UK8S 集群常見問題容器云 UK8S

ernest.wang 發布于2022-07-12 17:25 / 2921人閱讀

摘要：為什么在節點直接起容器網絡不通為什么在節點直接起容器網絡不通為什么在節點直接起容器網絡不通使用自己的插件，而直接用起的容器并不能使用該插件，因此網絡不通。

UK8S 集群常見問題

本篇目錄

1. UK8S 完全兼容原生 Kubernetes API嗎？2. UK8S 人工支持 3. UK8S對Node上發布的容器有限制嗎？如何修改？4. 為什么我的容器一起來就退出了？5. Docker 如何調整日志等級 6. 為什么節點已經異常了，但是 Pod 還處在 Running 狀態 7. 節點宕機了 Pod 一直卡在 Terminating 怎么辦 8. Pod 異常退出了怎么辦？9. CNI 插件升級為什么失敗了？10. UK8S 頁面概覽頁一直刷新不出來？11. UK8S 節點 NotReady 了怎么辦 12. 為什么我的集群連不上外網?13. 為什么在 K8S 節點 Docker 直接起容器網絡不通 14. 使用 ULB4 時 Vserver 為什么會有健康檢查失效 15. ULB4 對應的端口為什么不是 NodePort 的端口 16. 我想在刪除LoadBalancer類型的Service并保留EIP該怎么操作？17. Pod 的時區問題 18. kubectl top 命令報錯 19. containerd-shim進程泄露 20. 1.19.5 集群kubelet連接containerd失敗

1. UK8S 完全兼容原生 Kubernetes API嗎？

完全兼容。

2. UK8S 人工支持

對于使用 UK8S 遇到的本文檔未涉及的問題，如果需要人工支持，請提供主機的 uhost-id，并添加公鑰信任，將下面內容添加到ssh配置文件authorized_keys中。

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDGIFVUtrp+jAnIu1fBvyLx/4L4GNsX+6v8RodxM+t3G7gCgaG+kHqs1xkLBWQNNMVQz2c/vA1gMNYASnvK/aQJmI9NxuOoaoqbL/yrZ58caJG82TrDKGgByvAYcT5yJkJqGRuLlF3XL1p2C0P8nxf2dzfjQgy5LGvZ1awEsIeoSdEuicaxFoxkxzTH/OM2WSLuJ+VbFg8Xl0j3F5kP9sT/no1Gau15zSHxQmjmpGJSjiTpjSBCm4sMaJQ0upruK8RuuLAzGwNw8qRXJ4qY7Tvg36lu39KHwZ22w/VZT1cNZq1mQXvsR54Piaix163YoXfS7jke6j8L6Nm2xtY4inqd uk8s-tech-support

3. UK8S對Node上發布的容器有限制嗎？如何修改？

UK8S 為保障生產環境 Pod 的運行穩定，每個 Node 限制了 Pod 數量為 110 個，用戶可以通過登陸 Node 節點"vim /etc/kubernetes/kubelet.conf" 修改 maxpods:110，然后執行 systemctl restart kubelet 重啟 kubelet 即可。

4. 為什么我的容器一起來就退出了？

查看容器log，排查異常重啟的原因pod是否正確設置了啟動命令，啟動命令可以在制作鏡像時指定，也可以在pod配置中指定啟動命令必須保持在前臺運行，否則k8s會認為pod已經結束，并重啟pod。

5. Docker 如何調整日志等級

修改/etc/docker/daemon.json 文件，增加一行配置"debug": truesystemctl reload docker 加載配置，查看日志如果不再需要查看詳細日志，刪除debug配置，重新reload docker即可

6. 為什么節點已經異常了，但是 Pod 還處在 Running 狀態

這是由于k8s的狀態保護造成的，在節點較少或異常節點很多的情況下很容易出現具體可以查看文檔 https://kubernetes.io/zh/docs/concepts/architecture/nodes/#reliability

7. 節點宕機了 Pod 一直卡在 Terminating 怎么辦

