Problèmes connus de Google Distributed Cloud sous air gap 1.13.x

Artifact Registry

Erreur de rapprochement du sous-composant sar-failoverregistry

Versions : 1.13.1, 1.13.3, 1.13.4

Symptômes : lors de la création du cluster d'administrateur racine avec la commande gdcloud system admin-cluster install, l'opération peut échouer si la liste des serveurs est longue lors de l'amorçage. Le message d'erreur est le suivant :

Secret "sar-failoveregistry-backend-parameter" is invalid: data: Too long: must have at most 1048576 bytes

Solution de contournement : pour résoudre ce problème, procédez comme suit :

  1. Dans le même cluster Kubernetes que le sous-composant, listez les serveurs et vérifiez que chaque ressource personnalisée de serveur comporte un libellé dont la clé est cluster.private.gdc.goog/inventory-machine :

    kubectl get servers -n gpc-system

  2. Recherchez la ressource personnalisée du composant qui ressemble à ce qui suit :

      apiVersion: lcm.private.gdc.goog/v1
  kind: Component
  metadata:
    creationTimestamp: "2025-01-06T12:00:41Z"
    generation: 1
    name: sar-v1.14.2-sar-acbf97caf6
    resourceVersion: "3199"
    uid: 681ec5cb-9eb3-423b-ac1d-f6aa27abfd75
  spec:
    name: sar

  3. Dans la ressource personnalisée du composant System Artifact Registry (SAR), ajoutez le sélecteur d'étiquettes dans les serveurs runtimeParameterSources pour sar-failover-registry :

    1. Affichez la ressource server existante :

      servers:
  targetCluster: Local
  object:
    apiVersion: system.private.gdc.goog/v1alpha1
    kind: ServerList
    namespace: gpc-system

    2. Mettez à jour le champ "servers" dans la ressource personnalisée du composant :

      servers:
  targetCluster: Local
  object:
    apiVersion: system.private.gdc.goog/v1alpha1
    kind: ServerList
    namespace: gpc-system
    labelSelector:
      - key: cluster.private.gdc.goog/inventory-machine
        operator: "in"
        strValues:
          - "bm-1"
          - "bm-2"
          - "bm-3"

  4. Vérifiez que les modifications apportées au composant SAR à l'étape précédente sont propagées au sous-composant sar-failverregistry :

    1. Obtenez les détails du composant SAR :

      kubectl get component | grep sar

    2. Obtenez les détails du composant sar-failoverregistry :

      kubectl get subcomponent sar-failoverregistry -n root

      Utilisez l'option -n pour spécifier l'espace de noms.

Sauvegarde et restauration

Échec des instantanés en raison d'un manque d'espace sur le volume

Versions : toutes les versions 1.13.x

Symptômes : un problème intermittent lié à la sauvegarde des volumes persistants peut avoir un impact sur les workflows des tâches de sauvegarde périodiques. Pour certains volumes dont le taux de modification est élevé, les instantanés de volume pris pour les sauvegardes en cours peuvent entraîner un manque d'espace sur le volume, qui est alors placé en mode lecture seule.

Solution de contournement : Pour éviter tout impact potentiel sur les charges de travail de production, suivez les étapes du runbook BACK-R0104. Vous pouvez également supprimer les instantanés accumulés en suivant le runbook BACK-R0106.

Redémarrage des pods de l'agent et du plan de contrôle en raison d'un manque de mémoire

Versions : toutes les versions 1.13.x

Symptômes : les pods de l'agent et du plan de contrôle peuvent redémarrer s'ils manquent de mémoire.

Solution : Augmentez la mémoire des pods du plan de contrôle et de l'agent en suivant les instructions du runbook BACK-R0005. Augmentez la mémoire des pods à 2 Gio.

Échec de la sauvegarde pour l'instantané PVC

Versions : toutes les versions 1.13.x

Problèmes constatés : des échecs de sauvegarde se sont produits en raison du dépassement de la limite de 1 023 instantanés ONTAP par ressource PersistentVolumeClaim (PVC).

Solution de contournement : Pour résoudre ce problème, procédez comme suit :

  1. Mettez à jour le plan de sauvegarde pour que les limites ne soient jamais atteintes. Configurez un plan de sauvegarde pour effectuer une sauvegarde toutes les heures ou réduisez deleteLockDays à trois afin que le nombre d'instantanés ne dépasse pas 1 023 :

    apiVersion: backup.gdc.goog/v1
kind: BackupPlan
metadata:
  name: test-backup-plan
spec:
  clusterName: system-cluster
  backupSchedule:
    cronSchedule: "*/10 * * * *"
    paused: false
  backupConfig:
    backupScope:
      selectedApplications:
        namespacedNames:
        - name: test-protected-application
          namespace: release-namespace
    backupRepository: gdchservices-backup-repository
    includeVolumeData: true
    volumeStrategy: LocalSnapshotOnly
  retentionPolicy:
    backupDeleteLockDays: LOCK_DAYS
    backupRetainDays: RETENTION_DAYS

    Remplacez les éléments suivants :

    • LOCK_DAYS : empêche la suppression de la sauvegarde pendant le nombre de jours spécifié après sa création. Utilisez les valeurs suivantes :

      • Si le champ volumeStrategy est défini sur la valeur LocalSnapshotOnly, utilisez la valeur 2.
      • Si le champ volumeStrategy est défini sur la valeur ProvisionerSpecific, utilisez la valeur 7.

    • RETENTION_DAYS : supprime les sauvegardes après le nombre de jours spécifié après leur création. Si le champ volumeStrategy est défini sur la valeur LocalSnapshotOnly, utilisez une valeur inférieure à 3.

  2. Pour supprimer manuellement les instantanés excessifs de votre environnement à l'aide des commandes de suppression d'instantanés de volumes, procédez comme suit :

    1. Initialisez les variables :

      export RKCNF=/root/release/root-admin/root-admin-kubeconfig
export KCNF=/root/release/org-admin/gdchservices-admin-kubeconfig

export ORG_NAME=ORG_NAME
export PVC=PVC_NAME

      Remplacez les éléments suivants :

      • ORG_NAME : nom de votre organisation.
      • PVC_NAME : nom de la ressource PVC associée au plan de sauvegarde.

    2. NetApp ONTAP est un système d'exploitation utilisé pour administrer le stockage pour GDC. Accéder à ONTAP :

      export USERNAME="$(kubectl --kubeconfig ${RKCNF?} -n gpc-system get
secret storage-root-level1 -o jsonpath='{.data.username}' | base64 -d)"

export MGMT_IP="$(kubectl --kubeconfig ${RKCNF?} get storagecluster -A
-o jsonpath='{.items[0].spec.network.clusterManagement.ip}')"

export PASSWORD="$(kubectl --kubeconfig ${RKCNF?} -n gpc-system get
secret storage-root-level1 -o jsonpath='{.data.password}' | base64 -d)"

echo $PASSWORD

    3. Répertoriez tous les instantanés de la ressource PVC sélectionnée :

      ssh ${USERNAME?}@${MGMT_IP?} "volume snapshot show -vserver ${ORG_NAME?}
-fields volume,snapshot,size,create-time" | grep "snapshot-" >
/tmp/snapshot_unsort.list

      Utilisez le mot de passe de l'étape précédente pour vous connecter à la machine à l'adresse IP définie par la variable MGMT_IP.

    4. Recherchez le PVC avec le nombre d'instantanés le plus élevé :

      grep ${ORG_NAME?} /tmp/snapshot_unsort.list | grep snapshot | awk
'{print $2}' | sort | uniq -c

    5. Définissez le nom de ressource PVC sur celui qui comporte un nombre élevé d'instantanés :

      export PV_NAME=

    6. Supprimez l'instantané de la ressource PVC qui contient un nombre élevé d'instantanés. Le nombre d'instantanés pour une ressource PVC est limité à 1 023 :

      for snap_name in `grep ${ORG_NAME?} /tmp/snapshot_unsort.list | grep
snapshot | grep ${PV_NAME?} | awk '{print $3}'` do
    echo "volume snapshot delete -vserver ${ORG_NAME} -volume ${PV_NAME} -snapshot $snap_name"
    echo "Y"
done

    7. Connectez-vous à ONTAP et exécutez les commandes suivantes pour supprimer l'instantané :

      echo $PASSWORD

#Use this password to login to ontap
ssh ${username?}@${mgmt_ip?}

    8. Exécutez les commandes listées à l'étape précédente pour supprimer l'instantané. Une fois l'opération terminée, quittez la session SSH.

  3. Répétez la procédure de suppression jusqu'à ce que tous les instantanés PVC incriminés soient supprimés.

Restauration à partir d'une sauvegarde incompatible avec le quota SVM

Versions : 1.13.1

Symptômes : le problème est lié à une incompatibilité entre les fonctionnalités NetApp. Cette incompatibilité empêche la livraison du quota de locataire et la bonne implémentation des restaurations. Le problème ne se produit que lors de la restauration d'une sauvegarde dans un cluster d'utilisateur soumis à des quotas.

Solution de contournement : Si ce problème se produit, la restauration échoue et le message d'erreur DP volumes are not supported on storage-limit enabled Vserver s'affiche. L'opérateur d'infrastructure (IO) doit alors désactiver le quota pour ce cluster d'utilisateur et redémarrer le processus de restauration. Une fois la restauration terminée, l'IO doit réactiver les quotas de locataire et le système devrait continuer à fonctionner comme prévu. Pour en savoir plus, consultez le runbook FILE A0030.

Facturation

Les métriques de facturation ne s'affichent pas correctement dans le tableau de bord de facturation

Versions : 1.13.1

Problèmes constatés : les métriques de facturation ne sont pas correctement émises vers le cortex en raison de l'absence de MetricsProxySidecar.

Solution : créez une ressource billing-monetizer MetricsProxySidecar. Exécutez ensuite un script pour mettre à jour le metricExpression.

  1. Exportez la variable kubeconfig suivante :

    export KUBECONFIG=KUBECONFIG_PATH

    Remplacez la variable KUBECONFIG_PATH par le chemin d'accès au fichier kubeconfig du cluster d'administrateur de l'organisation. Suivez les étapes décrites dans le manuel de service IAM-R0101 pour générer le fichier kubeconfig requis pour cette solution de contournement.

  2. Créez une ressource billing-monetizer MetricsProxySidecar pour les espaces de noms billing-system et partner-billing-system :

    Pour billing-system :

    cat <<EOF | kubectl --kubeconfig=$KUBECONFIG apply -n billing-system -f -
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: MetricsProxySidecar
metadata:
  name: billing-monetizer
  namespace: billing-system
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  restartUninjectedPods: true
  restartUnsyncedPods: false
  sources:
  - port: 8080
    scrapeInterval: 60s
  destinations:
  - certificate:
      secretName: billing-monetizer-monitoring-target-infra-obs-cert
    port: 9090
  - certificate:
      secretName: billing-monetizer-monitoring-target-platform-obs-cert
    port: 9091
---
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: MetricsProxySidecar
metadata:
  name: usagemetering
  namespace: billing-system
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  restartUninjectedPods: true
  restartUnsyncedPods: false
  sources:
  - port: 8099
    scrapeInterval: 60s
  destinations:
  - port: 9090
    certificate:
      secretName: bil-usagemetering-monitoring-target-cert
EOF

    Pour partner-billing-system :

    cat <<EOF | kubectl --kubeconfig=$KUBECONFIG apply -n partner-billing-system -f -
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: MetricsProxySidecar
metadata:
  name: billing-monetizer
  namespace: partner-billing-system
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  restartUninjectedPods: true
  restartUnsyncedPods: false
  sources:
  - port: 8080
    scrapeInterval: 60s
  destinations:
  - certificate:
      secretName: billing-monetizer-monitoring-target-infra-obs-cert
    port: 9090
EOF

  3. Exécutez le script suivant pour mettre à jour metricExpression. Cela supprime container_name="monetizer" de skuconfig, y compris billing_total_cost{container_name="monetizer" :

    cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig bc73-b150-e0ea --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"BC4D-B784-EA3C|BC73-B150-E0EA|BD0C-C8CF-658B|BD1A-9464-9DF9|BD5A-044C-4860|BDB4-6C62-00BE|BDB4-BBA6-3EEE|3034-EE51-7404|3160-1596-5D9B|54AD-8EBC-8BB1\"}\n              [{{.Range}}:1m]          )        ) * max(metering_premium_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig bd1a-9464-9df9 --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"BC4D-B784-EA3C|BC73-B150-E0EA|BD0C-C8CF-658B|BD1A-9464-9DF9|BD5A-044C-4860|BDB4-6C62-00BE|BDB4-BBA6-3EEE|3034-EE51-7404|3160-1596-5D9B|54AD-8EBC-8BB1\"}\n              [{{.Range}}:1m]          )        ) * max(metering_enhanced_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig b93c-effb-6d6b --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_premium_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig b871-c5e5-bac1 --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_enhanced_support_base_fee)"
     }
   }
 ]
}'
EOF

cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig ba38-e4be-ba5d --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_enhanced_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig bbe8-7b7a-03de --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_premium_support_base_fee)"
     }
   }
 ]
}'
EOF

L'utilisateur ne parvient pas à créer BillingAccountBinding en raison de bugs dans le webhook de validation

Versions : 1.13.0, 1.13.1, 1.13.3

Symptômes : le bug se trouve dans la logique du webhook de validation BillingAccountBinding. Si un utilisateur tente de créer une ressource BillingAccountBinding, le webhook renvoie l'erreur permission denied.

Solution de contournement : Pour créer des ressources BillingAccountBinding, informez l'opérateur d'infrastructure et créez les ressources correspondantes via IAC.

Stockage de blocs

Les pods Grafana sont bloqués à l'état Init en raison d'erreurs de montage de volume.

Versions : 1.13.3

Symptômes :

Les pods Grafana des espaces de noms anthos-identity-service-obs-system et platform-obs-obs-system sont bloqués à l'état Init en raison d'erreurs d'installation de volume. Le message d'erreur dans les journaux kubelet indique un problème d'attachement multiple. Ce problème est dû à un bug dans Trident, qui ne parvient pas à identifier et à valider correctement l'appareil sous-jacent pour les mappages LUKS, ce qui entraîne une erreur d'attachement multiple.

Solution :

Recherchez un champ "deletionTimestamp" dans la revendication de volume persistant. S'il n'y a pas de deletionTimestamp (migration de pod), procédez comme suit :

  1. Consultez VolumeAttachment pour PVC afin d'identifier l'emplacement actuel du volume.
  2. Isolez les Nodes du cluster qui ne correspondent pas à cette valeur.
  3. Supprimez le Pod défaillant. Il devrait ainsi migrer vers le Node d'origine.

Après vérification, s'il existe un champ "deletionTimestamp" (suppression du volume), procédez comme suit :

  1. Consultez VolumeAttachment pour PVC afin d'identifier l'emplacement actuel du volume.

  2. Sur le Node, affichez le contenu de son fichier de suivi :

    cat /var/lib/trident/tracking/PVC_NAME.json

  3. Vérifiez que l'appareil LUKS trouvé dans le champ devicePath de la sortie du fichier de suivi est bien fermé. Ce chemin d'accès ne devrait pas exister à ce stade :

    stat DEVICE_PATH

  4. Vérifiez si le numéro de série est actuellement mappé à un appareil multipath.

    1. Copiez la valeur du champ iscsiLunSerial du fichier de suivi.

    2. Convertissez cette valeur en valeur hexadécimale attendue :

      echo 'iISCSILUNSERIAL' | xxd -l 12 -ps

    3. Avec cette nouvelle valeur, vérifiez si l'entrée multipath existe toujours :

      multipath -ll | grep SERIAL_HEX

    4. Si ce n'est pas le cas, supprimez le fichier de suivi.

    5. Si elle existe, vous verrez une valeur hexadécimale sérielle légèrement plus longue que celle recherchée, appelée multipathSerial. Exécutez la commande suivante et recherchez les périphériques de bloc :

      multipath -ll MULTIPATH_SERIAL

    6. Exécutez ensuite les commandes suivantes, la dernière étant exécutée uniquement pour chaque périphérique de bloc :

      systemctl restart iscsid
systemctl restart multipathd
multipath -f MULTIPATH_SERIAL
echo 1 > /sys/block/BLOCK_DEVICE_NAME/device/delete

Les pods du lanceur de machine virtuelle ne parviennent pas à mapper les volumes

Versions : 1.13.1

Symptômes :

Un avertissement semblable au suivant peut s'afficher :

 Warning  FailedMapVolume  2m50s (x206 over 13h)  kubelet  MapVolume.SetUpDevice failed for volume "pvc-2a68356a-47da-422b-8781-15e3a6fe7ec9" : rpc error: code = DeadlineExceeded desc = context deadline exceeded

Pour diagnostiquer le problème, procédez comme suit :

  1. Assurez-vous que les volumes et les pods se trouvent sur le même nœud.
  2. Recherchez le nœud sur lequel se trouvent les pods et vérifiez son état.
  3. Vérifiez la connectivité des nœuds.
  4. Vérifiez IPSEC.
  5. Vérifiez le multipath pour voir si un zombie est présent.

  6. Consultez les journaux Trident pour identifier l'étape du flux CSI qui a pu introduire ce zombie :

    kubectl --kubeconfig /root/release/system/org-1-system-cluster logs -n netapp-trident -c trident-main

Solution de contournement : pour contourner ce problème, suivez les étapes des runbooks suivants :

  1. Pour les problèmes concernant les nœuds, consultez le runbook FILE-R0010.
  2. Pour les problèmes liés à IPSEC, consultez le runbook FILE-R0007.
  3. Pour les problèmes liés aux LUN zombies, consultez le runbook FILE-R0020.
  4. Pour les problèmes liés aux LUN super zombie, consultez le runbook FILE-R0021.

Défaillances liées au stockage

Versions : 1.13.1

Symptômes : les échecs liés au stockage peuvent être identifiés par le déclenchement de l'alerte file_block_zombie_luns_present ou par l'échec du démarrage du pod en raison d'un problème dans l'appel MountVolume qui persiste pendant plusieurs boucles de réconciliation. Le délai avant expiration peut être d'environ deux minutes. Une répétition du même échec indique qu'un problème s'est produit dans le chemin d'accès CSI NodeStage ou NodePublish et qu'une solution de contournement est nécessaire. La seule exception concerne l'indication d'un échec de délai d'attente. Vous pouvez rencontrer des échecs comme celui-ci :

NMountVolume.SetUp failed for volume "pvc-a63313b2-3e30-4c92-b074-f9fffe0500a4" : rpc error: code = Internal desc = unable to mount device; exit status 32

MapVolume.SetUpDevice failed for volume "pvc-f594b0c7-a5b5-4a5b-8a53-bf13e95c4bb0" : rpc error: code = Internal desc = rpc error: code = Internal desc = failed to stage volume: multipath device not found when it is expected

MapVolume.SetUpDevice failed for volume "pvc-f594b0c7-a5b5-4a5b-8a53-bf13e95c4bb0" : rpc error: code = Internal desc = rpc error: code = Internal desc = failed to stage volume: failure when reconfiguring multipath

Solution :

  1. Pour voir si le Node qui contient le Pod peut être corrigé pour le PVC défaillant, isolez le nœud actuel sur lequel le pod est planifié et supprimez le Pod :

    KUBECONFIG=CLUSTER_KUBECONFIG kubectl cordon node TARGET_NODE

    Le Pod doit être planifié sur un Node complètement différent, ce qui oblige Trident à exécuter complètement NodeStage, NodePublish, NodeUnpublish et NodeUnstage. Il est possible que le problème de volume ne soit pas résolu immédiatement, car des sessions peuvent encore être ouvertes pour ce volume sur le Node d'origine.

  2. Une fois l'étape précédente terminée, annulez l'isolement du nœud en question :

    KUBECONFIG=CLUSTER_KUBECONFIG kubectl uncordon node TARGET_NODE

  3. Si des échecs sont toujours présents, isolez tous les autres Nodes, à l'exception de celui où le Pod était initialement planifié, puis supprimez le Pod. Cela devrait entraîner le démarrage de Pod sur le Node d'origine, où des appareils existants peuvent encore être présents.

  4. Une fois l'étape précédente terminée, libérez les nœuds concernés.

  5. En dernier recours pour enregistrer le PV et ses données, le Node peut être redémarré pour effacer les échecs multipath, udev et devmapper sur le Node. Bien que cette étape soit plutôt ardue, elle est la plus susceptible de réussir.

  6. Si les mesures d'atténuation précédentes ne permettent pas de résoudre le problème lié au volume, cela signifie que les données ont été corrompues et sont inutilisables. La seule option restante pour poursuivre le comportement prévu du conteneur est de supprimer les échecs PV, PVC et Pod, puis de redémarrer le nœud sur lequel le PV était hébergé. Cette action entraîne une perte complète des données déjà écrites dans le volume.

Volumes persistants créés avec une taille incorrecte

Versions : 1.13.1

Symptômes : les charges de travail avec un volume persistant sont créées avec une taille d'environ 16 Mio trop petite. Si les charges de travail dépendent exactement de la taille annoncée par un volume persistant, la petite différence fait échouer la charge de travail lors de l'expansion ou du provisionnement. Ce problème est plus susceptible de se produire pour les volumes persistants provisionnés avec une classe de stockage standard-block que pour ceux provisionnés avec une classe de stockage standard-rwo. Ce problème peut se produire sur les volumes persistants avec une classe de stockage standard-rwo qui utilisent le mode volumemode:block.

Solution : Allouez un volume persistant d'au moins 16 Mio de plus que ce qui est réellement nécessaire.

Impossible de supprimer la machine virtuelle de stockage

Versions : 1.13.1

Symptômes : l'StorageVirtualMachine peut afficher une erreur semblable à celle-ci :

 Warning  SVMDeletion  27m (x32 over 4h9m)   StorageVirtualMachine  Reconcile error for svm deletion: failed to delete svm: failed to delete svm volumes: failed to call VolumeCollectionGet: error message: "SVM \"org-2-user\" does not exist. "; error target: "svm.name"

Solution : Supprimez le finaliseur de StorageVirtualMachines dans l'espace de noms de l'organisation.

La désactivation d'une organisation ne nettoie pas les ressources

Versions : 1.13.1

Problèmes constatés : lorsque vous désactivez une organisation, certaines ressources StorageVirtualMachines sont conservées, par exemple :

  • Secret gpc-system/org-2-admin-backup-agent-cert-secret
  • Secret gpc-system/org-2-admin-client-cert-secret
  • Secret gpc-system/org-2-admin-server-cert-secret
  • Secret gpc-system/org-2-admin-svm-credential
  • Secret gpc-system/org-2-admin-backup-agent-cert-secret
  • Secret gpc-system/org-2-admin-client-cert-secret
  • Secret gpc-system/org-2-admin-server-cert-secret
  • Secret gpc-system/org-2-admin-svm-credential

Solution : Supprimez ces ressources.

Échec de la réconciliation de la suppression

Versions : 1.13.1

Symptômes : Lorsqu'un StorageVirtualMachine est supprimé avant le nettoyage des clusters qui en dépendent, il est possible de rencontrer un problème lors du nettoyage de certains volumes persistants (VP) des clusters.StorageVirtualMachine Plus précisément, lorsque les PV chiffrés LUKS ne sont pas nettoyés, leur secret empêche la suppression de l'espace de noms dans lequel ils se trouvent. Un avertissement semblable à celui-ci peut s'afficher dans les journaux :

Warning  ReconcileBackoff  5m35s (x6 over 88m)  ClusterLifecycleReconciler  cluster namespace deletion is not completed: deletion is still ongoing for namespace: /g-org-2-shared-service-cluster

Solution : Supprimez le finaliseur des secrets g-luks-gdc-vm-disk-* dans l'espace de noms du cluster de service.

Mise à niveau Bare Metal bloquée

Versions : 1.13.1, 1.13.5, 1.13.6

Symptômes : les tâches Ansible restent bloquées lors de la collecte des faits lorsqu'il existe des LUN zombies. L'exécution de la commande multipath -ll peut entraîner le problème suivant :

