日日操夜夜添-日日操影院-日日草夜夜操-日日干干-精品一区二区三区波多野结衣-精品一区二区三区高清免费不卡

公告：魔扣目錄網(wǎng)為廣大站長(zhǎng)提供免費(fèi)收錄網(wǎng)站服務(wù)，提交前請(qǐng)做好本站友鏈：【 網(wǎng)站目錄：http://www.ylptlb.cn 】， 免友鏈快審服務(wù)（50元/站），

點(diǎn)擊這里在線咨詢客服
新站提交
  • 網(wǎng)站：51998
  • 待審：31
  • 小程序：12
  • 文章：1030137
  • 會(huì)員：747

k8s部署維護(hù)問(wèn)題匯總

發(fā)布時(shí)間：2024-01-21 21:06:52 作者：網(wǎng)友整理

集群?jiǎn)栴}

系統(tǒng)

Error: unknown flag: --etcd-quorum-read

刪除service 里面的相應(yīng)字段

start request repeated too quickly for kube-apiserver.service

查看是不是有之前的進(jìn)程占用,然后將service 字段摳出來(lái)手動(dòng)啟動(dòng)查看可否成功,也可顯示錯(cuò)誤

health check for peer acd2ba924953b1ec could not connect: dial tcp 192.168.81.60:2380: getsockopt: connection refused

分析是因?yàn)閑tcd1的配置文件/etc/etcd/etcd.conf中的ETCD_INITIAL_CLUSTER_STATE是new，而在配置中ETCD_INITIAL_CLUSTER寫(xiě)入了etcd2/3的IP:PORT，這時(shí)etcd1嘗試去連接etcd2、etcd3，但是etcd2、3的etcd服務(wù)此時(shí)還未啟動(dòng)，因此需要先啟動(dòng)etcd2和3的etcd服務(wù)，再去啟動(dòng)etcd1。

dial tcp 127.0.0.1:2379: getsockopt: connection refused

etcd.conf ETCD_LISTEN_CLIENT_URLS 選項(xiàng)中加入 https://127.0.0.1:2379`

Unable to connect to the server: x509: certificate is valid for etcd1, etcd2, node1, node2, kube.NETes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster, kubernetes.default.svc.cluster.local, not k8s1

修改/root/cfssl/kubernetes/kubernetes-server-csr.json   加入錯(cuò)誤中的k8s

FAIled at step CHDIR spawning /usr/local/bin/kubelet: No such file or directory

mkdir /var/lib/kubelet (具體看service 里面WorkingDirectory)

failed to run Kubelet: misconfiguration: kubelet cgroup driver: "systemd" is different from Docker cgroup driver: "cgroupfs"

vim /usr/lib/systemd/system/docker.service ExecStart=/usr/local/bin/dockerd --exec-opt native.cgroupdriver=systemd   具體按照?qǐng)?bào)錯(cuò)修改

etcd cluster is unavailable or misconfigured; error #0: dial tcp 127.0.0.1:4

vim /etcd/etcd/etcd.conf
ETCD_LISTEN_CLIENT_URLS=https://192.168.50.12:2379,https://127.0.0.1:2379;

master  狀態(tài)  flanned 正常  pod 內(nèi)部通訊 互相ping 通node 狀態(tài)  宿主機(jī) 能ping 通百度容器  能ping 宿主機(jī)svc

現(xiàn)象

容器 不能ping 百度

kubectl run -it --rm DNS-test --image=busybox:1.28.4 sh 測(cè)試dns

Error registering network: failed to acquire lease: node "k8s-node2" pod cid

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"}}'

Unable to connect to the server: x509: certificate signed by unknown authori

原因:重新初始化環(huán)境沒(méi)有清理干凈

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

ERROR FileContent--proc-sys-net-bridge-bridge-nf-call-iptables]:

echo "1" >/proc/sys/net/bridge/bridge-nf-call-iptables

error: no configuration has been provided, try setting KUBERNETES_MASTER environment variable

在/etc/profile末尾增加export KUBECONFIG=/etc/kubernetes/admin.conf添加完后執(zhí)行source /etc/profile

svc不能被解析的原因

現(xiàn)象

pod 能ping 外網(wǎng) 但是不能解析百度  能ping114  不能ping svc 地址

解決

