資訊專欄INFORMATION COLUMN
摘要：為什么在節(jié)點直接起容器網(wǎng)絡不通為什么在節(jié)點直接起容器網(wǎng)絡不通為什么在節(jié)點直接起容器網(wǎng)絡不通使用自己的插件，而直接用起的容器并不能使用該插件，因此網(wǎng)絡不通。
完全兼容。
對于使用 UK8S 遇到的本文檔未涉及的問題，如果需要人工支持，請?zhí)峁┲鳈C的 uhost-id，并添加公鑰信任，將下面內(nèi)容添加到ssh配置文件authorized_keys中。
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDGIFVUtrp+jAnIu1fBvyLx/4L4GNsX+6v8RodxM+t3G7gCgaG+kHqs1xkLBWQNNMVQz2c/vA1gMNYASnvK/aQJmI9NxuOoaoqbL/yrZ58caJG82TrDKGgByvAYcT5yJkJqGRuLlF3XL1p2C0P8nxf2dzfjQgy5LGvZ1awEsIeoSdEuicaxFoxkxzTH/OM2WSLuJ+VbFg8Xl0j3F5kP9sT/no1Gau15zSHxQmjmpGJSjiTpjSBCm4sMaJQ0upruK8RuuLAzGwNw8qRXJ4qY7Tvg36lu39KHwZ22w/VZT1cNZq1mQXvsR54Piaix163YoXfS7jke6j8L6Nm2xtY4inqd uk8s-tech-supportUK8S 為保障生產(chǎn)環(huán)境 Pod 的運行穩(wěn)定，每個 Node 限制了 Pod 數(shù)量為 110 個，用戶可以通過登陸 Node 節(jié)點"vim /etc/kubernetes/kubelet.conf"
修改 maxpods:110，然后執(zhí)行 systemctl restart kubelet 重啟 kubelet 即可。
kubectl describe pods pod-name -n ns 查看 pod 的相關 event 及每個 container 的 status，是 pod 自己退出，還是由于
oom 被殺，或者是被驅(qū)逐如果是 pod 自己退出，kubectl logs pod-name -p -n ns 查看容器退出的日志，排查原因如果是由于 oom 被殺，建議根據(jù)業(yè)務重新調(diào)整 pod 的 request 和 limit 設置（兩者不宜相差過大），或檢查是否有內(nèi)存泄漏如果 pod 被驅(qū)逐，說明節(jié)點壓力過大，需要檢查時哪個 pod 占用資源過多，并調(diào)整 request 和 limit 設置非 pod 自身原因?qū)е碌耐顺觯枰獔?zhí)行dmesg查看系統(tǒng)日志以及journalctl -u kubelet查看 kubelet 相關日志。kubectl get pods -n kube-system |grep plugin-operation找到對應插件升級的 pod，并 describe pod 查看 pod
失敗原因。uk8s-xxxxxx-master-ulb4）UK8S 集群的三臺 master 主機是否被刪了或者關機等登陸到 UK8S 三臺 master 節(jié)點，檢查 etcd 和 kube-apiserver 服務是否正常，如果異常，嘗試重啟服務3.1 systemctl status etcd / systemctl restart etcd 如果單個 etcd 重啟失敗，請嘗試三臺節(jié)點的 etcd 同時重啟3.2 systemctl status kube-apiserver / systemctl restart kube-apiserverkubectl describe node node-name 查看節(jié)點 notReady 的原因，也可以直接在 console 頁面上查看節(jié)點詳情。如果可以登陸節(jié)點，journalctl -u kubelet 查看 kubelet 的日志， system status kubelet查看 kubelet 工作是否正常。對于節(jié)點已經(jīng)登陸不了的情況，如果希望快速恢復可以在控制臺找到對應主機斷電重啟。查看主機監(jiān)控，或登陸主機執(zhí)行sar命令，如果發(fā)現(xiàn)磁盤 cpu 和磁盤使用率突然上漲, 且內(nèi)存使用率也高，一般情況下是內(nèi)存 oom
導致的。關于內(nèi)存占用過高導致節(jié)點宕機，由于內(nèi)存占用過高，磁盤緩存量很少，會導致磁盤讀寫頻繁，進一步增加系統(tǒng)負載，打高cpu的惡性循環(huán)內(nèi)存 oom 的情況需要客戶自查是進程的內(nèi)存情況，k8s 建議 request 和 limit 設置的值不宜相差過大，如果相差較大，比較容易導致節(jié)點宕機。如果對節(jié)點 notready 原因有疑問，請按照UK8S人工支持聯(lián)系人工支持UK8S 使用 VPC 網(wǎng)絡實現(xiàn)內(nèi)網(wǎng)互通，默認使用了 UCloud 的 DNS，wget 獲取信息需要對 VPC 的子網(wǎng)配置網(wǎng)關，需要在 UK8S 所在的區(qū)域下進入VPC產(chǎn)品，對具體子網(wǎng)配置 NAT 網(wǎng)關，使集群節(jié)點可以通過 NAT 網(wǎng)關拉取外網(wǎng)數(shù)據(jù)，具體操作詳見VPC創(chuàng)建NAT網(wǎng)關 。
--network host 參數(shù)，使用 hostnetwork 的模式起容器tcpdump -i eth0 host 查看是否正常, ulb-ip 替換為 svc 對應的實際 ip查看節(jié)點上 kube-proxy 服務是否正常 systemctl status kube-proxy執(zhí)行iptables -L -n -t nat |grep KUBE-SVC 及 ipvsadm -L -n查看轉發(fā)規(guī)則是否下發(fā)正常iptables -L -n -t nat 或者ipvsadm -L -n 查看對應規(guī)則 修改 Service 類型，原 type: LoadBalancer 修改為 NodePort 或者 ClusterIP，再進行刪除 Service 操作，EIP 和 ULB 會保留。
因該操作 EIP 和 ULB 資源將不再受 UK8S 管理，所以需要手動至 ULB 和 EIP 頁面進行資源解綁和綁定。
在 Kubernetes 集群中運行的容器默認使用格林威治時間，而非宿主機時間。如果需要讓容器時間與宿主機時間一致，可以使用 "hostPath" 的方式將宿主機上的時區(qū)文件掛載到容器中。
大部分linux發(fā)行版都通過 "/etc/localtime" 文件來配置時區(qū)，我們可以通過以下命令來獲取時區(qū)信息：
# ls -l /etc/localtime
lrwxrwxrwx. 1 root root 32 Oct 15 2015 /etc/localtime -> ../usr/share/zoneinfo/Asia/Shanghai通過上面的信息，我們可以知道宿主機所在的時區(qū)為Asia/Shanghai，下面是一個Pod的yaml范例，說明如何將容器內(nèi)的時區(qū)配置更改為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如果容器之前已經(jīng)創(chuàng)建了，只需要在 yaml 文件中加上 volumeMounts 及 volumes 參數(shù)，再使用 kubectl apply 命令更新即可。
該情況一般有以下兩種可能
kube-system下面metrics-server Pod沒有正常工作，可以通過kubectl get pods -n kube-system進行查看metrics.k8s.io
API地址被錯誤重定向，可以執(zhí)行kubectl get apiservice v1beta1.metrics.k8s.io查看重定向到的service名稱，并確認service當前是否可用及是否對外暴露了v1beta1.metrics.k8s.io接口。默認重定向地址為kube-system/metrics-server情況二一般出現(xiàn)在部署prometheus，且prometheus提供的接口不支持v1beta1.metrics.k8s.io時。如果不需要自定義HPA指標，其實不需要此重定向操作。如果屬于情況二，可以按照下面步驟操作。
確認配置中的的prometheus service可用，并根據(jù)需要自定義HPA指標重新部署執(zhí)行下面yaml文件，回退到普通metrics server，Grafana等不依賴此api。注意，如果您之前已經(jīng)使用了自定義HPA指標，且處于線上環(huán)境，建議您僅確認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遇到containerd-shim進程泄露的情況，可以按照如下方式進行處理
確認泄露的進程id，執(zhí)行kill pid。注意，此時無需加-9參數(shù)，一般情況下簡單的kill就可以處理。確認containerd-shim進程退出后，可以觀察docker及kubelet是否恢復正常。注意，由于kubelet此時可能被docker卡住，阻擋了很多操作的執(zhí)行，當docker恢復后，可能會有大量操作同時執(zhí)行，導致節(jié)點負載瞬時升高，可以在操作前后分別重啟一遍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在1.19.5集群中，有可能出現(xiàn)節(jié)點not
ready的情況，查看kubelet日志，發(fā)現(xiàn)有大量Error while dialing dial unix:///run/containerd/containerd.sock相關的日志。這是1.19.5版本中一個已知bug，當遇到containerd重啟的情況下，kubelet會失去與containerd的連接，只有重啟kublet才能恢復。具體可以查看k8s官方issue。如果您遇到此問題，重啟kubelet即可恢復。同時目前uk8s集群已經(jīng)不支持創(chuàng)建1.19.5版本的集群，如果您的集群版本為1.19.5，可以通過升級集群的方式，升級到1.19.10。
文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/126974.html
摘要：詳細請見產(chǎn)品價格產(chǎn)品概念使用須知名詞解釋漏洞修復記錄集群節(jié)點配置推薦模式選擇產(chǎn)品價格操作指南集群創(chuàng)建需要注意的幾點分別是使用必讀講解使用需要賦予的權限模式切換的切換等。UK8S概覽UK8S是一項基于Kubernetes的容器管理服務，你可以在UK8S上部署、管理、擴展你的容器化應用，而無需關心Kubernetes集群自身的搭建及維護等運維類工作。了解使用UK8S為了讓您更快上手使用，享受UK...
摘要：集群常見問題單個集群最多能添加多少個節(jié)點當前單個集群對應節(jié)點數(shù)量可查看集群節(jié)點配置推薦。創(chuàng)建失敗，使用發(fā)現(xiàn)報錯為，是啥原因在創(chuàng)建等資源時，都需要扮演云賬戶的身份調(diào)用來完成相關操作。集群內(nèi)可以解析，但無法聯(lián)通外網(wǎng)拉取數(shù)據(jù)失敗。集群常見問題單個集群最多能添加多少個節(jié)點？A：當前單個UK8S集群對應節(jié)點數(shù)量可查看集群節(jié)點配置推薦。UK8S完全兼容原生Kubernetes API嗎？A：完全兼容。U...
摘要：會使用到以下產(chǎn)品的全部操作權限，例如代替你創(chuàng)建刪除云主機，由此產(chǎn)生的費用由你負責，請知悉。如何識別由創(chuàng)建的云資源由創(chuàng)建的云資源名稱，都遵循明確的命名規(guī)范，具體詳見命名規(guī)范簡要說明如下名稱，如名稱為的云主機，是這個集群的節(jié)點。容器云UK8S使用必讀注意：通過UK8S創(chuàng)建的云主機、云盤、EIP等資源，刪除資源請不要通過具體的產(chǎn)品列表頁刪除，否則可能導致UK8S運行不正常或數(shù)據(jù)丟失風險，可以通過U...
摘要：注意通過創(chuàng)建的云主機云盤等資源，刪除資源請不要通過具體的產(chǎn)品列表頁刪除，否則可能導致運行不正常或數(shù)據(jù)丟失風險，可以通過將資源釋放或解綁刪除。會使用到以下產(chǎn)品的全部操作權限，例如代替你創(chuàng)建刪除云主機，由此產(chǎn)生的費用由你負責，請知悉。注意：通過UK8S創(chuàng)建的云主機、云盤、EIP等資源，刪除資源請不要通過具體的產(chǎn)品列表頁刪除，否則可能導致UK8S運行不正常或數(shù)據(jù)丟失風險，可以通過UK8S將資源釋放...
摘要：產(chǎn)品概念是一項基于的容器管理服務，你可以在上部署管理擴展你的容器化應用，而無需關心集群自身的搭建及維護等運維類工作。完全兼容原生的，以私有網(wǎng)絡為基礎，并整合了等云產(chǎn)品。其命名規(guī)范為。產(chǎn)品概念UCloud Container Service for Kubernetes （UK8S）是一項基于Kubernetes的容器管理服務，你可以在UK8S上部署、管理、擴展你的容器化應用，而無需關心Kub...
閱讀 284·2024-11-07 18:25
閱讀 130366·2024-02-01 10:43
閱讀 868·2024-01-31 14:58
閱讀 828·2024-01-31 14:54
閱讀 82766·2024-01-29 17:11
閱讀 3048·2024-01-25 14:55
閱讀 1985·2023-06-02 13:36
閱讀 3033·2023-05-23 10:26