3600a098038314955593f574669785635 dm-11 NETAPP,LUN C-Mode
size=1.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- 5:0:0:10 sdaf 65:240 failed faulty running
| `- 6:0:0:10 sdau 66:224 failed faulty running
`-+- policy='service-time 0' prio=0 status=enabled
  |- 7:0:0:10 sdad 65:208 failed faulty running
  `- 8:0:0:10 sdar 66:176 failed faulty running

Le message d'erreur suivant peut également s'afficher :

 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv PLAY [Check inventory] *********************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv TASK [set_fact] ****************************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv Wednesday 03 July 2024  01:39:04 +0000 (0:00:00.018)       0:00:00.018 ********
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv ok: [10.252.151.3]
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv PLAY [Verify inventory]********************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv TASK [assert]******************************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv Wednesday 03 July 2024  01:39:04 +0000 (0:00:00.031)       0:00:00.050 ********
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv ok: [localhost]
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv PLAY [all] *********************************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv TASK [Gathering Facts] *********************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv Wednesday 03 July 2024  01:39:04 +0000 (0:00:00.064)       0:00:00.114 ********

Solution de contournement : Vérifiez la connectivité SSH avec le nœud cible, puis utilisez le runbook suivant : FILE-R0020.

Erreur de pièce jointe multiple Trident

Versions : 1.13.3

Symptômes : Les pods et les PVC peuvent être bloqués sur différents nœuds, le pod étant bloqué en attente de l'initialisation du PVC.

Solution :

  1. Vérifiez si le PVC contient un deletionTimestamp :

    kubectl --kubeconfig KUBECONFIGget pvc -n <namespace> | grep deletionTimestamp

  2. S'il n'y a pas de deletionTimestamp (migration de pod) :

    1. Vérifiez l'objet VolumeAttachment pour le PVC afin d'identifier l'emplacement du volume.
    2. Isolez les nœuds du cluster qui ne correspondent pas à cette valeur.
    3. Supprimez le pod défaillant. Cette action migre le POD vers le nœud d'origine.

  3. Si un deletionTimestamp (suppression de volume) est présent :

    1. Vérifiez l'objet VolumeAttachment pour le PVC afin d'identifier l'emplacement du volume.
    2. Sur le nœud, affichez le contenu de son fichier de suivi, /var/lib/trident/tracking/PVC_NAME.json.
    3. Vérifiez que l'appareil LUKS trouvé dans le champ "devicePath" de la sortie du fichier de suivi est bien fermé. Ce chemin d'accès ne doit pas exister à ce stade : stat DEVICE_PATH. Si le chemin d'accès existe toujours, un autre problème se produit.
    4. Vérifiez si le numéro de série est associé à un appareil multipath.
    5. Copiez la valeur du champ "iscsiLunSerial" du fichier de suivi.
    6. Convertissez cette valeur en valeur hexadécimale attendue : echo ISCSI_LUN_SERIAL | xxd -l 12 -ps
    7. Avec cette nouvelle valeur, vérifiez si l'entrée multipath existe toujours : multipath -ll | grep SERIAL_HEX.
    8. Si ce n'est pas le cas, supprimez le fichier de suivi.

    9. Si elle existe, vous verrez une valeur hexadécimale sérielle légèrement plus longue que celle que vous avez recherchée. Notez cette valeur sous la forme MULTIPATH_SERIAL. Exécutez multipath -ll MULTIPATH_SERIAL. Un message semblable à celui-ci s'affiche :

      3600a09803831486f2d24575445314678 dm-32 NETAPP,LUN C-Mode
size=8.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 1:0:0:12 sde  8:64   active ready running
| `- 2:0:0:12 sdt  65:48  active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  |- 3:0:0:12 sdbc 67:96  active ready running
  `- 4:0:0:12 sdbe 67:128 active ready running

    10. Exécutez les commandes suivantes :

      1. systemctl restart iscsid
      2. systemctl restart multipathd
      3. multipath -f MULTIPATH_SERIAL
      4. echo 1 > /sys/block/BLOCK_DEVICE_NAME/device/delete

    11. Exécutez la dernière commande de manière unique pour chaque périphérique de bloc.

Erreur de configuration d'IPsec

Versions : 1.13.4

Symptômes : la configuration IPsec ONTAP rencontre une erreur en raison d'une clé pré-partagée (PSK) non valide contenant 0X, qui est interprétée comme une chaîne hexadécimale.

Un avertissement semblable au suivant peut s'afficher :

Warning  ONTAPIPSecConfiguration  3m47s (x22 over 75m)  StorageEncryptionConnection  Reconcile error on ONTAP IPSec configuration: failed to call IpsecPolicyCreateDefault: error message: "The specified pre-shared key \"0XxBDkG8iHoAlOc
nCUfHl0AKYzClgGCH\" is not valid because it is not a valid hexadecimal string."; error target: ""

Solution :

  1. Obtenez les connexions de chiffrement du stockage :

    kubectl get  Storageencryptionconnections --kubeconfig ROOT_ADMIN_KUBECONFIG

    Recherchez l'entrée avec Ready=False et notez le nom de l'PRESHAREKEY. Le résultat peut ressembler à l'exemple suivant :

    NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR        PRESHAREDKEY                 READY   AGE
vm-5a77b2a2   vm-5a77b2a2        gpu-org-user            192.0.2.0/27   vm-5a77b2a2-pre-shared-key   False   26h

  2. Cette machine exécute une organisation GPU. Supprimez donc secrets gpc-system/vm-5a77b2a2-pre-shared-key dans gpu-org-admin.

  3. Attendez que le système recrée secret/vm-5a77b2a2-pre-shared-key.

  4. Recherchez un job avec un modèle tel que gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2. Notez que les huit derniers caractères sont générés de manière aléatoire. Une fois la clé à nouveau disponible, supprimez le job, par exemple jobs gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2m8xdl dans gpu-org-admin.

La machine virtuelle de stockage n'est pas créée

Versions : 1.13.5

Problèmes constatés : le service Harbor sur gpu-org ne démarre pas en raison d'un problème lié aux volumes de provisionnement. Ce problème est dû au fait que le pod file-storage-backend-controller fait référence à une machine d'inventaire inexistante.

Un message d'erreur de contrôleur de stockage semblable à celui-ci peut s'afficher, indiquant que InventoryMachine est introuvable :

{"ts":1730135301218.1772,"caller":"controller/controller.go:329","msg":"Reconciler error","controller":"StorageEncryptionConnectionGenerator","controllerGroup":"baremetal.cluster.gke.io","controllerKind":"InventoryMachine","InventoryMachine":{"n
ame":"vm-26c89d33","namespace":"@org-1/org-1-admin"},"namespace":"@org-1/org-1-admin","name":"vm-26c89d33","reconcileID":"48ab38a8-385d-4fdb-bd7e-1212f287379c","err":"InventoryMachine.baremetal.cluster.gke.io \"vm-26c89d33\" not found"}

Solution :

  1. Supprimez le pod file-storage-backend-controller.
  2. Laissez le contrôleur de stockage récupérer à nouveau les machines d'inventaire présentes.

Échec de la réconciliation des réseaux interclusters de stockage

Versions : 1.13.5, 1.13.6

Symptômes : après une mise à niveau, la ressource personnalisée StorageCluster dans le cluster d'administrateur racine ne devient pas prête en raison d'une erreur de configuration dans les sous-réseaux inter-clusters de la spécification. Le cluster de stockage signale Not Ready et inclut un événement avec cette erreur :

Reconciler error: failed to configure additional networks: failed to configure intercluster LIF: the \"\" Kind is not currently supported

Si cette erreur se produit, cela signifie que la revendication de sous-réseau intercluster utilisée par le cluster de stockage n'inclut pas le champ kind dans la référence. En inspectant la ressource personnalisée StorageCluster, vous trouverez une référence de revendication de sous-réseau intercluster avec uniquement un nom et un espace de noms, comme ceci :

spec:
  additionalNetworks:
  - destinationSubnets:
    - 10.252.112.0/20
    name: backup-agent-storage-network
    port: a0a
    subnetConfig:
      subnetClaimRef:
        name: file-block-storage-intercluster-lif-subnet
        namespace: root
    types:
    - BackupAgent

Solution : Mettez à jour la spécification StorageCluster pour inclure le champ kind: SubnetClaim dans la référence de revendication de sous-réseau :

spec:
  additionalNetworks:
  - destinationSubnets:
    - 10.252.112.0/20
    name: backup-agent-storage-network
    port: a0a
    subnetConfig:
      subnetClaimRef:
        kind: SubnetClaim
        name: file-block-storage-intercluster-lif-subnet
        namespace: root
    types:
    - BackupAgent

Après avoir mis à jour la spécification StorageCluster, redémarrez le déploiement file-storage-backend-controller et vérifiez que le cluster de stockage est prêt.

Gestion des clusters

Échec du job machine-init lors du provisionnement du cluster

Versions : 1.13.1

Symptômes :

  1. Lors du provisionnement du cluster, le job machine-init du deuxième nœud du plan de contrôle échoue avec le message suivant :

    FAILED! => {"changed": true, "cmd": "/usr/bin/kubeadm join phase control-plane-prepare certs --config /dev/stdin --v 5".

  2. Affichez les journaux :

    kubectl --kubeconfig=ADMIN_KUBECONFIG logs -p kube-apiserver-{first_node_name} -n kube-system | grep "etcdmain: open /etc/kubernetes/pki/etcd/ca.crt: permission denied"

    Le résultat affiché n'est pas vide.

Solution :

  1. Activez ou désactivez l'autorisation /etc/kubernetes/pki/etcd/ca.crt. Il s'agit d'une opération très sensible au temps. Le changement d'autorisation doit avoir lieu après l'exécution précédente du job machine-init, mais avant la prochaine exécution du job machine-init, car machine-init rétablit l'autorisation sur la racine.

  2. Redémarrez etcd dans le deuxième nœud pour récupérer etcd dans le premier nœud en cas de boucle de plantage.

Une fois ces deux étapes terminées, le kube-apiserver du premier nœud commence à s'exécuter et la tâche machine-init suivante réussit.

Aucune connectivité entre le cluster de service et le bucket de stockage d'objets

Versions : 1.13.1

Symptômes : la connexion d'un pod de base de données s'exécutant dans le cluster de service à un bucket de stockage d'objets dans le cluster d'administrateur de l'organisation échoue.

Solution : Suivez les instructions du runbook KUB-R0305.

Échec de la vérification préliminaire

Versions : 1.13.1

Symptômes : le message suivant peut s'afficher dans l'état de l'objet cluster :

conditions:
    message: Preflight check <cluster> failed
    reason: PreflightCheckFailed
    status: "False"
    type: PreflightCheckSuccessful

Vous devriez également voir un objet PreflightCheck correspondant portant le même nom et se trouvant dans le même espace de noms que l'objet de cluster, qui est présent depuis plusieurs heures alors que l'erreur ou l'échec indiqué dans l'objet PreflightCheck n'est plus un problème connu.

Solution : Supprimez l'objet PreflightCheck.

Échec de la création du pool de nœuds de calcul du cluster d'utilisateur

Versions : 1.13.5

Symptômes : la création du pool de nœuds de calcul du cluster utilisateur peut cesser de répondre pour l'un des types de machines suivants :

  • n2-standard-16-gdc
  • n2-standard-32-gdc
  • n2-highmem-16-gdc
  • n2-highmem-32-gdc

Solution de contournement : Supprimez ce pool de nœuds et recréez-le en sélectionnant d'autres types de machines disponibles dans le menu déroulant de l'interface utilisateur de création de cluster d'utilisateur.

Les clusters d'utilisateurs recréés peuvent rester bloqués dans l'état "En cours de réconciliation" en raison d'un nettoyage incorrect.

Versions : 1.13.x

Problèmes constatés : lorsque des clusters d'utilisateur sont créés avec le même nom qu'un cluster supprimé précédemment, ils peuvent rester bloqués à l'état Reconciling indéfiniment, avec un état mentionnant l'étape d'installation du module complémentaire ONE.

Solution : Désinstallez le module complémentaire Helm CLUSTER_NAME-abm-overrides et redémarrez le déploiement managed-adm-controller. Pour connaître la procédure détaillée, consultez MKS-R0004.

Service de base de données

Cette section liste les problèmes connus du service de base de données.

Clonage de base de données AlloyDB Omni bloqué

Versions : toutes les versions 1.13.x

Symptômes : lorsqu'un utilisateur clone un cluster AlloyDB Omni à partir d'un moment précis, le cluster de base de données cloné reste bloqué avec l'erreur DBSE0005 et ne peut pas devenir prêt. La ressource restore.alloydb correspondante est bloquée dans la phase "ProvisionInProgress".

Solution de contournement : Pour contourner ce problème, choisissez soigneusement le point dans le temps à partir de la COMPLETETIME des sauvegardes réussies.

Liste les sauvegardes AlloyDB Omni disponibles à cloner sur le serveur de l'API Management.

kubectl get backups.alloydb -n source-dbcluster-namespace

Exemples de résultats :

NAMESPACE   NAME                         PHASE       COMPLETETIME
db1         backupplan1-20240908215001   Succeeded   2024-09-08T21:37:38Z
db1         backupplan1-20240909215001   Succeeded   2024-09-09T21:16:18Z
db1         backupplan1-20240910215001   Succeeded   2024-09-10T21:09:38Z
db1         backupplan1-20240911215001   Succeeded   2024-09-11T21:50:47Z

Choisissez une valeur COMPLETETIME comme point temporel pour le clonage. Notez que l'heure est exprimée en temps UTC.

L'application des IOPS a un impact sur les performances de stockage

Versions : 1.13.1

Solution de contournement : Pour contourner ce problème, suivez l'une des options suivantes :

  • Augmentez la taille de l'espace de stockage.
  • Remplacez le quota d'IOPS.

Erreur de réconciliation lors de la mise à niveau du sous-composant dbs-fleet

Versions : 1.13.3

Symptômes : lorsque vous mettez à niveau l'organisation racine de la version 1.13.1 à la version 1.13.3, une erreur de réconciliation peut s'afficher. Recherchez les erreurs de rapprochement :

kubectl get subcomponent -n ${CLUSTER} -o json | jq -r '.items[] |  select(.status.conditions[]?.reason == "ReconciliationError") |  "Sub-Component: \(.metadata.name) - \(.status.conditions[]?.message)"'

L'erreur peut se présenter comme suit :

Sub-Component: dbs-fleet - Reconciliation error: E0121 - rollback chart: no ControlPlaneAgentsVersion with the name "alloydbomni-v0.12.46" found

Solution : Suivez les étapes du runbook OCLCM-R0122.

Échec de la création de DBCluster

Versions : 1.13.3

Symptômes : après la mise à niveau vers 1.13.3, les nouveaux DBclusters ne parviennent pas à se réconcilier, avec l'erreur suivante dans l'état :

status:
  criticalIncidents:
  - code: DBSE0001
    createTime: ""
    message: Internal. General Controller Error.
    resource:
      component: controller-default
      location: {}
    stackTrace:
    - component: controller-default
      message: 'DBSE0001: Internal. General Controller Error. Failed to reconcile
        Postgres DBCluster [<name>] DBSE0001: Internal.
        General Controller Error. target release is empty in ModuleInstance <name>'

Solution

Vérifiez qu'il existe des CR localrollout se terminant par cpa-v0.12.46 et cpa-v0.12.51 dans le cluster d'administrateur de l'organisation. Exemple :

kubectl get localrollouts -A

dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.46         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.46         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.51         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.51         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.51--cpa-v0.12.51   true

Recherchez et supprimez les CR localrollout qui se terminent par cpa-v0.12.46, en veillant à ce que les autres CR localrollout ne soient pas affectées.

kubectl get localrollouts -A | grep cpa-v0.12.46

Une liste semblable à celle-ci devrait s'afficher :

dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.46         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.46         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.46--cpa-v0.12.46   true

Supprimez-les un par un :

kubectl delete -n dbs-fleet-system localrollout/dp-alloydbomni-15-5.2--cpa-v0.12.46
...
...

Vérifiez que les CR localrollout se terminant par cpa-v0.12.51 sont toujours présents :

NAMESPACE          NAME                                        PAUSED   IN PROGRESS   FINISHED
dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.51         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.51         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.51--cpa-v0.12.51   true

DNS

DNSSEC doit être explicitement désactivé dans resolved.conf

Versions : 1.13.1, 1.13.3, 1.13.4

Symptômes : la résolution DNS échoue sur les nœuds bare metal ou de VM. Pour confirmer que la résolution DNS échoue, établissez une connexion SSH au nœud concerné et exécutez systemctl status systemd-resolved. Le résultat contient des lignes telles que DNSSEC validation failed for question . IN SOA: no-signature.

Solution :

  1. Ajoutez la ligne suivante à /etc/systemd/resolved.conf sur le nœud concerné.

    DNSSEC=false

  2. Redémarrez le service systemd-resolved :

    systemctl restart systemd-resolved.service

Service portuaire

Échec de la création du service Harbor

Versions : 1.13.6

Symptômes : la création d'une instance Harbor échoue en raison d'une incompatibilité d'espace de noms causée par une limite de longueur dans le nom ServiceIsolationEnvironment. Un message de ce type peut s'afficher :

Failed to reconcile ODSDatabase: failed to create or update ODS ProjectNetworkPolicy: namespaces "g-dbs-PROJECT_NAME-HARBOR_INSTANCE_NAME" not found

Solution de contournement : raccourcissez le nom de l'instance Harbor pour résoudre le problème actuel. Assurez-vous que la longueur combinée de PROJECT_NAME et de HARBOR_INSTANCE_NAME est inférieure à 27 caractères.

La suppression d'instances Harbor n'entraîne pas la suppression des miroirs de registre associés.

Versions : 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7, 1.13.8

Symptômes : La suppression des instances Harbor n'entraîne pas la suppression des miroirs de registre associés. Il est possible que le pool de nœuds soit bloqué dans l'état Provisioning. Cela est dû au fait que les miroirs de registre créés par le contrôleur MHS ne sont pas supprimés lorsque les instances Harbor le sont.

Solution de contournement : Vous devez supprimer manuellement les miroirs de registre. Pour résoudre ce problème, procédez comme suit :

  1. Connectez-vous au cluster d'administrateur de l'organisation. Pour en savoir plus, consultez la section Architecture d'un cluster GDC.

  2. Exécutez ce script pour supprimer tous les miroirs de registre qui correspondent à la valeur de la variable d'environnement HARBOR_INSTANCE_URL de tous les clusters Kubernetes portant le libellé lcm.private.gdc.goog/cluster-type=user :

    LABEL="lcm.private.gdc.goog/cluster-type=user"
ENDPOINT=HARBOR_INSTANCE_URL

while read -r out; do
    info=${out% *}
    ns_name=${info%:*}
    name=${ns_name##*/}
    ns=${ns_name%%/*}
    INDEX=$(kubectl get cluster user-vm-1 -n user-vm-1-cluster -ojson | jq '.spec.nodeConfig.registryMirrors | map(.endpoint=='\"$ENDPOINT\"') | index(true)')
    kubectl patch clusters "${name}" -n "${ns}" --type=json -p="[{'op': 'remove', 'path': '/spec/nodeConfig/registryMirrors/$INDEX'}]"
done <<< $(kubectl get clusters -l "$LABEL" -o jsonpath="$JSONPATH" -A)

    Remplacez HARBOR_INSTANCE_URL par l'URL de votre instance Harbor.

Module de sécurité matérielle

Les licences d'essai HSM désactivées sont toujours détectables

Versions : 1.13.1, 1.13.3-1.13.11

Symptômes : En raison d'un problème connu existant dans CipherTrust Manager, les licences d'essai désactivées sont toujours détectables et peuvent déclencher de fausses alertes d'expiration.

Solution de contournement : consultez HSM-R0003 pour vérifier les licences normales actives et supprimer les licences d'essai désactivées.

Fuite de descripteur de fichier du daemon hôte HSM

Versions : 1.13.x

Symptômes : si les HSM s'exécutent pendant plus de 30 jours, une fuite de descripteur de fichier peut entraîner l'arrêt de la réponse du service host-daemon, ce qui génère une erreur ServicesNotStarted.

Solution : Redémarrez le service host-daemon. Pour ce faire, demandez à votre opérateur d'infrastructure de se connecter au HSM via SSH en tant qu'utilisateur ksadmin et d'exécuter la commande suivante :

sudo systemctl restart host-daemon

Si cela ne fonctionne pas, votre IO peut redémarrer le HSM défectueux.

Certificats HSM expirés

Versions : 1.13.11

Problèmes constatés : lorsque vous mettez à niveau une organisation, un avertissement semblable à celui-ci peut s'afficher :

Warning  Unsuccessful  50m   OrganizationUpgrade  1 error occurred:
          * UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn't after 13h45m23.442682119s, last message was: Cluster upgrade for system cluster: in-progress

Le org-1-system-cluster est bloqué dans une mise à niveau de la version ABM en raison de certificats HSM (Hardware Security Module) expirés.

Une erreur semblable à celle de cet exemple peut également s'afficher dans HPE server iLO, StorageGRID ou ONTAP :

Not able to connect SSL to Key Manager server at IP_ADDRESS

Solution :

Faites manuellement la rotation de l'autorité de certification racine et du certificat d'interface Web avec ksctl :

  1. Mettez en veille toutes les RS HSM, HSMCluster et HSMTenant.

  2. Créez une autorité de certification racine avec les attributs copiés de l'ancienne. Recherchez l'ancien ID de CA avec ksctl ca locals list. Voici un exemple :

    ksctl ca locals create --cn example.com --copy-from-ca 6d7f7fa7-df81-44b7-b181-0d3e6f525d46
{
    "id": "b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "uri": "kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "account": "kylo:kylo:admin:accounts:kylo",
    "createdAt": "2025-06-04T18:46:25.728332Z",
    "updatedAt": "2025-06-04T18:46:25.728332Z",
    "state": "pending",
    "csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIHQMHgCAQAwFjEUMBIGA1UEAxMLZXhhbXBsZS5jb20wWTATBgcqhkjOPQIBBggq\nhkjOPQMBBwNCAAR5pwW1UC1JNg79gkjK2rvnmgaZpGNwb4VxYN3dQCieHtHlYJUu\nQWk56RB9oPw4SKkf/Y1ZwEI4m2mx3d9XFHU7oAAwCgYIKoZIzj0EAwIDSAAwRQIh\nANWTPjkJNcY56lSARN714EBa1gLuvxJlMENVHKEbanooAiA1BQ3sz7mxykL/1t7v\nqRlIpxKGrhw56XC67vz4NvZ4Kg==\n-----END CERTIFICATE REQUEST-----\n",
    "subject": "/CN=example.com",
    "notBefore": "0001-01-01T00:00:00Z",
    "notAfter": "0001-01-01T00:00:00Z",
    "sha1Fingerprint": "21F033940A65657CC6C2C1EA0BB775F14FD5D193",
    "sha256Fingerprint": "31EF6E1316DF039F77DDDB051890CDEBBF67BBE8A14AEE04E01716D30DC90937",
    "sha512Fingerprint": "F200817829A23F30239C33DC2CED8C889954A252EBA2CC12A3977FD5F91239ED7A2A4CCF0EA3D90D50CEF7A779E5C487798AAC75617DB2F29AF7F4794AD66F17",
    "purpose": {}
}

  3. Signez vous-même la nouvelle CA pour une durée d'un an. Voici un exemple :

    ksctl ca locals self-sign --id b0516120-6b4c-40ed-93f4-35e9fdc690e7 -x 365
{
    "id": "b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "uri": "kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "account": "kylo:kylo:admin:accounts:kylo",
    "createdAt": "2025-06-04T18:46:25.728332Z",
    "updatedAt": "2025-06-04T18:52:51.976847092Z",
    "state": "active",
    "csr": "",
    "cert": "-----BEGIN CERTIFICATE-----\nMIIBbTCCAROgAwIBAgIRAMyQJHhs4i2uwj4ghilVFJQwCgYIKoZIzj0EAwIwFjEU\nMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjUwNjAzMTg1MjUxWhcNMjYwNjA0MTg1\nMjUxWjAWMRQwEgYDVQQDEwtleGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49\nAwEHA0IABHmnBbVQLUk2Dv2CSMrau+eaBpmkY3BvhXFg3d1AKJ4e0eVglS5BaTnp\nEH2g/DhIqR/9jVnAQjibabHd31cUdTujQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV\nHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQ9uCnTZ+lHhiLx3f1xEn0+JC5J+TAKBggq\nhkjOPQQDAgNIADBFAiBsSiB5BRBJ8TZQ6O5TzMBgDoWzTZVMVXNLdZUiqHtcDwIh\nAOnqKNq5ytWLvMsBQKhulGgqqw1dccpkJJz01n3Smzyp\n-----END CERTIFICATE-----\n",
    "serialNumber": "271910941595574900448900837122680099988",
    "subject": "/CN=example.com",
    "issuer": "/CN=example.com",
    "notBefore": "2025-06-03T18:52:51Z",
    "notAfter": "2026-06-04T18:52:51Z",
    "sha1Fingerprint": "1114AF5ED6DF7D4A9F83A0F8DF5DFEF041A81622",
    "sha256Fingerprint": "93BAD9D44B320EFB446F65FE2A4F3A341147D15AF5315C000ADF644A3C1347A7",
    "sha512Fingerprint": "07386D7461B4013304CF0E0830517EA433E09EAB146A9F106F1B0DED4BBEC78BB4C89EAFAEC37178FE98AC4ACA234B98290D240607D5EA896F03DABF3DB56D5C",
    "purpose": {
            "client_authentication": "Enabled",
            "user_authentication": "Enabled"
    }
}

  4. Mettez à jour l'interface Web pour qu'elle utilise cette nouvelle CA pour la génération automatique de ses certificats. Voici un exemple :

    ksctl interfaces modify --name web --auto-gen-ca-id kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7                 
{                                                                                                                                                                      
    "id": "61aab814-2821-43ac-b652-41784b7b06bf",                                                                                                                  
    "name": "web",                                                                                                                                                 
    "mode": "tls-cert-opt-pw-opt",                                                                                                                                 
    "cert_user_field": "CN",                                                                                                                                       
    "auto_gen_ca_id": "kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7",                                                                              
    "trusted_cas": {                                                                                                                                               
            "local": [                                                                                                                                             
                    "kylo:kylo:naboo:localca:6d7f7fa7-df81-44b7-b181-0d3e6f525d46"                                                                                 
            ]                                                                                                                                                      
    },                                                                                                                                                             
    "createdAt": "2023-11-13T22:46:56.251881Z",                                                                                                                    
    "updatedAt": "2025-06-04T19:02:12.710563Z",                                                                                                                    
    "port": 443,                                                                                                                                                   
    "network_interface": "all",                                                                                                                                    
    "interface_type": "web",                                                                                                                                       
    "minimum_tls_version": "tls_1_2",                                                                                                                              
    "maximum_tls_version": "tls_1_3",                                                                                                                              
    "local_auto_gen_attributes": {                                                                                                                                 
            "cn": "web.ciphertrustmanager.local",                                                                                                                  
            "dns_names": [                                                                                                                                         
                    "web.ciphertrustmanager.local"                                                                                                                 
            ],      
...

  5. Générez un nouveau certificat d'interface Web, signé par la nouvelle autorité de certification. L'indicateur --url correspond à l'adresse IP de gestion du HSM (à partir de kubectl get hsm -n gpc-system). Voici un exemple :

    ksctl interfaces auto-gen-server-cert --name "web" --url=https://10.128.52.18
{
    "certificates": "-----BEGIN CERTIFICATE-----\nMIICljCCAjygAwIBAgIRANPuw/42oHZAb9nzAYnrf9MwCgYIKoZIzj0EAwIwFjEU\nMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjUwNjAzMTkwOTU5WhcNMjYwNjA0MTg1\nMjUxWjBjMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVFgxDzANBgNVBAcTBkF1c3Rp\nbjEPMA0GA1UEChMGVGhhbGVzMSUwIwYDVQQDExx3ZWIuY2lwaGVydHJ1c3RtYW5h\nZ2VyLmxvY2FsMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEy9T8uGa/N9ruRJMy\nxy4an+G/OyZjB/8nth1BPxpw5orljbTuOh9toS9c9FiOuMQQ13mGJSImadLP33PR\ngdXcHaOCARwwggEYMA4GA1UdDwEB/wQEAwIDiDATBgNVHSUEDDAKBggrBgEFBQcD\nATAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFD24KdNn6UeGIvHd/XESfT4kLkn5\nMGIGA1UdEQRbMFmCHHdlYi5jaXBoZXJ0cnVzdG1hbmFnZXIubG9jYWyBIXRlY2hu\naWNhbC5zdXBwb3J0QHRoYWxlc2dyb3VwLmNvbYcECoA0EocECgADAocErBMjAocE\nrBMLAjBeBgNVHR8EVzBVMFOgUaBPhk1odHRwOi8vY2lwaGVydHJ1c3RtYW5hZ2Vy\nLmxvY2FsL2NybHMvYjA1MTYxMjAtNmI0Yy00MGVkLTkzZjQtMzVlOWZkYzY5MGU3\nLmNybDAKBggqhkjOPQQDAgNIADBFAiEAusSKWMoFeTsK+OrbURch7XtMR31XD45E\n+w+wjf2VAk4CIAsHytphizTFQks4qqOMaHm6Ap58uU0HMNGSm0WW6mQY\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\nMIIBbTCCAROgAwIBAgIRAMyQJHhs4i2uwj4ghilVFJQwCgYIKoZIzj0EAwIwFjEU\nMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjUwNjAzMTg1MjUxWhcNMjYwNjA0MTg1\nMjUxWjAWMRQwEgYDVQQDEwtleGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49\nAwEHA0IABHmnBbVQLUk2Dv2CSMrau+eaBpmkY3BvhXFg3d1AKJ4e0eVglS5BaTnp\nEH2g/DhIqR/9jVnAQjibabHd31cUdTujQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV\nHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQ9uCnTZ+lHhiLx3f1xEn0+JC5J+TAKBggq\nhkjOPQQDAgNIADBFAiBsSiB5BRBJ8TZQ6O5TzMBgDoWzTZVMVXNLdZUiqHtcDwIh\nAOnqKNq5ytWLvMsBQKhulGgqqw1dccpkJJz01n3Smzyp\n-----END CERTIFICATE-----\n"
}

  6. À ce stade, openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text affiche toujours l'ancien certificat. Vous devez redémarrer le HSM pour récupérer le nouveau certificat.

    ssh -i ~/.ksctl/ssh-privatekey ksadmin@10.128.52.18

sudo reboot

    openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text affiche désormais le nouveau certificat.

  7. Supprimez l'ancienne autorité de certification de la CR HSM :

    kubectl edit hsm zv-aa-hsm01 -n gpc-system and delete hsm.Spec.RootCACertificates

  8. Désactivez la mise en veille du HSM : 

    kubectl annotate hsm zv-aa-hsm01 -n gpc-system hsm.security.private.gdc.goog/paused-

    Assurez-vous que le HSM devient opérationnel.

  9. Répétez ces étapes pour les deux autres HSM. Ils disposent déjà de la nouvelle autorité de certification racine auto-signée, car elle est partagée entre les HSM d'un cluster. Ignorez les étapes 2 et 3, mais répétez les étapes 4 à 8.

  10. Suivez la tâche laborieuse de rotation de l'AC HSM-T0008 pour automatiser la rotation de tous les certificats, mais ignorez l'étape Finaliser la rotation en ajoutant une nouvelle annotation de rotation à hsmcluster où ca-rotation-finalizing annotation est ajouté.

Importez le nouveau nom de l'autorité de certification dans iLO :

  1. Dans l'interface iLO, ouvrez la page "Administration - Gestionnaire de clés" et cliquez sur l'onglet Gestionnaire de clés.
  2. Faites alterner le nom du certificat.
  3. Effectuez un redémarrage à froid.
  4. Vérifiez que l'établissement de liaison SSL fonctionne à nouveau.

Gestion de l'authentification et des accès

Les pods gatekeeper-audit de l'espace de noms opa-system redémarrent fréquemment

Versions : 1.13.3

Symptômes : vérifiez l'état des pods gatekeeper-audit-*** dans l'espace de noms opa-system :

kubectl get pods/gatekeeper-audit-POD_ID -n opa-system-NAMESPACE_ID -n opa-system

Le résultat peut ressembler à l'exemple suivant :

NAME                                READY   STATUS    RESTARTS        AGE
gatekeeper-audit-58d8c4c777-7hzvm   2/2     Running   987 (12h ago)   12d

Ce problème est dû à des limites de ressources faibles.

Infrastructure as Code (IAC)

La création excessive de jetons GitLab risque de remplir les bases de données GitLab

Versions : 1.13.1

Symptômes : Le sous-composant iac-manager crée un jeton pour l'utilisateur configsync-ro de manière répétée, même lorsque ce n'est pas nécessaire. Cela peut entraîner le remplissage de la base de données GitLab et rendre l'IAC inaccessible. Il est possible que le pod pg-gitlab-database-0 de l'espace de noms gitlab-system ne puisse pas démarrer et affiche des événements tels que :

  Warning  Unhealthy  84s (x18 over 4m14s)   kubelet  Startup probe failed: /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
psql: error: connection to server at "localhost" (127.0.0.1), port 5432 failed: FATAL:  could not write init file

Solution :

Contactez votre représentant Google pour obtenir hotfix_3 pour la version 1.13.1 et l'appliquer.

Système de gestion des clés (KMS)

Si vous modifiez le type de clé racine, toutes les clés existantes ne seront plus valides.

Versions : 1.13.x

Symptômes : Une fois l'organisation créée, le KMS est automatiquement provisionné avec une clé racine logicielle. Pour migrer d'une clé racine logicielle vers une clé CTM, les utilisateurs effectuent un remplacement de sous-composant. Cela modifie le type de clé racine, ce qui invalide toutes les clés logicielles existantes dans le KMS.

Solution : Évitez de mettre à jour le type de clé racine si possible. Si vous modifiez le type de clé racine, toutes les clés existantes ne seront plus valides.

kms-rootkey-controller CrashLoopBackOff en raison de OOMKILL

Versions : 1.13.1

Problèmes constatés : lorsque l'utilisation de la mémoire kms-rootkey-controller dépasse la limite 600Mi, le contrôleur passe à l'état CrashLoopBackOff en raison d'un état OOMKilled.

Solution : créez un SubcomponentOverride pour mettre à jour la limite de mémoire sur 1500Mi. Pour obtenir des instructions, consultez le runbook KMS 0007. Une fois les étapes préalables du runbook effectuées, exécutez les commandes suivantes :

  1. Créez une ressource personnalisée SubcomponentOverride :

    cat << EOF > ~/kms-rootkey-subcomponentoverride.yaml

    L'exemple suivant montre une ressource personnalisée SubcomponentOverride complète :

    apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: kms-rootkey-subcomponentoverride
  namespace: root
spec:
  subComponentRef: kms-rootkey-cm
  backend:
    operableParameters:
      resourcesLimit:
        memory: 1500Mi
EOF

  2. Appliquez la ressource SubcomponentOverride :

    kubectl --kubeconfig ${KUBECONFIG:?} apply -f ~/kms-rootkey-subcomponentoverride.yaml

kubectl --kubeconfig ${KUBECONFIG:?} describe subcomponentoverride kms-rootkey-subcomponentoverride -n root

Journalisation

L'enregistreur d'audit du stockage d'objets ne peut pas résoudre l'hôte DNS

Versions : 1.13.x

Symptômes :

Dans le cluster d'administrateur racine, le déploiement obs-system/log-remote-logger contient plusieurs erreurs, comme les suivantes :

E1220 17:00:25.247258       1 manager.go:183] Failed to fetch obj audit logs for gce-gpcstgesite01: failed to get authorization token for Grid Management  API: Post "https://objectstorage-grid-mgmt.gpc-system.svc.cluster.local/api/v3/authorize": dial tcp: lookup objectstorage-grid-mgmt.gpc-system.svc.cluster.local: no such host

Solution : Corrigez le déploiement obs-system/log-remote-logger à l'aide de la commande suivante :

kubectl --kubeconfig ${KUBECONFIG:?} patch deployment log-remote-logger -n obs-system -p '{"spec":{"template":{"spec":{"dnsPolicy":"ClusterFirstWithHostNet"}}}}'

Le journal HaaS affiche des erreurs dans le cluster d'administrateur racine

Versions : 1.13.x

Symptômes :

Dans le cluster d'administrateur racine, le déploiement obs-system/log-remote-logger contient plusieurs erreurs, comme les suivantes :

E0109 17:33:08.917876       1 manager.go:156] Failed to run logger haas: Failed to get log targets: failed to list harborinstances in the cluster: failed to get API group resources: unable to retrieve the complete list of server APIs: artifactregistry.gdc.goog/v1: the server could not find the requested resource

Solution : Passez à la version 1.13.8 pour corriger l'erreur. Vous pouvez également modifier le déploiement obs-system/log-remote-logger comme suit :

Dans les arguments du conteneur remote-logger, mettez à jour l'indicateur --disabled-loggers pour inclure santricity et HaaS :

YAML

args:
  - --disabled-loggers=santricity,haas

Échec de Santricity Logger

Versions : 1.13.x

Symptômes :

Dans le cluster d'administrateur racine, le déploiement obs-system/log-remote-logger contient plusieurs erreurs, comme les suivantes :

E0109 17:33:10.931737       1 manager.go:183] Failed to fetch santricity audit logs for lb-aa-objs01: failed to get CA cert: failed to get ClusterIssuer internal-root-ca-issuer: no kind is registered for the type v1.ClusterIssuer in scheme "pkg/logging/manager.go:32"

Solution : Passez à la version 1.13.8 pour corriger l'erreur.

Les journaux de la cible de journalisation sont envoyés au mauvais projet

Versions : 1.13.x

Symptômes : les journaux DaemonSet obs-system/oplogs-forwarder consignent des avertissements semblables à ce qui suit :

oplogs-forwarder-2xrfw [2025/01/16 21:02:09] [ warn] [output:loki:log_output_loki_dbs_fleet_system_dbs_fleet] Tenant ID is overwritten platform-obs -> infra-obs
oplogs-forwarder-kxf8p [2025/01/16 21:05:23] [ warn] [output:loki:log_output_loki_workbench_system_nws_lt] Tenant ID is overwritten infra-obs -> platform-obs

Ces avertissements entraînent le routage des journaux vers le mauvais projet (ID de locataire). Ce problème est dû à un bug connu dans Fluent Bit. Pour en savoir plus, consultez le problème Fluent Bit sur GitHub.

Solution : Passez à la version 1.13.8 pour corriger l'erreur.

L'administrateur de plate-forme n'a pas accès aux journaux d'audit de l'espace de noms de la plate-forme.

Versions : 1.13.x

Symptômes : les journaux d'audit de l'espace de noms de la plate-forme sont visibles par l'opérateur d'infrastructure (OI) au lieu de l'administrateur de plate-forme (AP).

Solution de contournement : Ajoutez manuellement le libellé observability.gdc.goog/auditlog-destination=pa à l'espace de noms platform dans tous les clusters de l'organisation. Pour implémenter cette solution de contournement manuelle, procédez comme suit :

  1. Définissez KUBECONFIG sur le cluster cible.

  2. Ajoutez le libellé requis à l'espace de noms :

    KUBECONFIG=${KUBECONFIG:?} kubectl label namespace platform observability.gdc.goog/auditlog-destination=pa --overwrite

  3. Vérifiez que le libellé a bien été ajouté :

    KUBECONFIG=${KUBECONFIG:?} kubectl label namespace platform --list

Échec de l'initialisation des conteneurs par les pods

Versions : 1.13.x

Symptômes : la création des pods échoue avec une erreur semblable à la suivante :

Events:
│   Type     Reason                  Age                     From     Message                                                                                                                                                 │
│   ----     ------                  ----                    ----     -------                                                                                                                                                 │
│   Warning  FailedCreatePodSandBox  10m (x2080 over 7h40m)  kubelet  Failed to create pod sandbox: mkdir /var/log/pods/org-1_managed-asm-local-readiness-xq75d_9a3275d7-5f16-4d67-8f4a-38fe0993be4a: no space left on device │

Ces erreurs empêchent les pods de démarrer sur un nœud spécifique. Le comportement observé découle d'un cas limite connu dans lequel le fichier d'état logrotate-daemon est verrouillé, ce qui empêche le démon d'effectuer la rotation de fichier attendue. Pour confirmer cette erreur, procédez comme suit :

  1. Définissez KUBECONFIG sur le cluster cible.

  2. Identifiez l'instance anthos-audit-logs-forwarder-xxxx planifiée sur le nœud.

    KUBECONFIG=${KUBECONFIG:?} kubectl get po -n obs-system -o wide | grep anthos-audit-logs-forwarder

  3. Récupérez les journaux de l'instance anthos-audit-logs-forwarder-xxxx planifiée sur le nœud pour effectuer la validation.

    KUBECONFIG=${KUBECONFIG:?} kubectl logs -n obs-system anthos-audit-logs-forwarder-xxxx -c logrotate-daemon | grep "state file /var/lib/logrotate/status is already locked"

Solution :

Pour résoudre ce problème, procédez comme suit :

  1. Récupérez manuellement de l'espace disque dans le répertoire /var/log du nœud.

  2. Définissez KUBECONFIG sur le cluster cible.

  3. Identifiez le nœud cible dans le cluster.

    KUBECONFIG=${KUBECONFIG:?} kubectl get no -o wide

  4. Connectez-vous au nœud à l'aide de SSH et libérez manuellement de l'espace dans le répertoire /var/log du nœud. logrotate gère les fichiers de ces répertoires.

    /var/log/audit/*/*/*/audit.log
/var/log/audit*/*/*.log
/var/log/auditproxy-*/*.log
/var/log/global-api-*/audit.log
/var/log/ceph/ceph.audit.log
/var/log/fanout/audit/*.log
/var/log/fanout/audit/*/*.log
/var/log/netflow/*.log
/var/log/fanout/operational/*.log
/var/log/fanout/operational/*/*.log

  5. Recherchez les fichiers journaux de taille inhabituellement importante (plus de 100 Mo) ou datant de plus de deux jours. Une fois que vous avez le fichier cible, vous pouvez tronquer les journaux comme suit :

    truncate -s 1G <target_file>

  6. Identifiez l'instance anthos-audit-logs-forwarder-xxxx planifiée sur le nœud.

    KUBECONFIG=${KUBECONFIG:?} kubectl get po -n obs-system -o wide | grep anthos-audit-logs-forwarder

  7. Redémarrez l'instance anthos-audit-logs-forwarder-xxxx planifiée sur le nœud.

    KUBECONFIG=${KUBECONFIG:?} kubectl delete po -n obs-system anthos-audit-logs-forwarder-xxxx

Marketplace

Échec de l'extraction d'image Prisma Cloud

Versions : 1.13.7

Symptômes : la création d'une instance de service Prisma Cloud à partir de Marketplace échoue. Ce problème est dû à une balise d'image incorrecte.

Solution :

  1. Modifiez le déploiement twistlock-console pour modifier le tag d'image :

    KUBECONFIG=${KUBECONFIG:?} kubectl edit deployment twistlock-console -n ${PROJECT:?}

  2. Recherchez la ligne suivante :

    image: HARBOR_IP/library/twistlock/console:console_33_01_137

  3. Remplacez console_33_01_137 par console_33.01.137 :

    image: HARBOR_IP/library/twistlock/console:console_33.01.137

  4. Vérifiez que le pod s'exécute correctement :

    KUBECONFIG=${KUBECONFIG:?} kubectl get pods -n ${PROJECT:?}

    Le résultat peut ressembler à l'exemple suivant :

    NAME                                 READY   STATUS    RESTARTS   AGE
twistlock-console-58b578cbf4-5nvbk   1/1     Running   0          2m45s

Surveillance

Un grand nombre d'alertes ont été créées dans ServiceNow

Versions : 1.13.x

Symptômes :

Après avoir configuré la surveillance pour envoyer des alertes à ServiceNow à l'aide des tâches répétitives MON-T0016 et MON-T1016, un grand nombre d'incidents sont automatiquement créés dans ServiceNow.

Le problème présente les caractéristiques suivantes :

  • Tous les incidents sont vides.
  • Seuls le cluster d'administration racine et l'organisation gdchservices peuvent envoyer des alertes à ServiceNow.

Solution : Suivez la tâche de toil MON-T0018 immédiatement après avoir exécuté les tâches de toil MON-T0016 et MON-T1016.

Plusieurs alertes en double ont été créées dans ServiceNow

Versions : 1.13.x

Symptômes :

Après avoir configuré Monitoring pour envoyer des alertes à ServiceNow à l'aide des tâches de corvée MON-T0016, MON-T1016 et MON-T0018, plusieurs alertes en double sont créées dans ServiceNow.

Le problème présente les caractéristiques suivantes :

  • Plusieurs incidents en double sont créés pour certaines alertes, même après l'application de la tâche de toil MON-T0018.

Solution : Exécutez la tâche de labeur MON-T0019 immédiatement après les tâches de labeur MON-T0016, MON-T1016 et MON-T0018.

Impossible d'afficher les métriques Vertex AI

Versions : 1.13.1

Problèmes constatés : le pod dvs-frontend-server n'émet pas de métriques.

Solution de contournement : La version 1.13.1 n'est pas compatible avec les métriques chiffrées pour les services Vertex AI. Si le service Vertex AI n'est pas activé au bout d'une heure, redémarrez le pod du contrôleur mon-admin.

Erreur de rapprochement dans mon-cortex

Versions : 1.13.1, 1.13.9

Symptômes : le pod mon-cortex présente une erreur de rapprochement. Obtenez l'état du pod mon-cortex :

kubectl get subcomponent mon-cortex -n gpu-org-1-system-cluster

Le résultat peut ressembler à ceci :

NAME         AGE   STATUS
mon-cortex   15h   ReconciliationError

Un message de ce type peut être enregistré :

message: 'E0100 - deploy: failed to install chart: release mon-cortex-backend
        failed, and has been uninstalled due to atomic being set: context deadline
        exceeded'

Solution :

  1. Vérifiez quel pod Cortex affiche un message comme celui-ci :

    Warning  FailedMount             11s   kubelet                  MountVolume.MountDevice failed for volume "pvc-0ad24fdc-52ec-4080-8ac0-5784989d1da3" : rpc error: code = Internal desc = rpc error: code = Internal desc = failed to stage volume: could not open LUKS device; could not open LUKS device; could not open LUKS device; exit status 1

  2. Supprimez le PVC associé à ce pod et redémarrez-le.

Le pod metrics-server-exporter du cluster système est en boucle de plantage

Versions : 1.13.1

Problèmes constatés : le pod metrics-server-exporter du cluster système est en boucle de plantage avec OOMKilled, mais il ne semble pas atteindre sa limite. Diagnostiquer l'erreur :

kubectl --kubeconfig $KUBECONFIG describe pod -n mon-system metrics-server-exporter-<id>

Le résultat peut ressembler à ceci :

[...]
Containers:
  [...]
  otel-collector:
    Container ID:  containerd://3a1373de4880cde9e09aa9cacc109a8059ec29d9355aef1f03735fdcdcd45596
    Image:         gcr.io/private-cloud-staging/opentelemetry-collector:v0.93.0-gke.2
    Image ID:      gcr.io/private-cloud-staging/opentelemetry-collector@sha256:2b14f8fe936e725efca24dace1abcc26449d996b1480eab1b25d469a16aac221
    Port:          3113/TCP
    Host Port:     0/TCP
    Command:
      /otelcol
      --config=/conf/otel-collector-config.yaml
      --feature-gates=pkg.translator.prometheus.PermissiveLabelSanitization
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Thu, 20 Jun 2024 15:55:35 +0000
      Finished:     Thu, 20 Jun 2024 15:56:57 +0000
    Ready:          False
    Restart Count:  570
    Limits:
      cpu:     200m
      memory:  200Mi
    Requests:
      cpu:        100m
      memory:     100Mi
    Environment:  <none>

Solution : Réduisez la quantité de données diffusées sur le point de terminaison des métriques en supprimant le pod et en le laissant redémarrer. L'ancienne version de time-series conservée en mémoire est effacée, ce qui réduit la mémoire requise.

Ignorer les messages d'erreur de rapprochement ObservabilityPipeline

Versions : 1.13

Symptômes :

L'objet ObservabilityPipeline affiche des journaux Reconciler error comme ceux ci-dessous dans le pod root-admin-controller :

{"msg":"Reconciler error","controller":"observabilitypipeline","ObservabilityPipeline":{"name":"default","namespace":"infra-obs"},"namespace":"infra-obs","name":"default","err":"unable to reconcile project level ObservabilityPipeline: 1 error occurred:\n\t* failed to get system cluster client to install per project overrides: root admin cluster has no system cluster\n\n"}

Solution :

Ignorez les journaux qui remplissent toutes les conditions suivantes :

  • "controller":"observabilitypipeline"
  • "namespace":"infra-obs"
  • "name":"default"
  • "err" contient failed to get system cluster client to install per project overrides: root admin cluster has no system cluster

Si vous déboguez une alerte en raison d'un taux d'erreurs de réconciliation élevé, ignorez ces journaux, car il s'agit de faux négatifs.

Le ConfigMap mon-prober-backend-prometheus-config est réinitialisé.

Versions : 1.13.0 et 1.13.1

Symptômes :

  • L'alerte MON-A0001 s'est déclenchée.

  • Le ConfigMap mon-prober-backend-prometheus-config est réinitialisé pour n'inclure aucune tâche de sonde, par exemple :

    apiVersion: v1
data:
  prometheus.yaml: |
    remote_write:
    - url: http://cortex-tenant.mon-system.svc:9009/push
      name: cortex-tenant
kind: ConfigMap
metadata:
  creationTimestamp: "2024-06-26T14:55:07Z"
  name: mon-prober-backend-prometheus-config
  namespace: mon-system
  resourceVersion: "6606787"
  uid: 1a495af0-1fdc-40b8-845b-4976e3b0f899

Solution :

Pour résoudre le problème, procédez comme suit :

  1. Définissez les variables d'environnement suivantes :

    • KUBECONFIG : chemin d'accès au fichier kubeconfig dans le cluster.
    • TARGET_CLUSTER : nom du cluster dans lequel vous résolvez le problème.

  2. Suspendez le sous-composant mon-prober sur tous les clusters :

    kubectl --kubeconfig $KUBECONFIG annotate subcomponent mon-prober -n $TARGET_CLUSTER lcm.private.gdc.goog/paused=true

    Exemple :

    kubectl --kubeconfig ~/root-admin-kubeconfig annotate subcomponent mon-prober -n my-org lcm.private.gdc.goog/paused=true

  3. Redémarrez le contrôleur administrateur MON sur chaque cluster d'administrateur :

    kubectl --kubeconfig $KUBECONFIG rollout restart deploy -n obs-system mon-admin-backend-controller

    Le ConfigMap du vérificateur se remplit à mesure que chaque vérification est enregistrée.

  4. Suivez le runbook MON-R2009 pour couper le son de l'alerte MON-A0001, Blackbox monitoring metrics pipeline down, car cette alerte continuera de se déclencher.

Boucle de plantage OOMKilled du composant de passerelle du magasin Cortex

Versions : 1.13.3

Symptômes : si des erreurs s'affichent dans Grafana lors du chargement des métriques ou si les métriques ne se chargent pas du tout, il est possible que le pod cortex-store-gateway soit en boucle de plantage.

Pour diagnostiquer le pod cortex-store-gateway et vérifier s'il est en boucle de plantage, examinez son état :

kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG describe pod \
  -l app=cortex-store-gateway -n mon-system

Remplacez SYSTEM_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster système.

Si le pod est en boucle de plantage, le résultat ressemble à l'exemple suivant :

State:          Waiting
Reason:       CrashLoopBackOff
Last State:     Terminated
Reason:       OOMKilled
Exit Code:    137

Solution : Augmentez temporairement la limite de mémoire cortex-store-gateway en utilisant un SubcomponentOverride. Pour en savoir plus sur l'implémentation d'un SubComponentOverride, consultez le runbook MON-R2008.

Voici un exemple de SubcomponentOverride avec une limite de mémoire spécifiée :

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: mon-cortex-memory-bump
  namespace: org-1-system-cluster
spec:
  subComponentRef: 'mon-cortex'
  backend:
    operableParameters:
      storeGateway:
          resourcesLimit:
              memory: 16Gi

Laissez le remplacement en place jusqu'à ce que tous les pods cortex-store-gateway aient l'état Ready et assurez-vous que le sous-composant mon-cortex n'est pas mis en veille :

  • Vérifiez que les pods cortex-store-gateway ont l'état Ready :

    kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG get statefulset \
  -n mon-system cortex-store-gateway

    Si tous les pods ont l'état Ready, le résultat ressemble à l'exemple suivant :

    NAME                   READY   AGE
cortex-store-gateway   3/3     70d

    La colonne READY doit afficher la valeur N/N pour que tous les pods soient prêts. Sinon, il affiche des valeurs telles que 1/3 ou 2/3.

  • Assurez-vous que le sous-composant mon-cortex n'est pas mis en veille dans une organisation donnée :

    kubectl --kubeconfig ORG_ADMIN_KUBECONFIG describe subcomponent \
  -n SYSTEM_CLUSTER mon-cortex | grep paused

    Remplacez les éléments suivants :

    • ORG_ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur de l'organisation.
    • SYSTEM_CLUSTER : nom du cluster système.

    Si le sous-composant est mis en veille, la ligne suivante s'affiche :

    lcm.private.gdc.goog/paused: true

    Sinon, le résultat est vide.

Délai de retour de l'extraction de l'image du proxy des métriques du plan de contrôle Kube dans le cluster d'utilisateur

Versions : 1.13.3

Symptômes : lorsque les métriques liées à kube-scheduler ou kube-controller-manager (par exemple, les métriques scheduler_pending_pods et workqueue_depth) ne sont pas visibles dans Grafana, il peut s'agir d'un problème de backoff de récupération d'image avec le pod kube-control-plane-metrics-proxy.

Pour diagnostiquer le pod kube-control-plane-metrics-proxy et vérifier s'il présente un problème de délai avant nouvelle tentative d'extraction d'image, examinez son état :

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe pod \
  -l k8s-app=kube-control-plane-metrics-proxy -n obs-system

Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'utilisateur.

Si le pod présente un problème de délai avant nouvelle tentative de récupération d'image, le résultat ressemble à l'exemple suivant :

State:          Waiting
Reason:       ImagePullBackOff
Ready:          False
Restart Count:  0

Solution de contournement : suivez ces étapes pour résoudre le problème :

  1. Extrayez l'image gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0 du projet Harbor gpc-system-container-images. Pour obtenir des instructions et connaître les autorisations nécessaires pour extraire une image, consultez Extraire une image avec Docker.

  2. Transférez l'image gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0 vers le projet Harbor library. Pour obtenir des instructions et connaître les autorisations nécessaires pour transférer une image, consultez Transférer une image.

    Le projet library est utilisé pour les artefacts à déployer sur le cluster d'utilisateur.

Une augmentation du WAL entraîne une forte utilisation de la mémoire par Prometheus

Versions : 1.13.3

Symptômes : le nœud de VM du plan de contrôle du système signale les événements NodeHasInsufficientMemory et EvictionThresholdMet :

kubectl describe node NODE_NAME | grep Events -A100

Le résultat devrait ressembler à ceci :

Events:
  Type     Reason                     Age                   From                   Message
  ----     ------                     ----                  ----                   -------
  Normal   NodeNotReady               12m (x8 over 10d)     node-controller        Node vm-e792c63a status is now: NodeNotReady
  Normal   NodeHasNoDiskPressure      12m (x9 over 24d)     kubelet                Node vm-e792c63a status is now: NodeHasNoDiskPressure
  Normal   NodeHasSufficientPID       12m (x9 over 24d)     kubelet                Node vm-e792c63a status is now: NodeHasSufficientPID
  Normal   NodeReady                  12m (x9 over 24d)     kubelet                Node vm-e792c63a status is now: NodeReady
  Normal   NodeHasInsufficientMemory  12m (x34 over 13h)    kubelet                Node vm-e792c63a status is now: NodeHasInsufficientMemory
  Warning  EvictionThresholdMet       12m (x64 over 13h)    kubelet                Attempting to reclaim memory
  Normal   TridentServiceDiscovery    11m (x21 over 13h)    csi.trident.netapp.io  [iSCSI] detected on host.
  Normal   NodeHasSufficientMemory    6m52s (x31 over 24d)  kubelet                Node vm-e792c63a status is now: NodeHasSufficientMemory

Prometheus utilise beaucoup de mémoire en raison de la croissance du journal WAL (write-ahead log), ce qui a un impact sur la mémoire du nœud. La croissance du WAL peut se produire parce que Cortex n'a pas été déployé. Ce problème peut donc être une conséquence de l'indisponibilité de Cortex. L'instance Prometheus perd la connectivité à Cortex pendant une période prolongée, au cours de laquelle elle met en mémoire tampon les données en mémoire et sur le volume persistant (PV). Lorsque Prometheus est arrêté, il charge toutes les données de son fichier WAL en mémoire au démarrage.

Une autre cause première peut être des problèmes de connectivité réseau (réseau de services, réseaux physiques et supérieurs).

Solution de contournement : Pour résoudre ce problème, nous vous recommandons de corriger la cause première et de rétablir l'état opérationnel de Cortex ou de résoudre les problèmes de connectivité réseau. Attendez ensuite que le WAL de Prometheus soit vidé. Vous ne perdez pas de données, mais si Cortex était hors service, le nœud n'est pas disponible pendant la période nécessaire à la récupération de Cortex.

Vous pouvez également réduire l'échelle de Prometheus STS à zéro et supprimer le PV. Cette action réduit la durée totale d'indisponibilité du nœud, mais entraîne une perte de données. De plus, tant que Cortex reste hors service ou que vous rencontrez des problèmes de connectivité réseau, vous devez répéter cette action périodiquement. Tant qu'un problème de connexion entre Prometheus et Cortex persiste, le PV se remplit à nouveau.

Pour réduire l'échelle de Prometheus STS à zéro et supprimer le volume persistant, procédez comme suit :

  1. Réduisez la capacité du composant logmon-operator :

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG scale deployment -n obs-system logmon-operator --replicas 0

    Remplacez ORG_SYSTEM_KUBECONFIG par le chemin d'accès au fichier kubeconfig dans le cluster système de l'organisation.

  2. Réduisez le composant anthos-prometheus-k8s :

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG scale statefulset -n obs-system anthos-prometheus-k8s --replicas 0

  3. Supprimez la demande de volume persistant :

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG delete pvc -n obs-system anthos-prometheus-k8s-data-anthos-prometheus-k8s-0

  4. Effectuez à nouveau un scaling à la hausse de logmon-operator :

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG scale deployment -n obs-system logmon-operator --replicas 1

  5. Attendez que anthos-prometheus-k8s soit prêt.

Bootstrap multizone

Rôles de cluster manquants

Versions : 1.13.1

Symptômes : aucun rôle spécifique pour l'amorçage multizone à utiliser dans Ajouter les rôles requis.

Solution : Utilisez le rôle de cluster cluster-admin comme indiqué dans les instructions associées. Cela donne à l'utilisateur plus que le niveau d'accès minimum requis pour effectuer les tâches ultérieures.

Ressource Bootstrap incompatible

Versions : 1.13.1

Symptômes : La ressource Bootstrap créée à l'étape 3 de la section Créer le fichier d'amorçage est incompatible avec la logique qui la traite.

Solution : Modifiez le fichier YAML généré comme indiqué à l'étape 4.

La ressource GlobalAPIZone n'est pas créée dans l'API globale.

Versions : 1.13.1

Symptômes : le plan de contrôle ne crée pas de ressource GlobalAPIZone pour la zone dans l'API globale, ce qui empêche les composants qui s'appuient sur cette ressource de fonctionner correctement.

Solution : Créez la ressource comme indiqué dans Créer une ressource GlobalAPIZone.

Mise en réseau

Le réseau de nœuds de stockage d'objets est hors service

Versions : 1.13.1, 1.13.3, 1.13.4

Symptômes :

  1. Pendant la phase d'amorçage du stockage d'objets, l'interface utilisateur de l'outil d'installation du nœud d'administration OBJ indique que le réseau de grille est hors service.
  2. cables.csv et Cell CR indiquent que la valeur MPN dans cables.csv est QSFP-100G-CU2.5M pour les connexions entre les nœuds objsadmin de stockage d'objets et le commutateur TOR.

Explication Dans la version 1.13, le champ MPN du fichier cables.csv est utilisé pour déterminer la vitesse définie sur le commutateur Tor. Si la vitesse n'est pas définie sur ces ports, la connectivité du nœud objsadmin du commutateur Tor échouera. La liste utilisée pour mapper le numéro de pièce du fabricant à la vitesse ne tenait pas compte d'une valeur fournie par l'intégrateur système, ce qui a entraîné l'échec de l'amorçage du stockage d'objets. Dans la plupart des configurations 1.13, le fournisseur utilisé est QSFP-100G-CU2.5M.

Solution :

  1. Utilisez kubectl get -A cell -oyaml sur le cluster root-admin pour trouver la connexion associée à l'appliance de stockage d'objets et au commutateur TOR.
  2. Remplacez toutes les occurrences de "mpn" par "QSFP-100G-CU3M" pour les connexions objsadm → torsw.

Voici un exemple :

    - endA: "ap-aa-torsw01:Eth1/10"
      endB: "ap-aa-objsadm01:e3a"
      cableType: "DAC"
      mpn: "QSFP-100G-CU3M"
      length: "2m"
      color: "Black"

Nœud inaccessible

Versions : 1.13.1, 1.13.3, 1.13.4

Symptômes :

  1. Pendant la phase d'amorçage du réseau, certains commutateurs ne sont pas accessibles.
  2. Lors de la phase d'installation DHCP, certains serveurs ne sont pas accessibles via leur adresse IP iLO.

Solution :

  1. Rechargez les commutateurs de gestion concernés. Pour en savoir plus, consultez le runbook PNET-R0018.

PodCIDR non attribué aux nœuds alors que ClusterCIDRConfig est créé

Versions : 1.13.1

Symptômes : ClusterCIDRConfig est un objet requis pour attribuer PodCIDRs. Bien que le ClusterCIDRConfig ait été créé, le PodCIDRs n'a pas été attribué. Ce problème se produit si un ClusterCIDRConfig est créé en même temps que les pods ipam-controller sont en cours d'amorçage. La création du cluster est bloquée à l'état de réconciliation.

  1. Vérifiez si l'objet ClusterCIDRConfig est créé sur le cluster :

    kubectl --kubeconfig=CLUSTER_KUBECONFIG get clustercidrconfigs -oyaml

    Le résultat peut ressembler à ceci :

    apiVersion: v1
items:
- apiVersion: networking.gke.io/v1alpha1
  kind: ClusterCIDRConfig
  metadata:
    annotations:
      baremetal.cluster.gke.io/managed: "true"
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"networking.gke.io/v1alpha1","kind":"ClusterCIDRConfig","metadata":{"annotations":{"baremetal.cluster.gke.io/managed":"true"},"creationTimestamp":null,"name":"root-admin-control-plane"},"spec":{"ipv4":{"cidr":"172.24.0.0/21","perNodeMaskSize":23},"ipv6":{"cidr":"fd00:1::2:0/112","perNodeMaskSize":119}},"status":{}}
    creationTimestamp: "2024-06-17T05:27:55Z"
    finalizers:
    - networking.kubernetes.io/cluster-cidr-config-finalizer
    generation: 1
    name: root-admin-control-plane
    resourceVersion: "2172"
    uid: d1216fe3-04ed-4356-a105-170d72d56c90
  spec:
    ipv4:
      cidr: 172.24.0.0/21
      perNodeMaskSize: 23
    ipv6:
      cidr: fd00:1::2:0/112
      perNodeMaskSize: 119
kind: List
metadata:
  resourceVersion: ""

  2. Exécutez la commande "describe" pour l'un des objets de nœud du cluster qui est bloqué dans la réconciliation et vérifiez si un événement CIDRNotAvailable est présent sur l'objet de nœud :

    kubectl --kubeconfig=CLUSTER_KUBECONFIG describe node NODE_NAME

    Les événements de sortie peuvent ressembler à ceci :

      Type     Reason            Age                   From             Message
  ----     ------            ----                  ----             -------
  Normal   CIDRNotAvailable  3m22s (x96 over 21h)  cidrAllocator    Node gpc-adhoc-4f533d50vm-worker-node2-zone1 status is now: CIDRNotAvailable
  Warning  ReconcileError    3m22s (x96 over 21h)  ipam-controller  CIDRAssignmentFailed, retrying: failed to get cidrs for node gpc-adhoc-4f533d50vm-worker-node2-zone1, unable to get clusterCIDRs for node gpc-adhoc-4f533d50vm-worker-node2-zone1, no available CIDRs

Solution :

  1. Redémarrez les pods ipam-controller-manager :

    kubectl --kubeconfig=CLUSTER_KUBECONFIG -n kube-system rollout restart ds ipam-controller-manager

  2. Une fois que les pods ipam-controller-manager sont en cours d'exécution, vérifiez si le podCIDR est attribué aux nœuds :

    kubectl --kubeconfig=CLUSTER_KUBECONFIG get nodes -oyaml | grep podCIDR

    Le résultat peut ressembler à ceci :

    podCIDR: 172.24.4.0/23
podCIDRs:
podCIDR: 172.24.2.0/23
podCIDRs:
podCIDR: 172.24.0.0/23
podCIDRs:

Dérive NTP

Versions : 1.13.1

Symptômes : un nœud de VM a dérivé ou l'heure est inexacte après une mise en veille ou une exécution pendant un certain temps.

Solution :

  1. Établissez une connexion SSH au nœud de VM et modifiez le fichier /etc/chrony.conf.
  2. Remplacez la ligne makestep 1.0 3 par makestep 1.0 -1.

  3. Redémarrez le service chronyd :

    systemctl restart chronyd

Vous n'avez besoin d'effectuer cette modification qu'une seule fois pour chaque VM. La modification ne sera pas écrasée.

Pour résoudre rapidement le problème et passer à l'heure suivante, établissez une connexion SSH au nœud de VM et exécutez chronyc -a makestep.

Journaux d'audit SyncServer non analysés

Versions : 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7

Symptômes : Les journaux d'audit du SyncServer ne sont pas correctement analysés par log-remote-logger. Certains journaux d'audit ne seront pas disponibles dans Grafana. Vous pouvez voir des messages d'erreur dans le pod log-remote-logger root-admin, par exemple :

Failed to fetch syncserver audit logs for syncserver-...

Solution : Les journaux d'audit sont toujours disponibles sur le SyncServer. Suivez NTP-P0002 pour accéder à l'interface utilisateur SyncServer et afficher les journaux sous Logs > Events.

Échec de l'extraction de l'image du commutateur

Versions : 1.13.3

Symptômes : un message semblable à celui-ci peut s'afficher sur l'objet SwitchImageHostRequest lorsque vous effectuez une ARM de commutateur ou lorsque vous amorcez le cluster root-admin :

failed to pull or extract image "192.0.2.0:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004

Si vous avez accès à kubectl, utilisez-le pour vérifier si vous rencontrez ce problème :

kubectl --kubeconfig=<path/to/root-admin-kubeconfig> -n gpc-system get switchimagehostrequest -o yaml

Le résultat devrait ressembler à ceci :

kind: SwitchImageHostRequest
metadata:
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    meta.helm.sh/release-name: pnet-core-assets
    meta.helm.sh/release-namespace: pnet-system
  creationTimestamp: "2024-08-20T04:16:36Z"
  generation: 1
  labels:
    app.kubernetes.io/managed-by: Helm
  name: v1.13.0-pnet-aa505d9004
  namespace: gpc-system
  resourceVersion: "149295"
  uid: f6c5b880-3fdb-4679-acd4-840b52998946
spec:
  fromVersion: v1.13.0-pnet-aa505d9004
  toVersion: v1.13.0-pnet-aa505d9004
status:
  conditions:
  - lastTransitionTime: "2024-08-20T05:10:17Z"
    message: ""
    observedGeneration: 1
    reason: TFTPRunning
    status: "True"
    type: TFTPReady
  - lastTransitionTime: "2024-08-20T04:16:36Z"
    message: 'exception: failed to pull images with config images: [{10.249.48.5:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004
      /shared/tftpboot/switch/images}]: failed to pull or extract image "10.249.48.5:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004":
      failed to pull image from source "10.249.48.5:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004":
      GET https://10.249.48.5:10443/v2/gdch-switch/os/manifests/v1.13.0-pnet-aa505d9004:
      NOT_FOUND: artifact gdch-switch/os:v1.13.0-pnet-aa505d9004 not found'
    observedGeneration: 1
    reason: ReconcileBackoff
    status: Unknown
    type: Ready

Solution :

Créez manuellement un fichier SwitchImageHostRequest avec le tag d'image approprié :

  1. Connectez-vous au serveur d'amorçage.

  2. Utilisez gdcloud pour identifier la version correcte de l'image du commutateur :

    release/gdcloud artifacts tree release/oci/ | grep -i gdch-switch

    Le résultat devrait ressembler à ceci :

    │   │   │   │   └── gdch-switch/os:1.13.3-gdch.5385

    D'après ce résultat, la version correcte de l'image du commutateur est 1.13.3-gdch.5385.

  3. Modifiez l'objet SwitchImageHostRequest qui signale l'erreur :

    kubectl --kubeconfig=<path/to/root-admin-kubeconfig> -n gpc-system edit switchimagehostrequest <SWITCH_IMAGE_HOST_REQUEST_NAME>

  4. Modifiez ou remplacez les champs name, fromVersion et toVersion pour qu'ils correspondent à la version attendue de l'image du commutateur. Dans ce cas, il s'agit de 1.13.3-gdch.5385. Consultez le résultat diff suivant, qui illustre les modifications à apporter à l'objet SwitchImageHostRequest.

    kind: SwitchImageHostRequest
metadata:
- name: v1.13.0-pnet-aa505d9004
+ name: 1.13.3-gdch.5385
  namespace: gpc-system
spec:
- fromVersion: v1.13.0-pnet-aa505d9004
+ fromVersion: 1.13.3-gdch.5385
- toVersion: v1.13.0-pnet-aa505d9004
+ toVersion: 1.13.3-gdch.5385

Échec de la communication des pods StatefulSet

Versions : 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7, 1.13.8, 1.13.9, 1.13.10

Problèmes constatés : problèmes ou interruptions de connectivité dus à la suppression d'objets Cilium Endpoint (CEP) qui ne sont pas gérés correctement après le redémarrage des pods StatefulSet. Cela peut entraîner une identité de point de terminaison non gérée, ce qui peut amener les règles réseau à abandonner à tort le trafic légitime. Vous pouvez vérifier les pods concernés en vérifiant l'absence de leur objet CEP correspondant :

kubectl get cep -A | grep [*POD_IP*]

Solution : Redémarrez les pods StatefulSet concernés pour mettre à jour leur UID et actualiser les métadonnées associées :

kubectl rollout restart statefulset [*STATEFULSET_NAME*] -n [*NAMESPACE*]

Problèmes de connectivité aux instances DBS

Versions : 1.13.0, 1.13.1

Symptômes : les instances Database Services (DBS) sont inaccessibles et les clients de base de données affichent des délais d'expiration de connexion.

Ce problème peut être détecté par un autre composant du système qui repose sur DBS. Par exemple, la facturation peut signaler des messages d'erreur tels que les suivants :

DBSE0301: Healthcheck: DB cluster is not healthy. Cannot connect to DBdaemon
DBSE0005: DBDaemon Client Error. secure dbdaemon connection failed: context
deadline exceeded

Solution de contournement : L'échec est dû à un composant du système de mise en réseau qui ne peut pas planifier sur le cluster de services de l'organisation.

  1. Définissez les variables d'environnement suivantes :

    export KUBECONFIG=KUBECONFIG_PATH
export ORG_NAME=ORG_NAME

    Remplacez les éléments suivants :

    • KUBECONFIG_PATH : chemin d'accès au fichier kubeconfig du cluster d'administrateur de l'organisation.
    • ORG_NAME : nom de votre organisation, tel que org-1.

  2. Mettez à jour la configuration du composant réseau pour qu'il puisse être planifié :

    kubectl --kubeconfig=KUBECONFIG_PATH kubectl -n g-ORG_NAME-shared-service-cluster   patch addonconfiguration ang-overrides   --type='json'   -p='[{"op": "replace", "path": "/spec/configs/1/patchContent", "value": "apiVersion: apps/v1\nkind: DaemonSet\nmetadata:\n  name: ang-node\n  namespace: kube-system\nspec:\n  template:\n    spec:\n      containers:\n      - name: angd\n      - name: bgpd\n        env:\n        - name: DISABLE_RECEIVED_ROUTES\n          value: \"true\"\n      tolerations:\n      - operator: \"Exists\"\n        effect: \"NoSchedule\""}]'

La connectivité Mise en réseau est rétablie au bout de quelques minutes.

Le maillage de cluster n'est pas configuré avec des informations zonales

Versions : 1.13.5

Symptômes : une VM ne peut pas se connecter à un cluster de bases de données dans le même projet. La connectivité à l'équilibreur de charge interne est affectée. Ce problème est dû à un Clustermesh qui ne parvient pas à échanger des objets de service entre les clusters en raison d'informations de zone manquantes dans la configuration du nom du cluster.

Solution de contournement : Sur les environnements amorcés en tant que multizones, effectuez manuellement les étapes de contournement suivantes pour que l'équilibreur de charge interne fonctionne :

  1. Sur le cluster d'administrateur de l'organisation, obtenez le nom de la zone :

    ZONENAME="$(kubectl get controlplanes -A -o jsonpath="{.items[0].spec.zone}")"
echo $ZONENAME

    Le résultat peut ressembler à l'exemple suivant :

    zone1

  2. Sur le cluster d'administrateur de l'organisation, obtenez l'ID du site de la zone :

    SITEID="$(kubectl -n mz-system get zones $ZONENAME -o jsonpath="{.spec.siteID}")"
echo $SITEID

    Le résultat peut ressembler à l'exemple suivant :

    1

  3. Répertoriez tous les clusters :

    ​​kubectl get clusters -A

    Le résultat peut ressembler à l'exemple suivant :

    NAMESPACE                        NAME                     ABM VERSION        DESIRED ABM VERSION   CLUSTER STATE
g-org-1-shared-service-cluster   g-org-1-shared-service   1.30.0-gke.1592    1.30.0-gke.1592       Running
org-1-system-cluster             org-1-system             1.30.0-gke.1592    1.30.0-gke.1592       Running
user-vm-1-cluster                user-vm-1                1.16.11            1.16.11               Running
user-vm-2-cluster                user-vm-2                1.28.700-gke.150   1.28.700-gke.150      Running

  4. Pour chaque cluster, construisez le CILIUM_CLUSTERNAME :

    CLUSTER_NAME=CLUSTER_NAME
CILIUM_CLUSTERNAME=$CLUSTERNAME-zone$SITEID
echo $CILIUM_CLUSTERNAME

    Le résultat peut ressembler à l'exemple suivant :

    org-1-system-zone1

  5. Pour chaque cluster, définissez les autres paramètres comme suit. Exemple suivant pour org-1-system :

    CLUSTER_NAMESPACE=org-1-system-cluster
CLUSTER_VERSION=1.30.0-gke.1592

  6. Pour chaque cluster, créez un objet AddOnConfiguration et stockez-le dans un fichier addonconfig.yaml. Créez ce fichier pour tous les clusters existants et pour tous les nouveaux clusters que vous créerez à l'avenir :

    Sur cette page, définissez les variables suivantes pour mettre à jour l'exemple de code suivant :

    CLUSTER_NAMESPACE=CLUSTER_NAMESPACE
CLUSTER_VERSION=CLUSTER_VERSION
CILIUM_CLUSTERNAME=CILIUM_CLUSTERNAME

    apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: AddOnConfiguration
metadata:
  name: cilium-addon
  namespace: CLUSTER_NAMESPACE
spec:
  anthosBareMetalVersions:
  - CLUSTER_VERSION
  configs:
  - name: cilium-config
    namespace: kube-system
    apiVersion: v1
    kind: ConfigMap
    patchContent: |
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cilium-config
        namespace: kube-system
      data:
        cluster-name: CILIUM_CLUSTERNAME

  7. Appliquez addonconfig.yaml au cluster d'administrateur de l'organisation :

    kubectl apply -f addonconfig.yaml

  8. Sur les clusters système, de service et d'utilisateur, assurez-vous que cluster-name est mis à jour dans cilium-config sur le cluster. La mise à jour peut prendre un certain temps, mais cette étape est nécessaire avant de redémarrer le déploiement clustermesh-apiserver.

    kubectl get configmap -n kube-system cilium-config -o jsonpath="{.data.cluster-name}" && echo

  9. Sur les clusters système, de service et d'utilisateur, redémarrez le déploiement clustermesh-apiserver :

    kubectl rollout restart deployment -n kube-system clustermesh-apiserver

Des adresses IP EVPN incorrectes sont générées

Versions : 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7

Symptômes : les adresses IP d'appairage des sessions d'interconnexion EVPN multizones (MZ) générées par le système HAMS (Hardware Asset Management System) ne se terminent pas par .65 ni par .66, ce qui est incorrect et empêche l'établissement des sessions BGP EVPN MZ.

Solution :

Pour résoudre manuellement ce problème, procédez comme suit :

  1. Répertoriez toutes les ressources InterconnectSession :

    kubectl get interconnectsession -n gpc-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfig | grep zoneevpnpeering

  2. Examinez les ressources InterconnectSession multizones EVPN générées qui ont une valeur interconnectType de ZonePeering et une valeur addressFamily de EVPN :

    apiVersion: system.private.gdc.goog/v1alpha1
kind: InterconnectSession
metadata:
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
  creationTimestamp: null
  name: interconnect-session-am-aa-blsw01-zoneevpnpeering-3
  namespace: gpc-system
  labels:
    system.private.gdc.goog/ipv4-session-name-1: interconnect-session-am-aa-blsw01-zoneipv4peering-3
spec:
  interconnectLinkRef:
    name: interconnect-am-aa-blsw01-zoneevpnpeering-3
    namespace: gpc-system
  interconnectType: ZonePeering
  peerIP: 192.168.203.67
  md5HashKey: ""
  peerASN: 65402
  addressFamily: EVPN
status: {}

  3. Pour chacune des ressources InterconnectSession correspondant à ces paramètres, appliquez la correction suivante :

    1. Vérifiez le nom de ressource personnalisé de la session d'interconnexion.
    2. Si le nom se termine par un nombre impair, remplacez la dernière partie de l'adresse IP du pair par 65 à l'aide de la commande de l'étape suivante.
    3. Si le nom se termine par un nombre pair, remplacez la dernière partie de l'adresse IP du pair par 66 à l'aide de la commande de l'étape suivante.

  4. Modifiez la ressource InterconnectSession avec l'adresse IP du pair incorrecte :

    kubectl edit interconnectsession
interconnect-session-zy-aa-blsw01-zoneevpnpeering-1 -n gpc-system
--kubeconfig=/root/release/root-admin/root-admin-kubeconfig

  5. Appliquez cette correction à toutes les ressources InterconnectSession qui sont à l'origine de l'erreur.

Le tableau de bord du plan de contrôle réseau supérieur n'affiche aucune donnée

Versions : 1.13.7

Symptômes : les requêtes Prometheus dans TestUpperNetworkingMetrics échouent en raison de métriques manquantes dans le cluster org-1-system. Les panneaux clustermesh du tableau de bord du plan de contrôle de mise en réseau supérieur pour les administrateurs d'organisation d'E/S n'affichent aucune donnée. Le problème provient d'une incohérence dans le libellé source_cluster entre Cilium et le système de surveillance.

Solution : Supprimez le filtre source_cluster du tableau de bord du plan de contrôle UNET pour afficher les données.

Erreurs de diversion affichées lors de l'installation du réseau

Versions : 1.13.1

Problèmes constatés : des messages d'avertissement concernant le câblage s'affichent lors de l'installation du réseau. Exemple :

  W0725 18:01:19.127111   39319 switch_port.go:59] Got error on getting port speed for la-ac-mgmtsw01:Eth1/46<>la-ac-base03:ilo: no speed associated with cable model: 31342 (CAT6 5ft Black)
  W0725 18:01:19.127127   39319 switch_port.go:59] Got error on getting port speed for la-ac-mgmtsw01:Eth1/33<>la-ac-bm21:LOM1: no speed associated with cable model: 03982 (CAT6 4ft Black)

Vous pouvez ignorer ces messages d'erreur sans problème.

La création d'un PNP "allow-all-egress" refuse le trafic inattendu

Versions :

Toutes les versions de Google Distributed Cloud (GDC) sous air gap peuvent être affectées.

Symptômes : la règle de réseau du projet allow-all-egress autorise le trafic vers les points de terminaison du projet et les points de terminaison externes au cluster, mais pas vers les points de terminaison système. Ce problème peut entraîner le blocage de l'accès au système et aux services propriétaires, tels que la résolution DNS et le stockage d'objets.

Le PNP allow-all-egress peut se présenter comme suit :

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-all-egress
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
  egress:
  - {}

Solution : Supprimez le PNP allow-all-egress. Par défaut, une fois la protection contre l'exfiltration de données désactivée, le trafic est autorisé vers les points de terminaison de projet et externes en dehors des points de terminaison de cluster et système.

kubectl delete pnp  [*ALLOW_ALL_EGRESS_PNP_NAME*] -n [*NAMESPACE*]

Stockage d'objets

Impossible de supprimer l'organisation de stockage

Versions : 1.13.1

Symptômes : il est possible que la suppression d'une organisation échoue en raison d'un problème qui empêche la suppression de la SVM de se terminer. Un avertissement semblable au suivant peut s'afficher :

Warning StorageOrganizationDeletion 49m (x97
over 23h) StorageOrganization Reconcile error for storage org
deletion: cannot delete storage organization resources, pre-checks failed:
subnet claim "poc2/poc2-admin-svm-mgmt-network-subnet" exists,
cannot continue before it is deleted

Certains avertissements de mise à niveau de l'espace de stockage d'objets peuvent être ignorés

Versions : 1.13.3

Problèmes constatés : lorsque vous mettez à niveau le stockage d'objets, un avertissement semblable à celui-ci peut s'afficher :

Type     Reason          Age                From                              Message
  ----     ------          ----               ----                              -------
  Warning  ReconcileError  55m (x2 over 55m)  ObjectStorageAdminNodeReconciler  Reconcile error, retrying: error storing the ssh creds: 500 Internal Server Error:ErrorMessage: {"text":"The GDU service is currently busy. Try again later. Contact technical support if the issue persists.","key":"maintenance.gdu.gdu_server_locked

Solution :

  1. Vérifiez que chaque nœud dispose d'identifiants SSH correspondants stockés dans un secret.

    1. Vérifiez les nœuds d'administrateur :

      kubectl get objectstorageadminnodes -o json | jq -r '.items[].metadata.name' | while read -r nodeName; do kubectl get secret -n gpc-system $nodeName-ssh-creds; done

    2. Vérifiez les nœuds de stockage :

      kubectl get objectstoragestoragenodes -o json | jq -r '.items[].metadata.name' | while read -r nodeName; do kubectl get secret -n gpc-system $nodeName-ssh-creds; done

      Voici un exemple de résultat positif pour les nœuds de stockage :

      NAME                                      TYPE     DATA   AGE
gpcstgecn01-gce-gpcstgesite01-ssh-creds   Opaque   2      3d23h
NAME                                      TYPE     DATA   AGE
gpcstgecn02-gce-gpcstgesite01-ssh-creds   Opaque   2      3d23h
NAME                                      TYPE     DATA   AGE
gpcstgecn03-gce-gpcstgesite01-ssh-creds   Opaque   2      3d23h

      Si aucun secret n'est trouvé, l'erreur se présente comme suit :

      Error from server (NotFound): secrets "gpcstgeadm02-gce-gpcstgesite01-ssh-creds" not found

  2. Si la commande ne renvoie aucune erreur, vous pouvez ignorer sans risque les erreurs signalées par les réconciliateurs.

ObjectStorageStorageNodeReconciler rapports maintenance.gdu.gdu_server_locked

Versions : 1.13.3

Problèmes constatés : affiche les détails de objectstoragestoragenode :

kubectl describe objectstoragestoragenode zv-aa-objs02

Le résultat devrait ressembler à ceci :

Events:
  Type     Reason          Age                    From                                Message
  ----     ------          ----                   ----                                -------
  Warning  ReconcileError  54m (x2 over 54m)      ObjectStorageStorageNodeReconciler  Reconcile error, retrying: error storing the ssh creds: 500 Internal Server Error:ErrorMessage: {"text":"The GDU service is currently busy. Try again later. Contact technical support if the issue persists.","key":"maintenance.gdu.gdu_server_locked"}

Solution : vous pouvez ignorer ce problème. Le service GDU peut se verrouiller temporairement lorsqu'il reçoit trop de requêtes, mais il se déverrouille au bout de quelques minutes.

Échec de la vérification du stockage d'objets lors de la mise à niveau de Postflight 1.12.x vers 1.13.x

Versions : 1.13.x

Symptôme : l'échec de la mise à niveau ObjectStorageUpgrade CR avec l'erreur

Message:               check "ObjectStorageUpgrade" of operable component "OBJ" failed with reason "BackoffLimitExceeded", please check logs in pods: [gpc-system/upgrade-managed-check-objectstorageupgrade] 
Observed Generation:   2
Reason:                PostflightCheckFailed

Les pods gpc-system/upgrade-managed-check-objectstorageupgrade échouent avec l'erreur

Error: check "ObjectStorageUpgrade" preflight check failed: ObjectStorageSite gce-gpcstgesite01 not ready                                                                      │
  Usage:                                                                                                                                                                         │
    managed [flags]                                                                                                                                                              │
  Flags:                                                                                                                                                                         │
        --component_name string              preflight check name                                                                                                                │
        --current_version string             current version of the Organization                                                                                                 │
    -h, --help                               help for managed                                                                                                                    │
        --organization-upgrade-name string   the name of current OrganizationUpgrade                                                                                             │
        --target_version string              target version of the Organization                                                                                                  │
  F1023 06:18:01.122723       1 main.go:80] check "ObjectStorageUpgrade" preflight check failed: ObjectStorageSite gce-gpcstgesite01 not ready                                   │
  goroutine 1 [running]:

Cause première : la mise à niveau du composant opérationnel Object Storage de la version 1.12.x vers la version 1.13.x échoue si le cluster KIND d'amorçage n'a pas été désactivé ni supprimé. Même si la mise à niveau réussit, les services de stockage d'objets courants, tels que la création de buckets ou d'identifiants S3 via Kubernetes RBAC, peuvent échouer en raison d'erreurs de validation de certificat TLS. En effet, un pod de stockage d'objets spécifique au sein du cluster KIND tente en permanence d'installer le certificat de serveur TLS du point de terminaison de gestion StorageGRID, qui était valide dans la version 1.12.x, mais qui peut ne pas être reconnu dans la version 1.13.x. Lors de la mise à niveau, StorageGRID installe un nouveau certificat de serveur TLS vérifiable, mais le pod du cluster KIND le remplace par l'ancien certificat non valide, ce qui provoque l'erreur de certificat TLS.

Solution de contournement : Les conditions suivantes doivent être remplies :

  • Mise à niveau du stockage d'objets de la version 1.12.x vers la version 1.13.x
  • Le cluster d'amorçage (cluster KIND) existe toujours.

Procédez comme suit :

  1. Obtenez un kubeconfig qui dispose des autorisations d'affichage et de modification pour la ressource ObjectStorageSite dans le cluster d'amorçage (le cluster KIND).

  2. Définissez un alias pour kubectl se connectant au cluster d'amorçage (cluster KIND) :

    alias kubectlkind="kubectl --kubeconfig <Full path to the kubeconfig of the bootstrapping cluster>

  3. Récupérez l'instance de ressource personnalisée ObjectStorageSite à partir du cluster d'amorçage. Il doit y avoir une instance de ressource ObjectStorageSite :

    SITENAME=$(kubectlkind get ObjectStorageSite -A -o jsonpath='{.items[0].metadata.name}')

  4. Ajoutez une annotation de suspension du stockage d'objets à l'instance de ressource ObjectStorageSite :

    kubectlkind annotate ObjectStorageSite "${SITENAME:?}" storagegrid.netapp.storage.private.gdc.goog/paused=true

  5. Vérifiez que l'annotation de suspension du stockage d'objets a été ajoutée à l'instance ObjectStorageSite :

    kubectlkind get ObjectStorageSite "${SITENAME:?}" -o jsonpath='{.metadata.annotations}' | jq

  6. Acquérir un kubeconfig disposant d'un accès en lecture et d'une autorisation de modification de l'état pour les ressources ObjectStorageCluster dans le cluster d'administrateur racine.

  7. Définissez un alias pour kubectl se connectant au cluster d'administrateur racine :

    alias kubectlrootadmin="kubectl --kubeconfig <Full path to the kubeconfig of the root admin >"

  8. Vérifiez si une instance de ressource ObjectStorageCluster existe dans le cluster d'administration racine :

    kubectlrootadmin get ObjectStorageCluster

    Si aucune instance de ressource ObjectStorageCluster n'est disponible, la solution de contournement est terminée. Vous devrez peut-être effectuer à nouveau la procédure de mise à niveau d'Object Storage.

  9. Récupérez l'URL du point de terminaison de gestion à partir de l'état de la ressource ObjectStorageSite dans le cluster d'amorçage :

    MGMT_ENDPOINT=$(kubectlkind get ObjectStorageSite -o jsonpath='{.items[0].status.managementAPIEndpointURL}')

  10. Vérifiez si la variable d'environnement $MGMT_ENDPOINT a été définie. Le point de terminaison doit commencer par https:// :

    echo ${MGMT_ENDPOINT:?}

  11. N'effectuez les étapes restantes que s'il existe exactement une instance de ressource ObjectStorageCluster dans le cluster d'administrateur racine. Dans le cas contraire, effectuez à nouveau la procédure de mise à niveau du stockage d'objets :

    kubectlrootadmin patch ObjectStorageCluster <the name of ObjectStorageCluster> --type=merge --subresource status --patch "status: {managementAPIEndpointURL: '${MGMT_ENDPOINT:?}'}"

  12. Redémarrez le pod gpc-system/obj-infra-cluster-cm :

    kubectlrootadmin rollout restart deployment -n gpc-system obj-infra-cluster-cm-backend-controller

  13. Vérifiez si le point de terminaison de gestion a été ajouté à l'état de la ressource ObjectStorageCluster :

    kubectlrootadmin get ObjectStorageCluster -o jsonpath='{.items[0].status}' | jq

  14. Redémarrez le contrôle post-vol en supprimant le job Kubernetes de contrôle post-vol gpc-system/upgrade-managed-check-objectstorageupgrade-<random suffix>. La tâche sera recréée prochainement.

Nœud non accessible sur le réseau de données

Il s'agit d'un problème rare qui peut se produire si le pod anetd est pris dans une boucle de plantage.

Une ressource de noyau essentielle à la connectivité des nœuds peut rester bloquée dans un état corrompu.

Ce guide décrit les symptômes de ce problème, ainsi que les étapes à suivre pour le résoudre.

Versions :

Toutes les versions de Google Distributed Cloud (GDC) sous air gap peuvent être affectées.

Symptômes :

Si ce problème se produit, vous pouvez rencontrer les symptômes suivants :

  • Nœuds bloqués à l'état NotReady
  • La description du nœud affiche le message kubelet:kubelet was found unhealthy; repair flag : true.
  • L'accès SSH au nœud n'est pas possible sur le réseau de données.

Solution :

Suivez les instructions ci-dessous pour réparer chaque nœud défaillant :

  1. Obtenez l'adresse IP de gestion du nœud concerné :

    kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get -n gpc-system servers/NODE_NAME -ojsonpath='{.spec.managementNetwork.ips[0]}'

  2. Obtenez un accès SSH au nœud concerné.

  3. Connectez-vous au nœud à l'aide de SSH en utilisant l'adresse IP de gestion du nœud.

  4. Sur le nœud, exécutez la commande suivante, puis fermez la connexion SSH :

    tc filter del dev bond0 egress

  5. Redémarrez le daemonset anetd pour le cluster avec le nœud concerné :

    kubectl --kubeconfig AFFECTED_CLUSTER_KUBECONFIG rollout restart ds/anetd -n kube-system

    Le certificat du point de terminaison de l'équilibreur de charge StorageGRID a expiré

Versions : 1.13.10, 1.13.11, 1.13.12

Symptômes : le proxy de stockage d'objets renvoie une erreur 502 Bad Gateway.

Solution : suivez OBJ-T0003.

Système d'exploitation

Pods bloqués à l'état init

Versions : 1.13.1

Symptômes : le nœud est signalé comme prêt, mais l'accès SSH au nœud est lent et top -n 1 affiche plus de 100 processus zombies.

Solution :

  1. Suivez la procédure OS-P0001 pour vider le serveur. La décharge peut prendre plus de 20 minutes. Si la batterie ne se décharge pas au bout d'une heure, passez à l'étape suivante.

  2. Redémarrez le serveur en établissant une connexion SSH avec celui-ci et en exécutant la commande suivante :

    systemctl reboot

  3. Un deuxième redémarrage peut être nécessaire pour restaurer complètement le serveur.

  4. Vérifiez que l'accès SSH n'est plus lent et que le nombre de processus zombies est beaucoup plus faible (de préférence inférieur à 30).

  5. Annulez la vidange du serveur en définissant maintenance sur false sur le serveur.

bm-system-machine-preflight-check Échec du job Ansible pour un nœud bare metal ou de VM

Versions : 1.13.1

Problèmes constatés : le module de noyau nf_tables n'est pas chargé après le redémarrage, ce qui entraîne l'échec des tâches Ansible du cluster avec une erreur Either ip_tables or nf_tables kernel module must be loaded. Ce problème se produit lorsque le nœud bare metal ou de VM est redémarré avant d'être entièrement provisionné. Le job Ansible peut générer une erreur comme celle-ci :

fatal: [172.20.128.23]: FAILED! => {"changed": false, "msg": "following are the error messages for each failed preflight check {'check_netw
orking_kernel_module_pass': 'Either ip_tables or nf_tables kernel module must be loaded. Use the command \"modprobe <ip_tables OR nf_tables
>\" to load the module.'}"}

Solution :

Établissez une connexion SSH avec le nœud et exécutez la commande suivante :

modprobe nf_tables

VM sans espace disponible sur l'appareil

Versions : 1.13.1, 1.13.3, 1.13.4, 1.13.5

Problèmes constatés : lorsque le répertoire de journaux /var/log est plein, Node peut rester bloqué à l'état NotReady et les pods peuvent ne pas démarrer en raison de l'erreur no space left on device. Pour le vérifier, exécutez la commande suivante sur le nœud et vérifiez si l'utilisation est d'environ 100 %.

df -h /var/log
Filesystem                     Size  Used Avail Use% Mounted on
/dev/mapper/rocky-rl--var_log   15G   15G   20K 100% /var/log

Solution :

  1. Connectez-vous au nœud qui rencontre le problème et supprimez les anciennes archives de journaux pour /var/log/messages.

    find /var/log -name "messages*" -mtime +4 -delete

    Nous vous recommandons également de continuer à appliquer la solution de contournement suivante pour éviter que cela ne se produise. La solution de contournement consiste à créer un AnsiblePlaybook et à appliquer la modification via un CR OSPolicy personnalisé chargé de configurer en toute sécurité l'OS cible (machines BM et VM). Pour en savoir plus, consultez la procédure OS-P0005.

  2. Définissez les variables d'environnement suivantes :

    export KUBECONFIG=<the path to the kubeconfig file>

  3. Créez un playbook Ansible pour la solution de contournement :

    kubectl --kubeconfig=${KUBECONFIG:?must be set} apply -f - <<EOF
apiVersion: system.private.gdc.goog/v1alpha1
kind: AnsiblePlaybook
metadata:
  name: update-logrotate
  namespace: gpc-system
spec:
  playbook: |
    - name: Set the default context for the /etc/kubernetes path to etc_t
      hosts: all
      gather_facts: no
      tasks:
        - name: Change log rotation for /var/log/messages
          block:
            - name: Check if /etc/logrotate.d/syslog exists
              check_mode: false
              ansible.builtin.stat:
                path: '/etc/logrotate.d/syslog'
              register: syslog_exists
            - name: Comment out /var/log/messages lines in syslog
              ansible.builtin.replace:
                path: '/etc/logrotate.d/syslog'
                regexp: '^/var/log/messages'
                replace: '# /var/log/messages'
              when: syslog_exists.stat.exists
            - name: Change logrotate config for /var/log/messages
              ansible.builtin.blockinfile:
                path: '/etc/logrotate.d/syslog'
                block: |
                  /var/log/messages
                  {
                      daily
                      rotate 4
                      missingok
                      notifempty
                      sharedscripts
                      postrotate
                          /usr/bin/systemctl kill -s HUP rsyslog.service >/dev/null 2>&1 || true
                      endscript
                  }
              when: syslog_exists.stat.exists
EOF

  4. Identifiez les inventaires cibles auxquels appliquer la modification. La cible peut être un InventoryMachine individuel ou un NodePool. Consultez la procédure OS-P0005 (2. Pour en savoir plus, consultez "Identifier l'inventaire cible pour les configurations d'exécution".

    L'exemple OSPolicy suivant inclut deux inventaires cibles sous spec.inventory. Vous pouvez ajouter d'autres inventaires si nécessaire.

    kubectl --kubeconfig=${KUBECONFIG:?must be set} apply -f - <<EOF
apiVersion: system.private.gdc.goog/v1alpha1
kind: OSPolicy
metadata:
  name: manual-update-logrotate
  namespace: gpc-system
spec:
  inventory:
  - apiVersion: baremetal.cluster.gke.io/v1
    kind: NodePool
    name: control-plane-node-pool
    namespace: org-1-system-cluster
  - apiVersion: baremetal.cluster.gke.io/v1
    kind: NodePool
    name: control-plane-node-pool
    namespace: user-vm-1-cluster
  policy:
    installPlaybook:
      name: update-logrotate
EOF

  5. Validation

    Consultez la procédure OS-P0005 (validation) pour suivre l'état d'exécution de la règle.

Pods bloqués à l'état ContainerCreating

Versions : 1.13.3, 1.13.5, 1.13.6

Symptômes : un nœud est indiqué comme étant sain, mais de nombreux pods sont bloqués dans un état ContainerCreating et vous ne pouvez pas établir de connexion SSH au serveur.

Solution de contournement : Redémarrez le serveur et vérifiez que vous pouvez établir une connexion SSH au nœud lorsqu'il redémarre.

Impossible de se connecter en SSH au nœud provisionné

Versions : 1.13.5

Symptômes : un nœud est provisionné, mais le délai d'attente du protocole SSH est dépassé pour les adresses IP de gestion et de données.

Solution : Redémarrez le nœud via iLO. Une fois qu'il a démarré, connectez-vous en SSH et désactivez clamonacc avec systemctl stop clamonacc; systemctl disable clamonacc.

Les nœuds Bare Metal ne parviennent pas à démarrer à partir de la dernière image d'OS, car le démarrage sécurisé ne reconnaît pas la signature de l'OS

Versions : 1.13.12

Symptômes : Après la mise à niveau vers la version 1.13.12, si le nœud est redémarré, l'OS ne parvient pas à démarrer avec le nouveau noyau. L'écran de la console iLO affiche un problème lié au démarrage sécurisé :

../../grub-core/loader/i386/efi/linux.c:385:(hd0,gpt2)/vmlinuz-4.18.0-425.131.e.18.ciqfipscompliant.40.1.x86_64 has invalid signature,..:
 ../../grub-core/loader/i386/efi/linux.c:256: you need to load the kernel first.

Solution :

  1. Pour tout nœud qui ne parvient pas à démarrer en raison de ce problème, accédez à l'écran GRUB via la console iLO et sélectionnez Rocky Linux 4.18.0-425.131.e.18.ciqfipscompliant.38.1.x86_64 comme cible de démarrage. Cette procédure permet au nœud de démarrer avec le dernier bon noyau connu.

  2. Pour tous les serveurs Bare Metal mis à niveau vers la version 1.13.12 de GDC, procédez comme suit pour éviter l'échec du démarrage :

    1. Établissez une connexion SSH au serveur.
    2. Exécutez les commandes suivantes sur le serveur pour supprimer le noyau problématique :
    dnf remove kernel-core-4.18.0-425.131.e.18.ciqfipscompliant.40.1.x86_64
    1. Vérifiez que le noyau par défaut a bien été rétabli sur une version fonctionnelle connue :
    grubby --default-kernel

Le résultat est /boot/vmlinuz-4.18.0-425.131.e.18.ciqfipscompliant.38.1.x86_64.

Infrastructure de la suite Operations (OI)

La SSA n'est pas nécessaire pour le matériel 3.0

La configuration de l'adaptateur RAID est différente pour le matériel 3.0. Les serveurs OIC Hardware 3.0 utilisent un disque auto-chiffré. Il n'est donc plus nécessaire de lancer Smart Storage Administration (SSA). Des étapes supplémentaires sont nécessaires pour déterminer les identifiants de disque pour chaque serveur. Consultez Amorçage du serveur OI.

Sécurité du périmètre

Le cluster du système de l'organisation est bloqué lors de l'amorçage de l'organisation

Versions : 1.13.1

Problèmes constatés : lors de l'amorçage de l'organisation, le cluster système de l'organisation peut se bloquer. Les pods edr-sidecar-injector sont à l'état "En attente". Lorsque vous essayez de supprimer ces pods, un message d'erreur semblable à celui-ci peut s'afficher :

Delete failed with `Internal error occurred: failed calling webhook "validation.gatekeeper.sh": failed to call webhook: Post "https://gatekeeper-webhook-service.opa-system.svc:443/v1/"

