Submariner在GKE环境中节点标签持久化问题的解决方案

背景

在Kubernetes多集群网络方案Submariner的实际部署中，Google Kubernetes Engine（GKE）环境存在一个需要特别注意的技术特性：节点标签（Node Labels）的非持久化问题。这个问题不仅影响Submariner网关组件的正常运行，也是所有依赖节点标签的Kubernetes组件在GKE环境中都需要面对的共性问题。

问题现象

当GKE集群中的节点发生自动升级或重启时，通过kubectl命令手动添加的节点标签（如submariner.io/gateway=true）会被自动清除。这会导致：

1. Submariner的gateway Pod失去网络连接
2. 跨集群通信功能中断
3. 需要反复执行join操作来恢复服务

技术原理

GKE作为托管Kubernetes服务，其节点管理系统会定期执行维护操作，包括自动升级和节点替换。在这个过程中：

• 节点被视为"不可变基础设施"
• 手动添加的标签不被视为节点配置的一部分
• 节点重建后会恢复默认配置，但不会保留用户自定义标签

这与自建Kubernetes集群的行为有本质区别，在自建集群中节点标签通常是持久化的。

解决方案

临时解决方案

当发现节点标签丢失导致Submariner网关失效时，可以手动重新添加标签：

kubectl label node <节点名称> submariner.io/gateway=true

长期解决方案

对于生产环境，建议采用以下两种方案之一：

1. 使用LoadBalancer服务类型 在部署Submariner网关时指定使用负载均衡器：

   subctl join --load-balancer ...
   

   这种方式不依赖节点标签，通过Kubernetes Service实现网关访问

2. 自动化标签管理 开发自动化脚本或使用Operator定期检查并修复丢失的标签，可以通过以下方式实现：

   • 定时Job检查标签状态
   • 使用Kubernetes Admission Controller
   • 开发自定义Controller监听节点事件

最佳实践建议

1. 在GKE环境部署Submariner时，优先考虑使用LoadBalancer模式
2. 建立节点监控机制，及时发现标签丢失情况
3. 对于关键生产环境，考虑实现标签自动修复系统
4. 在CI/CD流程中加入节点标签检查步骤

总结

GKE的节点管理特性带来了便利性，但也引入了标签持久化这样的特殊考量。理解这一特性并采取适当措施，可以确保Submariner等依赖节点标签的组件在GKE环境中稳定运行。随着Submariner的持续发展，未来版本可能会提供更优雅的解决方案来规避这类基础设施差异带来的问题。