對(duì)應(yīng)的node上面沒(méi)有開(kāi)啟轉(zhuǎn)發(fā)(具體問(wèn)題可以先查看node上面的kube-proxy logs 因?yàn)閟vc 是通過(guò) kube-proxy分發(fā)出去的)echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables

Error registering network: failed to acquire lease: node "master2" pod cidr not assigned

設(shè)置 pod ip 的網(wǎng)段 ，網(wǎng)段之所以是 10.244.0.0/16，是因?yàn)楹竺姘惭b flannel 網(wǎng)絡(luò)插件時(shí)，yaml 文件里面的 ip 段也是這個(gè)，兩個(gè)保持一致，不然可能會(huì)使得 Node 間 Cluster IP 不通。這個(gè)參數(shù)必須得指定，如果這里不設(shè)置的話后面安裝 flannel 網(wǎng)絡(luò)插件時(shí)會(huì)報(bào)這個(gè)錯(cuò)誤

Applying cgroup … caused: mkdir …no space left on device或者在describe pod的時(shí)候出現(xiàn)cannot allocate memory

解決方法

當(dāng)大量pod 出現(xiàn)evictive情況

說(shuō)明節(jié)點(diǎn)資源不夠，清理空間

ingress 獲取源地址ip為127.0.0.1 問(wèn)題

 

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里面就可以了

etcd 節(jié)點(diǎn)異常恢復(fù)(openshift)

master 節(jié)點(diǎn)故障，docker ps -a |grep etcd |grep -v POD 發(fā)現(xiàn)etcd 異常退出

查看日志

docker logs -f etcd...
···
etcdserer : open wal error: wal : file not found

恢復(fù)步驟

將故障節(jié)點(diǎn)剝離集群，恢復(fù)后添加

etcdctl2 cluster-health
獲取問(wèn)題節(jié)點(diǎn)的member id
etcdclt2 member remove $memberid
將問(wèn)題節(jié)點(diǎn)移除
----
停止問(wèn)題節(jié)點(diǎn)上的etcd 服務(wù)
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 內(nèi)容，設(shè)置new etcd 配置
[osev3:clildren]
masters
etcd
nodes
new_etcd
----
從集群中釋放問(wèn)題節(jié)點(diǎn)
----
更新etcd 擴(kuò)容腳本
ansible-playbook playbooks/openshift-master/openshift_node_groups.yaml
----
驗(yàn)證
etcdctl clister-health

節(jié)點(diǎn)not ready

rpc error: code = ResourceExhausted desc = grpc: trying to send message larger than max (xxxxxxx vs. 8388608)

描述

集群有個(gè)master節(jié)點(diǎn)NotReady。kubelet報(bào)錯(cuò) “Warning ContainerGCFailed ... ”

Warning ContainerGCFailed ...
rpc error: code = ResourceExhausted desc = grpc: trying to send message larger
than max (xxxxxxx vs. 8388608)

這個(gè)錯(cuò)和下面是一個(gè)問(wèn)題。

rpc error: code = ResourceExhausted desc = grpc: received message larger
than max (xxxxx vs. 4194304)

原因

  • kubelet與cri-o通信，cri-o返回信息大小超過(guò)grpc的限制

  • kubelet無(wú)法與cri-o通信，導(dǎo)致內(nèi)部大量錯(cuò)誤出現(xiàn)

超過(guò)的根源在于容器數(shù)量過(guò)多，grpc返回信息過(guò)大，從而你超過(guò)了限制，無(wú)法正確返回。

解決方法

查看GRPC Buff塊大小，擴(kuò)大至8MB。擴(kuò)大方法參考

https://github.com/cri-o/cri-o/pull/2027github.com/cri-o/cri-o/pull/2027

假如已經(jīng)是8MB，仍然報(bào)錯(cuò)，則可能是鏡像等docker資源需要清理。可以執(zhí)行

docker system prune

為了根除此類錯(cuò)誤，可以在節(jié)點(diǎn)上設(shè)置完善的Garbage Collection機(jī)制。參考

Garbage Collectiondocs.openshift.com/container-platform/3.11/admin_guide/garbage_collection.html

node 拉取鏡像速度很快，但是起pod 鏡像很慢

Pods get stuck in ContainerCreating state when pulling image takes long

https://github.com/kubernetes/kubernetes/issues/83471