En même temps, certains autres pods en attente peuvent comporter des messages d'erreur tels que celui-ci :

Error creating: Internal error occurred: failed calling webhook "edr-sidecar-injector.gpc-system.internal": failed to call webhook: Post "https://edr-sidecar-injector.gpc-system.svc:443/mutate?timeout=10s": dial tcp 172.20.3.222:443: connect: connection refused

Le système nécessite une intervention manuelle pour se déverrouiller.

Solution :

  1. Dupliquez le CR MutatingWebhookConfiguration edr-sidecar-injector-webhook-cfg sur le cluster système.
  2. Dupliquez le CR ValidatingWebhookConfiguration gatekeeper-validating-webhook-configuration sur le cluster système.
  3. Supprimez les ressources personnalisées edr-sidecar-injector-webhook-cfg et gatekeeper-validating-webhook-configuration du cluster système.
  4. Attendez que les pods edr-sidecar-injector et gatekeeper-controller-manager soient de nouveau opérationnels.
  5. Restaurez le CR du webhook avec la commande kubectl apply.

Les groupes d'adresses de pare-feu PANW ne sont pas mis à jour lorsque les revendications CIDR sont modifiées

Versions : 1.13.1

Symptômes : lors de l'amorçage, l'OCIT cidr-claim est mis à jour avec la valeur correcte, mais pas le pare-feu AddressGroups. Une paire de AddressGroups, plus précisément vsys1-root-ocit-network-cidr-group et ocvsys1-root-ocit-network-cidr-group, utilise des blocs réseau qui ne chevauchent pas ceux réellement utilisés dans OIR. L'OIR ne parvient pas à résoudre les enregistrements de zone GDC et les requêtes expirent sans réponse.

