简介： 容器coredns问题排查整顿
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技术学院钉钉圈子，和更多云上人交换对于云平台的那些事。
原文链接
本文为阿里云原创内容，未经容许不得转载。