最近k8s遇到的一些問題

OOM killed 內存溢出殺死,java堆溢出，找開發查 拉取鏡像失敗 節點測試手動拉取，重新docker login running ，但是不可用 ping，節點查看kubelet服務，異常，cordon掉，重啟服務 unkonwn ping，查看節點pod，節點查看docker kubelet服務，cordon掉重啟 NotReady ping，節點查看docker kubelet服務，cordon掉重啟 UnexpectedAdmissionError kubectl get pod -A |grep UnexpectedAdmissionError| awk '{printf("kubectl delete pod ",$1,"-n",namespace)}' | /bin/bash journalctl -u kubelet --nopager journalctl -xefu kubelet

statefuset pod存儲空間清理不釋放

磁盤空間滿了。有很多core.xxx的大文件，判斷為OOM產生。刪除了幾個，發現空間沒有變化，mv走，gzip壓縮空間都沒有釋放。刪除句柄lsof -n |grep delete |awk '{print $2}' | xargs kill -9 還是沒釋放。看目錄名字應該是statefulset服務。查詢statefulset確定綁定關系，進入pod清理，發現釋放了部分空間。但是之前在節點上的空間沒有釋放。清理數據，delete pod后空間釋放出來了。

k8s service訪問異常

上午做壓測，下午測試就不行了服務1訪問服務2拒絕。
查詢服務2兩個od，都是running狀態，監控顯示一個死掉了，另一個無法進入。嘗試重啟pod，依然無法訪問查看kube-dns，pod狀態running，進入pod手動配置域名解析，滿足臨時訪問。問題仍然在排查
后發現別的服務pod訪問上也不正常，查看deployment發現可用為0。

[root@master ~]# kubectl get deployment -nkube-system NAME READY UP-TO-DATE AVAILABLE AGE kube-dns 2/2 2 0 154d [root@master ~]# kubectl delete pod kube-dns-b75-whqnx

進入pod注釋掉之前的解析配置，nslookup服務名解析正常，解析其他服務正常

kubectl 集群切換

方法一 kubectl --kubeconfig .kube/config get node kubectl --kubeconfig ./config2 get node方法二 export KUBECONFIG=$HOME/.kube/config:$HOME/.kube/config2 kubectl config use-context cluster1 //user.name kubectl get node //config里集群的信息 cat .kube/config ... users: - name: cluster1

gluster 日志問題

一個節點的磁盤告警，對應的volume都會告警，進而影響到所有綁定這些volume的pod節點告警 查找方法 隨便進入一個節點 df -h 查看掛載的哪個volume,對應的IP。 gluster volume info | grep -C5 IP 查看組成volume的節點，分別查看每個節點的使用狀態。 找到達到告警要求的節點。清理磁盤的空間。如果需要清理的是volume里的空間。根據volume名，進入pod里刪除。

gluster的占用空間大

查看 .gluster 這個隱藏目錄使用的空間，刪除長期不使用的塊 find .gluster -type f -links l -atime +30 | xargs rm -f

gluster服務一起的pod pending

describe pod //發現 無法掛載到enpoints 查看enponits確定是gluster volume掛載 gluster peer status 發現有一臺 disconnect /etc/init.d/glusterfs-server start gluster peer status //檢查鏈接ok，稍等查看pod的狀態發現已經running 如果無法啟動gluster-server， 查看enpoints對應的gluster volume 服務，gluster volume info 服務名 ，確定volume組成的節點ip。 把enpoints的ip指向可以連接的那個，觀察pod的狀態，再去想辦法修復disconnect的節點，或者替換該節點的塊。

回滾deployment

kubectl rollout restart deployment test -n namespace 重啟

helm安裝顯示不支持apiVersion

[root@master ~]# helm install --dry-run test2 sensu Error: unable to build kubernetes objects from release manifest: unable to recognize "": no matches for kind "Deployment" in version "extensions/v1beta1"

查一下支持的apiVersion，修改

