土法炼钢 · 系统与基础设施

【Linkerd】运维与升级:证书轮转与 2.20 destination 内存门

文章导航

分类入口
kubernetesnetwork
标签入口
#linkerd#upgrade#trust-anchor#mTLS#destination#memory#certificate-rotation#v2.20

目录

第 11 篇 把 multicluster 钉在共享 trust anchor 上。本篇谈版本门与证书门:控制面如何按组件顺序升级、trust anchor 为何必须 bundle + 全网格滚动、2.20 destination 内存优化对运维意味着什么——以及 live 文档不能冒充 2.20

官方文档写明:工作负载证书由 Linkerd 自动轮转,但 issuer 与 trust anchor 不会自动轮转——默认一年期自签只是快速试用形态。跳过 bundle 直接换根,是轴 2 全网格握手失败的高频人为事故。

本篇在系列中的位置

篇目 核心内容
第 11 篇 · GAPI 与多集群 GAPI 门与 multicluster
第 12 篇 · 运维与升级 升级顺序、trust anchor、destination 内存门
第 13 篇 · 排障坐标系 五轴否证
系列目录 全部篇目

版本锚定:Linkerd 2.20(tag version-2.20)。trust anchor 步骤以 Manually Rotating Control Plane TLS Credentials / Automatically Rotating Control Plane TLS Credentials 为准。destination 内存叙述引用 2.20 公告与 changelog 机制,本站无压测不复述「百分之八十五」为自测结论。


一、控制面升级顺序

Linkerd 控制面拆为 destination ∥ identity ∥ proxy-injector第 1 篇),升级时遵循官方 Upgrade 任务文档:

阶段 对象 要点
1 CRD / 策略 API 先让 API 版本与 2.20 兼容,避免 webhook 拒绝
2 控制面 Deployment linkerd upgrade 或等价 Helm 升控制面镜像
3 数据面 滚动 meshed workload,使 proxy 与 API 版本匹配
4 验证 linkerd check 分类(有环境才执行;无环境只保留检查项语义)

不要在未升 CRD 的情况下只换 proxy 镜像;不要假设「控制面 Ready」等于全网格数据面已跟上。multicluster 场景需各集群按同一 trust 计划执行(第 11 篇)。

2.20 另含 native sidecar 默认第 2 篇):升级后新注入 Pod 与 legacy init+sidecar 可能并存,排障证据包须分列,不可混为「注入坏了」。


二、trust anchor 轮转

身份分层(第 4 篇):

层级 轮转 典型有效期(默认安装)
Trust anchor 手动;须 bundle 过渡 365 天(linkerd install 生成)
Issuer 手动;须在 anchor 就绪后 随文档
工作负载证书 自动 短周期

无停机 trust anchor 轮转Manually Rotating 文档顺序,语义摘要):

  1. 生成新 anchor,与旧 anchor 打成 bundle
  2. linkerd upgrade --identity-trust-anchors-file=./bundle.crt 应用到控制面。
  3. 滚动重启所有 meshed Pod——proxy 在启动时读 trust roots;未重启者仍只信旧根。
  4. 将 issuer 轮换为新 anchor 签发的证书;再次 upgrade + 验证。
  5. 再次滚动工作负载,使工作负载证书切到新 issuer。
  6. 从 bundle 中移除旧 anchor,最后一次 upgrade 与滚动。

自动方案(cert-manager + trust-manager)见 Automatically Rotating:核心不变——bundle 窗口内新旧根并存,控制面与数据面均需重启,否则会出现「一部分 proxy 只信蓝、另一部分已信绿」的分裂信任域。

失败模式 表象 落轴
未 bundle 直接换根 大面积 TLS handshake error 2
未滚动 meshed Pod 间歇性握手失败 2
issuer 先于 anchor bundle linkerd check identity 警告 2
multicluster 只升一端 跨集群 gateway mTLS 失败 2 + 11

争论点:短期工作负载证书降低泄露窗口(SPIFFE 工程实践),但 anchor 手动门把运维负担集中在平台团队——零停机轮转依赖纪律化 runbook,而非单键自动。


三、2.20 destination 内存优化

2.20 重构 destination 控制器内部状态管理:在官方公告与 PR 叙述中,高 churn、大规模 EndpointSlice 场景下控制面内存显著下降(机制:跨相同过滤条件的订阅者共享端点过滤与 diff 状态,changelog #15166 口径)。

维度 运维含义 不是什么
控制面 OOM / 内存持续上涨 2.20 起优先核对是否已升 destination 组件 「应用少占内存」
与轴 3 排障 发现延迟、空端点仍看 Get() 流与 Informer 内存优化不替代 Endpoint 配置错误
升级动机 大集群、频繁 Pod 调度 小集群未必观察到差异

本站 destination 内存压测;不写 CPU%、不写本站复现的「百分之八十五」。若需数字,引用 Linkerd 2.20 公告/enterprise release notes 并标注为外部叙述。轴 5「destination OOM」在 2.20 后应先否证版本是否含该重构,再查 EndpointSlice churn。


四、live vs tag

来源 用法
源码 tag version-2.20、配套 chart、该版本任务文档 机制结论唯一锚
Announcing Linkerd 2.20、2.20 changelog A/B 级:新特性与破坏面
linkerd.io/docs/ live / 2-edge 线索;后版本能力禁止写成 2.20 事实
第三方「一键升级」帖 C 级;不单独支撑

OSS 自 2024-02 起项目本身不再发布 stable 制品——机制仍钉 tag,安装包来源见 releases 与 vendor 说明(第 15 篇 展开)。

值班口诀:变更单写 tag,不写「docs 今天看到的新键」。


五、否证检查表

# 检查项 通过标准 失败落轴
1 目标版本 控制面与数据面钉 2.20 / version-2.20
2 CRD / webhook 与 2.20 兼容;策略与 SP 校验正常 4
3 linkerd check 无 identity / destination 失败类(有环境才执行) 2–3
4 Trust 计划 anchor 轮转含 bundle 窗口 + 全网格滚动记录 2
5 Issuer 顺序 新 issuer 由新 anchor 签发后再摘旧根 2
6 数据面滚动 meshed Pod proxy 版本与注入方式(native/legacy)已记录 1、5
7 destination 镜像 2.20 destination 含内存重构 5
8 GAPI CRD 集群 GAPI 版本在 1.2.1–1.5.1;Linkerd 使用字段 ⊆ 1.2.1 4
9 multicluster 各集群 trust bundle 一致且已滚动 2、11

无集群时不写「升级成功」叙事;上表作变更单否证模板。下一篇把升级失败与日常连接失败收进五轴排障


参考资料

规范 / 官方文档(A)

本系列


上一篇Gateway API 与多集群

下一篇排障坐标系

读完这篇,下一步读什么

优先读同系列或同问题的下一篇,把单篇消费变成主题集群。


By .