第2章 Pod の使用

Pod はコンテナーに対してマシンインスタンス (物理または仮想) とほぼ同じ機能を持ちます。各 Pod は独自の内部 IP アドレスで割り当てられるため、そのポートスペース全体を所有し、Pod 内のコンテナーはそれらのローカルストレージおよびネットワークを共有できます。

Pod にはライフサイクルがあります。それらは定義された後にノードで実行されるために割り当てられ、コンテナーが終了するまで実行されるか、その他の理由でコンテナーが削除されるまで実行されます。ポリシーおよび終了コードによっては、Pod は終了後に削除されるか、コンテナーのログへのアクセスを有効にするために保持される可能性があります。

OpenShift Container Platform は Pod をほとんどがイミュータブルなものとして処理します。Pod が実行中の場合は Pod に変更を加えることができません。OpenShift Container Platform は既存 Pod を終了し、これを変更された設定、ベースイメージのいずれかまたはその両方で再作成して変更を実装します。Pod は拡張可能なものとしても処理されますが、再作成時に状態を維持しません。そのため、Pod はユーザーが直接管理するのではなく、通常は上位レベルのコントローラーによって管理される必要があります。

OpenShift Container Platform は、Pod の Kubernetes の概念を活用しています。これはホスト上に共にデプロイされる 1 つ以上のコンテナーであり、定義され、デプロイされ、管理される最小のコンピュート単位です。

以下は Pod の定義例です。これは数多くの Pod の機能を示していますが、それらのほとんどは他のトピックで説明されるため、ここではこれらを簡単に説明します。

kind: Pod
apiVersion: v1
metadata:
  name: example
  labels:
    environment: production
    app: abc 
spec:
  restartPolicy: Always 
  securityContext: 
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers: 
    - name: abc
      args:
      - sleep
      - "1000000"
      volumeMounts: 
       - name: cache-volume
         mountPath: /cache 
      image: registry.access.redhat.com/ubi7/ubi-init:latest 
      securityContext:
        allowPrivilegeEscalation: false
        runAsNonRoot: true
        capabilities:
          drop: ["ALL"]
      resources:
        limits:
          memory: "100Mi"
          cpu: "1"
        requests:
          memory: "100Mi"
          cpu: "1"
  volumes: 
  - name: cache-volume
    emptyDir:
      sizeLimit: 500Mi

kind: Pod
apiVersion: v1
metadata:
  name: example
  labels:
    environment: production
    app: abc 

spec:
  restartPolicy: Always 

  securityContext: 

    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers: 

    - name: abc
      args:
      - sleep
      - "1000000"
      volumeMounts: 

       - name: cache-volume
         mountPath: /cache 

      image: registry.access.redhat.com/ubi7/ubi-init:latest 

      securityContext:
        allowPrivilegeEscalation: false
        runAsNonRoot: true
        capabilities:
          drop: ["ALL"]
      resources:
        limits:
          memory: "100Mi"
          cpu: "1"
        requests:
          memory: "100Mi"
          cpu: "1"
  volumes: 

  - name: cache-volume
    emptyDir:
      sizeLimit: 500Mi

Pod の仕様 (「Pod 設定の例」を参照) または Pod の制御オブジェクトの仕様を使用すると、Pod の CPU およびメモリーの要求と制限を指定できます。

CPU およびメモリーの 要求 は、Pod の実行に必要なリソースの最小量を指定するものです。これは、OpenShift Container Platform が十分なリソースを持つノードに Pod をスケジュールするのに役立ちます。

CPU とメモリーの 制限 は、Pod が消費できるリソースの最大量を定義するものです。これは、Pod がリソースを過剰に消費して同じノード上の他の Pod に影響を与える可能性を防ぎます。

CPU およびメモリーの要求と制限は、次の原則に従って処理されます。

Pod が実行されているノードに十分なリソースがある場合、コンテナーは要求よりも多くの CPU またはメモリーリソースを使用する可能性があります。ただし、コンテナーは対応する制限を超えることはできません。たとえば、コンテナーのメモリー要求を 256 MiB に設定し、そのコンテナーが 8GiB のメモリーを持つノードにスケジュールされた Pod 内にあり、そのノードに他の Pod がない場合、コンテナーは要求された 256 MiB より多くのメモリーを使用しようとする可能性があります。

この動作は CPU およびメモリーの制限には適用されません。CPU およびメモリーの制限は、kubelet とコンテナーランタイムによって適用され、カーネルによって強制されます。Linux ノードでは、カーネルが cgroups を使用して制限を適用します。

Linux ワークロードの場合、huge page リソースを指定できます。huge page は Linux 固有の機能です。この機能が有効な場合、ノードのカーネルが、デフォルトのページサイズよりもはるかに大きいメモリーブロックを割り当てます。たとえば、デフォルトのページサイズが 4 KiB のシステムで、より大きな制限を指定できます。huge page の詳細は、「huge page」を参照してください。