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

Sauvegarde et restauration

La modification du plan de restauration de sauvegarde du cluster ne fonctionne pas

Versions : 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

Symptômes :

La ressource personnalisée RestorePlan ne peut pas être modifiée à l'aide de la console GDC.

Solution :

Créez un plan de restauration et supprimez l'ancien, ou modifiez le plan de restauration à l'aide de kubectl CLI.

Taille du disque source non valide

Versions : 1.14.4, 1.14.5

Symptômes : l'UI affiche de manière incorrecte une taille de disque de 0 Mo et une heure de création "Inconnue" en raison d'une modification du modèle de données backend après la migration vers l'architecture d'organisation v2.

Solution : il n'existe aucune autre méthode pour afficher ces informations dans l'UI.

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

Versions : 1.14.3, 1.14.4

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.

Les SLO de sauvegarde et de restauration ne sont pas appliqués

Versions : 1.14.3, 1.14.4

Symptômes : les métriques et les alertes concernant les objectifs de niveau de service (SLO) GDC ne sont pas configurées par défaut, car la définition de ressource personnalisée nécessaire n'est pas installée. Ces alertes sont utilisées dans Grafana.

Solutions de contournement : pour activer les SLO pour la sauvegarde et la restauration dans GDC, suivez le runbook BACK-T0001.

Les règles de conservation ne sont pas appliquées aux sauvegardes importées.

Versions : toutes les versions de Google Distributed Cloud (GDC) sous air gap peuvent être concernées.

Symptômes : L'association d'un dépôt de sauvegarde au cluster synchronise toutes les métadonnées de sauvegarde et de restauration, et traite les dépôts comme des sauvegardes importées. Ces sauvegardes importées sont ignorées à tort lors de la réconciliation, ce qui signifie que les règles de conservation sont ignorées et que les sauvegardes sont conservées indéfiniment.

Solution : Les sauvegardes importées sont signalées par l'icône backup.gdc.goog/imported-repository:BACKUP_REPOSITORY_NAME. Pour autoriser le rapprochement normal et l'application des règles de conservation, supprimez le libellé des sauvegardes à l'aide des commandes kubectl suivantes :

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

   export KUBECONFIG=KUBECONFIG
   export BACKUP_REPOSITORY_NAME=BACKUP_REPOSITORY_NAME
   export NAMESPACE=BACKUP_PLAN_NAMESPACE
   

   Remplacez les éléments suivants :

   • KUBECONFIG : chemin d'accès au fichier kubeconfig.
   • BACKUP_REPOSITORY_NAME : nom du dépôt de sauvegarde.
   • NAMESPACE : espace de noms contenant le plan de sauvegarde.

2. Répertoriez toutes les sauvegardes importées :

   kubectl get backups.backup.gdc.goog -n $NAMESPACE -l backup.gdc.goog/imported-repository=$BACKUP_REPOSITORY_NAME
   

3. Supprimez les libellés si nécessaire :

   • Supprimez les libellés de toutes les sauvegardes :

     kubectl get backups.backup.gdc.goog -l
     backup.gdc.goog/imported-repository=$BACKUP_REPOSITORY_NAME -n $NAMESPACE
     -o json | jq -r '.items[].metadata.name' | xargs -I{} kubectl label -n
     $NAMESPACE backups.backup.gdc.goog {} backup.gdc.goog/imported-repository-
     

   • Supprimez les libellés d'une seule sauvegarde :

     export BACKUP_NAME= kubectl label backups.backup.gdc.goog $BACKUP_NAME -n
     $NAMESPACE backup.gdc.goog/imported-repository-
     

Échec de la sauvegarde partielle de la VM

Versions : 1.14.3, 1.14.4

Symptômes : Si la sauvegarde d'une VM parmi plusieurs échoue, la sauvegarde de l'ensemble des VM est marquée comme ayant échoué.

Solution : Limitez le nombre de VM par plan de sauvegarde.

Nettoyer les ressources de sauvegarde orphelines après la suppression d'un cluster d'utilisateur ou de service

Versions : 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

Symptômes : lorsqu'un cluster d'utilisateur ou de service est supprimé, les ressources de l'agent de sauvegarde associé (comme StatefulSet, les pods, le secret, etc.) créées dans le cluster d'infrastructure et de gestion de l'organisation ne sont pas automatiquement nettoyées. Cela peut laisser des ressources orphelines. Si le cluster est recréé avec le même nom, le pod de l'agent de sauvegarde ne fonctionne pas.

Solution de contournement : Les ressources orphelines existent dans un espace de noms dédié du cluster d'infrastructure de l'organisation. Pour les nettoyer, vous devez supprimer cet espace de noms.

1. Définissez les fichiers kubeconfig pour l'infrastructure de l'organisation et les clusters de gestion.

   export ORG_INFRA_KUBECONFIG=<path_to_org_infra_kubeconfig>
   export MGMT_KUBECONFIG=<path_to_management_kubeconfig>
   

2. Identifiez l'espace de noms des ressources orphelines. L'espace de noms suit le modèle gpc-backup-<cluster-name>-system. Exemple :

   • gpc-backup-user-vm-1-cluster-system
   • gpc-backup-user-vm-2-cluster-system
   • gpc-backup-g-org-1-shared-service-cluster-system

3. Supprimez l'espace de noms. Cela supprimera toutes les ressources qu'il contient, y compris le StatefulSet et le pod de l'agent de sauvegarde dans le cluster d'infrastructure, ainsi que le secret dans le cluster de gestion.

   # Replace <namespace-name> with the actual namespace
   kubectl delete namespace <namespace-name> --kubeconfig "${ORG_INFRA_KUBECONFIG:?}"
   kubectl delete namespace <namespace-name> --kubeconfig "${MGMT_KUBECONFIG:?}"
   

4. Pour vérifier que le nettoyage a réussi, exécutez à nouveau la commande get all.

   # Replace <namespace-name> with the actual namespace
   kubectl get all -n <namespace-name> --kubeconfig "${ORG_INFRA_KUBECONFIG:?}"
   kubectl get all -n <namespace-name> --kubeconfig "${MGMT_KUBECONFIG:?}"
   

   La commande devrait maintenant échouer, car l'espace de noms n'existe plus. Vous devriez voir une erreur semblable à Error from server (NotFound): namespaces "<namespace-name>" not found.

La suppression de VirtualMachineRestore n'est pas compatible avec la CLI ni l'UI

Versions : 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

Problèmes constatés : le contrôleur VirtualMachineRestore ne nettoie pas automatiquement les ressources sous-jacentes (VolumeRestore, Restore) lors de la suppression d'une ressource VirtualMachineRestore. Vous devez effectuer un nettoyage manuel. Cela s'applique que vous supprimiez des données à l'aide de kubectl delete ou de l'interface utilisateur.

Solution : La solution consiste à supprimer manuellement les ressources dépendantes dans le bon ordre, puis à supprimer le finaliseur de la ressource VirtualMachineRestore.

1. Définissez le fichier kubeconfig pour qu'il pointe vers le cluster de gestion.

   export MGMT_KUBECONFIG=<path_to_management_kubeconfig>
   

2. Identifiez le VirtualMachineRestore à supprimer et son espace de noms.

   export VM_RESTORE_NAME=<vm-restore-to_be_deleted>
   export NAMESPACE=<namespace-of-vm-restore>
   

3. Recherchez et supprimez les ressources VolumeRestore associées. Elles sont créées avec un libellé qui les associe à VirtualMachineRestore.

   # Find and delete all associated VolumeRestores.
   kubectl delete volumerestores.backup.gdc.goog --all-namespaces -l "virtualmachine.gdc.goog/virtual-machine-restore-name=${VM_RESTORE_NAME:?}" --kubeconfig "${MGMT_KUBECONFIG:?}"
   

4. Recherchez et supprimez les ressources Restore associées. Elles sont créées avec un libellé qui les associe à VirtualMachineRestore.

   # Find and delete all associated Restores.
   kubectl delete restores.backup.gdc.goog -n "${NAMESPACE:?}" -l "virtualmachine.gdc.goog/virtual-machine-restore-name=${VM_RESTORE_NAME:?}" --kubeconfig "${MGMT_KUBECONFIG:?}"
   

5. Exécutez kubectl delete si ce n'est pas déjà fait, puis supprimez le finaliseur de la ressource VirtualMachineRestore. Il s'agit de la dernière étape qui permet au garbage collector Kubernetes de supprimer la ressource.

   kubectl patch virtualmachinerestores.virtualmachine.gdc.goog "${VM_RESTORE_NAME:?}" -n "${NAMESPACE:?}" --type=merge -p '{"metadata":{"finalizers":null}}' --kubeconfig "${MGMT_KUBECONFIG:?}"
   

6. Vérifiez la suppression.

   kubectl get virtualmachinerestores.virtualmachine.gdc.goog "${VM_RESTORE_NAME:?}" -n "${NAMESPACE:?}" --kubeconfig "${MGMT_KUBECONFIG:?}"
   

   La commande doit renvoyer une erreur NotFound, confirmant que la ressource a été supprimée.

Le pod du plan de contrôle de sauvegarde plante en raison d'une mémoire insuffisante

Versions : 1.14.4 et versions ultérieures

Symptômes : l'état du pod gpcbackup-controlplane-controller dans l'espace de noms système gpc-backup du cluster d'infrastructure de l'organisation est CrashLoopBackOff. Lorsque cette erreur se produit, les opérations de sauvegarde et de restauration échouent, cessent de répondre ou ne fonctionnent pas comme prévu.

Solution : Augmentez les limites de mémoire pour le déploiement gpcbackup-controlplane-controller en suivant BACK-R0005. Cette méthode applique un SubcomponentOverride pour ajuster les demandes et les limites de ressources de processeur et de mémoire.

La suppression de cluster d'utilisateur est bloquée.

Versions : 1.14.7 et ultérieures

Symptômes : les clusters sont bloqués à l'état "Suppression" en raison de problèmes liés aux finaliseurs.

Solution : Vérifiez si les volumes de stockage ont des relations SnapMirror avant de supprimer le cluster. Pour en savoir plus, consultez BACK-R0109.

La restauration est bloquée en raison d'une demande de volume persistant en attente

Versions : 1.14.3 et ultérieures

Symptômes : Les contrôleurs de revendication de volume persistant (PVC) ne parviennent parfois pas à communiquer avec les agents de sauvegarde dans le cluster d'infrastructure de l'organisation. Bien que ce problème n'ait pas d'incidence sur la fonctionnalité de sauvegarde, il peut entraîner le blocage d'une opération de restauration de volume à l'état Pending, qui finit par expirer. Ce problème affecte les opérations de restauration qui impliquent une restauration de volume, comme la fonctionnalité de restauration du service de base de données pour le clonage et la restauration d'une charge de travail utilisateur.

Si ce problème survient, les opérations de restauration ultérieures au sein du cluster concerné échoueront jusqu'à ce que vous redémarriez manuellement l'agent de sauvegarde correspondant.

Pour confirmer que votre problème de restauration est lié à ce problème spécifique, vous devez examiner les journaux de l'agent de sauvegarde :

1. Suivez IAM-R0005 pour obtenir le rôle BACK Debugger nécessaire (back-cluster-debugger) en appliquant la ressource ExpirationClusterRoleBinding.

2. Suivez IAM-R0004 pour générer le fichier kubeconfig du cluster d'infrastructure de l'organisation. Tous les agents de sauvegarde s'exécutent dans le cluster d'infrastructure de l'organisation.

3. Identifiez l'agent de sauvegarde qui facilite la restauration :

   kubectl --kubeconfig ORG_INFRA_KUBECONFIG get statefulsets \
       --all-namespaces | grep gpcbackup-agent
   

   Remplacez ORG_INFRA_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'infrastructure de l'organisation.

   Le résultat ressemble à ce qui suit :

   NAMESPACE                                          NAME                                     READY   AGE
   gpc-backup-g-org-1-shared-service-cluster-system   gpcbackup-agent-g-org-1-shared-service   1/1     22d
   gpc-backup-system                                  gpcbackup-agent                          1/1     22d
   gpc-backup-system                                  gpcbackup-agent-cp                       1/1     22d
   gpc-backup-user-vm-1-cluster-system                gpcbackup-agent-user-vm-1                1/1     22d
   gpc-backup-user-vm-2-cluster-system                gpcbackup-agent-user-vm-2                1/1     22d
   

   Lisez le résultat et identifiez l'agent de sauvegarde correspondant à votre restauration. Par exemple, si l'espace de noms StatefulSet concerné dans le résultat est gpc-backup-user-vm-1-cluster-system, l'agent de sauvegarde est gpcbackup-agent-user-vm-1.

4. Recherchez le message d'erreur dans les journaux du StatefulSet pour confirmer le problème :

   kubectl --kubeconfig=ORG_INFRA_KUBECONFIG logs statefulsets/BACKUP_AGENT \
       -n NAMESPACE | grep "Failed to watch \*v1.PersistentVolumeClaim"
   

   Remplacez les éléments suivants :

   • ORG_INFRA_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'infrastructure de l'organisation.

   • BACKUP_AGENT : agent de sauvegarde que vous avez identifié à l'étape précédente.

   • NAMESPACE : espace de noms que vous avez identifié à l'étape précédente.

   Si des journaux correspondants sont disponibles, vous êtes concerné par ce problème connu.

Solution de contournement : pour contourner le problème, procédez comme suit :

1. Redémarrez l'agent de sauvegarde :

   kubectl --kubeconfig=ORG_INFRA_KUBECONFIG rollout restart \
      statefulsets/BACKUP_AGENT -n NAMESPACE
   

   Remplacez les éléments suivants :

   • ORG_INFRA_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'infrastructure de l'organisation.

   • BACKUP_AGENT : agent de sauvegarde que vous avez identifié lors de la confirmation du problème.

   • NAMESPACE : espace de noms que vous avez identifié lors de la confirmation du problème.

   Le résultat ressemble à ce qui suit :

   statefulset.apps/gpcbackup-agent-g-org-1-shared-service restarted
   

2. Patientez jusqu'à 20 minutes pour que les opérations en attente reprennent automatiquement.

Vous pouvez effectuer une autre restauration pour le même cluster de destination une fois le redémarrage de l'agent de sauvegarde terminé. Une fois cette solution de contournement appliquée, il n'y aura aucun effet secondaire. Il n'est nécessaire de suivre cette solution de contournement qu'une seule fois par cluster concerné.

Gestion des clusters

Le sous-composant kub-gpu-controller ne se rapproche pas

Versions : 1.14.3

Problèmes constatés : Le sous-composant g-gdchservices-shared-service-cluster/kub-gpu-controller de l'organisation gdchservices ne se réconcilie pas. Le résultat suivant s'affiche :

│ Message: Reconciliation error: E0321 - runtime parameter: configRunner error
| (full log in oclcm-configrunner pod): rpc error: code = Unknown desc = failed
| to execute binary: exit status 1. Output:
│ <
│ I framework.go:159] "Reading input secret"
| inputSecretKey="g-gdchservices-shared-service-cluster/kub-gpu-controller-backend-parameter"
│ I framework.go:175] "Processing job" jobType=parameter
│ Error: no matched clusterName
│ >

Cet échec empêche le démarrage des machines GPU dans l'organisation gdchservices.

Solution : Passez à la version 1.14.4 ou ultérieure pour atténuer le problème.

Impossible de supprimer un pool de nœuds d'un cluster standard

Versions : 1.14.3, 1.14.4, 1.14.5

Corrigé : 1.14.6

Symptômes : la suppression des pools de nœuds obsolètes des clusters Standard échoue et les pools de nœuds ne sont pas supprimés dans le délai prévu. Les clusters standards sont en aperçu privé et ne sont peut-être pas disponibles pour tous les clients.

Solution : Supprimez manuellement les pools de nœuds obsolètes.

Cluster bloqué à l'état "Suppression en cours"

Versions : 1.14.6 et versions ultérieures

Problèmes constatés : lors de la suppression d'un cluster Kubernetes, il peut rester bloqué à l'état Deleting. Vérifiez l'état de votre cluster en exécutant la commande suivante :

kubectl get cluster CLUSTER_NAME -n platform \
    --kubeconfig MANAGEMENT_API_SERVER

Le résultat ressemble à ce qui suit :

NAMESPACE    NAME             STATE         K8S VERSION
platform     test-cluster     Deleting      1.28.15-gke.100

Vous pouvez également vérifier le problème en vérifiant l'état de l'espace de noms de votre cluster :

kubectl describe ns/CLUSTER_NAME-cluster \
    --kubeconfig MANAGEMENT_API_SERVER

Le résultat ressemble à ce qui suit :

Name:         test-cluster
Labels:       kubernetes.io/metadata.name=test-cluster
Status:       Terminating
Conditions:
  Type                            Status    LastTransitionTime      Reason                Message
  ----                            ------    ------------------      ------                -------
  NamespaceContentRemaining       True      DATE                    SomeResourcesRemain   Some resources are remaining: backendservices.networking.gdc.goog has 1 resource instances, forwardingruleinternals.networking.gdc.goog has 1 resource instances
  NamespaceFinalizersRemaining    True      DATE                    SomeFinalizersRemain  Some content in the namespace has finalizers remaining: backendservice.finalizers.networking.gdc.goog in 2 resource instances

L'espace de noms du cluster est bloqué à l'état Terminating, et les conditions NamespaceContentRemaining et NamespaceFinalizersRemaining sont définies sur True.

Solution de contournement : pour contourner le problème, procédez comme suit :

1. Corrigez l'API des règles de transfert :

   kubectl patch forwardingruleinternals.networking.gdc.goog -n "CLUSTER_NAME-cluster" \
       cluster-control-plane-vip-fr -p '{"metadata":{"finalizers":[]}}' --type='merge'
   

2. Corrigez l'API des services de backend :

   kubectl patch backendservices.networking.gdc.goog -n "CLUSTER_NAME-cluster" \
       cluster-control-plane-vip-bes -p '{"metadata":{"finalizers":[]}}' --type='merge'
   

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 : 1.14.6 et antérieures

Corrigé : 1.14.7

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 à partir desquelles 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.

DNS

L'alerte "GlobalCustomerRootDNSServerNotReachable" est déclenchée à tort

Versions : 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7, 1.14.8

Symptômes : l'alerte DNS-A0021 est déclenchée, ce qui suggère GlobalCustomerRootDNSServerNotReachable. La CR Probe pour global-customer-root-dns dans org-mp ne contient pas egress: true dans la spécification.

Solution :

1. Définissez le chemin d'accès KUBECONFIG pour org-mgmt :

   export MGMT_KUBECONFIG=MANAGEMENT_KUBECONFIG
   

