k8s -深入瞭解 Pod

阿新 • • 發佈：2021-11-08

一、資源限制

當定義 Pod 時可以選擇性地為每個容器設定所需要的資源數量。最常見的可設定資源是 CPU 和記憶體大小，以及其他型別的資源

當為 Pod 中的容器指定了 request 資源時，排程器就使用該資訊來決定將 Pod 排程到哪個節點上。當還為容器指定了 limit 資源時，kubelet 就會確保執行的容器不會使用超出所設的 limit 資源量。kubelet 還會為容器預留所設的 request 資源量，供該容器使用

如果 Pod 執行所在的節點具有足夠的可用資源，容器可以使用超出所設定的 request 資源量。不過，容器不可以使用超出所設定的 limit 資源量

如果給容器設定了記憶體的 limit 值，但未設定記憶體的 request 值，Kubernetes 會自動為其設定與記憶體 limit 相匹配的 request 值。類似的，如果給容器設定了 CPU 的 limit 值但未設定 CPU 的 request 值，則 Kubernetes 自動為其設定 CPU 的 request 值並使之與 CPU 的 limit 值匹配

官網示例：
https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

======Pod 和 容器 的資源請求和限制：======
spec.containers[].resources.requests.cpu		//定義建立容器時預分配的CPU資源
spec.containers[].resources.requests.memory		//定義建立容器時預分配的記憶體資源
spec.containers[].resources.limits.cpu			//定義 cpu 的資源上限
spec.containers[].resources.limits.memory		//定義記憶體的資源上限

二.CPU資源單位

CPU 資源的 request 和 limit 以 cpu 為單位。Kubernetes 中的一個 cpu 相當於1個 vCPU（1個超執行緒）

Kubernetes 也支援帶小數 CPU 的請求。spec.containers[].resources.requests.cpu 為 0.5 的容器能夠獲得一個 cpu 的一半 CPU 資源（類似於Cgroup對CPU資源的時間分片）

表示式 0.1 等價於表示式 100m（毫核），表示每 1000 毫秒內容器可以使用的 CPU 時間總量為 0.1*1000 毫秒

三、記憶體資源單位

記憶體的 request 和 limit 以位元組為單位。可以以整數表示，或者以10為底數的指數的單位（E、P、T、G、M、K）來表示，或者以2為底數的指數的單位（Ei、Pi、Ti、Gi、Mi、Ki）來表示

如：1KB=10^3=1000，1MB=10^6=1000000=1000KB，1GB=10^9=1000000000=1000MB
   1KiB=2^10=1024，1MiB=2^20=1048576=1024KiB

PS：在買硬碟的時候，作業系統報的數量要比產品標出或商家號稱的小一些，主要原因是標出的是以 MB、GB為單位的，1GB 就是1,000,000,000Byte，而作業系統是以2進製為處理單位的，因此檢查硬碟容量時是以MiB、GiB為單位，1GB=2^30=1,073,741,824，相比較而言，1GiB要比1GB多出1,073,741,824-1,000,000,000=73,741,824Byte，所以檢測實際結果要比標出的少一些。

======示例1：======
apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

此例子中的 Pod 有兩個容器。每個容器的 request 值為 0.25 cpu 和 64MiB 記憶體，每個容器的 limit 值為 0.5 cpu 和 128MiB 記憶體。那麼可以認為該 Pod 的總的資源 request 為 0.5 cpu 和 128 MiB 記憶體，總的資源 limit 為 1 cpu 和 256MiB 記憶體

======示例2：======
vim pod2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: web
    image: nginx
    env:
    - name: WEB_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: wp
    image: wordpress
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"


kubectl apply -f pod2.yaml
kubectl describe pod frontend

kubectl get pods -o wide
NAME       READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
frontend   2/2     Running   5          15m   10.244.2.4   node02   <none>           <none>

