《三》深入理解Pod物件
Pod容器分類
- 最小部署單元
- 一組容器的集合
- 一個Pod中的容器共享網路名稱空間
- Pod是短暫的
Infrastructure Container：基礎容器
• 維護整個Pod網路空間
InitContainers：初始化容器
• 先於業務容器開始執行
Containers：業務容器
• 並行啟動
映象拉取策略（imagePullPolicy）
- IfNotPresent：預設值，映象在宿主機上不存在時才拉取
- Always：每次建立 Pod 都會重新拉取一次映象
- Never： Pod 永遠不會主動拉取這個映象\
apiVersion: v1 kind: Pod metadata: name: foo namespace: awesomeapps spec: containers: - name: foo image: janedoe/awesomeapp:v1 imagePullPolicy: IfNotPresent
資源限制
預設情況下pod執行沒有任何CPU和記憶體的限制。這意味著系統中的pod可以儘可能多的消耗CPU和記憶體在pod執行的節點。
基於多種原因使用者可能希望對系統中的單個pod的資源使用量進行限制。
requests：容器執行是，最低資源需求，也就是說最少需要多少資源容器才能正常執行
limits：總的資源的限制，也就是說一個pod裡的容器最多使用多少資源
說明：
1、以下有2個容器（db、wp）
2、cpu：‘250m’ ：表示使用了1核的百分之25；500m 就是使用1核的50%
3、cpu: 0.1 ：表示0.1=100m
檢視限制的屬性：
查出分配的節點的IP
[[email protected]
檢視限制的屬性：
kubectl describe nodes 192.168.1.23
總結：
1、設定最大的limit 的配置
2、設定1核的cpu就是 cpu：1；cpu最大限制2核
重啟策略（restartPolicy）
- Always：當容器終止退出後，總是重啟容器，預設策略。比如 web伺服器，永續性的服務
- OnFailure：當容器異常退出（退出狀態碼非0）時，才重啟容器。
- Never:：當容器異常終止退出，從不重啟容器。
驗證：
檢視：
健康檢查（Probe）
參考文件：
在實際生產環境中，想要使得開發的應用程式完全沒有bug，在任何時候都執行正常，幾乎 是不可能的任務。因此，我們需要一套管理系統，來對使用者的應用程式執行週期性的健康檢查和修復操作。這套管理系統必須執行在應用程式之外，這一點非常重要一一如果它是應用程式的一部分，極有可能會和應用程式一起崩潰。因此，在Kubernetes中，系統和應用程式的健康檢查是由Kubelet來完成的。1、程序級健康檢查
最簡單的健康檢查是程序級的健康檢查，即檢驗容器程序是否存活。這類健康檢查的監控粒 度是在Kubernetes叢集中執行的單一容器。Kubelet會定期通過Docker Daemon獲取所有Docker程序的執行情況，如果發現某個Docker容器未正常執行，則重新啟動該容器程序。目前，程序級的健康檢查都是預設啟用的。
2．業務級健康檢查
在很多實際場景下，僅僅使用程序級健康檢查還遠遠不夠。有時，從Docker的角度來看，容器程序依舊在執行；但是如果從應用程式的角度來看，程式碼處於死鎖狀態，即容器永遠都無法正常響應使用者的業務
為了解決以上問題，Kubernetes引人了一個在容器內執行的活性探針（liveness probe）的概念，以支援使用者自己實現應用業務級的健康檢查。這些檢查項由Kubelet代為執行，以確保使用者的應用程式正確運轉，至於什麼樣的狀態才算“正確”，則由使用者自己定義。Kubernetes支援3種類型的應用健康檢查動作，分別為HTTP Get、Container Exec和TCP Socket。個人感覺exec的方式還是最通用的，因為不是每個服務都有http服務，但每個服務都可以在自己內部定義健康檢查的job，定期執行，然後將檢查結果儲存到一個特定的檔案中，外部探針就不斷的檢視這個健康檔案就OK了。Probe有以下兩種型別
livenessProbe
如果檢查失敗，將殺死容器，根據Pod的restartPolicy來操作。
readinessProbe
如果檢查失敗，Kubernetes會把Pod從service endpoints中剔除。
Probe支援以下三種檢查方
httpGet
傳送HTTP請求，返回200-400範圍狀態碼為成功，比如200成功，400不成功。
exec
執行Shell命令返回狀態碼是0為成功。
tcpSocket
發起TCP Socket建立成功。
initialDelaySeconds
initialDelaySeconds: 5
第一次使用probe時，需要等待5秒
periodSeconds
periodSeconds: 5
每隔5秒執行一個活性探針
2.1 Container Exec
當/tmp/healthy 這個被刪除了，再次 cat /tmp/healthy 不存在，狀態碼非0，就執行livenessProbe 這個規則
2.2 Container HTTP
說明：大於或等於200且小於400的任何程式碼表示成功。任何其他程式碼都指示失敗。
2.3 Container TCP
通過此配置，kubelet將嘗試開啟指定埠上的容器的套接字。如果可以建立連線，則認為容器是健康的，如果不能，則認為它是失敗的。
排程約束
說明
使用者建立一個pod，apiServer收到請求後，會將這個狀態（pod屬性）寫入到etcd中，apiServer通過watch 將新的pod 通知給Scheduler（排程器），Scheduler根據自身的排程演算法將pod分配到哪個node上，這些的配置資訊會存在etcd中，node上的kubelet 通過watch 繫結pod，並啟動docker,再更新pod狀態（執行，還是停止）etcd中，所以kubelet 展示給使用者
apiServer：相當於管家
etcd:相當於賬本
nodeName用於將Pod排程到指定的Node名稱上
nodeSelector用於將Pod排程到匹配Label的Node上
新建label標籤
kubectl label nodes 192.168.1.23 team=a
kubectl label nodes 192.168.1.24 team=b
檢視：
kubectl get nodes --show-labels
通過 kubectl describe pods pod-example 檢視排程器到哪個節點上
故障排查
解決：
檢視日誌
kubectl describe TYPE/NAME
kubectl logs
kubectl exec -it POD