Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

第2章 Pod の使用

2.1. Pod の使用
リンクのコピー

Pod は 1 つのホストにデプロイされる 1 つ以上のコンテナーであり、定義され、デプロイされ、管理される最小のコンピュート単位です。

2.1.1. Pod について
リンクのコピー

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

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

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

注記

OpenShift Container Platform ノードホストごとの Pod の最大数については、クラスターの制限を参照してください。

警告

レプリケーションコントローラーによって管理されないベア Pod はノードの中断時に再スケジュールされません。

2.1.2. Pod 設定の例
リンクのコピー

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

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

Pod オブジェクト定義 (YAML)

kind: Pod
apiVersion: v1
metadata:
  name: example
  namespace: default
  selfLink: /api/v1/namespaces/default/pods/example
  uid: 5cc30063-0265780783bc
  resourceVersion: '165032'
  creationTimestamp: '2019-02-13T20:31:37Z'
  labels:
    app: hello-openshift
1 

  annotations:
    openshift.io/scc: anyuid
spec:
  restartPolicy: Always
2 

  serviceAccountName: default
  imagePullSecrets:
    - name: default-dockercfg-5zrhb
  priority: 0
  schedulerName: default-scheduler
  terminationGracePeriodSeconds: 30
  nodeName: ip-10-0-140-16.us-east-2.compute.internal
  securityContext:
3 

    seLinuxOptions:
      level: 's0:c11,c10'
  containers:
4 

    - resources: {}
      terminationMessagePath: /dev/termination-log
      name: hello-openshift
      securityContext:
        capabilities:
          drop:
            - MKNOD
        procMount: Default
      ports:
        - containerPort: 8080
          protocol: TCP
      imagePullPolicy: Always
      volumeMounts:
5 

        - name: default-token-wbqsl
          readOnly: true
          mountPath: /var/run/secrets/kubernetes.io/serviceaccount
6 

      terminationMessagePolicy: File
      image: registry.redhat.io/openshift4/ose-ogging-eventrouter:v4.3
7 

  serviceAccount: default
8 

  volumes:
9 

    - name: default-token-wbqsl
      secret:
        secretName: default-token-wbqsl
        defaultMode: 420
  dnsPolicy: ClusterFirst
status:
  phase: Pending
  conditions:
    - type: Initialized
      status: 'True'
      lastProbeTime: null
      lastTransitionTime: '2019-02-13T20:31:37Z'
    - type: Ready
      status: 'False'
      lastProbeTime: null
      lastTransitionTime: '2019-02-13T20:31:37Z'
      reason: ContainersNotReady
      message: 'containers with unready status: [hello-openshift]'
    - type: ContainersReady
      status: 'False'
      lastProbeTime: null
      lastTransitionTime: '2019-02-13T20:31:37Z'
      reason: ContainersNotReady
      message: 'containers with unready status: [hello-openshift]'
    - type: PodScheduled
      status: 'True'
      lastProbeTime: null
      lastTransitionTime: '2019-02-13T20:31:37Z'
  hostIP: 10.0.140.16
  startTime: '2019-02-13T20:31:37Z'
  containerStatuses:
    - name: hello-openshift
      state:
        waiting:
          reason: ContainerCreating
      lastState: {}
      ready: false
      restartCount: 0
      image: openshift/hello-openshift
      imageID: ''
  qosClass: BestEffort
Copy to Clipboard Toggle word wrap