apiserver 前面使用的是 f5的負(fù)載均 策略有問(wèn)題，導(dǎo)致請(qǐng)求全部打在了master1上、                          

應(yīng)用故障

不同ns之前的pod怎么訪問(wèn)

創(chuàng)建一個(gè)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

 

 

pod內(nèi)出現(xiàn)no space left on device

說(shuō)明持久化存儲(chǔ)資源不足

pod處于running 域名訪問(wèn)404

檢查route  ingress 是否為正常狀態(tài) 本地配置host是否解析正常

network plugin cni failed to set up pod

關(guān)鍵詞： cni networkplugin

報(bào)錯(cuò)： networkPlugin cni filed  to send cni request: post http://xxx/dial .var/run/openshift/cni-server.sock: connet: connetc refuse

解決

找到調(diào)度的節(jié)點(diǎn)，重啟sdn

kubectl get openshift-sdn delete po --grace-period=0 --force sdn-xxx

不通pod 通過(guò)service hostname 訪問(wèn)不通

經(jīng)過(guò)排查為 networkplicy 缺少

https://kubernetes.io/zh/docs/concepts/services-networking/network-policies/

pod 不斷被重建

因?yàn)閚s開(kāi)啟可vpa導(dǎo)致

admission是會(huì)去手動(dòng)改request值  updater組件會(huì)發(fā)現(xiàn)request大于推薦去驅(qū)逐  然后admission掛了 改不了request  pod一起來(lái) updater發(fā)現(xiàn)它大于推薦request 就會(huì)驅(qū)逐  然后一直循環(huán)在驅(qū)逐

然后pod會(huì)提示找不到cm

應(yīng)用做更新，所有的yaml都在一個(gè)文件里面，可能是cm更新的慢了，然后pod會(huì)提示找不到cm，pod重啟還是會(huì)找不到cm

 

timeout expired waiting for volumes to attach or mount for pod

eureka的問(wèn)題：pod不存在了，容器存在，up中有ip，可以調(diào)度

pod狀態(tài)terminating，強(qiáng)制刪除了，但是容器沒(méi)有刪除導(dǎo)致的

pod自動(dòng)重啟，pod名字不變，ip 和創(chuàng)建時(shí)間變化

VPA目前驅(qū)逐pod后  pod名字不會(huì)變  但是ip和創(chuàng)建時(shí)間會(huì)變，VPA關(guān)閉后無(wú)此現(xiàn)象

壓力測(cè)試 短連接 pod 負(fù)載不均衡

會(huì)話保持必須關(guān)閉

a應(yīng)用配置ssl 之后跳轉(zhuǎn)到了其他的地址

a 應(yīng)用使用了b 應(yīng)用的證書(shū)

pod 存活幾秒鐘重啟

vpa-admin-controller  異常pod

 

FAQ

service 選擇不通的depoy 的pod

service 通過(guò)label 選擇pod， 可以在A，B 的deploy 分別添加一個(gè)相同的標(biāo)簽，svc 中的selector 使用這個(gè)相同的標(biāo)簽，這樣就可以選擇A 和 B 的deploy創(chuàng)建的pod

通過(guò)router4層可以下載，通過(guò)7層下載502 gataway

檢查haproxy的問(wèn)題，開(kāi)啟haproxy的日志

ip地址沖突排查

表現(xiàn)為ping 不通，telnet 失敗

arping -I ens33  10.0.13.3

如果存在多個(gè)mac 地址，則表明地址沖突

如何刪除terminating 的ns

現(xiàn)象

kubectl get ns 
demo			terminating			50d

查看編排內(nèi)容

kubectl get ns demo -o json
 "spec": {
        "finalizers": [
            "kubernetes"
        ]
    },
刪除上面這段 然后導(dǎo)入到新的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 中的entrypoint.sh 無(wú)執(zhí)行權(quán)限

在configmap下面增加熟悉mode：493(十進(jìn)制，八進(jìn)制就是755)

configmap:
  name: xxx
  items:
  - key: entrypoinyt.sh
    path: entrypoiny.sh
    mode: 493

 

build image no space left on device

怎么修改

修改docker 啟動(dòng)參數(shù)
vim /etc/systemd/system/multi-user.target.wants/docker.service

在 exec 參數(shù)后面加上 --graph=/xx/xxx/xx 

