Étape de mise à niveau : AnthosBareMetal

Cette étape met à niveau la version de Kubernetes et les modules complémentaires d'un cluster Kubernetes. Cette étape exécute également une tâche de mise à niveau mz-location-upgrade.

La mise à niveau du cluster est effectuée sur un nœud du cluster à la fois. Voici les grandes étapes de la mise à niveau du cluster :

  1. Des vérifications préliminaires sont exécutées pour s'assurer que le nœud est prêt pour la mise à niveau.
  2. Le nœud est drainé pour préparer la mise à niveau
  3. La version de Kubernetes sur le nœud est mise à niveau.
  4. Des vérifications post-vol sont effectuées pour s'assurer que la mise à niveau du nœud a réussi.
  5. La ressource InventoryMachine du nœud est supprimée de maintenance. Le nœud peut ainsi à nouveau accepter les pods.

Processus de drainage des nœuds

La vidange d'un nœud consiste à déplacer progressivement toutes les charges de travail qui y sont exécutées. Voici les étapes à suivre :

  1. La ressource InventoryMachine du nœud est placée sous maintenance.
  2. La ressource BaremetalMachine est placée sous maintenance.
  3. Le nœud Kubernetes est contaminé par baremetal.cluster.gke.io/maintenance : NoSchedule
  4. Pour les nœuds Bare Metal, toutes les machines virtuelles exécutées sur le nœud sont préparées pour la vidange en définissant InventoryMachine pour cette machine virtuelle sous maintenance.
  5. Les pods s'exécutant sur le nœud Kubernetes sont évincés de manière optimale. Chaque pod dispose d'un délai de grâce de 80 minutes pour s'arrêter.

Obtenir le fichier kubeconfig, le nom et l'espace de noms du cluster d'administrateur

Pour trier les problèmes à ce stade, vous avez besoin du KUBECONFIG du cluster d'administrateur, ainsi que du nom et de l'espace de noms du cluster en cours de mise à niveau. Définissez ORG_NAME sur l'organisation pour laquelle vous surveillez la mise à niveau.

export ORG_NAME=ORG_NAME

Sélectionnez l'une des options suivantes en fonction du cluster spécifié dans le nom de l'étape.

  1. Nom de l'étape : root-admin/AnthosBareMetal

    export ADMIN_KUBECONFIG=ROOT_ADMIN_KUBECONFIG
    export CLUSTER_NAME="root-admin"
    export CLUSTER_NAMESPACE="root"
    
  2. Nom de l'étape : org-admin/AnthosBareMetal

    export ADMIN_KUBECONFIG=ROOT_ADMIN_KUBECONFIG
    export CLUSTER_NAME="${ORG_NAME}-admin"
    export CLUSTER_NAMESPACE="${ORG_NAME}"
    
  3. Nom de l'étape : system/AnthosBareMetal

    export ADMIN_KUBECONFIG=ORG_ADMIN_KUBECONFIG
    export CLUSTER_NAME="${ORG_NAME}-system"
    export CLUSTER_NAMESPACE="${CLUSTER_NAME}-cluster"
    
  4. Nom de l'étape : service/AnthosBareMetal

    export ADMIN_KUBECONFIG=ORG_ADMIN_KUBECONFIG
    export CLUSTER_NAME="g-${ORG_NAME}-shared-service"
    export CLUSTER_NAMESPACE="${CLUSTER_NAME}-cluster"
    
  5. Migration des clusters d'utilisateur

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

Ressources à surveiller

  1. Ressource de cluster ABM clusters.baremetal.cluster.gke.io

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

    Exemple de résultat

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

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

    Exemple de résultat

    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
    

    Si une machine affiche une valeur ABM VERSION différente de DESIRED ABM VERSION ou READY différente de true, utilisez l'indicateur -o yaml pour obtenir plus de détails sur la machine.

  3. HealthChecks si un nœud ne parvient pas à passer en mode maintenance ou à en sortir.

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

    Exemple de résultat

    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
    

    Si une vérification de l'état indique que l'état n'est pas sain, utilisez l'indicateur -o yaml pour obtenir plus d'informations.

  4. Journaux du contrôleur à vérifier pour détecter les erreurs

      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. Recherchez les tâches de mise à niveau en cours ou ayant échoué à cette étape.

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

    Exemple de résultat

    "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 
    

    Exemple de résultat

    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
    

    Si une tâche en cours s'affiche dans le résultat, vous pouvez la décrire ou vérifier les journaux du pod pour détecter les erreurs.