2. Mettez en veille le sous-composant core-mz qui gère le CR de la sonde :

   kubectl --kubeconfig "${MGMT_KUBECONFIG:?}" annotate subcomponent  -n global-kube-system dns-core-mz lcm.private.gdc.goog/paused=true
   

3. Modifiez le CR de vérification actuel à partir de org-mp :

   kubectl --kubeconfig "${MGMT_KUBECONFIG:?}" edit probes -n dns-system global-customer-root-dns
   

4. Mettez à jour la spécification pour inclure egress: True et appliquez la modification. Notez que CLUSTER_NAME et GLOBAL_CUSTOMER_ROOT_IP restent inchangés.

   apiVersion: prober.private.gdc.goog/v1alpha1
   kind: Probe
   metadata:
     name: global-customer-root-dns
   spec:
     egress: True
     matchClusters:
     - CLUSTER_NAME
     probeJobs:
     - moduleName: dns_udp_global_customer_root
       name: healthy-dns-global-customer-root
       targets:
       - GLOBAL_CUSTOMER_ROOT_IP
   

Cette solution de contournement corrige le testeur. Toute fausse alerte devrait disparaître au bout de 15 minutes.

Stockage de fichiers/blocs

Impossible d'installer le volume de partage de fichiers dans la VM

Versions : 1.14.6, 1.14.7

Symptômes : la mise à jour des autorisations de stockage réseau échoue lorsqu'un nouveau nœud est ajouté à un cluster, ce qui peut entraîner le refus des demandes de montage NFS. Il est possible qu'une erreur access denied by server s'affiche lorsque vous installez un partage de fichiers NFS.

Solution : redémarrez les réconciliateurs file-share ou proxy-group, ou modifiez la ressource FileShare pour déclencher une mise à jour.

Pare-feu

Il manque une règle de stratégie de sécurité pour l'adresse dans le CR de sous-réseau.

Versions : 1.14.3

Symptômes : une organisation est inaccessible, car le groupe d'adresses du pare-feu est manquant dans la ressource personnalisée de sous-réseau global créée par le client dans le serveur d'API global de l'organisation.

Solution : Suivez les étapes du manuel de réparation FW-G0002 pour ajouter manuellement une règle de stratégie de sécurité afin d'autoriser le trafic.

Les pare-feu GDC refusent le trafic vers OIR pour le plan de gestion et le plan de données.

Versions : 1.14.3, 1.14.4

Symptômes : une fois la ressource personnalisée OCITTopology déployée, la connectivité entre OIR et le plan de gestion et le plan de données GDC est interrompue.

Solution : Suivez la procédure décrite dans le manuel d'entretien FW-G0002 pour ajouter manuellement des règles de stratégie de sécurité dans le cluster d'administrateur racine afin d'autoriser le trafic.

Les règles de stratégie de sécurité suivantes sont requises :

  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-data-egress
    namespace: root
  spec:
    action: allow
    destination:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-data
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    source:
      addresses:
      - ZONE_INFRA_CIDR
      zones:
      - vsys1-oc-data
  ---
  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-data-igress
    namespace: root
  spec:
    action: allow
    source:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-data
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    destination:
      addresses:
      - ZONE_INFRA_CIDR
      zones:
      - vsys1-oc-data
  —-
  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-mgmt-egress
    namespace: root
  spec:
    action: allow
    destination:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-mgmt
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    source:
      addresses:
      - MGMT_CIDR
      zones:
      - vsys1-oc-mgmt
  ---
  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-mgmt-ingress
    namespace: root
  spec:
    action: allow
    source:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-mgmt
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    destination:
      addresses:
      - MGMT_CIDR
      zones:
      - vsys1-oc-mgmt

Remplacez les éléments suivants :

• OCIT_CIDR : plages d'adresses IP dans le champ ocitCIDR du questionnaire d'informations client (CIQ).
• MGMT_CIDR : plages d'adresses IP dans le champ oobManagementCIDRs du questionnaire d'informations client (CIQ).
• ZONE_INFRA_CIDR : plages d'adresses IP dans le champ zoneInfraCIDRs du questionnaire d'informations client (CIQ).

Le pare-feu GDC refuse le trafic interzone et interorganisation

Versions : 1.14.3, 1.14.4, 1.14.5

Problèmes constatés : le trafic inter-zones et inter-organisations est bloqué par défaut par les pare-feu.

Solution : Suivez les étapes du runbook pour ajouter manuellement des règles de stratégie de sécurité afin d'autoriser le trafic.

Le pare-feu n'accepte pas les AttachmentGroup dont l'identifiant est identique au nom de l'organisation

Versions : 1.14.3 et ultérieures

Symptômes : après le déploiement d'un AttachmentGroup, si le champ identifier de cet objet AttachmentGroup est identique à orgName, le pare-feu ne parvient pas à analyser cet objet et les mises à jour de la configuration du pare-feu sont bloquées. Voici un exemple de AttachmentGroup problématique :

  apiVersion: system.private.gdc.goog/v1alpha1
  kind: AttachmentGroup
  metadata:
    name: attachment-group-org-1234
    namespace: gpc-system
  spec:
    identifier: myorg
    entities:
      - orgName: myorg
        domainType: OrgMixed

Solution : Évitez d'utiliser le nom de l'organisation comme identifiant. Plusieurs options s'offrent à vous pour corriger le AttachmentGroup incorrect.

Choisissez l'une des options suivantes pour corriger le AttachmentGroup problématique.

• Ajoutez une chaîne à la fin de l'identifiant d'origine avec un tiret :

  apiVersion: system.private.gdc.goog/v1alpha1
  kind: AttachmentGroup
  metadata:
    name: attachment-group-org-1234
    namespace: gpc-system
  spec:
    identifier: myorg-orgdx
    entities:
      - orgName: myorg
        domainType: OrgMixed
  

• Ajoutez une chaîne au début de l'identifiant d'origine avec un tiret :

  apiVersion: system.private.gdc.goog/v1alpha1
  kind: AttachmentGroup
  metadata:
    name: attachment-group-org-1234
    namespace: gpc-system
  spec:
    identifier: orgdx-myorg
    entities:
      - orgName: myorg
        domainType: OrgMixed
  

• Remplacez l'identifiant d'origine par une autre chaîne :

  apiVersion: system.private.gdc.goog/v1alpha1
  kind: AttachmentGroup
  metadata:
    name: attachment-group-org-1234
    namespace: gpc-system
  spec:
    identifier: dxidentifier
    entities:
      - orgName: myorg
        domainType: OrgMixed
  

Port

Le secret de la CLI Harbor devient non valide après une sauvegarde et une restauration

Versions : 1.14.3

Symptômes : après une sauvegarde et une restauration de Harbor, les secrets de CLI deviennent non valides et doivent être recréés.

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

1. Connectez-vous à Harbor avec un compte utilisateur IAP.
2. Cliquez sur votre nom d'utilisateur, puis sélectionnez Profil utilisateur.
3. Cliquez sur  Plus.
4. Créez un autre secret CLI automatiquement ou manuellement.

Pour en savoir plus sur Harbor dans GDC, consultez la présentation de Harbor.

Le job de sauvegarde et de restauration Harbor est en concurrence pour l'autorisation

Versions : 1.14.3, 1.14.4

Problèmes constatés : lorsque plusieurs instances Harbor existent dans différents projets utilisateur, les opérations de sauvegarde et de restauration sont en concurrence pour les contrôles d'accès basés sur les rôles et présentent un taux d'échec élevé.

Solution : Pour atténuer ce problème, suivez ces étapes afin de créer manuellement une liaison de rôle pour chaque espace de noms dans lequel des instances Harbor sont créées :

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

   INSTANCE_NAMESPACE=INSTANCE_NAMESPACE
   INFRA_CLUSTER_KUBECONFIG=INFRA_CLUSTER_KUBECONFIG
   

   Remplacez les éléments suivants :

   • INFRA_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'infrastructure.
   • INSTANCE_NAMESPACE : espace de noms dans lequel les instances Harbor de Managed Harbor Service (MHS) sont créées.

2. Créez la liaison de rôle pour la solution de contournement :

   kubectl --kubeconfig ${INFRA_CLUSTER_KUBECONFIG:?} create \
   rolebinding ${INSTANCE_NAMESPACE:?}-mhs-backup-manual-rolebinding \
   --role=haas-backup-secret-access-role --serviceaccount=${INSTANCE_NAMESPACE:?}-haas-system:haas-backup-sa \
   --namespace=haas-system
   

La taille de la sauvegarde Harbor affiche des valeurs nulles

Versions : 1.14.3, 1.14.4

Symptômes : La mesure de la taille des sauvegardes Harbor n'est pas implémentée pour le moment. Dans la console GDC, les champs SizeBytes affichent la valeur 0 et la colonne Size affiche la valeur 0 Mo. Ce comportement est normal pour le moment.

Erreur d'autorisation sur les ressources de sauvegarde sur la page de la console Harbor Registry

Versions : 1.14.3, 1.14.4

Symptômes : si vous ne disposez pas du rôle d'administrateur d'instance Harbor, une erreur d'autorisation s'affiche sur la ressource de sauvegarde lorsque vous consultez la page Harbor Container Registry dans la console GDC. Cette erreur s'affiche, car les informations de sauvegarde ont été ajoutées récemment à la page Harbor Container Registry, mais l'autorisation de lecture de la ressource de sauvegarde n'a pas été accordée aux rôles IAM autres que l'administrateur de l'instance Harbor.

Les autres éléments de la console GDC sur la page Harbor Container Registry fonctionnent toujours comme prévu. Pour en savoir plus sur les rôles dans GDC, consultez Définitions des rôles.

Page "La rotation du mot de passe de la base de données est bloquée"

Versions : 1.14.3, 1.14.4, 1.14.5, 1.14.6

Symptômes : des erreurs sont générées concernant l'authentification pour les requêtes adressées à la base de données, telles que failed SASL auth (FATAL: password authentication failed for user "dbsadmin" (SQLSTATE 28P01)), et de nombreuses requêtes de rotation générées automatiquement sont présentes pour un même secret rotatif.

Solution : Supprimez les demandes de rotation supplémentaires non prêtes pour un secret rotatif.

1. Définissez KUBECONFIG sur le serveur d'API mp.

2. Exportez l'espace de noms :

   NAMESPACE=haas-system
   

3. Vérifiez si des secrets rotatifs dans haas-system ne sont pas prêts :

   kubectl get rotatablesecrets -n ${NAMESPACE?}
   

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

   NAME                        CREDENTIALID   READY     AGE
   haasdb-pw-ar-test           HAAS-0002      True      109d
   haasdb-pw-gardener-harbor   HAAS-0002      True      178d
   haasdb-pw-haas-alice        HAAS-0002      Unknown   166d
   haasdb-pw-myinstance        HAAS-0002      True      80d
   haasdb-pw-osd               HAAS-0002      True      158d
   haasdb-pw-saptest           HAAS-0002      True      91d
   

4. Exportez le nom du secret rotatif, par exemple :

   ROTATABLE_SECRET=haasdb-pw-haas-alice
   

5. Supprimez les demandes de rotation supplémentaires qui ne sont pas prêtes :

   CUR_ROTATABLE_SECRET=$(kubectl get rotatablesecret ${ROTATABLE_SECRET?} -n ${NAMESPACE?} -ojsonpath='{.status.currentRotationRequestRef.name}')
   
   kubectl get rotationrequests -n ${NAMESPACE?} -o json | jq -r --arg rotatableSecret "${ROTATABLE_SECRET?}" --arg curRotatableSecret "${CUR_ROTATABLE_SECRET?}" '.items[] | select(.metadata.ownerReferences[0]? | .name==$rotatableSecret) | select(.status.conditions[0]? | .type=="Ready" and .status=="False") | select(.metadata.name != $curRotatableSecret) | .metadata.name' | xargs -r kubectl delete rotationrequests -n ${NAMESPACE?}
   

Module de sécurité matérielle

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

Versions : 1.14.3, 1.14.4, 1.14.5

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

Les HSM échouent avec l'erreur ValidateNetworkConfig après le démarrage

Versions : 1.14.x

Symptômes : les ressources personnalisées HSM n'atteignent pas l'état Ready et échouent en raison d'une erreur ValidateNetworkConfig. Le message d'erreur suivant s'affiche : data0 interface MAC address {} is not active. Cette erreur se produit si le système est redémarré et qu'une autre interface de données principale est définie.

Solution : Suivez le runbook HSM-R0059 et réappliquez la configuration réseau du HSM pour le réseau de données. Vous pouvez suivre ce runbook même si plusieurs HSM présentent cette erreur.

SANTÉ

Alertes SLO fausses

Versions : 1.14.3

Symptômes : un SLO successRange se déclenche de manière erronée.

Solution de contournement : Demandez à l'opérateur d'infrastructure (IO) de vérifier si l'alerte correspond à un problème réel ou à une fausse alerte.

Pour ce faire, lorsqu'une alerte est déclenchée, suivez le runbook correspondant pour résoudre la cause sous-jacente de l'alerte d'objectif de niveau de service (SLO).

1. Cas 1 : Si le runbook résout le problème et que l'alerte cesse de se déclencher, l'IO peut clôturer l'incident associé.

2. Cas 2 : Si le runbook est terminé, mais que l'alerte continue de se déclencher, cela indique un faux positif potentiel. Vérifiez si le SLO est enfreint :

   kubectl get servicelevelobjective {SLO_NAME} -n {SLO_NAMESPACE} -o yaml --kubeconfig root-admin-kubeconfig| awk '/successRange/ { found1 = 1 } /labelFilter/ { found2 = 1 } END { if (found1 && found2) print "Broken 1.14.3 SLO detected"; else print "SLO does not have a known 1.14.3 issue" }'
   

3. En fonction du résultat : s'il confirme que l'alerte est une fausse alerte, l'IO doit alors désactiver l'alerte dans l'instance GDC isolée. Dans le cas contraire, transmettez le problème à l'assistance Cloud.

4. Dans les deux cas, il convient que l'IO escalade le problème à l'assistance Cloud pour vérifier que le composant opérationnel est en bon état.

Configurations de SLO basées sur des jauges non valides

Versions : 1.14.3, 1.14.4

Symptômes : en raison d'une mauvaise configuration, un sous-ensemble d'objectifs de niveau de service (SLO) ne génère pas d'événements bons, mauvais ou totaux. Les SLO en question sont basés sur des jauges Prometheus et doivent être configurés en conséquence.

Solution :

Version 1.14.3 : aucune solution n'est disponible. Par conséquent, les alertes SLO ne se déclencheront pas pour les SLO concernés.

Version 1.14.4 : une solution de contournement est disponible pour corriger le SLO. Pour résoudre ce problème, le paramètre isGauge: true doit être appliqué à la spécification du SLO.

Exemple de configuration d'un graphique pour un SLO :

```yaml
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: ServiceLevelObjective
metadata:
  namespace: infra-obs
  name: fw-packet-discard-errors-slo
spec:
  successRange:
  - resource: fw
    description: Firewall packet discard rate with errors SLO
    runbookURL: FW-R0006
    goal: "0.995"
    isGauge: true
    period: 30d
    metricName: fw_packet_discard_errors_ps
    max: 2
```

Voici la liste des SLO connus qui sont corrigés avec ce paramètre :

• SLO de pare-feu :
  • fw-packet-discard-errors-slo
  • fw-packet-discard-no-error-slo
  • fw-packet-discard-unknown-protocol-slo
  • fw-uptime-slo
• SLO de fichier :
  • file-ontap-appliance-availability-slo
  • file-ipsec-networking-availability-slo
  • file-ontap-networking-availability-slo
  • file-iscsi-client-availability-slo
  • file-multipath-client-availability-slo
  • file-trident-client-availability-slo

Gestion de l'authentification et des accès

Échec de la création de la liaison de rôle IAM

Versions : 1.14.3

Symptômes : les noms des liaisons de rôle IAM sont générés par le système. Ces noms ne doivent pas comporter plus de 63 caractères et doivent respecter le format user-idp-prefix-rolename. Dans les cas où le nom généré dépasse la limite de 63 caractères, les liaisons de rôle ne peuvent pas être créées. Par conséquent, les autorisations définies à l'aide de rôles prédéfinis ou personnalisés ne seront pas attribuées aux utilisateurs.

Solution de contournement : La création de liaison de rôle peut réussir si le nom du rôle prédéfini ou personnalisé est très court (par exemple, 4 à 5 caractères).

Échec de la création de la liaison de rôle IAM pour les comptes de service du projet

Versions : 1.14.3, 1.14.4, 1.14.5, 1.14.6

Symptômes : Un compte de service de projet (PSA) avec le rôle organization-iam-admin ne peut pas utiliser la commande gdcloud projects add-iam-policy-binding pour s'attribuer un autre rôle, tel que le rôle project-iam-admin. Cette lacune empêche une PSA de gérer ses propres autorisations.

Solution : Vérifiez que vous disposez du rôle organization-iam-admin. Attribuez-vous ensuite le rôle project-iam-admin dans l'espace de noms du projet du PSA cible, et attribuez le rôle project-iam-admin au PSA. Cette configuration des autorisations permet au PSA de s'attribuer des autorisations supplémentaires ou d'en attribuer à d'autres PSA.

Retards dans la création de rôles prédéfinis pour les nouveaux projets

Versions : 1.14.3

Symptômes : lorsqu'un projet est créé, il manque des rôles par défaut, tels que project-bucket-object-admin.

Solution : Patientez entre 15 et 60 minutes, ou redémarrez manuellement le contrôleur iam-org-admin-cm-backend-controller dans l'espace de noms iam-system sur le cluster d'infrastructure de l'organisation.

La console GDC ne peut pas créer la première liaison de rôle

Versions : 1.14.4

Symptômes : lorsque vous créez la première liaison de rôle pour une nouvelle identité de service à l'aide de la console GDC, la création de la liaison de rôle est signalée comme réussie, mais elle ne fonctionne pas réellement. Toute autre action sur l'identité du service échoue et n'a aucun effet, y compris l'ajout ou la suppression de liaisons de rôle.

Solution de contournement : Utilisez la gdcloud CLI pour créer la première liaison de rôle pour une identité de service. Toutes les actions futures effectuées avec l'identité de service à l'aide de la console GDC fonctionnent correctement une fois la première liaison de rôle associée. Pour en savoir plus, consultez Attribuer une liaison de rôle à l'identité de service.

Les AO ne peuvent pas s'accorder l'accès aux rôles dans le cluster d'infrastructure.

Versions : 1.14.3. 1.14.4

Corrigé : correctif 21 de la version 1.14.3

