主頁 >  其他 > K8s Pod狀態與容器探針

K8s Pod狀態與容器探針

2023-06-01 08:46:37 其他

1、pod的調度流程及常見狀態

1.1、pod的調度流程

Pod創建程序如上圖所示，首先用戶向apiserver發送創建pod的請求，apiserver收到用于創建pod請求后，對應會對該用戶身份資訊進行驗證，該用戶是否是合法的用戶，是否具有創建pod的權限，如果能夠通過apiserver的驗證，則進行下一步，對用戶提交的資源進行準入控制，所謂準入控制是指對用戶提交的資源做格式，語法的驗證，是否滿足apiserver中定義的對應資源的api格式和語法；如果上述身份驗證和準入控制能夠順利通過，接下來，apiserver才會把對應創建pod的資訊存入etcd中，否者就直接拒絕用戶創建pod；etcd將對應資料存放好以后，會回傳給apiserver一個事件，即創建pod的相關資訊已經存入etcd中了；apiserver收到etcd的資源資訊存入完成事件后，會回傳給用戶一個pod創建完成的訊息；隨后，scheduler通過監視到apiserver上的資源變動事件，會對pod進行調度，調度規則就是先預選（預選就是把不符合pod運行的節點先踢出去，然后在剩下的節點中進行優選），然后再優選（優選就是在滿足預選留下的節點中進行打分，得分高者負責運行pod）；scheduler最后通過預選+優選的方式把pod調度到后端某個node節點上運行的結果回傳給apiserver，由apiserver將最終調度資訊存入etcd中，等待etcd將對應調度資訊更新完畢后，再回傳給apiserver一個pod狀態資訊更新完畢，apiserver再將對應狀態回傳給scheduler；隨后負責運行pod的node節點上的kubelet通過監視apiserver的資源變動事件，會發現一個和自己相關的事件，此時對應節點上的kubelet會呼叫本地容器引擎，將對應pod在本地運行起來；當本地容器引擎將pod正常運行起來后，對應容器引擎會回傳給本地kubelet一個pod運行完成的事件，隨后再由kubelet將對應事件回傳給apiserver，隨后apiserver再將pod狀態資訊存入etcd中,etcd將更新pod狀態資訊完成的事件通過apiserver將對應事件回傳給kubelet；如果此時用戶查詢pod狀態，就能夠正常通過apiserver在etcd中檢索出來的pod狀態；以上就是pod創建的一個大概程序；

1.2、pod的常見狀態

  • Unschedulable：#Pod不能被調度，kube-scheduler沒有匹配到合適的node節點
  • PodScheduled：#pod正處于調度中，在kube-scheduler剛開始調度的時候，還沒有將pod分配到指定的node，在篩選出合適的節點后就會更新etcd資料，將pod分配到指定的node，
  • Pending: #正在創建Pod但是Pod中的容器還沒有全部被創建完成=[處于此狀態的Pod應該檢查Pod依賴的存盤是否有權限掛載等，
  • Failed：#Pod中有容器啟動失敗而導致pod作業例外，
  • Unknown：#由于某種原因無法獲得pod的當前狀態，通常是由于與pod所在的node節點通信錯誤，
  • Initialized：#所有pod中的初始化容器已經完成了，
  • ImagePullBackOff：#Pod所在的node節點下載鏡像失敗，
  • Running：#Pod內部的容器已經被創建并且啟動，
  • Ready：#表示pod中的容器已經可以提供訪問服務，
  • Error: #pod 啟動程序中發生錯誤，
  • NodeLost: #Pod 所在節點失聯，
  • Waiting: #Pod 等待啟動，
  • Terminating: #Pod 正在被銷毀，
  • CrashLoopBackOff：#pod崩潰，但是kubelet正在將它重啟，
  • InvalidImageName：#node節點無法決議鏡像名稱導致的鏡像無法下載，
  • ImageInspectError：#無法校驗鏡像，鏡像不完整導致，
  • ErrImageNeverPull：#策略禁止拉取鏡像，鏡像中心權限是私有等，
  • RegistryUnavailable：#鏡像服務器不可用，網路原因或harbor宕機，
  • ErrImagePull：#鏡像拉取出錯，超時或下載被強制終止，
  • CreateContainerConfigError：#不能創建kubelet使用的容器配置，
  • CreateContainerError：#創建容器失敗，
  • RunContainerError：#pod運行失敗，容器中沒有初始化PID為1的守護行程等，
  • ContainersNotInitialized：#pod沒有初始化完畢，
  • ContainersNotReady：#pod沒有準備完畢，
  • ContainerCreating：#pod正在創建中，
  • PodInitializing：#pod正在初始化中，
  • DockerDaemonNotReady：#node節點decker服務沒有啟動，
  • NetworkPluginNotReady：#網路插件沒有啟動，