kubectl describe nodes node02				#由於當前虛擬機器有2個CPU，所以Pod的CPU Limits一共佔用了50%
Namespace                  Name                           CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE
  ---------                  ----                           ------------  ----------  ---------------  -------------  ---
  default                    frontend                       500m (25%)    1 (50%)     128Mi (3%)       256Mi (6%)     16m
  kube-system                kube-flannel-ds-amd64-f4pbp    100m (5%)     100m (5%)   50Mi (1%)        50Mi (1%)      19h
  kube-system                kube-proxy-pj4wp               0 (0%)        0 (0%)      0 (0%)           0 (0%)         19h
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests    Limits
  --------           --------    ------
  cpu                600m (30%)  1100m (55%)
  memory             178Mi (4%)  306Mi (7%)
  ephemeral-storage  0 (0%)      0 (0%)

四、重啟策略

Pod 在遇到故障之後重啟的動作
1.Always：當容器終止退出後，總是重啟容器，預設策略
2.OnFailure：當容器異常退出（退出狀態碼非0）時，重啟容器；正常退出則不重啟容器
3.Never：當容器終止退出，從不重啟容器

注：K8S 中不支援重啟 Pod 資源，只有刪除重建

======示例======
vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 30; exit 3


kubectl apply -f pod3.yaml

======檢視Pod狀態，等容器啟動後30秒後執行exit退出程序進入error狀態，就會重啟次數加1======
kubectl get pods
NAME                              READY   STATUS             RESTARTS   AGE
foo                               1/1     Running            1          50s


kubectl delete -f pod3.yaml

vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 30; exit 3
  restartPolicy: Never
#注意：跟container同一個級別

kubectl apply -f pod3.yaml

//容器進入error狀態不會進行重啟
kubectl get pods -w

五、健康檢查（探針 Probe）

探針是由kubelet對容器執行的定期診斷

探針的三種規則：
●livenessProbe ： 判斷容器是否正在執行。如果探測失敗，則kubelet會殺死容器，並且容器將根據 restartPolicy 來設定 Pod 狀態。如果容器不提供存活探針，則預設狀態為Success。

●readinessProbe ： 判斷容器是否準備好接受請求。如果探測失敗，端點控制器將從與 Pod 匹配的所有 service endpoints 中剔除刪除該Pod的IP地址。初始延遲之前的就緒狀態預設為Failure。如果容器不提供就緒探針，則預設狀態為Success。

●startupProbe （這個1.17版本增加的）：判斷容器內的應用程式是否已啟動，主要針對於不能確定具體啟動時間的應用。如果配置了 startupProbe 探測，在則在 startupProbe 狀態為 Success 之前，其他所有探針都處於無效狀態，直到它成功後其他探針才起作用。如果 startupProbe 失敗，kubelet 將殺死容器，容器將根據 restartPolicy 來重啟。如果容器沒有配置 startupProbe，則預設狀態為 Success

注：以上規則可以同時定義。在readinessProbe檢測成功之前，Pod的running狀態是不會變成ready狀態的

Probe支援三種檢查方法：
●exec ： 在容器內執行指定命令。如果命令退出時返回碼為0則認為診斷成功

●tcpSocket ： 對指定埠上的容器的IP地址進行TCP檢查（三次握手）。如果埠開啟，則診斷被認為是成功的

●httpGet ： 對指定的埠和路徑上的容器的IP地址執行HTTPGet請求。如果響應的狀態碼大於等於200且小於400，則診斷被認為是成功的

每次探測都將獲得以下三種結果之一：
●成功：容器通過了診斷。
●失敗：容器未通過診斷。
●未知：診斷失敗，因此不會採取任何行動

官網示例：

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

======示例1：exec方式======
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      failureThreshold: 1
      initialDelaySeconds: 5
      periodSeconds: 5