[root@master ~]# kubectl api-resources|grep deployment deployments deploy apps/v1 true Deployment [root@master ~]# grep -r kind sensu/ sensu/templates/deployment.yaml:kind: Deployment //修改這兩個 sensu/charts/redis/templates/deployment.yaml:kind: Deployment

修改完，測試，發現缺少 required field “selector”

[root@master ~]# helm install --dry-run test2 sensu Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: ValidationError(Deployment.spec): missing required field "selector" in io.k8s.api.apps.v1.DeploymentSpec

查看缺少的字段值，添加進去，

[root@master ~]# kubectl explain deployment.spec.selector [root@master ~]# vim sensu/templates/deployment.yaml ... spec:replicas: {{ .Values.replicaCount }} ####添加的是一下三行配置selector:matchLabels:app: {{ template "sensu.fullname" . }}

重新測試，ok

[root@master ~]# helm install --dry-run test2 sensu NAME: test2 LAST DEPLOYED: Mon May 2 10:20:30 2022

ingress發布出去的服務504 time out

查看服務ingress，查域名定位到vip 10.10.10.10，RIP： 10.10.10.11,10.10.10.12，也正是ingress-controller的節點機器，pod running狀態。 curl -v -H "www.baidu.com" 10.10.10.10 not ok curl -v -H "www.baidu.com" 10.10.10.11 not ok curl -v -H "www.baidu.com" 10.10.10.12 ok 查看10.10.10.11主機，vip在它上面，重啟它上面的ingress-controller后，服務訪問正常

防火墻問題服務504 time out

直接curl -v 顯示401報錯，需要登錄，在瀏覽器里登錄一下，并找到cookie（很長） curl -v -H "name" -H "cookie" pod ip：端口 #發現卡主了 進入容器，netstat，發現SYNSENT狀態的連接，說明連接發出沒有建立。/server # netstat Active Internet connections (w/o servers) Proto Recv-Q send-Q Local Address Foreign Address state tcp 0 0 server-pod-7553-rgmw0:35964 10.116.26.167:mysql ESTABLISHED tcp 1 0 server-pod-7553-rgmw0:8000 172.17.82.0:53484 CLOSE WA工T tcp 0 1 server-pod-7553-rgmw0:39026 172.30.75.45:http SYNSENT 卡主 tcp 0 / server # telnet 172.30.75.45 80 #telnet 果然不通 / server # ping 域名 #發現解析的正是這個ip，開完防火墻，服務就ok了 外網服務訪問不到 服務正常 排查一圈發現 ingress-controller 異常，ingress異常 重啟后訪問正常 證書重新設置后 服務無法正常訪問，部署未受影響，更新了所有節點的證書，重新部署了服務后正常 eks插件prometheus支持對外與入遠程段地址 http://10.244.15.82:9090/api/v1/write通過Remote write協議接入Prometheus監控數據

健康檢查的失敗pod一致重啟

k8s pod 啟動，容器始終處于running 0/1，最終因為健康檢查的失敗pod一直重啟。 首先，進入pod，查看服務的日志，發現沒有日志，感覺是entrypont沒有執行。 由于熟悉健康檢查的服務，直接對服務進行了啟動，此時服務正常了。但是約十分鐘，pod自動重啟了。 接下來看下來:詳細去看entrypoint。發現執行的是腳本，于是把腳本里的命令執行一遍，發現卡住了。 重啟pod，再次進入容器，ps一下，發現chmod進程卡主了，殺死這些卡主的進程后，pod running了。 但是這并沒有從根本上解決問題，date;chmod ..;date 統計了一下命令執行的時間，發現用時約5min。 由于是掛載的pvc，ping了一下pvc關聯的主機，發現時延30ms，這已經很大了，節點與他因為是跨ragion。 暫時的解決方案，增減了執行健康檢查等待的時間，長期的解決方案：遷移提供pvc的節點。

總結

以上是生活随笔為你收集整理的最近k8s遇到的一些问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。