高度なPod設定

このページでは、PriorityClass、RuntimeClass、Pod内のセキュリティコンテキストを含む高度なPod設定に関するトピックを扱い、スケジューリングとの関連についても説明します。

PriorityClass

PriorityClass を使用すると、他のPodと比較したPodの重要度を設定することができます。 Podに優先度クラスを割り当てると、Kubernetesは指定したPriorityClassに基づいて、そのPodの.spec.priorityフィールドを設定します(ただし、.spec.priorityを直接設定することはできません)。 Podがスケジュールできず、その問題がリソース不足によるものである場合、kube-schedulerは、より高い優先度のPodのスケジューリングを可能にするため、より低い優先度のPodをプリエンプトしようとします。

PriorityClassは、優先度クラス名を整数の優先度値にマッピングするクラスタースコープのAPIオブジェクトです。 数値が大きいほど高い優先度であることを示します。

PriorityClassを定義する

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 10000
globalDefault: false
description: "Priority class for high-priority workloads"

PriorityClassを使用してPodの優先度を指定する

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  priorityClassName: high-priority

ビルトインのPriorityClass

Kubernetesは2つのビルトインのPriorityClassを提供します:

  • system-cluster-critical: クラスターにとって重要なシステムコンポーネント用。
  • system-node-critical: 個々のノードにとって重要なシステムコンポーネント用。 これはKubernetesでPodが持つことができる最も高い優先度です。

詳細については、Podの優先度とプリエンプションを参照してください。

RuntimeClass

RuntimeClass を使用すると、Podの低レベルなコンテナランタイムを指定できます。 これは、異なる分離レベルやランタイム機能が必要な場合など、異なる種類のPodに対して異なるコンテナランタイムを指定したい場合に役立ちます。

Pod定義の例

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  runtimeClassName: myclass
  containers:
  - name: mycontainer
    image: nginx

RuntimeClassは、クラスター内の一部またはすべてのノードで利用可能なコンテナランタイムを表すクラスタースコープのオブジェクトです。

クラスター管理者は、RuntimeClassを支える具体的なランタイムをインストールおよび設定します。

管理者は、その特別なコンテナランタイム設定をすべてのノードに設定する場合もあれば、一部のノードのみに設定する場合もあります。

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

Podおよびコンテナレベルのセキュリティコンテキスト設定

Pod仕様内のsecurityContextフィールドは、Podとコンテナのセキュリティ設定をきめ細かく制御できます。

Pod全体のsecurityContext

セキュリティ設定の中には、Pod全体に適用されるものがあります。 その他の設定については、コンテナレベルでオーバーライドせずにデフォルトを設定することもできます。

以下は、PodレベルでPod全体のsecurityContextを使用する例です:

Pod定義の例

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:  # この設定は、Pod全体に適用されます
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: sec-ctx-demo
    image: registry.k8s.io/e2e-test-images/agnhost:2.45
    command: ["sh", "-c", "sleep 1h"]

コンテナレベルのセキュリティコンテキスト

特定のコンテナに対してのみ、セキュリティコンテキストを指定できます。 以下はその例です:

Pod定義の例

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-2
spec:
  containers:
  - name: sec-ctx-demo-2
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      allowPrivilegeEscalation: false
      runAsNonRoot: true
      runAsUser: 1000
      capabilities:
        drop:
        - ALL
      seccompProfile:
        type: RuntimeDefault

セキュリティコンテキストのオプション

  • ユーザーIDとグループID: コンテナを実行するユーザー/グループを制御します
  • ケーパビリティ: Linuxケーパビリティを追加または削除します
  • Seccompプロファイル: セキュリティコンピューティングプロファイル(seccomp)を設定します
  • SELinuxオプション: SELinuxコンテキストを設定します
  • AppArmor: 追加のアクセス制御のためにAppArmorプロファイルを設定します
  • Windowsオプション: Windows固有のセキュリティ設定を行います

注意:

PodのsecurityContextを使用して、Linuxコンテナで特権モードを許可することもできます。 特権モードは、securityContextの他の多くのセキュリティ設定を上書きします。 securityContextの他のフィールドを使用して同等の権限を付与できない場合を除き、この設定を使用することは避けてください。 PodレベルのセキュリティコンテキストでwindowsOptions.hostProcessフラグを設定することで、同様の特権モードでWindowsコンテナを実行できます。 詳細とその手順については、Windows HostProcess Podの作成を参照してください。

詳細については、Podまたはコンテナのセキュリティコンテキストの設定を参照してください。

Podのスケジューリングを制御する

Kubernetesは、Podがどのノードにスケジュールされるかを制御するためのいくつかのメカニズムを提供します。

ノードセレクター

最もシンプルな形式のノード選択制約:

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

ノードアフィニティ

ノードアフィニティを使用すると、Podをスケジュールできるノードを制約するルールを指定できます。 以下は、topology.kubernetes.io/zoneラベルの値に基づいて選択し、特定の大陸(continent)にあるとラベル付けされたノードでの実行を優先するPodの例です。

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: topology.kubernetes.io/zone
            operator: In
            values:
            - antarctica-east1
            - antarctica-west1
  containers:
  - name: with-node-affinity
    image: registry.k8s.io/pause:3.8

Podアフィニティとアンチアフィニティ

ノードアフィニティに加えて、ノード上ですでに実行されている 他のPod のラベルに基づいて、Podがスケジュールされるノードを制約することもできます。 Podアフィニティを使用すると、他のPodとの位置関係に基づいてPodを配置するルールを指定できます。

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - database
        topologyKey: topology.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: registry.k8s.io/pause:3.8

Toleration

Toleration を使用すると、一致するTaintを持つノードにPodをスケジュールできます:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: myapp
    image: nginx
  tolerations:
  - key: "key"
    operator: "Equal"
    value: "value"
    effect: "NoSchedule"

詳細については、ノード上へのPodのスケジューリングを参照してください。

Podのオーバーヘッド

Podのオーバーヘッドを使用すると、コンテナのリソース要求とリソース制限に加えて、Podのインフラストラクチャが消費するリソースを考慮できます。

---
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kvisor-runtime
handler: kvisor-runtime
overhead:
  podFixed:
    memory: "2Gi"
    cpu: "500m"
---
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  runtimeClassName: kvisor-runtime
  containers:
  - name: myapp
    image: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

次の項目


最終更新 May 04, 2026 at 3:49 PM PST: [ja] Translate content/ja/docs/concepts/workloads/pods/advanced-pod-config.md into Japanese (#54142) (0eb1163e37)