一、背景

云课堂服务需要调整gc参数，为了对比调整的效果，将6个jvm节点分为两组：一组是4个正常节点，另一组是2个灰度节点。

两个pod的服务名称不同，但是标签相同。

在service的实现上，取自Pod的标签，包括了正常组和灰度组。示意图见下：

image.png

详细配置见第二项。

有一点值得注意的是，阿里云k8s控制台所做的修改配置，会在下一次部署的时候，被yml内容所覆盖。这也是我们这次出现问题的原因之一。

二、配置

在阿里云k8s容器的控制台，修改了它的标签，由默认的app修改为serviceName。

1、正常节点的Deployment

spec:
  progressDeadlineSeconds: 600
  replicas: 4
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      serviceName: cloud-xxx-service

2、灰度节点的Deployment

spec:
  progressDeadlineSeconds: 600
  replicas: 4
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      serviceName: cloud-xxx-service

3、Service服务

spec:
  selector:
    serviceName: cloud-xxx-service

三、默认的配置

注意，在部署yml中，使用的标签默认都是app。另外在发布的时候，只更新deployment-xxx.yml，并不是每次去更新service-xxx.yml。

• deployment-xxx.yml 每次部署，k8s会将pod的标签重置。在上一步手动新增的serviceName标签，会被下面的部署脚本替换为app标签。

1、Deployment

spec:
  progressDeadlineSeconds: 600
  replicas: 6
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: cloud-xxx-service

2、Service

并没有更新，仍旧是上次的标签。

spec:
  selector:
    serviceName: cloud-xxx-service

四、service的实现是SLB

image.png

• 第一步，撤销2个灰度节点

  
  image.png

• 从下图中可以看出，它的健康状态为空，没有找到对应的pod节点。

  
  image.png

• 而在应用监控中，也没有任何流量请求进来。

• 第二步，修改service的标签，保持和pod的标签一致。

spec:
  selector:
    app: cloud-xxx-service

• 接着观察slb的健康状态，现在变成了“未打开”状态，正在检测后端服务

  
  image.png

• 几分钟后，观察到，状态恢复为“正常”了。

  
  image.png

五、总结

本次的问题原因有二：
1、发布的标签，默认是app，为了支持灰度，更换了标签为serviceName。影响点除了Deployment外，还有Service。每次部署的时候，只更新了Deployment，而不更新Service。最后导致标签不一致，SLB找不到后端服务。

2、更改标签，一定要更新在.yml文件，否则会导致你在阿里云k8s控制台所做的修改被覆盖。

解决办法：
1、Deployment和Service一起部署，保持标签的一致性。
2、在修改阿里云k8s控制台的设置时，务必及时更新.yml文件内容。