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

背景概述

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

问题本质

GKE作为托管Kubernetes服务，会定期自动执行节点升级维护。在这个过程中存在一个关键特性：

1. 通过kubectl手动添加的节点标签不会被系统保留
2. 节点升级后原有标签会被清除
3. Submariner网关组件依赖的submariner.io/gateway=true标签也会丢失

这种现象导致Submariner网关Pod在节点升级后失去网络连接能力，因为：

• 网关Pod的调度依赖于该标签
• 跨集群通信的端点信息没有自动更新

影响范围

该问题会引发以下现象：

1. 跨集群网络连接中断
2. 需要反复执行subctl join命令重新加入集群
3. 简单的网关Pod重启无法解决问题

解决方案

临时解决方案

当发现节点升级导致网络中断时，可执行以下命令恢复：

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

长期解决方案

对于生产环境，建议采用以下架构设计：

1. 使用LoadBalancer服务类型 在subctl join命令中加入--load-balancer参数，让Submariner网关通过GKE原生的负载均衡器提供服务，这样就不直接依赖节点标签。

2. 自动化标签管理 通过以下方式实现标签持久化：

• 开发定期检查的监控脚本
• 使用Kubernetes Operator自动重新应用标签
• 结合GKE的节点自动修复功能进行配置

3. 架构设计建议

• 为网关节点设置专用节点池
• 配置节点自动缩放时保留至少一个网关节点
• 考虑使用区域持久化存储记录网络状态

最佳实践建议

1. 在GKE环境部署Submariner前，应该充分了解该平台的这个特性
2. 生产环境建议采用LoadBalancer模式部署网关
3. 建立节点维护时的监控和告警机制
4. 文档化恢复流程，培训运维团队

技术原理深入

GKE的这种设计源于其托管服务的特性，为了保证平台的一致性和安全性，GKE会定期将节点重置为基准状态。这与自建Kubernetes集群的行为有本质区别。Submariner作为跨集群网络方案，需要适应不同云平台的这些特性差异。

理解这个底层原理，有助于我们在其他托管Kubernetes服务（如EKS、AKS）部署时，也能提前考虑类似的平台特性可能带来的影响。