删除service 里面的相应字段
查看是不是有之前的进程占用,然后将service 字段抠出来手动启动查看可否成功,也可显示错误
分析是因为etcd1的配置文件/etc/etcd/etcd.conf中的ETCD_INITIAL_CLUSTER_STATE是new，而在配置中ETCD_INITIAL_CLUSTER写入了etcd2/3的IP:PORT，这时etcd1尝试去连接etcd2、etcd3，但是etcd2、3的etcd服务此时还未启动，因此需要先启动etcd2和3的etcd服务，再去启动etcd1。
etcd.conf ETCD_LISTEN_CLIENT_URLS 选项中加入 https://127.0.0.1:2379`
修改/root/cfssl/kubernetes/kubernetes-server-csr.json 加入错误中的k8s
mkdir /var/lib/kubelet (具体看service 里面WorkingDirectory)
vim /usr/lib/systemd/system/docker.service ExecStart=/usr/local/bin/dockerd --exec-opt native.cgroupdriver=systemd 具体按照报错修改
vim /etcd/etcd/etcd.conf ETCD_LISTEN_CLIENT_URLS=https://192.168.50.12:2379,https://127.0.0.1:2379;
容器 不能ping 百度
kubectl run -it --rm DNS-test --image=busybox:1.28.4 sh 测试dns
kubectl patch node k8s-master -p '{"spec":{"podCIDR":"10.244.0.0/12"}}'
kubectl patch node k8s-node1 -p '{"spec":{"podCIDR":"10.244.0.0/12"}}'
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
echo "1" >/proc/sys/net/bridge/bridge-nf-call-iptables
在/etc/profile末尾增加export KUBECONFIG=/etc/kubernetes/admin.conf添加完后执行source /etc/profile
pod 能ping 外网 但是不能解析百度 能ping114 不能ping svc 地址
对应的node上面没有开启转发(具体问题可以先查看node上面的kube-proxy logs 因为svc 是通过 kube-proxy分发出去的)echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
设置 pod ip 的网段 ，网段之所以是 10.244.0.0/16，是因为后面安装 flannel 网络插件时，yaml 文件里面的 ip 段也是这个，两个保持一致，不然可能会使得 Node 间 Cluster IP 不通。这个参数必须得指定，如果这里不设置的话后面安装 flannel 网络插件时会报这个错误
解决方法
说明节点资源不够，清理空间
https://Github.com/kubernetes/ingress-Nginx/issues/8052#issuecomment-1003699587
如果ingress-nginx启用了enable-ssl-passthrough，就需要添加enable-real-ip: true
forwarded-for-header: proxy_protocol到configmap里面就可以了
master 节点故障，docker ps -a |grep etcd |grep -v POD 发现etcd 异常退出
查看日志
docker logs -f etcd...
···
etcdserer : open wal error: wal : file not found
恢复步骤
将故障节点剥离集群，恢复后添加
etcdctl2 cluster-health
获取问题节点的member id
etcdclt2 member remove $memberid
将问题节点移除
----
停止问题节点上的etcd 服务
mkdir -pv /etc/orgin/node/pods-stopped
mv /etc/origin/node/pods/* /etc/orgin/node/pods-stopped
rm -rf /var/lib/etcd/*
----
更新ansible中的inventory host 内容，设置new etcd 配置
[osev3:clildren]
masters
etcd
nodes
new_etcd
----
从集群中释放问题节点
----
更新etcd 扩容脚本
ansible-playbook playbooks/openshift-master/openshift_node_groups.yaml
----
验证
etcdctl clister-health
rpc error: code = ResourceExhausted desc = grpc: trying to send message larger than max (xxxxxxx vs. 8388608)
描述
集群有个master节点NotReady。kubelet报错 “Warning ContainerGCFailed ... ”
Warning ContainerGCFailed ...
rpc error: code = ResourceExhausted desc = grpc: trying to send message larger
than max (xxxxxxx vs. 8388608)
这个错和下面是一个问题。
rpc error: code = ResourceExhausted desc = grpc: received message larger
than max (xxxxx vs. 4194304)
原因
kubelet与cri-o通信，cri-o返回信息大小超过grpc的限制
kubelet无法与cri-o通信，导致内部大量错误出现
超过的根源在于容器数量过多，grpc返回信息过大，从而你超过了限制，无法正确返回。
解决方法
查看GRPC Buff块大小，扩大至8MB。扩大方法参考
https://github.com/cri-o/cri-o/pull/2027github.com/cri-o/cri-o/pull/2027
假如已经是8MB，仍然报错，则可能是镜像等docker资源需要清理。可以执行
docker system prune
为了根除此类错误，可以在节点上设置完善的Garbage Collection机制。参考
Garbage Collectiondocs.openshift.com/container-platform/3.11/admin_guide/garbage_collection.html
Pods get stuck in ContainerCreating state when pulling image takes long
https://github.com/kubernetes/kubernetes/issues/83471
apiserver 前面使用的是 f5的负载均 策略有问题，导致请求全部打在了master1上、
创建一个networkpolicy 的 Ingress
apiVersion: extension/v1beta1
Kind: NetworkPolicy
metadata:
generation:
name: allow-from-{ns1}-namespace
namespace: {ns2}
spec:
ingress:
- from:
- namespaceSelector:
matchLabels:
name: {ns1}
podSelector: {}
policyType:
- Ingress
说明持久化存储资源不足
检查route ingress 是否为正常状态 本地配置host是否解析正常
关键词： cni networkplugin
报错： networkPlugin cni filed to send cni request: post http://xxx/dial .var/run/openshift/cni-server.sock: connet: connetc refuse
解决
找到调度的节点，重启sdn
kubectl get openshift-sdn delete po --grace-period=0 --force sdn-xxx
经过排查为 networkplicy 缺少
https://kubernetes.io/zh/docs/concepts/services-networking/network-policies/
因为ns开启可vpa导致
admission是会去手动改request值 updater组件会发现request大于推荐去驱逐 然后admission挂了 改不了request pod一起来 updater发现它大于推荐request 就会驱逐 然后一直循环在驱逐
应用做更新，所有的yaml都在一个文件里面，可能是cm更新的慢了，然后pod会提示找不到cm，pod重启还是会找不到cm
pod状态terminating，强制删除了，但是容器没有删除导致的
VPA目前驱逐pod后 pod名字不会变 但是ip和创建时间会变，VPA关闭后无此现象
会话保持必须关闭
a 应用使用了b 应用的证书
vpa-admin-controller 异常pod
service 通过label 选择pod， 可以在A，B 的deploy 分别添加一个相同的标签，svc 中的selector 使用这个相同的标签，这样就可以选择A 和 B 的deploy创建的pod
检查haproxy的问题，开启haproxy的日志
表现为ping 不通，telnet 失败
arping -I ens33 10.0.13.3
如果存在多个mac 地址，则表明地址冲突
现象
kubectl get ns
demo terminating 50d
查看编排内容
kubectl get ns demo -o json
"spec": {
"finalizers": [
"kubernetes"
]
},
删除上面这段 然后导入到新的jjson 文件里面
curl -k -H "Content-Type: application/json" -X PUT --data-binary @1.sjon http://127.0.0.1:8001/api/v1/namespaces/demo/finalize
在configmap下面增加熟悉mode：493(十进制，八进制就是755)
configmap:
name: xxx
items:
- key: entrypoinyt.sh
path: entrypoiny.sh
mode: 493
怎么修改
修改docker 启动参数
vim /etc/systemd/system/multi-user.target.wants/docker.service
在 exec 参数后面加上 --graph=/xx/xxx/xx
systemctl daemon-reload
systemctl restart docker
修改daemon.jsono
{
"data-root": "/xxx/xxx"
}
~/.kube 客户端认证文件失效或者损坏，从其他节点的root用户拷一份过来即可
登陆到router 部署的节点
netstat -tnlp 查看端口是否正常监听
kubectl -n default routerxxx rsh
grep -i "xxxx" -r ./
查看tcp-router是否有明显错误日志
kubectl -n defaut logs -f routerxxx --tail=10
查看端口范围
iptables -nL INPUT
创建sa
kubectl create sa -n xxx xxx
添加sa到对应的scc
kubectl adm policy add-scc-to-user anyuid -n xx -z xxx
修改部署文件
serviceAccount: xxx
serviceAccountName: xxx
spec.template.spec.container[]
securityContext:
runAsuser: xxx
解决 Kubernetes 中 Pod 无法正常域名解析问题分析与 IPVS parseIP Error 问题
系统环境：
CoreDNS 版本：1.6.7
Docker 版本：19.03.8
Kubernetes 版本：1.18.1
操作系统版本：centos 7.8
CentOS 内核版本：3.10.0-1062
参考地址：
Kubernetes Github
CentOS 升级内核版本
Kubernetes 官方文档 - Services
Kubernetes 官方文档 - 调试DNS服务
Kubernetes 官方文档 - 自定义DNS服务
Issues "ipvs do not sync endpoint error: parseIP Error"
问题分析比较长，分析的怀疑人生...
一、问题描述
最近将 Kubernetes 升级到 1.18.1 版本，不过升级完后，查看工作节点的部分 Pod 无法启动，查看消息全是
connetion timeout
的问题，一看连接超时的地址大部分是以域名方式连接集群内部地址（ClusterIP），少部分是以域名方式连接集群外部地址，通过 IP 进行远程连接的应用倒是没有问题（例如，应用通过 IP 连接 MySQL），由此判断，初步怀疑很可能是 DNS 出现了问题，后来慢慢发现 kube-proxy 中的错误，再定位到 IPVS parseIP Error 错误，再到解决问题。下面是分析及姐问题的过程。
二、部署 DNS 调试工具
为了探针是否为 DNS 问题，这里需要提前部署用于测试 DNS 问题的 dnsutils 镜像，该镜像中包含了用于测试 DNS 问题的工具包，非常利于我们分析与发现问题。接下来，我们将在 Kubernetes 中部署这个工具镜像。
1、创建 DNS 工具 Pod 部署文件
创建用于部署的 Deployment 资源文件 ndsutils.yaml：
ndsutils.yaml
apiVersion: v1
kind: Pod
metadata:
name: dnsutils
spec:
containers:
- name: dnsutils
image: mydlqclub/dnsutils:1.3
imagePullPolicy: IfNotPresent
command: ["sleep","3600"]
2、通过 Kubectl 工具部署 NDS 工具镜像
通过 Kubectl 工具，将对上面 DNS 工具镜像部署到 Kubernetes 中：
-n：指定应用部署的 Namespace 空间。
$ kubectl create -f ndsutils.yaml -n kube-system
三、问题分析
1、进入 DNS 工具 Pod 的命令行
上面 DNS 工具已经部署完成，我们可也通过 Kubectl 工具进入 Pod 命令行，然后，使用里面的一些工具进行问题分析，命令如下：
exec：让指定 Pod 容器执行某些命令。
-i：将控制台内容传入到容器。
-t：进入容器的 tty 使用 bash 命令行。
-n：指定上面部署 DNS Pod 所在的 Namespace。
$ kubectl exec -it dnsutils /bin/sh -n kube-system
2、通过 Ping 和 Nsloopup 命令测试
进入容器 sh 命令行界面后，先使用 ping 命令来分别探测观察是否能够 ping 通集群内部和集群外部的地址，观察到的信息如下：
## Ping 集群外部，例如这里 ping 一下百度
$ ping www.baidu.com
ping: bad address 'www.baidu.com'
## Ping 集群内部 kube-apiserver 的 Service 地址
$ ping kubernetes.default
ping: bad address 'kubernetes.default'
## 使用 nslookup 命令查询域名信息
$ nslookup kubernetes.default
;; connection timed out; no servers could be reached
## 直接 Ping 集群内部 kube-apiserver 的 IP 地址
$ ping 10.96.0.1
PING 10.96.0.1 (10.96.0.1): 56 data bytes
64 bytes from 10.96.0.1: seq=0 ttl=64 time=0.096 ms
64 bytes from 10.96.0.1: seq=1 ttl=64 time=0.050 ms
64 bytes from 10.96.0.1: seq=2 ttl=64 time=0.068 ms
## 退出 dnsutils Pod 命令行
$ exit
可以观察到两次 ping 域名都不能 ping 通，且使用 nsloopup 分析域名信息时超时。然而，使用 ping kube-apiserver 的 IP 地址 "10.96.0.1" 则可以正常通信，所以，排除网络插件（flannel、calico 等）的问题。初步判断，很可能是 CoreDNS 组件的错误引起的某些问题，所以接下来我们测试 CoreDNS 是否正常。
3、检测 CoreDNS 应用是否正常运行
首先，检查 CoreDNS Pod 是否正在运行，如果 READY 为 0，则显示 CoreDNS 组件有问题：
-l：指定根据 label 标签进行查找，筛选有该 label 的 Pod。
-n：指定 CoreDNS 组件部署的 Namespace。
$ kubectl get pods -l k8s-app=kube-dns -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-669f77d7cc-8pkpw 1/1 Running 2 6h5m
coredns-669f77d7cc-jk9wk 1/1 Running 2 6h5m
可也看到 CoreDNS 两个 Pod 均正常启动，所以再查看两个 Pod 中的日志信息，看看有无错误日志：
$ for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name);
do kubectl logs --namespace=kube-system $p; done
.:53
[INFO] plugin/reload: Running configuration MD5 = 4e235fcc3696966e76816bcd9034ebc7
CoreDNS-1.6.7
linux/amd64, go1.13.6, da7f65b
.:53
[INFO] plugin/reload: Running configuration MD5 = 4e235fcc3696966e76816bcd9034ebc7
CoreDNS-1.6.7
linux/amd64, go1.13.6, da7f65b
通过上面信息可以观察到，日志中信息也是正常启动没有问题。再接下来，查看下 CoreDNS 的入口 Service "kube-dns" 是否存在：
kube-dns 的 IP 为 10.96.0.10，集群内的 Pod 都是通过该 IP 与 DNS 组件进行交互，查询 DNS 信息。
$ kubectl get service -n kube-system | grep kube-dns
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP
上面显示 Service "kube-dns" 也存在，但是 Service 是通过 endpoints 和 Pod 进行绑定的，所以看看这个 CoreDNS 的 endpoints 是否存在，及信息是否正确：
$ kubectl get endpoints kube-dns -n kube-system
NAME ENDPOINTS
kube-dns 10.244.0.21:53,d10.244.2.82:53,10.244.0.21:9153
可以看到 endpoints 配置也是正常的，正确的与两个 CporeDNS Pod 进行了关联。
经过上面一系列检测 CoreDNS 组件确实是正常运行。接下来，观察 CoreDNS 域名解析日志，进而确定 Pod 中的域名解析请求是否能够正常进入 CoreDNS。
4、观察 CoreDNS 域名解析日志信息
使用
kubectl edit
命令来修改存储于 Kubernetes
ConfigMap
中的
CoreDNS
配置参数信息，添加
log
参数，让 CoreDNS 日志中显示域名解析信息：
CoreDNS 配置参数说明：
errors: 输出错误信息到控制台。
health：CoreDNS 进行监控检测，检测地址为 http://localhost:8080/health 如果状态为不健康则让 Pod 进行重启。
ready: 全部插件已经加载完成时，将通过 endpoints 在 8081 端口返回 HTTP 状态 200。
kubernetes：CoreDNS 将根据 Kubernetes 服务和 pod 的 IP 回复 DNS 查询。
prometheus：是否开启 CoreDNS Metrics 信息接口，如果配置则开启，接口地址为 http://localhost:9153/metrics
forward：任何不在Kubernetes 集群内的域名查询将被转发到预定义的解析器 (/etc/resolv.conf)。
cache：启用缓存，30 秒 TTL。
loop：检测简单的转发循环，如果找到循环则停止 CoreDNS 进程。
reload：监听 CoreDNS 配置，如果配置发生变化则重新加载配置。
loadbalance：DNS 负载均衡器，默认 round_robin。
## 编辑 coredns 配置
$ kubectl edit configmap coredns -n kube-system
apiVersion: v1
data:
Corefile: |
.:53 {
log #添加log
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}
保存更改后 CoreDNS 会自动重新加载配置信息，不过可能需要等上一两分钟才能将这些更改传播到 CoreDNS Pod。等一段时间后，再次查看 CoreDNS 日志：
$ for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name);
do kubectl logs --namespace=kube-system $p; done
.:53
[INFO] plugin/reload: Running configuration MD5 = 6434d0912b39645ed0707a3569fd69dc
CoreDNS-1.6.7
linux/amd64, go1.13.6, da7f65b
[INFO] Reloading
[INFO] plugin/health: Going into lameduck mode for 5s
[INFO] 127.0.0.1:47278 - 55171 "HINFO IN 4940754309314083739.5160468069505858354. udp 57 false 512" NXDOMAIN qr,rd,ra 57 0.040844011s
[INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac
[INFO] Reloading complete
.:53
[INFO] plugin/reload: Running configuration MD5 = 6434d0912b39645ed0707a3569fd69dc
CoreDNS-1.6.7
linux/amd64, go1.13.6, da7f65b
[INFO] Reloading
[INFO] plugin/health: Going into lameduck mode for 5s
[INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac
[INFO] Reloading complete
[INFO] 127.0.0.1:32896 - 49064 "HINFO IN 1027842207973621585.7098421666386159336. udp 57 false 512" NXDOMAIN qr,rd,ra 57 0.044098742s
[INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac
[INFO] Reloading complete
可以看到 CoreDNS 已经重新加载了配置，我们再次进入 dnsuitls Pod 中执行 ping 命令：
## 进入 DNSutils Pod 命令行
$ kubectl exec -it dnsutils /bin/sh -n kube-system
## 执行 ping 命令
$ ping www.baidu.com
## 退出 dnsutils Pod 命令行
$ exit
然后，再次查看 CoreDNS 的日志信息：
$ for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name);
do kubectl logs --namespace=kube-system $p; done
.:53
[INFO] plugin/reload: Running configuration MD5 = 6434d0912b39645ed0707a3569fd69dc
CoreDNS-1.6.7
linux/amd64, go1.13.6, da7f65b
[INFO] Reloading
[INFO] plugin/health: Going into lameduck mode for 5s
[INFO] 127.0.0.1:47278 - 55171 "HINFO IN 4940754309314083739.5160468069505858354. udp 57 false 512" NXDOMAIN qr,rd,ra 57 0.040844011s
[INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac
[INFO] Reloading complete
.:53
[INFO] plugin/reload: Running configuration MD5 = 6434d0912b39645ed0707a3569fd69dc
CoreDNS-1.6.7
linux/amd64, go1.13.6, da7f65b
[INFO] Reloading
[INFO] plugin/health: Going into lameduck mode for 5s
[INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac
[INFO] Reloading complete
[INFO] 127.0.0.1:32896 - 49064 "HINFO IN 1027842207973621585.7098421666386159336. udp 57 false 512" NXDOMAIN qr,rd,ra 57 0.044098742s
[INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac
[INFO] Reloading complete
发现和之前没有执行 ping 命令时候一样，没有 DNS 域名解析的日志信息，说明 Pod 执行域名解析时，请求并没有进入 CoreDNS 中。接下来在查看 Pod 中 DNS 配置信息，进而分析问题。
5、查看 Pod 中的 DNS 配置信息
一般 Pod 中的
DNS
策略默认为
ClusterFirst
，该参数起到的作用是，优先从
Kubernetes DNS
插件地址读取
DNS
配置。所以，我们正常创建的 Pod 中，DNS 配置 DNS 服务器地址应该指定为 Kubernetes 集群的 DNS 插件 Service 提供的虚拟 IP 地址。
注：其中 DNS 策略（dnsPolicy）支持四种类型：
Default： 从 DNS 所在节点继承 DNS 配置，即该 Pod 的 DNS 配置与宿主机完全一致。
ClusterFirst：预先从 Kubenetes 的 DNS 插件中进行 DNS 解析，如果解析不成功，才会使用宿主机的 DNS 进行解析。
ClusterFirstWithHostNet：Pod 是用 HOST 模式启动的（hostnetwork），用 HOST 模式表示 Pod 中的所有容器，都使用宿主机的 /etc/resolv.conf 配置进行 DNS 解析，但如果使用了 HOST 模式，还继续使用 Kubernetes 的 DNS 服务，那就将 dnsPolicy 设置为 ClusterFirstWithHostNet。
None：完全忽略 kubernetes 系统提供的 DNS，以 Pod Spec 中 dnsConfig 配置为主。
为了再分析原因，我们接着进入 dnsutils Pod 中，查看 Pod 中 DNS 配置文件
/etc/resolv.conf
配置参数是否正确：
resolv.conf 配置参数说明：
search： 指明域名查询顺序。
nameserver： 指定 DNS 服务器的 IP 地址，可以配置多个 nameserver。
## 进入 dnsutils Pod 内部 sh 命令行
$ kubectl exec -it dnsutils /bin/sh -n kube-system
## 查看 resolv.conf 配置文件
$ cat /etc/resolv.conf
nameserver 10.96.0.10
search kube-system.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
## 退出 DNSutils Pod 命令行
$ exit
可以看到 Pod 内部的 resolv.conf 内容，其中 nameserver 指定 DNS 解析服务器 IP 为 "10.96.0.10" ，这个 IP 地址正是本人 Kubernetes 集群 CoreDNS 的 Service "kube-dns" 的 cluterIP，说明当 Pod 内部进行域名解析时，确实是将查询请求发送到 Service "kube-dns" 提供的虚拟 IP 进行域名解析。
那么，既然 Pod 中 DNS 配置文件没问题，且 CoreDNS 也没问题，会不会是 Pod 本身域名解析不正常呢？或者 Service "kube-dns" 是否能够正常转发域名解析请求到 CoreDNS Pod 中？
当然，猜想是没有用的，进行一下测试来观察问题到底出在哪里。
6、进行观察来定位问题所在
上面怀疑是 Pod 本身解析域名有问题，不能正常解析域名。或者 Pod 没问题，但是请求域名解析时将请求发送到 Service "kube-dns" 后不能正常转发请求到 CoreDNS Pod。 为了验证这两点，我们可以修改 Pod 中的 /etc/resolv.conf 配置来进行测试验证。
修改
resolv.conf
中
DNS
解析请求地址为
阿里云 DNS
服务器地址，然后执行
ping
命令验证是否为
Pod
解析域名是否有问题：
## 进入 dnsutils Pod 内部 sh 命令行
$ kubectl exec -it dnsutils /bin/sh -n kube-system
## 编辑 /etc/resolv.conf 文件，修改 nameserver 参数为阿里云提供的 DNS 服务器地址
$ vi /etc/resolv.conf
nameserver 223.5.5.5
#nameserver 10.96.0.10
search kube-system.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
## 修改完后再进行 ping 命令测试，看看是否能够解析 www.mydlq.club 网址
$ ping www.mydlq.club
PING www.mydlq.club (140.143.8.181) 56(84) bytes of data.
64 bytes from 140.143.8.181 (140.143.8.181): icmp_seq=1 ttl=128 time=9.70 ms
64 bytes from 140.143.8.181 (140.143.8.181): icmp_seq=2 ttl=128 time=9.21 ms
## 退出 DNSutils Pod 命令行
$ exit
上面可也观察到 Pod 中更换 DNS 服务器地址后，域名解析正常，说明 Pod 本身域名解析是没有问题的。
接下来再修改
resolv.conf
中
DNS
解析请求地址为
CoreDNS Pod
的
IP
地址，这样让
Pod
直接连接
CoreDNS Pod
的
IP
，而不通过
Service
进行转发，再进行
ping
命令测试，进而判断
Service
kube-dns
是否能够正常转发请求到
CoreDNS Pod
的问题：
## 查看 CoreDNS Pod 的 IP 地址
$ kubectl get pods -n kube-system -o wide | grep coredns
coredns-669f77d7cc-rss5f 1/1 Running 0 10.244.2.155 k8s-node-2-13
coredns-669f77d7cc-rt8l6 1/1 Running 0 10.244.1.163 k8s-node-2-12
## 进入 dnsutils Pod 内部 sh 命令行
$ kubectl exec -it dnsutils /bin/sh -n kube-system
## 编辑 /etc/resolv.conf 文件，修改 nameserver 参数为阿里云提供的 DNS 服务器地址
$ vi /etc/resolv.conf
nameserver 10.244.2.155
nameserver 10.244.1.163
#nameserver 10.96.0.10
search kube-system.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
## 修改完后再进行 ping 命令测试，看看是否能够解析 www.mydlq.club 网址
$ ping www.mydlq.club
PING www.baidu.com (39.156.66.18): 56 data bytes
64 bytes from 39.156.66.18: seq=0 ttl=127 time=6.054 ms
64 bytes from 39.156.66.18: seq=1 ttl=127 time=4.678 ms
## 退出 DNSutils Pod 命令行
$ exit
## 观察 CoreDNS 日志信息，查看有无域名解析相关日志
$ for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name);
do kubectl logs --namespace=kube-system $p; done
.:53
[INFO] plugin/reload: Running configuration MD5 = 6434d0912b39645ed0707a3569fd69dc
CoreDNS-1.6.7
linux/amd64, go1.13.6, da7f65b
[INFO] Reloading
[INFO] plugin/health: Going into lameduck mode for 5s
[INFO] 127.0.0.1:47278 - 55171 "HINFO IN 4940754309314083739.5160468069505858354. udp 57 false 512" NXDOMAIN qr,rd,ra 57 0.040844011s
[INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac
[INFO] Reloading complete
[INFO] 10.244.1.162:40261 - 21083 "AAAA IN www.mydlq.club.kube-system.svc.cluster.local. udp 62 false 512" NXDOMAIN qr,aa,rd 155 0.000398875s
[INFO] 10.244.1.162:40261 - 20812 "A IN www.mydlq.club.kube-system.svc.cluster.local. udp 62 false 512" NXDOMAIN qr,aa,rd 155 0.000505793s
[INFO] 10.244.1.162:55066 - 53460 "AAAA IN www.mydlq.club.svc.cluster.local. udp 50 false 512" NXDOMAIN qr,aa,rd 143 0.000215384s
[INFO] 10.244.1.162:55066 - 53239 "A IN www.mydlq.club.svc.cluster.local. udp 50 false 512" NXDOMAIN qr,aa,rd 143 0.000267642s
.:53
[INFO] plugin/reload: Running configuration MD5 = 6434d0912b39645ed0707a3569fd69dc
CoreDNS-1.6.7
linux/amd64, go1.13.6, da7f65b
[INFO] Reloading
[INFO] plugin/health: Going into lameduck mode for 5s
[INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac
[INFO] Reloading complete
[INFO] 127.0.0.1:32896 - 49064 "HINFO IN 1027842207973621585.7098421666386159336. udp 57 false 512" NXDOMAIN qr,rd,ra 57 0.044098742s
[INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac
[INFO] Reloading complete
[INFO] 10.244.1.162:40261 - 21083 "AAAA IN www.mydlq.club.kube-system.svc.cluster.local. udp 62 false 512" NXDOMAIN qr,aa,rd 155 0.000217299s
[INFO] 10.244.1.162:40261 - 20812 "A IN www.mydlq.club.kube-system.svc.cluster.local. udp 62 false 512" NXDOMAIN qr,aa,rd 155 0.000264552s
[INFO] 10.244.1.162:55066 - 53460 "AAAA IN www.mydlq.club.svc.cluster.local. udp 50 false 512" NXDOMAIN qr,aa,rd 143 0.000144795s
[INFO] 10.244.1.162:55066 - 53239 "A IN www.mydlq.club.svc.cluster.local. udp 50 false 512" NXDOMAIN qr,aa,rd 143 0.000221163s
经过上面两个测试，已经可以得知，如果
Pod DNS
配置中直接修改
DNS
服务器地址为
CoreDNS Pod
的
IP
地址，
DNS
解析确实没有问题，能够正常解析。不过，正常的情况下 Pod 中 DNS 配置的服务器地址一般是 CoreDNS 的 Service 地址，不直接绑定 Pod IP（因为 Pod 每次重启 IP 都会发生变化）。 所以问题找到了，正是在 Pod 向 CoreDNS 的 Service "kube-dns" 进行域名解析请求转发时，出现了问题，一般
Service
的问题都跟
Kube-proxy
组件有关，接下来观察该组件是否存在问题。
7、分析 Kube-Proxy 是否存在问题
观察 Kube-proxy 的日志，查看是否存在问题：
## 查看 kube-proxy Pod 列表
$ kubectl get pods -n kube-system | grep kube-proxy
kube-proxy-6kdj2 1/1 Running 3 9h
kube-proxy-lw2q6 1/1 Running 3 9h
kube-proxy-mftlt 1/1 Running 3 9h
## 选择一个 kube-proxy Pod，查看最后 5 条日志内容
$ kubectl logs kube-proxy-6kdj2 --tail=5 -n kube-system
E0326 15:20:23.159364 1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[10 96 0 10 0 0 0 0 0 0 0 0 0 0 0 0]
E0326 15:20:23.159388 1 proxier.go:1192] Failed to sync endpoint for service: 10.8.0.10:53/UPD, err: parseIP Error ip=[10 96 0 16 0 0 0 0 0 0 0 0 0 0 0 0]
E0326 15:20:23.159479 1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[10 96 0 10 0 0 0 0 0 0 0 0 0 0 0 0]
E0326 15:20:23.159501 1 proxier.go:1192] Failed to sync endpoint for service: 10.8.0.10:53/TCP, err: parseIP Error ip=[10 96 0 16 0 0 0 0 0 0 0 0 0 0 0 0]
E0326 15:20:23.159595 1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[10 96 0 10 0 0 0 0 0 0 0 0 0 0 0 0]
通过 kube-proxy Pod 的日志可以看到，里面有很多 Error 级别的日志信息，根据关键字
IPVS
、
parseIP Error
可知，可能是由于 IPVS 模块对 IP 进行格式化导致出现问题。
因为这个问题是升级到 kubernetes 1.18 版本才出现的，所以去 Kubernetes Github 查看相关 issues，发现有人在升级 Kubernetes 版本到 1.18 后，也遇见了相同的问题，经过 issue 中 Kubernetes 维护人员讨论，分析出原因可能为新版 Kubernetes 使用的 IPVS 模块是比较新的，需要系统内核版本支持，本人使用的是 CentOS 系统，内核版本为 3.10，里面的 IPVS 模块比较老旧，缺少新版 Kubernetes IPVS 所需的依赖。
根据该 issue 讨论结果，解决该问题的办法是，更新内核为新的版本。
注：该 issues 地址为 https://github.com/kubernetes/kubernetes/issues/89520
四、解决问题
1、升级系统内核版本
升级 Kubernetes 集群各个节点的 CentOS 系统内核版本：
## 载入公钥
$ rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
## 安装 ELRepo 最新版本
$ yum install -y https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm
## 列出可以使用的 kernel 包版本
$ yum list available --disablerepo=* --enablerepo=elrepo-kernel
## 安装指定的 kernel 版本：
$ yum install -y kernel-lt-4.4.218-1.el7.elrepo --enablerepo=elrepo-kernel
## 查看系统可用内核
$ cat /boot/grub2/grub.cfg | grep menuentry
menuentry 'CentOS Linux (3.10.0-1062.el7.x86_64) 7 (Core)' --class centos （略）
menuentry 'CentOS Linux (4.4.218-1.el7.elrepo.x86_64) 7 (Core)' --class centos ...（略）
## 设置开机从新内核启动
$ grub2-set-default "CentOS Linux (4.4.218-1.el7.elrepo.x86_64) 7 (Core)"
## 查看内核启动项
$ grub2-editenv list
saved_entry=CentOS Linux (4.4.218-1.el7.elrepo.x86_64) 7 (Core)
重启系统使内核生效：
$ reboot
启动完成查看内核版本是否更新：
$ uname -r
4.4.218-1.el7.elrepo.x86_64
2、测试 Pod 中 DNS 是否能够正常解析
进入 Pod 内部使用 ping 命令测试 DNS 是否能正常解析：
## 进入 dnsutils Pod 内部 sh 命令行
$ kubectl exec -it dnsutils /bin/sh -n kube-system
## Ping 集群外部，例如这里 ping 一下百度
$ ping www.baidu.com
64 bytes from 39.156.66.14 (39.156.66.14): icmp_seq=1 ttl=127 time=7.20 ms
64 bytes from 39.156.66.14 (39.156.66.14): icmp_seq=2 ttl=127 time=6.60 ms
64 bytes from 39.156.66.14 (39.156.66.14): icmp_seq=3 ttl=127 time=6.38 ms
## Ping 集群内部 kube-api 的 Service 地址
$ ping kubernetes.default
64 bytes from kubernetes.default.svc.cluster.local (10.96.0.1): icmp_seq=1 ttl=64 time=0.051 ms
64 bytes from kubernetes.default.svc.cluster.local (10.96.0.1): icmp_seq=2 ttl=64 time=0.051 ms
64 bytes from kubernetes.default.svc.cluster.local (10.96.0.1): icmp_seq=3 ttl=64 time=0.064 ms
可以看到 Pod 中的域名解析已经恢复正常。
环境说明
pod ---> router--->svc---redis pod
namesapce 1 的pod 访问不了router 访问拒绝
原因： apiserver 重启导致sdn重启，防火墙策略没有生效，重启防火墙后解决
