Upgrade-Phase: AnthosBareMetal

In dieser Phase werden die Kubernetes-Version und die Add-ons für einen Kubernetes-Cluster aktualisiert. In dieser Phase wird auch die Upgrade-Aufgabe mz-location-upgrade ausgeführt.

Das Cluster-Upgrade wird jeweils auf einem Knoten des Clusters durchgeführt. Die allgemeinen Schritte für das Cluster-Upgrade sind:

  1. Es werden Preflight-Prüfungen ausgeführt, um sicherzustellen, dass der Knoten für das Upgrade bereit ist.
  2. Der Knoten wird entleert, um das Upgrade vorzubereiten.
  3. Die Kubernetes-Version auf dem Knoten wird aktualisiert.
  4. Nach dem Upgrade werden Prüfungen durchgeführt, um sicherzustellen, dass das Knoten-Upgrade erfolgreich war.
  5. Die InventoryMachine-Ressource für den Knoten wird aus maintenance entfernt. Dadurch kann der Knoten wieder Pods annehmen.

Knoten per Drain beenden

Beim Entleeren eines Knotens werden alle auf diesem Knoten ausgeführten Arbeitslasten ordnungsgemäß von diesem Knoten entfernt. Sie umfasst die folgenden Schritte:

  1. Die InventoryMachine-Ressource für den Knoten befindet sich unter maintenance.
  2. Die BaremetalMachine-Ressource wird unter maintenance platziert.
  3. Der Kubernetes-Knoten ist mit baremetal.cluster.gke.io/maintenance markiert: NoSchedule
  4. Bei Bare-Metal-Knoten werden alle auf dem Knoten ausgeführten virtuellen Maschinen für den Drain vorbereitet, indem InventoryMachine für diese virtuelle Maschine unter maintenance festgelegt wird.
  5. Die auf dem Kubernetes-Knoten ausgeführten Pods werden ordnungsgemäß entfernt. Jeder Pod hat bis zu 80 Minuten Zeit, um ordnungsgemäß beendet zu werden.

kubeconfig-Datei, Clusternamen und Namespace des Administratorclusters abrufen

Um Probleme in dieser Phase zu beheben, benötigen Sie die KUBECONFIG des Administratorclusters sowie den Namen und Namespace des Clusters, für den das Upgrade durchgeführt wird. Legen Sie ORG_NAME auf die Organisation fest, für die Sie das Upgrade überwachen.

export ORG_NAME=ORG_NAME

Wählen Sie je nach Cluster, der im Namen der Phase angegeben ist, eine der folgenden Optionen aus.

  1. Stagename: root-admin/AnthosBareMetal

    export ADMIN_KUBECONFIG=ROOT_ADMIN_KUBECONFIG
export CLUSTER_NAME="root-admin"
export CLUSTER_NAMESPACE="root"

  2. Phasenname: org-admin/AnthosBareMetal

    export ADMIN_KUBECONFIG=ROOT_ADMIN_KUBECONFIG
export CLUSTER_NAME="${ORG_NAME}-admin"
export CLUSTER_NAMESPACE="${ORG_NAME}"

  3. Phase: system/AnthosBareMetal

    export ADMIN_KUBECONFIG=ORG_ADMIN_KUBECONFIG
export CLUSTER_NAME="${ORG_NAME}-system"
export CLUSTER_NAMESPACE="${CLUSTER_NAME}-cluster"

  4. Staging-Name: service/AnthosBareMetal

    export ADMIN_KUBECONFIG=ORG_ADMIN_KUBECONFIG
export CLUSTER_NAME="g-${ORG_NAME}-shared-service"
export CLUSTER_NAMESPACE="${CLUSTER_NAME}-cluster"

  5. Nutzercluster-Upgrade

    export ADMIN_KUBECONFIG=ORG_ADMIN_KUBECONFIG
export CLUSTER_NAME=USER_CLUSTER_NAME
export CLUSTER_NAMESPACE="${CLUSTER_NAME}-cluster"