2、pause容器及init容器

2.1、pause容器簡介

Pause 容器，又叫 Infra 容器，是pod的基礎容器，鏡像體積只有幾百KB左右，配置在kubelet中，主要的功能是一個pod中多個容器的網路通信，
Infra 容器被創建后會初始化 Network Namespace，之后其它容器就可以加入到 Infra 容器中共享Infra 容器的網路了，因此如果一個 Pod 中的兩個容器 A 和 B，那么關系如下 ：

  • A容器和B容器能夠直接使用 localhost 通信；
  • A容器和B容器可以可以看到網卡、IP與埠監聽資訊，
  • Pod 只有一個 IP 地址，也就是該 Pod 的 Network Namespace 對應的IP 地址(由Infra 容器初始化并創建)，
  • k8s環境中的每個Pod有一個獨立的IP地址(前提是地址足夠用)，并且此IP被當前 Pod 中所有容器在內部共享使用，
  • pod洗掉后Infra 容器隨機被洗掉,其IP被回收，

2.2、Pause容器共享的Namespace

  • NET Namespace：Pod中的多個容器共享同一個網路命名空間，即使用相同的IP和埠資訊，
  • IPC Namespace：Pod中的多個容器可以使用System V IPC或POSIX訊息佇列進行通信，
  • .UTS Namespace：pod中的多個容器共享一個主機名，MNT Namespace、PID Namespace、User Namespace未共享，

2.3、Pause容器Namespace驗證

1、 運行pod，進入容器查看iflink編號

2、到pod所在宿主機驗證網卡

2.4、pause容器配置示例

2.4.1、準備nginx組態檔，并配置動靜分離

error_log stderr;
events { worker_connections 1024; }
http {
  access_log /dev/stdout;
  server {
    listen 80 default_server;
    server_name www.mysite.com;
    location / {
      index index.html index.php;
      root /usr/share/nginx/html;
    }
    location ~ \.php$ {
    root /usr/share/nginx/html;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
    }
  }
}

2.4.2、部署pause容器

2.4.2.1、下載pause鏡像

nerdctl pull registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.8

2.4.2.2、運行pause鏡像為容器

nerdctl run -d -p 80:80 --name pause-container-test registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.8

2.4.3、準備測驗web頁面

root@deploy:~# mkdir html
root@deploy:~# cd html
root@deploy:~/html# echo "<h1>pause container web test</h1>" >index.html
root@deploy:~/html# cat >> index.php << EOF
> <?php
>      phpinfo();
> ?>
> EOF
root@deploy:~/html# ll
total 16
drwxr-xr-x 2 root root 4096 May 26 00:03 ./
drwxr-xr-x 9 root root 4096 May 26 00:02 ../
-rw-r--r-- 1 root root   34 May 26 00:02 index.html
-rw-r--r-- 1 root root   25 May 26 00:03 index.php
root@deploy:~/html# cat index.html 
<h1>pause container web test</h1>
root@deploy:~/html# cat index.php 
<?php
     phpinfo();
?>
root@deploy:~/html#

2.4.4、部署nginx 容器，并使用pause容器網路

nerdctl run -d --name nginx-container-test \
            -v `pwd`/nginx.conf:/etc/nginx/nginx.conf \
            -v `pwd`/html:/usr/share/nginx/html \
            --net=container:pause-container-test \
            nginx:1.20.2

2.4.5、部署php容器，并使用pause容器網路

nerdctl run -d --name php-container-test \
            -v `pwd`/html:/usr/share/nginx/html \
            --net=container:pause-container-test \
            php:5.6.40-fpm

2.4.6、pause容器驗證

訪問宿主機的80埠的index.php，看看是否能夠訪問到php頁面？

2.5、init容器簡介

2.5.1、init容器的作用

  • 可以為業務容器提前準備好業務容器的運行環境，比如將業務容器需要的組態檔提前生成并放在指定位置、檢查資料權限或完整性、軟體版本等基礎運行環境，
  • 可以在運行業務容器之前準備好需要的業務資料，比如從OSS下載、或者從其它位置copy，
  • 檢查依賴的服務是否能夠訪問，

2.5.2、init容器的特點

  • 一個pod可以有多個業務容器還能在有多個init容器，但是每個init容器和業務容器的運行環境都是隔離的，
  • init容器會比業務容器先啟動，
  • init容器運行成功之后才會繼續運行業務容器，
  • 如果一個pod有多個init容器，則需要從上到下逐個運行并且全部成功，最后才會運行業務容器，
  • init容器不支持探針檢測(因為初始化完成后就退出再也不運行了)，

2.5.3、init容器示例

kind: Deployment
#apiVersion: extensions/v1beta1
apiVersion: apps/v1
metadata:
  labels:
    app: myserver-myapp 
  name: myserver-myapp-deployment-name
  namespace: myserver
