毫無疑問，Kubernetes 是個(gè)偉大的開源作品，給作者所在團(tuán)隊(duì)中極大地提高了生產(chǎn)力，但在使用過程中，相信很多人跟作者一樣，會遇到各種各樣的問題，有時(shí)候解決的過程也是非常享受，某些問題還可能反復(fù)遇到。本篇文章記錄了本人在使用開始接觸 Kubernetes 至今遇到的各類問題及解決方案, 希望對其它同學(xué)有所幫助。

不定期更新

CRD spec.versions: Invalid value

原因: CRD yaml 文件中 apiVersion 與 versions 中的版本不對應(yīng)

參考: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/

刪除 namespaces 時(shí) Terminating，無法強(qiáng)制刪除且無法在該 ns 下創(chuàng)建對象

原因: ns 處于 terminating 時(shí) hang 住了，使用 --grace-period=0 --force 強(qiáng)制刪除也無效

解決:

# 導(dǎo)出K8s訪問密鑰
echo $(kubectl config view --raw -oyaml | grep client-cert  |cut -d ' ' -f 6) |base64 -d > /tmp/client.pem
echo $(kubectl config view --raw -oyaml | grep client-key-data  |cut -d ' ' -f 6 ) |base64 -d > /tmp/client-key.pem
echo $(kubectl config view --raw -oyaml | grep certificate-authority-data  |cut -d ' ' -f 6  ) |base64 -d > /tmp/ca.pem
# 解決namespace Terminating，根據(jù)實(shí)際情況修改<namespaces>
curl --cert /tmp/client.pem --key /tmp/client-key.pem --cacert /tmp/ca.pem -H "Content-Type: application/json" -X PUT --data-binary @/tmp/temp.json https://xxx.xxx.xxx.xxx:6443/api/v1/namespaces/<namespaces>/finalize

Docker 啟動時(shí)提示 no sockets found via socket activation

解決: 在啟動 Docker 前先執(zhí)行 systemctl unmask Docker.socket 即可

Prometheus opening storage failed: invalid block sequence

原因: 這個(gè)需要排查 Prometheus 持久化目錄中是否存在時(shí)間超出設(shè)置閾值的時(shí)間段的文件，刪掉后重啟即可

Kubelet 提示: The node was low on resource: ephemeral-storage

原因: 節(jié)點(diǎn)上 Kubelet 的配置路徑超過閾值會觸發(fā)驅(qū)逐，默認(rèn)情況下閾值是 85%

解決: 或者清理磁盤釋放資源，或者通過可修改 Kubelet 的配置參數(shù)imagefs.available來提高閾值,然后重啟 Kubelet.

參考: https://cloud.tencent.com/developer/article/1456389

kubectl 查看日志時(shí)提示: Error from server: Get https://xxx:10250/containerLogs/spring-prod/xxx-0/xxx: dial tcp xxx:10250: i/o timeout

原因: 目地機(jī)器的 iptables 對 10250 這個(gè)端口進(jìn)行了 drop，如下圖

iptables-save -L INPUT –-line-numbers

解決: 刪除對應(yīng)的規(guī)則

iptables -D INPUT 10

Service 解析提示 Temporary failure in name resolution

原因: 出現(xiàn)這種情況很奇怪，現(xiàn)象顯示就是域名無法解析，全格式的域名能夠解析是因?yàn)樵?pod 的/etc/hosts 中有全域名的記錄,那么問題就出在于 CoreDNS 解析上，CoreDNS 從日志來看，沒有任何報(bào)錯(cuò)，但是從 pod 的狀態(tài)來看，雖然處于 Running 狀態(tài)，但是 0/1 可以看出 CoreDNS 并未處于 ready 狀態(tài).

可以查看 ep 記錄，會發(fā)現(xiàn) Endpoint 那一欄是空的，這也就證實(shí)了 K8s 把 CoreDNS 的狀態(tài)分為了 notready 狀態(tài)，所以 ep 才沒有記錄，經(jīng)過與其它環(huán)境比較后發(fā)現(xiàn)跟配置有關(guān)，最終定位在 CoreDNS 的配置文件上,在插件上需要加上 ready

解決: 在 cm 的配置上添加 read 插件，如下圖