Solution : Après les modifications apportées à cidr-claim, assurez-vous que AddressGroup est mis à jour avec la dernière version de cidr-claim en redémarrant le déploiement fw-core-backend-controller dans l'espace de noms fw-system au niveau du cluster administrateur racine.

Serveurs physiques

Échec du bootstrap du serveur en raison de problèmes de POST sur le serveur HPE

Versions : 1.13.1

Problèmes constatés : l'amorçage du serveur échoue lorsqu'un serveur ne parvient pas à passer le processus de démarrage POST. Lorsque vous vous connectez à l'ILO et que vous vérifiez la console du serveur, l'erreur suivante s'affiche :

Symptom: An Invalid Opcode Exception has occurred indicating
that the processor tried to execute an invalid, undefined opcode,
or an instruction with invalid prefixes.

Causes: This issue is typically a software or firmware issue and
not indicative of a hardware problem

Causes: This issue is typically a software or firmware issue and
not indicative of a hardware problem.

ACTION : Reboot the server.

Solution :

Dans iLO, cliquez sur le bouton Marche/Arrêt, puis sélectionnez Cold Boot.

Serveurs bloqués à l'état de provisionnement

Versions : 1.13.1, 1.13.3, 1.13.5

Problèmes constatés : les serveurs sont bloqués à l'état de provisionnement lors de l'amorçage du serveur. Vérifiez l'état des serveurs :

