マシン管理

Azure Red Hat OpenShift 4

クラスターマシンの追加および保守

Red Hat OpenShift Documentation Team

概要

本書では、Azure Red Hat OpenShift 4 クラスターを構成するマシンを管理する方法を説明します。一部のタスクでは、Azure Red Hat OpenShift 4 クラスターの強化された自動マシン管理機能を利用でき、一部のタスクを手動で行うこともできます。本書で説明するすべてのタスクが必ずしもすべてのインストールタイプで利用可能である訳ではありません。

第1章 MachineSet の手動によるスケーリング

MachineSet のマシンのインスタンスを追加または削除できます。

注記

スケーリング以外の MachineSet の要素を変更する必要がある場合は、「MachineSet の変更」を参照してください。

前提条件

重要

このプロセスは、マシンを独自に手動でプロビジョニングしているクラスターには適用されません。高度なマシン管理およびスケーリング機能は、マシン API が機能しているクラスターでのみ使用することができます。

1.1. MachineSet の手動によるスケーリング

MachineSet のマシンのインスタンスを追加したり、削除したりする必要がある場合、MachineSet を手動でスケーリングできます。

前提条件

  • Azure Red Hat OpenShift クラスターと oc コマンドラインをインストールします。
  • cluster-admin パーミッションを持つユーザーとして、oc にログインします。

手順

  1. クラスターにある MachineSet を表示します。

    $ oc get machinesets -n openshift-machine-api

    MachineSet は <clusterid>-worker-<aws-region-az> の形式で一覧表示されます。

  2. MachineSet をスケーリングします。

    $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api

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

    $ oc edit machineset <machineset> -n openshift-machine-api

    MachineSet をスケールアップまたはスケールダウンできます。新規マシンが利用可能になるまで数分の時間がかかります。

1.2. MachineSet の削除ポリシー

RandomNewest、および Oldest は 3 つのサポートされるオプションです。デフォルトは Random であり、これは MachineSet のスケールダウン時にランダムマシンが選択され、削除されることを意味します。削除ポリシーは、特定の MachineSet を変更し、ユースケースに基づいて設定できます。

spec:
  deletePolicy: <delete policy>
  replicas: <desired replica count>

特定のマシンの優先順位は、削除ポリシーにかかわらず、アノテーション machine.openshift.io/cluster-api-delete-machine を関係するマシンに追加して設定できます。

重要

デフォルトで、Azure Red Hat OpenShift ルーター Pod はワーカーにデプロイされます。ルーターは Web コンソールなどの一部のクラスターリソースにアクセスすることが必要であるため、 ルーター Pod をまず再配置しない限り、ワーカー MachineSet を 0 にスケーリングできません。

注記

カスタム MachineSet は、サービスを特定のノードサービスで実行し、それらのサービスがワーカー MachineSet のスケールダウン時にコントローラーによって無視されるようにする必要があるユースケースで使用できます。これにより、サービスの中断が回避されます。

第2章 MachineSet の変更

ラベルの追加、インスタンスタイプの変更、ブロックストレージの変更など、MachineSet に変更を加えることができます。

注記

他の変更なしに MachineSet をスケーリングする必要がある場合は、「 MachineSet の手動によるスケーリング」を参照してください。

2.1. MachineSet の変更

MachineSet を変更するには、MachineSet YAML を編集します。次に、各マシンを削除するか、または MachineSet を 0 レプリカにスケールダウンして MachineSet に関連付けられたすべてのマシンを削除します。レプリカは必要な数にスケーリングします。MachineSet への変更は既存のマシンに影響を与えません。

他の変更を加えずに MachineSet をスケーリングする必要がある場合、マシンを削除する必要はありません。

注記

デフォルトで、Azure Red Hat OpenShift ルーター Pod はワーカーにデプロイされます。ルーターは Web コンソールなどの一部のクラスターリソースにアクセスすることが必要であるため、 ルーター Pod をまず再配置しない限り、ワーカー MachineSet を 0 にスケーリングできません。

前提条件

  • Azure Red Hat OpenShift クラスターと oc コマンドラインをインストールします。
  • cluster-admin パーミッションを持つユーザーとして、oc にログインします。

手順

  1. MachineSet を編集します。

    $ oc edit machineset <machineset> -n openshift-machine-api
  2. MachineSet を 0にスケールダウンします。

    $ oc scale --replicas=0 machineset <machineset> -n openshift-machine-api

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

    $ oc edit machineset <machineset> -n openshift-machine-api

    マシンが削除されるまで待機します。

  3. MachineSet を随時スケールアップします。

    $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api

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

    $ oc edit machineset <machineset> -n openshift-machine-api

    マシンが起動するまで待ちます。新規マシンには MachineSet に加えられた変更が含まれます。

第3章 マシンの削除

特定のマシンを削除できます。

3.1. 特定マシンの削除

特定のマシンを削除できます。

前提条件

  • Azure Red Hat OpenShift クラスターをインストールします。
  • oc として知られる OpenShift コマンドラインインターフェース (CLI) をインストールします。
  • cluster-admin パーミッションを持つユーザーとして、oc にログインします。

手順

  1. クラスターにあるマシンを表示し、削除するマシンを特定します。

    $ oc get machine -n openshift-machine-api

    コマンド出力には、<clusterid>-worker-<cloud_region> 形式のマシンの一覧が含まれます。

  2. マシンを削除します。

    $ oc delete machine <machine> -n openshift-machine-api
    重要

    デフォルトでは、マシンコントローラーは、成功するまでマシンによってサポートされるノードをドレイン (解放) しようとします。Pod の Disruption Budget(停止状態の予算)が正しく設定されていない場合などには、ドレイン (解放) の操作を実行してもマシンの削除を防ぐことができない場合があります。特定のマシンの "machine.openshift.io/exclude-node-draining" にアノテーションを付けると、ノードのドレイン(解放)を省略できます。削除中のマシンが MachineSet に属する場合、指定されたレプリカ数に対応するために新規マシンが即時に作成されます。

第4章 Azure Red Hat OpenShift クラスターへの自動スケーリングの適用

自動スケーリングの Azure Red Hat OpenShift クラスターへの適用には、クラスターへの ClusterAutoscaler のデプロイと各マシンタイプの MachineAutoscaler のデプロイが必要です。

重要

ClusterAutoscaler は、マシン API が機能しているクラスターでのみ設定できます。

4.1. ClusterAutoscaler について

ClusterAutoscaler は、現行のデプロイメントのニーズに合わせて Azure Red Hat OpenShift クラスターのサイズを調整します。これは、Kubernetes 形式の宣言引数を使用して、特定のクラウドプロバイダーのオブジェクトに依存しないインフラストラクチャー管理を提供します。ClusterAutoscaler には cluster スコープがあり、特定の namespace には関連付けられていません。

ClusterAutoscaler は、リソース不足のために現在のノードのいずれにもスケジュールできない Pod がある場合や、デプロイメントのニーズを満たすために別のノードが必要な場合に、クラスターのサイズを拡大します。ClusterAutoscaler は、指定される制限を超えてクラスターリソースを拡大することはありません。

重要

作成する ClusterAutoscaler 定義の maxNodesTotal 値が、クラスター内のマシンの想定される合計数に対応するのに十分な大きさの値であることを確認します。この値は、コントロールプレーンマシンの数とスケーリングする可能性のあるコンピュートマシンの数に対応できる値である必要があります。

ClusterAutoscaler は、リソースの使用量が少なく、重要な Pod すべてが他のノードに適合する場合など、一部のノードが長い期間にわたって不要な状態が続く場合にクラスターのサイズを縮小します。

以下のタイプの Pod がノードにある場合、 ClusterAutoscaler はそのノードを削除しません。

  • 制限のある PodDisruptionBudget (PDB) を持つ Pod。
  • デフォルトでノードで実行されない Kube システム Pod。
  • PDBB を持たないか、または制限が厳しい PDB を持つ Kuber システム Pod。
  • Deployment、ReplicaSet、または StatefulSet などのコントローラーオブジェクトによってサポートされない Pod。
  • ローカルストレージを持つ Pod。
  • リソース不足、互換性のないノードセレクターまたはアフィニティー、一致する非アフィニティーなどにより他の場所に移動できない Pod。
  • それらに "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" アノテーションがない場合、"cluster-autoscaler.kubernetes.io/safe-to-evict": "false" アノテーションを持つ Pod。

ClusterAutoscaler を設定する場合、使用に関する追加の制限が適用されます。

  • 自動スケーリングされたノードグループにあるノードを直接変更しない。同じノードグループ内のすべてのノードには同じ容量およびラベルがあり、同じシステム Pod を実行します。
  • Pod の要求を指定します。
  • Pod がすぐに削除されるのを防ぐ必要がある場合、適切な PDB を設定します。
  • クラウドプロバイダーのクォータが、設定する最大のノードプールに対応できる十分な大きさであることを確認します。
  • クラウドプロバイダーで提供されるものなどの、追加のノードグループ Autoscaler を実行しない。

Horizontal Pod Autoscaler (HPA) および ClusterAutoscaler は複数の異なる方法でクラスターリソースを変更します。HPA は、現在の CPU 負荷に基づいてデプロイメント、または ReplicaSet のレプリカ数を変更します。負荷が増大すると、HPA はクラスターで利用できるリソース量に関係なく、新規レプリカを作成します。十分なリソースがない場合、ClusterAutoscaler はリソースを追加し、HPA で作成された Pod が実行できるようにします。負荷が減少する場合、HPA は一部のレプリカを停止します。この動作によって一部のノードの使用率が低くなるか、または完全に空になる場合、ClusterAutoscaler は不必要なノードを削除します。

ClusterAutoscaler は Pod の優先順位を考慮に入れます。Pod の優先順位とプリエンプション機能により、クラスターに十分なリソースがない場合に優先順位に基づいて Pod のスケジューリングを有効にできますが、ClusterAutoscaler はクラスターがすべての Pod を実行するのに必要なリソースを確保できます。これら両方の機能の意図を反映するべく、ClusterAutoscaler には優先順位のカットオフ機能が含まれています。このカットオフを使用して Best Effort の Pod をスケジュールできますが、これにより ClusterAutoscaler がリソースを増やすことはなく、余分なリソースがある場合にのみ実行されます。

カットオフ値よりも低い優先順位を持つ Pod は、クラスターをスケールアップせず、クラスターのスケールダウンを防ぐこともありません。これらの Pod を実行するために新規ノードは追加されず、これらの Pod を実行しているノードはリソースを解放するために削除される可能性があります。

4.2. MachineAutoscaler について

MachineAutoscaler は、MachineSet で Azure Red Hat OpenShift クラスターにデプロイするマシン数を調整します。デフォルトの worker MachineSet および作成する他の MachineSet の両方をスケーリングできます。MachineAutoscaler は、追加のデプロイメントをサポートするのに十分なリソースがクラスターにない場合に追加のマシンを作成します。MachineAutoscaler リソースの値への変更 (例: インスタンスの最小または最大数) は、それらがターゲットとする MachineSet に即時に適用されます。

重要

マシンをスケーリングするには、ClusterAutoscaler の MachineAutoscaler をデプロイする必要があります。ClusterAutoscaler は、スケーリングできるリソースを判別するために、MachineAutoscaler が設定するアノテーションを MachineSet で使用します。MachineAutoscaler を定義せずに ClusterAutoscaler を定義する場合、ClusterAutoscaler はクラスターをスケーリングできません。

4.3. ClusterAutoscaler の設定

まず ClusterAutoscaler をデプロイし、リソースの自動スケーリングを Azure Red Hat OpenShift クラスターで管理します。

注記

ClusterAutoscaler のスコープはクラスター全体に設定されるため、クラスター用に 1 つの ClusterAutoscaler のみを作成できます。

4.3.1. ClusterAutoscaler リソース定義

この ClusterAutoscaler リソース定義は、 ClusterAutoscaler のパラメーターおよびサンプル値を表示します。

apiVersion: "autoscaling.openshift.io/v1"
kind: "ClusterAutoscaler"
metadata:
  name: "default"
spec:
  podPriorityThreshold: -10 1
  resourceLimits:
    maxNodesTotal: 24 2
    cores:
      min: 8 3
      max: 128 4
    memory:
      min: 4 5
      max: 256 6
    gpus:
      - type: nvidia.com/gpu 7
        min: 0 8
        max: 16 9
      - type: amd.com/gpu 10
        min: 0 11
        max: 4 12
  scaleDown: 13
    enabled: true 14
    delayAfterAdd: 10m 15
    delayAfterDelete: 5m 16
    delayAfterFailure: 30s 17
    unneededTime: 60s 18
1
ClusterAutoscaler に追加のノードをデプロイさせるために Pod が超えている必要のある優先順位を指定します。32 ビットの整数値を入力します。podPriorityThreshold 値は、各 Pod に割り当てる PriorityClass の値と比較されます。
2
デプロイするノードの最大数を指定します。この値は、Autoscaler が制御するマシンだけでなく、クラスターにデプロイされるマシンの合計数です。この値は、すべてのコントロールプレーンおよびコンピュートマシン、および MachineAutoscaler リソースに指定するレプリカの合計数に対応するのに十分な大きさの値であることを確認します。
3
デプロイするコアの最小数を指定します。
4
デプロイするコアの最大数を指定します。
5
ノードごとにメモリーの最小量 (GiB 単位) を指定します。
6
ノードごとにメモリーの最大量 (GiB 単位) を指定します。
7 10
オプションで、デプロイする GPU ノードのタイプを指定します。nvidia.com/gpu および amd.com/gpu のみが有効なタイプです。
8 11
デプロイする GPU の最小数を指定します。
9 12
デプロイする GPU の最大数を指定します。
13
このセクションでは、有効な ParseDuration 期間( nsusmssm、および hを含む)を使用して各アクションについて待機する期間を指定できます。
14
ClusterAutoscaler が不必要なノードを削除できるかどうかを指定します。
15
オプションで、ノードが最後に 追加 されてからノードを削除するまで待機する期間を指定します。値を指定しない場合、デフォルト値の 10m が使用されます。
16
ノードが最後に 削除 されたからノードを削除するまで待機する期間を指定します。値を指定しない場合、デフォルト値の 10s が使用されます。
17
スケールダウンが失敗してからノードを削除するまで待機する期間を指定します。値を指定しない場合、デフォルト値の 3m が使用されます。
18
不要なノードが削除の対象となるまでの期間を指定します。値を指定しない場合、デフォルト値の 10m が使用されます。

4.3.2. ClusterAutoscaler のデプロイ

ClusterAutoscaler をデプロイするには、 ClusterAutoscaler リソースのインスタンスを作成します。

手順

  1. カスタマイズされたリソース定義を含む ClusterAutoscaler リソースの YAML ファイルを作成します。
  2. クラスターにリソースを作成します。

    $ oc create -f <filename>.yaml 1
    1
    <filename> は、カスタマイズしたリソースファイルの名前です。

次のステップ

  • ClusterAutoscaler の設定後に、1 つ以上の MachineAutoscaler を設定する必要があります。

4.4. MachineAutoscaler の設定

ClusterAutoscaler の設定後に、クラスターのスケーリングに使用される MachineSet を参照する MachineAutoscaler リソースをデプロイします。

重要

ClusterAutoscaler リソースの設定後に、1 つ以上の MachineAutoscaler リソースをデプロイする必要があります。

注記

各 MachineSet に対して別々のリソースを設定する必要があります。MachineSet はそれぞれのリージョンごとに異なるため、複数のリージョンでマシンのスケーリングを有効にする必要があるかどうかを考慮してください。スケーリングする MachineSet には 1 つ以上のマシンが必要です。

4.4.1. MachineAutoscaler リソース定義

この MachineAutoscaler リソース定義は、 MachineAutoscaler のパラメーターおよびサンプル値を表示します。

apiVersion: "autoscaling.openshift.io/v1beta1"
kind: "MachineAutoscaler"
metadata:
  name: "worker-us-east-1a" 1
  namespace: "openshift-machine-api"
spec:
  minReplicas: 1 2
  maxReplicas: 12 3
  scaleTargetRef: 4
    apiVersion: machine.openshift.io/v1beta1
    kind: MachineSet 5
    name: worker-us-east-1a 6
1
MachineAutoscaler の名前を指定します。この MachineAutoscaler がスケーリングする MachineSet を簡単に特定できるようにするには、スケーリングする MachineSet の名前を指定するか、またはこれを組み込みます。MachineSet の名前は以下の形式を取ります。 <clusterid>-<machineset>-<aws-region-az>
2
ClusterAutoscaler がクラスターのスケーリングを開始した後に、指定された AWS ゾーンに残っている必要のある指定されたタイプのマシンの最小数を指定します。この値は、0 に設定しないでください。
3
ClusterAutoscaler がクラスタースケーリングの開始後に指定された AWS ゾーンにデプロイできる指定されたタイプの最大数マシンを指定します。ClusterAutoscaler 定義の maxNodesTotal 値が、MachineAutoScaler がこの数のマシンをデプロイするのに十分な大きさの値であることを確認します。
4
このセクションでは、スケーリングする既存の MachineSet を記述する値を指定します。
5
kind パラメーターの値は常に MachineSet です。
6
name の値は、 metadata.name パラメーター値に示されるように既存の MachineSet の名前に一致する必要があります。

4.4.2. MachineAutoscaler のデプロイ

MachineAutoscaler をデプロイするには、 MachineAutoscaler リソースのインスタンスを作成します。

手順

  1. カスタマイズされたリソース定義を含む MachineAutoscaler リソースの YAML ファイルを作成します。
  2. クラスターにリソースを作成します。

    $ oc create -f <filename>.yaml 1
    1
    <filename> は、カスタマイズしたリソースファイルの名前です。

4.5. 追加リソース

第5章 インフラストラクチャー MachineSet の作成

インフラストラクチャーコンポーネントのみをホストするように MachineSet を作成することができます。特定の Kubernetes ラベルをこれらのマシンに適用してから、インフラストラクチャーコンポーネントをそれらのマシンでのみ実行されるように更新します。これらのインフラストラクチャーノードは、環境の実行に必要なサブスクリプションの合計数にカウントされません。

重要

以前のバージョンの Azure Red Hat OpenShift とは異なり、インフラストラクチャーコンポーネントをマスターマシンに移動することはできません。コンポーネントを移動するには、新規 MachineSet を作成する必要があります。

5.1. Azure Red Hat OpenShift インフラストラクチャーコンポーネント

以下の Azure Red Hat OpenShift コンポーネントはインフラストラクチャーコンポーネントです。

  • マスターで実行される Kubernetes および Azure Red Hat OpenShift コントロールプレーンサービス
  • デフォルトルーター
  • コンテナーイメージレジストリー
  • クラスターメトリクスの収集、またはモニタリングサービス
  • クラスター集計ロギング
  • サービスブローカー

他のコンテナー、Pod またはコンポーネントを実行するノードは、サブスクリプションが適用される必要のあるワーカーノードです。

5.2. 実稼働環境用のインフラストラクチャー MachineSet の作成

実稼働デプロイメントでは、インフラストラクチャーコンポーネントを保持するために 3 つ以上の MachineSet をデプロイします。ロギング集約ソリューションおよびサービスメッシュはどちらも Elasticsearch をデプロインし、Elasticsearch では複数の異なるノードにインストールされる 3 つのインスタンスが必要です。高可用性を確保するには、これらのノードを複数の異なるアベイラビリティーゾーンにインストールし、デプロイします。各アベイラビリティーゾーンにそれぞれ異なる MachineSet が必要であるため、3 つ以上の MachineSet を作成します。

5.2.1. 異なるクラウドの MachineSet の作成

クラウドのサンプル MachineSet を使用します。

5.2.1.1. AWS 上の MachineSet カスタムリソースのサンプル YAML

このサンプル YAML は us-east-1a Amazon Web Services (AWS) ゾーンで実行され、node-role.kubernetes.io/<role>:""というラベルが付けられたノードを作成する MachineSet を定義します。

このサンプルでは、<infrastructureID> はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<role> は追加するノードラベルです。

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructureID> 1
  name: <infrastructureID>-<role>-<zone> 2
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructureID> 3
      machine.openshift.io/cluster-api-machineset: <infrastructureID>-<role>-<zone> 4
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructureID> 5
        machine.openshift.io/cluster-api-machine-role: <role> 6
        machine.openshift.io/cluster-api-machine-type: <role> 7
        machine.openshift.io/cluster-api-machineset: <infrastructureID>-<role>-<zone> 8
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/<role>: "" 9
      providerSpec:
        value:
          ami:
            id: ami-046fe691f52a953f9 10
          apiVersion: awsproviderconfig.openshift.io/v1beta1
          blockDevices:
            - ebs:
                iops: 0
                volumeSize: 120
                volumeType: gp2
          credentialsSecret:
            name: aws-cloud-credentials
          deviceIndex: 0
          iamInstanceProfile:
            id: <infrastructureID>-worker-profile 11
          instanceType: m4.large
          kind: AWSMachineProviderConfig
          placement:
            availabilityZone: us-east-1a
            region: us-east-1
          securityGroups:
            - filters:
                - name: tag:Name
                  values:
                    - <infrastructureID>-worker-sg 12
          subnet:
            filters:
              - name: tag:Name
                values:
                  - <infrastructureID>-private-us-east-1a 13
          tags:
            - name: kubernetes.io/cluster/<infrastructureID> 14
              value: owned
          userDataSecret:
            name: worker-user-data
1 3 5 11 12 13 14
クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。OpenShift CLI と jq パッケージがインストールされている場合は、以下のコマンドを実行してインフラストラクチャー ID を取得できます。
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 4 8
インフラストラクチャー ID、ノードラベル、およびゾーンを指定します。
6 7 9
追加するノードラベルを指定します。
10
Azure Red Hat OpenShift ノードの AWS ゾーンに有効な Red Hat Enterprise Linux CoreOS (RHCOS) AMI を指定します。

5.2.1.2. Azure 上の MachineSet カスタムリソースのサンプル YAML

このサンプル YAML は、centralus リージョンの 1 Microsoft Azure ゾーンで実行され、 node-role.kubernetes.io/<role>: "" というラベルの付けられたノードを作成する MachineSet を定義します。

このサンプルでは、<infrastructureID> はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<role> は追加するノードラベルです。

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructureID> 1
    machine.openshift.io/cluster-api-machine-role: <role> 2
    machine.openshift.io/cluster-api-machine-type: <role> 3
  name: <infrastructureID>-<role>-<region> 4
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructureID> 5
      machine.openshift.io/cluster-api-machineset: <infrastructureID>-<role>-<region> 6
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructureID> 7
        machine.openshift.io/cluster-api-machine-role: <role> 8
        machine.openshift.io/cluster-api-machine-type: <role> 9
        machine.openshift.io/cluster-api-machineset: <infrastructureID>-<role>-<region> 10
    spec:
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/<role>: "" 11
      providerSpec:
        value:
          apiVersion: azureproviderconfig.openshift.io/v1beta1
          credentialsSecret:
            name: azure-cloud-credentials
            namespace: openshift-machine-api
          image:
            offer: ""
            publisher: ""
            resourceID: /resourceGroups/<infrastructureID>-rg/providers/Microsoft.Compute/images/<infrastructureID>
            sku: ""
            version: ""
          internalLoadBalancer: ""
          kind: AzureMachineProviderSpec
          location: centralus
          managedIdentity: <infrastructureID>-identity 12
          metadata:
            creationTimestamp: null
          natRule: null
          networkResourceGroup: ""
          osDisk:
            diskSizeGB: 128
            managedDisk:
              storageAccountType: Premium_LRS
            osType: Linux
          publicIP: false
          publicLoadBalancer: ""
          resourceGroup: <infrastructureID>-rg 13
          sshPrivateKey: ""
          sshPublicKey: ""
          subnet: <infrastructureID>-<role>-subnet 14 15
          userDataSecret:
            name: <role>-user-data 16
          vmSize: Standard_D2s_v3
          vnet: <infrastructureID>-vnet 17
          zone: "1" 18
1 5 7 12 13 14 17
クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。OpenShift CLI と jq パッケージがインストールされている場合は、以下のコマンドを実行してインフラストラクチャー ID を取得できます。
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 3 8 9 11 15 16
追加するノードラベルを指定します。
4 6 10
インフラストラクチャー ID、ノードラベル、およびリージョンを指定します。
18
マシンを配置するリージョン内のゾーンを指定します。リージョンがゾーンをサポートすることを確認してください。

5.2.1.3. GCP 上の MachineSet カスタムリソースのサンプル YAML

このサンプル YAML は、Google Cloud Platform (GCP) で実行され、node-role.kubernetes.io/<role>: "" というラベルが付けられたノードを作成する MachineSet を定義します。

このサンプルでは、<infrastructureID> はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<role> は追加するノードラベルです。

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructureID> 1
  name: <infrastructureID>-w-a 2
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructureID> 3
      machine.openshift.io/cluster-api-machineset: <infrastructureID>-w-a 4
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructureID> 5
        machine.openshift.io/cluster-api-machine-role: <role> 6
        machine.openshift.io/cluster-api-machine-type: <role> 7
        machine.openshift.io/cluster-api-machineset: <infrastructureID>-w-a 8
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/<role>: "" 9
      providerSpec:
        value:
          apiVersion: gcpprovider.openshift.io/v1beta1
          canIPForward: false
          credentialsSecret:
            name: gcp-cloud-credentials
          deletionProtection: false
          disks:
          - autoDelete: true
            boot: true
            image: <infrastructureID>-rhcos-image 10
            labels: null
            sizeGb: 128
            type: pd-ssd
          kind: GCPMachineProviderSpec
          machineType: n1-standard-4
          metadata:
            creationTimestamp: null
          networkInterfaces:
          - network: <infrastructureID>-network 11
            subnetwork: <infrastructureID>-<role>-subnet 12
          projectID: <project_name> 13
          region: us-central1
          serviceAccounts:
          - email: <infrastructureID>-w@<project_name>.iam.gserviceaccount.com 14 15
            scopes:
            - https://www.googleapis.com/auth/cloud-platform
          tags:
          - <infrastructureID>-<role> 16
          userDataSecret:
            name: worker-user-data
          zone: us-central1-a
1 2 3 4 5 8 10 11 14
クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。OpenShift CLI と jq パッケージがインストールされている場合は、以下のコマンドを実行してインフラストラクチャー ID を取得できます。
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
12 16
インフラストラクチャー ID およびノードラベルを指定します。
6 7 9
追加するノードラベルを指定します。
13 15
クラスターに使用する GCP プロジェクトの名前を指定します。

5.2.2. MachineSet の作成

インストールプログラムによって作成されるものに加え、独自の MachineSet を作成して、選択する特定のワークロードに対するマシンのコンピュートリソースを動的に管理することができます。

前提条件

  • Azure Red Hat OpenShift クラスターをデプロイします。
  • oc として知られる OpenShift コマンドラインインターフェース (CLI) をインストールします。
  • cluster-admin パーミッションを持つユーザーとして、oc にログインします。

手順

  1. 説明されているように MachineSet カスタムリソースサンプルを含む新規 YAML ファイルを作成し、そのファイルに <file_name>.yaml という名前を付けます。

    <clusterID> および <role> パラメーターの値を設定していることを確認します。

    1. 特定のフィールドに設定する値が不明な場合は、クラスターから既存の MachineSet を確認できます。

      $ oc get machinesets -n openshift-machine-api
      
      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
      agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1d   0         0                             55m
      agl030519-vplxk-worker-us-east-1e   0         0                             55m
      agl030519-vplxk-worker-us-east-1f   0         0                             55m
    2. 特定の MachineSet の値を確認します。

      $ oc get machineset <machineset_name> -n \
           openshift-machine-api -o yaml
      
      ....
      
      template:
          metadata:
            labels:
              machine.openshift.io/cluster-api-cluster: agl030519-vplxk 1
              machine.openshift.io/cluster-api-machine-role: worker 2
              machine.openshift.io/cluster-api-machine-type: worker
              machine.openshift.io/cluster-api-machineset: agl030519-vplxk-worker-us-east-1a
      1
      クラスター ID。
      2
      デフォルトのノードラベル。
  2. 新規 MachineSet を作成します。

    $ oc create -f <file_name>.yaml
  3. MachineSet の一覧を表示します。

    $ oc get machineset -n openshift-machine-api
    
    
    NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
    agl030519-vplxk-infra-us-east-1a    1         1         1       1           11m
    agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
    agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
    agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
    agl030519-vplxk-worker-us-east-1d   0         0                             55m
    agl030519-vplxk-worker-us-east-1e   0         0                             55m
    agl030519-vplxk-worker-us-east-1f   0         0                             55m

    新規の MachineSet が利用可能な場合、 DESIRED および CURRENT の値は一致します。MachineSet が利用可能でない場合、数分待機してからコマンドを再度実行します。

  4. 新規の MachineSet が利用可能になった後に、マシンおよびそれが参照するノードのステータスを確認します。

    $ oc describe machine <name> -n openshift-machine-api

    例:

    $ oc describe machine agl030519-vplxk-infra-us-east-1a -n openshift-machine-api
    
    status:
      addresses:
      - address: 10.0.133.18
        type: InternalIP
      - address: ""
        type: ExternalDNS
      - address: ip-10-0-133-18.ec2.internal
        type: InternalDNS
      lastUpdated: "2019-05-03T10:38:17Z"
      nodeRef:
        kind: Node
        name: ip-10-0-133-18.ec2.internal
        uid: 71fb8d75-6d8f-11e9-9ff3-0e3f103c7cd8
      providerStatus:
        apiVersion: awsproviderconfig.openshift.io/v1beta1
        conditions:
        - lastProbeTime: "2019-05-03T10:34:31Z"
          lastTransitionTime: "2019-05-03T10:34:31Z"
          message: machine successfully created
          reason: MachineCreationSucceeded
          status: "True"
          type: MachineCreation
        instanceId: i-09ca0701454124294
        instanceState: running
        kind: AWSMachineProviderStatus
  5. 新しいノードを表示し、新規ノードが指定したラベルを持っていることを確認します。

    $ oc get node <node_name> --show-labels

    コマンド出力を確認し、node-role.kubernetes.io/<your_label>LABELS 一覧にあることを確認します。

注記

MachineSet への変更は、MachineSet が所有する既存のマシンには適用されません。たとえば、既存の MachineSet へ編集または追加されたラベルは、既存のマシンおよび MachineSet に関連付けられたノードには伝播しません。

次のステップ

他のアベイラビリティーゾーンで MachineSet が必要な場合、このプロセスを繰り返して追加の MachineSet を作成します。

5.3. リソースのインフラストラクチャー MachineSet への移行

インフラストラクチャーリソースの一部はデフォルトでクラスターにデプロイされます。それらは、作成したインフラストラクチャー MachineSet に移行できます。

5.3.1. ルーターの移動

ルーター Pod を異なる MachineSet にデプロイできます。デフォルトで、この Pod はワーカーノードに表示されます。

前提条件

  • 追加の MachineSet を Azure Red Hat OpenShift クラスターに設定します。

手順

  1. ルーター Operator の IngressController カスタムリソースを表示します。

    $ oc get ingresscontroller default -n openshift-ingress-operator -o yaml

    コマンド出力は以下のテキストのようになります。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      creationTimestamp: 2019-04-18T12:35:39Z
      finalizers:
      - ingresscontroller.operator.openshift.io/finalizer-ingresscontroller
      generation: 1
      name: default
      namespace: openshift-ingress-operator
      resourceVersion: "11341"
      selfLink: /apis/operator.openshift.io/v1/namespaces/openshift-ingress-operator/ingresscontrollers/default
      uid: 79509e05-61d6-11e9-bc55-02ce4781844a
    spec: {}
    status:
      availableReplicas: 2
      conditions:
      - lastTransitionTime: 2019-04-18T12:36:15Z
        status: "True"
        type: Available
      domain: apps.<cluster>.example.com
      endpointPublishingStrategy:
        type: LoadBalancerService
      selector: ingresscontroller.operator.openshift.io/deployment-ingresscontroller=default
  2. ingresscontroller リソースを編集し、 nodeSelectorinfra ラベルを使用するように変更します。

    $ oc edit ingresscontroller default -n openshift-ingress-operator -o yaml

    以下に示すように、infra ラベルを参照する nodeSelector スタンザを spec セクションに追加します。

      spec:
        nodePlacement:
          nodeSelector:
            matchLabels:
              node-role.kubernetes.io/infra: ""
  3. ルーター Pod が infra ノードで実行されていることを確認します。

    1. ルーター Pod の一覧を表示し、実行中の Pod のノード名をメモします。

      $ oc get pod -n openshift-ingress -o wide
      
      NAME                              READY     STATUS        RESTARTS   AGE       IP           NODE                           NOMINATED NODE   READINESS GATES
      router-default-86798b4b5d-bdlvd   1/1      Running       0          28s       10.130.2.4   ip-10-0-217-226.ec2.internal   <none>           <none>
      router-default-955d875f4-255g8    0/1      Terminating   0          19h       10.129.2.4   ip-10-0-148-172.ec2.internal   <none>           <none>

      この例では、実行中の Pod は ip-10-0-217-226.ec2.internal ノードにあります。

    2. 実行中の Pod のノードのステータスを表示します。

      $ oc get node <node_name> 1
      
      NAME                          STATUS  ROLES         AGE   VERSION
      ip-10-0-217-226.ec2.internal  Ready   infra,worker  17h   v1.16.2
      1
      Pod の一覧より取得した <node_name> を指定します。

      ロールの一覧に infra が含まれているため、Pod は正しいノードで実行されます。

5.3.2. デフォルトレジストリーの移行

レジストリー Operator を、その Pod を複数の異なるノードにデプロイするように設定します。

前提条件

  • 追加の MachineSet を Azure Red Hat OpenShift クラスターに設定します。

手順

  1. config/instance オブジェクトを表示します。

    $ oc get config/cluster -o yaml

    出力は以下のテキストのようになります。

    apiVersion: imageregistry.operator.openshift.io/v1
    kind: Config
    metadata:
      creationTimestamp: 2019-02-05T13:52:05Z
      finalizers:
      - imageregistry.operator.openshift.io/finalizer
      generation: 1
      name: cluster
      resourceVersion: "56174"
      selfLink: /apis/imageregistry.operator.openshift.io/v1/configs/cluster
      uid: 36fd3724-294d-11e9-a524-12ffeee2931b
    spec:
      httpSecret: d9a012ccd117b1e6616ceccb2c3bb66a5fed1b5e481623
      logging: 2
      managementState: Managed
      proxy: {}
      replicas: 1
      requests:
        read: {}
        write: {}
      storage:
        s3:
          bucket: image-registry-us-east-1-c92e88cad85b48ec8b312344dff03c82-392c
          region: us-east-1
    status:
    ...
  2. config/instance オブジェクトを編集します。

    $ oc edit config/cluster
  3. テキストの以下の行を、オブジェクトの spec セクションに追加します。

      nodeSelector:
        node-role.kubernetes.io/infra: ""
  4. レジストリー Pod がインフラストラクチャーノードに移動していることを確認します。

    1. 以下のコマンドを実行して、レジストリー Pod が置かれているノードを特定します。

      $ oc get pods -o wide -n openshift-image-registry
    2. ノードに指定したラベルがあることを確認します。

      $ oc describe node <node_name>

      コマンド出力を確認し、node-role.kubernetes.io/infraLABELS 一覧にあることを確認します。

5.3.3. モニタリングソリューションの移動

デフォルトでは、Prometheus、Grafana、および AlertManager が含まれる Prometheus Cluster Monitoring スタックはクラスターモニタリングをデプロイするためにデプロイされます。これは Cluster Monitoring Operator によって管理されます。このコンポーネント異なるマシンに移行するには、カスタム ConfigMap を作成し、これを適用します。

手順

  1. 以下の ConfigMap 定義を cluster-monitoring-configmap.yaml ファイルとして保存します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |+
        alertmanagerMain:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
        prometheusK8s:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
        prometheusOperator:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
        grafana:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
        k8sPrometheusAdapter:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
        kubeStateMetrics:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
        telemeterClient:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
        openshiftStateMetrics:
          nodeSelector:
            node-role.kubernetes.io/infra: ""

    この ConfigMap を実行すると、モニタリングスタックのコンポーネントがインフラストラクチャーノードに再デプロイされます。

  2. 新規の ConfigMap を適用します。

    $ oc create -f cluster-monitoring-configmap.yaml
  3. モニタリング Pod が新規マシンに移行することを確認します。

    $ watch 'oc get pod -n openshift-monitoring -o wide'
  4. コンポーネントが infra ノードに移動していない場合は、このコンポーネントを持つ Pod を削除します。

    $ oc delete pod -n openshift-monitoring <pod>

    削除された Pod からのコンポーネントが infra ノードに再作成されます。

追加リソース

5.3.4. クラスターロギングリソースの移動

すべてのクラスターロギングコンポーネント、Elasticsearch、Kibana、および Curator の Pod を異なるノードにデプロイするように Cluster Logging Operator を設定できます。Cluster Logging Operator Pod については、インストールされた場所から移動することはできません。

たとえば、Elasticsearch Pod の CPU、メモリーおよびディスクの要件が高いために、この Pod を別のノードに移動できます。

注記

MachineSet を 6 つ以上のレプリカを使用するように設定する必要があります。

前提条件

  • クラスターロギングおよび Elasticsearch がインストールされていること。これらの機能はデフォルトでインストールされません。

手順

  1. openshift-logging プロジェクトでクラスターロギングのカスタムリソースを編集します。

    $ oc edit ClusterLogging instance
    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    
    ....
    
    spec:
      collection:
        logs:
          fluentd:
            resources: null
          type: fluentd
      curation:
        curator:
          nodeSelector: 1
              node-role.kubernetes.io/infra: ''
          resources: null
          schedule: 30 3 * * *
        type: curator
      logStore:
        elasticsearch:
          nodeCount: 3
          nodeSelector: 2
              node-role.kubernetes.io/infra: ''
          redundancyPolicy: SingleRedundancy
          resources:
            limits:
              cpu: 500m
              memory: 16Gi
            requests:
              cpu: 500m
              memory: 16Gi
          storage: {}
        type: elasticsearch
      managementState: Managed
      visualization:
        kibana:
          nodeSelector: 3
              node-role.kubernetes.io/infra: '' 4
          proxy:
            resources: null
          replicas: 1
          resources: null
        type: kibana
    
    ....
1 2 3 4
適切な値が設定された nodeSelector パラメーターを、移動する必要のあるコンポーネントに追加します。表示されている形式の nodeSelector を使用することも、ノードに指定された値に基づいて <key>: <value> ペアを使用することもできます。

検証手順

コンポーネントが移動したことを確認するには、oc get pod -o wide コマンドを使用できます。

例:

  • Kibana Pod を ip-10-0-147-79.us-east-2.compute.internal ノードから移動する必要がある場合、以下を実行します。

    $ oc get pod kibana-5b8bdf44f9-ccpq9 -o wide
    NAME                      READY   STATUS    RESTARTS   AGE   IP            NODE                                        NOMINATED NODE   READINESS GATES
    kibana-5b8bdf44f9-ccpq9   2/2     Running   0          27s   10.129.2.18   ip-10-0-147-79.us-east-2.compute.internal   <none>           <none>
  • Kibana Pod を、専用インフラストラクチャーノードである ip-10-0-139-48.us-east-2.compute.internal ノードに移動する必要がある場合、以下を実行します。

    $ oc get nodes
    NAME                                         STATUS   ROLES          AGE   VERSION
    ip-10-0-133-216.us-east-2.compute.internal   Ready    master         60m   v1.16.2
    ip-10-0-139-146.us-east-2.compute.internal   Ready    master         60m   v1.16.2
    ip-10-0-139-192.us-east-2.compute.internal   Ready    worker         51m   v1.16.2
    ip-10-0-139-241.us-east-2.compute.internal   Ready    worker         51m   v1.16.2
    ip-10-0-147-79.us-east-2.compute.internal    Ready    worker         51m   v1.16.2
    ip-10-0-152-241.us-east-2.compute.internal   Ready    master         60m   v1.16.2
    ip-10-0-139-48.us-east-2.compute.internal    Ready    infra          51m   v1.16.2

    ノードには node-role.kubernetes.io/infra: '' ラベルがあることに注意してください。

    $ oc get node ip-10-0-139-48.us-east-2.compute.internal -o yaml
    
    kind: Node
    apiVersion: v1
    metadata:
      name: ip-10-0-139-48.us-east-2.compute.internal
      selfLink: /api/v1/nodes/ip-10-0-139-48.us-east-2.compute.internal
      uid: 62038aa9-661f-41d7-ba93-b5f1b6ef8751
      resourceVersion: '39083'
      creationTimestamp: '2020-04-13T19:07:55Z'
      labels:
        node-role.kubernetes.io/infra: ''
    ....
  • Kibana Pod を移動するには、クラスターロギング CR を編集してノードセレクターを追加します。

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    
    ....
    
    spec:
    
    ....
    
      visualization:
        kibana:
          nodeSelector: 1
            node-role.kubernetes.io/infra: '' 2
          proxy:
            resources: null
          replicas: 1
          resources: null
        type: kibana
    1 2
    ノード仕様のラベルに一致するノードセレクターを追加します。
  • CR を保存した後に、現在の Kibana Pod は終了し、新規 Pod がデプロイされます。

    $ oc get pods
    NAME                                            READY   STATUS        RESTARTS   AGE
    cluster-logging-operator-84d98649c4-zb9g7       1/1     Running       0          29m
    elasticsearch-cdm-hwv01pf7-1-56588f554f-kpmlg   2/2     Running       0          28m
    elasticsearch-cdm-hwv01pf7-2-84c877d75d-75wqj   2/2     Running       0          28m
    elasticsearch-cdm-hwv01pf7-3-f5d95b87b-4nx78    2/2     Running       0          28m
    fluentd-42dzz                                   1/1     Running       0          28m
    fluentd-d74rq                                   1/1     Running       0          28m
    fluentd-m5vr9                                   1/1     Running       0          28m
    fluentd-nkxl7                                   1/1     Running       0          28m
    fluentd-pdvqb                                   1/1     Running       0          28m
    fluentd-tflh6                                   1/1     Running       0          28m
    kibana-5b8bdf44f9-ccpq9                         2/2     Terminating   0          4m11s
    kibana-7d85dcffc8-bfpfp                         2/2     Running       0          33s
  • 新規 Pod が ip-10-0-139-48.us-east-2.compute.internal ノードに置かれます。

    $ oc get pod kibana-7d85dcffc8-bfpfp -o wide
    NAME                      READY   STATUS        RESTARTS   AGE   IP            NODE                                        NOMINATED NODE   READINESS GATES
    kibana-7d85dcffc8-bfpfp   2/2     Running       0          43s   10.131.0.22   ip-10-0-139-48.us-east-2.compute.internal   <none>           <none>
  • しばらくすると、元の Kibana Pod が削除されます。

    $ oc get pods
    NAME                                            READY   STATUS    RESTARTS   AGE
    cluster-logging-operator-84d98649c4-zb9g7       1/1     Running   0          30m
    elasticsearch-cdm-hwv01pf7-1-56588f554f-kpmlg   2/2     Running   0          29m
    elasticsearch-cdm-hwv01pf7-2-84c877d75d-75wqj   2/2     Running   0          29m
    elasticsearch-cdm-hwv01pf7-3-f5d95b87b-4nx78    2/2     Running   0          29m
    fluentd-42dzz                                   1/1     Running   0          29m
    fluentd-d74rq                                   1/1     Running   0          29m
    fluentd-m5vr9                                   1/1     Running   0          29m
    fluentd-nkxl7                                   1/1     Running   0          29m
    fluentd-pdvqb                                   1/1     Running   0          29m
    fluentd-tflh6                                   1/1     Running   0          29m
    kibana-7d85dcffc8-bfpfp                         2/2     Running   0          62s

第6章 マシンヘルスチェックのデプロイ

マシンヘルスチェックを設定し、デプロイして、マシンプールにある破損したマシンを自動的に修復します。

重要

このプロセスは、マシンを独自に手動でプロビジョニングしているクラスターには適用されません。高度なマシン管理およびスケーリング機能は、マシン API が機能しているクラスターでのみ使用することができます。

6.1. MachineHealthCheck について

MachineHealthCheck は特定の MachinePool の正常ではないマシンを自動的に修復します。

マシンの正常性を監視するには、リソースを作成し、コントローラーの設定を定義します。15 分間 NotReady ステータスにすることや、 node-problem-detector に永続的な条件を表示すること、また監視する一連のマシンのラベルなど、チェックする条件を設定します。

注記

マスターロールのあるマシンに MachineHealthCheck を適用することはできません。

MachineHealthCheck リソースを観察するコントローラーは、定義したステータスをチェックします。マシンがヘルスチェックに失敗した場合、これは自動的に検出され、新規マシンがこれに代わって作成されます。マシンが削除されると、machine deleted イベントが表示されます。マシンの削除による破壊的な影響を制限するために、コントローラーは 1 度に 1 つのノードのみをドレイン (解放) し、これを削除します。マシンのターゲットプールで許可される maxUnhealthy しきい値を上回る数の正常でないマシンがある場合、手動による介入が行われるように修復が停止します。

チェックを停止するには、リソースを削除します。

6.2. サンプル MachineHealthCheck リソース

MachineHealthCheck リソースは以下の YAML ファイルのようになります。

MachineHealthCheck

apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
  name: example 1
  namespace: openshift-machine-api
spec:
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-machine-role: <role> 2
      machine.openshift.io/cluster-api-machine-type: <role> 3
      machine.openshift.io/cluster-api-machineset: <cluster_name>-<label>-<zone> 4
  unhealthyConditions:
  - type:    "Ready"
    timeout: "300s"
    status: "False"
  - type:    "Ready"
    timeout: "300s"
    status: "Unknown"
  maxUnhealthy: "40%" 5

1
デプロイする MachineHealthCheck の名前を指定します。
2 3
チェックする必要のあるマシンプールのラベルを指定します。
4
追跡する MachineSet を <cluster_name>-<label>-<zone> 形式で指定します。たとえば、 prod-node-us-east-1a とします。
5
マシンのターゲットプールで許可される正常でないマシンの量を指定します。これはパーセンテージまたは整数として設定できます。
注記

matchLabels はあくまでもサンプルであるため、特定のニーズに応じてマシングループをマッピングする必要があります。

6.3. MachineHealthCheck リソースの作成

クラスターに、master プール以外のすべての MachinePools の MachineHealthCheck リソースを作成できます。

前提条件

  • oc コマンドラインインターフェースをインストールします。

手順

  1. MachineHealthCheck の定義を含む healthcheck.yml ファイルを作成します。
  2. healthcheck.yml ファイルをクラスターに適用します。

    $ oc apply -f healthcheck.yml

法律上の通知

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.

このページには機械翻訳が使用されている場合があります (詳細はこちら)。