KubernetesのPodライフサイクルと再起動ポリシーの理解方法

Podライフサイクルと再起動ポリシー

Podは、そのライフサイクル全体でシステムによって定義されたさまざまな状態を経験します。

Podの再起動ポリシー

PodのRestartPolicyは、Pod内のすべてのコンテナに適用され、Podが存在するノードのkubeletによってのみ判断および再起動されます。コンテナが異常終了した場合やヘルスチェックに失敗した場合、kubeletはRestartPolicyの設定に基づいて適切なアクションを実行します。

PodのRestartPolicyにはAlways、OnFailure、Neverの3つのオプションがあり、デフォルト値はAlwaysです。

• Always: コンテナが失敗したとき、kubeletは自動的にコンテナを再起動します。
• OnFailure: コンテナがゼロ以外の終了コードで終了したとき、kubeletはコンテナを自動的に再起動します。
• Never: コンテナの実行状態に関係なく、kubeletはコンテナを再起動しません。

失敗したコンテナを再起動するkubeletの時間間隔は、sync-frequencyに2nを乗算して計算されます。たとえば、1、2、4、8倍などです。最大遅延は5分で、成功した再起動後にこの時間が10分後にリセットされます。

PodのRestartPolicyは、その制御方法と密接に関連しています。現在、Podを管理するために使用できるコントローラーには、ReplicationController、Job、DaemonSet、およびkubelet管理（StaticPod）が含まれます。各コントローラーの再起動ポリシーの要件は次のとおりです。

• ReplicationControllerおよびDaemonSet: コンテナの継続的な実行を確保するために必ずAlwaysに設定する必要があります。
• Job: 実行が完了した後、コンテナが再起動されないようにするには、OnFailureまたはNeverに設定します。

kubeletはPodが失敗したときに自動的に再起動しますが、RestartPolicyの設定に関係なく、Podに対してヘルスチェックは実行しません。

Podのヘルスチェック

Podのヘルスステータスのチェックは、LivenessProbeとReadinessProbeの2種類のプローブを使用して行うことができます。

1. LivenessProbeプローブ：コンテナが生きているか（実行中の状態か）を判断するために使用されます。LivenessProbeプローブがコンテナが健康でないと検出した場合、kubeletはコンテナを停止し、コンテナの再起動ポリシーに基づいて適切なアクションを実行します。コンテナにLivenessProbeプローブが含まれていない場合、kubeletはLivenessProbeプローブが常に「成功」を返すと見なします。
2. ReadinessProbeプローブ：コンテナが完了し（Ready状態で）、リクエストを受け付けることができるかどうかを判断するために使用されます。ReadinessProbeプローブが失敗した場合、Podの状態が変更されます。エンドポイントコントローラーは、コンテナが含まれるPodのエンドポイントをサービスのエンドポイントから削除します。

プローブの設定パラメータ

HTTPプローブの設定

HTTPプローブの場合、kubeletは指定されたパスとポートに対してHTTPリクエストを送信してチェックを実行します。オプションのホストフィールドがオーバーライドされない限り、kubeletはPodのIPアドレスにプローブを送信します。スキームフィールドがHTTPSに設定されている場合、kubeletは証明書の検証をスキップしてHTTPSリクエストを送信します。ほとんどの場合、ポッドが仮想ホストに依存していない限り、ホストフィールドを設定する必要はありません。ポッドが127.0.0.1でリスンし、ポッドのhostNetworkフィールドがtrueに設定されている場合、httpGetのホストは127.0.0.1に設定する必要があります。ポッドが仮想ホストに依存している場合、これはより一般的なシナリオであるため、ホストを使用せず、httpHeadersでHostヘッダーを設定する必要があります。

詳細については公式ドキュメントを参照してください。

kubeletは定期的にLivenessProbeプローブを実行してコンテナのヘルスチェックを診断します。LivenessProbeには次の3つのモードがあります。

1.ExecAction

コンテナ内でコマンドを実行します。コマンドが0のコードを返すと、コンテナは健康と見なされます。

例：

“cat /tmp/health”コマンドを実行してコンテナが正常に実行されているかどうかを判断します。Podが実行された後、10秒後に/tmp/healthファイルが削除され、LivenessProbeヘルスチェックのinitialDelaySecondsが15秒に設定されています。プローブの結果はFailとなり、kubeletはコンテナを停止し、再起動します。

