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

ノード

OpenShift Container Platform 4.6

OpenShift Container Platform でのノードの設定および管理

概要

本書では、クラスターのノード、Pod、コンテナーを設定し管理する方法について説明します。また、Pod のスケジューリングや配置の設定方法、ジョブや DeamonSet を使用してタスクを自動化する方法やクラスターを効率化するための他のタスクなどに関する情報も提供します。

第1章 ノードの概要
リンクのコピー

1.1. ノードについて
リンクのコピー

ノードは、Kubernetes クラスター内の仮想マシンまたはベアメタルマシンです。ワーカーノードは、Pod としてグループ化されたアプリケーションコンテナーをホストします。コントロールプレーンノードは、Kubernetes クラスターを制御するために必要なサービスを実行します。OpenShift Container Platform では、コントロールプレーンノードには、OpenShift ContainerPlatform クラスターを管理するための Kubernetes サービス以上のものが含まれています。

クラスター内に安定した正常なノードを持つことは、ホストされたアプリケーションがスムーズに機能するための基本です。OpenShift Container Platform では、ノードを表す Node オブジェクトを介して Node にアクセス、管理、およびモニターできます。OpenShift CLI (oc) または Web コンソールを使用して、ノードで以下の操作を実行できます。

読み取り操作

読み取り操作により、管理者または開発者は OpenShift ContainerPlatform クラスター内のノードに関する情報を取得できます。

管理操作

管理者は、次のいくつかのタスクを通じて、OpenShift ContainerPlatform クラスター内のノードを簡単に管理できます。

  • ノードラベルを追加または更新します。ラベルは、Node オブジェクトに適用されるキーと値のペアです。ラベルを使用して Pod のスケジュールを制御できます。
  • カスタムリソース定義 (CRD) または kubeletConfig オブジェクトを使用してノード設定を変更します。
  • Pod のスケジューリングを許可または禁止するようにノードを設定します。ステータスが Ready の正常なワーカーノードでは、デフォルトで Pod の配置が許可されますが、コントロールプレーンノードでは許可されません。このデフォルトの動作を変更するには、ワーカーノードをスケジュール不可に設定 し、コントロールプレーンノードをスケジュール可能に設定 します。
  • system-reserved 設定を使用して、ノードにリソースを割り当てます。OpenShift Container Platform がノードに最適な system-reservedCPU およびメモリーリソースを自動的に決定できるようにするか、ノードに最適なリソースを手動で決定および設定することができます。
  • ノード上のプロセッサーコアの数、ハード制限、またはその両方に基づいて、ノード上で実行できる Pod の数を設定 します。
  • Pod の非アフィニティー を使用して、ノードを正常に再起動します。
  • マシンセットを使用してクラスターをスケールダウンすることにより、クラスターからノードを削除 します。ベアメタルクラスターからノードを削除するには、最初にノード上のすべての Pod をドレインしてから、手動でノードを削除する必要があります。
エンハンスメント操作

OpenShift Container Platform を使用すると、ノードへのアクセスと管理以上のことができます。管理者は、ノードで次のタスクを実行して、クラスターをより効率的でアプリケーションに適したものにし、開発者により良い環境を提供できます。

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

Pod は、ノードに一緒にデプロイされる 1 つ以上のコンテナーです。クラスター管理者は、Pod を定義し、スケジューリングの準備ができている正常なノードで実行するように割り当て、管理することができます。コンテナーが実行されている限り、Pod は実行されます。Pod を定義して実行すると、Pod を変更することはできません。Pod を操作するときに実行できる操作は次のとおりです。

読み取り操作

管理者は、次のタスクを通じてプロジェクト内の Pod に関する情報を取得できます。

管理操作

以下のタスクのリストは、管理者が OpenShift ContainerPlatform クラスターで Pod を管理する方法の概要を示しています。

エンハンスメント操作

OpenShift Container Platform で利用可能なさまざまなツールと機能を使用して、Pod をより簡単かつ効率的に操作できます。次の操作では、これらのツールと機能を使用して Pod をより適切に管理します。

Expand
操作ユーザー詳細情報

Horizontal Pod Autoscaler を作成して使用。

開発者

Horizontal Pod Autoscaler を使用して、実行する Pod の最小数と最大数、および Pod がターゲットとする CPU 使用率またはメモリー使用率を指定できます。水平 Pod オートスケーラーを使用すると、Pod を 自動的にスケーリング できます。

垂直 Pod オートスケーラーをインストールして使用。

管理者および開発者

管理者は、垂直 Pod オートスケーラーを使用して、リソースとワークロードのリソース要件を監視することにより、クラスターリソースをより適切に使用します。

開発者は、垂直 Pod オートスケーラーを使用して、各 Pod に十分なリソースがあるノードに Pod をスケジュールすることにより、需要が高い時に Pod が稼働し続けるようにします。

デバイスプラグインを使用して外部リソースへのアクセスを提供します。

Administrator

デバイスプラグイン は、ノード (kubelet の外部) で実行される gRPC サービスであり、特定のハードウェアリソースを管理します。デバイスプラグインを導入 して、クラスター全体でハードウェアデバイスを使用するための一貫性のあるポータブルソリューションを提供できます。

Secret オブジェクトを使用 して機密データを Pod に提供。

Administrator

一部のアプリケーションでは、パスワードやユーザー名などの機密情報が必要です。Secret オブジェクトを使用して、そのような情報をアプリケーション Pod に提供できます。

1.3. コンテナーについて
リンクのコピー

コンテナーは、OpenShift Container Platform アプリケーションの基本ユニットであり、依存関係、ライブラリー、およびバイナリーとともにパッケージ化されたアプリケーションコードで設定されます。コンテナーは、複数の環境、および物理サーバー、仮想マシン (VM)、およびプライベートまたはパブリッククラウドなどの複数のデプロイメントターゲット間に一貫性をもたらします。

Linux コンテナーテクノロジーは、実行中のプロセスを分離し、指定されたリソースのみへのアクセスを制限するための軽量メカニズムです。管理者は、Linux コンテナーで次のようなさまざまなタスクを実行できます。

OpenShift Container Platform は、Init コンテナー と呼ばれる特殊なコンテナーを提供します。Init コンテナーは、アプリケーションコンテナーの前に実行され、アプリケーションイメージに存在しないユーティリティーまたはセットアップスクリプトを含めることができます。Pod の残りの部分がデプロイされる前に、Init コンテナーを使用してタスクを実行できます。

ノード、Pod、およびコンテナーで特定のタスクを実行する以外に、OpenShift Container Platform クラスター全体を操作して、クラスターの効率とアプリケーション Pod の高可用性を維持できます。

第2章 Pod の使用
リンクのコピー

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

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

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

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

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

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

注記

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

警告

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

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

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

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

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

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

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

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

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

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

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

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

  serviceAccount: default
8 

  volumes:
9 

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

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

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

注記

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

2.2. Pod の表示
リンクのコピー

管理者として、クラスターで Pod を表示し、それらの Pod および全体としてクラスターの正常性を判別することができます。

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

OpenShift Container Platform は、Pod の Kubernetes の概念を活用しています。これはホスト上に共にデプロイされる 1 つ以上のコンテナーであり、定義され、デプロイされ、管理される最小のコンピュート単位です。Pod はコンテナーに対するマシンインスタンス (物理または仮想) とほぼ同等のものです。

特定のプロジェクトに関連付けられた Pod の一覧を表示したり、Pod についての使用状況の統計を表示したりすることができます。

2.2.2. プロジェクトでの Pod の表示
リンクのコピー

レプリカの数、Pod の現在のステータス、再起動の数および年数を含む、現在のプロジェクトに関連付けられた Pod の一覧を表示できます。

手順

プロジェクトで Pod を表示するには、以下を実行します。

  1. プロジェクトに切り替えます。 

    $ oc project <project-name>
    Copy to Clipboard Toggle word wrap

  2. 以下のコマンドを実行します。 

    $ oc get pods
    Copy to Clipboard Toggle word wrap

    以下に例を示します。 

    $ oc get pods -n openshift-console
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                       READY   STATUS    RESTARTS   AGE
console-698d866b78-bnshf   1/1     Running   2          165m
console-698d866b78-m87pm   1/1     Running   2          165m
    Copy to Clipboard Toggle word wrap

    -o wide フラグを追加して、Pod の IP アドレスと Pod があるノードを表示します。 

    $ oc get pods -o wide
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                       READY   STATUS    RESTARTS   AGE    IP            NODE                           NOMINATED NODE
console-698d866b78-bnshf   1/1     Running   2          166m   10.128.0.24   ip-10-0-152-71.ec2.internal    <none>
console-698d866b78-m87pm   1/1     Running   2          166m   10.129.0.23   ip-10-0-173-237.ec2.internal   <none>
    Copy to Clipboard Toggle word wrap

2.2.3. Pod の使用状況についての統計の表示
リンクのコピー

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

前提条件

  • 使用状況の統計を表示するには、cluster-reader パーミッションがなければなりません。
  • 使用状況の統計を表示するには、メトリクスをインストールしている必要があります。

手順

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

  1. 以下のコマンドを実行します。 

    $ oc adm top pods
    Copy to Clipboard Toggle word wrap

    以下に例を示します。 

    $ oc adm top pods -n openshift-console
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                         CPU(cores)   MEMORY(bytes)
console-7f58c69899-q8c8k     0m           22Mi
console-7f58c69899-xhbgg     0m           25Mi
downloads-594fcccf94-bcxk8   3m           18Mi
downloads-594fcccf94-kv4p6   2m           15Mi
    Copy to Clipboard Toggle word wrap

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

    $ oc adm top pod --selector=''
    Copy to Clipboard Toggle word wrap

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

2.2.4. リソースログの表示
リンクのコピー

OpenShift CLI (oc) および Web コンソールで、各種リソースのログを表示できます。ログの末尾から読み取られるログ。

前提条件

  • OpenShift CLI (oc) へのアクセス。

手順 (UI)

  1. OpenShift Container Platform コンソールで Workloads → Pods に移動するか、または調査するリソースから Pod に移動します。

    注記

    ビルドなどの一部のリソースには、直接クエリーする Pod がありません。このような場合には、リソースについて Details ページで Logs リンクを特定できます。

  2. ドロップダウンメニューからプロジェクトを選択します。
  3. 調査する Pod の名前をクリックします。
  4. Logs をクリックします。

手順 (CLI)

  • 特定の Pod のログを表示します。 

    $ oc logs -f <pod_name> -c <container_name>
    Copy to Clipboard Toggle word wrap

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

    -f
    オプション: ログに書き込まれている内容に沿って出力することを指定します。
    <pod_name>
    Pod の名前を指定します。
    <container_name>
    オプション: コンテナーの名前を指定します。Pod に複数のコンテナーがある場合、コンテナー名を指定する必要があります。

    以下に例を示します。 

    $ oc logs ruby-58cd97df55-mww7r
    Copy to Clipboard Toggle word wrap 
    $ oc logs -f ruby-57f7f4855b-znl92 -c ruby
    Copy to Clipboard Toggle word wrap

    ログファイルの内容が出力されます。

  • 特定のリソースのログを表示します。 

    $ oc logs <object_type>/<resource_name>
    1
    Copy to Clipboard Toggle word wrap
    1
    リソースタイプおよび名前を指定します。

    以下に例を示します。 

    $ oc logs deployment/ruby
    Copy to Clipboard Toggle word wrap

    ログファイルの内容が出力されます。

2.3. OpenShift Container Platform クラスターでの Pod の設定
リンクのコピー

管理者として、Pod に対して効率的なクラスターを作成し、維持することができます。

クラスターの効率性を維持することにより、1 回のみ実行するように設計された Pod をいつ再起動するか、Pod が利用できる帯域幅をいつ制限するか、中断時に Pod をどのように実行させ続けるかなど、Pod が終了するときの動作をツールとして使って必要な数の Pod が常に実行されるようにし、開発者により良い環境を提供することができます。

2.3.1. 再起動後の Pod の動作方法の設定
リンクのコピー

Pod 再起動ポリシーは、Pod のコンテナーの終了時に OpenShift Container Platform が応答する方法を決定します。このポリシーは Pod のすべてのコンテナーに適用されます。

以下の値を使用できます。

  • Always: Pod が再起動するまで、Pod で正常に終了したコンテナーの継続的な再起動を、指数関数のバックオフ遅延 (10 秒、20 秒、40 秒) で試行します。デフォルトは Always です。
  • OnFailure: Pod で失敗したコンテナーの継続的な再起動を、5 分を上限として指数関数のバックオフ遅延 (10 秒、20 秒、40 秒) で試行します。
  • Never: Pod で終了したコンテナーまたは失敗したコンテナーの再起動を試行しません。Pod はただちに失敗し、終了します。

いったんノードにバインドされた Pod は別のノードにはバインドされなくなります。これは、Pod がのノードの失敗後も存続するにはコントローラーが必要であることを示しています。

Expand
条件コントローラーのタイプ再起動ポリシー

(バッチ計算など) 終了することが予想される Pod

ジョブ

OnFailure または Never

(Web サービスなど) 終了しないことが予想される Pod

レプリケーションコントローラー

Always

マシンごとに 1 回実行される Pod

デーモンセット

すべて

Pod のコンテナーが失敗し、再起動ポリシーが OnFailure に設定される場合、Pod はノード上に留まり、コンテナーが再起動します。コンテナーを再起動させない場合には、再起動ポリシーの Never を使用します。

Pod 全体が失敗すると、OpenShift Container Platform は新規 Pod を起動します。開発者は、アプリケーションが新規 Pod で再起動される可能性に対応しなくてはなりません。とくに、アプリケーションは、一時的なファイル、ロック、以前の実行で生じた未完成の出力などを処理する必要があります。

注記

Kubernetes アーキテクチャーでは、クラウドプロバイダーからの信頼性のあるエンドポイントが必要です。クラウドプロバイダーが停止している場合、kubelet は OpenShift Container Platform が再起動されないようにします。

基礎となるクラウドプロバイダーのエンドポイントに信頼性がない場合は、クラウドプロバイダー統合を使用してクラスターをインストールしないでください。クラスターを、非クラウド環境で実行する場合のようにインストールします。インストール済みのクラスターで、クラウドプロバイダー統合をオンまたはオフに切り替えることは推奨されていません。

OpenShift Container Platform が失敗したコンテナーについて再起動ポリシーを使用する方法の詳細は、Kubernetes ドキュメントの State の例 を参照してください。

2.3.2. 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 に制限するには、以下を実行します。

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

    {
    "kind": "Pod",
    "spec": {
        "containers": [
            {
                "image": "openshift/hello-openshift",
                "name": "hello-openshift"
            }
        ]
    },
    "apiVersion": "v1",
    "metadata": {
        "name": "iperf-slow",
        "annotations": {
            "kubernetes.io/ingress-bandwidth": "10M",
            "kubernetes.io/egress-bandwidth": "10M"
        }
    }
}
    Copy to Clipboard Toggle word wrap

  2. オブジェクト定義を使用して Pod を作成します。 

    $ oc create -f <file_or_dir_path>
    Copy to Clipboard Toggle word wrap

2.3.3. Pod の Disruption Budget (停止状態の予算) を使って起動している Pod の数を指定する方法
リンクのコピー

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

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

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

  • 一連の Pod に対するラベルのクエリー機能であるラベルセレクター。

  • 同時に利用可能にする必要のある Pod の最小数を指定する可用性レベル。

    • minAvailable は、中断時にも常に利用可能である必要のある Pod 数です。
    • maxUnavailable は、中断時に利用不可にできる Pod 数です。
注記

maxUnavailable の 0% または 0 あるいは minAvailable の 100%、ないしはレプリカ数に等しい値は許可されますが、これによりノードがドレイン (解放) されないようにブロックされる可能性があります。

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

$ oc get poddisruptionbudget --all-namespaces
Copy to Clipboard Toggle word wrap

出力例

NAMESPACE         NAME          MIN-AVAILABLE   SELECTOR
another-project   another-pdb   4               bar=foo
test-project      my-pdb        2               foo=bar
Copy to Clipboard Toggle word wrap

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

注記

Pod の優先順位およびプリエンプションの設定に基づいて、優先順位の低い Pod は Pod の Disruption Budget の要件を無視して削除される可能性があります。

2.3.3.1. Pod の Disruption Budget を使って起動している Pod 数の指定
リンクのコピー

同時に起動している必要のあるレプリカの最小数またはパーセンテージは、PodDisruptionBudget オブジェクトを使って指定します。

手順

Pod の Disruption Budget を設定するには、以下を実行します。

  1. YAML ファイルを以下のようなオブジェクト定義で作成します。 

    apiVersion: policy/v1beta1
    1 
    
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  minAvailable: 2
    2 
    
  selector:
    3 
    
    matchLabels:
      foo: bar
    Copy to Clipboard Toggle word wrap
    1
    PodDisruptionBudget は policy/v1beta1 API グループの一部です。
    2
    同時に利用可能である必要のある Pod の最小数。これには、整数またはパーセンテージ (例: 20%) を指定する文字列を使用できます。
    3
    一連のリソースに対するラベルのクエリー。matchLabels と matchExpressions の結果は論理的に結合されます。

    または、以下を実行します。 

    apiVersion: policy/v1beta1
    1 
    
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  maxUnavailable: 25%
    2 
    
  selector:
    3 
    
    matchLabels:
      foo: bar
    Copy to Clipboard Toggle word wrap
    1
    PodDisruptionBudget は policy/v1beta1 API グループの一部です。
    2
    同時に利用不可にできる Pod の最大数。これには、整数またはパーセンテージ (例: 20%) を指定する文字列を使用できます。
    3
    一連のリソースに対するラベルのクエリー。matchLabels と matchExpressions の結果は論理的に結合されます。

  2. 以下のコマンドを実行してオブジェクトをプロジェクトに追加します。 

    $ oc create -f </path/to/file> -n <project_name>
    Copy to Clipboard Toggle word wrap

2.3.4. Critical Pod の使用による Pod の削除の防止
リンクのコピー

クラスターを十分に機能させるために不可欠であるのに、マスターノードではなく通常のクラスターノードで実行される重要なコンポーネントは多数あります。重要なアドオンをエビクトすると、クラスターが正常に動作しなくなる可能性があります。

Critical とマークされている Pod はエビクトできません。

手順

Pod を Citical にするには、以下を実行します。

  1. Pod 仕様を作成するか、または既存の Pod を編集して system-cluster-critical 優先順位クラスを含めます。 

    spec:
  template:
    metadata:
      name: critical-pod
    priorityClassName: system-cluster-critical
    1
    Copy to Clipboard Toggle word wrap
    1
    ノードからエビクトすべきではない Pod のデフォルトの優先順位クラス。

    または、クラスターにとって重要だが、必要に応じて削除できる Pod に system-node-critical を指定することもできます。

  2. Pod を作成します。 

    $ oc create -f <file-name>.yaml
    Copy to Clipboard Toggle word wrap

2.4. Horizontal Pod Autoscaler での Pod の自動スケーリング
リンクのコピー

開発者として、Horizontal Pod Autoscaler (HPA) を使って、レプリケーションコントローラーに属する Pod から収集されるメトリクスまたはデプロイメント設定に基づき、OpenShift Container Platform がレプリケーションコントローラーまたはデプロイメント設定のスケールを自動的に増減する方法を指定できます。

2.4.1. Horizontal Pod Autoscaler について
リンクのコピー

Horizontal Pod Autoscaler を作成することで、実行する Pod の最小数と最大数を指定するだけでなく、Pod がターゲットに設定する CPU の使用率またはメモリー使用率を指定することができます。

重要

メモリー使用率の自動スケーリングはテクノロジープレビュー機能のみとして提供されています。

Horizontal Pod Autoscaler を作成すると、OpenShift Container Platform は Pod で CPU またはメモリーリソースのメトリクスのクエリーを開始します。メトリクスが利用可能になると、Horizontal Pod Autoscaler は必要なメトリクスの使用率に対する現在のメトリクスの使用率の割合を計算し、随時スケールアップまたはスケールダウンを実行します。クエリーとスケーリングは一定間隔で実行されますが、メトリクスが利用可能になるでに 1 分から 2 分の時間がかかる場合があります。

レプリケーションコントローラーの場合、このスケーリングはレプリケーションコントローラーのレプリカに直接対応します。デプロイメント設定の場合、スケーリングはデプロイメント設定のレプリカ数に直接対応します。自動スケーリングは Complete フェーズの最新デプロイメントにのみ適用されることに注意してください。

OpenShift Container Platform はリソースに自動的に対応し、起動時などのリソースの使用が急増した場合など必要のない自動スケーリングを防ぎます。unready 状態の Pod には、スケールアップ時の使用率が 0 CPU と指定され、Autoscaler はスケールダウン時にはこれらの Pod を無視します。既知のメトリクスのない Pod にはスケールアップ時の使用率が 0% CPU、スケールダウン時に 100% CPU となります。これにより、HPA の決定時に安定性が増します。この機能を使用するには、readiness チェックを設定して新規 Pod が使用可能であるかどうかを判別します。

Horizontal Pod Autoscaler を使用するには、クラスターの管理者はクラスターメトリクスを適切に設定している必要があります。

2.4.1.1. サポートされるメトリクス
リンクのコピー

以下のメトリクスは Horizontal Pod Autoscaler でサポートされています。

Expand
表2.1 メトリクス
メトリクス説明API バージョン

CPU の使用率

使用されている CPU コアの数。Pod の要求される CPU の割合の計算に使用されます。

autoscaling/v1、autoscaling/v2beta2

メモリーの使用率

使用されているメモリーの量。Pod の要求されるメモリーの割合の計算に使用されます。

autoscaling/v2beta2

重要

メモリーベースの自動スケーリングでは、メモリー使用量がレプリカ数と比例して増減する必要があります。平均的には以下のようになります。

  • レプリカ数が増えると、Pod ごとのメモリー (作業セット) の使用量が全体的に減少します。
  • レプリカ数が減ると、Pod ごとのメモリー使用量が全体的に増加します。

OpenShift Container Platform Web コンソールを使用して、アプリケーションのメモリー動作を確認し、メモリーベースの自動スケーリングを使用する前にアプリケーションがそれらの要件を満たしていることを確認します。

以下の例は、image-registry DeploymentConfig オブジェクトの自動スケーリングを示しています。最初のデプロイメントでは 3 つの Pod が必要です。HPA オブジェクトは最小で 5 まで増加され、Pod 上の CPU 使用率が 75% に達すると、Pod を最大 7 まで増やします。 

$ oc autoscale dc/image-registry --min=5 --max=7 --cpu-percent=75
Copy to Clipboard Toggle word wrap

出力例

horizontalpodautoscaler.autoscaling/image-registry autoscaled
Copy to Clipboard Toggle word wrap