k get servers -A | grep -v availabl

Le résultat peut ressembler à ceci :

NAMESPACE    NAME         AGE   RACK    MACHINE-CLASS               MANAGEMENT-IP   DATA-IP    DATA-IP   BMC-IP           CLUSTER   NODEPOOL   STATE          PROVISION-READY
gpc-system   ag-aa-bm01   21h   ag-aa   o1-highmem1-40-gdc-metal    192.0.2.0       198.51.100.0         203.0.113.0                         provisioning
gpc-system   ag-ab-bm01   21h   ag-ab   o1-highmem1-40-gdc-metal    192.0.2.0       198.51.100.1         203.0.113.0                         provisioned    true
gpc-system   ag-ac-bm01   21h   ag-ac   o1-highmem1-40-gdc-metal    192.0.2.0       198.51.100.2         203.0.113.0                         provisioning

Solution :

  1. Démarrez manuellement le DHCP avec une configuration téléchargée depuis le cluster KIND. Dans cet exemple, /tmp/dhcp.conf correspond à la configuration DHCP du cluster KIND :

    docker run  -d -it --network host --name dnsmasq -v /tmp/dhcp.conf:/etc/dnsmasq.conf --cap-add=NET_ADMIN --restart always 198.51.100.255/gpc-system-container-images/private-cloud-staging/dnsmasq:VERSION

    Remplacez VERSION par la version de mise à jour, comme décrit dans les instructions de mise à niveau de Mise à niveau manuelle des composants de fichier pour les clusters racine et d'administrateur de l'organisation, par exemple 1.13.1-gdch.525.

  2. Vérifiez la configuration du BIOS sur le serveur et assurez-vous que NetworkBoot n'est pas activé pour les cartes d'interface réseau du plan de données (nommées selon le modèle Slot{i}Nic{i}).

  3. Vérifiez le BIOS par l'appel d'API :

    curl -kv https://{bmcIP}/redfish/v1/Systems/1/bios -u $bmcUser:$bmcPassword

    Où $bmcUser et $bmcPassword sont les mots de passe des ILO, qui se trouvent dans le fichier ou le répertoire cellcfg d'un secret appelé bmc-credentials-<server-name>, par exemple bmc-credentials-ai-aa-bm01. Vérifiez que le résultat de cette commande affiche Slot1Nic1: Disabled.

  4. Si l'un de ces Slot{i}Nic{i} est défini sur NetworkBoot, désactivez-le avec l'API des paramètres du BIOS.

    curl -kv https://{bmcIP}/redfish/v1/Systems/1/bios/settings -u $bmcUser:$bmcPassword -X PATCH -d '{"Attributes": {"Slot{i}Nic{i}":"Disabled"}}' -H 'content-type: application/json'

    Remplacez Slot{i}Nic{i} par le nom de l'emplacement qui pose problème dans la charge utile.

  5. Redémarrez le serveur.

Échec du provisionnement du serveur DL380a

Versions : 1.13.3, 1.13.4, 1.13.5

Symptômes : le provisionnement du serveur échoue au niveau de la tâche de chiffrement pour le modèle HPE DL380a. L'état du CR du serveur est bloqué sur available lors de l'amorçage du serveur :

# server name
export SERVER_NAME=

kubectl --kubeconfig "${KUBECONFIG:?must be set}" get servers ${SERVER_NAME} -n gpc-system

Solution :

  1. Suivez IAM-R0004 pour générer le KUBECONFIG pour le root-admin-cluster.

  2. Suivez PLATAUTH-G0001 pour générer la clé SSH root-id_rsa pour CLUSTER_NS=root.

  3. Mettez le serveur en pause en ajoutant l'annotation server.system.private.gdc.goog/paused à la ressource personnalisée du serveur :

    kubectl --kubeconfig "${KUBECONFIG:?must be set}" annotate server ${SERVER_NAME:?} -n gpc-system --overwrite server.system.private.gdc.goog/paused=''

  4. Connectez-vous au serveur à partir de l'adresse IP de gestion :

    export MGMT_IP=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME:?} -n gpc-system -o=jsonpath='{.spec.managementNetwork.ips[0]}')

ssh $MGMT_IP -i ~/.ssh/root-id_rsa

  5. Activer le chiffrement manuellement :

    /opt/MegaRAID/storcli/storcli64 /call/eall/sall secureerase force

/opt/MegaRAID/storcli/storcli64 /c0 delete securitykey

/opt/MegaRAID/storcli/storcli64 /c0 set securitykey useekms j

    Le résultat des commandes devrait ressembler à ce qui suit :

    root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /call/eall/sall secureerase force
CLI Version = 007.2417.0000.0000 Apr 21, 2023
Operating system = Linux 5.4.0-1072-fips
Controller = 0
Status = Success
Description = Drive Secure Erase Succeeded.

root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /c0 delete securitykey
CLI Version = 007.2417.0000.0000 Apr 21, 2023
Operating system = Linux 5.4.0-1072-fips
Controller = 0
Status = Success
Description = None

Controller Properties :
=====================

------------------------
Ctrl Method     Result
------------------------
  0 delete Key Success
------------------------

root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /c0 set securitykey useekms j
{
"Controllers":[
{
        "Command Status" : {
                "CLI Version" : "007.2417.0000.0000 Apr 21, 2023",
                "Operating system" : "Linux 5.4.0-1072-fips",
                "Controller" : 0,
                "Status" : "Success",
                "Description" : "None"
        },
        "Response Data" : {
                "Controller Properties" : [
                        {
                                "Ctrl" : 0,
                                "Method" : "Set Security using EKMS",
                                "Result" : "Please reboot the system for the changes to take effect"
                        }
                ]
        }
}
]
}

    Si la dernière commande n'a pas abouti ou si des erreurs telles que "Invalid BIOS EKM status" (État EKM du BIOS non valide) s'affichent, essayez de redémarrer le serveur et iLO, puis réexécutez cette étape.

    root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /c0 set securitykey useekms j
{
"Controllers":[
{
        "Command Status" : {
                "CLI Version" : "007.2417.0000.0000 Apr 21, 2023",
                "Operating system" : "Linux 5.4.0-1072-fips",
                "Controller" : 0,
                "Status" : "Failure",
                "Description" : "None",
                "Detailed Status" : [
                        {
                                "Ctrl" : 0,
                                "Method" : "Set Security using EKMS",
                                "Result" : "-",
                                "ErrMsg" : "Invalid BIOS EKM status",
                                "ErrCd" : 255
                        }
                ]
        }
}
]
}

    Si la dernière commande a réussi, redémarrez le serveur comme indiqué.

  6. Créez un lecteur logique manuellement :

    Une fois le serveur redémarré, reconnectez-vous à celui-ci à partir de l'adresse IP de gestion et listez tous les lecteurs disponibles :

    ssh $MGMT_IP -i ~/.ssh/root-id_rsa

/opt/MegaRAID/storcli/storcli64 /c0 show j

    Le résultat de la dernière commande peut ressembler à l'exemple suivant :

    {
  "Controllers":[
  {
    "Command Status" : {
      "CLI Version" : "007.2417.0000.0000 Apr 21, 2023",
      "Operating system" : "Linux 5.4.0-1072-fips",
      "Controller" : 0,
      "Status" : "Success",
      "Description" : "None"
    },
    "Response Data" : {
      "Product Name" : "HPE MR416i-o Gen11",
      "Serial Number" : "******",
      "PCI Slot Number" : 17,
      "SAS Address" : "******",
      "PCI Address" : "00:12:00:00",
      "System Time" : "09/12/2024 23:32:48",
      "Mfg. Date" : "09/15/23",
      "Controller Time" : "09/12/2024 23:32:47",
      "FW Package Build" : "52.26.3-5379",
      "BIOS Version" : "7.26.00.0_0x071A0000",
      "FW Version" : "5.260.03-3985",
      "Driver Name" : "megaraid_sas",
      "Driver Version" : "07.713.01.00-rc1",
      "Current Personality" : "RAID-Mode ",
      "Vendor Id" : 4096,
      "Device Id" : 4322,
      "SubVendor Id" : 5520,
      "SubDevice Id" : 808,
      "Host Interface" : "PCI-E",
      "Device Interface" : "SAS-12G",
      "Bus Number" : 18,
      "Device Number" : 0,
      "Function Number" : 0,
      "Domain ID" : 0,
      "Security Protocol" : "SPDM-1.0.0",
      "Physical Drives" : 8,
      "Drive LIST" : [
        {
          "EID:Slt" : "252:1",
          "DID" : 0,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "1.60 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "MO001600PXVRU   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:2",
          "DID" : 1,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "1.60 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "MO001600PXVRU   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:3",
          "DID" : 2,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:4",
          "DID" : 3,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:5",
          "DID" : 4,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:6",
          "DID" : 5,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:7",
          "DID" : 6,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:8",
          "DID" : 7,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        }
      ],
      "Enclosures" : 1,
      "Enclosure LIST" : [
        {
          "EID" : 252,
          "State" : "OK",
          "Slots" : 8,
          "PD" : 8,
          "PS" : 0,
          "Fans" : 0,
          "TSs" : 0,
          "Alms" : 0,
          "SIM" : 0,
          "Port#" : "2I"
        }
      ]
    }
  }
  ]
}

    Vous devez enregistrer les deux ID EID:Slt avec Size égal à 1.60 TB, dans ce cas :

    252:1,252:2

    Créez ensuite un lecteur logique à l'aide des ID EID:Slt :

    /opt/MegaRAID/storcli/storcli64 /c0 add vd type=raid1 drives=252:1,252:2 SED

    Le résultat de la dernière commande ressemble à ceci :

    /opt/MegaRAID/storcli/storcli64 /c0 add vd type=raid1 drives=252:1,252:2 SED

CLI Version = 007.2417.0000.0000 Apr 21, 2023
Operating system = Linux 5.4.0-1072-fips
Controller = 0
Status = Success
Description = Add LD Succeeded.

  7. Simule l'état du chiffrement du disque dans le CR du serveur.

    Modifiez l'état du CR du serveur :

    kubectl edit-status --kubeconfig "${KUBECONFIG:?must be set}" server ${SERVER_NAME:?} -n gpc-system

    Ajoutez ou modifiez l'état DiskEncryptionEnabled sur "true" :

      - lastTransitionTime: "<time>"
    message: ""
    observedGeneration: 1
    reason: DiskEncryptionJobSucceeded
    status: "True"
    type: DiskEncryptionEnabled

  8. Supprimez le job de chiffrement du serveur, le cas échéant :

    kubectl --kubeconfig "${KUBECONFIG:?must be set}" delete job server-encrypt-and-create-logical-drive-${SERVER_NAME:?} -n gpc-system

  9. Réactivez le serveur pour que le provisionnement reprenne :

    kubectl --kubeconfig "${KUBECONFIG:?must be set}" annotate server ${SERVER_NAME:?} -n gpc-system --overwrite server.system.private.gdc.goog/paused-

L'effacement sécurisé échoue sans licence

Versions : 1.13.5

Symptômes : lorsqu'un serveur est bloqué lors de l'installation, un état semblable à celui-ci peut s'afficher sur le CR du serveur :

- lastTransitionTime: "2024-09-10T20:28:33Z"
   message: 'unable to trigger secure erase: unable to complete secure erase
     for server "zx-ad-bm07": failed to post payload to /redfish/v1/Systems/1/Actions/Oem/Hpe/HpeComputerSystemExt.SecureSystemErase:
     400: {"error":{"code":"iLO.0.10.ExtendedInfo","message":"See @Message.ExtendedInfo
     for more information.","@Message.ExtendedInfo":[{"MessageId":"iLO.2.27.LicenseKeyRequired"}]}}'
   reason: Succeeded
   status: "False"
   type: BMCConfigPreinstallSecureEraseTriggered

Solution de contournement : suivez les instructions du runbook SERV-R0014.

Sécurité de la plate-forme

Le réconciliateur BYO SubCA ne vérifie pas si les certificats ont une clé publique correspondante

Versions : 1.13.1

Symptômes : lorsque le mode PKI BYO SubCA génère une demande de signature de certificat (CSR) alors qu'un certificat signé précédemment est importé dans la SubCA, le reconciler ne vérifie pas si la nouvelle CSR correspond à l'ancien certificat signé et marque la ressource personnalisée (CR) cert-manager CertificateRequest comme Ready. Cela se produit lors du renouvellement ou de la rotation manuelle du certificat de l'autorité de certification intermédiaire. Le contrôleur cert-manager tente de mettre à jour l'état du CR Certificate, ce qui déclenche le message d'erreur suivant :

The certificate request has failed to complete and will be retried: Error signing certificate: error creating x509 │
│  certificate: x509: provided PrivateKey doesn't match parent's PublicKey

Solution :

Suivez les instructions pour importer un nouveau certificat BYO-SubCA signé pour la nouvelle CSR.

Un problème cert-manager empêche l'émission de PKI BYO avec ACME

Versions : 1.13.1

Symptômes : L'échec se produit lors de la première émission ou du premier renouvellement de certificats BYO avec ACME (Automatic Certificate Management Environment). Lorsque vous exécutez la commande pour vérifier l'état du certificat, vous constatez que le certificat est not ready :

kubectl -n istio-system get certificate.pki.security.gdc.goog/default-wildcard-cert

La sortie ressemble à ceci :

status:
  conditions:
  - lastTransitionTime: "2024-07-23T17:27:02Z"
    message: 'reconciling Certificate status failed: cert-manager Certificate CR "default-wildcard-cert-pki-ct"/"pki-system" is not ready'
    observedGeneration: 1
    reason: ReconcileBackoff
    status: "False"
    type: Ready

Solution :

Redémarrez le déploiement cert-manager dans le cluster d'administrateur de l'organisation :

export KUBECONFIG=ORG_ADMIN_KUBECONFIG

kubectl rollout restart deployment/cert-manager -n cert-manager

Resource Manager

L'état du projet n'est pas disponible dans la console GDC

Versions : 1.13.1 et versions ultérieures

Symptômes : la console GDC n'affiche pas l'état d'un projet. Les projets qui ne sont pas à l'état Ready ne peuvent pas accepter de nouvelles ressources ni traiter de nouvelles modifications apportées aux ressources existantes. Étant donné qu'il est impossible de confirmer l'état du projet, on ne sait pas quand les ressources d'un projet peuvent être gérées, ce qui entraîne des erreurs lorsque de nouvelles actions sont tentées.

Solution de contournement : Consultez le runbook RM-R0100 pour imprimer l'état du projet à l'aide de kubectl CLI.

Mettre à niveau

bm-system et d'autres jobs bloqués

Versions : 1.13.1

Problèmes constatés : bm-system et d'autres tâches exécutant le playbook Ansible sont bloquées sur gathering facts.

Solution de contournement : saisissez le nom du nœud bloqué, puis exécutez multipath -ll | grep failed et multipath -ll | grep #. Si le résultat n'est pas vide,suivez les runbooks FILE R0020 et FILE R0021.

Adresse IP de gestion non accessible

Versions : 1.13.1, 1.13.3, 1.13.4, 1.13.5

Problèmes constatés : lors d'une mise à niveau, l'adresse IP de gestion d'un serveur est inaccessible, en particulier après un changement.

Avec Rocky Linux, lorsque des routes statiques sont ajoutées, l'adresse IP de destination utilisée pour atteindre les routes statiques doit être accessible avant l'ajout des routes statiques. Si le commutateur redémarre après une mise à niveau de l'OS, il est possible que cette adresse IP de gestion soit temporairement inaccessible.

Solution de contournement : Établissez une connexion SSH au serveur à l'aide de l'adresse IP des données et redémarrez le service réseau pour recréer les routes statiques manquantes :

systemctl restart NetworkManager.service

Le numéro de version de storagecluster ne s'affiche pas

Versions : 1.13.3

Symptômes : Après une mise à niveau, la ressource personnalisée StorageCluster n'affiche aucune valeur pour le champ d'état StorageVersion.

Vérifiez la version :

kubectl --kubeconfig <var>ROOT_ADMIN_KUBECONFIG</var> get StorageCluster -n gpc-system

Si le champ "Version" est vide, suivez les étapes de la solution de contournement.

Solution : Redémarrez le déploiement file-storage-backend-controller :

kubectl --kubeconfig  <var>ROOT_ADMIN_KUBECONFIG</var> rollout restart deployment -n file-system file-storage-backend-controller

Serveur Bare Metal bloqué à l'état de provisionnement

Versions : 1.13.1

Symptômes :

Le serveur Bare Metal est bloqué à l'état "provisionnement" pendant une longue période lors de la création d'une organisation.

Solution :

Il est possible que la configuration du BIOS du serveur ait changé et que le serveur utilise la mauvaise carte réseau pour le démarrage PXE.

Pour désactiver le démarrage réseau de la carte d'interface réseau du plan de données, procédez comme suit.

  • Accès requis :
    • Vous devez avoir accès aux identifiants d'administrateur BMC des serveurs bloqués.
    • Suivez IAM-R0005 pour obtenir le rôle ClusterRole hardware-admin dans le cluster root-admin pendant une heure.
    • Suivez IAM-R0004 pour générer le fichier KUBECONFIG du cluster root-admin.

  1. Définissez le nom du serveur bloqué.

    export SERVER_NAME=

  2. Définissez l'adresse IP et les identifiants du BMC du serveur.

    export ip=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME:?} -n gpc-system -ojsonpath='{.spec.bmc.ip}')
export BMC_CREDENTIALS_SECRET=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME:?} -n gpc-system -ojsonpath='{.spec.bmc.credentialsRef.name}')
export user=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get secret ${BMC_CREDENTIALS_SECRET:?} -n gpc-system -ojsonpath='{.data.username}' | base64 -d)
export pass=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get secret ${BMC_CREDENTIALS_SECRET:?} -n gpc-system -ojsonpath='{.data.password}' | base64 -d)

  3. Identifiez l'emplacement PCIe de la carte réseau du plan de données sur le serveur.

    kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME} -n gpc-system -o jsonpath={.spec.serverHardware.portBond.nicPortNames}

    Par exemple, le résultat suivant indique que la carte réseau est installée dans l'emplacement 3.

    ["s3p1","s3p2"]

    Définissez la variable PCIEslot :

    export DATA_NIC_SLOT=3

  4. Vérifiez que le démarrage réseau n'est pas désactivé.

    curl -ks -u $user:$pass https://$ip/redfish/v1/systems/1/bios/settings  | jq .Attributes | grep "Slot${DATA_NIC_SLOT}NicBoot1"

    Si le résultat est "NetworkBoot", vous devez le désactiver explicitement.

  5. Utilisez BMC pour désactiver la fonction de démarrage réseau sur la carte réseau du plan de données.

    Dans la commande suivante, remplacez "Slot3" par le numéro de slot réel.

    curl -k -u "$user":"$pass" -H "Content-Type: application/json" https://$ip/redfish/v1/systems/1/bios/settings/ -X PUT --data '{"Attributes":{"Slot3NicBoot1":"Disabled"}}' | jq

    , puis redémarrez la machine.

    curl -k -u "$user":"$pass" -H "Content-Type: application/json" https://$ip/redfish/v1/Systems/1/Actions/ComputerSystem.Reset/ -X POST -d '{"ResetType": "ForceRestart"}' | jq

    Le serveur met 10 à 15 minutes à redémarrer et reprend automatiquement le processus de provisionnement.

La mise à niveau du stockage d'objets affiche une erreur lors de la vérification post-vol ou pré-vol

Versions : 1.13.1

Symptômes : les vérifications préliminaires ou post-vol échouent et affichent une erreur. Vérifiez les journaux :

kubectl logs -n gpc-system upgrade-managed-check-objectstorageupgrade-87698-rrjhrW0410

L'erreur peut se présenter comme suit :

 03:42:05.701163       1 upgrade_check.go:276] 1 error occurred:
      * Group "/rbac.sysstd.role.vm-system.wtwf7txfmbhvujhpxrfampnrkdwqsvzro6i7rmo5tsfst4wbxldq" not ready for RBAC resource {Role vm-system g-vm-image-bucket-reader    }

   Error: check "ObjectStorageUpgrade" preflight check failed: 1 error occurred:
      * Bucket "gpc-system/range-read-internal" not ready

  F0410 03:42:05.701901       1 main.go:80] check "ObjectStorageUpgrade" preflight check failed: 1 error occurred:
      * Bucket "gpc-system/range-read-internal" not ready

Solution :

  1. Si l'erreur se produit lors des vérifications post-vol et que toutes les autres vérifications sont effectuées sans erreur, ignorez les vérifications post-vol. Lorsque la mise à niveau redémarre, vous devez également ignorer les vérifications préliminaires à l'aide du fichier kubeconfig de l'administrateur racine :

    kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-postflight-check=ok && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok

    Par exemple, si l'erreur se produit sur l'organisation 1, la commande se présente comme suit :

    kubectl delete organizationupgrade -n gpc-system org-1 && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-postflight-check=ok && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-preflight-check=ok

  2. Si l'erreur se produit lors des vérifications préliminaires et que toutes les autres vérifications préliminaires sont effectuées sans erreur, ignorez les vérifications préliminaires :

    kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok

    Par exemple, si l'erreur se produit sur l'organisation 1, la commande se présente comme suit :

    kubectl delete organizationupgrade -n gpc-system org-1 && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-preflight-check=ok

Vous devrez peut-être appliquer cette solution plusieurs fois si elle ne fonctionne pas.

Rollbacks de mise à niveau Helm

Versions : 1.13.3

Symptômes : un problème de mise à niveau Helm entraîne une série de rollbacks, ce qui empêche de trouver un Certificate et un ServiceEntry. Un message de ce type peut s'afficher :

REVISION        UPDATED                         STATUS          CHART                                   APP VERSION             DESCRIPTION
91              Thu Jul 18 13:26:42 2024        deployed        iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Upgrade complete
9138            Fri Jul 19 22:21:56 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9139            Fri Jul 19 22:22:04 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9140            Fri Jul 19 22:22:16 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9141            Fri Jul 19 22:22:30 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9142            Fri Jul 19 22:22:35 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9143            Fri Jul 19 22:22:42 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9144            Fri Jul 19 22:22:48 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9145            Fri Jul 19 22:22:56 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9146            Fri Jul 19 22:23:04 2024        failed          iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found

Solution : Suivez les étapes du runbook OCLCM-R0122.

Mise à niveau de nœud ou ABM bloquée, car le pod dhcp-tftp-core-server n'a pas été vidé

Versions : 1.13.3, 1.14.4, 1.14.5

Problèmes constatés : la mise à niveau du nœud peut se bloquer. Dans l'état de la machine Bare Metal, le pod dhcp-tftp-core-server n'est pas vidé. Un message de ce type peut s'afficher :

bareMetalMachineDrainingStatus:
    currentDrainingStage: SystemCriticalPriorityClass
    podsYetToDrain:
    - name: dhcp-tftp-core-server-7ffcfcbb97-6wlg7
      namespace: dhcp-system
      resourceVersion: "5005530"
      uid: f77826ea-1d57-46ff-a699-f42faa36c1d2

Solution : Forcez la suppression du pod dhcp-tftp-core-server-* pour continuer. La commande se présente comme suit :

kubectl delete pod dhcp-tftp-core-server-7ffcfcbb97-6wlg7 -n dhcp-system --force

OrganizationUpgrade est bloqué à l'étape de mise à niveau des nœuds

Versions : 1.13.3

Problèmes constatés : OrganizationUpgrade est bloqué à l'étape de mise à niveau des nœuds. Un message de ce type peut s'afficher :

  Last Transition Time: 2024-08-27T12:37:40Z
    Message:             observed the following reason: [JobRunning]
    Observed Generation: 614
    Reason:              Unsuccessful
    Status:              Unknown
    Type:                service/Node

Solution :

  1. Recherchez les CR upgradetaskrequest dans le cluster racine ka get upgradetaskrequest -n gpc-system. Vérifiez que le nœud est toujours en cours d'exécution. Assurez-vous qu'il est bloqué sur la tâche pour le service.

    spec:
    clusterType: service
Last Transition Time: 024-08-27T12:37:40Z
  Message:            job gpc-system/v1.13.0-os-aa505d9004-upg-task-org-1-os-node-upgra-czwwd is running
  Observed Generation: 1
  Reason:              JobRunning
  Status:              Unknown
  Type:                Succeeded

  2. Créez manuellement des CR nodeupgrade pour chaque revendication de pool de nœuds :

    export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get nodepoolclaims -n g-org-1-shared-service-cluster
NAME                                                     AGE
control-plane-node-pool                                  34d
dbs-billing-system-billing-dbcluster-n2-standard-4-gdc   34d
shared-service-default-worker                            34d

  3. Créez une CR nodeupgrade pour chaque revendication de pool de nœuds. Les détails de l'annotation upgrade.private.gdc.goog/target-release-version doivent être obtenus à partir du nom CRMD OS de la cible :

    kubectl get crmd  --kubeconfig ${ROOT_ADMIN_KUBECONFIG} | grep "os"
os-1.13.1-gdch.525                     35d
os-v1.13.0-os-4175a6dce6               27d
os-v1.13.0-os-aa505d9004               5d18h

  4. Utilisez la version indiquée ici dans les annotations upgrade.private.gdc.goog/target-release-version :

    kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} get crmd os-v1.13.0-os-aa505d9004 -o json | jq -r '.spec.config.vmNodeImage'
rocky-86-1.13-v20240731-1.13-r191

  5. Appliquez le yaml suivant à chaque nodepoolclaim :

        apiVersion: upgrade.private.gdc.goog/v1alpha1
    kind: NodeUpgrade
    metadata:
      annotations:
        upgrade.private.gdc.goog/target-release-version: VERSION
      name: NAME
      labels:
        addon.private.gdc.goog/cluster-type: service
      namespace: NAMESPACE
    spec:
      inFlightConf:
        maxConcurrentNodes: 1
      nodePoolClaimRef:
        name: NAME
        namespace: NAMESPACE
      nodeType: Virtual
      software:
        osImage:
          name: NAME
          version: VERSION

  6. Une fois les nœuds du cluster de service mis à niveau, définissez l'état du CR UpgradeTaskRequest sur "True" (Vrai) pour que la mise à niveau de l'organisation passe à l'étape suivante :

        kubectl patch upgradetaskrequest  upg-task-org-1-os-node-upgrade-task-pckxn --type='json' -p='[{"op": "replace", "path": "/status/conditions/0/status", "value": "True"}]' --subresource=status -n gpc-system --kubeconfig /root/release/root-admin/root-admin-kubeconfig

  7. La mise à niveau de l'organisation devrait maintenant passer à l'étape suivante, et l'état du service ou du nœud sera "Terminé" :

    Last Transition Time: 2024-08-27T22:44:09Z
  Message:             observed the following reason: [JobRunning]
  Observed Generation: 614
  Reason:              Complete
  Status:              True
  Type:                service/Node

Le noyau ne parvient pas à créer un conteneur

Versions : 1.13.3

Symptômes : le noyau ne parvient pas à allouer des cgroup de mémoire, ce qui entraîne des échecs lors de la création de conteneurs.

Un message de ce type peut s'afficher :