systemctl daemon-reload
systemctl restart docker

修改daemon.jsono

{
"data-root": "/xxx/xxx"
}

 

the server doesn’t have a resource type ‘xxx’

~/.kube 客戶端認(rèn)證文件失效或者損壞，從其他節(jié)點(diǎn)的root用戶拷一份過(guò)來(lái)即可

tcp router 不通，無(wú)法通過(guò)tcp連接到服務(wù)

登陸到router 部署的節(jié)點(diǎn)

netstat -tnlp 查看端口是否正常監(jiān)聽(tīng)

kubectl -n  default routerxxx rsh

grep -i  "xxxx" -r ./

查看tcp-router是否有明顯錯(cuò)誤日志

kubectl -n defaut logs -f routerxxx --tail=10

查看端口范圍

iptables -nL INPUT

怎么指定用戶id啟動(dòng)應(yīng)用runasuser

創(chuàng)建sa
kubectl create sa -n xxx xxx 
添加sa到對(duì)應(yīng)的scc
kubectl adm policy add-scc-to-user anyuid -n xx -z xxx 
修改部署文件
serviceAccount: xxx
  serviceAccountName: xxx
spec.template.spec.container[]
securityContext:
   runAsuser: xxx

node可以解析，pod不能解析

解決 Kubernetes 中 Pod 無(wú)法正常域名解析問(wèn)題分析與 IPVS parseIP Error 問(wèn)題

系統(tǒng)環(huán)境：

CoreDNS 版本：1.6.7
Docker 版本：19.03.8
Kubernetes 版本：1.18.1
操作系統(tǒng)版本：centos 7.8
CentOS 內(nèi)核版本：3.10.0-1062
參考地址：

Kubernetes Github
CentOS 升級(jí)內(nèi)核版本
Kubernetes 官方文檔 - Services
Kubernetes 官方文檔 - 調(diào)試DNS服務(wù)
Kubernetes 官方文檔 - 自定義DNS服務(wù)
Issues "ipvs do not sync endpoint error: parseIP Error"
問(wèn)題分析比較長(zhǎng)，分析的懷疑人生...

一、問(wèn)題描述
       最近將 Kubernetes 升級(jí)到 1.18.1 版本，不過(guò)升級(jí)完后，查看工作節(jié)點(diǎn)的部分 Pod 無(wú)法啟動(dòng)，查看消息全是 
connetion timeout
 的問(wèn)題，一看連接超時(shí)的地址大部分是以域名方式連接集群內(nèi)部地址（ClusterIP），少部分是以域名方式連接集群外部地址，通過(guò) IP 進(jìn)行遠(yuǎn)程連接的應(yīng)用倒是沒(méi)有問(wèn)題（例如，應(yīng)用通過(guò) IP 連接 MySQL），由此判斷，初步懷疑很可能是 DNS 出現(xiàn)了問(wèn)題，后來(lái)慢慢發(fā)現(xiàn) kube-proxy 中的錯(cuò)誤，再定位到 IPVS parseIP Error 錯(cuò)誤，再到解決問(wèn)題。下面是分析及姐問(wèn)題的過(guò)程。

二、部署 DNS 調(diào)試工具
為了探針是否為 DNS 問(wèn)題，這里需要提前部署用于測(cè)試 DNS 問(wèn)題的 dnsutils 鏡像，該鏡像中包含了用于測(cè)試 DNS 問(wèn)題的工具包，非常利于我們分析與發(fā)現(xiàn)問(wèn)題。接下來(lái)，我們將在 Kubernetes 中部署這個(gè)工具鏡像。

1、創(chuàng)建 DNS 工具 Pod 部署文件
創(chuàng)建用于部署的 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、通過(guò) Kubectl 工具部署 NDS 工具鏡像
通過(guò) Kubectl 工具，將對(duì)上面 DNS 工具鏡像部署到 Kubernetes 中：

-n：指定應(yīng)用部署的 Namespace 空間。
$ kubectl create -f ndsutils.yaml -n kube-system
三、問(wèn)題分析
1、進(jìn)入 DNS 工具 Pod 的命令行
上面 DNS 工具已經(jīng)部署完成，我們可也通過(guò) Kubectl 工具進(jìn)入 Pod 命令行，然后，使用里面的一些工具進(jìn)行問(wèn)題分析，命令如下：