spec:
  replicas: 1 
  selector:
    matchLabels:
      app: myserver-myapp-frontend
  template:
    metadata:
      labels:
        app: myserver-myapp-frontend
    spec:
      containers:
        - name: myserver-myapp-container
          image: nginx:1.20.0 
          #imagePullPolicy: Always
          volumeMounts:
          - mountPath: "/usr/share/nginx/html/myserver"
            name: myserver-data
          - name: tz-config
            mountPath: /etc/localtime
      initContainers:
        - name: init-web-data
          image: centos:7.9.2009
          command: ['/bin/bash','-c',"for i in `seq 1 10`;do echo '<h1>'$i web page at $(date +%Y%m%d%H%M%S) '<h1>' >> /data/nginx/html/myserver/index.html;sleep 1;done"]
          volumeMounts:
          - mountPath: "/data/nginx/html/myserver"
            name: myserver-data
          - name: tz-config
            mountPath: /etc/localtime
        - name: change-data-owner
          image: busybox:1.28
          command: ['/bin/sh','-c',"/bin/chmod 644 /data/nginx/html/myserver/* -R"]
          volumeMounts:
          - mountPath: "/data/nginx/html/myserver"
            name: myserver-data
          - name: tz-config
            mountPath: /etc/localtime
      volumes:
      - name: myserver-data
        hostPath:
          path: /tmp/data/html
      - name: tz-config
        hostPath:
          path: /etc/localtime 

---
kind: Service
apiVersion: v1
metadata:
  labels:
    app: myserver-myapp-service
  name: myserver-myapp-service-name
  namespace: myserver
spec:
  type: NodePort
  ports:
  - name: http
    port: 80
    targetPort: 80
    nodePort: 30080
  selector:
    app: myserver-myapp-frontend

上述配置清單，主要利用兩個初始化容器對nginx主容器生成資料和修改資料檔案權限的操作；在spec.template.spec欄位下用initcontainers來定義初始化容器相關內容；
應用配置清單

訪問nginx服務，看看對應資料是否生成？

2.6、Health Check

health check是指對容器做健康狀態檢測；該檢測主要確保容器里的某些服務是否處于健康狀態；該檢測是一個周期性的動作，即每隔幾秒或指定時間周期內進行檢測；

2.6.1、docker health check實作方式

2.6.1.1、在docker-compose實作健康狀態檢測

version: '3.6'
services:
  nginx-service:
    image: nginx:1.20.2 
    container_name: nginx-web1
    expose:
      - 80
      - 443
    ports:
      - "80:80"
      - "443:443"
    restart: always
    healthcheck: #添加服務健康狀態檢查
      test: ["CMD", "curl", "-f", "http://localhost"]
      interval: 5s #健康狀態檢查的間隔時間，默認為30s
      timeout: 5s #單次檢查的失敗超時時間，默認為30s
      retries: 3 #連續失敗次數默認3次，當連續失敗retries次數后將容器置為unhealthy狀態
      start_period: 60s #60s后每間隔interval的時間檢查一次，連續retries次后才將容器置為unhealthy狀態, 但是start_period時間內檢查成功就認為是檢查成功并裝容器置于healthy狀態

應用配置清單

docker-compose -f docker-compose-demo.yaml up -d

驗證容器健康狀態

2.6.1.2、在dockerfile實作健康狀態檢測

FROM nginx:1.20.2

HEALTHCHECK --interval=5s --timeout=2s --retries=3 \
CMD curl --silent --fail localhost:80 || exit 1

生成鏡像

docker build -t mynginx:1.20.2 -f ./dockerfile .

運行容器

docker run -it -d -p 80:80 mynginx:1.20.2

驗證健康狀態檢測

root@k8s-deploy:/compose# docker ps 
CONTAINER ID   IMAGE            COMMAND                  CREATED         STATUS                            PORTS                               NAMES
c3af9bdd5a41   mynginx:1.20.2   "/docker-entrypoint.…"   4 seconds ago   Up 2 seconds (health: starting)   0.0.0.0:80->80/tcp, :::80->80/tcp   keen_brown
root@k8s-deploy:/compose# docker ps 
CONTAINER ID   IMAGE            COMMAND                  CREATED         STATUS                   PORTS                               NAMES
c3af9bdd5a41   mynginx:1.20.2   "/docker-entrypoint.…"   9 seconds ago   Up 8 seconds (healthy)   0.0.0.0:80->80/tcp, :::80->80/tcp   keen_brown
root@k8s-deploy:/compose#

在檢測通過之前容器處于starting狀態,檢測通過(檢測回傳狀態碼為 0)之后為healthy狀態,檢測失敗(檢測回傳狀態碼為 1)之后為unhealthy狀態;

3、kubernetes pod生命周期