#initialDelaySeconds：指定 kubelet 在執行第一次探測前應該等待5秒，即第一次探測是在容器啟動後的第6秒才開始執行。預設是 0 秒，最小值是 0。
#periodSeconds：指定了 kubelet 應該每 5 秒執行一次存活探測。預設是 10 秒。最小值是 1。
#failureThreshold: 當探測失敗時，Kubernetes 將在放棄之前重試的次數。 存活探測情況下的放棄就意味著重新啟動容器。就緒探測情況下的放棄 Pod 會被打上未就緒的標籤。預設值是 3。最小值是 1。
#timeoutSeconds：探測的超時後等待多少秒。預設值是 1 秒。最小值是 1。（在 Kubernetes 1.20 版本之前，exec 探針會忽略 timeoutSeconds 探針會無限期地 持續執行，甚至可能超過所配置的限期，直到返回結果為止。）

vim exec.yaml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
  namespace: default
spec:
  containers:
  - name: liveness-exec-container
    image: busybox
    imagePullPolicy: IfNotPresent
    command: ["/bin/sh","-c","touch /tmp/live ; sleep 30; rm -rf /tmp/live; sleep 3600"]
    livenessProbe:
      exec:
        command: ["test","-e","/tmp/live"]
      initialDelaySeconds: 1
      periodSeconds: 3

kubectl create -f exec.yaml

kubectl describe pods liveness-exec
Events:
  Type     Reason     Age               From               Message
  ----     ------     ----              ----               -------
  Normal   Scheduled  51s               default-scheduler  Successfully assigned default/liveness-exec-pod to node02
  Normal   Pulled     46s               kubelet, node02    Container image "busybox" already present on machine
  Normal   Created    46s               kubelet, node02    Created container liveness-exec-container
  Normal   Started    45s               kubelet, node02    Started container liveness-exec-container
  Warning  Unhealthy  8s (x3 over 14s)  kubelet, node02    Liveness probe failed:
  Normal   Killing    8s                kubelet, node02    Container liveness-exec-container failed liveness probe,will be restarted

kubectl get pods -w
NAME                READY   STATUS    RESTARTS   AGE
liveness-exec       1/1     Running   1          85s

可以看到 Pod 中只有一個容器。kubelet 在執行第一次探測前需要等待 5 秒，kubelet 會每 5 秒執行一次存活探測。kubelet 在容器內執行命令 cat /tmp/healthy 來進行探測。如果命令執行成功並且返回值為 0，kubelet 就會認為這個容器是健康存活的。當到達第 31 秒時，這個命令返回非 0 值，kubelet 會殺死這個容器並重新啟動它

======示例2：httpGet方式======
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

在這個配置檔案中，可以看到 Pod 也只有一個容器。initialDelaySeconds 欄位告訴 kubelet 在執行第一次探測前應該等待 3 秒。periodSeconds 欄位指定了 kubelet 每隔 3 秒執行一次存活探測。kubelet 會向容器內執行的服務（服務會監聽 8080 埠）傳送一個 HTTP GET 請求來執行探測。如果伺服器上 /healthz 路徑下的處理程式返回成功程式碼，則 kubelet 認為容器是健康存活的。如果處理程式返回失敗程式碼，則 kubelet 會殺死這個容器並且重新啟動它。

任何大於或等於 200 並且小於 400 的返回程式碼標示成功，其它返回程式碼都標示失敗。

vim httpget.yaml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget
  namespace: default
spec:
  containers:
  - name: liveness-httpget-container
    image: soscscs/myapp:v1
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    livenessProbe:
      httpGet:
        port: http
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 10

kubectl create -f httpget.yaml

kubectl exec -it liveness-httpget -- rm -rf /usr/share/nginx/html/index.html

kubectl get pods
NAME               READY   STATUS    RESTARTS   AGE
liveness-httpget   1/1     Running   1          2m44s

======示例3：tcpSocket方式======
apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

這個例子同時使用 readinessProbe 和 livenessProbe 探測。kubelet 會在容器啟動 5 秒後傳送第一個 readinessProbe 探測。這會嘗試連線 goproxy 容器的 8080 埠。如果探測成功，kubelet 將繼續每隔 10 秒執行一次檢測。除了 readinessProbe 探測，這個配置包括了一個 livenessProbe 探測。kubelet 會在容器啟動 15 秒後進行第一次 livenessProbe 探測。就像 readinessProbe 探測一樣，會嘗試連線 goproxy 容器的 8080 埠。如果 livenessProbe 探測失敗，這個容器會被重新啟動。

