Menu Close

Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

クラスター管理

OpenShift Container Platform 3.9

OpenShift Container Platform 3.9 クラスター管理

Red Hat OpenShift Documentation Team

概要

『OpenShift クラスター管理』では、OpenShift クラスターを管理するための通常のタスクや他の詳細設定についてのトピックを扱います。

第1章 概要


『OpenShift クラスター管理』では、OpenShift Container Platform クラスターを管理するための日常的なタスクや他の詳細な設定についてのトピックを扱います。

第2章 ノードの管理

2.1. 概要

インスタンスにあるノードは、CLI を使用して管理することができます。

ノードの管理操作を実行すると、CLI は実際のノードホストの表現であるノードオブジェクトと対話します。マスターはノードオブジェクトの情報を使用し、ヘルスチェックでノードの検証を実行します。

2.2. ノードの一覧表示

マスターに認識されるすべてのノードを一覧表示するには、以下を実行します。

$ oc get nodes
NAME                   STATUS    ROLES     AGE       VERSION
master.example.com     Ready     master    7h        v1.9.1+a0ce1bc657
node1.example.com      Ready     compute   7h        v1.9.1+a0ce1bc657
node2.example.com      Ready     compute   7h        v1.9.1+a0ce1bc657

単一ノードについての情報のみを一覧表示するには、<node> を完全なノード名に置き換えます。

$ oc get node <node>

これらのコマンドの出力にある STATUS 列には、ノードの以下の状態が表示されます。

表2.1 ノードの状態

状態説明

Ready

ノードは StatusOK を返し、マスターから実行されるヘルスチェックをパスしています。

NotReady

ノードはマスターから実行されるヘルスチェックをパスしていません。

SchedulingDisabled

ノードへの Pod の配置をスケジュールできません。

注記

STATUS 列には、CLI でノードの状態を検索できない場合にノードについて Unknown が表示されます。

現在の状態の理由を含む特定ノードについての詳細情報を取得するには、以下を実行します。

$ oc describe node <node>

以下に例を示します。

$ oc describe node node1.example.com
Name:			node1.example.com
Labels:			kubernetes.io/hostname=node1.example.com
CreationTimestamp:	Wed, 10 Jun 2015 17:22:34 +0000
Conditions:
  Type		Status	LastHeartbeatTime			LastTransitionTime			Reason					Message
  Ready 	True 	Wed, 10 Jun 2015 19:56:16 +0000 	Wed, 10 Jun 2015 17:22:34 +0000 	kubelet is posting ready status
Addresses:	127.0.0.1
Capacity:
 memory:	1017552Ki
 pods:		100
 cpu:		2
Version:
 Kernel Version:		3.17.4-301.fc21.x86_64
 OS Image:			Fedora 21 (Twenty One)
 Container Runtime Version:	docker://1.6.0
 Kubelet Version:		v0.17.1-804-g496be63
 Kube-Proxy Version:		v0.17.1-804-g496be63
ExternalID:			node1.example.com
Pods:				(2 in total)
  docker-registry-1-9yyw5
  router-1-maytv
No events.

2.3. ノードの追加

ノードを既存の OpenShift Container Platform クラスターに追加するには、ノードコンポーネントのインストール、必要な証明書の生成およびその他の重要な手順を処理する Ansible Playbook を実行できます。Playbook を直接実行する方法については、通常インストール (Advanced installation)方式を参照してください。

またはクイックインストール方式を使用する場合は、インストーラーを再実行してノードを追加すると、同じ手順を実行できます。

2.4. ノードの削除

CLI を使用してノードを削除する場合、ノードオブジェクトは Kubernetes で削除されますが、ノード自体にある Pod は削除されません。レプリケーションコントローラーでサポートされないベア Pod は OpenShift Container Platform からアクセスできなくなり、レプリケーションコントローラーでサポートされる Pod は他の利用可能なノードにスケジュール変更されます。ローカルのマニフェスト Pod は手動で削除する必要があります。

OpenShift Container Platform クラスターからノードを削除するには、以下を実行します。

  1. 削除しようとしているノードからPod を退避します。
  2. ノードオブジェクトを削除します。

    $ oc delete node <node>
  3. ノードがノード一覧から削除されていることを確認します。

    $ oc get nodes

    Pod は、Ready 状態にある残りのノードに対してのみスケジュールされます。

  4. すべての Pod およびコンテナーを含む、OpenShift Container Platform のすべてのコンテンツをノードホストからアンインストールする必要がある場合は、ノードのアンインストールを継続し、uninstall.yml Playbook を使用する手順に従います。この手順では、Ansible を使用した通常インストール (Advanced installation) 方式についての全般的な理解があることが前提となります。

2.5. ノードのラベルの更新

ノードでラベルを追加し、更新するには、以下を実行します。

$ oc label node <node> <key_1>=<value_1> ... <key_n>=<value_n>

詳細な使用法を表示するには、以下を実行します。

$ oc label -h

2.6. ノード上の Pod の一覧表示

1 つ以上のノードにすべてまたは選択した Pod を一覧表示するには、以下を実行します。

$ oc adm manage-node <node1> <node2> \
    --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]

選択したノードのすべてまたは選択した Pod を一覧表示するには、以下を実行します。

$ oc adm manage-node --selector=<node_selector> \
    --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]

2.7. ノードをスケジュール対象外 (Unschedulable) またはスケジュール対象 (Schedulable) としてマークする

デフォルトで、Ready ステータスの正常なノードはスケジュール対象としてマークされます。つまり、新規 Pod をこのノードに配置することができます。手動でノードをスケジュール対象外としてマークすると、新規 Pod のノードでのスケジュールがブロックされます。ノード上の既存 Pod には影響がありません。

1 つまたは複数のノードをスケジュール対象外としてマークするには、以下を実行します。

$ oc adm manage-node <node1> <node2> --schedulable=false

以下に例を示します。

$ oc adm manage-node node1.example.com --schedulable=false
NAME                 LABELS                                        STATUS
node1.example.com    kubernetes.io/hostname=node1.example.com      Ready,SchedulingDisabled

現時点でスケジュール対象外のノードをスケジュール対象としてマークするには、以下を実行します。

$ oc adm manage-node <node1> <node2> --schedulable

または、特定のノード名 (例: <node1> <node2>) を指定する代わりに、--selector=<node_selector> オプションを使用して選択したノードをスケジュール対象またはスケジュール対象外としてマークすることができます。

2.8. Pod のノードからの退避

Pod を退避することで、すべての Pod または選択した Pod を 1 つまたは複数の指定ノードから移行できます。Pod の退避を実行するには、まずノードをスケジュール対象外としてマークする必要があります。

レプリケーションコントローラーでサポートされる Pod のみを退避できます。レプリケーションコントローラーは他のノードで新規 Pod を作成し、既存の Pod を指定したノードから削除します。デフォルトで、ベア Pod (レプリケーションコントローラーでサポートされていない Pod) はこの影響を受けません。

1 つ以上のノードですべてまたは選択した Pod を退避するには、以下を実行します。

$ oc adm drain <node1> <node2> [--pod-selector=<pod_selector>]

--force オプションを使用すると、ベア Pod の削除を強制的に実行できます。true に設定されると、Pod がレプリケーションコントローラー、ReplicaSet、ジョブ、daemonset、または StatefulSet で管理されていない場合でも削除が続行されます。

$ oc adm drain <node1> <node2> --force=true

--grace-period を使用して、各 Pod を正常に終了するための期間 (秒単位) を設定できます。負の値の場合には、Pod に指定されるデフォルト値が使用されます。

$ oc adm drain <node1> <node2> --grace-period=-1

--ignore-daemonsets を使用し、これを true に設定すると、Deamonset で管理された Pod を無視できます。

$ oc adm drain <node1> <node2> --ignore-daemonset=true

--timeout を使用すると、中止する前の待機期間を設定できます。値 0 は無限の時間を設定します。

$ oc adm drain <node1> <node2> --timeout=5s

--delete-local-data を使用し、これを true に設定すると、Pod が emptyDir (ノードがドレイン (解放)) される場合に削除されるローカルデータ) を使用する場合でも削除が続行されます。

$ oc adm drain <node1> <node2> --delete-local-data=true

退避を実行せずに移行するオブジェクトを一覧表示するには、--dry-run オプションを使用し、これを true に設定します。

$ oc adm drain <node1> <node2>  --dry-run=true

特定のノード名 (例: <node1> <node2>) を指定する代わりに、--selector=<node_selector> オプションを使用し、選択したノードで Pod を退避することができます。

2.9. ノードの再起動

プラットフォームで実行されるアプリケーションを停止せずにノードを再起動するには、まず Pod の退避を実行する必要があります。ルーティング階層によって可用性が高くされている Pod については、何も実行する必要はありません。ストレージ (通常はデータベース) を必要とするその他の Pod については、それらが 1 つの Pod が一時的にオフラインになっても作動したままになることを確認する必要があります。ステートフルな Pod の回復性はアプリケーションごとに異なりますが、いずれの場合でも、ノードの非アフィニティー (node anti-affinity) を使用して Pod が使用可能なノード間に適切に分散するようにスケジューラーを設定することが重要になります。

別の課題として、ルーターやレジストリーのような重要なインフラストラクチャーを実行しているノードを処理する方法を検討する必要があります。同じノードの退避プロセスが適用されますが、一部のエッジケースについて理解しておくことが重要です。

2.9.1. インフラストラクチャーノード

インフラストラクチャーノードは、OpenShift Container Platform 環境の一部を実行するためにラベルが付けられたノードです。現在、ノードの再起動を管理する最も簡単な方法として、インフラストラクチャーを実行するために利用できる 3 つ以上のノードを確保することができます。以下のシナリオでは、2 つのノードのみが利用可能な場合に OpenShift Container Platform で実行されるアプリケーションのサービスを中断しかねないよくある問題を示しています。

  • ノード A がスケジュール対象外としてマークされており、すべての Pod の退避が行われている。
  • このノードで実行されているレジストリー Pod がノード B に再デプロイされる。これは、ノード B が両方のレジストリー Pod を実行していることを意味します。
  • ノード B はスケジュール対象外としてマークされ、退避が行われる。
  • ノード B の 2 つの Pod エンドポイントを公開するサービスは、それらがノード A に再デプロイされるまでの短い期間すべてのエンドポイントを失う。

3 つのインフラストラクチャーノードを使用する同じプロセスではサービスの中断が生じません。しかし、Pod のスケジューリングにより、退避してローテーションに戻された最後のノードはゼロ (0) レジストリーを実行していることになり、他の 2 つのノードは 2 つのレジストリーと 1 つのレジストリーをそれぞれ実行します。最善の解決法として、Pod の非アフィニティーを使用できます。これは現在テスト目的で利用できる Kubernetes のアルファ機能ですが、実稼働ワークロードに対する使用はサポートされていません。

2.9.2. Pod の非アフィニティーの使用

Pod の非アフィニティーは、ノードの非アフィニティーとは若干異なります。ノードの非アフィニティーの場合、Pod のデプロイ先となる適切な場所がほかにない場合には違反が生じます。Pod の非アフィニティーの場合は required (必須) または preferred (優先) のいずれかに設定できます。

docker-registry Pod をサンプルとして使用すると、この機能を有効にするための最初の手順として、Pod に scheduler.alpha.kubernetes.io/affinity を設定します。この Pod はデプロイメント設定を使用するため、アノテーションを追加するのに適している場所は Pod テンプレートのメタデータになります。

$ oc edit dc/docker-registry -o yaml

...
  template:
    metadata:
      annotations:
        scheduler.alpha.kubernetes.io/affinity: |
          {
            "podAntiAffinity": {
              "requiredDuringSchedulingIgnoredDuringExecution": [{
                "labelSelector": {
                  "matchExpressions": [{
                    "key": "docker-registry",
                    "operator": "In",
                    "values":["default"]
                  }]
                },
                "topologyKey": "kubernetes.io/hostname"
              }]
            }
          }
重要

scheduler.alpha.kubernetes.io/affinity は、コンテンツが JSON の場合でも文字列として内部に保存されます。上記の例では、この文字列を YAML デプロイメント設定にアノテーションとして追加する方法を示しています。

この例では、Docker レジストリー Pod に docker-registry=default のラベルがあることを想定しています。Pod の非アフィニティーでは任意の Kubernetes の一致式を使用できます。

最後に必要となる手順として、/etc/origin/master/scheduler.jsonMatchInterPodAffinity スケジューラーの述語を有効にします。これが有効にされると、2 つのインフラストラクチャーノードのみが利用可能で、1 つのノードが再起動される場合に、Docker レジストリー Pod が他のノードで実行されることが禁じられます。oc get pods は、適切なノードが利用可能になるまでこの Pod を unready (準備ができていない) として報告します。ノードが利用可能になると、すべての Pod は Ready (準備ができている) 状態に戻り、次のノードを再起動することができます。

2.9.3. ルーターを実行するノードの処理

ほとんどの場合、OpenShift Container Platform ルーターを実行する Pod はホストのポートを公開します。PodFitsPorts スケジューラーの述語により、同じポートを使用するルーター Pod が同じノードで実行されないようにし、Pod の非アフィニティーが適用されます。ルーターの高可用性を維持するために IP フェイルオーバー を利用している場合には、他に実行することはありません。高可用性を確保するために AWS Elastic Load Balancing などの外部サービスを使用するルーター Pod の場合は、そのような外部サービスがルーター Pod の再起動に対して対応します。

ルーター Pod でホストのポートが設定されていないということも稀にあります。この場合は、インフラストラクチャーノードについての推奨される再起動プロセスに従う必要があります。

2.10. ノードリソースの設定

ノードのリソースは、kubelet 引数をノード設定ファイル (/etc/origin/node/node-config.yaml) に追加して設定することができます。kubeletArguments セクションを追加し、必要なオプションを組み込みます。

kubeletArguments:
  max-pods: 1
    - "40"
  resolv-conf: 2
    - "/etc/resolv.conf"
  image-gc-high-threshold: 3
    - "90"
  image-gc-low-threshold: 4
    - "80"
1
2
コンテナー DNS 解決設定のベースとして使用されるリゾルバーの設定ファイル。
3
イメージのガべージコレクションが常に実行される場合のディスク使用量のパーセント。デフォルト: 90%
4
イメージのガべージコレクションが一度も実行されない場合のディスク使用量のパーセント。デフォルト: 80%

利用可能なすべての kubelet オプションを表示するには、以下を実行します。

$ kubelet -h

この設定は、通常インストール (Advanced installation)の実行時に openshift_node_kubelet_args 変数を使用して実行できます。以下は例になります。

openshift_node_kubelet_args={'max-pods': ['40'], 'resolv-conf': ['/etc/resolv.conf'],  'image-gc-high-threshold': ['90'], 'image-gc-low-threshold': ['80']}

2.10.1. ノードあたりの最大 Pod 数の設定

注記

OpenShift Container Platform の各バージョンでサポートされている最大の制限については、「Cluster Limits」のページを参照してください。

/etc/origin/node/node-config.yaml ファイルでは、 pods-per-core および max-pods の 2 つのパラメーターがノードにスケジュールできる Pod の最大数を制御します。いずれのオプションも使用されている場合、2 つの内の小さい方の値でノードの Pod 数が制限されます。これらの値を超えると、以下の状況が発生します。

  • OpenShift Container Platform と Docker の両方で CPU 使用率が増加する。
  • Pod のスケジューリングの速度が遅くなる。
  • メモリー不足のシナリオが生じる可能性がある (ノードのメモリー量によって異なる)。
  • IP アドレスのプールを消費する。
  • リソースのオーバーコミットが起こり、アプリケーションのパフォーマンスが低下する。
注記

Kubernetes では、単一コンテナーを保持する Pod は実際には 2 つのコンテナーを使用します。2 つ目のコンテナーは実際のコンテナーの起動前にネットワークを設定するために使用されます。そのため、10 の Pod を使用するシステムでは、実際には 20 のコンテナーが実行されていることになります。

pods-per-core は、ノードのプロセッサーコア数に基づいてノードが実行できる Pod 数を設定します。たとえば、4 プロセッサーコアを搭載したノードで pods-per-core10 に設定される場合、このノードで許可される Pod の最大数は 40 になります。

kubeletArguments:
  pods-per-core:
    - "10"
注記

pods-per-core を 0 に設定すると、この制限が無効になります。

max-pods は、ノードのプロパティーにかかわらず、ノードが実行できる Pod 数を固定値に設定します。「Cluster Limits」では max-pods のサポートされる最大の値について説明しています。

kubeletArguments:
  max-pods:
    - "250"

上記の例では、pods-per-core のデフォルト値は 10 であり、max-pods のデフォルト値は 250 です。これは、ノードにあるコア数が 25 以上でない限り、デフォルトでは pods-per-core が制限を設定することになります。

2.11. Docker ストレージの再設定

Docker イメージをダウンロードし、コンテナーを実行して削除する際、Docker は常にマップされたディスク領域を解放する訳ではありません。結果として、一定の時間が経過するとノード上で領域不足が生じる可能性があり、これにより OpenShift Container Platform で新規 Pod を作成できなくなるか、または Pod の作成に時間がかかる可能性があります。

たとえば、以下は 6 分が経過しても ContainerCreating 状態にある Pod を示しており、イベントログは FailedSync イベントについて示しています。

$ oc get pod
NAME                               READY     STATUS              RESTARTS   AGE
cakephp-mysql-persistent-1-build   0/1       ContainerCreating   0          6m
mysql-1-9767d                      0/1       ContainerCreating   0          2m
mysql-1-deploy                     0/1       ContainerCreating   0          6m

$ oc get events
LASTSEEN   FIRSTSEEN   COUNT     NAME                               KIND                    SUBOBJECT                     TYPE      REASON                         SOURCE                                                 MESSAGE
6m         6m          1         cakephp-mysql-persistent-1-build   Pod                                                   Normal    Scheduled                      default-scheduler                                      Successfully assigned cakephp-mysql-persistent-1-build to ip-172-31-71-195.us-east-2.compute.internal
2m         5m          4         cakephp-mysql-persistent-1-build   Pod                                                   Warning   FailedSync                     kubelet, ip-172-31-71-195.us-east-2.compute.internal   Error syncing pod
2m         4m          4         cakephp-mysql-persistent-1-build   Pod                                                   Normal    SandboxChanged                 kubelet, ip-172-31-71-195.us-east-2.compute.internal   Pod sandbox changed, it will be killed and re-created.

この問題に対する 1 つの解決法として、Docker ストレージを再設定し、Docker で不要なアーティファクトを削除することができます。

Docker ストレージを再起動するノードで、以下を実行します。

  1. 以下のコマンドを実行して、ノードをスケジュール対象外としてマークします。

    $ oc adm manage-node <node> --schedulable=false
  2. 以下のコマンドを実行して Docker および atomic-openshift-node サービスをシャットダウンします。

    $ systemctl stop docker atomic-openshift-node
  3. 以下のコマンドを実行してローカルのボリュームディレクトリーを削除します。

    $ rm -rf /var/lib/origin/openshift.local.volumes

    このコマンドは、ローカルイメージのキャッシュをクリアします。その結果、ose-* イメージを含むイメージが再度プルする必要があります。これにより、イメージストアは回復しますが、Pod の起動時間が遅くなる可能性があります。

  4. /var/lib/docker ディレクトリーを削除します。

    $ rm -rf /var/lib/docker
  5. 以下のコマンドを実行して Docker ストレージを再設定します。

    $ docker-storage-setup --reset
  6. 以下のコマンドを実行して Docker ストレージを再作成します。

    $ docker-storage-setup
  7. /var/lib/docker ディレクトリーを再作成します。

    $ mkdir /var/lib/docker
  8. 以下のコマンドを実行して Docker および atomic-openshift-node サービスを再起動します。

    $ systemctl start docker atomic-openshift-node
  9. 以下のコマンドを実行してノードをスケジュール対象としてマークします。

    $ oc adm manage-node <node> --schedulable=true

2.12. ノードトラフィックインターフェースの変更

デフォルトで DNS はすべてのノードトラフィックをルーティングします。ノードの登録時に、マスターはノード IP アドレスを DNS 設定から受信するため、DNS 経由でノードにアクセスすることが、ほとんどのデプロイメントにおいて最も柔軟な解決策となります。

お使いのデプロイメントでクラウドプロバイダーを使用している場合、ノードはクラウドプロバイダーから IP 情報を取得します。ただし openshift-sdn は、 (設定されている場合は) nodeName や (nodeName が設定されていない場合は) システムホスト名の DNS ルックアップを含む、各種の方式を使用して IP の判別を試行します。

ノードトラフィックインターフェースには変更が必要になる場合があります。たとえば、以下の場合がこれに該当します。

  • OpenShift Container Platform が、内部ホスト名がすべてのホストで設定されていない/解決可能でないクラウドプロバイダーにインストールされている。
  • マスターから見たノードの IP とノード自体から見たノードの IP が同じではない。

openshift_set_node_ip Ansible 変数を設定すると、デフォルトのネットワークインターフェース以外のインターフェースでのノードトラフィックが強制的に実行されます。

ノードトラフィックインターフェースを変更するには、以下を実行します。

  1. openshift_set_node_ip Ansible 変数を true に設定します。
  2. openshift_ip を、設定するノードの IP アドレスに設定します。
注記

openshift_set_node_ip は本セクションで記載したケースの回避策として有効ですが、通常は実稼働環境には適していません。ノードが新規 IP アドレスを受信すると適切に機能しなくなるためです。

第3章 ユーザーの管理

3.1. 概要

ユーザーとは、OpenShift Container Platform API と対話するエンティティーです。ユーザーは、アプリケーションを開発する開発者の場合もあれば、クラスターを管理する管理者の場合もあります。ユーザーは、グループのすべてのメンバーに適用されるパーミッションを設定するグループに割り当てることができます。たとえば、API アクセスをグループに付与して、そのグループのすべてのメンバーに API アクセスを付与することができます。

このトピックでは、ユーザーアカウントの管理について説明します。これには、OpenShift Container Platform での新規ユーザーアカウントの作成方法とそれらの削除方法が含まれます。

3.2. ユーザーの作成

ユーザーの作成プロセスは、設定される アイデンティティープロバイダーによって異なります。デフォルトで、OpenShift Container Platform は、すべてのユーザー名およびパスワードのアクセスを拒否する DenyAll アイデンティティープロバイダーを使用します。

以下のプロセスでは、新規ユーザーを作成してからロールをそのユーザーに追加します。

  1. アイデンティティープロバイダーに応じたユーザーアカウントを作成します。これは、アイデンティティープロバイダー設定の一部として使用される mappingmethod によって異なります。詳細は、「Mapping Identities to Users (アイデンティティーのユーザーへのマッピング)」セクションを参照してください。
  2. 新規ユーザーに必要なロールを付与します。

    # oc create clusterrolebinding <clusterrolebinding_name> /
      --clusterrole=<role> --user=<user>

    ここで、--clusterrole オプションは必要なクラスターロールになります。たとえば、新規ユーザーに対して、クラスター内のすべてに対するアクセスを付与する cluster-admin 権限を付与するには、以下を実行します。

    # oc create clusterrolebinding registry-controller /
      --clusterrole=cluster-admin --user=admin

    ロールの説明および一覧については、Architecture Guide のクラスターロールおよびローカルロール についてのセクションを参照してください。

クラスター管理者は、各ユーザーのアクセスレベルの管理も実行できます。

注記

アイデンティティープロバイダーおよび定義されたグループ構造によっては、一部のロールがユーザーに自動的に付与される場合があります。詳細は、「グループの LDAP との同期」についてのセクションを参照してください。

3.3. ユーザーおよび ID リストの表示

OpenShift Container Platform のユーザー設定は、OpenShift Container Platform 内の複数の場所に保存されます。アイデンティティープロバイダーの種類を問わず、OpenShift Container Platform はロールベースのアクセス制御 (RBAC) 情報およびグループメンバーシップなどの詳細情報を内部に保存します。ユーザー情報を完全に削除するには、ユーザーアカウントに加えてこのデータも削除する必要があります。

OpenShift Container Platform では、2 つのオブジェクトタイプ (user および identity) に、アイデンティティープロバイダー外のユーザーデータが含まれます。

ユーザーの現在のリストを取得するには、以下を実行します。

$ oc get user
NAME      UID                                    FULL NAME   IDENTITIES
demo     75e4b80c-dbf1-11e5-8dc6-0e81e52cc949               htpasswd_auth:demo

ID の現在のリストを取得するには、以下を実行します。

$ oc get identity
NAME                  IDP NAME        IDP USER NAME   USER NAME   USER UID
htpasswd_auth:demo    htpasswd_auth   demo            demo        75e4b80c-dbf1-11e5-8dc6-0e81e52cc949

2 つのオブジェクトタイプ間で一致する UID があることに注意してください。OpenShift Container Platform の使用を開始した後に認証プロバイダーの変更を試行する場合で重複するユーザー名がある場合、そのユーザー名は、ID リストに古い認証方式を参照するエントリーがあるために機能しなくなります。

3.4. グループの作成

ユーザーは OpenShift Container Platform に要求するエンティティーである一方で、ユーザーのセットで構成される 1 つの以上のグループに編成することもできます。グループは、許可ポリシーなどの場合のように数多くのユーザーを 1 度に管理する際や、パーミッションを複数のユーザーに 1 度に付与する場合などに役立ちます。

組織が LDAP を使用している場合、LDAP レコードの OpenShift Container Platform に対する同期を実行し、複数のグループを 1 つの場所で設定できるようにすることができます。この場合、ユーザーについての情報が MDAP サーバーにあることを仮定します。詳細は、「Synching groups with LDAP (グループの LDAP との同期)」セクションを参照してください。LDAP を使用していない場合は、以下の手順を使用してグループを手動で作成できます。

新規グループを作成するには、以下を実行します。

# oc adm groups new <group_name> <user1> <user2>

たとえば、west グループを作成し、そのグループ内に john および betty ユーザーを置くには、以下を実行します。

# oc adm groups new west john betty

グループが作成されたことを確認し、グループに関連付けられたユーザーを一覧表示するには、以下を実行します。

# oc get groups
NAME      USERS
west      john, betty

次の手順は、* ロールバインディングの管理です。

3.5. ユーザーおよびグループラベルの管理

ラベルをユーザーまたはグループに追加するには、以下を実行します。

$ oc label user/<user_name> <label_name>

たとえばユーザー名が theuser で、ラベルが level=gold の場合には、以下のようになります。

$ oc label user/theuser level=gold

ラベルを削除するには、以下を実行します。

$ oc label user/<user_name> <label_name>-

ユーザーまたはグループのラベルを表示するには、以下を実行します。

$ oc describe user/<user_name>

3.6. ユーザーの削除

ユーザーを削除するには、以下を実行します。

  1. ユーザーレコードを削除します。

    $ oc delete user demo
    user "demo" deleted
  2. ユーザー ID を削除します。

    ユーザーの ID は使用するアイデンティティープロバイダーに関連付けられます。oc get user でユーザーレコードからプロバイダー名を取得します。

    この例では、アイデンティティープロバイダー名は htpasswd_auth です。コマンドは、以下のようになります。

    # oc delete identity htpasswd_auth:demo
    identity "htpasswd_auth:demo" deleted

    この手順を省略すると、ユーザーは再度ログインできなくなります。

上記の手順の完了後は、ユーザーが再びログインすると、新規のアカウントが OpenShift Container Platform に作成されます。

ユーザーの再ログインを防ごうとする場合 (たとえば、ある社員が会社を退職し、そのアカウントを永久に削除する必要がある場合)、そのユーザーを、設定されたアイデンティティープロバイダーの認証バックエンド (htpasswdkerberos その他) から削除することもできます。

たとえば htpasswd を使用している場合、該当のユーザー名とパスワードで OpenShift Container Platform に設定された htpasswd ファイルのエントリーを削除します。

Lightweight Directory Access Protocol (LDAP) または Red Hat Identity Management (IdM) などの外部 ID管理については、ユーザー管理ツールを使用してユーザーエントリーを削除します。

第4章 プロジェクトの管理

4.1. 概要

OpenShift Container Platform では、プロジェクトは関連オブジェクトを分類し、分離するために使用されます。管理者は、開発者に特定プロジェクトへのアクセスを付与し、開発者の独自プロジェクトの作成を許可したり、個別プロジェクト内の管理者権限を付与したりできます。

4.2. プロジェクトのセルフプロビジョニング

開発者の独自プロジェクトの作成を許可することができます。テンプレートに基づいてプロジェクトをプロビジョニングするエンドポイントがあります。web コンソールおよび oc new-project コマンドは、開発者による新規プロジェクトの作成時にこのエンドポイントを使用します。

4.2.1. 新規プロジェクトのテンプレートの変更

API サーバーは、master-config.yaml ファイルprojectRequestTemplate パラメーターで識別されるテンプレートに基づいてプロジェクトを自動的にプロビジョニングします。パラメーターが定義されない場合、API サーバーは要求される名前でプロジェクトを作成するデフォルトテンプレートを作成し、要求するユーザーをプロジェクトの「admin (管理者)」ロールに割り当てます。

独自のカスタムプロジェクトテンプレートを作成するには、以下を実行します。

  1. 現在のデフォルトプロジェクトテンプレートを使って開始します。

    $ oc adm create-bootstrap-project-template -o yaml > template.yaml
  2. オブジェクトを追加するか、または既存オブジェクトを変更することにより、テキストエディターで template.yaml ファイルを変更します。
  3. テンプレートを読み込みます。

    $ oc create -f template.yaml -n default
  4. 読み込まれたテンプレートを参照するよう master-config.yaml ファイルを変更します。

    ...
    projectConfig:
      projectRequestTemplate: "default/project-request"
      ...

プロジェクト要求が送信されると、API はテンプレートで以下のパラメーターを置き換えます。

パラメーター説明

PROJECT_NAME

プロジェクトの名前。必須。

PROJECT_DISPLAYNAME

プロジェクトの表示名。空にできます。

PROJECT_DESCRIPTION

プロジェクトの説明。空にできます。

PROJECT_ADMIN_USER

管理ユーザーのユーザー名。

PROJECT_REQUESTING_USER

要求するユーザーのユーザー名。

API へのアクセスは、self-provisioner ロールself-provisioners のクラスターのロールバインディングで開発者に付与されます。デフォルトで、このロールはすべての認証された開発者が利用できます。

4.2.2. セルフプロビジョニングの無効化

self-provisioners クラスターロールを認証されたユーザーグループから削除すると、新規プロジェクトのセルフプロビジョニングのパーミッションが拒否されます。

$ oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated system:authenticated:oauth

セルフプロビジョニングを無効にする場合、projectRequestMessage パラメーターを master-config.yaml ファイルに設定し、開発者に対して新規プロジェクトの要求方法を指示します。このパラメーターは、開発者のプロジェクトのセルフプロビジョニング試行時に web コンソールやコマンドラインに表示される文字列です。以下は例になります。

Contact your system administrator at projectname@example.com to request a project.

または、以下のようになります。

To request a new project, fill out the project request form located at
https://internal.example.com/openshift-project-request.

サンプル YAML ファイル

...
projectConfig:
  ProjectRequestMessage: "message"
  ...

4.3. ノードセレクターの使用

ノードセレクターは、Pod の配置を制御するためにラベルが付けられたノードと併用されます。

注記

ラベルは、通常インストール (Advanced installation) の実行時に割り当てるか、またはインストール後にノードに追加することができます。

4.3.1. クラスター全体でのデフォルトノードセレクターの設定

クラスター管理者は、クラスター全体でのノードセレクターを使用して Pod の配置を特定ノードに制限することができます。

/etc/origin/master/master-config.yaml でマスター設定ファイルを編集し、デフォルトノードセレクターの値を追加します。これは、指定された nodeSelector 値なしにすべてのプロジェクトで作成された Pod に適用されます。

...
projectConfig:
  defaultNodeSelector: "type=user-node,region=east"
...

変更を有効にするために OpenShift サービスを再起動します。

# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers

4.3.2. プロジェクト全体でのノードセレクターの設定

ノードセレクターを使って個々のプロジェクトを作成するには、プロジェクトの作成時に --node-selector オプションを使用します。たとえば、複数のリージョンを含む OpenShift Container Platform トポロジーがある場合、ノードセレクターを使用して、特定リージョンのノードにのみ Pod をデプロイするよう特定の OpenShift Container Platform プロジェクトを制限することができます。

以下では、myproject という名前の新規プロジェクトを作成し、Pod を user-node および east のラベルが付けられたノードにデプロイするように指定します。

$ oc adm new-project myproject \
    --node-selector='type=user-node,region=east'

いったんこのコマンドが実行されると、これが指定プロジェクト内にあるすべての Pod に対して管理者が設定するノードセレクターになります。

注記

new-project サブコマンドはクラスター管理者および開発者コマンドの oc admoc の両方で利用できますが、oc adm コマンドのみがノードセレクターを使った新規プロジェクトの作成に利用できます。new-project サブコマンドは、プロジェクトのセルフプロビジョニング時にプロジェクト開発者が利用することはできません。

oc adm new-project コマンドを使用すると、annotation セクションがプロジェクトに追加されます。プロジェクトを編集し、デフォルトを上書きするように openshift.io/node-selector 値を編集できます。

...
metadata:
  annotations:
    openshift.io/node-selector: type=user-node,region=east
...

また、以下のコマンドを使用して既存プロジェクトの namespace のデフォルト値を上書きできます。

# oc patch namespace myproject -p \
    '{"metadata":{"annotations":{"openshift.io/node-selector":"region=infra"}}}'

openshift.io/node-selector が空の文字列 (oc adm new-project --node-selector="") に設定される場合、プロジェクトには、クラスター全体のデフォルトが設定されている場合でも管理者設定のノードセレクターはありません。これは、クラスター管理者はデフォルトを設定して開発者のプロジェクトをノードのサブセットに制限したり、インフラストラクチャーまたは他のプロジェクトでクラスター全体をスケジュールしたりできることを意味します。

4.3.3. 開発者が指定するノードセレクター

OpenShift Container Platform 開発者は、追加でノードを制限する必要がある場合に Pod 設定でのノードセレクターの設定を行うことができます。これはプロジェクトノードセレクターに追加されるものであり、ノードセレクターの値を持つすべてのプロジェクトについて依然としてノードセレクターの値を指定できることになります。

たとえば、プロジェクトが上記のアノテーションで作成 (openshift.io/node-selector: type=user-node,region=east) されており、開発者が別のノードセレクターをそのプロジェクトの Pod に設定する場合 (例: clearance=classified)、Pod はこれらの 3 つのラベル (type=user-noderegion=east、および clearance=classified) を持つノードにのみスケジュールされます。region=west が Pod に設定されている場合、Pod はラベル region=east および region=west を持つノードを要求しても成功しません。ラベルは 1 つの値にのみ設定できるため、Pod はスケジュールされません。

4.4. ユーザーあたりのセルフプロビジョニングされたプロジェクト数の制限

指定されるユーザーが要求するセルフプロビジョニングされたプロジェクトの数は、ProjectRequestLimit 受付制御プラグインで制限できます。

重要

プロジェクトの要求テンプレートが、「新規プロジェクトのテンプレートの変更」で説明されるプロセスを使用して OpenShift Container Platform 3.1 (またはそれ以前のバージョン) で作成される場合、生成されるテンプレートには、ProjectRequestLimitConfig に使用されるアノテーション openshift.io/requester: ${PROJECT_REQUESTING_USER} が含まれません。アノテーションは追加する必要があります。

ユーザーの制限を指定するには、設定をマスター設定ファイル (/etc/origin/master/master-config.yaml) 内のプラグインに指定する必要があります。プラグインの設定は、ユーザーラベルのセレクターの一覧および関連付けられるプロジェクト要求の最大数を取ります。

セレクターは順番に評価されます。現在のユーザーに一致する最初のセレクターは、プロジェクトの最大数を判別するために使用されます。セレクターが指定されていない場合、制限はすべてのユーザーに適用されます。プロジェクトの最大数が指定されていない場合、無制限のプロジェクトが特定のセレクターに対して許可されます。

以下の設定は、ユーザーあたりのグローバル制限を 2 プロジェクトに設定し、ラベル level=advanced を持つユーザーに対して 10 プロジェクト、ラベル level=admin を持つユーザーに対して無制限のプロジェクトを許可します。

admissionConfig:
  pluginConfig:
    ProjectRequestLimit:
      configuration:
        apiVersion: v1
        kind: ProjectRequestLimitConfig
        limits:
        - selector:
            level: admin 1
        - selector:
            level: advanced 2
          maxProjects: 10
        - maxProjects: 2 3
1
セレクター level=admin の場合、maxProjects は指定されません。これは、このラベルを持つユーザーにはプロジェクト要求の最大数が設定されないことを意味します。
2
セレクター level=advanced の場合、最大数の 10 プロジェクトが許可されます。
3
3 つ目のエントリーにはセレクターが指定されていません。これは、セレクターが直前の 2 つのルールを満たさないユーザーに適用されることを意味します。ルールは順番に評価されるため、このルールは最後に指定する必要があります。
注記

ユーザーおよびグループラベルの管理」では、ユーザーおよびグループのラベルを追加し、削除し、表示する方法について詳述しています。

変更を加えた後にそれらの変更を有効にするには、OpenShift Container Platform を再起動します。

# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers

第5章 Pod の管理

5.1. 概要

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

5.2. 1 回実行 (run-once) Pod 期間の制限

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

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

5.2.1. RunOnceDuration プラグインの設定

このプラグインの設定には、1 回実行 (run-once) Pod のデフォルト有効期限を含める必要があります。この期限はグローバルに実施されますが、プロジェクト別の期限によって置き換えられることがあります。

kubernetesMasterConfig:
  admissionConfig:
    pluginConfig:
      RunOnceDuration:
        configuration:
          apiVersion: v1
          kind: RunOnceDurationConfig
          activeDeadlineSecondsOverride: 3600 1
1
1 回実行 (run-once) Pod のグローバルのデフォルト値 (秒単位) を指定します。

5.2.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 秒に上書きします。上書きに使用する値は、文字列形式で指定される必要があります。

5.2.2.1. Egress ルーター Pod のデプロイ

例5.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
1
この Pod で使用するためにクラスター管理者が予約するノードサブセットの IP アドレス。
2
ノード自体で使用されるデフォルトゲートウェイと同じ値。
3
Pod の接続は 203.0.113.25 にリダイレクトされます。ソース IP アドレスは 192.168.12.99 です。
4
Pod はラベルサイトが springfield-1 のノードにのみデプロイされます。

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 を指定することができます。

5.2.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 アドレスを使用して外部サーバーの対応するポートにリダイレクトされます。

5.2.3. Egress ファイアウォールでの Pod アクセスの制限

OpenShift Container Platform クラスター管理者は egress ポリシーを使用して、一部またはすべての Pod がクラスターからアクセスできる外部アドレスを制限できます。これにより、以下が可能になります。

  • Pod の対話を内部ホストに制限し、パブリックインターネットへの接続を開始できないようにする。

    または

  • Pod の対話をパブリックインターネットに制限し、(クラスター外の) 内部ホストへの接続を開始できないようにする。

    または

  • Pod が接続する理由のない指定された内部サブネット/ホストに到達できないようにする。

プロジェクトは複数の異なる egress ポリシーで設定でき、たとえば指定された IP 範囲への <project A> のアクセスを許可する一方で、同じアクセスを <project B> に対して拒否することができます。

注意

egress ポリシーで Pod のアクセスを制限するには、ovs-multitenant プラグイン を有効にする必要があります。

プロジェクト管理者は、EgressNetworkPolicy オブジェクトを作成することも、プロジェクトで作成するオブジェクトを編集することもできません。また、EgressNetworkPolicy の作成に関連して他のいくつかの制限があります。

  1. デフォルトプロジェクト (および oc adm pod-network make-projects-global でグローバルにされたその他のプロジェクト) には egress ポリシーを設定することができません。
  2. (oc adm pod-network join-projects を使用して) 2 つのプロジェクトをマージする場合、マージしたプロジェクトのいずれでも egress ポリシーを使用することはできません。
  3. いずれのプロジェクトも複数の egress ポリシーオブジェクトを持つことができません。

上記の制限のいずれかに違反すると、プロジェクトの egress ポリシーに障害が発生し、すべての外部ネットワークトラフィックがドロップされる可能性があります。

5.2.3.1. Pod アクセス制限の設定

Pod アクセス制限を設定するには、oc コマンドまたは REST API を使用する必要があります。oc [create|replace|delete] を使用すると、EgressNetworkPolicy オブジェクトを操作できます。api/swagger-spec/oapi-v1.json ファイルには、オブジェクトの機能方法についての API レベルの詳細情報が含まれます。

Pod のアクセス制限を設定するには、以下を実行します。

  1. 対象とするプロジェクトに移動します。
  2. Pod の制限ポリシーについての JSON ファイルを作成します。

    # oc create -f <policy>.json
  3. ポリシーの詳細情報を使って 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.com10.11.12.13 に解決されますが、20.21.22.23 に変更されたとします。OpenShift Container Platform では最長 30 秒後にこれらの DNS 更新に対応します。

5.3. Pod で利用可能な帯域幅の制限

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

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

  1. オブジェクト定義 JSON ファイルを作成し、kubernetes.io/ingress-bandwidth および kubernetes.io/egress-bandwidth アノテーションを使用してデータトラフィックの速度を指定します。たとえば、 Pod の egress および ingress の両方の帯域幅を 10M/s に制限するには、以下を実行します。

    例5.2 制限が設定された Pod オブジェクト定義

    {
        "kind": "Pod",
        "spec": {
            "containers": [
                {
                    "image": "nginx",
                    "name": "nginx"
                }
            ]
        },
        "apiVersion": "v1",
        "metadata": {
            "name": "iperf-slow",
            "annotations": {
                "kubernetes.io/ingress-bandwidth": "10M",
                "kubernetes.io/egress-bandwidth": "10M"
            }
        }
    }
  2. オブジェクト定義を使用して Pod を作成します。

    oc create -f <file_or_dir_path>

5.4. Pod の Disruption Budget (停止状態の予算) の設定

pod disruption budgetKubernetes 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
1
PodDisruptionBudgetpolicy/v1beta1 API グループの一部です。
2
一連のリソースに対するラベルのクエリー。matchLabelsmatchExpressions の結果は論理的に結合されます。
3
同時に利用可能である必要のある Pod の最小数。これには、整数またはパーセンテージ (例: 20%) を指定する文字列を使用できます。

上記のオブジェクト定義で 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 はエビクションの対象となります。

5.5. Pod の Preset (プリセット) を使用した情報の Pod への挿入

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

重要

Pod の Preset はテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポートについての詳細は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。

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

すべての情報を 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 への挿入」を参照してください。

第6章 ネットワークの管理

6.1. 概要

このトピックでは、プロジェクトの分離および発信トラフィックの制御を含む、全般的なクラスターネットワークの管理について説明します。

Pod ごとの帯域幅の制限などの Pod レベルのネットワーク機能については、Pod の管理で説明されています。

6.2. Pod ネットワークの管理

クラスターが ovs-multitenant SDN プラグインを使用するように設定されている場合、管理者 CLI を使用してプロジェクトの別個の Pod オーバーレイネットワークを管理することができます。必要な場合は、プラグイン設定手順について「SDN の設定」セクションを参照してください。

6.2.1. プロジェクトネットワークへの参加

プロジェクトを既存のプロジェクトネットワークに参加させるには、以下を実行します。

$ oc adm pod-network join-projects --to=<project1> <project2> <project3>

上記の例で、<project2> および <project3> のすべての Pod およびサービスから、<project1> のすべての Pod およびサービスへのアクセスが可能となり、その逆の場合も可能になります。サービスは、IP または完全修飾 DNS 名 (<service>.<pod_namespace>.svc.cluster.local) のいずれかでアクセスできます。たとえば、プロジェクト myprojectdb という名前のサービスにアクセスするには、db.myproject.svc.cluster.local を使用します。

または、特定のプロジェクト名を指定する代わりに --selector=<project_selector> オプションを使用することもできます。

6.3. プロジェクトネットワークの分離

プロジェクトネットワークをクラスターから分離したり、その逆を実行するには、以下を実行します。

$ oc adm pod-network isolate-projects <project1> <project2>

上記の例では、<project1> および <project2> のすべての Pod およびサービスは、クラスター内のグローバル以外のプロジェクトの Pod およびサービスにアクセスできず、その逆も実行できません。

または、特定のプロジェクト名を指定する代わりに --selector=<project_selector> オプションを使用することもできます。

6.3.1. プロジェクトネットワークのグローバル化

プロジェクトからクラスター内のすべての Pod およびサービスにアクセスできるようにするか、その逆を可能にするには、以下を実行します。

$ oc adm pod-network make-projects-global <project1> <project2>

上記の例では、<project1> および <project2> のすべての Pod およびサービスはクラスター内のすべての Pod およびサービスにアクセスでき、その逆の場合も可能になります。

または、特定のプロジェクト名を指定する代わりに --selector=<project_selector> オプションを使用することもできます。

6.4. ルートおよび Ingress オブジェクトにおけるホスト名の競合防止の無効化

OpenShift Container Platform では、ルートおよび ingress オブジェクトのホスト名の競合防止はデフォルトで有効にされています。これは、cluster-admin ロールのないユーザーは、作成時にのみルーターまたは ingress オブジェクトのホスト名を設定でき、その後は変更できなくなることを意味しています。ただし、ルートおよび ingress オブジェクトのこの制限は、一部またはすべてのユーザーに対して緩和することができます。

警告

OpenShift Container Platform はオブジェクト作成のタイムスタンプを使用して特定のホスト名の最も古いルートや ingress オブジェクトを判別するため、ルートまたは ingress オブジェクトは、古いルートがそのホスト名を変更したり、ingress オブジェクトが導入される場合に新規ルートのホスト名をハイジャックする可能性があります。

OpenShift Container Platform クラスター管理者は、作成後でもルートのホスト名を編集できます。また、特定のユーザーがこれを実行できるようにロールを作成することもできます。

$ oc create clusterrole route-editor --verb=update --resource=routes.route.openshift.io/custom-host

次に、新規ロールをユーザーにバインドできます。

$ oc adm policy add-cluster-role-to-user route-editor user

ingress オブジェクトのホスト名の競合防止を無効にすることもできます。これを実行することで、cluster-admin ロールを持たないユーザーが作成後も ingress オブジェクトのホスト名を編集できるようになります。これは、ingress オブジェクトのホスト名の編集を許可する場合などに Kubernetes の動作に依存する OpenShift Container Platform のインストールで役に立ちます。

  1. 以下を master.yaml ファイルに追加します。

    admissionConfig:
      pluginConfig:
        openshift.io/IngressAdmission:
          configuration:
            apiVersion: v1
            allowHostnameChanges: true
            kind: IngressAdmissionConfig
          location: ""
  2. 変更を有効にするために、マスターサービスを再起動します。

    $ systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers

6.5. Egress トラフィックの制御

クラスター管理者は、ホストレベルで数多くの静的 IP アドレスを特定ノードに割り当てることができます。アプリケーション開発者がそれぞれのアプリケーションサービスに専用 IP アドレスを必要とする場合、ファイアウォールアクセスを要求するプロセスでこのアドレスを要求することができます。その後、開発者はデプロイメント設定の nodeSelector を使用して、開発者のプロジェクトから egress ルーターをデプロイし、静的 IP アドレスが事前に割り当てられたホストに Pod が到達することを確認できます。

egress Pod のデプロイメントでは、宛先に到達するために必要なソース IP のいずれか、保護されるサービスの宛先 IP、およびゲートウェイ IP を宣言します。Pod のデプロイ後は、サービスを作成して、egress ルーター Pod にアクセスし、そのソース IP を企業ファイアウォールに追加できます。その後、開発者はプロジェクトで作成された egress ルーターサービスへのアクセス情報を取得します (例: service.project.cluster.domainname.com)。

開発者が外部の firewalled サービスにアクセスする必要がある場合、実際の保護されたサービス URL ではなくアプリケーション (例: JDBC 接続情報) で、egress ルーター Pod のサービス (service.project.cluster.domainname.com) に対して呼び出し実行することができます。

さらに、静的 IP アドレスをプロジェクトに割り当て、指定されたプロジェクトからの発信外部接続すべてに認識可能な起点を設定できます。これは、トラフィックと特定の宛先に送信するために使用されるデフォルトの egress ルーターとは異なります。詳細は、「外部プロジェクトトラフィックの固定 IP の有効化」セクションを参照してください。

注記

egress ルーターは OpenShift Dedicated では利用できません。

OpenShift Container Platform クラスター管理者は、以下を使用して egress トラフィックを制御できます。

ファイアウォール
egress ファイアウォールを使用すると、受け入れ可能な発信トラフィックポリシーを実施し、特定のエンドポイントまたは IP 範囲 (サブネット) のみを動的エンドポイント (OpenShift Container Platform 内の Pod) が通信できる受け入れ可能なターゲットとすることができます。
ルーター
egress ルーターを使用することで、識別可能なサービスを作成し、トラフィックを特定の宛先に送信できます。これにより、それらの外部の宛先はトラフィックを既知のソースから送られるものとして処理します。これにより namespace の特定の Pod のみがトラフィックをデータベースにプロキシー送信するサービス (egress ルーター) と通信できるよう外部データベースが保護されるため、セキュリティー対策として役立ちます。
iptables
上記の OpenShift Container Platform 内のソリューションのほかにも、発信トラフィックに適用される iptables ルールを作成することができます。これらのルールは、egress ファイアウォールよりも多くのオプションを許可しますが、特定のプロジェクトに制限することはできません。

6.5.1. 外部リソースへのアクセスを制限するための Egress ファイアウォールの使用

OpenShift Container Platform クラスター管理者は egress ファイアウォールを使用して、一部またはすべての Pod がクラスター内からアクセスできる外部アドレスを制限できます。これにより、以下が可能になります。

  • Pod の対話を内部ホストに制限し、パブリックインターネットへの接続を開始できないようにする。

    または

  • Pod の対話をパブリックインターネットに制限し、(クラスター外の) 内部ホストへの接続を開始できないようにする。

    または

  • Pod が接続する理由のない指定された内部サブネット/ホストに到達できないようにする。

プロジェクトを複数の異なる egress ポリシーを持つように設定できます。たとえば、<project A> の指定した IP 範囲へのアクセスを許可する一方で、同じアクセスを <project B> に対して拒否することができます。または、アプリケーション開発者の (Python) pip mirror からの更新を制限したり、更新を必要なソースからの更新のみに強制的に制限したりすることができます。

注意

Pod アクセスを egress ポリシーで制限するには、ovs-multitenant または ovs-networkpolicy プラグインを有効にする必要があります。

プロジェクト管理者は、EgressNetworkPolicy オブジェクトを作成することも、プロジェクトで作成するオブジェクトを編集することもできません。また、EgressNetworkPolicy の作成に関連して他のいくつかの制限があります。

  • デフォルトプロジェクト (および oc adm pod-network make-projects-global でグローバルにされたその他のプロジェクト) には egress ポリシーを設定することができません。
  • (oc adm pod-network join-projects を使用して) 2 つのプロジェクトをマージする場合、マージしたプロジェクトのいずれでも egress ポリシーを使用することはできません。
  • いずれのプロジェクトも複数の egress ポリシーオブジェクトを持つことができません。

上記の制限のいずれかに違反すると、プロジェクトの egress ポリシーに障害が発生し、すべての外部ネットワークトラフィックがドロップされる可能性があります。

oc コマンドまたは REST API を使用して egress ポリシーを設定します。oc [create|replace|delete] を使用して EgressNetworkPolicy オブジェクトを操作できます。api/swagger-spec/oapi-v1.json ファイルには、オブジェクトを実際に機能させる方法についての API レベルの詳細情報が含まれます。

egress ポリシーを設定するには、以下を実行します。

  1. 対象とするプロジェクトに移動します。
  2. 必要なポリシー詳細情報で 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 へのトラフィックは許可されません。

    ドメイン名の更新は、ローカルの非権威サーバーのドメインの TTL (time to live) 値か、または TTL をフェッチできない場合は 30 分の値に基づいてポーリングされます。Pod は必要な場合には、同じローカルの非権威サーバーのドメインを解決します。そうでない場合には、egress ネットワークポリシーコントローラーと Pod で認識されるドメインの IP アドレスが異なり、egress ネットワークが予想通りに実施されない場合があります。上記の例で www.foo.com10.11.12.13 に解決され、DNS TTL が 1 分に設定されていますが、後に 20.21.22.23 に変更されたとします。OpenShift Container Platform は最長 1 分後にこれらの変更に対応します。

注記

egress ファイアウォールは、DNS 解決用に Pod が置かれるノードの外部インターフェースに Pod が常にアクセスできるようにします。DNS 解決がローカルノード上のいずれかによって処理されない場合は、Pod でドメイン名を使用している場合には DNS サーバーの IP アドレスへのアクセスを許可する egress ファイアウォールを追加する必要があります。デフォルトインストーラーはローカル dnsmasq をセットアップするため、このセットアップを使用する場合は、ルールを追加する必要はありません。

  1. JSON ファイルを使用して EgressNetworkPolicy オブジェクトを作成します。

    $ oc create -f <policy>.json
注意

ルートを作成してサービスを公開すると、EgressNetworkPolicy は無視されます。Egress ネットワークポリシーサービスのエンドポイントのフィルターは、ノード kubeproxy で実行されます。ルーターが使用される場合は、kubeproxy はバイパスされ、egress ネットワークポリシーの実施は適用されません。管理者は、ルートを作成するためのアクセスを制限してこのバイパスを防ぐことができます。

6.5.2. 外部リソースから Pod トラフィックを認識可能にするための Egress ルーターの使用

OpenShift Container Platform egress ルーターは、他の用途で使用されていないプライベートソース IP アドレスを使用して、指定されたリモートサーバーにトラフィックをリダイレクトするサービスを実行します。このサービスにより、Pod はホワイトリスト IP アドレスからのアクセスのみを許可するように設定されたサーバーと通信できるようになります。

重要

egress ルーターはすべての発信接続のために使用されることが意図されていません。多数の egress ルーターを作成することで、ネットワークハードウェアの制限を引き上げる可能性があります。たとえば、すべてのプロジェクトまたはアプリケーションに egress ルーターを作成すると、ソフトウェアの MAC アドレスのフィルターにフォールバックする前にネットワークインターフェースが処理できるローカル MAC アドレス数の上限を超えてしまう可能性があります。

重要

現時点で、egress ルーターには Amazon AWS との互換性がありません。AWS に macvlan トラフィックとの互換性がないためです。

デプロイメントに関する考慮事項

Egressルーターは 2 つ目の IP アドレスおよび MAC アドレスをノードのプライマリーネットワークインターフェースに追加します。OpenShift Container Platform をベアメタルで実行していない場合は、ハイパーバイザーまたはクラウドプロバイダーが追加のアドレスを許可するように設定する必要があります。

Red Hat OpenStack Platform

OpenShift Container Platform を Red Hat OpenStack Platform を使ってデプロイしている場合、OpenStack 環境で IP および MAC アドレスのホワイトリストを作成する必要があります。これを行わないと、通信は失敗します

neutron port-update $neutron_port_uuid \
  --allowed_address_pairs list=true \
  type=dict mac_address=<mac_address>,ip_address=<ip_address>
Red Hat Enterprise Virtualization
Red Hat Enterprise Virtualization を使用している場合は、EnableMACAntiSpoofingFilterRulesfalse に設定する必要が あります。
VMware vSphere
VMware vSphere を使用している場合は、vSphere 標準スイッチのセキュリティー保護についての VMWare ドキュメントを参照してください。vSphere Web クライアントからホストの仮想スイッチを選択して、VMWare vSphere デフォルト設定を表示し、変更します。

とくに、以下が有効にされていることを確認します。

Egress ルーターモード

egress ルーターは、リダイレクトモードHTTP プロキシーモードの 2 つの異なるモードで実行できます。リダイレクトモードは、HTTP および HTTPS 以外のすべてのサービスで機能します。HTTP および HTTPS サービスの場合は、HTTP プロキシーモードを使用します。

6.5.2.1. リダイレクトモードでの Egress ルーター Pod のデプロイ

リダイレクトモードでは、egress ルーターは、トラフィックを独自の IP アドレスから 1 つ以上の宛先 IP アドレスにリダイレクトするために iptables ルールをセットアップします。予約されたソース IP アドレスを使用する必要のあるクライアント Pod は、宛先 IP に直接接続するのでなく、egress ルーターに接続するように変更される必要があります。

  1. 上記を使用して Pod 設定を作成します。

    apiVersion: v1
    kind: Pod
    metadata:
      name: egress-1
      labels:
        name: egress-1
      annotations:
        pod.network.openshift.io/assign-macvlan: "true" 1
    spec:
      initContainers:
      - name: egress-router
        image: registry.access.redhat.com/openshift3/ose-egress-router
        securityContext:
          privileged: true
        env:
        - name: EGRESS_SOURCE 2
          value: 192.168.12.99
        - name: EGRESS_GATEWAY 3
          value: 192.168.12.1
        - name: EGRESS_DESTINATION 4
          value: 203.0.113.25
        - name: EGRESS_ROUTER_MODE 5
          value: init
      containers:
      - name: egress-router-wait
        image: registry.access.redhat.com/openshift3/ose-pod
      nodeSelector:
        site: springfield-1 6
    1
    プライマリーネットワークインターフェースで Macvlan ネットワークインターフェースを作成し、これを Pod のネットワークプロジェクトに移行してから egress-router コンテナーを起動します。"true" の周りの引用符はそのまま残します。これらを省略すると、エラーが発生します。プライマリーネットワークインターフェース以外のネットワークインターフェースで Macvlan インターフェースを作成するには、アノテーションの値を該当インターフェースの名前に設定します。たとえば、 eth1 を使用します。
    2
    ノードが置かれている物理ネットワークの IP アドレスで、この Pod で使用するようにクラスター管理者が予約します。
    3
    ノードで使用されるデフォルトゲートウェイと同じ値です。
    4
    トラフィックの送信先となる外部サーバー。この例では、Pod の接続は 203.0.113.25 にリダイレクトされます。ソース IP アドレスは 192.168.12.99 です。
    5
    これは egress ルーターイメージに対して、これが「init コンテナー」としてデプロイされていることを示しています。以前のバージョンの OpenShift Container Platform (および egress ルーターイメージ) はこのモードをサポートしておらず、通常のコンテナーとして実行される必要がありました。
    6
    Pod はラベル site=springfield-1 の設定されたノードにのみデプロイされます。
  2. 上記の定義を使用して Pod を作成します。

    $ oc create -f <pod_name>.json

    Pod が作成されているかどうかを確認するには、以下を実行します。

    $ oc get pod <pod_name>
  3. egresss ルーターを参照するサービスを作成し、他の Pod が Pod の IP アドレスを見つけられるようにします。

    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 アドレスを使用して外部サーバーの対応するポートにリダイレクトされます。

egress ルーターのセットアップは、openshift3/ose-egress-router イメージで作成される「init コンテナー」で実行され、このコンテナーは Macvlan インターフェースを設定し、iptables ルールをセットアップできるように特権モード実行されます。iptables ルールのセットアップ終了後に、これは終了し、openshift3/ose-pod コンテナーが Pod が強制終了されるまで (特定のタスクを実行しない) 実行状態になります。

環境変数は egress-router イメージに対し、使用するアドレスを指示します。これは、EGRESS_SOURCE を IP アドレスとして、また EGRESS_GATEWAY をゲートウェイとして使用するよう Macvlan を設定します。

NAT ルールが設定され、Pod のクラスター IP アドレスの TCP または UDP ポートへの接続が EGRESS_DESTINATION の同じポートにリダイレクトされるようにします。

クラスター内の一部のノードのみが指定されたソース IP アドレスを要求でき、指定されたゲートウェイを使用できる場合、受け入れ可能なノードを示す nodeName または nodeSelector を指定することができます。

6.5.2.2. 複数の宛先へのリダイレクト

前の例では、任意のポートでの egress Pod (またはその対応するサービス) への接続は単一の宛先 IP にリダイレクトされます。ポートによっては複数の異なる宛先 IP を設定することもできます。

apiVersion: v1
kind: Pod
metadata:
  name: egress-multi
  labels:
    name: egress-multi
  annotations:
    pod.network.openshift.io/assign-macvlan: "true"
spec:
  initContainers:
  - name: egress-router
    image: registry.access.redhat.com/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: | 1
        80   tcp 203.0.113.25
        8080 tcp 203.0.113.26 80
        8443 tcp 203.0.113.26 443
        203.0.113.27
    - name: EGRESS_ROUTER_MODE
      value: init
  containers:
  - name: egress-router-wait
    image: registry.access.redhat.com/openshift3/ose-pod
1
ここでは、複数行の文字列に YAML 構文を使用しています。詳細は以下を参照してください。

EGRESS_DESTINATION の各行は以下の 3 つのタイプのいずれかになります。

  • <port> <protocol> <IP address>: これは、指定される <port> への着信接続が指定される <IP address> の同じポートにリダイレクトされることを示します。<protocol>tcp または udp のいずれかになります。上記の例では、最初の行がローカルポート 80 から 203.0.113.25 のポート 80 にトラフィックをリダイレクトしています。
  • <port> <protocol> <IP address> <remote port>: 接続が <IP address> の別の <remote port> にリダイレクトされるのを除き、上記と同じになります。この例では、2 番目と 3 番目の行ではローカルポート 8080 および 8443 を 203.0.113.26 のリモートポート 80 および 443 にリダイレクトしています。
  • <fallback IP address>: EGRESS_DESTINATION の最後の行が単一 IP アドレスである場合、それ以外のポートの接続はその IP アドレス (上記の例では 203.0.113.27) の対応するポートにリダイレクトされます。フォールバック IP アドレスがない場合、他のポートでの接続は単純に拒否されます。)

6.5.2.3. ConfigMap の使用による EGRESS_DESTINATION の指定

宛先マッピングのセットのサイズが大きいか、またはこれが頻繁に変更される場合、ConfigMap を使用して一覧を外部で維持し、egress ルーター Pod がそこから一覧を読み取れるようにすることができます。これには、プロジェクト管理者が ConfigMap を編集できるという利点がありますが、これには特権付きコンテナーが含まれるため、管理者は Pod 定義を直接編集することはできません。

  1. EGRESS_DESTINATION データを含むファイルを作成します。

    $ cat my-egress-destination.txt
    # Egress routes for Project "Test", version 3
    
    80   tcp 203.0.113.25
    
    8080 tcp 203.0.113.26 80
    8443 tcp 203.0.113.26 443
    
    # Fallback
    203.0.113.27

    空の行とコメントをこのファイルに追加できることに注意してください。

  2. このファイルから ConfigMap オブジェクトを作成します。

    $ oc delete configmap egress-routes --ignore-not-found
    $ oc create configmap egress-routes \
      --from-file=destination=my-egress-destination.txt

    ここで、egress-routes は作成される ConfigMap オブジェクトの名前で、my-egress-destination.txt はデータの読み取り元のファイルの名前です。

  3. 前述のように egress ルーター Pod 定義を作成しますが、ConfigMap を環境セクションの EGRESS_DESTINATION に指定します。

        ...
        env:
        - name: EGRESS_SOURCE
          value: 192.168.12.99
        - name: EGRESS_GATEWAY
          value: 192.168.12.1
        - name: EGRESS_DESTINATION
          valueFrom:
            configMapKeyRef:
              name: egress-routes
              key: destination
        - name: EGRESS_ROUTER_MODE
          value: init
        ...
注記

egress ルーターは、ConfigMap が変更されても自動的に更新されません。更新を取得するには Pod を再起動します。

6.5.2.4. Egress ルーター HTTP プロキシー Pod のデプロイ

HTTP プロキシーモードでは、egress ルーターはポート 8080 で HTTP プロキシーとして実行されます。これは、HTTP または HTTPS ベースのサービスと通信するクライアントの場合にのみ機能しますが、通常それらを機能させるのにクライアント Pod への多くの変更は不要です。環境変数を設定することで、プログラムは HTTP プロキシーを使用するように指示されます。

  1. 例として以下を使用して Pod を作成します。

    apiVersion: v1
    kind: Pod
    metadata:
      name: egress-http-proxy
      labels:
        name: egress-http-proxy
      annotations:
        pod.network.openshift.io/assign-macvlan: "true" 1
    spec:
      initContainers:
      - name: egress-router-setup
        image: registry.access.redhat.com/openshift3/ose-egress-router
        securityContext:
          privileged: true
        env:
        - name: EGRESS_SOURCE 2
          value: 192.168.12.99
        - name: EGRESS_GATEWAY 3
          value: 192.168.12.1
        - name: EGRESS_ROUTER_MODE 4
          value: http-proxy
      containers:
      - name: egress-router-proxy
        image: registry.access.redhat.com/openshift3/ose-egress-http-proxy
        env:
        - name: EGRESS_HTTP_PROXY_DESTINATION 5
          value: |
            !*.example.com
            !192.168.1.0/24
            *
    1
    プライマリーネットワークインターフェースで Macvlan ネットワークインターフェースを作成してから、これを Pod のネットワークプロジェクトに移行し、egress-router コンテナーを起動します。"true" の周りの引用符をそのまま残します。これらを省略すると、エラーが発生します。
    2
    ノード自体が置かれている物理ネットワークの IP アドレスで、この Pod で使用するためにクラスター管理者が予約します。
    3
    ノード自体で使用されるデフォルトゲートウェイと同じ値。
    4
    これは egress ルーターイメージに対し、これが HTTP プロキシーの一部としてデプロイされているため、iptables のリダイレクトルールを設定できないことを示します。
    5
    プロキシーの設定方法を指定する文字列または YAML の複数行文字列です。これは、init コンテナーの他の環境変数ではなく、HTTP プロキシーコンテナーの環境変数として指定されることに注意してください。

    EGRESS_HTTP_PROXY_DESTINATION 値に以下のいずれかを指定できます。また、* を使用することができます。これは「すべてのリモート宛先への接続を許可」することを意味します。設定の各行には、許可または拒否する接続の 1 つのグループを指定します。

    • IP アドレス (例: 192.168.1.1) は該当する IP アドレスへの接続を許可します。
    • CIDR 範囲 (例: 192.168.1.0/24) は CIDR 範囲への接続を許可します。
    • ホスト名 (例: www.example.com) は該当ホストへのプロキシーを許可します。
    • *. が先に付けられるドメイン名 (例: *.example.com) は該当ドメインおよびそのサブドメインのすべてへのプロキシーを許可します。
    • 上記のいずれかに ! を付けると、接続は許可されるのではなく、拒否されます。
    • 最後の行が * の場合、拒否されていないすべてのものが許可されます。または、許可されていないすべてのものが拒否されます。
  2. egresss ルーターを参照するサービスを作成し、他の Pod が Pod の IP アドレスを見つけられるようにします。

    apiVersion: v1
    kind: Service
    metadata:
      name: egress-1
    spec:
      ports:
      - name: http-proxy
        port: 8080 1
      type: ClusterIP
      selector:
        name: egress-1
    1
    http ポートが常に 8080 に設定されていることを確認します。
  3. http_proxy または https_proxy 変数を設定して、クライアント Pod (egress プロキシー Pod ではない) を HTTP プロキシーを使用するように設定します。

        ...
        env:
        - name: http_proxy
          value: http://egress-1:8080/ 1
        - name: https_proxy
          value: http://egress-1:8080/
        ...
    1
    手順 2 で作成されたサービス。
    注記

    すべてのセットアップに http_proxy および https_proxy 環境変数が必要になる訳ではありません。上記を実行しても作業用セットアップが作成されない場合は、Pod で実行しているツールまたはソフトウェアについてのドキュメントを参照してください。

リダイレクトする egress ルーターの上記の例と同様に、ConfigMap を使用して EGRESS_HTTP_PROXY_DESTINATION を指定することもできます。

6.5.2.5. Egress ルーター Pod のフェイルオーバーの有効化

レプリケーションコントローラーを使用し、ダウンタイムを防ぐために egress ルーター Pod の 1 つのコピーを常に確保できるようにします。

  1. 以下を使用してレプリケーションコントローラーの設定ファイルを作成します。

    apiVersion: v1
    kind: ReplicationController
    metadata:
      name: egress-demo-controller
    spec:
      replicas: 1 1
      selector:
        name: egress-demo
      template:
        metadata:
          name: egress-demo
          labels:
            name: egress-demo
          annotations:
            pod.network.openshift.io/assign-macvlan: "true"
        spec:
          initContainers:
          - name: egress-demo-init
            image: registry.access.redhat.com/openshift3/ose-egress-router
            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
            - name: EGRESS_ROUTER_MODE
              value: init
            securityContext:
              privileged: true
          containers:
          - name: egress-demo-wait
            image: registry.access.redhat.com/openshift3/ose-pod
          nodeSelector:
            site: springfield-1
    1
    replicas1 に設定されていることを確認します。1 つの Pod のみが指定される EGRESS_SOURCE 値を随時使用できるためです。これは、ルーターの単一コピーのみがラベル site=springfield-1 が設定されたノードで実行されることを意味します。
  2. この定義を使用して Pod を作成します。

    $ oc create -f <replication_controller>.json
  3. 検証するには、レプリケーションコントローラー Pod が作成されているかどうかを確認します。

    $ oc describe rc <replication_controller>

6.5.3. 外部リソースへのアクセスを制限するための iptables ルールの使用

クラスター管理者の中には、EgressNetworkPolicy のモデルや egress ルーターの対象外の発信トラフィックに対してアクションを実行する必要のある管理者がいる場合があります。この場合には、iptables ルールを直接作成してこれを実行することができます。

たとえば、特定の宛先へのトラフィックをログに記録するルールを作成したり、1 秒ごとに設定される特定数を超える発信接続を許可しないようにしたりできます。

OpenShift Container Platform はカスタム iptables ルールを自動的に追加する方法を提供していませんが、管理者がこのようなルールを手動で追加できる場所を提供します。各ノードは起動時に、filter テーブルに OPENSHIFT-ADMIN-OUTPUT-RULES という空のチェーンを作成します (チェーンがすでに存在していないと仮定します)。管理者がこのチェーンに追加するすべてのルールは、Pod からクラスター外にある宛先へのすべてのトラフィックに適用されます (それ以外のトラフィックには適用されません)。

この機能を使用する際には、注意すべきいくつかの点があります。

  1. 各ノードにルールが作成されていることを確認するのは管理者のタスクになります。OpenShift Container Platform はこれを自動的に確認する方法は提供しません。
  2. ルールは egress ルーターによってクラスターを退出するトラフィックには適用されず、ルールは EgressNetworkPolicy ルールが適用された後に実行されます (そのため、EgressNetworkPolicy で拒否されるトラフィックは表示されません)。
  3. ノードには「外部」IP アドレスと「内部」SDN IP アドレスの両方があるため、Pod からノードまたはノードからマスターへの接続の処理は複雑になります。そのため、一部の Pod とノード間/Pod とマスター間のトラフィックはこのチェーンを通過しますが、他の Pod とノード間/Pod とマスター間のトラフィックはこれをバイパスする場合があります。

6.6. 外部プロジェクトトラフィックの静的 IP の有効化

クラスター管理者は特定の静的 IP アドレスをプロジェクトに割り当て、トラフィックが外部から容易に識別できるようにできます。これは、トラフィックを特定の宛先に送信するために使用されるデフォルトの egress ルーターの場合とは異なります。

識別可能な IP トラフィックは起点を可視化することで、クラスターのセキュリティーを強化します。これが有効にされると、指定されたプロジェクトからのすべての発信外部接続は同じ固定ソース IP を共有します。つまり、すべての外部リソースがこのトラフィックを認識できるようになります。

egress ルーターの場合とは異なり、これは EgressNetworkPolicy ファイアウォールルールに基づいて実行されます。

静的 IP を有効にするには、以下を実行します。

  1. 必要な IP で NetNamespace を更新します。

    $ oc patch netnamespace <project_name> -p '{"egressIPs": ["<IP_address>"]}'

    たとえば、MyProject プロジェクトを IP アドレス 192.168.1.100 に割り当てるには、以下を実行します。

    $ oc patch netnamespace MyProject -p '{"egressIPs": ["192.168.1.100"]}'

    egressIPs フィールドは配列ですが、単一 IP アドレスに設定される必要があります。複数の IP を設定すると、他の IP は無視されます。

  2. egress IP を必要なノードホストに手動で割り当てます。ノードホストの HostSubnet オブジェクトの egressIPs フィールドを設定します。そのノードホストに割り当てる必要のある任意の数の IP を含めることができます。

    $ oc patch hostsubnet <node_name> -p \
      '{"egressIPs": ["<IP_address_1>", "<IP_address_2>"]}'

    たとえば node1 に egress IPs 192.168.1.100、192.168.1.101 および 192.168.1.102 が必要である場合が、以下のようになります。

    $ oc patch hostsubnet node1 -p \
      '{"egressIPs": ["192.168.1.100", "192.168.1.101", "192.168.1.102"]}'
    重要

    Egress IP はプライマリーネットワークインターフェースの追加の IP として実装され、ノードのプライマリー IP と同じサブネットに置かれる必要があります。一部のクラウドまたは仮想マシンソリューションを使用する場合に、プライマリーネットワークインターフェースで追加の IP アドレスを許可するには追加の設定が必要になる場合があります。

プロジェクトに対して上記が有効にされる場合、そのプロジェクトからのすべての egress トラフィックはその egress IP をホストするノードにルーティングされ、(NAT を使用して) その IP アドレスに接続されます。egressIPsNetNamespace で設定されているものの、その egress IP をホストするノードがない場合、namespace からの egress トラフィックはドロップされます。

6.7. マルチキャストの有効化

重要

現時点で、マルチキャストは低帯域幅の調整またはサービスの検出での使用に最も適しており、高帯域幅のソリューションとしては適していません。

OpenShift Container Platform の Pod 間のマルチキャストトラフィックはデフォルトで無効にされています。プロジェクトの対応する netnamespace オブジェクトにアノテーションを設定することで、プロジェクトごとにマルチキャストを有効にすることができます。

$ oc annotate netnamespace <namespace> \
    netnamespace.network.openshift.io/multicast-enabled=true

アノテーションを削除してマルチキャストを無効にします。

$ oc annotate netnamespace <namespace> \
    netnamespace.network.openshift.io/multicast-enabled-

ネットワークを結合している場合、すべてのプロジェクトで有効にされるようにマルチキャストを各プロジェクトの netnamespace で有効にする必要があります。マルチキャストをデフォルトプロジェクトで有効にするには、これを kube-service-catalog プロジェクトおよび グローバルにされたその他すべてのプロジェクトでも有効にする必要があります。

注記

マルチキャストのグローバルプロジェクトは、ユニキャストの場合のクラスター内のすべてのプロジェクトと通信するという文脈で「グローバル」なのではなく、マルチキャストによって他のグローバルプロジェクトのみと通信します。

6.8. NetworkPolicy の有効化

ovs-subnet および ovs-multitenant プラグインにはネットワークの分離についての独自のレガシーモデルがありますが、Kubernetes NetworkPolicy はサポートしません。ただし、NetworkPolicy サポートは、ovs-networkpolicy プラグインを使用すると利用できます。

ovs-networkpolicy プラグインを使用するよう設定されるクラスターでは、ネットワークの分離は完全に NetworkPolicy オブジェクトによって制御されます。デフォルトで、プロジェクトのすべての Pod は他の Pod およびネットワークのエンドポイントからアクセスできます。プロジェクト内の 1 つ以上の Pod を分離するには、そのプロジェクトで NetworkPolicy オブジェクトを作成し、許可する着信接続を指定します。プロジェクト管理者は独自のプロジェクト内で NetworkPolicy オブジェクトの作成および削除を実行できます。

Pod を参照する NetworkPolicy オブジェクトを持たない Pod は完全にアクセスできますが、Pod を参照する 1 つ以上の NetworkPolicy オブジェクトを持つ Pod は分離されます。これらの分離された Pod は 1 つ以上の NetworkPolicy オブジェクトで許可される接続のみを受け入れます。

複数の異なるシナリオに対応するいくつかの NetworkPolicy オブジェクト定義を見てみましょう。

  • すべてのトラフィックを拒否

    プロジェクトに「deny by default (デフォルトで拒否)」を実行させるには、すべての Pod に一致するが、トラフィックを一切許可しない NetworkPolicy オブジェクトを追加します。

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: deny-by-default
    spec:
      podSelector:
      ingress: []
  • プロジェクト内の Pod からの接続のみを許可

    Pod が同じプロジェクト内の他の Pod からの接続を受け入れるが、他のプロジェクトの Pod からの接続を拒否するように設定するには、以下を実行します。

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: allow-same-namespace
    spec:
      podSelector:
      ingress:
      - from:
        - podSelector: {}
  • Pod ラベルに基づいて HTTP および HTTPS トラフィックのみを許可

    特定のラベル (以下の例の role=frontend) の付いた Pod への HTTP および HTTPS アクセスのみを有効にするには、以下と同様の NetworkPolicy オブジェクトを追加します。

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: allow-http-and-https
    spec:
      podSelector:
        matchLabels:
          role: frontend
      ingress:
      - ports:
        - protocol: TCP
          port: 80
        - protocol: TCP
          port: 443

NetworkPolicy オブジェクトは加算されるものです。つまり、複数の NetworkPolicy オブジェクトを組み合わせて複雑なネットワーク要件を満すことができます。

たとえば、先の例で定義された NetworkPolicy オブジェクトの場合、同じプロジェト内に allow-same-namespaceallow-http-and-https ポリシーの両方を定義することができます。これにより、ラベル role=frontend の付いた Pod は各ポリシーで許可されるすべての接続、つまり、同じ namespace の Pod からのすべての接続、および すべて の namespace の Pod からのポート 80 443 での接続を受け入れます。

6.8.1. NetworkPolicy およびルーター

ovs-multitenant プラグインを使用する場合、ルーターからすべての namespace へのトラフィックは自動的に許可されます。これは、ルーターは通常 デフォルトの namespace にあり、すべての namespace がその namespace の Pod からの接続を許可するためです。ただし ovs-networkpolicy プラグインを使用すると、これは自動的に実行されません。そのため、デフォルトで namespace を分離するポリシーがある場合は、ルーターがこれにアクセスできるように追加の手順を実行する必要があります。

1 つのオプションとして、すべてのソースからのアクセスを許可する各サービスのポリシーを作成できます。以下は例になります。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-to-database-service
spec:
  podSelector:
    matchLabels:
      role: database
  ingress:
  - ports:
    - protocol: TCP
      port: 5432

これにより、ルーターはサービスにアクセスできますが、同時に他のユーザーの namespace にある Pod もこれにアクセスできます。これらの Pod は通常はパブリックルーターを使用してサービスにアクセスできるため、これによって問題が発生することはないはずです。

または、ovs-multitenant プラグインの場合のように、デフォルト namespace からの完全アクセスを許可するポリシーを作成することもできます。

  1. ラベルをデフォルト namespace に追加します。

    重要

    これはクラスター全体に対して 1 回のみ実行する必要があります。クラスター管理ロールには、ラベルを namespace に追加することが求められます。

    $ oc label namespace default name=default
  2. その namespace からの接続を許可するポリシーを作成します。

    注記

    接続を許可するそれぞれの namespace についてこの手順を実行します。プロジェクト管理者ロールを持つユーザーがポリシーを作成できます。

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: allow-from-default-namespace
    spec:
      podSelector:
      ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              name: default

6.8.2. 新規プロジェクトのデフォルト NetworkPolicy の設定

クラスター管理者は、新規プロジェクトの作成時に、デフォルトのプロジェクトテンプレートを変更してデフォルトの NetworkPolicy オブジェクト (1 つ以上) の自動作成を有効にできます。これを実行するには、以下を行います。

  1. 新規プロジェクトのテンプレートの変更」で説明されているように、カスタムプロジェクトテンプレートを作成し、マスターがこれを使用するように設定します。
  2. 必要な NetworkPolicy オブジェクトを含むようにテンプレートを編集します。

    $ oc edit template project-request -n default
    注記

    NetworkPolicy オブジェクトを既存テンプレートに含めるには、oc edit コマンドを使用します。現時点では、oc patch を使用してオブジェクトを Template リソースに追加することはできません。

    1. それぞれのデフォルトポリシーを objects 配列の要素として追加します。

      objects:
      ...
      - apiVersion: networking.k8s.io/v1
        kind: NetworkPolicy
        metadata:
          name: allow-from-same-namespace
        spec:
          podSelector:
          ingress:
          - from:
            - podSelector: {}
      - apiVersion: networking.k8s.io/v1
        kind: NetworkPolicy
        metadata:
          name: allow-from-default-namespace
        spec:
          podSelector:
          ingress:
          - from:
            - namespaceSelector:
                matchLabels:
                  name: default
      ...

6.9. HTTP Strict Transport Security の有効化

HTTP Strict Transport Security (HSTS) ポリシーは、ホストで HTTPS トラフィックのみを許可するセキュリティーの拡張機能です。デフォルトで、すべての HTTP 要求はドロップされます。これは、web サイトとの対話の安全性を確保したり、ユーザーのためにセキュアなアプリケーションを提供するのに役立ちます。

HSTS が有効にされると、HSTS はサイトから Strict Transport Security ヘッダーを HTTPS 応答に追加します。リダイレクトするルートで insecureEdgeTerminationPolicy 値を使用し、HTTP を HTTPS に送信するようにします。ただし、HSTS が有効にされている場合は、要求の送信前にクライアントがすべての要求を HTTP URL から HTTPS に変更するためにリダイレクトの必要がなくなります。これはクライアントでサポートされる必要はなく、max-age=0 を設定することで無効にできます。

重要

HSTS はセキュアなルート (edge termination または re-encrypt) でのみ機能します。この設定は、HTTP またはパススルールートには適していません。

ルートに対して HSTS を有効にするには、haproxy.router.openshift.io/hsts_header 値を edge termination または re-encrypt ルートに追加します。

apiVersion: v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains;preload
重要

haproxy.router.openshift.io/hsts_header 値にパラメーターのスペースやその他の値が入っていないことを確認します。max-age のみが必要になります。

必須の max-age パラメーターは、HSTS ポリシーの有効期間 (秒単位) を示します。クライアントは、ホストから HSTS ヘッダーのある応答を受信する際には常に max-age を更新します。max-age がタイムアウトになると、クライアントはポリシーを破棄します。

オプションの includeSubDomains パラメーターは、クライアントに対し、ホストのすべてのサブドメインがホストど同様に処理されるように指示します。

max-age が 0 より大きい場合、オプションの preload パラメーターは外部サービスがこのサイトをそれぞれの HSTS プリロードのリストに含めることを許可します。たとえば、Google などのサイトは preload が設定されているサイトの一覧を作成します。ブラウザーはこれらのリストを使用し、サイトと対話する前でも HTTPS 経由でのみ通信するサイトを判別できます。preload 設定がない場合、ブラウザーはヘッダーを取得するために HTTPS 経由でサイトと通信している必要があります。

6.10. スループットの問題のトラブルシューティング

OpenShift Container Platform でデプロイされるアプリケーションでは、特定のサービス間で非常に長い待ち時間が発生するなど、ネットワークのスループットの問題が生じることがあります。

Pod のログが問題の原因を指摘しない場合は、以下の方法を使用してパフォーマンスの問題を分析します。

  • ping または tcpdump などのパケットアナライザーを使用して Pod とそのノード間のトラフィックを分析します。

    たとえば、問題を生じさせる動作を再現している間に各ノードで tcpdump ツールを実行します。両サイトでキャプチャーしたデータを確認し、送信および受信タイムスタンプを比較して Pod への/からのトラフィックの待ち時間を分析します。待ち時間は、ノードのインターフェースが他の Pod やストレージデバイス、またはデータプレーンからのトラフィックでオーバーロードする場合に OpenShift Container Platform で発生する可能性があります。

    $ tcpdump -s 0 -i any -w /tmp/dump.pcap host <podip 1> && host <podip 2> 1
    1
    podip は Pod の IP アドレスです。以下のコマンドを実行して Pod の IP アドレスを取得します。
    # oc get pod <podname> -o wide

    tcpdump は 2 つの Pod 間のすべてのトラフィックが含まれる /tmp/dump.pcap のファイルを生成します。理想的には、ファイルサイズを最小限に抑えるために問題を再現するすぐ前と問題を再現したすぐ後ににアナライザーを実行することが良いでしょう。以下のようにノード間でパケットアナライザーを実行することもできます (式から SDN を排除する)。

    # tcpdump -s 0 -i any -w /tmp/dump.pcap port 4789
  • ストリーミングのスループットおよび UDP スループットを測定するために iperf などの帯域幅測定ツールを使用します。ボトルネックの特定を試行するには、最初に Pod から、次にノードからツールを実行します。iperf3 ツールは RHEL 7 の一部として組み込まれています。

iperf3 のインストールおよび使用についての詳細は、こちらの Red Hat ソリューションを参照してください。

第7章 サービスアカウントの設定

7.1. 概要

ユーザーが OpenShift Container Platform CLI または web コンソールを使用する場合、API トークンはユーザーを OpenShift Container Platform API に対して認証します。ただし、一般ユーザーの認証情報を利用できない場合、以下のようにコンポーネントが API 呼び出しを行うのが通例になります。

  • レプリケーションコントローラーが Pod を作成するか、または削除するために API 呼び出しを実行する。
  • コンテナー内のアプリケーションが検出目的で API 呼び出しを実行する。
  • 外部アプリケーションがモニターまたは統合目的で API 呼び出しを実行する。

サービスアカウントは、一般ユーザーの認証情報を共有せずに API アクセスをより柔軟に制御する方法を提供します。

7.2. ユーザー名およびグループ

すべてのサービスアカウントには、一般ユーザーのように、ロールを付与できるユーザー名が関連付けられています。ユーザー名はそのプロジェクトおよび名前から派生します。

system:serviceaccount:<project>:<name>

たとえば、view (表示) ロールを top-secret プロジェクトの robot サービスアカウントに追加するには、以下を実行します。

$ oc policy add-role-to-user view system:serviceaccount:top-secret:robot
重要

プロジェクトの特定のサービスアカウントにアクセスを付与する必要がある場合は、-z フラグを使用できます。サービスアカウントが属するプロジェクトから、-z フラグを使用し、<serviceaccount_name> を指定します。これにより誤字を防ぎ、アクセスを指定したサービスアカウントのみに付与できるため、この方法を使用することを強くお勧めします。以下は例になります。

 $ oc policy add-role-to-user <role_name> -z <serviceaccount_name>

プロジェクトにいない場合は、以下の例に示すように -n オプションを使用してこれを適用するプロジェクトの namespace を示します。

すべてのサービスアカウントは以下の 2 つのグループのメンバーです。

system:serviceaccount
システムのすべてのサービスアカウントが含まれます。
system:serviceaccount:<project>
指定されたプロジェクトのすべてのサービスアカウントが含まれます。

たとえば、すべてのプロジェクトのすべてのサービスアカウントが top-secret プロジェクトのリソースを表示できるようにするには、以下を実行します。

$ oc policy add-role-to-group view system:serviceaccount -n top-secret

managers プロジェクトのすべてのサービスアカウントが top-secret プロジェクトのリソースを編集できるようにするには、以下を実行します。

$ oc policy add-role-to-group edit system:serviceaccount:managers -n top-secret

7.3. サービスアカウントの管理

サービスアカウントは、各プロジェクトに存在する API オブジェクトです。サービスアカウントを管理するには、sa または serviceaccount オブジェクトタイプと共に oc コマンドを使用するか、または web コンソールを使用することができます。

現在のプロジェクトで既存のサービスアカウントの一覧を取得するには、以下を実行します。

$ oc get sa
NAME       SECRETS   AGE
builder    2         2d
default    2         2d
deployer   2         2d

新規のサービスアカウントを作成するには、以下を実行します。

$ oc create sa robot
serviceaccount "robot" created

サービスアカウントの作成後すぐに、以下の 2 つのシークレットがこれに自動的に追加されます。

  • API トークン
  • OpenShift Container レジストリーの認証情報

これらは、サービスアカウントの記述で表示できます。

$ oc describe sa robot
Name:		robot
Namespace:	project1
Labels:		<none>
Annotations:	<none>

Image pull secrets:	robot-dockercfg-qzbhb

Mountable secrets: 	robot-token-f4khf
                   	robot-dockercfg-qzbhb

Tokens:            	robot-token-f4khf
                   	robot-token-z8h44

システムはサービスアカウントに API トークンとレジストリーの認証情報が常にあることを確認します。

生成される API トークンとレジストリーの認証情報は期限切れになることはありませんが、シークレットを削除することで取り消すことができます。シークレットが削除されると、新規のシークレットが自動生成され、これに置き換わります。

7.4. サービスアカウント認証の有効化

サービスアカウントは、プライベート RSA キーで署名されるトークンを使用して API に対して認証されます。認証層では一致するパブリック RSA キーを使用して署名を検証します。

サービスアカウントトークンの生成を有効にするには、マスターで /etc/origin/master/master-config.yml ファイルの serviceAccountConfig スタンザを更新し、(署名 用に) privateKeyFilepublicKeyFiles 一覧の一致するパブリックキーファイルを指定します。

serviceAccountConfig:
  ...
  masterCA: ca.crt 1
  privateKeyFile: serviceaccount.private.key 2
  publicKeyFiles:
  - serviceaccount.public.key 3
  - ...
1
API サーバーの提供する証明書を検証するために使用される CA ファイル。
2
プライベート RSA キーファイル (トークンの署名用)。
3
パブリック RSA キーファイル (トークンの検証用)。プライベートキーファイルが提供されている場合、パブリックキーコンポーネントが使用されます。複数のパブリックキーファイルを使用でき、トークンはパブリックキーのいずれかで検証できる場合に受け入れられます。これにより、署名するキーのローテーションが可能となり、以前の署名者が生成したトークンは依然として受け入れられます。

7.5. 管理サービスアカウント

サービスアカウントは、ビルド、デプロイメントおよびその他の Pod を実行するために各プロジェクトで必要になります。マスターの /etc/origin/master/master-config.yml ファイルの managedNames 設定は、すべてのプロジェクトに自動作成されるサービスアカウントを制御します。

serviceAccountConfig:
  ...
  managedNames: 1
  - builder 2
  - deployer 3
  - default 4
  - ...
1
すべてのプロジェクトで自動作成するサービスアカウントの一覧。
2
各プロジェクトの builder サービスは、ビルド Pod で必要になり、内部コンテナーレジストリーを使用してプロジェクトのイメージストリームにイメージをプッシュする system:image-builder ロールが付与されます。
3
各プロジェクトの deployer サービスアカウントはデプロイメント Pod で必要になり、レプリケーションコントローラーおよびプロジェクトの Pod の表示および変更を可能にする system:deployer ロールが付与されます。
4
デフォルトのサービスアカウントは、別のサービスアカウントが指定されない限り、他のすべての Pod で使用されます。

プロジェクトのすべてのサービスアカウントには、内部コンテナーレジストリーを使用してイメージストリームからイメージのプルを可能にする system:image-puller ロールが付与されます。

7.6. インフラストラクチャーサービスアカウント

一部のインフラストラクチャーコントローラーは、サービスアカウント認証情報を使用して実行されます。以下のサービスアカウントは、サーバーの起動時に OpenShift Container Platform インフラストラクチャープロジェクト (openshift-infra) に作成され、クラスター全体で以下のロールが付与されます。

サービスアカウント説明

replication-controller

system:replication-controller ロールの割り当て

deployment-controller

system:deployment-controller ロールの割り当て

build-controller

system:build-controller ロールの割り当て。さらに、build-controller サービスアカウントは、特権付きの ビルド Pod を作成するために特権付きセキュリティーコンテキストに組み込まれます。

これらのサービスアカウントが作成されるプロジェクトを設定するには、マスターで /etc/origin/master/master-config.yml ファイルの openshiftInfrastructureNamespace フィールドを設定します。

policyConfig:
  ...
  openshiftInfrastructureNamespace: openshift-infra

7.7. サービスアカウントおよびシークレット

マスターで /etc/origin/master/master-config.yml ファイルの limitSecretReferences フィールドを true に設定し、Pod のシークレット参照をサービスアカウントでホワイトリストに入れることが必要になるようにします。この値を false に設定すると、Pod がプロジェクトのすべてのシークレットを参照できるようになります。

serviceAccountConfig:
  ...
  limitSecretReferences: false

第8章 ロールベースアクセス制御 (RBAC) の管理

8.1. 概要

CLI を使用して RBAC リソースを表示し、管理者 CLI を使用してロールとバインディングを管理することができます。

8.2. ロールとバインディングの表示

ロールは、クラスター全体およびプロジェクトのスコープの両方で各種のアクセスレベルを付与するために使用できます。ユーザーおよびグループは、1 度に複数のロールに関連付けるか、またはバインドすることができます。oc describe コマンドを使用して、ロールおよびそれらのバインディングの詳細を確認できます。

クラスター全体でバインドされた cluster-admin のデフォルトクラスターロールを持つユーザーはすべてのリソースに対してすべてのアクションを実行できます。ローカルにバインドされた admin のデフォルトクラスターロールを持つユーザーはそのプロジェクト内のロールとバインディングをローカルに管理できます。

注記

Evaluating Authorization」セクションで動詞の詳細リストを確認してください。

8.2.1. クラスターロールの表示

クラスターロールおよびそれらの関連付けられたルールセットを表示するには、以下を実行します。

$ oc describe clusterrole.rbac

クラスターロールの表示

$ oc describe clusterrole.rbac
Name:		admin
Labels:		<none>
Annotations:	openshift.io/description=A user that has edit rights within the project and can change the project's membership.
		rbac.authorization.kubernetes.io/autoupdate=true
PolicyRule:
  Resources							Non-Resource URLs	Resource Names	Verbs
  ---------							-----------------	--------------	-----
  appliedclusterresourcequotas					[]			[]		[get list watch]
  appliedclusterresourcequotas.quota.openshift.io		[]			[]		[get list watch]
  bindings							[]			[]		[get list watch]
  buildconfigs							[]			[]		[create delete deletecollection get list patch update watch]
  buildconfigs.build.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  buildconfigs/instantiate					[]			[]		[create]
  buildconfigs.build.openshift.io/instantiate			[]			[]		[create]
  buildconfigs/instantiatebinary				[]			[]		[create]
  buildconfigs.build.openshift.io/instantiatebinary		[]			[]		[create]
  buildconfigs/webhooks						[]			[]		[create delete deletecollection get list patch update watch]
  buildconfigs.build.openshift.io/webhooks			[]			[]		[create delete deletecollection get list patch update watch]
  buildlogs							[]			[]		[create delete deletecollection get list patch update watch]
  buildlogs.build.openshift.io					[]			[]		[create delete deletecollection get list patch update watch]
  builds							[]			[]		[create delete deletecollection get list patch update watch]
  builds.build.openshift.io					[]			[]		[create delete deletecollection get list patch update watch]
  builds/clone							[]			[]		[create]
  builds.build.openshift.io/clone				[]			[]		[create]
  builds/details						[]			[]		[update]
  builds.build.openshift.io/details				[]			[]		[update]
  builds/log							[]			[]		[get list watch]
  builds.build.openshift.io/log					[]			[]		[get list watch]
  configmaps							[]			[]		[create delete deletecollection get list patch update watch]
  cronjobs.batch						[]			[]		[create delete deletecollection get list patch update watch]
  daemonsets.extensions						[]			[]		[get list watch]
  deploymentconfigrollbacks					[]			[]		[create]
  deploymentconfigrollbacks.apps.openshift.io			[]			[]		[create]
  deploymentconfigs						[]			[]		[create delete deletecollection get list patch update watch]
  deploymentconfigs.apps.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  deploymentconfigs/instantiate					[]			[]		[create]
  deploymentconfigs.apps.openshift.io/instantiate		[]			[]		[create]
  deploymentconfigs/log						[]			[]		[get list watch]
  deploymentconfigs.apps.openshift.io/log			[]			[]		[get list watch]
  deploymentconfigs/rollback					[]			[]		[create]
  deploymentconfigs.apps.openshift.io/rollback			[]			[]		[create]
  deploymentconfigs/scale					[]			[]		[create delete deletecollection get list patch update watch]
  deploymentconfigs.apps.openshift.io/scale			[]			[]		[create delete deletecollection get list patch update watch]
  deploymentconfigs/status					[]			[]		[get list watch]
  deploymentconfigs.apps.openshift.io/status			[]			[]		[get list watch]
  deployments.apps						[]			[]		[create delete deletecollection get list patch update watch]
  deployments.extensions					[]			[]		[create delete deletecollection get list patch update watch]
  deployments.extensions/rollback				[]			[]		[create delete deletecollection get list patch update watch]
  deployments.apps/scale					[]			[]		[create delete deletecollection get list patch update watch]
  deployments.extensions/scale					[]			[]		[create delete deletecollection get list patch update watch]
  deployments.apps/status					[]			[]		[create delete deletecollection get list patch update watch]
  endpoints							[]			[]		[create delete deletecollection get list patch update watch]
  events							[]			[]		[get list watch]
  horizontalpodautoscalers.autoscaling				[]			[]		[create delete deletecollection get list patch update watch]
  horizontalpodautoscalers.extensions				[]			[]		[create delete deletecollection get list patch update watch]
  imagestreamimages						[]			[]		[create delete deletecollection get list patch update watch]
  imagestreamimages.image.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  imagestreamimports						[]			[]		[create]
  imagestreamimports.image.openshift.io				[]			[]		[create]
  imagestreammappings						[]			[]		[create delete deletecollection get list patch update watch]
  imagestreammappings.image.openshift.io			[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams							[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams.image.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams/layers						[]			[]		[get update]
  imagestreams.image.openshift.io/layers			[]			[]		[get update]
  imagestreams/secrets						[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams.image.openshift.io/secrets			[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams/status						[]			[]		[get list watch]
  imagestreams.image.openshift.io/status			[]			[]		[get list watch]
  imagestreamtags						[]			[]		[create delete deletecollection get list patch update watch]
  imagestreamtags.image.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  jenkins.build.openshift.io					[]			[]		[admin edit view]
  jobs.batch							[]			[]		[create delete deletecollection get list patch update watch]
  limitranges							[]			[]		[get list watch]
  localresourceaccessreviews					[]			[]		[create]
  localresourceaccessreviews.authorization.openshift.io		[]			[]		[create]
  localsubjectaccessreviews					[]			[]		[create]
  localsubjectaccessreviews.authorization.k8s.io		[]			[]		[create]
  localsubjectaccessreviews.authorization.openshift.io		[]			[]		[create]
  namespaces							[]			[]		[get list watch]
  namespaces/status						[]			[]		[get list watch]
  networkpolicies.extensions					[]			[]		[create delete deletecollection get list patch update watch]
  persistentvolumeclaims					[]			[]		[create delete deletecollection get list patch update watch]
  pods								[]			[]		[create delete deletecollection get list patch update watch]
  pods/attach							[]			[]		[create delete deletecollection get list patch update watch]
  pods/exec							[]			[]		[create delete deletecollection get list patch update watch]
  pods/log							[]			[]		[get list watch]
  pods/portforward						[]			[]		[create delete deletecollection get list patch update watch]
  pods/proxy							[]			[]		[create delete deletecollection get list patch update watch]
  pods/status							[]			[]		[get list watch]
  podsecuritypolicyreviews					[]			[]		[create]
  podsecuritypolicyreviews.security.openshift.io		[]			[]		[create]
  podsecuritypolicyselfsubjectreviews				[]			[]		[create]
  podsecuritypolicyselfsubjectreviews.security.openshift.io	[]			[]		[create]
  podsecuritypolicysubjectreviews				[]			[]		[create]
  podsecuritypolicysubjectreviews.security.openshift.io		[]			[]		[create]
  processedtemplates						[]			[]		[create delete deletecollection get list patch update watch]
  processedtemplates.template.openshift.io			[]			[]		[create delete deletecollection get list patch update watch]
  projects							[]			[]		[delete get patch update]
  projects.project.openshift.io					[]			[]		[delete get patch update]
  replicasets.extensions					[]			[]		[create delete deletecollection get list patch update watch]
  replicasets.extensions/scale					[]			[]		[create delete deletecollection get list patch update watch]
  replicationcontrollers					[]			[]		[create delete deletecollection get list patch update watch]
  replicationcontrollers/scale					[]			[]		[create delete deletecollection get list patch update watch]
  replicationcontrollers.extensions/scale			[]			[]		[create delete deletecollection get list patch update watch]
  replicationcontrollers/status					[]			[]		[get list watch]
  resourceaccessreviews						[]			[]		[create]
  resourceaccessreviews.authorization.openshift.io		[]			[]		[create]
  resourcequotas						[]			[]		[get list watch]
  resourcequotas/status						[]			[]		[get list watch]
  resourcequotausages						[]			[]		[get list watch]
  rolebindingrestrictions					[]			[]		[get list watch]
  rolebindingrestrictions.authorization.openshift.io		[]			[]		[get list watch]
  rolebindings							[]			[]		[create delete deletecollection get list patch update watch]
  rolebindings.authorization.openshift.io			[]			[]		[create delete deletecollection get list patch update watch]
  rolebindings.rbac.authorization.k8s.io			[]			[]		[create delete deletecollection get list patch update watch]
  roles								[]			[]		[create delete deletecollection get list patch update watch]
  roles.authorization.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  roles.rbac.authorization.k8s.io				[]			[]		[create delete deletecollection get list patch update watch]
  routes							[]			[]		[create delete deletecollection get list patch update watch]
  routes.route.openshift.io					[]			[]		[create delete deletecollection get list patch update watch]
  routes/custom-host						[]			[]		[create]
  routes.route.openshift.io/custom-host				[]			[]		[create]
  routes/status							[]			[]		[get list watch update]
  routes.route.openshift.io/status				[]			[]		[get list watch update]
  scheduledjobs.batch						[]			[]		[create delete deletecollection get list patch update watch]
  secrets							[]			[]		[create delete deletecollection get list patch update watch]
  serviceaccounts						[]			[]		[create delete deletecollection get list patch update watch impersonate]
  services							[]			[]		[create delete deletecollection get list patch update watch]
  services/proxy						[]			[]		[create delete deletecollection get list patch update watch]
  statefulsets.apps						[]			[]		[create delete deletecollection get list patch update watch]
  subjectaccessreviews						[]			[]		[create]
  subjectaccessreviews.authorization.openshift.io		[]			[]		[create]
  subjectrulesreviews						[]			[]		[create]
  subjectrulesreviews.authorization.openshift.io		[]			[]		[create]
  templateconfigs						[]			[]		[create delete deletecollection get list patch update watch]
  templateconfigs.template.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  templateinstances						[]			[]		[create delete deletecollection get list patch update watch]
  templateinstances.template.openshift.io			[]			[]		[create delete deletecollection get list patch update watch]
  templates							[]			[]		[create delete deletecollection get list patch update watch]
  templates.template.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]


Name:		basic-user
Labels:		<none>
Annotations:	openshift.io/description=A user that can get basic information about projects.
		rbac.authorization.kubernetes.io/autoupdate=true
PolicyRule:
  Resources						Non-Resource URLs	Resource Names	Verbs
  ---------						-----------------	--------------	-----
  clusterroles						[]			[]		[get list]
  clusterroles.authorization.openshift.io		[]			[]		[get list]
  clusterroles.rbac.authorization.k8s.io		[]			[]		[get list watch]
  projectrequests					[]			[]		[list]
  projectrequests.project.openshift.io			[]			[]		[list]
  projects						[]			[]		[list watch]
  projects.project.openshift.io				[]			[]		[list watch]
  selfsubjectaccessreviews.authorization.k8s.io		[]			[]		[create]
  selfsubjectrulesreviews				[]			[]		[create]
  selfsubjectrulesreviews.authorization.openshift.io	[]			[]		[create]
  storageclasses.storage.k8s.io				[]			[]		[get list]
  users							[]			[~]		[get]
  users.user.openshift.io				[]			[~]		[get]


Name:		cluster-admin
Labels:		<none>
Annotations:	authorization.openshift.io/system-only=true
		openshift.io/description=A super-user that can perform any action in the cluster. When granted to a user within a project, they have full control over quota and membership and can perform every action...
		rbac.authorization.kubernetes.io/autoupdate=true
PolicyRule:
  Resources	Non-Resource URLs	Resource Names	Verbs
  ---------	-----------------	--------------	-----
  		[*]			[]		[*]
  *.*		[]			[]		[*]


Name:		cluster-debugger
Labels:		<none>
Annotations:	authorization.openshift.io/system-only=true
		rbac.authorization.kubernetes.io/autoupdate=true
PolicyRule:
  Resources	Non-Resource URLs	Resource Names	Verbs
  ---------	-----------------	--------------	-----
  		[/debug/pprof]		[]		[get]
  		[/debug/pprof/*]	[]		[get]
  		[/metrics]		[]		[get]


Name:		cluster-reader
Labels:		<none>
Annotations:	authorization.openshift.io/system-only=true
		rbac.authorization.kubernetes.io/autoupdate=true
PolicyRule:
  Resources							Non-Resource URLs	Resource Names	Verbs
  ---------							-----------------	--------------	-----
  								[*]			[]		[get]
  apiservices.apiregistration.k8s.io				[]			[]		[get list watch]
  apiservices.apiregistration.k8s.io/status			[]			[]		[get list watch]
  appliedclusterresourcequotas					[]			[]		[get list watch]

...

各種のロールにバインドされたユーザーおよびグループを示す、クラスターのロールバインディングの現在のセットを表示するには、以下を実行します。

$ oc describe clusterrolebinding.rbac

クラスターのロールバインディングの表示

$ oc describe clusterrolebinding.rbac
Name:		admin
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	admin
Subjects:
  Kind			Name				Namespace
  ----			----				---------
  ServiceAccount	template-instance-controller	openshift-infra


Name:		basic-users
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	basic-user
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:authenticated


Name:		cluster-admin
Labels:		kubernetes.io/bootstrapping=rbac-defaults
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	cluster-admin
Subjects:
  Kind			Name		Namespace
  ----			----		---------
  ServiceAccount	pvinstaller	default
  Group			system:masters


Name:		cluster-admins
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	cluster-admin
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:cluster-admins
  User	system:admin


Name:		cluster-readers
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	cluster-reader
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:cluster-readers


Name:		cluster-status-binding
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	cluster-status
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:authenticated
  Group	system:unauthenticated


Name:		registry-registry-role
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	system:registry
Subjects:
  Kind			Name		Namespace
  ----			----		---------
  ServiceAccount	registry	default


Name:		router-router-role
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	system:router
Subjects:
  Kind			Name	Namespace
  ----			----	---------
  ServiceAccount	router	default


Name:		self-access-reviewers
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	self-access-reviewer
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:authenticated
  Group	system:unauthenticated


Name:		self-provisioners
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	self-provisioner
Subjects:
  Kind	Name				Namespace
  ----	----				---------
  Group	system:authenticated:oauth


Name:		system:basic-user
Labels:		kubernetes.io/bootstrapping=rbac-defaults
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	system:basic-user
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:authenticated
  Group	system:unauthenticated


Name:		system:build-strategy-docker-binding
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	system:build-strategy-docker
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:authenticated


Name:		system:build-strategy-jenkinspipeline-binding
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	system:build-strategy-jenkinspipeline
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:authenticated


Name:		system:build-strategy-source-binding
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	system:build-strategy-source
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:authenticated


Name:		system:controller:attachdetach-controller
Labels:		kubernetes.io/bootstrapping=rbac-defaults
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	system:controller:attachdetach-controller
Subjects:
  Kind			Name			Namespace
  ----			----			---------
  ServiceAccount	attachdetach-controller	kube-system


Name:		system:controller:certificate-controller
Labels:		kubernetes.io/bootstrapping=rbac-defaults
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	system:controller:certificate-controller
Subjects:
  Kind			Name			Namespace
  ----			----			---------
  ServiceAccount	certificate-controller	kube-system


Name:		system:controller:cronjob-controller
Labels:		kubernetes.io/bootstrapping=rbac-defaults
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true

...

8.2.2. ローカルのロールバインディングの表示

すべてのデフォルトクラスターロールは、ユーザーまたはグループにローカルにバインドできます。

カスタムローカルロールを作成できます。

ローカルのロールバインディングも表示することができます。

各種のロールにバインドされたユーザーおよびグループを示す、ローカルのロールバインディングの現在のセットを表示するには、以下を実行します。

$ oc describe rolebinding.rbac

デフォルトでは、ローカルのロールバインディングを表示する際に現在のプロジェクトが使用されます。または、プロジェクトは -n フラグで指定できます。これは、ユーザーに adminデフォルトクラスターロールがすでにある場合、別のプロジェクトのローカルのロールバンディングを表示するのに役立ちます。

ローカルのロールバンディングの表示

$ oc describe rolebinding.rbac -n joe-project
Name:		admin
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	admin
Subjects:
  Kind	Name	Namespace
  ----	----	---------
  User	joe


Name:		system:deployers
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	system:deployer
Subjects:
  Kind			Name		Namespace
  ----			----		---------
  ServiceAccount	deployer	joe-project


Name:		system:image-builders
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	system:image-builder
Subjects:
  Kind			Name	Namespace
  ----			----	---------
  ServiceAccount	builder	joe-project


Name:		system:image-pullers
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	system:image-puller
Subjects:
  Kind	Name					Namespace
  ----	----					---------
  Group	system:serviceaccounts:joe-project

8.3. ロールバインディングの管理

ロールユーザーまたはグループに追加、またはバインドすることにより、そのユーザーまたはグループにそのロールによって付与される関連アクセスが提供されます。oc adm policy コマンドを使用して、ユーザーおよびグループに対するロールの追加および削除を実行できます。

以下の操作を使用し、ローカルのロールバインディングでのユーザーまたはグループの関連付けられたロールを管理する際に、プロジェクトは -n フラグで指定できます。これが指定されていない場合には、現在のプロジェクトが使用されます。

表8.1 ローカルのロールバインディング操作

コマンド説明

$ oc adm policy who-can <verb> <resource>

リソースに対してアクションを実行できるユーザーを示します。

$ oc adm policy add-role-to-user <role> <username>

指定されたロールを現在のプロジェクトの指定ユーザーにバインドします。

$ oc adm policy remove-role-from-user <role> <username>

現在のプロジェクトの指定ユーザーから指定されたロールを削除します。

$ oc adm policy remove-user <username>

現在のプロジェクトの指定ユーザーとそれらのロールのすべてを削除します。

$ oc adm policy add-role-to-group <role> <groupname>

指定されたロールを現在のプロジェクトの指定グループにバインドします。

$ oc adm policy remove-role-from-group <role> <groupname>

現在のプロジェクトの指定グループから指定されたロールを削除します。

$ oc adm policy remove-group <groupname>

現在のプロジェクトの指定グループとそれらのロールのすべてを削除します。

以下の操作を使用して、クラスターのロールバインディングも管理できます。クラスターのロールバインディングは namespace を使用していないリソースを使用するため、-n フラグはこれらの操作に使用されません。

表8.2 クラスターのロールバインディング操作

コマンド説明

$ oc adm policy add-cluster-role-to-user <role> <username>

指定されたロールをクラスターのすべてのプロジェクトの指定ユーザーにバインドします。

$ oc adm policy remove-cluster-role-from-user <role> <username>

指定されたロールをクラスターのすべてのプロジェクトの指定ユーザーから削除します。

$ oc adm policy add-cluster-role-to-group <role> <groupname>

指定されたロールをクラスターのすべてのプロジェクトの指定グループにバインドします。

$ oc adm policy remove-cluster-role-from-group <role> <groupname>

指定されたロールをクラスターのすべてのプロジェクトの指定グループから削除します。

たとえば、以下を実行して admin ロールを joe-projectalice ユーザーに追加できます。

$ oc adm policy add-role-to-user admin alice -n joe-project

次に、ローカルのロールバインディングを表示し、出力に追加されていることを確認します。

$ oc describe rolebinding.rbac -n joe-project
Name:		admin
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	admin
Subjects:
  Kind	Name	Namespace
  ----	----	---------
  User	joe
  User	alice 1


Name:		system:deployers
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	system:deployer
Subjects:
  Kind			Name		Namespace
  ----			----		---------
  ServiceAccount	deployer	joe-project


Name:		system:image-builders
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	system:image-builder
Subjects:
  Kind			Name	Namespace
  ----			----	---------
  ServiceAccount	builder	joe-project


Name:		system:image-pullers
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	system:image-puller
Subjects:
  Kind	Name					Namespace
  ----	----					---------
  Group	system:serviceaccounts:joe-project
1
alice ユーザーが admins RoleBinding に追加されています。

8.4. ローカルロールの作成

プロジェクトのローカルロールを作成するには、以下のコマンドを実行します。

$ oc create role ...

このコマンドの以下の help の抜粋は、このコマンドの使用方法を説明しています。

Create a role with single rule.

Usage:
  oc create role NAME --verb=verb --resource=resource.group/subresource [--resource-name=resourcename] [--dry-run] [options]

Examples:
  # Create a Role named "pod-reader" that allows user to perform "get", "watch" and "list" on pods
  oc create role pod-reader --verb=get --verb=list --verb=watch --resource=pods

  # Create a Role named "pod-reader" with ResourceName specified
  oc create role pod-reader --verb=get,list,watch --resource=pods --resource-name=readablepod --resource-name=anotherpod

  # Create a Role named "foo" with API Group specified
  oc create role foo --verb=get,list,watch --resource=rs.extensions

  # Create a Role named "foo" with SubResource specified
  oc create role foo --verb=get,list,watch --resource=pods,pods/status

Options:
      --dry-run=false: If true, only print the object that would be sent, without sending it.
      --resource=[]: resource that the rule applies to
      --resource-name=[]: resource in the white list that the rule applies to, repeat this flag for multiple items
      --verb=[]: verb that applies to the resources contained in the rule

...

たとえば、ユーザーが Pod を表示できるようにするロールを作成するには、以下を実行します。

$ oc create role podview --verb=get --resource=pod -n bob-project

オプションで、これに説明のアノテーションを付けます。

新規ロールをユーザーにバインドするには、以下を実行します。

$ oc adm policy add-role-to-user podview user2 --role-namespace=bob-project -n bob-project

8.5. クラスターおよびローカルのロールバインディング

クラスターのロールバインディングは、クラスターレベルで存在するバインディングですが、ロールバインディングはプロジェクトレベルで存在します。クラスターの view (表示) ロールは、ユーザーがプロジェクトを表示できるようローカルのロールバインディングを使用してユーザーにバインドする必要があります。ローカルロールは、クラスターのロールが特定の状況に必要なパーミッションのセットを提供しない場合にのみ作成する必要があります。

一部のクラスターのロール名は最初は判別しにくい場合があります。クラスターロール clusteradmin は、ローカルのロールバインディングを使用してユーザーにバインドでき、このユーザーがクラスター管理者の特権を持っているように見せますが、実際にはそうではありません。一方、特定プロジェクトにバインドされる clusteradmin クラスターロールはそのプロジェクトのスーパー管理者のような機能があり、クラスターロール admin のパーミッションを付与するほか、レート制限を編集する機能などのいくつかの追加パーミッションを付与します。これは、 (実際のクラスター管理者にバインドされる) クラスターのロールバインディング を一覧表示しない Web コンソール UI を使う場合にとくに分かりにくくなりますが、この Web コンソール UI はローカルのロールバインディング (clusteradmin をローカルにバインドするために使用される) を一覧表示します。

第9章 イメージポリシー

9.1. 概要

インポートするイメージや、タグ付けしたり、クラスターで実行したりするイメージを制御することができます。この目的のために使用できる 2 つの機能があります。

インポート用に許可されるレジストリーは、イメージの起点 (origin) を特定の外部レジストリーのセットに制限できるイメージポリシー設定です。このルールセットはイメージストリームにインポートされるか、またはタグ付けされるすべてのイメージに適用されます。したがって、ルールセットと一致しないレジストリーを参照するイメージは拒否されます。

ImagePolicy 受付プラグイン を使用すると、クラスターでの実行を許可するイメージを指定できます。これは現時点ではベータ機能と見なされています。この機能により、以下を制御することができます。

  • イメージソース: イメージのプルに使用できるレジストリーについての指定。
  • イメージの解決: イメージが再タグ付けによって変更されないよう Pod のイミュータブルなダイジェストでの実行を強制する。
  • コンテナーイメージラベルの制限: イメージのラベルを制限するか、または要求する。
  • イメージアノテーションの制限: 統合コンテナーレジストリーでのイメージのアノテーションを制限するか、または要求する。

9.2. インポート用に許可されるレジストリーの設定

以下の例に示されるように、imagePolicyConfig:allowedRegistriesForImport セクション以下にある master-config.yaml にインポート用に許可されるレジスターを設定できます。この設定がない場合は、すべてのイメージが許可されます。

例9.1 インポート用に許可されるレジストリーの設定例

imagePolicyConfig:
  allowedRegistriesForImport:
  -
    domainName: registry.access.redhat.com 1
  -
    domainName: *.mydomain.com
    insecure: true 2
  -
    domainName: local.registry.corp:5000 3
1
指定されたセキュアなレジストリーからのイメージを許可します。
2
mydomain.com の任意のサブドメインでホストされる非セキュアなレジストリーからのイメージを許可します。mydomain.com はホワイトリストに追加されません。
3
ポートが指定された指定レジストリーからのイメージを許可します。

各ルールは以下の属性で構成されています。

  • domainName: ホスト名であり、オプションでその最後は :<port> サフィックスになり、ここで特殊なワイルドカード文字 (?*) が認識されます。ワイルドカード文字は : 区切り文字の前後の両方に置くことができます。ワイルドカードは区切り文字の前または後の部分に適用されます。
  • insecure: :<port> の部分が domainName にない場合、一致するポートを判別するために使用されるブール値です。true の場合、domainName はインポート時に非セキュアなフラグが使用されている限り、サフィックスが :80 のポートが設定されているか、またはポートが未指定のレジストリーに一致します。false の場合、サフィックスが :443 のポートか、またはポートが未指定のレジストリーが一致します。

ルールが同じドメインのセキュアなポートと非セキュアなポートの両方に一致する場合、ルールは 2 回一覧表示されるはずです (1 回は insecure=true が設定され、もう 1 回は insecure=false が設定されます)。

修飾されていないイメージ参照は、ルールの評価前に docker.io に対して修飾されます。これらをホワイトリストに追加するには、domainName: docker.io を使用します。

domainName: * ルールは任意のレジストリーのホスト名に一致しますが、ポートは依然として 443 に制限された状態になります。任意のポートで機能する任意のレジストリーに一致させるには、domainName: *:* を使用します。

インポート用に許可されるレジストリーの設定例で設定されるルールに基づいて、以下が実行されます。

  • oc tag --insecure reg.mydomain.com/app:v1 app:v1 は、mydomain.com ルールの処理によってホワイトリストに追加されます。
  • oc import-image --from reg1.mydomain.com:80/foo foo:latest もホワイトリストに追加されます。
  • oc tag local.registry.corp/bar bar:latest は、ポートが 3 番目のルールの 5000 に一致しないために拒否されます。

拒否されたイメージのインポートにより、以下のテキストのようなエラーメッセージが生成されます。

The ImageStream "bar" is invalid:
* spec.tags[latest].from.name: Forbidden: registry "local.registry.corp" not allowed by whitelist: "local.registry.corp:5000", "*.mydomain.com:80", "registry.access.redhat.com:443"
* status.tags[latest].items[0].dockerImageReference: Forbidden: registry "local.registry.corp" not allowed by whitelist: "local.registry.corp:5000", "*.mydomain.com:80", "registry.access.redhat.com:443"

9.3. ImagePolicy 受付プラグインの設定

この機能を有効にするには、master-config.yaml でプラグインを設定します。

例9.2 アノテーション付きのサンプルファイル

admissionConfig:
  pluginConfig:
    openshift.io/ImagePolicy:
      configuration:
        kind: ImagePolicyConfig
        apiVersion: v1
        resolveImages: AttemptRewrite 1
        executionRules: 2
        - name: execution-denied
          # Reject all images that have the annotation images.openshift.io/deny-execution set to true.
          # This annotation may be set by infrastructure that wishes to flag particular images as dangerous
          onResources: 3
          - resource: pods
          - resource: builds
          reject: true 4
          matchImageAnnotations: 5
          - key: images.openshift.io/deny-execution
            value: "true"
          skipOnResolutionFailure: true 6
        - name: allow-images-from-internal-registry
          # allows images from the internal registry and tries to resolve them
          onResources:
          - resource: pods
          - resource: builds
          matchIntegratedRegistry: true
        - name: allow-images-from-dockerhub
          onResources:
          - resource: pods
          - resource: builds
          matchRegistries:
          - docker.io
        resolutionRules: 7
        - targetResource:
            resource: pods
          localNames: true
        - targetResource: 8
            group: batch
            resource: jobs
          localNames: true 9
1
イミュータブルなイメージダイジェストを使用してイメージを解決し、Pod でイメージのプル仕様を更新します。
2
着信リソースに対して評価するルールの配列です。reject==true ルールのみがある場合、デフォルトは allow all になります。accept ルールがある場合のデフォルトは deny all になります。
3
ルールを実施するリソースを示します。何も指定されていない場合、デフォルトは pods になります。
4
このルールが一致する場合、Pod は拒否されることを示します。
5
イメージオブジェクトのメタデータで一致するアノテーションの一覧。
6
イメージを解決できない場合に Pod は失敗しません。
7
Kubernetes リソースでのイメージストリームの使用を許可するルールの配列。デフォルト設定は、pods、replicationcontrollers、replicasets、statefulsets、daemonsets、deployments および jobs がイメージフィールドで同じプロジェクトイメージストリームのタグ参照を使用することを許可します。
8
このルールが適用されるグループおよびリソースを特定します。リソースが * の場合、このルールはそのグループのすべてのリソースに適用されます。
9
LocalNames は、単一のセグメント名 (例: ruby:2.4) が、リソースまたはターゲットイメージストリームで local name resolution が有効にされている場合にのみ namespace のローカルイメージストリームとして解釈されるようにします。
注記

デフォルトのレジストリープレフィックス (docker.io または registry.access.redhat.com など) を使用してプルされるインフラストラクチャーイメージを使用する場合、レジストリープレフィックスがないイメージは matchRegistries 値には一致しません。インフラストラクチャーイメージにイメージポリシーに一致するレジストリープレフィックスを持たせるには、master-config.yaml ファイルに imageConfig.format 値を設定します。

9.4. ImagePolicy 受付プラグインのテスト

  1. openshift/image-policy-check を使用して設定をテストします。

    たとえば、上記の情報を使用して、以下のようにテストします。

    oc import-image openshift/image-policy-check:latest --confirm
  2. この YAML を使用して Pod を作成します。Pod が作成されるはずです。

    apiVersion: v1
    kind: Pod
    metadata:
      generateName: test-pod
    spec:
      containers:
      - image: docker.io/openshift/image-policy-check:latest
        name: first
  3. 別のレジストリーを参照する別の Pod を作成します。Pod は拒否されます。

    apiVersion: v1
    kind: Pod
    metadata:
      generateName: test-pod
    spec:
      containers:
      - image: different-registry/openshift/image-policy-check:latest
        name: first
  4. インポートされたイメージを使用して内部レジストリーを参照する Pod を作成します。Pod は作成され、イメージ仕様を確認すると、タグの位置にダイジェストが表示されます。

    apiVersion: v1
    kind: Pod
    metadata:
      generateName: test-pod
    spec:
      containers:
      - image: <internal registry IP>:5000/<namespace>/image-policy-check:latest
        name: first
  5. インポートされたイメージを使用して内部レジストリーを参照する Pod を作成します。Pod は作成され、イメージ仕様を確認すると、タグが変更されていないことを確認できます。

    apiVersion: v1
    kind: Pod
    metadata:
      generateName: test-pod
    spec:
      containers:
      - image: <internal registry IP>:5000/<namespace>/image-policy-check:v1
        name: first
  6. oc get istag/image-policy-check:latest からダイジェストを取得し、これを oc annotate images/<digest> images.openshift.io/deny-execution=true に使用します。以下は例になります。

    $ oc annotate images/sha256:09ce3d8b5b63595ffca6636c7daefb1a615a7c0e3f8ea68e5db044a9340d6ba8 images.openshift.io/deny-execution=true
  7. この Pod を再作成します。Pod は拒否されます。

    apiVersion: v1
    kind: Pod
    metadata:
      generateName: test-pod
    spec:
      containers:
      - image: <internal registry IP>:5000/<namespace>/image-policy-check:latest
        name: first

第10章 イメージの署名

10.1. 概要

Red Hat Enterprise Linux (RHEL) システムでのコンテナーイメージの署名により、以下を実行できます。

  • コンテナーイメージの起点の検証
  • イメージが改ざんされていないことの確認
  • ホストにプルできる検証済みイメージを判別するポリシーの設定

RHEL システムでのコンテナーイメージの署名についてのアーキテクチャーの詳細は、「Container Image Signing Integration Guide」を参照してください。

OpenShift Container レジストリーは、REST API 経由で署名を保存する機能を提供します。oc CLI を使用して、検証済みのイメージを web コンソールまたは CLI に表示し、イメージの署名を検証することができます。

注記

イメージ署名の保存についての初期サポートは OpenShift Container Platform 3.3 で追加されています。イメージ署名の検証についての初期サポートは OpenShift Container Platform 3.6 で追加されています。

10.2. Atomic CLI を使用したイメージの署名

OpenShift Container Platform はイメージの署名を自動化しません。署名には、通常はワークステーションに安全に保存される開発者のプライベート GPG キーが必要になります。本書では、このワークフローについて説明します。

atomic コマンドラインインターフェース (CLI)(バージョン 1.12.5 以降) は、OpenShift Container レジストリーにプッシュできるコンテナーイメージに署名するためのコマンドを提供します。atomic CLI は、Red Hat ベースのディストリビューション (RHEL、Centos、および Fedora) で利用できます。atomic CLI は RHEL Atomic Host システムには事前にインストールされます。atomic パッケージの RHEL ホストへのインストールについての詳細は、「イメージ署名サポートの有効化」を参照してください。

重要

atomic CLI は、oc login で認証された証明書を使用します。atomic および oc コマンドの両方で同じホストの同じユーザーを使用するようにしてください。たとえば、atomic CLI を sudo として使用する場合、OpenShift Container Platform に sudo oc login を使用してログインします。

署名をイメージに割り当てるには、ユーザーに image-signer クラスターロールがなければなりません。クラスター管理者は以下を使用してこれを追加できます。

$ oc adm policy add-cluster-role-to-user system:image-signer <user_name>

イメージにはプッシュ時に署名できます。

$ atomic push [--sign-by <gpg_key_id>] --type atomic <image>

署名は、atomic トランスポートタイプの引数が指定される際に OpenShift Container Platform に保存されます。詳細は、「Signature Transports」を参照してください。

atomic CLI を使用してイメージをセットアップし、実行する方法についての詳細は、「RHEL Atomic Host Managing Containers: Signing Container Images」ドキュメントか、または atomic push --help 出力で引数の詳細を参照してください。

atomic CLI および OpenShift Container レジストリーの使用についてのワークフローの特定の例については、「Container Image Signing Integration Guide」で説明されています。

10.3. OpenShift CLI を使用したイメージ署名の検証

oc adm verify-image-signature コマンドを使用して、OpenShift Container レジストリーにインポートされたイメージの署名を検証できます。このコマンドは、イメージ署名に含まれるイメージ ID が信頼できるかどうかを検証します。ここでは、パブリック GPG キーを使用して署名自体を検証し、提供される予想 ID と指定イメージの ID (プル仕様) のマッチングが行われます。

デフォルトで、このコマンドは通常 $GNUPGHOME/pubring.gpg にあるパブリック GPG キーリングをパス ~/.gnupg で使用します。デフォルトで、このコマンドは検証結果をイメージオブジェクトに保存し直すことはありません。これを実行するには、以下に示すように --save フラグを指定する必要があります。

注記

イメージの署名を検証するには、ユーザーに image-auditor クラスターロールがなければなりません。クラスター管理者は、以下を使用してこれを追加できます。

$ oc adm policy add-cluster-role-to-user system:image-auditor <user_name>

検証済みのイメージで無効な GPG キーまたは無効な予想 ID と共に --save フラグを使用すると、保存された検証ステータスが削除され、イメージは未検証の状態になります。

イメージ署名を検証するには、以下の形式を使用します。

$ oc adm verify-image-signature <image> --expected-identity=<pull_spec> [--save] [options]

<pull_spec> はイメージストリームを記述して確認でき、<image> はイメージストリームタグを記述して確認することができます。以下のコマンド出力例を参照してください。

イメージ署名の検証例

$ oc describe is nodejs -n openshift
Name:             nodejs
Namespace:        openshift
Created:          2 weeks ago
Labels:           <none>
Annotations:      openshift.io/display-name=Node.js
                  openshift.io/image.dockerRepositoryCheck=2017-07-05T18:24:01Z
Docker Pull Spec: 172.30.1.1:5000/openshift/nodejs
...

$ oc describe istag nodejs:latest -n openshift
Image Name:	sha256:2bba968aedb7dd2aafe5fa8c7453f5ac36a0b9639f1bf5b03f95de325238b288
...

$ oc adm verify-image-signature \
    sha256:2bba968aedb7dd2aafe5fa8c7453f5ac36a0b9639f1bf5b03f95de325238b288 \
    --expected-identity 172.30.1.1:5000/openshift/nodejs:latest \
    --public-key /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release \
    --save

10.4. レジストリー API の使用によるイメージ署名へのアクセス

OpenShift Container レジストリーは、イメージ署名の書き込みおよび読み取りを実行できる extensions エンドポイントを提供します。イメージ署名は、Docker レジストリー API 経由で OpenShift Container Platform の KVS (key-value store) に保存されます。

注記

このエンドポイントは実験段階にあり、アップストリームの Docker レジストリープロジェクトではサポートされていません。Docker レジストリー API の一般的な情報については、アップストリーム API のドキュメントを参照してください。

10.4.1. API 経由でのイメージ署名の書き込み

新規署名をイメージに追加するには、HTTP PUT メソッドを使用して JSON ペイロードを extensions エンドポイントに送信できます。

PUT /extensions/v2/<namespace>/<name>/signatures/<digest>
$ curl -X PUT --data @signature.json http://<user>:<token>@<registry_endpoint>:5000/extensions/v2/<namespace>/<name>/signatures/sha256:<digest>

署名コンテンツを含む JSON ペイロードの構造は以下のようになります。

{
  "version": 2,
  "type":    "atomic",
  "name":    "sha256:4028782c08eae4a8c9a28bf661c0a8d1c2fc8e19dbaae2b018b21011197e1484@cddeb7006d914716e2728000746a0b23",
  "content": "<cryptographic_signature>"
}

name フィールドには、<digest>@<name> 形式の一意の値であるイメージ署名の名前が含まれます。<digest> はイメージ名を表し、<name> は署名の名前になります。署名の名前には 32 文字の長さが必要です。<cryptographic_signature> は、コンテナー/イメージライブラリーで説明されている仕様に従っている必要があります。

10.4.2. API 経由でのイメージ署名の読み取り

署名済みのイメージが OpenShift Container レジストリーにすでにプッシュされていることを仮定した場合、以下のコマンドを使って署名を読み取ることができます。

GET /extensions/v2/<namespace>/<name>/signatures/<digest>
$ curl http://<user>:<token>@<registry_endpoint>:5000/extensions/v2/<namespace>/<name>/signatures/sha256:<digest>

<namespace> は OpenShift Container Platform プロジェクト名またはレジストリーのリポジトリー名を表し、<name> はイメージリポジトリーの名前を指します。digest はイメージの SHA-256 チェックサムを表します。

指定されたイメージに署名データが含まれる場合、上記のコマンド出力により、以下の JSON 応答が生成されます。

{
  "signatures": [
  {
    "version": 2,
    "type":    "atomic",
    "name":    "sha256:4028782c08eae4a8c9a28bf661c0a8d1c2fc8e19dbaae2b018b21011197e1484@cddeb7006d914716e2728000746a0b23",
    "content": "<cryptographic_signature>"
  }
  ]
}

name フィールドには、<digest>@<name> 形式の一意の値であるイメージ署名の名前が含まれます。<digest> はイメージ名を表し、<name> は署名の名前になります。署名の名前には 32 文字の長さが必要です。<cryptographic_signature> は、コンテナー/イメージライブラリーで説明されている仕様に従っている必要があります。

10.4.3. 署名ストアからのイメージ署名の自動インポート

OpenShift Container Platform は、署名ストアがすべての OpenShift Container Platform マスターノードに設定されている場合に、レジストリー設定ディレクトリーを使用してイメージ署名を自動インポートします。

レジストリー設定ディレクトリーには、各種レジストリー (リモートコンテナーイメージを保存するサーバー) およびそれらに保存されるコンテンツの設定が含まれます。この単一ディクトリーを使用すると、設定がコンテナー/イメージのすべてのユーザー間で共有されるように、各コマンドのコマンドラインオプションでその設定を指定する必要がありません。

デフォルトのレジストリー設定ディレクトリーは、/etc/containers/registries.d/default.yaml ファイルにあります。

すべての Red Hat イメージについてイメージ署名の自動インポートを実行する設定例:

docker:
  registry.access.redhat.com:
    sigstore: https://access.redhat.com/webassets/docker/content/sigstore 1
1
署名ストアの URL を定義します。この URL は、既存署名の読み取りに使用されます。
注記

OpenShift Container Platform によって自動的にインポートされる署名は、デフォルトで 未検証 の状態になり、イメージ管理者による検証が必要になります。

レジストリー設定ディレクトリーについての詳細は、「Registries Configuration Directory」を参照してください。

第11章 スコープ付きトークン

11.1. 概要

ユーザーは、他のエンティティーに対し、自らと同様に機能する権限を制限された方法で付与する必要があるかもしれません。たとえば、プロジェクト管理者は Pod の作成権限を委任する必要があるかもしれません。これを実行する方法の 1 つとして、スコープ付きトークンを作成することができます。

スコープ付きトークンは、指定されるユーザーを識別するが、そのスコープによって特定のアクションに制限するトークンです。現時点で、cluster-admin のみがスコープ付きトークンを作成できます。

11.2. 評価

スコープは、トークンの一連のスコープを PolicyRules のセットに変換して評価されます。次に、要求がそれらのルールに対してマッチングされます。要求属性は、追加の許可検査のために「標準」承認者に渡せるよう、スコープルールのいずれかに一致している必要があります。

11.3. ユーザースコープ

ユーザースコープでは、指定されたユーザーについての情報を取得することにフォーカスが置かれます。それらはインテントベースであるため、ルールは自動的に作成されます。

  • user:full: ユーザーのすべてのパーミッションによる API の完全な読み取り/書き込みアクセスを許可します。
  • user:info: ユーザー (名前、グループなど) についての情報の読み取り専用アクセスを許可します。
  • user:check-access: self-localsubjectaccessreviews および self-subjectaccessreviews へのアクセスを許可します。それらは、要求オブジェクトの空のユーザーおよびグループを渡す変数です。
  • user:list-projects: ユーザーがアクセスできるプロジェクトを一覧表示するための読み取り専用アクセスを許可します。

11.4. ロールスコープ

ロールスコープにより、 namespace でフィルターされる指定ロールと同じレベルのアクセスを持たせることができます。

  • role:<cluster-role name>:<namespace or * for all>: 指定された namespace のみにあるクラスターロール (cluster-role) で指定されるルールにスコープを制限します。

    注記

    注意: これは、アクセスのエスカレートを防ぎます。ロールはシークレット、ロールバインディング、およびロールなどのリソースへのアクセスを許可しますが、このスコープはそれらのリソースへのアクセスを制限するのに役立ちます。これにより、予期しないエスカレーションを防ぐことができます。edit (編集) などのロールはエスカレートされるロールと見なされないことが多いですが、シークレットのアクセスを持つロールの場合はロールのエスカレーションが生じます。

  • role:<cluster-role name>:<namespace or * for all>:!: bang (!) を含めることでこのスコープでアクセスのエスカレートを許可されますが、それ以外には上記の例と同様になります。

第12章 イメージのモニタリング

12.1. 概要

CLI を使用し、インスタンスでイメージをモニタリングできます。

12.2. イメージ統計の表示

OpenShift Container Platform は、管理対象のすべてのイメージの使用状況についてのいくつかの統計を表示できます。つまり、すべてのイメージは直接またはビルドによって内部レジストリーにプッシュされます。

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

$ oc adm top images
NAME                 IMAGESTREAMTAG            PARENTS                   USAGE                         METADATA    STORAGE
sha256:80c985739a78b openshift/python (3.5)                                                            yes         303.12MiB
sha256:64461b5111fc7 openshift/ruby (2.2)                                                              yes         234.33MiB
sha256:0e19a0290ddc1 test/ruby-ex (latest)     sha256:64461b5111fc71ec   Deployment: ruby-ex-1/test    yes         150.65MiB
sha256:a968c61adad58 test/django-ex (latest)   sha256:80c985739a78b760   Deployment: django-ex-1/test  yes         186.07MiB

コマンドにより、以下の情報が表示されます。

  • イメージ ID
  • プロジェクト、名前、および付随する ImageStreamTag のタグ
  • イメージ ID を使用するイメージの潜在的な親
  • イメージが使用されている場所についての情報
  • イメージに適切な Docker メタデータ情報が含まれるかどうかを示すフラグ
  • イメージのサイズ

12.3. ImageStreams 統計の表示

OpenShift Container Platform は、すべての ImageStreams の使用状況についてのいくつかの統計を表示できます。

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

$ oc adm top imagestreams
NAME                STORAGE     IMAGES  LAYERS
openshift/python    1.21GiB     4       36
openshift/ruby      717.76MiB   3       27
test/ruby-ex        150.65MiB   1       10
test/django-ex      186.07MiB   1       10

コマンドにより、以下の情報が表示されます。

  • プロジェクトおよび ImageStream の名前
  • 内部 Red Hat Container レジストリーに保存される ImageStream 全体のサイズ
  • この特定の ImageStream が参照しているイメージの数
  • ImageStream を構成する層の数

12.4. イメージのプルーニング

上記のコマンドで返される情報は、イメージのプルーニングを実行する際に役立ちます。

第13章 SCC (Security Context Constraints) の管理

13.1. 概要

SCC (Security Context Constraints) により、管理者は Pod のパーミッションを制御できます。この API タイプについての詳細は、SCC (security context constraints) アーキテクチャーのドキュメントを参照してください。SCC は、CLI を使用し、インスタンスで通常の API オブジェクトとして管理できます。

注記

SCC を管理するには、cluster-admin 権限が必要です。

重要

デフォルトの SCC を変更しないでください。デフォルトの SCC をカスタマイズすると、アップグレード時に問題が生じる可能性があります。代わりに 新規 SCC を作成してください。

13.2. SCC (Security Context Constraints) の一覧表示

SCC の現在の一覧を取得するには、以下を実行します。

$ oc get scc

NAME               PRIV      CAPS      SELINUX     RUNASUSER          FSGROUP     SUPGROUP    PRIORITY   READONLYROOTFS   VOLUMES
anyuid             false     []        MustRunAs   RunAsAny           RunAsAny    RunAsAny    10         false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
hostaccess         false     []        MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <none>     false            [configMap downwardAPI emptyDir hostPath persistentVolumeClaim secret]
hostmount-anyuid   false     []        MustRunAs   RunAsAny           RunAsAny    RunAsAny    <none>     false            [configMap downwardAPI emptyDir hostPath nfs persistentVolumeClaim secret]
hostnetwork        false     []        MustRunAs   MustRunAsRange     MustRunAs   MustRunAs   <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
nonroot            false     []        MustRunAs   MustRunAsNonRoot   RunAsAny    RunAsAny    <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
privileged         true      [*]       RunAsAny    RunAsAny           RunAsAny    RunAsAny    <none>     false            [*]
restricted         false     []        MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]

13.3. SCC (Security Context Constraints) オブジェクトの検査

特定の SCC を検査するには、oc getoc describeoc export、または oc edit を使用します。たとえば、restricted SCC を検査するには、以下を実行します。

$ oc describe scc restricted
Name:					restricted
Priority:				<none>
Access:
  Users:				<none>
  Groups:				system:authenticated
Settings:
  Allow Privileged:			false
  Default Add Capabilities:		<none>
  Required Drop Capabilities:		KILL,MKNOD,SYS_CHROOT,SETUID,SETGID
  Allowed Capabilities:			<none>
  Allowed Seccomp Profiles:		<none>
  Allowed Volume Types:			configMap,downwardAPI,emptyDir,persistentVolumeClaim,projected,secret
  Allow Host Network:			false
  Allow Host Ports:			false
  Allow Host PID:			false
  Allow Host IPC:			false
  Read Only Root Filesystem:		false
  Run As User Strategy: MustRunAsRange
    UID:				<none>
    UID Range Min:			<none>
    UID Range Max:			<none>
  SELinux Context Strategy: MustRunAs
    User:				<none>
    Role:				<none>
    Type:				<none>
    Level:				<none>
  FSGroup Strategy: MustRunAs
    Ranges:				<none>
  Supplemental Groups Strategy: RunAsAny
    Ranges:				<none>
注記

アップグレード時にカスタマイズされた SCC を保持するには、優先順位、ユーザー、グループ、ラベル、およびアノテーション以外にはデフォルトの SCC の設定を編集しないでください。

13.4. 新規 SCC (Security Context Constraints) の作成

新規 SCC を作成するには、以下を実行します。

  1. JSON または YAML ファイルで SCC を定義します。

    SCC (Security Context Constraints) オブジェクトの定義

    kind: SecurityContextConstraints
    apiVersion: v1
    metadata:
      name: scc-admin
    allowPrivilegedContainer: true
    runAsUser:
      type: RunAsAny
    seLinuxContext:
      type: RunAsAny
    fsGroup:
      type: RunAsAny
    supplementalGroups:
      type: RunAsAny
    users:
    - my-admin-user
    groups:
    - my-admin-group

    オプションとして、requiredDropCapabilities フィールドに必要な値を設定してドロップ機能を SCC に追加することができます。指定された機能はコンテナーからドロップされることになります。たとえば、SCC を KILLMKNOD、および SYS_CHROOT の必要なドロップ機能を使って作成するには、以下を SCC オブジェクトに追加します。

    requiredDropCapabilities:
    - KILL
    - MKNOD
    - SYS_CHROOT

    使用できる値の一覧は、Docker ドキュメントで確認できます。

ヒント

機能は Docker に渡されるため、特殊な ALL 値を使用してすべての機能をドロップすることができます。

  1. 次に、作成するファイルを渡して oc create を実行します。

    $ oc create -f scc_admin.yaml
    securitycontextconstraints "scc-admin" created
  2. SCC が作成されていることを確認します。

    $ oc get scc scc-admin
    NAME        PRIV      CAPS      SELINUX    RUNASUSER   FSGROUP    SUPGROUP   PRIORITY   READONLYROOTFS   VOLUMES
    scc-admin   true      []        RunAsAny   RunAsAny    RunAsAny   RunAsAny   <none>     false            [awsElasticBlockStore azureDisk azureFile cephFS cinder configMap downwardAPI emptyDir fc flexVolume flocker gcePersistentDisk gitRepo glusterfs iscsi nfs persistentVolumeClaim photonPersistentDisk quobyte rbd secret vsphere]

13.5. SCC (Security Context Constraints) の削除

SCC を削除するには、以下を実行します。

$ oc delete scc <scc_name>
注記

デフォルトの SCC を削除する場合、これは再起動時に再生成されます。

13.6. SCC (Security Context Constraints) の更新

既存 SCC を更新するには、以下を実行します。

$ oc edit scc <scc_name>
注記

アップグレード時にカスタマイズされた SCC を保持するには、優先順位、ユーザー、グループ以外にデフォルトの SCC の設定を編集しないでください。

13.6.1. SCC (Security Context Constraints) 設定のサンプル

明示的な runAsUser 設定がない場合

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext: 1
  containers:
  - name: sec-ctx-demo
    image: gcr.io/google-samples/node-hello:1.0

1
コンテナーまたは Pod が実行時に使用するユーザー ID を要求しない場合、有効な UID はこの Pod を作成する SCC よって異なります。制限付き SCC はデフォルトですべての認証ユーザーに付与されるため、ほとんどの場合はすべてのユーザーおよびサービスアカウントで利用でき、使用されます。この制限付き SCC は、securityContext.runAsUser フィールドの使用できる値を制限し、これをデフォルトに設定するために MustRunAsRange ストラテジーを使用します。受付プラグインではこの範囲を指定しないため、現行プロジェクトで openshift.io/sa.scc.uid-range アノテーションを検索して範囲フィールドにデータを設定します。最終的にコンテナーの runAsUser は予測が困難な範囲の最初の値と等しい値になります。予測が困難であるのはすべてのプロジェクトにはそれぞれ異なる範囲が設定されるためです。詳細は、「Understanding Pre-allocated Values and Security Context Constraints (事前に割り当てられた値および SCC (Security Context Constraint) について)」を参照してください。

明示的な runAsUser 設定がない場合

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000 1
  containers:
    - name: sec-ctx-demo
      image: gcr.io/google-samples/node-hello:1.0

1
特定のユーザー ID を要求するコンテナーまたは Pod が OpenShift Container Platform によって受け入れられるのは、サービスアカウントまたはユーザーにそのユーザー ID を許可する SCC へのアクセスが付与されている場合のみです。SCC は、任意の ID や特定の範囲内にある ID、または要求に固有のユーザー ID を許可します。

これは SELinux、fsGroup、および Supplemental Groups で機能します。詳細は、「Volume Security (ボリュームセキュリティー)」を参照してください。

13.7. デフォルト SCC (Security Context Constraints) の更新

デフォルト SCC は、それらが見つからない場合にはマスターの起動時に作成されます。SCC をデフォルトにリセットするか、またはアップグレード後に既存の SCC を新規のデフォルト定義に更新するには、以下を実行します。

  1. リセットする SCC を削除し、マスターを再起動してその再作成を実行します。
  2. oc adm policy reconcile-sccs コマンドを使用します。

oc adm policy reconcile-sccs コマンドは、すべての SCC ポリシーをデフォルト値に設定しますが、すでに設定した可能性のある追加ユーザー、グループ、ラベル、アノテーションおよび優先順位を保持します。変更される SCC を表示するには、オプションなしでコマンドを実行するか、または -o <format> オプションで優先する出力を指定してコマンドを実行します。

確認後は、既存 SCC のバックアップを取ってから --confirm オプションを使用してデータを永続化します。

注記

優先順位や許可をリセットする場合は、--additive-only=false オプションを使用します。

注記

SCC に優先順位、ユーザー、グループ、ラベル、またはアノテーション以外のカスタマイズ設定がある場合、これらの設定は調整時に失われます。

13.8. 使用方法

以下では、SCC を使用する一般的なシナリオおよび手順について説明します。

13.8.1. 特権付き SCC のアクセス付与

管理者が管理者グループ外のユーザーまたはグループに対して 特権付き Pod を追加作成するためのアクセスを付与することが必要になることがあります。これを実行するには、以下を行います。

  1. SCC へのアクセスを付与するユーザーまたはグループを決定します。

    警告

    ユーザーへのアクセス付与は、ユーザーが Pod を直接作成する場合にのみ可能です。ほとんどの場合、システム自体がユーザーの代わりに作成する Pod については、関連するコントローラーの作動に使用される サービスアカウントにアクセスを付与する必要があります。ユーザーの代わりに Pod を作成するリソースの例として、Deployments、StatefulSets、DaemonSets などが含まれます。

  2. 以下を実行します。

    $ oc adm policy add-scc-to-user <scc_name> <user_name>
    $ oc adm policy add-scc-to-group <scc_name> <group_name>

    たとえば、e2e-user特権付き SCC へのアクセスを許可するには、以下を実行します。

    $ oc adm policy add-scc-to-user privileged e2e-user
  3. 特権モードを要求するようにコンテナーの SecurityContext を変更します。

13.8.2. 特権付き SCC のサービスアカウントアクセスの付与

最初に、サービスアカウントを作成します。たとえば、サービスアカウント mysvcacct をプロジェクト myproject で作成するには、以下を実行します。

$ oc create serviceaccount mysvcacct -n myproject

次に、サービスアカウントを特権付き SCC に追加します。

$ oc adm policy add-scc-to-user privileged system:serviceaccount:myproject:mysvcacct

その後は、リソースがサービスアカウントの代わりに作成されていることを確認します。これを実行するには、spec.serviceAccountName フィールドをサービスアカウント名に設定します。サービスアカウント名を空のままにすると、デフォルトのサービスアカウントが使用されます。

次に、少なくとも 1 つの Pod のコンテナーがセキュリティーコンテキストで特権モードを要求していることを確認します。

13.8.3. Dokerfile の USER によるイメージ実行の有効化

特権付き SCC へのアクセスをすべての人に与えることなく、イメージが事前割り当て UID で強制的に実行されないようにクラスターのセキュリティーを緩和するには、以下を実行します。

  1. すべての認証されたユーザーに anyuid SCC へのアクセスを付与します。

    $ oc adm policy add-scc-to-group anyuid system:authenticated
警告

これにより、USERDockerfile に指定されていない場合は、イメージをルート ID で実行することができます。

13.8.4. ルートを要求するコンテナーイメージの有効化

一部のコンテナーイメージ (例: postgres および redis) には root アクセスが必要であり、ボリュームの保有方法についてのいくつかの予測が設定されています。これらのイメージについては、サービスアカウントを anyuid SCC に追加します。

$ oc adm policy add-scc-to-user anyuid system:serviceaccount:myproject:mysvcacct

13.8.5. レジストリーでの --mount-host の使用

PersistentVolume および PersistentVolumeClaim オブジェクトを使用する永続ストレージオブジェクトをレジストリーのデプロイメントに使用することが推奨されます。テストを実行中で、oc adm registry コマンドを --mount-host オプションと共に使用する必要がある場合には、まずレジストリーの新規サービスアカウントを作成し、これを特権付き SCC に追加する必要があります。詳細の説明については、『Administrator Guide』を参照してください。

13.8.6. 追加機能の提供

場合によっては、Docker が追加設定なしの機能として提供していない機能がイメージで必要になることがあります。この場合、Pod 仕様で追加機能を要求することができ、これは SCC に対して検証されます。

重要

これによりイメージを昇格された機能を使って実行できますが、これは必要な場合にのみ実行する必要があります。追加機能を有効にするためにデフォルトの restricted SCC を編集することはできません。

非 root ユーザーによって使用される場合、setcap コマンドを使用して、追加機能を要求するファイルに該当する機能が付与されていることを確認する必要もあります。たとえば、イメージの Dockerfile では、以下のようになります。

setcap cap_net_raw,cap_net_admin+p /usr/bin/ping

さらに機能が Docker のデフォルトとして提供されている場合には、これを要求するために Pod 仕様を変更する必要はありません。たとえば、NET_RAW がデフォルトで指定されており、機能がすでに ping で設定されている場合、ping を実行するのに特別な手順は必要ありません。

追加機能を提供するには、以下を実行します。

  1. 新規 SCC を作成します。
  2. allowedCapabilities フィールドを使用して許可された機能を追加します。
  3. Pod の作成時に、securityContext.capabilities.add フィールドで機能を要求します。

13.8.7. クラスターのデフォルト動作の変更

UID の事前割り当てを実行せず、任意ユーザーによるコンテナーの実行を許可し、特権付きコンテナーを禁止するようクラスターを変更するには、以下を実行します。

注記

アップグレード時にカスタマイズされた SCC を保持するには、優先順位、ユーザー、グループ、ラベル、およびアノテーション以外にはデフォルトの SCC の設定を編集しないでください。

  1. restricted SCC を編集します。

     $ oc edit scc restricted
  2. runAsUser.TypeRunAsAny に変更します。
  3. allowPrivilegedContainer が false に設定されていることを確認します。
  4. 変更を保存します。

UID を事前に割り当てないようにし、コンテナーが root で実行されないようにクラスターを変更するには、以下を実行します。

  1. restricted SCC を編集します。

     $ oc edit scc restricted
  2. runAsUser.TypeMustRunAsNonRoot に変更します。
  3. 変更を保存します。

13.8.8. hostPath ボリュームプラグインの使用

すべての人に 特権付き SCC へのアクセスを付与することなく、Pod で hostPath ボリュームプラグインを使用できるようにクラスターのセキュリティーを緩和するには、以下を実行します。

  1. restricted SCC を編集します。

    $ oc edit scc restricted
  2. allowHostDirVolumePlugin: true を追加します。
  3. 変更を保存します。

13.8.9. 受付を使用した特定 SCC の初回使用

SCC の Priority フィールドを設定し、受付コントローラーで SCC の並び替え順序を制御することができます。並び替えについての詳細は、「SCC Prioritization」セクションを参照してください。

13.8.10. SCC のユーザー、グループまたはプロジェクトへの追加

SCC をユーザーまたはグループに追加する前に、まず scc-review オプションを使用してユーザーまたはグループが Pod を作成できるかどうかをチェックできます。詳細は、「Authorization」のトピックを参照してください。

SCC はプロジェクトに直接付与されません。代わりに、サービスアカウントを SCC に追加し、Pod にサービスアカウント名を指定するか、または指定されない場合は default サービスアカウントを使用して実行します。

SCC をユーザーに追加するには、以下を実行します。

$ oc adm policy add-scc-to-user <scc_name> <user_name>

SCC をサービスアカウントに追加するには、以下を実行します。

$ oc adm policy add-scc-to-user <scc_name> \
    system:serviceaccount:<serviceaccount_namespace>:<serviceaccount_name>

現在の場所がサービスアカウントが属するプロジェクトの場合、-z フラグを使用し、<serviceaccount_name> のみを指定することができます。

$ oc adm policy add-scc-to-user <scc_name> -z <serviceaccount_name>
重要

上記の -z フラグについては、誤字を防ぎ、アクセスが指定されたサービスアカウントのみに付与されるため、その使用をを強く推奨します。プロジェクトにいない場合は、-n オプションを使用して、それが適用されるプロジェクトの namespace を指定します。

SCC をグループに追加するには、以下を実行します。

$ oc adm policy add-scc-to-group <scc_name> <group_name>

SCC を namespace のすべてのサービスアカウントに追加するには、以下を実行します。

$ oc adm policy add-scc-to-group <scc_name> \
    system:serviceaccounts:<serviceaccount_namespace>

第14章 スケジューリング

14.1. 概要

14.1.1. 概要

Pod のスケジューリングは、クラスター内のノードへの新規 Pod の配置を決定する内部プロセスです。

スケジューラーコードは、新規 Pod の作成時にそれらを確認し、それらをホストするのに最も適したノードを識別します。次に、マスター API を使用して Pod のバインディング (Pod とノードのバインディング) を作成します。

14.1.2. デフォルトスケジューリング

OpenShift Container Platform には、ほとんどのユーザーのニーズに対応するデフォルトスケジューラーが同梱されます。デフォルトスケジューラーは、Pod に最適なノードを判別するための固有のツールおよびカスタマイズ可能なツールの両方を使用します。

デフォルトスケジューラーが Pod の配置と利用できるカスタマイズ可能なパラメーターを判別する方法についての詳細は、「デフォルトスケジューリング」を参照してください。

14.1.3. 詳細スケジューリング

新規 Pod の配置場所に対する制御を強化する必要がある場合、OpenShift Container Platform の詳細スケジューリング機能を使用すると、Pod が特定ノード上か、または特定の Pod と共に実行されることを要求する (または実行されることが優先される) よう Pod を設定することができます。また詳細設定により、Pod をノードに配置することや他の Pod と共に実行することを防ぐこともできます。

詳細スケジューリングについての詳細は、「詳細スケジューリング」を参照してください。

14.1.4. カスタムスケジューリング

OpenShift Container Platform では、Pod 仕様を編集してユーザー独自のスケジューラーまたはサードパーティーのスケジューラーを使用することもできます。

詳細は、「カスタムスケジューラー」を参照してください。

14.2. デフォルトスケジューリング

14.2.1. 概要

OpenShift Container Platform のデフォルトの Pod スケジューラーは、クラスター内のノードにおける新規 Pod の配置場所を判別します。スケジューラーは Pod からのデータを読み取り、設定されるポリシーに基づいて適切なノードを見つけようとします。これは完全に独立した機能であり、スタンドアロン/プラグ可能ソリューションです。Pod を変更することはなく、Pod を特定ノードに関連付ける Pod のバインディングのみを作成します。

14.2.2. 汎用スケジューラー

既存の汎用スケジューラーはプラットフォームで提供されるデフォルトのスケジューラー エンジン であり、Pod をホストするノードを 3 つの手順で選択します。

14.2.3. ノードのフィルター

利用可能なノードは、指定される制約や要件に基づいてフィルターされます。フィルターは、各ノードで 述語 というフィルター関数の一覧を使用して実行されます。

14.2.3.1. フィルターされたノード一覧の優先順位付け

優先順位付けは、各ノードに一連の優先度関数を実行することによって行われます。この関数は 0 -10 までのスコアをノードに割り当て、0 は不適切であることを示し、10 は Pod のホストに適していることを示します。スケジューラー設定は、それぞれの優先度関数について単純な 重み (正の数値) を取ることができます。各優先度関数で指定されるノードのスコアは重み (ほとんどの優先度のデフォルトの重みは 1) で乗算され、すべての優先度で指定されるそれぞれのノードのスコアを追加して組み合わされます。この重み属性は、一部の優先度により重きを置くようにするなどのために管理者によって使用されます。

14.2.3.2. 最適ノードの選択

ノードの並び替えはそれらのスコアに基づいて行われ、最高のスコアを持つノードが Post をホストするように選択されます。複数のノードに同じ高スコアが付けられている場合、それらのいずれかがランダムに選択されます。

14.2.4. スケジューラーポリシー

述語優先度の選択によって、スケジューラーのポリシーが定義されます。

スケジューラー設定ファイルは、スケジューラーが反映する述語と優先度を指定する JSON ファイルです。

スケジューラーポリシーファイルがない場合、デフォルトの設定ファイル /etc/origin/master/scheduler.json が適用されます。

重要

スケジューラー設定ファイルで定義される述語および優先度は、デフォルトのスケジューラーポリシーを完全に上書きします。デフォルトの述語および優先度のいずれかが必要な場合、スケジューラー設定ファイルにその関数を明示的に指定する必要があります。

デフォルトのスケジューラー設定ファイル

{
    "apiVersion": "v1",
    "kind": "Policy",
    "predicates": [
        {
            "name": "NoVolumeZoneConflict"
        },
        {
            "name": "MaxEBSVolumeCount"
        },
        {
            "name": "MaxGCEPDVolumeCount"
        },
        {
            "name": "MaxAzureDiskVolumeCount"
        },
        {
            "name": "MatchInterPodAffinity"
        },
        {
            "name": "NoDiskConflict"
        },
        {
            "name": "GeneralPredicates"
        },
        {
            "name": "PodToleratesNodeTaints"
        },
        {
            "name": "CheckNodeMemoryPressure"
        },
        {
            "name": "CheckNodeDiskPressure"
        },
        {
            "argument": {
                "serviceAffinity": {
                    "labels": [
                        "region"
                    ]
                }
            },
            "name": "Region"

         }
    ],
    "priorities": [
        {
            "name": "SelectorSpreadPriority",
            "weight": 1
        },
        {
            "name": "InterPodAffinityPriority",
            "weight": 1
        },
        {
            "name": "LeastRequestedPriority",
            "weight": 1
        },
        {
            "name": "BalancedResourceAllocation",
            "weight": 1
        },
        {
            "name": "NodePreferAvoidPodsPriority",
            "weight": 10000
        },
        {
            "name": "NodeAffinityPriority",
            "weight": 1
        },
        {
            "name": "TaintTolerationPriority",
            "weight": 1
        },
        {
            "argument": {
                "serviceAntiAffinity": {
                    "label": "zone"
                }
            },
            "name": "Zone",
            "weight": 2
        }
    ]
}

14.2.4.1. スケジューラーポリシーの変更

デフォルトで、スケジューラーポリシーはマスター設定ファイルkubernetesMasterConfig.schedulerConfigFile フィールドで上書きされない限り、/etc/origin/master/scheduler.json というマスターのファイルに定義されます。

変更されたスケジューラー設定ファイルのサンプル

kind: "Policy"
version: "v1"
"predicates": [
        {
            "name": "PodFitsResources"
        },
        {
            "name": "NoDiskConflict"
        },
        {
            "name": "MatchNodeSelector"
        },
        {
            "name": "HostName"
        },
        {
            "argument": {
                "serviceAffinity": {
                    "labels": [
                        "region"
                    ]
                }
            },
            "name": "Region"
        }
    ],
    "priorities": [
        {
            "name": "LeastRequestedPriority",
            "weight": 1
        },
        {
            "name": "BalancedResourceAllocation",
            "weight": 1
        },
        {
            "name": "ServiceSpreadingPriority",
            "weight": 1
        },
        {
            "argument": {
                "serviceAntiAffinity": {
                    "label": "zone"
                }
            },
            "name": "Zone",
            "weight": 2
        }
    ]

スケジューラーポリシーを変更するには、以下を実行します。

  1. 必要なデフォルトの述語および優先度を設定するためにスケジューラー設定ファイルを編集します。カスタム設定を作成したり、サンプルのポリシー設定のいずれかを使用または変更したりすることができます。
  2. 必要な設定可能な述語設定可能な優先度を追加します。
  3. 変更を有効にするために OpenShift Container Platform を再起動します。

    # systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers

14.2.5. 利用可能な述語

述語は、不適切なノードをフィルターに掛けるルールです。

OpenShift Container Platform には、デフォルトでいくつかの述語が提供されています。これらの述語の一部は、特定のパラメーターを指定してカスタマイズできます。複数の述語を組み合わせてノードの追加フィルターを指定できます。

14.2.5.1. 静的な述語

これらの述語はユーザーから設定パラメーターまたは入力を取りません。これらはそれぞれの正確な名前を使用してスケジューラー設定に指定されます。

14.2.5.1.1. デフォルトの述語

デフォルトのスケジューラーポリシーには以下の述語が含まれます。

NoVolumeZoneConflict は Pod が要求するボリュームがゾーンで利用可能であることを確認します。

{"name" : "NoVolumeZoneConflict"}

MaxEBSVolumeCount は、AWS インスタンスに割り当てることのできるボリュームの最大数を確認します。

{"name" : "MaxEBSVolumeCount"}

MaxGCEPDVolumeCount は、Google Compute Engine (GCE) 永続ディスク (PD) の最大数を確認します。

{"name" : "MaxGCEPDVolumeCount"}

MatchInterPodAffinity は、Pod のアフィニティー/非アフィニティールールが Pod を許可するかどうかを確認します。

{"name" : "MatchInterPodAffinity"}

NoDiskConflict は Pod が要求するボリュームが利用可能であるかどうかを確認します。

{"name" : "NoDiskConflict"}

PodToleratesNodeTaints は Pod がノードのテイントを許容できるかどうかを確認します。

{"name" : "PodToleratesNodeTaints"}

CheckNodeMemoryPressure は、Pod がメモリー不足 (memory pressure) 状況にあるノードでスケジュールできるかどうかを確認します。

{"name" : "CheckNodeMemoryPressure"}
14.2.5.1.2. 他の静的な述語

OpenShift Container Platform は以下の述語もサポートしています。

CheckNodeDiskPressure は、Pod がディスク不足 (disk pressure) の状況にあるノードでスケジュールできるかどうかを確認します。

{"name" : "CheckNodeDiskPressure"}

CheckVolumeBinding は、バインドされている PVC とバインドされていない PVC の両方の場合に Pod が要求するボリュームに基づいて適しているかどうかを評価します* バインドされている PVC については、述語は対応する PV のノードアフィニティーが指定ノードによって満たされていることを確認します。* バインドされていない PVC については、述語は PVC 要件を満たす PV を検索し、PV のノードアフィニティーが指定ノードによって満たされていることを確認します。

述語は、すべてのバインドされる PVC にノードと互換性のある PV がある場合や、すべてのバインドされていない PVC が利用可能なノードと互換性のある PV に一致する場合に true を返します。

{"name" : "CheckVolumeBinding"}

CheckVolumeBinding 述語は、デフォルト以外のスケジューラーで有効にする必要があります。

CheckNodeCondition は Pod をノードでスケジュールできるかどうかを確認し、out of disk (ディスク不足)network unavailable (ネットワークが使用不可)、または not ready (準備できていない) 状態を報告します。

{"name" : "CheckNodeCondition"}

PodToleratesNodeNoExecuteTaints は、Pod がノードの NoExecute テイントを容認できるかどうかを確認します。

{"name" : "PodToleratesNodeNoExecuteTaints"}

CheckNodeLabelPresence は、すべての指定されたラベルがノードに存在するかどうかを確認します (その値が何であるかを問わない)。

{"name" : "CheckNodeLabelPresence"}

checkServiceAffinity は、ServiceAffinity ラベルがノードでスケジュールされる Pod について同種のものであることを確認します。

{"name" : "checkServiceAffinity"}

MaxAzureDiskVolumeCount は Azure ディスクボリュームの最大数を確認します。

{"name" : "MaxAzureDiskVolumeCount"}

14.2.5.2. 汎用的な述語

以下の汎用的な述語は、非クリティカル述語とクリティカル述語が渡されるかどうかを確認します。非クリティカル述語は、非 Critical Pod のみが渡す必要のある述語であり、クリティカル述語はすべての Pod が渡す必要のある述語です。

デフォルトのスケジューラーポリシーにはこの汎用的な述語が含まれます。

汎用的な非クリティカル述語

PodFitsResources は、リソースの可用性 (CPU、メモリー、GPU など) に基づいて適切な候補を判別します。ノードはそれらのリソース容量を宣言し、Pod は要求するリソースを指定できます。使用されるリソースではなく、要求されるリソースに基づいて適切な候補が判別されます。

{"name" : "PodFitsResources"}
汎用的なクリティカル述語

PodFitsHostPorts は、ノードに要求される Pod ポートの空きポートがある (ポートの競合がない) かどうかを判別します。

{"name" : "PodFitsHostPorts"}

HostName は、ホストパラメーターの有無と文字列のホスト名との一致に基づいて適切なノードを判別します。

{"name" : "HostName"}

MatchNodeSelector は、Pod で定義されるノードセレクター (nodeSelector)のクエリーに基づいて適したノードを判別します。

{"name" : "MatchNodeSelector"}

14.2.5.3. 設定可能な述語

これらの述語はスケジューラー設定 /etc/origin/master/scheduler.json (デフォルト) に設定し、述語の機能に影響を与えるラベルを追加することができます。

これらは設定可能であるため、ユーザー定義の名前が異なる限り、同じタイプ (ただし設定パラメーターは異なる) の複数の述語を組み合わせることができます。

これらの優先度の使用方法についての情報は、「スケジューラーポリシーの変更」を参照してください。

ServiceAffinity は、Pod で実行されるサービスに基づいて Pod をノードに配置します。同じノードまたは併置されているノードに同じサービスの複数の Pod を配置すると、効率が向上する可能性があります。

この述語は ノードセレクターの特定ラベルを持つ Pod を同じラベルを持つノードに配置しようとします。

Pod がノードセレクターでラベルを指定していない場合、最初の Pod は可用性に基づいて任意のノードに配置され、該当サービスの後続のすべての Pod はそのノードと同じラベルの値を持つノードにスケジュールされます。

"predicates":[
      {
         "name":"<name>", 1
         "weight" : "1" 2
         "argument":{
            "serviceAffinity":{
               "labels":[
                  "<label>" 3
               ]
            }
         }
      }
   ],
1
述語の名前を指定します。
2
1 (不適切) から 10 (最適) までの重みを指定します。
3
マッチングに使用するラベルを指定します。以下は例になります。
         "name":"ZoneAffinity",
         "weight" : "1"
         "argument":{
            "serviceAffinity":{
               "labels":[
                  "rack"

たとえば、ノードセレクター rack を持つサービスの最初の Pod がラベル region=rack を持つノードにスケジュールされている場合、同じサービスに属するその他すべての後続の Pod は同じ region=rack ラベルを持つノードにスケジュールされます。詳細は、「Pod 配置の制御」を参照してください。

複数レベルのラベルもサポートされています。ユーザーは同じリージョン内および (リージョン下の) 同じゾーン内のノードでスケジュールされるようサービスのすべての Pod を指定することもできます。

LabelsPresence は、値の種類を問わず、特定のノードに特定のラベルが定義されているかどうかを確認します。ラベルによるマッチングは、ノードに物理的な場所やステータスがラベルで定義されている場合などに役立ちます。

"predicates":[
      {
         "name":"<name>", 1
         "weight" : "1" 2
         "argument":{
            "labelsPresence":{
               "labels":[
                  "<label>" 3
                presence: true/false
               ]
            }
         }
      }
   ],
1
述語の名前を指定します。
2
1 (不適切) から 10 (最適) までの重みを指定します。
3
マッチングに使用するラベルを指定します。
ラベルが必須かどうかを指定します。
  • presence:false の場合、要求されるラベルのいずれかがノードラベルにある場合、Pod をスケジュールすることはできません。ラベルが存在しない場合は Pod をスケジュールできます。
  • presence:true の場合、要求されるラベルのすべてがノードラベルにある場合、Pod をスケジュールできます。ラベルのすべてが存在しない場合、Pod はスケジュールされません。

以下に例を示します。

         "name":"RackPreferred",
         "weight" : "1"
         "argument":{
            "labelsPresence":{
               "labels":[
                  "rack"
            "labelsPresence:"{
                "labels:"[
                - "region"
                presence: true

14.2.6. 利用可能な優先度

優先度は、設定に応じて残りのノードにランクを付けるルールです。

優先度のカスタムセットは、スケジューラーを設定するために指定できます。OpenShift Container Platform ではデフォルトでいくつかの優先度があります。他の優先度は、特定のパラメーターを指定してカスタマイズできます。優先順位に影響を与えるために、複数の優先度を組み合わせ、異なる重みをそれぞれのノードに指定することができます。

14.2.6.1. 静的優先度

静的優先度は、重みを除き、ユーザーからいずれの設定パラメーターも取りません。重みは指定する必要があり、0 または負の値にすることはできません。

これらはスケジューラー設定 /etc/origin/master/scheduler.json (デフォルト) に指定されます。

14.2.6.1.1. デフォルトの優先度

デフォルトのスケジューラーポリシーには、以下の優先度が含まれています。それぞれの優先度関数は、重み 10000 を持つ NodePreferAvoidPodsPriority 以外は重み 1 を持ちます。

SelectorSpreadPriority は、Pod に一致するサービス、レプリケーションコントローラー (RC)、レプリケーションセット (RS)、およびステートフルなセットを検索し、次にそれらのセレクターに一致する既存の Pod を検索します。スケジューラーは、一致する既存 Pod が少ないノードを優先し、Pod のスケジュール時にそれらのセレクターに一致する Pod 数の最も少ないノードで Pod をスケジュールします。

{"name" : "SelectorSpreadPriority", "weight" : 1}

InterPodAffinityPriority は、ノードの対応する PodAffinityTerm が満たされている場合に weightedPodAffinityTerm 要素を使った繰り返し処理や 重み の合計への追加によって合計を計算します。合計値の最も高いノードが最も優先されます。

{"name" : "InterPodAffinityPriority", "weight" : 1}

LeastRequestedPriority は要求されたリソースの少ないノードを優先します。これは、ノードでスケジュールされる Pod によって要求されるメモリーおよび CPU のパーセンテージを計算し、利用可能な/残りの容量の値の最も高いノードを優先します。

{"name" : "LeastRequestedPriority", "weight" : 1}

BalancedResourceAllocation は、均衡が図られたリソース使用率に基づいてノードを優先します。これは、容量の一部として消費済み CPU とメモリー間の差異を計算し、2 つのメトリクスがどの程度相互に近似しているかに基づいてノードの優先度を決定します。これは常に LeastRequestedPriority と併用する必要があります。

{"name" : "BalancedResourceAllocation", "weight" : 1}

NodePreferAvoidPodsPriority は、レプリケーションコントローラー以外のコントローラーによって所有される Pod を無視します。

{"name" : "NodePreferAvoidPodsPriority", "weight" : 10000}

NodeAffinityPriority は、ノードアフィニティーのスケジューリング設定に応じてノードの優先順位を決定します。

{"name" : "NodeAffinityPriority", "weight" : 1}

TaintTolerationPriority は、Pod についての 容認不可能な テイント数の少ないノードを優先します。容認不可能なテイントとはキー PreferNoSchedule のあるテイントのことです。

{"name" : "TaintTolerationPriority", "weight" : 1}
14.2.6.1.2. 他の静的優先度

OpenShift Container Platform は以下の優先度もサポートしています。

EqualPriority は、優先度の設定が指定されていない場合に、すべてのノードに等しい重み 1 を指定します。この優先順位はテスト環境にのみ使用することを推奨します。

{"name" : "EqualPriority", "weight" : 1}

MostRequestedPriority は、要求されたリソースの最も多いノードを優先します。これは、ノードスケジュールされる Pod で要求されるメモリーおよび CPU のパーセンテージを計算し、容量に対して要求される部分の平均の最大値に基づいて優先度を決定します。

{"name" : "MostRequestedPriority", "weight" : 1}

ImageLocalityPriority は、Pod コンテナーのイメージをすでに要求しているノードを優先します。

{"name" : "ImageLocalityPriority", "weight" : 1}

ServiceSpreadingPriority は、同じマシンに置かれる同じサービスに属する Pod 数を最小限にすることにより Pod を分散します。

{"name" : "ServiceSpreadingPriority", "weight" : 1}

14.2.6.2. 設定可能な優先度

これらの優先度は、デフォルトでスケジューラー設定 /etc/origin/master/scheduler.json で設定し、これらの優先度に影響を与えるラベルを追加できます。

優先度関数のタイプは、それらが取る引数によって識別されます。これらは設定可能なため、ユーザー定義の名前が異なる場合に、同じタイプの (ただし設定パラメーターは異なる) 設定可能な複数の優先度を組み合わせることができます。

これらの優先度の使用方法についての情報は、「スケジューラーポリシーの変更」を参照してください。

ServiceAntiAffinity はラベルを取り、ラベルの値に基づいてノードのグループ全体に同じサービスに属する Pod を適正に分散します。これは、指定されたラベルの同じ値を持つすべてのノードに同じスコアを付与します。また Pod が最も集中していないグループ内のノードにより高いスコアを付与します。

"priorities":[
      {
         "name":"<name>", 1
         "weight" : "1" 2
         "argument":{
            "serviceAntiAffinity":{
               "labels":[
                  "<label>" 3
               ]
            }
         }
      }
   ]
1
優先度の名前を指定します。
2
1 (不適切) から 10 (最適) までの重みを指定します。
3
マッチングに使用するラベルを指定します。

以下に例を示します。

         "name":"RackSpread",
         "weight" : "1"
         "argument":{
            "serviceAffinity":{
               "labels":[
                  "rack"

LabelPreference は、その値が何であるかを問わず、特定のラベルが定義されているノードを優先します。

"predicates":[
      {
         "name":"<name>", 1
         "weight" : "1" 2
         "argument":{
            "labelsPresence":{
               "labels":[
                  "<label>" 3
                presence: true/false
               ]
            }
         }
      }
   ],
1
優先度の名前を指定します。
2
1 (不適切) から 10 (最適) までの重みを指定します。
3
マッチングに使用するラベルを指定します。
ラベルが必須かどうかを指定します。
  • presence:false の場合、要求されるラベルのいずれかがノードラベルにある場合、Pod をスケジュールすることはできません。ラベルが存在しない場合は Pod をスケジュールできます。
  • presence:true の場合、要求されるラベルのすべてがノードラベルにある場合、Pod をスケジュールできます。ラベルのすべてが存在しない場合、Pod はスケジュールされません。

以下に例を示します。

         "name":"RackPreferred",
         "weight" : "1"
         "argument":{
            "labelsPresence":{
               "labels":[
                  "rack"

14.2.7. 使用例

OpenShift Container Platform 内でのスケジューリングの重要な使用例として、柔軟なアフィニティーと非アフィニティーポリシーのサポートを挙げることができます。

14.2.7.1. インフラストラクチャーのトポロジーレベル

管理者は、ノードのラベル (例: region=r1zone=z1rack=s1) を指定してインフラストラクチャーの複数のトポロジーレベルを定義することができます。

これらのラベル名には特別な意味はなく、管理者はそれらのインフラストラクチャーラベルに任意の名前 (例: 都市/建物/部屋) を付けることができます。さらに、管理者はインフラストラクチャートポロジーに任意の数のレベルを定義できます。通常は、(regionszonesracks などの) 3 つのレベルが適切なサイズです。管理者はこれらのレベルのそれぞれにアフィニティーと非アフィニティールールを任意の組み合わせで指定することができます。

14.2.7.2. アフィニティー

管理者は、任意のトポロジーレベルまたは複数のレベルでもアフィニティーを指定できるようにスケジューラーを設定することができます。特定レベルのアフィニティーは、同じサービスに属するすべての Pod が同じレベルに属するノードにスケジュールされることを示します。これは、管理者がピア Pod が地理的に離れ過ぎないようにすることでアプリケーションの待機時間の要件に対応します。同じアフィニティーグループ内で Pod をホストするために利用できるノードがない場合、Pod はスケジュールされません。

Pod がスケジュールされる場所に対する制御を強化する必要がある場合は、「ノードアフィニティーの使用」および「Pod のアフィニティーおよび非アフィニティーの使用」を参照してください。これらの詳細スケジューリング機能により、管理者は Pod をスケジュールできるノードを指定し、他の Pod に関連してスケジューリングを強制的に実行したり、拒否したりできます。

14.2.7.3. 非アフィニティー

管理者は、任意のトポロジーレベルまたは複数のレベルでも非アフィニティーを設定できるようスケジューラーを設定することができます。特定レベルの非アフィニティー (または「分散」)は、同じサービスに属するすべての Pod が該当レベルに属するノード全体に分散されることを示します。これにより、アプリケーションが高可用性の目的で適正に分散されます。スケジューラーは、可能な限り均等になるようにすべての適用可能なノード全体にサービス Pod を配置しようとします。

Pod がスケジュールされる場所に対する制御を強化する必要がある場合は、「ノードアフィニティーの使用」および「Pod のアフィニティーおよび非アフィニティーの使用」を参照してください。これらの詳細スケジューリング機能により、管理者は Pod をスケジュールできるノードを指定し、他の Pod に関連してスケジューリングを強制的に実行したり、拒否したりできます。

14.2.8. ポリシー設定のサンプル

以下の設定は、スケジューラーポリシーファイルを使って指定される場合のデフォルトのスケジューラー設定を示しています。

kind: "Policy"
version: "v1"
predicates:
...
  - name: "RegionZoneAffinity" 1
    argument:
      serviceAffinity: 2
        labels: 3
          - "region"
          - "zone"
priorities:
...
  - name: "RackSpread" 4
    weight: 1
    argument:
      serviceAntiAffinity: 5
        label: "rack" 6
1
述語の名前です。
2
3
述語のラベルです。
4
優先度の名前です。
5
6
優先度のラベルです。

以下の設定例のいずれの場合も、述語と優先度関数の一覧は、指定された使用例に関連するもののみを含むように切り捨てられます。実際には、完全な/分かりやすいスケジューラーポリシーには、上記のデフォルトの述語および優先度のほとんど (すべてではなくても) が含まれるはずです。

以下の例は、region (affinity) → zone (affinity) → rack (anti-affinity) の 3 つのトポロジーレベルを定義します。

kind: "Policy"
version: "v1"
predicates:
...
  - name: "RegionZoneAffinity"
    argument:
      serviceAffinity:
        labels:
          - "region"
          - "zone"
priorities:
...
  - name: "RackSpread"
    weight: 1
    argument:
      serviceAntiAffinity:
        label: "rack"

以下の例は、city (affinity) → building (anti-affinity) → room (anti-affinity) の 3 つのトポロジーレベルを定義します。

kind: "Policy"
version: "v1"
predicates:
...
  - name: "CityAffinity"
    argument:
      serviceAffinity:
        labels:
          - "city"
priorities:
...
  - name: "BuildingSpread"
    weight: 1
    argument:
      serviceAntiAffinity:
        label: "building"
  - name: "RoomSpread"
    weight: 1
    argument:
      serviceAntiAffinity:
        label: "room"

以下の例では、「region」ラベルが定義されたノードのみを使用し、「zone」ラベルが定義されたノードを優先するポリシーを定義します。

kind: "Policy"
version: "v1"
predicates:
...
  - name: "RequireRegion"
    argument:
      labelsPresence:
        labels:
          - "region"
        presence: true
priorities:
...
  - name: "ZonePreferred"
    weight: 1
    argument:
      labelPreference:
        label: "zone"
        presence: true

以下の例では、静的および設定可能な述語および優先度を組み合わせています。

kind: "Policy"
version: "v1"
predicates:
...
  - name: "RegionAffinity"
    argument:
      serviceAffinity:
        labels:
          - "region"
  - name: "RequireRegion"
    argument:
      labelsPresence:
        labels:
          - "region"
        presence: true
  - name: "BuildingNodesAvoid"
    argument:
      labelsPresence:
        labels:
          - "building"
        presence: false
  - name: "PodFitsPorts"
  - name: "MatchNodeSelector"
priorities:
...
  - name: "ZoneSpread"
    weight: 2
    argument:
      serviceAntiAffinity:
        label: "zone"
  - name: "ZonePreferred"
    weight: 1
    argument:
      labelPreference:
        label: "zone"
        presence: true
  - name: "ServiceSpreadingPriority"
    weight: 1

14.3. カスタムスケジューリング

14.3.1. 概要

デフォルトのスケジューラーと共に複数のカスタムスケジューラーを実行し、各 Pod に使用できるスケジューラーを設定できます。

特定のスケジューラーを使用して指定された Pod をスケジュールするには、Pod 仕様にスケジューラーの名前を指定します

14.3.2. スケジューラーのデプロイ

以下の手順は、スケジューラーをクラスターにデプロイするための一般的なプロセスです。

注記

スケジューラーの作成/デプロイ方法については、本書では扱いません。これらについては、Kubernetes ソースディレクトリーの plugin/pkg/scheduler などを参照してください。

  1. Pod 設定を作成するか、または編集し、schedulerName パラメーターでスケジューラーの名前を指定します。名前は一意である必要があります。

    スケジューラーを含む Pod 仕様のサンプル

    apiVersion: v1
    kind: Pod
    metadata:
      name: custom-scheduler
      labels:
        name: multischeduler-example
    spec:
      schedulerName: custom-scheduler 1
      containers:
      - name: pod-with-second-annotation-container
        image: docker.io/ocpqe/hello-pod

    1
    使用するスケジューラーの名前です。スケジューラー名が指定されていない場合、Pod はデフォルトのスケジューラーを使用して自動的にスケジュールされます。
  2. 以下のコマンドを実行して Pod を作成します。

    $ oc create -f scheduler.yaml
  3. 以下のコマンドを実行し、Pod がカスタムスケジューラーで作成されていることを確認します。

    $ oc get pod custom-scheduler -o yaml
  4. 以下のコマンドを実行して Pod のステータスを確認します。

    $ oc get pod

    Pod は実行されていないはずです。

    NAME                READY     STATUS    RESTARTS   AGE
    custom-scheduler    0/1       Pending    0         2m
  5. カスタムスケジューラーをデプロイします。
  6. 以下のコマンドを実行して Pod のステータスを確認します。

    $ oc get pod

    Pod は実行されているはずです。

    NAME                READY     STATUS    RESTARTS   AGE
    custom-scheduler    1/1       Running    0         4m
  7. 以下のコマンドを実行し、スケジューラーが使用されていることを確認します。

    $ oc describe pod custom-scheduler

    以下の切り捨てられた出力に示されるように、スケジューラーの名前が一覧表示されます。

    [...]
    Events:
      FirstSeen  LastSeen  Count  From              SubObjectPath  Type       Reason Message
      ---------  --------  -----  ----              -------------  --------   ------ -------
      1m         1m        1      my-scheduler      Normal         Scheduled  Successfully assigned custom-scheduler to <$node1>
    [...]

14.4. Pod 配置の制御

14.4.1. 概要

クラスター管理者は、特定のロールを持つアプリケーション開発者が Pod のスケジュール時に特定ノードをターゲットとすることを防ぐポリシーを設定できます。

Pod ノード制約の受付コントローラーは、Pod がラベルを使用して指定されたノードホストのみにデプロイされるようにし、特定のロールを持たないユーザーが nodeSelector フィールドを使用して Pod をスケジュールできないようにします。

14.4.2. ノード名の使用による Pod 配置の制約

Pod ノード制約の受付コントローラーを使用し、Pod にラベルを割り当て、これを Pod 設定の nodeName 設定に指定することで、Pod が指定されたノードホストにのみデプロイされるようにします。

  1. 必要なラベル (詳細は、「ノードでのラベルの更新」を参照) およびノードセレクターが環境にセットアップされていることを確認します。

    たとえば、Pod 設定が必要なラベルを示す nodeName 値を持つことを確認します。

    apiVersion: v1
    kind: Pod
    spec:
      nodeName: <value>
  2. マスター設定ファイル (/etc/origin/master/master-config.yaml) を 2 箇所で変更します。

    1. PodNodeConstraintsadmissionConfig セクションに追加します。

      ...
      admissionConfig:
        pluginConfig:
          PodNodeConstraints:
            configuration:
              apiversion: v1
              kind: PodNodeConstraintsConfig
      ...
    2. 次に、同じ設定を kubernetesMasterConfig セクションに追加します。

      ...
      kubernetesMasterConfig:
        admissionConfig:
          pluginConfig:
            PodNodeConstraints:
              configuration:
                apiVersion: v1
                kind: PodNodeConstraintsConfig
      ...
  3. 変更を有効にするために OpenShift Container Platform を再起動します。

    #systemctl restart atomic-openshift-master

14.4.3. ノードセレクターの使用による Pod 配置の制約

ノードセレクターを使用して、Pod が特定のラベルを持つノードにのみ配置されるようにすることができます。クラスター管理者は、Pod ノード制約の受付コントローラーを使用して、pods/binding パーミッションのないユーザーがノードセレクターを使用して Pod をスケジュールできないようにするポリシーを設定できます。

マスター設定ファイルの nodeSelectorLabelBlacklist フィールドを使用して、一部のロールが Pod 設定の nodeSelector フィールドで指定できるラベルを制御できます。pods/binding パーミッションロールを持つユーザー、サービスアカウントおよびグループは任意のノードセレクターを指定できます。pods/binding パーミッションがない場合は、nodeSelectorLabelBlacklist に表示されるすべてのラベルに nodeSelector を設定することは禁止されます。

たとえば、OpenShift Container Platform クラスターは、2 つの地域にまたがる 5 つのデータセンターで構成される場合があります。米国の "us-east"、"us-central"、および "us-west"、およびアジア太平洋地域 (APAC) の "apac-east" および "apac-west" です。それぞれの地理的地域の各ノードには、region: us-east などのラベルが付けられます。

注記

ラベルの割り当ての詳細は、「ノードでのラベルの更新」を参照してください。

クラスター管理者は、アプリケーション開発者が地理的に最も近い場所にあるノードにのみ Pod をデプロイできるインフラストラクチャーを作成できます。ノードセレクターを作成し、米国のデータセンターを superregion: us に、APAC のデータセンターを superregion: apac に分類できます。

データセンターごとのリソースの均等なロードを維持するには、必要な region をマスター設定の nodeSelectorLabelBlacklist セクションに追加できます。その後は、米国の開発者が Pod を作成するたびに、Pod は superregion: us ラベルの付いた地域のいずれかにあるノードにデプロイされます。開発者が Pod に特定の region (地域) をターゲットに設定しようとすると (例: region: us-east)、エラーが出されます。これを Pod にノードセレクターを設定せずに試行すると、ターゲットとした region (地域) にデプロイすることができます。それは superregion: us がプロジェクトレベルのノードセレクターとして設定されており、region: us-east というラベルが付けられたノードには superregion: us というラベルも付けられているためです。

  1. 必要なラベル (詳細は、「ノードでのラベルの更新」を参照) およびノードセレクターが環境にセットアップされていることを確認します。

    たとえば、Pod 設定が必要なラベルを示す nodeSelector 値を持つことを確認します。

    apiVersion: v1
    kind: Pod
    spec:
      nodeSelector:
        <key>: <value>
    ...
  2. マスター設定ファイル (/etc/origin/master/master-config.yaml) を 2 箇所で変更します。

    1. nodeSelectorLabelBlacklist を、Pod の配置を拒否する必要のあるノードホストに割り当てられるラベルと共に admissionConfig セクションに追加します。

      ...
      admissionConfig:
        pluginConfig:
          PodNodeConstraints:
            configuration:
              apiversion: v1
              kind: PodNodeConstraintsConfig
              nodeSelectorLabelBlacklist:
                - kubernetes.io/hostname
                - <label>
      ...
    2. 次に、同じ設定を kubernetesMasterConfig セクションに追加し、Pod の直接の作成を制限します。

      ...
      kubernetesMasterConfig:
        admissionConfig:
          pluginConfig:
            PodNodeConstraints:
              configuration:
                apiVersion: v1
                kind: PodNodeConstraintsConfig
                nodeSelectorLabelBlacklist:
                  - kubernetes.io/hostname
                  - <label_1>
      ...
  3. 変更を有効にするために OpenShift Container Platform を再起動します。

    #systemctl restart atomic-openshift-master

14.4.4. プロジェクト対する Pod 配置の制御

Pod ノードセレクターの受付コントローラーを使用して、Pod を特定のプロジェクトに関連付けられたノードに対して強制的に適用したり、Pod がそれらのノードでスケジュールされないようにしたりできます。

Pod ノードセレクター の受付コントローラーは、プロジェクトのラベルと Pod で指定されるノードセレクターを使用して Pod を配置する場所を決定します。新規 Pod は、Pod のノードセレクターがプロジェクトのラベルに一致する場合にのみプロジェクトに関連付けられたノードに配置されます。

Pod の作成後に、ノードセレクターは Pod にマージされ、Pod 仕様に元々含まれていたラベルとノードセレクターの新規ラベルが含まれるようにします。以下の例は、マージの結果について示しています。

Pod ノードセレクター の受付コントローラーにより、特定のプロジェクトで許可されるラベルの一覧を作成することもできます。この一覧は開発者がプロジェクトで使用できるラベルを認識するための ホワイトリスト として機能し、管理者がクラスターでのラベル設定の制御を強化するのに役立ちます。

Pod ノードセレクター の受付コントローラーをアクティブにするには、以下を実行します。

  1. 以下の方法のいずれかを使用して Pod ノードセレクター の受付コントローラーとホワイトリストを設定します。

    • 以下をマスター設定ファイル (/etc/origin/master/master-config.yaml) に追加します。

      admissionConfig:
        pluginConfig:
          PodNodeSelector:
            configuration:
              podNodeSelectorPluginConfig: 1
                clusterDefaultNodeSelector: "k3=v3" 2
                ns1: region=west,env=test,infra=fedora,os=fedora 3
      1
      Pod ノードセレクター の受付コントローラープラグインを追加します。
      2 3
      すべてのノードのデフォルトラベルを作成します。
      指定されたプロジェクトで許可されるラベルのホワイトリストを作成します。ここで、プロジェクトは ns1 で、ラベルはそれに続く key=value ペアになります。
      • 受付コントローラーの情報を含むファイルを作成します。

        podNodeSelectorPluginConfig:
            clusterDefaultNodeSelector: "k3=v3"
             ns1: region=west,env=test,infra=fedora,os=fedora

        次に、マスター設定でファイルを参照します。

        admissionConfig:
          pluginConfig:
            PodNodeSelector:
              location: <path-to-file>
        注記

        プロジェクトにノードセレクターが指定されていない場合、そのプロジェクトに関連付けられた Pod はデフォルトのノードセレクター (clusterDefaultNodeSelector) を使用してマージされます。

  2. 変更を有効にするために OpenShift Container Platform を再起動します。

    #systemctl restart atomic-openshift-master
  3. scheduler.alpha.kubernetes.io/node-selector アノテーションおよびラベルを含むプロジェクトオブジェクトを作成します。

    {
        "kind": "Namespace",
        "apiVersion": "v1",
        "metadata": {
            "name": "ns1",
            "annotations": {
                "scheduler.alpha.kubernetes.io/node-selector": "env=test,infra=fedora" 1
            }
        },
        "spec": {},
        "status": {}
    }
    1
    プロジェクトのラベルセレクターに一致するラベルを作成するためのアノテーションです。ここで、キー/値のラベルは env=test および infra=fedora になります。
  4. ノードセレクターにラベルを含む Pod 仕様を作成します。以下は例になります。

    apiVersion: v1
    kind: Pod
    metadata:
      labels:
        name: hello-pod
      name: hello-pod
    spec:
      containers:
        - image: "docker.io/ocpqe/hello-pod:latest"
          imagePullPolicy: IfNotPresent
          name: hello-pod
          ports:
            - containerPort: 8080
              protocol: TCP
          resources: {}
          securityContext:
            capabilities: {}
            privileged: false
          terminationMessagePath: /dev/termination-log
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      nodeSelector: 1
        env: test
        os: fedora
      serviceAccount: ""
    status: {}
    1
    プロジェクトラベルに一致するノードセレクターです。
  5. プロジェクトに Pod を作成します。

    oc create -f pod.yaml --namespace=ns1
  6. ノードセレクターのラベルが Pod 設定に追加されていることを確認します。

    get pod pod1 --namespace=ns1 -o json
    
    nodeSelector": {
     "env": "test",
     "infra": "fedora",
     "os": "fedora"
    }

    ノードセレクターは Pod にマージされ、Pod は適切なプロジェクトでスケジュールされます。

プロジェクト仕様で指定されていないラベルを使って Pod を作成する場合、Pod はノードでスケジュールされません。

たとえば、ここでラベル env: production はにずれのプロジェクト仕様にもありません。

nodeSelector:
 "env: production"
 "infra": "fedora",
 "os": "fedora"

ノードセレクターのアノテーションのないノードがある場合は、Pod はそこにスケジュールされます。

14.5. 詳細スケジューリング

14.5.1. 概要

詳細スケジューリングには、Pod が特定ノードで実行されることを要求したり、Pod が特定ノードで実行されることが優先されるように Pod を設定することが関係します。

通常、詳細スケジューリングは必要になりません。OpenShift Container Platform が Pod を合理的な方法で自動的に配置するためです。たとえば、デフォルトスケジューラーは Pod をノード間で均等に分散し、ノードの利用可能なリソースを考慮します。ただし、Pod を配置する場所についてはさらに制御を強化する必要がある場合があります。

Pod をより高速なディスクが搭載されたマシンに配置する必要ある場合 (またはそのマシンに配置するのを防ぐ場合)、または 2 つの異なるサービスの Pod が相互に通信できるように配置する必要がある場合、詳細スケジューリングを使用してそれを可能にすることができます。

適切な新規 Pod を特定のノードグループにスケジュールし、その他の新規 Pod がそれらのノードでスケジュールされるのを防ぐには、必要に応じてこれらの方法を組み合わせることができます。

14.5.2. 詳細スケジューリングの使用

クラスターで詳細スケジューリングを起動する方法はいくつかあります。

Pod のアフィニティーおよび非アフィニティー

Pod のアフィニティーにより、Pod がその配置に使用できるアフィニティー (または非アフィニティー) を、(セキュリティー上の理由によるアプリケーションの待機時間の要件などのために) Pod のグループに対して指定できるようにします。ノード自体は配置に対する制御を行いません。

Pod のアフィニティーはノードのラベルと Pod のラベルセレクターを使用して Pod 配置のルールを作成します。ルールは mandatory (必須) または best-effort (優先) のいずれかにすることができます。

Pod のアフィニティーおよび非アフィニティーの使用」を参照してください。

ノードのアフィニティー

ノードのアフィニティーにより、Pod がその配置に使用できるアフィニティー (または非アフィニティー) を、(高可用性のための特殊なハードウェア、場所、要件などにより) ノード のグループに対して指定できるようにします。ノード自体は配置に対する制御を行いません。

ノードのアフィニティーはノードのラベルと Pod のラベルセレクターを使用して Pod 配置のルールを作成します。ルールは mandatory (必須) または best-effort (優先) のいずれかにすることができます。

ノードアフィニティーの使用」を参照してください。

ノードセレクター

ノードセレクターは詳細スケジューリングの最も単純な形態です。ノードのアフィニティーのように、ノードセレクターはノードのラベルと Pod のラベルセレクターを使用し、Pod がその配置に使用する ノード を制御できるようにします。ただし、ノードセレクターにはノードのアフィニティーが持つ required (必須) ルールまたは preferred (優先) ルールはありません。

ノードセレクターの使用」を参照してください。

テイントおよび容認 (Toleration)

テイント/容認により、ノード はノード上でスケジュールする必要のある (またはスケジュールすべきでない) Pod を制御できます。テイントはノードのラベルであり、容認は Pod のラベルです。スケジュールを可能にするには、Pod のラベルは ノードのラベル (テイント) に一致する (またはこれを許容する) 必要があります。

テイント/容認にはアフィニティーと比較して 1 つ利点があります。たとえばアフィニティーの場合は、異なるラベルを持つノードの新規グループをクラスターに追加する場合、ノードにアクセスさせたい Pod とノードを使用させたくない Pod のそれぞれに対してアフィニティーを更新する必要がありますが、テイント/容認の場合には、新規ノードに到達させる必要のある Pod のみを更新すれば、他の Pod は拒否されることになります。

テイントおよび容認の使用」を参照してください。

14.6. 詳細スケジューリングおよびノードのアフィニティー

14.6.1. 概要

ノードのアフィニティー は、Pod の配置場所を判別するためにスケジューラーによって使用されるルールのセットです。ルールはカスタムのノードのラベルと Pod で指定されるラベルセレクターを使って定義されます。ノードのアフィニティーにより、Pod ノード のグループに対してはアフィニティー (または非アフィニティー) を指定できます。ノード自体は配置に対して制御を行いません。

たとえば、Pod を特定の CPU を搭載したノードまたは特定のアベイラビリティーゾーンにあるノードでのみ実行されるよう設定することができます。

ノードのアフィニティールールには、required (必須) および preferred (優先) の 2 つのタイプがあります。

required (必須) ルールは、Pod をノードにスケジュールする前に 満たされている必要があります。一方、preferred (優先) ルールは、ルールが満たされる場合にスケジューラーがルールの実施を試行しますが、その実施が必ずしも保証される訳ではありません。

注記

ランタイム時にノードのラベルに変更が生じ、その変更により Pod でのノードのアフィニティールールを満たさなくなる状態が生じるでも、Pod はノードで引き続き実行されます。

14.6.2. ノードのアフィニティーの設定

ノードのアフィニティーは、Pod 仕様で設定することができます。required (必須) ルールpreferred (優先) ルール のいずれかまたはその両方を指定することができます。両方を指定する場合、ノードは最初に required (必須) ルールを満たす必要があり、その後に preferred (優先) ルールを満たそうとします。

以下の例は、Pod をキーが e2e-az-NorthSouth で、その値が e2e-az-North または e2e-az-South のいずれかであるラベルの付いたノードに Pod を配置することを求めるルールが設定された Pod 仕様です。

ノードのアフィニティーの required (必須) ルールが設定された Pod 設定ファイルのサンプル

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity: 1
      requiredDuringSchedulingIgnoredDuringExecution: 2
        nodeSelectorTerms:
        - matchExpressions:
          - key: e2e-az-NorthSouth 3
            operator: In 4
            values:
            - e2e-az-North 5
            - e2e-az-South 6
  containers:
  - name: with-node-affinity
    image: docker.io/ocpqe/hello-pod

1
ノードのアフィニティーを設定するためのスタンザです。
2
required (必須) ルールを定義します。
3 5 6
ルールを適用するために一致している必要のあるキー/値のペア (ラベル)。
4
演算子は、ノードのラベルと Pod 仕様の matchExpression パラメーターの値のセットの間の関係を表します。この値は、InNotInExists、または DoesNotExistLt、または Gt にすることができます。

以下の例は、キーが e2e-az-EastWest で、その値が e2e-az-East または e2e-az-West のラベルが付いたノードに Pod を配置すること優先する preferred (優先) ルールが設定されたノード仕様です。

ノードのアフィニティーの preferred (優先) ルールが設定された Pod 設定ファイルのサンプル

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity: 1
      preferredDuringSchedulingIgnoredDuringExecution: 2
      - weight: 1 3
        preference:
          matchExpressions:
          - key: e2e-az-EastWest 4
            operator: In 5
            values:
            - e2e-az-East 6
            - e2e-az-West 7
  containers:
  - name: with-node-affinity
    image: docker.io/ocpqe/hello-pod

1
ノードのアフィニティーを設定するためのスタンザです。
2
preferred (優先) ルールを定義します。
3
preferred (優先) ルールの重みを指定します。最も高い重みを持つノードが優先されます。
4 6 7
ルールを適用するために一致している必要のあるキー/値のペア (ラベル)。
5
演算子は、ノードのラベルと Pod 仕様の matchExpression パラメーターの値のセットの間の関係を表します。この値は、InNotInExists、または DoesNotExistLt、または Gt にすることができます。

ノードの非アフィニティー についての明示的な概念はありませんが、NotIn または DoesNotExist 演算子を使用すると、動作が複製されます。

注記

同じ Pod 設定でノードのアフィニティーと ノードセレクターを使用している場合、以下に注意してください。

  • nodeSelectornodeAffinity の両方を設定する場合、Pod が候補ノードでスケジュールされるにはどちらの条件も満たしている必要があります。
  • nodeAffinity タイプに関連付けられた複数の nodeSelectorTerms を指定する場合、nodeSelectorTerms のいずれかが満たされている場合に Pod をノードにスケジュールすることができます。
  • nodeSelectorTerms に関連付けられた複数の matchExpressions を指定する場合、すべての matchExpressions が満たされている場合にのみ Pod をノードにスケジュールすることができます。

14.6.2.1. ノードアフィニティーの required (必須) ルールの設定

Pod がノードにスケジュールされる前に、required (必須) ルールを 満たしている必要があります

以下の手順は、ノードとスケジューラーがノードに配置する必要のある Pod を作成する単純な設定を示しています。

  1. ノード設定を編集するか、または oc label node コマンドを使用してラベルをノードに追加します。

    $ oc label node node1 e2e-az-name=e2e-az1
  2. Pod 仕様では、nodeAffinity スタンザを使用して requiredDuringSchedulingIgnoredDuringExecution パラメーターを設定します。

    1. 満たす必要のあるキーおよび値を指定します。新規 Pod を編集したノードにスケジュールする必要がある場合、ノードのラベルと同じkey および value パラメーターを使用します。
    2. operator を指定します。演算子は InNotInExistsDoesNotExistLt、または Gt にすることができます。たとえば、演算子 In を使用してラベルがノードで必要になるようにします。

      spec:
        affinity:
          nodeAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              nodeSelectorTerms:
              - matchExpressions:
                - key: e2e-az-name
                  operator: In
                  values:
                  - e2e-az1
                  - e2e-az2
  3. Pod の作成します。

    $ oc create -f e2e-az2.yaml

14.6.2.2. ノードアフィニティーの preferred (優先) ルールの設定

preferred (優先) ルールは、ルールを満たす場合に、スケジューラーはルールの実施を試行しますが、その実施が必ずしも保証される訳ではありません。

以下の手順は、ノードとスケジューラーがノードに配置しようとする Pod を作成する単純な設定を示しています。

  1. ノード設定を編集するか、または oc label node コマンドを実行してラベルをノードに追加します。

    $ oc label node node1 e2e-az-name=e2e-az3
  2. Pod 仕様では、nodeAffinity スタンザを使用して preferredDuringSchedulingIgnoredDuringExecution パラメーターを設定します。

    1. ノードの重みを数字の 1-100 で指定します。最も高い重みを持つノードが優先されます。
    2. 満たす必要のあるキーおよび値を指定します。新規 Pod を編集したノードにスケジュールする必要がある場合、ノードのラベルと同じkey および value パラメーターを使用します。

            preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 1
              preference:
                matchExpressions:
                - key: e2e-az-name
                  operator: In
                  values:
                  - e2e-az3
  3. operator を指定します。演算子は InNotInExistsDoesNotExistLt、または Gt にすることができます。たとえば、演算子 In を使用してラベルをノードで必要になるようにします。
  4. Pod を作成します。

    $ oc create -f e2e-az3.yaml

14.6.3. 各種の例

以下の例は、ノードのアフィニティーを示しています。

14.6.3.1. 一致するラベルを持つノードのアフィニティー

以下の例は、一致するラベルを持つノードと Pod のノードのアフィニティーを示しています。

  • Node1 ノードにはラベル zone:us があります。

    $ oc label node node1 zone=us
  • Pod pod-s1 にはノードアフィニティーの required (必須) ルールの下に zoneus のキー/値のペアがあります。

    $ cat pod-s1.yaml
    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-s1
    spec:
      containers:
        - image: "docker.io/ocpqe/hello-pod"
          name: hello-pod
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                - key: "zone"
                  operator: In
                  values:
                  - us
  • 標準コマンドを使用して Pod を作成します。

    $ oc create -f pod-s1.yaml
    pod "pod-s1" created
  • Pod pod-s1Node1 にスケジュールできます。

     oc get pod -o wide
    NAME     READY     STATUS       RESTARTS   AGE      IP      NODE
    pod-s1   1/1       Running      0          4m       IP1     node1

14.6.3.2. 一致するラベルのないノードのアフィニティー

以下の例は、一致するラベルを持たないノードと Pod のノードのアフィニティーを示しています。

  • Node1 ノードにはラベル zone:emea があります。

    $ oc label node node1 zone=emea
  • Pod pod-s1 にはノードアフィニティーの required (必須) ルールの下に zoneus のキー/値のペアがあります。

    $ cat pod-s1.yaml
    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-s1
    spec:
      containers:
        - image: "docker.io/ocpqe/hello-pod"
          name: hello-pod
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                - key: "zone"
                  operator: In
                  values:
                  - us
  • Pod pod-s1Node1 にスケジュールすることができません。

    oc describe pod pod-s1
    <---snip--->
    Events:
     FirstSeen LastSeen Count From              SubObjectPath  Type                Reason
     --------- -------- ----- ----              -------------  --------            ------
     1m        33s      8     default-scheduler Warning        FailedScheduling    No nodes are available that match all of the following predicates:: MatchNodeSelector (1).

14.7. 詳細スケジューリングおよび Pod のアフィニティーと非アフィニティー

14.7.1. 概要

Pod のアフィニティー および Pod の非アフィニティー により、他の Pod との関連で Pod を配置する方法についてのルールを指定できます。ルールは、カスタムのノードのラベルおよび Pod で指定されるラベセレクターを使用して定義されます。Pod のアフィニティー/非アフィニティーにより、Pod はアフィニティー (または非アフィニティー) を、その配置に使用できる Pod のグループに対して指定できます。ノード自体は配置に対する制御を行いません。

たとえば、アフィニティールールを使用することで、サービス内で、または他のサービスの Pod との関連で Pod を分散したり、パックしたりすることができます。非アフィニティールールにより、特定のサービスの Pod がそののサービスの Pod のパフォーマンスに干渉すると見なされる別のサービスの Pod と同じノードでスケジュールされることを防ぐことができます。または、関連する障害を減らすために複数のノードまたはアベイラビリティーゾーン間でサービスの Pod を分散することもできます。

Pod のアフィニティー/非アフィニティーにより、他の Pod のラベルに基づいて Pod のスケジュール対象とするノードを制限することができます。ラベルはキー/値のペアです。

  • Pod のアフィニティーはスケジューラーに対し、新規 Pod のラベルセレクターが現在の Pod のラベルに一致する場合に他の Pod と同じノードで新規 Pod を見つけるように指示します。
  • Pod の非アフィニティーは、新規 Pod のラベルセレクターが現在の Pod のラベルに一致する場合に、同じラベルを持つ Pod と同じノードで新規 Pod を見つけることを禁止します。

Pod のアフィニティーには、required (必須) および preferred (優先) の 2 つのタイプがあります。

required (必須) ルールは、Pod をノードにスケジュールする前に 満たされている必要があります。一方、preferred (優先) ルールは、ルールが満たされる場合にスケジューラーがルールの実施を試行しますが、その実施が必ずしも保証される訳ではありません。

14.7.2. Pod のアフィニティーおよび非アフィニティーの設定

Pod のアフィニティー/非アフィニティーは Pod 仕様ファイルで設定します。required (必須) ルールpreferred (優先) ルールのいずれかまたはその両方を指定することができます。両方を指定する場合、ノードは最初に required (必須) ルールを満たす必要があり、その後に preferred (優先) ルールを満たそうとします。

以下の例は、Pod のアフィニティーおよび非アフィニティーに設定される Pod 仕様を示しています。

この例では、Pod のアフィニティールールは ノードにキー security と値 S1 を持つラベルの付いた 1 つ以上の Pod がすでに実行されている場合にのみ Pod をノードにスケジュールできることを示しています。Pod の非アフィニティールールは、ノードがキー security と値 S2 を持つラベルが付いた Pod がすでに実行されている場合は Pod をノードにスケジュールしないように設定することを示しています。

Pod のアフィニティーが設定された Pod 設定のサンプル

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity: 1
      requiredDuringSchedulingIgnoredDuringExecution: 2
      - labelSelector:
          matchExpressions:
          - key: security 3
            operator: In 4
            values:
            - S1 5
        topologyKey: failure-domain.beta.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: docker.io/ocpqe/hello-pod

1
Pod のアフィニティーを設定するためのスタンザです。
2
required (必須) ルールを定義します。
3 5
ルールを適用するために一致している必要のあるキーと値 (ラベル) です。
4
演算子は、既存 Pod のラベルと新規 Pod の仕様の matchExpression パラメーターの値のセットの間の関係を表します。これには InNotInExists、または DoesNotExist のいずれかを使用できます。

Pod の非アフィニティーが設定された Pod 設定のサンプル

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-antiaffinity
spec:
  affinity:
    podAntiAffinity: 1
      preferredDuringSchedulingIgnoredDuringExecution: 2
      - weight: 100 3
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security 4
              operator: In 5
              values:
              - S2 6
          topologyKey: kubernetes.io/hostname
  containers:
  - name: with-pod-affinity
    image: docker.io/ocpqe/hello-pod

1
Pod の非アフィニティーを設定するためのスタンザです。
2
preferred (優先) ルールを定義します。
3
preferred (優先) ルールの重みを指定します。最も高い重みを持つノードが優先されます。
4 6
ルールを適用するために一致している必要のあるキーと値 (ラベル) です。
5
演算子は、既存 Pod のラベルと新規 Pod の仕様の matchExpression パラメーターの値のセットの間の関係を表します。これには InNotInExists、または DoesNotExist のいずれかを使用できます。
注記

ノードのラベルに、Pod のノードのアフィニティールールを満たさなくなるような結果になる変更がランタイム時に生じる場合も、Pod はノードで引き続き実行されます。

14.7.2.1. アフィニティールールの設定

以下の手順は、ラベルの付いた Pod と Pod のスケジュールを可能にするアフィニティーを使用する Pod を作成する 2 つの Pod の単純な設定を示しています。

  1. Pod 仕様の特定のラベルの付いた Pod を作成します。

    $ cat team4.yaml
    apiVersion: v1
    kind: Pod
    metadata:
      name: security-s1
      labels:
        security: S1
    spec:
      containers:
      - name: security-s1
        image: docker.io/ocpqe/hello-pod
  2. 他の Pod の作成時に、以下のように Pod 仕様を編集します。

    1. podAffinity スタンザを使用して、requiredDuringSchedulingIgnoredDuringExecution パラメーターまたは preferredDuringSchedulingIgnoredDuringExecution パラメーターを設定します。
    2. 満たしている必要のあるキーおよび値を指定します。新規 Pod を他の Pod と共にスケジュールする必要がある場合、最初の Pod のラベルと同じ key および value パラメーターを使用します。

          podAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                - key: security
                  operator: In
                  values:
                  - S1
              topologyKey: failure-domain.beta.kubernetes.io/zone
    3. operator を指定します。演算子は InNotInExists、または DoesNotExist にすることができます。たとえば、演算子 In を使用してラベルをノードで必要になるようにします。
    4. topologyKey を指定します。これは、システムがトポロジードメインを表すために使用する事前にデータが設定された Kubernetes ラベルです。
  3. Pod を作成します。

    $ oc create -f <pod-spec>.yaml

14.7.2.2. 非アフィニティールールの設定

以下の手順は、ラベルの付いた Pod と Pod のスケジュールの禁止を試行する非アフィニティーの preferred (優先) ルールを使用する Pod を作成する 2 つの Pod の単純な設定を示しています。

  1. Pod 仕様の特定のラベルの付いた Pod を作成します。

    $ cat team4.yaml
    apiVersion: v1
    kind: Pod
    metadata:
      name: security-s2
      labels:
        security: S2
    spec:
      containers:
      - name: security-s2
        image: docker.io/ocpqe/hello-pod
  2. 他の Pod の作成時に、Pod 仕様を編集して以下のパラメーターを設定します。
  3. podAffinity スタンザを使用して、requiredDuringSchedulingIgnoredDuringExecution パラメーターまたは preferredDuringSchedulingIgnoredDuringExecution パラメーターを設定します。

    1. ノードの重みを 1-100 で指定します。最も高い重みを持つノードが優先されます。
    2. 満たしている必要のあるキーおよび値を指定します。新規 Pod を他の Pod と共にスケジュールされないようにする必要がある場合、最初の Pod のラベルと同じ key および value パラメーターを使用します。

          podAntiAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                  - key: security
                    operator: In
                    values:
                    - S2
                topologyKey: kubernetes.io/hostname
    3. preferred (優先) ルールの場合、重みを 1-100 で指定します。
    4. operator を指定します。演算子は InNotInExists、または DoesNotExist にすることができます。たとえば、演算子 In を使用してラベルをノードで必要になるようにします。
  4. topologyKey を指定します。これは、システムがトポロジードメインを表すために使用する事前にデータが設定された Kubernetes ラベルです。
  5. Pod を作成します。

    $ oc create -f <pod-spec>.yaml

14.7.3. 各種の例

以下の例は、Pod のアフィニティーおよび非アフィニティーについて示しています。

14.7.3.1. Pod のアフィニティー

以下の例は、一致するラベルとラベルセレクターを持つ Pod についての Pod のアフィニティーを示しています。

  • Pod team4 にはラベル team:4 が付けられています。

    $ cat team4.yaml
    apiVersion: v1
    kind: Pod
    metadata:
      name: team4
      labels:
         team: "4"
    spec:
      containers:
      - name: ocp
        image: docker.io/ocpqe/hello-pod
  • Pod team4a には、podAffinity の下にラベルセレクター team:4 が付けられています。

    $ cat pod-team4a.yaml
    apiVersion: v1
    kind: Pod
    metadata:
      name: team4a
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: team
                operator: In
                values:
                - "4"
            topologyKey: kubernetes.io/hostname
      containers:
      - name: pod-affinity
        image: docker.io/ocpqe/hello-pod
  • team4a Pod は team4 Pod と同じノードにスケジュールされます。

14.7.3.2. Pod の非アフィニティー

以下の例は、一致するラベルとラベルセレクターを持つ Pod についての Pod の非アフィニティーを示しています。

  • Pod pod-s1 にはラベル security:s1 が付けられています。

    cat pod-s1.yaml
    apiVersion: v1
    kind: Pod
    metadata:
      name: s1
      labels:
        security: s1
    spec:
      containers:
      - name: ocp
        image: docker.io/ocpqe/hello-pod
  • Pod pod-s2 には、podAntiAffinity の下にラベルセレクター security:s1 が付けられています。

    cat pod-s2.yaml
    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-s2
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: security
                operator: In
                values:
                - s1
            topologyKey: kubernetes.io/hostname
      containers:
      - name: pod-antiaffinity
        image: docker.io/ocpqe/hello-pod
  • Pod pod-s2 は、security:s2 ラベルの付いた Pod を持つノードがない場合はスケジュールされません。そのラベルの付いた他の Pod がない場合、新規 Pod は保留状態のままになります。

    NAME      READY     STATUS    RESTARTS   AGE       IP        NODE
    pod-s2    0/1       Pending   0          32s       <none>

14.7.3.3. 一致するラベルのない Pod のアフィニティー

以下の例は、一致するラベルとラベルセレクターのない Pod についての Pod のアフィニティーを示しています。

  • Pod pod-s1 にはラベル security:s1 が付けられています。

    $ cat pod-s1.yaml
    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-s1
      labels:
        security: s1
    spec:
      containers:
      - name: ocp
        image: docker.io/ocpqe/hello-pod
  • Pod pod-s2 にはラベルセレクター security:s2 があります。

    $ cat pod-s2.yaml
    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-s2
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: security
                operator: In
                values:
                - s2
            topologyKey: kubernetes.io/hostname
      containers:
      - name: pod-affinity
        image: docker.io/ocpqe/hello-pod
  • Pod pod-s2pod-s1 と同じノードにスケジュールできません。

14.8. 詳細スケジューリングおよびノードセレクター

14.8.1. 概要

ノードセレクター はキーと値のペアのマップを指定します。ルールは、カスタムのノードのラベルおよび Pod で指定されるセレクターを使用して定義されます。

Pod がノードで実行する要件を満たすには、Pod はノードのラベルとして示されるキーと値のペアを持っている必要があります。

同じ Pod 設定でノードのアフィニティーと ノードセレクターを使用している場合は、以下の「重要な考慮事項」を参照してください。

14.8.2. ノードセレクターの設定

Pod 設定で nodeSelector を使用することで、Pod を特定のラベルの付いたノードのみに配置することができます。

  1. 必要なラベル (詳細は、「ノードでのラベルの更新」を参照) およびノードセレクターが環境にセットアップされていることを確認します。

    たとえば、Pod 設定が必要なラベルを示す nodeSelector 値を持つことを確認します。

    apiVersion: v1
    kind: Pod
    spec:
      nodeSelector:
        <key>: <value>
    ...
  2. マスター設定ファイル (/etc/origin/master/master-config.yaml) を 2 箇所で変更します。

    1. nodeSelectorLabelBlacklist を、Pod の配置を拒否する必要のあるノードホストに割り当てられるラベルと共に admissionConfig セクションに追加します。

      ...
      admissionConfig:
        pluginConfig:
          PodNodeConstraints:
            configuration:
              apiversion: v1
              kind: PodNodeConstraintsConfig
              nodeSelectorLabelBlacklist:
                - kubernetes.io/hostname
                - <label>
      ...
    2. 次に、同じ設定を kubernetesMasterConfig セクションに追加し、Pod の直接の作成を制限します。

      ...
      kubernetesMasterConfig:
        admissionConfig:
          pluginConfig:
            PodNodeConstraints:
              configuration:
                apiVersion: v1
                kind: PodNodeConstraintsConfig
                nodeSelectorLabelBlacklist:
                  - kubernetes.io/hostname
                  - <label_1>
      ...
  3. 変更を有効にするために OpenShift Container Platform を再起動します。

    #systemctl restart atomic-openshift-master
注記

同じ Pod 設定でノードセレクターとノードのアフィニティーを使用している場合は、以下に注意してください。

  • nodeSelectornodeAffinity の両方を設定する場合、Pod が候補ノードでスケジュールされるにはどちらの条件も満たしている必要があります。
  • nodeAffinity タイプに関連付けられた複数の nodeSelectorTerms を指定する場合、nodeSelectorTerms のいずれかが満たされている場合に Pod をノードにスケジュールすることができます。
  • nodeSelectorTerms に関連付けられた複数の matchExpressions を指定する場合、すべての matchExpressions が満たされている場合にのみ Pod をノードにスケジュールすることができます。

14.9. 詳細スケジューリングおよび容認

14.9.1. 概要

テイントおよび容認により、ノード はノード上でスケジュールする必要のある (またはスケジュールすべきでない) Pod を制御できます。

14.9.2. テイントおよび容認 (Toleration)

テイント により、ノードは Pod に一致する 容認 がない場合に Pod のスケジュールを拒否することができます。

テイントはノード仕様 (NodeSpec) でノードに適用され、容認は Pod 仕様 (PodSpec) で Pod に適用されます。ノードのテイントはノードに対し、テイントを容認しないすべての Pod を拒否するよう指示します。

テイントおよび容認は、key、value、および effect.で構成されています。演算子により、これらの 3 つのパラメーターのいずれかを空のままにすることができます。

表14.1 テイントおよび容認コンポーネント

パラメーター説明

key

key には、253 文字までの文字列を使用できます。キーは文字または数字で開始する必要があり、文字、数字、ハイフン、ドットおよびアンダースコアを含めることができます。

value

value には、63 文字までの文字列を使用できます。値は文字または数字で開始する必要があり、文字、数字、ハイフン、ドットおよびアンダースコアを含めることができます。

effect

effect は以下のいずれかにすることができます。

NoSchedule

  • テイントに一致しない新規 Pod はノードにスケジュールされません。
  • ノードの既存 Pod はそのままになります。

PreferNoSchedule

  • テイントに一致しない新規 Pod はノードにスケジュールされる可能性がありますが、スケジューラーはスケジュールしないようにします。
  • ノードの既存 Pod はそのままになります。

NoExecute

  • テイントに一致しない新規 Pod はノードにスケジュールできません。
  • 一致する容認を持たないノードの既存 Pod は削除されます。

operator

Equal

key/value/effect パラメーターは一致する必要があります。これはデフォルトになります。

Exists

key/effect パラメーターは一致する必要があります。いずれかに一致する value パラメーターを空のままにする必要があります。

容認はテイントと一致します。

  • operator パラメーターが Equal に設定されている場合:

    • key パラメーターは同じになります。
    • value パラメーターは同じになります。
    • effect パラメーターは同じになります。
  • operator パラメーターが Exists に設定されている場合:

    • key パラメーターは同じになります。
    • effect パラメーターは同じになります。

14.9.2.1. 複数テイントの使用

複数のテイントを同じノードに、複数の容認を同じ Pod に配置することができます。OpenShift Container Platform は複数のテイントと容認を以下のように処理します。

  1. Pod に一致する容認のあるテイントを処理します。
  2. 残りの一致しないテイントは Pod について以下の effect を持ちます。

    • effect が NoSchedule の一致しないテイントが 1 つ以上ある場合、OpenShift Container Platform は Pod をノードにスケジュールできません。
    • effect が NoSchedule の一致しないテイントがなく、effect が PreferNoSchedule の一致しない テイントが 1 つ以上ある場合、OpenShift Container Platform は Pod のノードへのスケジュールを試行しません。
    • effect が NoExecute のテイントが 1 つ以上ある場合、OpenShift Container Platform は Pod をノードからエビクトするか (ノードですでに実行中の場合)、または Pod のそのノードへのスケジュールが実行されません (ノードでまだ実行されていない場合)。

      • テイントを容認しない Pod はすぐにエビクトされます。
      • 容認の仕様に tolerationSeconds を指定せずにテイントを容認する Pod は永久にバインドされたままになります。
      • 指定された tolerationSeconds を持つテイントを容認する Pod は指定された期間バインドされます。

以下に例を示します。

  • ノードには以下のテイントがあります。

    $ oc adm taint nodes node1 key1=value1:NoSchedule
    $ oc adm taint nodes node1 key1=value1:NoExecute
    $ oc adm taint nodes node1 key2=value2:NoSchedule
  • Pod には以下の容認があります。

    tolerations:
    - key: "key1"
      operator: "Equal"
      value: "value1"
      effect: "NoSchedule"
    - key: "key1"
      operator: "Equal"
      value: "value1"
      effect: "NoExecute"

この場合、3 つ目のテイントに一致する容認がないため、Pod はノードにスケジュールできません。Pod はこのテイントの追加時にノードですでに実行されている場合は実行が継続されます。3 つ目のテイントは 3 つのテイントの中で Pod で容認されない唯一のテイントであるためです。

14.9.3. テイントの既存ノードへの追加

テイントおよび容認コンポーネントの表で説明されているパラメーターと共に oc adm taint コマンドを使用してテイントをノードに追加します。

$ oc adm taint nodes <node-name> <key>=<value>:<effect>

以下に例を示します。

$ oc adm taint nodes node1 key1=value1:NoSchedule

この例では、テイントを、キー key1、値 value1、およびテイント effect NoSchedule を持つ node1 にテイントを配置します。

14.9.4. 容認の Pod への追加

容認を Pod に追加するには、Pod 仕様を tolerations セクションを含めるように編集します。

Equal 演算子を含む Pod 設定ファイルのサンプル

tolerations:
- key: "key1" 1
  operator: "Equal" 2
  value: "value1" 3
  effect: "NoExecute" 4
  tolerationSeconds: 3600 5

1 2 3 4
テイントおよび容認コンポーネント の表で説明されている toleration パラメーターです。
5
tolerationSeconds パラメーターは、Pod がエビクトされる前にノードにバインドされる期間を指定します。以下の「Pod エビクションを遅延させる容認期間 (秒数) の使用」を参照してください。

Exists 演算子を含む Pod 設定ファイルのサンプル

tolerations:
- key: "key1"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 3600

これらの容認のいずれも上記の oc adm taint コマンドで作成されるテイントに一致します。いずれかの容認のある Pod は node1 にスケジュールできます。

14.9.4.1. Pod のエビクションを遅延させる容認期間 (秒数) の使用

Pod 仕様に tolerationSeconds パラメーターを指定して、Pod がエビクトされる前にノードにバインドされる期間を指定できます。effect NoExecute のあるテイントがノードに追加される場合、テイントを容認しない Pod は即時にエビクトされます (テイントを容認する Pod はエビクトされません)。ただし、エビクトされる Pod に tolerationSeconds パラメーターがある場合、Pod は期間切れになるまでエビクトされません。

以下に例を示します。

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"
  tolerationSeconds: 3600

ここで、この Pod が実行中であるものの、一致するテイントがない場合、Pod は 3,600 秒間バインドされたままとなり、その後にエビクトされます。テイントが期限前に削除される場合、Pod はエビクトされません。

14.9.4.1.1. 容認の秒数のデフォルト値の設定

このプラグインは、node.alpha.kubernetes.io/notReady:NoExecute および node.alpha.kubernetes.io/notReady:NoExecute テイントを 5 分間容認するための Pod のデフォルトの容認を設定します。

ユーザーが提供する Pod 設定にいずれかの容認がある場合、デフォルトは追加されません。

デフォルトの容認の秒数を有効にするには、以下を実行します。

  1. マスター設定ファイル (/etc/origin/master/master-config.yaml) を変更して DefaultTolerationSeconds を admissionConfig セクションに追加します。

    admissionConfig:
      pluginConfig:
        DefaultTolerationSeconds:
          configuration:
            kind: DefaultAdmissionConfig
            apiVersion: v1
            disable: false
  2. 変更を有効にするために、OpenShift を再起動します。

    # systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
  3. デフォルトが追加されていることを確認します。

    1. Pod を作成します。

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

      以下に例を示します。

      $ oc create -f hello-pod.yaml
      pod "hello-pod" created
    2. Pod の容認を確認します。

      $ oc describe pod <pod-name> |grep -i toleration

      以下に例を示します。

      $ oc describe pod hello-pod |grep -i toleration
      Tolerations:    node.alpha.kubernetes.io/notReady=:Exists:NoExecute for 300s

14.9.5. ノードの問題の発生時における Pod エビクションの禁止

OpenShift Container Platform は、node unreachable および node not ready 状態をテイントとして表示するよう設定できます。これにより、デフォルトの 5 分を使用するのではなく、unreachable (到達不能) または not ready (準備ができていない) 状態になるノードにバインドされたままになる期間を Pod 仕様ごとに指定することができます。

テイントベースのエビクション機能が有効にされた状態で、テイントはノードコントローラーによって自動的に追加され、Pod を Ready ノードからエビクトするための通常のロジックは無効にされます。

  • ノードが not ready (準備ができていない) 状態になると、node.alpha.kubernetes.io/notReady:NoExecute テイントは追加され、Pod はノードでスケジュールできなくなります。既存 Pod は容認期間 (秒数) 中はそのまま残ります。
  • ノードが not reachable (到達不能) の状態になると、node.alpha.kubernetes.io/unreachable:NoExecute テイントは追加され、Pod はノードでスケジュールできません。既存の Pod は容認期間 (秒数) 中はそのまま残ります。

テイントベースのエビクションを有効にするには、以下を実行します。

  1. マスター設定ファイル (/etc/origin/master/master-config.yaml) を変更して以下を kubernetesMasterConfig セクションに追加します。

    kubernetesMasterConfig:
       controllerArguments:
            feature-gates:
            - "TaintBasedEvictions=true"
  2. テイントがノードに追加されていることを確認します。

    oc describe node $node | grep -i taint
    
    Taints: node.alpha.kubernetes.io/notReady:NoExecute
  3. 変更を有効にするために、OpenShift を再起動します。

    # systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
  4. 容認を Pod に追加します。

    tolerations:
    - key: "node.alpha.kubernetes.io/unreachable"
      operator: "Exists"
      effect: "NoExecute"
      tolerationSeconds: 6000

    または

    tolerations:
    - key: "node.alpha.kubernetes.io/notReady"
      operator: "Exists"
      effect: "NoExecute"
      tolerationSeconds: 6000
注記

ノードの問題の発生時に Pod エビクションの既存のレート制限の動作を維持するために、システムはテイントをレートが制限された方法で追加します。これにより、マスターがノードからパーティション化される場合などのシナリオで発生する大規模な Pod エビクションを防ぐことができます。

14.9.6. Daemonset および容認

Daemonset Pod は、Default Toleration Seconds (デフォルトの容認期間の秒数) が無効にされている場合でも、tolerationSeconds のない node.alpha.kubernetes.io/unreachable および node.alpha.kubernetes.io/notReadyNoExecute 容認の設定と共に作成されます。

14.9.7. 各種の例

テイントおよび容認は、Pod をノードから切り離し、ノードで実行されるべきでない Pod をエビクトする柔軟性のある方法として使用できます。以下は典型的なシナリオのいくつかになります。

14.9.7.1. ノードをユーザー専用にする

ノードのセットを特定のユーザーセットが排他的に使用するように指定できます。

専用ノードを指定するには、以下を実行します。

  1. テイントをそれらのノードに追加します。

    以下に例を示します。

    $ oc adm taint nodes node1 dedicated=groupName:NoSchedule
  2. カスタムの受付コントローラーを作成して、対応する容認を Pod に追加します。

    容認のある Pod のみが専用ノードを使用することを許可されます。

14.9.7.2. ユーザーのノードへのバインド

特定ユーザーが専用ノードのみを使用できるようにノードを設定することができます。

ノードをユーザーの使用可能な唯一のノードとして設定するには、以下を実行します。

  1. テイントをそれらのノードに追加します。

    以下に例を示します。

    $ oc adm taint nodes node1 dedicated=groupName:NoSchedule
  2. カスタムの受付コントローラーを作成して、対応する容認を Pod に追加します。

    受付コントローラーは、Pod が key:value ラベル (dedicated=groupName) が付けられたノードのみにスケジュールされるようにノードのアフィニティーを追加します。

  3. テイントと同様のラベル (key:value ラベルなど) を専用ノードに追加します。

14.9.7.3. 特殊ハードウェアを持つノード

ノードの小規模なサブセットが特殊ハードウェア(GPU など) を持つクラスターでは、テイントおよび容認を使用して、特殊ハードウェアを必要としない Pod をそれらのノードから切り離し、特殊ハードウェアを必要とする Pod をそのままにすることができます。また、特殊ハードウェアを必要とする Pod に対して特定のノードを使用することを要求することもできます。

Pod が特殊ハードウェアからブロックされるようにするには、以下を実行します。

  1. 以下のコマンドのいずれかを使用して、特殊ハードウェアを持つノードにテイントを設定します。

    $ oc adm taint nodes <node-name> disktype=ssd:NoSchedule
    $ oc adm taint nodes <node-name> disktype=ssd:PreferNoSchedule
  2. 受付コントローラーを使用して特殊ハードウェアを使用する Pod に対応する容認を追加します。

たとえば受付コントローラーは容認を追加することで、Pod の一部の特徴を使用し、Pod が特殊ノードを使用できるかどうかを判別できます。

Pod が特殊ハードウェアのみを使用できるようにするには、追加のメカニズムが必要です。たとえば、特殊ハードウェアを持つノードにラベルを付け、ハードウェアを必要とする Pod でノードのアフィニティーを使用できます。

第15章 クォータの設定

15.1. 概要

ResourceQuota オブジェクトで定義されるリソースクォータは、プロジェクトごとにリソース消費量の総計を制限する制約を指定します。これは、タイプ別にプロジェクトで作成できるオブジェクトの数量を制限すると共に、そのプロジェクトのリソースが消費できるコンピュートリソースおよびストレージの合計量を制限することができます。

注記

コンピュートリソースについての詳細は、『Developer Guide』を参照してください。

15.2. クォータで管理されるリソース

以下では、クォータで管理できる一連のコンピュートリソースとオブジェクトタイプについて説明します。

注記

status.phase in (Failed, Succeeded) が true の場合、Pod は終了状態にあります。

表15.1 クォータで管理されるコンピュートリソース

リソース名説明

cpu

非終了状態のすべての Pod での CPU 要求の合計はこの値を超えることができません。cpu および requests.cpu は同じ値で、交換可能なものとして使用できます。

memory

非終了状態のすべての Pod でのメモリー要求の合計はこの値を超えることができません memory および requests.memory は同じ値で、交換可能なものとして使用できます。

requests.cpu

非終了状態のすべての Pod での CPU 要求の合計はこの値を超えることができません。cpu および requests.cpu は同じ値で、交換可能なものとして使用できます。

requests.memory

非終了状態のすべての Pod でのメモリー要求の合計はこの値を超えることができません memory および requests.memory は同じ値で、交換可能なものとして使用できます。

limits.cpu

非終了状態のすべての Pod での CPU 制限の合計はこの値を超えることができません。

limits.memory

非終了状態のすべての Pod でのメモリー制限の合計はこの値を超えることができません。

表15.2 クォータで管理されるストレージリソース

リソース名説明

requests.storage

任意の状態のすべての Persistent Volume Claim (永続ボリューム要求、PVC) でのストレージ要求の合計はこの値を超えることができません。

persistentvolumeclaims

プロジェクトに存在できる Persistent Volume Claim (永続ボリューム要求、PVC) の合計数です。

<storage-class-name>.storageclass.storage.k8s.io/requests.storage

一致するストレージクラスを持つ、任意の状態のすべての Persistent Volume Claim (永続ボリューム要求、PVC) でのストレージ要求の合計はこの値を超えることができません。

<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims

プロジェクトに存在できる、一致するストレージクラスを持つ Persistent Volume Claim (永続ボリューム要求、PVC) の合計数です。

表15.3 クォータで管理されるオブジェクト数

リソース名説明

pods

プロジェクトに存在できる非終了状態の Pod の合計数です。

replicationcontrollers

プロジェクトに存在できるレプリケーションコントローラーの合計数です。

resourcequotas

プロジェクトに存在できるリソースクォータの合計数です。

services

プロジェクトに存在できるサービスの合計数です。

secrets

プロジェクトに存在できるシークレットの合計数です。

configmaps

プロジェクトに存在できる ConfigMap オブジェクトの合計数です。

persistentvolumeclaims

プロジェクトに存在できる Persistent Volume Claim (永続ボリューム要求、PVC) の合計数です。

openshift.io/imagestreams

プロジェクトの存在できるイメージストリームの合計数です。

15.3. クォータのスコープ

各クォータには スコープ のセットが関連付けられます。クォータは、列挙されたスコープの交差部分に一致する場合にのみリソースの使用状況を測定します。

スコープをクォータに追加すると、クォータが適用されるリソースのセットを制限できます。許可されるセット以外のリソースを設定すると、検証エラーが発生します。

スコープ説明

Terminating

spec.activeDeadlineSeconds >= 0 の Pod に一致します。

NotTerminating

spec.activeDeadlineSecondsnil の Pod に一致します。

BestEffort

cpu または memory のいずれかの QoS (Quality of Service) が Best Effort の Pod に一致します。コンピュートリソースのコミットについての詳細は、「QoS (Quality of Service) クラス」を参照してください。

NotBestEffort

cpu および memory の QoS (Quality of Service) が Best Effort でない Pod に一致します。

BestEffort スコープは、以下のリソースを制限することにクォータを制限します。

  • pods

TerminatingNotTerminating、および NotBestEffort スコープは、以下のリソースを追跡することにクォータを制限します。

  • pods
  • memory
  • requests.memory
  • limits.memory
  • cpu
  • requests.cpu
  • limits.cpu

15.4. クォータの実施

プロジェクトのリソースクォータが最初に作成されると、プロジェクトは、更新された使用状況の統計が計算されるまでクォータの制約に違反する可能性のある新規リソースの作成機能を制限します。

クォータが作成され、使用状況の統計が更新されると、プロジェクトは新規コンテンツの作成を許可します。リソースを作成または変更する場合、クォータの使用量はリソースの作成または変更要求があるとすぐに増分します。

リソースを削除する場合、クォータの使用量は、プロジェクトのクォータ統計の次回の完全な再計算時に減分されます。設定可能な時間を指定して、クォータ使用量の統計値を現在確認されるシステム値まで下げるのに必要な時間を決定します。

プロジェクト変更がクォータ使用制限を超える場合、サーバーはそのアクションを拒否し、クォータ制約を違反していること、およびシステムで現在確認される使用量の統計値を示す適切なエラーメッセージがユーザーに返されます。

15.5. 要求 vs 制限

コンピュートリソースの割り当て時に、各コンテナーでは CPU とメモリーのそれぞれに要求値と制限値を指定できます。クォータはこれらの値を制限できます。

クォータに requests.cpu または requests.memory の値が指定されている場合、すべての着信コンテナーがそれらのリソースを明示的に要求することが求められます。クォータに limits.cpu または limits.memory の値が指定されている場合、すべての着信コンテナーがそれらのリソースの明示的な制限を指定することが求められます。

15.6. リソースクォータ定義のサンプル

core-object-counts.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: core-object-counts
spec:
  hard:
    configmaps: "10" 1
    persistentvolumeclaims: "4" 2
    replicationcontrollers: "20" 3
    secrets: "10" 4
    services: "10" 5

1
プロジェクトに存在できる ConfigMap オブジェクトの合計数です。
2
プロジェクトに存在できる Persistent Volume Claim (永続ボリューム要求、PVC) の合計数です。
3
プロジェクトに存在できるレプリケーションコントローラーの合計数です。
4
プロジェクトに存在できるシークレットの合計数です。
5
プロジェクトに存在できるサービスの合計数です。

openshift-object-counts.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: openshift-object-counts
spec:
  hard:
    openshift.io/imagestreams: "10" 1

1
プロジェクトの存在できるイメージストリームの合計数です。

compute-resources.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    pods: "4" 1
    requests.cpu: "1" 2
    requests.memory: 1Gi 3
    limits.cpu: "2" 4
    limits.memory: 2Gi 5

1
プロジェクトに存在できる非終了状態の Pod の合計数です。
2
非終了状態のすべての Pod において、CPU 要求の合計は 1 コアを超えることができません。
3
非終了状態のすべての Pod において、メモリー要求の合計は 1 Gi を超えることができません。
4
非終了状態のすべての Pod において、CPU 制限の合計は 2 コアを超えることができません。
5
非終了状態のすべての Pod において、メモリー制限の合計は 2 Gi を超えることができません。

besteffort.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: besteffort
spec:
  hard:
    pods: "1" 1
  scopes:
  - BestEffort 2

1
プロジェクトに存在できる QoS (Quality of Service) が BestEffort の非終了状態の Pod の合計数です。
2
クォータを、メモリーまたは CPU のいずれかの QoS (Quality of Service) が BestEffort の一致する Pod のみに制限します。

compute-resources-long-running.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources-long-running
spec:
  hard:
    pods: "4" 1
    limits.cpu: "4" 2
    limits.memory: "2Gi" 3
  scopes:
  - NotTerminating 4

1
非終了状態の Pod の合計数です。
2
非終了状態のすべての Pod において、CPU 制限の合計はこの値を超えることができません。
3
非終了状態のすべての Pod において、メモリー制限の合計はこの値を超えることができません。
4
クォータをspec.activeDeadlineSecondsnil に設定されている一致する Pod のみに制限します。ビルド Pod は、RestartNever ポリシーが適用されない場合に NotTerminating になります。

compute-resources-time-bound.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources-time-bound
spec:
  hard:
    pods: "2" 1
    limits.cpu: "1" 2
    limits.memory: "1Gi" 3
  scopes:
  - Terminating 4

1
非終了状態の Pod の合計数です。
2
非終了状態のすべての Pod において、CPU 制限の合計はこの値を超えることができません。
3
非終了状態のすべての Pod において、メモリー制限の合計はこの値を超えることができません。
4
クォータをspec.activeDeadlineSeconds >=0 に設定されている一致する Pod のみに制限します。たとえば、このクォータはビルド Pod またはデプロイヤー Pod に影響を与えますが、web サーバーまたはデータベースなどの長時間実行されない Pod には影響を与えません。

storage-consumption.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-consumption
spec:
  hard:
    persistentvolumeclaims: "10" 1
    requests.storage: "50Gi" 2
    gold.storageclass.storage.k8s.io/requests.storage: "10Gi" 3
    silver.storageclass.storage.k8s.io/requests.storage: "20Gi" 4
    silver.storageclass.storage.k8s.io/persistentvolumeclaims: "5" 5
    bronze.storageclass.storage.k8s.io/requests.storage: "0" 6
    bronze.storageclass.storage.k8s.io/persistentvolumeclaims: "0" 7

1
プロジェクト内の Persistent Volume Claim (永続ボリューム要求、PVC) の合計数です。
2
プロジェクトのすべての Persistent Volume Claim (永続ボリューム要求、PVC) において、要求されるストレージの合計はこの値を超えることができません。
3
プロジェクトのすべての Persistent Volume Claim (永続ボリューム要求、PVC) において、gold ストレージクラスで要求されるストレージの合計はこの値を超えることができません。
4
プロジェクトのすべての Persistent Volume Claim (永続ボリューム要求、PVC) において、silver ストレージクラスで要求されるストレージの合計はこの値を超えることができません。
5
プロジェクトのすべての Persistent Volume Claim (永続ボリューム要求、PVC) において、silver ストレージクラスの要求の合計数はこの値を超えることができません。
6
プロジェクトのすべての Persistent Volume Claim (永続ボリューム要求、PVC) において、bronze ストレージクラスで要求されるストレージの合計はこの値を超えることができません。これが 0 に設定される場合、bronze ストレージクラスはストレージを要求できないことを意味します。
7
プロジェクトのすべての Persistent Volume Claim (永続ボリューム要求、PVC) において、bronze ストレージクラスで要求されるストレージの合計はこの値を超えることができません。これが 0 に設定される場合は、bronze ストレージクラスでは要求を作成できないことを意味します。

15.7. クォータの作成

クォータを作成するには、「リソースクォータ定義のサンプル」に示されるように、まずクォータをファイルの仕様に基づいて定義します。次に、そのファイルを使用してこれをプロジェクトに適用します。

$ oc create -f <resource_quota_definition> [-n <project_name>]

以下に例を示します。

$ oc create -f resource-quota.json -n demoproject

15.8. クォータの表示

web コンソールでプロジェクトの Quota ページに移動し、プロジェクトのクォータで定義されるハード制限に関連する使用状況の統計を表示できます。

CLI を使用してクォータの詳細を表示することもできます。

  1. 最初に、プロジェクトで定義されたクォータの一覧を取得します。たとえば、demoproject というプロジェクトの場合、以下を実行します。

    $ oc get quota -n demoproject
    NAME                AGE
    besteffort          11m
    compute-resources   2m
    core-object-counts  29m
  2. 次に、関連するクォータについての説明を表示します。たとえば、core-object-counts クォータの場合は、以下のようになります。

    $ oc describe quota core-object-counts -n demoproject
    Name:			core-object-counts
    Namespace:		demoproject
    Resource		Used	Hard
    --------		----	----
    configmaps		3	10
    persistentvolumeclaims	0	4
    replicationcontrollers	3	20
    secrets			9	10
    services		2	10

15.9. クォータの同期期間の設定

リソースのセットが削除される際に、リソースの同期期間が /etc/origin/master/master-config.yaml ファイルの resource-quota-sync-period 設定によって決定されます。

クォータの使用状況が復元される前に、ユーザーがリソースの再使用を試行すると問題が発生する場合があります。resource-quota-sync-period 設定を変更して、リソースセットの再生成が所定の期間 (秒単位) に実行され、リソースを再度利用可能にすることができます。

kubernetesMasterConfig:
  apiLevels:
  - v1beta3
  - v1
  apiServerArguments: null
  controllerArguments:
    resource-quota-sync-period:
      - "10s"

変更後に、マスターサービスを再起動してそれらの変更を適用します。

# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers

再生成時間の調整は、リソースの作成および自動化が使用される場合のリソース使用状況の判別に役立ちます。

注記

resource-quota-sync-period 設定は、システムパフォーマンスのバランスを取るように設計されています。同期期間を短縮すると、マスターに大きな負荷がかかる可能性があります。

15.10. デプロイメント設定におけるクォータアカウンティング

クォータがプロジェクトに定義されている場合、デプロイメント設定の考慮事項については、「デプロイメントリソース」を参照してください。

15.11. リソース消費における明示的なクォータの要求

リソースがクォータで管理されていない場合、ユーザーには消費できるリソース量の制限がありません。たとえば、gold ストレージクラスに関連するストレージのクォータがない場合、プロジェクトが作成できる gold ストレージの容量はバインドされません。

高コストのコンピュートまたはストレージリソースの場合、管理者はリソースを消費するための明示的なクォータの付与が必要となるようにする場合があります。たとえば、プロジェクトに gold ストレージクラスに関連するストレージのクォータが明示的に付与されていない場合、そのプロジェクトのユーザーはこのタイプのストレージを作成することができません。

特定リソースの消費における明示的なクォータが必要となるようにするには、以下のスタンザを master-config.yaml に追加する必要があります。

admissionConfig:
  pluginConfig:
    ResourceQuota:
      configuration:
        apiVersion: resourcequota.admission.k8s.io/v1alpha1
        kind: Configuration
        limitedResources:
        - resource: persistentvolumeclaims 1
          matchContains:
        - gold.storageclass.storage.k8s.io/requests.storage 2
1
デフォルトで消費が制限されるグループ/リソースです。
2
デフォルトで制限対象となる、グループ/リソースに関連付けられたクォータで追跡されるリソースの名前です。

上記の例では、クォータシステムは PersistentVolumeClaim を作成するか、または更新するすべての操作をインターセプトします。これは、クォータで認識されるリソースが消費されることを確認し、プロジェクトのそれらのリソースのクォータがない場合に要求は拒否されます。この例ではユーザーが gold ストレージクラスに関連付けられたストレージを使用する PersistentVolumeClaim を作成しており、プロジェクトに一致するクォータがない場合には要求が拒否されます。

第16章 複数プロジェクトのクォータ設定

16.1. 概要

ClusterResourceQuota オブジェクトで定義される複数プロジェクトのクォータは、クォータを複数プロジェクト間で共有できるようにします。それぞれの選択されたプロジェクトで使用されるリソースは集計され、その集計は選択したすべてのプロジェクトでリソースを制限するために使用されます。

16.2. プロジェクトの選択

プロジェクトは、アノテーションの選択またはラベルの選択のいずれか、またはその両方に基づいて選択できます。たとえば、アノテーションに基づいてプロジェクトを選択するには、以下のコマンドを実行します。

$ oc create clusterquota for-user \
     --project-annotation-selector openshift.io/requester=<user-name> \
     --hard pods=10 \
     --hard secrets=20

これは以下の ClusterResourceQuota オブジェクトを作成します。

apiVersion: v1
kind: ClusterResourceQuota
metadata:
  name: for-user
spec:
  quota: 1
    hard:
      pods: "10"
      secrets: "20"
  selector:
    annotations: 2
      openshift.io/requester: <user-name>
    labels: null 3
status:
  namespaces: 4
  - namespace: ns-one
    status:
      hard:
        pods: "10"
        secrets: "20"
      used:
        pods: "1"
        secrets: "9"
  total: 5
    hard:
      pods: "10"
      secrets: "20"
    used:
      pods: "1"
      secrets: "9"
1
選択したプロジェクトに対して実施される ResourceQuotaSpec オブジェクトです。
2
アノテーションの単純なキー/値のセレクターです。
3
プロジェクトを選択するために使用できるラベルセレクターです。
4
選択された各プロジェクトの現在のクォータの使用状況を記述する namespace ごとのマップです。
5
選択されたすべてのプロジェクトにおける使用量の総計です。

この複数プロジェクトのクォータの記述は、デフォルトのプロジェクト要求エンドポイントを使用して <user-name> によって要求されるすべてのプロジェクトを制御します。ここでは、10 Pod および 20 シークレットに制限されます。

同様にラベルに基づいてプロジェクトを選択するには、以下のコマンドを実行します。

$  oc create clusterresourcequota for-name \ 1
    --project-label-selector=name=frontend \ 2
    --hard=pods=10 --hard=secrets=20
1
clusterresourcequota および clusterquota は同じコマンドのエイリアスです。for-nameclusterresourcequota オブジェクトの名前です。
2
ラベル別にプロジェクトを選択するには、--project-label-selector=key=value 形式を使用してキーと値のペアを指定します。

これは以下の ClusterResourceQuota オブジェクト定義を作成します。

apiVersion: v1
kind: ClusterResourceQuota
metadata:
  creationTimestamp: null
  name: for-name
spec:
  quota:
    hard:
      pods: "10"
      secrets: "20"
  selector:
    annotations: null
    labels:
      matchLabels:
        name: frontend

16.3. 適用可能な ClusterResourceQuotas の表示

プロジェクト管理者は、各自のプロジェクトを制限する複数プロジェクトのクォータを作成したり、変更したりすることはできませんが、それぞれのプロジェクトに適用される複数プロジェクトのクォータを表示することはできます。プロジェクト管理者は、AppliedClusterResourceQuota リソースを使ってこれを実行できます。

$ oc describe AppliedClusterResourceQuota

以下が生成されます。

Name:   for-user
Namespace:  <none>
Created:  19 hours ago
Labels:   <none>
Annotations:  <none>
Label Selector: <null>
AnnotationSelector: map[openshift.io/requester:<user-name>]
Resource  Used  Hard
--------  ----  ----
pods        1     10
secrets     9     20

16.4. 選択における粒度

クォータの割り当てを要求する際にロックに関して考慮する必要があるため、複数プロジェクトのクォータで選択されるアクティブなプロジェクトの数は重要な考慮点になります。単一の複数プロジェクトクォータで 100 を超えるプロジェクトを選択すると、それらのプロジェクトの API サーバーの応答に負の影響が及びます。

第17章 制限範囲の設定

17.1. 概要

LimitRange オブジェクトで定義される制限範囲は、Pod、コンテナー、イメージ、イメージストリーム、および Persistent Volume Claim (永続ボリューム要求、PVC) のレベルでプロジェクトコンピュートリソース制約を列挙し、Pod、コンテナー、イメージ、イメージストリームまたは Persistent Volume Claim (永続ボリューム要求、PVC) で消費できるリソースの量を指定します。

すべてのリソース作成および変更要求は、プロジェクトの各 LimitRange オブジェクトに対して評価されます。リソースが列挙された制約のいずれかに違反する場合、リソースは拒否されます。リソースが明示的な値を指定しない場合で、制約がデフォルト値をサポートする場合は、デフォルト値がリソースに適用されます。

コア Limit Range オブジェクトの定義

apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "core-resource-limits" 1
spec:
  limits:
    - type: "Pod"
      max:
        cpu: "2" 2
        memory: "1Gi" 3
      min:
        cpu: "200m" 4
        memory: "6Mi" 5
    - type: "Container"
      max:
        cpu: "2" 6
        memory: "1Gi" 7
      min:
        cpu: "100m" 8
        memory: "4Mi" 9
      default:
        cpu: "300m" 10
        memory: "200Mi" 11
      defaultRequest:
        cpu: "200m" 12
        memory: "100Mi" 13
      maxLimitRequestRatio:
        cpu: "10" 14

1
制限範囲オブジェクトの名前です。
2
すべてのコンテナーにおいて Pod がノードで要求できる CPU の最大量です。
3
すべてのコンテナーにおいて Pod がノードで要求できるメモリーの最大量です。
4
すべてのコンテナーにおいて Pod がノードで要求できる CPU の最小量です。
5
すべてのコンテナーにおいて Pod がノードで要求できるメモリーの最小量です。
6
Pod の単一コンテナーが要求できる CPU の最大量です。
7
Pod の単一コンテナーが要求できるメモリーの最大量です。
8
Pod の単一コンテナーが要求できる CPU の最小量です。
9
Pod の単一コンテナーが要求できるメモリーの最小量です。
10
指定されない場合にコンテナーによる使用制限となる CPU のデフォルト量です。
11
指定されない場合にコンテナーによる使用制限となるメモリーのデフォルト量です。
12
指定されない場合にコンテナーによる要求制限となる CPU のデフォルト量です。
13
指定されない場合にコンテナーの要求制限となるメモリーのデフォルト量です。
14
制限の要求に対する比率でコンテナーで実行できる CPU バーストの最大量です。

CPU およびメモリーの測定方法についての詳細は、「コンピュートリソース」を参照してください。

OpenShift Container Platform の Limit Range オブジェクトの定義

apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "openshift-resource-limits"
spec:
  limits:
    - type: openshift.io/Image
      max:
        storage: 1Gi 1
    - type: openshift.io/ImageStream
      max:
        openshift.io/image-tags: 20 2
        openshift.io/images: 30 3

1
内部レジストリーにプッシュできるイメージの最大サイズです。
2
イメージストリームの仕様に基づく一意のイメージタグの最大数です。
3
イメージストリームのステータスに基づく一意のイメージ参照の最大数です。

コアおよび OpenShift Container Platform リソースのどちらも単一の制限範囲オブジェクトで指定できます。ここでは明確にする目的でこれらを 2 つのサンプルに分けています。

17.1.1. コンテナーの制限

サポートされるリソース:

  • CPU
  • メモリー

サポートされる制約:

コンテナーごとに設定されます。指定される場合、以下が一致している必要があります。

表17.1 コンテナー

制約動作

Min

Min[resource]: container.resources.requests[resource] (必須) または container/resources.limits[resource] (オプション) より小さいか等しい

設定で min CPU を定義している場合、要求値はその CPU 値よりも大きくなければなりません。制限値を指定する必要はありません。

Max

container.resources.limits[resource] (必須): Max[resource] より小さいか等しい

設定で max CPU を定義している場合、要求値を定義する必要はありませんが、CPU 制約の最大値の条件を満たす制限値を設定する必要があります。

MaxLimitRequestRatio

MaxLimitRequestRatio[resource]: ( container.resources.limits[resource] / container.resources.requests[resource]) より小さいか等しい

設定で maxLimitRequestRatio 値を定義している場合、新規コンテナーには要求値および制限値の両方が必要になります。さらに OpenShift Container Platform は、制限を要求で除算して制限の要求に対する比率を算出します。

たとえば、コンテナーのlimit 値が cpu: 500 で、request 値が cpu: 100 である場合、cpu の要求に対する制限の比は 5 になります。この比率は maxLimitRequestRatio より小さいか等しくなければなりません。

サポートされるデフォルト:

Default[resource]
指定がない場合は container.resources.limit[resource] を所定の値にデフォルト設定します。
Default Requests[resource]
指定がない場合は、container.resources.requests[resource] を所定の値にデフォルト設定します。

17.1.2. Pod の制限

サポートされるリソース:

  • CPU
  • メモリー

サポートされる制約:

Pod のすべてのコンテナーにおいて、以下が一致している必要があります。

表17.2 Pod

制約実施される動作

Min

Min[resource]: container.resources.requests[resource] (必須) または container.resources.limits[resource] (オプション) より小さいか等しい

Max

container.resources.limits[resource] (必須): Max[resource] より小さいか等しい

MaxLimitRequestRatio

MaxLimitRequestRatio[resource]: ( container.resources.limits[resource] / container.resources.requests[resource]) より小さいか等しい

17.1.3. イメージの制限

サポートされるリソース:

  • ストレージ

リソースタイプ名:

  • openshift.io/Image

イメージごとに設定されます。指定される場合、以下が一致している必要があります。

表17.3 イメージ

制約動作

Max

image.dockerimagemetadata.size: Max[resource] より小さいか等しい

注記

制限を超える Blob がレジストリーにアップロードされないようにするために、クォータを実施するようレジストリーを設定する必要があります。環境変数 REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ENFORCEQUOTAtrue に設定される必要があります。この設定は、新規デプロイメントについてデフォルトで実行されます。古いデプロイメント設定を更新するには、「Enforcing quota in the Registry」を参照してください。

警告

イメージのサイズは、アップロードされるイメージのマニフェストで常に表示される訳ではありません。これは、とりわけ Docker 1.10 以上で作成され、v2 レジストリーにプッシュされたイメージの場合に該当します。このようなイメージが古い Docker デーモンでプルされると、イメージマニフェストはレジストリーによってスキーマ v1 に変換されますが、この場合サイズ情報が欠落します。イメージに設定されるストレージの制限がこのアップロードを防ぐことはありません。

現在、この問題への対応が行われています。

17.1.4. イメージストリームの制限

サポートされるリソース:

  • openshift.io/image-tags
  • openshift.io/images

リソースタイプ名:

  • openshift.io/ImageStream

イメージストリームごとに設定されます。指定される場合、以下が一致している必要があります。

表17.4 ImageStream

制約動作

Max[openshift.io/image-tags]

length( uniqueimagetags( imagestream.spec.tags ) ): Max[openshift.io/image-tags] より小さいか等しい

uniqueimagetags は、指定された仕様タグのイメージへの一意の参照を返します。

Max[openshift.io/images]

length( uniqueimages( imagestream.status.tags ) ): Max[openshift.io/images] より小さいか等しい

uniqueimages はステータスタグにある一意のイメージ名を返します。名前はイメージのダイジェストに等しくなります。

17.1.4.1. イメージ参照の数

リソース openshift.io/image-tags は、一意のイメージ参照を表します。使用できる参照は、ImageStreamTagImageStreamImage および DockerImage になります。それらは oc tag および oc import-image コマンドを使用するか、または タグのトラッキングを使用して作成されます。内部参照か外部参照であるかの区別はありませんが、イメージストリームの仕様でタグ付けされる一意の参照はそれぞれ 1 回のみカウントされます。この参照は内部コンテナーレジストリーへのプッシュを制限することはありませんが、タグの制限に役立ちます。

リソース openshift.io/images は、イメージストリームのステータスに記録される一意のイメージ名を表します。これにより、内部レジストリーにプッシュできるイメージ数を制限できます。内部参照か外部参照であるかの区別はありません。

17.1.5. PersistentVolumeClaim の制限

サポートされるリソース:

  • ストレージ

サポートされる制約:

プロジェクトのすべての Persistent Volume Claim (永続ボリューム要求、PVC) において、以下が一致している必要があります。

表17.5 Pod

制約実施される動作

Min

Min[resource] ⇐ claim.spec.resources.requests[resource] (必須)

Max

claim.spec.resources.requests[resource] (必須) ⇐ Max[resource]

Limit Range オブジェクトの定義

{
  "apiVersion": "v1",
  "kind": "LimitRange",
  "metadata": {
    "name": "pvcs" 1
  },
  "spec": {
    "limits": [{
        "type": "PersistentVolumeClaim",
        "min": {
          "storage": "2Gi" 2
        },
        "max": {
          "storage": "50Gi" 3
        }
      }
    ]
  }
}

1
制限範囲オブジェクトの名前です。
2
Persistent Volume Claim (永続ボリューム要求、PVC) で要求できるストレージの最小量です。
3
Persistent Volume Claim (永続ボリューム要求、PVC) で要求できるストレージの最大量です。

17.2. 制限範囲の作成

制限範囲をプロジェクトに適用するには、必要な仕様に基づいてファイルシステムで制限範囲オブジェクトの定義を作成します。以下を実行します。

$ oc create -f <limit_range_file> -n <project>

17.3. 制限の表示

web コンソールでプロジェクトの Quota ページに移動し、プロジェクトで定義される制限範囲を表示できます。

CLI を仕様して制限範囲の詳細を表示することもできます。

  1. まず、プロジェクトで定義される制限範囲の一覧を取得します。たとえば、demoproject というプロジェクトの場合は以下のようになります。

    $ oc get limits -n demoproject
    NAME              AGE
    resource-limits   6d
  2. 次に、関連のある制限範囲の説明を表示します。たとえば、resource-limits 制限範囲の場合は以下のようになります。

    $ oc describe limits resource-limits -n demoproject
    Name:                           resource-limits
    Namespace:                      demoproject
    Type                            Resource                Min     Max     Default Request Default Limit   Max Limit/Request Ratio
    ----                            --------                ---     ---     --------------- -------------   -----------------------
    Pod                             cpu                     200m    2       -               -               -
    Pod                             memory                  6Mi     1Gi     -               -               -
    Container                       cpu                     100m    2       200m            300m            10
    Container                       memory                  4Mi     1Gi     100Mi           200Mi           -
    openshift.io/Image              storage                 -       1Gi     -               -               -
    openshift.io/ImageStream        openshift.io/image      -       12      -               -               -
    openshift.io/ImageStream        openshift.io/image-tags -       10      -               -               -

17.4. 制限の削除

プロジェクトの制限を実施しないように有効な制限範囲を削除します。

$ oc delete limits <limit_name>

第18章 オブジェクトのプルーニング

18.1. 概要

OpenShift Container Platform で作成される API オブジェクトは、一定期間が経過すると、アプリケーションのビルドやデプロイなどの通常のユーザー操作によって etcd データストアに蓄積されます。

管理者は、不要になった古いバージョンのオブジェクトを OpenShift Container Platform インスタンスから定期的にプルーニングできます。たとえば、イメージのプルーニングにより、使用されなくなったものの、ディスク領域を使用している古いイメージや層を削除できます。

18.2. プルーニングの基本操作

CLI は、共通の親コマンドでプルーニング操作を分類します。

$ oc adm prune <object_type> <options>

これにより、以下が指定されます。

  • buildsdeployments、または images などのアクションを実行するための <object_type> です。
  • オブジェクトタイプのプルーニングの実行においてサポートされる <options> です。

18.3. デプロイメントのプルーニング

使用年数やステータスによりシステムで不要となったデプロイメントをプルーニングするために、管理者は以下のコマンドを実行できます。

$ oc adm prune deployments [<options>]

表18.1 デプロイメントのプルーニング用の CLI の設定オプション

オプション説明

--confirm

ドライランの実行ではなく、プルーニングが実行されることを示します。

--orphans

デプロイメント設定が存在せず、ステータスが complete (完了) または failed (失敗) で、レプリカ数がゼロであるすべてのデプロイメントをプルーニングします。

--keep-complete=<N>

デプロイメント設定に基づき、ステータスが complete (完了) で、レプリカ数がゼロである最後の N デプロイメントを保持します (デフォルト: 5)。

--keep-failed=<N>

デプロイメント設定に基づき、ステータスが failed (失敗) で、レプリカ数がゼロである最後の N デプロイメントを保持します (デフォルト: 1)。

--keep-younger-than=<duration>

現在の時間との対比で <duration> 未満の新しいオブジェクトはプルーニングしません (デフォルト: 60m)。有効な測定単位には、ナノ秒 (ns)、マイクロ秒 (us)、ミリ秒 (ms)、秒 (s)、分 (m)、および時間 (h) が含まれます。

プルーニング操作によって削除されるものを確認するには、以下を実行します。

$ oc adm prune deployments --orphans --keep-complete=5 --keep-failed=1 \
    --keep-younger-than=60m

プルーニング操作を実際に実行するには、以下を実行します。

$ oc adm prune deployments --orphans --keep-complete=5 --keep-failed=1 \
    --keep-younger-than=60m --confirm

18.4. ビルドのプルーニング

使用年数やステータスによりシステムで不要となったビルドをプルーニングするために、管理者は以下のコマンドを実行できます。

$ oc adm prune builds [<options>]

表18.2 ビルドのプルーニング用の CLI の設定オプション

オプション説明

--confirm

ドライランの実行ではなく、プルーニングが実行されることを示します。

--orphans

ビルド設定が存在せず、ステータスが complete (完了)、failed (失敗)、error (エラー)、または canceled (中止) のすべてのビルドをプルーニングします。

--keep-complete=<N>

ビルド設定に基づき、ステータスが complete (完了) の最後の N ビルドを保持します (デフォルト: 5)。

--keep-failed=<N>

ビルド設定に基づき、ステータスが failed (失敗)、error (エラー)、または canceled (中止) の最後の N ビルドを保持します (デフォルト: 1)。

--keep-younger-than=<duration>

現在の時間との対比で <duration> 未満の新しいオブジェクトはプルーニングしません (デフォルト: 60m)。

プルーニング操作によって削除されるものを確認するには、以下を実行します。

$ oc adm prune builds --orphans --keep-complete=5 --keep-failed=1 \
    --keep-younger-than=60m

プルーニング操作を実際に実行するには、以下を実行します。

$ oc adm prune builds --orphans --keep-complete=5 --keep-failed=1 \
    --keep-younger-than=60m --confirm
注記

開発者は、ビルド設定を変更することにより、自動ビルドプルーニングを有効にできます。

18.5. イメージのプルーニング

使用年数やステータスまたは制限の超過によりシステムで不要となったイメージをプルーニングするために、管理者は以下のコマンドを実行できます。

$ oc adm prune images [<options>]
注記

現時点でイメージをプルーニングするには、まず アクセストークンを使ってユーザーとして CLI にログインする必要があります。また、ユーザーにはクラスターロール(system:image-pruner) 以上のロールがなければなりません (例: cluster-admin)。

注記

--prune-registry=false が使用されていない限り、イメージのプルーニングにより、統合レジストリーのデータが削除されます。この操作が適切に機能するには、storage:delete:enabledtrue に設定された状態での レジストリーの設定を確認します。

注記

--namespace フラグの付いたイメージをプルーニングしてもイメージは削除されず、イメージストリームのみが削除されます。イメージは namespace を使用しないリソースです。そのため、プルーニングを特定の namespace に制限すると、イメージの現在の使用量を算出できなくなります。

デフォルトで、統合レジストリーは Blob メタデータをキャッシュしてストレージに対する要求数を減らし、要求の処理速度を高めます。プルーニングによって統合レジストリーのキャッシュが更新されることはありません。プルーニング後にプッシュされる、プルーニングされた層を含むイメージは破損します。キャッシュにメタデータを持つプルーニングされた層はプッシュされないためです。したがって、プルーニング後はキャッシュをクリアする必要があります。これは、レジストリーの再デプロイによって実行できます。

$ oc rollout latest dc/docker-registry

統合レジストリーが Redis キャッシュを使用する場合は、データベースを手動でクリーンアップする必要があります。

プルーニング後にレジストリーを再デプロイするオプションを実行できない場合は、キャッシュを永久に無効にする必要があります。

表18.3 イメージのプルーニング用の CLI の設定オプション

オプション説明

--all

レジストリーにプッシュされていないものの、プルスルー (pullthrough) でミラーリングされたイメージを組み込みます。これはデフォルトでオンに設定されます。プルーニングを統合レジストリーにプッシュされたイメージに制限するには、--all=false を渡します。

--certificate-authority

OpenShift Container Platform で管理されるレジストリーと通信する際に使用する認証局ファイルへのパスです。デフォルトは現行ユーザーの設定ファイルの認証局データに設定されます。これが指定されている場合、セキュアな通信が実行されます。

--confirm

ドライランを実行する代わりにプルーニングが実行されることを示します。これには、統合 Docker レジストリーへの有効なルートが必要になります。このコマンドがクラスターネットワーク外で実行される場合、ルートは --registry-url を使用して指定される必要があります。

--force-insecure

このオプションは注意して使用してください。 HTTP 経由でホストされているか、または無効な HTTPS 証明書を持つ Docker レジストリーへの非セキュアな接続を許可します。詳細は、「セキュアまたは非セキュアな接続の使用」を参照してください。

--keep-tag-revisions=<N>

それぞれのイメージストリームについては、タグごとに最大 N のイメージリビジョンを保持します (デフォルト: 3)。

--keep-younger-than=<duration>

現在の時間との対比で <duration> 未満の新しいイメージはプルーニングしません。現在の時間との対比で <duration> 未満の他のオブジェクトで参照されるイメージはプルーニングしません (デフォルト: 60m)。

--prune-over-size-limit

同じプロジェクトに定義される最小の制限を超える各イメージをプルーニングします。このフラグは --keep-tag-revisions または --keep-younger-than と共に使用することはできません。

--registry-url

レジストリーと通信する際に使用するアドレスです。このコマンドは、管理されるイメージおよびイメージストリームから判別されるクラスター内の URL の使用を試行します。これに失敗する (レジストリーを解決できないか、これにアクセスできない) 場合、このフラグを使用して他の機能するルートを指定する必要があります。レジストリーのホスト名の前には、特定の接続プロトコルを実施する https:// または http:// を付けることができます。

--prune-registry

他のオプションで規定される条件と共に、このオプションは、OpenShift Container Platform イメージ API オブジェクトに対応するレジストリーのデータがプルーニングされるかどうかを制御します。デフォルトで、イメージのプルーニングは、イメージ API オブジェクトとレジストリーの対応するデータの両方を処理します。このオプションは、イメージオブジェクトの数を減らすなどの目的で etcd の内容のみを削除することを検討していて、レジストリーのストレージのクリーンアップは検討していない場合や、レジストリーの適切なメンテナンス期間中などに レジストリーのハードプルーニングによってこれを別途実行しようとする場合に役立ちます。

18.5.1. イメージのプルーニングの各種条件

  • --keep-younger-than 分前よりも後に作成され、現時点で以下によって参照されていない「OpenShift Container Platform で管理される」イメージ (アノテーション openshift.io/image.managed を持つイメージ) を削除します。

    • --keep-younger-than 分前よりも後に作成された Pod。
    • --keep-younger-than 分前よりも後に作成されたイメージストリーム。
    • 実行中の Pod。
    • 保留中の Pod。
    • レプリケーションコントローラー。
    • デプロイメント設定。
    • ビルド設定。
    • ビルド。
    • stream.status.tags[].items--keep-tag-revisions の最新のアイテム。
  • 同じプロジェクトで定義される最小の制限を超えており、現時点で以下によって参照されていない「OpenShift Container Platform で管理される」イメージ (アノテーション openshift.io/image.managed を持つイメージ) を削除します。

    • 実行中の Pod。
    • 保留中の Pod。
    • レプリケーションコントローラー。
    • デプロイメント設定。
    • ビルド設定。
    • ビルド。
  • 外部レジストリーからのプルーニングはサポートされていません。
  • イメージがプルーニングされる際、イメージのすべての参照は status.tags にイメージの参照を持つすべてのイメージストリームから削除されます。
  • イメージによって参照されなくなったイメージ層も削除されます。
注記

--prune-over-size-limit--keep-tag-revisions または --keep-younger-than フラグと共に使用することができません。これを実行すると、この操作が許可されないことを示す情報が返されます。

注記

--prune-registry=false とその後に レジストリーのハードプルーニング を実行することで、OpenShift Container Platform イメージ API オブジェクトの削除とイメージデータのレジストリーからの削除を分離することができます。これによりタイミングウィンドウが制限され、1 つのコマンドで両方をプルーニングする場合よりも安全に実行できるようになります。ただし、タイミングウィンドウを完全に取り除くことはできません。

たとえばプルーニングの実行時にプルーニング対象のイメージを特定する場合も、そのイメージを参照する Pod を引き続き作成することができます。また、プルーニングの操作時にイメージを参照している可能性のある API オブジェクトを追跡することもできます。これにより、削除されたコンテンツの参照に関連して発生する可能性のある問題を軽減することができます。

また、--prune-registry オプションを指定しないか、または --prune-registry=true を指定してプルーニングを再実行しても、--prune-registry=false を指定して以前にプルーニングされたイメージの、イメージレジストリー内で関連付けられたストレージがプルーニングされる訳ではないことに注意してください。--prune-registry=false を指定してプルーニングされたすべてのイメージは、レジストリーのハードプルーニングによってのみ削除できます。

プルーニング操作によって削除されるものを確認するには、以下を実行します。

  1. 最高 3 つのタグリビジョンを保持し、6 分前よりも後に作成されたリソース (イメージ、イメージストリームおよび Pod) を保持します。

    $ oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m
  2. 定義された制限を超えるすべてのイメージをプルーニングします。

    $ oc adm prune images --prune-over-size-limit

前述のオプションでプルーニング操作を実際に実行するには、以下を実行します。

$ oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m --confirm

$ oc adm prune images --prune-over-size-limit --confirm

18.5.2. セキュアまたは非セキュアな接続の使用

セキュアな通信の使用は優先され、推奨される方法です。これは、必須の証明書検証と共に HTTPS 経由で実行されます。prune コマンドは、可能な場合は常にセキュアな通信の使用を試行します。これを使用できない場合には、非セキュアな通信にフォールバックすることがあり、これには危険が伴います。この場合、証明書検証は省略されるか、または単純な HTTP プロトコルが使用されます。

非セキュアな通信へのフォールバックは、--certificate-authority が指定されていない場合、以下のケースで可能になります。

  1. prune コマンドが --force-insecure オプションと共に実行される。
  2. 指定される registry-url の前に http:// スキームが付けられる。
  3. 指定される registry-url がローカルリンクアドレスまたは localhost である。
  4. 現行ユーザーの設定が非セキュアな接続を許可する。これは、ユーザーが --insecure-skip-tls-verify を使用してログインするか、またはプロンプトが出される際に非セキュアな接続を選択することによって生じる可能性があります。
重要

レジストリーのセキュリティーが、OpenShift Container Platform で使用されるものとは異なる認証局で保護される場合、これを --certificate-authority フラグを使用して指定する必要があります。そうしないと、prune コマンドは、「正しくない認証局の使用」または「セキュリティーが保護されたレジストリーに対する非セキュアな接続の使用」で一覧表示されているエラーと同様のエラーを出して失敗します。

18.5.3. イメージのプルーニングに関する問題

イメージがプルーニングされない

イメージが蓄積し続け、prune コマンドが予想よりも小規模な削除を実行する場合、プルーニング候補のイメージについて満たすべき条件があることを確認します。

とくに削除する必要のあるイメージが、それぞれのタグ履歴において選択したタグリビジョンのしきい値よりも高い位置にあることを確認します。たとえば、sha:abz という名前の古く陳腐化したイメージがあるとします。イメージがタグ付けされている namespace N で以下のコマンドを実行すると、イメージが myapp という単一イメージストリームで 3 回タグ付けされていることに気づかれるでしょう。

$ image_name="sha:abz"
$ oc get is -n N -o go-template='{{range $isi, $is := .items}}{{range $ti, $tag := $is.status.tags}}'\
  '{{range $ii, $item := $tag.items}}{{if eq $item.image "'"${image_name}"\
  $'"}}{{$is.metadata.name}}:{{$tag.tag}} at position {{$ii}} out of {{len $tag.items}}\n'\
  '{{end}}{{end}}{{end}}{{end}}'
myapp:v2 at position 4 out of 5
myapp:v2.1 at position 2 out of 2
myapp:v2.1-may-2016 at position 0 out of 1

デフォルトオプションが使用される場合、イメージは myapp:v2.1-may-2016 タグの履歴の 0 の位置にあるためプルーニングされません。イメージがプルーニングの対象と見なされるようにするには、管理者は以下を実行する必要があります。

  1. oc adm prune images コマンドで --keep-tag-revisions=0 を指定します。

    注意

    このアクションを実行すると、イメージが指定されたしきい値よりも新しいか、またはこれよりも新しいオブジェクトによって参照されていない限り、すべてのタグが基礎となるイメージと共にすべての namespace から削除されます。

  2. リビジョンのしきい値より下にあるすべての istag、つまり myapp:v2.1 および myapp:v2.1-may-2016 を削除します。
  3. 同じ istag にプッシュする新規ビルドを実行するか、または他のイメージをタグ付けしてイメージを履歴内でさらに移動させます。ただし、これは古いリリースタグの場合には常に適切な操作となる訳ではありません。

特定のイメージのビルド日時が名前の一部になっているタグは、その使用を避ける必要があります (イメージが未定義の期間保持される必要がある場合を除きます)。このようなタグは履歴内で 1 つのイメージのみに関連付けられる可能性があり、その場合にこれらをプルーニングできなくなります。詳細は、istag の命名規則を参照してください。

非セキュアなレジストリーに対するセキュアな接続の使用

oc adm prune images の出力で以下のようなメッセージが表示される場合、レジストリーのセキュリティーは保護されておらず、oc adm prune images クライアントがセキュアな接続の使用を試行することを示しています。

error: error communicating with registry: Get https://172.30.30.30:5000/healthz: http: server gave HTTP response to HTTPS client
  1. 推奨される解決法として、レジストリーのセキュリティーを保護することができます。これが必要でない場合には、--force-insecure をコマンドに追加して、クライアントが非セキュアな接続の使用を強制することができます (推奨される方法ではありません)

18.5.3.1. セキュリティーが保護されたレジストリーに対する非セキュアな接続の使用

oc adm prune images コマンドの出力に以下のエラーのいずれかが表示される場合、レジストリーのセキュリティー保護に使用されている認証局で署名された証明書が、接続の検証用に oc adm prune images クライアントで使用されるものとは異なることを意味します。

error: error communicating with registry: Get http://172.30.30.30:5000/healthz: malformed HTTP response "\x15\x03\x01\x00\x02\x02"
error: error communicating with registry: [Get https://172.30.30.30:5000/healthz: x509: certificate signed by unknown authority, Get http://172.30.30.30:5000/healthz: malformed HTTP response "\x15\x03\x01\x00\x02\x02"]

デフォルトでは、ユーザーの接続ファイルに保存されている認証局データが使用されます。これはマスター API との通信の場合も同様です。

--certificate-authority オプションを使用して Docker レジストリーサーバーに適切な認証局を指定します。

正しくない認証局の使用

以下のエラーは、セキュリティーが保護された Docker レジストリーの証明書の署名に使用される認証局がクライアントで使用される認証局とは異なることを示しています。

error: error communicating with registry: Get https://172.30.30.30:5000/: x509: certificate signed by unknown authority

フラグ --certificate-authority を使用して適切な認証局を指定します。

回避策として、--force-insecure フラグを代わりに追加することもできます (推奨される方法ではありません)

18.6. レジストリーのハードプルーニング

OpenShift Container レジストリーは、OpenShift Container Platform クラスターの etcd で参照されない Blob を蓄積します。基本的なイメージプルーニングの手順はこれらに対応しません。これらの Blob は 孤立した Blob と呼ばれています。

孤立した Blob は以下のシナリオで発生する可能性があります。

  • oc delete image <sha256:image-id> コマンドを使ってイメージを手動で削除すると、etcd のイメージのみが削除され、レジストリーのストレージからは削除されない。
  • docker デーモンの障害によって生じるレジストリーへのプッシュにより、一部の Blob はアップロードされるものの、(最後のコンポーネントとしてアップロードされる) イメージマニフェスト はアップロードされない。固有のイメージ Blob すべては孤立する。
  • OpenShift Container Platform がクォータの制限によりイメージを拒否する。
  • 標準のイメージプルーナーがイメージマニフェストを削除するが、関連する Blob を削除する前に中断される。
  • 対象の Blob を削除できないというレジストリープルーナーのバグにより、それらを参照するイメージオブジェクトは削除されるが、Blob は孤立する。

基本的なイメージプルーニングとは異なるレジストリーの ハードプルーニング により、孤立した Blob を削除することができます。OpenShift Container レジストリーのストレージ領域が不足している場合や、孤立した Blob があると思われる場合にはハードプルーニングを実行する必要があります。

これは何度も行う操作ではなく、多数の孤立した Blob が新たに作成されているという証拠がある場合にのみ実行する必要があります。または、(作成されるイメージの数によって異なりますが) 1 日 1 回などの定期的な間隔で標準のイメージプルーニングを実行することもできます。

孤立した Blob をレジストリーからハードプルーニングするには、以下を実行します。

  1. ログイン: CLI を使用し、アクセストークンを持つユーザーとしてログインします。
  2. 基本的なイメージプルーニングの実行: 基本的なイメージプルーニングにより、不要になった追加のイメージが削除されます。ハードプルーニングによってイメージが削除される訳ではなく、レジストリーストレージに保存された Blob のみが削除されます。したがって、ハードプルーニングの実行前にこれを実行する必要があります。

    手順については、「イメージのプルーニング」を参照してください。

  3. レジストリーの読み取り専用モードへの切り替え: レジストリーが読み取り専用モードで実行されていない場合、プルーニングと同時に実行されているプッシュの結果は以下のいずれかになります。

    • 失敗する。さらに孤立した Blob が新たに発生する。
    • 成功する。ただし、(参照される Blob の一部が削除されたため) イメージをプルできない。

    プッシュは、レジストリーが読み取り書き込みモードに戻されるまで成功しません。したがって、ハードプルーニングは注意してスケジューリングする必要があります。

    レジストリーを読み取り専用モードに切り換えるには、以下を実行します。

    1. 以下の環境変数を設定します。

      $ oc env -n default \
          dc/docker-registry \
          'REGISTRY_STORAGE_MAINTENANCE_READONLY={"enabled":true}'
    2. デフォルトで、レジストリーは直前の手順が完了すると自動的に再デプロイするはずです。再デプロイが完了するのを待機してから次に進んでください。ただし、これらのトリガーを無効にしている場合は、レジストリーを手動で再デプロイし、新規の環境変数が選択されるようにする必要があります。

      $ oc rollout -n default \
          latest dc/docker-registry
  4. system:image-pruner ロールの追加: 一部のリソースを一覧表示するには、レジストリーインスタンスの実行に使用するサービスアカウントに追加のパーミッションが必要になります。

    1. サービスアカウント名を取得します。

      $ service_account=$(oc get -n default \
          -o jsonpath=$'system:serviceaccount:{.metadata.namespace}:{.spec.template.spec.serviceAccountName}\n' \
          dc/docker-registry)
    2. system:image-pruner クラスターロールをサービスアカウントに追加します。

      $ oc adm policy add-cluster-role-to-user \
          system:image-pruner \
          ${service_account}
  5. (オプション) プルーナーのドライランモードでの実行: 削除される Blob の数を確認するには、ドライランモードでハードプルーナーを実行します。これにより変更が加えられることはありません。

    $ oc -n default \
        exec -i -t "$(oc -n default get pods -l deploymentconfig=docker-registry \
        -o jsonpath=$'{.items[0].metadata.name}\n')" \
        -- /usr/bin/dockerregistry -prune=check

    または、プルーニング候補の実際のパスを取得するには、ロギングレベルを上げます。

    $ oc -n default \
        exec "$(oc -n default get pods -l deploymentconfig=docker-registry \
          -o jsonpath=$'{.items[0].metadata.name}\n')" \
        -- /bin/sh \
        -c 'REGISTRY_LOG_LEVEL=info /usr/bin/dockerregistry -prune=check'

    出力サンプル (切り捨て済み)

    $ oc exec docker-registry-3-vhndw \
        -- /bin/sh -c 'REGISTRY_LOG_LEVEL=info /usr/bin/dockerregistry -prune=check'
    
    time="2017-06-22T11:50:25.066156047Z" level=info msg="start prune (dry-run mode)" distribution_version="v2.4.1+unknown" kubernetes_version=v1.6.1+$Format:%h$ openshift_version=unknown
    time="2017-06-22T11:50:25.092257421Z" level=info msg="Would delete blob: sha256:00043a2a5e384f6b59ab17e2c3d3a3d0a7de01b2cabeb606243e468acc663fa5" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6
    time="2017-06-22T11:50:25.092395621Z" level=info msg="Would delete blob: sha256:0022d49612807cb348cabc562c072ef34d756adfe0100a61952cbcb87ee6578a" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6
    time="2017-06-22T11:50:25.092492183Z" level=info msg="Would delete blob: sha256:0029dd4228961086707e53b881e25eba0564fa80033fbbb2e27847a28d16a37c" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6
    time="2017-06-22T11:50:26.673946639Z" level=info msg="Would delete blob: sha256:ff7664dfc213d6cc60fd5c5f5bb00a7bf4a687e18e1df12d349a1d07b2cf7663" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6
    time="2017-06-22T11:50:26.674024531Z" level=info msg="Would delete blob: sha256:ff7a933178ccd931f4b5f40f9f19a65be5eeeec207e4fad2a5bafd28afbef57e" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6
    time="2017-06-22T11:50:26.674675469Z" level=info msg="Would delete blob: sha256:ff9b8956794b426cc80bb49a604a0b24a1553aae96b930c6919a6675db3d5e06" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6
    ...
    Would delete 13374 blobs
    Would free up 2.835 GiB of disk space
    Use -prune=delete to actually delete the data

  6. ハードプルーニングの実行: ハードプルーニングを実行するには、docker-registry Pod の実行中インスタンスで以下のコマンドを実行します。

    $ oc -n default \
        exec -i -t "$(oc -n default get pods -l deploymentconfig=docker-registry -o jsonpath=$'{.items[0].metadata.name}\n')" \
        -- /usr/bin/dockerregistry -prune=delete

    出力サンプル

    $ oc exec docker-registry-3-vhndw \
        -- /usr/bin/dockerregistry -prune=delete
    
    Deleted 13374 blobs
    Freed up 2.835 GiB of disk space

  7. レジストリーを読み取り書き込みモードに戻す: プルーニングの終了後は、以下を実行してレジストリーを読み取り書き込みモードに戻すことができます。

    $ oc env -n default dc/docker-registry REGISTRY_STORAGE_MAINTENANCE_READONLY-

18.7. cron ジョブのプルーニング

重要

cron ジョブについては、現時点ではテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポートについての詳細は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。

cron ジョブは正常なジョブのプルーニングを実行できますが、失敗したジョブを適切に処理しない可能性があります。そのため、クラスター管理者は定期的なジョブのクリーンアップを手動で実行する必要があります。また、信頼できるユーザーの小規模なグループに cron ジョブへのアクセスを制限し、ジョブや Pod が作成され過ぎないように適切なクォータを設定することも推奨されます。

第19章 カスタムリソースによる Kubernetes API の拡張

Kubernetes API では、リソースは特定の種類の API オブジェクトのコレクションを保管するエンドポイントです。たとえば、ビルトインされた Pod リソースには Pod オブジェクトのコレクションが含まれます。

カスタムリソースは、Kubernetes API を拡張するか、またはプロジェクトまたはクラスターに独自の API を導入することを可能にするオブジェクトです。

カスタムリソース定義 (CRD) ファイルは、独自のオブジェクトの種類を定義し、API サーバーがライフサイクル全体を処理できるようにします。CRD をクラスターにデプロイすると、Kubernetes API サーバーは指定されたカスタムリソースを提供し始めます。

新規のカスタムリソース定義 (CRD) の作成時に、Kubernetes API サーバーは、クラスター全体または単一プロジェクト (namespace) でアクセスできる新規 RESTful リソースパスを作成することによって応答します。既存のビルトインオブジェクトの場合のように、プロジェクトを削除すると、そのプロジェクトのすべてのカスタムオブジェクトが削除されます。

19.1. カスタムリソース定義の作成

CRD を作成するには、YAML ファイルを開き、以下の例のようにフィールドに入力します。

カスタムリソース定義の YAML ファイルサンプル

apiVersion: apiextensions.k8s.io/v1beta1 1
kind: CustomResourceDefinition
metadata:
  name: crontabs.stable.example.com 2
spec:
  group: stable.example.com 3
  version: v1 4
  scope: Namespaced 5
  names:
    plural: crontabs 6
    singular: crontab 7
    kind: CronTab 8
    shortNames:
    - ct 9

1
apiextensions.k8s.io/v1beta1 API を使用します。
2
定義の名前を指定します。これは group および plural フィールドの値を使用する <plural-name><group> 形式である必要があります。
3
API のグループ名を指定します。API グループは、論理的に関連付けられるオブジェクトのコレクションです。たとえば、Job または ScheduledJob などのすべてのバッチオブジェクトはバッチ API グループ (batch.api.example.com など) である可能性があります。組織の完全修飾ドメイン名を使用することが奨励されます。
4
URL で使用されるバージョン名を指定します。それぞれの API グループは複数バージョンで存在させることができます。たとえば、v1alphavibetav1 などが使用されます。
5
カスタムオブジェクトがクラスター (Cluster) の 1 つのプロジェクト (Namespaced) またはすべてのプロジェクトで利用可能であるかどうかを指定します。
6
URL で使用される複数形の名前を指定します。plural フィールドは API URL のリソースと同じになります。
7
CLI および表示用にエイリアスとして使用される単数形の名前を指定します。
8
作成できるオブジェクトの種類を指定します。タイプは CamelCase にすることができます。
9
CLI でリソースに一致する短い文字列を指定します。
注記

デフォルトで、カスタムリソース定義のスコープはクラスターに設定され、すべてのプロジェクトで利用可能です。

定義ファイルの設定後にオブジェクトを定義します。

oc create -f <file-name>.yaml

新規の RESTful API エンドポイントは以下のように作成されます。

/apis/<spec:group>/<spec:version>/<scope>/*/<names-plural>/...

たとえば、サンプルファイルを使用すると、以下のエンドポイントが作成されます。

/apis/stable.example.com/v1/namespaces/*/crontabs/...

次にこのエンドポイント URL はカスタムオブジェクトを作成し、管理するために使用できます。オブジェクトの種類は、作成したカスタムリソース定義オブジェクトの spec.kind フィールドに基づくものです。

19.2. カスタムオブジェクトの作成

カスタムリソース定義オブジェクトの作成後に、カスタムオブジェクトを作成することができます。

カスタムオブジェクトにはカスタムフィールドを含めることができます。これらのフィールドには任意の JSON を含めることができます。

以下の例では、cronSpec および image カスタムフィールドが CronTab という種類のカスタムオブジェクトに設定されます。CronTab という種類は、上記で作成したカスタムリソース定義オブジェクトの spec.kind フィールドから取られています。

カスタムオブジェクトの YAML ファイルサンプル

apiVersion: "stable.example.com/v1" 1
kind: CronTab 2
metadata:
  name: my-new-cron-object 3
spec: 4
  cronSpec: "* * * * /5"
  image: my-awesome-cron-image

1
カスタムリソース定義からグループ名および API バージョン (名前/バージョン) を指定します。
2
カスタムリソース定義のタイプを指定します。
3
オブジェクトの名前を指定します。
4
オブジェクトのタイプに固有の条件を指定します。

オブジェクトファイルの設定後に、オブジェクトを作成します。

oc create -f <file-name>.yaml

19.3. カスタムオブジェクトの管理

次に、カスタムリソースを管理することができます。

特定の種類のカスタムリソースについての情報を取得するには、以下を入力します。

oc get <kind>

以下に例を示します。

oc get crontab

NAME                 KIND
my-new-cron-object   CronTab.v1.stable.example.com

リソース名では大文字と小文字が区別されず、CRD で定義される単数形または複数形のいずれか、および任意の短縮名を指定できることに注意してください。以下は例になります。

oc get crontabs
oc get crontab
oc get ct

未加工 JSON データを表示することもできます。

oc get <kind> -o yaml

これを作成するために使用した YAML のカスタム <1> cronSpec および <2> image フィールドが含まれることを確認できるはずです。

oc get ct -o yaml

apiVersion: v1
items:
- apiVersion: stable.example.com/v1
  kind: CronTab
  metadata:
    clusterName: ""
    creationTimestamp: 2017-05-31T12:56:35Z
    deletionGracePeriodSeconds: null
    deletionTimestamp: null
    name: my-new-cron-object
    namespace: default
    resourceVersion: "285"
    selfLink: /apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object
    uid: 9423255b-4600-11e7-af6a-28d2447dc82b
  spec:
    cronSpec: '* * * * /5' 1
    image: my-awesome-cron-image 2

19.4. ファイナライザー

カスタムオブジェクトは ファイナライザー をサポートします。これにより、コントローラーはオブジェクトの削除前に満たしている必要のある条件を実装できます。

以下のようにファイナライザーをカスタムオブジェクトに追加できます。

apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
  finalizers:
  - finalizer.stable.example.com

ファイナライザーが設定されたオブジェクトでの最初の削除要求により、オブジェクトの削除ではなく metadata.deletionTimestamp フィールドの値が設定されます。これによりコントローラーがトリガーされ、コントローラーはオブジェクトによる対象ファイナライザーの実行を監視します。

次に、各コントローラーは一覧からファイナライザーを削除し、削除要求を再び発行します。この要求により、ファイナライザーの一覧が空である (つまり、すべてのファイナライザーが実行済みである) 場合にのみオブジェクトが削除されます。

第20章 ガベージコレクション

20.1. 概要

OpenShift Container Platform ノードは、2 種類のガベージコレクションを実行します。

20.2. コンテナーのガベージコレクション

コンテナーのガベージコレクションはデフォルトで有効にされ、エビクションのしきい値に達すると自動的に実行されます。ノードは Pod のコンテナーを API からアクセス可能な状態にしようとします。Pod が削除された場合、コンテナーも削除されます。コンテナーは Pod が削除されておらず、エビクションのしきい値に達していない限り保持されます。ノードがディスク不足 (disk pressure) の状態にある場合、コンテナーが削除され、それらのログは oc logs でアクセスできなくなります。

コンテナーのガベージコレクションのポリシーは 3 つのノード設定に基づいています。

設定説明

minimum-container-ttl-duration

コンテナーがガベージコレクションの対象となるのに必要な最小の年数です。デフォルトは 0 です。制限なしにするには 0 を使用します。この設定の値は、時間の h、分の m、秒の s などの単位のサフィックスを使用して指定することができます。

maximum-dead-containers-per-container

Pod コンテナーごとに保持するインスタンス数です。デフォルトは 1 です。

maximum-dead-containers

ノードにある実行されないコンテナーの合計の最大数です。デフォルトは、無制限を意味する -1 です。

競合が生じる場合、maximum-dead-containers 設定は maximum-dead-containers-per-container 設定よりも優先されます。たとえば、maximum-dead-containers-per-container の数を保持することでコンテナーの合計数が maximum-dead-containers より大きくなる場合、最も古いコンテナーが削除され、maximum-dead-containers の制限が満たされるようにします。

ノードが実行されていないコンテナーを削除すると、それらのコンテナーの内部にあるすべてのファイルも削除されます。そのノードで作成されたコンテナーに対してのみガベージコレクションが実行されます。

ノードホストにある /etc/origin/node/node-config.yaml ファイルの kubeletArguments セクションでこれらの設定の値を指定します。このセクションがすでに存在しない場合には、これを追加します。

コンテナーのガベージコレクション設定

kubeletArguments:
  minimum-container-ttl-duration:
    - "10s"
  maximum-dead-containers-per-container:
    - "2"
  maximum-dead-containers:
    - "240"

20.2.1. 削除するコンテナーの検出

ガべージコレクターの各ループでは、以下の手順が実行されます。

  1. 利用可能なコンテナーの一覧を取得します。
  2. 実行中であるか、または minimum-container-ttl-duration パラメーターよりも長く存続していないすべてのコンテナーをフィルターに掛けます。
  3. 残りのすべてのコンテナーを、Pod およびイメージ名のメンバーシップに基づいて同等のクラスに分類します。
  4. 特定されないコンテナー (kubelet で管理されているコンテナーであるが、それらの名前の形式が正しくないコンテナー) をすべて削除します。
  5. maximum-dead-containers-per-container パラメーターよりも多くのコンテナーが含まれるそれぞれのクラスについて、そのクラスのコンテナーを作成時間で並び替えます。
  6. maximum-dead-containers-per-container パラメーターの条件が満たされるまで、コンテナーを最も古いものから順に削除し始めます。
  7. 依然として maximum-dead-containers パラメーターよりも多くのコンテナーが一覧にある場合、コレクターは各クラスのコンテナーの削除を開始し、それぞれのクラスにあるコンテナー数がクラスあたりのコンテナーの平均数、または <all_remaining_containers>/<number_of_classes> よりも大きくならないようにします。
  8. これでも十分でない場合は、一覧にあるすべてのコンテナーを並び替えて、maximum-dead-containers の条件を満たすまで、コンテナーを古いものから順番に削除し始めます。
重要

各種のニーズに合わせてデフォルト設定を更新してください。

ガべージコレクションは、関連付けられている Pod のないコンテナーのみを削除します。

20.3. イメージのガベージコレクション

イメージのガべージコレクションでは、ノードの cAdvisor によって報告されるディスク使用量に基づいて、ノードから削除するイメージを決定します。この場合、以下の設定が考慮に入れられます。

設定説明

image-gc-high-threshold

イメージのガべージコレクションをトリガーするディスク使用量のパーセント (整数で表される) です。デフォルトは 85 です。

image-gc-low-threshold

イメージのガべージコレクションが解放しようとするディスク使用量のパーセント (整数で表される) です。デフォルトは 80 です。

ノードホストにある /etc/origin/node/node-config.yaml ファイルの kubeletArguments セクションでこれらの設定の値を指定します。このセクションがすでに存在しない場合には、これを追加します。

イメージのガベージコレクション設定

kubeletArguments:
  image-gc-high-threshold:
    - "85"
  image-gc-low-threshold:
    - "80"

20.3.1. 削除するイメージの検出

以下の 2 つのイメージ一覧がそれぞれのガベージコレクターの実行で取得されます。

  1. 1 つ以上の Pod で現在実行されているイメージの一覧
  2. ホストで利用可能なイメージの一覧

新規コンテナーの実行時に新規のイメージが表示されます。すべてのイメージにはタイムスタンプのマークが付けられます。イメージが実行中 (上記の最初の一覧) か、または新規に検出されている (上記の 2 番目の一覧) 場合、これには現在の時間のマークが付けられます。残りのイメージには以前のタイムスタンプのマークがすでに付けられています。すべてのイメージはタイムスタンプで並び替えられます。

コレクションが開始されると、停止条件を満たすまでイメージが最も古いものから順番に削除されます。

第21章 ノードリソースの割り当て

21.1. 概要

より信頼性の高いスケジューリングを提供し、ノードにおけるリソースのオーバーコミットを最小限にするために、各ノードは、ホスト上のすべての基礎となる ノードコンポーネント (例: kubelet、kube-proxy、Docker) および残りのシステムコンポーネント (例: sshdNetworkManager) に使用される分をリソースの一部として保持できます。このリソースが指定されると、スケジューラーは、ノードが Pod に割り当てたリソース (例: メモリー、CPU) についての詳細な情報を取得できます。

21.2. 割り当てられるリソースについてのノードの設定

ノードコンポーネント用に予約されたリソースは 2 つのノード設定に基づきます。

設定説明

kube-reserved

ノードコンポーネント用に予約されたリソースです。デフォルトは none です。

system-reserved

残りのシステムコンポーネント用に予約されたリソースです。デフォルトは none です。

これらは、<resource_type>=<resource_quantity> ペアのセット (例: cpu=200m,memory=512Mi) を使用してノード設定ファイル (デフォルトでは /etc/origin/node/node-config.yaml ファイル) の kubeletArguments セクションに設定することができます。このセクションは、すでに存在しない場合は追加します。

例21.1 ノードの割り当て可能なリソースの設定

kubeletArguments:
  kube-reserved:
    - "cpu=200m,memory=512Mi"
  system-reserved:
    - "cpu=200m,memory=512Mi"

現時点で、cpu および memory のリソースタイプがサポートされています。cpu の場合、リソースの量はコアの単位で指定されます (例: 200m、0.5, 1)。memory の場合、これはバイト単位で指定されます (例: 200Ki、50Mi、5Gi)。

詳細は、「コンピュートリソース」を参照してください。

フラグが設定されていない場合、これはデフォルトで 0 になります。フラグのいずれも設定されていない場合、割り当てられるリソースは、割り当て可能なリソースの導入前であるためにノードの容量に設定されます。

21.3. 割り当てられるリソースの計算

リソースの割り当てられる量は以下の数式に基づいて計算されます。

[Allocatable] = [Node Capacity] - [kube-reserved] - [system-reserved] - [Hard-Eviction-Thresholds]
注記

Hard-Eviction-Thresholds を割り当て可能なリソースから差し引く点はシステムの信頼性を強化するための動作の変更点です。この値に基づいて割り当て可能なリソースをノードレベルでエンドユーザー Pod に対して適用できます。experimental-allocatable-ignore-eviction 設定は、レガシー動作を保持するために利用できますが、今後のリリースでは非推奨となります。

[Allocatable] が負の値の場合、これは 0 に設定されます。

21.4. ノードの割り当て可能なリソースおよび容量の表示

ノードの現在の容量および割り当て可能なリソースを表示するには、以下を実行できます。

$ oc get node/<node_name> -o yaml
...
status:
...
  allocatable:
    cpu: "4"
    memory: 8010948Ki
    pods: "110"
  capacity:
    cpu: "4"
    memory: 8010948Ki
    pods: "110"
...

21.5. ノードによって報告されるシステムリソース

OpenShift Container Platform 3.3 より、各ノードはコンテナーランタイムおよび kubelet によって利用されるシステムリソースについて報告します。--system-reserved および --kube-reserved の設定をより容易に行えるようにするには、ノード要約 API を使用して対応するノードのリソース使用状況をインストロスペクトできます。この API は <master>/api/v1/nodes/<node>/proxy/stats/summary からアクセスできます。

たとえば、cluster.node22 ノードからリソースにアクセスするには、以下を実行できます。

$ curl <certificate details> https://<master>/api/v1/nodes/cluster.node22/proxy/stats/summary
{
    "node": {
        "nodeName": "cluster.node22",
        "systemContainers": [
            {
                "cpu": {
                    "usageCoreNanoSeconds": 929684480915,
                    "usageNanoCores": 190998084
                },
                "memory": {
                    "rssBytes": 176726016,
                    "usageBytes": 1397895168,
                    "workingSetBytes": 1050509312
                },
                "name": "kubelet"
            },
            {
                "cpu": {
                    "usageCoreNanoSeconds": 128521955903,
                    "usageNanoCores": 5928600
                },
                "memory": {
                    "rssBytes": 35958784,
                    "usageBytes": 129671168,
                    "workingSetBytes": 102416384
                },
                "name": "runtime"
            }
        ]
    }
}

証明書の詳細については、「REST API Overview」を参照してください。

21.6. ノードの実施

ノードは、Pod が設定された割り当て可能な値に基づいて消費できるリソースの合計量を制限できます。この機能は、Pod がリソースのシステムサービス (例: コンテナーランタイム、ノードエージェントなど) のリソース不足の状態を防ぎ、ノードの信頼性を大幅に強化します。管理者におかれましては、ノードの信頼性を強化するために必要なノードの使用状況のターゲットに基づいてリソースを予約することを強く奨励します。

ノードは、QoS (Quality of Service) を実施する新規の cgroup 階層を使用してリソースの制約を実施します。すべての Pod は、システムデーモンと切り離された専用の cgroup 階層で起動します。

この機能を設定するために、以下の kubelet 引数を指定します。

例21.2 ノードの cgroup 設定

kubeletArguments:
  cgroups-per-qos:
    - "true" 1
  cgroup-driver:
    - "systemd" 2
  enforce-node-allocatable:
    - "pods" 3
1 1
ノードによって管理される新規の cgroup 階層を有効化または無効化します。この設定の変更にはノードの完全なドレイン (解放) が必要になります。このフラグは、ノードがノードの割り当て可能分を実施できるようにするには true である必要があります。ユーザーにはこの値を変更しないようにすることを推奨します。
2 2
cgroup 階層を管理する際にノードで使用される cgroup ドライバーです。この値はコンテナーランタイムに関連付けられたドライバーに一致する必要があります。有効な値は systemd および cgroupfs です。デフォルトは systemd です。
3
ノードがノードのリソース制約を実施するスコープのカンマ区切りの一覧です。有効な値は podssystem-reserved、および kube-reserved です。デフォルトは pods です。ユーザーにはこの値を変更しないようにすることを推奨します。

オプションとして、enforce-node-allocatable フラグでトークンを指定することで、ノードが kube で予約される制限およびシステムで予約される制限を実施するようにできます。これらが指定される場合、対応する --kube-reserved-cgroup または --system-reserved-cgroup を指定する必要があります。今後のリリースでは、ノードおよびコンテナーランタイムは system.slice と切り離された共通の cgroup でパッケージ化されます。パッケージ化されるまでは、ユーザーは enforce-node-allocatable フラグのデフォルト値を変更しないようにすることを推奨します。

管理者は Guaranteed Pod と同様にシステムデーモンを処理する必要があります。システムデーモンは、境界となる制御グループ内で予想外の動作をする可能性があり、この動作はクラスターデプロイメントの一部として管理される必要があります。システム予約の制限を実施することにより、ノード上の重要なシステムサービスで CPU が不足したり、OOM による強制終了が生じる可能性があります。そのため、オペレーターが正確な推定値を判別するためにノードの徹底的なプロファイリングを実行した場合や、そのグループのプロセスで OOM による強制終了が発生した場合に確実に復元できる場合にのみシステム予約の制限を実施することが推奨されます。

したがって、ユーザーはデフォルトで pods に対してのみノードの割り当て可能分を実施し、ノード全体の信頼性を維持するためにシステムデーモンの適切な予約を確保しておくことを強くお勧めします。

21.7. エビクションしきい値

ノードがメモリー不足の状態にある場合、ノード全体に、またノードで実行されているすべての Pod に影響が及ぶ可能性があります。システムデーモンによるメモリーの使用がメモリーの予約されている量を超える場合、OOM イベントが発生し、ノード全体やノードで実行されているすべての Pod に影響が及び可能性があります。システムの OOM を防止する (またはその発生可能性を下げる) ために、ノードは Out Of Resource Handling (リソース不足の処理) を行います。

--eviction-hard フラグで一部のメモリーを確保することで、ノードは、ノードのメモリー可用性が絶対値またはパーセンテージを下回る場合は常に Pod のエビクトを試行します。システムデーモンがノードに存在しない場合、Pod はメモリーの capacity - eviction-hard に制限されます。このため、メモリー不足の状態になる前にエビクションのバッファーとして確保されているリソースは Pod で利用することはできません。

以下の例は、ノードの割り当て可能分のメモリーに対する影響について説明しています。

  • ノード容量: 32Gi
  • --kube reserved: 2Gi
  • --system-reserved: 1Gi
  • --eviction-hard は <100Mi に設定される。

このノードについては、有効なノードの割り当て可能な値は 28.9Gi です。ノードおよびシステムコンポーネントが予約分をすべて使い切る場合、Pod に利用可能なメモリーは 28.9Gi となり、この使用量を超える場合に kubelet は Pod をエビクトします。

トップレベルの cgroup でノードの割り当て可能分 (28.9Gi) を実施する場合、Pod は 28.9Gi を超えることはできません。エビクションは、システムデーモンが 3.1Gi よりも多くのメモリーを消費しない限り実行されません。

上記の例ではシステムデーモンが予約分すべてを使い切らない場合も、ノードのエビクションが開始される前に、Pod では境界となる cgroup からの memcg OOM による強制終了が発生します。この状況で QoS をより効果的に実行するには、ノードですべての Pod のトップレベルの cgroup に対し、ハードエビクションしきい値が Node Allocatable + Eviction Hard Thresholds になるよう適用できます。

システムデーモンがすべての予約分を使い切らない場合で、Pod が 28.9Gi を超えるメモリーを消費する場合、ノードは Pod を常にエビクトします。エビクションが時間内に生じない場合には、Pod が 29Gi のメモリーを消費すると OOM による強制終了が生じます。

21.8. スケジューラー

スケジューラーは、node.Status.Capacity ではなく node.Status.Allocatable の値を使用して、ノードが Pod スケジューリングの候補になるかどうかを判別します。

デフォルトで、ノードはそのマシン容量をクラスターで完全にスケジュール可能であるとして報告します。

第22章 不透明な整数リソース

22.1. 概要

不透明な整数リソースは、クラスターのオペレーターがシステムで認識されない新規のノードレベルのリソースを提供することを可能にします。ユーザーは CPU やメモリーと同様に Pod 仕様にあるこれらのリソースを消費できます。スケジューラーは、利用可能な量を上回るリソースが複数の Pod に同時に割り当てられないようにリソースアカウンティングを実行します。

注記

不透明な整数リソースは現時点でアルファ機能であり、リソースアカウンティングのみが実装されています。これらのリソースについてのリソースクォータや制限範囲のサポートはなく、これらが QoS に影響を与えることはありません。

不透明な整数リソースが 不透明 (opaque) と言われるのは、OpenShift Container Platform がリソースが何を認識しない状態でも、そのリソースが十分にある場合に Pod をノードにスケジュールするためです。それらが 整数リソース と言われるのは、それらが整数で表される量で利用可能であるか、または 公開 されるためです。API サーバーはこれらのリソースの量を整数に制限します。有効な 量の例は、33000m、および 3Ki などです。

不透明な整数リソースは以下を割り当てるために使用できます。

  • ラストレベルキャッシュ (LLC)
  • Graphics processing unit (GPU) デバイス
  • Field-programmable gate array (FPGA) デバイス
  • 帯域幅を並列ファイルシステムと共有するためのスロット

たとえば、ノードに特殊な種類のディスクストレージ 800 GiB がある場合、その特殊ストレージに opaque-int-resource-special-storage などの名前を作成することができます。これを 100 GiB などの特定サイズのチャンクの単位で公開することができます。この場合、ノードではタイプ opaque-int-resource-special-storage の 8 つのリソースがあることを公開します。

不透明な整数リソースの名前はプレフィックス pod.alpha.kubernetes.io/opaque-int-resource- で開始する必要があります。

22.2. 不透明な整数リソースの作成

以下は、不透明な整数リソースを使用するために必要な 2 つの手順です。まず、クラスターのオペレーターは 1 つ以上のノードでノード別の不透明なリソースに名前を付け、これを公開する必要があります。次に、アプリケーション開発者は Pod で不透明なリソースを要求する必要があります。

不透明な整数リソースを利用可能にするには、以下を実行します。

  1. リソースを割り当て、pod.alpha.kubernetes.io/opaque-int-resource- で開始される名前を割り当てます。
  2. クラスターのノードについて status.capacity で利用可能な数量を指定する PATCH HTTP 要求を API サーバーに送信することにより、新規の不透明な整数リソースを公開します。

    たとえば、以下の HTTP 要求は openshift-node-1 ノードで 5 つの foo リソースを公開します。

    PATCH /api/v1/nodes/openshift-node-1/status HTTP/1.1
    Accept: application/json
    Content-Type: application/json-patch+json
    Host: openshift-master:8080
    
    [
      {
        "op": "add",
        "path": "/status/capacity/pod.alpha.kubernetes.io~1opaque-int-resource-foo",
        "value": "5"
      }
    ]
    注記

    path にある ~1/ 文字のエンコーディングです。JSON-Patch の操作パスの値は JSON-Pointer として解釈されます。詳細は、IETF RFC 6901、セクション 3 を参照してください。

    この操作の後に、ノード status.capacity には新規リソースが含まれます。status.allocatable フィールドは、新規リソースで自動的に、また非同期的に更新されます。

    注記

    スケジューラーは、Pod が適切であるかどうかを評価する際にノードの status.allocatable 値を使用するため、ノードの容量を新規リソースで修正してから、そのリソースを要求する最初の Pod がノードでスケジュールされるまでの間に少しの遅延が生じる可能性があります。

アプリケーション開発者は、不透明なリソースの名前を spec.containers[].resources.requests フィールドのキーとして組み込むよう Pod 設定を編集することにより、不透明なリソースを消費できます。

例: 以下の Pod は 2 つの CPU および 1 つの foo (不透明なリソース) を要求しています。

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: myimage
    resources:
      requests:
        cpu: 2
        pod.alpha.kubernetes.io/opaque-int-resource-foo: 1

Pod は、(CPU、メモリー、およびすべての不透明なリソースを含む) リソース要求のすべてが満たされる場合にのみスケジュールされます。Pod は、リソース要求がいずれのノードでも満たされない場合には PENDING 状態のままになります。

Conditions:
  Type    Status
  PodScheduled  False
...
Events:
  FirstSeen  LastSeen	Count	From		  SubObjectPath	Type	  Reason	    Message
  ---------  --------	-----	----		  -------------	--------  ------	    -------
  14s	     0s		6	default-scheduler		Warning	  FailedScheduling  No nodes are available that match all of the following predicates:: Insufficient pod.alpha.kubernetes.io/opaque-int-resource-foo (1).

この情報は『Developer Guide』の「Quotas and Limit Ranges」でも参照できます。

第23章 オーバーコミット

23.1. 概要

コンテナーは、コンピュートリソース要求および制限を指定することができます。要求はコンテナーのスケジューリングに使用され、最小限のサービス保証を提供します。一方、制限はノードで消費できるコンピュートリソースの量を制限します。

scheduler は、クラスター内のすべてのノードにおけるコンピュートリソース使用の最適化を試行します。これは Pod のコンピュートリソース要求とノードの利用可能な容量を考慮に入れて Pod を特定のノードに配置します。

要求および制限により、管理者はノードでのリソースのオーバーコミットを許可し、管理できます。これは、保証されるパフォーマンスとキャパシティーのトレードオフが許容される開発環境において役立ちます。

23.2. 要求および制限

各コンピュートリソースについて、コンテナーはリソース要求および制限を指定できます。スケジューリングの決定は要求に基づいて行われ、ノードに要求される値を満たす十分な容量があることが確認されます。コンテナーが制限を指定するものの、要求を省略する場合、要求はデフォルトで制限値に設定されます。コンテナーは、ノードの指定される制限を超えることはできません。

制限の実施方法は、コンピュートリソースのタイプによって異なります。コンテナーが要求または制限を指定しない場合、コンテナーはリソース保証のない状態でノードにスケジュールされます。実際に、コンテナーはローカルの最も低い優先順位で利用できる指定リソースを消費できます。リソースが不足する状態では、リソース要求を指定しないコンテナーに最低レベルの QoS (Quality of Service) が設定されます。

23.2.1. Buffer Chunk Limit の調整

Fluentd ロガーが多数のログを処理できない場合、メモリーの使用量を減らし、データ損失を防ぐためにファイルバッファリングに切り換える必要があります。

Fluentd buffer_chunk_limit は、デフォルト値が 8m の環境変数 BUFFER_SIZE_LIMIT によって決定されます。出力ごとのファイルのバッファーサイズは、デフォルト値が 256Mi の環境変数 FILE_BUFFER_LIMIT によって決定されます。永続的なボリュームサイズは、FILE_BUFFER_LIMIT に出力を乗算した結果よりも大きくなければなりません。

Fluentd および Mux Pod では、永続ボリューム /var/lib/fluentd は PVC または hostmount などによって作成される必要があります。その領域はファイルバッファーに使用されます。

buffer_type および buffer_path は、以下のように Fluentd 設定ファイルで設定されます。

$ egrep "buffer_type|buffer_path" *.conf
output-es-config.conf:
  buffer_type file
  buffer_path `/var/lib/fluentd/buffer-output-es-config`
output-es-ops-config.conf:
  buffer_type file
  buffer_path `/var/lib/fluentd/buffer-output-es-ops-config`
filter-pre-mux-client.conf:
  buffer_type file
  buffer_path `/var/lib/fluentd/buffer-mux-client`

Fluentd buffer_queue_limit は 32 です。

23.3. コンピュートリソース

コンピュートリソースについてのノードで実施される動作は、リソースタイプによって異なります。

23.3.1. CPU

コンテナーには要求する CPU の量が保証され、さらにコンテナーで指定される任意の制限までノードで利用可能な CPU を消費できます。複数のコンテナーが追加の CPU の使用を試行する場合、CPU 時間が各コンテナーで要求される CPU の量に基づいて分配されます。

たとえば、あるコンテナーが 500m の CPU 時間を要求し、別のコンテナーが 250m の CPU 時間を要求した場合、ノードで利用可能な追加の CPU 時間は 2:1 の比率でコンテナー間で分配されます。コンテナーが制限を指定している場合、指定した制限を超えて CPU を使用しないようにスロットリングされます。

CPU 要求は、Linux カーネルの CFS 共有サポートを使用して実施されます。デフォルトで、CPU 制限は、Linux カーネルの CFS クォータサポートを使用して 100ms の測定間隔で 実施されます。ただし、これは無効にすることができます

23.3.2. メモリー

コンテナーには要求するメモリー量が保証されます。コンテナーは要求したよりも多くのメモリーを使用できますが、いったん要求した量を超えた場合には、ノードのメモリーが不足している状態では強制終了される可能性があります。

コンテナーが要求した量よりも少ないメモリーを使用する場合、システムタスクやデーモンがノードのリソース予約で確保されている分よりも多くのメモリーを必要としない限りそれが強制終了されることはません。コンテナーがメモリーの制限を指定する場合、その制限量を超えると即時に強制終了されます。

23.4. QoS (Quality of Service) クラス

ノードは、要求を指定しない Pod がスケジュールされている場合やノードのすべての Pod での制限の合計が利用可能なマシンの容量を超える場合に オーバーコミット されます。

オーバーコミットされる環境では、ノード上の Pod がいずれかの時点で利用可能なコンピュートリソースよりも多くの量の使用を試行することができます。これが生じると、ノードはそれぞれの Pod に優先順位を指定する必要があります。この決定を行うために使用される機能は、QoS (Quality of Service) クラスと呼ばれます。

各コンピュートリソースについて、コンテナーは 3 つの QoS クラスに分類されます (優先順位は降順)。

表23.1 QoS (Quality of Service) クラス

優先順位クラス名説明

1 (最高)

Guaranteed

制限およびオプションの要求がすべてのリソースについて設定されている場合 (0 と等しくない) でそれらの値が等しい場合、コンテナーは Guaranteed として分類されます。

2

Burstable

制限およびオプションの要求がすべてのリソースについて設定されている場合 (0 と等しくない) でそれらの値が等しくない場合、コンテナーは Burstable として分類されます。

3 (最低)

BestEffort

要求および制限がリソースのいずれについても設定されない場合、コンテナーは BestEffort として分類されます。

メモリーは圧縮できないリソースであるため、メモリー不足の状態では、最も優先順位の低いコンテナーが最初に強制終了されます。

  • Guaranteed コンテナーは優先順位が最も高いコンテナーとして見なされ、保証されます。強制終了されるのは、これらのコンテナーで制限を超えるか、またはシステムがメモリー不足の状態にあるものの、エビクトできる優先順位の低いコンテナーが他にない場合のみです。
  • システム不足の状態にある Burstable コンテナーは、制限を超過し、BestEffort コンテナーが他に存在しない場合に強制終了される可能性があります。
  • BestEffort コンテナーは優先順位の最も低いコンテナーとして処理されます。これらのコンテナーのプロセスは、システムがメモリーー不足になると最初に強制終了されます。

23.5. マスターでのオーバーコミットの設定

スケジューリングは要求されるリソースに基づいて行われる一方で、クォータおよびハード制限はリソース制限のことを指しており、これは要求されるリソースよりも高い値に設定できます。要求と制限の間の差異は、オーバーコミットのレベルを定めるものとなります。たとえば、コンテナーに 1Gi のメモリー要求と 2Gi のメモリー制限が指定される場合、コンテナーのスケジューリングはノードで 1Gi を利用可能とする要求に基づいて行われますが、 2Gi まで使用することができます。そのため、この場合のオーバーコミットは 200% になります。

OpenShift Container Platform 管理者がオーバーコミットのレベルを制御し、ノードのコンテナー密度を管理する必要がある場合、開発者コンテナーで設定された要求と制限の比率を上書きするようマスターを設定することができます。この設定を制限とデフォルトを指定する プロジェクトごとの LimitRange と共に使用することで、オーバーコミットを必要なレベルに設定できるようコンテナーの制限と要求を調整することができます。

これを実行するには、以下の例にあるように master-config.yamlClusterResourceOverride 受付コントローラーを設定することが必要です (既存の設定ツリーが存在する場合はこれを再利用するか、または必要に応じて存在しない要素を導入します)。

  admissionConfig:
    pluginConfig:
      ClusterResourceOverride:   1
        configuration:
          apiVersion: v1
          kind: ClusterResourceOverrideConfig
          memoryRequestToLimitPercent: 25  2
          cpuRequestToLimitPercent: 25     3
          limitCPUToMemoryPercent: 200     4
1
これはプラグイン名です。大文字/小文字の区別が必要であり、プラグインの完全に一致する名前以外はすべて無視されます。
2
(オプション、1-100) コンテナーのメモリー制限が指定されているか、デフォルトに設定されている場合、メモリー要求は制限のこのパーセンテージに対応して上書きされます。
3
(オプション、1-100) コンテナーの CPU 制限が指定されているか、またはデフォルトに設定されている場合、CPU 要求は制限のこのパーセンテージに対応して上書きされます。
4
(オプション、正の整数) コンテナーのメモリー制限が指定されているか、デフォルトに設定されている場合、CPU 制限はメモリー制限のパーセンテージに対応して上書きされます。この場合、1Gi の RAM が 1 CPU コアと等しくなる場合に 100 パーセントになります。これは、CPU 要求を上書きする前に処理されます (設定されている場合)。

マスター設定の変更後は、マスターの再起動が必要になります。

制限がコンテナーに設定されていない場合にはこれらの上書きは影響を与えないことに注意してください。(個別プロジェクトごとに、または プロジェクトテンプレート を使用して) デフォルトの制限で LimitRange オブジェクトを作成し、上書きが適用されるようにします。

また、上書き後も、コンテナーの制限および要求がプロジェクトのいずれかの LimitRange オブジェクトで依然として検証される必要があることにも注意してください。たとえば、開発者が最小限度に近い制限を指定し、要求を最小限度よりも低い値に上書きすることで、Pod が禁止される可能性があります。この最適でないユーザーエクスペリエンスについては、今後の作業で対応する必要がありますが、現時点ではこの機能および LimitRanges を注意して設定してください。

上書きが設定されている場合に、プロジェクトを編集し、以下のアノテーションを追加することで、上書きをプロジェクトごとに無効にすることができます (たとえば、インフラストラクチャーコンポーネントの設定を上書きと切り離して実行できます)。

quota.openshift.io/cluster-resource-override-enabled: "false"

23.6. ノードでのオーバーコミットの設定

オーバーコミット環境では、最適なシステム動作を提供できるようにノードを適切に設定する必要があります。

23.6.1. Quality of Service (QoS) 層でのメモリー予約

experimental-qos-reserved パラメーターを使用して、特定の QoS レベルの Pod で予約されるメモリーのパーセンテージを指定することができます。この機能は、最も低い OoS クラスの Pod が高い QoS クラスの Pod で要求されるリソースを使用できないようにするために要求されたリソースの予約を試行します。

高い QOS レベル用にリソースを予約することで、リソース制限を持たない Pod が高い QoS レベルの Pod で要求されるリソースを侵害しないようにできます。

experimental-qos-reserved を設定するには、ノードの /etc/origin/node/node-config.yaml ファイルを編集します。

kubeletArguments:
  cgroups-per-qos:
  - true
  cgroup-driver:
  - 'systemd'
  cgroup-root:
  - '/'
  experimental-qos-reserved: 1
  - 'memory=50%'
1
Pod のリソース要求が QoS レベルでどのように予約されるかを指定します。

OpenShift Container Platform は、以下のように experimental-qos-reserved パラメーターを使用します。

  • experimental-qos-reserved=memory=100% の値は、 Burstable および BestEffort QOS クラスが、これらより高い QoS クラスで要求されたメモリーを消費するのを防ぎます。これにより、Guaranteed および Burstable ワークロードのメモリーリソースの保証レベルを上げることが優先され、BestEffort および Burstable ワークロードでの OOM が発生するリスクが高まります。
  • experimental-qos-reserved=memory=50% の値は、Burstable および BestEffort QOS クラスがこれらより高い QoS クラスによって要求されるメモリーの半分を消費することを許可します。
  • experimental-qos-reserved=memory=0% の値は、Burstable および BestEffort QoS クラスがノードの割り当て可能分を完全に消費することを許可しますが (利用可能な場合)、これにより、Guaranteed ワークロードが要求したメモリーにアクセスできなくなるリスクが高まります。この状況により、この機能は無効にされています。

23.6.2. CPU 制限の実施

デフォルトで、ノードは Linux カーネルの CPU CFS クォータのサポートを使用して指定された CPU 制限を実施します。ノードで CPU 制限を実施する必要がない場合は、以下を含むようにノード設定ファイル (node-config.yaml ファイル) を変更してその実施を無効にすることができます。

kubeletArguments:
  cpu-cfs-quota:
    - "false"

CPU 制限の実施が無効にされる場合、それがノードに与える影響を理解しておくことが重要になります。

  • コンテナーが CPU の要求をする場合、これは Linux カーネルの CFS 共有によって引き続き実施されます。
  • コンテナーが CPU の要求を明示的に指定しないものの、制限を指定する場合には、要求は指定された制限にデフォルトで設定され、Linux カーネルの CFS 共有で実施されます。
  • コンテナーが CPU の要求と制限の両方を指定する場合、要求は Linux カーネルの CFS 共有で実施され、制限はノードに影響を与えません。

23.6.3. システムリソースのリソース予約

スケジューラー は、Pod 要求に基づいてノード上のすべての Pod に十分なリソースがあることを確認します。これは、ノード上のコンテナーの要求の合計がノード容量を上回らないことを確認します。これには、ノードで起動されたすべてのコンテナーが含まれますが、クラスターの範囲外で起動されたコンテナーやプロセスは含まれません。

ノード容量の一部を予約して、クラスターが機能できるようノードで実行する必要のあるシステムデーモン用に確保することが推奨されます (sshddocker など)。とくに、メモリーなどの圧縮できないリソースのリソース予約を行うことが推奨されます。

Pod 以外のプロセスのリソースを明示的に予約する必要がある場合、以下の 2 つの方法でこれを実行できます。

  • 優先される方法として、スケジューリングに利用できるリソースを指定してノードリソースを割り当てることができます。詳細は、「ノードリソースの割り当て」を参照してください。
  • 2 つ目の方法として resource-reserver Pod を作成できます。この Pod は、クラスターによるスケジュールの対象外となるようノードで容量を確保します。以下は例になります。

    例23.1 resource-reserver Pod の定義

    apiVersion: v1
    kind: Pod
    metadata:
      name: resource-reserver
    spec:
      containers:
      - name: sleep-forever
        image: gcr.io/google_containers/pause:0.8.0
        resources:
          limits:
            cpu: 100m 1
            memory: 150Mi 2
    1
    クラスターに認識されないホストレベルのデーモン用にノード上で確保する CPU の量です。
    2
    クラスターに認識されないホストレベルのデーモン用にノード上で確保するメモリーの量です。

    定義は resource-reserver.yaml のようなファイルに保存し、ファイルを /etc/origin/node/ または別の指定がある場合は --config=<dir> などのノード設定ディレクトリーに置くことができます。

    さらに、ノードサーバーをノード設定ディレクトリーから定義を読み取れるように設定する必要があります。これは、ノード設定ファイルkubeletArguments.config フィールドでディレクトリーの名前(通常の名前は node-config.yaml) を指定することにより実行できます。

    kubeletArguments:
      config:
        - "/etc/origin/node"  1
    1
    --config=<dir> が指定されている場合、ここでは <dir> を使用します。

    resource-reserver.yaml ファイルが有効な状態でノードサーバーを起動すると、sleep-forever コンテナーも起動します。スケジューラーはノードの残りの容量も考慮し、クラスター Pod を配置する場所を適宜調整します。

    resource-reserver Pod を削除するには、ノード設定ディレクトリーから resource-reserver.yaml ファイルを削除するか、またはこれを移動することができます。

23.6.4. カーネルの調整可能なフラグ

ノードが起動すると、メモリー管理用のカーネルの調整可能なフラグが適切に設定されます。カーネルは、物理メモリーが不足しない限り、メモリーの割り当てに失敗するこはありません。

この動作を確認するために、ノードはカーネルに対し、常にメモリーのオーバーコミットを実行するように指示します。

$ sysctl -w vm.overcommit_memory=1

また、ノードはカーネルに対し、メモリーが不足する状況でもパニックにならないように指示します。その代わりに、カーネルの OOM killer は優先順位に基づいてプロセスを強制終了します。

$ sysctl -w vm.panic_on_oom=0
注記

上記のフラグはノード上にすでに設定されているはずであるため、追加のアクションは不要です。

23.6.5. swap メモリーの無効化

QoS 保証を維持するため、swap はノード上でデフォルトで無効にすることができます。そうしない場合、ノードの物理リソースがオーバーサブスクライブし、Pod の配置時の Kubernetes スケジューラーによるリソース保証が影響を受ける可能性があります。

たとえば、2 つの Guaranteed pod がメモリー制限に達した場合、それぞれのコンテナーが swap メモリーを使用し始める可能性があります。十分な swap 領域がない場合には、pod のプロセスはシステムのオーバーサブスクライブのために終了する可能性があります。

swap を無効にするには、以下を実行します。

$ swapoff -a

swap を無効にしないと、ノードが MemoryPressure にあることを認識しなくなり、Pod がスケジューリング要求に対応するメモリーを受け取れなくなります。結果として、追加の Pod がノードに配置され、メモリー不足の状態が加速し、最終的にはシステムの Out Of Memory (OOM) イベントが発生するリスクが高まります。

重要

swap が有効にされている場合、利用可能なメモリーについての リソース不足の処理 (out of resource handling) のエビクションしきい値は予想通りに機能しなくなります。メモリー不足の状態の場合に Pod をノードからエビクトし、Pod を不足状態にない別のノードで再スケジューリングできるようにリソース不足の処理 (out of resource handling) を利用できるようにします。

第24章 Ingress トラフィックの固有の外部 IP の割り当て

24.1. 概要

外部トラフィックをクラスターにつなぐ方法の 1 つとして、ExternalIP または IngressIP アドレスを使用することができます。

重要

この機能は、クラウド以外のデプロイメントでのみサポートされます。クラウド (GCE、AWS、および OpenStack) デプロイメントの場合、ロードバランサーサービスを使用し、クラウドの自動デプロイメントでサービスのエンドポイントをターゲットに設定します。

OpenShift Container Platform は 2 つの IP アドレスのプールをサポートします。

  • IngressIP は、サービスの外部 IP アドレスを選択する場合に Loadbalancer で使用されます。
  • ExternalIP は、ユーザーが設定されたプールから特定 IP を選択する場合に使用されます。
注記

これらはいずれも、ネットワークインターフェースコントローラー (NIC) または仮想イーサネット、または外部ルーティングのいずれであっても、使用される OpenShift Container Platform ホストのデバイスに設定される必要があります。この場合、Ipfailover はホストを設定し、NIC を設定するため、これを使用することが推奨されます。

IngressIP および ExternalIP はいずれも外部トラフィックのクラスターへのアクセスを可能にし、適切にルーティングされている場合に、外部トラフィックはサービスが公開する TCP/UDP ポート経由でサービスのエンドポイントに到達できます。これは、外部 IP をサービスに手動で割り当てる際に、制限された数の共有 IP アドレスのポート領域を管理しなくてはならない場合よりも単純になります。またこれらのアドレスは、高可用性を設定する場合に仮想 IP (VIP) としても使用できます。

OpenShift Container Platform は IP アドレスの自動および手動割り当ての両方をサポートしており、それぞれのアドレスは 1 つのサービスの最大数に割り当てられることが保証されます。これにより、各サービスは、ポートが他のサービスで公開されているかによらず、自らの選択したポートを公開できます。

24.2. 制限

ExternalIP を使用するには、以下を実行できます。

  • externalIPNetworkCIDRs 範囲から IP アドレスを選択します。
  • マスター設定ファイルで、IP アドレスを ingressIPNetworkCIDR プールから割り当てます。この場合、OpenShift Container Platform はローカルバランサーサービスタイプのクラウド以外のバージョンを実装し、IP アドレスをサービスに割り当てます。

    注意

    割り当てた IP アドレスがクラスター内の 1 つ以上のノードで終了することを確認する必要があります。既存の oc adm ipfailover を使用して外部 IP の可用性が高いことを確認します。

手動で設定された外部 IP の場合、起こり得るポートのクラッシュについては 「first-come, first-served (先着順)」で処理されます。ポートを要求する場合、その IP アドレスに割り当てられていない場合にのみ利用可能となります。以下は例になります。

手動で設定された外部 IP のポートのクラッシュ例

2 つのサービスが同じ外部 IP アドレス 172.7.7.7 で手動で設定されている。

MongoDB service A がポート 27017 を要求し、次に MongoDB service B が同じポートを要求する。最初の要求がこのポートを取得します。

ただし、Ingress コントローラーが外部 IP を割り当てる場合、ポートのクラッシュは問題とはなりません。コントローラーが各サービスに固有のアドレスを割り当てるためです。

24.3. 固有の外部 IP を使用するようクラスターを設定する

クラウド以外のクラスターで、ingressIPNetworkCIDR はデフォルトで 172.29.0.0/16 に設定されています。クラスター環境がこのプライベート範囲をまだ使用していない場合は、このデフォルトを使用できます。ただし、異なる範囲を使用する必要がある場合は、ingress IP を割り当てる前に、/etc/origin/master/master-config.yaml ファイルで ingressIPNetworkCIDR を設定する必要があります。次に、マスターサービスを再起動します。

注意

LoadBalancer タイプのサービスに割り当てられる外部 IP は常に ingressIPNetworkCIDR の範囲にあります。ingressIPNetworkCIDR が割り当てられた外部 IP がこの範囲内からなくなるように変更される場合、影響を受けるサービスには、新規の範囲と互換性のある新規の外部 IP が割り当てられます。

注記

高可用性を使用している場合、この範囲は 255 IP アドレスより少なくなければなりません。

/etc/origin/master/master-config.yaml のサンプル

networkConfig:
  ingressIPNetworkCIDR: 172.29.0.0/16

24.3.1. サービスの Ingress IP の設定

Ingress IP を割り当てるには、以下を実行します。

  1. loadBalancerIP 設定で特定の IP を要求する LoadBalancer サービスの YAML ファイルを作成します。

    LoadBalancer 設定サンプル

    apiVersion: v1
    kind: Service
    metadata:
      name: egress-1
    spec:
      ports:
      - name: db
        port: 3306
      loadBalancerIP: 172.29.0.1
      type: LoadBalancer
      selector:
        name: my-db-selector

  2. Pod に LoadBalancer サービスを作成します。

    $ oc create -f loadbalancer.yaml
  3. 外部 IP のサービスを確認します。たとえば、myservice という名前のサービスを確認します。

    $ oc get svc myservice

    LoadBalancer タイプのサービスに外部 IP が割り当てられている場合、出力には IP が表示されます。

    NAME         CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
    myservice    172.30.74.106   172.29.0.1    3306/TCP    30s

24.4. 開発またはテスト目的での Ingress CIDR のルーティング

ingress CIDR のトラフィックをクラスターのノードに送信する静的ルートを追加します。以下は例になります。

# route add -net 172.29.0.0/16 gw 10.66.140.17 eth0

上記の例では、172.29.0.0/16ingressIPNetworkCIDR10.66.140.17 はノード IP です。

24.4.1. サービス externalIP

クラスターの内部 IP アドレスに加えて、アプリケーション開発者はクラスターの外部にある IP アドレスを設定することができます。OpenShift Container Platform 管理者は、トラフィックがこの IP を持つノードに到達することを確認する必要があります。

externalIP は、master-config.yaml ファイルで設定される externalIPNetworkCIDRs 範囲から管理者によって選択される必要があります。master-config.yaml が変更される際に、マスターサービスは再起動される必要があります。

# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers

externalIPNetworkCIDR /etc/origin/master/master-config.yaml のサンプル

networkConfig:
  externalIPNetworkCIDR: 172.47.0.0/24

サービス externalIP 定義 (JSON)

{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "my-service"
    },
    "spec": {
        "selector": {
            "app": "MyApp"
        },
        "ports": [
            {
                "name": "http",
                "protocol": "TCP",
                "port": 80,
                "targetPort": 9376
            }
        ],
        "externalIPs" : [
            "80.11.12.10"         1
        ]
    }
}

1
ポート が公開される外部 IP アドレスの一覧です (これは内部 IP アドレス一覧に追加される一覧です)。

第25章 Out of Resource (リソース不足) エラーの処理

25.1. 概要

このトピックでは、OpenShift Container Platform がメモリー不足 (OOM) やディスク領域不足の状況を防ぐためのベストエフォートの取り組みについて説明します。

ノードは、利用可能なコンピュートリソースが少ない場合に安定性を維持する必要があります。これは、メモリーやディスクなどの圧縮不可能なリソースを扱う場合にとくに重要になります。どちらかのリソースが消費されると、ノードは不安定になります。

管理者は、エビクションポリシーを使用してノードをプロアクティブにモニターし、ノードでコンピュートリソースおよびメモリーリソースが不足する状況を防ぐことができます。

このトピックでは、OpenShift Container Platform がリソース不足の状況に対処する方法についての情報を提供し、シナリオ例推奨される対策について説明します。

警告

swap メモリーがノードに対して有効にされる場合、ノードは MemoryPressure 状態にあるかどうかを検知できません。

メモリーベースのエビクションを利用するには、オペレーターは swap を無効にする必要があります。

25.2. エビクションポリシーの設定

エビクションポリシー により、ノードが利用可能なリソースが少ない状況で実行されている場合に 1 つ以上の Pod が失敗することを許可します。Pod の失敗により、ノードは必要なリソースを回収できます。

エビクションポリシーは、エビクショントリガーシグナルと、ノード設定ファイルまたはコマンドラインで設定される特定のエビクションしきい値の組み合わせです。エビクションは、ノードがしきい値を超える Pod に対して即時のアクションを実行するハードエビクションか、またはノードがアクションを実行する前の猶予期間を許可するソフトエビクションのどちらかになります。ハードおよびソフトエビクションの違いという重要な情報については、以下のセクションを参照してください。

適切に設定されたエビクションポリシーを使用することで、ノードは、プロアクティブにモニターし、コンピュートリソースを完全に使い切る事態を防ぐことができます。

注記

ノードによる Pod の失敗が生じる場合、Pod 内のすべてのコンテナーが停止し、PodPhaseFailed に切り替わります。

25.2.1. ノード設定を使用したポリシーの作成

エビクションポリシーを設定するには、ノード設定ファイル (/etc/origin/node/node-config.yaml ファイル) を編集して eviction-hard または eviction-soft パラメーターでエビクションしきい値を指定します。

以下に例を示します。

例25.1 ハードエビクションについてのノード設定ファイルのサンプル

kubeletArguments:
  eviction-hard: 1
  - memory.available<500Mi2
  - nodefs.available<500Mi
  - nodefs.inodesFree<100Mi
  - imagefs.available<100Mi
  - imagefs.inodesFree<100Mi
1
エビクションのタイプ: ハードエビクションにこのパラメーターを使用します。
2
特定のエビクショントリガーシグナルに基づくエビクションのしきい値です。

例25.2 ソフトエビクションについてのノード設定ファイルのサンプル

kubeletArguments:
  eviction-soft: 1
  - memory.available<500Mi 2
  - nodefs.available<500Mi
  - nodefs.inodesFree<100Mi
  - imagefs.available<100Mi
  - imagefs.inodesFree<100Mi
  eviction-soft-grace-period:3
  - memory.available=1m30s
  - nodefs.available=1m30s
  - nodefs.inodesFree=1m30s
  - imagefs.available=1m30s
  - imagefs.inodesFree=1m30s
1
エビクションのタイプ: ソフトエビクションにこのパラメーターを使用します。
2
特定のエビクショントリガーシグナルに基づくエビクションのしきい値です。
3
ソフトエビクションの猶予期間です。パフォーマンスを最適化するためにデフォルト値のままにします。
  1. 変更を有効するために OpenShift Container Platform サービスを再起動します。

    # systemctl restart atomic-openshift-node

25.2.2. エビクションシグナルについて

以下の表にあるシグナルのいずれかに基づいてエビクションの意思決定をトリガーするようノードを設定することができます。エビクションシグナルは、しきい値と共にエビクションのしきい値に追加できます。

各シグナルの値は、ノード要約 API に基づいて Description 列で説明されています。

シグナルを表示するには、以下を実行します。

curl <certificate details> \
  https://<master>/api/v1/nodes/<node>/proxy/stats/summary

表25.1 サポートされるエビクションシグナル

ノードの状態エビクションシグナル説明

MemoryPressure

memory.available

memory.available = node.status.capacity[memory] - node.stats.memory.workingSet

ノードの利用可能なメモリーがエビクションしきい値を超えている。

DiskPressure

nodefs.available

nodefs.available = node.stats.fs.available

ノードの root ファイルシステムまたはイメージファイルシステムのいずれかで利用可能なディスク領域がエビクションしきい値を超えている。

nodefs.inodesFree

nodefs.inodesFree = node.stats.fs.inodesFree

imagefs.available

imagefs.available = node.stats.runtime.imagefs.available

imagefs.inodesFree

imagefs.inodesFree = node.stats.runtime.imagefs.inodesFree

上記のシグナルのそれぞれは、リテラル値またはパーセンテージベースの値のいずれかをサポートします。パーセンテージベースの値は、各シグナルに関連付けられる合計容量との関連で計算されます。

スクリプトは kubelet が実行する一連の手順を使用し、cgroup から memory.available 値を派生させます。スクリプトは計算から非アクティブなファイルメモリー (つまり、非アクティブな LRU リストのファイルベースのメモリーのバイト数) を計算から除外します。非アクティブなファイルメモリーはリソースの不足時に回収可能になることが想定されます。

注記

free -m はコンテナーで機能しないため、free -m のようなツールは使用しないでください。

ノードは、以下のようにディスクの不足状態を検出する際に nodefs および imagefs ファイルシステムのパーティションをサポートします。

  • nodefs ファイルシステムは、ノードがローカルディスク、デーモンログなど (/ を指定するファイルシステムなど) に使用するファイルシステムです。
  • imagefs ファイルシステムは、コンテナーランタイムがイメージおよび個別のコンテナーの書き込み可能な層を保存するために使用するファイルシステムです。

OpenShift Container Platform はこれらのファイルシステムを 10 秒ごとにモニターします。

ボリュームおよびログを専用ファイルシステムに保存する場合、ノードはそのファイルシステムをモニターしません。

注記

OpenShift Container Platform 3.4, の時点で、ノードはディスク不足に基づくエビクションの意思決定をトリガーする機能をサポートします。ディスク不足のために Pod をエビクトする前に、ノードはコンテナーおよびイメージのガべージコレクションも実行します。今後のリリースでは、ガべージコレクションは、純粋なディスクのエビクションベースの設定が優先されるために非推奨になります。

25.2.3. エビクションのしきい値について

しきい値をノード設定ファイルに追加することで、ノードのリソース回収をトリガーするエビクションしきい値を指定するようノードを設定することができます。

関連付けられた猶予期間とは別にエビクションのしきい値に達する場合、ノードは、ノードがメモリー不足またはディスク不足であることを示す状態を報告します。これにより、スケジューラーがリソース回収の試行期間中に Pod をノードにスケジュールすることを防ぐことができます。

ノードは、node-status-update-frequency 引数で指定される頻度で、ノードのステータス更新を継続的に報告します。これはデフォルトで 10s (10 秒) に設定されています。

エビクションのしきい値は、しきい値に達する際にノードが即時にアクションを実行する場合にハード となり、リソース回収前の猶予期間を許可する場合はソフトになります。

注記

ソフトエビクションは、特定レベルの使用状況をターゲットとしているものの、一時的な値の上昇を許容できる場合により一般的に使用されます。ソフトエビクションは、ハードエビクションのしきい値よりも低く設定することが推奨されますが、期間はオペレーターが固有に設定できます。システム予約もソフトエビクションのしきい値以上に設定する必要があります。

ソフトエビクションのしきい値は高度な機能になります。ソフトエビクションのしきい値の使用を試行する前にハードエビクションのしきい値を設定してください。

しきい値は以下の形式で設定されます。

<eviction_signal><operator><quantity>
  • eviction-signal 値は任意のサポートされるエビクションシグナルにすることができます。
  • operator 値は < になります。
  • quantity 値は、Kubernetes で使用される数量表現と一致している必要があり、% トークンで終了する場合はパーセンテージで表現されます。

たとえば、オペレーターが 10Gi メモリーのあるノードを持つ場合で、オペレーターは利用可能なメモリーが 1Gi を下回る場合にエビクションを導入する必要がある場合、メモリーのエビクションしきい値は以下のいずれかで指定することができます。

memory.available<1Gi
memory.available<10%
注記

ノードはエビクションしきい値の評価とモニターを 10 秒ごとに実行し、値を変更することはできません。これはハウスキープ処理の間隔になります。

25.2.3.1. ハードエビクションのしきい値について

ハードエビクションのしきい値には猶予期間がなく、しきい値を超えることが確認される場合には、ノードは関連付けられた不足状態にあるリソースを回収するために即時のアクションを実行します。ハードエビクションのしきい値に達する場合、ノードは正常な終了なしに Pod を即時に強制終了します。

ハードエビクションのしきい値を設定するには、「ポリシー作成のためのノード設定の使用」に示されるように、エビクションしきい値を eviction-hard の下にあるノード設定ファイルに追加します。

ハードエビクションのしきい値が設定されたノード設定ファイルのサンプル

kubeletArguments:
  eviction-hard:
  - memory.available<500Mi
  - nodefs.available<500Mi
  - nodefs.inodesFree<100Mi
  - imagefs.available<100Mi
  - imagefs.inodesFree<100Mi

この例は一般的なガイドラインを示すためのもので、推奨される設定ではありません。

25.2.3.1.1. デフォルトのハードエビクションしきい値

OpenShift Container Platform は、eviction-hard の以下のデフォルト設定を使用します。

...
kubeletArguments:
  eviction-hard:
  - memory.available<100Mi
  - nodefs.available<10%
  - nodefs.inodesFree<5%
  - imagefs.available<15%
...

25.2.3.2. ソフトエビクションのしきい値について

ソフトエビクションのしきい値は、エビクションしきい値と管理者が指定する必要な猶予期間のペアを設定します。ノードは、猶予期間が経過するまではエビクションシグナルに関連付けられたリソースを回収しません。猶予期間がノード設定ファイルに指定されない場合、ノードは起動時にエラーを出して失敗します。

さらにソフトエビクションのしきい値に達する場合、オペレーターは Pod をノードからエビクトする際に使用する Pod 終了の猶予期間として許可される最長期間を指定できます。eviction-max-pod-grace-period が指定されると、ノードは pod.Spec.TerminationGracePeriodSeconds と maximum-allowed-grace-period の値の小さい方を使用します。これが指定されていない場合は、ノードは正常な停止なしに、Pod を即時に強制終了します。

ソフトエビクションのしきい値については、以下のフラグがサポートされています。

  • eviction-soft: エビクションしきい値のセットです (例: memory.available<1.5Gi)。対応する猶予期間を経過してからこの値に達すると、Pod のエビクションをトリガーします。
  • eviction-soft-grace-period: エビクションの猶予期間のセットです (例: memory.available=1m30s)。これは、Pod のエビクションをトリガーするまでソフトエビクションのしきい値が有効である期間に対応します。
  • eviction-max-pod-grace-period: ソフトエビクションのしきい値に達する際の Pod の終了時に使用される最長で許可される猶予期間 (秒単位) です。

ソフトエビクションのしきい値を設定するには、「ポリシー作成のためのノード設定の使用」に示されるように、エビクションのしきい値を eviction-soft の下にあるノード設定ファイルに追加します。

ソフトエビクションのしきい値が設定されたノード設定ファイルのサンプル

kubeletArguments:
  eviction-soft:
  - memory.available<500Mi
  - nodefs.available<500Mi
  - nodefs.inodesFree<100Mi
  - imagefs.available<100Mi
  - imagefs.inodesFree<100Mi
  eviction-soft-grace-period:
  - memory.available=1m30s
  - nodefs.available=1m30s
  - nodefs.inodesFree=1m30s
  - imagefs.available=1m30s
  - imagefs.inodesFree=1m30s

この例は一般的なガイドラインを示すためのもので、推奨される設定ではありません。

25.3. スケジューリング用のリソース量の設定

スケジューラーがノードを完全に割り当て、エビクションを防止できるようにするために、スケジューリングで利用できるノードリソースの数量を制御できます。

system-reserved を、Pod のデプロイおよび system-daemon 用にスケジューラーで利用可能にするリソース量と等しくなるようにします。エビクションは、Pod が割り当て可能なリソースの要求量よりも多くのリソースを使用する場合に生じます。

ノードは 2 つの値を報告します。

  • Capacity: マシンにあるリソースの量です。
  • Allocatable: スケジューリング用に利用可能にされるリソースの量です。

割り当て可能なリソースの量を設定するには、ノード設定ファイル (/etc/origin/node/node-config.yaml ファイル) を編集し、eviction-hard または eviction-softsystem-reserved パラメーターを追加するか、または変更します。

+

kubeletArguments:
  eviction-hard: 1
    - "memory.available<500Mi"
  system-reserved:
    - "1.5Gi"
1
このしきい値は、eviction-hard または eviction-soft のいずれかにできます。
  1. 変更を有効するために OpenShift Container Platform サービスを再起動します。

    # systemctl restart atomic-openshift-node

25.4. ノードの状態変動の制御

ノードがソフトエビクトしきい値の上下で変動しているものの、関連付けられた猶予期間を超えていない場合、対応するノード状態は truefalse の間で変動します。これにより、スケジュールの問題が生じる場合があります。

この変動を防ぐには、eviction-pressure-transition-period パラメーターを設定して、ノードが不足状態からの切り換え前に待機する期間を制御します。

  1. <resource_type>=<resource_quantity> のペアを使用してこのパラメーターを編集するか、またはこれをノード設定ファイル (/etc/origin/node/node-config.yaml) の kubeletArgumentsセクションに追加します。
kubeletArguments:
  eviction-pressure-transition-period="5m"

+ ノードは、指定期間の指定された不足状態についてエビクションしきい値に達していないことを確認する場合に状態を false に戻します。

+

注記

調整を行う前にデフォルト値 (5 分) を使用します。このデフォルト値のオプションには、システムを安定させ、安定した状態になる前にスケジューラーが新規 Pod をノードに割り当てないようにすることが意図されています。

  1. 変更を有効するために OpenShift Container Platform サービスを再起動します。

    # systemctl restart atomic-openshift-node

25.5. ノードレベルのリソースの回収

エビクション条件が満たされる場合、ノードはシグナルが定義されたしきい値を下回るまで、不足状態にあるリソースを回収するプロセスを実行します。このプロセスでは、ノードはいずれの新規 Pod のスケジューリングもサポートしません。

ノードは、ホストシステムにコンテナーランタイム用の専用 imagefs が設定されているかどうかに基づいて、エンドユーザー Pod のエビクト前にノードレベルのリソース回収を試行します。

Imagefs が設定されている場合

ホストシステムに imagefs が設定されている場合:

  • nodefs ファイルシステムがエビクションしきい値を満たす場合、ノードは以下の順番でディスク領域を解放します。

    • 実行されない Pod/コンテナーの削除
  • imagefs ファイルシステムがエビクションのしきい値を満たす場合、ノードは以下の順番でディスク領域を解放します。

    • すべての未使用イメージの削除
Imagefs が設定されていない場合

ホストシステムに imagefs がされていない場合:

  • nodefs ファイルシステムがエビクションしきい値を満たす場合、ノードは以下の順番でディスク領域を解放します。

    • 実行されない Pod/コンテナーの削除
    • すべての未使用イメージの削除

25.6. Pod エビクションについて

エビクションしきい値に達し、猶予期間を経過している場合、ノードはシグナルが定義されたしきい値を下回るまで Pod のエビクトのプロセスを実行します。

ノードは、エビクトする Pod を QoS (Quality of Service) に基づいてランク付けし、同じQoS レベルにある Pod については Pod のスケジューリング要求との関連で不足状態のリソースの消費量に基づいてランク付けします。

それぞれの QoS レベルには OOM スコープが設定されており、Linux out-of-memory ツール (OOM killer) はこのスコープを使用して強制終了する Pod を判別します。以下の「QoS および Out of Memory Killer について」を参照してください。

以下の表には、各 QoS レベルと関連付けられた OOM スコアが一覧表示されています。

表25.2 Quality of Service (QoS) レベル

QoS (Quality of Service)説明

Guaranteed

要求との関連で不足状態にあるリソースの最大量を消費する Pod が最初に失敗します。いずれの Pod もその要求を超えていない場合、ストラテジーは不足状態にあるリソースを最も多く消費する Pod をターゲットにします。

Burstable

リソースの要求との関連で、不足状態にあるリソースの最大量を消費する Pod が最初に失敗します。いずれの Pod もその要求を超えていない場合、ストラテジーは不足状態にあるリソースを最も多く消費する Pod をターゲットにします。

BestEffort

不足状態にあるリソースの最大量を消費する Pod が最初に失敗します。

Guaranteed Pod は、(ノード、dockerjournald などの) システムデーモンが システム予約か、または kube 予約 の割り当てを使用して予約されている量よりも多くのリソースを消費しているか、またはノードに Guaranteed Pod のみが残っているのでない限り、別の Pod のリソース消費が原因でエビクトされることはありません。

ノードに Guaranteed Pod のみが残っている場合、ノードはノードの安定性に最も影響の少ない Guaranteed Pod をエビクトし、他の Guaranteed Pod に対する予想外の消費による影響を制限します。

ローカルディスクは BestEffort リソースです。必要な場合は、ノードは DiskPressure の発生時にディスクを回収するため、Pod を 1 度に 1 つずつエビクトします。ノードは QoS に基づいて Pod をランク付けします。ノードが inode の不足状態に対応している場合、ノードは QoS の最も低いレベルにある Pod を最初にエビクトして inode を回収します。ノードが利用可能なディスクの不足状態に対応している場合は、ノードはローカルディスクを最も多く消費する QoS 内の Pod をランク付けし、それらの Pod を最初にエビクトします。

25.6.1. QoS および Out of Memory Killer について

ノードによるメモリーの回収が可能になる前にシステムの OOM (Out of Memory) イベントが発生する場合、ノードの動作はこれに対応する OOM killer によって異なります。

ノードは、Pod の QoS に基づいて各コンテナーの oom_score_adj 値を設定します。

表25.3 Quality of Service (QoS) レベル

QoS (Quality of Service)oom_score_adj

Guaranteed

-998

Burstable

min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)

BestEffort

1000

ノードがシステムの OOM イベントが発生する前にメモリーを回収できない場合、oom_killeroom_score を計算します。

% of node memory a container is using + `oom_score_adj` = `oom_score`

次にノードは、スコアの最も高いコンテナーを強制終了します。

スケジューリング要求に関連してメモリーを最も多く消費する、QoS の最も低いレベルにあるコンテナーが最初に失敗します。

Pod のエビクションとは異なり、Pod コンテナーが OOM が原因で失敗する場合、ノードはノードの再起動ポリシーに基づいてこのコンテナーを再起動できます。

25.7. Pod スケジューラーおよび OOR 状態について

スケジューラーは、追加の Pod をノードに配置する際にノードの状態を表示します。たとえば、ノードに以下のようなエビクションのしきい値がある場合は、以下のようになります。

eviction-hard is "memory.available<500Mi"

さらに利用可能なメモリーが 500Mi を下回る場合、ノードは Node.Status.ConditionsMemoryPressure の値を true として報告します。

表25.4 ノードの状態およびスケジューラーの動作

ノードの状態スケジューラーの動作

MemoryPressure

ノードがこの状態を報告する場合、スケジューラーは BestEffort Pod をノードに配置しません。

DiskPressure

ノードがこの状態を報告する場合、スケジューラーは追加の Pod をノードに配置しません。

25.8. シナリオ例

以下のシナリオについて考えてみましょう。

オペレーター:

  • メモリー容量が 10Gi のノードがある。
  • システムデーモン (カーネル、ノードなど) のメモリー容量の 10% を予約する必要がある。
  • システムの OOM の悪化または発生の可能性を軽減するため、メモリー使用率が 95% の時点で Pod をエビクトする必要がある。

この設定から、system-reserved にはエビクションのしきい値でカバーされるメモリー量が含まれていることを読み取ることができます。

この容量に達するのは、一部の Pod による使用がその要求を超えるか、またはシステムによる使用が 1Gi を超える場合のいずれかになります。

ノードに 10 Gi の容量があり、システムデーモン (system-reserved) 用に 10% の容量を予約する必要がある場合、以下の計算を実行します。

capacity = 10 Gi
system-reserved = 10 Gi * .1 = 1 Gi

割り当て可能なリソースの量は以下のようになります。

allocatable = capacity - system-reserved = 9 Gi

これは、デフォルトでスケジューラーはノードに対し、9 Gi のメモリーを要求する Pod をスケジュールすることを意味します。

エビクションをオンに設定して、エビクションのトリガーが利用可能なメモリーが 30 秒間で 10% の容量を下回ることをノードで確認される場合や、5% の容量を下回る場合には即時にトリガーされるようにする必要がある場合、スケジューラーで 8Gi が割り当て可能であることを確認できる必要があります。そのため、システム予約ではエビクションしきい値の大きい方の値がカバーされている必要があります。

capacity = 10 Gi
eviction-threshold = 10 Gi * .1 = 1 Gi
system-reserved = (10Gi * .1) + eviction-threshold = 2 Gi
allocatable = capacity - system-reserved = 8 Gi

node-config.yaml に以下を入力します。

kubeletArguments:
  system-reserved:
  - "2Gi"
  eviction-hard:
  - memory.available<.5Gi
  eviction-soft:
  - memory.available<1Gi
  eviction-soft-grace-period:
  - memory.available=30s

この設定により、スケジューラーは Pod が設定される要求を下回る量のメモリーを使用することを前提とし、メモリー不足を即時に発生させ、エビクションをトリガーする Pod をノードに配置しないようにします。