Zu überwachende Ressourcen

  1. ABM-Clusterressource clusters.baremetal.cluster.gke.io 

      kubectl get cluster -n "${CLUSTER_NAMESPACE}" "${CLUSTER_NAME}" --kubeconfig=${ADMIN_KUBECONFIG}

    Beispielausgabe

    NAME         ABM VERSION       DESIRED ABM VERSION   CLUSTER STATE
root-admin   1.29.400-gke.86   1.29.400-gke.86       Running

  2. ABM-BaremetalMachine-Ressourcen

      kubectl get baremetalmachines -n "${CLUSTER_NAMESPACE}" --kubeconfig=${ADMIN_KUBECONFIG}

    Beispielausgabe

    NAME       CLUSTER      READY   INSTANCEID             MACHINE    ABM VERSION       DESIRED ABM VERSION
10.8.0.2   root-admin   true    baremetal://10.8.0.2   10.8.0.2   1.29.400-gke.86   1.29.400-gke.86
10.8.0.3   root-admin   true    baremetal://10.8.0.3   10.8.0.3   1.29.400-gke.86   1.29.400-gke.86
10.8.0.4   root-admin   true    baremetal://10.8.0.4   10.8.0.4   1.29.400-gke.86   1.29.400-gke.86

    Wenn auf einem Computer ABM VERSION von DESIRED ABM VERSION abweicht oder READY nicht gleich true ist, verwenden Sie das Flag -o yaml, um weitere Details zum Computer zu erhalten.

  3. HealthChecks, wenn ein Knoten nicht in den Wartungsmodus wechseln oder den Wartungsmodus verlassen kann.

      export MACHINE_IP=MACHINE_IP
  kubectl get healthchecks -n kube-system --kubeconfig=${ADMIN_KUBECONFIG}

    Beispielausgabe

    NAMESPACE     NAME                                                 COMPONENT   NAMESPACE   STATUS    LAST_COMPLETED
kube-system   bm-system-10.8.0.2-machine                                                   Healthy   14m
kube-system   bm-system-10.8.0.3-machine                                                   Healthy   14m
kube-system   bm-system-10.8.0.4-machine                                                   Healthy   5m43s
kube-system   bm-system-add-ons-add-ons                                                    Healthy   46m
kube-system   bm-system-add-ons-configdrift                                                Healthy   46m

    Wenn eine Systemdiagnose als fehlerhaft angezeigt wird, verwenden Sie das Flag -o yaml, um Details zu prüfen.

  4. Controller-Logs auf Fehler prüfen

      export MACHINE_IP=MACHINE_IP
  kubectl logs -n kube-system -l baremetal.cluster.gke.io/lifecycle-controller-component=true | grep ${MACHINE_IP}
  kubectl logs -n capi-system -l baremetal.cluster.gke.io/lifecycle-controller-component=true | grep ${MACHINE_IP}

  5. Prüfen Sie, ob in dieser Phase Upgradeaufgaben ausgeführt werden oder fehlgeschlagen sind.

    export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl get upgradetaskrequests -n gpc-system -o json | jq '.items[] | select(.status.conditions[].status=="Unknown") | .metadata.name'

    Beispielausgabe

    "upg-task-org-1-os-node-upgrade-task-whg8v"

    export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
export UPGRADE_TASK=$(kubectl get upgradetaskrequests -n gpc-system -o json | jq -r '.items[] | select(.status.conditions[].status=="Unknown") | .metadata.name')
kubectl get upgradetaskrequests -n gpc-system "${UPGRADE_TASK}" -o yaml

    Beispielausgabe

    status:
  conditions:
  - lastTransitionTime: "2024-09-25T16:26:33Z"
    message: job gpc-system/v1.13.0-os-7cf810d7a5-upg-task-org-1-os-node-upgra-4n5t6
      is running
    observedGeneration: 1
    reason: JobRunning
    status: Unknown
    type: Succeeded
  upgradeTaskResponse:
    name: upg-task-org-1-os-node-upgrade-task-whg8v-v1.13.0-os-7cf810d7a5

    Wenn Sie einen laufenden Job in der Ausgabe sehen, können Sie den Job beschreiben oder die Pod-Logs auf Fehler prüfen.