1. リソースの制限

ポッドを定義するときに、各コンテナに必要なリソースの数をオプションで設定できます。最も一般的な構成可能なリソースは、数あるリソースの中でも特に CPU とメモリのサイズです。

ポッド内のコンテナにリクエストリソースが指定されている場合、それはコンテナの実行に必要なリソースの最小量を表し、スケジューラはこの情報を使用してポッドをどのノードにスケジュールするかを決定します。コンテナーに制限リソースも指定されている場合、kubelet は、実行中のコンテナーが設定された制限リソースを超えて使用しないようにします。Kubelet は、コンテナーが使用するために、コンテナーの設定されたリクエストリソース量も予約します。

ポッドが実行されているノードに十分な利用可能なリソースがある場合、コンテナは設定されたリクエストよりも多くのリソースを使用できます。ただし、コンテナーは設定された制限を超えるリソースを使用できません。

コンテナーにメモリ制限値が設定されているが、メモリリクエスト値が設定されていない場合、Kubernetes はメモリ制限に一致するリクエスト値を自動的に設定します。同様に、コンテナに CPU 制限値が設定されているが、CPU リクエスト値が設定されていない場合、Kubernetes はコンテナの CPU リクエスト値を自動的に設定し、それを CPU 制限値と照合します。

公式サイトの例

https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

ポッドとコンテナのリソースリクエストと制限:

spec.containers[].resources.requests.cpu		//定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory		//定义创建容器时预分配的内存资源
spec.containers[].resources.limits.cpu			//定义 cpu 的资源上限 
spec.containers[].resources.limits.memory		//定义内存的资源上限

CPUリソースユニット

CPU リソースの要求と制限は cpu にあります。Kubernetes の 1 つの 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 ミリ秒であることを意味します。

Kubernetes では、1m 未満の精度で CPU リソースを設定することはできません。

メモリリソースユニット

メモリの要求と制限はバイト単位です。これは、整数として、または 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

例 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"

この例のポッドには 2 つのコンテナがあります。各コンテナのリクエスト値は 0.25 cpu と 64MiB のメモリで、各コンテナの制限値は 0.5 cpu と 128MiB のメモリです。この場合、Pod のリソース要求の合計は 0.5 CPU とメモリ 128 MiB、リソース制限の合計は 1 CPU と 256 MiB であると考えることができます。

例 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: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "abc123"
    resources:
      requests:
        memory: "512Mi"
        cpu: "0.5"
      limits:
        memory: "1Gi"
        cpu: "1"

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%)

ここに画像の説明を挿入します

2. 再スタート戦略

ポッド内のコンテナが終了したら、ノード上の kubelet を通じてコンテナを再起動します。ポッド内のすべてのコンテナに適用されます。

1. Always: コンテナが終了して終了するときは、常にコンテナを再起動します。デフォルトポリシー
2. OnFailure: コンテナが異常終了した場合 (終了ステータスコードが 0 以外)、コンテナを再起動します。正常に終了した場合、コンテナは再起動されません。
3. Never: コンテナ終了時コンテナを終了し、決して再起動しないでください。
#注意: K8S は Pod リソースの再起動をサポートせず、削除と再構築のみをサポートします。
yaml を使用して Deployment タイプと StatefulSet タイプを作成する場合、restartPolicy は Always のみにすることができます。kubectl の実行でポッドを作成するときは、Always、OnFailure、Never の 3 つの戦略を選択できます。

kubectl edit deployment nginx-deployment
......
  restartPolicy: Always


//示例
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

ここに画像の説明を挿入します

3. ヘルスチェック (プローブとも呼ばれます)

プローブは、kubelet によってコンテナー上で実行される定期的な診断です。

プローブに関する 3 つのルール:

●livenessProbe: コンテナが実行されているかどうかを判断します。プローブが失敗した場合、kubelet はコンテナーを強制終了し、コンテナーは restartPolicy に従ってポッドの状態を設定します。コンテナーが liveness プローブを提供しない場合、デフォルトのステータスは成功です。