pod的生命周期( pod lifecycle)，從pod start時候可以配置postStart檢測，運行程序中可以配置livenessProbe和readinessProbe,最后在 stop前可以配置preStop操作，

3.1、探針簡介

探針是由 kubelet 對容器執行的定期診斷，以保證Pod的狀態始終處于運行狀態，要執行診斷，kubelet 呼叫由容器實作的Handler(處理程式)，也成為Hook(鉤子)，有三種型別的處理程式：

  1. ExecAction #在容器內執行指定命令，如果命令退出時回傳碼為0則認為診斷成功，
  2. TCPSocketAction #對指定埠上的容器的IP地址進行TCP檢查，如果埠打開，則診斷被認為是成功的，
  3. HTTPGetAction：#對指定的埠和路徑上的容器的IP地址執行HTTPGet請求，如果回應的狀態碼大于等于200且小于 400，則診斷被認為是成功的，

每次探測都將獲得以下三種結果之一：

  1. 成功：容器通過了診斷，
  2. 失敗：容器未通過診斷，
  3. 未知：診斷失敗，因此不會采取任何行動，

Pod 重啟策略:Pod 一旦配置探針，在檢測失敗時候，會基于restartPolicy 對 Pod進行下一步操作：

  • restartPolicy (容器重啟策略)：
    • Always：當容器例外時，k8s自動重啟該容器，ReplicationController/Replicaset/Deployment，默認為Always，
    • OnFailure：當容器失敗時(容器停止運行且退出碼不為0)，k8s自動重啟該容器，
    • Never：不論容器運行狀態如何都不會重啟該容器,Job或CronJob
  • imagePullPolicy (鏡像拉取策略)：
    • IfNotPresent：node節點沒有此鏡像就去指定的鏡像倉庫拉取，node有就使用node本地鏡像，
    • Always：每次重建pod都會重新拉取鏡像，
    • Never：從不到鏡像中心拉取鏡像，只使用本地鏡像，

3.2、探針型別

  • startupProbe: #啟動探針,kubernetes v1.16引入
    判斷容器內的應用程式是否已啟動完成，如果配置了啟動探測，則會先禁用所有其它的探測，直到startupProbe檢測成功為止，如果startupProbe探測失敗，則kubelet將殺死容器，容器將按照重啟策略進行下一步操作，如果容器沒有提供啟動探測，則默認狀態為成功
  • livenessProbe: #存活探針
    檢測容器容器是否正在運行，如果存活探測失敗，則kubelet會殺死容器，并且容器將受到其重啟策略的影響，如果容器不提供存活探針，則默認狀態為 Success，livenessProbe用于控制是否重啟pod，
  • readinessProbe: #就緒探針
    如果就緒探測失敗，端點控制器將從與Pod匹配的所有Service的端點中洗掉該Pod的IP地址，初始延遲之前的就緒狀態默認為Failure(失敗)，如果容器不提供就緒探針，則默認狀態為 Success，readinessProbe用于控制pod是否添加至service，

3.3、探針配置引數

探針有很多配置欄位，可以使用這些欄位精確的控制存活和就緒檢測的行為,官方檔案https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

  • initialDelaySeconds: 120 #初始化延遲時間，告訴kubelet在執行第一次探測前應該等待多少秒，默認是0秒，最小值是0，
  • periodSeconds: 60 #探測周期間隔時間，指定了kubelet應該每多少秒秒執行一次存活探測，默認是 10 秒，最小值是 1，
  • timeoutSeconds: 5 #單次探測超時時間，探測的超時后等待多少秒，默認值是1秒，最小值是1，
  • successThreshold: 1 #從失敗轉為成功的重試次數，探測器在失敗后，被視為成功的最小連續成功數，默認值是1，存活探測的這個值必須是1，最小值是 1，
  • failureThreshold：3 #從成功轉為失敗的重試次數，當Pod啟動了并且探測到失敗，Kubernetes的重試次數，存活探測情況下的放棄就意味著重新啟動容器，就緒探測情況下的放棄Pod 會被打上未就緒的標簽，默認值是3，最小值是1，

3.3.1、探針http配置引數

HTTP 探測器可以在 httpGet 上配置額外的欄位

  • host: #連接使用的主機名，默認是Pod的 IP，也可以在HTTP頭中設定 “Host” 來代替，
  • scheme: http #用于設定連接主機的方式（HTTP 還是 HTTPS），默認是 HTTP，
  • path: /monitor/index.html #訪問 HTTP 服務的路徑，
  • httpHeaders: #請求中自定義的 HTTP 頭,HTTP 頭欄位允許重復，
  • port: 80 #訪問容器的埠號或者埠名，如果數字必須在 1 ～ 65535 之間，

3.4、探針示例

3.4.1、使用httpGet實作pod存活性探測

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myserver-myapp-frontend-deployment
  namespace: myserver