exec：讓指定 Pod 容器執(zhí)行某些命令。
-i：將控制臺(tái)內(nèi)容傳入到容器。
-t：進(jìn)入容器的 tty 使用 bash 命令行。
-n：指定上面部署 DNS Pod 所在的 Namespace。
$ kubectl exec -it dnsutils /bin/sh -n kube-system
2、通過(guò) Ping 和 Nsloopup 命令測(cè)試
進(jìn)入容器 sh 命令行界面后，先使用 ping 命令來(lái)分別探測(cè)觀察是否能夠 ping 通集群內(nèi)部和集群外部的地址，觀察到的信息如下：

## Ping 集群外部，例如這里 ping 一下百度
$ ping www.baidu.com
ping: bad address 'www.baidu.com'

## Ping 集群內(nèi)部 kube-apiserver 的 Service 地址
$ ping kubernetes.default
ping: bad address 'kubernetes.default'

## 使用 nslookup 命令查詢域名信息
$ nslookup kubernetes.default
;; connection timed out; no servers could be reached

## 直接 Ping 集群內(nèi)部 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 分析域名信息時(shí)超時(shí)。然而，使用 ping kube-apiserver 的 IP 地址 "10.96.0.1" 則可以正常通信，所以，排除網(wǎng)絡(luò)插件（flannel、calico 等）的問(wèn)題。初步判斷，很可能是 CoreDNS 組件的錯(cuò)誤引起的某些問(wèn)題，所以接下來(lái)我們測(cè)試 CoreDNS 是否正常。

3、檢測(cè) CoreDNS 應(yīng)用是否正常運(yùn)行
首先，檢查 CoreDNS Pod 是否正在運(yùn)行，如果 READY 為 0，則顯示 CoreDNS 組件有問(wèn)題：

-l：指定根據(jù) label 標(biāo)簽進(jìn)行查找，篩選有該 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 兩個(gè) Pod 均正常啟動(dòng)，所以再查看兩個(gè) Pod 中的日志信息，看看有無(wú)錯(cuò)誤日志：

$ 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
通過(guò)上面信息可以觀察到，日志中信息也是正常啟動(dòng)沒(méi)有問(wèn)題。再接下來(lái)，查看下 CoreDNS 的入口 Service "kube-dns" 是否存在：

kube-dns 的 IP 為 10.96.0.10，集群內(nèi)的 Pod 都是通過(guò)該 IP 與 DNS 組件進(jìn)行交互，查詢 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 是通過(guò) endpoints 和 Pod 進(jìn)行綁定的，所以看看這個(gè) 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 配置也是正常的，正確的與兩個(gè) CporeDNS Pod 進(jìn)行了關(guān)聯(lián)。

經(jīng)過(guò)上面一系列檢測(cè) CoreDNS 組件確實(shí)是正常運(yùn)行。接下來(lái)，觀察 CoreDNS 域名解析日志，進(jìn)而確定 Pod 中的域名解析請(qǐng)求是否能夠正常進(jìn)入 CoreDNS。

4、觀察 CoreDNS 域名解析日志信息
使用 
kubectl edit
 命令來(lái)修改存儲(chǔ)于 Kubernetes 
ConfigMap
 中的 
CoreDNS
 配置參數(shù)信息，添加 
log
 參數(shù)，讓 CoreDNS 日志中顯示域名解析信息：

CoreDNS 配置參數(shù)說(shuō)明：

errors: 輸出錯(cuò)誤信息到控制臺(tái)。
health：CoreDNS 進(jìn)行監(jiān)控檢測(cè)，檢測(cè)地址為 http://localhost:8080/health 如果狀態(tài)為不健康則讓 Pod 進(jìn)行重啟。
ready: 全部插件已經(jīng)加載完成時(shí)，將通過(guò) endpoints 在 8081 端口返回 HTTP 狀態(tài) 200。
kubernetes：CoreDNS 將根據(jù) Kubernetes 服務(wù)和 pod 的 IP 回復(fù) DNS 查詢。
prometheus：是否開(kāi)啟 CoreDNS Metrics 信息接口，如果配置則開(kāi)啟，接口地址為 http://localhost:9153/metrics
forward：任何不在Kubernetes 集群內(nèi)的域名查詢將被轉(zhuǎn)發(fā)到預(yù)定義的解析器 (/etc/resolv.conf)。
cache：?jiǎn)⒂镁彺妫?0 秒 TTL。
loop：檢測(cè)簡(jiǎn)單的轉(zhuǎn)發(fā)循環(huán)，如果找到循環(huán)則停止 CoreDNS 進(jìn)程。
reload：監(jiān)聽(tīng) CoreDNS 配置，如果配置發(fā)生變化則重新加載配置。
loadbalance：DNS 負(fù)載均衡器，默認(rèn) 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 會(huì)自動(dòng)重新加載配置信息，不過(guò)可能需要等上一兩分鐘才能將這些更改傳播到 CoreDNS Pod。等一段時(shí)間后，再次查看 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 已經(jīng)重新加載了配置，我們?cè)俅芜M(jìn)入 dnsuitls Pod 中執(zhí)行 ping 命令：

## 進(jìn)入 DNSutils Pod 命令行
$ kubectl exec -it dnsutils /bin/sh -n kube-system

## 執(zhí)行 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
發(fā)現(xiàn)和之前沒(méi)有執(zhí)行 ping 命令時(shí)候一樣，沒(méi)有 DNS 域名解析的日志信息，說(shuō)明 Pod 執(zhí)行域名解析時(shí)，請(qǐng)求并沒(méi)有進(jìn)入 CoreDNS 中。接下來(lái)在查看 Pod 中 DNS 配置信息，進(jìn)而分析問(wèn)題。

5、查看 Pod 中的 DNS 配置信息
一般 Pod 中的 
DNS
 策略默認(rèn)為 
ClusterFirst
，該參數(shù)起到的作用是，優(yōu)先從 
Kubernetes DNS
 插件地址讀取 
DNS
 配置。所以，我們正常創(chuàng)建的 Pod 中，DNS 配置 DNS 服務(wù)器地址應(yīng)該指定為 Kubernetes 集群的 DNS 插件 Service 提供的虛擬 IP 地址。

注：其中 DNS 策略（dnsPolicy）支持四種類型：

Default： 從 DNS 所在節(jié)點(diǎn)繼承 DNS 配置，即該 Pod 的 DNS 配置與宿主機(jī)完全一致。
ClusterFirst：預(yù)先從 Kubenetes 的 DNS 插件中進(jìn)行 DNS 解析，如果解析不成功，才會(huì)使用宿主機(jī)的 DNS 進(jìn)行解析。
ClusterFirstWithHostNet：Pod 是用 HOST 模式啟動(dòng)的（hostnetwork），用 HOST 模式表示 Pod 中的所有容器，都使用宿主機(jī)的 /etc/resolv.conf 配置進(jìn)行 DNS 解析，但如果使用了 HOST 模式，還繼續(xù)使用 Kubernetes 的 DNS 服務(wù)，那就將 dnsPolicy 設(shè)置為 ClusterFirstWithHostNet。
None：完全忽略 kubernetes 系統(tǒng)提供的 DNS，以 Pod Spec 中 dnsConfig 配置為主。
為了再分析原因，我們接著進(jìn)入 dnsutils Pod 中，查看 Pod 中 DNS 配置文件 
/etc/resolv.conf
 配置參數(shù)是否正確：

resolv.conf 配置參數(shù)說(shuō)明：

search： 指明域名查詢順序。
nameserver： 指定 DNS 服務(wù)器的 IP 地址，可以配置多個(gè) nameserver。
## 進(jìn)入 dnsutils Pod 內(nèi)部 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 內(nèi)部的 resolv.conf 內(nèi)容，其中 nameserver 指定 DNS 解析服務(wù)器 IP 為 "10.96.0.10" ，這個(gè) IP 地址正是本人 Kubernetes 集群 CoreDNS 的 Service "kube-dns" 的 cluterIP，說(shuō)明當(dāng) Pod 內(nèi)部進(jìn)行域名解析時(shí)，確實(shí)是將查詢請(qǐng)求發(fā)送到 Service "kube-dns" 提供的虛擬 IP 進(jìn)行域名解析。

