一、Kurbernetes的list-watch機制

1.1 list-watch機制簡介

Kubernetes 通過 List-Watch 的機制進行每個組件的協(xié)作，保持數據同步，每個組件之間的設計實現了解耦。

list 機制，通過調用資源的list API羅列資源，基于HTTP短鏈接實現；

watch機制，通過調用資源的watch API監(jiān)聽資源變更事件，基于HTTP 長鏈接實現

這種機制對于需要持續(xù)跟蹤 Kubernetes 集群中資源的狀態(tài)變化的應用程序非常有用，例如自動伸縮、監(jiān)控、日志收集等。

1.2 創(chuàng)建pod的流程（結合list-watch機制）

1）客戶端向apiserver發(fā)送創(chuàng)建Pod的請求，然后apiserver將請求信息存入到etcd中；

2）存入完成后，etcd會通過apiserver發(fā)送創(chuàng)建Pod資源的事件；

3）controller manager通過list-watch機制監(jiān)聽apiserver發(fā)送出來的事件，并創(chuàng)建相關的Pod資源，創(chuàng)建完成后，通過apiserver將信存入到etcd中

4） etcd存入更新信息之后，再次通過apiserver發(fā)送調度Pod資源的事件；

5）scheduler通過list-watch機制監(jiān)聽到apiserver發(fā)出的調度事件，通過調度算法，將Pod資源調度到合適的node節(jié)點上，調度完成后通過apiserver將調度完成后的信息更新到etcd中；

6）etcd收到更新信息后，再次向apiserver發(fā)送創(chuàng)建Pod的事件；

7）kubelet通過list-watch機制監(jiān)聽apiserver發(fā)出的創(chuàng)建Pod的事件，然后根據事件信息，在相應的node節(jié)點完成Pod的創(chuàng)建。

二、Scheduler的調度策略

2.1 簡介

Scheduler 是 kubernetes 的調度器，主要的任務是把定義的 pod 分配到集群的節(jié)點上。

Sheduler 是作為單獨的程序運行的，啟動之后會一直監(jiān)聽 APIServer，獲取 spec.nodeName 為空的 pod，對每個 pod 都會創(chuàng)建一個 binding，表明該 pod 應該放到哪個節(jié)點上。

調度規(guī)則

1）公平：如何保證每個節(jié)點都能被分配資源

2）資源高效利用：集群所有資源最大化被使用

3）效率：調度的性能要好，能夠盡快地對大批量的 pod 完成調度工作

4）靈活：允許用戶根據自己的需求控制調度的邏輯

調度的流程

1）首先是過濾掉不滿足條件的節(jié)點，這個過程稱為預算策略（predicate）；

2）然后對通過的節(jié)點按照優(yōu)先級排序，這個是優(yōu)選策略（priorities）；

3）最后從中選擇優(yōu)先級最高的節(jié)點。如果中間任何一步驟有錯誤，就直接返回錯誤。

2.2 預選策略（predicate）

預選策略：過濾掉不滿足條件的節(jié)點的過程。

常見的算法	描述
PodFitsResources	節(jié)點上剩余的資源是否大于 pod 請求的資源。
PodFitsHost	如果 pod 指定了 NodeName，檢查節(jié)點名稱是否和 NodeName 匹配。
PodFitsHostPorts	節(jié)點上已經使用的 port 是否和 pod 申請的 port 沖突。
PodSelectorMatches	過濾掉和 pod 指定的 label 不匹配的節(jié)點。
NoDiskConflict	已經 mount 的 volume 和 pod 指定的 volume 不沖突，除非它們都是只讀。

