第7章 Pod の管理

このトピックでは、Pod を 1 回実行する場合の期間や使用可能な帯域幅を含む Pod の管理について説明します。

コンテナーのランタイム環境を提供する、Pod についての使用状況の統計を表示できます。これらの使用状況の統計には CPU、メモリー、およびストレージの消費量が含まれます。

使用状況の統計を表示するには、以下を実行します。

oc adm top pods

$ oc adm top pods
NAME                         CPU(cores)   MEMORY(bytes)
hawkular-cassandra-1-pqx6l   219m         1240Mi
hawkular-metrics-rddnv       20m          1765Mi
heapster-n94r4               3m           37Mi

ラベルを持つ Pod の使用状況の統計を表示するには、以下を実行します。

oc adm top pod --selector=''

$ oc adm top pod --selector=''

フィルターに使用するセレクター (ラベルクエリー) を選択する必要があります。=、==、および != をサポートします。

OpenShift Container Platform は 1 回実行 (run-once) Pod を使用して Pod のデプロイやビルドの実行などのタスクを実行します。1 回実行 (run-once) Pod は、RestartPolicy が Never または OnFailure の Pod です。

クラスター管理者は RunOnceDuration の受付制御プラグインを使用し、1 回実行 (run-once) Pod の有効期間の制限を強制的に実行できます。期限が切れると、クラスターはそれらの Pod をアクティブに終了しようとします。このような制限を設ける主な理由は、ビルドなどのタスクが長い時間にわたって実行されることを防ぐことにあります。

kubernetesMasterConfig:
  admissionConfig:
    pluginConfig:
      RunOnceDuration:
        configuration:
          apiVersion: v1
          kind: RunOnceDurationConfig
          activeDeadlineSecondsOverride: 3600 

kubernetesMasterConfig:
  admissionConfig:
    pluginConfig:
      RunOnceDuration:
        configuration:
          apiVersion: v1
          kind: RunOnceDurationConfig
          activeDeadlineSecondsOverride: 3600 

apiVersion: v1
kind: Project
metadata:
  annotations:
    openshift.io/active-deadline-seconds-override: "1000" 

apiVersion: v1
kind: Project
metadata:
  annotations:
    openshift.io/active-deadline-seconds-override: "1000" 

apiVersion: v1
kind: Pod
metadata:
  name: egress-1
  labels:
    name: egress-1
  annotations:
    pod.network.openshift.io/assign-macvlan: "true"
spec:
  containers:
  - name: egress-router
    image: openshift3/ose-egress-router
    securityContext:
      privileged: true
    env:
    - name: EGRESS_SOURCE 
      value: 192.168.12.99
    - name: EGRESS_GATEWAY 
      value: 192.168.12.1
    - name: EGRESS_DESTINATION 
      value: 203.0.113.25
  nodeSelector:
    site: springfield-1 

apiVersion: v1
kind: Pod
metadata:
  name: egress-1
  labels:
    name: egress-1
  annotations:
    pod.network.openshift.io/assign-macvlan: "true"
spec:
  containers:
  - name: egress-router
    image: openshift3/ose-egress-router
    securityContext:
      privileged: true
    env:
    - name: EGRESS_SOURCE 

      value: 192.168.12.99
    - name: EGRESS_GATEWAY 

      value: 192.168.12.1
    - name: EGRESS_DESTINATION 

      value: 203.0.113.25
  nodeSelector:
    site: springfield-1 

apiVersion: v1
kind: Service
metadata:
  name: egress-1
spec:
  ports:
  - name: http
    port: 80
  - name: https
    port: 443
  type: ClusterIP
  selector:
    name: egress-1

apiVersion: v1
kind: Service
metadata:
  name: egress-1
spec:
  ports:
  - name: http
    port: 80
  - name: https
    port: 443
  type: ClusterIP
  selector:
    name: egress-1

QoS (Quality-of-Service) トラフィックシェーピングを Pod に適用し、その利用可能な帯域幅を効果的に制限することができます。(Pod からの) Egress トラフィックは、設定したレートを超えるパケットを単純にドロップするポリシングによって処理されます。(Pod への) Ingress トラフィックは、データを効果的に処理できるようシェーピングでパケットをキューに入れて処理されます。Pod に設定する制限は、他の Pod の帯域幅には影響を与えません。