spec:
  replicas: 1
  selector:
    matchLabels: #rs or deployment
      app: myserver-myapp-frontend-label
    #matchExpressions:
    #  - {key: app, operator: In, values: [myserver-myapp-frontend,ng-rs-81]}
  template:
    metadata:
      labels:
        app: myserver-myapp-frontend-label
    spec:
      containers:
      - name: myserver-myapp-frontend-label
        image: nginx:1.20.2
        ports:
        - containerPort: 80
        readinessProbe:
        livenessProbe:
          httpGet:
            #path: /monitor/monitor.html
            path: /index.html
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 3
          timeoutSeconds: 1
          successThreshold: 1
          failureThreshold: 3
---
apiVersion: v1
kind: Service
metadata:
  name: myserver-myapp-frontend-service
  namespace: myserver
spec:
  ports:
  - name: http
    port: 81
    targetPort: 80
    nodePort: 40012
    protocol: TCP
  type: NodePort
  selector:
    app: myserver-myapp-frontend-label

上述配置清單，主要描述了使用httpget探針對nginxpod進行存活性探測，探測方法就是對容器的80埠，路徑為/index.html進行每隔3秒訪問一次，探測超時等待1秒，如果連續3次訪問失敗，則該pod存活性探測失敗；只要有一次訪問成功，則該pod存活性探測成功；

3.4.2、使用tcpSocket實作pod存活性探測

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myserver-myapp-frontend-deployment
  namespace: myserver
spec:
  replicas: 1
  selector:
    matchLabels: #rs or deployment
      app: myserver-myapp-frontend-label
    #matchExpressions:
    #  - {key: app, operator: In, values: [myserver-myapp-frontend,ng-rs-81]}
  template:
    metadata:
      labels:
        app: myserver-myapp-frontend-label
    spec:
      containers:
      - name: myserver-myapp-frontend-label
        image: nginx:1.20.2
        ports:
        - containerPort: 80
        livenessProbe:
        #readinessProbe:
          tcpSocket:
            port: 80
            #port: 8080
          initialDelaySeconds: 5
          periodSeconds: 3
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3
---
apiVersion: v1
kind: Service
metadata:
  name: myserver-myapp-frontend-service
  namespace: myserver
spec:
  ports:
  - name: http
    port: 81
    targetPort: 80
    nodePort: 40012
    protocol: TCP
  type: NodePort
  selector:
    app: myserver-myapp-frontend-label

3.4.3、使用exec執行命令的方式實作pod存活性探測

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myserver-myapp-redis-deployment
  namespace: myserver
spec:
  replicas: 1
  selector:
    matchLabels: #rs or deployment
      app: myserver-myapp-redis-label
    #matchExpressions:
    #  - {key: app, operator: In, values: [myserver-myapp-redis,ng-rs-81]}
  template:
    metadata:
      labels:
        app: myserver-myapp-redis-label
    spec:
      containers:
      - name: myserver-myapp-redis-container
        image: redis
        ports:
        - containerPort: 6379
        livenessProbe:
        #readinessProbe:
          exec:
            command:
            #- /apps/redis/bin/redis-cli
            - /usr/local/bin/redis-cli 
            - quit
          initialDelaySeconds: 5
          periodSeconds: 3
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3
      
---
apiVersion: v1
kind: Service
metadata:
  name: myserver-myapp-redis-service
  namespace: myserver
spec:
  ports:
  - name: http
    port: 6379
    targetPort: 6379
    nodePort: 40016
    protocol: TCP
  type: NodePort
  selector:
    app: myserver-myapp-redis-label

3.4.4、啟動探針示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myserver-myapp-frontend-deployment
  namespace: myserver
spec:
  replicas: 1
  selector:
    matchLabels: #rs or deployment
      app: myserver-myapp-frontend-label
    #matchExpressions:
    #  - {key: app, operator: In, values: [myserver-myapp-frontend,ng-rs-81]}
  template:
    metadata:
      labels:
        app: myserver-myapp-frontend-label
    spec:
      containers:
      - name: myserver-myapp-frontend-label
        image: nginx:1.20.2
        ports:
        - containerPort: 80
        startupProbe:
          httpGet:
            path: /index.html
            port: 80
          initialDelaySeconds: 5 #首次檢測延遲5s
          failureThreshold: 3  #從成功轉為失敗的次數
          periodSeconds: 3 #探測間隔周期
---
apiVersion: v1
kind: Service
metadata:
  name: myserver-myapp-frontend-service
  namespace: myserver
spec:
  ports:
  - name: http
    port: 81
    targetPort: 80
    nodePort: 40012
    protocol: TCP
  type: NodePort
  selector:
    app: myserver-myapp-frontend-label

3.4.5、啟動探針，存活探針，就緒探針示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myserver-myapp-frontend-deployment
  namespace: myserver
