kebernetes（k8s）：更改service的工作模式为lvs(ipvs)之后，出现解析失败，curl出错的原因分析及解决方法

问题描述

1.近期在k8s中，将service的iptables工作模式改为 lvs之后，出现不能解析的情况.
将service的工作模式改为ipvs后，出现无法解析服务的情况，而且当访问service的VIP时，不能访问后端的endpoints。

排查过程

1.当在master创建一个service后，就会在后端的节点创建一个VIP，这个VIP和service的VIP是一样的。
2.在后端查看ipvs的策略时，发现指向后端pod的ip都不对。
分析：
之所以解析不到i，访问不到VIP，是因为它实际访问的子节点是ipvs里指向的主机，而子节点是不对的。
当把service工作模式改为iptables时，发现一切正常。

3.测试重新删除再创建
把已经创建的service删除，重新创建。
发现此时后端的ip指向都正确。

测试时发现，能通过ip访问，但是通过域名访问时，解析依然是个问题，依然失败。
而且当改变副本数量时，ipvs不能立马感知到。
正常时，这两个pod的ip地址，会同步到ipvs策略里。
ipvs并没有同步，ip和数量都不对。

4.排查是否是master中的dnspod容器出现了问题

1）集群中的dns服务由两个pod提供
2）当运行pod时，pod里便会自动配置dns的解析为这个ip，两个dns pod提供负载均衡
后端节点上也有集群dns的解析
可以看出，后端节点上dns的负载均衡ip也不对，解析也不会对

测试是dns本身出了问题了么？？？

测试时发现dns本身并没有问题，只是通过dns的vip访问时出了问题，问题还是在lvs的调度策略，他没有更新策略。
5.查看日志
查看日志时，发现大量报错

问题解决

经过查找资料，是系统的内核版本过低,需要将集群中的节点的内核全部升级

1.我的系统版本是rhel7.6,但是用centos的内核也可以
其他节点做一样的操作，这里不再赘述
在真机发现，更新内核时，对系统的cpu的负载很高，因此建议一台一台更新。

检验成果

1.首先看自己的k8s集群运行是否成功

再测试解析时
再次拉神pod个数时，后端节点也动态发现