# ... 省略
data:
  Corefile: |
    .:53 {
        errors
        health
        ready  # 加上該行后問題解決
        kubernetes cluster.local in-addr.arpa ip6.arpa {
          pods insecure
          upstream /etc/resolv.conf
          fallthrough in-addr.arpa ip6.arpa
        }
       # ... 省略

關(guān)于 CoreDNS 的 ready 插件的使用,可以參考??這里

總結(jié)起來就是使用 ready 來表明當(dāng)前已準(zhǔn)備好可以接收請求，從 codedns 的 yaml 文件也可以看到有livenessProbe

使用 Kubectl 命令行時(shí)提示: Unable to connect to the server: x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0

原因: 這個(gè)跟本地的 go 環(huán)境有關(guān)

解決: 在使用 kubectl 前使用命令export GODEBUG=x509ignoreCN=0即可

namespaces "kube-system" is forbidden: this namespace may not be deleted

原因: kube-system 是集群中受保護(hù)的 ns, 被禁止刪除，主要是防止誤操作，如果需要?jiǎng)h除的話，可以使用 --force

參考: https://github.com/kubernetes/kubernetes/pull/62167/files

unknown field volumeClaimTemplates

原因: 提示這個(gè)錯(cuò)誤的原因是資源對象是 Deployment, 而 Deployment 本就是無狀態(tài)的， 所以也就沒有使用 pv 這一說法了，可以參考 api

參考: ??Deploymentspec-v1-apps

CoreDNS 提示 Loop (127.0.0.1:38827 -> :53) detected for zone "."

原因: CoreDNS 所在的宿主機(jī)上 /etc/resolv.conf 中存在有 127.0.xx 的 nameserver，這樣會造成解析死循環(huán)。

解決: 修改宿主機(jī) /etc/resolv.conf 或者將 CoreDNS 的 ConfigMap 中的 forward 修改為一個(gè)可用的地址, 如 8.8.8.8。

hostPath volumes are not allowed to be used

原因: 集群中存在 psp 禁止 pod 直接掛載 hostpath.

解決: 通過添加以下的 psp 規(guī)則來允許或者刪除存在的 psp 都可

apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
  name: auth-privilege-psp
spec:
  allowPrivilegeEscalation: true
  allowedHostPaths:
  - pathPrefix: /
  fsGroup:
    ranges:
    - max: 65535
      min: 1
    rule: RunAsAny
  hostNetwork: true
  hostPID: true
  hostPorts:
  - max: 9796
    min: 9796
  privileged: true
  requiredDropCapabilities:
  - ALL
  runAsUser:
    rule: RunAsAny
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    ranges:
    - max: 65535
      min: 1
    rule: RunAsAny
  volumes:
  - configMap
  - emptyDir
  - projected
  - secret
  - downwardAPI
  - persistentVolumeClaim
  - hostPath

container has runAsNonRoot and image has non-numeric user (grafana), cannot verify user is non-root

原因: 這是由于在 deploy 中設(shè)置了 securityContext: runAsNonRoot: true，在這種情況下，當(dāng) pod 啟動時(shí)，使用的默認(rèn)用戶。比如上面的 grafana，K8s 無法確定他是不是 root 用戶

解決: 指定 securityContext:runAsUser: 1000，隨便一個(gè) id 號即可，只要不是 0(0 代表 root)。

參考: https://stackoverflow.com/questions/51544003/using-runasnonroot-in-kubernetes

OCI runtime create failed: no such file or directory

原因: /var/lib/Kubelet/pod 下的數(shù)據(jù)目錄已經(jīng)損壞.

解決: 刪除對應(yīng)的目錄即可

鏡像拉取時(shí)出現(xiàn) ImageInspectError

原因: 這種情況下一般都是鏡像損壞了

解決: 把相關(guān)的鏡像刪除后重新拉取

Kubelet 日志提示: node not found

原因: 這個(gè)報(bào)錯(cuò)只是中間過程，真正的原因在于 apiserver 沒有啟動成功，導(dǎo)致會一直出現(xiàn)這個(gè)錯(cuò)誤

解決: 排查 Kubelet 與 apiserver 的連通是否正常

OCI runtime create failed: executable file not found in PATH

原因: 在 path 中沒有 nvidia-container-runtime-hook 這個(gè)二進(jìn)制文件，可能跟本人刪除 nvidia 顯卡驅(qū)動有關(guān).

解決: nvidia-container-runtime-hook 是 Docker nvidia 的 runtime 文件，重新安裝即可.

Nginx Ingress Empty address