minReplicas が 3 に設定された image-registryDeploymentConfig オブジェクトのサンプル HPA

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: image-registry
  namespace: default
spec:
  maxReplicas: 7
  minReplicas: 3
  scaleTargetRef:
    apiVersion: apps.openshift.io/v1
    kind: DeploymentConfig
    name: image-registry
  targetCPUUtilizationPercentage: 75
status:
  currentReplicas: 5
  desiredReplicas: 0
Copy to Clipboard Toggle word wrap

  1. デプロイメントの新しい状態を表示します。 

    $ oc get dc image-registry
    Copy to Clipboard Toggle word wrap

    デプロイメントには 5 つの Pod があります。

    出力例

    NAME             REVISION   DESIRED   CURRENT   TRIGGERED BY
image-registry   1          5         5         config
    Copy to Clipboard Toggle word wrap

2.4.1.2. スケーリングポリシー
リンクのコピー

autoscaling/v2beta2 API を使用すると、スケーリングポリシー を Horizontal Pod Autoscaler に追加できます。スケーリングポリシーは、OpenShift Container Platform の Horizontal Pod Autoscaler (HPA) が Pod をスケーリングする方法を制御します。スケーリングポリシーにより、特定の期間にスケーリングするように特定の数または特定のパーセンテージを設定して、HPA が Pod をスケールアップまたはスケールダウンするレートを制限できます。固定化ウィンドウ (stabilization window) を定義することもできます。これはメトリクスが変動する場合に、先に計算される必要な状態を使用してスケーリングを制御します。同じスケーリングの方向に複数のポリシーを作成し、変更の量に応じて使用するポリシーを判別することができます。タイミングが調整された反復によりスケーリングを制限することもできます。HPA は反復時に Pod をスケーリングし、その後の反復で必要に応じてスケーリングを実行します。

スケーリングポリシーを適用するサンプル HPA オブジェクト

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-resource-metrics-memory
  namespace: default
spec:
  behavior:
    scaleDown:
1 

      policies:
2 

      - type: Pods
3 

        value: 4
4 

        periodSeconds: 60
5 

      - type: Percent
        value: 10
6 

        periodSeconds: 60
      selectPolicy: Min
7 

      stabilizationWindowSeconds: 300
8 

    scaleUp:
9 

      policies:
      - type: Pods
        value: 5
10 

        periodSeconds: 70
      - type: Percent
        value: 12
11 

        periodSeconds: 80
      selectPolicy: Max
      stabilizationWindowSeconds: 0
...
Copy to Clipboard Toggle word wrap

1
scaleDown または scaleUp のいずれかのスケーリングポリシーの方向を指定します。この例では、スケールダウンのポリシーを作成します。
2
スケーリングポリシーを定義します。
3
ポリシーが反復時に特定の Pod の数または Pod のパーセンテージに基づいてスケーリングするかどうかを決定します。デフォルト値は pods です。
4
反復ごとに Pod の数または Pod のパーセンテージのいずれかでスケーリングの量を決定します。Pod 数でスケールダウンする際のデフォルト値はありません。
5
スケーリングの反復の長さを決定します。デフォルト値は 15 秒です。
6
パーセンテージでのスケールダウンのデフォルト値は 100% です。
7
複数のポリシーが定義されている場合は、最初に使用するポリシーを決定します。最大限の変更を許可するポリシーを使用するように Max を指定するか、最小限の変更を許可するポリシーを使用するように Min を指定するか、または HPA がポリシーの方向でスケーリングしないように Disabled を指定します。デフォルト値は Max です。
8
HPA が必要とされる状態で遡る期間を決定します。デフォルト値は 0 です。
9
この例では、スケールアップのポリシーを作成します。
10
Pod 数によるスケールアップの量。Pod 数をスケールアップするためのデフォルト値は 4% です。
11
Pod のパーセンテージによるスケールアップの量。パーセンテージでスケールアップするためのデフォルト値は 100% です。

スケールダウンポリシーの例

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-resource-metrics-memory
  namespace: default
spec:
...
  minReplicas: 20
...
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Pods
        value: 4
        periodSeconds: 30
      - type: Percent
        value: 10
        periodSeconds: 60
      selectPolicy: Max
    scaleUp:
      selectPolicy: Disabled
Copy to Clipboard Toggle word wrap

この例では、Pod の数が 40 より大きい場合、パーセントベースのポリシーがスケールダウンに使用されます。このポリシーでは、 selectPolicy による要求により、より大きな変更が生じるためです。

80 の Pod レプリカがある場合、初回の反復で HPA は Pod を 8 Pod 減らします。これは、1 分間 (periodSeconds: 60) の (type: Percent および value: 10 パラメーターに基づく) 80 Pod の 10% に相当します。次回の反復では、Pod 数は 72 になります。HPA は、残りの Pod の 10% が 7.2 であると計算し、これを 8 に丸め、8 Pod をスケールダウンします。後続の反復ごとに、スケーリングされる Pod 数は残りの Pod 数に基づいて再計算されます。Pod の数が 40 未満の場合、Pod ベースの数がパーセントベースの数よりも大きくなるため、Pod ベースのポリシーが適用されます。HPA は、残りのレプリカ (minReplicas) が 20 になるまで、30 秒 (periodSeconds: 30) で一度に 4 Pod (type: Pods および value: 4) を減らします。

selectPolicy: Disabled パラメーターは HPA による Pod のスケールアップを防ぎます。必要な場合は、レプリカセットまたはデプロイメントセットでレプリカの数を調整して手動でスケールアップできます。

設定されている場合、oc edit コマンドを使用してスケーリングポリシーを表示できます。 

$ oc edit hpa hpa-resource-metrics-memory
Copy to Clipboard Toggle word wrap

出力例

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  annotations:
    autoscaling.alpha.kubernetes.io/behavior:\
'{"ScaleUp":{"StabilizationWindowSeconds":0,"SelectPolicy":"Max","Policies":[{"Type":"Pods","Value":4,"PeriodSeconds":15},{"Type":"Percent","Value":100,"PeriodSeconds":15}]},\
"ScaleDown":{"StabilizationWindowSeconds":300,"SelectPolicy":"Min","Policies":[{"Type":"Pods","Value":4,"PeriodSeconds":60},{"Type":"Percent","Value":10,"PeriodSeconds":60}]}}'
...
Copy to Clipboard Toggle word wrap

2.4.2. Web コンソールを使用した Horizontal Pod Autoscaler の作成
リンクのコピー

Web コンソールから、デプロイメントで実行する Pod の最小および最大数を指定する Horizontal Pod Autoscaler (HPA) を作成できます。Pod がターゲットに設定する CPU またはメモリー使用量を定義することもできます。

注記

HPA は、Operator がサポートするサービス、Knative サービス、または Helm チャートの一部であるデプロイメントに追加することはできません。

手順

Web コンソールで HPA を作成するには、以下を実行します。

  1. Topology ビューで、ノードをクリックしてサイドペインを表示します。

  2. Actions ドロップダウンリストから、Add HorizontalPodAutoscaler を選択して Add HorizontalPodAutoscaler フォームを開きます。

    図2.1 Horizontal Pod Autoscaler の追加

    Add HorizontalPodAutoscaler form
    View larger image
    Add HorizontalPodAutoscaler form

  3. Add HorizontalPodAutoscaler フォームから、名前、最小および最大の Pod 制限、CPU およびメモリーの使用状況を定義し、Save をクリックします。

    注記

    CPU およびメモリー使用量の値のいずれかが見つからない場合は、警告が表示されます。

Web コンソールで HPA を編集するには、以下を実行します。

  1. Topology ビューで、ノードをクリックしてサイドペインを表示します。
  2. Actions ドロップダウンリストから、Edit HorizontalPodAutoscaler を選択し、 Horizontal Pod Autoscaler フォームを開きます。
  3. Edit Horizontal Pod Autoscaler フォームから、最小および最大の Pod 制限および CPU およびメモリー使用量を編集し、Save をクリックします。
注記

Web コンソールで Horizontal Pod Autoscaler を作成または編集する際に、Form view から YAML viewに切り替えることができます。

Web コンソールで HPA を削除するには、以下を実行します。

  1. Topology ビューで、ノードをクリックし、サイドパネルを表示します。
  2. Actions ドロップダウンリストから、Remove HorizontalPodAutoscaler を選択します。
  3. 確認のポップアップウィンドウで、Remove をクリックして HPA を削除します。

2.4.3. CLI を使用した CPU 使用率向けの Horizontal Pod Autoscaler の作成
リンクのコピー

既存の Deployment、DeploymentConfig、ReplicaSet、ReplicationController 、または StatefulSet オブジェクトの水平 Pod オートスケーラー (HPA) を作成して、そのオブジェクトに関連付けられた Pod を自動的にスケーリングし、指定した CPU 使用率を維持できます。

HPA は、すべての Pod で指定された CPU 使用率を維持するために、最小数と最大数の間でレプリカ数を増減します。

CPU 使用率について自動スケーリングを行う際に、oc autoscale コマンドを使用し、実行する必要のある Pod の最小数および最大数と Pod がターゲットとして設定する必要のある平均 CPU 使用率を指定することができます。最小値を指定しない場合、Pod には OpenShift Container Platform サーバーからのデフォルト値が付与されます。特定の CPU 値について自動スケーリングを行うには、ターゲット CPU および Pod の制限のある HorizontalPodAutoscaler オブジェクトを作成します。

前提条件

Horizontal Pod Autoscaler を使用するには、クラスターの管理者はクラスターメトリクスを適切に設定している必要があります。メトリクスが設定されているかどうかは、oc describe PodMetrics <pod-name> コマンドを使用して判断できます。メトリクスが設定されている場合、出力は以下の Usage の下にある Cpu と Memory のように表示されます。 

$ oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Copy to Clipboard Toggle word wrap

出力例

Name:         openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Namespace:    openshift-kube-scheduler
Labels:       <none>
Annotations:  <none>
API Version:  metrics.k8s.io/v1beta1
Containers:
  Name:  wait-for-host-port
  Usage:
    Memory:  0
  Name:      scheduler
  Usage:
    Cpu:     8m
    Memory:  45440Ki
Kind:        PodMetrics
Metadata:
  Creation Timestamp:  2019-05-23T18:47:56Z
  Self Link:           /apis/metrics.k8s.io/v1beta1/namespaces/openshift-kube-scheduler/pods/openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Timestamp:             2019-05-23T18:47:56Z
Window:                1m0s
Events:                <none>
Copy to Clipboard Toggle word wrap

手順

CPU 使用率のための Horizontal Pod Autoscaler を作成するには、以下を実行します。

  1. 以下のいずれかを実行します。

    • CPU 使用率のパーセントに基づいてスケーリングするには、既存のオブジェクトとして HorizontalPodAutoscaler オブジェクトを作成します。 

      $ oc autoscale <object_type>/<name> \
      1 
      
  --min <number> \
      2 
      
  --max <number> \
      3 
      
  --cpu-percent=<percent>
      4
      Copy to Clipboard Toggle word wrap
      1
      自動スケーリングするオブジェクトのタイプと名前を指定します。オブジェクトが存在し、 Deployment、DeploymentConfig/dc、ReplicaSet/rs、ReplicationController/rc 、または StatefulSet である必要があります。
      2
      オプションで、スケールダウン時のレプリカの最小数を指定します。
      3
      スケールアップ時のレプリカの最大数を指定します。
      4
      要求された CPU のパーセントで表示された、すべての Pod に対する目標の平均 CPU 使用率を指定します。指定しない場合または負の値の場合、デフォルトの自動スケーリングポリシーが使用されます。

      たとえば、次のコマンドが示すように、image-registryDeploymentConfig オブジェクトの自動スケーリング。最初のデプロイメントでは 3 つの Pod が必要です。HPA オブジェクトは最小で 5 まで増加され、Pod 上の CPU 使用率が 75% に達すると、Pod を最大 7 まで増やします。 

      $ oc autoscale dc/image-registry --min=5 --max=7 --cpu-percent=75
      Copy to Clipboard Toggle word wrap

    • 特定の CPU 値に合わせてスケーリングするには、既存のオブジェクトに対して次のような YAML ファイルを作成します。

      1. 以下のような YAML ファイルを作成します。 

        apiVersion: autoscaling/v2beta2
        1 
        
kind: HorizontalPodAutoscaler
metadata:
  name: cpu-autoscale
        2 
        
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: v1
        3 
        
    kind: ReplicaSet
        4 
        
    name: example
        5 
        
  minReplicas: 1
        6 
        
  maxReplicas: 10
        7 
        
  metrics:
        8 
        
  - type: Resource
    resource:
      name: cpu
        9 
        
      target:
        type: AverageValue
        10 
        
        averageValue: 500m
        11
        Copy to Clipboard Toggle word wrap
        1
        autoscaling/v2beta2 API を使用します。
        2
        この Horizontal Pod Autoscaler オブジェクトの名前を指定します。
        3
        スケーリングするオブジェクトの API バージョンを指定します。
        • ReplicationController の場合は、 v1 を使用します。
        • DeploymentConfig の場合は、 apps.openshift.io/v1 を使用します。
        • Deployment、ReplicaSet、Statefulset オブジェクトの場合は、apps/v1 を使用します。
        4
        オブジェクトのタイプを指定します。オブジェクトは、 Deployment、DeploymentConfig/dc、ReplicaSet/rs、ReplicationController/rc 、または StatefulSet である必要があります。
        5
        スケーリングするオブジェクトの名前を指定します。オブジェクトが存在する必要があります。
        6
        スケールダウン時のレプリカの最小数を指定します。
        7
        スケールアップ時のレプリカの最大数を指定します。
        8
        メモリー使用率に metrics パラメーターを使用します。
        9
        CPU 使用率に cpu を指定します。
        10
        AverageValue に設定します。
        11
        ターゲットに設定された CPU 値で averageValue に設定します。

      2. Horizontal Pod Autoscaler を作成します。 

        $ oc create -f <file-name>.yaml
        Copy to Clipboard Toggle word wrap

  2. Horizontal Pod Autoscaler が作成されていることを確認します。 

    $ oc get hpa cpu-autoscale
    Copy to Clipboard Toggle word wrap

    出力例

    NAME            REFERENCE                       TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
cpu-autoscale   ReplicationController/example   173m/500m       1         10        1          20m
    Copy to Clipboard Toggle word wrap

2.4.4. CLI を使用したメモリー使用率向けの Horizontal Pod Autoscaler オブジェクトの作成
リンクのコピー

直接の値または要求されるメモリーのパーセンテージのいずれかで指定する平均のメモリー使用率を維持するために、オブジェクトに関連付けられた Pod を自動的にスケーリングする既存の DeploymentConfig オブジェクトまたは ReplicationController オブジェクトの Horizontal Pod Autoscaler (HPA) を作成できます。

HPA は、すべての Pod で指定のメモリー使用率を維持するために、最小数と最大数の間のレプリカ数を増減します。

メモリー使用率については、Pod の最小数および最大数と、Pod がターゲットとする平均のメモリー使用率を指定することができます。最小値を指定しない場合、Pod には OpenShift Container Platform サーバーからのデフォルト値が付与されます。

重要

メモリー使用率の自動スケーリングはテクノロジープレビュー機能としてのみ提供されています。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポートについての詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

前提条件

Horizontal Pod Autoscaler を使用するには、クラスターの管理者はクラスターメトリクスを適切に設定している必要があります。メトリクスが設定されているかどうかは、oc describe PodMetrics <pod-name> コマンドを使用して判断できます。メトリクスが設定されている場合、出力は以下の Usage の下にある Cpu と Memory のように表示されます。 

$ oc describe PodMetrics openshift-kube-scheduler-ip-10-0-129-223.compute.internal -n openshift-kube-scheduler
Copy to Clipboard Toggle word wrap

出力例

Name:         openshift-kube-scheduler-ip-10-0-129-223.compute.internal
Namespace:    openshift-kube-scheduler
Labels:       <none>
Annotations:  <none>
API Version:  metrics.k8s.io/v1beta1
Containers:
  Name:  scheduler
  Usage:
    Cpu:     2m
    Memory:  41056Ki
  Name:      wait-for-host-port
  Usage:
    Memory:  0
Kind:        PodMetrics
Metadata:
  Creation Timestamp:  2020-02-14T22:21:14Z
  Self Link:           /apis/metrics.k8s.io/v1beta1/namespaces/openshift-kube-scheduler/pods/openshift-kube-scheduler-ip-10-0-129-223.compute.internal
Timestamp:             2020-02-14T22:21:14Z
Window:                5m0s
Events:                <none>
Copy to Clipboard Toggle word wrap

手順

メモリー使用率の Horizontal Pod Autoscaler を作成するには、以下を実行します。

  1. 以下のいずれか 1 つを含む YAML ファイルを作成します。

    • 特定のメモリー値に合わせてスケーリングするには、既存の ReplicationController オブジェクトまたはレプリケーションコントローラーに対して、次のような HorizontalPodAutoscaler オブジェクトを作成します。

      出力例

      apiVersion: autoscaling/v2beta2
      1 
      
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-resource-metrics-memory
      2 
      
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: v1
      3 
      
    kind: ReplicationController
      4 
      
    name: example
      5 
      
  minReplicas: 1
      6 
      
  maxReplicas: 10
      7 
      
  metrics:
      8 
      
  - type: Resource
    resource:
      name: memory
      9 
      
      target:
        type: AverageValue
      10 
      
        averageValue: 500Mi
      11 
      
  behavior:
      12 
      
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Pods
        value: 4
        periodSeconds: 60
      - type: Percent
        value: 10
        periodSeconds: 60
      selectPolicy: Max
      Copy to Clipboard Toggle word wrap

      1
      autoscaling/v2beta2 API を使用します。
      2
      この Horizontal Pod Autoscaler オブジェクトの名前を指定します。
      3
      スケーリングするオブジェクトの API バージョンを指定します。
      • レプリケーションコントローラーについては、v1 を使用します。
      • DeploymentConfig オブジェクトについては、apps.openshift.io/v1 を使用します。
      4
      スケーリングするオブジェクトの種類 (ReplicationController または DeploymentConfig のいずれか) を指定します。
      5
      スケーリングするオブジェクトの名前を指定します。オブジェクトが存在する必要があります。
      6
      スケールダウン時のレプリカの最小数を指定します。
      7
      スケールアップ時のレプリカの最大数を指定します。
      8
      メモリー使用率に metrics パラメーターを使用します。
      9
      メモリー使用率の memory を指定します。
      10
      タイプを AverageValue に設定します。
      11
      averageValue および特定のメモリー値を指定します。
      12
      オプション: スケールアップまたはスケールダウンのレートを制御するスケーリングポリシーを指定します。

    • パーセンテージについてスケーリングするには、以下のように HorizontalPodAutoscaler オブジェクトを作成します。

      出力例

      apiVersion: autoscaling/v2beta2
      1 
      
kind: HorizontalPodAutoscaler
metadata:
  name: memory-autoscale
      2 
      
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps.openshift.io/v1
      3 
      
    kind: DeploymentConfig
      4 
      
    name: example
      5 
      
  minReplicas: 1
      6 
      
  maxReplicas: 10
      7 
      
  metrics:
      8 
      
  - type: Resource
    resource:
      name: memory
      9 
      
      target:
        type: Utilization
      10 
      
        averageUtilization: 50
      11 
      
  behavior:
      12 
      
    scaleUp:
      stabilizationWindowSeconds: 180
      policies:
      - type: Pods
        value: 6
        periodSeconds: 120
      - type: Percent
        value: 10
        periodSeconds: 120
      selectPolicy: Max
      Copy to Clipboard Toggle word wrap

      1
      autoscaling/v2beta2 API を使用します。
      2
      この Horizontal Pod Autoscaler オブジェクトの名前を指定します。
      3
      スケーリングするオブジェクトの API バージョンを指定します。
      • レプリケーションコントローラーについては、v1 を使用します。
      • DeploymentConfig オブジェクトについては、apps.openshift.io/v1 を使用します。
      4
      スケーリングするオブジェクトの種類 (ReplicationController または DeploymentConfig のいずれか) を指定します。
      5
      スケーリングするオブジェクトの名前を指定します。オブジェクトが存在する必要があります。
      6
      スケールダウン時のレプリカの最小数を指定します。
      7
      スケールアップ時のレプリカの最大数を指定します。
      8
      メモリー使用率に metrics パラメーターを使用します。
      9
      メモリー使用率の memory を指定します。
      10
      Utilization に設定します。
      11
      averageUtilization および ターゲットに設定する平均メモリー使用率をすべての Pod に対して指定します (要求されるメモリーのパーセントで表す)。ターゲット Pod にはメモリー要求が設定されている必要があります。
      12
      オプション: スケールアップまたはスケールダウンのレートを制御するスケーリングポリシーを指定します。

  2. Horizontal Pod Autoscaler を作成します。 

    $ oc create -f <file-name>.yaml
    Copy to Clipboard Toggle word wrap

    以下に例を示します。 

    $ oc create -f hpa.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    horizontalpodautoscaler.autoscaling/hpa-resource-metrics-memory created
    Copy to Clipboard Toggle word wrap

  3. Horizontal Pod Autoscaler が作成されていることを確認します。 

    $ oc get hpa hpa-resource-metrics-memory
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                          REFERENCE                       TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
hpa-resource-metrics-memory   ReplicationController/example   2441216/500Mi   1         10        1          20m
    Copy to Clipboard Toggle word wrap 

    $ oc describe hpa hpa-resource-metrics-memory
    Copy to Clipboard Toggle word wrap

    出力例

    Name:                        hpa-resource-metrics-memory
Namespace:                   default
Labels:                      <none>
Annotations:                 <none>
CreationTimestamp:           Wed, 04 Mar 2020 16:31:37 +0530
Reference:                   ReplicationController/example
Metrics:                     ( current / target )
  resource memory on pods:   2441216 / 500Mi
Min replicas:                1
Max replicas:                10
ReplicationController pods:  1 current / 1 desired
Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     True    ReadyForNewScale    recommended size matches current size
  ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
  ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
Events:
  Type     Reason                   Age                 From                       Message
  ----     ------                   ----                ----                       -------
  Normal   SuccessfulRescale        6m34s               horizontal-pod-autoscaler  New size: 1; reason: All metrics below target
    Copy to Clipboard Toggle word wrap

2.4.5. CLI を使用した Horizontal Pod Autoscaler の状態条件について
リンクのコピー

状態条件セットを使用して、Horizontal Pod Autoscaler (HPA) がスケーリングできるかどうかや、現時点でこれがいずれかの方法で制限されているかどうかを判別できます。

HPA の状態条件は、自動スケーリング API の v2beta1 バージョンで利用できます。

