Kubernetes kOps项目升级v1.26时ServiceAccountIssuer变更问题解析
2025-05-14 04:21:01作者:庞队千Virginia
在Kubernetes集群管理工具kOps从v1.25升级到v1.26版本的过程中,一个关键变化是移除了masterInternalName配置项。这个看似简单的变更实际上会引发一系列连锁反应,特别是对ServiceAccount令牌签发机制的影响,可能导致集群升级后关键组件如Calico网络插件无法正常工作。
问题背景
当用户尝试将kOps从v1.25.4升级到v1.26.6版本时,升级过程中会自动修改两个关键配置:
- 移除显式指定的
masterInternalName - 自动将
serviceAccountIssuer和serviceAccountJWKSURI的值从原来的master.cluster.domain变更为api.internal.cluster.domain
这种变更导致的核心问题是:所有依赖ServiceAccount令牌进行认证的组件(如Calico CNI插件)会突然无法通过认证,因为它们持有的令牌是由旧的签发者(master.cluster.domain)签发的,而API Server现在只认可新签发者(api.internal.cluster.domain)的令牌。
问题表现
升级过程中最明显的症状是:
- Calico-node Pod中的install-cni init容器启动失败,报错"Unable to create token for CNI kubeconfig error=Unauthorized"
- 其他依赖k8s API的Pod也出现类似的未授权错误
- 新启动的控制平面节点上的核心组件无法正常工作
根本原因分析
这个问题源于Kubernetes的服务账户令牌签发机制。在Kubernetes中:
- ServiceAccount令牌包含签发者(issuer)信息
- API Server会验证请求中令牌的签发者是否与当前配置的
serviceAccountIssuer匹配 - 当签发者变更时,所有现有的令牌立即失效
- kOps v1.26强制使用
api.internal.cluster.domain作为签发者,不再支持自定义的masterInternalName
解决方案
经过实践验证,可以采用以下分阶段迁移方案来平滑过渡:
第一阶段:准备阶段
- 在集群配置中添加
additionalSans,包含原masterInternalName的值 - 从集群配置中移除
masterInternalName - 在master节点组中添加pre-hook,临时修改kube-apiserver manifest,将原签发者作为主签发者
第二阶段:初始迁移
- 应用配置变更并滚动更新master节点
- 手动创建
master.cluster.domain的DNS记录指向master节点IP - 更新
kubernetes-services-endpointConfigMap中的KUBERNETES_SERVICE_HOST值(如使用Calico CNI)
第三阶段:签发者切换
- 更新pre-hook,将新签发者设为主签发者,原签发者作为辅助签发者
- 再次应用变更并滚动更新master节点
- 滚动更新集群中所有worker节点
第四阶段:清理阶段
- 等待24小时确保所有动态SA令牌刷新
- 移除master节点组中的pre-hook
- 从集群配置中移除
additionalSans - 最后滚动更新master节点
- 删除临时的
master.cluster.domainDNS记录
技术要点
在整个迁移过程中,有几个关键点需要特别注意:
- DNS记录的维护至关重要 - 必须确保
master.cluster.domain始终正确解析到当前master节点的IP - 分阶段切换签发者可以避免服务中断 - 先添加新签发者为辅助,再提升为主签发者
- 足够的等待时间 - 确保所有组件都有机会刷新它们的ServiceAccount令牌
- 全节点滚动更新 - 确保集群中所有节点都使用新配置
未来改进
kOps社区已经意识到这个问题,并在新版本中计划添加对多ServiceAccount签发者的原生支持。这将使类似的迁移变得更加简单和安全,无需复杂的pre-hook操作。
对于计划升级到kOps v1.26及更高版本的用户,建议:
- 提前规划ServiceAccount签发者迁移策略
- 在测试环境验证迁移方案
- 考虑等待支持多签发者的kOps版本发布后再进行升级
通过这种谨慎的迁移方法,用户可以确保集群在kOps升级过程中保持稳定,避免因ServiceAccount令牌失效导致的服务中断。
登录后查看全文
热门项目推荐
相关项目推荐
atomcodeClaude Code 的开源替代方案。连接任意大模型,编辑代码,运行命令,自动验证 — 全自动执行。用 Rust 构建,极致性能。 | An open-source alternative to Claude Code. Connect any LLM, edit code, run commands, and verify changes — autonomously. Built in Rust for speed. Get StartedRust0213
cann-learning-hubCANN 学习中心仓,支持在线互动运行、边学边练,提供教程、示例与优化方案,一站式助力昇腾开发者快速上手。Jupyter Notebook0138
uni-appA cross-platform framework using Vue.jsJavaScript08
GLM-5.2智谱开源 GLM-5.2,这是针对长文本任务的最新旗舰模型。相较于前代产品 GLM-5.1,它在长文本任务处理能力上实现了显著飞跃,并且首次在稳定的 100 万 token 上下文中提供这一能力。Jinja00
SwanLab⚡️SwanLab - an open-source, modern-design AI training tracking and visualization tool. Supports Cloud / Self-hosted use. Integrated with PyTorch / Transformers / LLaMA Factory / veRL/ Swift / Ultralytics / MMEngine / Keras etc.Python00
tiny-universe《大模型白盒子构建指南》:一个全手搓的Tiny-UniverseJupyter Notebook03
项目优选
收起
deepin linux kernel
C
32
16
openEuler内核是openEuler操作系统的核心,既是系统性能与稳定性的基石,也是连接处理器、设备与服务的桥梁。
C
469
465
暂无描述
Dockerfile
778
5.08 K
Ascend Extension for PyTorch
Python
757
968
本项目是CANN提供的transformer类大模型算子库,实现网络在NPU上加速计算。
C++
876
2.03 K
本项目是CANN提供的神经网络类计算算子库,实现网络在NPU上加速计算。
C++
697
1.4 K
昇腾LLM分布式训练框架
Python
185
231
JiuwenSwarm 是一款基于openJiuwen开发的智能AI Agent,它能够将大语言模型的强大能力,通过你日常使用的各类通讯应用,直接延伸至你的指尖。
Python
2.25 K
676
本项目是CANN提供的数学类基础计算算子库,实现网络在NPU上加速计算。
C++
1.1 K
1.14 K
本仓库是 Flutter SDK 与 Flutter Engine 的 OpenHarmony 适配版本,由 CPF-Flutter 团队维护。开发者可使用熟悉的 Flutter 技术栈开发 OpenHarmony 应用,3.35.7 及以后的适配版本可基于本仓库源码构建支持 OpenHarmony 的 Flutter Engine。
Dart
1.04 K
271