Kubernetes 資源
本頁面列出的命令/步驟可用於檢查最重要的 Kubernetes 資源，並適用於 Rancher 啟動的 Kubernetes 叢集。
確保你配置了正確的 kubeconfig（例如，對於 Rancher HA，使用 export KUBECONFIG=$PWD/kube_config_cluster.yml），或透過 UI 使用嵌入式 kubectl。
節點
取得節點
執行以下命令並檢查以下內容：
- 應列出叢集中的所有節點，確保沒有遺漏任何節點。
- 所有節點應該具有 Ready 狀態（如果不在 Ready 狀態，請使用
docker logs kubelet檢查該節點上的kubelet容器日誌） - 檢查所有節點是否回報正確的版本。
- 檢查 OS/Kernel/Docker 值是否如預期顯示（你可能可以將問題與升級的 OS/Kernel/Docker 相關聯）
kubectl get nodes -o wide
範例輸出：
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
controlplane-0 Ready controlplane 31m v1.13.5 138.68.188.91 <none> Ubuntu 18.04.2 LTS 4.15.0-47-generic docker://18.9.5
etcd-0 Ready etcd 31m v1.13.5 138.68.180.33 <none> Ubuntu 18.04.2 LTS 4.15.0-47-generic docker://18.9.5
worker-0 Ready worker 30m v1.13.5 139.59.179.88 <none> Ubuntu 18.04.2 LTS 4.15.0-47-generic docker://18.9.5
取得節點條件
執行以下命令列出具有節點條件的節點
kubectl get nodes -o go-template='{{range .items}}{{$node := .}}{{range .status.conditions}}{{$node.metadata.name}}{{": "}}{{.type}}{{":"}}{{.status}}{{"\n"}}{{end}}{{end}}'
執行以下命令列出具有可能會阻止正常操作的活動節點條件的節點。
kubectl get nodes -o go-template='{{range .items}}{{$node := .}}{{range .status.conditions}}{{if ne .type "Ready"}}{{if eq .status "True"}}{{$node.metadata.name}}{{": "}}{{.type}}{{":"}}{{.status}}{{"\n"}}{{end}}{{else}}{{if ne .status "True"}}{{$node.metadata.name}}{{": "}}{{.type}}{{": "}}{{.status}}{{"\n"}}{{end}}{{end}}{{end}}{{end}}'
範例輸出：
worker-0: DiskPressure:True
Kubernetes 領導者選舉
Kubernetes Controller Manager 領導者
領導者由領導者選舉流程確定。在確定領導者後，領導者（holderIdentity）儲存在 kube-controller-manager 端點中（在此範例中為 controlplane-0）。
kubectl -n kube-system get endpoints kube-controller-manager -o jsonpath='{.metadata.annotations.control-plane\.alpha\.kubernetes\.io/leader}'
{"holderIdentity":"controlplane-0_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","leaseDurationSeconds":15,"acquireTime":"2018-12-27T08:59:45Z","renewTime":"2018-12-27T09:44:57Z","leaderTransitions":0}>
Kubernetes Scheduler 領導者
領導者由領導者選舉流程確定。在確定領導者後，領導者（holderIdentity）儲存在 kube-scheduler 端點中（在此範例中為 controlplane-0）。
kubectl -n kube-system get endpoints kube-scheduler -o jsonpath='{.metadata.annotations.control-plane\.alpha\.kubernetes\.io/leader}'
{"holderIdentity":"controlplane-0_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","leaseDurationSeconds":15,"acquireTime":"2018-12-27T08:59:45Z","renewTime":"2018-12-27T09:44:57Z","leaderTransitions":0}>
Ingress Controller
預設的 Ingress Controller 是 NGINX，並在 ingress-nginx 命名空間中部署為 DaemonSet。Pod 僅調度到具有 worker 角色的節點。
檢查 Pod 是否在所有節點上執行：
kubectl -n ingress-nginx get pods -o wide
範例輸出：
kubectl -n ingress-nginx get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
default-http-backend-797c5bc547-kwwlq 1/1 Running 0 17m x.x.x.x worker-1
nginx-ingress-controller-4qd64 1/1 Running 0 14m x.x.x.x worker-1
nginx-ingress-controller-8wxhm 1/1 Running 0 13m x.x.x.x worker-0
如果 Pod 無法執行（狀態不是 Running，Ready 狀態未顯示 1/1，或你看到大量的重新啟動），請檢查 Pod 詳細資訊、日誌和命名空間事件。
Pod 詳細資訊
kubectl -n ingress-nginx describe pods -l app=ingress-nginx
Pod 容器日誌
以下命令可以顯示所有標記為 "app=ingress-nginx" 的 Pod 的日誌，但由於 kubectl logs 命令的限制，它只會顯示 10 行日誌。請參閱 kubectl logs -h 的 --tail 以取得更多資訊。
kubectl -n ingress-nginx logs -l app=ingress-nginx
如果需要完整的日誌，請在命令中指定 Pod 名稱：
kubectl -n ingress-nginx logs <pod name>
命名空間事件
kubectl -n ingress-nginx get events
除錯日誌記錄
要啟用除錯日誌記錄：
kubectl -n ingress-nginx patch ds nginx-ingress-controller --type='json' -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--v=5"}]'
檢查配置
檢索每個 Pod 中產生的配置：
kubectl -n ingress-nginx get pods -l app=ingress-nginx --no-headers -o custom-columns=.NAME:.metadata.name | while read pod; do kubectl -n ingress-nginx exec $pod -- cat /etc/nginx/nginx.conf; done
Rancher 代理程式
與叢集的通訊（透過 cattle-cluster-agent 的 Kubernetes API）以及與節點的通訊（透過 cattle-node-agent 的叢集佈建）是透過 Rancher 代理程式完成的。
cattle-node-agent
檢查 cattle-node-agent Pod 是否存在於每個節點上，具有 Running 狀態，並且沒有大量的重新啟動：
kubectl -n cattle-system get pods -l app=cattle-agent -o wide
範例輸出：
NAME READY STATUS RESTARTS AGE IP NODE
cattle-node-agent-4gc2p 1/1 Running 0 2h x.x.x.x worker-1
cattle-node-agent-8cxkk 1/1 Running 0 2h x.x.x.x etcd-1
cattle-node-agent-kzrlg 1/1 Running 0 2h x.x.x.x etcd-0
cattle-node-agent-nclz9 1/1 Running 0 2h x.x.x.x controlplane-0
cattle-node-agent-pwxp7 1/1 Running 0 2h x.x.x.x worker-0
cattle-node-agent-t5484 1/1 Running 0 2h x.x.x.x controlplane-1
cattle-node-agent-t8mtz 1/1 Running 0 2h x.x.x.x etcd-2
檢查特定 cattle-node-agent Pod 或所有 cattle-node-agent Pod 的日誌記錄：
kubectl -n cattle-system logs -l app=cattle-agent
cattle-cluster-agent
檢查 cattle-cluster-agent Pod 是否存在於叢集中，具有 Running 狀態，並且沒有大量的重新啟動：
kubectl -n cattle-system get pods -l app=cattle-cluster-agent -o wide
範例輸出：
NAME READY STATUS RESTARTS AGE IP NODE
cattle-cluster-agent-54d7c6c54d-ht9h4 1/1 Running 0 2h x.x.x.x worker-1
檢查 cattle-cluster-agent Pod 的日誌記錄：
kubectl -n cattle-system logs -l app=cattle-cluster-agent
Job 和 Pod
檢查 Pod 或 Job 是否具有 Running/Completed 狀態
要檢查，請執行命令：
kubectl get pods --all-namespaces
如果 Pod 不在 Running 狀態，你可以透過執行以下命令深入了解根本原因：
描述 Pod
kubectl describe pod POD_NAME -n NAMESPACE
Pod 容器日誌
kubectl logs POD_NAME -n NAMESPACE
如果 Job 不在 Completed 狀態，你可以透過執行以下命令深入了解根本原因：
描述 Job
kubectl describe job JOB_NAME -n NAMESPACE
來自 Job 的 Pod 容器的日誌
kubectl logs -l job-name=JOB_NAME -n NAMESPACE
被驅逐的 Pod
Pod 可以根據驅逐訊號被驅逐。
檢索被驅逐的 Pod 清單（Pod 名稱和命名空間）：
kubectl get pods --all-namespaces -o go-template='{{range .items}}{{if eq .status.phase "Failed"}}{{if eq .status.reason "Evicted"}}{{.metadata.name}}{{" "}}{{.metadata.namespace}}{{"\n"}}{{end}}{{end}}{{end}}'
要刪除所有被驅逐的 Pod：
kubectl get pods --all-namespaces -o go-template='{{range .items}}{{if eq .status.phase "Failed"}}{{if eq .status.reason "Evicted"}}{{.metadata.name}}{{" "}}{{.metadata.namespace}}{{"\n"}}{{end}}{{end}}{{end}}' | while read epod enamespace; do kubectl -n $enamespace delete pod $epod; done
檢索被驅逐的 Pod 清單、調度的節點和原因：
kubectl get pods --all-namespaces -o go-template='{{range .items}}{{if eq .status.phase "Failed"}}{{if eq .status.reason "Evicted"}}{{.metadata.name}}{{" "}}{{.metadata.namespace}}{{"\n"}}{{end}}{{end}}{{end}}' | while read epod enamespace; do kubectl -n $enamespace get pod $epod -o=custom-columns=NAME:.metadata.name,NODE:.spec.nodeName,MSG:.status.message; done
Job 未完成
如果你已啟用 Istio，並且你遇到已部署的 Job 未完成的問題，你將需要使用這些步驟為你的 Pod 新增註解。
由於 Istio Sidecar 無限期執行，即使任務已完成，Job 也無法被視為完成。這是一個臨時的解決方法，並將為進出已註解 Pod 的任何流量停用 Istio。請記住，這可能不允許你繼續使用 Job 進行整合測試，因為 Job 將無法存取服務網格。