Arrestare e accendere il dispositivo

Questa pagina descrive come spegnere e accendere l'appliance con air gap di Google Distributed Cloud (GDC). Ad esempio, per spostare il dispositivo in una nuova posizione.

Potresti utilizzare l'appliance GDC air-gapped in posizioni operative temporanee, dove è necessario spegnere il dispositivo per il trasporto per spostarlo tra le posizioni. Potresti anche dover ripristinare il dispositivo in seguito a un'interruzione dell'alimentazione, poiché i generatori potrebbero alimentarlo in ambienti difficili.

Prima di iniziare

Assicurati di arrestare tutti i carichi di lavoro prima di procedere. Google non può garantire cosa succederà se i carichi di lavoro sono attivi durante un arresto.

Prerequisiti

  1. Puoi eseguire questo runbook su un laptop o una workstation connessi alla rete dell'appliance air-gapped di Google Distributed Cloud (GDC). In alternativa, puoi connettere un laptop o una workstation allo switch seguendo la procedura descritta in Connettere il dispositivo.
  2. Assicurati di avere accesso al file kubeconfig per il cluster root-admin.
  3. Imposta la variabile di ambiente KUBECONFIG corretta eseguendo export KUBECONFIG=PATH_TO_KUBECONFIG.
  4. Assicurati di avere la chiave e il certificato SSH.

Arresta le lame

  1. Ottieni informazioni sui nodi eseguendo kubectl get nodes -A -o wide.

  2. Metti in pausa la sincronizzazione di BareMetalHost eseguendo il seguente comando per tutti i nodi uno alla volta.Sostituisci NODE_NAME con i nomi dei nodi ottenuti nel passaggio 1:

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

    L'output potrebbe essere simile a questo esempio:

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

  3. Isola tutti i nodi uno alla volta:

    kubectl cordon NODE_NAME

    L'output potrebbe essere simile a questo esempio:

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

  4. Per determinare il nodo leader etcd e i nodi follower, esegui questo passaggio uno alla volta per tutti i nodi:

    1. Trova gli IP di destinazione per SSH annotando i valori nella colonna INTERNAL-IP dell'output di kubectl get nodes -A -o wide. Stabilisci una connessione SSH:

      ssh root@INTERNAL-IP

    2. Per determinare se il nodo corrente è il leader o il follower di etcd, esegui il seguente comando nel terminale 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

      Presta attenzione al campo IS LEADER.

      L'output potrebbe essere simile a questo esempio per il nodo 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 |        |
+----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+

      L'output potrebbe essere simile a questo esempio per i due nodi follower 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 |        |
+----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+

      Prendi nota dello stato di etcd-leader e etcd-follower dei nodi.

  5. Svuota i due nodi follower etcd. Non svuotare il nodo leader etcd.

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

    L'output potrebbe essere simile al seguente:

    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. Arresta normalmente i due nodi follower etcd. Segui il passaggio successivo uno alla volta per entrambi i nodi.

  7. Disattiva NODE_NAME utilizzando iLO:

    1. Recupera il nome utente per iLO:

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

    2. Recupera la password per iLO:

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

    3. Recupera l'indirizzo BMC-IP per NODE_NAME dai valori nella colonna BMC-IP:

      kubectl get servers -A

    4. Visita l'indirizzo BMC-IP ottenuto nel passaggio precedente e accedi inserendo il nome utente e la password ottenuti.

    5. Passa il mouse sopra il primo pulsante nella riga superiore. Dovrebbe visualizzare Power: ON. Fai clic. Viene visualizzato un menu a discesa. Fai clic sul primo elemento etichettato Momentary Press. Il colore del pulsante cambierà da verde ad arancione, il che significa che il nodo si sta spegnendo. Attendi che il colore del pulsante diventi giallo, a indicare che la macchina è spenta. Ci vorranno alcuni minuti.

  8. Dopo aver arrestato entrambi i nodi etcd-follower, ripeti il passaggio 7 per il nodo leader etcd.

Rimuovere le YubiKey per il trasporto

Se devi trasportare il sistema dopo il completamento dell'installazione, rimuovi le YubiKey e trasportale separatamente. Assicurati di taggare tu stesso le chiavi.

Accendere e connettersi

Se l'alimentazione è stata interrotta in modo imprevisto, ad esempio un arresto forzato, il dispositivo si riavvia automaticamente. In questo caso, devi iniziare dal passaggio 7, saltando i passaggi da 1 a 6. Dopo un'interruzione di corrente imprevista, potresti riscontrare una perdita di dati, anche dopo il riavvio.

Piano d'azione

  1. Inserisci le yubikey in ogni nodo.

  2. Collega la macchina appliance GDC air-gapped all'alimentazione e premi il tasto di accensione su ciascun nodo in qualsiasi ordine.

  3. Dopo l'accensione dei nodi, attendi qualche minuto per la connessione del control plane. kubectl può connettersi al control plane in meno di 30 minuti.

  4. Recupera i nomi dei nodi eseguendo kubectl get nodes -A.

  5. Rimuovi il cordone da ogni nodo per abilitare la pianificazione:

    kubectl uncordon `NODE_NAME`

  6. Riprendi la sincronizzazione degli host bare metal per ogni nodo:

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

  7. Controlla lo stato dei nodi utilizzando kubectl get nodes -A.

    • Se tutti i nodi sono in stato Ready, attendi due ore per il completamento del processo di riconciliazione. L'output potrebbe essere simile al seguente:

      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

      In questo caso non sono necessarie ulteriori azioni.

    • In caso contrario, se uno o più nodi sono nello stato "NotReady", riavvia alcuni servizi per preparare il cluster. L'output potrebbe essere simile al seguente:

      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

      In questo caso, annota il nome del nodo non pronto e procedi con i passaggi successivi.

  8. Stabilisci una connessione SSH al nodo NotReady. Gli indirizzi IP di destinazione di SSH sono i valori della colonna INTERNAL-IP dell'output di kubectl get nodes -A -o wide:

    ssh root@INTERNAL-IP

  9. Riavvia i servizi containerd e kubelet sul nodo NotReady. I seguenti comandi devono essere eseguiti sui nodi, non sul laptop o sulla workstation del cliente connessi all'appliance air-gap di Google Distributed Cloud (GDC):

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

  10. Per verificare lo stato dei servizi containerd e kubelet, esegui i seguenti comandi sul nodo NotReady:

    systemctl status kubelet
systemctl status containerd

    L'output potrebbe essere simile al seguente:

    # 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
.
.
.

    Se i servizi containerd e kubelet funzionano correttamente dopo il riavvio, attendi due ore per il completamento della riconciliazione.