企业官网建设流程全解析

本文以本仓库stable/keel中已归档（DEPRECATED）的 Keel Helm Chart 为对象，完整讲解如何在 Kubernetes 集群中安装 Keel、启用 Kubernetes / Helm 双 Provider，并通过部署注解或 Helm release 配置让业务应用在镜像更新时自动升级。读完本文，你将掌握 Keel 的完整安装流程、18 项核心配置参数、轮询（polling）触发与 WebhookRelay 侧车集成方式，并了解本仓库图表在弃用后的迁移方向。

Keel 是一个用于自动化 Kubernetes 部署更新的工具，它本身无状态（stateless）、健壮（robust）且轻量（lightweight）。在 Helm Charts 官方仓库中，stable/keel目录提供了对应的 Helm Chart（chart 版本0.6.1，应用版本0.9.5），默认将 Keel 部署到kube-system命名空间（与早期 Helm 的Tiller所在命名空间保持一致）。

Keel 的核心能力

Keel 的价值在于把"镜像出新版本 → 应用自动升级"这件事自动化，其主要特性如下：

• Kubernetes 与 Helm 双 Provider：Keel 同时提供对 Kubernetes Deployment 和 Helm Release 的直接集成，可以分别管理这两类工作负载的更新。
• 无 CLI / 无 API：与其他***ctl式运维工具不同，Keel 不提供命令行或 API 接口，一切通过标签（labels）、注解（annotations）和 Chart 配置完成。
• Semver 策略（Semver policies）：可以为每个 Deployment 或 Helm Release 单独指定更新策略（all/major/minor/patch/force）。
• Google Container Registry（GCR）自动配置：通过周期性扫描环境，自动为你的部署镜像建立 Pub/Sub topic 和 subscription，实现 GCR 推送事件触发。
• 原生 DockerHub、Quay Webhook 支持：收到 Webhook 后，Keel 会自动识别受影响的 Deployment 并执行更新。
• 轮询机制（Polling）：当 Webhook 与 Pub/Sub 都不可用时，Keel 仍可定期查询 Docker Registry——若当前 tag 是 semver 版本则检测新 tag，若使用latest这类 tag 则检测同一 tag 的 SHA digest 变化。
• 通知（Notifications）：开箱即用地支持 Slack 通知与标准 Webhook 通知。

这些能力共同构成了一个"设置一次、长期自动"的持续部署（Continuous Deployment）基础组件。注意，本仓库中的stable/keelChart 已在 Chart.yaml 中标记deprecated: true，并遵循仓库的弃用流程归档，新版本 Chart 已迁移至 Keel 上游仓库维护的chart/keel目录与专用 Charts 仓库，下文安装命令仅适用于本归档版本。

安装 Chart：Kubernetes Provider 模式（默认）

本 Chart 默认启用Docker 镜像轮询与Kubernetes Provider，即当新的 Docker 镜像可用时，集群中的 Kubernetes Deployment 会被自动升级。执行：

helm upgrade --install keel stable/keel

在 templates/deployment.yaml 中可以看到该模式的实际落地方式：容器以command: ["/bin/keel"]启动，polling.enabled（默认true）直接映射为环境变量POLL=1，从而开启轮询；容器监听9300端口，并提供/healthz就绪/存活探针（initialDelaySeconds: 30、timeoutSeconds: 10），方便安装后快速验证。

安装完成后，可按 templates/NOTES.txt 的提示验证 Pod 是否就绪：

kubectl --namespace=kube-system get pods -l "app=keel,release=keel"

安装 Chart：Helm Provider 模式

如果希望 Keel 管理的是Helm Release（而不仅是 Deployment），需要显式开启 Helm Provider。轮询默认已开启，只需追加--set参数：

helm upgrade --install keel stable/keel --set helmProvider.enabled="true"

从源码看，helmProvider.enabled=true会在容器环境中注入HELM_PROVIDER=1（见 templates/deployment.yaml），Keel 进程据此加载 Helm Provider 逻辑，此后便能自动升级 Helm Release。

让 Helm Release 被 Keel 自动更新

要让自己发布的应用被 Keel 接管升级，需要在应用 Chart 的values.yaml中加入keel配置块，然后执行helm upgrade ...：

keel: # keel policy (all/major/minor/patch/force) policy: all # trigger type, defaults to events such as pubsub, webhooks trigger: poll # polling schedule pollSchedule: "@every 3m" # images to track and update images: - repository: image.repository # it must be the same names as your app's values tag: image.tag # it must be the same names as your app's values

配置要点：

• policy：更新策略，可选all（任意版本升级）、major、minor、patch（仅对应级别的 semver 升级）或force（强制）。
• trigger：触发方式，默认走 Pub/Sub、Webhook 等事件；设为poll则启用轮询。
• pollSchedule：轮询调度表达式，示例@every 3m表示每 3 分钟检查一次。
• images：需要跟踪与更新的镜像列表，其中repository与tag必须与你的应用values.yaml中的对应字段同名，Keel 才能正确对应到实际运行的镜像。

如果不方便维护values.yaml文件，也可以用--set标志在命令行中完成同样配置：

helm upgrade --install whd webhookdemo --reuse-values \ --set keel.policy="all",keel.trigger="poll",keel.pollSchedule="@every 3m" \ --set keel.images[0].repository="image.repository" \ --set keel.images[0].tag="image.tag"

值得注意的是，Keel 也会用这组keel.*配置自更新自身镜像（本 Chart 的默认 values.yaml 中即带有一份默认的keel.policy: all、keel.trigger: poll、keel.pollSchedule: "@every 3m"配置，注释说明"注释掉以下行即可关闭 Keel 自动自更新"）。更完整的策略与触发说明可参考 Keel 官方 User Guide。