# kubectl get ingress
NAME         HOSTS                                       ADDRESS   PORTS   AGE
Prometheus   Prometheus.1box.com                                   80      31d

會發(fā)現(xiàn) address 中的 ip 是空的，而查看生產(chǎn)環(huán)境時(shí)卻是有 ip 列表的.

原因: 這個(gè)其實(shí)不是一個(gè)錯(cuò)誤，也不影響使用，原因在于測試環(huán)境中是不存在 LoadBalancer 類型的 svc, 如果需要 address 中顯示 ip 的話需要做些額外的設(shè)置

解決:

1. 在 nginx controller 的容器中指定啟動參數(shù)-report-ingress-status
2. 在 nginx controller 引用的 ConfigMap 中添加external-status-address: "10.164.15.220"

這樣的話,在 address 中變會顯示 10.164.15.220 了

參考:

https://github.com/nginxinc/kubernetes-ingress/issues/587

https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/reporting-resources-status/

Kubelet: but volume paths are still present on disk

原因: 這種 pod 已經(jīng)被刪除了，但是 volume 還存在于 disk 中

解決: 刪除對應(yīng)的目錄/var/lib/Kubelet/pods/3cd73...

參考: https://github.com/longhorn/longhorn/issues/485

PLEG is not healthy

原因: 宿主機(jī)上面跑的容器太多，導(dǎo)致 pod 無法在 3m 鐘內(nèi)完成生命周期檢查

解決: PLEG(Pod Lifecycle Event Generator) 用于 kublet 同步 pod 生命周期，本想著如果是因?yàn)闀r(shí)間短導(dǎo)致的超時(shí)，那是不是可以直接調(diào)整這個(gè)時(shí)間呢? 查看 Kubelet 的源碼發(fā)現(xiàn)不太行，3m 時(shí)間是寫在代碼里的因此無法修改，當(dāng)然修改再編譯肯定沒問題，但成本太大，所以只得優(yōu)化容器的調(diào)度情況.

參考: https://developers.redhat.com/blog/2019/11/13/pod-lifecycle-event-generator-understanding-the-pleg-is-not-healthy-issue-in-kubernetes/

metrics-server: 10255 connection refused