Symptômes : les AO ne peuvent pas s'accorder à eux-mêmes ni à d'autres utilisateurs l'accès à des rôles dans le cluster d'infrastructure.

Solution : Les utilisateurs AO doivent contacter les IO pour obtenir l'accès requis. Les IO peuvent utiliser IAC pour fournir aux utilisateurs AO l'accès requis.

Le jeton de compte de service existant devient non valide

Versions : 1.14.3

Corrigé : correctif 21 de la version 1.14.3

Symptômes : le jeton de compte de service existant émis par le cluster utilisateur devient invalide, car l'argument service-account-issuer apiserver est modifié une fois que le cluster est en cours d'exécution après l'amorçage. Ce problème empêche le pod, par exemple le pod avec un conteneur side-car istio-proxy, sur le cluster utilisateur d'authentifier à l'aide du jeton de compte de service. Il faut ensuite des heures pour que le jeton de compte de service soit actualisé avec les nouvelles configurations.

Solution : Redémarrez manuellement le pod sur le cluster d'utilisateur pour que le jeton du compte de service soit renouvelé avec les nouvelles configurations.

Infrastructure as Code (IAC)

Échec de la réconciliation du sous-composant en raison d'un espace de noms manquant

Versions : 1.14.3

Problèmes constatés : un sous-composant ne parvient pas à se réconcilier. Cela se produit parce que l'espace de noms config-management-monitoring requis n'est pas créé automatiquement dans le cluster gdchservices-mp.

Solution : Créez l'espace de noms config-management-monitoring dans le cluster gdchservices-mp à l'aide du fichier manifeste suivant :

apiVersion: v1
kind: Namespace
metadata:
  labels:
    configmanagement.gke.io/system: "true"
  name: config-management-monitoring
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep

Échec de la collecte des métriques IAC ConfigSync

Versions : 1.14.3, 1.14.4

Symptômes : un problème dans le sous-système de surveillance ConfigSync d'IAC empêche le déploiement otel-collector de démarrer. Les métriques ConfigSync ne sont pas collectées pour la surveillance et les alertes.

Solution : procédez comme suit dans le cluster root-admin :

1. Mettez en pause le sous-composant iac-configsync-mon.
2. Modifiez l'objet MetricsProxySidecar/iac-configsync-metrics dans l'espace de noms config-management-monitoring.

3. Dans le fichier YAML MetricsProxySidecar/iac-configsync-metrics, recherchez les éléments suivants :

   spec:
     [...]
     destinations:
     - certificate:
         secretName: iac-configsync-mon-target-cert
   

   Remplacez cette section par ce qui suit :

   spec:
     [...]
     destinations:
     - certificate:
         secretName: iac-configsync-mon-mon-target-cert
   

4. Redémarrez le déploiement otel-collector dans l'espace de noms config-management-monitoring.

Échec de IAC RootSync

Versions : 1.14.3

Symptômes : un problème se produit lors de la synchronisation des ressources Config Sync de GitLab vers les clusters en raison d'un secret iac-creds manquant . Les iac-creds ne sont pas permutés en raison d'un problème iacmanager.

Solution : procédez comme suit dans le cluster :

1. Suivez le runbook IAC-R0015 pour résoudre le problème de secret iac-creds manquant. Il effectue la rotation des identifiants du gestionnaire IaC et de Config Sync.

Inventaire

Échec de la réconciliation de l'audit d'inventaire

Versions : 1.14.3

Problèmes constatés : le sous-composant inv-audit ne parvient pas à effectuer la réconciliation, car HarborRobotAccount n'est disponible que dans le plan de gestion.

Solution : Créez un silence dans AlertManager pour couper le son de l'alerte component_reconciliation_errors pour component: inv.

Système de gestion des clés

KMS configuré pour utiliser une clé racine CTM ne bascule pas en cas d'indisponibilité d'un HSM

Versions : 1.14.x

Symptômes : Certaines requêtes adressées au KMS échouent lorsqu'un HSM n'est pas disponible et que d'autres HSM disponibles auraient pu être utilisés. Ce problème ne s'applique que lorsque le KMS est configuré pour utiliser une clé racine CTM.

Solution : Supprimez le HSM indisponible du HSMCluster en suivant le runbook HSM-P0006. Redémarrez ensuite le déploiement kms-backend :

kubectl --kubeconfig=ORG_INFRA_KUBECONFIG rollout restart deployment/kms-backend -n kms-system

Cette commande redémarre les pods kms-backend et rétablit la connexion aux HSM du HSMCluster.

Équilibreurs de charge

Échec de la création de l'équilibreur de charge global en raison de l'épuisement du CIDR du sous-réseau

Versions : 1.14.3

Symptômes : la création d'un équilibreur de charge externe ou interne global échoue en raison d'un nombre insuffisant d'adresses IP dans les sous-réseaux mondiaux. Le système ne peut pas allouer dynamiquement d'adresses IP pour les équilibreurs de charge globaux en raison d'un contrôleur qui utilise un chemin de code incorrect. L'équilibreur de charge ne fait référence qu'à un seul sous-réseau. Si ce sous-réseau ne dispose plus d'adresses IP disponibles, il n'est pas possible de passer à un autre sous-réseau. Cette limitation entraîne l'affichage de l'erreur.

Solution de contournement : Vous devez créer votre propre sous-réseau et des adresses IP statiques pour vos ressources ForwardingRule. Pour en savoir plus sur la création de sous-réseaux, consultez Configurer des sous-réseaux pour la mise en réseau des charges de travail. Lorsque vous créez une ressource ForwardingRule, vous pouvez spécifier le sous-réseau dans le champ cidrRef.

Versions : 1.14.3

Problème constaté : les objets d'équilibreur de charge n'atteignent pas l'état Ready.

Solution : Vous devez créer des ressources Backend dont le champ spec a une valeur. Les ressources Backend identifient les points de terminaison de l'équilibreur de charge. Si vous ne fournissez pas de valeur pour le champ spec, des erreurs peuvent se produire.

La modification des ressources de l'équilibreur de charge n'entraîne pas la réconciliation des services

Versions : 1.14.3

Symptômes : la modification des ressources personnalisées de l'équilibreur de charge n'entraîne pas la réconciliation des services d'équilibrage de charge.

Solution de contournement : pour atténuer ce problème, supprimez et recréez l'équilibreur de charge en supprimant les ressources BackendService et ForwardingRule de cet équilibreur de charge.

Les noms de zones incorrects ne sont pas refusés

Versions : 1.14.3

Symptômes : la ressource BackendService globale n'accepte pas les noms de zones incorrects. Si le nom de la zone est incorrect, l'équilibreur de charge échoue au lieu de valider et de refuser la configuration.

Solution de contournement : Vous devez fournir les noms corrects des zones utilisées. Si l'équilibreur de charge est mal configuré, vous devez supprimer et recréer les ressources personnalisées de l'équilibreur de charge.

Erreur de webhook d'équilibreur de charge global et zonal

Versions : 1.14.3

Symptômes : l'erreur suivante est renvoyée :

Error from server (InternalError): error when creating "STDIN": Internal error
occurred: failed calling webhook
"projectnetworkpolicies.networking.global.gdc.goog": failed to call webhook:
Post
"https://unet-global-org-cm-webhooks.unet-system.svc/validate-networking-global-gdc-goog-v1-projectnetworkpolicy?timeout=10s":
context deadline exceeded

Solution : Pour résoudre ce problème, redémarrez et supprimez le pod unet-global-cm :

root@bootstrapper-zone1:~# k8s.org get pods -n unet-system
unet-global-org-cm-backend-controller-7df58cd9db-8szkh   1/1     Running   42 (7h22m ago)   9d

root@bootstrapper-zone1:~# k8s.org delete pods -n unet-system
unet-global-org-cm-backend-controller-7df58cd9db-8szkh

Journalisation

Le pod Loki plante ou est OOMKilled lors de la relecture du WAL

Versions : 1.14.3, 1.14.4, 1.14.5

Symptômes :

Les pods audit-logs-loki-io de l'espace de noms obs-system passent à l'état CrashLoopBackOff. Cela est dû à des échecs prématurés de la vérification de l'activité ou à un arrêt pour mémoire saturée (OOM, Out Of Memory) lors de la relecture du journal WAL (Write-Ahead Log), en raison d'une valeur wal_replay_ceiling qui dépasse la limite de mémoire du pod.

Solution :

Procédez comme suit pour ajuster la configuration de Loki afin de permettre une relecture WAL réussie. Les modifications doivent être appliquées au cluster concerné (par exemple, root-admin ou org-infra).

1. Définissez KUBECONFIG=/path/to/affected-cluster.kubeconfig comme variable d'environnement.

2. Mettez en veille le LoggingPipelineReconciler pour empêcher le contrôleur d'annuler les modifications manuelles. Appliquez ce fichier manifeste :

   apiVersion: lcm.private.gdc.goog/v1
   kind: SubcomponentOverride
   metadata:
     name: log-logging-pipeline-pause
     namespace: root
   spec:
     subComponentRef: "log-admin"
     backend:
       operableParameters:
         controller:
           disableReconcilers: "LoggingPipelineReconciler"
   

   Vérifiez que le remplacement est actif. Le résultat doit inclure "disable-reconcilers=LoggingPipelineReconciler".

   kubectl get deploy -n obs-system log-admin-backend-controller -o jsonpath='{.spec.template.spec.containers[0].args}' --kubeconfig=${KUBECONFIG} | jq
   

3. Définissez replay_memory_ceiling sur 8GB dans le fichier ConfigMap audit-logs-loki-io-cm.

   kubectl edit cm audit-logs-loki-io-cm -n obs-system --kubeconfig=${KUBECONFIG}
   

   Modifiez la section wal :

   [...]
     wal:
       replay_memory_ceiling: 8GB ## <-- Change to 8GB
   [...]
   

4. Facultatif : Mettez à l'échelle le proxy d'objet. Si les pods obj-proxy sont proches de leurs limites de ressources, faites évoluer le déploiement pour gérer la charge accrue pendant la récupération.

   a. Vérifiez l'utilisation des ressources :

   kubectl top po -n gpc-system -l name=obj-proxy-manager --kubeconfig=${KUBECONFIG}
   

   b. Si l'utilisation est élevée, faites évoluer le déploiement :

   kubectl scale deployment obj-proxy -n gpc-system --replicas=7 --kubeconfig=${KUBECONFIG}
   

   c. Si nécessaire, vous pouvez également augmenter la limite de mémoire du pod (par exemple, de 12000Mi à 16000Mi).

5. Augmentez la taille de la PVC pour le pod concerné (par exemple, loki-storage-audit-logs-loki-io-0 de 70Gi à 75Gi) pour éviter la pression sur le disque. Suivez la procédure interne SUPP-R001 pour redimensionner le PVC. Le redémarrage à l'étape suivante applique la nouvelle taille.

6. Ajoutez un startupProbe au StatefulSet audit-logs-loki-io pour laisser le temps à la relecture WAL avant le début des vérifications d'activité. L'enregistrement de la modification déclenche un redémarrage progressif des pods (5 à 10 minutes).

   kubectl edit sts audit-logs-loki-io -n obs-system --kubeconfig=${KUBECONFIG}
   

   Ajoutez ce startupProbe à la spécification du conteneur audit-logs-loki-io :

   startupProbe:
     failureThreshold: 1000
     httpGet:
       path: /ready
       port: loki
       scheme: HTTP
     periodSeconds: 10
     successThreshold: 1
     timeoutSeconds: 10
   

Vérifier la solution de contournement

1. Vérifiez l'état du pod et du StatefulSet : assurez-vous que tous les pods audit-logs-loki-io sont Running et que le StatefulSet indique que tous les réplicas sont prêts.

   kubectl get po -n obs-system -l app=audit-logs-loki-io --kubeconfig=${KUBECONFIG}
   kubectl get sts -n obs-system audit-logs-loki-io --kubeconfig=${KUBECONFIG}
   

2. Vérifiez que la PVC a été redimensionnée. Le résultat attendu est 75Gi.

   kubectl get pvc -n obs-system loki-storage-audit-logs-loki-io-0 -o jsonpath='{.status.capacity.storage}' --kubeconfig=${KUBECONFIG} ; echo
   

3. Vérifiez que la récupération du fichier WAL a réussi en recherchant les messages errors=false dans les journaux des pods.

   kubectl logs -n obs-system audit-logs-loki-io-0 --kubeconfig=${KUBECONFIG} | grep -i "wal"
   

4. Vérifiez que l'utilisation du répertoire /wal à l'intérieur du pod est faible.

   kubectl exec -n obs-system audit-logs-loki-io-0 -c audit-logs-loki-io --kubeconfig=${KUBECONFIG} -- df -Ph /wal
   

5. Vérifiez l'état de la bague Loki :

   a. Transférez le port du service Loki :

   DATA_IP=$(ip -br -4 a s dev bond0| awk '{print $3}' | cut -d / -f 1)
   kubectl port-forward -n obs-system svc/audit-logs-loki-io --address $DATA_IP 43100:3100 --kubeconfig=${KUBECONFIG}
   

   b. Vérifiez que toutes les instances sont opérationnelles sur http://<DATA_IP>:43100/ring.

Nettoyer le remplacement et le proxy d'objet

Une fois la validation réussie, effectuez les étapes de nettoyage suivantes.

1. Supprimez le remplacement du sous-composant :

   kubectl delete subcomponentoverride log-logging-pipeline-pause -n root --kubeconfig=${KUBECONFIG}
   

2. Si vous avez augmenté la taille du déploiement obj-proxy, ramenez-la à sa taille d'origine.

Surveillance

Les Webhooks AlertManager n'envoient pas d'alertes pour certains clusters

Version : 1.14.3

Symptômes : Les Webhooks AlertManager ne parviennent pas à envoyer de requêtes ni de notifications d'alerte à ServiceNow depuis un cluster autre que le cluster d'administrateur racine ou le cluster dans lequel réside l'instance ServiceNow. Par conséquent, aucune alerte n'est créée dans ServiceNow pour l'organisation.

Vous pouvez identifier l'échec de l'envoi d'alertes par le webhook si vous recevez des messages de journal d'erreur à plusieurs reprises. Pour rechercher les erreurs répétées, procédez comme suit :

1. Exportez les variables d'environnement :

   export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG
   

   Remplacez MGMT_API_KUBECONFIG par le chemin d'accès au fichier kubeconfig du serveur de l'API Management.

2. Recherchez le pod :

   kubectl --kubeconfig ${MGMT_API_KUBECONFIG} get pods \
     -n mon-system -o name | grep mon-alertmanager-servicenow-webhook-backend-
   

3. Récupérez les journaux :

   kubectl --kubeconfig ${MGMT_API_KUBECONFIG} logs POD_NAME -n mon-system
   

   Remplacez POD_NAME par le nom du pod.

4. Recherchez les erreurs répétées qui ressemblent à ce qui suit :

   Errorsendingtherequest ... read: connection reset by peer
   

Remarque : Les erreurs impliquant CHANGE_ME indiquent que ce webhook n'a pas été configuré. Ce problème ne concerne que les clusters qui ne disposent pas d'instance ServiceNow.

Solution de contournement : la solution de contournement recommandée pour ce problème consiste à suspendre deux sous-composants, l'un pour les alertes de métasurveillance et l'autre pour les alertes régulières. Remplacez ensuite le libellé egress.networking.gke.io/enabled: "true" par networking.private.gdc.goog/infra-access: enabled dans le déploiement mon-alertmanager-servicenow-webhook-backend du cluster concerné. Ce libellé permet au pod de communiquer avec d'autres clusters d'infrastructure sans passer par une passerelle de sortie.

Pour appliquer la solution de contournement recommandée, procédez comme suit :

1. Exportez les variables d'environnement :

   export ROOT_KUBECONFIG=ROOT_KUBECONFIG
   export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG
   export ORG=ORG
   

   Remplacez les éléments suivants :

   • ROOT_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur racine.
   • MGMT_API_KUBECONFIG : chemin d'accès au fichier kubeconfig du serveur de l'API Management.
   • ORG : espace de noms de l'organisation.

2. Mettre en veille des sous-composants :

   • Mettez en veille le sous-composant mon-alertmanager-servicenow-webhook :

   kubectl --kubeconfig ${ROOT_KUBECONFIG} annotate subcomponent "mon-alertmanager-servicenow-webhook" \
     -n "${ORG}" lcm.private.gdc.goog/paused=true
   

   • Mettez en veille le sous-composant mon-meta-monitoring :

   kubectl --kubeconfig ${ROOT_KUBECONFIG} annotate subcomponent "mon-meta-monitoring" \
     -n "${ORG}" lcm.private.gdc.goog/paused=true
   

3. Mettez à jour le déploiement mon-alertmanager-servicenow-webhook-backend qui couvre la plupart des alertes :

   kubectl --kubeconfig ${MGMT_API_KUBECONFIG} edit deployment \
     -n mon-system mon-alertmanager-servicenow-webhook-backend
   

4. Remplacez le libellé dans spec.template.metadata.labels en remplaçant egress.networking.gke.io/enabled: "true" par networking.private.gdc.goog/infra-access: "enabled".

5. Mettez à jour le déploiement meta-alertmanager-servicenow-webhook qui couvre les alertes liées à la pile de surveillance :

   kubectl --kubeconfig ${MGMT_API_KUBECONFIG} edit deployment \
     -n mon-system meta-alertmanager-servicenow-webhook
   

6. Remplacez le libellé dans spec.template.metadata.labels en remplaçant egress.networking.gke.io/enabled: "true" par networking.private.gdc.goog/infra-access: "enabled".

Vous pouvez également utiliser Grafana pour afficher les mêmes alertes.

Les incidents ServiceNow sont parfois dupliqués

Version : 1.14.3

Symptômes : il est possible que des incidents ServiceNow en double s'affichent pour le même pod.

Solution de contournement : vous pouvez identifier les demandes en double en comparant les empreintes digitales dans la description de l'incident.

Les métriques d'infrastructure peuvent être trop sensibles

Version : 1.14.3

Symptômes : des alarmes peuvent s'afficher pour l'alerte oclcm-reconciler-success-rate.

Solution : Vous pouvez couper le son de l'alerte en toute sécurité. Il s'agit d'une alerte trop bruyante. Nous nous efforçons d'améliorer le signal.

Les métriques de réconciliation peuvent être trop sensibles

Version : 1.14.3, 1.14.4, 1.14.5

Symptômes : des alarmes peuvent s'afficher pour l'alerte component_reconciliation_errors.

Solution : Vous pouvez couper le son de l'alerte en toute sécurité en suivant le runbook MON-R2009. Cette alerte est trop bruyante.

Deux fausses alertes sont ouvertes dans le cluster d'administrateur racine.

