关闭并开启设备

本页面介绍如何关闭和启动 Google Distributed Cloud (GDC) 空气隔离设备。例如:将设备移至新位置。

您可能会在临时运营地点使用 GDC 网闸隔离配置设备,在这种情况下,必须关闭设备才能在不同地点之间运输设备。您可能还需要从电源故障中恢复设备,因为发电机可能会在恶劣的环境中为设备供电。

准备工作

请确保先停止所有工作负载,然后再继续操作。如果工作负载在关机期间处于活跃状态,Google 无法保证会发生什么情况。

前提条件

  1. 您可以在连接到 Google Distributed Cloud (GDC) 经过网闸隔离的设备的网络的笔记本电脑或工作站上执行此操作手册。或者,您也可以按照连接设备中的说明将笔记本电脑或工作站连接到交换机。
  2. 确保您有权访问根管理员集群的 kubeconfig。
  3. 运行 export KUBECONFIG=PATH_TO_KUBECONFIG,设置正确的 KUBECONFIG 环境变量。
  4. 确保您拥有 SSH 密钥和证书。

关闭刀片

  1. 运行 kubectl get nodes -A -o wide 可获取节点信息。

  2. 通过逐一运行以下命令(针对所有节点)来暂停 BareMetalHost 同步。将 NODE_NAME 替换为在上一步中获得的节点名称:

    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. 获取 ONTAP Select (OTS) 凭据。您需要这些凭据才能在稍后关闭 OTS 节点。

    运行以下命令,确定 MGMTIP(管理 IP)列下列出的 OTS 管理 IP 地址:

     export KUBECONFIG=/root/release/root-admin/kube-admin-remote-kubeconfig
    
     kubectl get storagecluster -n gpc-system
    

    运行以下命令以检索 OTS 管理员密码:

     export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig
    
     # Find the secret name
     SECRET_NAME=$(kubectl get secrets -n gpc-system -o name | grep 'ontap-.*-stge01-credential')
    
     # Decode the password from that secret
     OTS_PASSWORD=$(kubectl get $SECRET_NAME -n gpc-system -o jsonpath='{.data.netapp_password}' | base64 --decode)
    
     echo $OTS_PASSWORD
    

    保存 OTS 管理 IP 和密码。

  4. 逐个封锁所有节点:

    kubectl cordon NODE_NAME
    

    输出可能如下所示:

    node/**-**-bm01 cordoned
    node/**-**-bm02 cordoned
    node/**-**-bm03 cordoned
    
  5. 关闭 ONTAP Select (OTS) 节点

    使用您检索到的管理 IP 地址和管理员密码,与 OTS 集群建立 SSH 连接:

     ssh admin@<ots-management-ip>
    

    关闭 OTS 节点(虚拟机)。下面给出了一个示例:

     bn-aa-stge01::> cluster show
     Node                  Health  Eligibility
     --------------------- ------- ------------
     bn-aa-stge01-01       true    true
     bn-aa-stge01-02       true    true
    
     bn-aa-stge01::> set diag
    
     Warning: These diagnostic commands are for use by NetApp personnel only.
     Do you want to continue? {y|n}: y
    
     bn-aa-stge01::> system node halt -node *
    
  6. 为防止 Gatekeeper webhook 在其 pod 离线时阻止节点排空,请暂时将其失败政策设置为 Ignore:

    kubectl patch validatingwebhookconfiguration gatekeeper-validating-webhook-configuration -p '{"webhooks":[{"name":"validation.gatekeeper.sh","failurePolicy":"Ignore"}]}'
    
  7. 如需确定 etcd 领导者节点和跟随者节点,请针对所有节点逐一运行此步骤:

    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 |        |
      +----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+
      

      对于两个 etcd follower 节点,输出可能如下例所示:

      [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 状态。

  8. 排空节点。

    排空两个 etcd follower 节点。不要排空 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
    .
    .
    .
    
  9. 正常关停两个 etcd follower 节点。请为两个节点逐一执行后续步骤。

  10. 使用 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 的第一个项目。按钮颜色将从绿色变为橙色,表示节点正在关闭。等待按钮变为黄色,表示设备已关机。这需要几分钟时间。

  11. 在两个 etcd-follower 节点都关闭后,最后重复该步骤,对 etcd leader 节点排空节点。

移除用于传输的 Yubikey

如果需要在安装完成后运输系统,请移除 Yubikey 并单独运输。确保您自行标记密钥。

开机并连接

如果设备意外断电(例如硬关机),会自动恢复运行。在这种情况下,您可以跳过开启设备并连接设备的步骤,直接从解除每个节点的隔离状态这一步开始操作。在意外断电后,即使重新启动,您也可能会遇到数据丢失的情况。

行动计划

  1. 在每个节点中插入 YubiKey。

  2. 将 GDC 空气隔离设备机器插入电源,然后按节点 **-**-bm03 上的电源按钮启动 OTS 中介服务器。

  3. 在节点 **-**-bm03 可用后,通过检查 SCSI 目标子系统 (SCST) 服务的状态来验证 OTS 中介服务器是否处于活跃状态。此服务应显示 Active: active (running):

    sudo systemctl status scst.service
    
  4. 按任意顺序按下剩余两个节点的电源按钮。

  5. 节点启动后,等待几分钟,让控制平面连接。kubectl 可以在 30 分钟内连接到控制平面。

  6. 运行 kubectl get nodes -A 可获取节点的名称。

  7. 取消封锁每个节点以启用调度:

    kubectl uncordon NODE_NAME
    
  8. 恢复每个节点的裸金属主机的同步:

    kubectl annotate bmhost -n gpc-system NODE_NAME "baremetalhost.metal3.io/paused=false" --overwrite
    
  9. 将 Gatekeeper 验证 webhook 配置恢复为 Fail,以恢复集群安全政策:

    kubectl patch validatingwebhookconfiguration gatekeeper-validating-webhook-configuration -p '{"webhooks":[{"name":"validation.gatekeeper.sh","failurePolicy":"Fail"}]}'
    
  10. 使用 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
    

    在这种情况下,您无需采取进一步行动。

  11. 如果一个或多个节点处于 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
    
    1. 建立与 NotReady 节点的 SSH 连接。SSH 的目标 IP 地址是 kubectl get nodes -A -o wide 输出中 INTERNAL-IP 列下的值:

      ssh root@INTERNAL-IP
      
    2. 在 NotReady 节点上重启 containerd 和 kubelet 服务。在节点上运行以下命令,不要在连接到 GDC 网闸隔离配置设备的笔记本电脑或工作站上运行:

      systemctl stop containerd
      systemctl daemon-reload
      systemctl restart containerd
      systemctl stop kubelet
      systemctl start kubelet
      
    3. 在 NotReady 节点上运行以下命令,验证 containerd 和 kubelet 服务的状态:

      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 服务运行且所有节点都处于 Ready 状态后,请等待 2 小时,以便基本堆栈完成协调,然后再进行问题排查。