手順

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

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

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

      $ 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. 特定のマシンセットの値を確認します。

      $ 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 CR を作成します。

   $ oc create -f <file_name>.yaml

3. マシンセットの一覧を表示します。

   $ 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

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

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

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

手順

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

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

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

      $ 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. 特定のマシンセットの値を確認します。

      $ 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 CR を作成します。

   $ oc create -f <file_name>.yaml

3. マシンセットの一覧を表示します。

   $ 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

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

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

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

手順

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

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

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

      $ 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. 特定のマシンセットの値を確認します。

      $ 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 CR を作成します。

   $ oc create -f <file_name>.yaml

3. マシンセットの一覧を表示します。

   $ 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

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

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

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

手順

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

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

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

      $ 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. 特定のマシンセットの値を確認します。

      $ 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 CR を作成します。

   $ oc create -f <file_name>.yaml

3. マシンセットの一覧を表示します。

   $ 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

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

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

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

手順

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

2. クラスターにリソースを作成します。

   $ oc create -f <filename>.yaml 1

   1

   <filename> は、カスタマイズしたリソースファイルの名前です。

手順

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

2. クラスターにリソースを作成します。

   $ oc create -f <filename>.yaml 1

   1

   <filename> は、カスタマイズしたリソースファイルの名前です。

手順

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

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

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

      $ 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. 特定のマシンセットの値を確認します。

      $ 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 CR を作成します。

   $ oc create -f <file_name>.yaml

3. マシンセットの一覧を表示します。

   $ 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

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

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

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

手順

1. 以下のコマンドを使用して、テイントを infra ノードに追加し、ユーザーのワークロードをこれにスケジュールできないようにします。

   $ oc adm taint nodes <node_name> <key>:<effect>

   以下は例になります。

   $ oc adm taint nodes node1 node-role.kubernetes.io/infra:NoSchedule

   この例では、テイントを、キー node-role.kubernetes.io/infra およびテイントの effect NoSchedule を持つ node1 に配置します。effect が NoSchedule のノードは、テイントを容認する Pod のみをスケジュールしますが、既存の Pod はノードにスケジュールされたままになります。

   注記

   Descheduler が使用されると、ノードのテイントに違反する Pod はクラスターからエビクトされる可能性があります。

2. ルーター、レジストリーおよびモニタリングのワークロードなどの、infra ノードにスケジュールする必要のある Pod 設定の容認を追加します。以下のコードを Pod オブジェクトの仕様に追加します。

   tolerations:
     - effect: NoSchedule 1
       key: node-role.kubernetes.io/infra 2
       operator: Exists 3

   1

   ノードに追加した effect を指定します。

   2

   ノードに追加したキーを指定します。

   3

   Exists Operator を、キー node-role.kubernetes.io/infra のあるテイントがノードに存在するように指定します。

   この容認は、oc adm taint コマンドで作成されたテイントと一致します。この容認のある Pod は infra ノードにスケジュールできます。

   注記

   OLM でインストールされた Operator の Pod を infra ノードに常に移動できる訳ではありません。Operator Pod を移動する機能は、各 Operator の設定によって異なります。

3. スケジューラーを使用して Pod を infra ノードにスケジュールします。詳細は、Pod のノードへの配置の制御 についてのドキュメントを参照してください。

手順

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 リソースを編集し、 nodeSelector を infra ラベルを使用するように変更します。

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

   以下に示すように、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.17.1

      1

      Pod の一覧より取得した <node_name> を指定します。

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

手順

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

手順

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: ""
       thanosQuerier:
         nodeSelector:
           node-role.kubernetes.io/infra: ""

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

2. 新規の設定マップを適用します。

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

手順

1. openshift-logging プロジェクトで ClusterLogging カスタムリソース (CR) を編集します。

   $ 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. クラスターの 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.4 で必要なリポジトリーを有効にします。

   # subscription-manager repos \
       --enable="rhel-7-server-rpms" \
       --enable="rhel-7-server-extras-rpms" \
       --enable="rhel-7-server-ansible-2.9-rpms" \
       --enable="rhel-7-server-ose-4.4-rpms"

6. openshift-ansible を含む必要なパッケージをインストールします。

   # yum install openshift-ansible openshift-clients jq

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

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.4 で必要なリポジトリーのみを有効にします。

   # subscription-manager repos \
       --enable="rhel-7-server-rpms" \
       --enable="rhel-7-server-extras-rpms" \
       --enable="rhel-7-server-ose-4.4-rpms"

7. ホストで firewalld を停止し、無効にします。

   # systemctl disable --now firewalld.service

   注記

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

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_user の root を指定しない場合、ansible_become を True に設定し、ユーザーに 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 インベントリーファイルへのパスを指定します。

手順

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

   # oc get nodes
   
   NAME                    STATUS   ROLES    AGE   VERSION
   master-01.example.com   Ready    master   40d   v1.17.1
   master-02.example.com   Ready    master   40d   v1.17.1
   master-03.example.com   Ready    master   40d   v1.17.1
   worker-01.example.com   Ready    worker   40d   v1.17.1
   worker-02.example.com   Ready    worker   40d   v1.17.1

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

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

   $ oc get csr
   
   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   ...

   この例では、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

4. クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。

   $ oc get csr

   出力例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
   csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
   ...

5. 残りの CSR が承認されず、それらが Pending ステータスにある場合、クラスターマシンの CSR を承認します。

   • それらを個別に承認するには、それぞれの有効な 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

6. すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが Ready になります。以下のコマンドを実行して、これを確認します。

   $ oc get nodes

   出力例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  73m  v1.20.0
   master-1  Ready     master  73m  v1.20.0
   master-2  Ready     master  74m  v1.20.0
   worker-0  Ready     worker  11m  v1.20.0
   worker-1  Ready     worker  11m  v1.20.0

   注記

   サーバー CSR の承認後にマシンが Ready ステータスに移行するまでに数分の時間がかかる場合があります。

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.4 で必要なリポジトリーのみを有効にします。

   # subscription-manager repos \
       --enable="rhel-7-server-rpms" \
       --enable="rhel-7-server-extras-rpms" \
       --enable="rhel-7-server-ose-4.4-rpms"

7. ホストで firewalld を停止し、無効にします。

   # systemctl disable --now firewalld.service

   注記

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

手順

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 インベントリーファイルへのパスを指定します。

手順

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

   # oc get nodes
   
   NAME                    STATUS   ROLES    AGE   VERSION
   master-01.example.com   Ready    master   40d   v1.17.1
   master-02.example.com   Ready    master   40d   v1.17.1
   master-03.example.com   Ready    master   40d   v1.17.1
   worker-01.example.com   Ready    worker   40d   v1.17.1
   worker-02.example.com   Ready    worker   40d   v1.17.1

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

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

   $ oc get csr
   
   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   ...

   この例では、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

4. クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。

   $ oc get csr

   出力例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
   csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
   ...

5. 残りの CSR が承認されず、それらが Pending ステータスにある場合、クラスターマシンの CSR を承認します。

   • それらを個別に承認するには、それぞれの有効な 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

6. すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが Ready になります。以下のコマンドを実行して、これを確認します。

   $ oc get nodes

   出力例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  73m  v1.20.0
   master-1  Ready     master  73m  v1.20.0
   master-2  Ready     master  74m  v1.20.0
   worker-0  Ready     worker  11m  v1.20.0
   worker-1  Ready     worker  11m  v1.20.0

   注記

   サーバー CSR の承認後にマシンが Ready ステータスに移行するまでに数分の時間がかかる場合があります。

手順

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

   1. テンプレートの名前を右クリックし、Clone → Clone 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 Options → Advanced をクリックします。

      • 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. 継続してクラスター用の追加のコンピュートマシンを作成します。

手順

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

   # oc get nodes
   
   NAME                    STATUS   ROLES    AGE   VERSION
   master-01.example.com   Ready    master   40d   v1.17.1
   master-02.example.com   Ready    master   40d   v1.17.1
   master-03.example.com   Ready    master   40d   v1.17.1
   worker-01.example.com   Ready    worker   40d   v1.17.1
   worker-02.example.com   Ready    worker   40d   v1.17.1

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

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

   $ oc get csr
   
   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   ...

   この例では、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

4. クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。

   $ oc get csr

   出力例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
   csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
   ...

5. 残りの CSR が承認されず、それらが Pending ステータスにある場合、クラスターマシンの CSR を承認します。

   • それらを個別に承認するには、それぞれの有効な 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

6. すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが Ready になります。以下のコマンドを実行して、これを確認します。

   $ oc get nodes

   出力例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  73m  v1.20.0
   master-1  Ready     master  73m  v1.20.0
   master-2  Ready     master  74m  v1.20.0
   worker-0  Ready     worker  11m  v1.20.0
   worker-1  Ready     worker  11m  v1.20.0

   注記

   サーバー CSR の承認後にマシンが Ready ステータスに移行するまでに数分の時間がかかる場合があります。

手順

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

   # oc get nodes
   
   NAME                    STATUS   ROLES    AGE   VERSION
   master-01.example.com   Ready    master   40d   v1.17.1
   master-02.example.com   Ready    master   40d   v1.17.1
   master-03.example.com   Ready    master   40d   v1.17.1
   worker-01.example.com   Ready    worker   40d   v1.17.1
   worker-02.example.com   Ready    worker   40d   v1.17.1

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

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

   $ oc get csr
   
   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   ...

   この例では、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

4. クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。

   $ oc get csr

   出力例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
   csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
   ...

5. 残りの CSR が承認されず、それらが Pending ステータスにある場合、クラスターマシンの CSR を承認します。

   • それらを個別に承認するには、それぞれの有効な 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

6. すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが Ready になります。以下のコマンドを実行して、これを確認します。

   $ oc get nodes

   出力例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  73m  v1.20.0
   master-1  Ready     master  73m  v1.20.0
   master-2  Ready     master  74m  v1.20.0
   worker-0  Ready     worker  11m  v1.20.0
   worker-1  Ready     worker  11m  v1.20.0

   注記

   サーバー CSR の承認後にマシンが Ready ステータスに移行するまでに数分の時間がかかる場合があります。