節點宕機超過一定時間后（一般為 5 分鐘），k8s 會嘗試驅逐 pod，導致 pod 變為 Terminating 狀態由于此時 kubelet 無法執行刪除pod的一系列操作，pod 會一直卡在 Terminating類型為 daemonset 的 pod，默認在每個節點都有調度，因此 pod 宕機不需要考慮此種類型 pod，k8s 也默認不會驅逐該類型的 pod類型為 depolyment 和 replicaset 的 pod，當 pod 卡在 termanting 時，控制器會自動拉起對等數量的 pod類型為 statefulset 的 pod，當 pod 卡在 termanting 時，由于 statefulset 下屬的 pod 名稱固定，必須等上一個 pod 徹底刪除，對應的新 pod 才會被拉起，在節點宕機情況下無法自動拉起恢復對于使用 udisk-pvc 的 pod，由于 pvc 無法卸載，會導致新起的 pod 無法運行，請按照本文 pvc 相關內容(#如何查看pvc對應的udisk實際掛載情況)，確認相關關系

8. Pod 異常退出了怎么辦？

kubectl describe pods pod-name -n ns 查看 pod 的相關 event 及每個 container 的 status，是 pod 自己退出，還是由于 oom 被殺，或者是被驅逐如果是 pod 自己退出，kubectl logs pod-name -p -n ns 查看容器退出的日志，排查原因如果是由于 oom 被殺，建議根據業務重新調整 pod 的 request 和 limit 設置（兩者不宜相差過大），或檢查是否有內存泄漏如果 pod 被驅逐，說明節點壓力過大，需要檢查時哪個 pod 占用資源過多，并調整 request 和 limit 設置非 pod 自身原因導致的退出，需要執行dmesg查看系統日志以及journalctl -u kubelet查看 kubelet 相關日志。

9. CNI 插件升級為什么失敗了？

檢查節點是否設置了污點及禁止調度（master 節點的默認污點不計算在內），帶有污點的節點需要選擇強制升級（不會對節點有特殊影響）。如果強制升級失敗的，請重新點擊 cni 強制升級。執行kubectl get pods -n kube-system |grep plugin-operation找到對應插件升級的 pod，并 describe pod 查看 pod 失敗原因。

10. UK8S 頁面概覽頁一直刷新不出來？

api-server 對應的 ulb4 是否被刪除（uk8s-xxxxxx-master-ulb4）UK8S 集群的三臺 master 主機是否被刪了或者關機等登陸到 UK8S 三臺 master 節點，檢查 etcd 和 kube-apiserver 服務是否正常，如果異常，嘗試重啟服務3.1 systemctl status etcd / systemctl restart etcd 如果單個 etcd 重啟失敗，請嘗試三臺節點的 etcd 同時重啟3.2 systemctl status kube-apiserver / systemctl restart kube-apiserver

11. UK8S 節點 NotReady 了怎么辦

kubectl describe node node-name 查看節點 notReady 的原因，也可以直接在 console 頁面上查看節點詳情。如果可以登陸節點，journalctl -u kubelet 查看 kubelet 的日志， system status kubelet查看 kubelet 工作是否正常。對于節點已經登陸不了的情況，如果希望快速恢復可以在控制臺找到對應主機斷電重啟。查看主機監控，或登陸主機執行sar命令，如果發現磁盤 cpu 和磁盤使用率突然上漲, 且內存使用率也高，一般情況下是內存 oom 導致的。關于內存占用過高導致節點宕機，由于內存占用過高，磁盤緩存量很少，會導致磁盤讀寫頻繁，進一步增加系統負載，打高cpu的惡性循環內存 oom 的情況需要客戶自查是進程的內存情況，k8s 建議 request 和 limit 設置的值不宜相差過大，如果相差較大，比較容易導致節點宕機。如果對節點 notready 原因有疑問，請按照UK8S人工支持聯系人工支持

12. 為什么我的集群連不上外網?

UK8S 使用 VPC 網絡實現內網互通，默認使用了 UCloud 的 DNS，wget 獲取信息需要對 VPC 的子網配置網關，需要在 UK8S 所在的區域下進入VPC產品，對具體子網配置 NAT 網關，使集群節點可以通過 NAT 網關拉取外網數據，具體操作詳見VPC創建NAT網關。

13. 為什么在 K8S 節點 Docker 直接起容器網絡不通

UK8S 使用 UCloud 自己的 CNI 插件，而直接用 Docker 起的容器并不能使用該插件，因此網絡不通。如果需要長期跑任務，不建議在 UK8S 節點用 Docker 直接起容器，應該使用 pod如果只是臨時測試，可以添加--network host 參數，使用 hostnetwork 的模式起容器

14. 使用 ULB4 時 Vserver 為什么會有健康檢查失效

如果 svc 的 externalTrafficPolicy 為 Local 時，這種情況是正常的，失敗的節點表示沒有運行對應的 pod需要在節點上抓包 tcpdump -i eth0 host 查看是否正常, ulb-ip 替換為 svc 對應的實際 ip查看節點上 kube-proxy 服務是否正常 systemctl status kube-proxy執行iptables -L -n -t nat |grep KUBE-SVC 及 ipvsadm -L -n查看轉發規則是否下發正常

15. ULB4 對應的端口為什么不是 NodePort 的端口

K8S 節點上對 ulb_ip+serviceport 的端口組合進行了 iptables 轉發，所以不走 nodeport如果有興趣，可以通過在節點上執行iptables -L -n -t nat 或者ipvsadm -L -n 查看對應規則

16. 我想在刪除LoadBalancer類型的Service并保留EIP該怎么操作？

修改 Service 類型，原 type: LoadBalancer 修改為 NodePort 或者 ClusterIP，再進行刪除 Service 操作，EIP 和 ULB 會保留。

因該操作 EIP 和 ULB 資源將不再受 UK8S 管理，所以需要手動至 ULB 和 EIP 頁面進行資源解綁和綁定。

17. Pod 的時區問題

在 Kubernetes 集群中運行的容器默認使用格林威治時間，而非宿主機時間。如果需要讓容器時間與宿主機時間一致，可以使用 "hostPath" 的方式將宿主機上的時區文件掛載到容器中。

大部分linux發行版都通過 "/etc/localtime" 文件來配置時區，我們可以通過以下命令來獲取時區信息：

# ls -l /etc/localtime
lrwxrwxrwx. 1 root root 32 Oct 15  2015 /etc/localtime -> ../usr/share/zoneinfo/Asia/Shanghai

通過上面的信息，我們可以知道宿主機所在的時區為Asia/Shanghai，下面是一個Pod的yaml范例，說明如何將容器內的時區配置更改為Asia/Shanghai，和宿主機保持一致。

apiVersion: app/v1
kind: Pod
metadata:
 name: nginx
 labels:
   name: nginx
spec:
    containers:
    - name: nginx
      image: nginx
      imagePullPolicy: "IfNotPresent"
      resources:
        requests:
          cpu: 100m
          memory: 100Mi
      ports:
         - containerPort: 80
      volumeMounts:
      - name: timezone-config
        mountPath: /etc/localtime
    volumes:
      - name: timezone-config
        hostPath:
           path: /usr/share/zoneinfo/Asia/Shanghai

如果容器之前已經創建了，只需要在 yaml 文件中加上 volumeMounts 及 volumes 參數，再使用 kubectl apply 命令更新即可。

18. kubectl top 命令報錯

該情況一般有以下兩種可能

kube-system下面metrics-server Pod沒有正常工作，可以通過kubectl get pods -n kube-system進行查看metrics.k8s.io API地址被錯誤重定向，可以執行kubectl get apiservice v1beta1.metrics.k8s.io查看重定向到的service名稱，并確認service當前是否可用及是否對外暴露了v1beta1.metrics.k8s.io接口。默認重定向地址為kube-system/metrics-server

情況二一般出現在部署prometheus，且prometheus提供的接口不支持v1beta1.metrics.k8s.io時。如果不需要自定義HPA指標，其實不需要此重定向操作。如果屬于情況二，可以按照下面步驟操作。

確認配置中的的prometheus service可用，并根據需要自定義HPA指標重新部署執行下面yaml文件，回退到普通metrics server，Grafana等不依賴此api。注意，如果您之前已經使用了自定義HPA指標，且處于線上環境，建議您僅確認prometheus service可用即可。回退到普通metrics server可能導致之前的自定義HPA指標失效，請謹慎操作。

apiVersion: apiregistration.k8s.io/v1beta1
kind: APIService
metadata:
  name: v1beta1.metrics.k8s.io
spec:
  service:
    name: metrics-server
    namespace: kube-system
  group: metrics.k8s.io
  version: v1beta1
  insecureSkipTLSVerify: true
  groupPriorityMinimum: 100
  versionPriority: 100

19. containerd-shim進程泄露

目前發現使用docker的k8s集群，有可能會遇到containerd-shim進程泄露，尤其是在頻繁創建刪除Pod或者Pod頻繁重啟的情況下。此時甚至有可能導致docker inspect某個容器卡住進一步導致kubelet PLEG timeout 異常。此時以coredns Pod為例，說明如何查看是否存在containerd-shim進程泄露。如下示例，正常情況下，一個containerd-shim進程會有一個實際工作的子進程。子進程消失時，containerd-shim進程會自動退出。如果containerd-shim進程沒有子進程，則說明存在進程泄露。

遇到containerd-shim進程泄露的情況，可以按照如下方式進行處理

確認泄露的進程id，執行kill pid。注意，此時無需加-9參數，一般情況下簡單的kill就可以處理。確認containerd-shim進程退出后，可以觀察docker及kubelet是否恢復正常。注意，由于kubelet此時可能被docker卡住，阻擋了很多操作的執行，當docker恢復后，可能會有大量操作同時執行，導致節點負載瞬時升高，可以在操作前后分別重啟一遍kubelet及docker。

[root@xxxx ~]# docker ps |grep coredns-8f7c8b477-snmpq
ee404991798d   uhub.service.ucloud.cn/uk8s/coredns                        "/coredns -conf /etc…"   4 minutes ago   Up 4 minutes             k8s_coredns_coredns-8f7c8b477-snmpq_kube-system_26da4954-3d8e-4f67-902d-28689c45de37_0
b592e7f9d8f2   uhub.service.ucloud.cn/google_containers/pause-amd64:3.2   "/pause"                 4 minutes ago   Up 4 minutes             k8s_POD_coredns-8f7c8b477-snmpq_kube-system_26da4954-3d8e-4f67-902d-28689c45de37_0
[root@xxxx ~]# ps aux |grep ee404991798d
root       10386  0.0  0.2 713108 10628 ?        Sl   11:12   0:00 /usr/bin/containerd-shim-runc-v2 -namespace moby -id ee404991798d70cb9c3c7967a31b3bc2a50e56b072f2febf604004f5a3382ce2 -address /run/containerd/containerd.sock
root       12769  0.0  0.0 112724  2344 pts/0    S+   11:16   0:00 grep --color=auto ee404991798d
[root@xxxx ~]# ps -ef |grep 10386
root       10386       1  0 11:12 ?        00:00:00 /usr/bin/containerd-shim-runc-v2 -namespace moby -id ee404991798d70cb9c3c7967a31b3bc2a50e56b072f2febf604004f5a3382ce2 -address /run/containerd/containerd.sock
root       10421   10386  0 11:12 ?        00:00:00 /coredns -conf /etc/coredns/Corefile
root       12822   12398  0 11:17 pts/0    00:00:00 grep --color=auto 10386

20. 1.19.5 集群kubelet連接containerd失敗

在1.19.5集群中，有可能出現節點not ready的情況，查看kubelet日志，發現有大量Error while dialing dial unix:///run/containerd/containerd.sock相關的日志。這是1.19.5版本中一個已知bug，當遇到containerd重啟的情況下，kubelet會失去與containerd的連接，只有重啟kublet才能恢復。具體可以查看k8s官方issue。如果您遇到此問題，重啟kubelet即可恢復。同時目前uk8s集群已經不支持創建1.19.5版本的集群，如果您的集群版本為1.19.5，可以通過升級集群的方式，升級到1.19.10。

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/126974.html

【容器云UK8S】新手指導

摘要：詳細請見產品價格產品概念使用須知名詞解釋漏洞修復記錄集群節點配置推薦模式選擇產品價格操作指南集群創建需要注意的幾點分別是使用必讀講解使用需要賦予的權限模式切換的切換等。UK8S概覽UK8S是一項基于Kubernetes的容器管理服務，你可以在UK8S上部署、管理、擴展你的容器化應用，而無需關心Kubernetes集群自身的搭建及維護等運維類工作。了解使用UK8S為了讓您更快上手使用，享受UK...

Tecode 2022-06-28 19:00 評論0 收藏0
【容器云 UK8S】集群常見問題：UK8S創建Pod失敗，使用kubectl describe po

摘要：集群常見問題單個集群最多能添加多少個節點當前單個集群對應節點數量可查看集群節點配置推薦。創建失敗，使用發現報錯為，是啥原因在創建等資源時，都需要扮演云賬戶的身份調用來完成相關操作。集群內可以解析，但無法聯通外網拉取數據失敗。集群常見問題單個集群最多能添加多少個節點？A：當前單個UK8S集群對應節點數量可查看集群節點配置推薦。UK8S完全兼容原生Kubernetes API嗎？A：完全兼容。U...

Tecode 2022-06-28 19:00 評論0 收藏0
【容器云 UK8S】使用必讀：授權給UK8S云產品的管理權限、請勿隨意操作由UK8S創建的資源、請盡

摘要：會使用到以下產品的全部操作權限，例如代替你創建刪除云主機，由此產生的費用由你負責，請知悉。如何識別由創建的云資源由創建的云資源名稱，都遵循明確的命名規范，具體詳見命名規范簡要說明如下名稱，如名稱為的云主機，是這個集群的節點。容器云UK8S使用必讀注意：通過UK8S創建的云主機、云盤、EIP等資源，刪除資源請不要通過具體的產品列表頁刪除，否則可能導致UK8S運行不正常或數據丟失風險，可以通過U...

Tecode 2022-06-28 18:59 評論0 收藏0
【容器云 UK8S】操作指南：使用必讀之授權給UK8S云產品的管理權限，規避將業務部署在Master

摘要：注意通過創建的云主機云盤等資源，刪除資源請不要通過具體的產品列表頁刪除，否則可能導致運行不正常或數據丟失風險，可以通過將資源釋放或解綁刪除。會使用到以下產品的全部操作權限，例如代替你創建刪除云主機，由此產生的費用由你負責，請知悉。注意：通過UK8S創建的云主機、云盤、EIP等資源，刪除資源請不要通過具體的產品列表頁刪除，否則可能導致UK8S運行不正常或數據丟失風險，可以通過UK8S將資源釋放...

Tecode 2022-06-28 19:00 評論0 收藏0
【容器云 UK8S】產品簡介：產品概念、使用須知與名詞解釋

摘要：產品概念是一項基于的容器管理服務，你可以在上部署管理擴展你的容器化應用，而無需關心集群自身的搭建及維護等運維類工作。完全兼容原生的，以私有網絡為基礎，并整合了等云產品。其命名規范為。產品概念UCloud Container Service for Kubernetes （UK8S）是一項基于Kubernetes的容器管理服務，你可以在UK8S上部署、管理、擴展你的容器化應用，而無需關心Kub...

Tecode 2022-06-28 18:59 評論0 收藏0