Kubernetes原地升级实现原理

kubernetes原地升级实现原理

在介绍原地升级实现原理之前，我们先来看一些原地升级功能所依赖的原生 Kubernetes 功能：

技术背景

背景 1：Kubelet 针对 Pod 容器的版本管理

每个 Node 上的 Kubelet，会针对本机上所有 Pod.spec.containers 中的每个 container 计算一个 hash 值，并记录到实际创建的容器中。

如果我们修改了 Pod 中某个 container 的 image 字段，kubelet 会发现 container 的 hash 发生了变化、与机器上过去创建的容器 hash 不一致，而后 kubelet 就会把旧容器停掉，然后根据最新 Pod spec 中的 container 来创建新的容器。

这个功能，其实就是针对单个 Pod 的原地升级的核心原理。

背景 2：Pod 更新限制

在原生 kube-apiserver 中，对 Pod 对象的更新请求有严格的 validation 校验逻辑：

// validate updateable fields:
// 1.  spec.containers[*].image
// 2.  spec.initContainers[*].image
// 3.  spec.activeDeadlineSeconds

简单来说，对于一个已经创建出来的 Pod，在 Pod Spec 中只允许修改containers/initContainers 中的 image 字段，以及 activeDeadlineSeconds 字段。对 Pod Spec 中所有其他字段的更新，都会被 kube-apiserver 拒绝。

背景 3：containerStatuses 上报

kubelet 会在 pod.status 中上报 containerStatuses，对应 Pod 中所有容器的实际运行状态：

apiVersion: v1
kind: Pod
spec:
  containers:
  -