容器coredns问题排查整理

容器coredns问题排查整理

1.问题描述

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

2.问题排查

1)接到客户反馈 Kubernetes 托管版集群出现网络问题,电话沟通后授权进行查看:Pod 网络通畅,域名解析出现异m ~ G _ M + P A常;(ping IP 可通,但ping域名不通)
2)结合客户操作,怀疑与安全组配置有关,尝试进一步 : 8 l排查安n % , B F y全组问题。详细排查无w { 3问题后,决定重启 coredns POD。重启后 coredns POD 漂移到其它 ECS上,集群中大部F 7 0 3 s p + S分主机恢复正常;
3)确? Q t认coredns原宿主机存在网络连接问题,将该主机踢出集群后,集群恢复正常;
4)经过环境测试后最终定位原因在于客户侧误解 Kubernetes 集群安全组页面“解绑实例”功能为解绑安全组,导致误操作解绑和绑定ENI 网卡,同时产品健康检查机制存在缺陷,无法探测到辅助网卡的链路问题,导致问题无法快速发现并解决,最终导致客户集群网络无法联通。` N Z ~

3.优化改进

1)优化安全组页面存在“] O u T h o解绑实例”功能文e y z 3 . 5案,同时增加由 Kubernetes 集群创建的网卡在用户解绑时的风险提示,避免4 ^ R X f L f F客户误操作引发业务中断;
2)优化健康检查机制,确保辅助网卡链路异常场景能够被快速发现。

4.问题复现

4.1环境准备

1)e 1 ckubernetes托管版集群,网络模式为Terway,kube-proxy代理模式为IPVS,四节点,需要创建测试的应用pod;

容器coredns问题排查整理

图1:初始环境

2)查看coredns所在的宿主机,目前该V U e [ & epod存在于201、H , 6 T I o s200机器上;

容器coredns问题排查整理

图2:coredns pod

4.2具体操作

1)模拟客户侧的操作在安全组界面“解绑coredns所在主机; 7 . V [ . I的辅助网卡”;
登录ECS控制台--实例-M + t G } O W l P-选择机器--本实例弹性网卡界面查看
容器coredns问题排查整理

图3:实例弹性网卡

跳转至安全组界面---选择集群的安全组实例id--u 6 V h 2-安全组内弹性网卡--搜索刚刚查找的弹性网卡--解绑实例
容器coredns问题排查整理

图4q i 6 ] c s b:安全组内弹性网卡

2)解绑完成之后再次将辅助网卡绑定至原有实例;
容器coredns问题排查整理

图5:查看原有实例网卡

3)登录任意一个应用pod内,利用dig baidu.com测试解析是否正常
kubectl exec -it centos-deployment-7k % Y w r K5765fbb54-x5f6v -- /bin/bash,进入pF ; _ y j ^od内:
容器coredns问题排查整理

图6:pod内测试

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

4)为什么解绑之后重新绑定至原有实例还是不可以呢?原因就在于解绑后重新绑定网卡后该网卡的state仍然是DOWN状态,需要重新up网卡;
up网卡:ip link set eth1 up
容器coredns问题排查整理

图7:up网卡

网卡在被up后,再次进入pod进行测试,会发现解析就可以正常运行了。
容器coredns问题排查整理

图8:up网卡后测试

其实w p _ : s Y *kube-dns后有两个coredns POD,那么这两个coredns是采| g z u取什么策略去提供解析服务呢?

5.问题分析

利用ipvsadm可以看到c[ o q Z R r ;oredns是按照rr的方式去提供服务的,并且设置了session的超时保持* s 2 8时间是10800(超时时间可以通过查看ku; 3 M G ) ] x jbe-dns的yaml文件):
容器coredns问题排查整理

图9:kube-dns的session时间

正是因为上述kube-dns的session的保持时间设置了10800,导致域名解析y P m {请求一直都是寻找坏的coredns POD(坏coredns也就是被解绑后重新绑定辅助网卡的那台机器上的coredns),所以客户侧在解绑操作后3 J 5 `续一直没有无法进行正常解析,类似于下a c 7 L e # c面的现象:
容器coredns问题排查整理

图10:长ping失败现象

测试下去掉该session设置,再次进行域名解析测试(修改kube-( q E a - d s *dns svc的yaml中的sessionAffinity为None):
容器coredns问题排查整理

图11:svc yaml

容器coredns问题排查整理

图12:dig图

容器coredns问题排查整理

图13:tcpdump抓包

所以修改sessionAffinity为None后,第一次的解析会走好的coredns,第二次请求就会走坏的o = 9corednsr R e,这也就是证明coredns以rr策略提供服务的。
容器coredns问题排查整理

图14:长ping正常现象

我们是阿里云智能全球技术服务-SRE团队,我们致力成为一个以技术为基础、面向服t ( C B务、保障业务系统S M y l # J高可用的V l S M工程师团队;提供专业、体系化的SRE服务,帮助广大客户更好地使用云、基于云O O o ` ^ 1 c m W构建更加稳定可靠的业务系统,提升业务稳定性。我们期望能够分享更多帮助企业客户上8 X 2 Q ! ^ H m云、用好云,让客户云上业务运行更加稳定可靠的技术,您可用钉钉扫描下方二维码,加入阿里云SRE技术学院钉钉圈子,和更多云上人交流关于云平i J M台的那些事。

容器coredns问题排查整理