●readinessProbe: コンテナがリクエストを受け入れる準備ができているかどうかを判断します。検出に失敗した場合、エンドポイントコントローラーは、ポッドに一致するすべてのサービスエンドポイントからポッドの IP アドレスを削除します。初期遅延前の準備完了状態はデフォルトで失敗になります。コンテナーが Readiness プローブを提供しない場合、デフォルトのステータスは成功です。

●startupProbe (バージョン 1.17 で追加): 主に具体的な起動時間を判断できないアプリケーションに対して、コンテナ内のアプリケーションが起動したかどうかを判断します。startupProbe プローブが設定されている場合、startupProbe ステータスが Success になるまで他のすべてのプローブは非アクティブになり、成功するまで他のプローブは有効になりません。startProbe が失敗した場合、kubelet はコンテナを強制終了し、コンテナは restartPolicy に従って再起動されます。コンテナーがstartupProbeで構成されていない場合、デフォルトのステータスは成功です。

注: 上記のルールは同時に定義できます。readinessProbe テストが成功するまで、ポッドの実行状態は準備完了状態に変わりません。

プローブは 3 つの検査方法をサポートしています。

●exec：コンテナ内で指定されたコマンドを実行します。コマンド終了時のリターンコードが 0 であれば、診断は成功したとみなされます。

●tcpSocket: 指定したポート上のコンテナの IP アドレスに対して TCP インスペクション (3 ウェイハンドシェイク) を実行します。ポートが開いていれば、診断は成功したとみなされます。

●httpGet: 指定されたポートと URI パス上のコンテナの IP アドレスに対して HTTPGet リクエストを実行します。応答のステータスコードが 200 以上 400 未満の場合、診断は成功したとみなされます。

各プローブには、次の 3 つの結果のいずれかが表示されます。

●成功：コンテナがテストに合格したことを示します。
●不合格：コンテナがテストに不合格であることを示します。
●不明：検出が正常に行われていないことを示します。

公式ウェブサイトの例:

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

3.1 例 1: 実行モード

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 が諦めるまでに再試行する回数。生存検出の場合の中止は、コンテナの再起動を意味します。準備完了の検出中に放棄されたポッドには、準備ができていないというラベルが付けられます。デフォルト値は 3 です。最小値は 1 です。
#timeoutSeconds: プローブがタイムアウトになった後に待機する秒数。デフォルト値は 1 秒です。最小値は 1 です。(Kubernetes 1.20 より前では、exec プローブは timeoutSeconds を無視し、結果が返されるまで、プローブは無期限に実行され続け、場合によっては設定された期限を超えても実行され続けました。)

Pod 内にコンテナーが 1 つだけあることがわかります。kubelet は最初のプローブを実行する前に 5 秒待つ必要があります。kubelet は 5 秒ごとに生存プローブを実行します。kubelet はコンテナ内でコマンド cat /tmp/healthy を実行して検出します。コマンドが正常に実行され、戻り値が 0 の場合、kubelet はコンテナーが正常で生きているとみなします。31 秒に達すると、このコマンドはゼロ以外の値を返し、kubelet はコンテナーを強制終了して再起動します。

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

3.2 例 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 にコンテナーが 1 つだけあることがわかります。InitialDelaySeconds フィールドは、最初のプローブを実行する前に 3 秒待つ必要があることを kubelet に伝えます。periodSeconds フィールドは、kubelet が 3 秒ごとに生存プローブを実行することを指定します。kubelet は、コンテナ内で実行されているサービスに HTTP GET リクエストを送信し (サービスはポート 8080 をリッスンします)、検出を実行します。サーバー上の /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.3 例 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: 10
      failureThreshold: 2

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          1s
probe-tcp   1/1     Running             1          25s       #第一次是 init(5秒) + period(10秒) * 2
probe-tcp   1/1     Running             2          45s       #第二次是 period(10秒) + period(10秒)  重试了两次
probe-tcp   1/1     Running             3          65s

3.4 例 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

準備完了の検出に失敗し、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

3.5 例 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

準備完了の検出は失敗し、ポッドは READY 状態に入ることができず、エンドポイントコントローラーはポッドの 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

4. アクションの開始と終了

im 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 事件。

【クラウドネイティブ】アドバンストポッド

目次