Pod在整個生命週期中被系統定義爲各類狀態,熟悉Pod的各類狀態對於理解如何設置Pod的調度策略,重啓策略頗有必要html
Pending
API Server已經建立Pod 但在Pod內還有一個或多個的鏡像沒有建立,包括正在下載鏡像的過程。node
Running
Pod內全部容器已經建立完成,且至少有一個容器處於運行狀態python
Successded
Pod內全部容器均成功執行退出,而且不會再重啓nginx
Faild
Pod內全部容器均已退出,但至少有一個容器爲退出失敗狀態api
Pod的重啓策略應用於Pod內全部的容器,而且僅在Pod所處的Node上由kubelet進行判斷和重啓操做tomcat
重啓策略app
配置在spec與containers同級中socket
........ containers: - name: tomcat-app1-container image: harbor.magedu.local/tomcat-app1:v1 command: ["/apps/tomcat/bin/run_tomcat.sh"] imagePullPolicy: IfNotPresent #imagePullPolicy: Always ports: - containerPort: 8080 protocol: TCP name: http env: - name: "password" value: "123456" resources: limits: cpu: 1 memory: "512Mi" requests: cpu: 500m memory: "512Mi" restartPolicy: Always #重啓策略
Pod健康檢查和服務可用性檢查tcp
Kubernetes對Pod的健康檢查能夠經過兩類探針檢查LivenessProbe,ReadinessProbe,kubelet按期執行這兩類探針來診斷容器的監控狀態oop
LivenessProber探針
用於判斷容器是否存活(Running狀態),若是LivenessProbe探針探測到容器不健康,則kubelete將殺掉該容器,並根據容器的重啓策略作相應的處理,若是一個容器不包含LivenessProbe探針,那麼kubelet認爲該容器的LivenessProbe彈指值返回永遠時Seccess
ReadinessProbe探針
用於判斷容器服務是否可用(Ready狀態),達到Ready狀態的Pod才能夠接受請求,流量能夠接入。對於service管理的Pod service與Pod Endpoint的關聯關係也會將基於Pod是否Ready進行設置
ExecAction
在容器內執行一個命令,若是該命令的返回值爲0 則代表容器健康
TCPSocketActio
經過容器的IP地址和端口號執行TCP檢
查,若是可以創建TCP鏈接,則代表容器健康
HTTPGetAction
經過容器的IP地址,端口號及路徑調用Http Get方法,若是狀態碼大於等於200且小於400,則認爲容器健康
生產建議使用此方法調用你的程序接口進行檢測
輔助探測的其它配置項目
initialDelaySeconds: 5 #啓動容器後的多長時間進行探測
periodSeconds: 3 #間隔多長時間執行一次探測
timeoutSeconds: 5 #探測超時等待多少秒進行下一次探測
successThreshold: 1 #從失敗轉爲成功的重試次數,探測器在失敗後,被視爲成功的最小連續成功數,默認值是1,存活探測的這個值必須是1,最小值是 1
failureThreshold: 3 #從成功轉爲失敗的重試次數,當Pod啓動了而且探測到失敗,Kubernetes的重試次數,存活探測狀況下的放棄就意味着從新啓動容器,就緒探測狀況下的放棄Pod 會被打上未就緒的標籤,默認值是3,最小值是1
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 1 selector: matchLabels: #rs or deployment app: ng-deploy-80 template: metadata: labels: app: ng-deploy-80 spec: containers: - name: ng-deploy-80 image: nginx:1.17.5 ports: - containerPort: 80 livenessProbe: httpGet: path: /index.html port: 80 initialDelaySeconds: 5 #啓動容器後的多長時間進行探測 periodSeconds: 3 #間隔多長時間執行一次探測 timeoutSeconds: 5 #探測超時等待多少秒進行下一次探測 successThreshold: 1 #從失敗轉爲成功的重試次數,探測器在失敗後,被視爲成功的最小連續成功數,默認值是1,存活探測的這個值必須是1,最小值是 1 failureThreshold: 3 #從成功轉爲失敗的重試次數,當Pod啓動了而且探測到失敗,Kubernetes的重試次數,存活探測狀況下的放棄就意味着從新啓動容器,就緒探測狀況下的放棄Pod 會被打上未就緒的標籤,默認值是3,最小值是1
kubelet定時發送HTTP請求到 localhost:80/index.html 來進行容器應用的健康檢查
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 1 selector: matchLabels: #rs or deployment app: ng-deploy-80 template: metadata: labels: app: ng-deploy-80 spec: containers: - name: ng-deploy-80 image: nginx:1.17.5 ports: - containerPort: 80 livenessProbe: tcpSocket: port: 80 initialDelaySeconds: 5 periodSeconds: 3 timeoutSeconds: 5 successThreshold: 1 failureThreshold: 3
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 1 selector: matchLabels: #rs or deployment app: ng-deploy-80 template: metadata: labels: app: ng-deploy-80 spec: containers: - name: ng-deploy-80 image: nginx:1.17.5 ports: - containerPort: 80 livenessProbe: exec: command: - cat - /root/ initialDelaySeconds: 5 periodSeconds: 3 timeoutSeconds: 5 successThreshold: 1 failureThreshold: 3
配置參數同樣
livenessProbe 連續探測失敗會重啓、重建pod,readinessProbe不會執行重啓或者重建Pod操做
livenessProbe 連續檢測指定次數失敗後會將容器置於(Crash Loop BackOff)且不可用,readinessProbe不
會
readinessProbe 連續探測失敗會從service的endpointd中刪除該Pod,livenessProbe不具有此功能,可是會將容器掛起livenessProbe
livenessProbe用戶控制是否重啓pod,readinessProbe用於控制pod是否添加至service
建議:
兩個探針都配置
imagePullPolicy: IfNotPresent
node節點沒有此鏡像就去指定的鏡像倉庫拉取,node有就使用node本地鏡像。
imagePullPolicy: Always
每次重建pod都會從新拉取鏡像
imagePullPolicy: Never 從不到鏡像中心拉取鏡像,只使用本地鏡像