HPA は、以下の状態条件で応答します。

  • AbleToScale 条件では、HPA がメトリクスを取得して更新できるか、またバックオフ関連の条件によりスケーリングが回避されるかどうかを指定します。

    • True 条件はスケーリングが許可されることを示します。
    • False 条件は指定される理由によりスケーリングが許可されないことを示します。

  • ScalingActive 条件は、HPA が有効にされており (ターゲットのレプリカ数がゼロでない)、必要なメトリクスを計算できるかどうかを示します。

    • True 条件はメトリクスが適切に機能していることを示します。
    • False 条件は通常フェッチするメトリクスに関する問題を示します。

  • ScalingLimited 条件は、必要とするスケールが Horizontal Pod Autoscaler の最大値または最小値によって制限されていたことを示します。

    • True 条件は、スケーリングするためにレプリカの最小または最大数を引き上げるか、または引き下げる必要があることを示します。

    • False 条件は、要求されたスケーリングが許可されることを示します。 

      $ oc describe hpa cm-test
      Copy to Clipboard Toggle word wrap

      出力例

      Name:                           cm-test
Namespace:                      prom
Labels:                         <none>
Annotations:                    <none>
CreationTimestamp:              Fri, 16 Jun 2017 18:09:22 +0000
Reference:                      ReplicationController/cm-test
Metrics:                        ( current / target )
  "http_requests" on pods:      66m / 500m
Min replicas:                   1
Max replicas:                   4
ReplicationController pods:     1 current / 1 desired
Conditions:
      1 
      
  Type              Status    Reason              Message
  ----              ------    ------              -------
  AbleToScale       True      ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
  ScalingActive     True      ValidMetricFound    the HPA was able to successfully calculate a replica count from pods metric http_request
  ScalingLimited    False     DesiredWithinRange  the desired replica count is within the acceptable range
Events:
      Copy to Clipboard Toggle word wrap

      1
      Horizontal Pod Autoscaler の状況メッセージです。

以下は、スケーリングできない Pod の例です。

出力例

Conditions:
  Type         Status  Reason          Message
  ----         ------  ------          -------
  AbleToScale  False   FailedGetScale  the HPA controller was unable to get the target's current scale: no matches for kind "ReplicationController" in group "apps"
Events:
  Type     Reason          Age               From                       Message
  ----     ------          ----              ----                       -------
  Warning  FailedGetScale  6s (x3 over 36s)  horizontal-pod-autoscaler  no matches for kind "ReplicationController" in group "apps"
Copy to Clipboard Toggle word wrap

以下は、スケーリングに必要なメトリクスを取得できなかった Pod の例です。

出力例

Conditions:
  Type                  Status    Reason                    Message
  ----                  ------    ------                    -------
  AbleToScale           True     SucceededGetScale          the HPA controller was able to get the target's current scale
  ScalingActive         False    FailedGetResourceMetric    the HPA was unable to compute the replica count: failed to get cpu utilization: unable to get metrics for resource cpu: no metrics returned from resource metrics API
Copy to Clipboard Toggle word wrap

以下は、要求される自動スケーリングが要求される最小数よりも小さい場合の Pod の例です。

出力例

Conditions:
  Type              Status    Reason              Message
  ----              ------    ------              -------
  AbleToScale       True      ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
  ScalingActive     True      ValidMetricFound    the HPA was able to successfully calculate a replica count from pods metric http_request
  ScalingLimited    False     DesiredWithinRange  the desired replica count is within the acceptable range
Copy to Clipboard Toggle word wrap

2.4.5.1. CLI を使用した Horizontal Pod Autoscaler の状態条件の表示
リンクのコピー

Pod に設定された状態条件は、Horizontal Pod Autoscaler (HPA) で表示することができます。

注記

Horizontal Pod Autoscaler の状態条件は、自動スケーリング API の v2beta1 バージョンで利用できます。

前提条件

Horizontal Pod Autoscaler を使用するには、クラスターの管理者はクラスターメトリクスを適切に設定している必要があります。メトリクスが設定されているかどうかは、oc describe PodMetrics <pod-name> コマンドを使用して判断できます。メトリクスが設定されている場合、出力は以下の Usage の下にある Cpu と Memory のように表示されます。 

$ oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Copy to Clipboard Toggle word wrap

出力例

Name:         openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Namespace:    openshift-kube-scheduler
Labels:       <none>
Annotations:  <none>
API Version:  metrics.k8s.io/v1beta1
Containers:
  Name:  wait-for-host-port
  Usage:
    Memory:  0
  Name:      scheduler
  Usage:
    Cpu:     8m
    Memory:  45440Ki
Kind:        PodMetrics
Metadata:
  Creation Timestamp:  2019-05-23T18:47:56Z
  Self Link:           /apis/metrics.k8s.io/v1beta1/namespaces/openshift-kube-scheduler/pods/openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Timestamp:             2019-05-23T18:47:56Z
Window:                1m0s
Events:                <none>
Copy to Clipboard Toggle word wrap

手順

Pod の状態条件を表示するには、Pod の名前と共に以下のコマンドを使用します。 

$ oc describe hpa <pod-name>
Copy to Clipboard Toggle word wrap

以下に例を示します。 

$ oc describe hpa cm-test
Copy to Clipboard Toggle word wrap

条件は、出力の Conditions フィールドに表示されます。

出力例

Name:                           cm-test
Namespace:                      prom
Labels:                         <none>
Annotations:                    <none>
CreationTimestamp:              Fri, 16 Jun 2017 18:09:22 +0000
Reference:                      ReplicationController/cm-test
Metrics:                        ( current / target )
  "http_requests" on pods:      66m / 500m
Min replicas:                   1
Max replicas:                   4
ReplicationController pods:     1 current / 1 desired
Conditions:
1 

  Type              Status    Reason              Message
  ----              ------    ------              -------
  AbleToScale       True      ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
  ScalingActive     True      ValidMetricFound    the HPA was able to successfully calculate a replica count from pods metric http_request
  ScalingLimited    False     DesiredWithinRange  the desired replica count is within the acceptable range
Copy to Clipboard Toggle word wrap

2.5. Vertical Pod Autoscaler を使用した Pod リソースレベルの自動調整
リンクのコピー

OpenShift Container Platform の Vertical Pod Autoscaler Operator (VPA) は、Pod 内のコンテナーの履歴および現在の CPU とメモリーリソースを自動的に確認し、把握する使用値に基づいてリソース制限および要求を更新できます。VPA は個別のカスタムリソース (CR) を使用して、プロジェクトの Deployment、Deployment Config、StatefulSet、Job、DaemonSet、ReplicaSet、または ReplicationController などのワークロードオブジェクトに関連付けられたすべての Pod を更新します。

VPA は、Pod に最適な CPU およびメモリーの使用状況を理解するのに役立ち、Pod のライフサイクルを通じて Pod のリソースを自動的に維持します。

重要

Vertical Pod Autoscaler はテクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

2.5.1. Vertical Pod Autoscaler Operator について
リンクのコピー

Vertical Pod Autoscaler Operator (VPA) は、API リソースおよびカスタムリソース (CR) として実装されます。CR は、プロジェクトのデーモンセット、レプリケーションコントローラーなどの特定のワークロードオブジェクトに関連付けられた Pod について Vertical Pod Autoscaler Operator が取るべき動作を判別します。

VPA は、それらの Pod 内のコンテナーの履歴および現在の CPU とメモリーの使用状況を自動的に計算し、このデータを使用して、最適化されたリソース制限および要求を判別し、これらの Pod が常時効率的に動作していることを確認することができます。たとえば、VPA は使用している量よりも多くのリソースを要求する Pod のリソースを減らし、十分なリソースを要求していない Pod のリソースを増やします。

VPA は、一度に 1 つずつ推奨値で調整されていない Pod を自動的に削除するため、アプリケーションはダウンタイムなしに継続して要求を提供できます。ワークロードオブジェクトは、元のリソース制限および要求で Pod を再デプロイします。VPA は変更用の受付 Webhook を使用して、Pod がノードに許可される前に最適化されたリソース制限および要求で Pod を更新します。VPA が Pod を削除する必要がない場合は、VPA リソース制限および要求を表示し、必要に応じて Pod を手動で更新できます。

たとえば、CPU の 50% を使用する Pod が 10% しか要求しない場合、VPA は Pod が要求よりも多くの CPU を消費すると判別してその Pod を削除します。レプリカセットなどのワークロードオブジェクトは Pod を再起動し、VPA は推奨リソースで新しい Pod を更新します。

開発者の場合、VPA を使用して、Pod を各 Pod に適したリソースを持つノードにスケジュールし、Pod の需要の多い期間でも稼働状態を維持することができます。

管理者は、VPA を使用してクラスターリソースをより適切に活用できます。たとえば、必要以上の CPU リソースを Pod が予約できないようにします。VPA は、ワークロードが実際に使用しているリソースをモニターし、他のワークロードで容量を使用できるようにリソース要件を調整します。VPA は、初期のコンテナー設定で指定される制限と要求の割合をそのまま維持します。

注記

VPA の実行を停止するか、またはクラスターの特定の VPA CR を削除する場合、VPA によってすでに変更された Pod のリソース要求は変更されません。新規 Pod は、VPA による以前の推奨事項ではなく、ワークロードオブジェクトで定義されたリソースを取得します。

2.5.2. Vertical Pod Autoscaler Operator のインストール
リンクのコピー

OpenShift Container Platform Web コンソールを使って Vertical Pod Autoscaler Operator (VPA) をインストールすることができます。

手順

  1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
  2. 利用可能な Operator の一覧から VerticalPodAutoscaler を選択し、Install をクリックします。
  3. Install Operator ページで、Operator recommended namespace オプションが選択されていることを確認します。これにより、Operator が必須の openshift-vertical-pod-autoscaler namespace にインストールされます。この namespace は存在しない場合は、自動的に作成されます。
  4. Install をクリックします。

  5. VPA Operator コンポーネントを一覧表示して、インストールを確認します。

    1. Workloads → Pods に移動します。
    2. ドロップダウンメニューから openshift-vertical-pod-autoscaler プロジェクトを選択し、4 つの Pod が実行されていることを確認します。
    3. Workloads → Deploymentsに移動し、4 つの デプロイメントが実行されていることを確認します。

  6. オプション:以下のコマンドを使用して、OpenShift Container Platform CLI でインストールを確認します。 

    $ oc get all -n openshift-vertical-pod-autoscaler
    Copy to Clipboard Toggle word wrap

    出力には、4 つの Pod と 4 つのデプロイメントが表示されます。

    出力例

    NAME                                                    READY   STATUS    RESTARTS   AGE
pod/vertical-pod-autoscaler-operator-85b4569c47-2gmhc   1/1     Running   0          3m13s
pod/vpa-admission-plugin-default-67644fc87f-xq7k9       1/1     Running   0          2m56s
pod/vpa-recommender-default-7c54764b59-8gckt            1/1     Running   0          2m56s
pod/vpa-updater-default-7f6cc87858-47vw9                1/1     Running   0          2m56s

NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/vpa-webhook   ClusterIP   172.30.53.206   <none>        443/TCP   2m56s

NAME                                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/vertical-pod-autoscaler-operator   1/1     1            1           3m13s
deployment.apps/vpa-admission-plugin-default       1/1     1            1           2m56s
deployment.apps/vpa-recommender-default            1/1     1            1           2m56s
deployment.apps/vpa-updater-default                1/1     1            1           2m56s

NAME                                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/vertical-pod-autoscaler-operator-85b4569c47   1         1         1       3m13s
replicaset.apps/vpa-admission-plugin-default-67644fc87f       1         1         1       2m56s
replicaset.apps/vpa-recommender-default-7c54764b59            1         1         1       2m56s
replicaset.apps/vpa-updater-default-7f6cc87858                1         1         1       2m56s
    Copy to Clipboard Toggle word wrap

2.5.3. Vertical Pod Autoscaler Operator の使用について
リンクのコピー

Vertical Pod Autoscaler Operator (VPA) を使用するには、クラスター内にワークロードオブジェクトの VPA カスタムリソース (CR) を作成します。VPA は、そのワークロードオブジェクトに関連付けられた Pod に最適な CPU およびメモリーリソースを確認し、適用します。VPA は、デプロイメント、ステートフルセット、ジョブ、デーモンセット、レプリカセット、またはレプリケーションコントローラーのワークロードオブジェクトと共に使用できます。VPA CR はモニターする必要のある Pod と同じプロジェクトになければなりません。

VPA CR を使用してワークロードオブジェクトを関連付け、VPA が動作するモードを指定します。

  • Auto および Recreate モードは、Pod の有効期間中は VPA CPU およびメモリーの推奨事項を自動的に適用します。VPA は、推奨値で調整されていないプロジェクトの Pod を削除します。ワークロードオブジェクトによって再デプロイされる場合、VPA はその推奨内容で新規 Pod を更新します。
  • Initial モードは、Pod の作成時にのみ VPA の推奨事項を自動的に適用します。
  • Off モードは、推奨されるリソース制限および要求のみを提供するので、推奨事項を手動で適用することができます。off モードは Pod を更新しません。

CR を使用して、VPA 評価および更新から特定のコンテナーをオプトアウトすることもできます。

たとえば、Pod には以下の制限および要求があります。 

resources:
  limits:
    cpu: 1
    memory: 500Mi
  requests:
    cpu: 500m
    memory: 100Mi
Copy to Clipboard Toggle word wrap

auto に設定された VPA を作成すると、VPA はリソースの使用状況を確認して Pod を削除します。再デプロイ時に、Pod は新規のリソース制限および要求を使用します。 

resources:
  limits:
    cpu: 50m
    memory: 1250Mi
  requests:
    cpu: 25m
    memory: 262144k
Copy to Clipboard Toggle word wrap

以下のコマンドを実行して、VPA の推奨事項を表示できます。 

$ oc get vpa <vpa-name> --output yaml
Copy to Clipboard Toggle word wrap

数分後に、出力には、以下のような CPU およびメモリー要求の推奨内容が表示されます。

出力例

...
status:
...
  recommendation:
    containerRecommendations:
    - containerName: frontend
      lowerBound:
        cpu: 25m
        memory: 262144k
      target:
        cpu: 25m
        memory: 262144k
      uncappedTarget:
        cpu: 25m
        memory: 262144k
      upperBound:
        cpu: 262m
        memory: "274357142"
    - containerName: backend
      lowerBound:
        cpu: 12m
        memory: 131072k
      target:
        cpu: 12m
        memory: 131072k
      uncappedTarget:
        cpu: 12m
        memory: 131072k
      upperBound:
        cpu: 476m
        memory: "498558823"
...
Copy to Clipboard Toggle word wrap

出力には、target (推奨リソース)、lowerBound (最小推奨リソース)、upperBound (最大推奨リソース)、および uncappedTarget (最新の推奨リソース) が表示されます。

VPA は lowerBound および upperBound の値を使用して、Pod の更新が必要であるかどうかを判別します。Pod のリソース要求が lowerBound 値を下回るか、upperBound 値を上回る場合は、VPA は終了し、target 値で Pod を再作成します。

2.5.3.1. VPA の推奨事項の自動適用
リンクのコピー

VPA を使用して Pod を自動的に更新するには、updateMode が Auto または Recreate に設定された特定のワークロードオブジェクトの VPA CR を作成します。

Pod がワークロードオブジェクト用に作成されると、VPA はコンテナーを継続的にモニターして、CPU およびメモリーのニーズを分析します。VPA は、CPU およびメモリーについての VPA の推奨値を満たさない Pod を削除します。再デプロイ時に、Pod は VPA の推奨値に基づいて新規のリソース制限および要求を使用し、アプリケーションに設定された Pod の Disruption Budget (停止状態の予算) を反映します。この推奨事項は、参照用に VPA CR の status フィールドに追加されます。

注記

ワークロードオブジェクトは、VPA が Pod を監視し、更新できるようにレプリカを 2 つ以上指定する必要があります。ワークロードオブジェクトが 1 つのレプリカを指定する場合、VPA はアプリケーションのダウンタイムを防ぐために Pod を削除しません。Pod を手動で削除し、推奨リソースを使用することができます。

Auto モードの VPA CR の例

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
1 

    name:       frontend
2 

  updatePolicy:
    updateMode: "Auto"
3
Copy to Clipboard Toggle word wrap

1 1
この VPA CR が管理するワークロードオブジェクトのタイプ。
2
この VPA CR が管理するワークロードオブジェクトの名前。
3
モードを Auto または Recreate に設定します。
  • Auto:VPA は、Pod の作成時にリソース要求を割り当て、要求されるリソースが新規の推奨事項と大きく異なる場合に、それらを終了して既存の Pod を更新します。
  • Recreate:VPA は、Pod の作成時にリソース要求を割り当て、要求されるリソースが新規の推奨事項と大きく異なる場合に、それらを終了して既存の Pod を更新します。このモードはほとんど使用されることはありません。リソース要求が変更される際に Pod が再起動されていることを確認する必要がある場合にのみ使用します。
注記

VPA が推奨リソースを判別し、新規 Pod に推奨事項を割り当てる前に、プロジェクトに動作中の Pod がなければなりません。

2.5.3.2. Pod 作成時における VPA 推奨の自動適用
リンクのコピー

VPA を使用して、Pod が最初にデプロイされる場合にのみ推奨リソースを適用するには、updateMode が Initial に設定された特定のワークロードオブジェクトの VPA CR を作成します。

次に、VPA の推奨値を使用する必要のあるワークロードオブジェクトに関連付けられた Pod を手動で削除します。Initial モードで、VPA は新しいリソースの推奨内容を確認する際に Pod を削除したり、更新したりしません。

Initial モードの VPA CR の例

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
1 

    name:       frontend
2 

  updatePolicy:
    updateMode: "Initial"
3
Copy to Clipboard Toggle word wrap

1
この VPA CR が管理するワークロードオブジェクトのタイプ。
2
この VPA CR が管理するワークロードオブジェクトの名前。
3
モードを Initial に設定します。VPA は、Pod の作成時にリソースを割り当て、Pod の有効期間中はリソースを変更しません。
注記

VPA が推奨リソースを判別し、新規 Pod に推奨事項を割り当てる前に、プロジェクトに動作中の Pod がなければなりません。

2.5.3.3. VPA の推奨事項の手動適用
リンクのコピー

CPU およびメモリーの推奨値を判別するためだけに VPA を使用するには、updateMode を off に設定した特定のワークロードオブジェクトの VPA CR を作成します。

Pod がワークロードオブジェクト用に作成されると、VPA はコンテナーの CPU およびメモリーのニーズを分析し、VPA CR の status フィールドにそれらの推奨事項を記録します。VPA は、新しい推奨リソースを判別する際に Pod を更新しません。

Off モードの VPA CR の例

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
1 

    name:       frontend
2 

  updatePolicy:
    updateMode: "Off"
3
Copy to Clipboard Toggle word wrap

1
この VPA CR が管理するワークロードオブジェクトのタイプ。
2
この VPA CR が管理するワークロードオブジェクトの名前。
3
モードを Off に設定します。

以下のコマンドを使用して、推奨事項を表示できます。 

$ oc get vpa <vpa-name> --output yaml
Copy to Clipboard Toggle word wrap

この推奨事項により、ワークロードオブジェクトを編集して CPU およびメモリー要求を追加し、推奨リソースを使用して Pod を削除および再デプロイできます。

注記

VPA が推奨リソースを判別する前に、プロジェクトに動作中の Pod がなければなりません。

2.5.3.4. VPA の推奨事項をすべてのコンテナーに適用しないようにする
リンクのコピー

ワークロードオブジェクトに複数のコンテナーがあり、VPA がすべてのコンテナーを評価および実行対象としないようにするには、特定のワークロードオブジェクトの VPA CR を作成し、resourcePolicy を追加して特定のコンテナーをオプトアウトします。

VPA が推奨リソースで Pod を更新すると、resourcePolicy が設定されたコンテナーは更新されず、VPA は Pod 内のそれらのコンテナーの推奨事項を提示しません。 

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
1 

    name:       frontend
2 

  updatePolicy:
    updateMode: "Auto"
3 

  resourcePolicy:
4 

    containerPolicies:
    - containerName: my-opt-sidecar
      mode: "Off"
Copy to Clipboard Toggle word wrap
1
この VPA CR が管理するワークロードオブジェクトのタイプ。
2
この VPA CR が管理するワークロードオブジェクトの名前。
3
モードを Auto、Recreate、または Off に設定します。Recreate モードはほとんど使用されることはありません。リソース要求が変更される際に Pod が再起動されていることを確認する必要がある場合にのみ使用します。
4
オプトアウトするコンテナーを指定し、mode を Off に設定します。

たとえば、Pod には同じリソース要求および制限の 2 つのコンテナーがあります。 

# ...
spec:
  containers:
  - name: frontend
    resources:
      limits:
        cpu: 1
        memory: 500Mi
      requests:
        cpu: 500m
        memory: 100Mi
  - name: backend
    resources:
      limits:
        cpu: "1"
        memory: 500Mi
      requests:
        cpu: 500m
        memory: 100Mi
# ...
Copy to Clipboard Toggle word wrap

backend コンテナーがオプトアウトに設定された VPA CR を起動した後、VPA は Pod を終了し、frontend コンテナーのみに適用される推奨リソースで Pod を再作成します。 

...
spec:
  containers:
    name: frontend
    resources:
      limits:
        cpu: 50m
        memory: 1250Mi
      requests:
        cpu: 25m
        memory: 262144k
...
    name: backend
    resources:
      limits:
        cpu: "1"
        memory: 500Mi
      requests:
        cpu: 500m
        memory: 100Mi
...
Copy to Clipboard Toggle word wrap

2.5.4. Vertical Pod Autoscaler Operator の使用
リンクのコピー

VPA カスタムリソース (CR) を作成して、Vertical Pod Autoscaler Operator (VPA) を使用できます。CR は、分析すべき Pod を示し、VPA がそれらの Pod について実行するアクションを判別します。

手順

