容器探針

上面已經講到容器狀態,那么這些容器的狀態是怎么檢測到的呢?實際上在pod中有三種探針，存活探針(livenessProbe)、就緒探針(readinessProbe)和啟動探針(startupProbe)。

• livenessProbe，叫做存活探針，是為了檢測容器是否正在運行，是否活著（如果探測失敗就會殺死容器根據重啟策略選擇是否重啟）；
• readinessProbe，叫做就緒探針，是為了檢測容器是否準備就緒，是否能接受客戶端請求；它會指示容器是否準備好為請求提供服務。如果就緒態探測失敗， EndpointSlice 控制器將從與該 Pod 匹配的所有 Service 的EndpointSlice 中刪除該 Pod 的 IP 地址（為了防止我們正常的服務訪問這個錯誤的Pod導致業務崩潰）。
• startupProbe，叫做啟動探針，用于判斷容器進程是否已經啟動，一旦判斷成功就會失效不再判斷，一般用于那些啟動很久的程序。指示容器中的應用是否已經啟動。如果提供了啟動探針，則所有其他探針都會被 禁用，直到此探針成功為止（可以見得，啟動探針的優先級還是很高的）。如果啟動探測失敗，kubelet 將殺死容器， 而容器依其重啟策略進行重啟。

實際上容器探針收集到這些數據后就匯報給我們的控制平面了（kubernetes的大腦），我們看到的容器狀態就是從這里來的（如Running/NotReady）

小知識-控制平面

控制平面(control plane)既前面介紹過的kube-apiserver，kube-controller-manager，kube-scheduler，etcd這幾個組件組成。他們互相協作就實現了對整個k8s集群進行有效有序的管理。

Pod實戰

聲明式模型&命令模式

命令模式：顧名思義就是直接在服務器和平常敲命令一樣，直接命令執行創建Pod（不推薦）

聲明式：編寫一個yaml文件，其中包含了我們期望Pod的狀態，比如包含幾個容器，容器鏡像是什么，pod名字叫什么等等

雖然給出了兩種方式，但是絕對不推薦命令模式，我們目前在k8s集群，遇到的pod可能是巨大數量的，并且pod也會經常改變，可想而知，敲命令到手軟，并且多了你自己也記不住誰是誰了吧，維護起來讓人頭疼，所以命令模式絕對不是好的選擇。

部署第一個pod

在部署之前我們來理一下思路，這里以聲明式模型來討論

1. 首先我們編寫一個yaml文件，包含了我們期望的pod狀態的內容
2. 然后我們將這個文件post到api-server
3. api-server經過一系列驗證后返回一個響應后，由其他組件監聽到后進行創建pod與調度pod到合適的node節點

那么大致流程就像下圖：

那么我們實戰開始：

編寫pod清單文件

vi pod.ymlapiVersion: v1
kind: Pod
metadata:name: holle-podlabels:zone: prodversion: v1
spec:containers:- name: hello-ctrimage: nginx:1.22.1ports:- containerPort: 8080

kubectl命令將清單文件post到api-server

kubectl apply -f pod.yml# 查看pod狀態
kubectl get pod -o wide

這里已經可以看見我們的pod已經READY了，并且狀態為Running，NODE項說明這個pod實際運行在node01節點上，集群內部訪問ip為10.244.2.98

驗證pod

由于我們在清單文件定義pod中運行nginx鏡像，所以訪問上面pod給出的ip應該是可以出現nginx的歡迎頁（注意關閉node01的防火墻與selinux）

至此，我們的第一個pod已經創建成功并運行起來了，不過它目前似乎只能在集群內部訪問，外部訪問不了，那是因為我們并未配置暴露服務給外部，這一部分后續再說。

刪除pod

由于我們是直接定義的pod文件，所以刪除pod可以有兩種方式

第一種：kubectl delete holle-pod (注意這里的holle-pod是上面我們查詢pod狀態的NAME字段)

第二種：kubectl delete -f pod.yml (注意這里的pod.yml是我們編寫的pod清單文件)

可以看見我們刪除后再次查看pod狀態已經提示未找到了