本页介绍如何关停和启动 Google Distributed Cloud (GDC) 气隙设备。例如:将设备移至新位置。
您可能会在临时运营地点使用 GDC 气隙设备,在这种情况下,您需要关停设备以进行运输,以便在不同地点之间移动设备。您可能还需要从电源故障中恢复设备,因为在恶劣的环境中,发电机可能会为设备供电。
准备工作
请确保在继续操作之前停止所有工作负载。如果工作负载在关停期间处于活跃状态,Google 无法保证会发生什么情况。
前提条件
- 您可以在连接到 Google Distributed Cloud (GDC) 气隙设备网络的笔记本电脑或工作站上执行此 Runbook。或者,您可以按照连接设备中的说明将笔记本电脑或工作站连接到交换机。
- 确保您有权访问根管理员集群的 kubeconfig。
- 通过运行
export KUBECONFIG=PATH_TO_KUBECONFIG设置正确的 KUBECONFIG 环境变量。 - 确保您拥有 SSH 密钥和证书。
关停刀片服务器
运行
kubectl get nodes -A -o wide获取节点信息。通过 为所有节点 逐个运行以下命令来暂停 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获取 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 和密码。
逐个封锁所有节点:
kubectl cordon NODE_NAME输出可能如下所示:
node/**-**-bm01 cordoned node/**-**-bm02 cordoned node/**-**-bm03 cordoned关闭 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 *如需确定 etcd 领导者节点和跟随者节点,请为所有节点逐个运行此步骤:
通过记下
kubectl get nodes -A -o wide输出的INTERNAL-IP列下的值,找到用于 SSH 的目标 IP。建立 SSH 连接:ssh root@INTERNAL-IP如需确定当前节点是 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 跟随者节点,输出可能如下所示:
[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 领导者和 etcd 跟随者状态。
排空两个 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 . . .正常关停两个 etcd 跟随者节点。为这两个节点 逐个 执行下一步。
使用 iLO 关闭
NODE_NAME:检索 iLO 的用户名:
kubectl get secret bmc-credentials-NODE_NAME -n gpc-system -o jsonpath="{.data.username}" | base64 --decode检索 iLO 的密码:
kubectl get secret bmc-credentials-NODE_NAME -n gpc-system -o jsonpath="{.data.password}" | base64 --decode从
BMC-IP列的值中检索NODE_NAME的BMC-IP地址:kubectl get servers -A访问在上一步中获取的
BMC-IP地址,然后输入获取的用户名和密码进行登录。将鼠标悬停在顶行中的第一个按钮上。它应显示
Power: ON。点击该按钮。系统会显示一个下拉菜单,点击标记为Momentary Press的第一个项。按钮颜色将从绿色变为橙色,表示节点正在关停。等待按钮颜色变为黄色,表示机器已关机。这需要几分钟时间。
在两个 etcd 跟随者节点都关停后,最后对 etcd 领导者节点重复第 7 步。
移除 YubiKey 以进行运输
如果您需要在安装完成后运输系统,请移除 YubiKey 并单独运输 YubiKey。确保您自行标记密钥。
启动并连接
如果电源意外丢失(例如硬关停),设备会自动恢复。在这种情况下,您应从第 7 步开始,跳过第 1 步到第 6 步。意外断电后,即使重新启动,您也可能会丢失数据。
行动计划
在每个节点中插入 YubiKey。
将 GDC 气隙设备机器插入电源,然后按节点
**-**-bm03上的电源按钮以启动 OTS 中介服务器。在节点
**-**-bm03可用后,通过检查 SCSI 目标子系统 (SCST) 服务的状态来验证 OTS 中介服务器是否处于活跃状态。此服务应显示Active: active (running):sudo systemctl status scst.service按任意顺序按其余两个节点上的电源按钮。
节点启动后,等待几分钟,让控制平面连接。
kubectl可以在 30 分钟内连接到控制平面。运行
kubectl get nodes -A获取节点名称。取消封锁每个节点以启用调度:
kubectl uncordon `NODE_NAME`恢复每个节点的裸金属主机同步:
kubectl annotate bmhost -n gpc-system NODE_NAME "baremetalhost.metal3.io/paused=false" --overwrite使用
kubectl get nodes -A检查节点的状态。如果所有节点都处于
Ready状态,请等待两个小时,让协调流程完成。输出可能如下所示: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在这种情况下,无需执行任何进一步的操作。
否则,如果一个或多个节点处于“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在这种情况下,请记下未就绪的节点的名称,然后继续执行后续步骤。
建立与
NotReady节点的 SSH 连接。SSH 的目标 IP 地址是kubectl get nodes -A -o wide输出的INTERNAL-IP列下的值:ssh root@INTERNAL-IP在
NotReady节点上重启containerd和kubelet服务。以下命令将在节点上运行,而不是在连接到 Google Distributed Cloud (GDC) 气隙设备的客户笔记本电脑或工作站上运行:systemctl stop containerd systemctl daemon-reload systemctl restart containerd systemctl stop kubelet systemctl start kubelet如需验证
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服务在重启后运行正常,请等待两个小时,让对账完成。