vim tcpsocket.yaml
apiVersion: v1
kind: Pod
metadata:
  name: probe-tcp
spec:
  containers:
  - name: nginx
    image: soscscs/myapp:v1
    livenessProbe:
      initialDelaySeconds: 5
      timeoutSeconds: 1
      tcpSocket:
        port: 8080
      periodSeconds: 3

kubectl create -f tcpsocket.yaml

kubectl exec -it probe-tcp  -- netstat -natp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1/nginx: master pro

kubectl get pods -w
NAME        READY   STATUS    RESTARTS   AGE
probe-tcp   1/1     Running   0          4s
probe-tcp   1/1     Running   1          14s
probe-tcp   1/1     Running   2          26s

======示例4：就緒檢測======
vim readiness-httpget.yaml
apiVersion: v1
kind: Pod
metadata:
  name: readiness-httpget
  namespace: default
spec:
  containers:
  - name: readiness-httpget-container
    image: soscscs/myapp:v1
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index1.html
      initialDelaySeconds: 1
      periodSeconds: 3
    livenessProbe:
      httpGet:
        port: http
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 10

kubectl create -f readiness-httpget.yaml

//readiness探測失敗，無法進入READY狀態
kubectl get pods
NAME                READY   STATUS    RESTARTS   AGE
readiness-httpget   0/1     Running   0          18s

kubectl exec -it readiness-httpget sh
 # cd /usr/share/nginx/html/
 # ls
50x.html    index.html
 # echo 123 > index1.html
 # exit

kubectl get pods
NAME                READY   STATUS    RESTARTS   AGE
readiness-httpget   1/1     Running   0          2m31s

kubectl exec -it readiness-httpget -- rm -rf /usr/share/nginx/html/index.html

kubectl get pods -w
NAME                READY   STATUS    RESTARTS   AGE
readiness-httpget   1/1     Running   0          4m10s
readiness-httpget   0/1     Running   1          4m15s

======示例5：就緒檢測2======
vim readiness-myapp.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp1
  labels:
     app: myapp
spec:
  containers:
  - name: myapp
    image: soscscs/myapp:v1
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10
---
apiVersion: v1
kind: Pod
metadata:
  name: myapp2
  labels:
     app: myapp
spec:
  containers:
  - name: myapp
    image: soscscs/myapp:v1
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10
---
apiVersion: v1
kind: Pod
metadata:
  name: myapp3
  labels:
     app: myapp
spec:
  containers:
  - name: myapp
    image: soscscs/myapp:v1
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
  type: ClusterIP
  ports:
  - name: http
    port: 80
    targetPort: 80

kubectl create -f readiness-myapp.yaml

kubectl get pods,svc,endpoints -o wide
NAME         READY   STATUS    RESTARTS   AGE     IP            NODE     NOMINATED NODE   READINESS GATES
pod/myapp1   1/1     Running   0          3m42s   10.244.2.13   node02   <none>           <none>
pod/myapp2   1/1     Running   0          3m42s   10.244.1.15   node01   <none>           <none>
pod/myapp3   1/1     Running   0          3m42s   10.244.2.14   node02   <none>           <none>

NAME                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE     SELECTOR
......
service/myapp        ClusterIP   10.96.138.13   <none>        80/TCP    3m42s   app=myapp

NAME                   ENDPOINTS                                      AGE
......
endpoints/myapp        10.244.1.15:80,10.244.2.13:80,10.244.2.14:80   3m42s


kubectl exec -it pod/myapp1 -- rm -rf /usr/share/nginx/html/index.html