Version : 1.14.3

Problèmes constatés : les alertes MON-A0001_slow et MON-A0001_fast sont en état de déclenchement dans le cluster d'administrateur racine.

L'incident sur ServiceNow ressemble à l'exemple suivant :

number        priority        sys_created_on        u_organization_id   short_description   active
INC004043     1 - Critical    2025-04-30 08:29:00   root                MON-A0001_slow      true
INC0040427    1 - Critical    2025-04-30 08:28:55   root                MON-A0001_fast      true

L'incident est décrit comme suit :

Description:
Message: "Blackbox monitoring metrics pipeline down"
Runbook URL: MON-R0001
Generator URL: cortex.mon-system.svc:9009/graph?g0.expr=%28mon_metrics_pipeline_error_rate1h%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%2814.4+%2A+0.05%29+and+mon_metrics_pipeline_error_rate5m%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%2814.4+%2A+0.05%29%29+or+%28mon_metrics_pipeline_error_rate6h%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%286+%2A+0.05%29+and+mon_metrics_pipeline_error_rate30m%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%286+%2A+0.05%29%29&g0.tab=1
AlertCode: MON-A0001
Severity: critical
Cluster: org-1-admin
Namespace: <no value>
Pod Name: <no value>
fingerprint: 3b386f1373178e97

Remarque : Le champ u_organization_id affiche la valeur root, mais le cluster dans la description est ORG_NAME-admin. Vous trouverez l'alerte dans l'instance Grafana du cluster d'administrateur racine.

Solution de contournement : suivez ces étapes pour résoudre le problème uniquement dans le cluster d'administrateur racine :

1. Supprimez le libellé monitoring.gdc.goog/metamonitoring-project=mon-system dans mon-a0001-blackbox-monitoring-obs-system MonitoringRule.

2. Supprimez toutes les règles d'enregistrement portant le nom mon_metrics_pipeline_absent et la valeur du libellé de cluster ORG_NAME-admin de mon-a0001-blackbox-monitoring-obs-system MonitoringRule.

   L'exemple suivant montre une règle d'enregistrement mon_metrics_pipeline_absent à supprimer :

   Expr:               absent(probe_success{job="mon-system/meta-monitoring-meta-prometheus/meta_prometheus_probe_metric",cluster="gdchservices-admin"}) OR on() vector(0)
       Labels:
         _source_project:  blackbox-monitoring-obs-system
         Cluster:          gdchservices-admin
         Job:              mon-system/meta-monitoring-meta-prometheus/meta_prometheus_probe_metric
       Record:             mon_metrics_pipeline_absent
   

Les alertes MON_A0001_slow et MON_A0001_fast reviennent à l'état Normal au bout de quelques minutes (environ 40 minutes).

Le gestionnaire du contrôleur d'administrateur racine affiche un taux d'erreur élevé

Version : 1.14.3

Symptômes : Des alarmes peuvent s'afficher pour l'alerte ControllerReconciliationErrorRateHigh. Le gestionnaire de contrôleurs affichera des journaux indiquant : ApplianceStorage.ceph.storage.private.gdc.goog \"appliance-storage\" not found

Solution : Vous pouvez désactiver le contrôleur à l'origine de l'erreur sans risque.

1. Exportez les variables d'environnement :

   export ROOT_KUBECONFIG=ROOT_KUBECONFIG
   

2. Modifiez le déploiement du gestionnaire de contrôleurs d'administrateur racine :

   kubectl --kubeconfig ${ROOT_KUBECONFIG} edit deployment \
     -n gpc-system root-admin-controller
   

   Dans le conteneur manager, s'il n'existe pas encore d'argument --disable-reconcilers, ajoutez-en un avec la valeur --disable-reconcilers=ApplianceStorageTunnelReconciler. Si c'est le cas, ajoutez le réconciliateur ApplianceStorageTunnelReconciler avec une virgule. Par exemple, --disable-reconcilers=ManagementSwitch,ManagementAggSwitch,TORSwitch,AggSwitch,ApplianceTORSwitch,ApplianceStorageTunnelReconciler :

Les journaux d'erreurs devraient être effacés.

Les tableaux de bord KUB n'affichent aucune donnée dans tous les panneaux PA

Versions : 1.14.3

Symptômes : les tableaux de bord KUB n'affichent aucune donnée dans tous les panneaux de Grafana pour les administrateurs de plate-forme.

Solution : Mettez en veille le sous-composant KSM et mettez à jour monitoringtarget et metricsproxysidecar :

1. Mettez le sous-composant en veille :

   export SUBCOMPONENT_NAME=mon-kube-state-metrics
   export SUBCOMPONENT_NAMESPACE=ORG_NAME
   kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG annotate subcomponent "${SUBCOMPONENT_NAME:?}" -n "${SUBCOMPONENT_NAMESPACE:?}" lcm.private.gdc.goog/paused=true
   

   Remplacez les éléments suivants :

   • ORG_NAME : nom de l'organisation
   • ROOT_ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig root-admin

2. Ajoutez les éléments suivants à la métrique mon-kube-state-metrics-metrics-proxy metricsproxysidecar dans la section .spec.destinations :

     - certificate:
     secretName: mon-pa-kube-state-metrics-cert
   port: 8091
   

   Le fichier metricsproxysidecar mis à jour peut se présenter comme suit :

   ...
   spec:
     containerName: otel-collector
     destinations:
     - certificate:
         secretName: mon-io-kube-state-metrics-cert
       port: 8090
     - certificate:
         secretName: mon-pa-kube-state-metrics-cert
       port: 8091
     resources:
       limits:
   ...
   

3. Supprimez la section matchClusters: de la mon-pa-kube-state-metrics monitoringtarget spec. La mon-pa-kube-state-metricsmonitoringtarget spec mise à jour peut se présenter comme suit :

   ...
   spec:
     podMetricsEndpoints:
       metricsRelabelings:
       - action: replace
         replacement: platform-obs
         targetLabel: _gdch_project
       path:
         value: /metrics
       port:
         value: 8091
       scheme:
         value: http
       scrapeInterval: 60s
       scrapeTimeout: 45s
     selector:
       matchLabels:
         monitoringtarget: mon-kube-state-metrics
   

Autorisations mal configurées pour le rôle observability-admin-debugger

Versions : 1.14.3, 1.14.4

Symptômes : les IO ne peuvent pas redémarrer les pods Cortex ou Prometheus dans l'espace de noms mon-system.

Solution :

Pour les organisations :

1. Mettez en pause le sous-composant iam-common.

2. Mettez à jour le roleTemplate observability-admin-debugger/iam-system comme suit :

   apiVersion: iam.private.gdc.goog/v1alpha1
   kind: RoleTemplate
   metadata:
     name: observability-admin-debugger
     namespace: iam-system
   spec:
     metadata:
       roleType: predefined
       hierarchyLevel: org
       persona: infra-operator
       displayName: "Observability Admin"
       bindingType: rolebinding
       roleNamespace: "mon-system"
       operableComponent: IAM
     rules:
     - apiGroups:
       - "apps"
       resources:
       - "deployments"
       resourceNames:
       - "logmon-operator"
       - "cortex-tenant"
       - "meta-blackbox-exporter"
       - "blackbox-exporter"
       verbs:
       - "*"
     - apiGroups:
       - "apps"
       resources:
       - "statefulsets"
       resourceNames:
       - "anthos-prometheus-k8s"
       - "meta-prometheus"
       - "mon-prober-backend-prometheus"
       - "primary-prometheus-shard0-replica0"
       - "primary-prometheus-shard0-replica1"
       - "primary-prometheus-shard1-replica0"
       - "primary-prometheus-shard1-replica1"
       verbs:
       - "*"
     - apiGroups:
       - ""
       resources:
       - "secrets"
       resourceNames:
       - "anthos-prometheus-scrape-cert"
       - "kube-control-plane-metrics-proxy-cert"
       - "metrics-consumers-ca"
       - "metrics-providers-ca"
       - "anthos-prometheus-etcd-scrape"
       verbs:
       - "*"
     - apiGroups:
       - "cert-manager.io"
       resources:
       - "certificates"
       resourceNames:
       - "anthos-prometheus-scrape"
       - "kube-control-plane-metrics-proxy-cert"
       - "metrics-consumers-ca"
       - "metrics-providers-ca"
       verbs:
       - "get"
       - "list"
       - "watch"
   

Pour l'administrateur racine :

1. Mettez en pause le sous-composant iam-common.

2. Mettez à jour le roleTemplate observability-admin-debugger-root/iam-system comme suit :

   apiVersion: iam.private.gdc.goog/v1alpha1
   kind: RoleTemplate
   metadata:
     name: observability-admin-debugger
     namespace: iam-system
   spec:
     metadata:
       roleType: predefined
       hierarchyLevel: org
       persona: infra-operator
       displayName: "Observability Admin"
       bindingType: rolebinding
       roleNamespace: "mon-system"
       operableComponent: IAM
     rules:
     - apiGroups:
       - "apps"
       resources:
       - "deployments"
       resourceNames:
       - "logmon-operator"
       - "cortex-tenant"
       - "meta-blackbox-exporter"
       - "blackbox-exporter"
       verbs:
       - "*"
     - apiGroups:
       - "apps"
       resources:
       - "statefulsets"
       resourceNames:
       - "anthos-prometheus-k8s"
       - "meta-prometheus"
       - "mon-prober-backend-prometheus"
       - "primary-prometheus-shard0-replica0"
       - "primary-prometheus-shard0-replica1"
       - "primary-prometheus-shard1-replica0"
       - "primary-prometheus-shard1-replica1"
       verbs:
       - "*"
     - apiGroups:
       - ""
       resources:
       - "secrets"
       resourceNames:
       - "anthos-prometheus-scrape-cert"
       - "kube-control-plane-metrics-proxy-cert"
       - "metrics-consumers-ca"
       - "metrics-providers-ca"
       - "anthos-prometheus-etcd-scrape"
       verbs:
       - "*"
     - apiGroups:
       - "cert-manager.io"
       resources:
       - "certificates"
       resourceNames:
       - "anthos-prometheus-scrape"
       - "kube-control-plane-metrics-proxy-cert"
       - "metrics-consumers-ca"
       - "metrics-providers-ca"
       verbs:
       - "get"
       - "list"
       - "watch"
   

Rôle de débogueur Grafana manquant

Versions : 1.14.3, 1.14.4

Problèmes constatés : le rôle grafana-debugger-cp n'est pas présent dans les espaces de noms du projet fantôme d'observabilité (*-obs-system). Il est impossible d'accorder aux utilisateurs l'ensemble d'autorisations approprié pour déboguer les problèmes liés à Grafana.

Solution de contournement : Créez la ressource personnalisée ClusterRoleTemplate suivante dans infra-cp et utilisez le ClusterRole correspondant qui est créé pour obtenir les autorisations grafana-debugger.

apiVersion: iam.private.gdc.goog/v1alpha1
kind: ClusterRoleTemplate
metadata:
  name: grafana-debugger-cp
spec:
  metadata:
    roleType: predefined
    hierarchyLevel: infra-cp
    persona: infra-operator
    displayName: "Grafana Admin"
    bindingType: rolebinding
    operableComponent: MON
  rules:
  - apiGroups:
    - "apps"
    resources:
    - "deployments"
    resourceNames:
    - "grafana-proxy-server"
    verbs:
    - "delete"
    - "get"
    - "list"
    - "patch"
    - "update"
    - "watch"
  - apiGroups:
    - "apps"
    resources:
    - "statefulsets"
    resourceNames:
    - "grafana"
    verbs:
    - "delete"
    - "get"
    - "list"
    - "patch"
    - "update"
    - "watch"
  - apiGroups:
    - ""
    resources:
    - "pods"
    resourceNames:
    - "grafana-0"
    verbs:
    - "delete"
    - "get"
    - "list"
    - "patch"
    - "update"
    - "watch"
  - apiGroups:
    - ""
    resources:
    - "pods"
    verbs:
    - "get"
    - "list"
    - "watch"
  - apiGroups:
    - "monitoring.private.gdc.goog"
    resources:
    - "datasources"
    verbs:
    - "create"
    - "delete"
    - "get"
    - "list"
    - "update"
    - "patch"
    - "watch"
  - apiGroups:
    - "monitoring.global.private.gdc.goog"
    resources:
    - "datasourcereplicas"
    verbs:
    - "create"
    - "delete"
    - "get"
    - "list"
    - "update"
    - "patch"
    - "watch"

Les métriques et les journaux multizones ne sont pas visibles après l'ajout d'une zone

Versions : 1.14.*

Symptômes : le tableau de bord Grafana n'affiche pas les journaux ni les métriques pour la zone nouvellement ajoutée.

Solution 1 : Redémarrez le déploiement datasource-proxy :

kubectl KUBECONFIG=${KUBECONFIG_ORG} rollout restart deployment datasource-proxy -n mon-system

Les pods datasource-proxy redémarreront et la configuration du point de terminaison multizone sera mise à jour pour la zone nouvellement ajoutée.

Le finaliseur MonitoringTarget bloque la suppression de l'espace de noms.

Versions : 1.14.3, 1.14.4

Symptômes : l'espace de noms n'est pas supprimé et des clusters non opérationnels sont présents dans l'organisation concernée.

Solution de contournement : supprimez manuellement les finaliseurs des ressources personnalisées MonitoringTarget qui ont bloqué la suppression de l'espace de noms.

La suppression du projet est bloquée en raison de finaliseurs en attente pour le tableau de bord et la source de données

Versions : 1.14.3, 1.14.4

Corrigé : correctif 22 de la version 1.14.3

Symptômes : les projets ne sont pas supprimés et l'espace de noms de fin présente des erreurs comme dans l'exemple suivant :

Some resources are remaining: dashboards.observability.gdc.goog has 2 resource instances, datasources.monitoring.private.gdc.goog has 2 resource instances.

Solution : Supprimez manuellement les finaliseurs du tableau de bord et de la source de données.

Les métriques de KSM ne sont pas visibles

Versions : 1.14.3

Corrigé : correctif 22 de la version 1.14.3

Symptômes : les tableaux de bord KUB affichent No Data dans tous les panneaux.

Solution : Mettez en veille le sous-composant KSM et mettez à jour monitoringtarget et metricsproxysidecar.

1. Mettre en veille un sous-composant :

   export SUBCOMPONENT_NAME=mon-kube-state-metrics
   export SUBCOMPONENT_NAMESPACE=ORG_NAME
   kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG annotate subcomponent "${SUBCOMPONENT_NAME:?}" -n "${SUBCOMPONENT_NAMESPACE:?}" lcm.private.gdc.goog/paused=true
   

   Remplacez les éléments suivants :

   • ORG_NAME : nom de l'organisation.
   • ROOT_ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig de l'administrateur racine.

2. Ajoutez le code suivant à mon-kube-state-metrics-metrics-proxy metricsproxysidecar dans .spec.destinations :

   - certificate:
     secretName: mon-pa-kube-state-metrics-cert
   port: 8091
   

   La métrique mon-kube-state-metrics-metrics-proxy mise à jour ressemble à cet exemple :

   ...
   spec:
     containerName: otel-collector
     destinations:
     - certificate:
         secretName: mon-io-kube-state-metrics-cert
       port: 8090
     - certificate:
         secretName: mon-pa-kube-state-metrics-cert
       port: 8091
     resources:
       limits:
   ...
   