特定のワークロードオブジェクトの VPA CR を作成するには、以下を実行します。

  1. スケーリングするワークロードオブジェクトがあるプロジェクトに切り替えます。

    1. VPA CR YAML ファイルを作成します。 

      apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
      1 
      
    name:       frontend
      2 
      
  updatePolicy:
    updateMode: "Auto"
      3 
      
  resourcePolicy:
      4 
      
    containerPolicies:
    - containerName: my-opt-sidecar
      mode: "Off"
      Copy to Clipboard Toggle word wrap
      1
      この VPA が管理するワークロードオブジェクトのタイプ (Deployment、StatefulSet、Job、DaemonSet、ReplicaSet、または ReplicationController) を指定します。
      2
      この VPA が管理する既存のワークロードオブジェクトの名前を指定します。
      3
      VPA モードを指定します。
      • auto は、コントローラーに関連付けられた Pod に推奨リソースを自動的に適用します。VPA は既存の Pod を終了し、推奨されるリソース制限および要求で新規 Pod を作成します。
      • recreate は、ワークロードオブジェクトに関連付けられた Pod に推奨リソースを自動的に適用します。VPA は既存の Pod を終了し、推奨されるリソース制限および要求で新規 Pod を作成します。recreate モードはほとんど使用されることはありません。リソース要求が変更される際に Pod が再起動されていることを確認する必要がある場合にのみ使用します。
      • initial は、ワークロードオブジェクトに関連付けられた Pod が作成される際に、推奨リソースを自動的に適用します。VPA は、新しい推奨リソースを確認する際に Pod を更新しません。
      • off は、ワークロードオブジェクトに関連付けられた Pod の推奨リソースのみを生成します。VPA は、新しい推奨リソースを確認する際に Pod を更新しません。また、新規 Pod に推奨事項を適用しません。
      4
      オプション:オプトアウトするコンテナーを指定し、モードを Off に設定します。

    2. VPA CR を作成します。 

      $ oc create -f <file-name>.yaml
      Copy to Clipboard Toggle word wrap

      しばらくすると、VPA はワークロードオブジェクトに関連付けられた Pod 内のコンテナーのリソース使用状況を確認します。

      以下のコマンドを実行して、VPA の推奨事項を表示できます。 

      $ oc get vpa <vpa-name> --output yaml
      Copy to Clipboard Toggle word wrap

      出力には、以下のような CPU およびメモリー要求の推奨事項が表示されます。

      出力例

      ...
status:

...

  recommendation:
    containerRecommendations:
    - containerName: frontend
      lowerBound:
      1 
      
        cpu: 25m
        memory: 262144k
      target:
      2 
      
        cpu: 25m
        memory: 262144k
      uncappedTarget:
      3 
      
        cpu: 25m
        memory: 262144k
      upperBound:
      4 
      
        cpu: 262m
        memory: "274357142"
    - containerName: backend
      lowerBound:
        cpu: 12m
        memory: 131072k
      target:
        cpu: 12m
        memory: 131072k
      uncappedTarget:
        cpu: 12m
        memory: 131072k
      upperBound:
        cpu: 476m
        memory: "498558823"

...
      Copy to Clipboard Toggle word wrap

      1
      lowerBound は、推奨リソースの最小レベルです。
      2
      target は、推奨リソースのレベルです。
      3
      upperBound は、推奨リソースの最大レベルです。
      4
      uncappedTarget は最新の推奨リソースです。

2.5.5. Vertical Pod Autoscaler Operator のアンインストール
リンクのコピー

Vertical Pod Autoscaler Operator (VPA) を OpenShift Container Platform クラスターから削除できます。アンインストール後、既存の VPA CR によってすでに変更された Pod のリソース要求は変更されません。新規 Pod は、Vertical Pod Autoscaler Operator による以前の推奨事項ではなく、ワークロードオブジェクトで定義されるリソースを取得します。

注記

oc delete vpa <vpa-name> コマンドを使用して、特定の VPA を削除できます。Vertical Pod Autoscaler のアンインストール時と同じアクションがリソース要求に対して適用されます。

VPA Operator を削除した後、潜在的な問題を回避するために、Operator に関連する他のコンポーネントを削除することをお勧めします。

前提条件

  • Vertical Pod Autoscaler Operator がインストールされていること。

手順

  1. OpenShift Container Platform Web コンソールで、Operators → Installed Operators をクリックします。
  2. openshift-vertical-pod-autoscaler プロジェクトに切り替えます。
  3. VerticalPodAutoscaler Operator を検索し、Options メニューをクリックします。Uninstall Operator を選択します。
  4. ダイアログボックスで、Uninstall をクリックします。
  5. オプション: 演算子に関連付けられているすべてのオペランドを削除するには、ダイアログボックスで、Delete all operand instances for this operatorチェックボックスをオンにします。
  6. Uninstall をクリックします。

  7. オプション: OpenShift CLI を使用して VPA コンポーネントを削除します。

    1. VPA の変更用 Webhook 設定を削除します。 

      $ oc delete mutatingwebhookconfigurations/vpa-webhook-config
      Copy to Clipboard Toggle word wrap

    2. VPA カスタムリソースを一覧表示します。 

      $ oc get verticalpodautoscalercheckpoints.autoscaling.k8s.io,verticalpodautoscalercontrollers.autoscaling.openshift.io,verticalpodautoscalers.autoscaling.k8s.io -o wide --all-namespaces
      Copy to Clipboard Toggle word wrap

      出力例

      NAMESPACE      NAME                                                                       AGE
my-project     verticalpodautoscalercheckpoint.autoscaling.k8s.io/vpa-recommender-httpd   5m46s

NAMESPACE                           NAME                                                               AGE
openshift-vertical-pod-autoscaler   verticalpodautoscalercontroller.autoscaling.openshift.io/default   11m

NAMESPACE      NAME                                                       MODE   CPU   MEM       PROVIDED   AGE
my-project     verticalpodautoscaler.autoscaling.k8s.io/vpa-recommender   Auto   93m   262144k   True       9m15s
      Copy to Clipboard Toggle word wrap

    3. 一覧表示された VPA カスタムリソースを削除します。以下に例を示します。 

      $ oc delete verticalpodautoscalercheckpoint.autoscaling.k8s.io/vpa-recommender-httpd -n my-project
      Copy to Clipboard Toggle word wrap 
      $ oc delete verticalpodautoscalercontroller.autoscaling.openshift.io/default -n openshift-vertical-pod-autoscaler
      Copy to Clipboard Toggle word wrap 
      $ oc delete verticalpodautoscaler.autoscaling.k8s.io/vpa-recommender -n my-project
      Copy to Clipboard Toggle word wrap

    4. VPA カスタムリソース定義 (CRD) を一覧表示します。 

      $ oc get crd
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                                                              CREATED AT
 ...
verticalpodautoscalercheckpoints.autoscaling.k8s.io               2022-02-07T14:09:20Z
verticalpodautoscalercontrollers.autoscaling.openshift.io         2022-02-07T14:09:20Z
verticalpodautoscalers.autoscaling.k8s.io                         2022-02-07T14:09:20Z
 ...
      Copy to Clipboard Toggle word wrap

    5. 一覧表示された VPA CRD を削除します。 

      $ oc delete crd verticalpodautoscalercheckpoints.autoscaling.k8s.io verticalpodautoscalercontrollers.autoscaling.openshift.io verticalpodautoscalers.autoscaling.k8s.io
      Copy to Clipboard Toggle word wrap

      CRD を削除すると、関連付けられたロール、クラスターロール、およびロールバインディングが削除されます。ただし、手動で削除する必要のあるクラスターロールがいくつかあります。

    6. VPA クラスターロールを一覧表示します。 

      $ oc get clusterrole | grep openshift-vertical-pod-autoscaler
      Copy to Clipboard Toggle word wrap

      出力例

      openshift-vertical-pod-autoscaler-6896f-admin        2022-02-02T15:29:55Z
openshift-vertical-pod-autoscaler-6896f-edit         2022-02-02T15:29:55Z
openshift-vertical-pod-autoscaler-6896f-view         2022-02-02T15:29:55Z
      Copy to Clipboard Toggle word wrap

    7. 一覧表示された VPA クラスターロールを削除します。以下に例を示します。 

      $ oc delete clusterrole openshift-vertical-pod-autoscaler-6896f-admin openshift-vertical-pod-autoscaler-6896f-edit openshift-vertical-pod-autoscaler-6896f-view
      Copy to Clipboard Toggle word wrap

    8. VPA Operator を削除します。 

      $ oc delete operator/vertical-pod-autoscaler.openshift-vertical-pod-autoscaler
      Copy to Clipboard Toggle word wrap

2.6. Pod への機密性の高いデータの提供
リンクのコピー

アプリケーションによっては、パスワードやユーザー名など開発者に使用させない秘密情報が必要になります。

管理者として シークレット オブジェクトを使用すると、この情報を平文で公開することなく提供することが可能です。

2.6.1. シークレットについて
リンクのコピー

Secret オブジェクトタイプはパスワード、OpenShift Container Platform クライアント設定ファイル、プライベートソースリポジトリーの認証情報などの機密情報を保持するメカニズムを提供します。シークレットは機密内容を Pod から切り離します。シークレットはボリュームプラグインを使用してコンテナーにマウントすることも、システムが Pod の代わりにシークレットを使用して各種アクションを実行することもできます。

キーのプロパティーには以下が含まれます。

  • シークレットデータはその定義とは別に参照できます。
  • シークレットデータのボリュームは一時ファイルストレージ機能 (tmpfs) でサポートされ、ノードで保存されることはありません。
  • シークレットデータは namespace 内で共有できます。

YAML Secret オブジェクト定義

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque
1 

data:
2 

  username: dmFsdWUtMQ0K
3 

  password: dmFsdWUtMg0KDQo=
stringData:
4 

  hostname: myapp.mydomain.com
5
Copy to Clipboard Toggle word wrap

1
シークレットにキー名および値の構造を示しています。
2
data フィールドのキーに使用可能な形式については、Kubernetes identifiers glossary の DNS_SUBDOMAIN 値のガイドラインに従う必要があります。
3
data マップのキーに関連付けられる値は base64 でエンコーディングされている必要があります。
4
stringData マップのエントリーが base64 に変換され、このエントリーは自動的に data マップに移動します。このフィールドは書き込み専用です。この値は data フィールドでのみ返されます。
5
stringData マップのキーに関連付けられた値は単純なテキスト文字列で設定されます。

シークレットに依存する Pod を作成する前に、シークレットを作成する必要があります。

シークレットの作成時に以下を実行します。

  • シークレットデータでシークレットオブジェクトを作成します。
  • Pod のサービスアカウントをシークレットの参照を許可するように更新します。
  • シークレットを環境変数またはファイルとして使用する Pod を作成します (secret ボリュームを使用)。
2.6.1.1. シークレットの種類
リンクのコピー

type フィールドの値で、シークレットのキー名と値の構造を指定します。このタイプを使用して、シークレットオブジェクトにユーザー名とキーの配置を実行できます。検証の必要がない場合には、デフォルト設定の opaque タイプを使用してください。

以下のタイプから 1 つ指定して、サーバー側で最小限の検証をトリガーし、シークレットデータに固有のキー名が存在することを確認します。

  • kubernetes.io/service-account-token。サービスアカウントトークンを使用します。
  • kubernetes.io/basic-auth。Basic 認証で使用します。
  • kubernetes.io/ssh-auth.SSH キー認証で使用します。
  • kubernetes.io/tls。TLS 認証局で使用します。

検証が必要ない場合には type: Opaque と指定します。これは、シークレットがキー名または値の規則に準拠しないという意味です。opaque シークレットでは、任意の値を含む、体系化されていない key:value ペアも利用できます。

注記

example.com/my-secret-type などの他の任意のタイプを指定できます。これらのタイプはサーバー側では実行されませんが、シークレットの作成者がその種類のキー/値の要件に従う意図があることを示します。

シークレットのさまざまなタイプの例については、シークレットの使用 に関連するコードのサンプルを参照してください。

2.6.1.2. シークレットデータキー
リンクのコピー

シークレットキーは DNS サブドメインになければなりません。

2.6.2. シークレットの作成方法
リンクのコピー

管理者は、開発者がシークレットに依存する Pod を作成できるよう事前にシークレットを作成しておく必要があります。

シークレットの作成時に以下を実行します。

  1. 秘密にしておきたいデータを含む秘密オブジェクトを作成します。各シークレットタイプに必要な特定のデータは、以下のセクションで非表示になります。

    不透明なシークレットを作成する YAML オブジェクトの例

    apiVersion: v1
kind: Secret
metadata:
  name: test-secret
type: Opaque
    1 
    
data:
    2 
    
  username: dmFsdWUtMQ0K
  password: dmFsdWUtMQ0KDQo=
stringData:
    3 
    
  hostname: myapp.mydomain.com
  secret.properties: |
    property1=valueA
    property2=valueB
    Copy to Clipboard Toggle word wrap

    1
    シークレットのタイプを指定します。
    2
    エンコードされた文字列およびデータを指定します。
    3
    デコードされた文字列およびデータを指定します。

    data フィールドまたは stringdata フィールドの両方ではなく、いずれかを使用してください。

  2. Pod のサービスアカウントをシークレットを参照するように更新します。

    シークレットを使用するサービスアカウントの YAML

    apiVersion: v1
kind: ServiceAccount
 ...
secrets:
- name: test-secret
    Copy to Clipboard Toggle word wrap

  3. シークレットを環境変数またはファイルとして使用する Pod を作成します (secret ボリュームを使用)。

    シークレットデータと共にボリュームのファイルが設定された Pod の YAML

    apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "cat /etc/secret-volume/*" ]
      volumeMounts:
    1 
    
          - name: secret-volume
            mountPath: /etc/secret-volume
    2 
    
            readOnly: true
    3 
    
  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret
    4 
    
  restartPolicy: Never
    Copy to Clipboard Toggle word wrap

    1
    シークレットが必要な各コンテナーに volumeMounts フィールドを追加します。
    2
    シークレットが表示される未使用のディレクトリー名を指定します。シークレットデータマップの各キーは mountPath の下にあるファイル名になります。
    3
    true に設定します。true の場合、ドライバーに読み取り専用ボリュームを提供するように指示します。
    4
    シークレットの名前を指定します。

    シークレットデータと共に環境変数が設定された Pod の YAML

    apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "export" ]
      env:
        - name: TEST_SECRET_USERNAME_ENV_VAR
          valueFrom:
            secretKeyRef:
    1 
    
              name: test-secret
              key: username
  restartPolicy: Never
    Copy to Clipboard Toggle word wrap

    1
    シークレットキーを使用する環境変数を指定します。

    シークレットデータと環境変数が設定されたビルド設定の YAML

    apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: secret-example-bc
spec:
  strategy:
    sourceStrategy:
      env:
      - name: TEST_SECRET_USERNAME_ENV_VAR
        valueFrom:
          secretKeyRef:
    1 
    
            name: test-secret
            key: username
    Copy to Clipboard Toggle word wrap

    1
    シークレットキーを使用する環境変数を指定します。
2.6.2.1. シークレットの作成に関する制限
リンクのコピー

シークレットを使用するには、Pod がシークレットを参照できる必要があります。シークレットは、以下の 3 つの方法で Pod で使用されます。

  • コンテナーの環境変数を事前に設定するために使用される。
  • 1 つ以上のコンテナーにマウントされるボリュームのファイルとして使用される。
  • Pod のイメージをプルする際に kubelet によって使用される。

ボリュームタイプのシークレットは、ボリュームメカニズムを使用してデータをファイルとしてコンテナーに書き込みます。イメージプルシークレットは、シークレットを namespace のすべての Pod に自動的に挿入するためにサービスアカウントを使用します。

テンプレートにシークレット定義が含まれる場合、テンプレートで指定のシークレットを使用できるようにするには、シークレットのボリュームソースを検証し、指定されるオブジェクト参照が Secret オブジェクトを実際に参照していることを確認できる必要があります。そのため、シークレットはこれに依存する Pod の作成前に作成されている必要があります。最も効果的な方法として、サービスアカウントを使用してシークレットを自動的に挿入することができます。

シークレット API オブジェクトは namespace にあります。それらは同じ namespace の Pod によってのみ参照されます。

個々のシークレットは 1MB のサイズに制限されます。これにより、apiserver および kubelet メモリーを使い切るような大規模なシークレットの作成を防ぐことができます。ただし、小規模なシークレットであってもそれらを数多く作成するとメモリーの消費につながります。

2.6.2.2. 不透明なシークレットの作成
リンクのコピー

管理者は、不透明なシークレットを作成できます。これにより、任意の値を含むことができる非構造化 key:value のペアを格納できます。

手順

  1. コントロールプレーンノードの YAML ファイルに Secret オブジェクトを作成します。

    以下に例を示します。 

    apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
    1 
    
data:
  username: dXNlci1uYW1l
  password: cGFzc3dvcmQ=
    Copy to Clipboard Toggle word wrap
    1
    不透明なシークレットを指定します。

  2. 以下のコマンドを使用して Secret オブジェクトを作成します。 

    $ oc create -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

  3. Pod でシークレットを使用するには、以下を実行します。

    1. シークレットの作成方法についてセクションに示すように、Pod のサービスアカウントを更新してシークレットを参照します。
    2. シークレットの作成方法についてに示すように、シークレットを環境変数またはファイル (secret ボリュームを使用) として使用する Pod を作成します。
2.6.2.3. サービスアカウントトークンシークレットの作成
リンクのコピー

管理者は、サービスアカウントトークンシークレットを作成できます。これにより、API に対して認証する必要のあるアプリケーションにサービスアカウントトークンを配布できます。

注記

サービスアカウントトークンシークレットを使用する代わりに、TokenRequest API を使用してバインドされたサービスアカウントトークンを取得することをお勧めします。TokenRequest API から取得したトークンは、有効期間が制限されており、他の API クライアントが読み取れないため、シークレットに保存されているトークンよりも安全です。

TokenRequest API を使用できず、読み取り可能な API オブジェクトで有効期限が切れていないトークンのセキュリティーエクスポージャーが許容できる場合にのみ、サービスアカウントトークンシークレットを作成する必要があります。

バインドされたサービスアカウントトークンの作成に関する詳細は、以下の追加リソースセクションを参照してください。

手順

  1. コントロールプレーンノードの YAML ファイルに Secret オブジェクトを作成します。

    secret オブジェクトの例:

    apiVersion: v1
kind: Secret
metadata:
  name: secret-sa-sample
  annotations:
    kubernetes.io/service-account.name: "sa-name"
    1 
    
type: kubernetes.io/service-account-token
    2
    Copy to Clipboard Toggle word wrap

    1
    既存のサービスアカウント名を指定します。ServiceAccount と Secret オブジェクトの両方を作成する場合は、ServiceAccount オブジェクトを最初に作成します。
    2
    サービスアカウントトークンシークレットを指定します。

  2. 以下のコマンドを使用して Secret オブジェクトを作成します。 

    $ oc create -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

  3. Pod でシークレットを使用するには、以下を実行します。

    1. シークレットの作成方法についてセクションに示すように、Pod のサービスアカウントを更新してシークレットを参照します。
    2. シークレットの作成方法についてに示すように、シークレットを環境変数またはファイル (secret ボリュームを使用) として使用する Pod を作成します。
2.6.2.4. Basic 認証シークレットの作成
リンクのコピー

管理者は Basic 認証シークレットを作成できます。これにより、Basic 認証に必要な認証情報を保存できます。このシークレットタイプを使用する場合は、Secret オブジェクトの data パラメーターには、base64 形式でエンコードされた以下のキーが含まれている必要があります。

  • username: 認証用のユーザー名
  • password: 認証のパスワードまたはトークン
注記

stringData パラメーターを使用して、クリアテキストコンテンツを使用できます。

手順

  1. コントロールプレーンノードの YAML ファイルに Secret オブジェクトを作成します。

    secret オブジェクトの例

    apiVersion: v1
kind: Secret
metadata:
  name: secret-basic-auth
type: kubernetes.io/basic-auth
    1 
    
data:
stringData:
    2 
    
  username: admin
  password: t0p-Secret
    Copy to Clipboard Toggle word wrap

    1
    Basic 認証のシークレットを指定します。
    2
    使用する Basic 認証値を指定します。

  2. 以下のコマンドを使用して Secret オブジェクトを作成します。 

    $ oc create -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

  3. Pod でシークレットを使用するには、以下を実行します。

    1. シークレットの作成方法についてセクションに示すように、Pod のサービスアカウントを更新してシークレットを参照します。
    2. シークレットの作成方法についてに示すように、シークレットを環境変数またはファイル (secret ボリュームを使用) として使用する Pod を作成します。
2.6.2.5. SSH 認証シークレットの作成
リンクのコピー

管理者は、SSH 認証シークレットを作成できます。これにより、SSH 認証に使用されるデータを保存できます。このシークレットタイプを使用する場合、Secret オブジェクトの data パラメーターには、使用する SSH 認証情報が含まれている必要があります。

手順

  1. コントロールプレーンノードの YAML ファイルに Secret オブジェクトを作成します。

    secret オブジェクトの例:

    apiVersion: v1
kind: Secret
metadata:
  name: secret-ssh-auth
type: kubernetes.io/ssh-auth
    1 
    
data:
  ssh-privatekey: |
    2 
    
          MIIEpQIBAAKCAQEAulqb/Y ...
    Copy to Clipboard Toggle word wrap

    1
    SSH 認証シークレットを指定します。
    2
    SSH のキー/値のペアを、使用する SSH 認証情報として指定します。

  2. 以下のコマンドを使用して Secret オブジェクトを作成します。 

    $ oc create -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

  3. Pod でシークレットを使用するには、以下を実行します。

    1. シークレットの作成方法についてセクションに示すように、Pod のサービスアカウントを更新してシークレットを参照します。
    2. シークレットの作成方法についてに示すように、シークレットを環境変数またはファイル (secret ボリュームを使用) として使用する Pod を作成します。
2.6.2.6. Docker 設定シークレットの作成
リンクのコピー

管理者は Docker 設定シークレットを作成できます。これにより、コンテナーイメージレジストリーにアクセスするための認証情報を保存できます。

  • kubernetes.io/dockercfg.このシークレットタイプを使用してローカルの Docker 設定ファイルを保存します。secret オブジェクトの data パラメーターには、base64 形式でエンコードされた .dockercfg ファイルの内容が含まれている必要があります。
  • kubernetes.io/dockerconfigjson.このシークレットタイプを使用して、ローカルの Docker 設定 JSON ファイルを保存します。secret オブジェクトの data パラメーターには、base64 形式でエンコードされた .docker/config.json ファイルの内容が含まれている必要があります。

手順

  1. コントロールプレーンノードの YAML ファイルに Secret オブジェクトを作成します。

    Docker 設定の secret オブジェクトの例

    apiVersion: v1
kind: Secret
metadata:
  name: secret-docker-cfg
  namespace: my-project
type: kubernetes.io/dockerconfig
    1 
    
data:
  .dockerconfig:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==
    2
    Copy to Clipboard Toggle word wrap

    1
    シークレットが Docker 設定ファイルを使用することを指定します。
    2
    base64 でエンコードされた Docker 設定ファイルの出力

    Docker 設定の JSON secret オブジェクトの例

    apiVersion: v1
kind: Secret
metadata:
  name: secret-docker-json
  namespace: my-project
type: kubernetes.io/dockerconfig
    1 
    