//readiness探測失敗，Pod 無法進入READY狀態，且端點控制器將從 endpoints 中剔除刪除該 Pod 的 IP 地址
kubectl get pods,svc,endpoints -o wide
NAME         READY   STATUS    RESTARTS   AGE     IP            NODE     NOMINATED NODE   READINESS GATES
pod/myapp1   0/1     Running   0          5m17s   10.244.2.13   node02   <none>           <none>
pod/myapp2   1/1     Running   0          5m17s   10.244.1.15   node01   <none>           <none>
pod/myapp3   1/1     Running   0          5m17s   10.244.2.14   node02   <none>           <none>

NAME                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE     SELECTOR
......
service/myapp        ClusterIP   10.96.138.13   <none>        80/TCP    5m17s   app=myapp

NAME                   ENDPOINTS                       AGE
......
endpoints/myapp        10.244.1.15:80,10.244.2.14:80   5m17s

======啟動、退出動作======
vim post.yaml
apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: soscscs/myapp:v1
    lifecycle:   #此為關鍵欄位
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler >> /var/log/nginx/message"]
      preStop:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the poststop handler >> /var/log/nginx/message"]
    volumeMounts:
    - name: message-log
      mountPath: /var/log/nginx/
      readOnly: false
  initContainers:
  - name: init-myservice
    image: soscscs/myapp:v1
    command: ["/bin/sh", "-c", "echo 'Hello initContainers' >> /var/log/nginx/message"]
    volumeMounts:
    - name: message-log
      mountPath: /var/log/nginx/
      readOnly: false
  volumes:
  - name: message-log
    hostPath:
      path: /data/volumes/nginx/log/
      type: DirectoryOrCreate

kubectl create -f post.yaml

kubectl get pods -o wide
NAME             READY   STATUS    RESTARTS   AGE    IP            NODE     NOMINATED NODE   READINESS GATES
lifecycle-demo   1/1     Running   0          2m8s   10.244.2.28   node02   <none>           <none>

kubectl exec -it lifecycle-demo -- cat /var/log/nginx/message
Hello initContainers
Hello from the postStart handler

//在 node02 節點上檢視
[root@node02 ~]# cd /data/volumes/nginx/log/
[root@node02 log]# ls
access.log  error.log  message
[root@node02 log]# cat message
Hello initContainers
Hello from the postStart handler
#由上可知，init Container先執行，然後當一個主容器啟動後，Kubernetes 將立即傳送 postStart 事件。

//刪除 pod 後，再在 node02 節點上檢視
kubectl delete pod lifecycle-demo

[root@node02 log]# cat message
Hello initContainers
Hello from the postStart handler
Hello from the poststop handler
#由上可知，當在容器被終結之前， Kubernetes 將傳送一個 preStop 事件。

k8s -深入瞭解 Pod

一、資源限制

二.CPU資源單位

三、記憶體資源單位

四、重啟策略

五、健康檢查（探針 Probe）

k8s -深入瞭解 Pod

Kubernetes 入門：深入瞭解 Pod

深入瞭解Netty【五】執行緒模型

深入瞭解Netty【六】Netty工作原理

深入瞭解Kafka【一】概述與基礎架構

深入瞭解Kafka【二】工作流程及檔案儲存機制

深入瞭解Netty【八】TCP拆包、粘包和解決方案

深入瞭解Netty【七】Netty核心元件

深入瞭解Netty【四】IO模型

深入瞭解Netty【一】BIO、NIO、AIO簡單介紹

深入瞭解Kafka【三】資料可靠性分析

深入瞭解Kafka【五】Partition和消費者的關係

深入瞭解Kafka【四】消費者的Offset管理

深入瞭解Redis底層資料結構

深入瞭解java中的string物件

深入瞭解JVM位元組碼增強技術

深入瞭解Spring中Bean的作用域和生命週期

深入瞭解SQL注入

深入瞭解如何基於Python讀寫Kafka

深入瞭解Python在HDA中的應用

k8s -深入瞭解 Pod

一、資源限制

二.CPU資源單位

三、記憶體 資源單位

四、重啟策略

五、健康檢查（探針 Probe）

相關推薦

三、記憶體資源單位