那么，既然 Pod 中 DNS 配置文件沒(méi)問(wèn)題，且 CoreDNS 也沒(méi)問(wèn)題，會(huì)不會(huì)是 Pod 本身域名解析不正常呢？或者 Service "kube-dns" 是否能夠正常轉(zhuǎn)發(fā)域名解析請(qǐng)求到 CoreDNS Pod 中？

當(dāng)然，猜想是沒(méi)有用的，進(jìn)行一下測(cè)試來(lái)觀察問(wèn)題到底出在哪里。

6、進(jìn)行觀察來(lái)定位問(wèn)題所在
上面懷疑是 Pod 本身解析域名有問(wèn)題，不能正常解析域名。或者 Pod 沒(méi)問(wèn)題，但是請(qǐng)求域名解析時(shí)將請(qǐng)求發(fā)送到 Service "kube-dns" 后不能正常轉(zhuǎn)發(fā)請(qǐng)求到 CoreDNS Pod。 為了驗(yàn)證這兩點(diǎn)，我們可以修改 Pod 中的 /etc/resolv.conf 配置來(lái)進(jìn)行測(cè)試驗(yàn)證。

修改 
resolv.conf
 中 
DNS
 解析請(qǐng)求地址為 
阿里云 DNS
 服務(wù)器地址，然后執(zhí)行 
ping
 命令驗(yàn)證是否為 
Pod
 解析域名是否有問(wèn)題：

## 進(jìn)入 dnsutils Pod 內(nèi)部 sh 命令行
$ kubectl exec -it dnsutils /bin/sh -n kube-system

## 編輯 /etc/resolv.conf 文件，修改 nameserver 參數(shù)為阿里云提供的 DNS 服務(wù)器地址
$ 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

## 修改完后再進(jìn)行 ping 命令測(cè)試，看看是否能夠解析 www.mydlq.club 網(wǎng)址
$ 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 服務(wù)器地址后，域名解析正常，說(shuō)明 Pod 本身域名解析是沒(méi)有問(wèn)題的。

接下來(lái)再修改 
resolv.conf
 中 
DNS
 解析請(qǐng)求地址為 
CoreDNS Pod
 的 
IP
 地址，這樣讓 
Pod
 直接連接 
CoreDNS Pod
 的 
IP
，而不通過(guò) 
Service
 進(jìn)行轉(zhuǎn)發(fā)，再進(jìn)行 
ping
 命令測(cè)試，進(jìn)而判斷 
Service
 
kube-dns
 是否能夠正常轉(zhuǎn)發(fā)請(qǐng)求到 
CoreDNS Pod
 的問(wèn)題：

## 查看 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

## 進(jìn)入 dnsutils Pod 內(nèi)部 sh 命令行
$ kubectl exec -it dnsutils /bin/sh -n kube-system

## 編輯 /etc/resolv.conf 文件，修改 nameserver 參數(shù)為阿里云提供的 DNS 服務(wù)器地址
$ 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

## 修改完后再進(jìn)行 ping 命令測(cè)試，看看是否能夠解析 www.mydlq.club 網(wǎng)址
$ 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 日志信息，查看有無(wú)域名解析相關(guān)日志
$ 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
經(jīng)過(guò)上面兩個(gè)測(cè)試，已經(jīng)可以得知，如果 
Pod DNS
 配置中直接修改 
DNS
 服務(wù)器地址為 
CoreDNS Pod
 的 
IP
 地址，
DNS
 解析確實(shí)沒(méi)有問(wèn)題，能夠正常解析。不過(guò)，正常的情況下 Pod 中 DNS 配置的服務(wù)器地址一般是 CoreDNS 的 Service 地址，不直接綁定 Pod IP（因?yàn)?Pod 每次重啟 IP 都會(huì)發(fā)生變化）。 所以問(wèn)題找到了，正是在 Pod 向 CoreDNS 的 Service "kube-dns" 進(jìn)行域名解析請(qǐng)求轉(zhuǎn)發(fā)時(shí)，出現(xiàn)了問(wèn)題，一般 
Service
 的問(wèn)題都跟 
Kube-proxy
 組件有關(guān)，接下來(lái)觀察該組件是否存在問(wèn)題。

7、分析 Kube-Proxy 是否存在問(wèn)題
觀察 Kube-proxy 的日志，查看是否存在問(wèn)題：

## 查看 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

