Gardener项目：如何为不同Worker Pool独立控制Kubernetes版本-优快云博客

本文链接：https://blog.youkuaiyun.com/gitblog_01136/article/details/148602713

Gardener项目：如何为不同Worker Pool独立控制Kubernetes版本

gardener Homogeneous Kubernetes clusters at scale on any infrastructure using hosted control planes. 项目地址: https://gitcode.com/gh_mirrors/ga/gardener

背景介绍

在Kubernetes集群管理中，版本升级是一个需要谨慎处理的操作。传统方式下，集群的控制平面(Control Plane)和所有工作节点(Worker Node)必须保持相同的Kubernetes版本。这种强一致性要求虽然简化了管理，但在实际生产环境中可能会带来诸多不便。

传统方式的局限性

在早期版本的Gardener中，所有worker pool都会继承控制平面的Kubernetes版本。当控制平面版本变更时，所有worker pool都会随之更新：

主版本变更：通过滚动更新节点实现
补丁版本变更：原地更新

这种方式对于处理大量数据的敏感工作负载来说可能不够灵活，因为这些工作负载通常对节点重启非常敏感。

Gardener v1.36+的改进

从Gardener v1.36版本开始，引入了为不同worker pool独立指定Kubernetes版本的能力。这一功能带来了以下优势：

渐进式升级：可以先升级控制平面，再逐步升级worker pool
工作负载灵活性：为不同类型的工作负载选择最合适的Kubernetes版本
最小化影响：减少因版本升级导致的服务中断

实现原理

通过在Shoot资源的spec中为每个worker pool单独指定.spec.provider.workers[].kubernetes.version字段，可以实现worker pool版本与控制平面版本的解耦。

配置示例

spec:
  kubernetes:
    version: 1.27.4  # 控制平面版本
  provider:
    workers:
    - name: data1    # 第一个worker pool
      kubernetes:
        version: 1.26.8  # 显式指定版本
    - name: data2    # 第二个worker pool
                     # 未指定版本，继承控制平面版本

版本控制规则

Gardener对worker pool的Kubernetes版本有以下约束条件：

默认继承：如果worker pool未指定版本，则继承控制平面版本
最大版本差：worker pool版本最多可比控制平面低两个小版本
降级限制：如果worker pool之前未指定版本，则不能直接设置为比当前控制平面低的版本
版本移除限制：当从worker pool中移除版本指定时，与控制平面的版本差不能超过一个小版本

使用场景建议

敏感工作负载升级：
- 先升级控制平面
- 保持worker pool版本不变
- 添加新版本worker pool
- 逐步迁移工作负载
多版本共存：
- 为不同特性的工作负载选择最适合的Kubernetes版本
- 例如：新特性需求的工作负载使用较新版本，稳定性要求高的工作负载使用较旧版本
渐进式升级：
- 先升级部分worker pool验证稳定性
- 确认无误后再升级剩余worker pool