data:
  .dockerconfigjson:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==
    2
    Copy to Clipboard Toggle word wrap

    1
    シークレットが Docker 設定の JSON ファイルを使用することを指定します。
    2
    base64 でエンコードされた Docker 設定 JSON ファイルの出力

  2. 以下のコマンドを使用して Secret オブジェクトを作成します。 

    $ oc create -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

  3. Pod でシークレットを使用するには、以下を実行します。

    1. シークレットの作成方法についてセクションに示すように、Pod のサービスアカウントを更新してシークレットを参照します。
    2. シークレットの作成方法についてに示すように、シークレットを環境変数またはファイル (secret ボリュームを使用) として使用する Pod を作成します。

2.6.3. シークレットの更新方法
リンクのコピー

シークレットの値を変更する場合、値 (すでに実行されている Pod で使用される値) は動的に変更されません。シークレットを変更するには、元の Pod を削除してから新規の Pod を作成する必要があります (同じ PodSpec を使用する場合があります)。

シークレットの更新は、新規コンテナーイメージのデプロイメントと同じワークフローで実行されます。kubectl rolling-update コマンドを使用できます。

シークレットの resourceVersion 値は参照時に指定されません。したがって、シークレットが Pod の起動と同じタイミングで更新される場合、Pod に使用されるシークレットのバージョンは定義されません。

注記

現時点で、Pod の作成時に使用されるシークレットオブジェクトのリソースバージョンを確認することはできません。コントローラーが古い resourceVersion を使用して Pod を再起動できるように、Pod がこの情報を報告できるようにすることが予定されています。それまでは既存シークレットのデータを更新せずに別の名前で新規のシークレットを作成します。

2.6.4. シークレットで署名証明書を使用する方法
リンクのコピー

サービスの通信を保護するため、プロジェクト内のシークレットに追加可能な、署名されたサービス証明書/キーペアを生成するように OpenShift Container Platform を設定することができます。

サービス提供証明書のシークレット は、追加設定なしの証明書を必要とする複雑なミドルウェアアプリケーションをサポートするように設計されています。これにはノードおよびマスターの管理者ツールで生成されるサーバー証明書と同じ設定が含まれます。

サービス提供証明書のシークレット用に設定されるサービス Pod 仕様

apiVersion: v1
kind: Service
metadata:
  name: registry
  annotations:
    service.beta.openshift.io/serving-cert-secret-name: registry-cert
1 

# ...
Copy to Clipboard Toggle word wrap

1
証明書の名前を指定します。

他の Pod は Pod に自動的にマウントされる /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt ファイルの CA バンドルを使用して、クラスターで作成される証明書 (内部 DNS 名の場合にのみ署名される) を信頼できます。

この機能の署名アルゴリズムは x509.SHA256WithRSA です。ローテーションを手動で実行するには、生成されたシークレットを削除します。新規の証明書が作成されます。

2.6.4.1. シークレットで使用する署名証明書の生成
リンクのコピー

署名されたサービス証明書/キーペアを Pod で使用するには、サービスを作成または編集して service.beta.openshift.io/serving-cert-secret-name アノテーションを追加した後に、シークレットを Pod に追加します。

手順

サービス提供証明書のシークレット を作成するには、以下を実行します。

  1. サービスの Pod 仕様を編集します。

  2. シークレットに使用する名前に service.beta.openshift.io/serving-cert-secret-name アノテーションを追加します。 

    kind: Service
apiVersion: v1
metadata:
  name: my-service
  annotations:
      service.beta.openshift.io/serving-cert-secret-name: my-cert
    1 
    
spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
    Copy to Clipboard Toggle word wrap

    証明書およびキーは PEM 形式であり、それぞれ tls.crt および tls.key に保存されます。

  3. サービスを作成します。 

    $ oc create -f <file-name>.yaml
    Copy to Clipboard Toggle word wrap

  4. シークレットを表示して、作成されていることを確認します。

    1. すべてのシークレットの一覧を表示します。 

      $ oc get secrets
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                     TYPE                                  DATA      AGE
my-cert                  kubernetes.io/tls                     2         9m
      Copy to Clipboard Toggle word wrap

    2. シークレットの詳細を表示します。 

      $ oc describe secret my-cert
      Copy to Clipboard Toggle word wrap

      出力例

      Name:         my-cert
Namespace:    openshift-console
Labels:       <none>
Annotations:  service.beta.openshift.io/expiry: 2023-03-08T23:22:40Z
              service.beta.openshift.io/originating-service-name: my-service
              service.beta.openshift.io/originating-service-uid: 640f0ec3-afc2-4380-bf31-a8c784846a11
              service.beta.openshift.io/expiry: 2023-03-08T23:22:40Z

Type:  kubernetes.io/tls

Data
====
tls.key:  1679 bytes
tls.crt:  2595 bytes
      Copy to Clipboard Toggle word wrap

  5. このシークレットを使って Pod 仕様を編集します。 

    apiVersion: v1
kind: Pod
metadata:
  name: my-service-pod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
  volumes:
  - name: foo
    secret:
      secretName: my-cert
      items:
      - key: username
        path: my-group/my-username
        mode: 511
    Copy to Clipboard Toggle word wrap

    これが利用可能な場合、Pod が実行されます。この証明書は内部サービス DNS 名、 <service.name>.<service.namespace>.svc に適しています。

    証明書/キーのペアは有効期限に近づくと自動的に置換されます。シークレットの service.beta.openshift.io/expiry アノテーションで RFC3339 形式の有効期限の日付を確認します。

    注記

    ほとんどの場合、サービス DNS 名 <service.name>.<service.namespace>.svc は外部にルーティング可能ではありません。<service.name>.<service.namespace>.svc の主な使用方法として、クラスターまたはサービス間の通信用として、 re-encrypt ルートで使用されます。

2.6.5. シークレットのトラブルシューティング
リンクのコピー

サービス証明書の生成は以下を出して失敗します (サービスの service.beta.openshift.io/serving-cert-generation-error アノテーションには以下が含まれます)。 

secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60
Copy to Clipboard Toggle word wrap

証明書を生成したサービスがすでに存在しないか、またはサービスに異なる serviceUID があります。古いシークレットを削除し、サービスのアノテーション (service.beta.openshift.io/serving-cert-generation-error、service.beta.openshift.io/serving-cert-generation-error-num) をクリアして証明書の再生成を強制的に実行する必要があります。

  1. シークレットを削除します。 

    $ oc delete secret <secret_name>
    Copy to Clipboard Toggle word wrap

  2. アノテーションをクリアします。 

    $ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-
    Copy to Clipboard Toggle word wrap 
    $ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num-
    Copy to Clipboard Toggle word wrap
注記

アノテーションを削除するコマンドでは、削除するアノテーション名の後に - を付けます。

2.7. 設定マップの作成および使用
リンクのコピー

以下のセクションでは、設定マップおよびそれらを作成し、使用する方法を定義します。

2.7.1. 設定マップについて
リンクのコピー

数多くのアプリケーションには、設定ファイル、コマンドライン引数、および環境変数の組み合わせを使用した設定が必要です。OpenShift Container Platform では、これらの設定アーティファクトは、コンテナー化されたアプリケーションを移植可能な状態に保つためにイメージコンテンツから切り離されます。

ConfigMap オブジェクトは、コンテナーを OpenShift Container Platform に依存させないようにする一方で、コンテナーに設定データを挿入するメカニズムを提供します。設定マップは、個々のプロパティーなどの粒度の細かい情報や、設定ファイル全体または JSON Blob などの粒度の荒い情報を保存するために使用できます。

ConfigMap API オブジェクトは、Pod で使用したり、コントローラーなどのシステムコンポーネントの設定データを保存するために使用できる設定データのキーと値のペアを保持します。以下に例を示します。

ConfigMap オブジェクト定義

kind: ConfigMap
apiVersion: v1
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: example-config
  namespace: default
data:
1 

  example.property.1: hello
  example.property.2: world
  example.property.file: |-
    property.1=value-1
    property.2=value-2
    property.3=value-3
binaryData:
  bar: L3Jvb3QvMTAw
2
Copy to Clipboard Toggle word wrap

1 1
設定データが含まれます。
2
バイナリー Java キーストアファイルなどの UTF8 以外のデータを含むファイルを参照します。Base 64 のファイルデータを入力します。
注記

イメージなどのバイナリーファイルから設定マップを作成する場合に、binaryData フィールドを使用できます。

設定データはさまざまな方法で Pod 内で使用できます。設定マップは以下を実行するために使用できます。

  • コンテナーへの環境変数値の設定
  • コンテナーのコマンドライン引数の設定
  • ボリュームの設定ファイルの設定

ユーザーとシステムコンポーネントの両方が設定データを設定マップに保存できます。

設定マップはシークレットに似ていますが、機密情報を含まない文字列の使用をより効果的にサポートするように設計されています。

設定マップの制限

設定マップは、コンテンツを Pod で使用される前に作成する必要があります。

コントローラーは、設定データが不足していても、その状況を許容して作成できます。ケースごとに設定マップを使用して設定される個々のコンポーネントを参照してください。

ConfigMap オブジェクトはプロジェクト内にあります。

それらは同じプロジェクトの Pod によってのみ参照されます。

Kubelet は、API サーバーから取得する Pod の設定マップの使用のみをサポートします。

これには、CLI を使用して作成された Pod、またはレプリケーションコントローラーから間接的に作成された Pod が含まれます。これには、OpenShift Container Platform ノードの --manifest-url フラグ、その --config フラグ、またはその REST API を使用して作成された Pod は含まれません (これらは Pod を作成する一般的な方法ではありません)。

2.7.2. OpenShift Container Platform Web コンソールでの設定マップの作成
リンクのコピー

OpenShift Container Platform Web コンソールで設定マップを作成できます。

手順

  • クラスター管理者として設定マップを作成するには、以下を実行します。

    1. Administrator パースペクティブで Workloads → Config Maps を選択します。
    2. ページの右上にある Create Config Map を選択します。
    3. 設定マップの内容を入力します。
    4. Create を選択します。

  • 開発者として設定マップを作成するには、以下を実行します。

    1. 開発者パースペクティブで、Config Maps を選択します。
    2. ページの右上にある Create Config Map を選択します。
    3. 設定マップの内容を入力します。
    4. Create を選択します。

2.7.3. CLI を使用して設定マップを作成する
リンクのコピー

以下のコマンドを使用して、ディレクトリー、特定のファイルまたはリテラル値から設定マップを作成できます。

手順

  • 設定マップの作成 

    $ oc create configmap <configmap_name> [options]
    Copy to Clipboard Toggle word wrap
2.7.3.1. ディレクトリーからの設定マップの作成
リンクのコピー

ディレクトリーから設定マップを作成できます。この方法では、ディレクトリー内の複数のファイルを使用して設定マップを作成できます。

手順

以下の例の手順は、ディレクトリーから設定マップを作成する方法を説明しています。

  1. 設定マップの設定に必要なデータがすでに含まれるファイルのあるディレクトリーについて見てみましょう。 

    $ ls example-files
    Copy to Clipboard Toggle word wrap

    出力例

    game.properties
ui.properties
    Copy to Clipboard Toggle word wrap 

    $ cat example-files/game.properties
    Copy to Clipboard Toggle word wrap

    出力例

    enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
    Copy to Clipboard Toggle word wrap 

    $ cat example-files/ui.properties
    Copy to Clipboard Toggle word wrap

    出力例

    color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを入力して、このディレクトリー内の各ファイルの内容を保持する設定マップを作成します。 

    $ oc create configmap game-config \
    --from-file=example-files/
    Copy to Clipboard Toggle word wrap

    --from-file オプションがディレクトリーを参照する場合、そのディレクトリーに直接含まれる各ファイルが ConfigMap でキーを設定するために使用されます。 このキーの名前はファイル名であり、キーの値はファイルの内容になります。

    たとえば、前のコマンドは次の設定マップを作成します。 

    $ oc describe configmaps game-config
    Copy to Clipboard Toggle word wrap

    出力例

    Name:           game-config
Namespace:      default
Labels:         <none>
Annotations:    <none>

Data

game.properties:        158 bytes
ui.properties:          83 bytes
    Copy to Clipboard Toggle word wrap

    マップにある 2 つのキーが、コマンドで指定されたディレクトリーのファイル名に基づいて作成されていることに気づかれることでしょう。それらのキーの内容のサイズは大きくなる可能性があるため、oc describe の出力はキーの名前とキーのサイズのみを表示します。

  3. -o オプションを使用してオブジェクトの oc get コマンドを入力し、キーの値を表示します。 

    $ oc get configmaps game-config -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

    apiVersion: v1
data:
  game.properties: |-
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:34:05Z
  name: game-config
  namespace: default
  resourceVersion: "407"
  selflink: /api/v1/namespaces/default/configmaps/game-config
  uid: 30944725-d66e-11e5-8cd0-68f728db1985
    Copy to Clipboard Toggle word wrap

2.7.3.2. ファイルから設定マップを作成する
リンクのコピー

ファイルから設定マップを作成できます。

手順

以下の手順例では、ファイルから設定マップを作成する方法を説明します。

注記

ファイルから設定マップを作成する場合、UTF8 以外のデータを破損することなく、UTF8 以外のデータを含むファイルをこの新規フィールドに配置できます。OpenShift Container Platform はバイナリーファイルを検出し、ファイルを MIME として透過的にエンコーディングします。サーバーでは、データを破損することなく MIME ペイロードがデコーディングされ、保存されます。

--from-file オプションを CLI に複数回渡すことができます。以下の例を実行すると、ディレクトリーからの作成の例と同等の結果を出すことができます。

  1. 特定のファイルを指定して設定マップを作成します。 

    $ oc create configmap game-config-2 \
    --from-file=example-files/game.properties \
    --from-file=example-files/ui.properties
    Copy to Clipboard Toggle word wrap

  2. 結果を確認します。 

    $ oc get configmaps game-config-2 -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

    apiVersion: v1
data:
  game.properties: |-
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:52:05Z
  name: game-config-2
  namespace: default
  resourceVersion: "516"
  selflink: /api/v1/namespaces/default/configmaps/game-config-2
  uid: b4952dc3-d670-11e5-8cd0-68f728db1985
    Copy to Clipboard Toggle word wrap

ファイルからインポートされたコンテンツの設定マップで設定するキーを指定できます。これは、key=value 式を --from-file オプションに渡すことで設定できます。以下に例を示します。

  1. キーと値のペアを指定して、設定マップを作成します。 

    $ oc create configmap game-config-3 \
    --from-file=game-special-key=example-files/game.properties
    Copy to Clipboard Toggle word wrap

  2. 結果を確認します。 

    $ oc get configmaps game-config-3 -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

    apiVersion: v1
data:
  game-special-key: |-
    1 
    
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:54:22Z
  name: game-config-3
  namespace: default
  resourceVersion: "530"
  selflink: /api/v1/namespaces/default/configmaps/game-config-3
  uid: 05f8da22-d671-11e5-8cd0-68f728db1985
    Copy to Clipboard Toggle word wrap

    1
    これは、先の手順で設定したキーです。
2.7.3.3. リテラル値からの設定マップの作成
リンクのコピー

設定マップにリテラル値を指定することができます。

手順

--from-literal オプションは、リテラル値をコマンドラインに直接指定できる key=value 構文を取ります。

  1. リテラル値を指定して設定マップを作成します。 

    $ oc create configmap special-config \
    --from-literal=special.how=very \
    --from-literal=special.type=charm
    Copy to Clipboard Toggle word wrap

  2. 結果を確認します。 

    $ oc get configmaps special-config -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

    apiVersion: v1
data:
  special.how: very
  special.type: charm
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: special-config
  namespace: default
  resourceVersion: "651"
  selflink: /api/v1/namespaces/default/configmaps/special-config
  uid: dadce046-d673-11e5-8cd0-68f728db1985
    Copy to Clipboard Toggle word wrap

2.7.4. ユースケース: Pod で設定マップを使用する
リンクのコピー

以下のセクションでは、Pod で ConfigMap オブジェクトを使用する際のいくつかのユースケースについて説明します。

2.7.4.1. 設定マップの使用によるコンテナーでの環境変数の設定
リンクのコピー

設定マップはコンテナーで個別の環境変数を設定するために使用したり、有効な環境変数名を生成するすべてのキーを使用してコンテナーで環境変数を設定するために使用したりすることができます。

例として、以下の設定マップについて見てみましょう。

2 つの環境変数を含む ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
1 

  namespace: default
2 

data:
  special.how: very
3 

  special.type: charm
4
Copy to Clipboard Toggle word wrap

1
設定マップの名前。
2
設定マップが存在するプロジェクト。設定マップは同じプロジェクトの Pod によってのみ参照されます。
3 4
挿入する環境変数。

1 つの環境変数を含む ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: env-config
1 

  namespace: default
data:
  log_level: INFO
2
Copy to Clipboard Toggle word wrap

1
設定マップの名前。
2
挿入する環境変数。

手順

  • configMapKeyRef セクションを使用して、Pod のこの ConfigMap のキーを使用できます。

    特定の環境変数を挿入するように設定されている Pod 仕様のサンプル

    apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:
    1 
    
        - name: SPECIAL_LEVEL_KEY
    2 
    
          valueFrom:
            configMapKeyRef:
              name: special-config
    3 
    
              key: special.how
    4 
    
        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
    5 
    
              key: special.type
    6 
    
              optional: true
    7 
    
      envFrom:
    8 
    
        - configMapRef:
            name: env-config
    9 
    
  restartPolicy: Never
    Copy to Clipboard Toggle word wrap

    1
    ConfigMap から指定された環境変数をプルするためのスタンザです。
    2
    キーの値を挿入する Pod 環境変数の名前です。
    3 5
    特定の環境変数のプルに使用する ConfigMap の名前です。
    4 6
    ConfigMap からプルする環境変数です。
    7
    環境変数をオプションにします。オプションとして、Pod は指定された ConfigMap およびキーが存在しない場合でも起動します。
    8
    ConfigMap からすべての環境変数をプルするためのスタンザです。
    9
    すべての環境変数のプルに使用する ConfigMap の名前です。

    この Pod が実行されると、Pod のログには以下の出力が含まれます。 

    SPECIAL_LEVEL_KEY=very
log_level=INFO
    Copy to Clipboard Toggle word wrap
注記

SPECIAL_TYPE_KEY=charm は出力例に一覧表示されません。optional: true が設定されているためです。

2.7.4.2. 設定マップを使用したコンテナーコマンドのコマンドライン引数の設定
リンクのコピー

設定マップを使用して、コンテナー内のコマンドまたは引数の値を設定することもできます。これは、Kubernetes 置換構文 $(VAR_NAME) を使用して実行できます。次の設定マップを検討してください。 

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm
Copy to Clipboard Toggle word wrap

手順

  • 値をコンテナーのコマンドに挿入するには、環境変数で ConfigMap を使用する場合のように環境変数として使用する必要のあるキーを使用する必要があります。次に、$(VAR_NAME) 構文を使用してコンテナーのコマンドでそれらを参照することができます。

    特定の環境変数を挿入するように設定されている Pod 仕様のサンプル

    apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]
    1 
    
      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.how
        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.type
  restartPolicy: Never
    Copy to Clipboard Toggle word wrap

    1
    環境変数として使用するキーを使用して、コンテナーのコマンドに値を挿入します。

    この Pod が実行されると、test-container コンテナーで実行される echo コマンドの出力は以下のようになります。 

    very charm
    Copy to Clipboard Toggle word wrap
2.7.4.3. 設定マップの使用によるボリュームへのコンテンツの挿入
リンクのコピー

設定マップを使用して、コンテンツをボリュームに挿入することができます。

ConfigMap カスタムリソース (CR) の例

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm
Copy to Clipboard Toggle word wrap

手順

設定マップを使用してコンテンツをボリュームに挿入するには、2 つの異なるオプションを使用できます。

  • 設定マップを使用してコンテンツをボリュームに挿入するための最も基本的な方法は、キーがファイル名であり、ファイルの内容がキーの値になっているファイルでボリュームを設定する方法です。 

    apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "cat", "/etc/config/special.how" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config
    1 
    
  restartPolicy: Never
    Copy to Clipboard Toggle word wrap
    1
    キーを含むファイル。

    この Pod が実行されると、cat コマンドの出力は以下のようになります。 

    very
    Copy to Clipboard Toggle word wrap

  • 設定マップキーが投影されるボリューム内のパスを制御することもできます。 

    apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "cat", "/etc/config/path/to/special-key" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config
        items:
        - key: special.how
          path: path/to/special-key
    1 
    
  restartPolicy: Never
    Copy to Clipboard Toggle word wrap
    1
    設定マップキーへのパス。

    この Pod が実行されると、cat コマンドの出力は以下のようになります。 

    very
    Copy to Clipboard Toggle word wrap

2.8. Pod で外部リソースにアクセスするためのデバイスプラグインの使用
リンクのコピー

デバイスプラグインを使用すると、カスタムコードを作成せずに特定のデバイスタイプ (GPU、InfiniBand、またはベンダー固有の初期化およびセットアップを必要とする他の同様のコンピューティングリソース) を OpenShift Container Platform Pod で使用できます。

2.8.1. デバイスプラグインについて
リンクのコピー

デバイスプラグインは、クラスター間でハードウェアデバイスを使用する際の一貫した移植可能なソリューションを提供します。デバイスプラグインは、拡張メカニズムを通じてこれらのデバイスをサポートし (これにより、コンテナーがこれらのデバイスを利用できるようになります)、デバイスのヘルスチェックを実施し、それらを安全に共有します。

重要

OpenShift Container Platform はデバイスのプラグイン API をサポートしますが、デバイスプラグインコンテナーは個別のベンダーによりサポートされます。

デバイスプラグインは、特定のハードウェアリソースの管理を行う、ノード上で実行される gRPC サービスです (kubelet の外部にあります)。デバイスプラグインは以下のリモートプロシージャーコール (RPC) をサポートしている必要があります。 

service DevicePlugin {
      // GetDevicePluginOptions returns options to be communicated with Device
      // Manager
      rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {}

      // ListAndWatch returns a stream of List of Devices
      // Whenever a Device state change or a Device disappears, ListAndWatch
      // returns the new list
      rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}

      // Allocate is called during container creation so that the Device
      // Plug-in can run device specific operations and instruct Kubelet
      // of the steps to make the Device available in the container
      rpc Allocate(AllocateRequest) returns (AllocateResponse) {}

      // PreStartcontainer is called, if indicated by Device Plug-in during
      // registration phase, before each container start. Device plug-in
      // can run device specific operations such as reseting the device
      // before making devices available to the container
      rpc PreStartcontainer(PreStartcontainerRequest) returns (PreStartcontainerResponse) {}
}
Copy to Clipboard Toggle word wrap
デバイスプラグインの例
注記

