第7章 Pod の管理
7.1. 概要
このトピックでは、Pod を 1 回実行する場合の期間や使用可能な帯域幅を含む Pod の管理について説明します。
7.2. Pod の表示
コンテナーのランタイム環境を提供する、Pod についての使用状況の統計を表示できます。これらの使用状況の統計には CPU、メモリー、およびストレージの消費量が含まれます。
使用状況の統計を表示するには、以下を実行します。
$ 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=''
フィルターに使用するセレクター (ラベルクエリー) を選択する必要があります。=
、==
、および !=
をサポートします。
使用状況の統計を閲覧するには、cluster-reader
パーミッションがなければなりません。
使用状況の統計を閲覧するには、メトリクスをインストールしている必要があります。
7.3. 1 回実行 (run-once) Pod 期間の制限
OpenShift Container Platform は 1 回実行 (run-once) Pod を使用して Pod のデプロイやビルドの実行などのタスクを実行します。1 回実行 (run-once) Pod は、RestartPolicy
が Never
または OnFailure
の Pod です。
クラスター管理者は RunOnceDuration の受付制御プラグインを使用し、1 回実行 (run-once) Pod の有効期間の制限を強制的に実行できます。期限が切れると、クラスターはそれらの Pod をアクティブに終了しようとします。このような制限を設ける主な理由は、ビルドなどのタスクが長い時間にわたって実行されることを防ぐことにあります。
7.3.1. RunOnceDuration プラグインの設定
このプラグインの設定には、1 回実行 (run-once) Pod のデフォルト有効期限を含める必要があります。この期限はグローバルに実施されますが、プロジェクト別の期限によって置き換えられることがあります。
kubernetesMasterConfig:
admissionConfig:
pluginConfig:
RunOnceDuration:
configuration:
apiVersion: v1
kind: RunOnceDurationConfig
activeDeadlineSecondsOverride: 3600 1
- 1
- 1 回実行 (run-once) Pod のグローバルのデフォルト値 (秒単位) を指定します。
7.3.2. プロジェクト別のカスタム期間の指定
1 回実行 (run-once) Pod のグローバルな最長期間を設定することに加え、管理者はアノテーション (openshift.io/active-deadline-seconds-override
) を特定プロジェクトに追加し、グローバルのデフォルト値を上書きすることができます。
apiVersion: v1
kind: Project
metadata:
annotations:
openshift.io/active-deadline-seconds-override: "1000" 1
- 1
- 1 回実行 (run-once) Pod のデフォルト有効期限 (秒単位) を 1000 秒に上書きします。上書きに使用する値は、文字列形式で指定される必要があります。
7.3.2.1. Egress ルーター Pod のデプロイ
例7.1 Egress ルーターの Pod 定義のサンプル
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 1 value: 192.168.12.99 - name: EGRESS_GATEWAY 2 value: 192.168.12.1 - name: EGRESS_DESTINATION 3 value: 203.0.113.25 nodeSelector: site: springfield-1 4
pod.network.openshift.io/assign-macvlan annotation
はプライマリーネットワークインターフェースに Macvlan ネットワークインターフェースを作成してから、それを Pod のネットワーク namespace に移行し、egress-router コンテナーを起動します。
"true"
の周りの引用符をそのまま残します。これらを省略するとエラーが生じます。
Pod には openshift3/ose-egress-router イメージを使用する単一コンテナーが含まれ、そのコンテナーは特権モードで実行されるので、Macvlan インターフェースを設定したり、iptables
ルールをセットアップしたりできます。
環境変数は egress-router イメージに対し、使用するアドレスを指示します。これは、EGRESS_SOURCE
を IP アドレスとして、また EGRESS_GATEWAY
をゲートウェイとして使用するよう Macvlan を設定します。
NAT ルールが設定され、Pod のクラスター IP アドレスの TCP または UDP ポートへの接続が EGRESS_DESTINATION
の同じポートにリダイレクトされるようにします。
クラスター内の一部のノードのみが指定されたソース IP アドレスを要求でき、指定されたゲートウェイを使用できる場合、受け入れ可能なノードを示す nodeName
または nodeSelector
を指定することができます。
7.3.2.2. Egress ルーターサービスのデプロイ
通常、egress ルーターを参照するサービスを作成する必要が生じる場合があります (ただし、これは必ずしも必須ではありません)。
apiVersion: v1 kind: Service metadata: name: egress-1 spec: ports: - name: http port: 80 - name: https port: 443 type: ClusterIP selector: name: egress-1
Pod がこのサービスに接続できるようになります。これらの接続は、予約された egress IP アドレスを使用して外部サーバーの対応するポートにリダイレクトされます。
7.3.3. Egress ファイアウォールでの Pod アクセスの制限
OpenShift Container Platform クラスター管理者は egress ポリシーを使用して、一部またはすべての Pod がクラスターからアクセスできる外部アドレスを制限できます。これにより、以下が可能になります。
Pod の対話を内部ホストに制限し、パブリックインターネットへの接続を開始できないようにする。
または
Pod の対話をパブリックインターネットに制限し、(クラスター外の) 内部ホストへの接続を開始できないようにする。
または
- Pod が接続する理由のない指定された内部サブネット/ホストに到達できないようにする。
プロジェクトは複数の異なる egress ポリシーで設定でき、たとえば指定された IP 範囲への <project A>
のアクセスを許可する一方で、同じアクセスを <project B>
に対して拒否することができます。
egress ポリシーで Pod のアクセスを制限するには、ovs-multitenant プラグイン を有効にする必要があります。
プロジェクト管理者は、EgressNetworkPolicy
オブジェクトを作成することも、プロジェクトで作成するオブジェクトを編集することもできません。また、EgressNetworkPolicy
の作成に関連して他のいくつかの制限があります。
-
デフォルト
プロジェクト (およびoc adm pod-network make-projects-global
でグローバルにされたその他のプロジェクト) には egress ポリシーを設定することができません。 -
(
oc adm pod-network join-projects
を使用して) 2 つのプロジェクトをマージする場合、マージしたプロジェクトのいずれでも egress ポリシーを使用することはできません。 - いずれのプロジェクトも複数の egress ポリシーオブジェクトを持つことができません。
上記の制限のいずれかに違反すると、プロジェクトの egress ポリシーに障害が発生し、すべての外部ネットワークトラフィックがドロップされる可能性があります。
7.3.3.1. Pod アクセス制限の設定
Pod アクセス制限を設定するには、oc
コマンドまたは REST API を使用する必要があります。oc [create|replace|delete]
を使用すると、EgressNetworkPolicy
オブジェクトを操作できます。api/swagger-spec/oapi-v1.json ファイルには、オブジェクトの機能方法についての API レベルの詳細情報が含まれます。
Pod のアクセス制限を設定するには、以下を実行します。
- 対象とするプロジェクトに移動します。
Pod の制限ポリシーについての JSON ファイルを作成します。
# oc create -f <policy>.json
ポリシーの詳細情報を使って JSON ファイルを設定します。以下は例になります。
{ "kind": "EgressNetworkPolicy", "apiVersion": "v1", "metadata": { "name": "default" }, "spec": { "egress": [ { "type": "Allow", "to": { "cidrSelector": "1.2.3.0/24" } }, { "type": "Allow", "to": { "dnsName": "www.foo.com" } }, { "type": "Deny", "to": { "cidrSelector": "0.0.0.0/0" } } ] } }
上記のサンプルがプロジェクトに追加されると、IP 範囲
1.2.3.0/24
およびドメイン名www.foo.com
へのへのトラフィックは許可されますが、その他すべての外部 IP アドレスへのアクセスは拒否されます (ポリシーが 外部 トラフィックにのみ適用されるので他の Pod へのトラフィックは影響を受けません)。EgressNetworkPolicy
のルールは順番にチェックされ、一致する最初のルールが実施されます。上記の例の 3 つの例を逆順に定義した場合、0.0.0.0/0
ルールが最初にチェックされ、すべてのトラフィックに一致し、それらすべてを拒否するため、1.2.3.0/24
およびwww.foo.com
へのトラフィックは許可されません。ドメイン名の更新は 30 秒以内に反映されます。上記の例で
www.foo.com
は10.11.12.13
に解決されますが、20.21.22.23
に変更されたとします。OpenShift Container Platform では最長 30 秒後にこれらの DNS 更新に対応します。
7.4. Pod で利用可能な帯域幅の制限
QoS (Quality-of-Service) トラフィックシェーピングを Pod に適用し、その利用可能な帯域幅を効果的に制限することができます。(Pod からの) Egress トラフィックは、設定したレートを超えるパケットを単純にドロップするポリシングによって処理されます。(Pod への) Ingress トラフィックは、データを効果的に処理できるようシェーピングでパケットをキューに入れて処理されます。Pod に設定する制限は、他の Pod の帯域幅には影響を与えません。
Pod の帯域幅を制限するには、以下を実行します。
オブジェクト定義 JSON ファイルを作成し、
kubernetes.io/ingress-bandwidth
およびkubernetes.io/egress-bandwidth
アノテーションを使用してデータトラフィックの速度を指定します。たとえば、 Pod の egress および ingress の両方の帯域幅を 10M/s に制限するには、以下を実行します。例7.2 制限が設定された Pod オブジェクト定義
{ "kind": "Pod", "spec": { "containers": [ { "image": "openshift/hello-openshift", "name": "hello-openshift" } ] }, "apiVersion": "v1", "metadata": { "name": "iperf-slow", "annotations": { "kubernetes.io/ingress-bandwidth": "10M", "kubernetes.io/egress-bandwidth": "10M" } } }
オブジェクト定義を使用して Pod を作成します。
oc create -f <file_or_dir_path>
7.5. Pod の Disruption Budget (停止状態の予算) の設定
Pod の disruption budget は Kubernetes API の一部であり、他の オブジェクトタイプのように oc
コマンドで管理できます。この設定により、メンテナンスのためのノードのドレイン (解放) など、操作時に Pod への安全面の各種の制約を指定できます。
OpenShift Container Platform 3.6 より、Pod の disruption budget は完全にサポートされています。
PodDisruptionBudget
は、同時に起動している必要のあるレプリカの最小数またはパーセンテージを指定する API オブジェクトです。これらをプロジェクトに設定することは、ノードのメンテナンス (クラスターのスケールダウンまたはクラスターのアップグレードなどの実行) 時に役立ち、この設定は (ノードの障害時ではなく) 自発的なエビクションの場合にのみ許可されます。
PodDisruptionBudget
オブジェクトの設定は、以下の主要な部分で構成されています。
- 一連の Pod に対するラベルのクエリー機能であるラベルセレクター。
- 同期に利用可能にする必要のある Pod の最小数を指定する可用性レベル。
以下は、PodDisruptionBudget
リソースのサンプルです。
apiVersion: policy/v1beta1 1 kind: PodDisruptionBudget metadata: name: my-pdb spec: selector: 2 matchLabels: foo: bar minAvailable: 2 3
上記のオブジェクト定義で YAML ファイルを作成した場合、これを以下のようにプロジェクトに追加することができます。
$ oc create -f </path/to/file> -n <project_name>
以下を実行して、Pod の disruption budget をすべてのプロジェクトで確認することができます。
$ 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 はエビクションの対象となります。
7.6. Pod の Preset (プリセット) を使用した情報の Pod への挿入
Pod の Preset は、ユーザーが指定する情報を Pod の作成時に Pod に挿入するオブジェクトです。
OpenShift Container Platform 3.7 の時点で、Pod の Preset はサポートされなくなりました。
挿入可能な Pod の Preset オブジェクトを使用します。
- シークレットオブジェクト
-
ConfigMap
オブジェクト - ストレージボリューム
- コンテナーボリュームのマウント
- 環境変数
すべての情報を Pod に追加する場合には、開発者は Pod ラベルが PodPreset のラベルセレクターに一致することのみを確認する必要があります。Pod のラベルは、一致するラベルセレクターを持つ 1 つ以上の Pod の Preset オブジェクトに Pod を関連付けます。
Pod の Preset を使用すると、開発者は Pod が使用するサービスについての詳細を知らなくても Pod をプロビジョニングできます。管理者は、開発者による Pod のデプロイを阻むことなくサービスの設定項目を開発者に対して非表示にできます。たとえば、管理者はシークレットでデータベースの名前、ユーザー名、およびパスワードを提供し、環境変数でデータベースポートを提供する Pod の Preset を作成できます。Pod の開発者はすべての情報を Pod に組み込むために使用するラベルのみを把握している必要があります。さらに開発者も Pod の Preset を作成して同じタスクを実行することができます。たとえば開発者は、環境変数を複数 Pod に自動的に挿入する Preset を作成できます。
Pod の Preset 機能は、サービスカタログがインストールされている場合にのみ利用できます。
Pod 仕様で podpreset.admission.kubernetes.io/exclude: "true"
パラメーターを使用し、特定の Pod が挿入されないようにすることができます。Pod 仕様のサンプルを参照してください。
詳細は、「Pod の Preset (プリセット) を使用した情報の Pod への挿入」を参照してください。
7.7. Critical 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"