1.问题描述

客户侧在变更容器安全组之后出现网络不通。

2.问题排查

1）接到客户反馈 Kubernetes 托管版集群出现网络问题，电话沟通后授权进行查看：Pod 网络通畅，域名解析出现异常（ping IP 可通，但ping域名不通）；
2）结合客户操作，怀疑与安全组配置有关，尝试进一步排查安全组问题。详细排查无问题后，决定重启 coredns POD。重启后 coredns POD 漂移到其它 ECS上，集群中大部分主机恢复正常；
3）确认coredns原宿主机存在网络连接问题，将该主机踢出集群后，集群恢复正常；
4）经过环境测试后最终定位原因在于客户侧误解 Kubernetes 集群安全组页面“解绑实例”功能为解绑安全组，导致误操作解绑和绑定ENI 网卡，同时产品健康检查机制存在缺陷，无法探测到辅助网卡的链路问题，导致问题无法快速发现并解决，最终导致客户集群网络无法联通。

3.优化改进

1）优化安全组页面存在“解绑实例”功能文案，同时增加由 Kubernetes 集群创建的网卡在用户解绑时的风险提示，避免客户误操作引发业务中断；
2）优化健康检查机制，确保辅助网卡链路异常场景能够被快速发现。

4.问题复现

4.1环境准备

1）kubernetes托管版集群，网络模式为Terway，kube-proxy代理模式为IPVS，四节点，需要创建测试的应用pod；

图1：初始环境

2）查看coredns所在的宿主机，目前该pod存在于201、200机器上；

图2：coredns pod

4.2具体操作

1）模拟客户侧的操作在安全组界面“解绑coredns所在主机的辅助网卡”；
登录ECS控制台--实例--选择机器--本实例弹性网卡界面查看

图3：实例弹性网卡

跳转至安全组界面---选择集群的安全组实例id---安全组内弹性网卡--搜索刚刚查找的弹性网卡--解绑实例

图4：安全组内弹性网卡

2）解绑完成之后再次将辅助网卡绑定至原有实例；

图5：查看原有实例网卡

3）登录任意一个应用pod内，利用dig baidu.com测试解析是否正常
kubectl exec -it centos-deployment-75765fbb54-x5f6v -- /bin/bash，进入pod内：

图6：pod内测试

上图就是一开始客户侧遇到的现象：ping域名不通，ping IP可以通。

4）为什么解绑之后重新绑定至原有实例还是不可以呢？原因就在于解绑后重新绑定网卡后该网卡的state仍然是DOWN状态，需要重新up网卡；
up网卡：ip link set eth1 up

图7：up网卡

网卡在被up后，再次进入pod进行测试，会发现解析就可以正常运行了。

图8：up网卡后测试

其实kube-dns后有两个coredns POD，那么这两个coredns是采取什么策略去提供解析服务呢？

5.问题分析

利用ipvsadm可以看到coredns是按照rr的方式去提供服务的，并且设置了session的超时保持时间是10800（超时时间可以通过查看kube-dns的yaml文件）：

图9：kube-dns的session时间

正是因为上述kube-dns的session的保持时间设置了10800，导致域名解析的请求一直都是寻找坏的coredns POD（坏coredns也就是被解绑后重新绑定辅助网卡的那台机器上的coredns），所以客户侧在解绑操作后一直无法进行正常解析，类似于下面的现象：

图10：长ping失败现象

测试下去掉该session设置，再次进行域名解析测试（修改kube-dns svc的yaml中的sessionAffinity为None）：

图11：svc yaml

图12：dig图

图13：tcpdump抓包

所以修改sessionAffinity为None后，第一次的解析会走好的coredns，第二次请求就会走坏的coredns，这也就是证明coredns以rr策略提供服务的。

图14：长ping正常现象

我们是阿里云智能全球技术服务-SRE团队，我们致力成为一个以技术为基础、面向服务、保障业务系统高可用的工程师团队；提供专业、体系化的SRE服务，帮助广大客户更好地使用云、基于云构建更加稳定可靠的业务系统，提升业务稳定性。我们期望能够分享更多帮助企业客户上云、用好云，让客户云上业务运行更加稳定可靠的技术，您可用钉钉扫描下方二维码，加入阿里云SRE技术学院钉钉圈子，和更多云上人交流关于云平台的那些事。