デバイスプラグイン参照の実装を容易にするために、vendor/k8s.io/kubernetes/pkg/kubelet/cm/deviceplugin/device_plugin_stub.go という Device Manager コードのスタブデバイスプラグインを使用できます。

2.8.1.1. デバイスプラグインのデプロイ方法
リンクのコピー
  • デーモンセットは、デバイスプラグインのデプロイメントに推奨される方法です。
  • 起動時にデバイスプラグインは、デバイスマネージャーから RPC を送信するためにノードの /var/lib/kubelet/device-plugin/ での UNIX ドメインソケットの作成を試行します。
  • デバイスプラグインは、ソケットの作成のほかにもハードウェアリソース、ホストファイルシステムへのアクセスを管理する必要があるため、特権付きセキュリティーコンテキストで実行される必要があります。
  • デプロイメント手順の詳細については、それぞれのデバイスプラグインの実装で確認できます。

2.8.2. デバイスマネージャーについて
リンクのコピー

デバイスマネージャーは、特殊なノードのハードウェアリソースを、デバイスプラグインとして知られるプラグインを使って公開するメカニズムを提供します。

特殊なハードウェアは、アップストリームのコード変更なしに公開できます。

重要

OpenShift Container Platform はデバイスのプラグイン API をサポートしますが、デバイスプラグインコンテナーは個別のベンダーによりサポートされます。

デバイスマネージャーはデバイスを 拡張リソース として公開します。ユーザー Pod は、他の 拡張リソース を要求するために使用されるのと同じ 制限/要求 メカニズムを使用してデバイスマネージャーで公開されるデバイスを消費できます。

使用開始時に、デバイスプラグインは /var/lib/kubelet/device-plugins/kubelet.sock の Register を起動してデバイスマネージャーに自己登録し、デバイスマネージャーの要求を提供するために /var/lib/kubelet/device-plugins/<plugin>.sock で gRPC サービスを起動します。

デバイスマネージャーは、新規登録要求の処理時にデバイスプラグインサービスで ListAndWatch リモートプロシージャーコール (RPC) を起動します。応答としてデバイスマネージャーは gRPC ストリームでプラグインから デバイス オブジェクトの一覧を取得します。デバイスマネージャーはプラグインからの新規の更新の有無についてストリームを監視します。プラグイン側では、プラグインはストリームを開いた状態にし、デバイスの状態に変更があった場合には常に新規デバイスの一覧が同じストリーム接続でデバイスマネージャーに送信されます。

新規 Pod の受付要求の処理時に、Kubelet はデバイスの割り当てのために要求された Extended Resource をデバイスマネージャーに送信します。デバイスマネージャーはそのデータベースにチェックインして対応するプラグインが存在するかどうかを確認します。プラグインが存在し、ローカルキャッシュと共に割り当て可能な空きデバイスがある場合、Allocate RPC がその特定デバイスのプラグインで起動します。

さらにデバイスプラグインは、ドライバーのインストール、デバイスの初期化、およびデバイスのリセットなどの他のいくつかのデバイス固有の操作も実行できます。これらの機能は実装ごとに異なります。

2.8.3. デバイスマネージャーの有効化
リンクのコピー

デバイスマネージャーを有効にし、デバイスプラグインを実装してアップストリームのコード変更なしに特殊なハードウェアを公開できるようにします。

デバイスマネージャーは、特殊なノードのハードウェアリソースを、デバイスプラグインとして知られるプラグインを使って公開するメカニズムを提供します。

  1. 設定するノードタイプの静的な MachineConfigPool CRD に関連付けられたラベルを取得します。以下のいずれかの手順を実行します。

    1. マシン設定を表示します。 

      # oc describe machineconfig <name>
      Copy to Clipboard Toggle word wrap

      以下に例を示します。 

      # oc describe machineconfig 00-worker
      Copy to Clipboard Toggle word wrap

      出力例

      Name:         00-worker
Namespace:
Labels:       machineconfiguration.openshift.io/role=worker
      1
      Copy to Clipboard Toggle word wrap

      1
      デバイスマネージャーに必要なラベル。

手順

  1. 設定変更のためのカスタムリソース (CR) を作成します。

    Device Manager CR の設定例

    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: devicemgr
    1 
    
spec:
  machineConfigPoolSelector:
    matchLabels:
       machineconfiguration.openshift.io: devicemgr
    2 
    
  kubeletConfig:
    feature-gates:
      - DevicePlugins=true
    3
    Copy to Clipboard Toggle word wrap

    1
    CR に名前を割り当てます。
    2
    Machine Config Pool からラベルを入力します。
    3
    DevicePlugins を 'true` に設定します。

  2. デバイスマネージャーを作成します。 

    $ oc create -f devicemgr.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    kubeletconfig.machineconfiguration.openshift.io/devicemgr created
    Copy to Clipboard Toggle word wrap

  3. デバイスマネージャーが実際に有効にされるように、/var/lib/kubelet/device-plugins/kubelet.sock がノードで作成されていることを確認します。これは、デバイスマネージャーの gRPC サーバーが新規プラグインの登録がないかどうかリッスンする UNIX ドメインソケットです。このソケットファイルは、デバイスマネージャーが有効にされている場合にのみ Kubelet の起動時に作成されます。

2.9. Pod スケジューリングの決定に Pod の優先順位を含める
リンクのコピー

クラスターで Pod の優先順位およびプリエンプションを有効にできます。Pod の優先度は、他の Pod との比較した Pod の重要度を示し、その優先度に基づいて Pod をキューに入れます。Pod のプリエンプションは、クラスターが優先順位の低い Pod のエビクトまたはプリエンプションを実行することを可能にするため、適切なノードに利用可能な領域がない場合に優先順位のより高い Pod をスケジュールできます。 Pod の優先順位は Pod のスケジューリングの順序にも影響を与え、リソース不足の場合のノード上でのエビクションの順序に影響を与えます。

優先順位およびプリエンプションを使用するには、Pod の相対的な重みを定義する優先順位クラスを作成します。次に Pod 仕様で優先順位クラスを参照し、スケジューリングの重みを適用します。

2.9.1. Pod の優先順位について
リンクのコピー

Pod の優先順位およびプリエンプション機能を使用する場合、スケジューラーは優先順位に基づいて保留中の Pod を順序付け、保留中の Pod はスケジューリングのキューで優先順位のより低い他の保留中の Pod よりも前に置かれます。その結果、より優先順位の高い Pod は、スケジューリングの要件を満たす場合に優先順位の低い Pod よりも早くスケジュールされる可能性があります。Pod をスケジュールできない場合、スケジューラーは引き続き他の優先順位の低い Pod をスケジュールします。

2.9.1.1. Pod の優先順位クラス
リンクのコピー

Pod には優先順位クラスを割り当てることができます。これは、名前から優先順位の整数値へのマッピングを定義する namespace を使用していないオブジェクトです。値が高いと優先順位が高くなります。

優先順位およびプリエンプションは、1000000000 (10 億) 以下の 32 ビットの整数値を取ることができます。プリエンプションやエビクションを実行すべきでない Critical Pod 用に 10 億より大きい数を予約します。デフォルトで、OpenShift Container Platform には 2 つの予約された優先順位クラスがあり、これらは重要なシステム Pod で保証されたスケジューリングが適用されるために使用されます。 

$ oc get priorityclasses
Copy to Clipboard Toggle word wrap

出力例

NAME                      VALUE        GLOBAL-DEFAULT   AGE
cluster-logging           1000000      false            29s
system-cluster-critical   2000000000   false            72m
system-node-critical      2000001000   false            72m
Copy to Clipboard Toggle word wrap

  • system-node-critical: この優先順位クラスには 2000001000 の値があり、ノードからエビクトすべきでないすべての Pod に使用されます。この優先順位クラスを持つ Pod の例として、sdn-ovs、sdn などがあります。数多くの重要なコンポーネントには、デフォルトで system-node-critical の優先順位クラスが含まれます。以下は例になります。

    • master-api
    • master-controller
    • master-etcd
    • sdn
    • sdn-ovs
    • sync

  • system-cluster-critical: この優先順位クラスには 2000000000 (20 億) の値があり、クラスターに重要な Pod に使用されます。この優先順位クラスの Pod は特定の状況でノードからエビクトされる可能性があります。たとえば、system-node-critical 優先順位クラスで設定される Pod が優先される可能性があります。この場合でも、この優先順位クラスではスケジューリングが保証されます。この優先順位クラスを持つ可能性のある Pod の例として、fluentd、descheduler などのアドオンコンポーネントなどがあります。数多くの重要なコンポーネントには、デフォルトで system-cluster-critical 優先順位クラスが含まれます。 以下はその一例です。

    • fluentd
    • metrics-server
    • descheduler
  • cluster-logging: この優先順位は、Fluentd Pod が他のアプリケーションより優先してノードにスケジュールされるようにするために Fluentd で使用されます。
2.9.1.2. Pod の優先順位名
リンクのコピー

1 つ以上の優先順位クラスを準備した後に、Pod 仕様に優先順位クラス名を指定する Pod を作成できます。優先順位の受付コントローラーは、優先順位クラス名フィールドを使用して優先順位の整数値を設定します。名前付きの優先順位クラスが見つからない場合、Pod は拒否されます。

2.9.2. Pod のプリエンプションについて
リンクのコピー

開発者が Pod を作成する場合、Pod はキューに入れられます。開発者が Pod の優先順位またはプリエンプションを設定している場合、スケジューラーはキューから Pod を選択し、Pod をノードにスケジュールしようとします。スケジューラーが Pod について指定されたすべての要件を満たす適切なノードに領域を見つけられない場合、プリエンプションロジックが保留中の Pod についてトリガーされます。

スケジューラーがノードで 1 つ以上の Pod のプリエンプションを実行する場合、優先順位の高い Pod 仕様の nominatedNodeName フィールドは、nodename フィールドと共にノードの名前に設定されます。スケジューラーは nominatedNodeName フィールドを使用して Pod の予約されたリソースを追跡し、またクラスターのプリエンプションについての情報をユーザーに提供します。

スケジューラーが優先順位の低い Pod のプリエンプションを実行した後に、スケジューラーは Pod の正常な終了期間を許可します。スケジューラーが優先順位の低い Pod の終了を待機する間に別のノードが利用可能になると、スケジューラーはそのノードに優先順位の高い Pod をスケジュールできます。その結果、Pod 仕様の nominatedNodeName フィールドおよび nodeName フィールドが異なる可能性があります。

さらに、スケジューラーがノード上で Pod のプリエンプションを実行し、終了を待機している場合で、保留中の Pod よりも優先順位の高い Pod をスケジュールする必要がある場合、スケジューラーは代わりに優先順位の高い Pod をスケジュールできます。その場合、スケジューラーは保留中の Pod の nominatedNodeName をクリアし、その Pod を他のノードの対象とすることができます。

プリエンプションは、ノードから優先順位の低いすべての Pod を削除する訳ではありません。スケジューラーは、優先順位の低い Pod の一部を削除して保留中の Pod をスケジュールできます。

スケジューラーは、保留中の Pod をノードにスケジュールできる場合にのみ、Pod のプリエンプションを実行するノードを考慮します。

2.9.2.1. Pod プリエンプションおよび他のスケジューラーの設定
リンクのコピー

Pod の優先順位およびプリエンプションを有効にする場合、他のスケジューラー設定を考慮します。

Pod の優先順位および Pod の Disruption Budget (停止状態の予算)
Pod の Disruption Budget (停止状態の予算) は一度に稼働している必要のあるレプリカの最小数またはパーセンテージを指定します。Pod の Disruption Budget (停止状態の予算) を指定する場合、OpenShift Container Platform は、 Best Effort レベルで Pod のプリエンプションを実行する際にそれらを適用します。スケジューラーは、Pod の Disruption Budget (停止状態の予算) に違反しない範囲で Pod のプリエンプションを試行します。該当する Pod が見つからない場合には、Pod の Disruption Budget (停止状態の予算) の要件を無視して優先順位の低い Pod のプリエンプションが実行される可能性があります。
Pod の優先順位およびアフィニティー
Pod のアフィニティーは、新規 Pod が同じラベルを持つ他の Pod と同じノードにスケジュールされることを要求します。

保留中の Pod にノード上の 1 つ以上の優先順位の低い Pod との Pod 間のアフィニティーがある場合、スケジューラーはアフィニティーの要件を違反せずに優先順位の低い Pod のプリエンプションを実行することはできません。この場合、スケジューラーは保留中の Pod をスケジュールするための別のノードを探します。ただし、スケジューラーが適切なノードを見つけることは保証できず、保留中の Pod がスケジュールされない可能性があります。

この状態を防ぐには、優先順位が等しい Pod との Pod のアフィニティーの設定を慎重に行ってください。

2.9.2.2. プリエンプションが実行された Pod の正常な終了
リンクのコピー

Pod のプリエンプションの実行中、スケジューラーは Pod の正常な終了期間が期限切れになるのを待機します。その後、Pod は機能を完了し、終了します。Pod がこの期間後も終了しない場合、スケジューラーは Pod を強制終了します。 この正常な終了期間により、スケジューラーによる Pod のプリエンプションの実行時と保留中の Pod のノードへのスケジュール時に時間差が出ます。

この時間差を最小限にするには、優先順位の低い Pod の正常な終了期間を短く設定します。

2.9.3. 優先順位およびプリエンプションの設定
リンクのコピー

Pod 仕様で priorityClassName を使用して優先順位クラスオブジェクトを作成し、Pod を優先順位に関連付けることで、Pod の優先度およびプリエンプションを適用できます。

優先順位クラスオブジェクトのサンプル

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
1 

value: 1000000
2 

globalDefault: false
3 

description: "This priority class should be used for XYZ service pods only."
4
Copy to Clipboard Toggle word wrap

1
優先順位クラスオブジェクトの名前です。
2
オブジェクトの優先順位の値です。
3
この優先順位クラスが優先順位クラス名が指定されない状態で Pod に使用されるかどうかを示すオプションのフィールドです。このフィールドはデフォルトで false です。globalDefault が true に設定される 1 つの優先順位クラスのみがクラスター内に存在できます。globalDefault:true が設定された優先順位クラスがない場合、優先順位クラス名が設定されていない Pod の優先順位はゼロになります。globalDefault:true が設定された優先順位クラスを追加すると、優先順位クラスが追加された後に作成された Pod のみがその影響を受け、これによって既存 Pod の優先順位は変更されません。
4
開発者がこの優先順位クラスで使用する必要のある Pod を記述するオプションのテキスト文字列です。

手順

優先順位およびプリエンプションを使用するようにクラスターを設定するには、以下を実行します。

  1. 1 つ以上の優先順位クラスを作成します。

    1. 優先順位の名前および値を指定します。
    2. 優先順位クラスおよび説明に globalDefault フィールドをオプションで指定します。

  2. Pod 仕様を作成するか、または既存の Pod を編集して、以下のように優先順位クラスの名前を含めます。

    優先順位クラス名を持つ Pod 仕様サンプル

    apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  priorityClassName: high-priority
    1
    Copy to Clipboard Toggle word wrap

    1
    この Pod で使用する優先順位クラスを指定します。

  3. Pod を作成します。 

    $ oc create -f <file-name>.yaml
    Copy to Clipboard Toggle word wrap

    優先順位の名前は Pod 設定または Pod テンプレートに直接追加できます。

2.10. ノードセレクターの使用による特定ノードへの Pod の配置
リンクのコピー

ノードセレクター は、キーと値のペアのマップを指定します。ルールは、ノード上のカスタムラベルと Pod で指定されたセレクターを使って定義されます。

Pod がノードで実行する要件を満たすには、Pod はノードのラベルとして示されるキーと値のペアを持っている必要があります。

同じ Pod 設定でノードのアフィニティーとノードセレクターを使用している場合、以下の重要な考慮事項を参照してください。

2.10.1. ノードセレクターの使用による Pod 配置の制御
リンクのコピー

Pod でノードセレクターを使用し、ノードでラベルを使用して、Pod がスケジュールされる場所を制御できます。ノードセレクターにより、OpenShift Container Platform は一致するラベルが含まれるノード上に Pod をスケジュールします。

ラベルをノード、マシンセット、またはマシン設定に追加します。マシンセットにラベルを追加すると、ノードまたはマシンが停止した場合に、新規ノードにそのラベルが追加されます。ノードまたはマシン設定に追加されるラベルは、ノードまたはマシンが停止すると維持されません。

ノードセレクターを既存 Pod に追加するには、ノードセレクターを ReplicaSet オブジェクト、DaemonSet オブジェクト、StatefulSet オブジェクト、Deployment オブジェクト、または DeploymentConfig オブジェクトなどの Pod の制御オブジェクトに追加します。制御オブジェクト下の既存 Pod は、一致するラベルを持つノードで再作成されます。新規 Pod を作成する場合、ノードセレクターを Pod 仕様に直接追加できます。

注記

ノードセレクターを既存のスケジュールされている Pod に直接追加することはできません。

前提条件

ノードセレクターを既存 Pod に追加するには、Pod の制御オブジェクトを判別します。たとえば、router-default-66d5cf9464-m2g75 Pod は router-default-66d5cf9464 レプリカセットによって制御されます。 

$ oc describe pod router-default-66d5cf9464-7pwkc

Name:               router-default-66d5cf9464-7pwkc
Namespace:          openshift-ingress

....

Controlled By:      ReplicaSet/router-default-66d5cf9464
Copy to Clipboard Toggle word wrap

Web コンソールでは、Pod YAML の ownerReferences に制御オブジェクトを一覧表示します。 

  ownerReferences:
    - apiVersion: apps/v1
      kind: ReplicaSet
      name: router-default-66d5cf9464
      uid: d81dd094-da26-11e9-a48a-128e7edf0312
      controller: true
      blockOwnerDeletion: true
Copy to Clipboard Toggle word wrap

手順

  1. マシンセットを使用するか、またはノードを直接編集してラベルをノードに追加します。

    • MachineSet オブジェクトを使用して、ノードの作成時にマシンセットによって管理されるノードにラベルを追加します。

      1. 以下のコマンドを実行してラベルを MachineSet オブジェクトに追加します。 

        $ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api
        Copy to Clipboard Toggle word wrap

        以下に例を示します。 

        $ oc patch MachineSet abc612-msrtw-worker-us-east-1c  --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api
        Copy to Clipboard Toggle word wrap

      2. oc edit コマンドを使用して、ラベルが MachineSet オブジェクトに追加されていることを確認します。

        以下に例を示します。 

        $ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api
        Copy to Clipboard Toggle word wrap

        MachineSet オブジェクトの例

        apiVersion: machine.openshift.io/v1beta1
kind: MachineSet

....

spec:
...
  template:
    metadata:
...
    spec:
      metadata:
        labels:
          region: east
          type: user-node
....
        Copy to Clipboard Toggle word wrap

    • ラベルをノードに直接追加します。

      1. ノードの Node オブジェクトを編集します。 

        $ oc label nodes <name> <key>=<value>
        Copy to Clipboard Toggle word wrap

        たとえば、ノードにラベルを付けるには、以下を実行します。 

        $ oc label nodes ip-10-0-142-25.ec2.internal type=user-node region=east
        Copy to Clipboard Toggle word wrap

      2. ラベルがノードに追加されていることを確認します。 

        $ oc get nodes -l type=user-node,region=east
        Copy to Clipboard Toggle word wrap

        出力例

        NAME                          STATUS   ROLES    AGE   VERSION
ip-10-0-142-25.ec2.internal   Ready    worker   17m   v1.18.3+002a51f
        Copy to Clipboard Toggle word wrap

  2. 一致するノードセレクターを Pod に追加します。

    • ノードセレクターを既存 Pod および新規 Pod に追加するには、ノードセレクターを Pod の制御オブジェクトに追加します。

      ラベルを含む ReplicaSet オブジェクトのサンプル

      kind: ReplicaSet

....

spec:

....

  template:
    metadata:
      creationTimestamp: null
      labels:
        ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
        pod-template-hash: 66d5cf9464
    spec:
      nodeSelector:
        kubernetes.io/os: linux
        node-role.kubernetes.io/worker: ''
        type: user-node
      1
      Copy to Clipboard Toggle word wrap

      1
      ノードセレクターを追加します。

    • ノードセレクターを特定の新規 Pod に追加するには、セレクターを Pod オブジェクトに直接追加します。

      ノードセレクターを持つ Pod オブジェクトの例

      apiVersion: v1
kind: Pod

....

spec:
  nodeSelector:
    region: east
    type: user-node
      Copy to Clipboard Toggle word wrap

      注記

      ノードセレクターを既存のスケジュールされている Pod に直接追加することはできません。

第3章 Pod のノードへの配置の制御 (スケジューリング)
リンクのコピー

3.1. スケジューラーによる Pod 配置の制御
リンクのコピー

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

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

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

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

3.1.1. スケジューラーの使用例
リンクのコピー

OpenShift Container Platform 内でのスケジューリングの重要な使用例として、柔軟なアフィニティーと非アフィニティーポリシーのサポートを挙げることができます。

3.1.1.1. インフラストラクチャーのトポロジーレベル
リンクのコピー

管理者は、ノードにラベルを指定することで、インフラストラクチャー (ノード) の複数のトポロジーレベルを定義することができます。たとえば、region=r1、zone=z1、rack=s1 などはそれらの例になります。

これらのラベル名には特別な意味はなく、管理者はそれらのインフラストラクチャーラベルに任意の名前 (例: 都市/建物/部屋) を付けることができます。さらに、管理者はインフラストラクチャートポロジーに任意の数のレベルを定義できます。通常は、(regions → zones → racks) などの 3 つのレベルが適切なサイズです。管理者はこれらのレベルのそれぞれにアフィニティーと非アフィニティールールを任意の組み合わせで指定することができます。

3.1.1.2. アフィニティー
リンクのコピー

管理者は、任意のトポロジーレベルまたは複数のレベルでもアフィニティーを指定できるようにスケジューラーを設定することができます。特定レベルのアフィニティーは、同じサービスに属するすべての Pod が同じレベルに属するノードにスケジュールされることを示します。これは、管理者がピア Pod が地理的に離れ過ぎないようにすることでアプリケーションの待機時間の要件に対応します。同じアフィニティーグループ内で Pod をホストするために利用できるノードがない場合、Pod はスケジュールされません。

Pod がスケジュールされる場所に対する制御を強化する必要がある場合は、ノードアフィニティールールを使用したノードへの Pod 配置の制御、および アフィニティーおよび非アフィニティールールを使用した他の Pod に応じた Pod 配置 について参照してください。

