Kubernetes生命週期和探針

時間 2020-12-02

標籤 html node python nginx api tomcat app socket tcp oop 欄目 HTML 简体版

原文原文鏈接

簡介

簡介

Pod在整個生命週期中被系統定義爲各類狀態，熟悉Pod的各類狀態對於理解如何設置Pod的調度策略，重啓策略頗有必要html

1. Pod的狀態

Pending
API Server已經建立Pod 但在Pod內還有一個或多個的鏡像沒有建立，包括正在下載鏡像的過程。node
Running
Pod內全部容器已經建立完成，且至少有一個容器處於運行狀態python
Successded
Pod內全部容器均成功執行退出，而且不會再重啓nginx
Faild
Pod內全部容器均已退出，但至少有一個容器爲退出失敗狀態api

2. Pod重啓策略

Pod的重啓策略應用於Pod內全部的容器，而且僅在Pod所處的Node上由kubelet進行判斷和重啓操做tomcat

重啓策略app

Always：老是重啓；當容器失效時，由kubelete自動重啓該容器，默認值
OneFailure：當容器終止運行且退出碼不爲0時候，由kubelete自動重啓該容器
Never：不論容器運行狀態如何都不會重啓該容器,Job或CronJob

配置在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      #重啓策略

3. Pod探針

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進行設置

3.1 探針的探測方式

ExecAction
在容器內執行一個命令，若是該命令的返回值爲0 則代表容器健康
TCPSocketActio
經過容器的IP地址和端口號執行TCP檢
查，若是可以創建TCP鏈接，則代表容器健康
HTTPGetAction
經過容器的IP地址，端口號及路徑調用Http Get方法，若是狀態碼大於等於200且小於400，則認爲容器健康
生產建議使用此方法調用你的程序接口進行檢測

3.2 配置方式

輔助探測的其它配置項目

initialDelaySeconds: 5 #啓動容器後的多長時間進行探測
periodSeconds: 3 #間隔多長時間執行一次探測
timeoutSeconds: 5 #探測超時等待多少秒進行下一次探測
successThreshold: 1 #從失敗轉爲成功的重試次數，探測器在失敗後，被視爲成功的最小連續成功數，默認值是1，存活探測的這個值必須是1，最小值是 1
failureThreshold: 3 #從成功轉爲失敗的重試次數，當Pod啓動了而且探測到失敗，Kubernetes的重試次數，存活探測狀況下的放棄就意味着從新啓動容器，就緒探測狀況下的放棄Pod 會被打上未就緒的標籤，默認值是3，最小值是1

HttpGet探針

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 來進行容器應用的健康檢查

TcpSocket探針

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

ExecAction探針

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

3.2 livenessProbe和readinessProbe的對比

配置參數同樣

livenessProbe 連續探測失敗會重啓、重建pod，readinessProbe不會執行重啓或者重建Pod操做
livenessProbe 連續檢測指定次數失敗後會將容器置於(Crash Loop BackOff)且不可用，readinessProbe不
會
readinessProbe 連續探測失敗會從service的endpointd中刪除該Pod，livenessProbe不具有此功能，可是會將容器掛起livenessProbe
livenessProbe用戶控制是否重啓pod，readinessProbe用於控制pod是否添加至service

建議：
兩個探針都配置