Conditions:
  Type                          Status    LastHeartbeatTime                 LastTransitionTime                Reason                          Message
  ----                          ------    -----------------                 ------------------                ------                          -------
  FrequentContainerdRestart     False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentContainerdRestart     containerd is functioning properly
  KernelDeadlock                False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   KernelHasNoDeadlock             kernel has no deadlock
  ReadonlyFilesystem            False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   FilesystemIsNotReadOnly         Filesystem is not read-only
  ContainerRuntimeUnhealthy     False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 10:52:30 +0000   ContainerRuntimeIsHealthy       Container runtime on the node is functioning properly
  FrequentUnregisterNetDevice   False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentUnregisterNetDevice   node is functioning properly
  KubeletUnhealthy              False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   KubeletIsHealthy                kubelet on the node is functioning properly
  FrequentKubeletRestart        False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentKubeletRestart        kubelet is functioning properly
  FrequentDockerRestart         False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentDockerRestart         docker is functioning properly
  MemoryPressure                Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.
  DiskPressure                  Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.
  PIDPressure                   Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.
  Ready                         Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.

[root@zv-aa-bm01 ~]# journalctl -u kubelet -f | grep cilium-agent
Aug 29 17:29:47 zv-aa-bm01 kubelet[48625]: E0829 17:29:47.941493   48625 pod_workers.go:1298]
"Error syncing pod, skipping" err="failed to \"StartContainer\" for \"cilium-agent\" with CrashLoopBackOff: \"back-off 5m0s restarting failed container=cilium-agent pod=anetd-pvmz4_kube-system(db55cbd2-36e3-4d20-8c6b-edbb5191232d)\"" pod="kube-system/anetd-pvmz4" podUID="db55cbd2-36e3-4d20-8c6b-edbb5191232d"
Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.

et que le nœud utilise un très grand nombre de cgroups :

# cat /proc/cgroups | grep memory
memory  12      380360  1

Solution :

Suivez l'une des procédures suivantes :

  1. Exécutez echo 3 > /proc/sys/vm/drop_caches sur le nœud et redémarrez kubelet.
  2. Si la méthode précédente ne fonctionne pas, essayez de redémarrer le nœud.

Échec intermittent de la connectivité à l'adresse IP virtuelle du cluster externe

Versions : 1.13.3

Symptômes : des échecs de connexion intermittents à l'adresse IP virtuelle (VIP) du cluster externe, comme l'adresse IP virtuelle du plan de contrôle, l'adresse IP virtuelle istio-gateway ou l'adresse IP virtuelle Harbor, entraînent une erreur dial tcp :: connect: no route to host.

Pour diagnostiquer ce problème, procédez comme suit :

  1. Connectez-vous au cluster d'administrateur racine. Cette solution de contournement suppose que vous déboguez des adresses IP dans un cluster d'administrateur racine. Si vous déboguez des problèmes de connectivité avec d'autres clusters Kubernetes, tels que les clusters d'administrateur ou de système de l'organisation, remplacez la valeur KUBECONFIG par le chemin d'accès kubeconfig du cluster approprié.

  2. Il existe deux catégories connues d'adresses IP pouvant être concernées. Vérifiez si le Border Gateway Protocol (BGP) annonce les adresses IP aux commutateurs ToR (Top-of-Rack) :

    • Si l'adresse IP est une adresse IP de plan de contrôle Kubernetes, comme 192.0.2.100, utilisez cette commande pour obtenir les informations de configuration :

      KUBECONFIG=KUBECONFIG
kubectl cluster-info
# Kubernetes control plane is running at https://192.0.2.100:443`

      Remplacez KUBECONFIG par le chemin d'accès à votre fichier kubeconfig dans le cluster d'administrateur racine.

    • Pour certaines configurations, la ressource personnalisée BGPAdvertisedRoute définit les routes de l'adresse IP qui sont annoncées à d'autres réseaux ou systèmes à l'aide de BGP. Si l'adresse IP est annoncée par la ressource personnalisée BGPAdvertisedRoute, utilisez cette commande pour obtenir les informations de configuration :

      TARGET_IP=TARGET_IP_ADDRESS
KUBECONFIG=KUBECONFIG
kubectl get BGPAdvertisedRoute -A --kubeconfig=$KUBECONFIG | grep $TARGET_IP

      Remplacez TARGET_IP_ADDRESS par l'adresse IP qui rencontre des problèmes de connectivité intermittents.

  3. Vérifiez l'état des ressources personnalisées BGPSession. Un BGPSession représente une session d'appairage BGP individuelle établie entre votre cluster Kubernetes et un pair BGP externe. Inspectez les journaux des pods BGPAdvertiser et vérifiez que toutes les ressources BGPSession sont à l'état Established :

    KUBECONFIG=KUBECONFIG
kubectl get pods -l app=bgpadvertiser -n kube-system

# Based on the name of pods, check their logs
kubectl logs pod/bgpadvertiser-gpc-adhoc-6a265a03vm-worker-node0-zone1 -n
kube-system --kubeconfig=$KUBECONFIG`

    Le résultat d'un pod BGPAdvertiser opérationnel contient l'extrait suivant :

    I0904 04:32:19.999906       1 main.go:217] BGP advertiser serving...\
time="2024-09-04T04:32:25Z" level=info msg="Peer Up" Key=10.200.0.1
State=BGP_FSM_OPENCONFIRM Topic=Peer\

  4. Vérifiez la stabilité de la connexion. Créez et exécutez un script pour vérifier si la connectivité est intermittente ou instable :

    1. Créez le script :

      #!/bin/bash

TARGET=$1
CNT=0
for i in {1..100}; do
    output=$(curl --no-progress-meter -k https://$TARGET 2>&1)
    if echo "$output" | grep -q "No route to host"; then
            CNT=$((CNT+ 1))
            echo "Attempt $i: $output"
    fi
    sleep 0.1
done
echo "$CNT out of 100 runs hit No route to host error"

    2. Exécutez le script :

      ./script.sh TARGET_IP_ADDRESS:PORT

      Remplacez PORT par le numéro de port qui pose problème.

      Si votre connexion présente des problèmes, un message semblable à celui-ci s'affiche :

      Attempt 2: curl: (7) Failed to connect to 192.0.2.201 port 10443: No route
to host
Attempt 4: curl: (7) Failed to connect to 192.0.2.201 port 10443: No route
to host
Attempt 7: curl: (7) Failed to connect to 192.0.2.201 port 10443: No route
to host`

  5. Le résultat précédent confirme le problème. Vérifiez les routes sur les commutateurs TOR pour voir si la configuration des commutateurs TOR est à l'origine du problème.

    En supposant que le trafic soit abandonné pour une adresse IP exemple de 192.0.2.201 et qu'il soit annoncé par la ressource BGPAdvertisedRoute, examinez les sauts dans la ressource BGPAdvertisedRoute pour identifier les points de défaillance potentiels :

    apiVersion: networking.gke.io/v1
kind: BGPAdvertisedRoute
metadata:
  annotations:
    bgploadbalancer.networking.gke.io/servicename: istio-ingressgateway
    bgploadbalancer.networking.gke.io/servicens: istio-system
  creationTimestamp: "2024-08-20T19:03:02Z"
  generation: 150
  name: default-istio-system-istio-ingressgateway-rj2fv
  namespace: kube-system
  ownerReferences:
  - apiVersion: networking.gke.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: BGPLoadBalancer
    name: default
    uid: f681f3e5-c66a-45d6-a3ac-9d7ae26f555f
  resourceVersion: "27133500"
  uid: 8ede0c81-3aba-40ce-a441-4aec334b41bd
spec:
  bgpPeerNames:
  - 192.0.2.6-peer-10.0.1.1
  - 192.0.2.5-peer-10.0.1.0
  - 192.0.2.5-peer-10.0.1.1
  - 192.0.2.6-peer-10.0.1.0
  nextHops:
  - 192.0.2.2
  - 192.0.2.3
  - 192.0.2.4
  prefix: 192.0.2.201/32

  6. Examinez les adresses IP dans le champ nextHops. Pour chaque adresse IP, recherchez le nom du serveur. Exemple :

    - 192.0.2.2 zt-aa-bm08
- 192.0.2.3 zt-aa-bm09
- 192.0.2.4 zt-ab-bm01

  7. Ce résultat montre que les prochains sauts sont vers des serveurs des racks aa et ab. Connectez-vous aux commutateurs TOR des racks aa et ab, puis comparez les routes dans les deux racks :

    show ip route 192.0.2.201 vrf root-external-vrf

  8. Si les routes sont différentes entre les commutateurs TOR des deux racks, vous rencontrez le problème que la solution de contournement atténue. La sortie pour ce problème ressemble à ceci :

    zt-aa-torsw01# show ip route 192.0.2.201 vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 3/0, all-best
*via 192.0.2.2, [20/0], 1w1d, bgp-65070, external, tag 64513
*via 192.0.2.3, [20/0], 1w1d, bgp-65070, external, tag 64513
*via 192.0.2.4, [20/0], 1w1d, bgp-65070, external, tag 64513

zt-aa-torsw02# sh ip route 192.0.2.201  vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 3/0, all-best
*via 192.0.2.2, [20/0], 1w3d, bgp-65070, external, tag 64513
*via 192.0.2.3, [20/0], 1w3d, bgp-65070, external, tag 64513
*via 192.0.2.4, [20/0], 1w3d, bgp-65070, external, tag 64513

zt-ab-torsw01# show ip route 192.0.2.201 vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 2/0, all-best
*via 10.249.88.2, [200/0], 1w1d, bgp-65070, internal, tag 64513
*via 192.0.2.3, [200/0], 1w1d, bgp-65070, internal, tag 64513

zt-ab-torsw02# sh ip route  192.0.2.201  vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 2/0, all-best
*via 192.0.2.2, [200/0], 1w3d, bgp-65070, internal, tag 64513
*via 192.0.2.3, [200/0], 1w3d, bgp-65070, internal, tag 64513

    Dans cette sortie, les routes du rack aa sont dans l'état attendu, avec trois prochains sauts listés en face du préfixe. Toutefois, dans le rack ab, le préfixe ne comporte que deux sauts suivants. Lorsque le trafic destiné au préfixe est haché dans le rack ab, le nœud correspondant au saut suivant manquant ne reçoit jamais le trafic et le réseau rencontre un problème de connectivité.

Suivez la solution de contournement pour atténuer ce problème.

Solution :

Cette solution de contournement permet de résoudre les problèmes de connectivité intermittents à certaines adresses IP dans les clusters Kubernetes.

Pour atténuer ce problème, vous devez appliquer plusieurs modifications de configuration à la session BGP entre les commutateurs d'agrégation. Les commutateurs d'agrégation (AGG) agrègent le trafic de plusieurs commutateurs TOR. Pour mettre à jour toutes les configurations nécessaires :

  1. Un fichier de configuration appelé switchstaticconfig représente les configurations statiques sur un seul commutateur. Téléchargez le fichier switchstaticconfig pour les deux commutateurs AGG :

    export KUBECONFIG=KUBECONFIG
kubectl get switchstaticconfig za-ab-aggsw01-static-config -n gpc-system -oyaml > /tmp/za-ab-aggsw01-static-config.yaml
kubectl get switchstaticconfig za-ac-aggsw01-static-config -n gpc-system -oyaml > /tmp/za-ac-aggsw01-static-config.yaml

  2. Obtenez le numéro de système autonome (ASN) de l'environnement :

    root@bootstrapper:/tmp# kubectl get ClusterBGPRouter --kubeconfig KUBECONFIG -A -o yaml | grep networkASN | head -1
    networkASN: 65030

    Ce résultat affiche une valeur ASN de 65030. Vous devez utiliser la valeur ASN renvoyée ici dans les étapes suivantes.

  3. Une adresse IP de bouclage sur un commutateur AGG sert d'adresse stable et toujours active pour la gestion, le routage et le dépannage, même si d'autres connexions réseau sont hors service. Obtenez les adresses IP de bouclage de chacun des commutateurs AGG :

    root@bootstrapper:~# kubectl get --kubeconfig KUBECONFIG
aggswitchinternal -n gpc-system -o
jsonpath='{range.items[*]}{.metadata.name}{":\t"}{.spec.loopbackIPs}{"\n"}{end}'

    La sortie ressemble à ceci :

    za-ab-aggsw01-internal: ["192.0.2.1"]
za-ac-aggsw01-internal: ["192.0.2.2"]

  4. Mettez à jour le staticswitchconfig pour le commutateur za-ab-aggsw01 AGG. Ajoutez cet extrait à la section config :

    spec:
  config: |

route-map onlydefault permit 10
match ip address prefix default
router bgp ASN
      neighbor LOOPBACK_ADDRESS
  address-family l2vpn evpn
      route-map onlydefault in

...
    key chain OSPF_AUTH_KEYCHAIN_0
      key 1

    Remplacez les éléments suivants :

    • ASN : valeur ASN de l'étape précédente. Dans cet exemple, cette valeur est 65030.
    • LOOPBACK_ADDRESS : il s'agit de l'adresse IP de bouclage du commutateur AGG za-ac-aggsw01. Dans cet exemple, la valeur est 192.0.2.2.

  5. Appliquez la même mise à jour à l'autre commutateur AGG, za-ac-aggsw01. Vous devez fournir l'adresse de bouclage correcte. L'adresse IP de bouclage est différente pour chaque commutateur :

    za-ab-aggsw01-internal: ["192.0.2.1"]
za-ac-aggsw01-internal: ["192.0.2.2"]

  6. Créez et exécutez le même script que celui utilisé pour diagnostiquer le problème à cette étape afin de vérifier que la correction a fonctionné. Aucun message d'erreur ne s'affiche.

Erreur Incorrect version of Trident lors de la mise à niveau

Versions : 1.13.3, 1.13.4, 1.13.5

Symptômes : lors de la mise à niveau à partir de versions antérieures à la version 1.13.3, ontap affiche l'erreur Incorrect version of Trident. Un message de ce type peut s'afficher :

Status:
  Conditions:
  Last Transition Time: 2024-08-27T15:19:07Z
  Message:              Incorrect version of Trident. Wanted v23.10.0-gke.6, got v23.10.0-gke5
  Observed Generation:  1
  Reason:               QualificationFailed
  Status:               False
  Type:                 AllComplete
  Events:

Solution :

  1. Mettez à jour le releasemetadata de la version vers laquelle vous effectuez la mise à niveau :

    export KUBECONFIG=<point to ROOT Admin Kubeconfig>
To get the list of all releasemetadata:
`kubectl get releasemetadata`

    Le résultat peut ressembler à ceci :

    NAME AGE 1.12.2-gdch.785 24d 1.12.4-gdch.96 13d 1.13.3-gdch.5548 11h

  2. Choisissez la version vers laquelle vous effectuez la mise à niveau, comme indiqué dans l'exemple suivant :

    kubectl get releasemetadata 1.13.3-gdch.5548 -o yaml > releasemetadata.yaml

  3. Mettez à jour tridentVersion dans la section fileBlockStorage du fichier .yaml avec la version mentionnée dans l'erreur. Si le message d'erreur ressemblait à ceci :

    Message: Incorrect version of Trident. Wanted v23.10.0-gke.6, got v23.10.0-gke.5

    Remplacez tridentVersion par v23.10.0-gke.5 dans releasemetadata.yaml.

    Par exemple, si la valeur d'origine était infraComponents: fileBlockStorage: ONTAPVersion: 9.14.1P1 harvestVersion: v22.08.0-gke.7 tridentVersion: v23.10.0-gke.6,

    Remplacez-le par la valeur suivante :

    infraComponents: fileBlockStorage: ONTAPVersion: 9.14.1P1 harvestVersion: v22.08.0-gke.7 tridentVersion: v23.10.0-gke.5.

  4. Appliquez les modifications :

    kubectl apply -f releasemetadata.yaml

  5. Appliquez à nouveau l'augmentation de l'espace de stockage ontap.

Échec de la programmation des pods

Versions : 1.13.3. 1.13.4, 1.13.5

Symptômes : lors du provisionnement du cluster d'utilisateur, certains pods ne sont pas planifiés. Un message de ce type peut s'afficher :

0/6 nodes are available: 1 Insufficient cpu. preemption: 0/6 nodes are available: 6 No preemption victims found for incoming pod

Solution :

Augmentez la taille du pool de nœuds du plan de contrôle du cluster d'utilisateur :

  kubectl --kubeconfig ORG_ADMIN_KUBECONFIG patch addresspoolclaim/control-plane-node-pool -n ${CLUSTER_NAME}-cluster --type=json -p="[{'op': 'replace', 'path': '/spec/size', 'value': 5}]"
  kubectl --kubeconfig ORG_ADMIN_KUBECONFIG patch nodepoolclaim/control-plane-node-pool -n ${CLUSTER_NAME}-cluster --type=json -p="[{'op': 'replace', 'path': '/spec/nodeCount', 'value': 5}]"

Échec de la mise à niveau dans le sous-composant iac-zoneselection-global

Versions : 1.13.1

Symptômes : lors d'une mise à niveau vers la version 1.13.3, une erreur se produit sur le sous-composant iac-zoneselection-global. Un message de ce type peut s'afficher :

== Subcomponents with failures in root org ===
Sub-Component: iac-zoneselection-global - Reconciliation error: E0100 - deploy: failed to install chart: release iac-zoneselection-global-backend failed, and has been uninstalled due to atomic being set: 1 error occurred:
        * ZoneSelection.location.mz.global.private.gdc.goog "iac" is invalid: spec.resultObjectName: Required value

Events: Type     Reason               Age                   From          Message
----     ------               ----                  ----          -------
Warning  ReconciliationError  119s (x521 over 20h)  Subcomponent  E0100 - deploy: failed to install chart: release iac-zoneselection-global-backend failed, and has been uninstalled due to atomic being set: 1 error occurred:
         * ZoneSelection.location.mz.global.private.gdc.goog "iac" is invalid: spec.resultObjectName: Required value

Solution :

La mise à niveau vers la version 1.13.3 corrige l'erreur.

Le délai des vérifications de mise à niveau a expiré

Versions : 1.12.x, 1.13.x

Problèmes constatés : lors de la mise à niveau de l'organisation, la vérification de la mise à niveau affiche l'état False avec la raison DeadlineExceeded. Un message de ce type peut s'afficher :

  Preflight Check:                                                                                                                                                                                                          
    Conditions:                                                                                                                                                                                                             
      Last Transition Time:  2024-10-29T18:57:47Z                                                                                                                                                                           
      Message:               the result has status: False, reason: PreflightCheckFailed, and err: [check "OPAUpgrade" of operable component "OPA" failed with reason "DeadlineExceeded", no existing pods found, check "Arti
actAvailability" of operable component "AR" failed with reason "DeadlineExceeded", no existing pods found, check "PackageValidation" of operable component "AR" failed with reason "DeadlineExceeded", no existing pods foun
d, check "IAMUpgrade" of operable component "IAM" failed with reason "DeadlineExceeded", no existing pods found, check "NodeHealth" of operable component "OS" failed with reason "DeadlineExceeded", no existing pods found
, check "DNSHealth" of operable component "DNS" failed with reason "DeadlineExceeded", no existing pods found, check "AdminClusterCheck" of operable component "UPORC" failed with reason "DeadlineExceeded", no existing po
ds found[]                                                                                                                                                                                                                  
      Observed Generation:   3                                                                                                                                                                                              
      Reason:                PreflightCheckFailed                                                                                                                                                                           
      Status:                False                                                                                                                                                                                          
      Type:                  Succeeded                                                                                                                                                                                      
    Start Time:              2024-10-29T17:57:47Z

Solution :

  1. Supprimez les tâches de vérification de la mise à niveau qui ont échoué et qui correspondent aux vérifications de la mise à niveau ayant échoué.
  2. Attendez que les tâches de vérification de la mise à niveau soient recréées.
  3. Examinez les journaux des tâches recréées et triez les problèmes.

L'addon meta-monitoring échoue, car l'emplacement strongswan se trouve dans un répertoire d'exécution différent.

Versions : 1.12.x, 1.13.x

Symptômes : lors de la mise à niveau vers la version 1.13.4 ou 1.13.5, le module complémentaire meta-monitoring échoue :

kubectl --kubeconfig ORG_ADMIN_KUBECONFIGget addons -A | grep meta-monitoring
org-1-system-cluster                                      meta-monitoring                                      false                                        false                                      1.12.4-gdch.96

Vérifiez le module complémentaire :

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG get -n org-1-system-cluster addon meta-monitoring -o yaml

Le message de condition peut se présenter comme suit :

status:
  conditions:
  - lastTransitionTime: "2024-11-19T02:57:30Z"
    message: 'Error occurred during addon installation: failed to rollback chart:
      create: failed to create: Internal error occurred: failed calling webhook "validation.gatekeeper.sh":
      failed to call webhook: Post "https://gatekeeper-webhook-service.opa-system.svc:443/v1/admit?timeout=3s":
      context deadline exceeded'
    observedGeneration: 2
    reason: InstallationError
    status: "False"
    type: Deployed

Solution :

  1. Assurez-vous que les sessions BGP du cluster du système de l'organisation échouent, par exemple :

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG get bgpsessions -A
NAME                                           LOCAL ASN   PEER ASN   LOCAL IP        PEER IP     STATE   LAST REPORT
10.252.122.10-peer-10.0.1.32-vm-7351eebe       64513       65030      10.252.122.10   10.0.1.32           
10.252.122.10-peer-10.0.1.33-vm-7351eebe       64513       65030      10.252.122.10   10.0.1.33           
10.252.122.11-peer-10.0.1.32-vm-7351eebe       64513       65030      10.252.122.11   10.0.1.32           
10.252.122.11-peer-10.0.1.33-vm-7351eebe       64513       65030      10.252.122.11   10.0.1.33           
172.20.128.3-peer-10.0.1.48-za-aa-bm02-hltg2   64513       65030      172.20.128.3    10.0.1.48           
172.20.128.3-peer-10.0.1.49-za-aa-bm02-hqblq   64513       65030      172.20.128.3    10.0.1.49

  2. Assurez-vous que les pods ang-node sont bloqués sur ContainerCreating, par exemple :

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG get pods -n kube-system -l app=ang-node
NAME                                                 READY   STATUS              RESTARTS        AGE
ang-node-5c6c8                                       0/3     ContainerCreating   0               2d21h
ang-node-6skkl                                       0/3     ContainerCreating   0               2d14h
ang-node-7d7dj                                       0/3     ContainerCreating   0               2d20h
ang-node-9l4xc                                       0/3     ContainerCreating   0               2d17h

    L'erreur suivante s'affiche :

    Warning  FailedMount  112s (x2056 over 2d21h)  kubelet  MountVolume.SetUp failed for volume "vici" : hostPath type check failed: /var/run/strongswan is not a directory

  3. Appliquez la modification suivante à ang-overrides AddonConfiguration dans le cluster d'administrateur de l'organisation :

    kubectl --kubeconfig ORG_ADMIN_KUBECONFIG edit addonconfiguration ang-overrides -n org-1-system-cluster

    Modifiez les éléments suivants :

                volumes:
            - hostPath:
                path: /var/run/strongswan
                type: Directory
              name: vici

    aux éléments suivants :

                volumes:
            - hostPath:
                path: /var/run
                type: Directory
              name: vici

  4. Au bout d'environ une minute, vérifiez que les pods ang-node sont désormais à l'état Running :

    NAME             READY   STATUS    RESTARTS   AGE
ang-node-7hj5q   3/3     Running   0          15s
ang-node-xps2m   3/3     Running   0          34s
ang-node-krx8p   3/3     Running   0          34s
ang-node-cbm1a   3/3     Running   0          34s

  5. Assurez-vous que les sessions BGP du cluster du système d'organisation sont désormais en cours d'exécution.

  6. Le module complémentaire meta-monitoring passe à l'étape suivante.

La mise à niveau de l'organisation racine est bloquée en raison d'un échec de la tâche de signature

Versions : 1.13.3, 1.13.4

Symptômes : lorsque vous passez de la version 1.13.3 à la version 1.13.4, un message semblable à celui-ci peut s'afficher :

Message:       [the result has status: False, reason: PreflightCheckFailed, and err: check "PackageValidation" of operable component "AR" failed with reason "DeadlineExceeded", no existing pods found, the result has status: Unknown, reason: UpgradeCheckJobsInProgress

Solution :

  1. Désactivez la vérification préliminaire :

    kubectl annotate -n gpc-system organization root upgrade.private.gdc.goog/skip-preflight-check=ok

  2. Supprimez le job artifact-signature-verification-*** en échec.

  3. Attendez la fin de la mise à niveau de la racine.

  4. Facultatif : activez la vérification préliminaire si l'environnement est mis à niveau vers la version 1.13.4 ou ultérieure.

Une fois que le contrôleur est en version 1.13.4, les mises à niveau ne devraient plus poser ce problème.

La mise à niveau de l'organisation locataire échoue lors de la vérification préliminaire avec ErrImagePull

Versions : 1.13.3

Symptômes : la mise à niveau de l'organisation locataire échoue lors de la vérification préliminaire avec ErrImagePull pour le pod de validation du package. Un message de ce type peut s'afficher :

export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get po -n package-validation-system  | grep artifact-signature-verification

Les pods affichent une erreur ImagePullBackOff :

kubectl describe po -n package-validation-system POD_NAME

Une erreur d'extraction d'image s'affiche, comme dans l'exemple suivant :

Name:             artifact-signature-verification-20240823224755-4ppkt
Namespace:        package-validation-system
Priority:         0
Service Account:  package-validation
Node:             ak-ab-base02/203.0.113.250
Start Time:       Fri, 23 Aug 2024 22:47:55 +0000
Labels:           batch.kubernetes.io/controller-uid=bf81d5eb-d597-464e-a907-67c1c8a11c11
                  batch.kubernetes.io/job-name=artifact-signature-verification-20240823224755
                  controller-uid=bf81d5eb-d597-464e-a907-67c1c8a11c11
                  job-name=artifact-signature-verification-20240823224755
Annotations:      <none>
Status:           Pending
IP:               203.0.113.255
IPs:
  IP:           203.0.113.255
Controlled By:  Job/artifact-signature-verification-20240823224755
Containers:
  artifact-signature-verification:
    Container ID:
    Image:          gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004
    Image ID:
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       ImagePullBackOff
    Ready:          False
    Restart Count:  0
...
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                     From               Message
  ----     ------     ----                    ----               -------
  Normal   Scheduled  10m                     default-scheduler  Successfully assigned package-validation-system/artifact-signature-verification-20240823224755-4ppkt to ak-ab-base02
  Normal   Pulling    7m25s (x4 over 9m22s)   kubelet            Pulling image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004"
  Warning  Failed     7m14s (x4 over 9m12s)   kubelet            Failed to pull image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004": failed to pull and unpack image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004": failed to resolve reference "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004": unexpected status from HEAD request to https://203.0.113.255/v2/private-cloud-staging/signature-verifier/manifests/v1.13.0-uporc-aa505d9004?ns=gcr.io: 401 Unauthorized
  Warning  Failed     7m14s (x4 over 9m12s)   kubelet            Error: ErrImagePull
  Warning  Failed     7m3s (x6 over 9m11s)    kubelet            Error: ImagePullBackOff
  Normal   BackOff    4m11s (x17 over 9m11s)  kubelet            Back-off pulling image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004"

Solution :

Ignorer les vérifications préliminaires :

kubectl annotate -n gpc-system organization ORG_NAME \
upgrade.private.gdc.goog/skip-preflight-check=ok

Impossible de trouver serviceaccount lors de la migration de l'organisation racine

Versions : 1.13.8, 1.13.9

Symptômes : lors de la mise à niveau vers la version 1.13.8, le déploiement addon pour les RBAC échoue si des mises à niveau ont déjà été effectuées et si des modules complémentaires existent déjà. Les symptômes peuvent se manifester à l'un des stades suivants :

  1. vérifications avant ou après le vol ;
  2. Toute étape impliquant une tâche de mise à niveau et le message indiquant que le job est en cours d'exécution, même si la tâche est bloquée. Le message status.conditions indique que le job est en cours d'exécution depuis longtemps, ce qui indique un problème.

Pour vérifier si une vérification préliminaire de la mise à niveau a échoué, vérifiez l'état de l'objet OrganizationUpgrade correspondant pour l'organisation en cours de mise à niveau :

  kubectl get -n gpc-system organizationupgrade ORG_NAME -o yaml

  1. Si le job échoue lors de la vérification préliminaire, un message d'échec semblable à celui-ci ou un message UpgradeCheckRBACDeploymentInProgress peut s'afficher :

      - lastTransitionTime: "2024-09-27T00:28:21Z"
    message: ""
    observedGeneration: 2
    reason: Unknown
    status: "False"
    type: PreflightCheck

  2. Si le job échoue au niveau d'Anthos Bare Metal (ABM) où la tâche est en cours d'exécution, le résultat suivant s'affiche :

    - Last Transition Time:  2024-09-26T19:55:13Z
  message:               observed the following reason: [JobRunning]
  observedGeneration:    3
  reason:                Unsuccessful
  status:                Unknown
  type:                  root-admin/AnthosBareMetal

  3. Si l'échec se produit lors des vérifications, le CR upgradecheckrequest échoue :

    kubectl get upgradecheckrequests -n gpc-system  --kubeconfig /root/release/root-admin/root-admin-kubeconfig

    Le résultat peut ressembler à l'exemple suivant :

    NAME                                   AGE
upgrade-check-root-postflight-xc7p8    6h32m

  4. Si l'échec se produit dans les tâches, le CR upgradetaskrequests échoue :

    kubectl get upgradetaskrequests -n gpc-system  --kubeconfig /root/release/root-admin/root-admin-kubeconfig

    Le résultat peut ressembler à l'exemple suivant :

    NAME                                          AGE
upg-task-org-1-mz-mz-location-upgrade-5n6wp   2d19h

  5. Si l'échec indique une erreur RBAC lors de la recherche d'un compte de service, vérifiez si un module complémentaire précédent est déployé :

    Type     Reason        Age                   From            Message
----     ------        ----                  ----            -------
Warning  FailedCreate  38s (x11 over 5m41s)  job-controller  Error creating: pods "v1.13.0-mz-2837f80328-upg-task-root-mz-mz-location-jkv69-" is forbidden: error looking up service account gpc-system/upgrade-task-mz-sa-v1.13.0-mz-2837f80328: serviceaccount "upgrade-task-mz-sa-v1.13.0-mz-2837f80328" not found

Solution :

  1. Vérifiez si un module complémentaire précédent est déployé :

      Type     Reason        Age                    From            Message
  ----     ------        ----                   ----            -------
  Warning  FailedCreate  4m30s (x101 over 99m)  job-controller  Error creating: pods "v1.13.0-os-2837f80328-upg-task-root-os-node-upgrad-fdblm-" is forbidden: error looking up service account gpc-system/upgrade-task-os-sa-v1.13.0-os-2837f80328: serviceaccount "upgrade-task-os-sa-v1.13.0-os-2837f80328" not foundcount gpc-system/upgrade-task-mz-sa-v1.13.0-mz-2837f80328: serviceaccount "upgrade-task-mz-sa-v1.13.0-mz-2837f80328" not found

  2. Obtenez les modules complémentaires a priori qui existent pour le même composant, upgrade-task-mz pour la tâche :

    kubectl get addons -n gpc-system | grep upgrade-task
upgrade-task-mz-lsqzc            true       true    v1.13.0-mz-7cf810d7a5

  3. Supprimer ce module complémentaire :

    kubectl delete addon -n gpc-system upgrade-task-mz-lsqzc upgrade-task-os-px5wj
addon.addon.private.gdc.goog "upgrade-task-mz-lsqzc" deleted

  4. Après avoir supprimé le module complémentaire, supprimez également le upgradetaskrequest ou le upgradecheckrequest correspondant. Il sera recréé.

    kubectl delete upgradetaskrequest -n gpc-system upgrade-task-mz-lsqzc

  5. Continuez à surveiller le upgradetaskrequest ou le upgradecheckrequest nouvellement créé, ou le job correspondant directement.

Échec de la mise à niveau sur shared-service-cluster upgrade

Versions : 1.13.3

Symptômes : la mise à niveau d'Anthos sur Bare Metal est bloquée sur une ou plusieurs machines Bare Metal. Toutes les autres machines bare metal ont été mises à niveau avec succès ou n'ont pas encore commencé la mise à niveau. Une machine Bare Metal est en mode maintenance, mais affiche toujours l'ancienne version dans les champs "VERSION ABM actuelle" et "VERSION ABM souhaitée".

Suivez Anthos sur Bare Metal pour obtenir l'état baremetalmachine et les détails du cluster :

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

Résultat attendu :

NAME           CLUSTER                  READY   INSTANCEID                  MACHINE         ABM VERSION        DESIRED ABM VERSION
192.0.2.0      g-org-1-shared-service   true    baremetal://192.0.2.0       192.0.2.0       1.29.300-gke.185   1.29.300-gke.185
192.0.2.18     g-org-1-shared-service   true    baremetal://192.0.2.18      192.0.2.18      1.29.300-gke.185   1.29.300-gke.185
192.0.2.19     g-org-1-shared-service   true    baremetal://192.0.2.19      192.0.2.19      1.29.300-gke.185   1.29.300-gke.185
192.0.2.10     g-org-1-shared-service   true    baremetal://192.0.2.10      192.0.2.10      1.29.300-gke.185   1.29.300-gke.185
192.0.2.22     g-org-1-shared-service   true    baremetal://192.0.2.22      192.0.2.22      1.29.300-gke.185   1.29.300-gke.185
192.0.2.9      g-org-1-shared-service   true    baremetal://192.0.2.9       192.0.2.9       1.29.0-gke.1449    1.29.0-gke.1449 

kubectl get baremetalmachines -n "${CLUSTER_NAMESPACE}" --kubeconfig=${ADMIN_KUBECONFIG} ${MACHINE_IP}  -o json | jq '.status.underMaintenance'

Résultat attendu :

true

Solution :

  1. Désactivez le mode de maintenance pour la machine d'inventaire :

    export InventoryMachineName=$(kubectl --kubeconfig=${ADMIN_KUBECONFIG} get inventorymachines -A  -o json | jq '.items[] | select(.spec.address=="${MACHINE_IP}") | .metadata.name')
kubectl --kubeconfig "${ADMIN_KUBECONFIG:?}" patch inventorymachine/${InventoryMachineName:?} --type=merge  -p '{"spec": {"maintenance": false}}'

  2. Attendez que la machine d'inventaire quitte le mode maintenance. Cette opération peut prendre jusqu'à 10 minutes.

    kubectl --kubeconfig "${ADMIN_KUBECONFIG:?}" wait inventorymachine/${InventoryMachineName} --for=jsonpath=.status.maintenance=true --timeout=600s

  3. Surveillez les baremetalmachines pour vérifier que la machine voit la mise à jour de la version ABM sélectionnée.

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

Échec de l'installation du module complémentaire system-dashboards

Versions : 1.13.5

Symptômes : la mise à niveau de la version 1.12.4 vers la version 1.13.5 échoue lors de la mise à niveau du module complémentaire system-dashboards :

│ Status:                                                                                                                                                                        │
│   Conditions:                                                                                                                                                                  │
│     Last Transition Time:  2024-10-22T00:34:54Z                                                                                                                                │
│     Message:               Error occurred during addon installation: failed to rollback chart: no ConfigMap with the name "cluster-etcd-platform-obs" found                    │
│     Observed Generation:   2                                                                                                                                                   │
│     Reason:                InstallationError                                                                                                                                   │
│     Status:                False

Solution : Suivez les étapes du runbook OCLCM-R0122.

La CR NodeUpgradeTask est bloquée à la condition NodeOSInPlaceUpgradePostProcessingCompleted

Versions : 1.13.5

Problèmes constatés : lors de la mise à niveau vers la version 1.13.5, la ressource personnalisée NodeUpgradeTask est bloquée à l'état NodeOSInPlaceUpgradePostProcessingCompleted.

Vérifiez si le job os-artifact-collector correspondant est terminé. Si le job est bloqué pendant plusieurs heures, le message suivant s'affiche :

  root@gpc-adhoc-7e017e71vm-bootstrapper-zone1:~# kag logs  os-artifact-collector-bm-45942837-p8hrk-z56gh 
  I1020 22:06:11.844634       1 main.go:30] BuildDate: 2024-10-19T16:54:08Z
  I1020 22:06:11.844695       1 main.go:31] Version: 0.0.0-gdch.1.v3f2043