spec:
  replicas: 3
  selector:
    matchLabels: #rs or deployment
      app: myserver-myapp-frontend-label
    #matchExpressions:
    #  - {key: app, operator: In, values: [myserver-myapp-frontend,ng-rs-81]}
  template:
    metadata:
      labels:
        app: myserver-myapp-frontend-label
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: myserver-myapp-frontend-label
        image: nginx:1.20.2
        ports:
        - containerPort: 80
        startupProbe:
          httpGet:
            path: /index.html
            port: 80
          initialDelaySeconds: 5 #首次檢測延遲5s
          failureThreshold: 3  #從成功轉為失敗的次數
          periodSeconds: 3 #探測間隔周期
        readinessProbe:
          httpGet:
            #path: /monitor/monitor.html
            path: /index.html
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 3
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3
        livenessProbe:
          httpGet:
            #path: /monitor/monitor.html
            path: /index.html
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 3
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3
---
apiVersion: v1
kind: Service
metadata:
  name: myserver-myapp-frontend-service
  namespace: myserver
spec:
  ports:
  - name: http
    port: 81
    targetPort: 80
    nodePort: 40012
    protocol: TCP
  type: NodePort
  selector:
    app: myserver-myapp-frontend-label

3.5、postStart and preStop handlers簡介

官方檔案https://kubernetes.io/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/
postStart 和 preStop handlers 處理函式

  • postStart：Pod啟動后立即執行指定的擦操作:
    • Pod被創建后立即執行,即不等待pod中的服務啟動，
    • 如果postStart執行失敗pod不會繼續創建，
  • preStop：
    • pod被停止之前執行的動作，
    • 如果preStop一直執行不完成，則最后寬限2秒后強制洗掉，

3.5.1、postStart and preStop handlers示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myserver-myapp1-lifecycle
  labels:
    app: myserver-myapp1-lifecycle
  namespace: myserver
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myserver-myapp1-lifecycle-label
  template:
    metadata:
      labels:
        app: myserver-myapp1-lifecycle-label
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: myserver-myapp1-lifecycle-label
        image: tomcat:7.0.94-alpine 
        lifecycle:
          postStart:
            exec:
             #command: 把自己注冊到注冊在中心
              command: ["/bin/sh", "-c", "echo 'Hello from the postStart handler' >> /usr/local/tomcat/webapps/ROOT/index.html"]

            #httpGet:
            #  #path: /monitor/monitor.html
            #  host: www.magedu.com
            #  port: 80
            #  scheme: HTTP
            #  path: index.html
          preStop:
            exec:
             #command: 把自己從注冊中心移除
              command:
                - /bin/bash
                - -c
                - 'sleep 10000000'
              #command: ["/usr/local/tomcat/bin/catalina.sh","stop"]
              #command: ['/bin/sh','-c','/path/preStop.sh']
        ports:
          - name: http
            containerPort: 8080

---
apiVersion: v1
kind: Service
metadata:
  name: myserver-myapp1-lifecycle-service
  namespace: myserver
spec:
  ports:
  - name: http
    port: 80
    targetPort: 8080
    nodePort: 30012
    protocol: TCP
  type: NodePort
  selector:
    app: myserver-myapp1-lifecycle-label

3.6、Pod的終止流程

  1. 向API-Server提交洗掉請求、API-Server完成鑒權和準入并將事件寫入etcd
  2. Pod被設定為”Terminating”狀態、從service的Endpoints串列中洗掉并不再接受客戶端請求，
  3. pod執行PreStop
  4. kubelet向pod中的容器發送SIGTERM信號(正常終止信號)終止pod里面的主行程，這個信號讓容器知道自己很快將會被關閉terminationGracePeriodSeconds: 60 #可選終止等待期(pod洗掉寬限期)，如果有設定洗掉寬限時間，則等待寬限時間到期，否則最多等待30s，Kubernetes等待指定的時間稱為優雅終止寬限期,默認情況下是30秒,值得注意的是等待期與preStop Hook和SIGTERM信號并行執行，即Kubernetes可能不會等待preStop Hook完成(最長30秒之后主行程還沒有結束就就強制終止pod)，
  5. SIGKILL信號被發送到Pod，并洗掉Pod
作者：Linux-1874 出處：https://www.cnblogs.com/qiuhom-1874/ 本文著作權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利.

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/553985.html

標籤：其他

上一篇：React Native+小程式容器=更高的開發效率

下一篇：返回列表