[root@master test]# cat docker_pod.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: docker-pod
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
      - name: docker-nginx-docker
        image: daocloud.io/library/nginx:1.13.0-alpine
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        command: ["/bin/sh", "-c", "echo ok >/tmp/health; sleep 60;rm -rf /tmp/health; sleep 600"]
        livenessProbe:
          exec:
            command:
            - cat
            - /tmp/health
          initialDelaySeconds: 15
          timeoutSeconds: 1

2.TCPSocketAction

コンテナのIPアドレスとポート番号を使用してTCP接続を試行してTCPチェックを実行します。接続が成功した場合、コンテナは健康と見なされます。

[root@master test]# cat docker_pod.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: docker-pod
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
      - name: docker-nginx-docker
        image: daocloud.io/library/nginx:1.13.0-alpine
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        livenessProbe:
          tcpSocket:
            port: 80
          initialDelaySeconds: 15
          periodSeconds: 10
          timeoutSeconds: 1

3.HTTPGetAction

コンテナのIPアドレス、ポート番号、およびパスを使用してHTTP Getメソッドを呼び出します。返されるステータスコードが200以上400未満の場合、コンテナは健康と見なされます。

[root@master test]# cat docker_pod.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: docker-pod
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
      - name: docker-nginx-docker
        image: daocloud.io/library/nginx:1.13.0-alpine
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /docker/
            port: 80
          initialDelaySeconds: 15
          periodSeconds: 10
          timeoutSeconds: 1

Podのスケジューリング

Kubernetesシステムでは、Podはほとんどがコンテナのキャリアであり、一連のPodのスケジューリングと自動制御機能を完了するには、Deployment、DaemonSet、RC、Jobなどのオブジェクトが必要です。

Deployment/RC：完全自動スケジューリング

DeploymentまたはRCの主な機能の1つは、コンテナアプリケーションの複数のレプリカを自動的に展開し、クラスター内でユーザーが指定したレプリカの数を常に監視することです。

以下は、三つのnginxアプリケーションのPodを作成するDeployment構成の例です。

これらの三つのnginx Podは、システムによって完全に自動的にスケジュールされます。それぞれが実行されるノードは、スケジューラーによって一連のアルゴリズムを介して完全に決定されます。ユーザーはスケジューリングプロセスや結果に介入することはできません。

自動スケジューリングアルゴリズムを使用して一連のPodを展開する以外にも、Kubernetesは豊富なスケジューリング戦略を提供しています。ユーザーは、Podの定義でNodeSelector、NodeAffinity、PodAffinity、Pod Disruption Budgetsなどのより細かいスケジューリング戦略設定を使用するだけで、正確なPodのスケジューリングを実現できます。

NodeSelector：指向性のあるスケジューリング

Kubernetesマスター上のスケジューラーサービス（kube-schedulerプロセス）がPodのスケジューリングを担当します。

デフォルトでは、Podは任意のノードで実行できます。ただし、Kubernetesの「NodeSelectors」と呼ばれる機能を使用して、ノードのラベルに基づいてどのノードでPodが実行可能かを制限することができます。

Kubernetesでは、ノードにキーと値のペアでラベルが割り当てられます。たとえば、ノードには「environment=production」や「disk=ssd」といったラベルが付けられることがあります。ノードには複数のラベルが付けられることがあります。

Podはその仕様でNodeSelectorフィールドを指定できます。 NodeSelectorはキーと値のペアのマップです。ノードでPodを実行するために、ノードはラベルとして示された各

キーと値のペアを持っている必要があります。

以下は、NodeSelectorを使用してPodを特定のラベルのノードにスケジュールする方法の例です：

NodeSelectorを使用してPodを作成します：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  nodeSelector:
    disk: ssd

この例では、Pod nginxは、ラベルdisk=ssdのノードにのみスケジュールされます。

NodeSelectorを使用することで、Kubernetesのスケジューリングの決定に影響を与えることができ、Podのデプロイメント戦略を実現できます。

Kubernetesのスケジューリング戦略やNodeSelectorの詳細については、Kubernetesの公式ドキュメントを参照してください。