基于Rocky Linux 9 通过kubeadm部署Kubernetes + containerd + Cilium + Kube-vip高可用集群应用实践
一、整体架构设计与组件选型
1.1 设计目标
| |
|---|
| |
| 基于eBPF的Cilium替代kube-proxy，降低网络延迟和CPU开销 |
| |
| |
| |
1.2 集群整体逻辑架构
1.3 三主高可用集群运维系统架构拓扑
以下拓扑图展示了三主高可用集群中每个节点的核心组件部署关系，包括控制平面节点和工作节点上运行的各类进程及其交互方式。
拓扑要点说明：
- kube-vip：三个控制平面节点均运行kube-vip，同一时刻仅Leader持有VIP（虚线表示浮动关系），Follower通过Raft协议监听Leader状态
- etcd集群：三个etcd实例两两互联构成Raft共识集群，任一节点故障不影响数据一致性
- API Server本地etcd：每个apiserver优先连接本地etcd，减少网络跳转
- 工作节点kubelet：通过VIP:6443连接控制平面，VIP故障切换时自动重连至新Leader
- Cilium Agent：每个节点均运行Cilium Agent，负责向内核注入eBPF程序并维护跨节点隧道
- eBPF程序：运行在内核态，替代kube-proxy处理Service负载均衡和DNAT
1.4 网络请求流转示意图
以下示意图展示了集群中各类网络请求的完整流转路径，包括外部访问API Server、Pod间通信、Service负载均衡等核心场景。
请求流转说明：
| | |
|---|
| 客户端→VIP→ARP解析→Leader节点→kube-apiserver→etcd | |
| Pod→eBPF tc→Service后端表查找→DNAT→目标Pod | Cilium eBPF完全替代kube-proxy |
| Pod→eBPF egress→VXLAN封装→物理网络→eBPF ingress→目标Pod | Cilium VXLAN/Geneve隧道或Direct Routing |
| 外部流量→NodePort→eBPF拦截→SNAT+DNAT→目标Pod | Cilium eBPF NodePort处理，bpf_masquerade |
| kubelet→VIP:6443上报状态；API Server→:10250回调 | TLS Bootstrap证书认证、Watch长连接 |
1.5 组件交互与数据流架构
1.6 网络拓扑与流量路径
1.7 组件版本矩阵与操作系统兼容性
| | | | | | | |
|---|
| 操作系统 | | | | | | | |
| Linux内核 | | | | | | | |
| Kubernetes | | | | | | | |
| containerd | | | | | | | v2.0需glibc≥2.28，el7仅glibc 2.17；v1.7可用但非推荐 |
| Cilium | | | | | | | |
| kube-vip | | | | | | | |
| etcd | | | | | | | |
| crun | | | | | | | |
| runc | | | | | | | |
关键说明：
- CentOS 7 / RHEL 7（el7）：默认内核3.10，无法支持Cilium eBPF数据平面；更重要的是，el7默认glibc版本为2.17，而containerd v2.0+要求glibc ≥ 2.28，这意味着即使通过ELRepo升级内核至5.x解决了eBPF问题，el7仍无法运行containerd v2.0+，从根本上不具备部署本方案的条件。仅可使用containerd v1.7（非推荐版本），且需面对内核与CNI的双重限制
- CentOS 8 Stream / Rocky Linux 8 / RHEL 8（el8）：默认内核4.18、glibc 2.28，glibc满足containerd v2.0+要求，但内核需通过
dnf update kernel或ELRepo升级至5.x以支持Cilium eBPF完整功能 - Rocky Linux 9 / RHEL 9（el9）：默认内核5.14+、glibc 2.34，原生满足所有组件的内核与C库版本要求，为推荐操作系统
- Ubuntu 22.04/24.04：内核5.15/6.8、glibc 2.35/2.39，同样完整支持，可替代使用
glibc版本与containerd兼容性速查：
| | | | |
|---|
| | | | |
| el8（Rocky Linux 8 / RHEL 8） | | | | |
| el9（Rocky Linux 9 / RHEL 9） | | | | |
| | | | |
| | | | |
1.8 组件选型对比与决策依据
| | | |
|---|
| containerd | | 社区主流、性能优异、K8s原生支持、v2.0版本CRI接口稳定 |
| Cilium | | eBPF高性能数据平面、可替换kube-proxy、支持L3-L7网络策略、Hubble可观测 |
| kube-vip | HAProxy+Keepalived, Nginx+Keepalived | 原生K8s集成、静态Pod部署、ARP/BGP双模式、零外部依赖 |
| kubeadm | | |
| crun/runc | | crun性能更优体积更小；kata适用于强隔离场景 |
| Service NodePort → Gateway API | | ingress-nginx已列入退役计划，需尽早规划Gateway API选型（Envoy Gateway/Istio Gateway/Kong等）；初期可用Service NodePort |
二、关键技术原理说明
2.1 kube-vip高可用原理
kube-vip提供Kubernetes控制平面的高可用虚拟IP（VIP），支持两种工作模式：
ARP模式（本方案采用）
核心原理详解：
- Raft选举：kube-vip在所有控制平面节点间运行Raft一致性协议，选举出唯一Leader持有VIP
- Gratuitous ARP：Leader节点主动发送免费ARP报文，通知网络中所有设备VIP的MAC地址已更新
- 静态Pod方式部署：kube-vip作为静态Pod运行在
/etc/kubernetes/manifests/目录下，由kubelet直接管理，不依赖集群API Server - Service LB：同时支持为Kubernetes Service提供负载均衡VIP，替代外部LoadBalancer
BGP模式（可选）
适用于大规模数据中心环境，kube-vip通过BGP协议向路由器发布VIP路由，实现跨子网负载均衡。配置方式为将--arp替换为--bgp并指定BGP参数。
2.2 Cilium eBPF网络原理
核心原理详解：
- eBPF（Extended Berkeley Packet Filter）：在Linux内核中安全执行沙盒程序的技术，无需修改内核源码即可扩展内核功能
- 数据平面替换：Cilium将eBPF程序挂载到网络设备的tc（traffic control）ingress/egress钩子上，在内核态直接处理网络包，跳过iptables规则链
- kube-proxy替换：
kubeProxyReplacement=strict模式下，Cilium完全接管Service的负载均衡和DNAT，移除所有iptables规则 - 网络策略：支持L3/L4网络策略（IP和端口）和L7网络策略（HTTP/gRPC/Kafka等协议），在eBPF层直接执行，性能远优于iptables实现
- Hubble可观测：基于eBPF事件流提供服务依赖图、网络流量监控、故障诊断能力
- 封装模式：支持VXLAN、Geneve封装或直接路由（Direct Routing）模式实现跨节点Pod通信
2.3 etcd Raft共识原理
核心原理详解：
- Raft协议：etcd使用Raft一致性协议保证分布式数据的一致性，要求多数节点（Quorum）确认写入才算成功
- Leader选举：集群中只有一个Leader处理写入请求，Follower转发写请求给Leader
- 日志复制：Leader将每次写操作作为日志条目复制到所有Follower，多数确认后提交
- 脑裂防护：奇数节点部署（3或5），确保网络分区时最多只有一个分区拥有多数节点
- 数据持久化：每个etcd节点将数据持久化到磁盘，建议使用SSD以保证写入性能
2.4 containerd CRI接口原理
核心原理详解：
- CRI（Container Runtime Interface）：Kubernetes定义的容器运行时接口标准，kubelet通过gRPC调用CRI
- containerd架构：containerd内置CRI Plugin，无需额外安装CRI shim（dockershim已弃用）
- SystemdCgroup：containerd的cgroup驱动必须与kubelet一致，均设为
systemd以避免资源管理冲突 - 镜像管理：containerd通过
ctr和crictl命令行工具管理镜像，crictl为CRI标准CLI - 命名空间隔离：containerd使用namespace隔离不同客户端的容器和镜像，K8s默认使用
k8s.io命名空间
2.5 kube-proxy后端模式与内核模块依赖
Kubernetes Service的负载均衡由kube-proxy实现，kube-proxy支持三种后端模式，每种模式对内核模块有不同的强依赖：
三种后端模式对比：
| | | | |
|---|
| Kubernetes默认 | | | | |
| 规则查找复杂度 | | | | |
| Service规模 | | | | |
| 规则更新延迟 | | | | |
| 内核模块依赖 | ip_tables, iptable_nat, nf_conntrack | nf_tables, nft_compat, nf_conntrack | ip_vs, ip_vs_rr/wrr/sh, nf_conntrack_ipv4 | CONFIG_BPF, bpf_jit_enable |
| conntrack依赖 | | | | |
| el9内核支持 | | | | |
| el8内核支持 | | | | |
| 推荐场景 | | | | 本方案首选 |
关键说明：
iptables/nftables内核模块强依赖：即使本方案使用Cilium eBPF完全替代kube-proxy，集群初始化阶段（kubeadm init）和kube-proxy删除之前，iptables相关模块仍须加载。未加载ip_tables/iptable_nat/nf_conntrack模块会导致kube-proxy启动失败，进而影响集群初始化
nftables迁移趋势：Kubernetes社区自v1.29引入nftables后端（Alpha），v1.31+进入Beta，v1.36+推荐作为iptables的替代。nftables解决了iptables的规则膨胀和全量刷写问题，建议在未使用Cilium的集群中逐步从iptables迁移至nftables。需确保内核已加载nf_tables和nft_compat模块
IPVS长期规划：IPVS模式适用于Service数量超过5000的大规模集群，提供O(1)查找性能。但IPVS与nftables不兼容，且社区长期方向是eBPF替代。建议仅在确实存在大规模Service场景且暂不部署Cilium时启用IPVS，长期应规划向eBPF演进。启用IPVS需额外加载ip_vs、ip_vs_rr、ip_vs_wrr、ip_vs_sh模块，并配置vs.conn_reuse_mode=0等内核参数
本方案策略：采用Cilium kubeProxyReplacement=strict模式，eBPF完全接管Service处理，彻底消除对iptables/nftables/IPVS的运行时依赖。但初始化阶段仍需iptables模块可用，待Cilium接管后删除kube-proxy
三、主机规划与前置准备
3.1 主机规划
资源配置说明：
- 控制平面节点最低2C/4G可运行，但生产环境建议4C/8G+，etcd对磁盘IO敏感，必须使用SSD
- 工作节点配置取决于工作负载，建议8C/16G起步，生产环境根据业务需求扩展
- VIP地址必须与控制平面节点在同一子网，且未被任何设备占用
3.2 系统初始化（所有节点执行）
3.2.1 操作系统准备（el8/el9适用）
# el8系统需先升级内核至5.x# 方法1：通过ELRepo安装新内核rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.orgyum install -y https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpmyum --enablerepo=elrepo-kernel install -y kernel-ltgrub2-set-default 0grub2-mkconfig -o /boot/grub2/grub.cfgreboot# 验证内核版本uname -r # 应为5.4+或更高
# el9系统内核默认5.14+，无需额外升级# 确认内核版本uname -r # 应为5.14+
3.2.2 关闭防火墙
systemctl stop firewalldsystemctl disable firewalld
生产环境替代方案： 若无法关闭防火墙，需开放以下端口：
3.2.3 关闭SELinux
setenforce 0sed -i 's/^SELINUX=enforcing{CRICTL_VERSION}/crictl-{CRICTL_VERSION}-linux-amd64.tar.gz -C /usr/local/bin/rm -f crictl-{KUBEVIP_VERSION}/kube-vip-linux-amd64chmod +x /usr/local/bin/kube-vip
第三步：生成kube-vip静态Pod清单
# 在所有控制平面节点上执行# 设置变量VIP=192.168.1.100INTERFACE=eth0 # 替换为实际网卡名，可通过 ip addr 查看# 生成静态Pod YAMLkube-vip manifest pod \ --interface VIP \ --controlplane \ --services \ --arp \ --leaderElection \ | tee /etc/kubernetes/manifests/kube-vip.yaml
生成的kube-vip.yaml示例与参数说明：
apiVersion: v1kind: Podmetadata: name: kube-vip namespace: kube-systemspec: containers: - name: kube-vip image: ghcr.io/kube-vip/kube-vip:v0.8.0 imagePullPolicy: IfNotPresent args: - manager env: - name: vip_arp value: "true" # 启用ARP模式 - name: vip_interface value: "eth0" # 绑定VIP的网卡名 - name: vip_address value: "192.168.1.100" # VIP地址 - name: port value: "6443" # kube-apiserver端口 - name: vip_controlplane value: "true" # 启用控制平面负载均衡 - name: vip_services value: "true" # 启用Service负载均衡 - name: vip_leaderElection value: "true" # 启用Leader选举 securityContext: capabilities: add: - NET_ADMIN - NET_RAW - SYS_TIME volumeMounts: - name: config mountPath: /etc/kubernetes/admin.conf volumes: - name: config hostPath: path: /etc/kubernetes/admin.conf hostNetwork: true hostAliases: - hostnames: - kubernetes ip: 127.0.0.1
重要提示： kube-vip静态Pod需要/etc/kubernetes/admin.conf文件，但在第一个节点kubeadm init之前该文件不存在。因此在第一个控制平面节点上，应在kubeadm init之后再放置kube-vip.yaml；在其余控制平面节点上，可在kubeadm join之前预先放置，因为join时会生成admin.conf。
6.3 kube-vip BGP模式配置（可选高级方案）
适用于跨子网或大规模环境，需配合BGP路由器/交换机使用：
kube-vip manifest pod \ --interface VIP \ --controlplane \ --services \ --bgp \ --bgp-peers 192.168.1.1:179 \ --bgp-asn 65001 \ --leaderElection | tee /etc/kubernetes/manifests/kube-vip.yaml
七、kubeadm初始化高可用控制平面
7.1 第一个控制平面节点初始化
创建kubeadm配置文件
# kubeadm-config.yamlapiVersion: kubeadm.k8s.io/v1beta4kind: InitConfigurationnodeRegistration: criSocket: unix:///run/containerd/containerd.sock kubeletExtraArgs: cgroup-driver: systemd rotate-server-certificates: true---apiVersion: kubeadm.k8s.io/v1beta4kind: ClusterConfigurationkubernetesVersion: v1.36.0controlPlaneEndpoint: "k8s-vip:6443"imageRepository: registry.aliyuncs.com/google_containersnetworking: podSubnet: "10.244.0.0/16" serviceSubnet: "10.96.0.0/12" dnsDomain: "cluster.local"apiServer: extraArgs: authorization-mode: Node,RBAC enable-admission-plugins: NodeRestriction,PodSecurityPolicy,LimitRanger,ServiceAccount audit-log-path: /var/log/kubernetes/audit.log audit-log-maxage: 30 audit-log-maxbackup: 10 audit-log-maxsize: 200 certSANs: - k8s-vip - 192.168.1.100 - 192.168.1.10 - 192.168.1.11 - 192.168.1.12 - k8s-master01 - k8s-master02 - k8s-master03controllerManager: extraArgs: bind-address: 0.0.0.0 cluster-signing-duration: 87600hscheduler: extraArgs: bind-address: 0.0.0.0etcd: local: dataDir: /var/lib/etcd extraArgs: auto-compaction-mode: periodic auto-compaction-retention: 1h snapshot-count: "10000"---apiVersion: kubelet.config.k8s.io/v1beta1kind: KubeletConfigurationcgroupDriver: systemdrotateCertificates: trueserverTLSBootstrap: truemaxPods: 110podPidsLimit: -1resolvConf: /run/systemd/resolve/resolv.conf
配置详解：
- controlPlaneEndpoint：指向kube-vip的VIP地址，所有组件通过VIP访问API Server
- certSANs：证书中需包含所有控制平面节点IP和VIP，否则TLS验证失败
- etcd优化
- audit日志
- rotateCertificates
执行初始化
# 预检查（可先执行dry-run验证配置）kubeadm init --config kubeadm-config.yaml --upload-certs --dry-run# 正式初始化kubeadm init --config kubeadm-config.yaml --upload-certs
--upload-certs参数说明： 将控制平面证书加密上传至etcd，其他控制平面节点join时可自动下载证书，无需手动复制。证书密钥有效期为2小时。
初始化成功后配置kubectl
mkdir -p HOME/.kube/configsudo chown (id-g) INTERFACE \ --address HOME/.kubesudo cp -i /etc/kubernetes/admin.conf (id -u):HOME/.kube/config
注意： 如果token过期（默认24小时），可在已有控制平面节点重新生成：
kubeadm token create --print-join-command
如果certificate-key过期（默认2小时），需重新上传：
kubeadm init phase upload-certs --upload-certs
7.3 验证控制平面状态
# 查看所有节点kubectl get nodes -o wide# 查看所有系统Podkubectl get pods -n kube-system -o wide# 查看etcd集群健康状态kubectl get pods -n kube-system -l component=etcdETCD_POD=ETCD_POD -- etcdctl \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ endpoint health --cluster# 验证VIP可达curl -k https://192.168.1.100:6443/version
八、Cilium CNI网络插件部署
8.1 Cilium部署前准备
# 确认内核版本满足要求uname -r # 必须 >= 5.4，推荐 >= 5.10# 确认eBPF相关内核配置已开启cat /boot/config-(curl-s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)CILIUM_CLI_ARCH=amd64curl -L --fail --remote-name-all \ https://github.com/cilium/cilium-cli/releases/download/{CILIUM_CLI_ARCH}.tar.gz{,.sha256sum}sha256sum --check cilium-linux-{CILIUM_CLI_ARCH}.tar.gz /usr/local/binrm -f cilium-linux-(curl -s https://raw.githubusercontent.com/cilium/hubble/main/stable.txt)curl -L --fail --remote-name-all \ https://github.com/cilium/hubble/releases/download/(date +%Y%m%d_%H%M%S)RETAIN_DAYS=7mkdir -p BACKUP_DIR/etcd-snapshot-ETCD_ENDPOINT \ --cacert=ETCD_CERT \ --key=BACKUP_DIR/etcd-snapshot-BACKUP_DIR -name "etcd-snapshot-*.db" -mtime +DATE.db"
12.4 集群升级流程
# 1. 升级kubeadmdnf install -y kubeadm-1.37.0 # 假设升级到1.37# 2. 预检查kubeadm upgrade plan# 3. 升级第一个控制平面节点kubeadm upgrade apply v1.37.0# 4. 升级其余控制平面节点（逐个执行）kubeadm upgrade node# 5. 升级工作节点（逐个执行，确保服务可用）# 在工作节点上：dnf install -y kubelet-1.37.0 kubeadm-1.37.0 kubectl-1.37.0kubeadm upgrade nodesystemctl restart kubelet# 6. 验证升级kubectl get nodes -o wide
升级原则： 一次仅升级一个minor版本（如1.36→1.37），不可跳版本升级；先升级控制平面再升级工作节点；升级前必须备份etcd数据。
十三、网络入口架构演进与Gateway API选型规划
13.1 背景与演进趋势
Kubernetes网络入口（Ingress）正在经历重大架构变革。ingress-nginx作为Kubernetes社区长期维护的默认Ingress控制器，已被SIG-Network列入退役路线图（deprecation timeline），取而代之的是Gateway API——新一代的标准网络入口API。
关键背景：
- ingress-nginx退役：SIG-Network已明确Ingress API无法扩展满足现代网络需求（多租户、L4/L7统一、流量拆分等），ingress-nginx将进入维护模式，不再增加新功能
- Gateway API GA：Gateway API自v1.0起已达到GA稳定阶段，Kubernetes v1.36+完全支持，是社区确定的网络入口标准演进方向
- Ingress API兼容：Gateway API控制器通常提供Ingress API兼容层，允许渐进式迁移，无需一次性替换
13.2 本方案网络入口策略
本方案采用分阶段演进策略，从最基础的Service NodePort起步，逐步向Gateway API迁移：
| | | | |
|---|
| Phase 1 - 初期 | Service NodePort + ClusterIP | | | 零额外组件部署，端口范围30000-32767，适合初期验证 |
| Phase 2 - 过渡 | Ingress API + ingress-nginx | | | 当前最成熟方案，但需规划迁移至Gateway API |
| Phase 3 - 目标 | Gateway API + Envoy Gateway | | | |
13.3 Gateway API核心概念
Gateway API vs Ingress API 对比：
| | |
|---|
| API层级 | | 三层角色：GatewayClass → Gateway → Route |
| 多租户 | | |
| 协议支持 | | HTTP、HTTPS、TCP、UDP、TLS、gRPC |
| 流量管理 | | |
| 扩展性 | | |
| 控制器绑定 | | |
| 状态反馈 | | 完整的Conditions和ListenersStatus |
13.4 Gateway API网关选型对比
| Envoy Gateway | Istio Gateway | Kong Gateway | Cilium Gateway API |
|---|
| 推荐场景 | | | | |
| 底层数据平面 | | | | |
| Gateway API兼容 | | | | |
| Ingress兼容 | | | | |
| 部署复杂度 | | | | |
| 资源开销 | | | | |
| API管理能力 | | | | |
| L4/L7支持 | | | | |
| 社区活跃度 | | | | |
| 生产就绪度 | | | | |
| 本方案推荐度 | | | | |
13.5 推荐选型决策路径
决策建议：
首选方案：Envoy Gateway — 本方案推荐作为Gateway API的默认控制器选型
- CNCF官方Gateway API参考实现，API兼容性最完整
性能优先：Cilium Gateway API — 已部署Cilium的集群可考虑
API管理需求：Kong Gateway — 需要认证/限流/插件生态时
服务网格场景：Istio Gateway — 需要mTLS/流量治理/可观测时
13.6 Phase 1 实践：Service NodePort（当前方案）
本方案当前阶段使用最基础的Service NodePort方式暴露服务，零额外组件：
# 部署测试应用并暴露NodePortkubectl create deployment demo-app --image=nginx --replicas=2kubectl expose deployment demo-app --port=80 --target-port=80 --type=NodePort \ --name=demo-app-nodeport# 查看分配的NodePortkubectl get svc demo-app-nodeport# NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE# demo-app-nodeport NodePort 10.96.xxx.xxx <none> 80:3xxxx/TCP 5s# 通过任意节点IP:NodePort访问curl http://192.168.1.20:3xxxx
NodePort局限性与后续迁移触发条件：
- 端口范围仅30000-32767，无法使用标准80/443端口
- 触发迁移条件：当需要以下任一能力时，应迁移至Gateway API
13.7 Phase 3 实践：Envoy Gateway部署示例（目标方案）
当集群运行稳定后，可按以下步骤部署Envoy Gateway：
# 1. 安装Envoy Gateway（通过Helm）helm install eg oci://docker.io/envoyproxy/gateway-helm \ --version v1.2.0 \ --namespace envoy-gateway-system \ --create-namespace# 2. 等待Envoy Gateway就绪kubectl wait --timeout=5m -n envoy-gateway-system deployment/envoy-gateway --for=condition=Available# 3. 创建GatewayClass和Gatewaycat <<EOF | kubectl apply -f -apiVersion: gateway.networking.k8s.io/v1kind: GatewayClassmetadata: name: egspec: controllerName: gateway.envoyproxy.io/gatewayclass-controller---apiVersion: gateway.networking.k8s.io/v1kind: Gatewaymetadata: name: eg namespace: defaultspec: gatewayClassName: eg listeners: - name: http protocol: HTTP port: 80 allowedRoutes: namespaces: from: All - name: https protocol: HTTPS port: 443 tls: mode: Terminate certificateRefs: - name: eg-tls-cert kind: Secret allowedRoutes: namespaces: from: AllEOF# 4. 创建HTTPRoute路由规则cat <<EOF | kubectl apply -f -apiVersion: gateway.networking.k8s.io/v1kind: HTTPRoutemetadata: name: demo-app namespace: defaultspec: parentRefs: - name: eg namespace: default hostnames: - "app.example.com" rules: - backendRefs: - name: demo-app port: 80 filters: - type: RequestHeaderModifier requestHeaderModifier: add: - name: X-Gateway value: envoy-gatewayEOF# 5. 验证Gateway和路由状态kubectl get gateway -Akubectl get httproute -Akubectl describe gateway eg -n default# 6. 获取Gateway外部IP并访问export GATEWAY_IP=GATEWAY_IP
13.8 迁移路线图总结
| | | | |
|---|
| 当前（集群建成0-3月） | | | | |
| 3-6个月 | | | | 评估Envoy Gateway可行性，测试Gateway API |
| 6-12个月 | | Gateway API + Envoy Gateway | | 部署Envoy Gateway，逐步迁移Ingress至HTTPRoute |
| 12个月+ | | | | 清理Ingress资源，评估是否需要服务网格（Istio）或API管理（Kong） |
长期技术演进关键决策点：
ingress-nginx退役时间窗口：ingress-nginx将在Gateway API达到生产就绪后进入维护模式（预计1-2年内停止功能更新）。建议在6个月内完成Gateway API选型评估，12个月内启动迁移
kube-proxy后端演进：当前Cilium eBPF strict模式已完全替代kube-proxy。若后续因特殊原因需回退至kube-proxy，社区推荐路径为 iptables → nftables → eBPF，应避免向IPVS投入过多运维精力
Service NodePort的定位：NodePort作为最基础的服务暴露方式，在Gateway API成熟后仍适用于内部服务和调试场景，不会被完全取代
PS:写作过程中若有考虑不周或信息偏差，非常期待大家的留言指正～我们会认真回复、积极沟通，并尽快更新优化。感谢阅读与包容！
