デバイスをシャットダウンして電源をオンにする

このページでは、Google Distributed Cloud（GDC）エアギャップ アプライアンスをシャットダウンして起動する方法について説明します。たとえば、デバイスを新しい場所に移動する場合などです。

GDC エアギャップ アプライアンスは、一時的な運用場所で使用されることがあります。このような場所では、デバイスを移動するために、輸送のためにデバイスをシャットダウンする必要があります。また、発電機が過酷な環境で電力を供給する可能性があるため、停電からデバイスを復元する必要がある場合もあります。

始める前に

続行する前に、すべてのワークロードを停止してください。シャットダウン中にワークロードがアクティブな場合に何が起こるかは保証できません。

前提条件

  1. このランブックは、Google Distributed Cloud（GDC）エアギャップ アプライアンスのネットワークに接続されたノートパソコンまたはワークステーションで実行できます。または、デバイスを接続するの手順に沿って、ノートパソコンまたはワークステーションをスイッチに接続することもできます。
  2. ルート管理者クラスタの kubeconfig へのアクセス権があることを確認します。
  3. export KUBECONFIG=PATH_TO_KUBECONFIG を実行して、正しい KUBECONFIG 環境変数を設定します。
  4. SSH 認証鍵と証明書があることを確認します。

ブレードをシャットダウンする

  1. kubectl get nodes -A -o wide を実行して、ノードの情報を取得します。

  2. 次のコマンドをすべてのノードで 1 つずつ実行して、BareMetalHost の同期を一時停止します。NODE_NAME は、手順 1 で取得したノード名に置き換えます。

    kubectl annotate bmhost -n gpc-system NODE_NAME "baremetalhost.metal3.io/paused=true" --overwrite

    出力は次のようになります。

    baremetalhost.metal3.io/**-**-bm01 annotated
baremetalhost.metal3.io/**-**-bm02 annotated
baremetalhost.metal3.io/**-**-bm03 annotated

  3. すべてのノードを 1 つずつ閉鎖します。

    kubectl cordon NODE_NAME

    出力は次のようになります。

    node/**-**-bm01 cordoned
node/**-**-bm02 cordoned
node/**-**-bm03 cordoned

  4. etcd リーダーノードとフォロワーノードを特定するには、すべてのノードに対してこの手順を 1 つずつ実行します。

    1. kubectl get nodes -A -o wide の出力の INTERNAL-IP 列にある値をメモして、SSH のターゲット IP を見つけます。SSH 接続を確立します。

      ssh root@INTERNAL-IP

    2. 現在のノードが etcd リーダーかフォロワーかを確認するには、SSH ターミナルで次のコマンドを実行します。

      ETCDCTL_API=3 etcdctl \
    --cacert /etc/kubernetes/pki/etcd/ca.crt \
    --cert /etc/kubernetes/pki/etcd/server.crt \
    --key /etc/kubernetes/pki/etcd/server.key \
    --write-out=table endpoint status

      IS LEADER フィールドに注意してください。

      出力は、etcd リーダーノードの次の例のようになります。

      [root@**-**-bm0* ~]# ETCDCTL_API=3 etcdctl \
>      --cacert /etc/kubernetes/pki/etcd/ca.crt \
>      --cert /etc/kubernetes/pki/etcd/server.crt \
>      --key /etc/kubernetes/pki/etcd/server.key \
>      --write-out=table endpoint status
+----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+
|    ENDPOINT    |        ID        |   VERSION    | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+
| ************** | **************** | 3.4.30-gke.1 |  162 MB |      true |      false |      3641 |   12957958 |           12957958 |        |
+----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+

      出力は、2 つの etcd フォロワー ノードの次の例のようになります。

      [root@**-**-bm0* ~]# ETCDCTL_API=3 etcdctl \
>      --cacert /etc/kubernetes/pki/etcd/ca.crt \
>      --cert /etc/kubernetes/pki/etcd/server.crt \
>      --key /etc/kubernetes/pki/etcd/server.key \
>      --write-out=table endpoint status
+----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+
|    ENDPOINT    |        ID        |   VERSION    | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+
| ************** | **************** | 3.4.30-gke.1 |  163 MB |     false |      false |      3641 |   12957404 |           12957404 |        |
+----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+

      ノードの etcd-leader と etcd-follower のステータスをメモします。

  5. 2 つの etcd フォロワー ノードをドレインします。etcd リーダーノードをドレインしないでください。

    kubectl drain NODE_NAME --delete-emptydir-data --grace-period 900 --ignore-daemonsets --disable-eviction

    出力は次のようになります。

    node/**-**-bm01 already cordoned
WARNING: ignoring DaemonSet-managed Pods: kube-system/anetd-krj2z, kube-system/etcd-defrag-xh469, kube-system/ipam-controller-manager-2f4dz, kube-system/istio-cni-node-cgqv4, kube-system/kube-proxy-5mwf2, kube-system/localpv-mn2jh, kube-system/metallb-speaker-6l7sv, mon-system/mon-node-exporter-backend-nd8mp, netapp-trident/netapp-trident-node-linux-rrlmd, obs-system/anthos-audit-logs-forwarder-tpfqv, obs-system/anthos-log-forwarder-npjh4, obs-system/kube-control-plane-metrics-proxy-wp8nh, obs-system/log-failure-detector-crbnv, obs-system/oplogs-forwarder-sqwvj, vm-system/macvtap-v9pgp, vm-system/virt-handler-86khx
pod/grafana-0 deleted
pod/capi-kubeadm-bootstrap-controller-manager-1.30.400-gke.136lvgtf deleted
pod/grafana-0 deleted
pod/grafana-proxy-server-86d8fc4758-mkc4f deleted
.
.
.

node/**-**-bm02 already cordoned
WARNING: ignoring DaemonSet-managed Pods: kube-system/anetd-v75jz, kube-system/etcd-defrag-t5jnc, kube-system/ipam-controller-manager-5958m, kube-system/istio-cni-node-ggv4c, kube-system/kube-proxy-r6x46, kube-system/localpv-g56xc, kube-system/metallb-speaker-tmw72, mon-system/mon-node-exporter-backend-9rs7k, netapp-trident/netapp-trident-node-linux-9jmfp, obs-system/anthos-audit-logs-forwarder-bwns9, obs-system/anthos-log-forwarder-lbskj, obs-system/kube-control-plane-metrics-proxy-grthl, obs-system/log-failure-detector-dzh4v, obs-system/oplogs-forwarder-vdn7z, vm-system/macvtap-mjwtc, vm-system/virt-handler-dlqvv
pod/vai-web-plugin-backend-5dfd6d6597-nxxgn
pod/vai-web-plugin-frontend-6b5468968b-mrr7g
pod/grafana-proxy-server-64b759fbf6-b8pl8
pod/iam-bundledidp-backend-0
.
.
.

  6. 2 つの etcd フォロワー ノードを正常にシャットダウンします。両方のノードで次の手順を1 つずつ実行します。

  7. iLO を使用して NODE_NAME をオフにするには:

    1. iLO のユーザー名を取得します。

      kubectl get secret bmc-credentials-NODE_NAME -n gpc-system -o jsonpath="{.data.username}" | base64 --decode

    2. iLO のパスワードを取得します。

      kubectl get secret bmc-credentials-NODE_NAME -n gpc-system -o jsonpath="{.data.password}" | base64 --decode

    3. BMC-IP 列の値から NODE_NAME の BMC-IP アドレスを取得します。

      kubectl get servers -A

    4. 前の手順で取得した BMC-IP アドレスにアクセスし、取得したユーザー名とパスワードを入力してログインします。

    5. 上段の最初のボタンにカーソルを合わせます。Power: ON が表示されます。クリック、プルダウン メニューが表示されるので、Momentary Press というラベルの付いた最初の項目をクリックします。ボタンの色が緑からオレンジに変わり、ノードがシャットダウン中であることを示します。ボタンの色が黄色に変わるまで待ちます。これは、マシンが電源オフになったことを示します。数分かかります。

  8. 両方の etcd フォロワー ノードがシャットダウンしたら、最後に etcd リーダー ノードに対して手順 7 を繰り返します。

輸送のために YubiKey を取り外す

インストール完了後にシステムを輸送する必要がある場合は、YubiKey を取り外して、YubiKey を個別に輸送します。キーに自分でタグ付けしてください。

電源を入れて接続する

ハード シャットダウンなどで電源が予期せず切れた場合、デバイスは自動的に復旧します。この場合は、ステップ 1 ～ 6 をスキップして、ステップ 7 から開始します。予期しない停電が発生した場合、データが失われることがありますが、停電後に復元されます。

アクション プラン

  1. 各ノードに YubiKey を挿入します。

  2. GDC エアギャップ アプライアンス マシンを電源に接続し、各ノードの電源ボタンを任意の順序で押します。

  3. ノードの電源が入ったら、コントロール プレーンが接続されるまで数分待ちます。kubectl は 30 分以内にコントロール プレーンに接続できます。

  4. kubectl get nodes -A を実行して、ノードの名前を取得します。

  5. 各ノードの閉鎖を解除して、スケジューリングを有効にします。

    kubectl uncordon `NODE_NAME`

  6. 各ノードのベアメタル ホストの同期を再開します。

    kubectl annotate bmhost -n gpc-system NODE_NAME "baremetalhost.metal3.io/paused=false" --overwrite

  7. kubectl get nodes -A を使用して、ノードのステータスを確認します。

    • すべてのノードが Ready 状態の場合は、調整プロセスが完了するまで 2 時間待ちます。出力は次のようになります。

      NAME         STATUS     ROLES           AGE     VERSION
**-**-bm01   Ready      control-plane   4d13h   v1.30.6-gke.300
**-**-bm02   Ready      control-plane   4d13h   v1.30.6-gke.300
**-**-bm03   Ready      control-plane   4d13h   v1.30.6-gke.300

      この場合、追加のアクションを行う必要はありません。

    • それ以外の場合、1 つ以上のノードが NotReady 状態の場合は、一部のサービスを再起動してクラスタを準備します。出力は次のようになります。

      NAME         STATUS     ROLES           AGE     VERSION
**-**-bm01   Ready      control-plane   4d13h   v1.30.6-gke.300
**-**-bm02   Ready      control-plane   4d13h   v1.30.6-gke.300
**-**-bm03   NotReady   control-plane   4d13h   v1.30.6-gke.300

      この場合は、準備ができていないノードの名前をメモして、次のステップに進みます。

  8. NotReady ノードへの SSH 接続を確立します。SSH のターゲット IP アドレスは、kubectl get nodes -A -o wide の出力の INTERNAL-IP 列の値です。

    ssh root@INTERNAL-IP

  9. NotReady ノードで containerd サービスと kubelet サービスを再起動します。次のコマンドは、Google Distributed Cloud（GDC）のエアギャップ アプライアンスに接続されたお客様のノートパソコンまたはワークステーションではなく、ノードで実行します。

    systemctl stop containerd
systemctl daemon-reload
systemctl restart containerd
systemctl stop kubelet
systemctl start kubelet

  10. containerd サービスと kubelet サービスのステータスを確認するには、NotReady ノードで次のコマンドを実行します。

    systemctl status kubelet
systemctl status containerd

    出力は次のようになります。

    # systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
Loaded: loaded (/usr/lib/systemd/system/kubelet.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/kubelet.service.d
        └─00-standalone_containerd.conf, 10-kubeadm.conf
Active: active (running) since Thu 2025-03-27 07:58:27 UTC; 34s ago
.
.
.

# systemctl status containerd
● containerd.service - containerd container runtime
Loaded: loaded (/etc/systemd/system/containerd.service; disabled; vendor preset: disabled)
Active: active (running) since Thu 2025-03-27 07:58:17 UTC; 52s ago
.
.
.

    再起動後に containerd サービスと kubelet サービスが正常に動作している場合は、調整が完了するまで 2 時間待ちます。