如果在 predicate 過程中沒有合適的節(jié)點，pod 會一直在 Pending 狀態(tài)`，不斷重試調度，直到有節(jié)點滿足條件。

2.3 優(yōu)選策略（priorities）

**優(yōu)選策略：**對通過的節(jié)點按照優(yōu)先級排序。

優(yōu)先級由一系列鍵值對組成，鍵是該優(yōu)先級項的名稱，值是它的權重（該項的重要性）。

常見的優(yōu)先級選項	描述
LeastRequestedPriority	通過計算CPU和Memory的使用率來決定權重，使用率越低權重越高。也就是說，這個優(yōu)先級指標傾向于資源使用比例更低的節(jié)點。
BalancedResourceAllocation	節(jié)點上 CPU 和 Memory 使用率越接近，權重越高。這個一般和上面的一起使用，不單獨使用。比如 node01 的 CPU 和 Memory 使用率 20:60，node02 的 CPU 和 Memory 使用率 50:50，雖然 node01 的總使用率比 node02 低，但 node02 的 CPU 和 Memory 使用率更接近，從而調度時會優(yōu)選 node02。
ImageLocalityPriority	傾向于已經有要使用鏡像的節(jié)點，鏡像總大小值越大，權重越高。

通過算法對所有的優(yōu)先級項目和權重進行計算，得出最終的結果。

三、標簽管理

#基本語法
kubectl label <資源類型> <資源名稱> <標簽鍵>=<標簽值> [options]

字段	功能
<資源類型>	要添加或修改標簽的資源類型	如 pod、deployment、service 等
<資源名稱>	要添加或修改標簽的資源對象的名稱
<標簽鍵>=<標簽值>	要添加或修改的標簽及其對應的值

3.1 查看標簽的幫助信息

kubectl label --help

3.2 查看標簽信息

--show-labels選項

#基本語法
kubectl get <資源類型> [<資源名稱>]  [-n namespace] --show-labels 

舉個例子

#查看指定命名空間中所有pod的標簽
kubectl get pods  -n my-ns --show-labels

3.3 添加標簽

使用 kubectl label 命令可以為資源對象添加標簽，在命令中指定資源類型、名稱和要添加的標簽及其值。

kubectl label <資源類型> <資源名稱> [-n namespce] key=value

key=value 表示要添加或修改的標簽鍵值對。

鍵（key）是一個字符串，可以是任何你指定的名字；

值（value）是一個字符串，可以是任何你指定的值。

鍵和值之間使用等號（=）連接。

舉個例子

#為名為 nginx-test1 的 Pod 添加app=backend 和 version=1.15 兩個標簽
kubectl label pod nginx-test1 -n my-ns app=backend version=1.15

3.4 修改標簽

使用--overwrite選項 可以修改已存在的標簽值。

如果不使用該選項，則只會添加新標簽或更新值不同的標簽。

#基本格式
kubectl label <資源類型> <資源名稱> <標簽鍵>=<新標簽值> --overwrite

舉個例子

kubectl label pod nginx-test1 -n my-ns app=1234 version=1222 --overwrite

3.5 刪除標簽

要刪除 Kubernetes 資源對象的標簽，可以使用 kubectl label 命令，將標簽值設置為空。

#基本格式
kubectl label <資源類型> <資源名稱> <標簽鍵>-

使用 -（減號）指示要刪除標簽。

刪除標簽不會刪除整個資源對象，只會刪除指定的標簽鍵和值。

舉個例子

#刪除app標簽
kubectl label pod nginx-test1 -n my-ns app-

3.6 根據標簽值查找資源對象

-l選項，根據標簽值查找 Kubernetes 資源對象。

標簽選擇器支持邏輯操作符（例如逗號表示邏輯與）和等價性操作符（= 表示等于）。

#基本格式
kubectl get/describe <資源類型>  -l key[=value]

使用 kubectl get 命令和自定義選擇器查詢語句來進行更復雜的標簽篩選。

使用 kubectl describe 命令查找具有指定標簽的資源對象的詳細信息。

舉個例子

kubectl get pod  -n my-ns -l app
kubectl get pod  -n my-ns -l version

kubectl describe pod  -n my-ns -l name=test1

四、kubernetes對Pod的調度策略

在 Kubernetes 中，調度 是指將 Pod 放置到合適的節(jié)點上，以便對應節(jié)點上的 Kubelet 能夠運行這些 Pod。

1）定向調度： 使用 nodeName 字段指定node節(jié)點名稱；使用 nodeSelector 字段指定node節(jié)點的標簽；

2）親和性調度： 使用 節(jié)點/Pod 親和性（NodeAffinity、PodAffinity、PodAntiAffinity）；

3）污點與容忍： 使用 節(jié)點設置污點，結合 Pod設置容忍。

4）全自動調度：運行在哪個節(jié)點上完全由Scheduler經過一系列的算法計算得出；

#補充，Pod和node的關系
Node 是 Kubernetes 集群中的工作節(jié)點
一個 Node 可以運行多個 Pod，而一個 Pod 只能運行在一個 Node 上
使用標簽和選擇器可以管理 Node 和 Pod 之間的關系，從而實現靈活的調度和管理。

五、定向調度

5.1 調度策略簡介

nodeName：指定節(jié)點名稱，用于將Pod調度到指定的Node上，不經過調度器。

nodeSelector：在 Pod 定義文件的 spec 下的 nodeSelector 字段中設置一個標簽選擇器，在 Pod 調度的時候，只有具有這些標簽的 Node 才會被考慮用來運行這個 Pod。

5.2 調度實例

5.2.1 通過nodeName字段

配置清單文件

apiVersion: v1
kind: Pod
metadata:name: my-pod
spec:nodeName: node02containers:- name: my-containerimage: nginx

創(chuàng)建與測試

kubectl apply -f test2.yamlkubectl get pods 

5.2.2 通過nodeSelector字段

配置

1.為在 Kubernetes 集群的節(jié)點設置標簽

kubectl label nodes node01 mylabel=backend
kubectl label nodes node02 mylabel=frontend

2.創(chuàng)建一個 Deployment

定義 Pod 調度策略為使用 NodeSelector，在創(chuàng)建時選擇具有 mylabel=backend 的節(jié)點上運行。

apiVersion: apps/v1
kind: Deployment
metadata:name: myapp
spec:replicas: 3selector:matchLabels:app: myapptemplate:metadata:labels:app: myappspec:nodeSelector:mylabel: backendcontainers:- name: myapp-containerimage: nginx

kubectl apply -f test1.yaml

測試

kubectl get pods -o wide

所有的 Pod 都運行在具有 mylabel=backend 的節(jié)點上。

六、親和性調度

官方文檔：將 Pod 指派給節(jié)點 | Kubernetes

kubectl explain pod.spec.affinity

鍵值運算關系	描述
In	label 的值在某個列表中
NotIn	label 的值不在某個列表中
Gt	label 的值大于某個值
Lt	label 的值小于某個值
Exists	某個 label 存在
DoesNotExist	某個 label 不存在

6.1 Node親和性

節(jié)點親和性(nodeAffinity)：匹配指定node節(jié)點的標簽，將要部署的Pod調度到滿足條件的node節(jié)點上

6.2 Pod親和性

Pod親和性(podAffinity)：匹配指定的Pod的標簽，將要部署的Pod調度到與指定Pod所在的node節(jié)點處于同一個拓撲域的node節(jié)點上。

如果有多個node節(jié)點屬于同一個拓撲域，通過Pod親和性部署多個Pod時則調度器會試圖將Pod均衡的調度到處于同一個拓撲域的node節(jié)點上

6.3 Pod反親和性

Pod反親和性(podAntiAffinity)：匹配指定的Pod的標簽，將要部署的Pod調度到與指定Pod所在的node節(jié)點處于不同的拓撲域的node節(jié)點上

如果有多個node節(jié)點不在同一個拓撲域，通過Pod反親和性部署多個Pod時則調度器會試圖將Pod均衡的調度到不在同一個拓撲域的node節(jié)點上

6.4 拓撲域

6.4.1 拓撲域的定義

拓撲域（Topology Domain）是用于描述和控制Pod調度和部署的一種機制,它基于節(jié)點的拓撲信息來限制Pod的調度位置，以滿足用戶定義的性能和資源需求。

使用拓撲域特性，可以在Pod的調度過程中指定節(jié)點的拓撲約束，這意味著可以定義一個Pod只能被調度到帶有某些特定標簽的節(jié)點上，或者避免被調度到具有某些標簽的節(jié)點上。

例如，可以指定要求一個Pod只能調度到同一個機架或同一個區(qū)域中的節(jié)點上，以滿足高可用性或數據局部性的需求。

6.4.2 如何判斷是否在同一個拓撲域？

通過拓撲域key(topologyKey)判斷。

如果有其它node節(jié)點擁有，和指定Pod所在的node節(jié)點，相同的拓撲域key的標簽key和值，那么它們就屬于同一個拓撲域。

6.5 親和性的策略

#查看字段信息
kubectl explain pod.spec.affinity.xxAffinity

字段	字段名	描述
required…	硬策略	強制性的滿足條件 如果沒有滿足條件的node節(jié)點，Pod會處于Pending狀態(tài)，直到有符合條件的node節(jié)點出現
preferred…	軟策略	非強制性的，會優(yōu)先選擇滿足條件的node節(jié)點進行調度 即使沒有滿足條件的node節(jié)點，Pod依然會完成調度

如果有多個軟策略選項的話，權重越大，優(yōu)先級越高。

如果把硬策略和軟策略合在一起使用，則要先滿足硬策略之后才會滿足軟策略。

6.6 親和性調度實例

6.6.1 node親和性

1.添加標簽

kubectl label nodes node01 disk=ssd
kubectl label nodes node02 disk=dds

配置清單文件

使用節(jié)點親和性調度規(guī)則，要求將 Pod 調度到標簽為 “disk=ssd” 的節(jié)點。

vim pod1.yamlapiVersion: v1
kind: Pod
metadata:name: frontend-pod
spec:containers:- name: frontendimage: nginxaffinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: diskoperator: Invalues:- ssd

創(chuàng)建并測試

kubectl apply -f pod1.yaml -n my-ns 
kubectl get pods -n my-ns -o wide

6.6.2 Pod親和性

多個pod在一個節(jié)點

添加標簽

kubectl label nodes node01 app=backend
kubectl label nodes node02 app=frontend

配置清單文件

apiVersion: v1
kind: Pod
metadata:name: frontend-pod
spec:containers:- name: frontendimage: nginxaffinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: appoperator: NotInvalues:- frontendtopologyKey: "kubernetes.io/hostname"
---
apiVersion: v1
kind: Pod
metadata:name: backend-pod
spec:containers:- name: backendimage: mysqlaffinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: appoperator: NotInvalues:- backendtopologyKey: "kubernetes.io/hostname"

創(chuàng)建并測試

kubectl apply -f pod2.yaml -n my-ns 
kubectl get pods -n my-ns -o wide

Kubernetes 將會創(chuàng)建一個具有 Pod Anti-Affinity 配置的 Deployment，確保這三個 Pod 盡量運行在不同的節(jié)點上。

6.6.3 Pod反親和性

多個pod不在同一個節(jié)點

配置清單文件

apiVersion: apps/v1
kind: Deployment
metadata:name: my-app-deployment
spec:replicas: 3selector:matchLabels:app: my-apptemplate:metadata:labels:app: my-appspec:containers:- name: my-app-containerimage: my-app-imageaffinity:podAntiAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: appoperator: Invalues:- my-apptopologyKey: "kubernetes.io/hostname"

創(chuàng)建并測試

kubectl apply -f pod3.yaml -n my-ns 
kubectl get pods -n my-ns -o wide

六、污點和容忍

通過使用污點和容忍機制，可以更精確地控制Pod的調度行為，確保Pod被調度到滿足特定條件的節(jié)點上。

7.1 節(jié)點設置污點

基本概念

在 Kubernetes 中，Node（節(jié)點）上的污點（Taint）是用于標記節(jié)點的屬性，以控制 Pod（容器）在節(jié)點上的調度行為。

通過給節(jié)點打上污點，可以限制節(jié)點上可以調度的 Pod，從而實現更精細的調度策略。

污點由三個部分組成：

• Key（鍵）：標記的名稱。
• Value（值）：標記的值，可選。
• Effect（作用）：標記的作用。

污點的組成格式如下：
key=value:effect

taint effect 支持的選項		描述
NoSchedule	一定不會被調度	表示 k8s 將不會將 Pod 調度到具有該污點的 Node 上
PreferNoSchedule	盡量不被調度	表示 k8s 將盡量避免將 Pod 調度到具有該污點的 Node 上
NoExecute	不會被調度，并驅逐Pod	表示 k8s 將不會將 Pod 調度到具有該污點

相關命令

#給節(jié)點打上污點
kubectl taint node <node名稱> key=[value]:effect#覆蓋現有的污點
kubectl taint node <node名稱> key=[value]:effect --overwrite#刪除
kubectl taint node <node名稱> key[=value:effect]-kubectl describe nodes <node名稱> | grep Taints

##舉個例子##
#給名為 `node-1` 的節(jié)點打上鍵為 `special`，值為 `true` 的污點，并設置作用為 `NoSchedule`：
kubectl taint node node-1 special=true:NoSchedule這將導致 Pod 除非聲明容忍該污點，否則不會被調度到 `node-1` 節(jié)點上。

7.2 Pod設置容忍

Pod 可以使用容忍（Toleration）來聲明對污點的容忍，以允許在具有相應污點的節(jié)點上調度。

配置清單格式

#Pod設置容忍 toleration
spec:tolerations:- key: 污點鍵名operator: Equal|Existsvalue: 污點鍵值effect: NoSchedule|PreferNoSchedule|NoExecute

相關命令

設置node節(jié)點不可調用
kubectl cordon <node名稱>
kubectl uncordon <node名稱>設置node節(jié)點不可調用并驅逐Pod
kubectl drain <node名稱> --ignore-daemonsets --force --delete-emptydir-data

7.3 調度實例

1.打上污點

kubectl taint node node01 key1=value1:NoSchedule

2.編寫測試清單文件

apiVersion: v1
kind: Pod
metadata:name: my-pod
spec:containers:- name: my-appimage: my-app-imagetolerations:- key: "key1"operator: "Equal"value: "value1"effect: "NoSchedule"

3.測試

kubectl apply -f pod4.yaml -n my-nskubectl get pod -o wide -n my-ns

八、Pod啟動階段

8.1 Pod啟動過程

0）控制器創(chuàng)建Pod副本；

1）調度器scheduler根據調度算法選擇一臺最適合的node節(jié)點調度Pod；

2）kubelet拉取鏡像；

3）kubelet掛載存儲卷等；

4）kubelet創(chuàng)建并運行容器；

5）kubelet根據容器的探針探測結果設置Pod狀態(tài)。

8.2 Pod生命周期的5種狀態(tài)

狀態(tài)	描述
Pending	Pod已經創(chuàng)建，但是Pod還處于包括未完成調度到node節(jié)點的過程或者還處于在鏡像拉取過程中、存儲卷掛載失敗的情況
Running	Pod所有容器已被創(chuàng)建，且至少有一個容器正在運行
Succeeded	Pod所有容器都已經成功退出，且不再重啟。（completed）
Failed	Pod所有容器都退出，且至少有一個容器是異常退出的。（error）
Unknown	master節(jié)點的controller manager無法獲取到Pod狀態(tài) 通常是因為master節(jié)點的apiserver與Pod所在node節(jié)點的kubelet通信失聯(lián)導致的

?

?

九、小結

9.1 理論部分

K8S是通過 List-Watch 機制實現每個組件的協(xié)作
controller manager、scheduler、kubelet 通過 List-Watch 機制監(jiān)聽 apiserver 發(fā)出的事件，apiserver 通過 List-Watch 機制監(jiān)聽 etcd 發(fā)出的事件scheduler的調度策略：
預選策略/預算策略：通過調度算法過濾掉不滿足條件的node節(jié)點；如果沒有滿足條件的node節(jié)點，Pod會處于Pending狀態(tài)，直到有符合條件的node節(jié)點出現
PodFitsResources、PodFitsHost、PodFitsHostPorts、PodSelectorMatches、NoDiskConflict優(yōu)選策略：根據優(yōu)先級選項為滿足預選策略條件的node節(jié)點進行優(yōu)先級權重排序，最終選擇優(yōu)先級最高的node節(jié)點來調度Pod
LeastRequestedPriority、BalancedResourceAllocation、ImageLocalityPriority標簽的管理操作：
kubectl label <資源類型> <資源名稱> 標簽key=標簽value
kubectl label <資源類型> <資源名稱> 標簽key=標簽value --overwrite
kubectl label <資源類型> <資源名稱> 標簽key-kubectl get <資源類型> [資源名稱] --show-labels
kubectl get <資源類型> -l 標簽key[=標簽value]指定node節(jié)點調度Pod的方式：
1）使用 nodeName 字段指定node節(jié)點名稱
2）使用 nodeSelector 字段指定node節(jié)點的標簽
3）使用 節(jié)點/Pod 親和性
4）使用 節(jié)點設置污點 + Pod設置容忍親和性：
節(jié)點親和性(nodeAffinity)：匹配指定node節(jié)點的標簽，將要部署的Pod調度到滿足條件的node節(jié)點上Pod親和性(podAffinity)：匹配指定的Pod的標簽，將要部署的Pod調度到與指定Pod所在的node節(jié)點處于同一個拓撲域的node節(jié)點上如果有多個node節(jié)點屬于同一個拓撲域，通過Pod親和性部署多個Pod時則調度器會試圖將Pod均衡的調度到處于同一個拓撲域的node節(jié)點上Pod反親和性(podAntiAffinity)：匹配指定的Pod的標簽，將要部署的Pod調度到與指定Pod所在的node節(jié)點處于不同的拓撲域的node節(jié)點上如果有多個node節(jié)點不在同一個拓撲域，通過Pod反親和性部署多個Pod時則調度器會試圖將Pod均衡的調度到不在同一個拓撲域的node節(jié)點上如何判斷是否在同一個拓撲域？
通過拓撲域key(topologyKey)判斷，如果有其它node節(jié)點擁有與指定Pod所在的node節(jié)點相同的拓撲域key的標簽key和值，那么它們就屬于同一個拓撲域親和性的策略：
硬策略(required....)：要強制性的滿足條件，如果沒有滿足條件的node節(jié)點，Pod會處于Pending狀態(tài)，直到有符合條件的node節(jié)點出現軟策略(preferred....)：非強制性的，會優(yōu)先選擇滿足條件的node節(jié)點進行調度，即使沒有滿足條件的node節(jié)點，Pod依然會完成調度節(jié)點設置污點 taint
kubectl taint node <node名稱> key=[value]:effectNoSchedule(一定不會被調度)  PreferNoSchedule(盡量不被調度)  NoExecute(不會被調度，并驅逐Pod)kubectl taint node <node名稱> key=[value]:effect --overwritekubectl taint node <node名稱> key[=value:effect]-kubectl describe nodes <node名稱> | grep TaintsPod設置容忍 toleration
spec:tolerations:- key: 污點鍵名operator: Equal|Existsvalue: 污點鍵值effect: NoSchedule|PreferNoSchedule|NoExecute設置node節(jié)點不可調用
kubectl cordon <node名稱>
kubectl uncordon <node名稱>設置node節(jié)點不可調用并驅逐Pod
kubectl drain <node名稱> --ignore-daemonsets --force --delete-emptydir-dataPod的啟動過程：
0）控制器創(chuàng)建Pod副本
1）調度器scheduler根據調度算法選擇一臺最適合的node節(jié)點調度Pod
2）kubelet拉取鏡像
3）kubelet掛載存儲卷等
4）kubelet創(chuàng)建并運行容器
5）kubelet根據容器的探針探測結果設置Pod狀態(tài)Pod生命周期的5種狀態(tài)
Pending    Pod已經創(chuàng)建，但是Pod還處于包括未完成調度到node節(jié)點的過程或者還處于在鏡像拉取過程中、存儲卷掛載失敗的情況
Running    Pod所有容器已被創(chuàng)建，且至少有一個容器正在運行
Succeeded  Pod所有容器都已經成功退出，且不再重啟。（completed）
Failed     Pod所有容器都退出，且至少有一個容器是異常退出的。（error）
Unknown    master節(jié)點的controller manager無法獲取到Pod狀態(tài)，通常是因為master節(jié)點的apiserver與Pod所在node節(jié)點的kubelet通信失聯(lián)導致的（比如kubelet本身出故障）
總結：Pod遵循預定義的生命周期，起始于Pending階段，如果至少其中有一個主容器正常運行，則進入Running階段，之后取決于Pod是否有容器以失敗狀態(tài)退出而進入Succeeded或者Failed階段。

9.2 K8s常用故障排錯流程/手段

kubectl get pods                                   查看Pod的運行狀態(tài)和就緒狀態(tài)
kubectl describe <資源類型|pods> <資源名稱>        查看資源的詳細信息和事件描述，主要是針對沒有進入Running階段的排查手段
kubectl logs <pod名稱> -c <容器名稱> [-p]          查看Pod容器的進程日志，主要是針對進入Running階段后的排查手段
kubectl exec -it <pod名稱> -c <容器名稱> sh|bash   進入Pod容器查看容器內部相關的（進程、端口、文件等）狀態(tài)信息
kubectl debug -it <pod名稱> --image=<臨時容器的鏡像名> --target=<目標容器>    在Pod中創(chuàng)建臨時容器進入目標容器進行調試，主要是針對沒有調試工具的容器使用
nsenter -n --target <容器pid>                      在Pod容器的宿主機使用nsenter轉換網絡命名空間，直接在宿主機進入目標容器的網絡命名空間進行抓包等調試kubectl get nodes           查看node節(jié)點運行狀態(tài)
kubectl describe nodes      查看node節(jié)點詳細信息和資源描述
kubectl get cs              查看master組件的健康狀態(tài)
kubectl cluster-info        查看集群信息journalctl -u kubelet -f    跟蹤查看kubelet進程日志