卸载 Chart

卸载时直接删除 release，命令会移除该 Chart 关联的所有 Kubernetes 组件：

$ helm delete keel

配置参数总览

下表列出了stable/keelChart 的主要可配置参数，涵盖轮询、触发、通知与服务等维度，且同时适用于 Kubernetes 与 Helm 两种 Provider：

参数可通过--set key=value[,key=value]逐项传入helm install，也可以准备一份 YAML 文件一次性提供全部参数：

$ helm install --name keel -f values.yaml stable/keel

Tip: 可以直接使用本 Chart 自带的默认 values.yaml 作为起点，它已包含上述所有参数的默认值与注释说明。

参数到环境变量的映射（源码级解读）

对照 templates/deployment.yaml 可以看到，这些 values 参数最终都会被翻译为 Keel 进程读取的环境变量：

几点实操提醒（与默认 values.yaml 字段名保持一致）：

• gcr.projectID在 README 参数表中写作gcr.projectID，而 values.yaml 实际字段为gcr.projectId，部署模板读取的也是.Values.gcr.projectId，请以 values 文件中的拼写为准。
• Slack 审批频道参数在 README 表中写作slack.approvalChannel，但 values 与模板使用的实际字段是slack.approvalsChannel（复数形式），同样请以 values 文件与模板为准。
• 除了表格中的参数，values.yaml 还支持image.repository/image.tag/image.pullPolicy（默认keelhq/keel:0.9.5、IfNotPresent）、resources（默认注释掉，可按需放开 CPU/内存 limits 与 requests）、以及nodeSelector（默认空对象）。

对外暴露服务与 Webhook 接收

默认情况下service.enabled=false，即不创建 Service，此时 Keel 只能通过轮询方式工作。若需要接收 Docker Registry 推送的 Webhook，应开启服务：

service: enabled: true type: LoadBalancer externalPort: 9300

templates/service.yaml 会据此创建type: LoadBalancer的 Service，将外部9300端口转发到容器9300端口（targetPort: 9300，协议 TCP，服务名keel）。安装完成后，按 templates/NOTES.txt 的提示获取访问地址：

• LoadBalancer：export SERVICE_IP=$(kubectl get svc --namespace kube-system keel -o jsonpath='{.status.loadBalancer.ingress[0].ip}')，然后访问http://$SERVICE_IP:9300；LoadBalancer IP 分配可能需要数分钟，可用kubectl get svc --namespace kube-system -w keel观察。
• ClusterIP：可通过kubectl port-forward --namespace kube-system $POD_NAME 9300:9300在本地访问。
• NodePort：可用kubectl get --namespace kube-system -o jsonpath="{.spec.ports[0].nodePort}" services keel取得 NodePort 后访问。

WebhookRelay 侧车：不暴露公网也能收 Webhook

如果不想把 Keel Service 暴露到公网，本 Chart 支持以侧车（sidecar）模式集成 WebhookRelay（webhookrelay.com），由 webhookrelayd 容器在集群内部接收并转递 Webhook。启用方式：

helm upgrade --install keel stable/keel \ --set webhookRelay.enabled=true \ --set webhookRelay.key=YOUR_KEY \ --set webhookRelay.secret=YOUR_SECRET \ --set webhookRelay.bucket=YOUR_BUCKET

对应实现细节：

• templates/secrets-webhookrelay.yaml 会将key/secret通过b64enc编码写入名为keel-webhookrelay的OpaqueSecret；
• templates/deployment.yaml 在 Keel 容器旁追加webhookrelayd容器（默认镜像webhookrelay/webhookrelayd:0.6.3，IfNotPresent），KEY与SECRET通过secretKeyRef从上述 Secret 注入，BUCKET直接作为环境变量传入。

该模式下不需要service.enabled=true，Keel 内网即可收到来自 WebhookRelay 转发的事件。

模板命名与基础结构

本 Chart 的模板命名遵循 Helm 惯例（见 templates/_helpers.tpl）：

• keel.name：默认取.Chart.Name（即keel），支持通过nameOverride覆盖，并按 DNS 规范截断到 63 字符；
• keel.fullname：默认拼接为<release-name>-keel，同样截断 63 字符并去除尾部-。

此外 Chart 还会创建一个同名的 ServiceAccount（templates/service-account.yaml中固定创建、不可关闭），Deployment 通过注解kubernetes.io/service-account.name: keel关联使用。

弃用说明与迁移方向

本仓库中的stable/keel已按官方弃用流程归档（deprecated: true，chart 版本0.6.1、appVersion0.9.5），不再继续在helm/charts仓库内维护；新版本已迁移至 Keel 上游维护的新 Chart（源码位于 Keel 项目仓库的chart/keel目录，Charts 仓库为 charts.keel.sh）。如果你的集群仍在使用本归档版本，建议在规划下一次升级时评估迁移到上游新 Chart，并注意核对新 Chart 的配置字段与触发机制是否与本文所述保持一致。

小结

通过本文，你已经掌握了stable/keel这一 Kubernetes 原生自动更新组件的完整部署链路：默认 Kubernetes Provider 模式与 Helm Provider 模式的安装差异、应用侧keel.*配置块的编写与--set等价写法、18 项配置参数的语义与默认值、values 参数到容器环境变量的映射关系，以及 WebhookRelay 侧车方案和弃用后的迁移方向。参考 values.yaml 与本仓库模板源码，即可在此基础上搭建一套"镜像更新即自动发布"的持续部署环境。