目錄
2 資源管理方式
2.1 命令式對象管理
2.2 資源類型
2.2.1 常用的資源類型
2.2.2 kubectl常見命令操作
2.3 基本命令示例
2.4 運行和調試命令示例
2.5 高級命令示例
3 pod簡介
3.1 創建自主式pod（生產環境不推薦）
3.1.1 優缺點
3.1.2 創建自主式pod示例
3.2 利用控制器管理pod（推薦）
3.2.1 優點
3.2.2 控制器管理pod示例
3.2.3 應用版本更新和回滾
3.3 利用yaml文件部署應用
3.3.1 用yaml文件部署應用有以下優點
3.3.2 資源清單參數
3.3.2.1 如何獲取資源幫助
3.3.3 編寫示例
3.3.3.1 運行簡單的單個容器pod
3.3.3.2 運行多個容器pod
3.3.3.3 理解pod間的網絡整合
3.3.3.4 端口映射
3.3.3.5 設定環境變量
3.3.3.6 資源限制
3.3.3.7 容器啟動管理
3.3.3.8 選擇運行的節點
3.3.3.9 共享宿主機網絡
4 pod的生命周期
4.1 INIT容器
4.1.1 INIT容器的功能
4.1.2 INIT容器示例
4.2 探針
4.2.1 探針是由kubelet對容器執行的定期診斷
4.2.2?Kubelet 可以選擇是否執行在容器上運行的三種探針執行和做出反應
4.2.3?ReadinessProbe 與 LivenessProbe 的區別
4.2.4?StartupProbe 與 ReadinessProbe、LivenessProbe 的區別
4.2.5 探針實例
4.2.5.1 存活探針示例
4.2.5.2 就緒探針示例
1 資源管理介紹
- 在kubernetes中，所有內容都抽象為資源，用戶需要通過操作資源來管理kubernetes
- kubernetes的本質是一個集群系統，用戶可以在集群中部署各種服務
- 所謂的部署服務，就是在kubernetes集群中運行一個個容器，并將指定程序跑在容器中
- kubernetes的最小管理單元是pod而不是容器，只能將容器放在pod中
- kubernetes一般不會直接管理pod，而是通過pod控制器來管理pod
- pod中服務的訪問是由kubernetes提供的service資源來實現
- pod中程序的數據需要持久化是由kubernetes提供的各種存儲系統來實現
2 資源管理方式
- 命令式對象管理：直接使用命令去操作kubernetes資源
kubectl run nginx-pod --image nginx:latest --port=80- 命令式對象配置：通過命令配置和配置文件去操作kubernetes資源
kubectl create/patch -f nginx-pod.yml- 聲明式對象配置：通過apply命令和配置文件去操作kubernetes資源
kubectl apply -f nginx-pod.yml| 類型 | 適用環境 | 優點 | 缺點 |
| 命令式對象管理 | 測試 | 簡單 | 只能操作活動對象，無法審計、跟蹤 |
| 命令式對象配置 | 開發 | 可以審計、跟蹤 | 項目較大時，配置文件較多，操作麻煩 |
| 聲明式對象配置 | 開發 | 支持目錄操作 | 意外情況下難以調試 |
2.1 命令式對象管理
kubectl是kuberneter集群的命令工具，通過對集群本身進行管理，并能夠在集群上進行容器化應用部署
kubectl命令語法如下：
kubectl [comand] [type] [name] [flags]- comand：指定要對資源執行的操作，如：create\get\delete
- type：指定資源類型，如：deployment\pod\service
- name：指定資源的名稱，名稱大小寫敏感
- flags：指定額外的可選參數
# 查看所有pod
kubectl get pod# 查看某個pod
kubectl get pod pod_name# 查看某個pod，并以yaml格式展示
kubectl get pod pod_name -o yaml2.2 資源類型
kubernetes中所有的內容都抽象為資源
kubectl api-resources2.2.1 常用的資源類型
2.2.2 kubectl常見命令操作
2.3 基本命令示例
kubectl詳細命令說明請參考：https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands
https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands
1.顯示集群版本
kubectl version
2.顯示集群信息
kubectl cluster-info
3.創建一個webcluster控制器，控制器pod期望為2
kubectl create deployment webcluseter --image nginx --replicas 2
4.查看控制器
kubectl get deployments.apps
5.查看資源幫助
kubectl explain deployment
6.查看控制器幫助參數
kubectl explain deployment.spec
7.編輯控制器配置
kubectl edit deployments.apps webcluseter
8.利用補丁更改控制器配置
kubectl patch deployments.apps webcluseter -p '{"spec":{"replicas":4}}'
9.刪除資源
kubectl delete deployments.apps webcluseter
2.4 運行和調試命令示例
1.運行pod
kubectl run testpod --image nginx
2.暴漏端口
kubectl expose pod testpod --port 80 --target-port 80
3.查看資源詳細信息
kubectl describe pod testpod
4.查看資源日志
kubectl logs pods/testpod
5.運行非交互式pod
kubectl run nginx --image nginx
6.運行交互式pod
kubectl run -it testpod --image busybox
7.進入到已經運行的容器，且容器有交互式環境
kubectl attach pods/testpod -it
8.在已經運行的pod中運行指定命令
kubectl exec -it pods/nginx /bin/bash
9.復制日志文件到pod中
kubectl cp anaconda-ks.cfg nginx:/
10.復制pod中的文件到本機
kubectl cp nginx:/anaconda-ks.cfg anaconda-ks.cfg
2.5 高級命令示例
1.利用命令生成yaml模板文件
kubectl create deployment --image nginx webcluster --dry-run=client -o yaml > webcluster.yml
2.管理資源標簽
kubectl get pod/nginx --show-labels
3.更改標簽（--overwrite：覆蓋已存在的同名標簽）
kubectl label pod nginx app=webcluster --overwrite
4.刪除pod上的標簽（控制器會重啟啟動新pod）
kubectl label pod nginx app-
3 pod簡介
- pod是kuberneter可以創建和管理的最小單元
- 一個pod代表著集群中運行的一個進程，每個pod都有唯一的ip
- 一個pod類似于一個豌豆莢，包含一個或多個容器（通常是docker）
- 多個容器間共享IPC、Network和UTC namespace
3.1 創建自主式pod（生產環境不推薦）
3.1.1 優缺點
優點：
靈活性高：可以精確控制pod的各種配置參數，包括容器的鏡像、資源限制、環境變量、命令和參數等，滿足特定的應用需求
學習和調試方便：對于學習kubernetes的原理和機制非常有幫助，通過手動創建pod可以深入了解pod的結構和配置方式。在調試問題時，可以更直接地觀察和調整pod的設置
適用于特殊場景：在一些特殊情況下，如進行一次性任、快速驗證概念或在資源受限的環境中進行特定配置時，手動創建pod可能是一種有效的方式
缺點：
管理復雜：如果需要管理大量的pod，手動創建和維護會變得非常繁瑣和耗時，難以實現自動化的擴容縮容、故障恢復等操作
缺乏高級功能：無法自動享受kubernetes提供的高級功能，如自動部署、滾動更新、服務發現等。這可能導致應用的部署和管理效率低下
可維護性差：手動創建的pod在更新應用版本或修改配置時需要手動干預，容易出現錯誤，并且難以保證一致性。相比之下，通過聲明式配置或使用kubernetes的部署工具可以更方便的進行應用的維護和更新
3.1.2 創建自主式pod示例
1.查看所有pod
kubectl get pods
2.建立pod
kubectl run timinglee --image nginx
3.顯示pod較為詳細的信息
kubectl get pods -o wide
3.2 利用控制器管理pod（推薦）
3.2.1 優點
1.高可用和可靠：
自動故障恢復：如果一個pod失敗或被刪除，控制器會自動創建新的pod來維持期望的pod數量。確保應用始終處于可用狀態，減少因單個pod故障導致的服務中斷
健康檢測和自愈：可以配置控制器對pod進行健康檢查（如存活探針和就緒探針）。如果pod不健康，控制器會采取適當的行動，如重啟pod或刪除并重新創建它，以保證應用的正常運行
2.可擴展性：
輕松擴縮容：可以通過簡單的命令或配置更改來增加或減少pod的數量，以滿足不同工作負載的需求。例如，在高流量期間可以快速擴展以處理更多請求，在低流量期間可以縮容以節省資源
水平自動擴縮容（HPA）：可以基于自定義指標（如CPU利用率，內存使用情況或應用特定指標）自動調整pod的數量，實現動態的資源分配和成本優化
3.版本管理和更新：
滾動更新：對于deployment等控制器，可以執行滾動更新來逐步替換舊版本的pod為新版本，確保應用在更新過程中始終保持可用。可以控制更新的速率和策略，以減少對用戶的影響
回滾：如果新版本出現問題，可以輕松回滾到上一個穩定版本，保證應用的穩定性和可靠性
4.聲明式配置：
簡潔的配置方式：使用yaml或json格式的聲明式配置文件來定義應用的部署需求。這種方式使得配置易于理解、維護和版本控制，同時也方便團隊協作
期望狀態管理：只需要定義應用的期望狀態（如副本數量、容器鏡像等），控制器會自動調整實際狀態與期望狀態保持一致。無需手動管理每一個pod的創建和刪除，提高了管理效率
5.服務發現和負載均衡：
自動注冊和發現：kubernetes中的服務（service）可以自動發現用控制器管理的pod，并將流量路由到pod。這使得應用的服務發現和負載均衡變得簡單可靠，無需手動配置負載均衡器
流量分發：可以根據不同的策略（如輪詢、隨機等）將請求分發到不同的pod，提高應用的性能和可用性
6.多環境一致性：
一致的部署方式：在不同的環境（如開發、測試、生產）中，可使用相同的控制器和配置來部署應用，確保應用在不同環境的一致行為。這有助于減少部署差異和錯誤，提高開發和運維效率
3.2.2 控制器管理pod示例
# 建立控制器并自動運行pod
kubectl create deployment timinglee --image nginx# 為timinglee擴容
kubectl scale deployment timinglee --replicas 4# 為timinglee縮容
kubectl scale deployment timinglee --replicas 2# 刪除控制器，恢復實驗環境
kubectl delete deployments.apps timinglee
3.2.3 應用版本更新和回滾
# 利用控制器創建pod，期望為2
kubectl create deployment myapp --image myapp:v1 --replicas 2# 查看pod狀態，是否創建成功
kubectl get pod# 暴漏pod端口，讓外部客戶能夠訪問內部pod
kubectl expose deployment myapp --port 80 --target-port 80# 查看端口是否暴漏成功
kubectl get service myapp# 訪問服務myapp:v1
curl 10.105.155.12# 查看歷史版本
kubectl rollout history deployment myapp# 更新控制器鏡像為myapp:v2
kubectl set image deployments/myapp myapp=myapp:v2# 查看歷史版本，確認是否更新成功
kubectl rollout history deployment myapp# 訪問服務myapp:v2
curl 10.105.155.12# 版本回滾
kubectl rollout undo deployment myapp --to-revision 1# 查看回滾是否成功
curl 10.105.155.12
3.3 利用yaml文件部署應用
3.3.1 用yaml文件部署應用有以下優點
1.聲明式配置：
- 清晰表達期望狀態：以聲明式方式描述應用的部署需求，包括副本數量、容器配置、網絡設置等。這使得配置易于理解和維護，并且可以方便的查看應用的預期狀態。
- 可重復性和版本控制：配置文件可以被版本控制，確保在不同環境中的部署一致性。可以輕松回滾到以前的版本或不同環境中重復使用相同的配置。
- 團隊協作：便于團隊成員之間共享和協作，大家可以對配置文件進行審核和修改，提高部署的可靠性和穩定性。
2.靈活性和可擴展性：
- 豐富的配置選項：可以通過yaml文件詳細的配置各種kubernetes資源，如Deployment、Service、ConfigMap、Secret等。可以根據應用的特定需求進行高度定制化。
- 組合和擴展：可以將多個資源的配置組合在一個或多個yaml文件中，實現復雜的應用部署架構。同時，可以輕松的添加新的資源或修改現有資源以滿足不斷變化的需求。
3.與工具集成：
- 與CI/CD流程集成：可以將yaml配置文件與持續集成和持續部署（CI/CD）工具集成，實現自動化的應用部署。例如，可以在代碼提交后自動觸發部署流程，使用配置文件來部署應用到不同的環境。
- 命令行工具支持：Kubernetes的命令行工具kubectl對yaml配置文件有很好的支持，可以方便的應用、更新和刪除配置。同時，還可以使用其它工具來驗證和分析yaml配置文件，確保正確性和安全性。
3.3.2 資源清單參數
| 參數名稱 | 類型 | 參數說明 |
| version | String | 這里是指k8s API的版本，目前基本是v1，可以用kubernetes api-versions命令查詢 |
| kind | String | 這里指的是yaml文件定義的資源類型和角色，比如pod |
| metadata | Object | 元數據對象，固定值就寫metadata |
| metadata.name | String | 元數據對象的名字，這里由我們編寫，比如命名pod的名字 |
| metadata.namespace | String | 元數據對象的命名空間，由我們自身定義，默認default |
| Spec | Object | 詳細定義對象，固定值就寫Spec |
| spec.containers[] | list | 這里是Spec對象的容器列表定義，是個列表 |
| spec.containers[].name | String | 這里定義容器的名字 |
| spec.containers[].image | String | 這里定義用到鏡像的名字 |
| spec.containers[].imagePullPolicy | String | 定義鏡像拉取策略，有三個值可選：1.Always：每次都嘗試重新拉取鏡像 2.IfNotPresent：如果本地有鏡像就使用本地鏡像 3.Never：表示僅使用本地鏡像 |
| spec.containers[].command[] | list | 指定容器運行時啟動的命令，若未指定則運行容器打包時指定的命令 |
| spec.containers[].args[] | list | 指定容器運行參數，可以指定多個 |
| spec.containers[].workingDir | String | 指定容器工作目錄 |
| spec.containers[].volumeMounts[] | list | 指定容器內部的存儲卷配置 |
| spec.containers[].volumeMounts[].name | String | 指定可以被容器掛載的卷的名稱 |
| spec.containers[].volumeMounts[].mountPath | String | 指定可以被容器掛載的存儲卷的路徑 |
| spec.containers[].volumeMounts[].readOnly | String | 設置存儲卷路徑的讀寫模式，ture或false，默認為寫模式 |
| spec.containers[].ports[] | list | 指定容器需要用到的端口列表 |
| spec.containers[].name | String | 指定端口名稱 |
| spec.containers[].containerPort | String | 指定容器需要監聽的端口號 |
| spec.containers[].ports[].hostPort | String | 指定容器所在主機需要監聽的端口號，默認跟上面containerPort相同，注意設置了hostPort同一臺主機無法啟動該容器的相同副本（因為主機的端口號不能相同，這樣會沖突） |
| spec.containers[].ports[].protocol | String | 指定端口協議支持TCP和UDP默認值為TCP |
| spec.containers[].env[] | list | 指定容器運行前需要設置的環境變量列表 |
| spec.containers[].env[].name | String | 指定環境變量名稱 |
| spec.containers[].env[].value | String | 指定環境變量值 |
| spec.containers[].resources | Object | 指定資源限制和資源請求的值（這里開始就是設置容器的資源上限） |
| spec.containers[].resources.limits | Object | 指定設置容器運行時資源的運行上限 |
| spec.containers[].resources.limits.cpu | String | 指定CPU的限制，單位為核心數，1=1000m |
| spec.containers[].resources.limits.memory | String | 指定MEM內存的限制，單位為MIB、GiB |
| spec.containers[].resources.requests | Object | 指定容器啟動和調度時的限制設置 |
| spec.containers[].resources.requests.cpu | String | CPU請求，單位為核心數，容器啟動時初始化可用數量 |
| spec.containers[].resources.requests.memory | String | 內存請求，單位為MIB、GIB，容器啟動的初始化可用數量 |
| spec.restartPolicy | string | 定義pod的重啟策略，默認值為Always 1.Always：只要容器終止（無論退出狀態碼是什么），kubelet 都會自動重啟容器。 2.OnFailure：僅當容器異常終止（退出狀態碼非 0）時，kubelet 才會重啟容器；若容器正常終止（退出狀態碼為 0），則不會重啟。 3.Never：無論容器以何種狀態終止（正常或異常），kubelet 都不會重啟容器。 |
| spec.nodeSelector | Object | 定義Node的Lable過濾標簽，以key:value格式指定 |
| spec.imagePullSecrets | Objest | 定義pull鏡像時使用secret名稱，以name:secretkey格式指定 |
| spec.host.Network | Boolean | 定義是否使用主機網絡模式，默認值為false。設置true表示使用宿主機網絡，不使用docker網橋，同時設置了true將無法在同一臺宿主機上啟動第二個副本 |
3.3.2.1 如何獲取資源幫助
kubectl explain pod.spec.containers
3.3.3 編寫示例
3.3.3.1 運行簡單的單個容器pod
使用命令獲取yaml模板
kubectl run timinglee --image myapp:v1 --dry-run=client -o yaml > pod.ymlapiVersion: v1
kind: Pod
metadata:labels:run: timinglee # pod標簽name: timinglee
spec:containers:- image: myapp:v1 # pod鏡像name: timinglee # 容器名稱3.3.3.2 運行多個容器pod
注意：如果多個容器運行在一個pod中，資源共享的同時在使用相同資源時也會干擾，比如端口
1.端口干擾示例：
apiVersion: v1
kind: Pod
metadata:labels:run: timingleename: timinglee
spec:containers:- image: myapp:v1name: web1- image: myapp:v2name: web2
2.在一個pod中開啟多個容器時一定要確保容器彼此不能互相干擾
apiVersion: v1
kind: Pod
metadata:labels:run: timingleename: timinglee
spec:containers:- image: myapp:v1name: web1- image: myapp:v2name: web2command:- /bin/sh- -c- sleep 100000
3.3.3.3 理解pod間的網絡整合
1.同一個pod中的容器使用同一個網絡
apiVersion: v1
kind: Pod
metadata:labels:run: timingleename: timinglee
spec:containers:- image: myapp:v1name: web1- image: myapp:v2name: web2command:- /bin/sh- -c- sleep 100000
3.3.3.4 端口映射
apiVersion: v1
kind: Pod
metadata:labels:run: timingleename: timinglee
spec:containers:- image: myapp:v1name: web1ports:- name: http # 端口名稱（自定義，用于標識端口用途）containerPort: 80 # 容器內部監聽的端口（容器內應用實際使用的端口）hostPort: 80 # 宿主機（節點）暴露的端口（外部訪問容器的入口）protocol: TCP # 協議類型（默認 TCP，可選 UDP）
3.3.3.5 設定環境變量
apiVersion: v1
kind: Pod
metadata:labels:run: timingleename: timinglee
spec:containers:- image: myapp:v1name: web1command:- /bin/sh- -c- echo $NAME;sleep 300000env:- name: NAMEvalue: timinglee
3.3.3.6 資源限制
資源限制會影響pod的Qos Class資源優先級，資源優先級分為Guaranteed > Burstable > BestEffort
QoS（Quality of Service）即服務質量
| 資源設定 | 優先級類型 |
|---|---|
| 資源限定未設定 | BestEffort |
| 資源限定設定且最大和最小不一致 | Burstable |
| 資源限定設定且最大和最小一致 | Guaranteed |
apiVersion: v1
kind: Pod
metadata:labels:run: timingleename: timinglee
spec:containers:- image: myapp:v1name: web1resources:limits: # pod使用資源的最高限制cpu: 500mmemory: 100Mrequests: # pod期望使用的資源量，不能大于limitscpu: 500mmemory: 100M
kubectl describe pod timinglee
3.3.3.7 容器啟動管理
apiVersion: v1
kind: Pod
metadata:labels:run: timingleename: timinglee
spec:restartPolicy: Alwayscontainers:- image: myapp:v1name: web1
3.3.3.8 選擇運行的節點
apiVersion: v1
kind: Pod
metadata:labels:run: timingleename: timinglee
spec:restartPolicy: AlwaysnodeSelector:kubernetes.io/hostname: node2containers:- image: myapp:v1name: web1
3.3.3.9 共享宿主機網絡
apiVersion: v1
kind: Pod
metadata:labels:run: timingleename: timinglee
spec:restartPolicy: AlwayshostNetwork: true # 共享宿主機網絡containers:- image: myapp:v1name: web1command:- /bin/sh- -c- sleep 100000
4 pod的生命周期
4.1 INIT容器
官方文檔：Pod | Kubernetes生產級別的容器編排系統https://kubernetes.io/zh/docs/concepts/workloads/pods/
Pod 可以包含多個容器，應用運行在這些容器里面，同時 Pod 也可以有一個或多個先于應用容器啟動的 Init 容器。
Init 容器與普通的容器非常像，除了如下兩點：
-
它們總是運行到完成
-
init 容器不支持 Readiness，因為它們必須在 Pod 就緒之前運行完成，每個 Init 容器必須運行成功，下一個才能夠運行。
如果Pod的 Init 容器失敗，Kubernetes 會不斷地重啟該 Pod，直到 Init 容器成功為止。但是，如果 Pod 對應的 restartPolicy 值為 Never，它不會重新啟動。
4.1.1 INIT容器的功能
-
Init 容器可以包含一些安裝過程中應用容器中不存在的實用工具或個性化代碼。
-
Init 容器可以安全地運行這些工具，避免這些工具導致應用鏡像的安全性降低。
-
應用鏡像的創建者和部署者可以各自獨立工作，而沒有必要聯合構建一個單獨的應用鏡像。
-
Init 容器能以不同于Pod內應用容器的文件系統視圖運行。因此，Init容器可具有訪問 Secrets 的權限，而應用容器不能夠訪問。
-
由于 Init 容器必須在應用容器啟動之前運行完成，因此 Init 容器提供了一種機制來阻塞或延遲應用容器的啟動，直到滿足了一組先決條件。一旦前置條件滿足，Pod內的所有的應用容器會并行啟動。
| 特性 | init 容器 | 主容器（containers） |
|---|---|---|
| 啟動時機 | 主容器啟動前，按順序執行 | init 容器全部成功后才啟動 |
| 生命周期 | 一次性執行，成功退出后不再運行 | 持續運行（除非異常終止或被重啟） |
| 資源占用 | 輕量（通常用?busybox?等小鏡像） | 按應用需求占用資源（如 CPU、內存） |
| 失敗影響 | 導致主容器無法啟動，Pod 可能重試 | 主容器失敗會按?restartPolicy?重啟 |
4.1.2 INIT容器示例
apiVersion: v1
kind: Pod
metadata:labels:run: initpodname: initpod
spec:containers:- image: myapp:v1name: myappinitContainers:- name: init-myserviceimage: busyboxcommand:- sh- -c- until test -e /testfile; do echo wating for myservice; sleep 2; done
test -e /testfile：檢查?/testfile?文件是否存在（-e?表示 “存在即返回成功”）until ...; do ...; done：循環執行?do?后的命令，直到?until?后的條件（/testfile?存在）滿足才退出循環echo wating for myservice; sleep 2：每次循環輸出 “等待 myservice” 的日志，并休眠 2 秒，避免頻繁檢查占用資源
kubectl exec pods/initpod -c init-myservice -- /bin/sh -c "touch /testfile"效果：
init 容器?init-myservice?中的循環命令?until test -e /testfile; do ...?會檢測到?/testfile?已存在，循環終止，init 容器會正常退出
kubectl exec：在運行的 Pod 容器中執行命令pods/initpod：指定目標 Pod 名稱為?initpod-c init-myservice：指定要操作的容器為 init 容器?init-myservice（因為 Pod 可能包含多個容器，必須明確指定）-- /bin/sh -c "touch /testfile"：在容器內執行的命令，通過?touch?命令創建?/testfile?文件
4.2 探針
4.2.1 探針是由kubelet對容器執行的定期診斷
每次探測都將獲得以下三種結果之一：
成功：容器診斷通過
失敗：容器未通過診斷
未知：診斷失敗，因此不會采取任何行動
4.2.2?Kubelet 可以選擇是否執行在容器上運行的三種探針執行和做出反應
- ExecAction：在容器內執行指定命令，如果命令退出時返回碼為 0 則認為診斷成功。
- TCPSocketAction：對指定端口上的容器的 IP 地址進行 TCP 檢查，如果端口打開，則診斷被認為是成功的
- HTTPGetAction：對指定的端口和路徑上的容器的 IP 地址執行 HTTP Get 請求，如果響應的狀態碼大于等于200 且小于 400，則診斷被認為是成功的
-
livenessProbe：指示容器是否正在運行。如果存活探測失敗，則 kubelet 會殺死容器，并且容器將受到其重啟策略的影響。如果容器不提供存活探針，則默認狀態為 Success。
-
readinessProbe：指示容器是否準備好服務請求。如果就緒探測失敗，端點控制器將從與 Pod 匹配的所有 Service 的端點中刪除該 Pod 的 IP 地址。初始延遲之前的就緒狀態默認為Failure。如果容器不提供就緒探針，則默認狀態為 Success。
-
startupProbe: 指示容器中的應用是否已經啟動。如果提供了啟動探測(startup probe)，則禁用所有其他探測，直到它成功為止。如果啟動探測失敗，kubelet 將殺死容器，容器服從其重啟策略進行重啟。如果容器沒有提供啟動探測，則默認狀態為成功Success。
4.2.3?ReadinessProbe 與 LivenessProbe 的區別
-
ReadinessProbe 當檢測失敗后，將 Pod 的 IP:Port 從對應的 EndPoint 列表中刪除。
-
LivenessProbe 當檢測失敗后，將殺死容器并根據 Pod 的重啟策略來決定作出對應的措施。
4.2.4?StartupProbe 與 ReadinessProbe、LivenessProbe 的區別
-
如果三個探針同時存在，先執行 StartupProbe 探針，其他兩個探針將會被暫時禁用，直到 pod 滿足 StartupProbe 探針配置的條件，其他 2 個探針啟動，如果不滿足按照規則重啟容器。
-
另外兩種探針在容器啟動后，會按照配置，直到容器消亡才停止探測，而 StartupProbe 探針只是在容器啟動后按照配置滿足一次后，不在進行后續的探測。
4.2.5 探針實例
4.2.5.1 存活探針示例
apiVersion: v1
kind: Pod
metadata:labels:run: livenessname: liveness
spec:containers:- image: myapp:v1name: myapplivenessProbe:tcpSocket:port: 8080 # 檢測端口存在性initialDelaySeconds: 3 # 容器啟動后等待3s后探針開始工作periodSeconds: 1 # 執行探測的時間間隔，默認10stimeoutSeconds: 1 # 探針執行檢測請求后，等待響應的超時時間，默認1s
8080端口不存在，存活探針檢測失敗，容器未通過診斷
4.2.5.2 就緒探針示例
apiVersion: v1
kind: Pod
metadata:labels:run: readinessname: readiness
spec:containers:- image: myapp:v1name: myappreadinessProbe:httpGet:path: /test.htmlport: 80initialDelaySeconds: 1periodSeconds: 3timeoutSeconds: 1
kubectl describe pod/readiness
404 錯誤表示：容器內的 Web 服務（myapp:v1）在?http://<容器IP>:80/test.html?路徑下不存在該文件，導致探針判定容器 “未就緒”。
執行命令在容器內創建?/test.html?文件
kubectl exec pods/readiness -c myapp -- /bin/sh -c "echo test > /usr/share/nginx/html/test.html"
路徑?/usr/share/nginx/html?是 Nginx 等 Web 服務的默認根目錄，創建?test.html?后，http://<容器IP>:80/test.html?可正常訪問（返回 200 狀態碼）
就緒探針檢測到?/test.html?存在且返回 200，判定容器 “就緒”，Pod 狀態更新為?READY 1/1
再次查看 Service 時，Endpoints?字段顯示 Pod 的 IP 和端口
此時 Service 可正常將外部流量路由到 Pod，實現服務訪問
到此kubernetes中pod的管理及優化介紹完畢！