3. Supprimez la section matchClusters: de la spécification monitoringtarget mon-pa-kube-state-metrics. La spécification monitoringtarget mon-pa-kube-state-metrics mise à jour se présente comme suit :

   ...
   spec:
     podMetricsEndpoints:
       metricsRelabelings:
       - action: replace
         replacement: platform-obs
         targetLabel: _gdch_project
       path:
         value: /metrics
       port:
         value: 8091
       scheme:
         value: http
       scrapeInterval: 60s
       scrapeTimeout: 45s
     selector:
       matchLabels:
         monitoringtarget: mon-kube-state-metrics`
   

Le pipeline de métriques système est en panne

Version : 1.14.3

Symptômes : L'alerte MON-A0001 est active même après avoir suivi le runbook MON-R0001.

Solution :

1. Si le problème se produit dans le cluster d'administrateur, créez le SubcomponentOverride suivant dans root-admin à l'aide du runbook IAC-R0004. Pour les autres clusters (utilisateur, périmètre ou partagé, par exemple), créez SubcomponentOverride dans ${ORG}-mp.

   kind: SubcomponentOverride
   metadata:
     name: mon-cortex-tenant
     namespace: <NAMESPACE>
   spec:
     backend:
       operableParameters:
         concurrency: 1024
         resourcesLimit:
           cpu: "8"
           memory: 16Gi
     subComponentRef: mon-cortex-tenant
   

2. Trouvez le bon NAMESPACE :

   kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG get subcomponent -A | grep "mon-cortex-tenant"
   

   Voici le résultat :

   org-1-mp             mon-cortex-tenant                      27h   ReconciliationCompleted
   org-1                mon-cortex-tenant                      46h   ReconciliationCompleted
   root                 mon-cortex-tenant                      47h   ReconciliationCompleted
   

   L'espace de noms est la racine si le pipeline est en panne pour root-admin, ou org-1 si le pipeline est en panne pour org-1 admin :

   kubectl --kubeconfig=ORG_ADMIN_KUBECONFIG get subcomponent -A | grep "mon-cortex-tenant"
   

   Voici le résultat :

   g-org-1-perimeter-cluster        mon-cortex-tenant                     40h   ReconciliationCompleted
   g-org-1-shared-service-cluster   mon-cortex-tenant                     40h   ReconciliationCompleted
   user-vm-1-cluster                mon-cortex-tenant                     40h   ReconciliationCompleted
   user-vm-2-cluster                mon-cortex-tenant                     40h   ReconciliationCompleted
   

   Ici, l'espace de noms correct peut être g-org-1-perimeter-cluster, g-org-1-shared-service-cluster, user-vm-1-cluster ou user-vm-2-cluster selon le cluster pour lequel le pipeline de métriques système est en panne.

3. Après avoir appliqué le SubcomponentOverride, redémarrez le déploiement cortex-tenant dans les clusters concernés. Vérifiez si les valeurs sont mises à jour dans le cluster concerné :

   kubectl --kubeconfig ${KUBECONFIG:?} get configmap cortex-tenant-config -n mon-system -o yaml
   

4. Mettez à jour le champ de simultanéité.

5. Redémarrez les déploiements cortex-tenant :

   kubectl --kubeconfig ${KUBECONFIG:?} rollout restart deployment/cortex-tenant -n mon-system
   

Architecture mutualisée

La console n'indique pas les échecs de création de pool de nœuds

Version : 1.14.4, 1.14.5, 1.14.6

Corrigé : 1.14.7

Symptômes : dans la console GDC, lorsqu'un pool de nœuds ne peut pas être créé, l'UI affiche à tort un message creation in progress indiquant que le pool de nœuds a été créé.

Solution de contournement : utilisez la CLI gdcloud pour valider la création du pool de nœuds.

Multizone

La zone inaccessible redirige vers la page d'authentification

Version : 1.14.x

Symptômes : lorsqu'une zone est inaccessible, la console GDC redirige vers une page affichant une erreur d'authentification. Toutefois, l'inaccessibilité de la zone peut ne pas être due à un problème d'authentification, mais plutôt à une panne zonale.

Solution : utilisez l'URL zonale pour contourner le problème. Si l'URL zonale ne fonctionne pas non plus, demandez à votre opérateur d'infrastructure (IO) de vérifier si la zone pour laquelle vous rencontrez des problèmes d'authentification est hors service.

Le rôle permettant d'afficher les zones à l'aide de la gcloud CLI n'est pas appliqué

Version : 1.14.x

Symptômes : le rôle IAM requis pour utiliser la commande gdcloud zones list n'est pas appliqué à l'univers GDC par défaut. Le rôle manquant, qui n'est pas disponible en tant que rôle prédéfini, empêche l'utilisation de la gcloud CLI pour lister les zones.

Solution de contournement : Appliquez les ressources de rôle IAM global-zone-viewer et de liaison de rôle au serveur d'API global :

1. Créez un fichier YAML de rôle, tel que global-zone-viewer.yaml, avec le contenu suivant :

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: global-zone-viewer
     namespace: mz-system
   rules:
   - apiGroups:
     - location.mz.global.private.gdc.goog
     resources:
     - zones
     verbs:
     - get
     - list
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: global-zone-viewer-binding
     namespace: mz-system
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: global-zone-viewer
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:authenticated
   

2. Appliquez le fichier YAML au serveur d'API global de l'organisation :

   kubectl --kubeconfig ORG_GLOBAL_API_SERVER_KUBECONFIG apply -f global-zone-viewer.yaml
   

Cette liaison de rôle authentifie tous les utilisateurs du système pour qu'ils puissent afficher les zones à l'aide de gdcloud zones list.

Erreurs de connexion intermittentes à l'URL de la console globale

Versions : 1.14.x

Symptômes : lorsque vous vous connectez à la console GDC avec l'URL globale, vous pouvez recevoir des erreurs indiquant que votre session n'est plus valide. Cette erreur peut être due à un bug réseau sous-jacent et ne reflète pas précisément l'état de votre session.

Solution de contournement : Connectez-vous à la console GDC avec les URL zonales pour gérer les ressources globales depuis chaque zone. Pour savoir comment changer de contexte zonal depuis la console GDC, consultez Gérer les ressources dans plusieurs zones.

Mise en réseau

L'ajustement de l'ordre des zones MultiZoneNetworkConfig entraîne un échec du remplacement de la configuration

Versions : toutes les versions 1.14.x peuvent être concernées.

Symptômes :

1. L'état READY des commutateurs top-of-rack (ToR) est défini sur "False". Vous pouvez le vérifier en exécutant la commande suivante :

   kubectl get torswitches -A
   

2. Le remplacement de la configuration du commutateur échoue avec une erreur indiquant que l'entrée existe déjà. Cela se voit dans les journaux de remplacement de la configuration du commutateur. Le message d'erreur ressemble à ceci :

   % Insertion failed - entry already exists
   

Ce problème est dû à l'ajustement de l'ordre des zones dans MultiZoneNetworkConfig. Le système génère des numéros de séquence pour les règles de liste d'accès BGP en fonction de la position de chaque zone dans la liste de configuration. Si l'ordre des zones est modifié, le système génère de nouvelles règles avec des numéros de séquence différents qui sont en conflit avec les règles déjà présentes sur le commutateur.

Solutions :

Pour résoudre ce problème, supprimez manuellement la configuration de la liste d'accès au chemin AS BGP en conflit de chaque commutateur ToR concerné. Cela permet au système de réconcilier et d'appliquer la configuration appropriée.

1. Établissez une connexion SSH à chaque commutateur ToR qui n'est pas à l'état Ready.

2. Passez en mode de configuration globale :

   config t
   

3. Supprimez la configuration de la liste d'accès en conflit :

   no ip as-path access-list other-zones
   

4. Quittez le mode configuration.

Une fois cette commande exécutée sur tous les commutateurs concernés, le réconciliateur appliquera la configuration appropriée et les commutateurs passeront à l'état READY.

Expiration de l'opération de remplacement de la configuration

Versions : toutes les versions 1.14.x peuvent être concernées.

Symptômes :

Un grand nombre de listes de contrôle d'accès (LCA) provoque un délai d'expiration lors de la configuration des commutateurs réseau. La ressource personnalisée BorderLeafSwitch n'est pas dans l'état Ready. Lorsque vous établissez une connexion SSH avec le commutateur non prêt, l'état Commit expiry s'affiche.

Par exemple, la commande suivante affiche l'état :

sh config-replace log verify

Le résultat ressemble à ce qui suit :

  Config-replace type: atomic .replace_tmp_11924
  Start Time: Wed Jul 09 18:08:33 2025
  Operation Status: Success
  Commit Status: Commit expiry

Solution :

Dans les versions 1.14.3 ou 1.14.7+, modifiez la ressource personnalisée SubcomponentOverride nommée pnet-core-override dans l'espace de noms root, puis ajoutez un champ httpTimeout à .spec.operableParameters.netDevGW.

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: pnet-core-override
  namespace: root
spec:
  backend:
    bootstrapParameters:
      enableMetricsEncryption: true
    operableParameters:
      disableNetworkReconcilerFeatures: ""
      enableOperationStoragePVC: false
      netDevGW:
        httpTimeout: 10m
  subComponentRef: pnet-core

Patientez 15 minutes pour que l'infrastructure d'automatisation puisse envoyer les nouvelles configurations aux commutateurs. Configurez httpTimeout selon vos besoins jusqu'à ce que les messages Commit expiry disparaissent.

Dans les versions 1.14.4, 1.14.5 et 1.14.6, effectuez manuellement la configuration de remplacement et validez les modifications.

1. Mettez en pause le transfert :

   export SWITCH_NAME=SWITCH_NAME # example: aa-aa-blsw01
   export SWITCH_TYPE=SWITCH_TYPE # example: borderleafswitch
   
   kubectl -n gpc-system annotate $SWITCH_TYPE $SWITCH_NAME system.private.gdc.goog/paused="true"
   

2. Suivez le runbook PNET-P0001 pour obtenir l'accès au commutateur.

3. Recherchez la configuration à remplacer :

   switch-cli# dir | grep new_config
   

4. Effectuez le remplacement de la configuration :

   switch-cli# configure replace <new_config_file>
   

   Cette opération peut prendre plus de cinq minutes.

5. Une fois la commande config-replace exécutée, validez la modification :

   switch-cli# configure replace commit
   

6. Réactiver le transfert :

   kubectl -n gpc-system annotate $SWITCH_TYPE $SWITCH_NAME system.private.gdc.goog/paused-
   

Échec du déploiement avec un ASN BGP de 4 octets

Versions : 1.14.3, 1.14.4

Symptômes : la configuration du protocole BGP (Border Gateway Protocol) avec un numéro de système autonome (ASN) de quatre octets sur les commutateurs réseau entraîne des échecs de configuration. Sans une configuration BGP correctement appliquée, le réseau de cette zone GDC peut ne pas être en mesure d'établir un routage approprié, ce qui peut entraîner des problèmes de connectivité, l'impossibilité d'annoncer des routes ou une instabilité générale du réseau. Il n'existe aucune solution pour le moment.

Trafic anycast mondial bloqué

Versions : 1.14.3

Symptômes : le trafic destiné aux points de terminaison anycast mondiaux est bloqué par les listes de contrôle d'accès (LCA).

Solution :

Pour résoudre le problème lié au blocage du trafic anycast global par les listes de contrôle d'accès (ACL), vous devez créer une ressource personnalisée SubcomponentOverride dans le cluster d'administration racine afin d'autoriser explicitement le trafic vers les blocs CIDR anycast du serveur DNS global. Procédez comme suit :

1. Recherchez tous les blocs CIDR anycast mondiaux. Pour trouver les blocs CIDR anycast mondiaux à mettre à jour, procédez comme suit :

   1. Connectez-vous au serveur d'API global racine.

   2. Répertoriez toutes les ressources personnalisées de sous-réseau dans tous les espaces de noms à l'aide de la commande suivante :

      kubectl get subnet -A
      

   3. Filtrez la sortie pour trouver les ressources de sous-réseau où le filtre metadata.name contient le mot clé anycast.

   4. Pour chaque ressource de sous-réseau trouvée avec anycast dans son nom, notez la valeur de spec.subnet. Cette valeur représente un bloc CIDR anycast mondial.

2. Dans le cluster d'administrateur racine, créez une ressource personnalisée SubcomponentOverride nommée pnet-trafficpolicy-dc-override dans l'espace de noms racine. Pour chaque sous-réseau anycast que vous avez identifié à l'étape précédente, ajoutez les règles comme indiqué dans le fichier YAML :

   apiVersion: lcm.private.gdc.goog/v1
   kind: SubcomponentOverride
   metadata:
     name: pnet-trafficpolicy-dc-override
     namespace: root
   spec:
     backend:
       operableParameters:
         breakglassRules:
           default-traffic-policy-data:
           - IPVersions:
             - IPv4
             L4Protocol: IP
             action: Accept
             description: INTERCONNECT_RULE_DESCRIPTION
             destinationEndPoint:
               host:
                 hostPrefix: GLOBAL_ANYCAST_CIDR
               port:
                 portType: ANY
             direction: Ingress
             enforcePoints:
             - enableLogging: false
               enforcePointType: DataInterconnect
             sourceEndPoint:
               host:
                 hostType: ANY
               port:
                 portType: ANY
           - IPVersions:
             - IPv4
             L4Protocol: IP
             action: Accept
             description: HAIRPIN_RULE_DESCRIPTION
             destinationEndPoint:
               host:
                 hostType: ANY
               port:
                 portType: ANY
             direction: Ingress
             enforcePoints:
             - enableLogging: false
               enforcePointType: DataHairpin
             sourceEndPoint:
               host:
                 hostPrefix: GLOBAL_ANYCAST_CIDR
               port:
                 portType: ANY
     subComponentRef: pnet-trafficpolicy-dc
   

   Remplacez les éléments suivants :

   • INTERCONNECT_RULE_DESCRIPTION : texte descriptif de la règle de réseau d'interconnexion.
   • GLOBAL_ANYCAST_CIDR : bloc CIDR anycast mondial, tel que 136.125.38.128/28. Pour chaque anycast trouvé à l'étape précédente, créez la règle à l'aide de ce fichier YAML.
   • HAIRPIN_RULE_DESCRIPTION : texte descriptif de la règle de réseau en épingle.

L'échec partiel de l'ID de canal de distribution entraîne une perte de trafic

Versions : 1.14.3

Symptômes : lorsque les deux liens DCI (Data Center Interconnect) qui connectent le commutateur leaf de bordure d'une zone au commutateur de l'opérateur, ou lorsque le commutateur leaf de bordure d'une zone subit une défaillance matérielle, environ 50 % du trafic réseau interzones est perdu.

Nom de VRF trop long

Versions : 1.14.2

Symptômes : un message semblable à l'exemple suivant peut s'afficher, indiquant que les commutateurs ne sont pas en bon état lorsque vous exécutez cette commande :

sh config-replace log verify

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

Operation            : Config-replace to user config
Checkpoint file name : .replace_tmp_20791
Scheme               : tmp
Cfg-replace done By  : admin
Cfg-replace mode     : atomic
Verbose              : disabled
Start Time           : Fri, 20:03:38 08 Nov 2024
Start Time UTC       : Fri, 20:03:38 08 Nov 2024
-------------------------------------------
Command : snmp-server context gdch-services-orginfrainternal-vrf vrf gdch-servic
es-orginfrainternal-vrf, parse error : -20, mode : /exec/configure/vrf
Failed to parse: snmp-server context gdch-services-orginfrainternal-vrf vrf gdch
-services-orginfrainternal-vrf
Configuration above is invalid or not supported via CR/rollback feature

Solution de contournement : Le nom du CR de l'organisation ne peut pas comporter plus de 19 caractères.

Échec de la communication des pods StatefulSet

Versions : 1.14.3, 1.14.4

Corrigé : correctif 23 de la version 1.14.3, version 1.14.5

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*]

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
   

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*]

Problème lié au tableau de bord Grafana du SLO de disponibilité multizone et entre zones

Versions : 1.14.3

Symptômes : dans Grafana, le tableau de bord des SLO pnet-cross-zone-availability n'affiche aucune métrique.

Solution : Suivez le runbook PNET-P0001 pour accéder au commutateur et vérifier manuellement l'état de la session BGP et de la connectivité multizones.

Échec de la réconciliation des passerelles d'entrée du plan de données et de gestion

Versions : 1.14.3

Problèmes constatés : les sous-composants asm-dataplane-ingress ou asm-management-ingress ne parviennent pas à se réconcilier avec l'erreur suivante :

message: 'Reconciliation error: E0111 - upgrade chart: cannot patch "management-ingress-gateway" with kind BackendService: BackendService.networking.gdc.goog "management-ingress-gateway" is invalid: spec.targetPorts: Invalid value: "array": TargetPorts list is immutable'

ForwardingRuleInternal et ForwardingRuleExternal sont d'autres valeurs possibles dans la chaîne d'erreur au lieu de BackendService. De même, le nom de ressource peut être dataplane-ingress-gateway, dataplane-ingress-gateway-global ou management-ingress-gateway-global au lieu de management-ingress-gateway.

Solution de contournement : Déterminez si la ressource est présente dans le serveur de l'API de gestion ou dans le serveur de l'API globale. Cela peut être déduit de la version de l'API du type de ressource dans la chaîne d'erreur. Par exemple, une ressource avec le suffixe networking.gdc.goog est présente dans le serveur de l'API Management, tandis qu'une ressource avec le suffixe networking.global.gdc.goog est présente dans le serveur de l'API globale.

Une fois le serveur d'API identifié, supprimez la ressource à l'aide du fichier kubeconfig correspondant. Exemple :

kubectl --kubeconfig API_SERVER_KUBECONFIG delete Backendservice dataplane-ingress-gateway -n istio-system

La page des règles réseau du projet n'est pas compatible avec le champ du sélecteur de projet dans l'API ProjectNetworkPolicy

Versions : 1.14.3, 1.14.4

Symptômes : lorsque vous créez une règle de réseau de projet qui inclut le champ projectSelector et que vous l'affichez dans la console GDC, l'interface utilisateur affiche tous les projets sélectionnés pour la règle au lieu des projets figurant dans le champ projectSelector.

Solution de contournement : Utilisez l'API pour créer et lire une règle de réseau de projet qui inclut le champ projectSelector.

Système d'exploitation

Échec du provisionnement du serveur

Versions : 1.14.3

Symptômes : lors du provisionnement du serveur, les erreurs 401 suivantes peuvent s'afficher sur la ressource personnalisée BaremetalHost correspondante lors du téléchargement de l'image OS à partir du registre Harbor. Le serveur est alors bloqué dans une boucle de déprovisionnement et de reprovisionnement.

Pour vérifier si ces erreurs se sont produites, décrivez la ressource personnalisée BaremetalHost :

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG describe baremetalhost SERVER_NAME -n gpc-system

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

Normal  InspectionComplete     14m    metal3-baremetal-controller  Hardware inspection completed
Normal  ProvisioningStarted    5m39s  metal3-baremetal-controller  Image provisioning started for https://robot%24om5hgylsfvzxs43umvwtu43boiwwc4djmv4hizloonuw63rnmjqwg23fnzsc2ylqnfsxq5dfnzzws33ofvzwk4twmvza:4usy4JXE6BAdEVU2t8LMqDPhfM4EnW73@10.129.24
.66:31714/artifacts/serve/Z3BjLXN5c3RlbS1vcy1pbWFnZXMvZ2RjaC1ub2RlLW9zOnJvY2t5LTg2LTEuMTQtdjIwMjQxMDIzLTEuMTQtcjI4MQ==
Normal  ProvisioningError      5m28s  metal3-baremetal-controller  Image provisioning failed: Failed to prepare to deploy: Validation of image href https://robot%24om5hgylsfvzxs43umvwtu43boiwwc4djmv4hizloonuw63rnmjqwg23fnzsc2ylqnfsxq5dfnzzws33ofvzwk
4twmvza:4usy4JXE6BAdEVU2t8LMqDPhfM4EnW73@10.129.24.66:31714/artifacts/serve/Z3BjLXN5c3RlbS1vcy1pbWFnZXMvZ2RjaC1ub2RlLW9zOnJvY2t5LTg2LTEuMTQtdjIwMjQxMDIzLTEuMTQtcjI4MQ== failed, reason: Got HTTP code 401 instead of 200 in response to HEAD request.
Normal  DeprovisioningStarted  5m17s  metal3-baremetal-controller  Image deprovisioning started

Solution :

1. Obtenez le nom et l'espace de noms du nodePoolClaim auquel appartient le serveur :

   kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get server SERVER_NAME -n gpc-system -ojson | jq '.spec.nodePoolClaimRef'
   

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

   {
   "name": "control-plane-extension-pool-o2-standard1-96-gdc-metal",
   "namespace": "gpu-org-lancer"
   }
   

2. Obtenez le nom de l'image de l'OS à partir de NodePoolClaim :

   kubectl get nodepoolclaim NODEPOOLCLAIM_NAME -n NODEPOOLCLAIM_NAMESPACE -o json | jq '.spec.machineSpec.osImageName'
   

3. Obtenez l'URL de l'image de l'OS à partir du OSImageMetadata :

   kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get osimagemetadata OS_IMAGE_NAME -o json | jq '.commonMetadata.servingURL'
   

4. Mettez à jour la ressource personnalisée Server avec la dernière URL de l'image OS :

   kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG patch server SERVER_NAME -n gpc-system --type=json -p='[{"op": "replace", "path": "/spec/image/urlSpec/url", "value" : "'OS_IMAGE_URL'"}]'
   

La mise à niveau de l'OS du nœud peut rester bloquée à l'étape "NodeOSInPlaceUpgradePostProcessingCompleted"

Versions : 1.14.3, 1.14.4

Symptômes :

Lors de la mise à niveau d'un nœud, NodeUpgradeTask reste bloqué à l'étape NodeOSInPlaceUpgradePostProcessingCompleted avec une erreur de réconciliateur et le message failed verifying delta after upgrade. Cette erreur indique que le processus de vérification de la mise à niveau a détecté des différences de packages inattendues sur le nœud. Plus précisément, il identifie les packages qui sont toujours à l'état "need-upgrade" (mise à niveau requise) ou qui apparaissent comme des packages "only-in-new" (nouveaux uniquement) après la tentative de mise à niveau.

Le message d'erreur liste les packages spécifiques dont la validation a échoué. Exemple d'extrait :

{"ts":1748758118826.9954,"caller":"controller/controller.go:329","msg":"Reconciler error","controller":"NodeUpgradeTask","controllerGroup":"upgrade.private.gdc.goog","controllerKind":"NodeUpgradeTask","NodeUpgradeTask":{"name":"lancer-org1-data-plane-pool-o2-standard1-96-gdc-metal-nmw2h-zx-ac-bm15","namespace":"lancer-org1"},"namespace":"lancer-org1","name":"lancer-org1-data-plane-pool-o2-standard1-96-gdc-metal-nmw2h-zx-ac-bm15","reconcileID":"26585774-7059-46b7-a0f7-0e627b2a2bb5","err":"failed verifying delta after upgrade: 2 errors occurred:\n\t* failed to make \"need-upgrade\" empty, found\n  - bind-export-libs\n  from: 9.11.36-16.el8_6.86ciq_lts.2\n  to: 9.11.36-16.el8_6.86ciq_lts.4\n...\n- strongswan-sqlite\n  from: 5.9.10-1.el8_6.ciqlts\n  to: 5.9.10-2.el8\n\t* failed to make \"only-in-new\" empty, found lsof=4.93.2-1.el8\nstrace=5.13-4.el8\n\n"}

Ce symptôme peut être dû à deux problèmes. Déterminez d'abord la cause du problème :

1. Cause-A : la machine est inaccessible, ce qui rend OSArtifactSnapShot obsolète.

   Vérifiez si le nœud en cours de mise à niveau est toujours opérationnel et si le job OSArtifactSnapShot correspondant échoue.

   Si OSArtifactSnapShot est obsolète et que la machine n'est pas accessible pendant plus de 20 minutes, passez à Mitigation-A. Sinon, continuez à rechercher Cause-B.

2. Cause-B : échec silencieux de la mise à niveau du RPM

   Dans de rares cas, la mise à niveau du RPM sur une machine peut échouer silencieusement après une mise à niveau partielle. Deux ConfigMap doivent contenir la différence de package avant et après la mise à niveau :

   in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-before-upgrade
   in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-after-upgrade
   

   Si le fichier "after-upgrade" contient moins de packages que le fichier configmap "before-upgrade", cela signifie que la mise à niveau a été abandonnée en mode silencieux et que tous les packages n'ont pas été mis à niveau. Accédez à Mitigation-B.

Solution :

Mitigation-A : réparer une machine inaccessible

Essayez de réparer la machine en la redémarrant. Si la machine reste inaccessible après plusieurs tentatives de redémarrage, contactez l'équipe SERV pour obtenir de l'aide. Une fois la machine à nouveau accessible, supprimez OSArtifactSnapShot pour forcer la réconciliation. Une fois OSArtifactSnapShot réconcilié, NodeUpgradeTask doit passer à l'étape suivante.

Mitigation-B : réessayez NodeUpgradeTask

1. Connectez-vous en SSH à la machine en cours de mise à niveau et collectez les journaux suivants pour le dépannage ultérieur. Les fichiers suivants doivent être collectés :

   • /var/log/dnf.log
   • /var/log/dnf.rpm.log
   • dnf history > dnf_history.log
   • rpm -qa --last > rpm_last.log

2. Supprimez la NodeUpgradeTask défaillante. Cela déclenchera une nouvelle tentative de NodeUpgradeTask sur le nœud concerné. Le nouveau NodeUpgradeTask devrait terminer la mise à niveau du RPM et passer à l'étape suivante.

La mise à niveau des nœuds OS peut être bloquée lors de la création du serveur de packages

Versions : 1.14.3, 1.14.4

Symptômes :

Lorsqu'un CR NodeUpgrade est créé, que sa mise en veille est suspendue et qu'il reste à l'état in-progress pendant plus de 30 minutes, il peut échouer silencieusement lors de la création du serveur de package. Le problème est qu'un NodeUpgrade reste sur .status.upgradeStatus=in-progress, mais qu'aucun .status.tasks n'est chargé :

status:
  duration: 0s
  upgradeStatus: in-progress

Pour confirmer que cela échoue lors de la création du serveur de packages, lisez le journal du contrôleur de mise à niveau de l'OS :

kubectl logs deployment/os-upgrade-controller -n os-system --kubeconfig=/path/to/admin-cluster-kubeconfig-of-the-nodeupgrade-object

Si le journal du contrôleur affiche failed to create package server et failed to create package repo server DNS registration avec une raison détaillée (l'une des suivantes)

• spec.fqdnPrefix already used in an existing DNS registration
• name already used in an existing DNS.

Il suggère ensuite que certaines autres ressources de serveur de packages utilisées par d'autres NodeUpgrade sont toujours actives et entrent en conflit avec la ressource à créer pour le NodeUpgrade en cours de blocage.

Solution :

Pour confirmer, vous pouvez vérifier la ressource du serveur de package réel (de certaines API, telles que dnsregistration.network.private.gdc.goog dans le serveur d'API de gestion du cluster qui gère le CR NodeUpgrade) et trouver le NodeUpgrade qui possède ces ressources. Si le NodeUpgrade propriétaire du DNSRegistration est déjà terminé, mais que la ressource DNSRegistration n'est toujours pas supprimée, vous pouvez supprimer l'objet DNSRegistration si tous ses objets NodeUpgrade référencés sont terminés.

1. Listez tous les CR DNSRegistration pour le serveur de packages NodeUpgrade :

   kubectl get dnsregistration.network.private.gdc.goog -n $NAMESPACE $NAME $ -ojson --kubeconfig=/path/to/mgmt-api-server-kubeconfig-of-the-nodeupgrade-object | grep nu-bm
   

2. Interrogez le propriétaire du RS NodeUpgrade pour un DNSRegistration spécifique :

   kubectl get dnsregistration.network.private.gdc.goog -n $NAMESPACE $NAME $ -ojson --kubeconfig=/path/to/mgmt-api-server-kubeconfig-of-the-nodeupgrade-object | jq -r '.metadata.annotations."package-server-owners"'
   

Les mises à niveau de l'OS des nœuds peuvent rencontrer des problèmes et s'arrêter à n'importe quelle étape du processus.

Versions : 1.14.4, 1.14.5, 1.14.6

Symptômes :

Le CR NodeUpgradeTask est toujours inférieur à in-progress depuis plus de deux heures, mais il pourra peut-être se compléter automatiquement si vous lui laissez suffisamment de temps.

La demande de modification NodeUpgradeTask est en cours depuis plus de deux heures. Bien que la saisie semi-automatique puisse finir par fonctionner, le problème sous-jacent est l'incapacité de l'os-policy-reconciler à gérer efficacement un grand volume de CR OSPolicy. Ce problème se produit lors de l'étape NodeOSInPlaceUpgradeCompleted.

Pour confirmer davantage cet échec lors de la création du serveur de packages, consultez le journal du contrôleur de mise à niveau de l'OS.

kubectl logs deployment/os-upgrade-controller -n os-system --kubeconfig=/path/to/admin-cluster-kubeconfig-of-the-nodeupgrade-object

Si le journal du contrôleur ne contient pas d'entrée OSPolicy provenant de NodeUpgradeTask, cela indique que le contrôleur est surchargé.

Solution :

Mettez en veille toutes les RS OSPolicy non essentielles pendant le processus de mise à niveau.

La commande "storage cp" d'un fichier volumineux entraîne la défaillance de l'API kube-api de gestion de l'organisation

Versions : 1.14.3 et ultérieures

Symptômes : lors d'une opération gdcloud storage cp ou gdcloud system container-registry load-oci à partir d'un poste de travail OIC, il est possible que l'accès à org-infra soit perdu, suivi de la désactivation de kube-api de org-mgmt. Il s'agit d'un problème rare. Il est utile de collecter des données pour l'équipe d'ingénieurs.

Solution de contournement : lorsque ce problème se produit, essayez la procédure suivante :

1. Pour chaque nœud du plan de contrôle, exécutez uptime pour voir si les nœuds ont été redémarrés au cours des dernières 24 heures.
2. Notez l'heure du redémarrage.
3. Recherchez les paniques du noyau sur chaque nœud CP qui se sont produites juste avant le redémarrage en exécutant dmesg | grep -i 'kernel panic'.
4. Sur chaque nœud de plan de contrôle, vérifiez si les cartes NIC Mellanox sont installées en exécutant la commande lspci | grep -i eth | grep -i mellanox. Si aucune carte réseau Mellanox n'est présente, arrêtez de lire cet article sur les problèmes connus.

5. Sur chaque nœud CP, vérifiez les paramètres réseau suivants sur data0 :

   [root@cp-node-01 ~]# ethtool -k data0 | grep -E 'generic-receive-offload|large-receive-offload|rx-checksumming|rx-gro-hw'
   rx-checksumming: off
   generic-receive-offload: on
   large-receive-offload: off
   rx-gro-hw: on  # <--- Check this value
   

   Si rx-gro-hw (voir ci-dessus) est défini sur "off" sur tous les nœuds, arrêtez de lire ce problème connu.

6. Rassemblez des informations pour Google afin de l'aider à diagnostiquer le problème :

   k8s.org get po -n anthos-identity-service -l k8s-app=ais
   
   k8s.org get po -n management-kube-system
   
   k8s.org get po -n kube-system -l component=kube-apiserver
   
   k8s.org get nodes -l node-role.kubernetes.io/control-plane
   

7. Sur chaque nœud CP, exécutez les commandes suivantes :

   dmesg | grep -i 'kernel panic'
   
   journalctl -u disable-rx-gro-hw.service
   
   systemctl status disable-rx-gro-hw
   
   modinfo mlx5_core | grep ^version:
   

8. Pour résoudre le problème de paramètres réseau, rx-gro-hw doit être défini sur off en exécutant les commandes suivantes sur tous les nœuds CP :

   ethtool -K data0 rx off gro off lro off
   ethtool -K data1 rx off gro off lro off
   ethtool -K bond00 rx off gro off lro off
   

9. Vérifiez à nouveau les paramètres :

   [root@cp-node-01 ~]# ethtool -k data0 | grep -E 'generic-receive-offload|large-receive-offload|rx-checksumming|rx-gro-hw'
   rx-checksumming: off
   generic-receive-offload: on
   large-receive-offload: off
   rx-gro-hw: off # <--- Check this, should be "off"
   

10. Réessayez l'opération d'origine, comme gdcloud storage cp ou gdcloud system container-registry load-oci. Si l'échec persiste, contactez l'équipe d'ingénieurs.

Operations Suite Infrastructure Core Services (OIC)

Performances médiocres du serveur intermédiaire

Versions : toutes les versions de Google Distributed Cloud (GDC) sous air gap peuvent être concernées.

Symptômes : les opérations du navigateur ou du système prennent trop de temps.

Solution :

Augmentez le nombre de processeurs virtuels sur les serveurs relais à l'aide du gestionnaire Hyper-V sur BM03 et BM04 :

1. Sélectionnez une VM Jumphost, puis cliquez sur Paramètres dans le volet d'actions.
2. Sélectionnez Processeur, puis augmentez le nombre de Processeurs virtuels à quatre ou plus, en fonction de la charge de travail.
3. Répétez l'opération pour les Jumphosts restants.

Resource Manager

Impossible de supprimer des projets dans la console GDC

Versions : 1.14.3, 1.14.4

Symptômes : la console GDC fournit le bouton Supprimer pour les projets existants sur la page Détails du projet, mais ce bouton ne fonctionne pas.

Solution de contournement : Pour supprimer un projet existant, vous devez utiliser la gcloud CLI. Pour en savoir plus, consultez Supprimer un projet.

Playbooks Ansible d'organisation manquants

Versions : 1.14.3

Symptômes : lors de la création d'une organisation, le job create-ansible-playbooks qui crée les playbooks Ansible requis échoue sans message d'erreur. L'absence de playbooks Ansible entraîne des problèmes tels que le manque de machines virtuelles de périmètre et des difficultés à créer une organisation mondiale.

Solution : Suivez le runbook OS-R0009 pour créer manuellement les playbooks Ansible d'organisation manquants.

Une organisation mondiale asymétrique affiche des configurations zonales inexistantes

Versions : 1.14.4

Symptômes : lorsque vous créez une organisation mondiale v1 avec seulement un sous-ensemble de configurations d'organisation zonales, toutes les zones affichent toujours un état de réplica d'organisation. Par exemple, si vous disposez d'un univers GDC avec trois zones, mais que vous ne créez une configuration d'organisation zonale que pour deux zones, la troisième zone affiche toujours un état de réplica erroné pour la troisième organisation zonale inexistante.

Pour confirmer l'état erroné, imprimez l'état de l'organisation mondiale :

kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get organization \
    ORG_NAME -n gpc-system -o yaml

La sortie YAML ressemble à ceci :

...

- name: zone3
  replicaStatus:
    systemInfo:
      cidrInfo: {}
  rolloutStatus:
    conditions:
    - lastTransitionTime: "2025-03-12T02:09:21Z"
      message: ""
      observedGeneration: 1
      reason: Current
      status: "True"
      type: Synced
    - lastTransitionTime: "2025-03-12T02:09:22Z"
      message: rollout succeeded
      observedGeneration: 1
      reason: RolloutSucceeded
      status: "True"
      type: Replicated

...

Notez que cela ne se produit que pour les organisations v1, car les configurations zonales asymétriques ne sont pas prises en charge pour les organisations v2.

Solution : Vous pouvez ignorer l'état erroné de l'instance répliquée, car l'organisation zonale n'existe pas, sauf si vous l'avez créée spécifiquement.

Cluster

Le pool de nœuds de calcul du cluster d'infrastructure n'est pas supprimé

Versions : 1.14.3, 1.14.4

Symptômes : lorsque vous supprimez un pool de nœuds de calcul de la spécification CR Organization, le pool de nœuds n'est pas supprimé automatiquement. En d'autres termes, la commande kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} affiche toujours le pool de nœuds à supprimer.

# Organization CR example
apiVersion: resourcemanager.private.gdc.goog/v1alpha1
kind: Organization
...
spec:
  resourceCapacities:
    workloadServers:
      o2-standard1-96-gdc-metal: 4 # worker node pool to remove
...

Solution : Après avoir supprimé le pool de nœuds de calcul de la spécification CR Organization, supprimez manuellement le CR NodePoolClaim pour ce pool de nœuds du cluster d'administrateur racine en exécutant la commande suivante : sh kubectl delete nodepoolclaim data-plane-pool-{machine-class} -n {org-name}

Attendez que le NodePoolClaim et ses CR NodePool associés soient complètement supprimés, c'est-à-dire que la commande kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} ne génère plus le pool de nœuds de calcul.

Stockage

Échec de la suppression des buckets créés avec la commande gdcloud config set zone

Versions : 1.14.7 et ultérieures

Symptômes : Les buckets créés avec la commande gdcloud config set zone ne peuvent pas être supprimés en raison de problèmes d'autorisation, car la commande tente d'opérer dans la mauvaise zone.

Solution de contournement : Utilisez la console pour définir la zone spécifique d'un bucket ou remplacez le flag --zone par --location dans la commande gdcloud.

Déclenchement d'alertes SLO OBJ

Versions : 1.14.3, 1.14.4

Symptômes : des alertes SLO pour OBJ sont déclenchées en raison de l'erreur ErrFailedStreamingDecryptRequest dans le proxy OBJ : obj-list-object-ops-availability-slo, obj-rw-object-ops-error-rate-slo.

Solution : coupez le son de l'alerte. L'erreur est identifiée à tort comme une erreur système alors qu'elle est due à l'utilisateur qui met fin à la connexion, ce qui n'est pas pris en compte dans le SLO.

ETag vide pour S3 UploadPart

Versions : 1.14.3

Problèmes constatés : après avoir envoyé une requête UploadPart, vous obtenez un code d'état 200 Success dans le message de réponse, mais le champ ETag est vide. Cette erreur se produit lorsqu'un InternalServerError se produit en raison d'une interruption du réseau et que le code d'état n'est pas mis à jour sur 500 InternalServerError.

Solution : Réessayez la requête comme si elle avait échoué précédemment.

Échec du montage des pods en raison d'une erreur mkfs.ext4 de Trident

Versions : 1.14.3

Symptômes : après avoir tenté de monter des pods, vous constatez que tous les pods qui passent à un nœud particulier ou qui en proviennent échouent. Un message d'erreur RPC : DeadlineExceeded desc = context deadline exceeded s'affiche, indiquant que le nœud est bloqué. Lorsque ce message s'affiche, vous ne pouvez plus effectuer d'opérations Trident supplémentaires sur le nœud en question. Les volumes diffusant des données ne sont pas affectés, mais ceux qui sont déplacés vers et depuis le nœud peuvent subir une interruption.

Solution :

1. Inspectez les journaux Trident sur le nœud que le pod tente de monter et vérifiez que la file d'attente augmente. Les journaux peuvent se présenter comme suit :

   2025-01-24T00:27:22.783599667Z time="2025-01-24T00:27:22Z" level=debug msg="Attempting to acquire shared lock (NodeUnstageVolume-pvc-0f04a9c5-00fc-4c3c-9fc1-6730598f7caa); 421 position in the queue." lock=csi_node_server logLayer=csi_frontend requestID=94c8ad12-6479-4e1c-8791-118b565d6c6b requestSource=CSI workflow="node_server=unstage"
   

2. Connectez-vous au nœud et examinez le résultat de dmesg. Les journaux peuvent se présenter comme suit :

   Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
   Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
   Jan 31 02:43:47 ap-ae-bm18 kernel: device-mapper: multipath: 253:40: Failing path 65:144.
   Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
   Jan 31 02:43:47 ap-ae-bm18 kernel: device-mapper: multipath: 253:40: Failing path 65:160.
   Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
   

3. Après avoir confirmé que vous rencontrez une erreur mkfs.ext4 de Trident, redémarrez le nœud.

Trident ne parvient pas à créer un volume en raison d'une erreur existante

Versions : 1.14.3

Symptômes :

Un PVC n'est pas provisionné et affiche un événement semblable à celui-ci :

failed to create cloned volume {pvc-bab6bc52-fd37-4ead-a57b-e833e14c172a} on backend iscsi-san: volume trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a already exists

Lorsque cet événement se produit, le PVC n'est pas provisionné tant que vous n'avez pas effectué la solution de contournement.

Solution :

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

1. Notez le nom du volume interne à partir de l'événement. Par exemple, l'événement échantillon affiché dans la section Symptômes indique le nom de volume interne trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a.
2. Suivez le runbook FILE-R0105 pour accéder à ONTAP.

3. Supprimez le volume :

   volume delete trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a
   

file_block_iscsi_sessions_unhealthy alert signale un faux positif

Versions : 1.14.3

Symptômes : dans certains environnements, l'alerte file_block_iscsi_sessions_unhealthy se déclenche, indiquant qu'un ou plusieurs nœuds rencontrent des échecs iSCSI. Le contrôleur file-observability utilise un collecteur de métriques personnalisé pour suivre l'état des sessions iSCSI sur chaque nœud Kubernetes. Toutefois, dans certains cas, le collecteur de métriques ne parvient pas à analyser la sortie de la commande iscsiadm et signale zéro session iSCSI en cours d'exécution, même si iSCSI dispose de sessions opérationnelles.

Solution :

Pour vérifier qu'iSCSI ne rencontre pas de problèmes et désactiver l'alerte si elle est en fait un faux positif :

1. Sur la page "Explore" de Grafana, exécutez la requête fb_sessions_running_count{job="file-observability-backend-target.file-system"}. La requête renvoie une métrique pour chaque nœud du cluster. Si des nœuds signalent une métrique fb_sessions_running_count de 0, notez le nom du nœud.

2. Pour chaque nœud dont les métriques fb_sessions_running_count renvoient 0, exécutez les commandes suivantes :

   1. Établissez une connexion SSH avec le nœud concerné.

   2. Exécutez la commande iscsiadm -m session. Plusieurs lignes doivent s'afficher. Chaque ligne correspond à une session iSCSI en cours d'exécution. Si la commande ne renvoie rien ou si des erreurs s'affichent dans le résultat, escaladez le problème à l'équipe d'ingénieurs chargée du blocage des fichiers.

   3. Si la commande précédente a renvoyé des sessions iSCSI, vous avez confirmé que l'alerte pour ce nœud est un faux positif.

3. Lorsque vous confirmez que tous les nœuds concernés ont des sessions iSCSI saines et que l'alerte se déclenche de manière erronée, créez un silence dans AlertManager pour désactiver l'alerte file_block_iscsi_sessions_unhealthy.

L'alerte file_block_storage_disk_failure se déclenche pour les disques de rechange

Versions : 1.14.3

Symptômes : dans certains environnements, l'alerte file_block_storage_disk_failure se déclenche, indiquant qu'un ou plusieurs disques dans ONTAP sont défectueux. Le contrôleur file-observability utilise un collecteur de métriques personnalisé pour suivre l'état de chaque disque dans ONTAP, mais dans les versions antérieures de GDC, le collecteur ne considère pas un disque de secours comme étant en bon état et déclenche une alerte pour le disque de secours.

Solution :

Pour vérifier que les disques sont des disques de secours et désactiver l'alerte pour le disque, procédez comme suit :

1. Sur la page "Explore" de Grafana, exécutez la requête disks_labels_healthy{job="file-observability-backend-target.file-system"}. La requête renverra une métrique pour chaque disque dans ONTAP. Si des disques affichent une métrique de 0 (non opérationnel), notez leur nom.

2. Pour chaque disque dont les métriques disks_labels_healthy renvoient 0, exécutez les commandes suivantes :

   1. Connectez-vous au cluster ONTAP via SSH et exécutez la commande disk show -disk <disk-name> -fields state en utilisant le nom de disque collecté à partir de la requête de métrique.

   2. Vérifiez que le résultat de la commande indique que l'état du disque est present ou spare. Si le disque est dans un état autre que present ou spare, escaladez le problème à l'équipe d'ingénierie chargée du blocage des fichiers.

   3. Si le disque en question indique present ou spare, nous pouvons confirmer que l'alerte ne devrait pas se déclencher pour ce disque. Créez un silence dans AlertManager pour désactiver l'alerte file_block_storage_disk_failure avec le libellé disk_name défini sur le nom du disque.

3. Une fois les silences créés pour tous les disques de rechange, accédez à Grafana pour vérifier que les alertes ne sont plus déclenchées.

L'alerte file_block_storage_node_peer_connection_unhealthy se déclenche une fois la connexion rétablie

Versions : 1.14.3

Symptômes : dans certains environnements, l'alerte file_block_storage_node_peer_connection_unhealthy se déclenche, indiquant qu'une ou plusieurs connexions entre les nœuds ONTAP échouent. Le contrôleur file-observability utilise un collecteur de métriques personnalisé pour suivre l'état de ces connexions. Un problème connu fait que cette alerte continue de se déclencher même après le rétablissement de la connexion ayant échoué.

Solution :

Pour vérifier que les connexions entre les nœuds sont opérationnelles et désactiver l'alerte pour les nœuds :

1. Sur la page "Explore" de Grafana, exécutez la requête storage_node_peer_connections{job="file-observability-backend-target.file-system"}. La requête renvoie une métrique pour chaque connexion entre les nœuds de stockage du cluster. Si des connexions signalent une métrique storage_node_peer_connections de 0, notez les libellés source_node, destination_ip et storage_cluster_name de la métrique.

2. Pour chaque métrique storage_node_peer_connections renvoyant 0, exécutez les commandes suivantes :

   1. Établissez une connexion SSH avec le cluster de stockage ONTAP à partir du libellé storage_cluster_name.

   2. Exécutez la commande suivante sur le cluster ONTAP en utilisant les valeurs des libellés source_node et destination_ip :

   ping -node <node-name> -destination <destination-ip> -verbose -show-detail
   

   Si la commande ping échoue, transmettez le problème à l'équipe d'ingénierie chargée du blocage des fichiers. Si la commande ping réussit, cela confirme que les connexions de nœuds sont opérationnelles et que l'alerte se déclenche de manière erronée.

   1. Créez un silence dans AlertManager pour désactiver l'alerte file_block_storage_node_peer_connection_unhealthy avec les libellés source_node et destination_ip définis sur le nœud source et l'adresse IP de destination à partir de la métrique.

3. Une fois les silences créés pour tous les nœuds opérationnels, accédez à Grafana pour vérifier que les alertes ne sont plus déclenchées.

L'alerte file_block_nodes_not_reachable se déclenche une fois la connexion rétablie

Versions : 1.14.3

Symptômes : dans certains environnements, l'alerte file_block_nodes_not_reachable se déclenche, indiquant qu'une ou plusieurs connexions des services IPsec sur les nœuds Kubernetes à ONTAP échouent. Le contrôleur file-observability utilise un collecteur de métriques personnalisé pour suivre l'état de ces connexions. Un problème connu fait que cette alerte continue de se déclencher même après le rétablissement de la connexion ayant échoué.

Solution :

Pour vérifier que les connexions sur les nœuds sont opérationnelles et désactiver l'alerte pour les nœuds :

1. Sur la page "Explore" de Grafana, exécutez la requête fb_all_nodes_reachable{job="file-observability-backend-target.file-system"}. La requête renvoie une métrique pour chaque nœud du cluster. Si des nœuds signalent une métrique fb_all_nodes_reachable de 0, notez le nom du nœud.

2. Pour chaque nœud dont les métriques fb_all_nodes_reachable renvoient 0, exécutez les commandes suivantes :

   1. Établissez une connexion SSH avec le nœud concerné.

   2. Exécutez la commande suivante :

      journalctl -u strongswan | grep "sending packet" | sed "s/\[/ /g" | sed "s/\]/ /g" | awk '{ print $14 }' | sort -n | uniq | awk '{print "ping -c 5 " $1}' | sh
      

      La commande tentera d'envoyer un ping à ONTAP à l'aide de toutes les connexions IPsec. Si des pings de la commande échouent, transférez le problème à l'équipe d'ingénieurs chargée du blocage des fichiers. Si les commandes ping réussissent, cela confirme que les connexions de nœuds sont opérationnelles et que l'alerte se déclenche de manière erronée.

   3. Si tous les pings de la commande réussissent, cela signifie que les connexions sur le nœud sont saines et que l'alerte se déclenche de manière erronée. Créez un silence dans AlertManager pour désactiver l'alerte file_block_nodes_not_reachable avec le libellé node_name défini sur le nom du nœud.

3. Une fois les silences créés pour tous les nœuds opérationnels, accédez à Grafana pour vérifier que les alertes ne sont plus déclenchées.

L'alerte file_block_storage_high_node_total_latency se déclenche en cas de charges de travail importantes.

Versions : 1.14.3

Symptômes : L'alerte file_block_storage_high_node_total_latency peut se déclencher dans certains environnements en raison de charges de travail importantes sur les nœuds de stockage. Cette alerte persiste jusqu'à ce que ces charges de travail soient entièrement traitées. Même lorsque les performances de lecture et d'écriture sur les volumes sont rapides, les nœuds de stockage peuvent toujours signaler une latence élevée pour des opérations de bloc spécifiques.

Solution :

Pour vérifier que les latences de volume sont normales et désactiver l'alerte de latence du nœud de stockage, procédez comme suit :

1. Vérifiez les alertes de latence des volumes :

   1. Dans Grafana, vérifiez que les alertes file_block_storage_high_volume_write_latency et file_block_storage_high_volume_read_latency ne sont pas déclenchées et qu'elles indiquent des temps de latence optimaux pour les volumes.

2. Transmettre la demande si la latence du volume est élevée :

   1. Si les alertes de lecture ou d'écriture de volume sont déclenchées, cela indique une latence élevée dans l'ensemble du système de stockage. Faites remonter ce problème à l'équipe d'ingénierie chargée du blocage des fichiers.

3. Mettre en sourdine l'alerte de latence des nœuds (si les volumes sont sains) :

   1. Si les alertes d'écriture et de lecture de volume sont saines, l'alerte de latence de nœud est probablement un faux positif.

   2. Créez un silence dans AlertManager pour l'alerte file_block_storage_high_node_total_latency.

   3. Après avoir créé le silence, accédez à Grafana pour vérifier que l'alerte ne se déclenche plus.

Mise à niveau de nœud bloquée

Versions : 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

Symptômes : ce blocage se produit lorsqu'un LUN (Logical Unit Number) devient en lecture seule, souvent en raison de problèmes liés aux instantanés. Dans ce cas, le nœud est mis en quarantaine pour déplacer le pod concerné vers un autre nœud. Comme le processus de mise à niveau des nœuds comporte une vérification préalable pour s'assurer que les nœuds ne sont pas mis en quarantaine, cet état empêche la mise à niveau de se poursuivre.

Solution : Désactivez manuellement le sous-composant file-read-only-lun-cleanup avant de lancer la procédure de mise à niveau :

1. Identifiez chaque organisation concernée.

2. Appliquez un SubcomponentOverride pour chaque organisation de l'environnement.

   apiVersion: lcm.private.gdc.goog/v1
   kind: SubcomponentOverride
   metadata:
     name: file-read-only-lun-cleanup
     namespace: ORG_NAMESPACE
   spec:
     subComponentRef: "file-read-only-lun-cleanup"
     disable: true
   

3. Vérifiez qu'aucun nœud des organisations concernées n'est mis en quarantaine :

   1. Répertoriez les nœuds de l'organisation :

      kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes
      

      Le résultat ressemble à ce qui suit :

      NAME                STATUS                     ROLES           AGE   VERSION
      admin-node0-zone1   Ready,SchedulingDisabled   control-plane   14h   v1.30.8-gke.200
      admin-node1-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
      admin-node2-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
      

      Notez les noms des nœuds dont l'état est SchedulingDisabled. Dans cet exemple de résultat, le nœud mis en quarantaine est admin-node0-zone1.

   2. Décordonnez les nœuds qui ont renvoyé l'état SchedulingDisabled à l'étape précédente :

      kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG uncordon NODE_NAME
      

   3. Vérifiez que tous les nœuds sont prêts :

      kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes
      

      Le résultat ressemble à ce qui suit :

      NAME                STATUS                     ROLES           AGE   VERSION
      admin-node0-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
      admin-node1-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
      admin-node2-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
      

L'alerte file_block_zombie_luns_present se déclenche une fois les erreurs multipath résolues.

Versions : 1.14.3 et ultérieures

Problèmes constatés : l'alerte file_block_zombie_luns_present peut se déclencher dans certains environnements, car le contrôleur file-observability ne parvient pas à analyser la sortie de la commande multipath -ll. Dans ce cas, l'alerte concernant les LUN zombies est déclenchée en permanence, même lorsque le service multipath est opérationnel sur tous les nœuds.

Solution :

Pour vérifier que les services multipath fonctionnent correctement sur les nœuds concernés, procédez comme suit :

1. Sur la page "Explore" de Grafana, exécutez la requête zombie_lun_exists{job="file-observability-backend-target.file-system"}. La requête renvoie une métrique pour chaque nœud du cluster. Si des nœuds signalent une métrique zombie_lun_exists de 1, notez le nom du nœud.

2. Pour chaque nœud dont les métriques zombie_lun_exists renvoient 1, exécutez les commandes suivantes :

   1. Établissez une connexion SSH avec le nœud concerné.

   2. Exécutez la commande suivante :

      multipath -ll
      

      La commande renvoie des informations sur tous les périphériques de bloc gérés par le service multipath. Vérifiez qu'aucun des appareils de stockage en mode bloc ne contient la chaîne failed undef unknown ou la chaîne failed faulty running dans son état.

   3. Si des appareils affichent l'état failed faulty running, suivez le runbook FILE-R0020 pour résoudre le problème des LUN zombies.

   4. Si des appareils affichent l'état failed undef unknown, suivez le runbook FILE-R0021 pour résoudre le problème des LUN super zombies.

3. Coupez le son des alertes de LUN zombie si les nœuds sont opérationnels :

   1. Si aucun périphérique de bloc non valide n'est trouvé sur l'un des nœuds, l'alerte de LUN zombie est un faux positif.

   2. Créez un silence dans AlertManager pour l'alerte file_block_zombie_luns_present.

   3. Après avoir créé le silence, accédez à ServiceNow pour vérifier que l'alerte ne se déclenche plus.

Impossible de supprimer un bucket vide depuis la console

Versions : 1.14.4 et versions ultérieures

Symptômes : Dans la console GDC, vous ne pouvez pas supprimer un bucket vide. Le bucket peut contenir des marqueurs de suppression et potentiellement d'autres versions d'objets lorsque la gestion des versions des objets est activée avec des règles de conservation. Un message d'erreur semblable à celui-ci pourrait apparaître :

can't delete bucket containing empty objects: Delete the bucket inside to delete
the object

Solution de contournement : Utilisez la commande gdcloud storage rm -a pour supprimer les objets, y compris les marqueurs de suppression, afin de rendre le bucket supprimable.

Artifact Registry système

Les tâches de réplication Harbor sont bloquées

Versions : 1.14.3

Problèmes constatés : les jobs de réplication des artefacts Harbor sont bloqués. Ce problème empêche la distribution d'artefacts à l'organisation et la création d'organisations.

Solution de contournement : pour résoudre ce problème, suivez les étapes du runbook SAR-R1010.

L'état d'erreur transitoire n'est pas effacé lors de la réconciliation de la ressource personnalisée du compte robot Harbor

Versions : 1.14.3

Problèmes constatés : une alerte CustomResourceErrorStatusAlert libellée kind=HarborRobotAccount et code=SAR2002 se déclenche de manière erronée. Par exemple, l'alerte incorrecte présente le champ message défini sur "Erreur lors de la récupération du robot : échec de la liste des robots : 503 Service Unavailable".

Solution de contournement : Demandez à l'opérateur d'infrastructure (IO) de vérifier si l'alerte correspond à un véritable problème ou à une fausse alerte, puis de la désactiver s'il s'agit d'une fausse alerte, en suivant les instructions ci-dessous.

Lorsqu'une alerte est déclenchée, suivez le runbook SAR-E2002 pour identifier et résoudre la cause sous-jacente de l'alerte.

En raison de ce problème connu, même si le runbook résout correctement la cause sous-jacente, l'alerte peut continuer à se déclencher de manière erronée. Continuez à vérifier l'état des erreurs de l'objet de ressource personnalisée (CR) HarborRobotAccount (HRD) cible pour lequel une alerte est émise :

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

   export KUBECONFIG=KUBECONFIG
   export HRD_NAME=HRD_NAME
   export HRD_NAMESPACE=HRD_NAMESPACE
   

   Remplacez les éléments suivants :

   • KUBECONFIG : chemin d'accès au fichier kubeconfig.
   • HRD_NAME : nom de la ressource personnalisée HarborRobotAccount cible.
   • HRD_NAMESPACE : espace de noms contenant la ressource personnalisée HarborRobotAccount cible.

2. Vérifiez l'état d'erreur du CR HarborRobotAccount cible :

   kubectl get harborrobotaccount ${HRD_NAME?} -n ${HRD_NAMESPACE?} -ojsonpath='{.status.errorStatus} {"\n"}'
   

Si la valeur lastUpdateTime indique que le champ errorStatus a été mis à jour il y a plus de 30 minutes, l'alerte est une fausse alerte. Pour atténuer la fausse alerte, mettez-la en sourdine dans l'instance GDC isolée en suivant le runbook MON-R2009.

Fausse alerte SAR-R0003

Versions : 1.14.3 et ultérieures

Problèmes constatés : une alerte avec le code SAR-R0003, l'OC SAR et le niveau de gravité critical se déclenche de manière erronée.

Solution : Suivez le runbook MON-R2009 pour couper le son de l'alerte.

Système de gestion des demandes

Le serveur MID ServiceNow ne démarre pas correctement

Versions : 1.14.3

Corrigé : 1.14.4

Symptômes : le serveur MID ServiceNow, qui s'intègre à Splunk, ne parvient pas à s'enregistrer auprès de ServiceNow au démarrage en raison d'une incompatibilité de version.

Solution :

1. Mettez en pause le sous-composant ts-mid-server.

KUBECONFIG=ROOT_ADMIN_KUBECONFIG kubectl annotate subcomponent ts-mid-server -n gdchservices lcm.private.gdc.goog/paused=true

1. Remplacez la chaîne de version du serveur MID.

KUBECONFIG=GDCHSERVICES_ADMIN_KUBECONFIG kubectl set env statefulset/midserver-set -n support MID_CONFIG_mid__pinned__version=washingtondc-12-20-2023__patch5-06-21_06-26-2024_1335

Mettre à niveau

L'annotation du cluster de services partagés n'est pas mise à jour après une mise à niveau réussie du cluster

Versions : 1.14.4

Symptômes : les CR des clusters de périmètre et de services partagés pour clusters.baremetal.cluster.gke.io reflètent la version GKE correcte après la mise à niveau. Les CR clusters.cluster.gdc.goog affichent toujours la version GKE précédente.

Solution de contournement : Mettez à jour l'annotation upgrade.gdc.goog/version dans clusters.baremetal.cluster.gke.io avec le nouveau nom UserClusterMetadata correspondant à la version mise à niveau de GKE.

La mise à niveau du nœud d'administrateur de l'organisation est bloquée

Versions : 1.14.6

Corrigé : 1.14.7

Symptômes : le processus de mise à niveau des nœuds pour le plan de contrôle de l'administrateur de l'organisation gdchservices est bloqué. La mise à niveau du nœud échoue, car il est impossible d'établir une connexion SSH au nœud, ce qui entraîne une erreur Connection timed out.

La mise à niveau du module complémentaire est bloquée

Versions : 1.14.6

Corrigé : 1.14.7

Symptômes : la mise à niveau du module complémentaire pour le cluster d'administrateur racine est bloquée lors de la mise à niveau d'une version 1.14.x précédente vers la version 1.14.6. Un message d'état peut indiquer que la mise à niveau a dépassé le délai prévu :

message: 'UPG1401: addon upgrade expected to finish within 2h0m0s but hasn''t
      after 8h8m24.00395866s, last message was: Addon upgrade for root-admin cluster
      in progress'

Solution : Mettez à jour manuellement le spec.addOnSetTemplateRef de la ressource addonset root-admin pour qu'il pointe vers le bon modèle pour la nouvelle version.

Échec du rapport d'assistance

Versions : 1.14.3, 1.14.4, 1.14.5, 1.14.6

Corrigé : 1.14.7

Symptômes : la commande gdcloud resource-support get-report échoue lorsqu'elle est exécutée pour un cluster d'utilisateur en raison d'un problème d'autorisations.

Le démarrage de la VM peut être bloqué après la mise à niveau du nœud OS.

Versions : 1.14.6

Problèmes constatés : lors de la mise à niveau de la version 1.14.3 vers la version 1.14.6, les machines virtuelles des clusters de périmètre ou de services partagés ne parviennent pas à démarrer et deviennent inaccessibles après une mise à niveau de l'OS.

Par exemple, la commande suivante peut confirmer le problème :

kubectl --kubeconfig CP_KUBECONFIG logs -n VM_NAMESPACE VIRT_LAUNCHER_POD_NAME -c guest-console-log

Le résultat du journal de la console de la VM affiche un message d'erreur du noyau semblable à ce qui suit :

[    2.005806] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    2.008100] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64 #1
[    2.011153] Hardware name: KubeVirt None/RHEL, BIOS 1.14.0-2 04/01/2014
[    2.013401] Call Trace:
[    2.015365]  dump_stack+0x41/0x60
[    2.016641]  panic+0xe7/0x2ac
[    2.017864]  mount_block_root+0x2be/0x2e6
[    2.019176]  ? do_early_param+0x95/0x95
[    2.020287]  prepare_namespace+0x135/0x16b
[    2.021476]  kernel_init_freeable+0x210/0x23a
[    2.022724]  ? rest_init+0xaa/0xaa
[    2.023721]  kernel_init+0xa/0x110
[    2.024698]  ret_from_fork+0x1f/0x40
[    2.025913] Kernel Offset: 0x33c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    2.028706] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---

Solution de contournement : procédez comme suit pour contourner le problème :

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

   export MP_KUBECONFIG=MANAGEMENT_API_KUBECONFIG
   export CP_KUBECONFIG=ORG_INFRA_KUBECONFIG
   export VM_NAMESPACE=VM_NAMESPACE
   export VM_NAME=FAILED_VM_NAME
   

2. Arrêtez la VM en échec :

   kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE \
       $VM_NAME --type='merge' -p='{"spec": {"runningState": "Stopped"}}'
   

3. Ouvrez l'éditeur pour dissocier le disque de démarrage de la VM ayant échoué :

   kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE $VM_NAME
   

4. Remplacez le disque de démarrage par un nom d'espace réservé dans la spécification de la VM :

   # Several lines of code are omitted here.
   spec:
     disks:
     - boot: true
       virtualMachineDiskRef:
         # This is a random placeholder name you put here. Doesn't need to exist
         name: VM_DISK_PLACEHOLDER_NAME
   

5. Créez un secret de script de démarrage :

   cat <<'EOF' > script
   #!/bin/bash
   username="newuser"
   password="Lime+blaze8legend"
   sudo useradd -m -s /bin/bash "$username"
   echo "$username:$password" | sudo chpasswd
   sudo usermod -aG sudo "$username"
   EOF
   
   kubectl --kubeconfig=$MP_KUBECONFIG create secret generic configure-password -n $VM_NAMESPACE --from-file=script
   

6. Créez une VM d'assistance :

   1. Obtenez l'image de VM pour le disque de démarrage de la VM. L'image ne doit pas appartenir à la même famille de système d'exploitation que le disque de démarrage du nœud de VM problématique. Utilisez donc grep pour trouver l'image Ubuntu :

      # find the latest ubuntu-20.04 OS version
      UBUNTU_OS_VERSION=$(kubectl --kubeconfig $MP_KUBECONFIG get vmimage -A --sort-by=.metadata.creationTimestamp | grep ubuntu-20.04 | tail -n 1 | awk '{print $2}')
      

   2. Créez le disque de démarrage et la VM. Créez un disque de démarrage et une VM avec un disque secondaire associé et un script de démarrage pour accéder à la console :

      kubectl --kubeconfig $MP_KUBECONFIG apply -n $VM_NAMESPACE -f - <<EOF
      apiVersion: virtualmachine.gdc.goog/v1
      kind: VirtualMachineDisk
      metadata:
        name: HELPER_VM_BOOT_DISK_NAME
      spec:
        source:
          image:
            name: UBUNTU_OS_VERSION
            namespace: vm-system
        size: 20Gi
      ---
      apiVersion: virtualmachine.gdc.goog/v1
      kind: VirtualMachine
      metadata:
        name: HELPER_VM_NAME
      spec:
        compute:
          virtualMachineType: n3-standard-2-gdc
        disks:
        - virtualMachineDiskRef:
            name: HELPER_VM_NAME-disk
          boot: true
          autoDelete: true
        - virtualMachineDiskRef:
            name: PROBLEM_VM_BOOT_DISK
          autoDelete: false
        startupScripts:
        - scriptSecretRef:
            name: configure-password
          name: configure-password
      EOF
      

   3. Vérifiez que la VM d'assistance est en cours d'exécution :

      kubectl --kubeconfig $MP_KUBECONFIG get gvm -n ${VM_NAMESPACE} HELPER_VM_NAME
      

7. Consolez la VM d'assistance et régénérez l'initramfs :

   1. Console de la VM d'assistance :

      kubectl virt console HELPER_VM_NAME  -n ${VM_NAMESPACE} --kubeconfig=$CP_KUBECONFIG
      

   2. Utilisez les identifiants suivants :

      username="newuser"

      password="Lime+blaze8legend"

   3. Installez les partitions du disque associé :

      sudo mkdir /mnt/kernelpanic/
      sudo mount /dev/mapper/rocky-rl--root /mnt/kernelpanic/
      sudo mount /dev/mapper/rocky-rl--root /mnt/kernelpanic/
      sudo mount /dev/sdb2 /mnt/kernelpanic/boot/
      sudo mount /dev/sdb1 /mnt/kernelpanic/boot/efi/
      sudo mount /dev/rocky/rl-home /mnt/kernelpanic/home/
      sudo mount /dev/rocky/rl-var /mnt/kernelpanic/var/
      sudo mount /dev/rocky/rl-var_tmp /mnt/kernelpanic/var/tmp/
      sudo mount /dev/rocky/rl-var_log /mnt/kernelpanic/var/log/
      sudo mount /dev/rocky/rl-var_log_audit /mnt/kernelpanic/var/log/audit/
      sudo mount /dev/rocky/rl-tmp /mnt/kernelpanic/tmp/
      
      sudo mount -t sysfs sysfs /mnt/kernelpanic/sys/
      sudo mount -t proc procfs /mnt/kernelpanic/proc/
      sudo mount -t devtmpfs devtmpfs /mnt/kernelpanic/dev/
      sudo mount -t devpts devpts /mnt/kernelpanic/dev/pts/
      sudo mount -o bind /dev/pts/ /mnt/kernelpanic/dev/pts/
      

   4. Établissez une connexion chroot au point d'installation et régénérez l'initramfs :

      sudo chroot /mnt/kernelpanic/
      dracut --regenerate-all --force
      

   5. Vérifiez que le nouvel initramfs pour la nouvelle version du noyau 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64 est généré :

      ls /boot/initramfs-* -l
      

      La sortie ressemble à ceci :

      -rw-------. 1 root root 184937778 Feb  5  2025 /boot/initramfs-0-rescue-e4d67258cb64499f98609307ac4a93e8.img
      -rw-------. 1 root root 119867729 Aug  7 17:35 /boot/initramfs-4.18.0-553.16.1.el8_6.ciqfips.0.6.1.x86_64.img
      -rw-------. 1 root root  35321114 Aug  7 17:36 /boot/initramfs-4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64.img
      

8. Arrêtez la VM d'assistance :

   kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE HELPER_VM_NAME --type='merge' -p='{"spec": {"runningState": "Stopped"}}'
   

9. Dissociez le disque de la VM d'assistance :

   1. Ouvrez la spécification de la VM d'assistance dans un éditeur :

      kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE HELPER_VM_NAME
      

   2. Supprimez le code suivant du fichier YAML :

      - virtualMachineDiskRef:
          name: PROBLEM_VM_BOOT_DISK
        autoDelete: false
      

10. Réassociez le disque de démarrage à la VM défaillante :

    1. Ouvrez la spécification de la VM ayant échoué dans un éditeur :

       kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE $VM_NAME
       

    2. Mettez à jour la spécification comme suit :

       # Several lines of code are omitted here.
       spec:
         disks:
         - boot: true
           virtualMachineDiskRef:
             name: PROBLEM_VM_BOOT_DISK
       

11. Démarrez la VM en échec :

    kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE $VM_NAME --type='merge' -p='{"spec": {"runningState": "Running"}}'
    

12. Vérifiez que la mise à niveau est corrigée :

    1. Vérifiez que la ressource personnalisée Node pour cette VM affiche Ready et utilise la version de noyau plus récente 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64 :

       kubectl --kubeconfig=$CP_KUBECONFIG get node NODE_NAME -owide
       

       Le résultat ressemble à ce qui suit :

       NAME          STATUS   ROLES           AGE    VERSION            INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                           KERNEL-VERSION                               CONTAINER-RUNTIME
       vm-45b03137   Ready    worker          139d   v1.30.12-gke.300   10.204.0.7    <none>        Rocky Linux 8.6 (Green Obsidian)   4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64   containerd://1.6.38-gke.0
       

    2. Vérifiez la version du noyau après avoir établi une connexion SSH à la VM :

       uname -a
       

       Le résultat doit afficher la nouvelle version du noyau 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64.

L'ingesteur n'est toujours pas opérationnel et n'est pas automatiquement oublié après la mise à niveau

Versions : 1.14.x

Problèmes constatés : le sous-composant log-infra n'est pas opérationnel après la mise à niveau. Pour vérifier, exécutez : none kubectl --kubeconfig ${KUBECONFIG:?} get subcomponent -n ${CLUSTER_NAMESPACE:?} log-infra Pour vérifier l'état d'un sous-composant, vous devez utiliser le fichier kubeconfig du cluster parent pour KUBECONFIG et l'espace de noms du cluster actuel pour CLUSTER_NAMESPACE. La commande renvoie l'ÉTAT du sous-composant. Si l'ÉTAT n'est pas ReconciliationCompleted, cela signifie que le sous-composant n'est pas sain dans ce cluster.

Certains pods Loki du cluster ne sont pas en bon état. Pour lister tous les pods Loki, exécutez la commande suivante : none kubectl --kubeconfig ${KUBECONFIG:?} get pods -n obs-system | awk 'NR==1 || /loki/' Cette commande affiche tous les pods Loki, y compris leurs colonnes STATUS et READY. Un pod est considéré comme non opérationnel si son ÉTAT n'est pas Running ou si certains de ses conteneurs ne sont pas prêts. La colonne READY, au format a/b, indique le nombre de conteneurs prêts a sur le total b. Un pod est opérationnel lorsque a et b sont égaux.

Vérifiez les journaux des pods Loki défectueux : none kubectl --kubeconfig ${KUBECONFIG:?} logs <pod-name> -n obs-system

Voici un exemple de journaux de sortie de pods non opérationnels :

level=warn ts=2024-12-21T05:01:42.331048596Z caller=ingester.go:385 component=ingester msg="autoforget have seen 2 unhealthy ingesters out of 3, network may be partitioned, skip forgeting ingesters this round"
level=warn ts=2024-12-21T05:01:45.928939929Z caller=lifecycler.go:291 component=ingester msg="found an existing instance(s) with a problem in the ring, this instance cannot become ready until this problem is resolved. The /ring http endpoint on the distributor (or single binary) provides visibility into the ring." ring=ingester err="instance 10.99.196.153:9095 past heartbeat timeout"

Solution de contournement : Pour supprimer un ingester défectueux de l'anneau Loki, consultez le runbook AL-R0031.

Vertex AI

Les demandes de traduction peuvent générer le code d'erreur RESOURCE_EXHAUSTED

Versions : 1.14.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.14.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: SHARED_SERVICE_CLUSTER_NAMESPACE
   spec:
     subComponentRef: "vai-translation"
     backend:
       operableParameters:
         enableRAG: true
   

   Remplacez SHARED_SERVICE_CLUSTER_NAMESPACE par l'espace de noms du cluster de services partagés.

2. Appliquez la ressource personnalisée SubcomponentOverride au cluster d'administration de l'organisation :

   kubectl --kubeconfig ORG_MGMT_KUBECONFIG apply -f vai-translation.yaml
   

   Remplacez ORG_MGMT_KUBECONFIG par le chemin d'accès au fichier kubeconfig de gestion dans le cluster d'administrateur de l'organisation.

Le pod et le service de l'interface de traduction ou d'OCR ne parviennent pas à s'initialiser.

Versions : 1.11.x, 1.12.x, 1.13.x, 1.14.x

Symptômes : lors des mises à niveau, le cluster de base de données est recréé, ce qui entraîne l'obsolescence et la désynchronisation du secret ODS secret-store sur le cluster de services partagés. C'est pourquoi l'initialisation du pod et du service de l'interface de traduction ou d'OCR échoue.

Solution :

Supprimez le secret dans le cluster de service partagé :

kubectl --kubeconfig SHARED_SERVICEG_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n VAI_API_NAMESPACE

Remplacez SHARED_SERVICE_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig dans le cluster de services partagés.

Si le service problématique est Translation, remplacez VAI_API_NAMESPACE par "g-vai-translation-sie". Si le service problématique est OCR, remplacez VAI_API_NAMESPACE par "g-vai-ocr-sie".

Un contrôleur recrée automatiquement le secret et le synchronise à nouveau avec le cluster de bases de données.

Vertex AI Search

Composants de recherche bloqués à l'état "Reconciling"

Versions : 1.14.6

Problèmes constatés : les sous-composants vaisearch-conversation et vaisearch-frontend sont bloqués dans un état Reconciling si aucune ressource personnalisée SearchConfig n'est créée dans l'organisation.

Solution de contournement : vous pouvez ignorer le problème. Une fois la ressource personnalisée SearchConfig créée, les sous-composants doivent terminer leur réconciliation.

Serveur

La rotation des identifiants du BIOS est bloquée à l'étape "Réinitialisation demandée"

Versions : 1.14.4

Symptômes : la rotation des identifiants du BIOS reste bloquée à l'état "Réinitialisation demandée". Pour le vérifier, consultez l'annotation gdch.cluster.gke.io/rotation-status pour le secret des identifiants BIOS du serveur :

kubectl get secret bios-credentials-SERVER_NAME -n gpc-system -o jsonpath='{.metadata.annotations.gdch\.cluster\.gke\.io/rotation-status}'

Remplacez SERVER_NAME par le nom du serveur. Si la rotation est bloquée, le résultat de la commande est "reset-requested".

Solution : Pour terminer la rotation des identifiants du BIOS, suivez le runbook SERV-R0018.

Impossible de provisionner les serveurs précédemment installés

Versions : 1.14.6

Symptômes : les serveurs ne parviennent pas à être provisionnés après avoir été déprovisionnés et reprovisionnés, en particulier en raison de problèmes liés à la gestion des clés iLO (Integrated Lights-Out) et HSM (Hardware Security Module). Les serveurs, qui faisaient auparavant partie d'une organisation désactivée, rencontrent des erreurs lors du provisionnement d'images, ce qui indique une incapacité à trouver un appareil approprié, souvent en raison de disques verrouillés à partir d'anciennes clés ou de clés supprimées. Un message d'erreur semblable à celui-ci peut s'afficher :

No suitable device was found for deployment - root device hints were not
provided and all found block devices are smaller than 4294967296B

Solution de contournement : Supprimez et réinstallez les serveurs concernés pour qu'ils passent à l'état "Provisionné". Pour en savoir plus, consultez les runbooks SERV-R0020 et SERV-R0021.

Machines virtuelles

Échec de l'importation d'image

Versions : 1.14.4. 1.14.5

Corrigé : 1.14.6

Symptômes : l'importation d'une image à l'aide de la commande gdcloud compute images import échoue avec une erreur Unauthorized en raison de délais d'expiration de session.

Solution de contournement : Utilisez l'API KRM pour l'importation d'images BYOI au lieu de la CLI gdcloud.

L'importation d'images KRM prend beaucoup de temps

Versions : 1.14.6 et versions ultérieures

Symptômes : l'importation d'une image à l'aide de l'API KRM prend beaucoup de temps. La ressource VirtualMachineImageImport reste dans un état TranslationJobInProgress pendant une période prolongée, ce qui indique que la phase de traduction ne se termine pas comme prévu. Le pod image-translation passe à l'état CrashLoopBackOff.

Solution :

1. Réessayez l'importation en créant une ressource VirtualMachineImageImport avec un autre nom.
2. Surveillez l'état VirtualMachineImageImport en vérifiant régulièrement la ressource jusqu'à ce que son état passe à WaitingForTranslationJob. Pour en savoir plus, consultez le runbook VMM R0007.