1. 程式人生 > >《三》深入理解Pod對象

《三》深入理解Pod對象

nes sele 綁定 container 建立 structure rest 是否存活 返回

Pod容器分類
  1. 最小部署單元
  2. 一組容器的集合
  3. 一個Pod中的容器共享網絡命名空間
  4. 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
[root@docker demo]# kubectl describe pods frontend

查看限制的屬性:
kubectl describe nodes 192.168.1.23

總結:
1、設置最大的limit 的配置
2、設置1核的cpu就是 cpu:1;cpu最大限制2核

重啟策略(restartPolicy)

  • Always:當容器終止退出後,總是重啟容器,默認策略。比如 web服務器,持久性的服務
  • OnFailure:當容器異常退出(退出狀態碼非0)時,才重啟容器。
  • Never::當容器異常終止退出,從不重啟容器。

技術分享圖片

驗證:
技術分享圖片

查看:
技術分享圖片

健康檢查(Probe)

參考文檔:https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

 在實際生產環境中,想要使得開發的應用程序完全沒有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

總結

1、pod三個分類
2、鏡像拉取策略哪個關鍵字
3、資源限制哪2個字段
4、重啟策略哪3個策略
5、健康檢查哪2個類型 哪3個檢查方法

《三》深入理解Pod對象