【免费下载链接】charts⚠️(OBSOLETE) Curated applications for Kubernetes项目地址https://gitcode.com/gh_mirrors/chart/charts点击查看免费下载本文以本仓库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 Chartchart 版本0.6.1应用版本0.9.5默认将 Keel 部署到kube-system命名空间与早期 Helm 的Tiller所在命名空间保持一致。Keel 的核心能力Keel 的价值在于把镜像出新版本 → 应用自动升级这件事自动化其主要特性如下Kubernetes 与 Helm 双 ProviderKeel 同时提供对 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 RegistryGCR自动配置通过周期性扫描环境自动为你的部署镜像建立 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 仓库下文安装命令仅适用于本归档版本。安装 ChartKubernetes Provider 模式默认本 Chart 默认启用Docker 镜像轮询与Kubernetes Provider即当新的 Docker 镜像可用时集群中的 Kubernetes Deployment 会被自动升级。执行helm upgrade --install keel stable/keel在 templates/deployment.yaml 中可以看到该模式的实际落地方式容器以command: [/bin/keel]启动polling.enabled默认true直接映射为环境变量POLL1从而开启轮询容器监听9300端口并提供/healthz就绪/存活探针initialDelaySeconds: 30、timeoutSeconds: 10方便安装后快速验证。安装完成后可按 templates/NOTES.txt 的提示验证 Pod 是否就绪kubectl --namespacekube-system get pods -l appkeel,releasekeel安装 ChartHelm Provider 模式如果希望 Keel 管理的是Helm Release而不仅是 Deployment需要显式开启 Helm Provider。轮询默认已开启只需追加--set参数helm upgrade --install keel stable/keel --set helmProvider.enabledtrue从源码看helmProvider.enabledtrue会在容器环境中注入HELM_PROVIDER1见 templates/deployment.yamlKeel 进程据此加载 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 apps values tag: image.tag # it must be the same names as your apps 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.policyall,keel.triggerpoll,keel.pollScheduleevery 3m \ --set keel.images[0].repositoryimage.repository \ --set keel.images[0].tagimage.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 两种 ProviderParameterDescriptionDefaultpolling.enabledDocker registries pollingtruehelmProvider.enabledEnable/disable Helm providerfalsegcr.enabledEnable/disable GCR Registryfalsegcr.projectIDGCP Project ID GCR belongs togcr.pubsub.enabledEnable/disable GCP Pub/Sub triggerfalsewebhook.enabledEnable/disable Webhook Notificationfalsewebhook.endpointRemote webhook endpointslack.enabledEnable/disable Slack Notificationfalseslack.tokenSlack tokenslack.channelSlack channelslack.approvalChannelSlack approval channelslack.botNameSlack Bot nameservice.enableEnable/disable Keel servicefalseservice.typeKeel service typeLoadBalancerservice.externalPortKeel service port9300webhookRelay.enabledEnable/disable WebhookRelay integrationfalsewebhookRelay.keyWebhookRelay keywebhookRelay.secretWebhookRelay secretwebhookRelay.bucketWebhookRelay bucket参数可通过--set keyvalue[,keyvalue]逐项传入helm install也可以准备一份 YAML 文件一次性提供全部参数$ helm install --name keel -f values.yaml stable/keelTip: 可以直接使用本 Chart 自带的默认 values.yaml 作为起点它已包含上述所有参数的默认值与注释说明。参数到环境变量的映射源码级解读对照 templates/deployment.yaml 可以看到这些 values 参数最终都会被翻译为 Keel 进程读取的环境变量Values 参数注入的环境变量生效条件polling.enabledPOLL1/0恒注入按开关取值helmProvider.enabledHELM_PROVIDER1仅true时注入gcr.enabledPROJECT_ID、PUBSUB1仅true时注入webhook.enabledWEBHOOK_ENDPOINT仅true时注入slack.enabledSLACK_TOKEN、SLACK_CHANNELS、SLACK_BOT_NAME、SLACK_APPROVALS_CHANNEL仅true时注入几点实操提醒与默认 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.enabledfalse即不创建 Service此时 Keel 只能通过轮询方式工作。若需要接收 Docker Registry 推送的 Webhook应开启服务service: enabled: true type: LoadBalancer externalPort: 9300templates/service.yaml 会据此创建type: LoadBalancer的 Service将外部9300端口转发到容器9300端口targetPort: 9300协议 TCP服务名keel。安装完成后按 templates/NOTES.txt 的提示获取访问地址LoadBalancerexport SERVICE_IP$(kubectl get svc --namespace kube-system keel -o jsonpath{.status.loadBalancer.ingress[0].ip})然后访问http://$SERVICE_IP:9300LoadBalancer 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模式集成 WebhookRelaywebhookrelay.com由 webhookrelayd 容器在集群内部接收并转递 Webhook。启用方式helm upgrade --install keel stable/keel \ --set webhookRelay.enabledtrue \ --set webhookRelay.keyYOUR_KEY \ --set webhookRelay.secretYOUR_SECRET \ --set webhookRelay.bucketYOUR_BUCKET对应实现细节templates/secrets-webhookrelay.yaml 会将key/secret通过b64enc编码写入名为keel-webhookrelay的OpaqueSecrettemplates/deployment.yaml 在 Keel 容器旁追加webhookrelayd容器默认镜像webhookrelay/webhookrelayd:0.6.3IfNotPresentKEY与SECRET通过secretKeyRef从上述 Secret 注入BUCKET直接作为环境变量传入。该模式下不需要service.enabledtrueKeel 内网即可收到来自 WebhookRelay 转发的事件。模板命名与基础结构本 Chart 的模板命名遵循 Helm 惯例见 templates/_helpers.tplkeel.name默认取.Chart.Name即keel支持通过nameOverride覆盖并按 DNS 规范截断到 63 字符keel.fullname默认拼接为release-name-keel同样截断 63 字符并去除尾部-。此外 Chart 还会创建一个同名的 ServiceAccounttemplates/service-account.yaml中固定创建、不可关闭Deployment 通过注解kubernetes.io/service-account.name: keel关联使用。弃用说明与迁移方向本仓库中的stable/keel已按官方弃用流程归档deprecated: truechart 版本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 与本仓库模板源码即可在此基础上搭建一套镜像更新即自动发布的持续部署环境。赞分享【免费下载链接】charts⚠️(OBSOLETE) Curated applications for Kubernetes项目地址https://gitcode.com/gh_mirrors/chart/charts点击查看免费下载相关推荐Fuzzywuzzy云原生部署Kubernetes集群与Helm ChartFuzzywuzzy云原生部署Kubernetes集群与Helm Chart 一、Fuzzywuzzy容器化基础 Fuzzywuzzy项目提供Dockerfi后端Kubernetes部署策略蓝绿部署、金丝雀发布与滚动更新Kubernetes部署策略蓝绿部署、金丝雀发布与滚动更新 本文深入探讨了Kubernetes中的三种核心部署策略滚动更新、蓝绿部署和金丝雀发布。首先详细分云原生容器编排集群管理微服务RunVSAgent支持的三大AI编码代理Roo Code、Cline与Kilo Code深度测评RunVSAgent支持的三大AI编码代理Roo Code、Cline与Kilo Code深度测评 RunVSAgent是一款能够在其他IDE平台中无缝运行基开发工具AI Agent人工智能创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考