1
Pod には 1 つまたは複数のラベルで "タグ付け" することができ、このラベルを使用すると、一度の操作で Pod グループの選択や管理が可能になります。これらのラベルは、キー/値形式で metadata ハッシュに保存されます。
2
Pod 再起動ポリシーと使用可能な値の Always、OnFailure、および Never です。デフォルト値は Always です。
3
OpenShift Container Platform は、コンテナーが特権付きコンテナーとして実行されるか、選択したユーザーとして実行されるかどうかを指定するセキュリティーコンテキストを定義します。デフォルトのコンテキストには多くの制限がありますが、管理者は必要に応じてこれを変更できます。
4
containers は、1 つ以上のコンテナー定義の配列を指定します。
5
コンテナーは外部ストレージボリュームがコンテナー内にマウントされるかどうかを指定します。この場合、OpenShift Container Platform API に対して要求を行うためにレジストリーが必要とする認証情報へのアクセスを保存するためにボリュームがあります。
6
Pod に提供するボリュームを指定します。ボリュームは指定されたパスにマウントされます。コンテナーのルート (/) や、ホストとコンテナーで同じパスにはマウントしないでください。これは、コンテナーに十分な特権が付与されている場合に、ホストシステムを破壊する可能性があります (例: ホストの /dev/pts ファイル)。ホストをマウントするには、/host を使用するのが安全です。
7
Pod 内の各コンテナーは、独自のコンテナーイメージからインスタンス化されます。
8
OpenShift Container Platform API に対して要求する Pod は一般的なパターンです。この場合、serviceAccount フィールドがあり、これは要求を行う際に Pod が認証する必要のあるサービスアカウントユーザーを指定するために使用されます。これにより、カスタムインフラストラクチャーコンポーネントの詳細なアクセス制御が可能になります。
9
Pod は、コンテナーで使用できるストレージボリュームを定義します。この場合、デフォルトのサービスアカウントトークンを含む secret ボリュームのエフェメラルボリュームを提供します。

ファイル数が多い永続ボリュームを Pod に割り当てる場合、それらの Pod は失敗するか、起動に時間がかかる場合があります。詳細は、When using Persistent Volumes with high file counts in OpenShift, why do pods fail to start or take an excessive amount of time to achieve "Ready" state? を参照してください。

注記

この Pod 定義には、Pod が作成され、ライフサイクルが開始された後に OpenShift Container Platform によって自動的に設定される属性が含まれません。Kubernetes Pod ドキュメント には、Pod の機能および目的の詳細が記載されています。

2.1.3. リソース要求および制限について
リンクのコピー

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

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

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

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

  • CPU 制限は、CPU スロットリングを使用して適用されます。コンテナーが CPU 制限に近づくと、コンテナーの制限として指定された CPU へのアクセスをカーネルが制限します。したがって、CPU 制限はカーネルによって適用されるハード制限です。OpenShift Container Platform では、コンテナーが CPU 制限を長時間超過することが許される場合があります。ただし、コンテナーランタイムは、CPU 使用率が高すぎる場合でも Pod またはコンテナーを終了しません。

    CPU の制限と要求は CPU 単位で測定されます。1 つの CPU ユニットは、ノードが物理ホストであるか、物理マシン内で実行されている仮想マシンであるかに応じて、1 つの物理 CPU コアまたは 1 つの仮想コアに相当します。小数の要求も許可されます。たとえば、CPU 要求を 0.5 にしてコンテナーを定義すると、1.0 CPU を要求した場合の半分の CPU 時間を要求することになります。CPU ユニットの場合、0.1 は 100m に相当します。これは 100 millicpu または 100 ミリコア として読み取られます。CPU リソースは常に絶対的なリソース量であり、相対的な量ではありません。

    注記

    デフォルトでは、Pod に割り当てることができる CPU の最小量は 10 mCPU です。Pod の仕様では、10 mCPU 未満のリソース制限を要求できます。その場合も、Pod には 10 mCPU が割り当てられます。

  • メモリー制限は、カーネルにより、Out of Memory (OOM) による強制終了を使用して適用されます。コンテナーがメモリー制限を超えるメモリーを使用する場合、カーネルはそのコンテナーを終了できます。ただし、終了はカーネルがメモリーの逼迫を検出した場合にのみ実行されます。そのため、メモリーを過剰に割り当てるコンテナーがすぐに強制終了されないことがあります。つまり、メモリー制限はリアクティブに適用されます。コンテナーはメモリー制限を超えるメモリーを使用することがあります。その場合、コンテナーが強制終了される可能性があります。

    メモリーは、数量を表す E、P、T、G、M、または k のいずれかの接尾辞を使用して、単純な整数または固定小数点数として表すことができます。対応する 2 のべき乗の単位 (Ei、Pi、Ti、Gi、Mi、または Ki) を使用することもできます。

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」を参照してください。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat