マシン管理

OpenShift Container Platform 4.3

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

Red Hat OpenShift Documentation Team

概要

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

第1章 MachineSet の作成

1.1. AWS での MachineSet の作成

Amazon Web Services (AWS) で OpenShift Container Platform クラスターの特定の目的を果たすように異なる MachineSet を作成することができます。たとえば、インフラストラクチャー MachineSet および関連マシンを作成して、サポートするワークロードを新しいマシンに移動できます。

1.1.1. マシン API の概要

マシン API は、アップストリームのクラスター API プロジェクトおよびカスタム OpenShift Container Platform リソースに基づく重要なリソースの組み合わせです。

OpenShift Container Platform 4.3 クラスターの場合、マシン API はクラスターインストールの終了後にすべてのノードホストのプロビジョニングの管理アクションを実行します。このシステムにより、OpenShift Container Platform 4.3 はパブリックまたはプライベートのクラウドインフラストラクチャーに加えて弾力性があり、動的なプロビジョニング方法を提供します。

以下の 2 つのリソースは重要なリソースになります。

マシン
ノードのホストを記述する基本的なユニットです。マシンには、複数の異なるクラウドプラットフォーム用に提供されるコンピュートノードのタイプを記述する providerSpec があります。たとえば、Amazon Web Services (AWS) 上のワーカーノードのマシンタイプは特定のマシンタイプおよび必要なメタデータを定義する場合があります。
MachineSet
マシンのグループです。MachineSet とマシンの関係は、ReplicaSet と Pod の関係と同様です。マシンを追加する必要がある場合や、マシンの数を縮小したりする必要がある場合、コンピューティングのニーズに応じて MachineSet の replicas フィールドを変更します。

以下のカスタムリソースは、クラスターに機能を追加します。

MachineAutoscaler
このリソースはマシンをクラウドで自動的にスケーリングします。ノードに対する最小および最大のスケーリングの境界を、指定される MachineSet に設定でき、MachineAutoscaler はノードの該当範囲を維持します。MachineAutoscaler オブジェクトは ClusterAutoscaler オブジェクトの設定後に有効になります。ClusterAutoscale および MachineAutoscaler リソースは、どちらも ClusterAutoscalerOperator によって利用可能にされます。
ClusterAutoscaler
このリソースはアップストリームの ClusterAutoscalerプロジェクトに基づいています。OpenShift Container Platform の実装では、これは MachineSet API を拡張することによってクラスター API に統合されます。コア、ノード、メモリー、および GPU などのリソースのクラスター全体でのスケーリング制限を設定できます。優先順位を設定することにより、重要度の低い Pod のために新規ノードがオンラインにならないようにクラスターで Pod の優先順位付けを実行できます。また、ScalingPolicy を設定してノードをスケールダウンせずにスケールアップできるようにすることもできます。
MachineHealthCheck

このリソースはマシンの正常でない状態を検知し、マシンを削除し、サポートされているプラットフォームでは新規マシンを作成します。

注記

バージョン 4.3 では、MachineHealthChecks はテクノロジープレビュー機能です。

OpenShift Container Platform バージョン 3.11 では、クラスターでマシンのプロビジョニングが管理されないためにマルチゾーンアーキテクチャーを容易に展開することができませんでした。しかし、OpenShift Container Platform バージョン 4.1 以降、このプロセスはより簡単になりました。それぞれの MachineSet のスコープが単一ゾーンに設定されるため、インストールプログラムはユーザーに代わって、アベイラビリティーゾーン全体に MachineSet を送信します。さらに、コンピューティングは動的に展開されるため、ゾーンに障害が発生した場合の、マシンのリバランスが必要な場合に使用するゾーンを常に確保できます。Autoscaler はクラスターの有効期間中にベストエフォートでバランシングを提供します。

1.1.2. 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
OpenShift Container Platform ノードの AWS ゾーンに有効な Red Hat Enterprise Linux CoreOS (RHCOS) AMI を指定します。

1.1.3. MachineSet の作成

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

前提条件

  • OpenShift Container Platform クラスターをデプロイします。
  • OpenShift CLI (oc) をインストールします。
  • 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 を作成します。

1.2. Azure での MachineSet の作成

Microsoft Azure 上の OpenShift Container Platform クラスターで特定の目的を果たすように異なる MachineSet を作成することができます。たとえば、インフラストラクチャー MachineSet および関連マシンを作成して、サポートするワークロードを新しいマシンに移動できます。

1.2.1. マシン API の概要

マシン API は、アップストリームのクラスター API プロジェクトおよびカスタム OpenShift Container Platform リソースに基づく重要なリソースの組み合わせです。

OpenShift Container Platform 4.3 クラスターの場合、マシン API はクラスターインストールの終了後にすべてのノードホストのプロビジョニングの管理アクションを実行します。このシステムにより、OpenShift Container Platform 4.3 はパブリックまたはプライベートのクラウドインフラストラクチャーに加えて弾力性があり、動的なプロビジョニング方法を提供します。

以下の 2 つのリソースは重要なリソースになります。

マシン
ノードのホストを記述する基本的なユニットです。マシンには、複数の異なるクラウドプラットフォーム用に提供されるコンピュートノードのタイプを記述する providerSpec があります。たとえば、Amazon Web Services (AWS) 上のワーカーノードのマシンタイプは特定のマシンタイプおよび必要なメタデータを定義する場合があります。
MachineSet
マシンのグループです。MachineSet とマシンの関係は、ReplicaSet と Pod の関係と同様です。マシンを追加する必要がある場合や、マシンの数を縮小したりする必要がある場合、コンピューティングのニーズに応じて MachineSet の replicas フィールドを変更します。

以下のカスタムリソースは、クラスターに機能を追加します。

MachineAutoscaler
このリソースはマシンをクラウドで自動的にスケーリングします。ノードに対する最小および最大のスケーリングの境界を、指定される MachineSet に設定でき、MachineAutoscaler はノードの該当範囲を維持します。MachineAutoscaler オブジェクトは ClusterAutoscaler オブジェクトの設定後に有効になります。ClusterAutoscale および MachineAutoscaler リソースは、どちらも ClusterAutoscalerOperator によって利用可能にされます。
ClusterAutoscaler
このリソースはアップストリームの ClusterAutoscalerプロジェクトに基づいています。OpenShift Container Platform の実装では、これは MachineSet API を拡張することによってクラスター API に統合されます。コア、ノード、メモリー、および GPU などのリソースのクラスター全体でのスケーリング制限を設定できます。優先順位を設定することにより、重要度の低い Pod のために新規ノードがオンラインにならないようにクラスターで Pod の優先順位付けを実行できます。また、ScalingPolicy を設定してノードをスケールダウンせずにスケールアップできるようにすることもできます。
MachineHealthCheck

このリソースはマシンの正常でない状態を検知し、マシンを削除し、サポートされているプラットフォームでは新規マシンを作成します。

注記

バージョン 4.3 では、MachineHealthChecks はテクノロジープレビュー機能です。

OpenShift Container Platform バージョン 3.11 では、クラスターでマシンのプロビジョニングが管理されないためにマルチゾーンアーキテクチャーを容易に展開することができませんでした。しかし、OpenShift Container Platform バージョン 4.1 以降、このプロセスはより簡単になりました。それぞれの MachineSet のスコープが単一ゾーンに設定されるため、インストールプログラムはユーザーに代わって、アベイラビリティーゾーン全体に MachineSet を送信します。さらに、コンピューティングは動的に展開されるため、ゾーンに障害が発生した場合の、マシンのリバランスが必要な場合に使用するゾーンを常に確保できます。Autoscaler はクラスターの有効期間中にベストエフォートでバランシングを提供します。

1.2.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
マシンを配置するリージョン内のゾーンを指定します。リージョンがゾーンをサポートすることを確認してください。

1.2.3. MachineSet の作成

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

前提条件

  • OpenShift Container Platform クラスターをデプロイします。
  • OpenShift CLI (oc) をインストールします。
  • 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 を作成します。

1.3. GCP での MachineSet の作成

異なる MachineSet を作成して、Google Cloud Platform (GCP) 上の OpenShift Container Platform クラスターで特定の目的で使用できます。たとえば、インフラストラクチャー MachineSet および関連マシンを作成して、サポートするワークロードを新しいマシンに移動できます。

1.3.1. マシン API の概要

マシン API は、アップストリームのクラスター API プロジェクトおよびカスタム OpenShift Container Platform リソースに基づく重要なリソースの組み合わせです。

OpenShift Container Platform 4.3 クラスターの場合、マシン API はクラスターインストールの終了後にすべてのノードホストのプロビジョニングの管理アクションを実行します。このシステムにより、OpenShift Container Platform 4.3 はパブリックまたはプライベートのクラウドインフラストラクチャーに加えて弾力性があり、動的なプロビジョニング方法を提供します。

以下の 2 つのリソースは重要なリソースになります。

マシン
ノードのホストを記述する基本的なユニットです。マシンには、複数の異なるクラウドプラットフォーム用に提供されるコンピュートノードのタイプを記述する providerSpec があります。たとえば、Amazon Web Services (AWS) 上のワーカーノードのマシンタイプは特定のマシンタイプおよび必要なメタデータを定義する場合があります。
MachineSet
マシンのグループです。MachineSet とマシンの関係は、ReplicaSet と Pod の関係と同様です。マシンを追加する必要がある場合や、マシンの数を縮小したりする必要がある場合、コンピューティングのニーズに応じて MachineSet の replicas フィールドを変更します。

以下のカスタムリソースは、クラスターに機能を追加します。

MachineAutoscaler
このリソースはマシンをクラウドで自動的にスケーリングします。ノードに対する最小および最大のスケーリングの境界を、指定される MachineSet に設定でき、MachineAutoscaler はノードの該当範囲を維持します。MachineAutoscaler オブジェクトは ClusterAutoscaler オブジェクトの設定後に有効になります。ClusterAutoscale および MachineAutoscaler リソースは、どちらも ClusterAutoscalerOperator によって利用可能にされます。
ClusterAutoscaler
このリソースはアップストリームの ClusterAutoscalerプロジェクトに基づいています。OpenShift Container Platform の実装では、これは MachineSet API を拡張することによってクラスター API に統合されます。コア、ノード、メモリー、および GPU などのリソースのクラスター全体でのスケーリング制限を設定できます。優先順位を設定することにより、重要度の低い Pod のために新規ノードがオンラインにならないようにクラスターで Pod の優先順位付けを実行できます。また、ScalingPolicy を設定してノードをスケールダウンせずにスケールアップできるようにすることもできます。
MachineHealthCheck

このリソースはマシンの正常でない状態を検知し、マシンを削除し、サポートされているプラットフォームでは新規マシンを作成します。

注記

バージョン 4.3 では、MachineHealthChecks はテクノロジープレビュー機能です。

OpenShift Container Platform バージョン 3.11 では、クラスターでマシンのプロビジョニングが管理されないためにマルチゾーンアーキテクチャーを容易に展開することができませんでした。しかし、OpenShift Container Platform バージョン 4.1 以降、このプロセスはより簡単になりました。それぞれの MachineSet のスコープが単一ゾーンに設定されるため、インストールプログラムはユーザーに代わって、アベイラビリティーゾーン全体に MachineSet を送信します。さらに、コンピューティングは動的に展開されるため、ゾーンに障害が発生した場合の、マシンのリバランスが必要な場合に使用するゾーンを常に確保できます。Autoscaler はクラスターの有効期間中にベストエフォートでバランシングを提供します。

1.3.2. 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 プロジェクトの名前を指定します。

1.3.3. MachineSet の作成

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

前提条件

  • OpenShift Container Platform クラスターをデプロイします。
  • OpenShift CLI (oc) をインストールします。
  • 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 を作成します。

1.4. OpenStack での MachineSet の作成

異なる MachineSet を作成して、Red Hat OpenStack Platform (RHOSP) 上の OpenShift Container Platform クラスターで特定の目的で使用できます。たとえば、インフラストラクチャー MachineSet および関連マシンを作成して、サポートするワークロードを新しいマシンに移動できます。

1.4.1. マシン API の概要

マシン API は、アップストリームのクラスター API プロジェクトおよびカスタム OpenShift Container Platform リソースに基づく重要なリソースの組み合わせです。

OpenShift Container Platform 4.3 クラスターの場合、マシン API はクラスターインストールの終了後にすべてのノードホストのプロビジョニングの管理アクションを実行します。このシステムにより、OpenShift Container Platform 4.3 はパブリックまたはプライベートのクラウドインフラストラクチャーに加えて弾力性があり、動的なプロビジョニング方法を提供します。

以下の 2 つのリソースは重要なリソースになります。

マシン
ノードのホストを記述する基本的なユニットです。マシンには、複数の異なるクラウドプラットフォーム用に提供されるコンピュートノードのタイプを記述する providerSpec があります。たとえば、Amazon Web Services (AWS) 上のワーカーノードのマシンタイプは特定のマシンタイプおよび必要なメタデータを定義する場合があります。
MachineSet
マシンのグループです。MachineSet とマシンの関係は、ReplicaSet と Pod の関係と同様です。マシンを追加する必要がある場合や、マシンの数を縮小したりする必要がある場合、コンピューティングのニーズに応じて MachineSet の replicas フィールドを変更します。

以下のカスタムリソースは、クラスターに機能を追加します。

MachineAutoscaler
このリソースはマシンをクラウドで自動的にスケーリングします。ノードに対する最小および最大のスケーリングの境界を、指定される MachineSet に設定でき、MachineAutoscaler はノードの該当範囲を維持します。MachineAutoscaler オブジェクトは ClusterAutoscaler オブジェクトの設定後に有効になります。ClusterAutoscale および MachineAutoscaler リソースは、どちらも ClusterAutoscalerOperator によって利用可能にされます。
ClusterAutoscaler
このリソースはアップストリームの ClusterAutoscalerプロジェクトに基づいています。OpenShift Container Platform の実装では、これは MachineSet API を拡張することによってクラスター API に統合されます。コア、ノード、メモリー、および GPU などのリソースのクラスター全体でのスケーリング制限を設定できます。優先順位を設定することにより、重要度の低い Pod のために新規ノードがオンラインにならないようにクラスターで Pod の優先順位付けを実行できます。また、ScalingPolicy を設定してノードをスケールダウンせずにスケールアップできるようにすることもできます。
MachineHealthCheck

このリソースはマシンの正常でない状態を検知し、マシンを削除し、サポートされているプラットフォームでは新規マシンを作成します。

注記

バージョン 4.3 では、MachineHealthChecks はテクノロジープレビュー機能です。

OpenShift Container Platform バージョン 3.11 では、クラスターでマシンのプロビジョニングが管理されないためにマルチゾーンアーキテクチャーを容易に展開することができませんでした。しかし、OpenShift Container Platform バージョン 4.1 以降、このプロセスはより簡単になりました。それぞれの MachineSet のスコープが単一ゾーンに設定されるため、インストールプログラムはユーザーに代わって、アベイラビリティーゾーン全体に MachineSet を送信します。さらに、コンピューティングは動的に展開されるため、ゾーンに障害が発生した場合の、マシンのリバランスが必要な場合に使用するゾーンを常に確保できます。Autoscaler はクラスターの有効期間中にベストエフォートでバランシングを提供します。

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

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

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

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_ID> 1
    machine.openshift.io/cluster-api-machine-role: <node_role> 2
    machine.openshift.io/cluster-api-machine-type: <node_role> 3
  name: <infrastructure_ID>-<node_role> 4
  namespace: openshift-machine-api
spec:
  replicas: <number_of_replicas>
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_ID> 5
      machine.openshift.io/cluster-api-machineset: <infrastructure_ID>-<node_role> 6
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_ID> 7
        machine.openshift.io/cluster-api-machine-role: <node_role> 8
        machine.openshift.io/cluster-api-machine-type: <node_role> 9
        machine.openshift.io/cluster-api-machineset: <infrastructure_ID>-<node_role> 10
    spec:
      providerSpec:
        value:
          apiVersion: openstackproviderconfig.openshift.io/v1alpha1
          cloudName: openstack
          cloudsSecret:
            name: openstack-cloud-credentials
            namespace: openshift-machine-api
          flavor: <nova_flavor>
          image: <glance_image_name_or_location>
          kind: OpenstackProviderSpec
          networks:
          - filter: {}
            subnets:
            - filter:
                name: <subnet_name>
                tags: openshiftClusterID=<infrastructure_ID>
          securityGroups:
          - filter: {}
            name: <infrastructure_ID>-<node_role>
          serverMetadata:
            Name: <infrastructure_ID>-<node_role>
            openshiftClusterID: <infrastructure_ID>
          tags:
          - openshiftClusterID=<infrastructure_ID>
          trunk: true
          userDataSecret:
            name: <node_role>-user-data 11
1 5 7
クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。OpenShift CLI と jq パッケージがインストールされている場合は、以下のコマンドを実行してインフラストラクチャー ID を取得できます。
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 3 8 9 11
追加するノードラベルを指定します。
4 6 10
インフラストラクチャー ID およびノードラベルを指定します。

1.4.3. MachineSet の作成

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

前提条件

  • OpenShift Container Platform クラスターをデプロイします。
  • OpenShift CLI (oc) をインストールします。
  • 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 を作成します。

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

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

注記

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

2.1. 前提条件

重要

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

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

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

前提条件

  • OpenShift Container Platform クラスターおよび 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 をスケールアップまたはスケールダウンできます。新規マシンが利用可能になるまで数分の時間がかかります。

2.3. MachineSet の削除ポリシー

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

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

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

重要

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

注記

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

第3章 MachineSet の変更

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

注記

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

3.1. MachineSet の変更

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

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

注記

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

前提条件

  • OpenShift Container Platform クラスターと 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 に加えられた変更が含まれます。

第4章 マシンの削除

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

4.1. 特定マシンの削除

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

前提条件

  • OpenShift Container Platform クラスターをインストールします。
  • OpenShift CLI (oc) をインストールします。
  • 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 に属する場合、指定されたレプリカ数に対応するために新規マシンが即時に作成されます。

第5章 OpenShift Container Platform クラスターへの自動スケーリングの適用

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

重要

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

5.1. ClusterAutoscaler について

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

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

重要

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

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

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

  • 制限のある PodDisruptionBudget (PDB) を持つ Pod。
  • デフォルトでノードで実行されない Kube システム Pod。
  • PDB を持たないか、または制限が厳しい 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 を実行しているノードはリソースを解放するために削除される可能性があります。

5.2. MachineAutoscaler について

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

重要

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

5.3. ClusterAutoscaler の設定

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

注記

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

5.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 が使用されます。

5.3.2. ClusterAutoscaler のデプロイ

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

手順

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

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

5.4. 次のステップ

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

5.5. MachineAutoscaler の設定

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

重要

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

注記

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

5.5.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 の名前に一致する必要があります。

5.5.2. MachineAutoscaler のデプロイ

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

手順

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

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

5.6. 追加リソース

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

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

重要

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

6.1. OpenShift Container Platform インフラストラクチャーコンポーネント

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

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

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

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

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

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

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

6.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
OpenShift Container Platform ノードの AWS ゾーンに有効な Red Hat Enterprise Linux CoreOS (RHCOS) AMI を指定します。

6.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
マシンを配置するリージョン内のゾーンを指定します。リージョンがゾーンをサポートすることを確認してください。

6.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 プロジェクトの名前を指定します。

6.2.2. MachineSet の作成

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

前提条件

  • OpenShift Container Platform クラスターをデプロイします。
  • OpenShift CLI (oc) をインストールします。
  • 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 を作成します。

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

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

6.3.1. ルーターの移動

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

前提条件

  • 追加の MachineSet を OpenShift Container Platform クラスターに設定します。

手順

  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 は正しいノードで実行されます。

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

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

前提条件

  • 追加の MachineSet を OpenShift Container Platform クラスターに設定します。

手順

  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 一覧にあることを確認します。

6.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 ノードに再作成されます。

追加リソース

6.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

第7章 ユーザーによってプロビジョニングされるインフラストラクチャー

7.1. RHEL コンピュートマシンの OpenShift Container Platform クラスターへの追加

OpenShift Container Platform では、Red Hat Enterprise Linux (RHEL) のコンピュートまたはワーカーマシンをユーザーによってプロビジョニングされるインフラストラクチャークラスターに追加できます。RHEL は、コンピュートマシンでのみのオペレーティングシステムとして使用できます。

7.1.1. RHEL コンピュートノードのクラスターへの追加について

OpenShift Container Platform 4.3 には、ユーザーによってプロビジョニングされるインフラストラクチャーを使用する場合、Red Hat Enterprise Linux (RHEL) マシンをクラスター内のコンピュートマシン (またはワーカーマシンとしても知られる) を使用するオプションがあります。クラスター内のコントロールプレーンまたはマスターマシンには Red Hat Enterprise Linux CoreOS (RHCOS) マシンを使用する必要があります。

ユーザーによってプロビジョニングされるインフラストラクチャーを使用するすべてのインストールの場合、クラスターで RHEL コンピュートマシンを使用する選択をする場合には、システム更新の実行や、パッチの適用、またその他の必要なすべてのタスクの実行を含むオペレーティングシステムのライフサイクル管理およびメンテナンスのすべてを独自に実行する必要があります。

重要

OpenShift Container Platform をクラスター内のマシンから削除するには、オペレーティングシステムを破棄する必要があるため、クラスターに追加する RHEL マシンについては専用のハードウェアを使用する必要があります。

重要

swap メモリーは、OpenShift Container Platform クラスターに追加されるすべての RHEL マシンで無効にされます。これらのマシンで swap メモリーを有効にすることはできません。

RHEL コンピュートマシンは、コントロールプレーンを初期化してからクラスターに追加する必要があります。

7.1.2. RHEL コンピュートノードのシステム要件

OpenShift Container Platform 環境の Red Hat Enterprise Linux (RHEL) コンピュートマシンホスト (またはワーカーマシンホストとしても知られる) は以下の最低のハードウェア仕様およびシステムレベルの要件を満たしている必要があります。

  • まず、お使いの Red Hat アカウントに有効な OpenShift Container Platform サブスクリプションがなければなりません。これがない場合は、営業担当者にお問い合わせください。
  • 実稼働環境では予想されるワークロードに対応するコンピュートーノードを提供する必要があります。クラスター管理者は、予想されるワークロードを計算し、オーバーヘッドの約 10 パーセントを追加する必要があります。実稼働環境の場合、ノードホストの障害が最大容量に影響を与えることがないよう、十分なリソースを割り当てるようにします。
  • 各システムは、以下のハードウェア要件を満たしている必要があります。

    • 物理または仮想システム、またはパブリックまたはプライベート IaaS で実行されるインスタンス。
    • ベース OS: RHEL 7.6 (「最小」のインストールオプション)

      重要

      OpenShift Container Platform 4.3 でサポートされるのは RHEL 7.6 のみになります。コンピュートマシンを RHEL 8 にアップグレードすることはできません。

    • FIPS モードで OpenShift Container Platform をデプロイしている場合、起動する前に FIPS を RHEL マシン上で有効にする必要があります。詳細は、RHEL 7 のドキュメントの「FIPS モードの有効化」を参照してください。
    • NetworkManager 1.0 以降。
    • 1 vCPU。
    • 最小 8 GB の RAM。
    • /var/ を含むファイルシステムの最小 15 GB のハードディスク領域。
    • /usr/local/bin/ を含むファイルシステムの最小 1 GB のハードディスク領域。
    • システムの一時ディレクトリーを含むファイルシステムの最小 1 GB のハードディスク領域。システムの一時ディレクトリーは、Python の標準ライブラリーの tempfile モジュールで定義されるルールに基づいて決定されます。
  • 各システムは、システムプロバイダーの追加の要件を満たす必要があります。たとえば、クラスターを VMware vSphere にインストールしている場合、ディスクはその ストレージガイドライン に応じて設定され、disk.enableUUID=true 属性が設定される必要があります。

7.1.2.1. 証明書署名要求の管理

ユーザーがプロビジョニングするインフラストラクチャーを使用する場合、クラスターの自動マシン管理へのアクセスは制限されるため、インストール後にクラスターの証明書署名要求 (CSR) のメカニズムを提供する必要があります。kube-controller-manager は kubelet クライアント CSR のみを承認します。machine-approver は、kubelet 認証情報を使用して要求される提供証明書の有効性を保証できません。適切なマシンがこの要求を発行したかどうかを確認できないためです。kubelet 提供証明書の要求の有効性を検証し、それらを承認する方法を判別し、実装する必要があります。

7.1.3. Playbook 実行のためのマシンの準備

Red Hat Enterprise Linux をオペレーティングシステムとして使用するコンピュートマシンを OpenShift Container Platform 4.3 クラスターに追加する前に、Playbook を実行するマシンを準備する必要があります。このマシンはクラスターの一部にはなりませんが、クラスターにアクセスできる必要があります。

前提条件

  • Playbook を実行するマシンに OpenShift CLI (oc) をインストールします。
  • cluster-admin パーミッションを持つユーザーとしてログインします。

手順

  1. クラスターの kubeconfig ファイルおよびクラスターのインストールに使用したインストールプログラムがマシン上にあることを確認します。これを実行する 1 つの方法として、クラスターのインストールに使用したマシンと同じマシンを使用することができます。
  2. マシンを、コンピュートマシンとして使用する予定のすべての RHEL ホストにアクセスできるように設定します。Bastion と SSH プロキシーまたは VPN の使用など、所属する会社で許可されるすべての方法を利用できます。
  3. すべての RHEL ホストへの SSH アクセスを持つユーザーを Playbook を実行するマシンで設定します。

    重要

    SSH キーベースの認証を使用する場合、キーを SSH エージェントで管理する必要があります。

  4. これを実行していない場合には、マシンを RHSM に登録し、 OpenShift サブスクリプションのプールをこれにアタッチします。

    1. マシンを RHSM に登録します。

      # subscription-manager register --username=<user_name> --password=<password>
    2. RHSM から最新のサブスクリプションデータをプルします。

      # subscription-manager refresh
    3. 利用可能なサブスクリプションを一覧表示します。

      # subscription-manager list --available --matches '*OpenShift*'
    4. 直前のコマンドの出力で、OpenShift Container Platform サブスクリプションのプール ID を見つけ、これをアタッチします。

      # subscription-manager attach --pool=<pool_id>
  5. OpenShift Container Platform 4.3 で必要なリポジトリーを有効にします。

    # subscription-manager repos \
        --enable="rhel-7-server-rpms" \
        --enable="rhel-7-server-extras-rpms" \
        --enable="rhel-7-server-ansible-2.8-rpms" \
        --enable="rhel-7-server-ose-4.3-rpms"
  6. openshift-ansible を含む必要なパッケージをインストールします。

    # yum install openshift-ansible openshift-clients jq

    openshift-ansible パッケージはインストールプログラムユーティリティーを提供し、Ansible Playbook などのクラスターに RHEL コンピュートノードを追加するために必要な他のパッケージおよび関連する設定ファイルをプルします。openshift-clientsoc CLI を提供し、jq パッケージはコマンドライン上での JSON 出力の表示方法を向上させます。

7.1.4. RHEL コンピュートノードの準備

Red Hat Enterprise Linux (RHEL) マシンを OpenShift Container Platform クラスターに追加する前に、各ホストをRed Hat Subscription Manager (RHSM) に登録し、有効な OpenShift Container Platform サブスクリプションをアタッチし、必要なリポジトリーを有効にする必要があります。

  1. 各ホストで RHSM に登録します。

    # subscription-manager register --username=<user_name> --password=<password>
  2. RHSM から最新のサブスクリプションデータをプルします。

    # subscription-manager refresh
  3. 利用可能なサブスクリプションを一覧表示します。

    # subscription-manager list --available --matches '*OpenShift*'
  4. 直前のコマンドの出力で、OpenShift Container Platform サブスクリプションのプール ID を見つけ、これをアタッチします。

    # subscription-manager attach --pool=<pool_id>
  5. Yum リポジトリーをすべて無効にします。

    1. 有効にされている RHSM リポジトリーをすべて無効にします。

      # subscription-manager repos --disable="*"
    2. 残りの Yum リポジトリーを一覧表示し、repo id にあるそれらの名前をメモします (ある場合) 。

      # yum repolist
    3. yum-config-manager を使用して、残りの Yum リポジトリーを無効にします。

      # yum-config-manager --disable <repo_id>

      または、すべてのリポジトリーを無効にします。

       yum-config-manager --disable \*

      利用可能なリポジトリーが多い場合には、数分の時間がかかることがあります。

  6. OpenShift Container Platform 4.3 で必要なリポジトリーのみを有効にします。

    # subscription-manager repos \
        --enable="rhel-7-server-rpms" \
        --enable="rhel-7-server-extras-rpms" \
        --enable="rhel-7-server-ose-4.3-rpms"
  7. ホストで firewalld を停止し、無効にします。

    # systemctl disable --now firewalld.service
    注記

    firewalld は、後で有効にすることはできません。これを実行する場合、ワーカー上の OpenShift Container Platform ログにはアクセスできません。

7.1.5. RHEL コンピュートマシンのクラスターへの追加

Red Hat Enterprise Linux をオペレーティングシステムとして使用するコンピュートマシンを OpenShift Container Platform 4.3 クラスターに追加することができます。

前提条件

  • Playbook を実行するマシンに必要なパッケージをインストールし、必要な設定が行われています。
  • インストール用の RHEL ホストを準備しています。

手順

Playbook を実行するために準備しているマシンで以下の手順を実行します。

  1. コンピュートマシンホストおよび必要な変数を定義する /<path>/inventory/hosts という名前の Ansible インベントリーファイルを作成します。

    [all:vars]
    ansible_user=root 1
    #ansible_become=True 2
    
    openshift_kubeconfig_path="~/.kube/config" 3
    
    [new_workers] 4
    mycluster-rhel7-0.example.com
    mycluster-rhel7-1.example.com
    1
    Ansible タスクをリモートコンピュートマシンで実行するユーザー名を指定します。
    2
    ansible_userroot を指定しない場合、ansible_becomeTrue に設定し、ユーザーに sudo パーミッションを割り当てる必要があります。
    3
    クラスターの kubeconfig ファイルへのパスを指定します。
    4
    クラスターに追加する各 RHEL マシンを一覧表示します。各ホストについて完全修飾ドメイン名を指定する必要があります。この名前は、クラスターがマシンにアクセスするために使用するホスト名であるため、マシンにアクセスできるように正しいパブリックまたはプライベートの名前を設定します。
  2. Playbook を実行します。

    $ cd /usr/share/ansible/openshift-ansible
    $ ansible-playbook -i /<path>/inventory/hosts playbooks/scaleup.yml 1
    1
    <path> については、作成した Ansible インベントリーファイルへのパスを指定します。

7.1.6. マシンの CSR の承認

マシンをクラスターに追加する際に、追加したそれぞれのマシンについて 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、または必要な場合はそれらを承認してください。

前提条件

  • マシンがクラスターに追加されています。

手順

  1. クラスターがマシンを認識していることを確認します。

    $ oc get nodes
    
    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.16.2
    master-1  Ready     master  63m  v1.16.2
    master-2  Ready     master  64m  v1.16.2
    worker-0  NotReady  worker  76s  v1.16.2
    worker-1  NotReady  worker  70s  v1.16.2

    出力には作成したすべてのマシンが一覧表示されます。

  2. 保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に Pending または Approved ステータスが表示されていることを確認します。

    $ oc get csr
    
    NAME        AGE     REQUESTOR                                                                   CONDITION
    csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 1
    csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
    csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending 2
    csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
    ...
    1
    クライアント要求の CSR。
    2
    サーバー要求の CSR。

    この例では、2 つのマシンがクラスターに参加しています。この一覧にはさらに多くの承認された CSR が表示される可能性があります。

  3. 追加したマシンの保留中の CSR すべてが Pending ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。

    注記

    CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。最初の CSR の承認後、後続のノードクライアント CSR はクラスターの kube-controller-manger によって自動的に承認されます。kubelet 提供証明書の要求を自動的に承認する方法を実装する必要があります。

    • それらを個別に承認するには、それぞれの有効な CSR について以下のコマンドを実行します。

      $ oc adm certificate approve <csr_name> 1
      1
      <csr_name> は、現行の CSR の一覧からの CSR の名前です。
    • すべての保留中の CSR を承認するには、以下のコマンドを実行します。

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

追加情報

7.1.7. Ansible ホストファイルの必須パラメーター

Red Hat Enterprise Linux (RHEL) コンピュートマシンをクラスターに追加する前に、以下のパラメーターを Ansible ホストファイルに定義する必要があります。

パラメーター説明

ansible_user

パスワードなしの SSH ベースの認証を許可する SSH ユーザー。SSH キーベースの認証を使用する場合、キーを SSH エージェントで管理する必要があります。

システム上のユーザー名。デフォルト値は root です。

ansible_become

ansible_user の値が root ではない場合、 ansible_becomeTrue に設定する必要があり、ansible_user として指定するユーザーはパスワードなしの sudo アクセスが可能になるように設定される必要があります。

True。値が True ではない場合、このパラメーターを指定したり、定義したりしないでください。

openshift_kubeconfig_path

クラスターの kubeconfig ファイルが含まれるローカルディレクトリーへのパスおよびファイル名を指定します。

設定ファイルのパスと名前。

7.1.7.1. RHCOS コンピュートマシンのクラスターからの削除

Red Hat Enterprise Linux (RHEL) コンピュートマシンをクラスターに追加した後に、Red Hat Enterprise Linux CoreOS (RHCOS) コンピュートマシンを削除できます。

前提条件

  • RHEL コンピュートマシンをクラスターに追加済みです。

手順

  1. マシンの一覧を表示し、RHCOS コンピューマシンのノード名を記録します。

    $ oc get nodes -o wide
  2. それぞれの RHCOS コンピュートマシンについて、ノードを削除します。

    1. oc adm cordon コマンドを実行して、ノードにスケジュール対象外 (unschedulable) のマークを付けます。

      $ oc adm cordon <node_name> 1
      1
      RHCOS コンピュートマシンのノード名を指定します。
    2. ノードからすべての Pod をドレイン (解放) します。

      $ oc adm drain <node_name> --force --delete-local-data --ignore-daemonsets 1
      1
      分離した RHCOS コンピュートマシンのノード名を指定します。
    3. ノードを削除します。

      $ oc delete nodes <node_name> 1
      1
      ドレイン (解放) した RHCOS コンピュートマシンのノード名を指定します。
  3. コンピュートマシンの一覧を確認し、RHEL ノードのみが残っていることを確認します。

    $ oc get nodes -o wide
  4. RHCOS マシンをクラスターのコンピュートマシンのロードバランサーから削除します。仮想マシンを削除したり、RHCOS コンピュートマシンの物理ハードウェアを再イメージ化したりできます。

7.2. RHEL コンピュートマシンの OpenShift Container Platform クラスターへのさらなる追加

OpenShift Container Platform クラスターに Red Hat Enterprise Linux (RHEL) コンピュートマシン (またはワーカーマシンとしても知られる) がすでに含まれる場合、RHEL コンピュートマシンをさらに追加することができます。

7.2.1. RHEL コンピュートノードのクラスターへの追加について

OpenShift Container Platform 4.3 には、ユーザーによってプロビジョニングされるインフラストラクチャーを使用する場合、Red Hat Enterprise Linux (RHEL) マシンをクラスター内のコンピュートマシン (またはワーカーマシンとしても知られる) を使用するオプションがあります。クラスター内のコントロールプレーンまたはマスターマシンには Red Hat Enterprise Linux CoreOS (RHCOS) マシンを使用する必要があります。

ユーザーによってプロビジョニングされるインフラストラクチャーを使用するすべてのインストールの場合、クラスターで RHEL コンピュートマシンを使用する選択をする場合には、システム更新の実行や、パッチの適用、またその他の必要なすべてのタスクの実行を含むオペレーティングシステムのライフサイクル管理およびメンテナンスのすべてを独自に実行する必要があります。

重要

OpenShift Container Platform をクラスター内のマシンから削除するには、オペレーティングシステムを破棄する必要があるため、クラスターに追加する RHEL マシンについては専用のハードウェアを使用する必要があります。

重要

swap メモリーは、OpenShift Container Platform クラスターに追加されるすべての RHEL マシンで無効にされます。これらのマシンで swap メモリーを有効にすることはできません。

RHEL コンピュートマシンは、コントロールプレーンを初期化してからクラスターに追加する必要があります。

7.2.2. RHEL コンピュートノードのシステム要件

OpenShift Container Platform 環境の Red Hat Enterprise Linux (RHEL) コンピュートマシンホスト (またはワーカーマシンホストとしても知られる) は以下の最低のハードウェア仕様およびシステムレベルの要件を満たしている必要があります。

  • まず、お使いの Red Hat アカウントに有効な OpenShift Container Platform サブスクリプションがなければなりません。これがない場合は、営業担当者にお問い合わせください。
  • 実稼働環境では予想されるワークロードに対応するコンピュートーノードを提供する必要があります。クラスター管理者は、予想されるワークロードを計算し、オーバーヘッドの約 10 パーセントを追加する必要があります。実稼働環境の場合、ノードホストの障害が最大容量に影響を与えることがないよう、十分なリソースを割り当てるようにします。
  • 各システムは、以下のハードウェア要件を満たしている必要があります。

    • 物理または仮想システム、またはパブリックまたはプライベート IaaS で実行されるインスタンス。
    • ベース OS: RHEL 7.6 (「最小」のインストールオプション)

      重要

      OpenShift Container Platform 4.3 でサポートされるのは RHEL 7.6 のみになります。コンピュートマシンを RHEL 8 にアップグレードすることはできません。

    • FIPS モードで OpenShift Container Platform をデプロイしている場合、起動する前に FIPS を RHEL マシン上で有効にする必要があります。詳細は、RHEL 7 のドキュメントの「FIPS モードの有効化」を参照してください。
    • NetworkManager 1.0 以降。
    • 1 vCPU。
    • 最小 8 GB の RAM。
    • /var/ を含むファイルシステムの最小 15 GB のハードディスク領域。
    • /usr/local/bin/ を含むファイルシステムの最小 1 GB のハードディスク領域。
    • システムの一時ディレクトリーを含むファイルシステムの最小 1 GB のハードディスク領域。システムの一時ディレクトリーは、Python の標準ライブラリーの tempfile モジュールで定義されるルールに基づいて決定されます。
  • 各システムは、システムプロバイダーの追加の要件を満たす必要があります。たとえば、クラスターを VMware vSphere にインストールしている場合、ディスクはその ストレージガイドライン に応じて設定され、disk.enableUUID=true 属性が設定される必要があります。

7.2.2.1. 証明書署名要求の管理

ユーザーがプロビジョニングするインフラストラクチャーを使用する場合、クラスターの自動マシン管理へのアクセスは制限されるため、インストール後にクラスターの証明書署名要求 (CSR) のメカニズムを提供する必要があります。kube-controller-manager は kubelet クライアント CSR のみを承認します。machine-approver は、kubelet 認証情報を使用して要求される提供証明書の有効性を保証できません。適切なマシンがこの要求を発行したかどうかを確認できないためです。kubelet 提供証明書の要求の有効性を検証し、それらを承認する方法を判別し、実装する必要があります。

7.2.3. RHEL コンピュートノードの準備

Red Hat Enterprise Linux (RHEL) マシンを OpenShift Container Platform クラスターに追加する前に、各ホストをRed Hat Subscription Manager (RHSM) に登録し、有効な OpenShift Container Platform サブスクリプションをアタッチし、必要なリポジトリーを有効にする必要があります。

  1. 各ホストで RHSM に登録します。

    # subscription-manager register --username=<user_name> --password=<password>
  2. RHSM から最新のサブスクリプションデータをプルします。

    # subscription-manager refresh
  3. 利用可能なサブスクリプションを一覧表示します。

    # subscription-manager list --available --matches '*OpenShift*'
  4. 直前のコマンドの出力で、OpenShift Container Platform サブスクリプションのプール ID を見つけ、これをアタッチします。

    # subscription-manager attach --pool=<pool_id>
  5. Yum リポジトリーをすべて無効にします。

    1. 有効にされている RHSM リポジトリーをすべて無効にします。

      # subscription-manager repos --disable="*"
    2. 残りの Yum リポジトリーを一覧表示し、repo id にあるそれらの名前をメモします (ある場合) 。

      # yum repolist
    3. yum-config-manager を使用して、残りの Yum リポジトリーを無効にします。

      # yum-config-manager --disable <repo_id>

      または、すべてのリポジトリーを無効にします。

       yum-config-manager --disable \*

      利用可能なリポジトリーが多い場合には、数分の時間がかかることがあります。

  6. OpenShift Container Platform 4.3 で必要なリポジトリーのみを有効にします。

    # subscription-manager repos \
        --enable="rhel-7-server-rpms" \
        --enable="rhel-7-server-extras-rpms" \
        --enable="rhel-7-server-ose-4.3-rpms"
  7. ホストで firewalld を停止し、無効にします。

    # systemctl disable --now firewalld.service
    注記

    firewalld は、後で有効にすることはできません。これを実行する場合、ワーカー上の OpenShift Container Platform ログにはアクセスできません。

7.2.4. RHEL コンピュートマシンのクラスターへの追加

Red Hat Enterprise Linux をオペレーティングシステムとして使用するコンピュートマシンを OpenShift Container Platform 4.3 クラスターに追加することができます。

前提条件

  • OpenShift Container Platform クラスターに RHEL コンピュートノードがすでに含まれています。
  • 最初の RHEL コンピュートマシンをクラスターに追加するために使用した hosts ファイルは、Playbook を実行するマシン上にあります。
  • Playbook を実行するマシンは RHEL ホストにアクセスできる必要があります。Bastion と SSH プロキシーまたは VPN の使用など、所属する会社で許可されるすべての方法を利用できます。
  • クラスターの kubeconfig ファイルおよびクラスターのインストールに使用したインストールプログラムが Playbook の実行に使用するマシン上にあります。
  • インストール用の RHEL ホストを準備する必要があります。
  • すべての RHEL ホストへの SSH アクセスを持つユーザーを Playbook を実行するマシンで設定します。
  • SSH キーベースの認証を使用する場合、キーを SSH エージェントで管理する必要があります。
  • Playbook を実行するマシンに OpenShift CLI (oc) をインストールします。

手順

  1. コンピュートマシンホストおよび必要な変数を定義する /<path>/inventory/hosts にある Ansible インベントリーファイルを開きます。
  2. ファイルの [new_workers] セクションの名前を [workers] に変更します。
  3. [new_workers] セクションをファイルに追加し、それぞれの新規ホストの完全修飾ドメイン名を定義します。ファイルは以下の例のようになります。

    [all:vars]
    ansible_user=root
    #ansible_become=True
    
    openshift_kubeconfig_path="~/.kube/config"
    
    [workers]
    mycluster-rhel7-0.example.com
    mycluster-rhel7-1.example.com
    
    [new_workers]
    mycluster-rhel7-2.example.com
    mycluster-rhel7-3.example.com

    この例では、mycluster-rhel7-0.example.com および mycluster-rhel7-1.example.com マシンがクラスターにあり、mycluster-rhel7-2.example.com および mycluster-rhel7-3.example.com マシンを追加します。

  4. スケールアップ Playbook を実行します。

    $ cd /usr/share/ansible/openshift-ansible
    $ ansible-playbook -i /<path>/inventory/hosts playbooks/scaleup.yml 1
    1
    <path> については、作成した Ansible インベントリーファイルへのパスを指定します。

7.2.5. マシンの CSR の承認

マシンをクラスターに追加する際に、追加したそれぞれのマシンについて 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、または必要な場合はそれらを承認してください。

前提条件

  • マシンがクラスターに追加されています。

手順

  1. クラスターがマシンを認識していることを確認します。

    $ oc get nodes
    
    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.16.2
    master-1  Ready     master  63m  v1.16.2
    master-2  Ready     master  64m  v1.16.2
    worker-0  NotReady  worker  76s  v1.16.2
    worker-1  NotReady  worker  70s  v1.16.2

    出力には作成したすべてのマシンが一覧表示されます。

  2. 保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に Pending または Approved ステータスが表示されていることを確認します。

    $ oc get csr
    
    NAME        AGE     REQUESTOR                                                                   CONDITION
    csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 1
    csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
    csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending 2
    csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
    ...
    1
    クライアント要求の CSR。
    2
    サーバー要求の CSR。

    この例では、2 つのマシンがクラスターに参加しています。この一覧にはさらに多くの承認された CSR が表示される可能性があります。

  3. 追加したマシンの保留中の CSR すべてが Pending ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。

    注記

    CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。最初の CSR の承認後、後続のノードクライアント CSR はクラスターの kube-controller-manger によって自動的に承認されます。kubelet 提供証明書の要求を自動的に承認する方法を実装する必要があります。

    • それらを個別に承認するには、それぞれの有効な CSR について以下のコマンドを実行します。

      $ oc adm certificate approve <csr_name> 1
      1
      <csr_name> は、現行の CSR の一覧からの CSR の名前です。
    • すべての保留中の CSR を承認するには、以下のコマンドを実行します。

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

追加情報

7.2.6. Ansible ホストファイルの必須パラメーター

Red Hat Enterprise Linux (RHEL) コンピュートマシンをクラスターに追加する前に、以下のパラメーターを Ansible ホストファイルに定義する必要があります。

パラメーター説明

ansible_user

パスワードなしの SSH ベースの認証を許可する SSH ユーザー。SSH キーベースの認証を使用する場合、キーを SSH エージェントで管理する必要があります。

システム上のユーザー名。デフォルト値は root です。

ansible_become

ansible_user の値が root ではない場合、 ansible_becomeTrue に設定する必要があり、ansible_user として指定するユーザーはパスワードなしの sudo アクセスが可能になるように設定される必要があります。

True。値が True ではない場合、このパラメーターを指定したり、定義したりしないでください。

openshift_kubeconfig_path

クラスターの kubeconfig ファイルが含まれるローカルディレクトリーへのパスおよびファイル名を指定します。

設定ファイルのパスと名前。

7.3. コンピュートマシンの vSphere への追加

コンピュートマシンを VMware vSphere の OpenShift Container Platform クラスターに追加することができます。

7.3.1. 前提条件

7.3.2. vSphere での追加の Red Hat Enterprise Linux CoreOS (RHCOS) マシンの作成

VMware vSphere でユーザーによってプロビジョニングされるインフラストラクチャーを使用するクラスターのコンピュートマシンを追加で作成できます。

前提条件

  • コンピュートマシンの base64 でエンコードされた Ignition ファイルを取得します。
  • クラスター用に作成した vSphere テンプレートにアクセスできる必要があります。

手順

  1. テンプレートがデプロイされた後に、マシンの仮想マシンをクラスターにデプロイします。

    1. テンプレートの名前を右クリックし、CloneClone to Virtual Machine をクリックします。
    2. Select a name and folder タブで、仮想マシンの名前を指定します。compute-1 などのように、マシンタイプを名前に含めることができるかもしれません。
    3. Select a name and folder タブで、クラスターに作成したフォルダーの名前を選択します。
    4. Select a compute resource タブで、データセンター内のホストの名前を選択します。
    5. オプション: Select storage タブで、ストレージオプションをカスタマイズします。
    6. Select clone options で、Customize this virtual machine’s hardware を選択します。
    7. Customize hardware タブで、VM OptionsAdvanced をクリックします。

      • Latency Sensitivity 一覧から、High を選択します。
      • Edit Configuration をクリックし、Configuration Parameters ウィンドウで Add Configuration Params をクリックします。以下のパラメーター名および値を定義します。

        • guestinfo.ignition.config.data: このマシンファイルの base64 でエンコードしたコンピュート Ignition 設定ファイルの内容を貼り付けます。
        • guestinfo.ignition.config.data.encoding: base64 を指定します。
        • disk.EnableUUID: TRUE を指定します。
    8. Customize hardware タブの Virtual Hardware パネルで、必要に応じて指定した値を変更します。RAM、CPU、およびディスクストレージの量がマシンタイプの最小要件を満たすことを確認してください。また、ネットワークが複数利用可能な場合は、必ず Add network adapter に正しいネットワークを選択してください。
    9. 設定を完了し、仮想マシンの電源をオンにします。
  2. 継続してクラスター用の追加のコンピュートマシンを作成します。

7.3.3. マシンの CSR の承認

マシンをクラスターに追加する際に、追加したそれぞれのマシンについて 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、または必要な場合はそれらを承認してください。

前提条件

  • マシンがクラスターに追加されています。

手順

  1. クラスターがマシンを認識していることを確認します。

    $ oc get nodes
    
    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.16.2
    master-1  Ready     master  63m  v1.16.2
    master-2  Ready     master  64m  v1.16.2
    worker-0  NotReady  worker  76s  v1.16.2
    worker-1  NotReady  worker  70s  v1.16.2

    出力には作成したすべてのマシンが一覧表示されます。

  2. 保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に Pending または Approved ステータスが表示されていることを確認します。

    $ oc get csr
    
    NAME        AGE     REQUESTOR                                                                   CONDITION
    csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 1
    csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
    csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending 2
    csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
    ...
    1
    クライアント要求の CSR。
    2
    サーバー要求の CSR。

    この例では、2 つのマシンがクラスターに参加しています。この一覧にはさらに多くの承認された CSR が表示される可能性があります。

  3. 追加したマシンの保留中の CSR すべてが Pending ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。

    注記

    CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。最初の CSR の承認後、後続のノードクライアント CSR はクラスターの kube-controller-manger によって自動的に承認されます。kubelet 提供証明書の要求を自動的に承認する方法を実装する必要があります。

    • それらを個別に承認するには、それぞれの有効な CSR について以下のコマンドを実行します。

      $ oc adm certificate approve <csr_name> 1
      1
      <csr_name> は、現行の CSR の一覧からの CSR の名前です。
    • すべての保留中の CSR を承認するには、以下のコマンドを実行します。

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

追加情報

7.4. コンピュートマシンのベアメタルへの追加

ベアメタルの OpenShift Container Platform クラスターにコンピュートマシンを追加することができます。

7.4.1. 前提条件

7.4.2. Red Hat Enterprise Linux CoreOS (RHCOS) マシンの作成

ベアメタルインフラストラクチャーにインストールされているクラスターにコンピュートマシンを追加する前に、それが使用する RHCOS マシンを作成する必要があります。ISO イメージまたはネットワーク PXE ブートを使用する手順を実行してマシンを作成することができます。

7.4.2.1. ISO イメージを使用した追加の Red Hat Enterprise Linux CoreOS (RHCOS) マシンの作成

ISO イメージを使用して、ベアメタルクラスターの追加のコンピュートマシンを作成できます。

前提条件

  • クラスターのコンピュートマシンの Ignition 設定ファイルの URL を取得します。このファイルがインストール時に HTTP サーバーにアップロードされている必要があります。
  • クラスターのインストール時に HTTP サーバーにアップロードした BIOS または UEFI RHCOS イメージファイルの URL を取得します。

手順

  1. ISO ファイルを使用して、追加のコンピュートマシンに RHCOS をインストールします。クラスターのインストール前にマシンを作成する際に使用したのと同じ方法を使用します。

    • ディスクに ISO イメージを書き込み、これを直接起動します。
    • LOM インターフェースで ISO リダイレクトを使用します。
  2. インスタンスの起動後に、TAB または E キーを押してカーネルコマンドラインを編集します。
  3. パラメーターをカーネルコマンドラインに追加します。

    coreos.inst=yes
    coreos.inst.install_dev=sda 1
    coreos.inst.image_url=<bare_metal_image_URL> 2
    coreos.inst.ignition_url=http://example.com/worker.ign 3
    1
    インストール先のシステムのブロックデバイスを指定します。
    2
    サーバーにアップロードした UEFI または BIOS イメージの URL を指定します。
    3
    コンピュート Ignition 設定ファイルの URL を指定します。
  4. Enter を押してインストールを完了します。RHCOS のインストール後に、システムは再起動します。システムの再起動後、指定した Ignition 設定ファイルを適用します。
  5. 継続してクラスター用の追加のコンピュートマシンを作成します。

7.4.2.2. PXE または iPXE ブートによる追加の Red Hat Enterprise Linux CoreOS (RHCOS) マシンの作成

PXE または iPXE ブートを使用して、ベアメタルクラスターの追加のコンピュートマシンを作成できます。

前提条件

  • クラスターのコンピュートマシンの Ignition 設定ファイルの URL を取得します。このファイルがインストール時に HTTP サーバーにアップロードされている必要があります。
  • クラスターのインストール時に HTTP サーバーにアップロードした RHCOS ISO イメージ、圧縮されたメタル BIOS、kernel、および initramfs ファイルの URL を取得します。
  • インストール時に OpenShift Container Platform クラスターのマシンを作成するために使用した PXE ブートインフラストラクチャーにアクセスできる必要があります。RHCOS のインストール後にマシンはローカルディスクから起動する必要があります。
  • UEFI を使用する場合、OpenShift Container Platform のインストール時に変更した grub.conf ファイルにアクセスできます。

手順

  1. RHCOS イメージの PXE または iPXE インストールが正常に行われていることを確認します。

    • PXE の場合:

      DEFAULT pxeboot
      TIMEOUT 20
      PROMPT 0
      LABEL pxeboot
          KERNEL http://<HTTP_server>/rhcos-<version>-installer-kernel-<architecture> 1
          APPEND ip=dhcp rd.neednet=1 initrd=http://<HTTP_server>/rhcos-<version>-installer-initramfs.<architecture>.img console=tty0 console=ttyS0 coreos.inst=yes coreos.inst.install_dev=sda coreos.inst.image_url=http://<HTTP_server>/rhcos-<version>-metal.<architecture>.raw.gz coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 2 3
      1
      HTTP サーバーにアップロードした kernel ファイルの場所を指定します。
      2
      複数の NIC を使用する場合、ip オプションに単一インターフェースを指定します。たとえば、eno1 という名前の NIC で DHCP を使用するには、ip=eno1:dhcp を設定します。
      3
      HTTP サーバーにアップロードした RHCOS ファイルの場所を指定します。initrd パラメーター値は initramfs ファイルの場所であり、coreos.inst.image_url パラメーター値は圧縮された metal RAW イメージの場所、および coreos.inst.ignition_url パラメーター値はワーカー Ignition 設定ファイルの場所になります。
    • iPXE の場合:

      kernel http://<HTTP_server>/rhcos-<version>-installer-kernel-<architecture> ip=dhcp rd.neednet=1 initrd=http://<HTTP_server>/rhcos-<version>-installer-initramfs.<architecture>.img console=tty0 console=ttyS0 coreos.inst=yes coreos.inst.install_dev=sda coreos.inst.image_url=http://<HTTP_server>/rhcos-<version>-metal.<arhcitectutre>.raw.gz coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 1 2
      initrd http://<HTTP_server>/rhcos-<version>-installer-initramfs.<architecture>.img 3
      boot
      1
      HTTP サーバーにアップロードした RHCOS ファイルの場所を指定します。kernel パラメーター値は kernel ファイルの場所であり、initrd パラメーター値は initramfs ファイルの場所、coreos.inst.image_url パラメーター値は圧縮された metal RAW イメージの場所、および coreos.inst.ignition_url パラメーター値はワーカー Ignition 設定ファイルの場所になります。
      2
      複数の NIC を使用する場合、ip オプションに単一インターフェースを指定します。たとえば、eno1 という名前の NIC で DHCP を使用するには、ip=eno1:dhcp を設定します。
      3
      HTTP サーバーにアップロードした initramfs ファイルの場所を指定します。
  2. PXE または iPXE インフラストラクチャーを使用して、クラスターに必要なコンピュートマシンを作成します。

7.4.3. マシンの CSR の承認

マシンをクラスターに追加する際に、追加したそれぞれのマシンについて 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、または必要な場合はそれらを承認してください。

前提条件

  • マシンがクラスターに追加されています。

手順

  1. クラスターがマシンを認識していることを確認します。

    $ oc get nodes
    
    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.16.2
    master-1  Ready     master  63m  v1.16.2
    master-2  Ready     master  64m  v1.16.2
    worker-0  NotReady  worker  76s  v1.16.2
    worker-1  NotReady  worker  70s  v1.16.2

    出力には作成したすべてのマシンが一覧表示されます。

  2. 保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に Pending または Approved ステータスが表示されていることを確認します。

    $ oc get csr
    
    NAME        AGE     REQUESTOR                                                                   CONDITION
    csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 1
    csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
    csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending 2
    csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
    ...
    1
    クライアント要求の CSR。
    2
    サーバー要求の CSR。

    この例では、2 つのマシンがクラスターに参加しています。この一覧にはさらに多くの承認された CSR が表示される可能性があります。

  3. 追加したマシンの保留中の CSR すべてが Pending ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。

    注記

    CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。最初の CSR の承認後、後続のノードクライアント CSR はクラスターの kube-controller-manger によって自動的に承認されます。kubelet 提供証明書の要求を自動的に承認する方法を実装する必要があります。

    • それらを個別に承認するには、それぞれの有効な CSR について以下のコマンドを実行します。

      $ oc adm certificate approve <csr_name> 1
      1
      <csr_name> は、現行の CSR の一覧からの CSR の名前です。
    • すべての保留中の CSR を承認するには、以下のコマンドを実行します。

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

追加情報

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

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

重要

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

8.1. MachineHealthCheck について

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

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

注記

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

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

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

8.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" 5
    status: "False"
  - type:    "Ready"
    timeout: "300s" 6
    status: "Unknown"
  maxUnhealthy: "40%" 7

1
デプロイする MachineHealthCheck の名前を指定します。
2 3
チェックする必要のあるマシンプールのラベルを指定します。
4
追跡する MachineSet を <cluster_name>-<label>-<zone> 形式で指定します。たとえば、prod-node-us-east-1a とします。
5 6
ノードの状態のタイムアウト期間を指定します。タイムアウト期間の条件が満たされると、マシンは修正されます。タイムアウトの時間が長くなると、正常でないマシンのワークロードのダウンタイムが長くなる可能性があります。
7
マシンのターゲットプールで許可される正常でないマシンの量を指定します。これはパーセンテージまたは整数として設定できます。
注記

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

8.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.