十一分钟，零人工：在Kairos上构建自愈式Kubernetes升级流水线
内容提要
本文介绍了一个基于Kairos不可变Linux发行版的Kubernetes管理集群升级流水线。通过Gitea、Renovate、Kyverno、Cosign、ArgoCD和kairos-operator六种工具，实现全自动滚动升级，零人工干预，11分钟内完成三节点升级，无中断。文中还提到修复了并发升级bug和Renovate模板字段问题，并计划扩展至网关集群。
延伸解读
并发升级的隐患
文章指出，升级配置中的`concurrency: 0`并非预期中的“一次一个节点”，而是“所有节点同时”。这导致三节点控制平面同时重启，etcd仲裁幸免于难，但纯属运气。修复为`concurrency: 1`后，升级才真正安全。这提醒我们，Kubernetes升级中并发控制至关重要，错误的配置可能带来集群不可用的风险。
不可变基础设施的升级策略
Kairos采用A/B分区升级，新镜像写入非活动分区后重启，回滚只需引导旧分区。这种设计增强了供应链安全，但升级流程必须自动化才能发挥价值。本文的流水线通过Renovate自动检测新版本、ArgoCD应用变更、kairos-operator执行滚动升级，实现了零人工干预，展示了不可变基础设施与GitOps结合的优势。
自动化中的“静默失败”陷阱
Renovate的`extractVersionTemplate`字段不存在，导致版本号未正确转换，升级CR的`metadata.name`未更新，流水线看似运行却未执行升级。这凸显了自动化中“静默失败”的风险：工具可能看似正常，实则未完成预期任务。因此，保留人工审查环节至关重要，以捕捉自动化中的逻辑错误。
Q&A
Kairos是什么？它如何实现系统升级？
Kairos是一个不可变的Linux发行版，基于A/B分区升级和cosign签名镜像。它不进行原地修补，而是将新操作系统镜像写入非活动分区并重启，回滚只需引导旧分区。
这个Kubernetes升级流水线使用了哪些工具？各自的作用是什么？
使用了六种工具：Gitea（自托管Git和CI）、Renovate（检测新版本并自动开PR）、Kyverno（准入控制，验证镜像来源）、Cosign（验证镜像签名）、ArgoCD（GitOps，自动应用变更）、kairos-operator（执行节点升级）。
升级过程中如何保证etcd quorum不丢失？
通过设置升级CR的concurrency为1，确保一次只升级一个节点，避免多个控制平面节点同时重启导致quorum丢失。
为什么升级CR的metadata.name必须改变？
因为NodeOpUpgrade是一次性资源，kairos-operator处理完后不会重新处理。如果只修改spec.image，operator不会触发新升级。改变metadata.name会强制ArgoCD删除旧CR并创建新CR，从而触发升级。
Renovate的extractVersionTemplate字段有什么问题？如何修复？
extractVersionTemplate在Renovate的自定义管理器模式中不存在，导致它静默失效，Renovate只更新了镜像标签而没有更新CR名称。修复方法是改用currentValueTemplate，它能正确转换版本格式，使Renovate的版本比较逻辑正常工作。
这次升级实际耗时多久？人工干预多少？
从PR合并到所有节点完成升级，总耗时11分钟，人工干预为零。
未来计划如何进一步改进这个流水线？
计划将网关集群也纳入同一ArgoCD GitOps循环，并增加CI dry-run阶段，在PR合并前运行kairos-agent upgrade --recovery测试新镜像，提前发现失败。
