helm 部署 hyperf 需自建 chart，因官方无标准 chart；通过 helm create 封装已有 yaml、参数化 values.yaml、配置滚动更新与探针、结合 ci/cd 多环境管理。
直接用 Helm 部署 Hyperf 并不常见，因为 Hyperf 是 PHP 应用，本身不是云原生中间件（如 Redis、MinIO、Harbor），官方并未提供标准 Helm Chart。但你可以通过自建 Chart 的方式，把已有的 Kubernetes YAML（Deployment、Service、ConfigMap 等）打包成 Helm Chart，实现参数化、可复用、易管理的部署流程。
为什么不用现成的 Hyperf Helm Chart
目前 Bitnami、MinIO、Harbor 等项目都维护了高质量的官方 Helm Chart，但 Hyperf 社区和主流仓库（如 Artifact Hub）中没有被广泛采纳的、开箱即用的官方 Chart。它的部署逻辑更贴近“通用 Web 应用”，而非有状态中间件，因此最佳实践是：自己封装 Chart，复用已有 K8s 配置。
快速部署四步走
你只需基于已有的 Hyperf K8s YAML 文件（如 namespace.yaml、configmap.yaml、deployment.yaml 等），做轻量封装：
- 新建空 Chart：
helm create hyperf-app，删掉 templates/ 下默认示例，保留_helpers.tpl - 把你的 YAML 拆解后放入 templates/ 目录：namespace →
namespace.yaml，ConfigMap →configmap.yaml，Secret →secret.yaml，Deployment + Service →deployment.yaml（注意将硬编码值替换成{{ .Values.xxx }}） - 在
values.yaml中定义可配置项，例如：
replicaCount: 3
image: registry.company.com/hyperf-app:latest
servicePort: 9501
resources.requests.memory: "256Mi"
env.APP_ENV: "prod" - 安装部署：
helm install hyperf-prod ./hyperf-app -n hyperf-prod --create-namespace
关键配置要点
Hyperf 在 K8s 中稳定运行，需特别关注三点：
-
滚动更新策略：在 Deployment 模板中设
maxUnavailable: 0和maxSurge: 1，确保零停机升级 -
健康探针：livenessProbe 建议调用
/health或执行php bin/hyperf.php ping；readinessProbe 可复用相同逻辑，避免新 Pod 过早接收流量 -
优雅终止：在 containers.lifecycle.preStop 中添加
sleep 10 && kill -SIGTERM 1，给 Swoole Worker 足够时间处理完长连接和队列任务
进阶建议：对接 CI/CD 与多环境
把 Chart 推到私有 Helm 仓库（如 Harbor 的 Helm Chart 仓库或 ChartMuseum），再结合 GitOps 工具（Argo CD / Flux）管理不同环境：
- 开发环境用
values-dev.yaml：资源限制宽松、开启 debug 日志、挂载 ConfigMap 为文件而非 env - 生产环境用
values-prod.yaml：启用 Secret 注入敏感信息、开启 TLS（配合 Ingress）、限制 CPU/Memory 防止雪崩 - CI 流水线中自动渲染并验证：
helm template hyperf-prod ./hyperf-app -f values-prod.yaml | kubectl apply -f -