標籤雲
其他(160110) Python(38193) JavaScript(25469) Java(18172) C(15235) 區塊鏈(8268) C＃(7972) AI(7469) 爪哇(7425) MySQL(7219) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5873) 数组(5741) R(5409) Linux(5344) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4580) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2434) ASP.NET(2403) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) .NET技术(1979) 功能(1967) Web開發(1951) HtmlCss(1950) C++(1928) python-3.x(1918) 弹簧靴(1913) xml(1889) PostgreSQL(1879) .NETCore(1863) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 網閘典型架構簡述

    網閘架構一般分為兩種：三主機的三系統架構網閘和雙主機的2+1架構網閘。 三主機架構分別為內端機、外端機和仲裁機。三機無論從軟體和硬體上均各自獨立。首先從硬體上來看，三機都用各自獨立的主板、記憶體及存盤設備。從軟體上來看，三機有各自獨立的作業系統。這樣能達到完全的三機獨立。對于“2+1”系統，“2”分為 ......

    uj5u.com 2020-09-10 02:00:44 more
  • 如何從xshell上傳檔案到centos linux虛擬機里

    如何從xshell上傳檔案到centos linux虛擬機里及：虛擬機CentOs下執行 yum -y install lrzsz命令，出現錯誤：鏡像無法找到軟體包 前言 一、安裝lrzsz步驟 二、上傳檔案 三、遇到的問題及解決方案 總結 前言 提示：其實很簡單，往虛擬機上安裝一個上傳檔案的工具 ......

    uj5u.com 2020-09-10 02:00:47 more
  • 一、SQLMAP入門

    一、SQLMAP入門 1、判斷是否存在注入 sqlmap.py -u 網址/id=1 id=1不可缺少。當注入點后面的引數大于兩個時。需要加雙引號， sqlmap.py -u "網址/id=1&uid=1" 2、判斷文本中的請求是否存在注入 從文本中加載http請求，SQLMAP可以從一個文本檔案中 ......

    uj5u.com 2020-09-10 02:00:50 more
  • Metasploit 簡單使用教程

    metasploit 簡單使用教程 浩先生， 2020-08-28 16:18:25 分類專欄： kail 網路安全 linux 文章標簽： linux資訊安全 編輯 著作權 metasploit 使用教程 前言 一、Metasploit是什么？ 二、準備作業 三、具體步驟 前言 Msfconsole ......

    uj5u.com 2020-09-10 02:00:53 more
  • 游戲逆向之驅動層與用戶層通訊

    驅動層代碼： #pragma once #include <ntifs.h> #define add_code CTL_CODE(FILE_DEVICE_UNKNOWN,0x800,METHOD_BUFFERED,FILE_ANY_ACCESS) /* 更多游戲逆向視頻www.yxfzedu.com ......

    uj5u.com 2020-09-10 02:00:56 more
  • 北斗電力時鐘（北斗授時服務器）讓網路資料更精準

    北斗電力時鐘（北斗授時服務器）讓網路資料更精準 北斗電力時鐘（北斗授時服務器）讓網路資料更精準 京準電子科技官微——ahjzsz 近幾年，資訊技術的得了快速發展，互聯網在逐漸普及，其在人們生活和生產中都得到了廣泛應用，并且取得了不錯的應用效果。計算機網路資訊在電力系統中的應用，一方面使電力系統的運行 ......

    uj5u.com 2020-09-10 02:01:03 more
  • 【CTF】CTFHub 技能樹 彩蛋 writeup

    ?碎碎念 CTFHub：https://www.ctfhub.com/ 筆者入門CTF時時剛開始刷的是bugku的舊平臺，后來才有了CTFHub。 感覺不論是網頁UI設計，還是題目質量，賽事跟蹤，工具軟體都做得很不錯。 而且因為獨到的金幣制度的確讓人有一種想去刷題賺金幣的感覺。 個人還是非常喜歡這個 ......

    uj5u.com 2020-09-10 02:04:05 more
  • 02windows基礎操作

    我學到了一下幾點 Windows系統目錄結構與滲透的作用 常見Windows的服務詳解 Windows埠詳解 常用的Windows注冊表詳解 hacker DOS命令詳解（net user / type /md /rd/ dir /cd /net use copy、批處理 等） 利用dos命令制作 ......

    uj5u.com 2020-09-10 02:04:18 more
  • 03.Linux基礎操作

    我學到了以下幾點 01Linux系統介紹02系統安裝，密碼啊破解03Linux常用命令04LAMP 01LINUX windows： win03 8 12 16 19 配置不繁瑣 Linux：redhat,centos(紅帽社區版)，Ubuntu server,suse unix:金融機構，證券，銀 ......

    uj5u.com 2020-09-10 02:04:30 more
  • 05HTML

    01HTML介紹 02頭部標簽講解03基礎標簽講解04表單標簽講解 HTML前段語言 js1.了解代碼2.根據代碼 懂得挖掘漏洞 （POST注入/XSS漏洞上傳）3.黑帽seo 白帽seo 客戶網站被黑帽植入劫持代碼如何處理4.熟悉html表單 <html><head><title>TDK標題，描述 ......

    uj5u.com 2020-09-10 02:04:36 more