## 選擇一個(gè) kube-proxy Pod，查看最后 5 條日志內(nèi)容
$ 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]
通過(guò) kube-proxy Pod 的日志可以看到，里面有很多 Error 級(jí)別的日志信息，根據(jù)關(guān)鍵字 
IPVS
、
parseIP Error
 可知，可能是由于 IPVS 模塊對(duì) IP 進(jìn)行格式化導(dǎo)致出現(xiàn)問(wèn)題。

因?yàn)檫@個(gè)問(wèn)題是升級(jí)到 kubernetes 1.18 版本才出現(xiàn)的，所以去 Kubernetes Github 查看相關(guān) issues，發(fā)現(xiàn)有人在升級(jí) Kubernetes 版本到 1.18 后，也遇見(jiàn)了相同的問(wèn)題，經(jīng)過(guò) issue 中 Kubernetes 維護(hù)人員討論，分析出原因可能為新版 Kubernetes 使用的 IPVS 模塊是比較新的，需要系統(tǒng)內(nèi)核版本支持，本人使用的是 CentOS 系統(tǒng)，內(nèi)核版本為 3.10，里面的 IPVS 模塊比較老舊，缺少新版 Kubernetes IPVS 所需的依賴。

根據(jù)該 issue 討論結(jié)果，解決該問(wèn)題的辦法是，更新內(nèi)核為新的版本。

注：該 issues 地址為 https://github.com/kubernetes/kubernetes/issues/89520

四、解決問(wèn)題
1、升級(jí)系統(tǒng)內(nèi)核版本
升級(jí) Kubernetes 集群各個(gè)節(jié)點(diǎn)的 CentOS 系統(tǒng)內(nèi)核版本：

## 載入公鑰
$ 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

## 查看系統(tǒng)可用內(nèi)核
$ 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 ...（略）

## 設(shè)置開(kāi)機(jī)從新內(nèi)核啟動(dòng)
$ grub2-set-default "CentOS Linux (4.4.218-1.el7.elrepo.x86_64) 7 (Core)"

## 查看內(nèi)核啟動(dòng)項(xiàng)
$ grub2-editenv list
saved_entry=CentOS Linux (4.4.218-1.el7.elrepo.x86_64) 7 (Core)
重啟系統(tǒng)使內(nèi)核生效：

$ reboot
啟動(dòng)完成查看內(nèi)核版本是否更新：

$ uname -r

4.4.218-1.el7.elrepo.x86_64
2、測(cè)試 Pod 中 DNS 是否能夠正常解析
進(jìn)入 Pod 內(nèi)部使用 ping 命令測(cè)試 DNS 是否能正常解析：

## 進(jìn)入 dnsutils Pod 內(nèi)部 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 集群內(nèi)部 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 中的域名解析已經(jīng)恢復(fù)正常。

pod ping 不通node

環(huán)境說(shuō)明

pod ---> router--->svc---redis pod

namesapce 1 的pod 訪問(wèn)不了router 訪問(wèn)拒絕

原因： apiserver 重啟導(dǎo)致sdn重啟，防火墻策略沒(méi)有生效，重啟防火墻后解決

分享到：
標(biāo)簽：k8s
用戶無(wú)頭像

網(wǎng)友整理

注冊(cè)時(shí)間：

網(wǎng)站：5 個(gè)   小程序：0 個(gè)  文章：12 篇

  • 51998

    網(wǎng)站

  • 12

    小程序

  • 1030137

    文章

  • 747

    會(huì)員

趕快注冊(cè)賬號(hào)，推廣您的網(wǎng)站吧！
最新入駐小程序

數(shù)獨(dú)大挑戰(zhàn)2018-06-03

數(shù)獨(dú)一種數(shù)學(xué)游戲，玩家需要根據(jù)9

答題星2018-06-03

您可以通過(guò)答題星輕松地創(chuàng)建試卷

全階人生考試2018-06-03

各種考試題，題庫(kù)，初中，高中，大學(xué)四六

運(yùn)動(dòng)步數(shù)有氧達(dá)人2018-06-03

記錄運(yùn)動(dòng)步數(shù)，積累氧氣值。還可偷

每日養(yǎng)生app2018-06-03

每日養(yǎng)生,天天健康

體育訓(xùn)練成績(jī)?cè)u(píng)定2018-06-03

通用課目體育訓(xùn)練成績(jī)?cè)u(píng)定