これらの高度なスケジュール機能を使うと、管理者は Pod をスケジュールするノードを指定でき、他の Pod との比較でスケジューリングを実行したり、拒否したりすることができます。

3.1.1.3. 非アフィニティー
リンクのコピー

管理者は、任意のトポロジーレベルまたは複数のレベルでも非アフィニティーを設定できるようスケジューラーを設定することができます。特定レベルの非アフィニティー (または分散) は、同じサービスに属するすべての Pod が該当レベルに属するノード全体に分散されることを示します。これにより、アプリケーションが高可用性の目的で適正に分散されます。スケジューラーは、可能な限り均等になるようにすべての適用可能なノード全体にサービス Pod を配置しようとします。

Pod がスケジュールされる場所に対する制御を強化する必要がある場合は、ノードアフィニティールールを使用したノードへの Pod 配置の制御、および アフィニティーおよび非アフィニティールールを使用した他の Pod に応じた Pod 配置 について参照してください。

これらの高度なスケジュール機能を使うと、管理者は Pod をスケジュールするノードを指定でき、他の Pod との比較でスケジューリングを実行したり、拒否したりすることができます。

3.2. デフォルトスケジューラーの設定による Pod 配置の制御
リンクのコピー

OpenShift Container Platform のデフォルトの Pod スケジューラーは、クラスター内のノードにおける新規 Pod の配置場所を判別します。スケジューラーは Pod からのデータを読み取り、設定されるポリシーに基づいて適切なノードを見つけようとします。これは完全に独立した機能であり、スタンドアロン/プラグ可能ソリューションです。Pod を変更することはなく、Pod を特定ノードに関連付ける Pod のバインディングのみを作成します。

述語と優先順位を選択することで、スケジューラーのポリシーを定義できます。述語と優先順位の一覧は、スケジューラーポリシーの変更 を参照してください。

デフォルトスケジューラーオブジェクトのサンプル

apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  annotations:
    release.openshift.io/create-only: "true"
  creationTimestamp: 2019-05-20T15:39:01Z
  generation: 1
  name: cluster
  resourceVersion: "1491"
  selfLink: /apis/config.openshift.io/v1/schedulers/cluster
  uid: 6435dd99-7b15-11e9-bd48-0aec821b8e34
spec:
  policy:
1 

    name: scheduler-policy
  defaultNodeSelector: type=user-node,region=east
2
Copy to Clipboard Toggle word wrap

1
カスタムスケジューラーポリシーファイルの名前を指定できます。
2
オプション: Pod の配置を特定のノードに制限するためにデフォルトノードセレクターを指定します。デフォルトのノードセレクターはすべての namespace で作成された Pod に適用されます。Pod は、デフォルトのノードセレクターおよび既存の Pod のノードセレクターに一致するラベルのあるノードにスケジュールできます。このフィールドが設定されている場合でも、プロジェクトスコープのノードセレクターを持つ namespace は影響を受けません。

3.2.1. デフォルトスケジューリングについて
リンクのコピー

既存の汎用スケジューラーはプラットフォームで提供されるデフォルトのスケジューラー エンジン であり、Pod をホストするノードを 3 つの手順で選択します。

ノードのフィルター
利用可能なノードは、指定される制約や要件に基づいてフィルターされます。フィルターは、各ノードで 述語 というフィルター関数の一覧を使用して実行されます。
フィルターされたノード一覧の優先順位付け
優先順位付けは、各ノードに一連の優先度関数を実行することによって行われます。この関数は 0 -10 までのスコアをノードに割り当て、0 は不適切であることを示し、10 は Pod のホストに適していることを示します。スケジューラー設定は、それぞれの優先度関数について単純な 重み (正の数値) を取ることができます。各優先度関数で指定されるノードのスコアは重み (ほとんどの優先度のデフォルトの重みは 1) で乗算され、すべての優先度で指定されるそれぞれのノードのスコアを追加して組み合わされます。この重み属性は、一部の優先度により重きを置くようにするなどの目的で管理者によって使用されます。
最適ノードの選択
ノードの並び替えはそれらのスコアに基づいて行われ、最高のスコアを持つノードが Pod をホストするように選択されます。複数のノードに同じ高スコアが付けられている場合、それらのいずれかがランダムに選択されます。
3.2.1.1. スケジューラーポリシーについて
リンクのコピー

述語と優先順位を選択することで、スケジューラーのポリシーを定義します。

スケジューラー設定ファイルは JSON ファイルであり、policy.cfg という名前にする必要があります。これは、スケジューラーが反映する述語と優先順位を指定します。

スケジューラーポリシーがない場合、デフォルトのスケジューラーの動作が使用されます。

重要

スケジューラー設定ファイルで定義される述語および優先度は、デフォルトのスケジューラーポリシーを完全に上書きします。デフォルトの述語および優先順位のいずれかが必要な場合、ポリシーの設定でその関数を明示的に指定する必要があります。

スケジューラー設定マップの例

