1. Homepage
  2. Runtime Fabric (1.13)
  3. VM/ベアメタル

  4. Runtime Fabric での定期メンテナンスの実行

VM/ベアメタルの Runtime Fabric の定期メンテナンスの実行

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。

VM/ベアメタルの Runtime Fabric を使用する場合、次の手順を使用して定期メンテナンスを実行できます。これには、OS パッチとセキュリティの更新の適用が含まれます。

コントローラーノードのメンテナンス

コントローラーノードは、Runtime Fabric クラスターのエントリポイントであり、アプリケーションワークロードは実行しません。

1 台ずつ、すべてのコントローラーノードを更新します。

  1. 上流の TCP ロードバランサーで、負荷分散プールからコントローラーノードを削除します。

  2. 必要なパッチを適用してからノードを再起動します。

  3. コントローラーノードで更新が完了したら、ノードをクラスターに戻して、次のノードを更新します。

ワーカーノードのメンテナンス

ワーカーノードを更新するには、次の手順を実行します。

  1. コントローラーノードで、​gravity shell​ コマンドを実行します。

  2. すべてのノードの状況が ​READY​ であることを確認します。

    $ kubectl get nodes

NAME          STATUS   ROLES    AGE   VERSION
172.31.0.9    Ready    node     1d   v1.x.x
172.31.0.8    Ready    master   1d   v1.x.x

  3. アプリケーション名前空間 (環境 ID) を取得します。

    $ kubectl get ns

NAME                                   STATUS   AGE
default                                Active   1d
fff5df7b-c49d-48c9-967d-0071412722x4   Active   1d
kube-node-lease                        Active   1d
kube-public                            Active   1d
kube-system                            Active   1d
monitoring                             Active   1d
rtf                                    Active   1d

    コマンド出力において、アプリケーション名前空間は長い文字列として表されます。上の例では、アプリケーション名前空間は ​fff5df7b-c49d-48c9-967d-0071412722x4​ です。

    Runtime Fabric クラスターが複数の環境に関連付けられている場合は、複数のアプリケーション名前空間の値が表示されます。

  4. 名前空間でポッドとノードが実行中であることを確認します。

    $ kubectl -n <namespace> get pod -owide

    コマンド出力では、​READY​ 列に ​Running​ と表示されています。

    NAME                                         READY   STATUS    RESTARTS   AGE     IP             NODE          NOMINATED NODE   READINESS GATES
my-app-name-1-84f95cb7c9-glktk     2/2     Running   0          9m27s   10.244.88.29   172.31.0.9   <none>           <none>

    複数の環境を使用している場合は、以下のステップを各環境で実行する必要があります。

  5. 更新が必要な各ワーカーノードに対して次の手順を実行します。

    1. ノードをドレーンします。

      $ kubectl drain <node name> --ignore-daemonsets --delete-local-data

      ノードをドレーンすると、次のアクションが実行されます。

      • アプリケーションが別のノード上でスケジュールされてから削除されます。

      • ノードの状況が ​SchedulingDisabled​ に変更されます。

        アプリケーションのレプリカが最低 2 つ実行されていて、アプリケーションのデプロイ時に ​[Enforce deploying replicas across nodes (ノード間でレプリカのデプロイメントを適用)]​ が指定されていない限り、ドレーン処理中はサービスが中断します。

    2. ノードの状況が ​Ready,SchedulingDisabled​ であることを確認します。

      $ kubectl get node

NAME          STATUS                     ROLES    AGE   VERSION
172.31.0.9   Ready,SchedulingDisabled   node     1d   v1.x.x

    3. ドレーン済みのノードでアプリケーションポッドが実行中ではないことを確認します。

      $ kubectl get pod -n <namespace>  -owide

      NODE​ 列に表示されるコマンド出力に、ドレーン済みのノードでアプリケーションポッドが実行中ではないことが表示されていることを確認してください。

    4. OS パッチを適用してからノードを再起動します。

    5. 再起動の完了後、ノードでスケジューリングを再び有効化します。

    $ kubectl uncordon 172.31.0.9

node/172.31.0.9 uncordoned

$ kubectl get node

NAME          STATUS   ROLES    AGE   VERSION
172.31.0.9   Ready    node     1d   v1.x.x