Arrestare e accendere il dispositivo

Questa pagina descrive come spegnere e accendere l'appliance con air gap 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.

Arrestare 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. Arresta i nodi ONTAP Select (OTS)

    Accedi al cluster OTS

    Esegui questo comando per identificare l'indirizzo IP di gestione OTS elencato nella colonna MGMTIP (Management IP):

     export KUBECONFIG=/root/release/root-admin/kube-admin-remote-kubeconfig

 kubectl get storagecluster -n gpc-system

    Esegui i seguenti comandi per recuperare la password dell'amministratore 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

    Stabilisci una connessione SSH al cluster OTS utilizzando l'IP di gestione e la password amministratore:

     ssh admin@<ots-management-ip>

    Arresta i nodi OTS (VM). Di seguito è riportato un esempio:

     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 *

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

  6. Svuota i due nodi follower etcd. Non svuota 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
.
.
.

  7. Arresta normalmente i due nodi follower etcd. Segui il passaggio successivo uno alla volta per entrambi i nodi.

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

  9. 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 le chiavi personalmente.

Accensione e connessione

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 sul nodo **-**-bm03 per avviare il server mediatore OTS. Una volta che il nodo è disponibile, verifica che il server intermediario OTS sia attivo controllando lo stato dei servizi intermediario e sottosistema di destinazione SCSI (SCST). Entrambi i servizi devono mostrare Active: active (running):

    systemctl status ontap_mediator mediator-scst

    Poi premi il tasto di accensione sui due nodi rimanenti 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 nello 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 nella 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 isolata 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.