Solution :

  1. Supprimez le job ou le pod pour forcer une nouvelle tentative.

Échec de la distribution d'images lors d'une mise à niveau

Versions : 1.13.5

Problèmes constatés : la distribution d'images échoue lors d'une mise à niveau de la version 1.12.4 vers la version 1.13.x :

Error: error uploading the VM image to object storage: failed to upload to object storage: BadRequest: Bad Request
    status code: 400, request id: , host id: 
F1018 02:04:46.191627       1 main.go:88] VM Image Distributor quit: error uploading the VM image to object storage: failed to upload to object storage: BadRequest: Bad Request
    status code: 400, request id: , host id: 
goroutine 1 [running]:

Vérifiez les pods obj-proxy dans gpc-system sur l'organisation pour voir si la validation du certificat échoue :

E1021 19:10:31.710076       1 token_source.go:185] Unable to rotate token: failed to initialize aisClient: failed to initialise AIS client: failed to obtain login config from the provided path "https://console.org-1.zone1.google.gdch.test/.well-known/login-config" with error: unable to parse centralized login config file: unsuccessful get request to config URL (https://console.org-1.zone1.google.gdch.test/.well-known/login-config) with error: Get "https://console.org-1.zone1.google.gdch.test/.well-known/login-config": tls: failed to verify certificate: x509: certificate signed by unknown authority

Solution :

  1. Redémarrez le pod obj-proxy à l'aide de KUBECONFIG de l'organisation pour laquelle il échoue :

    export KUBECONFIG=<ORG_KUBECONFIG>
kubectl delete pods -n gpc-system -l name=obj-proxy-manager

  2. Vérifiez les journaux pour obj-proxy : 

    kubectl get pods -n gpc-system | grep obj-proxy

    Le résultat attendu est le suivant :

    obj-proxy-gdgzp                                                1/1     Running     0              5d1h
obj-proxy-nhnsm                                                1/1     Running     0              5d1h
obj-proxy-wrxlq                                                1/1     Running     0              5d1h

  3. Vérifiez les journaux des pods disponibles, par exemple : 

    kubectl logs obj-proxy-gdgzp -n gpc-system

  4. Les tâches de distribution d'images devraient se terminer après l'application de la solution de contournement.

Échec d'un nœud lors de la mise à niveau du cluster d'utilisateur

Versions : 1.13.3

Problèmes constatés : une tâche exécutée sur un nœud échoue lors de la mise à niveau du cluster d'utilisateur et affiche un message d'erreur semblable à celui-ci :

 Reason: mkdir: cannot create directory '/root/.ansible/tmp/ansible-tmp-1727810181.4584012-29-114086005628321': No space left on device

  1. Connectez-vous au nœud et vérifiez si la partition est pleine :

    df -h /

    Le résultat peut ressembler à l'exemple suivant :

    Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/rocky-rl--root   31G   31G  120K 100% /

  2. Vérifiez si /etc/kubernetes/tmp utilise une grande quantité d'espace : du -s /etc/kubernetes/tmp. Ce problème se produit lorsque Kubernetes effectue plus de sauvegardes que d'habitude.

Solution :

  1. Effacez toutes les sauvegardes sur rm -f /etc/kubernetes/tmp/* :

    df -h /

    Le résultat peut ressembler à l'exemple suivant :

    Filesystem                  Size  Used Avail Use% Mounted on
/dev/m

La mise à niveau de l'administrateur racine est recréée et échoue lors des vérifications préliminaires

Versions : 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7, 1.13.8, 1.13.9

Symptôme : la mise à niveau de l'organisation racine échoue lors de la vérification préliminaire, par exemple :

│   Preflight Check:                                                                                                                                                             │
│     Conditions:                                                                                                                                                                │
│       Last Transition Time:  2024-10-28T14:17:31Z                                                                                                                              │
│       Message:               [the result has status: False, reason: PreflightCheckFailed, and err: check "ASMStable" of operable component "ASM" failed with reason "BackoffLi │
│ mitExceeded", please check logs in pods: [gpc-system/upgrade-managed-check-asmstable-4dw66-cld74, gpc-system/upgrade-managed-check-asmstable-4dw66-k8xk5, gpc-system/upgrade-m │
│ anaged-check-asmstable-4dw66-wtc6q, gpc-system/upgrade-managed-check-asmstable-4dw66-l9b6v, gpc-system/upgrade-managed-check-asmstable-4dw66-nf62h, gpc-system/upgrade-managed │
│ -check-asmstable-4dw66-6m7p2, gpc-system/upgrade-managed-check-asmstable-4dw66-4mqmb], the result has status: Unknown, reason: UpgradeCheckJobsInProgress, and err: upgrade ch │
│ eck jobs in progress for Operable Components: haas,bil]                                                                                                                        │
│       Observed Generation:   2                                                                                                                                                 │
│       Reason:                PreflightCheckFailed                                                                                                                              │
│       Status:                False                                                                                                                                             │
│       Type:                  Succeeded                                                                                                                                         │
│     Start Time:              2024-10-28T14:46:42Z

Le cluster root-admin et kubeapiserver pour root-admin ont été mis à niveau vers la version abm choisie.

Exemple :

export KUBECONFIG=<path to root admin kubeconfig>
kubectl describe kubeapiserver root-admin -n root
kubectl get cluster root-admin -n root

Exemple de résultat pour kubectl describe kubeapiserver root-admin -n root :

Name:         root-admin
Namespace:    root
Labels:       lcm.private.gdc.goog/cluster-type=root-admin
              lcm.private.gdc.goog/cluster-version=1.29.600-gke.108
              lcm.private.gdc.goog/component-version=v1.13.0-oclcm-f4c190e0f2

Exemple de résultat pour kubectl get cluster root-admin -n root :

NAME         ABM VERSION        DESIRED ABM VERSION   CLUSTER STATE
root-admin   1.29.600-gke.108   1.29.600-gke.108      Running

Solution

Appliquez l'option de désactivation de la vérification préliminaire pour poursuivre la mise à niveau :

export KUBECONFIG=<path to root admin kubeconfig>
kubectl delete organizationupgrade root -n gpc-system && kubectl annotate -n gpc-system organization root upgrade.private.gdc.goog/skip-preflight-check=ok 
kubectl delete organizationupgrade root -n gpc-system

Les espaces de noms platform-obs-obs-system ou platform-obs sont bloqués à l'état "Arrêt en cours"

Versions : 1.13.5

Symptômes : les modules complémentaires ne parviennent pas à se déployer lors de la mise à niveau ou de l'amorçage, et affichent un message d'erreur semblable à celui-ci : 

 export KUBECONFIG=ROOT_ADMIN
 kubectl get addon -n org-1 system-alerts system-dashboards

Le résultat suivant s'affiche :

  NAME                DEPLOYED   READY   VERSION
  system-alerts
  system-dashboards   false      false   1.12.4-gdch.96

Si les états "DÉPLOYÉ" ou "PRÊT" affichent false ou sont vides, vérifiez les modules complémentaires concernés pour identifier l'erreur. Par exemple :

  export KUBECONFIG=ROOT_ADMIN
  kubectl describe addon -n org-1 system-alerts

Le résultat suivant s'affiche :

  ...
  ... unable to create new content in namespace platform-obs-obs-system because it is being terminated                             
  ...

Le module complémentaire est bloqué, car il a tenté de créer du contenu dans les espaces de noms en cours de suppression. Ce blocage persiste, car la suppression de l'espace de noms est également bloquée.

Solution :

  1. Avant de commencer une mise à niveau, annotez les projets pour éviter leur suppression :

    export KUBECONFIG=ORG_ADMIN
kubectl annotate project -n gpc-system platform-obs helm.sh/resource-policy="keep"

    Le résultat suivant s'affiche :

    project.resourcemanager.gdc.goog/platform-obs annotated
kubectl annotate project -n gpc-system platform-obs-obs-system helm.sh/resource-policy="keep"
project.resourcemanager.gdc.goog/platform-obs-obs-system annotated

    Si l'environnement présente déjà les symptômes décrits précédemment, suivez la procédure de contournement suivante :

  2. La suppression de l'espace de noms est bloquée en raison de ressources avec des finaliseurs. Pour procéder à la suppression, supprimez les finaliseurs à l'aide du script fourni : 

      export KUBECONFIG=ORG_ADMIN
  function rm_finalizer() {
      export TYPE=$1
      export NS=$2
      RESOURCES=$(kubectl get $TYPE -n $NS --no-headers -o custom-columns=":metadata.name")
      for rc in $RESOURCES; do
          kubectl patch $TYPE $rc -n $NS \
                  --type json \
                  --patch '{"metadata":{"finalizers":[]}}' --type=merge
      done
    }
    rm_finalizer "monitoringrule" "platform-obs-obs-system"
    rm_finalizer "monitoringrule" "platform-obs"
    rm_finalizer "loggingrule" "platform-obs"
```
Note: Use a bash terminal (default on bootstrappers) to run the script.

  3. Attendez que la ressource soit supprimée. Après avoir exécuté le script, supprimez les ressources et les espaces de noms en cours d'arrêt. Vous devrez peut-être exécuter à nouveau le script si l'espace de noms est toujours bloqué à l'état "Arrêt en cours". Une fois l'espace de noms arrêté, il sera automatiquement recréé. Vérifiez que les espaces de noms ont été recréés et qu'ils sont à l'état ACTIF :

      export KUBECONFIG=ORG_ADMIN
  kubectl get namespace platform-obs platform-obs-obs-system

    Le résultat suivant s'affiche :

      NAME                      STATUS   AGE
  platform-obs              Active   45s
  platform-obs-obs-system   Active   49s

    Avec les espaces de noms actifs, les modules complémentaires bloqués devraient être déployés en quelques minutes. Vérifiez que leurs états DEPLOYED et READY sont désormais définis sur "true" :

      export KUBECONFIG=ROOT_ADMIN
  kubectl get addon -n org-1 system-alerts system-dashboards

    Le résultat suivant s'affiche :

      NAME                DEPLOYED   READY   VERSION
  system-alerts       true       true    1.14.0-gdch.143998
  system-dashboards   true       true    1.14.0-gdch.143998

Boucles de plantage UPORC dans le cluster KIND lors de l'amorçage

Versions : 1.13.x

Symptômes : la boucle de plantage du déploiement uporc-root-backend-controller sous l'espace de noms uporc-system dans le cluster KIND.

Solution :

  1. Vérifiez si les objets ComponentGroupReleaseMetadata et ReleaseMetadata correspondent :

    export KUBECONFIG=KIND
kubectl get componentgroupreleasemetadata
kubectl get releasemetadata

    Si les objets correspondent, aucune solution de contournement n'est nécessaire.

  2. Si les objets ne correspondent pas, contactez l'équipe UPORC pour obtenir de l'aide, car cela peut indiquer d'autres problèmes sous-jacents.

Échec de la mise à niveau du nœud

Versions : 1.13.6

Problèmes constatés : la mise à niveau du nœud a échoué à NodeOSInPlaceUpgradeCompleted.

  1. Vérifiez les journaux des tâches ospolicy os-upgrade.
  2. Si le journal inclut une erreur suggérant que le fichier de configuration est corrompu, accédez à la machine du nœud et vérifiez manuellement le contenu du fichier pour voir s'il est corrompu. L'erreur de journal peut mentionner le code d'erreur configparser.DuplicateOptionError et le fichier /etc/yum.repos.d/gdch.repo.

Solution : Supprimez manuellement le fichier /etc/yum.repos.d/gdch.repo corrompu sur le nœud défectueux, uniquement si vous avez confirmé que le fichier est corrompu.

Le job Ansible pour la mise à niveau régénère automatiquement le fichier dans le cadre du playbook Ansible.

### NodeUpgradeTask CR is stuck at the NodeOSInPlaceUpgradePostProcessingCompleted condition

Versions : 1.13.5

Problèmes constatés : lors de la mise à niveau vers la version 1.13.5, la ressource personnalisée NodeUpgradeTask est bloquée à l'état NodeOSInPlaceUpgradePostProcessingCompleted.

Vérifiez si le job os-artifact-collector correspondant est terminé. Si le job est bloqué pendant plusieurs heures, le message suivant s'affiche :

  root@gpc-adhoc-7e017e71vm-bootstrapper-zone1:~# kag logs  os-artifact-collector-bm-45942837-p8hrk-z56gh 
  I1020 22:06:11.844634       1 main.go:30] BuildDate: 2024-10-19T16:54:08Z
  I1020 22:06:11.844695       1 main.go:31] Version: 0.0.0-gdch.1.v3f2043

Solution :

  1. Supprimez le job ou le pod pour forcer une nouvelle tentative.

La CR NodeUpgradeTask est bloquée à la condition NodeBIOSFirmwareUpgradeCompleted

Versions : 1.13.5

Problèmes constatés : lors de la mise à niveau vers la version 1.13.5, la ressource personnalisée NodeUpgradeTask est bloquée à l'état NodeBIOSFirmwareUpgradeCompleted.

Vérifiez si la condition NodeBIOSFirmwareUpgradeCompleted correspondante est bloquée et si la condition suivante s'affiche :

  {
  "lastTransitionTime": "2024-12-03T04:03:37Z",
  "message": "",
  "observedGeneration": 1,
  "reason": "InProgress",
  "status": "False",
  "type": "NodeBIOSFirmwareUpgradeCompleted"
  }

Solution :

  1. Dans la RS NodeUpgrade, modifiez manuellement "U30 v3.20 (05/29/2024)" en "U30 v3.20 (05/27/2024)".

La mise à niveau du cluster est bloquée, car un nœud n'a pas pu passer en mode maintenance

Versions : 1.13.5, 1.13.6, 1.13.7

Problèmes constatés : la mise à niveau du cluster (cluster d'administrateur de l'organisation, système ou utilisateur) est bloquée, car un nœud ne parvient pas à passer en mode maintenance.

Le cluster affiche MaintenanceMode défini sur true, mais Status est bloqué sur false lors de l'exécution de la commande suivante :

kubectl get baremetalmachines -A -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,MaintenanceMode:.spec.maintenanceMode,Status:.status.underMaintenace

Le résultat suivant s'affiche :

NAMESPACE           NAME            MaintenanceMode   Status
user-vm-1-cluster   10.8.4.22       true              false
user-vm-1-cluster   10.8.4.23       false             false
user-vm-1-cluster   10.8.4.24       false             false
user-vm-1-cluster   172.20.128.13   false             false
user-vm-1-cluster   172.20.128.14   false             false
user-vm-1-cluster   172.20.128.15   false             false

Solution :

Définissez KUBECONFIG sur le fichier kubeconfig du cluster contenant le nœud à vider. Il peut s'agir du cluster d'utilisateur ou d'un cluster de services partagés.

for VM in $(kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints --no-headers | grep "baremetal.cluster.gke.io/maintenance" | awk '{print $1}'); do
  for i in {1..50}; do
    kubectl delete po -n kube-system $(kubectl get po -A -o wide  | grep ang | grep -e $VM| awk '{print $2}');
  done
done

Délai d'expiration persistant lors de l'organizationupgrade racine initiale

Versions : 1.13.3

Symptômes : si l'annotation "Ignorer l'intervalle de maintenance" est présente lors de la mise à niveau d'une organisation, le CR organizationupgrade est corrigé à plusieurs reprises, ce qui réinitialise la progression.

Solution :

Mettez en veille le sous-composant rm-org et réduisez le nombre d'instances répliquées rm-org-backend-controller.

  1. Si l'alias n'est pas déclaré, exécutez la commande suivante :

    alias ka="kubectl --kubeconfig=/root/release/root-admin/root-admin-kubeconfig"

  2. Mettez en veille le sous-composant et réduisez le scaling du déploiement pour rm-org :

    kubectl --kubeconfigROOT_ADMIN_KUBECONFIG annotate subcomponent -n root rm-org lcm.private.gdc.goog/paused=true
kubectl --kubeconfigROOT_ADMIN_KUBECONFIG scale deploy -n gpc-system rm-org-backend-controller --replicas=0

  3. Une fois la mise à niveau du cluster terminée, réduisez l'échelle du déploiement :

    kubectl --kubeconfigROOT_ADMIN_KUBECONFIG scale deploy -n gpc-system rm-org-backend-controller --replicas=1

Le sous-composant obj-syslog-server n'a pas pu être rapproché dans l'organisation racine

Versions : 1.13.3, 1.13.4, 1.13.5, 1.13.6

Symptômes : lors de la mise à niveau vers la version 1.13.x, le sous-composant obj-syslog-server est à l'état ReconciliationError :

root        obj-syslog-server     ReconciliationError

avec une condition semblable à :

Sub-Component: obj-syslog-server - Reconciliation error: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded

Last Transition Time: 2024-09-17T21:49:25Z
     Message: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded
     Observed Generation: 1
     ReconciliationError
     Status:True
     Type: Reconciling
     Last Transition Time: 2024-09-17T21:49:23Z
     Message: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded
     Observed Generation: 1
     Reason: DeployError
     Status: False
     Type: Deployed

Vous pouvez constater que le pod syslog-server-abcdefg-wxyz est à l'état CrashLoopBackOff avec l'erreur suivante :

       containerID: containerd://65d460176a1dcae412af698fa02fa5ffb0c5f0ef9bf0d0e2111ef88845630827
       exitCode: 128
       finishedAt: "2024-09-18T19:14:45Z"
       message: 'failed to create containerd task: failed to create shim task: OCI
         runtime create failed: runc create failed: unable to start container process:
         error during container init: error mounting "/var/lib/kubelet/pods/637cf395-e597-446d-9949-1371cca88970/volume-subpaths/observability-ca/syslog-server/2"
         to rootfs at "/etc/ssl/certs/obs-ca-cert.pem": mount /var/lib/kubelet/pods/637cf395-e597-446d-9949-1371cca88970/volume-subpaths/observability-ca/syslog-server/2:/etc/ssl/certs/obs-ca-cert.pem
         (via /proc/self/fd/6), flags: 0x5001: not a directory: unknown'
       reason: StartError
       startedAt: "1970-01-01T00:00:00Z"

Solution :

Pour rétablir l'état opérationnel du sous-composant, supprimez les volumeMounts inutiles.

  1. Modifiez le déploiement actuel :

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

    kubectl edit deployments syslog-server -n istio-system

  2. Supprimez les volumeMounts inutiles dans spec.containers.volumeMounts. Supprimez les chemins de montage suivants :

        - mountPath: /etc/ssl/certs/obs-ca-cert.pem
      name: observability-ca
      readOnly: true1.
      subPath: ca.crt
    - mountPath: /etc/ssl/certs/obj-ca-cert.pem
      name: obj-ca
      readOnly: true
      subPath: ca.crt

  3. Appliquez les modifications. Le sous-composant reviendra à l'état ReconciliationCompleted une fois les modifications appliquées.

La mise à niveau ABM ou de nœud est bloquée sur maintenanceMode false

Versions : 1.13.4

Symptômes : Le nœud est bloqué lors de la mise à niveau du cluster AnthosBaremetal et ne passe pas en mode maintenance.

Vérifiez la baremetalmachine sur un nœud de cluster de service, par exemple :

kubectl get baremetalmachine -n g-org-1-shared-service-cluster 192.0.2.0 -o json | jq .spec.maintenanceMode
false

Solution :

Redémarrez anthos-cluster-operator pour propager BMM.MaintenanceMode :

kubectl get baremetalmachine -n g-org-1-shared-service-cluster 192.0.2.0 -o json | jq .spec.maintenanceMode
true

Échec de la mise à niveau du module complémentaire atat-webhooks pour l'organisation locataire

Versions : 1.13.5

Problèmes constatés : la mise à niveau du module complémentaire atat-webhooks ne permet pas de récupérer les données :

org-1                                         atat-webhooks                                    false                                        false                                     1.13.4-gdch.5582

Un message de ce type peut s'afficher :

Status:                                                                                                                                                                                                        │
│   Conditions:                                                                                                                                                                                                  │
│     Last Transition Time:  2024-10-30T17:57:06Z                                                                                                                                                                │
│     Message:               Error occurred during addon installation: failed to generate parameters for AddOn[atat-webhooks]: failed to generate runtime parameters: parameter job not ready yet                │
│     Observed Generation:   4                                                                                                                                                                                   │
│     Reason:                InstallationError                                                                                                                                                                   │
│     Status:                False                                                                                                                                                                               │
│     Type:                  Deployed                                                                                                                                                                            │
│     Last Transition Time:  2024-10-30T17:56:36Z                                                                                                                                                                │
│     Message:               Reconciliation error

Vérifiez les pods pour atat-webhooks-parameters-***** : 

kubectl logs -n org-1 atat-webhooks-parameters-***** --kubeconfig ROOT_ADMIN_KUBECONFIG

Un message d'erreur semblable à celui-ci peut s'afficher :

E1030 22:04:33.242244       7 main.go:39] failed to generate parameter for AddOn [atat-webhooks], error: ATAT0003: Organization.resourcemanager.private.gdc.goog "org-1" is invalid: metadata.labels[atat.config.google.com/task-order-number]: Invalid value: "TO1234": The current date 2024-10-30 is not within the valid range of this TaskOrder: 2024-06-30 - 2024-10-30.

Solution :

  1. Créez une copie du portefeuille actuel :

    export KUBECONFIG=ROOT_ADMIN_KUBECONFIG

    kubectl get portfolios -n atat-system portfolio-org-1 -oyaml > portfolio-org-1

  2. Définissez portfolio-org-1 Pop End Date sur une date ultérieure :

    kubectl delete portfolios -n atat-system portfolio-org-1

    Si cette commande cesse de répondre, supprimez la condition .Metadata.Finalizers du portefeuille actif avant de supprimer le portefeuille. La condition peut se présenter comme suit :

    │     portfolio.finalizers.atat.config.google.com

  3. Appliquez à nouveau le fichier YAML copié :

    kubectl apply -f portfolio-org-1

  4. Vérifiez les dates pour vous assurer que les portefeuilles et la configmap sont à jour.

  5. Si la tâche ne se rétablit pas, supprimez la tâche atat-webhooks-parameters en échec. Elle se rétablira. Attendez la fin de l'opération :

    kubectl delete jobs -n org-1 atat-webhooks-parameters

Échec de la vérification post-vol ou de la mise à niveau en raison d'erreurs DeadlineExceeded ou BackoffLimitExceeded.

Versions : 1.13.8

Symptômes :

Lors de la mise à niveau de la version 1.13.7 vers la version 1.13.8, les vérifications post-migration sont toujours en attente et affichent des erreurs DeadlineExceeded ou BackoffLimitExceeded.

Message:postflight check result: pending, [NodeHealth (OS) HarborClusterHealth (AR)] still running 
Observed Generation: 3
Reason: ReconcileBackoff
Status: Unknown 
Type: ManagedCheckSucceeded 
Last Transition Time: 2025-02-13T02:11:41Z
Message: observed the following failure reasons: [ReconcileBackoff UpgradeCheckJobsInProgress]

Solution :

Identifiez les tâches qui échouent :

  1. Vérifiez si les tâches échouent lors des vérifications préliminaires ou post-déploiement :

    kubectl get jobs -A -l "upgrade.private.gdc.goog/use" -o json | jq '.items[] | select(.status.conditions | any(.reason == "BackoffLimitExceeded" or .reason == "DeadlineExceeded")) | {name: .metadata.name, namespace: .metadata.namespace, status: .status.conditions[].type, reason: .status.conditions[].reason}'

  2. Vérifiez si les jobs échouent lors de la mise à niveau :

    kubectl get jobs -A -l "upgrade.private.gdc.goog/upgrade-check-owner" -o json | jq '.items[] | select(.status.conditions | any(.reason == "BackoffLimitExceeded" or .reason == "DeadlineExceeded")) | {name: .metadata.name, namespace: .metadata.namespace, status: .status.conditions[].type, reason: .status.conditions[].reason}'

  3. Supprimez les jobs :

    kubectl delete jobs -n gpc-system CHECK_NAME

Les vérifications de mise à niveau incluent des résultats non pertinents pour le niveau de vérification

Versions : 1.13.x

Symptômes :

Les vérifications de la mise à niveau de l'organisation peuvent échouer en raison de résultats inclus de manière incorrecte à partir d'autres niveaux. Par exemple, les vérifications de l'organisation racine peuvent afficher les résultats de l'organisation locataire, ou les vérifications de l'organisation locataire peuvent afficher les résultats du cluster d'utilisateurs.

Exemples de journaux d'échec pour les vérifications de l'organisation racine :

kubectl logs -n gpc-system upgrade-check-postflight-haas-n2rk2-zv9rr --kubeconfig /root/release/root-admin/root-admin-kubeconfig
... {org-1 admin } failure ...

Solution :

Pour ignorer complètement les vérifications préliminaires ou post-vol, utilisez la commande suivante :

Requête préliminaire :

kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok

Après la diffusion :

kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-postflight-check=ok

Vertex AI

Les API pré-entraînées affichent l'état Enabling dans l'interface utilisateur.

Versions : 1.13.1

Problèmes constatés : MonitoringTarget affiche l'état Not Ready lors de la création de clusters d'utilisateur, ce qui entraîne l'affichage continu de l'état Enabling pour les API pré-entraînées dans l'interface utilisateur.

Solution :

  1. Ouvrez le menu de votre navigateur Chrome (icône à trois points).
  2. Cliquez sur Plus d'outils > Outils pour les développeurs pour ouvrir la console.
  3. Cliquez sur l'onglet Réseau dans la console.
  4. Recherchez les demandes ai-service-status.
  5. Cliquez sur l'onglet Réponse d'une requête ai-service-status pour afficher le contenu de cette requête.
  6. Vérifiez que tout semble prêt, à l'exception des composants MonitoringTarget et LoggingTarget.

Échec de la fonction d'API pré-entraînée streaming_recognize de Speech-to-Text

Versions : 1.13.3

Symptômes : lorsque vous appelez la fonction d'API pré-entraînée streaming_recognize de Speech-to-Text, un problème lié à la bibliothèque cliente génère un message d'erreur 400 semblable à ce qui suit :

google.api_core.exceptions.InvalidArgument: 400 The header 'x-goog-user-project' should be set

Solution de contournement : utilisez le script Python suivant pour permettre à la fonction streaming_recognize de fonctionner :

import base64

from google.cloud import speech_v1p1beta1
from google.cloud.speech_v1p1beta1.services.speech import client
import google.auth
from google.auth.transport import requests
import requests as reqs
from google.api_core.client_options import ClientOptions
import os

audience= "https://ENDPOINT:443"
api_endpoint="ENDPOINT:443"
os.environ["GOOGLE_APPLICATION_CREDENTIALS"] = "APPLICATION_DEFAULT_CREDENTIALS_FILENAME"
os.environ["GRPC_DEFAULT_SSL_ROOTS_FILE_PATH"] = "CERT_NAME"

def get_client(creds):
  opts = ClientOptions(api_endpoint=api_endpoint)
  return client.SpeechClient(credentials=creds, client_options=opts)

def main():
  creds = None
  try:
    creds, project_id = google.auth.default()
    creds = creds.with_gdch_audience(audience)
    sesh = reqs.Session()
    sesh.verify = False
    req = requests.Request(session=sesh)
    creds.refresh(req)
  except Exception as e:
    print("Caught exception" + str(e))
    raise e
  return creds

def speech_func(creds):
  tc = get_client(creds)
  content="[ENCODED CONTENT STRING HERE]"

  audio = speech_v1p1beta1.RecognitionAudio()
  audio.content = base64.standard_b64decode(content)
  config = speech_v1p1beta1.StreamingRecognitionConfig()
  config.config.encoding= speech_v1p1beta1.RecognitionConfig.AudioEncoding.LINEAR16
  config.config.sample_rate_hertz=16000
  config.config.language_code="en-US"
  config.config.audio_channel_count=1

  request_config = speech_v1p1beta1.StreamingRecognizeRequest(
    streaming_config = config,
  )

  request_audio = speech_v1p1beta1.StreamingRecognizeRequest(
    audio_content = audio.content
  )

  requests = [request_config, request_audio]

  def request_generator():
      for request in requests:
          yield request

  metadata = (("x-goog-user-project", "projects/vtx-pretrained"),)
  resp = tc.streaming_recognize(requests=request_generator(), metadata=metadata)

  for response in resp:
    print(response)

if __name__=="__main__":
  creds = main()
  speech_func(creds)

Remplacez les éléments suivants :

Le script Python introduit les différences suivantes entre les fonctions streaming_recognize et recognize pour que la solution de contournement pour streaming_recognize fonctionne :

  • Ligne 4 : instruction import supplémentaire par rapport au script recognize (from google.cloud.speech_v1p1beta1.services.speech import client).
  • Ligne 18 : le client est renvoyé par client.SpeechClient() au lieu de speech_v1p1beta1.SpeechClient().

Le pod et le service de l'interface de traduction ne parviennent pas à s'initialiser

Versions : 1.11.x, 1.12.x, 1.13.x

Symptômes : lors des mises à niveau, le cluster de bases de données Translation est recréé, ce qui entraîne l'obsolescence et la désynchronisation du secret secret-store du cluster système ODS. C'est pourquoi le pod et le service de l'interface de traduction ne parviennent pas à s'initialiser.

Solution :

Supprimez le secret dans le cluster système :

kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n ai-translation-system

Remplacez SYSTEM_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig dans le cluster système.

Un contrôleur recrée automatiquement le secret et le resynchronise avec le cluster de bases de données.

L'interrogation de l'état des jobs n'est pas compatible avec l'API batchTranslateDocument.

Versions : 1.13.3

Symptômes : Vertex AI n'est pas compatible avec les opérations GET et LIST dans les API du service de traduction. L'appel de l'API Translation BatchTranslateDocument renvoie une opération de longue durée semblable à l'exemple suivant :

{
  "name": "projects/PROJECT_ID/operations/OPERATION_ID",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.translation.v3.BatchTranslateDocumentMetadata",
    "state": "RUNNING"
  }
}

Ce problème est dû à une limitation de l'APIP (autorisation) qui vous empêche d'appeler directement le point de terminaison. Les points de terminaison ne sont pas compatibles avec l'interrogation de l'état des jobs. De plus, vous ne pouvez pas effectuer d'opérations GET sur l'opération de longue durée en raison de la limitation de l'APIP.

Solution de contournement : En tant qu'opérateur d'application (AO), vérifiez l'état du job en consultant régulièrement votre dossier s3_destination et recherchez un fichier de sortie de job nouvellement créé. Si le dossier contient le fichier de sortie, cela signifie que le job s'est terminé correctement.

Les requêtes batchTranslateDocument peuvent entraîner des problèmes de performances

Versions : 1.13.3

Symptômes : le service de traduction de documents par lot lit un ou plusieurs fichiers d'entrée utilisateur et écrit les fichiers de sortie traduits et de traitement temporaire dans StorageGRID. Un client curl est créé pour chaque action de lecture/écriture, car la réutilisation du client échoue.

Les clients S3 curl du binaire sont à usage unique, ce qui signifie que chaque client ne peut effectuer qu'une seule action de lecture/écriture sur les buckets StorageGRID. Par conséquent, un nouveau client curl est créé chaque fois qu'une communication avec le client StorageGRID est établie à partir du serveur batchTranslateDocument pour lire et écrire des fichiers dans des buckets.

Toutefois, cette méthode n'est pas optimale pour les clients curl. Cela peut entraîner les problèmes suivants :

  • Dégradation des performances : augmentation de la latence et diminution du débit
  • Épuisement des ressources : surcharge de mémoire et de processeur, et épuisement des sockets
  • Surcharge des serveurs : limitation du débit ou des requêtes

La console GDC affiche un état incohérent après l'activation des API pré-entraînées

Versions : 1.13.3

Symptômes : lorsque vous activez des API pré-entraînées pour la première fois, la console GDC peut afficher un état incohérent pour votre service activé après quelques minutes. La console GDC rétablit l'état Enabling sur Disabled et affiche à nouveau le bouton Activer dans l'interface utilisateur, même si le service est en fait en cours d'activation.

Solution : L'état devient cohérent après quelques minutes et le service reflète son état correct.

Pour vérifier l'état du service, ouvrez l'onglet Réseau dans la console du navigateur et vérifiez l'état de la requête ai-service-status. La charge utile doit indiquer que l'opérateur de niveau 2 est activé.

Les demandes de traduction de plus de 250 caractères entraînent le plantage des pods translation-prediction-server

Versions : 1.13.3

Symptômes : lorsque vous envoyez des requêtes de traduction d'environ 250 caractères ou plus (y compris les requêtes de traduction de documents), les pods translation-prediction-0 ou translation-prediction-1 peuvent planter, ce qui nécessite de recharger le modèle. Le rechargement du modèle est automatique et peut prendre environ 30 minutes.

Ce problème est dû à une limitation des conteneurs de traduction.

Solution de contournement : Divisez les demandes de traduction pour qu'elles comportent moins de 250 caractères. Une longueur comprise entre 200 et 250 caractères est acceptable pour toutes les langues. Aucune autre action n'est requise pour atténuer le problème si une longue requête provoque le plantage des pods.

GPUAllocation pour le cluster de services partagés n'est pas configuré correctement

Versions : 1.13.3

Symptômes : les charges de travail Vertex AI ne peuvent pas être planifiées en raison d'un manque de ressources GPU suffisantes. Par exemple, si vous ne parvenez pas à afficher ni à activer les points de terminaison de service Vertex AI, cela peut être dû à un manque de ressources GPU suffisantes.

Ce problème de ressources peut être dû à l'absence de l'annotation suivante dans certaines ressources GPUAllocation situées dans le cluster de services partagés :

processed: "true"

Solution :

  1. Suivez IAM-R0004 pour générer le fichier kubeconfig pour g-ORG_NAME-shared-service-cluster.

  2. Répertoriez toutes les allocations de GPU dans le cluster de service qui ne comportent pas l'annotation processed: "true" :

    kubectl get gpuallocations -A -n vm-system \
    --kubeconfig SERVICE_CLUSTER_KUBECONFIG \
    -o json | jq \
    '.items[] | select(.metadata.annotations.processed == null ) | .metadata.name'

    Le résultat ressemble à ce qui suit :

    zi-ad-bm08

  3. Ouvrez la ressource GPUAllocation non allouée dans un éditeur :

    kubectl edit gpuallocation -n vm-system NODE_NAME

  4. Modifiez l'allocation de GPU en fonction du nombre total d'allocations de GPU présentes dans le cluster de services :

    • S'il n'existe qu'une seule ressource personnalisée d'allocation de GPU, ajoutez-y l'annotation processed: "true" et modifiez sa spécification pour qu'elle ressemble à ce qui suit :

      annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 4
    profiles:
    - mixed-5
    - uniform-3g.40gb
    - uniform-3g.40gb
    - uniform-7g.80gb
  node: $node_name // unchanged
  pod: 0
  vm: 0

    • S'il existe deux ressources personnalisées d'allocation de GPU, recherchez celle sans l'annotation processed: "true", ajoutez-y l'annotation processed: "true" et modifiez sa spécification pour qu'elle ressemble à ce qui suit :

      annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 2
    profiles:
    - mixed-5
    - uniform-3g.40gb
  node: $node_name // unchanged
  pod: 0
  vm: 0

    • S'il existe quatre ressources personnalisées d'allocation de GPU, recherchez celle sans l'annotation processed: "true", ajoutez-y l'annotation processed: "true" et modifiez sa spécification pour qu'elle ressemble à ce qui suit :

      annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 1
    profiles:
    - mixed-5
  node: $node_name // unchanged
  pod: 0
  vm: 0

  5. Enregistrez les modifications apportées à la ressource personnalisée GPUAllocation et vérifiez que son état d'allocation est défini sur true :

    kubectl get gpuallocations -A --kubeconfig SERVICE_CLUSTER_KUBECONFIG

    Le résultat ressemble à ce qui suit :

    NAMESPACE   NAME         ALLOCATED   DEVICEMODEL
vm-system   zi-ad-bm08   true        H100L 94GB
vm-system   zi-ad-bm09   true        H100L 94GB

Lors de la mise à niveau de la version 1.9.x vers la version 1.13.3, le contrôleur OCLCM affiche des erreurs

Versions : 1.13.3

Symptômes : lors de la mise à niveau de la version 1.9.x vers la version 1.13.3, le contrôleur OCLCM (Operable Component Lifecycle Management) pour les sous-composants Vertex AI peut afficher des erreurs. Ce problème est dû à une erreur liée au job du module complémentaire ai_platform. Les erreurs que vous recevez lors de la mise à niveau indiquent qu'OCLCM ne peut pas transférer la propriété de ces composants Vertex AI.

Voici les composants Vertex AI concernés dans le cluster administrateur de l'organisation :

Nom Espace de noms
aip-l1operator-deployment ai-system
aip-l2operator-deployment ai-system
aip-web-plugin-frontend ai-system
aip-web-plugin-backend ai-system
aip-l1operator-sa ai-system
aip-l2operator-sa ai-system
aip-web-plugin-sa ai-system
aip-l1operator-role N/A
aip-l2operator-role N/A
aip-web-plugin-role N/A
aip-l1operator-rolebinding N/A
aip-l2operator-rolebinding N/A
aip-web-plugin-rolebinding N/A
aip-l1operator-log ai-system
aip-l2operator-log ai-system
aip-web-plugin-frontend-log ai-system
aip-web-plugin-backend-log ai-system
log-rule-aipl-a004 platform-obs
mon-rule-aipl-a0001 platform-obs
mon-rule-aipl-a0003 platform-obs
aip-l1operator-mon ai-system
aip-l1operator-mon-cm ai-system
aip-l2operator-mon ai-system
aip-l2operator-mon-cm ai-system
aip-l1operator-webhook-svc ai-system
aip-web-plugin-frontend-svc ai-system
aip-web-plugin-backend-svc ai-system
aip-web-plugin-frontend-virtualsvc ai-system
aip-web-plugin-backend-virtualsvc ai-system
aip-l1operator-selfsigned-issuer ai-system
aip-l1operator-serving-cert ai-system
aip-l1operator-validating-webhook ai-system
aip-l1operator-mutating-webhook ai-system

Solution de contournement : Pour résoudre ce problème, vous devez supprimer manuellement les composants Vertex AI concernés du cluster d'administrateur de l'organisation. La nouvelle version de Vertex AI basée sur OCLCM les réinstalle ensuite.

Supprimez manuellement les composants Vertex AI concernés dans le cluster d'administrateur de l'organisation :

kubectl --kubeconfig=ORG_ADMIN_CLUSTER_KUBECONFIG delete deployment -n NAMESPACE COMPONENT_NAME

Remplacez les éléments suivants :

  • ORG_ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig dans le cluster d'administrateur de l'organisation.
  • NAMESPACE : espace de noms du composant Vertex AI que vous souhaitez supprimer. Si le composant n'a pas d'espace de noms, supprimez -n NAMESPACE de la commande.
  • COMPONENT_NAME : nom du composant Vertex AI que vous souhaitez supprimer.

L'exemple suivant montre comment supprimer le composant aip-l1operator-deployment qui existe dans l'espace de noms ai-system sur le cluster d'administrateur de l'organisation :

kubectl --kubeconfig=ORG-ADMIN-CLUSTER-KUBECONFIG delete deployment -n ai-system aip-l1operator-deployment

Les demandes de traduction peuvent générer le code d'erreur RESOURCE_EXHAUSTED

Versions : 1.13.3

Symptômes : après avoir envoyé une demande de traduction, vous obtenez le code d'erreur RESOURCE_EXHAUSTED dans le message de réponse. Cette erreur se produit lorsque vous dépassez une limite de fréquence système. Une ressource a été épuisée (par exemple, un quota par utilisateur a été atteint, le nombre maximal de requêtes par seconde a été dépassé ou le système de fichiers dans son intégralité manque d'espace).

Solution : Demandez à votre opérateur d'infrastructure de redémarrer les shards de backend du service de traduction. Ensuite, renvoyez les demandes de traduction en augmentant le délai entre les demandes ou en envoyant des demandes plus courtes.

batchTranslateDocument renvoie une erreur 503

Versions : 1.13.3

Symptômes : après avoir envoyé une requête batchTranslateDocument, vous obtenez le code d'erreur 503 "Batch Document translation is not implemented" dans le message de réponse. Cette erreur se produit, car la méthode BatchTranslateDocument nécessite le service Aspose, qui n'est déployé que lorsque le paramètre opérationnel enableRAG est défini sur true dans le cluster.

Solution de contournement : Demandez à votre opérateur d'infrastructure (IO) de définir le paramètre enableRAG sur true dans le cluster d'administration de l'organisation en procédant comme suit :

  1. Créez une ressource personnalisée SubcomponentOverride dans un fichier YAML nommé vai-translation.yaml avec le paramètre enableRAG défini sur true :

    apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: "vai-translation"
  namespace: ORG_ADMIN_NAMESPACE
spec:
  subComponentRef: "vai-translation"
  backend:
    operableParameters:
      enableRAG: true

    Remplacez ORG_ADMIN_NAMESPACE par l'espace de noms du cluster d'administrateur de l'organisation.

  2. Appliquez la ressource personnalisée SubcomponentOverride au cluster d'administration de l'organisation :

    kubectl --kubeconfig ORG_ADMIN_KUBECONFIG apply -f vai-translation.yaml

    Remplacez ORG_ADMIN_KUBECONFIG par le chemin d'accès au fichier kubeconfig dans le cluster d'administrateur de l'organisation.

Services Vertex AI pré-entraînés indisponibles

Versions : 1.13.7, 1.13.9

Symptômes : les services Vertex AI OCR et Translation ne démarrent pas en raison de problèmes de planification Kubernetes. Un avertissement semblable à celui-ci peut s'afficher dans les journaux :

 Warning  FailedScheduling  105s (x40 over 3h18m)  default-scheduler  0/9 nodes are available: 1 Insufficient nvidia.com/mig-3g.40gb-NVIDIA_A100_80GB_PCIE, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-billing-
system-billing-dbcluster: }, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-g-vai-ocr-sie-g-vai-ocr-sie: }, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-g-vai-translation-sie-g-v-1gvg:
 }, 3 Insufficient cpu, 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }. preemption: 0/9 nodes are available: 3 No preemption victims found for incoming pod, 6 Preemption is not helpful for scheduling.

Solution de contournement : Ajoutez des nœuds de calcul au pool par défaut et supprimez les pods sur les nœuds GPU afin que les charges de travail d'IA puissent être planifiées.

Machines virtuelles

Échec de l'importation d'images BYO pour les images qcow2 et brutes

Versions : 1.13.1, 1.13.3

Symptômes : lorsque des images de VM locales sont importées à l'aide de la CLI gdcloud compute images import, l'état de l'importation est bloqué sur WaitingForTranslationVM ou ImportJobNotCreated. En effet, le disque temporaire créé pour la traduction ou l'importation utilise exactement la même taille que l'image qcow2/raw, mais LUKS ajoute une surcharge de quelques Mio, ce qui entraîne l'échec du provisionnement du disque.

Solution :

Créez manuellement un VirtualMachineImageImport avec le même nom d'image, mais avec un spec.minimumDiskSize plus grand.

Par exemple, si la commande utilisée pour importer l'image était la suivante :

gdcloud compute images import $IMPORT_NAME --project $PROJECT --source-file=$LOCAL_FILENAME --os=$OS

Si le VirtualMachineImageImport d'origine créé automatiquement par la CLI a une taille de X Gio, créez-en un nouveau avec une taille de X+1 Gio.minimumDiskSize La valeur dépend de la taille de l'image importée. Dans le cas de qcow2, il s'agit de la taille virtuelle. Par exemple, 20 Gio doit être remplacé par 21 Gio.

Remplacez les valeurs des espaces réservés en fonction de la façon dont la CLI a été appelée.

  1. Recherchez le VirtualMachineImageImport :

    kubectl get virtualmachineimageimport $IMPORT_NAME -n $PROJECT -o yaml

    Si l'objet n'est pas présent, déclenchez à nouveau la commande gdcloud compute images import .... Une fois que la sortie de la console passe de Uploading image to .. à Image import has started for ..., appuyez sur Ctrl+C pour que l'image locale soit importée dans le stockage d'objets et que VirtualMachineImageImport soit conservé pour référence afin d'en créer un.

  2. Créez un VirtualMachineImageImport avec un minimumDiskSize plus grand :

    apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineImageImport
metadata:
  name: $IMPORT_NAME_NEW
  namespace: $NAMESPACE
spec:
  imageMetadata:
    minimumDiskSize: $NEW_SIZE
    name: $IMAGE_NAME
    operatingSystem: $OS
  source:
    objectStorage:
      bucketRef:
        name: vm-images-bucket
      objectName: $LOCAL_FILENAME

Échec du provisionnement d'un disque à partir d'une image

Versions : 1.13.1, 1.13.3

Problèmes constatés : lorsque vous provisionnez un disque à partir d'une image personnalisée, la valeur minimumDiskSize peut être trop proche de la taille virtuelle, ce qui entraîne l'échec du provisionnement du disque. Le disque de la VM est à l'état "En attente", mais n'est jamais provisionné.

Solution de contournement : créez manuellement un disque avec un spec.minimumDiskSize plus grand.

Le plug-in d'appareils NVIDIA DaemonSet échoue lorsqu'un cluster possède des GPU

Versions : 1.13.3

Symptômes : le plug-in d'appareils NVIDIA DaemonSet échoue avec le message driver rpc error sur les nœuds de cluster avec GPU :

kubectl --kubeconfig KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

Remplacez KUBECONFIG par le chemin d'accès au fichier kubeconfig dans le cluster.

Vous obtenez un résultat semblable à l'exemple suivant :

Warning  Failed     23m (x4 over 25m)  kubelet            Error: failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error running hook #0: error running hook: exit status 1, stdout: , stderr: Auto-detected mode as 'legacy'
nvidia-container-cli: initialization error: driver rpc error: timed out: unknown

Ce problème empêche les machines virtuelles (VM) et les pods d'utiliser les GPU. Les implications sont basées sur les types de clusters suivants :

  • Cluster système : la ressource personnalisée GPUAllocation n'est pas créée pour ce nœud Bare Metal, et les GPU de ce nœud ne sont pas configurés en mode VM pour être utilisés par le service et le cluster d'utilisateur. Pour résoudre ce problème, consultez la solution de contournement pour le cluster système.
  • Cluster de service ou d'utilisateur : la ressource personnalisée GPUAllocation n'est pas créée pour ce nœud de VM, et les GPU de ce nœud ne peuvent pas être utilisés par les pods du cluster. Pour résoudre ce problème, consultez la solution de contournement pour le cluster de service ou d'utilisateur.

Solution de contournement pour le cluster système :

Pour résoudre le problème dans le cluster système, procédez comme suit :

  1. Définissez la variable d'environnement KUBECONFIG avec le chemin d'accès au fichier kubeconfig dans le cluster système. Pour en savoir plus, consultez le runbook IAM-R0004.

  2. Identifiez le nœud qui pose problème :

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:

    La sortie doit afficher le nom du nœud et l'adresse IP du nœud Kubernetes.

    S'il existe plusieurs nœuds, exécutez les étapes sur chacun d'eux. Dans ce cas, le résultat ressemble à l'exemple suivant :

    Node:                 yy-ab-bm04/172.20.128.26

  3. Définissez la variable d'environnement NODE_NAME avec le nom du nœud, par exemple :

    export NODE_NAME=yy-ab-bm04

  4. Établissez une connexion SSH avec le nœud. Pour en savoir plus, consultez le runbook PLATAUTH-G0001.

  5. Vérifiez que le nœud dispose de GPU :

    nvidia-smi -L

    Le résultat doit afficher les GPU du nœud, comme dans l'exemple suivant :

    GPU 0: NVIDIA H100 NVL (UUID: GPU-0f6179a7-71a8-c654-44f0-1542bddf2574)
GPU 1: NVIDIA H100 NVL (UUID: GPU-4debf794-d8a5-74a2-e521-0c763288ea79)
GPU 2: NVIDIA H100 NVL (UUID: GPU-5827b65a-3841-d877-fc17-881a2b71d416)
GPU 3: NVIDIA H100 NVL (UUID: GPU-31448904-9ae2-c95a-1986-a56cce004f49)

  6. Activez le mode persistance sur les GPU :

    nvidia-smi -pm 1

    Cette action garantit que les pilotes NVIDIA sont toujours chargés afin que le plug-in de l'appareil n'expire pas.

    Le résultat doit ressembler à l'exemple ci-dessous :

    Enabled persistence mode for GPU 00000000:4E:00.0.
Enabled persistence mode for GPU 00000000:62:00.0.
Enabled persistence mode for GPU 00000000:C9:00.0.
Enabled persistence mode for GPU 00000000:DE:00.0.
All done.

  7. Quittez la session SSH :

    exit

  8. Vérifiez que le plug-in de l'appareil est en cours d'exécution en interrogeant DaemonSet :

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

  9. Vérifiez que la ressource personnalisée GPUAllocation est créée et configurée en mode VM :

    kubectl --kubeconfig $KUEBCONFIG get gpuallocation -n vm-system $NODE_NAME -o yaml

    Le résultat doit ressembler à l'exemple ci-dessous :

    apiVersion: gpu.cluster.gke.io/v1
kind: GPUAllocation
metadata:
  annotations:
    processed: "true"
  creationTimestamp: "2024-08-21T07:03:18Z"
  generation: 2
  name: yy-ab-bm04
  namespace: vm-system
  resourceVersion: "12179728"
  uid: b840cb53-5b0b-45bf-ab26-66db98fd64a4
spec:
  node: yy-ab-bm04
  pod: 0
  vm: 4
status:
  allocated: true
  conditions:
  - lastTransitionTime: "2024-08-21T07:05:49Z"
    message: ""
    observedGeneration: 2
    reason: AllocationFulfilled
    status: "True"
    type: AllocationStatus
  - lastTransitionTime: "2024-08-21T07:03:53Z"
    message: ""
    observedGeneration: 2
    reason: DeviceStateUpdated
    status: "True"
    type: DeviceStateUpdated
  consumption:
    pod: 0/0
    vm: 4/4
  deviceModel: H100L 94GB

Solution de contournement pour le service ou le cluster d'utilisateurs :

Pour résoudre le problème dans le service ou le cluster, procédez comme suit :

  1. Définissez la variable d'environnement KUBECONFIG avec le chemin d'accès au fichier kubeconfig dans le cluster de service ou d'utilisateur. Pour en savoir plus, consultez le runbook IAM-R0004.

  2. Identifiez le nœud qui pose problème :

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:

    La sortie doit afficher le nom du nœud et l'adresse IP du nœud Kubernetes.

    S'il existe plusieurs nœuds, exécutez les étapes sur chacun d'eux. Dans ce cas, le résultat ressemble à l'exemple suivant :

    Node:                 vm-948fa7f4/172.20.128.21

  3. Définissez la variable d'environnement NODE_NAME avec le nom du nœud, par exemple :

    export NODE_NAME=vm-948fa7f4

  4. Établissez une connexion SSH avec le nœud. Pour en savoir plus, consultez le runbook PLATAUTH-G0001.

  5. Vérifiez que le nœud dispose de GPU :

    nvidia-smi -L

    Le résultat doit afficher les GPU du nœud, comme dans l'exemple suivant :

    GPU 0: NVIDIA H100 NVL (UUID: GPU-0f6179a7-71a8-c654-44f0-1542bddf2574)
GPU 1: NVIDIA H100 NVL (UUID: GPU-4debf794-d8a5-74a2-e521-0c763288ea79)

  6. Activez le mode persistance sur les GPU :

    nvidia-smi -pm 1

    Cette action garantit que les pilotes NVIDIA sont toujours chargés afin que le plug-in de l'appareil n'expire pas.

    Le résultat doit ressembler à l'exemple ci-dessous :

    Enabled persistence mode for GPU 00000000:05:00.0.
Enabled persistence mode for GPU 00000000:06:00.0.
All done.

  7. Quittez la session SSH :

    exit

  8. Vérifiez que le plug-in de l'appareil est en cours d'exécution en interrogeant DaemonSet :

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

  9. Vérifiez que la ressource personnalisée GPUAllocation est créée et configurée en mode VM :

    kubectl --kubeconfig $KUBECONFIG get gpuallocation -n vm-system $NODE_NAME -o yaml

    Le résultat doit ressembler à l'exemple ci-dessous :

    apiVersion: gpu.cluster.gke.io/v1
kind: GPUAllocation
metadata:
  annotations:
    processed: "true"
  creationTimestamp: "2024-08-21T07:03:18Z"
  generation: 2
  name: vm-948fa7f4
  namespace: vm-system
  resourceVersion: "12179728"
  uid: b840cb53-5b0b-45bf-ab26-66db98fd64a4
spec:
  node: vm-948fa7f4
  pod: 2
  vm: 0
status:
  allocated: true
  conditions:
  - lastTransitionTime: "2024-08-21T07:05:49Z"
    message: ""
    observedGeneration: 2
    reason: AllocationFulfilled
    status: "True"
    type: AllocationStatus
  - lastTransitionTime: "2024-08-21T07:03:53Z"
    message: ""
    observedGeneration: 2
    reason: DeviceStateUpdated
    status: "True"
    type: DeviceStateUpdated
  consumption:
    pod: 0/2
    vm: 0/0
  deviceModel: H100L 94GB

La VM du cluster système n'est pas prête

Versions : 1.13.3

Problèmes constatés : la VM du cluster système n'est pas prête. Un message de ce type peut s'afficher :

│ Conditions:                                                                                                                                   │
│   Type                          Status    LastHeartbeatTime                 LastTransitionTime                Reason                          │
│  Message                                                                                                                                      │
│   ----                          ------    -----------------                 ------------------                ------                          │
│  -------                                                                                                                                      │
│   KubeletUnhealthy              False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:37 +0000   KubeletIsHealthy                │
│  kubelet on the node is functioning properly                                                                                                  │
│   KernelDeadlock                False     Tue, 20 Aug 2024 02:10:42 +0000   Sun, 30 Jun 2024 16:53:33 +0000   KernelHasNoDeadlock             │
│  kernel has no deadlock                                                                                                                       │
│   ReadonlyFilesystem            False     Tue, 20 Aug 2024 02:10:42 +0000   Sun, 30 Jun 2024 16:53:33 +0000   FilesystemIsNotReadOnly         │
│  Filesystem is not read-only                                                                                                                  │
│   FrequentUnregisterNetDevice   False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:40 +0000   NoFrequentUnregisterNetDevice   │
│  node is functioning properly                                                                                                                 │
│   ContainerRuntimeUnhealthy     False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:39 +0000   ContainerRuntimeIsHealthy       │
│  Container runtime on the node is functioning properly                                                                                        │
│   FrequentKubeletRestart        False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:41 +0000   NoFrequentKubeletRestart        │
│  kubelet is functioning properly                                                                                                              │
│   FrequentDockerRestart         False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:40 +0000   NoFrequentDockerRestart         │
│  docker is functioning properly                                                                                                               │
│   FrequentContainerdRestart     False     Tue, 20 Aug 2024 02:10:42 +0000   Thu, 15 Aug 2024 01:44:23 +0000   NoFrequentContainerdRestart     │
│  containerd is functioning properly                                                                                                           │
│   MemoryPressure                Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   DiskPressure                  Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   PIDPressure                   Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   Ready                         Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.

Solution :

  1. Recherchez le VirtualMachineInstance et supprimez-le.
  2. Redémarrez une nouvelle VM.

Espace temporaire des rapports sur le volume de données introuvable

Versions : 1.13.3, 1.13.4

Symptômes : lorsque vous créez un disque de VM, le volume de données est indiqué comme créé :

gdch-vm-infra   gdc-vm-disk-vm-ce34b8ea-disk   Succeeded   100.0%     1          18h

Toutefois, un pod d'importateur, tel que importer-gdc-vm-disk-vm-ce34b8ea-disk, effectue des boucles de plantage avec un message semblable à celui-ci :

E0823 16:14:15.920008       1 data-processor.go:251] scratch space required and none found
E0823 16:14:15.920017       1 importer.go:185] scratch space required and none found

Solution : Supprimez le pod d'importateur après avoir confirmé que l'état du volume de données est Succeeded.

Les VM des projets dont le nom comporte plus de 45 caractères restent à l'état arrêté

Versions : 1.13.5

Symptômes : lors de la création d'une VM, celle-ci reste à l'état Stopped si le nom du projet comporte plus de 45 caractères.

Solution : Créez un projet dont le nom ne dépasse pas 45 caractères.

L'allocation de GPU est manquante sur le cluster de service

Versions : 1.13.5

Problèmes constatés : le GPUAllocation est manquant dans le cluster de services partagés de gpu-org. Un message peut s'afficher lorsque vous obtenez les allocations de GPU :

KUBECONFIG=/root/release/user/gpu-org-shared-service-kubeconfig kubectl get gpuallocations -A

Le résultat ressemble à ceci :

No resources found

Solution :

  1. Ajoutez un rejet au nœud GPU :

    taints:
  - effect: NoExecute
    key: vmm.gdc.goog/gpu-node
    value: a3-highgpu-4g

  2. Supprimez le rejet pour autoriser la programmation du pod virt-launcher de la VM.

Impossible de planifier la VM de nœud de calcul du cluster de service partagé

Versions : 1.13.6

Symptômes : une VM de nœud de calcul Kubernetes n'a pas pu être planifiée en raison de ressources de processeur insuffisantes sur le nœud désigné, malgré la disponibilité de GPU. Un événement semblable à celui-ci peut s'afficher :

Warning  FailedScheduling  33m (x29 over 92m)    default-scheduler  0/9 nodes are available: 1 Insufficient memory, 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }, 5 Insufficient cpu, 5 Insufficient nvidia.com/gpu-vm-H100L_94GB. preemption: 0/
9 nodes are available: 3 Preemption is not helpful for scheduling, 6 No preemption victims found for incoming pod.

Solution :

  1. Arrêtez manuellement les VM sans GPU pour libérer des ressources de processeur.
  2. Une fois la VM en attente planifiée, démarrez les VM sans GPU.