问题说明
kube-proxy 在 iptables 模式下，如果 Pod 升级或异常重启后，选用的 iptables 命令后端实现可能发生切换。此情况下，若 Service 后端发生变更，可能会导致 Service 访问异常。
具体受影响的 Kubernetes 版本以及 kube-proxy 版本为：
集群版本 | kube-proxy 模式 | kube-proxy 版本 |
1.24 | iptables | v1.24.4-tke.4 及以下 |
1.22 | iptables | v1.22.5-tke.10 及以下 |
1.20 | iptables | v1.20.6-tke.30 及以下 |
1.18 | iptables | v1.18.4-tke.34 及以下 |
1.16 | iptables | v1.16.3-tke.33 及以下 |
1.14 | iptables | v1.14.3-tke.27 及以下 |
具体受影响的节点操作系统版本为：
实现 iptables 双后端版本 | 系统默认后端 |
TencentOS Server 3.1（TK4） | nft |
TencentOS Server 3.1（Final） | nft |
CentOS Linux 8 | nft |
修复方案
将 kube-proxy 升级到以下版本：
TKE 集群版本 | 修复策略 |
1.24.4 | v1.24.4-tke.24 及以上 |
1.22.5 | v1.22.5-tke.33 及以上 |
1.20.6 | v1.20.6-tke.52 及以上 |
1.18.4 | v1.18.4-tke.49-rc1 及以上 |
1.16.3 | v1.16.3-tke.42-rc2 及以上 |
1.14.3 | v1.14.3-tke.33-rc2 及以上 |
kube-proxy 升级方法
kube-proxy 升级影响
如果 Node 使用原地滚动升级，正常情况下对业务基本无影响。kube-proxy 是控制面组件，升级时会对 kube-proxy pod 进行一次重启，pod 启动时间大约30秒：
1. 对当前已有的 Service 的转发面无任何影响。
2. 在 pod 启动期间新建的 Service，生效时间略有延迟。
kube-proxy iptables 命令后端切换场景说明
说明：
1. 受影响的节点操作系统中 iptables 命令后端同时存在 legacy 和 nft 后端。
2. 受影响的 kube-proxy 版本，iptables 后端选择逻辑为：首先判断 legacy 后端下规则数是否大于等于 10 条，如果是则使用 legacy 后端，不是则判断 legacy 后端规则数是否大于等于 nft 后端条目数，是则使用 legacy，否则使用 nft。
3. 高版本 kube-proxy 会使用节点操作系统默认的 iptables 后端。
Pod 异常重启/主动重建场景
初始时使用 nft 后端，启动后其他组件在 legacy 后端增加了规则，导致 legacy 后端规则数大于等于 10。重启后导致后端切换到 legacy。
Pod 升级场景
升级前使用 legacy 后端，升级后切换到节点默认后端 nft。