unable to fully collect metrics: [unable to fully scrape metrics from source Kubelet_summary:K8s-node-49: unable to fetch metrics from Kubelet K8s-node-49 (xxx.xxx.xxx.49): Get http://xxx.xxx.xxx.49:10255/stats/summary?only_cpu_and_memory=true: dial tcp xxx.xxx.xxx.49:10255: connect: connection refused

原因: 現(xiàn)在的 K8s 都默認(rèn)禁用了 Kubelet 的 10255 端口，出現(xiàn)這個(gè)錯(cuò)誤是因此在 Kubelet 啟動命令中啟用了該端口

解決: 將 - --Kubelet-port=10255 注釋

metrics-server: no such host

unable to fetch metrics from Kubelet K8s-node-234 (K8s-node-234): Get https://K8s-node-234:10250/stats/summary?only_cpu_and_memory=true: dial tcp: lookup K8s-node-234 on 10.96.0.10:53: no such host

解決: 使用 Kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP 參數(shù)

參考: https://github.com/kubernetes-sigs/metrics-server/blob/master/README.md

pod 無法解析域名

集群中新增了幾臺機(jī)器用于部署 clickhouse 用于做大數(shù)據(jù)分析，為了不讓這類占用大量資源的 Pod 影響其它 Pod，因此選擇給機(jī)器打 taint 的形式控制該類 Pod 的調(diào)度, 創(chuàng)建 Pod 后發(fā)現(xiàn)這些 Pod 都會出現(xiàn) DNS 解析異常,

原因；要注意容器網(wǎng)絡(luò)，比如這里使用的是 flannel 是否容忍了這些機(jī)器的 taint，不然的話，flannel 是無法被調(diào)度到這些機(jī)器的,因此容器間的通信會出現(xiàn)問題，可以將類似 flannel 這些的基礎(chǔ) POD 容忍所有的 NoScheule 與 NoExecute

解決: flannel 的 ds yaml 中添加以下 toleration，這樣適用任何的場景

      tolerations:
      - effect: NoSchedule
        operator: Exists
      - effect: NoExecute
        operator: Exists

Are you tring to mount a directory on to a file

原因: Yaml 文件中使用了 subPath, 但是 mountPath 指向了一個(gè)目錄

解決: mountPath 需要加上文件名

Kubernetes 啟動后提示 slice: no such file ro directory

原因: yum 安裝的 Kubelet 默認(rèn)的是 cgroupfs，而 Docker 一般默認(rèn)的是 systemd。但是 kubernetes 安裝的時(shí)候建議使用 systemd, Kubelet 跟 Docker 的不一致, 要么修改 Kubelet 的啟動參數(shù) , 要么修改 dokcer 啟動參數(shù)

解決:

• Docker 的啟動參數(shù)文件為: /etc/Docker/daemon.json: "exec-opts": ["native.cgroupdriver=systemd”]
• Kubelet 的啟動參數(shù)文件為: /var/lib/Kubelet/config.yaml: cgroupDriver: systemd

"cni0" already has an IP address different from xxx.xxxx.xxx.xxx

原因: 使用 kubeadm reset 重復(fù)操作過, reset 之后，之前 flannel 創(chuàng)建的 bridge device cni0 和網(wǎng)口設(shè)備 flannel.1 依然健在

解決: 添加之前需要清除下網(wǎng)絡(luò)

kubeadm reset
systemctl stop Kubelet
systemctl stop Docker
rm -rf /var/lib/cni/
rm -rf /var/lib/Kubelet/*
rm -rf /etc/cni/
ifconfig cni0 down
ifconfig flannel.1 down
ifconfig Docker0 down
ip link delete cni0
ip link delete flannel.1
systemctl start Docker
systemctl start Kubelet

kubeadm 初始化時(shí)提示 CPU 小于 2

[preflight] Running pre-flight checks
error execution phase preflight: [preflight] Some fatal errors occurred:
    [ERROR NumCPU]: the number of available CPUs 1 is less than the required 2
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`

原因: kubeadm 對資源一定的要求，如果是測試環(huán)境無所謂的話,可忽略

解決:

使用 --ignore-preflight-errors 忽略

Unable to update cni config: no network found

原因: 還未部署網(wǎng)絡(luò)插件容器，導(dǎo)致在 /etc/cni 下還沒有文件

解決: 根據(jù)實(shí)際情況部署網(wǎng)絡(luò)插件

while reading 'google-Dockercfg' metadata

原因: 從其它機(jī)器訪問上述這些 url 確實(shí)出現(xiàn) 404

解決: 由于是在 RKE 上部署 K8s, 所以可能會去訪問 google 相關(guān)的 url, 不影響業(yè)務(wù),可以忽略

no providers available to validate pod request

原因: 在 api-server 的啟動參數(shù) enable-admission 中設(shè)置了 PodSecrityPolicy, 但是集群中又沒有任何的 podsecritypolicy，因此導(dǎo)致整個(gè)集群都無法新建出 pod

解決: 刪除相應(yīng)的 podsecritypolicy 即可

unable to upgrade connection: Unauthorized

原因: Kubelet 的啟動參數(shù)少了 x509 認(rèn)證方式

解決: 配置證書的路徑, 加上重啟 Kubelet 即可

kubectl get cs 提示<unknown>

原因: 這是個(gè) kubectl 的 bug, 跟版本相關(guān)，kubernetes 有意廢除 get cs 命令

解決: 目前對集群的運(yùn)行無影響, 可通過加 -o yaml 查看狀態(tài)

安裝 kubeadm 時(shí)提示 Depends 錯(cuò)誤

原因: 跟 kubeadm 沒多大關(guān)系, 系統(tǒng)安裝的有問題

解決: 執(zhí)行以下命令修復(fù)

apt --fix-broken install
apt-get update

訪問 service 時(shí)提示 Connection refused

現(xiàn)象: 從另一環(huán)境中把 yaml 文件導(dǎo)入到新環(huán)境后有些 service 訪問不通

telnet mongodb-mst.external 27017
Trying 10.97.135.242...
telnet: Unable to connect to remote host: Connection refused

首先排除了域名、端口的配置問題。

會發(fā)現(xiàn)提示連接拒絕.可以確定的是集群內(nèi)的 DNS 是正常的.

那么就是通過 clusterIP 無法到達(dá) realserver. 查看 iptables 規(guī)則

發(fā)現(xiàn)提示default has no Endpoints --reject-with icmp-port-unreachable

很奇怪, 提示沒有 Endpoints, 但是使用kubectl get ep又能看到 ep 存在且配置沒有問題

而且這個(gè) default 是怎么來的.

為了方便部署, 很多配置是從別的環(huán)境導(dǎo)出的配置, 有些 service 訪問是沒問題的, 只有少部分 connection refused。

結(jié)比一下發(fā)現(xiàn)一個(gè)很有趣的問題，先來看下不正常的 yaml 文件:

由于服務(wù)在集群外部署的, 因此這里使用了 subset 方式, 開始懷疑問題在這里, 但是后來知道這個(gè)不是重點(diǎn)

乍一看這個(gè)配置沒什么問題, 部署也很正常, 但是對比正常的 yaml 文件，發(fā)現(xiàn)一個(gè)區(qū)別：

如果在 services 中的端口指定了名字, 那么在 subsets 中的端口也要帶名字, 沒有帶名字的就會出現(xiàn) connection refused，這個(gè)確實(shí)之前從來沒有關(guān)注過, 一個(gè)端口的情況下也不會指定名字

而且這面 iptalbes 中提示的 default 剛好就是這里的 port name,雖然不敢相信，但是也只能試一試這個(gè)方法: 在 subsets 中也加了 port name

重新部署一個(gè)，再次查看 iptalbes 規(guī)則

iptables-save|grep mongodb-mst

OMG, 居然可行, 再看下 telnet 的結(jié)果:

Trying 10.105.116.92...
Connected to mongodb-mst.external.svc.cluster.local.
Escape character is '^]'.

訪問也是沒問題, 那么原因就在于:

在 service 中指定了 port name 時(shí), 也需要在 ep 中指定 port name

error converting fieldPath: field label not supported

今天遇到一個(gè)部署 Deployment 出錯(cuò)的問題, yaml 文件如下:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-Deployment
  namespace: 4test
  labels:
    app: config-demo-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: config-demo-app
  template:
    metadata:
      labels:
        app: config-demo-app
      annotations:
        # The field we'll use to couple our ConfigMap and Deployment
        configHash: 4431f6d28fdf60c8140d28c42cde331a76269ac7a0e6af01d0de0fa8392c1145
    spec:
      containers:
      - name: config-demo-app
        image: gcr.io/optimum-rock-145719/config-demo-app
        ports:
        - containerPort: 80
        envFrom:
        # The ConfigMap we want to use
        - configMapRef:
            name: demo-config
        # Extra-curricular: We can make the hash of our ConfigMap available at a
        # (e.g.) debug Endpoint via a fieldRef
        env:
        - name: CONFIG_HASH
          #value: "4431f6d28fdf60c8140d28c42cde331a76269ac7a0e6af01d0de0fa8392c1145"
          valueFrom:
            fieldRef:
              fieldPath: spec.template.metadata.annotations.configHash

提示以下錯(cuò)誤:

會提示 Unsupported value:spec.template.metadata.annotations.configHash。

目的很簡單: container 中的環(huán)境變量中引用 configHash 變量, 這個(gè)值是當(dāng) ConfigMap 變更時(shí)比對兩個(gè)不同的 sha 值以此達(dá)到重啟 pod 的目的, 但 fieldPath 顯然不支持 spec.template.metadata.annotations.configHash。

從報(bào)錯(cuò)提示來看, 支持列表有 metadata.name, metadata.namespace, metadata.uid, spec.nodeName,spec.serviceAccountName, status.hostIp, status.PodIP, status.PodIPs。

這些值用于容器中需要以下信息時(shí)可以不從 K8s 的 apiserver 中獲取而是可以很方便地從這些變量直接獲得。

參考:

• https://www.magalix.com/blog/kubernetes-patterns-the-reflection-pattern
• https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/

參考文章:

• https://www.ibm.com/docs/en/cloud-private/3.2.0?topic=console-namespace-is-stuck-in-terminating-state
• https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/
• https://github.com/kubernetes/kubernetes/issues/19317
• http://www.xuyasong.com/?p=1725
• https://kubernetes.io/
• https://fuckcloudnative.io/
• https://www.cnblogs.com/breezey/p/8810039.html
• https://ieevee.com/tech/2018/04/25/downwardapi.html
• https://www.magalix.com/blog/kubernetes-patterns-the-reflection-pattern
• https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#Deploymentspec-v1-apps
• https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/
• https://github.com/kubernetes/kubernetes/pull/62167/files
• https://github.com/kubernetes-sigs/metrics-server/blob/master/README.md