Pod の帯域幅を制限するには、以下を実行します。

Pod の disruption budget は Kubernetes API の一部であり、他の オブジェクトタイプのように oc コマンドで管理できます。この設定により、メンテナンスのためのノードのドレイン (解放) など、操作時に Pod への安全面の各種の制約を指定できます。

PodDisruptionBudget は、同時に起動している必要のあるレプリカの最小数またはパーセンテージを指定する API オブジェクトです。これらをプロジェクトに設定することは、ノードのメンテナンス (クラスターのスケールダウンまたはクラスターのアップグレードなどの実行) 時に役立ち、この設定は (ノードの障害時ではなく) 自発的なエビクションの場合にのみ許可されます。

PodDisruptionBudget オブジェクトの設定は、以下の主要な部分で構成されています。

以下は、PodDisruptionBudget リソースのサンプルです。

apiVersion: policy/v1beta1 
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  selector:  
    matchLabels:
      foo: bar
  minAvailable: 2  

apiVersion: policy/v1beta1 

kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  selector:  

    matchLabels:
      foo: bar
  minAvailable: 2  

上記のオブジェクト定義で YAML ファイルを作成した場合、これを以下のようにプロジェクトに追加することができます。

oc create -f </path/to/file> -n <project_name>

$ oc create -f </path/to/file> -n <project_name>

以下を実行して、Pod の disruption budget をすべてのプロジェクトで確認することができます。

oc get poddisruptionbudget --all-namespaces

$ oc get poddisruptionbudget --all-namespaces

NAMESPACE         NAME          MIN-AVAILABLE   SELECTOR
another-project   another-pdb   4               bar=foo
test-project      my-pdb        2               foo=bar

PodDisruptionBudget は、最低でも minAvailable の Pod がシステムで実行されている場合は正常であるとみなされます。この制限を超えるすべての Pod はエビクションの対象となります。

Pod の Preset は、ユーザーが指定する情報を Pod の作成時に Pod に挿入するオブジェクトです。

挿入可能な Pod の Preset オブジェクトを使用します。

すべての情報を Pod に追加する場合には、開発者は Pod ラベルが PodPreset のラベルセレクターに一致することのみを確認する必要があります。Pod のラベルは、一致するラベルセレクターを持つ 1 つ以上の Pod の Preset オブジェクトに Pod を関連付けます。

Pod の Preset を使用すると、開発者は Pod が使用するサービスについての詳細を知らなくても Pod をプロビジョニングできます。管理者は、開発者による Pod のデプロイを阻むことなくサービスの設定項目を開発者に対して非表示にできます。たとえば、管理者はシークレットでデータベースの名前、ユーザー名、およびパスワードを提供し、環境変数でデータベースポートを提供する Pod の Preset を作成できます。Pod の開発者はすべての情報を Pod に組み込むために使用するラベルのみを把握している必要があります。さらに開発者も Pod の Preset を作成して同じタスクを実行することができます。たとえば開発者は、環境変数を複数 Pod に自動的に挿入する Preset を作成できます。

Pod 仕様で podpreset.admission.kubernetes.io/exclude: "true" パラメーターを使用し、特定の Pod が挿入されないようにすることができます。Pod 仕様のサンプルを参照してください。

詳細は、「Pod の Preset (プリセット) を使用した情報の Pod への挿入」を参照してください。

Heapster および DNS など、クラスターの完全な機能に欠かせないコアコンポーネントであるものの、マスターではなく通常のクラスターノードで実行されるコアコンポーネントが多数あります。クラスターは重要なアドオンがエビクトされると正常な機能を停止する可能性があります。scheduler.alpha.kubernetes.io/critical-pod アノテーションを Pod 仕様に追加し、Descheduler がこれらの Pod を削除できないようにすることで Pod を Critical Pod にすることができます。

spec:
  template:
    metadata:
      name: critical-pod
      annotations:
        scheduler.alpha.kubernetes.io/critical-pod: "true"

spec:
  template:
    metadata:
      name: critical-pod
      annotations:
        scheduler.alpha.kubernetes.io/critical-pod: "true"