apiVersion: v1
data:
  policy.cfg: |
    {
        "kind" : "Policy",
        "apiVersion" : "v1",
        "predicates" : [
                {"name" : "MaxGCEPDVolumeCount"},
                {"name" : "GeneralPredicates"},
1 

                {"name" : "MaxAzureDiskVolumeCount"},
                {"name" : "MaxCSIVolumeCountPred"},
                {"name" : "CheckVolumeBinding"},
                {"name" : "MaxEBSVolumeCount"},
                {"name" : "MatchInterPodAffinity"},
                {"name" : "CheckNodeUnschedulable"},
                {"name" : "NoDiskConflict"},
                {"name" : "NoVolumeZoneConflict"},
                {"name" : "PodToleratesNodeTaints"}
                ],
        "priorities" : [
                {"name" : "LeastRequestedPriority", "weight" : 1},
                {"name" : "BalancedResourceAllocation", "weight" : 1},
                {"name" : "ServiceSpreadingPriority", "weight" : 1},
                {"name" : "NodePreferAvoidPodsPriority", "weight" : 1},
                {"name" : "NodeAffinityPriority", "weight" : 1},
                {"name" : "TaintTolerationPriority", "weight" : 1},
                {"name" : "ImageLocalityPriority", "weight" : 1},
                {"name" : "SelectorSpreadPriority", "weight" : 1},
                {"name" : "InterPodAffinityPriority", "weight" : 1},
                {"name" : "EqualPriority", "weight" : 1}
                ]
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2019-09-17T08:42:33Z"
  name: scheduler-policy
  namespace: openshift-config
  resourceVersion: "59500"
  selfLink: /api/v1/namespaces/openshift-config/configmaps/scheduler-policy
  uid: 17ee8865-d927-11e9-b213-02d1e1709840`
Copy to Clipboard Toggle word wrap

1
GeneralPredicates 述語は PodFitsResources、HostName、PodFitsHostPorts、および MatchNodeSelector 述語を表します。同じ述語を複数回設定することは許可されていないため、GeneralPredicates 述語を、表現される 4 つの述語と共に使用することはできません。

3.2.2. スケジューラーポリシーファイルの作成
リンクのコピー

デフォルトのスケジューリング動作を変更するには、必要な述語および優先順位を使用して JSON ファイルを作成します。次に、JSON ファイルから設定マップを生成し、設定マップを使用するように cluster スケジューラーオブジェクトを指定します。

手順

スケジューラーポリシーを設定するには、以下を実行します。

  1. 必要な述語と優先順位を使って policy.cfg という名前の JSON ファイルを作成します。

    スケジューラー JSON ファイルのサンプル

    {
"kind" : "Policy",
"apiVersion" : "v1",
"predicates" : [
    1 
    
        {"name" : "MaxGCEPDVolumeCount"},
        {"name" : "GeneralPredicates"},
        {"name" : "MaxAzureDiskVolumeCount"},
        {"name" : "MaxCSIVolumeCountPred"},
        {"name" : "CheckVolumeBinding"},
        {"name" : "MaxEBSVolumeCount"},
        {"name" : "MatchInterPodAffinity"},
        {"name" : "CheckNodeUnschedulable"},
        {"name" : "NoDiskConflict"},
        {"name" : "NoVolumeZoneConflict"},
        {"name" : "PodToleratesNodeTaints"}
        ],
"priorities" : [
    2 
    
        {"name" : "LeastRequestedPriority", "weight" : 1},
        {"name" : "BalancedResourceAllocation", "weight" : 1},
        {"name" : "ServiceSpreadingPriority", "weight" : 1},
        {"name" : "NodePreferAvoidPodsPriority", "weight" : 1},
        {"name" : "NodeAffinityPriority", "weight" : 1},
        {"name" : "TaintTolerationPriority", "weight" : 1},
        {"name" : "ImageLocalityPriority", "weight" : 1},
        {"name" : "SelectorSpreadPriority", "weight" : 1},
        {"name" : "InterPodAffinityPriority", "weight" : 1},
        {"name" : "EqualPriority", "weight" : 1}
        ]
}
    Copy to Clipboard Toggle word wrap

    1
    必要に応じて述語を追加します。
    2
    必要に応じて優先順位を追加します。

  2. スケジューラー JSON ファイルに基づいて設定マップを作成します。 

    $ oc create configmap -n openshift-config --from-file=policy.cfg <configmap-name>
    1
    Copy to Clipboard Toggle word wrap
    1
    設定マップの名前を入力します。

    以下に例を示します。 

    $ oc create configmap -n openshift-config --from-file=policy.cfg scheduler-policy
    Copy to Clipboard Toggle word wrap

    出力例

    configmap/scheduler-policy created
    Copy to Clipboard Toggle word wrap

  3. スケジューラー Operator カスタムリソースを編集して設定マップを追加します。 

    $ oc patch Scheduler cluster --type='merge' -p '{"spec":{"policy":{"name":"<configmap-name>"}}}' --type=merge
    1
    Copy to Clipboard Toggle word wrap
    1
    設定マップの名前を指定します。

    以下に例を示します。 

    $ oc patch Scheduler cluster --type='merge' -p '{"spec":{"policy":{"name":"scheduler-policy"}}}' --type=merge
    Copy to Clipboard Toggle word wrap

    Scheduler 設定リソースに変更を加えた後に、openshift-kube-apiserver Pod の再デプロイを待機します。これには数分の時間がかかる場合があります。Pod が再デプロイされるまで、新規スケジューラーは有効になりません。

  4. openshift-kube-scheduler namespace のスケジューラー Pod のログを表示して、スケジューラーポリシーが設定されていることを確認します。以下のコマンドは、スケジューラーによって登録される述語と優先順位をチェックします。 

    $ oc logs <scheduler-pod> | grep predicates
    Copy to Clipboard Toggle word wrap

    以下に例を示します。 

    $ oc logs openshift-kube-scheduler-ip-10-0-141-29.ec2.internal | grep predicates
    Copy to Clipboard Toggle word wrap

    出力例

    Creating scheduler with fit predicates 'map[MaxGCEPDVolumeCount:{} MaxAzureDiskVolumeCount:{} CheckNodeUnschedulable:{} NoDiskConflict:{} NoVolumeZoneConflict:{} GeneralPredicates:{} MaxCSIVolumeCountPred:{} CheckVolumeBinding:{} MaxEBSVolumeCount:{} MatchInterPodAffinity:{} PodToleratesNodeTaints:{}]' and priority functions 'map[InterPodAffinityPriority:{} LeastRequestedPriority:{} ServiceSpreadingPriority:{} ImageLocalityPriority:{} SelectorSpreadPriority:{} EqualPriority:{} BalancedResourceAllocation:{} NodePreferAvoidPodsPriority:{} NodeAffinityPriority:{} TaintTolerationPriority:{}]'
    Copy to Clipboard Toggle word wrap

3.2.3. スケジューラーポリシーの変更
リンクのコピー

openshift-config プロジェクトでスケジューラーポリシーの設定マップを作成または編集して、スケジューリング動作を変更します。scheduler policy を作成するには、述語と優先順位の追加および削除を設定マップに対して実行します。

手順

現在のカスタムスケジュールを変更するには、以下のいずれかの方法を使用します。

  • スケジューラーポリシーの設定マップを編集します。 

    $ oc edit configmap <configmap-name>  -n openshift-config
    Copy to Clipboard Toggle word wrap

    以下に例を示します。 

    $ oc edit configmap scheduler-policy -n openshift-config
    Copy to Clipboard Toggle word wrap

    出力例

    apiVersion: v1
data:
  policy.cfg: |
    {
        "kind" : "Policy",
        "apiVersion" : "v1",
        "predicates" : [
    1 
    
                {"name" : "MaxGCEPDVolumeCount"},
                {"name" : "GeneralPredicates"},
                {"name" : "MaxAzureDiskVolumeCount"},
                {"name" : "MaxCSIVolumeCountPred"},
                {"name" : "CheckVolumeBinding"},
                {"name" : "MaxEBSVolumeCount"},
                {"name" : "MatchInterPodAffinity"},
                {"name" : "CheckNodeUnschedulable"},
                {"name" : "NoDiskConflict"},
                {"name" : "NoVolumeZoneConflict"},
                {"name" : "PodToleratesNodeTaints"}
                ],
        "priorities" : [
    2 
    
                {"name" : "LeastRequestedPriority", "weight" : 1},
                {"name" : "BalancedResourceAllocation", "weight" : 1},
                {"name" : "ServiceSpreadingPriority", "weight" : 1},
                {"name" : "NodePreferAvoidPodsPriority", "weight" : 1},
                {"name" : "NodeAffinityPriority", "weight" : 1},
                {"name" : "TaintTolerationPriority", "weight" : 1},
                {"name" : "ImageLocalityPriority", "weight" : 1},
                {"name" : "SelectorSpreadPriority", "weight" : 1},
                {"name" : "InterPodAffinityPriority", "weight" : 1},
                {"name" : "EqualPriority", "weight" : 1}
                ]
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2019-09-17T17:44:19Z"
  name: scheduler-policy
  namespace: openshift-config
  resourceVersion: "15370"
  selfLink: /api/v1/namespaces/openshift-config/configmaps/scheduler-policy
    Copy to Clipboard Toggle word wrap

    1
    必要に応じて述語を追加または削除します。
    2
    必要に応じて述語の重みを追加、削除、または変更します。

    スケジューラーが更新されたポリシーで Pod を再起動するまでに数分の時間がかかる場合があります。

  • 使用されるポリシーと述語を変更します。

    1. スケジューラーポリシーの設定マップを削除します。 

      $ oc delete configmap -n openshift-config <name>
      Copy to Clipboard Toggle word wrap

      以下に例を示します。 

      $ oc delete configmap -n openshift-config  scheduler-policy
      Copy to Clipboard Toggle word wrap

    2. policy.cfg ファイルを編集し、必要に応じてポリシーおよび述語を追加し、削除します。

      以下に例を示します。 

      $ vi policy.cfg
      Copy to Clipboard Toggle word wrap

      出力例

      apiVersion: v1
data:
  policy.cfg: |
    {
    "kind" : "Policy",
    "apiVersion" : "v1",
    "predicates" : [
            {"name" : "MaxGCEPDVolumeCount"},
            {"name" : "GeneralPredicates"},
            {"name" : "MaxAzureDiskVolumeCount"},
            {"name" : "MaxCSIVolumeCountPred"},
            {"name" : "CheckVolumeBinding"},
            {"name" : "MaxEBSVolumeCount"},
            {"name" : "MatchInterPodAffinity"},
            {"name" : "CheckNodeUnschedulable"},
            {"name" : "NoDiskConflict"},
            {"name" : "NoVolumeZoneConflict"},
            {"name" : "PodToleratesNodeTaints"}
            ],
    "priorities" : [
            {"name" : "LeastRequestedPriority", "weight" : 1},
            {"name" : "BalancedResourceAllocation", "weight" : 1},
            {"name" : "ServiceSpreadingPriority", "weight" : 1},
            {"name" : "NodePreferAvoidPodsPriority", "weight" : 1},
            {"name" : "NodeAffinityPriority", "weight" : 1},
            {"name" : "TaintTolerationPriority", "weight" : 1},
            {"name" : "ImageLocalityPriority", "weight" : 1},
            {"name" : "SelectorSpreadPriority", "weight" : 1},
            {"name" : "InterPodAffinityPriority", "weight" : 1},
            {"name" : "EqualPriority", "weight" : 1}
            ]
    }
      Copy to Clipboard Toggle word wrap

    3. スケジューラー JSON ファイルに基づいてスケジューラーポリシーの設定マップを再作成します。 

      $ oc create configmap -n openshift-config --from-file=policy.cfg <configmap-name>
      1
      Copy to Clipboard Toggle word wrap
      1
      設定マップの名前を入力します。

      以下に例を示します。 

      $ oc create configmap -n openshift-config --from-file=policy.cfg scheduler-policy
      Copy to Clipboard Toggle word wrap

      出力例

      configmap/scheduler-policy created
      Copy to Clipboard Toggle word wrap

3.2.3.1. スケジューラーの述語について
リンクのコピー

述語は、不適切なノードをフィルターに掛けるルールです。

OpenShift Container Platform には、デフォルトでいくつかの述語が提供されています。これらの述語の一部は、特定のパラメーターを指定してカスタマイズできます。複数の述語を組み合わせてノードの追加フィルターを指定できます。

3.2.3.1.1. 静的な述語
リンクのコピー

これらの述語はユーザーから設定パラメーターまたは入力を取りません。これらはそれぞれの正確な名前を使用してスケジューラー設定に指定されます。

3.2.3.1.1.1. デフォルトの述語
リンクのコピー

デフォルトのスケジューラーポリシーには以下の述語が含まれます。

NoVolumeZoneConflict 述語は Pod が要求するボリュームがゾーンで利用可能であることを確認します。 

{"name" : "NoVolumeZoneConflict"}
Copy to Clipboard Toggle word wrap

MaxEBSVolumeCount 述語は、AWS インスタンスに割り当てることのできるボリュームの最大数を確認します。 

{"name" : "MaxEBSVolumeCount"}
Copy to Clipboard Toggle word wrap

MaxAzureDiskVolumeCount 述語は Azure ディスクボリュームの最大数をチェックします。 

{"name" : "MaxAzureDiskVolumeCount"}
Copy to Clipboard Toggle word wrap

PodToleratesNodeTaints 述語は Pod がノードテイントを許容できるかどうかをチェックします。 

{"name" : "PodToleratesNodeTaints"}
Copy to Clipboard Toggle word wrap

CheckNodeUnschedulable 述語は、Pod を Unschedulable 仕様でノード上にスケジュールできるかどうかをチェックします。 

{"name" : "CheckNodeUnschedulable"}
Copy to Clipboard Toggle word wrap

CheckVolumeBinding 述語は、バインドされた PVC とバインドされていない PVC の両方について Pod が要求するボリュームに基づいて Pod が適切かどうかを評価します。

  • バインドされる PVC の場合、述語は対応する PV のノードアフィニティーが指定ノードで満たされていることをチェックします。
  • バインドされない PVC の場合、述語は PVC 要件を満たし、PV ノードのアフィニティーが指定ノードで満たされる利用可能な PV を検索します。

述語は、すべてのバインドされる PVC にノードと互換性のある PV がある場合や、すべてのバインドされていない PVC が利用可能なノードと互換性のある PV に一致する場合に true を返します。 

{"name" : "CheckVolumeBinding"}
Copy to Clipboard Toggle word wrap

NoDiskConflict 述語は Pod が要求するボリュームが利用可能であるかどうかを確認します。 

{"name" : "NoDiskConflict"}
Copy to Clipboard Toggle word wrap

MaxGCEPDVolumeCount 述語は、Google Compute Engine (GCE) 永続ディスク (PD) の最大数を確認します。 

{"name" : "MaxGCEPDVolumeCount"}
Copy to Clipboard Toggle word wrap

MaxCSIVolumeCountPred 述語は、ノードに割り当てられる Container Storage Interface (CSI) ボリュームの数と、その数が設定した制限を超えるかどうかを判別します。 

{"name" : "MaxCSIVolumeCountPred"}
Copy to Clipboard Toggle word wrap

MatchInterPodAffinity 述語は、Pod のアフィニティー/非アフィニティールールが Pod を許可するかどうかを確認します。 

{"name" : "MatchInterPodAffinity"}
Copy to Clipboard Toggle word wrap
3.2.3.1.1.2. 他の静的な述語
リンクのコピー

OpenShift Container Platform は以下の述語もサポートしています。

注記

CheckNode-* 述語は、Taint Nodes By Condition 機能が有効にされている場合は使用できません。Taint Nodes By Condition 機能はデフォルトで有効にされています。

CheckNodeCondition 述語は、out of disk (ディスク不足)、network unavailable (ネットワークが使用不可)、または not ready (準備できていない) 状態を報告するノードで Pod をスケジュールできるかどうかを確認します。 

{"name" : "CheckNodeCondition"}
Copy to Clipboard Toggle word wrap

CheckNodeLabelPresence 述語は、すべての指定されたラベルがノードに存在するかどうかを確認します (その値が何であるかを問わない)。 

{"name" : "CheckNodeLabelPresence"}
Copy to Clipboard Toggle word wrap

checkServiceAffinity 述語は、ServiceAffinity ラベルがノードでスケジュールされる Pod について同種のものであることを確認します。 

{"name" : "checkServiceAffinity"}
Copy to Clipboard Toggle word wrap

PodToleratesNodeNoExecuteTaints 述語は、Pod がノードの NoExecute テイントを容認できるかどうかを確認します。 

{"name" : "PodToleratesNodeNoExecuteTaints"}
Copy to Clipboard Toggle word wrap
3.2.3.1.2. 汎用的な述語
リンクのコピー

以下の汎用的な述語は、非クリティカル述語とクリティカル述語が渡されるかどうかを確認します。非クリティカル述語は、非 Critical Pod のみが渡す必要のある述語であり、クリティカル述語はすべての Pod が渡す必要のある述語です。

デフォルトのスケジューラーポリシーにはこの汎用的な述語が含まれます。

汎用的な非クリティカル述語

PodFitsResources 述語は、リソースの可用性 (CPU、メモリー、GPU など) に基づいて適切な候補を判別します。ノードはそれらのリソース容量を宣言し、Pod は要求するリソースを指定できます。使用されるリソースではなく、要求されるリソースに基づいて適切な候補が判別されます。 

{"name" : "PodFitsResources"}
Copy to Clipboard Toggle word wrap
汎用的なクリティカル述語

PodFitsHostPorts 述語は、ノードに要求される Pod ポートの空きポートがある (ポートの競合がない) かどうかを判別します。 

{"name" : "PodFitsHostPorts"}
Copy to Clipboard Toggle word wrap

HostName 述語は、ホストパラメーターの有無と文字列のホスト名との一致に基づいて適切なノードを判別します。 

{"name" : "HostName"}
Copy to Clipboard Toggle word wrap

MatchNodeSelector 述語は、Pod で定義されるノードセレクター (nodeSelector) のクエリーに基づいて適したノードを判別します。 

{"name" : "MatchNodeSelector"}
Copy to Clipboard Toggle word wrap
3.2.3.2. スケジューラーの優先順位について
リンクのコピー

優先順位は、設定に応じてノードにランクを付けるルールです。

優先度のカスタムセットは、スケジューラーを設定するために指定できます。OpenShift Container Platform ではデフォルトでいくつかの優先度があります。他の優先度は、特定のパラメーターを指定してカスタマイズできます。優先順位に影響を与えるために、複数の優先度を組み合わせ、異なる重みをそれぞれのノードに指定することができます。

3.2.3.2.1. 静的優先度
リンクのコピー

静的優先度は、重みを除き、ユーザーからいずれの設定パラメーターも取りません。重みは指定する必要があり、0 または負の値にすることはできません。

これらは openshift-config プロジェクトのスケジューラーポリシー設定マップに指定されます。

3.2.3.2.1.1. デフォルトの優先度
リンクのコピー

デフォルトのスケジューラーポリシーには、以下の優先度が含まれています。それぞれの優先度関数は、重み 10000 を持つ NodePreferAvoidPodsPriority 以外は重み 1 を持ちます。

NodeAffinityPriority の優先度は、ノードアフィニティーのスケジュールの優先度に応じてノードに優先順位を付けます。 

{"name" : "NodeAffinityPriority", "weight" : 1}
Copy to Clipboard Toggle word wrap

TaintTolerationPriority の優先度は、Pod についての 容認不可能な テイント数の少ないノードを優先します。容認不可能なテイントとはキー PreferNoSchedule のあるテイントのことです。 

{"name" : "TaintTolerationPriority", "weight" : 1}
Copy to Clipboard Toggle word wrap

ImageLocalityPriority の優先度は、Pod コンテナーのイメージをすでに要求しているノードを優先します。 

{"name" : "ImageLocalityPriority", "weight" : 1}
Copy to Clipboard Toggle word wrap

SelectorSpreadPriority は、Pod に一致するサービス、レプリケーションコントローラー (RC)、レプリケーションセット (RS)、およびステートフルなセットを検索し、次にそれらのセレクターに一致する既存の Pod を検索します。スケジューラーは、一致する既存の Pod が少ないノードを優先します。次に、Pod のスケジュール時にそれらのセレクターに一致する Pod 数の最も少ないノードで Pod をスケジュールします。 

{"name" : "SelectorSpreadPriority", "weight" : 1}
Copy to Clipboard Toggle word wrap

InterPodAffinityPriority の優先度は、ノードの対応する PodAffinityTerm が満たされている場合に weightedPodAffinityTerm の要素を使った繰り返し処理や 重み の合計への追加によって合計を計算します。合計値の最も高いノードが最も優先されます。 

{"name" : "InterPodAffinityPriority", "weight" : 1}
Copy to Clipboard Toggle word wrap

LeastRequestedPriority の優先度は、要求されたリソースの少ないノードを優先します。これは、ノードでスケジュールされる Pod によって要求されるメモリーおよび CPU のパーセンテージを計算し、利用可能な/残りの容量の値の最も高いノードを優先します。 

{"name" : "LeastRequestedPriority", "weight" : 1}
Copy to Clipboard Toggle word wrap

BalancedResourceAllocation の優先度は、均衡が図られたリソース使用率に基づいてノードを優先します。これは、容量の一部として消費済み CPU とメモリー間の差異を計算し、2 つのメトリクスがどの程度相互に近似しているかに基づいてノードの優先度を決定します。これは常に LeastRequestedPriority と併用する必要があります。 

{"name" : "BalancedResourceAllocation", "weight" : 1}
Copy to Clipboard Toggle word wrap

NodePreferAvoidPodsPriority の優先度は、レプリケーションコントローラー以外のコントローラーによって所有される Pod を無視します。 

{"name" : "NodePreferAvoidPodsPriority", "weight" : 10000}
Copy to Clipboard Toggle word wrap
3.2.3.2.1.2. 他の静的優先度
リンクのコピー

OpenShift Container Platform は以下の優先度もサポートしています。

EqualPriority の優先度は、優先度の設定が指定されていない場合に、すべてのノードに等しい重み 1 を指定します。この優先順位はテスト環境にのみ使用することを推奨します。 

{"name" : "EqualPriority", "weight" : 1}
Copy to Clipboard Toggle word wrap

MostRequestedPriority の優先度は、要求されたリソースの最も多いノードを優先します。これは、ノードスケジュールされる Pod で要求されるメモリーおよび CPU のパーセンテージを計算し、容量に対して要求される部分の平均の最大値に基づいて優先度を決定します。 

{"name" : "MostRequestedPriority", "weight" : 1}
Copy to Clipboard Toggle word wrap

ServiceSpreadingPriority の優先度は、同じマシンに置かれる同じサービスに属する Pod 数を最小限にすることにより Pod を分散します。 

{"name" : "ServiceSpreadingPriority", "weight" : 1}
Copy to Clipboard Toggle word wrap
3.2.3.2.2. 設定可能な優先順位
リンクのコピー

これらの優先順位を openshift-config namespace のスケジューラーポリシー設定マップに設定し、優先順位の機能に影響を与えるラベルを追加できます。

優先度関数のタイプは、それらが取る引数によって識別されます。これらは設定可能なため、ユーザー定義の名前が異なる場合に、同じタイプの (ただし設定パラメーターは異なる) 設定可能な複数の優先度を組み合わせることができます。

優先順位の使用方法については、スケジューラーポリシーの変更についての箇所を参照してください。

ServiceAntiAffinity の優先度はラベルを取り、ラベルの値に基づいてノードのグループ全体に同じサービスに属する Pod を適正に分散します。これは、指定されたラベルの同じ値を持つすべてのノードに同じスコアを付与します。また Pod が最も集中していないグループ内のノードにより高いスコアを付与します。 

{
"kind": "Policy",
"apiVersion": "v1",

"priorities":[
    {
        "name":"<name>",
1 

        "weight" : 1
2 

        "argument":{
            "serviceAntiAffinity":{
                "label": "<label>"
3 

                }
           }
       }
   ]
}
Copy to Clipboard Toggle word wrap
1
優先度の名前を指定します。
2
重みを指定します。ゼロ以外の正の値を指定します。
3
一致するラベルを指定します。

以下に例を示します。 

{
"kind": "Policy",
"apiVersion": "v1",
"priorities": [
    {
        "name":"RackSpread",
        "weight" : 1,
        "argument": {
            "serviceAntiAffinity": {
                "label": "rack"
                }
           }
       }
   ]
}
Copy to Clipboard Toggle word wrap
注記

カスタムラベルに基づいて ServiceAntiAffinity パラメーターを使用しても Pod を予想通りに展開できない場合があります。Red Hat ソリューション を参照してください。

labelPreference パラメーターは指定されたラベルに基づいて優先順位を指定します。ラベルがノードにある場合、そのノードに優先度が指定されます。ラベルが指定されていない場合は、優先度はラベルを持たないノードに指定されます。labelPreference パラメーターのある複数の優先度が設定されている場合、すべての優先度に同じ重みが付けられている必要があります。 

{
"kind": "Policy",
"apiVersion": "v1",
"priorities":[
    {
        "name":"<name>",
1 

        "weight" : 1
2 

        "argument":{
            "labelPreference":{
                "label": "<label>",
3 

                "presence": true
4 

                }
            }
        }
    ]
}
Copy to Clipboard Toggle word wrap
1
優先度の名前を指定します。
2
重みを指定します。ゼロ以外の正の値を指定します。
3
一致するラベルを指定します。
4
ラベルが必要であるかを、true または false のいずれかで指定します。

3.2.4. ポリシー設定のサンプル
リンクのコピー

以下の設定は、スケジューラーポリシーファイルを使って指定される場合のデフォルトのスケジューラー設定を示しています。 

{
"kind": "Policy",
"apiVersion": "v1",
"predicates": [
    {
        "name": "RegionZoneAffinity",
1 

        "argument": {
            "serviceAffinity": {
2 

              "labels": ["region, zone"]
3 

           }
        }
     }
  ],
"priorities": [
    {
        "name":"RackSpread",
4 

        "weight" : 1,
        "argument": {
            "serviceAntiAffinity": {
5 

                "label": "rack"
6 

                }
           }
       }
   ]
}
Copy to Clipboard Toggle word wrap
1
述語の名前です。
2
述語のタイプです。
3
述語のラベルです。
4
優先順位の名前です。
5
優先順位のタイプです。
6
優先順位のラベルです。

以下の設定例のいずれの場合も、述語と優先度関数の一覧は、指定された使用例に関連するもののみを含むように切り捨てられます。実際には、完全な/分かりやすいスケジューラーポリシーには、上記のデフォルトの述語および優先度のほとんど (すべてではなくても) が含まれるはずです。

以下の例は、region (affinity) → zone (affinity) → rack (anti-affinity) の 3 つのトポロジーレベルを定義します。 

{
"kind": "Policy",
"apiVersion": "v1",
"predicates": [
    {
        "name": "RegionZoneAffinity",
        "argument": {
            "serviceAffinity": {
              "labels": ["region, zone"]
           }
        }
     }
  ],
"priorities": [
    {
        "name":"RackSpread",
        "weight" : 1,
        "argument": {
            "serviceAntiAffinity": {
                "label": "rack"
                }
           }
       }
   ]
}
Copy to Clipboard Toggle word wrap

以下の例は、city (affinity) → building (anti-affinity) → room (anti-affinity) の 3 つのとポロジーレベルを定義します。 

{
"kind": "Policy",
"apiVersion": "v1",
"predicates": [
    {
        "name": "CityAffinity",
        "argument": {
            "serviceAffinity": {
              "label": "city"
           }
        }
     }
  ],
"priorities": [
    {
        "name":"BuildingSpread",
        "weight" : 1,
        "argument": {
            "serviceAntiAffinity": {
                "label": "building"
                }
           }
       },
    {
        "name":"RoomSpread",
        "weight" : 1,
        "argument": {
            "serviceAntiAffinity": {
                "label": "room"
                }
           }
       }
   ]
}
Copy to Clipboard Toggle word wrap

以下の例では、region ラベルが定義されたノードのみを使用し、zone ラベルが定義されたノードを優先するポリシーを定義します。 

{
"kind": "Policy",
"apiVersion": "v1",
"predicates": [
    {
        "name": "RequireRegion",
        "argument": {
            "labelPreference": {
                "labels": ["region"],
                "presence": true
           }
        }
     }
  ],
"priorities": [
    {
        "name":"ZonePreferred",
        "weight" : 1,
        "argument": {
            "labelPreference": {
                "label": "zone",
                "presence": true
                }
           }
       }
   ]
}
Copy to Clipboard Toggle word wrap

以下の例では、静的および設定可能な述語および優先順位を組み合わせています。 

{
"kind": "Policy",
"apiVersion": "v1",
"predicates": [
    {
        "name": "RegionAffinity",
        "argument": {
            "serviceAffinity": {
                "labels": ["region"]
           }
        }
     },
    {
        "name": "RequireRegion",
        "argument": {
            "labelsPresence": {
                "labels": ["region"],
                "presence": true
           }
        }
     },
    {
        "name": "BuildingNodesAvoid",
        "argument": {
            "labelsPresence": {
                "label": "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}
    ]
}
Copy to Clipboard Toggle word wrap

アフィニティーとは、スケジュールするノードを制御する Pod の特性です。非アフィニティーとは、Pod がスケジュールされることを拒否する Pod の特性です。

OpenShift Container Platform では、Pod のアフィニティー と Pod の非アフィニティー によって、他の Pod のキー/値ラベルに基づいて、Pod のスケジュールに適したノードを制限することができます。

3.3.1. 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 つのタイプがあります。

Pod をノードにスケジュールする前に、required (必須) ルールを 満たしている必要があります。preferred (優先) ルールは、ルールを満たす場合に、スケジューラーはルールの実施を試行しますが、その実施が必ずしも保証される訳ではありません。

注記

Pod の優先順位およびプリエンプションの設定により、スケジューラーはアフィニティーの要件に違反しなければ Pod の適切なノードを見つけられない可能性があります。その場合、Pod はスケジュールされない可能性があります。

この状態を防ぐには、優先順位が等しい Pod との 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
Copy to Clipboard Toggle word wrap

1
Pod のアフィニティーを設定するためのスタンザです。
2
required (必須) ルールを定義します。
3 5
ルールを適用するために一致している必要のあるキーと値 (ラベル) です。
4
演算子は、既存 Pod のラベルと新規 Pod の仕様の matchExpression パラメーターの値のセットの間の関係を表します。これには In、NotIn、Exists、または 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
          topologyKey: kubernetes.io/hostname
  containers:
  - name: with-pod-affinity
    image: docker.io/ocpqe/hello-pod
Copy to Clipboard Toggle word wrap

1
Pod の非アフィニティーを設定するためのスタンザです。
2
preferred (優先) ルールを定義します。
3
preferred (優先) ルールの重みを指定します。最も高い重みを持つノードが優先されます。
4
非アフィニティールールが適用される時を決定する Pod ラベルの説明です。ラベルのキーおよび値を指定します。
5
演算子は、既存 Pod のラベルと新規 Pod の仕様の matchExpression パラメーターの値のセットの間の関係を表します。これには In、NotIn、Exists、または DoesNotExist のいずれかを使用できます。
注記

ノードのラベルに、Pod のノードのアフィニティールールを満たさなくなるような結果になる変更がランタイム時に生じる場合も、Pod はノードで引き続き実行されます。

3.3.2. Pod アフィニティールールの設定
リンクのコピー

以下の手順は、ラベルの付いた 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
    Copy to Clipboard Toggle word wrap

  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
      Copy to Clipboard Toggle word wrap
    3. operator を指定します。演算子は In、NotIn、Exists、または DoesNotExist にすることができます。たとえば、演算子 In を使用してラベルをノードで必要になるようにします。
    4. topologyKey を指定します。これは、システムがトポロジードメインを表すために使用する事前にデータが設定された Kubernetes ラベル です。

  3. Pod を作成します。 

    $ oc create -f <pod-spec>.yaml
    Copy to Clipboard Toggle word wrap

3.3.3. Pod 非アフィニティールールの設定
リンクのコピー

以下の手順は、ラベルの付いた 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
    Copy to Clipboard Toggle word wrap
  2. 他の Pod の作成時に、Pod 仕様を編集して以下のパラメーターを設定します。

  3. podAntiAffinity スタンザを使用して、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
      Copy to Clipboard Toggle word wrap
    3. preferred (優先) ルールの場合、重みを 1-100 で指定します。
    4. operator を指定します。演算子は In、NotIn、Exists、または DoesNotExist にすることができます。たとえば、演算子 In を使用してラベルをノードで必要になるようにします。
  4. topologyKey を指定します。これは、システムがトポロジードメインを表すために使用する事前にデータが設定された Kubernetes ラベル です。

  5. Pod を作成します。 

    $ oc create -f <pod-spec>.yaml
    Copy to Clipboard Toggle word wrap

3.3.4. Pod のアフィニティールールと非アフィニティールールの例
リンクのコピー

以下の例は、Pod のアフィニティーおよび非アフィニティーについて示しています。

3.3.4.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
    Copy to Clipboard Toggle word wrap

  • 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
    Copy to Clipboard Toggle word wrap
  • team4a Pod は team4 Pod と同じノードにスケジュールされます。
3.3.4.2. 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
    Copy to Clipboard Toggle word wrap

  • 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
    Copy to Clipboard Toggle word wrap
  • Pod pod-s2 は pod-s1 と同じノードにスケジュールできません。
3.3.4.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
    Copy to Clipboard Toggle word wrap

  • 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
    Copy to Clipboard Toggle word wrap

  • Pod pod-s2 は、security:s2 ラベルの付いた Pod を持つノードがない場合はスケジュールされません。そのラベルの付いた他の Pod がない場合、新規 Pod は保留状態のままになります。

    出力例

    NAME      READY     STATUS    RESTARTS   AGE       IP        NODE
pod-s2    0/1       Pending   0          32s       <none>
    Copy to Clipboard Toggle word wrap

3.4. ノードのアフィニティールールを使用したノード上での Pod 配置の制御
リンクのコピー

アフィニティーとは、スケジュールするノードを制御する Pod の特性です。

OpenShift Container Platformnode では、アフィニティーとはスケジューラーが Pod を配置する場所を決定するために使用する一連のルールのことです。このルールは、ノードのカスタムラベルと Pod で指定されたラベルセレクターを使って定義されます。

3.4.1. ノードのアフィニティーについて
リンクのコピー

ノードのアフィニティーにより、Pod がその配置に使用できるノードのグループに対してアフィニティーを指定できます。ノード自体は配置に対して制御を行いません。

たとえば、Pod を特定の CPU を搭載したノードまたは特定のアベイラビリティーゾーンにあるノードでのみ実行されるよう設定することができます。

ノードのアフィニティールールには、required (必須) および preferred (優先) の 2 つのタイプがあります。

Pod をノードにスケジュールする前に、required (必須) ルールを 満たしている必要があります。preferred (優先) ルールは、ルールを満たす場合に、スケジューラーはルールの実施を試行しますが、その実施が必ずしも保証される訳ではありません。

注記

ランタイム時にノードのラベルに変更が生じ、その変更により Pod でのノードのアフィニティールールを満たさなくなる状態が生じるでも、Pod はノードで引き続き実行されます。

ノードのアフィニティーは 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
Copy to Clipboard Toggle word wrap

1
ノードのアフィニティーを設定するためのスタンザです。
2
required (必須) ルールを定義します。
3 5 6
ルールを適用するために一致している必要のあるキー/値のペア (ラベル) です。
4
演算子は、ノードのラベルと Pod 仕様の matchExpression パラメーターの値のセットの間の関係を表します。この値は、In、NotIn、Exists、または DoesNotExist、Lt、または 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
Copy to Clipboard Toggle word wrap

1
ノードのアフィニティーを設定するためのスタンザです。
2
preferred (優先) ルールを定義します。
3
preferred (優先) ルールの重みを指定します。最も高い重みを持つノードが優先されます。
4 6 7
ルールを適用するために一致している必要のあるキー/値のペア (ラベル) です。
5
演算子は、ノードのラベルと Pod 仕様の matchExpression パラメーターの値のセットの間の関係を表します。この値は、In、NotIn、Exists、または DoesNotExist、Lt、または Gt にすることができます。

ノードの非アフィニティー についての明示的な概念はありませんが、NotIn または DoesNotExist 演算子を使用すると、動作が複製されます。

注記

同じ Pod 設定でノードのアフィニティーとノードのセレクターを使用している場合は、以下に注意してください。

  • nodeSelector と nodeAffinity の両方を設定する場合、Pod が候補ノードでスケジュールされるにはどちらの条件も満たしている必要があります。
  • nodeAffinity タイプに関連付けられた複数の nodeSelectorTerms を指定する場合、nodeSelectorTerms のいずれかが満たされている場合に Pod をノードにスケジュールすることができます。
  • nodeSelectorTerms に関連付けられた複数の matchExpressions を指定する場合、すべての matchExpressions が満たされている場合にのみ Pod をノードにスケジュールすることができます。

3.4.2. ノードアフィニティーの required (必須) ルールの設定
リンクのコピー

Pod をノードにスケジュールする前に、required (必須) ルールを 満たしている必要があります。

手順

以下の手順は、ノードとスケジューラーがノードに配置する必要のある Pod を作成する単純な設定を示しています。

  1. oc label node コマンドを使ってラベルをノードに追加します。 

    $ oc label node node1 e2e-az-name=e2e-az1
    Copy to Clipboard Toggle word wrap

  2. Pod 仕様では、nodeAffinity スタンザを使用して requiredDuringSchedulingIgnoredDuringExecution パラメーターを設定します。

    1. 満たしている必要のあるキーおよび値を指定します。新規 Pod を編集したノードにスケジュールする必要がある場合、ノードのラベルと同じ key および value パラメーターを使用します。

    2. operator を指定します。演算子は In、NotIn、Exists、DoesNotExist、Lt、または Gt にすることができます。たとえば、演算子 In を使用してラベルがノードで必要になるようにします。

      出力例

      spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: e2e-az-name
            operator: In
            values:
            - e2e-az1
            - e2e-az2
      Copy to Clipboard Toggle word wrap

  3. Pod を作成します。 

    $ oc create -f e2e-az2.yaml
    Copy to Clipboard Toggle word wrap

3.4.3. ノードアフィニティーの preferred (優先) ルールの設定
リンクのコピー

preferred (優先) ルールは、ルールを満たす場合に、スケジューラーはルールの実施を試行しますが、その実施が必ずしも保証される訳ではありません。

手順

以下の手順は、ノードとスケジューラーがノードに配置しようとする Pod を作成する単純な設定を示しています。

  1. oc label node コマンドを使ってラベルをノードに追加します。 

    $ oc label node node1 e2e-az-name=e2e-az3
    Copy to Clipboard Toggle word wrap

  2. Pod 仕様では、 nodeAffinity スタンザを使用して preferredDuringSchedulingIgnoredDuringExecution パラメーターを設定します。

    1. ノードの重みを数字の 1-100 で指定します。最も高い重みを持つノードが優先されます。

    2. 満たしている必要のあるキーおよび値を指定します。新規 Pod を編集したノードにスケジュールする必要がある場合、ノードのラベルと同じ key および value パラメーターを使用します。 

      spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: e2e-az-name
            operator: In
            values:
            - e2e-az3
      Copy to Clipboard Toggle word wrap
    3. operator を指定します。演算子は In、NotIn、Exists、DoesNotExist、Lt、または Gt にすることができます。たとえば、演算子 In を使用してラベルがノードで必要になるようにします。

  3. Pod を作成します。 

    $ oc create -f e2e-az3.yaml
    Copy to Clipboard Toggle word wrap

3.4.4. ノードのアフィニティールールの例
リンクのコピー

以下の例は、ノードのアフィニティーを示しています。

3.4.4.1. 一致するラベルを持つノードのアフィニティー
リンクのコピー

以下の例は、一致するラベルを持つノードと Pod のノードのアフィニティーを示しています。

  • Node1 ノードにはラベル zone:us があります。 

    $ oc label node node1 zone=us
    Copy to Clipboard Toggle word wrap

  • pod-s1 pod にはノードアフィニティーの required (必須) ルールの下に zone と us のキー/値のペアがあります。 

    $ cat pod-s1.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    apiVersion: v1
kind: Pod
metadata:
  name: pod-s1
spec:
  containers:
    - image: "docker.io/ocpqe/hello-pod"
      name: hello-pod