マシン管理

手順

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

   重要

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

手順

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 に加えられた変更が含まれます。

手順

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 に属する場合、指定されたレプリカ数に対応するために新規マシンが即時に作成されます。

手順

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

   # subscription-manager repos \
       --enable="rhel-7-server-rpms" \
       --enable="rhel-7-server-extras-rpms" \
       --enable="rhel-7-server-ansible-2.7-rpms" \
       --enable="rhel-7-server-ose-4.1-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.1 で必要なリポジトリーのみを有効にします。

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

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

   # systemctl disable --now firewalld.service

   注記

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

1. クラスターのプルシークレットを抽出します。

   $ oc -n openshift-config get -o jsonpath='{.data.\.dockerconfigjson}' secret pull-secret | base64 -d | jq .

2. pull-secret.txt という名前のファイルにプルシークレットを保存します。

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

   [all:vars]
   ansible_user=root 1
   #ansible_become=True 2
   
   openshift_kubeconfig_path="~/.kube/config" 3
   openshift_pull_secret_path="~/pull-secret.txt" 4
   
   [new_workers] 5
   mycluster-worker-0.example.com
   mycluster-worker-1.example.com

   1

   Ansible タスクをリモートコンピュートマシンで実行するユーザー名を指定します。

   2

   ansible_user の root を指定しない場合、ansible_become を True に設定し、ユーザーに sudo パーミッションを割り当てる必要があります。

   3

   クラスターの kubeconfig ファイルへのパスを指定します。

   4

   クラスターのイメージレジストリーのプルシークレットが含まれるファイルへのパスを指定します。

   5

   クラスターに追加する各 RHEL マシンを一覧表示します。各ホストについて完全修飾ドメイン名を指定する必要があります。この名前は、クラスターがマシンにアクセスするために使用するホスト名であるため、マシンにアクセスできるように正しいパブリックまたはプライベートの名前を設定します。

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-0  Ready     master  63m  v1.13.4+b626c2fe1
   master-1  Ready     master  63m  v1.13.4+b626c2fe1
   master-2  Ready     master  64m  v1.13.4+b626c2fe1
   worker-0  NotReady  worker  76s  v1.13.4+b626c2fe1
   worker-1  NotReady  worker  70s  v1.13.4+b626c2fe1

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

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 -ojson | jq -r '.items[] | select(.status == {} ) | .metadata.name' | xargs oc adm certificate approve

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

   # subscription-manager repos \
       --enable="rhel-7-server-rpms" \
       --enable="rhel-7-server-extras-rpms" \
       --enable="rhel-7-server-ose-4.1-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"
   openshift_pull_secret_path="~/pull-secret.txt"
   
   [workers]
   mycluster-worker-0.example.com
   mycluster-worker-1.example.com
   
   [new_workers]
   mycluster-worker-2.example.com
   mycluster-worker-3.example.com

   この例では、mycluster-worker-0.example.com および mycluster-worker-1.example.com マシンがクラスターにあり、mycluster-worker-2.example.com および mycluster-worker-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-0  Ready     master  63m  v1.13.4+b626c2fe1
   master-1  Ready     master  63m  v1.13.4+b626c2fe1
   master-2  Ready     master  64m  v1.13.4+b626c2fe1
   worker-0  NotReady  worker  76s  v1.13.4+b626c2fe1
   worker-1  NotReady  worker  70s  v1.13.4+b626c2fe1

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

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 -ojson | jq -r '.items[] | select(.status == {} ) | .metadata.name' | xargs oc adm certificate approve

手順

1. MachineHealthCheck の定義を含む healthcheck.yml ファイルを作成します。

2. healthcheck.yml ファイルをクラスターに適用します。

   $ oc apply -f healthcheck.yml