1. 需求背景

在传统的虚拟机部署形式下，部分客户依赖虚拟机 IP 地址，用于问题排查、监控、流量分配等，固定 IP 支持能够帮助用户更好地从虚拟机向容器迁移，提升运维效率。

2. 需求概览

固定 IP，是指 Statefulset 所管理的 Pod，其全生命周期内，所对应的 IP 不变，即一个 Pod 在生命周期内对应的IP不变。 不过，需要强调的是，我们要实现的是 Pod-name 与PodIP对应关系不变，而不是 Pod UUID不变。这也是为什么只有 sts 的 pod 才支持固定IP，而 Deployment 等的 Pod 无法支持固定 IP。

2.1 指定 Pod 对应 IP

对于支持固定IP，又分为1）支持让用户指定IP 及 2）不支持让用户指定IP两种，第一期产品设计中，对外仅考虑不指定 IP 设计，指定 IP 需求将在后期迭代中规划。

2.2 多子网问题

第一期：只支持单个子网的 Sts，需要在文档中强提醒为 Sts 分配合理的 Node 节点和子网
第二期：为 Node 节点添加子网 label，显式声明子网，仍然仅支持单子网模式

2.2 删除 Pod 时的 IP 回收策略

另外，Pod被删除时（可以是缩容时，也可以是STS被删除时），IP回收的策略： 1）如果立即回收，则可能会导致扩容时sts-pod-4这个以前存在过的Pod IP出现变化，与预期不符合。2）如果在一定周期后回收，这又引入了一个周期管理的问题，使得方案过于复杂。 3）如果不回收，则以为着会有大量的IP一直未被释放，因此需要引入一个用户手工删除CRD的能力。
第一期：默认不回收，引入手工删除 CRD 能力，保留回收策略参数
第二期：支持设置回收时间

3. 功能列表

3.1 功能列表

功能模块 功能点 优先级
STS 固定 IP 插件管理 创建插件 P0
查看插件 P1
删除插件 P1
升级插件 P2，本期暂不支持
IP 资源池查看 P1
IP 资源池删除 P1
STS / Pod 及对应 IP 的管理 Sts 创建 P0
Sts 扩容 P0
Sts 缩容 P0
Sts 删除 P0
Sts 更新 P0
节点宕机 Pod 强制漂移 P1
节点被强制删除 P1
集群异常 / 删除 P1

3.2 参数说明

参数 说明
network.beta.kubernetes.io/ucloud-statefulset-static-ip Sts spec.template.annotations 中的参数
true / false，是否需要固定 IP，默认为 false
network.beta.kubernetes.io/ucloud-statefulset-ip-claim-policy Sts spec.template.annotations 中的参数
int (≥0)，单位为小时；默认留空，即不回收；取 0 时为立即回收。第一期不对用户暴露该参数，即默认永不回收（除非手动删除）
VpcIPClaim 自定义 CRD 对象，记录 VpcIP（CNI 为 Pod 申请的 SecondaryIP）、Pod 与 VpcIP 之间的对应关系，Pod Node Mac 地址等，对应相应的 PodName 及 NS 并具有唯一性

4. STS 固定 IP 插件管理

待完成
有 CRD 及 VpcIPClaim 的时候，不允许做插件的删除

5. STS / Pod 及对应 IP 的管理

5.1 Pod 创建（Sts 创建 / Sts 扩容）

  • 适用于 Sts 创建及 Sts 扩容两种场景
  • 由于 Node 没有子网的 Label ，无法做 Sts 及 Pod 子网的控制，第一期先忽略子网的问题，如 Pod 在 Sts 缩容再扩容情况下被调度到不同的子网，则直接报错
  • 在 Sts 更新（Pod 删除再创建），节点正常宕机导致的 Pod 迁移中，也会出现 Pod 创建的场景，参照此流程图

image.png

5.2 Pod 删除（Sts 缩容 / Sts 删除）

  • Sts 删除（即 Sts 缩容到 replica = 0）与 Sts 缩容无额外的逻辑或异常状况需要处理
  • 在 Sts 更新（Pod 删除再创建），节点正常宕机导致的 Pod 迁移中，也会出现 Pod 删除的场景，参照此流程图

image.png

5.3 Sts 更新

Sts 更新过程，可拆解为老 Pod 删除（Sts 缩容）+ 新 Pod 创建（Sts 扩容），参照 5.1 及 5.2。

5.4 节点宕机

5.4.1 正常宕机

触发 Pod 的强制迁移，即 Pod 删除 + Pod 创建过程。

5.4.2 非正常宕机

场景：CNI 及 Sts 插件来不及记录 Pod 的销毁，SecondaryIP 仍然被绑定在原 Node 主机上，VpcIPClaim 中仍然记录「InUse」，但 K8S 已经触发重新创建 Pod
动作：强制更新 VpcIPClaim 中的 Mac 地址等

5.5 节点强制删除

场景：云主机页面进行的 Node 节点删除

  • 主要处理 VpcIP 作为 SecondaryIP，被虚拟网络强制回收的情况
  • 如果申请不到原来的 IP，直接报错，由后台提醒用户做手动 IP 的释放

image.png

6. 异常情况处理

  • 集群删除，删除所有 VpcIP 及相应的 VpcIPClaim。
  • Node 节点全部被强制删除，参照「5.5 节点强制删除」逻辑。节点全部被强制删除的情况下，CRD 对象（VpcIPClaim）仍会保留在 Master 节点的 etcd 中，在重新添加 Node 节点时恢复。
  • Master 节点被强制删除，Node 节点还在，则 VpcIPClaim 对象无法正常恢复
  • Sts 固定 IP 插件或 CRD controller 被误删，仍将保留 VpcIPCaim 对象，重新安装后恢复正常管理机制
  • VpcIPClaim 对象被误删，需要手工联系后台，重新根据原有 Pod、Node、VpcIP 信息创建 VpcIPClaim 对象进行恢复，如 VpcIPClaim Template 及对象均被删，直接报错，无法恢复
  • 用户在 Deployment 中声明 static-ip = true，或没有安装 Sts 固定 IP 插件的情况下声明了 static-ip = true，直接报错