最新发布
  • K8s Pod狀態與容器探針

    Pause 容器，又叫 Infra 容器，是pod的基礎容器，鏡像體積只有幾百KB左右，配置在kubelet中，主要的功能是一個pod中多個容器的網路通信。
    Infra 容器被創建后會初始化 Network Namespace，之后其它容器就可以加入到 Infra 容器中共享Infra 容器的網路了... ......

    uj5u.com 2023-06-01 08:46:37 more
  • React Native+小程式容器=更高的開發效率

    React Native是由Facebook開發并于2015年首次發布的一個框架，用于構建原始的移動應用程式。 它具有許多技術上的優勢： 跨平臺開發：使用React Native，您可以使用相同的代碼庫構建同時運行在iOS和Android平臺上的應用程式。這種跨平臺的開發方式可以大大減少開發作業量和 ......

    uj5u.com 2023-06-01 08:23:46 more
  • ChatGPT正式登陸iOS平臺

    6天前，ChatGPT在美區App Store中上架了官方App，累計下載量已經突破 50 萬次，OpenAI 的 ChatGPT 應用在上架之后，其熱度遠超必應聊天等聊天機器人，以及其它使用 GPT-4 的第三方應用。 3.5是免費的，GPT4是收費的，需要開通Plus會員，還集成了OpenAI的 ......

    uj5u.com 2023-06-01 08:23:42 more
  • 4.4. 物件序列化與反序列化

    在本節中，我們將詳細討論Java中的物件序列化與反序列化概念、使用方法以及實體。物件序列化是將物件的狀態資訊轉換為位元組流的程序，而反序列化則相反，是將位元組流恢復為物件的程序。 #### 4.4.1 為什么需要物件序列化？ 物件序列化的主要目的是為了在不同的系統間傳輸物件，或者將物件持久化到磁盤檔案中 ......

    uj5u.com 2023-06-01 08:23:36 more
  • 玩轉服務器之網站篇：新手使用WordPress搭建博客和靜態網站部署

    在之前的玩轉服務器系列文章里，我們介紹了如何構建小型的高可用環境、PHP、Python、Java web、docker環境部署，以及Node.js SSR應用，本篇文章主要介紹新手也能快速上手的WordPress博客搭建和靜態網站部署的教程 ......

    uj5u.com 2023-06-01 08:23:31 more
  • 解讀與用戶一起“跳動”的開源實時監控工具 HertzBeat

    摘要：開源專案遇上華為云，會擦出怎樣的火花？ 在本期《開源實時監控工具HertzBeat如何與用戶一起“跳動？ 》的主題直播中，HertzBeat & TanCloud 創始人鞏超與開發者和伙伴朋友們交流當前主流指標監控方案，解讀HertzBeat及能力特點，并為大家演示了如何通過華為云商店安裝部署 ......

    uj5u.com 2023-06-01 08:23:16 more
  • 基于AIGC的京東購物助手的技術方案設想

    隨著AIGC的爆火，ChatGPT，GPT-4的發布，我作為一個演算法作業者，深感AI發展的迅猛。最近，OpenAI的插件和聯網功能陸續向用戶公開，我也在第一時間試用了這些最新的功能。在OpenAI的插件市場上，我被一個可以幫助分析食譜，并生成購物清單的功能所吸引。 ......

    uj5u.com 2023-06-01 08:22:53 more
  • 【經驗分享】銳捷EVE在火狐游覽器中，取消一律打開此應用的選項，重

    # 環境： >工具：銳捷EVE模擬器，火狐游覽器，SecureCRT_8.7 系統版本：Windows 10 # 需求描述： >描述：在選擇一律使用此程式打開應用后，找不到取消的地方，也因此無法更改打開的應用。 >提示： >若按照教程還是無法完成操作，可以進入右側的企鵝，找我看看，或者進嗶哩嗶哩自行 ......

    uj5u.com 2023-06-01 08:22:39 more
  • C端用戶體驗度量實戰篇-京東快遞小程式體驗度量全面升級

    本文通過介紹體驗度量模型升級研究程序、研究方法及研究結果等內容，結合實際C端產品應用，觀測新模型運行周期的表現，驗證了其在高速發展的業務形態和日益變化的用戶需求上的適用性和有效性。 ......

    uj5u.com 2023-06-01 08:22:33 more
  • 爛慫if-else代碼優化方案

    # 0.問題概述 代碼可讀性是衡量代碼質量的重要標準，可讀性也是可維護性、可擴展性的保證，因為代碼是連接程式員和機器的中間橋梁，要對雙邊友好。Quora 上有一個帖子： “What are some of the most basic things every programmer should k ......

    uj5u.com 2023-06-01 08:22:20 more

Copyright © 2010-2020 有解無憂