Problèmes connus de Google Distributed Cloud sous air gap 1.12.x
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Le cluster de stockage pour la sauvegarde de volumes utilise le serveur DNS externe au lieu du redirecteur, ce qui empêche la sauvegarde de volumes de résoudre les points de terminaison de stockage d'objets au niveau de l'organisation. Dans la version 1.12, le trafic de sauvegarde nécessite de nouvelles routes vers chaque organisation.
Solution :
Les IO doivent mettre à jour le cluster de stockage pour activer la résolution DNS au niveau de l'organisation et créer un itinéraire depuis les interfaces logiques (LIF) de réplication vers les points de terminaison de stockage d'objets dans chaque organisation. Copiez et collez les commandes suivantes à partir du programme d'amorçage.
Définissez la variable d'environnement KUBECONFIG :
L'extraction de la passerelle Ingress de l'administrateur de l'organisation à partir des nœuds ONTAP échoue, car aucune route n'existe entre le sous-réseau de sauvegarde et les plans de contrôle de l'organisation.
Solution :
Les IO doivent mettre à jour le cluster de stockage pour activer la résolution DNS au niveau de l'organisation et créer un itinéraire depuis les interfaces logiques (LIF) de réplication vers les points de terminaison de stockage d'objets dans chaque organisation. Copiez et collez les commandes suivantes à partir du programme d'amorçage.
Définissez la variable d'environnement KUBECONFIG :
Si le dépôt de sauvegarde ne présente aucun état d'erreur, mais qu'une alerte est déclenchée, il est possible que la métrique d'alerte pour le dépôt soit déclenchée par erreur. Il s'agit d'un problème connu dans la version 1.12.0, qui a été résolu dans la version 1.12.4. Ce problème est dû au fait que le dépôt de sauvegarde tente périodiquement de se connecter au stockage d'objets pour effectuer une vérification de l'état'état et passe à l'état "Non opérationnel" en cas d'échec de la connexion. Toutefois, si le dépôt de sauvegarde est récupéré, la métrique indiquant son état ne repassera pas correctement à l'état précédent, ce qui entraînera le blocage de l'alerte dans un état de déclenchement indéfini.
Pour résoudre ce problème, vous pouvez supprimer et recréer manuellement le dépôt de sauvegarde afin de réinitialiser sa métrique d'état. Suivez la procédure du runbook BACK-R0003 pour recréer le dépôt de sauvegarde.
Message d'erreur : bil-storage-system-cluster - Reconciliation error: E0121- rollback chart: no Job with the name "billing-storage-system-init-job-628" found
Le sous-composant bil-storage-system-cluster ne parvient pas à effectuer la réconciliation en raison de tâches obsolètes. billing-storage-system-init-job-628 et billing-storage-system-init-job-629 restent après une exécution réussie.
Les pods Grafana des espaces de noms anthos-identity-service-obs-system et platform-obs-obs-system sont bloqués à l'état Init en raison d'erreurs d'installation de volume. Le message d'erreur dans les journaux kubelet indique un problème d'attachement multiple. Ce problème est dû à un bug dans Trident, qui ne parvient pas à identifier et à valider correctement l'appareil sous-jacent pour les mappages LUKS, ce qui entraîne une erreur d'attachement multiple.
Solution :
Recherchez un champ "deletionTimestamp" dans la revendication de volume persistant. S'il n'y a pas de deletionTimestamp (migration de pod), procédez comme suit :
Consultez VolumeAttachment pour PVC afin d'identifier l'emplacement actuel du volume.
Mettez hors service les Nodes du cluster qui ne correspondent pas à cette valeur.
Supprimez le Pod défaillant. Il devrait ainsi migrer vers le Node d'origine.
Après vérification, s'il existe un champ "deletionTimestamp" (suppression du volume), procédez comme suit :
Consultez VolumeAttachment pour PVC afin d'identifier l'emplacement actuel du volume.
Sur le Node, affichez le contenu de son fichier de suivi :
cat/var/lib/trident/tracking/PVC_NAME.json
Vérifiez que l'appareil LUKS trouvé dans le champ devicePath de la sortie du fichier de suivi est bien fermé. Ce chemin d'accès ne doit pas déjà exister :
statDEVICE_PATH
Vérifiez si le numéro de série est actuellement associé à un appareil multipath.
Copiez la valeur du champ iscsiLunSerial du fichier de suivi.
Convertissez cette valeur en valeur hexadécimale attendue :
echo'iISCSILUNSERIAL>'|xxd-l12-ps
Avec cette nouvelle valeur, vérifiez si l'entrée multipath existe toujours :
multipath-ll|grepSERIAL_HEX
Si ce n'est pas le cas, supprimez le fichier de suivi.
Si elle existe, vous verrez une valeur hexadécimale sérielle légèrement plus longue que celle recherchée, appelée multipathSerial. Exécutez la commande suivante et recherchez les périphériques de bloc :
multipath-llMULTIPATH_SERIAL
Exécutez ensuite les commandes suivantes, la dernière étant exécutée uniquement pour chaque périphérique de bloc :
kubectl--kubeconfig=ADMIN_KUBECONFIGlogs-pkube-apiserver-{first_node_name}-nkube-system|grep"etcdmain: open /etc/kubernetes/pki/etcd/ca.crt: permission denied"
Le résultat affiché n'est pas vide.
Solution :
Activez ou désactivez l'autorisation /etc/kubernetes/pki/etcd/ca.crt. Il s'agit d'une opération très sensible au temps. Le changement d'autorisation doit avoir lieu après l'exécution précédente du job machine-init, mais avant la prochaine exécution du job machine-init, car machine-init rétablit l'autorisation sur la racine.
Redémarrez etcd dans le deuxième nœud pour récupérer etcd dans le premier nœud à partir de la boucle de plantage.
Une fois ces deux étapes terminées, le kube-apiserver du premier nœud commence à s'exécuter et le prochain job machine-init réussit.
Une fois que vous avez terminé de configurer l'exportation vers un système SIEM externe, l'entrée SIEM n'est pas incluse dans le pipeline de traitement Fluent Bit et les journaux du serveur d'API Kubernetes ne sont pas présents dans ce SIEM.
Lors de la mise à niveau de la version 1.12.2 vers la version 1.12.4, si un nœud est supprimé puis réajouté, le processus machine-init pour ce nœud peut échouer.
Cet échec se produit, car le trafic réseau du nœud réajouté vers les services essentiels du plan de contrôle est refusé par la règle ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes.
Cette erreur est mise en évidence par les messages d'état dans l'exemple de résultat suivant :
Récupérez les CIDR à partir de CIDRClaim/org-external-cidr -n root (plus précisément le champ .status.ipv4AllocationStatus.allocatedCidrBlocks). Exécutez la commande suivante dans le cluster d'administrateur racine :
Ajoutez ces CIDR à ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes, plus précisément au champ .spec.ingress.fromCIDR. Appliquez cette modification dans le cluster d'administrateur racine à l'aide de la commande suivante :
Pour le cluster d'administrateur de l'organisation :
Obtenez les CIDR pour l'organisation (par exemple, org-1) à partir de CIDRClaim/org-external-cidr -n org-1 (plus précisément le champ .status.ipv4AllocationStatus.allocatedCidrBlocks). Cette commande est exécutée sur le cluster administrateur racine pour obtenir les CIDR de "org-1" :
Ajoutez ces CIDR à ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes, plus précisément au champ .spec.ingress.fromCIDR. Appliquez cette modification dans le cluster d'administrateur de l'organisation concernée à l'aide de la commande suivante :
Sur un nœud bare metal du cluster système, deux conteneurs anetd ne peuvent pas être arrêtés. Après avoir arrêté de force le processus, redémarré kubelet et containerd, le pod anetd est recréé, mais tous les conteneurs sont bloqués dans podInit et containerd affiche le message d'erreur suivant :
Cela empêche le démarrage de l'interface réseau de conteneur (CNI) et la planification d'autres pods.
Solution :
Effectuez les atténuations suivantes pour éviter cet état de nœud :
Ne planifiez pas plus de 10 PVC à la fois sur un même nœud. Attendez qu'ils soient montés avant de planifier d'autres sauvegardes. Cela se remarquait surtout lorsque vous essayiez de créer des VM.
Mettez à jour le fichier /etc/lvm/lvm.conf sur chaque nœud pour inclure la ligne filter = [ "r|/dev/dm.|", "r|/dev/sg.|" ] dans le bloc devices{}.
Si le nœud passe dans un état où il affiche des délais d'attente pour les rattachements et les montages de volumes, ou s'il ne parvient pas à supprimer un volume, vérifiez le nombre de processus vgs suspendus sur le nœud pour déterminer si le nœud se trouve dans cet état particulièrement mauvais. Le moyen le plus fiable de corriger un nœud dans cet état consiste à le redémarrer.
Un autre mode de défaillance peut se produire. Ce mode d'échec présente la signature suivante lors de la tentative de montage : mount(2) system call failed: No space left on device. Cela provient probablement de la propagation du montage sur le nœud. Pour le vérifier, exécutez cat /proc/mounts | grep devtmpfs | awk '{ print $2 }' | sort -n | uniq -c. Si l'une de ces valeurs est supérieure à 1, supprimez le pod qui l'utilise. Cela devrait déclencher un démontage. Si cela ne fonctionne pas, démontez manuellement ce chemin. Si vous êtes toujours bloqué, redémarrez votre appareil.
Dans certains cas, en raison de conditions de concurrence, Google Distributed Cloud (GDC) air-gapped ne parvient pas à créer les ressources personnalisées Kubernetes ACL de commutateur nécessaires lors de l'amorçage initial de Distributed Cloud.
Lors du provisionnement de Server pendant la création d'un cluster, il est possible que le serveur soit marqué comme provisionné, mais qu'il manque la condition Provision-Ready. Par conséquent, le NodePool ne peut pas utiliser ce serveur. Un exemple de message d'événement d'erreur dans NodePool peut se présenter comme suit :
Réinitialisez ILO en exécutant le script suivant :
SERVER_NAME=ROOT_ADMIN_KUBECONFIG=ILO_IP=$(kubectlgetservers${SERVER_NAME}-ngpc-system--template={{.spec.bmc.ip}}--kubeconfig=${ROOT_ADMIN_KUBECONFIG})SECRET_NAME=$(kubectlgetsecrets-ogo-template='{{range $index,$pod := .items}}{{.metadata.name}}{{"\n"}}{{end}}'-ngpc-system--kubeconfig=${ROOT_ADMIN_KUBECONFIG}|grepbmc|grep${SERVER_NAME})ILO_USER=$(kubectlgetsecrets${SECRET_NAME}-ngpc-system--template={{.data.username}}--kubeconfig=${ROOT_ADMIN_KUBECONFIG}|base64-d)ILO_PASS=$(kubectlgetsecrets${SECRET_NAME}-ngpc-system--template={{.data.password}}--kubeconfig=${ROOT_ADMIN_KUBECONFIG}|base64-d)# Perform iLO Resetcurl-k-u${ILO_USER}:${ILO_PASS}-H"Content-Type: application/json"-H"OData-Version: 4.0"https://${ILO_IP}/redfish/v1/Managers/1/Actions/Manager.Reset--data'{"ResetType":"ForceRestart"}'-XPOST|jq
# Perform server power cycle, start with power off target servercurl-k-u${ILO_USER}:${ILO_PASS}-H"Content-Type: application/json"-H"OData-Version: 4.0"-XPOSThttps://${ILO_IP}/redfish/v1/Systems/1/Actions/ComputerSystem.Reset--data'{"ResetType":"ForceOff"}'|jq.
# Verify target server powered off successfullycurl-kqs-u${ILO_USER}:${ILO_PASS}https://${ILO_IP}/redfish/v1/Systems/1|jq'.PowerState'# Power server backcurl-k-u${ILO_USER}:${ILO_PASS}-H"Content-Type: application/jsonls "-H"OData-Version: 4.0"-XPOSThttps://${ILO_IP}/redfish/v1/Systems/1/Actions/ComputerSystem.Reset--data'{"ResetType":"On"}'|jq.
Dans de rares cas, la procédure de réinitialisation d'iLO précédente peut ne pas résoudre complètement le problème. Dans ce cas, un re-provisionnement du serveur est nécessaire. Pour connaître les procédures détaillées, consultez les runbooks OS-P0002 et OS-P0003.
Vous ne trouvez pas nxos.10.3.1.bin, mais vous trouvez quelque chose de similaire, comme nxos64-cs.10.3.1.F.bin, dans le répertoire bootflash du commutateur.
Solution :
Sur la machine d'amorçage, procédez comme suit. Vous devez suivre ces étapes pendant le processus de préinstallation. S'il existe plusieurs dossiers /tmp/preinstall-bootstrap-, appliquez les modifications au dossier actuel utilisé par le processus de préinstallation en consultant les journaux du processus de préinstallation. Si vous devez redémarrer la commande de préinstallation, cette action crée également un dossier /tmp/preinstall-bootstrap-.
Accédez au dossier /tmp/preinstall-bootstrap-RANDOM_NUMBER.
Dans le dossier, recherchez le fichier poap.py.
Supprimez entièrement la ligne contenant la somme de contrôle md5 dans ce fichier afin que head -n 4 poap.py se présente comme suit :
La mise à niveau de la version 1.11.x vers la version 1.12.1 échoue, car le contrôleur pnet ne génère pas correctement la ressource personnalisée (CR) hairpinlink.
Solution :
Après la mise à niveau, dans le cluster d'administrateur racine, modifiez le fichier clusterroles/pnet-core-backend-controllers-role.
Recherchez hairpinlinks, puis ajoutez les autorisations create,update,delete à la ressource.
Vérifiez que les CR hairpinlinks et hairpinbgpsessions sont générés.
Ce problème est dû au nettoyage incorrect du job de mise à niveau. Aucune action n'est requise. Vous pouvez laisser le job dans l'état de boucle de plantage.
Cela pose problème pour les serveurs dont l'heure n'est pas synchronisée. La configuration n'est pas appliquée correctement et doit être modifiée pour un autre espace de noms afin d'être appliquée correctement.
Solution :
Appliquez les étapes suivantes à tous les clusters :
Répertoriez les règles d'OS existantes :
kubectlgetospolicies-nntp-system
Le résultat affiche admin-ntp-policy ou worker-ntp-policy.
En fonction du nom de la règle, enregistrez-la dans un fichier .yaml :
Modifiez le fichier en remplaçant metadata.namespace par gpc-system et en supprimant status: line et tout ce qui suit.ntp-system
Appliquez le fichier modifié au cluster :
kubectlapply-fntp-ospolicy.yaml
Patientez quelques minutes le temps que le contrôleur applique la règle OS.
Établissez une connexion SSH à l'un des nœuds auxquels OSPolicy s'applique, puis exécutez cat /etc/chrony.conf. Le résultat affiche un message au début du fichier indiquant qu'il est géré par Ansible et que les serveurs nist.time.gov ou ntp.pool ont été supprimés de la configuration.
Les utilisateurs ne peuvent pas démarrer le processus de sauvegarde et de restauration des VM en raison de paramètres de contrôle des accès basé sur les rôles (RBAC) et de schéma incorrects dans le gestionnaire de VM.
Les noms des plans de sauvegarde de VM ne peuvent pas comporter plus de 63 caractères.
Par exemple, le message d'erreur suivant peut s'afficher :
Les noms des plans de sauvegarde de VM sont une concaténation du nom VirtualMachineBackupPlanTemplate, du type de ressource (vm ou vm-disk) et du nom de cette ressource. Cette chaîne concaténée ne doit pas dépasser 63 caractères.
Pour ce faire, veillez à ce que les noms de ces ressources soient courts lorsque vous les créez. Pour en savoir plus sur la création de ces ressources, consultez Créer et démarrer une instance de VM et Créer un plan de sauvegarde pour les VM.
Les charges de travail du service de base de données sont provisionnées et configurées dans des projets distincts du cluster système Distributed Cloud. Bien que les projets soient utilisés pour appliquer des limites administratives dans Distributed Cloud, ils n'ont aucune incidence sur la façon dont une charge de travail est exécutée ni sur l'endroit où elle l'est. Par conséquent, ces charges de travail peuvent partager l'infrastructure de calcul sous-jacente avec d'autres instances de base de données et différents systèmes de plan de contrôle.
Solution :
Pour les charges de travail de base de données qui nécessitent une isolation supplémentaire, les utilisateurs peuvent demander la création d'un pool de nœuds sur le cluster système. Ce pool de nœuds, qui doit être référencé lors de la création du projet, garantit que les charges de travail de base de données sont provisionnées et exécutées sur une infrastructure de calcul dédiée. L'opérateur d'infrastructure doit terminer la configuration du pool de nœuds isolé.
Pour AlloyDB Omni version 15.2.1, lorsque plusieurs clusters AlloyDB Omni sont créés sur le même nœud, le dernier cluster créé reste bloqué dans un état de réconciliation. Obtenir les journaux PostgreSQL avec une commande
Lors du déploiement client, le nom d'utilisateur de l'administrateur du fichier secret.yaml doit être admin. Au lieu de cela, le fichier contient TO-BE-FILLED après la première création. Le nom d'utilisateur admin doit être utilisé pour initialiser la première configuration sur le pare-feu et sur l'adresse IP de bouclage admin\admin.
Solution :
Vérifiez que TO-BE-FILLED n'est pas présent dans les identifiants de pare-feu suivants :
CELL_ID/CELL_ID-secret.yaml
CELL_ID-ab-rack/CELL_ID-secret.yaml
CELL_ID-ac-rack/CELL_ID-secret.yaml
Vérifiez que tous les comptes administrateur du pare-feu ont le nom d'utilisateur admin.
Les stratégies de pare-feu IDPS par défaut ne sont pas compatibles avec les adresses IP personnalisées de l'organisation pour l'interconnexion Direct Connect (DX). Par conséquent, la création d'une organisation avec des adresses IP personnalisées échoue, car ces adresses ne peuvent pas se connecter à Harbor dans l'administrateur racine.
Solution :
Pour débloquer le trafic, créez manuellement un SecurityPolicyRule pour les adresses IP personnalisées de l'organisation et déployez-le sur les pare-feu IDPS. Suivez les étapes du runbook FW-G0002 pour effectuer les opérations suivantes :
1. Créez un SecurityPolicyRule d'entrée dans le système virtuel de pare-feu racine pour permettre aux adresses IP personnalisées de l'organisation d'accéder à Harbor racine.
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 faux avertissements d'expiration.
Solution :
Consultez HSM-R0003 pour vérifier les licences normales actives et supprimer les licences d'essai désactivées.
Le module de sécurité matériel (HSM) se comporte de manière inattendue lors de la suppression d'un CTMKey KMS. Par exemple, il est possible que le service KMS ne démarre pas pour l'organisation.
Solution :
Les utilisateurs peuvent détruire les données par chiffrement en supprimant les clés KMS au lieu de la clé racine KMS, ce qui se manifeste par un CTMKey.
La configuration du webhook ServiceNow entraîne une nouvelle réconciliation et une restauration des modifications apportées à l'objet ConfigMapmon-alertmanager-servicenow-webhook-backend et à l'objet Secretmon-alertmanager-servicenow-webhook-backend dans l'espace de noms mon-system par la gestion du cycle de vie (LCM).
Solution :
Suspendez le sous-composant LCM pour que les modifications soient appliquées sans être annulées :
Obtenez les chemins d'accès aux fichiers kubeconfig des clusters administrateur racine et administrateur de l'organisation. Enregistrez les chemins d'accès dans les variables d'environnement ROOT_ADMIN_KUBECONFIG et ORG_ADMIN_KUBECONFIG, respectivement.
Mettez en veille le sous-composant LCM dans l'un des clusters suivants :
Mettez en veille le sous-composant LCM dans le cluster d'administrateur racine :
Certaines métriques des clusters d'utilisateurs ne sont pas collectées. Ce problème affecte les clusters de VM utilisateur, mais pas le cluster système.
Vous pouvez consulter les journaux suivants sur le serveur Prometheus :
prometheus-serverts=2024-02-21T16:07:42.300Zcaller=dedupe.go:112component=remotelevel=warnremote_name=cortex-remote-writeurl=http://cortex-tenant.mon-system.svc:9009/pushmsg="Failed to send batch, retrying"err="server returned HTTP status 500 Internal Server Error: 2 errors occurred:"
Vous pouvez consulter les journaux suivants du locataire Cortex :
cortex-tenanttime="2024-02-23T18:03:44Z"level=errormsg="proc: src=127.0.0.6:55021 lookup cortex.mon-system.svc on 172.25.38.10:53: no such host"
Solution :
Pour résoudre le problème, procédez comme suit :
Obtenez le chemin d'accès au fichier kubeconfig du cluster. Enregistrez le chemin d'accès dans la variable d'environnement KUBECONFIG.
Déployez un service stub dans les clusters de VM utilisateur :
Les métriques destinées à l'instance Grafana de l'opérateur d'infrastructure peuvent se trouver dans l'instance Grafana de l'administrateur de plate-forme, et inversement. Ce problème est dû aux requêtes d'équilibrage de charge ASM au-delà des limites du cluster, qui ont des locataires par défaut différents.
Solution :
La solution de contournement nécessite d'avoir accès à la source private-cloud et de pouvoir déployer une mise à jour de composant. Vous devez modifier la configuration du maillage pour limiter le service cortex-tenant afin qu'il ne reçoive que le trafic du cluster local, et déployer le composant ASM.
Ouvrez le fichier manifests/plain/asm/1.19/asm-primary-cluster-operator.yaml.
Présentez le champ serviceSettings dans le champ meshConfig.
Le champ meshConfig se présente initialement comme suit :
Lors de la mise à niveau de la version 1.11.0 vers la version 1.11.3, la mise à niveau des nœuds échoue pour NodeOSInPlaceUpgradeCompleted.
kalogs-ngpc-systemos-policy-preflight-os-upgrade-bm-86efcc8en8sh2-6h5cn|grepGDCH-OS-ANSIBLE-CHECK-A50[GDCH-OS-ANSIBLE-CHECK]{"syntax":{"success":true,
"msg":""},
"apply":{"reachablity":{"success":true,
"msg":""},
"execution":{"success":false,
"msg":"errors found when simluating play execution on host: 10.3.20.9",
"tasks":[{"task":"os/upgrade : Copy GRUB file to BOOT location",
"error":"Source /boot/efi/EFI/ubuntu/grubx64.efi not found"}]}},
"diff":null
}
Solution :
Connectez-vous à la machine Bare Metal qui est mise à niveau. Vérifiez si fstab comporte /boot/efi et si le répertoire est monté :
Exécutez mount -a et vérifiez si le répertoire est monté :
# mount -a
root@mb-aa-bm04:~#ls/boot/efi/
EFI
Effectuez les vérifications ici. Exécutez les commandes suivantes :
C
# Ensure all three cmds prints `Files are identical`if["$(sha256sum/boot/efi/EFI/ubuntu/shimx64.efi|awk'{ print $1 }')"=="$(sha256sum/boot/efi/EFI/BOOT/BOOTX64.EFI|awk'{ print $1 }')"];thenecho"Files are identical.";elseecho"Files are different.";fiif["$(sha256sum/boot/efi/EFI/ubuntu/grubx64.efi|awk'{ print $1 }')"=="$(sha256sum/boot/efi/EFI/BOOT/grubx64.efi|awk'{ print $1 }')"];thenecho"Files are identical.";elseecho"Files are different.";fiif["$(sha256sum/boot/efi/EFI/ubuntu/grub.cfg|awk'{ print $1 }')"=="$(sha256sum/boot/efi/EFI/ubuntu/grub.cfg|awk'{ print $1 }')"];thenecho"Files are identical.";elseecho"Files are different.";fi
Si tous les fichiers ne sont pas identiques, exécutez cette commande sur la machine et répétez les vérifications.
La mise à niveau du cluster est bloquée depuis plus d'une heure. L'état et les spécifications du mode maintenance de la machine Bare Metal ne correspondent pas. Par exemple, la commande :
Une tâche de redémarrage de VM échoue après la solution de contournement manuelle pour le pod os-policy. Le message suivant s'affiche :
kologsos-policy-preflight-os-reboot-vm-b1fb94147x8r9-nqmvp-ngpc-system
playbook:server-reboot.yaml
{"custom_stats":{},
"global_custom_stats":{},
"plays":[{"play":{"duration":{"end":"2024-01-12T03:50:52.749714Z",
"start":"2024-01-12T03:50:42.694226Z"},
"id":"5251f140-5a01-5cce-6150-000000000006",
"name":"Run OS Upgrade Tasks"},
"tasks":[{"hosts":{"172.20.128.10":{"action":"setup",
"changed":false,
"msg":"Failed to connect to the host via ssh: ssh: connect to host 172.20.128.10 port 22: Connection timed out",
"unreachable":true}},
"task":{"duration":{"end":"2024-01-12T03:50:52.749714Z",
"start":"2024-01-12T03:50:42.704562Z"},
"id":"5251f140-5a01-5cce-6150-00000000000b",
"name":"os/reboot : Gather OS distribution information"}}]}],
"stats":{"172.20.128.10":{"changed":0,
"failures":0,
"ignored":0,
"ok":0,
"rescued":0,
"skipped":0,
"unreachable":1}}}[GDCH-OS-ANSIBLE-CHECK]{"syntax":{"success":true,
"msg":""},
"apply":{"reachablity":{"success":false,
"msg":"Failed to connect to the host via ssh: ssh: connect to host 172.20.128.10 port 22: Connection timed out"},
"execution":{"success":false,
"msg":"",
"tasks":null
}},
"diff":null
}[GDCH-OS-ANSIBLE-CHECK]
Error:reachabilityerr:Failedtoconnecttothehostviassh:ssh:connecttohost172.20.128.10port22:Connectiontimedout
Solution :
Arrêter et démarrer la VM résout le problème. Suivez les instructions de l'article Démarrer et arrêter une VM.
Lors de la mise à niveau d'une organisation racine de la version 1.11.1 vers la version 1.12.1, la mise à niveau peut échouer au niveau du module complémentaire avec des erreurs Helm pull :
Lors d'une mise à niveau, le sous-composant OPA Gatekeeper n'est pas installé dans le cluster système. Toutefois, les contraintes et le webhook permettant de les appliquer sont installés.
Plusieurs pods d'un cluster système peuvent rester bloqués dans l'état TaintToleration :
Le pod dont le nom de conteneur est istio-proxy n'est pas prêt et présente l'état ImagePullBackOff avec l'événement Back-off pulling image "auto".
Solution :
Vérifiez que le webhook de mutation istio-revision-tag-default est présent dans le cluster. Si ce n'est pas le cas, patientez environ 10 minutes pour voir si le système se rétablit automatiquement. Si ce n'est pas le cas, signalez le problème.
Si le webhook de mutation est présent, supprimez le pod problématique et vérifiez qu'il est de nouveau opérationnel. .spec.containers[].image ne doit pas être auto, mais doit ressembler à une image réelle, comme suit : gcr.io/gke-release/asm/proxyv2:<image version>.
Lors de la mise à niveau de la version 1.11.1 vers la version 1.12.1, il est possible que la mise à niveau de ValidatingWebhookConfigurations, MutatingWebhookConfigurations et MonitoringRules déployés par le composant Log échoue.
Solution :
Assurez-vous de disposer de kubectl et d'avoir accès au runbook IAM-R0004 pour obtenir le KUBECONFIG du cluster d'administrateur racine.
Supprimez ValidatingWebhookConfiguration root-admin-private-logging-validation-webhook du cluster d'administrateur racine :
En raison d'un problème dans le job log-infra-backend-preinstall, les journaux d'audit et les journaux opérationnels Lokis ne sont pas installés et les journaux ne sont pas collectés.
Symptômes :
Vous pouvez voir un CrashLoopBackoff dans le cluster système :
Augmentez la mémoire de chaque ingesteur, le nombre d'ingesteurs ou les deux. Pour ce faire, déployez un SubcomponentOverride sur le cluster d'administrateur de l'organisation, comme illustré dans l'exemple suivant :
apiVersion:lcm.private.gdc.goog/v1
kind:SubcomponentOverride
metadata:
name:mon-cortex-ingester-override
namespace:org-1-system-cluster
spec:
backend:
operableParameters:
ingester:
resourcesLimit:
memory:"6Gi"# 6Gi is the default, increase to add more memory to each ingesterreplicas:4# 4 is the default, increase to create more ingester instances.subComponentRef:mon-cortex
addOn:{}anthosBareMetal:
conditions:
-lastTransitionTime:"2024-09-12T12:10:55Z"message:'UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn''t after 39h18m50.606521473s, last message was: Cluster upgrade for root-admin cluster: in-progress'observedGeneration:1reason:ABMUpgradeTimeout
status:Unknown
type:Succeeded
startTime:"2024-09-12T12:10:55Z"node:{}
2. L'état de la machine Bare Metal indique un échec de la vérification check_registry_mirror_reachability_pass.
kubectl--kubeconfig=${ROOT_ADMIN_OR_ORG_ADMIN_KUBECONFIG}getbaremetalmachines-A-ojson|jq'.items[] | select(.status.underMaintenace != .spec.maintenanceMode) | .metadata.name as $name | .status.underMaintenace as $statm | .spec.maintenanceMode as $specm | .status.conditions[] | select(.status == "False") | select(.type == "MaintenaceModeHealthCheckReady")'
addOn:{}anthosBareMetal:
conditions:
-lastTransitionTime:"2024-09-12T12:10:55Z"message:'UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn''t after 39h18m50.606521473s, last message was: Cluster upgrade for root-admin cluster: in-progress'observedGeneration:1reason:ABMUpgradeTimeout
status:Unknown
type:Succeeded
startTime:"2024-09-12T12:10:55Z"node:{}
2. Les vérifications de l'état affichent l'erreur netutil manquante.
{"lastHealthcheck":{"error":{"code":"500",
"reason":"[Errno 2] No such file or directory: /usr/local/bin/abm-tools10.5.23.4/netutil"},
"lastCompletedTime":"2024-09-14T05:11:39Z",
"lastStatus":"Error",
"monitoredComponentVersion":"1.28.900-gke.112",
"version":"1.28.900-gke.112"},
"lastScheduledTime":"2024-09-14T05:26:00Z"}
Solution :
Supprimer le job Kubernetes correspondant au HealthCheck ayant échoué
Lors de la mise à niveau de la version 1.11.x vers la version 1.12.x, il est possible qu'une VM ne soit pas prête en raison d'un nombre trop élevé de pods, ce qui bloque le drainage d'un nœud Bare Metal.
Lors de la mise à niveau de la version 1.11.x vers la version 1.12.1, NodeUpgrade contient plusieurs versions pour le même modèle de matériel, ce qui bloque la vérification de la mise à niveau du micrologiciel.
Solution :
Pour modifier la CR NodeUpgradespec, procédez comme suit :
Si la mise à niveau concerne des serveurs HPE Gen10 (GDC-4D), supprimez le micrologiciel du modèle ilo6. Sinon, supprimez le micrologiciel du modèle ilo5.
Section permettant de conserver l'entrée avec le redfishVersion le plus récent pour chaque description.
Par exemple, si les deux entrées suivantes existent, ne conservez que celle avec 2.98 Oct 10 2023 :
Si le commutateur est activé, le résultat renvoie "On".
Solution :
Supprimez le bloc image des serveurs problématiques et attendez que les serveurs reviennent à l'état disponible. Une fois qu'ils sont disponibles, ajoutez à nouveau le bloc image.
Ce problème se produit lorsque les erreurs iLO sont ignorées et que la réponse HTTP est lue au lieu d'être renvoyée immédiatement, ce qui entraîne une déréférence de pointeur nul.
Les nœuds devraient être en mode maintenance lors d'une mise à niveau. Si un nœud est en maintenance, vous n'aurez peut-être pas assez de ressources pour planifier harbor-db.
Solution :
Pour résoudre le problème, suivez les étapes ci-dessous :
L'objet Prometheus StatefulSet est mal configuré avec la classe de stockage standard au lieu de standard-rwo. Ce problème entraîne l'échec du démarrage de l'objet StatefulSet Anthos Prometheus à partir du composant de surveillance.
Ce problème se produit, car le reconciler ObservabilityPipeline ne définit cette valeur que lors de la première installation, et le reconciler ObsProjectInfra surveille les ressources personnalisées du cluster.
Solution :
Pour résoudre le problème, redémarrez le déploiement fleet-admin-controller dans le cluster d'administrateur de l'organisation.
Le sous-composant mon-common doit déployer un objet de télémétrie Istio dans le cluster d'administration de l'organisation pour empêcher la journalisation d'audit de toutes les requêtes pour Cortex. Toutefois, le fichier manifeste n'est pas inclus dans le fichier de compilation.
Solution :
Suivez les étapes ci-dessous pour déployer l'objet de télémétrie Istio dans le cluster d'administrateur de l'organisation :
Créez un fichier YAML définissant la ressource personnalisée (CR) Istio Telemetry dans l'espace de noms mon-system du cluster d'administrateur de l'organisation :
# Disable access logging from workloads internal to GDCH.# Telemetry CR to disable Istio access logs from obs-system namespace.
apiVersion:telemetry.istio.io/v1alpha1
kind:Telemetry
metadata:
name:disable-audit-logging
namespace:mon-system
spec:
accessLogging:
-providers:
-name:otel
disabled:true
Appliquez le fichier manifeste au cluster d'administrateur de l'organisation dans l'espace de noms mon-system :
Le ConfigMap du vérificateur se remplit à mesure que chaque vérification est enregistrée.
Suivez le runbook MON-R2009 pour couper le son de l'alerte MON-A0001, Blackbox monitoring metrics pipeline down, car cette alerte continuera de se déclencher.
Lors de la mise à niveau de la version 1.11.x vers la version 1.12.x, un pod de téléchargement d'image de commutateur peut rester bloqué à l'état ErrImagePull avec l'avertissement suivant :
Lors de la mise à niveau de la version 1.11.x vers la version 1.12.1, le pare-feu de l'hôte bloque le téléchargement de l'image de l'assistant en raison d'une incompatibilité des interfaces utilisées par le pare-feu de l'hôte.
Solution :
Appliquez la solution de contournement suivante avant la mise à niveau, uniquement si vous passez de la version 1.11.x à la version 1.12.x.
Mettez à jour les clusters d'administrateur racine et d'administrateur de l'organisation.
Obtenez le nom et l'espace de noms du pool de nœuds pour les nœuds Bare Metal de l'administrateur racine et de l'administrateur de l'organisation. Pour le cluster root-admin, utilisez le fichier kubeconfig root-admin. La commande suivante liste un inventaire des machines et filtre la liste par machines bare metal :
Les champs NODEPOOL_NAME et NODEPOOL_NAMESPACE sont renseignés avec la liste de tous les pools de nœuds du cluster respectif lorsque le fichier YAML précédent est déployé.
Voici un exemple de fichier YAML pour le cluster d'administrateur racine avec les noms réels du pool de nœuds de l'administrateur racine et du pool de nœuds de l'administrateur de l'organisation :
Les commutateurs réseau préchargés avec une version antérieure à 9.3.10 ne parviennent pas à démarrer, car la version attendue du commutateur est 10.3(4a).
Solution :
Mettez à niveau manuellement le micrologiciel du commutateur de la version 9.3.5 à la version 9.3.10, puis de la version 9.3.10 à la version 10.3.4a.
conditions:
-lastTransitionTime:"2024-03-28T01:37:20Z"message:'Reconciliation error: E0100 - deploy: failed to install chart: release file-netapp-trident-backend failed, and has been uninstalled due to atomic being set: cannot patch "standard-rwo" with kind StorageClass: StorageClass.storage.k8s.io "standard-rwo" is invalid: parameters: Forbidden: updates to parameters are forbidden. && cannot patch "standard-block" with kind StorageClass: StorageClass.storage.k8s.io "standard-block" is invalid: parameters: Forbidden: updates to parameters are forbidden.'observedGeneration:1reason:ReconciliationError
status:"True"type:Reconciling
Dans cet exemple, deux classes de stockage ont échoué : standard-rwo et �.standard-block
Solution :
Supprimez les StorageClasses que la tâche n'a pas réussi à créer, comme standard-rwo, standard-block, standard-rwo-non-luks et standard-block-non-luks.
Déclenchez la recréation de StorageClasses en redémarrant le contrôleur oclcm-backend pour votre cluster (contrôleur root-admin pour les clusters root et d'administrateur d'organisation, contrôleur org-admin pour les clusters système et d'utilisateur).
Pour la version 1.12.4, vérifiez que les classes de stockage installées ont l'annotation disk.gdc.goog/luks-encrypted: définie sur "true" (à l'exception des classes de stockage non-LUKS). Si l'annotation n'est pas définie sur "true", répétez les étapes 1 et 2.
Redémarrez le déploiement netapp-trident et netapp-trident DaemonSet dans le cluster.
Vérifiez que le secret LUKS a été créé pour vos ressources PersistentVolumeClaim (PVC). Chaque PVC doit avoir un secret au format g-luks-$pvc_name.
Vérifiez que le sous-composant file-netapp-trident ne présente aucune erreur dans l'état.
Après la mise à niveau de l'organisation racine de la version 1.12.1 vers la version 1.12.x, la validation post-mise à niveau échoue avec l'erreur suivante :
Il est possible que les pools de nœuds des clusters d'utilisateur exécutés sur la version 1.27.x de Kubernetes ne s'initialisent pas, ce qui empêche le cluster d'utilisateur de gérer les charges de travail de conteneur.
Solution :
Ne créez pas de cluster d'utilisateur avec la version 1.27.x de Kubernetes.
L'importation d'images de VM échoue lors de l'étape de traduction d'image si une image source Ubuntu contient des sources APT par défaut dans sources.list.
Solution :
Assurez-vous que le répertoire /var/lib/apt/lists/ est vide dans l'image source.
VMRuntime sur le cluster cible (qui peut être un cluster d'administrateur ou système) a l'état VMRuntime.ready défini sur "false" et network-controller-manager dans l'espace de noms kube-system est en attente.
La suppression du déploiement network-controller-manager devrait le recréer automatiquement avec les certificats requis par l'opérateur VMM. Le déploiement devrait passer à l'état Running, puis l'état VMRuntime devrait passer à ready=true.
Les pods de l'outil d'importation de VM plantent en boucle et le volume de données reste bloqué à l'état d'importation pendant plus de 90 minutes. L'état des pods peut ressembler à ceci :
message:'Reconciliation error: E0111 - upgrade chart: release unet-nodenetworkpolicy-infra-assets failed, and has been rolled back due to atomic being set: cannot patch "mgmt-network" with kind Network: admission webhook "vnetwork.networking.gke.io" denied the request: Network.networking.gke.io "mgmt-network" is invalid: Spec.NodeInterfaceMatcher: Forbidden: Field is immutable'observedGeneration:2
Solution :
Si l'échec se produit au niveau de la racine, remplacez KUBECONFIG par le kubeconfig de l'administrateur racine dans les étapes suivantes.
Si l'échec concerne l'organisation, remplacez KUBECONFIG par le kubeconfig de l'administrateur de l'organisation dans les étapes suivantes.
Lors de la mise à niveau de la version 1.11.x vers la version 1.12.2, ou après, les jobs portant le nom bm-system-add-ons-* peuvent échouer avec l'erreur suivante :
Le fichier peut contenir le message suivant dans la section backendStatus.
message:'E0100 - deploy: failed to install chart: release file-observability-backend failed, and has been uninstalled due to atomic being set: deployments.apps "file-observability-backend-controller" not found'
Solution :
Vérifiez l'espace de noms file-system pour vous assurer qu'il ne s'arrête pas dans org-admin cluster :
Mettez en pause le sous-composant file-observability jusqu'à ce que le sous-composant mon-admin soit opérationnel, en ajoutant les annotations suivantes au sous-composant :
Exécutez ksctl system info get --url=https://HSM_MANAGEMENT_IP pour vérifier que toutes les versions de HSM sont mises à niveau vers .Spec.TargetVersion de ctmclusterupgraderequest :
Mettez à jour le champ Status.FirmwareVersion de chaque HSM vers la version mise à niveau obtenue à l'étape précédente :
Exemple :
kubectledit-statushsmHSM_NAME-ngpc-system
Remplacez l'état de la dernière condition False par True pour ctmclusterupgraderequest.status.conditions. Après cela, l'état de la dernière condition hsmupgraderequest.status.conditions devient également "true" (vrai).
Lors d'une mise à niveau, l'adresse IP de gestion d'un serveur est inaccessible, en particulier après une mise à niveau de l'OS du commutateur.
Avec Rocky Linux, lorsque des routes statiques sont ajoutées, l'adresse IP de destination utilisée pour atteindre les routes statiques doit être accessible avant l'ajout des routes statiques. Si le commutateur redémarre après une mise à niveau de l'OS, cette adresse IP de gestion peut être temporairement inaccessible.
Solution :
Établissez une connexion SSH au serveur à l'aide de l'adresse IP des données, puis redémarrez le service réseau pour recréer les routes statiques manquantes :
Lorsque vous déployez manuellement l'organisation gdchservices, le système de gestion des tickets ne dispose d'aucun serveur en amont opérationnel, aucune VM n'est créée et le pod midserver n'est pas opérationnel dans le cluster gdchservices-system de l'espace de noms support.
Solution :
Créez une ressource personnalisée TicketingSystem avec l'image de VM appropriée dans le cluster gdchservices-admin :
L'accès à la connexion ne fonctionne pas pour une VM avec une adresse IP de gestion. Une erreur semblable à celle-ci peut s'afficher dans les journaux de pods anetd :
Le nouveau sous-composant doit présenter les spécifications suivantes et l'URL de chat doit indiquer la version vers laquelle les clusters ont déjà été migrés :
Si l'erreur se produit lors des vérifications post-vol et que toutes les autres vérifications sont effectuées sans erreur, ignorez les vérifications post-vol. Lorsque la mise à niveau redémarre, vous devez également ignorer les vérifications préliminaires à l'aide du fichier kubeconfig de l'administrateur racine :
Si l'erreur se produit lors des vérifications préliminaires et que toutes les autres vérifications préliminaires sont effectuées sans erreur, ignorez les vérifications préliminaires :
Le schéma Portfolio a été modifié dans la version 1.12 de GDC. Le champ portfolioName a été refactorisé en portfolioID. Recherchez le fichier YAML contenant la ressource personnalisée de portefeuille mentionnée dans le message d'erreur. Renommez le champ portfolioName en portfolioID.
Voici les raisons potentielles pour lesquelles une tâche en cours n'est pas créée pour une tâche de correctif qui n'a effectué que des tâches de prévol :
Si le protocole NTP échoue, aucune autre tâche de correctif ne peut s'exécuter.
Le nœud est non opérationnel.
L'agent OS Config n'est pas en cours d'exécution.
L'agent OS Config ne peut pas communiquer avec le service OS Config.
Un problème est survenu avec le service OS Config.
Solution :
Vérifiez le CR `NodeTargetPolicy` du nœud.
Recherchez `.spec.osPolicies` du CR `NodeTargetPolicy` qui a `ref.name=admin-ntp-policy` et `type: Ready` avec l'état "false" :
# Enter the node InventoryMachine name.NAME=kubectlgetnodetargetpolicy-ngpc-system$NAME-ojsonpath="{.spec.osPolicies}"|jq
La ressource personnalisée NodeUpgrade mentionne version: rocky-86-xyz dans sa spécification, même si le nœud en cours de mise à niveau est Ubuntu.
Solution :
Vous n'avez pas besoin de solution de contournement, car ces informations sont inoffensives. Le nœud est correctement mis à niveau vers une version plus récente d'Ubuntu.
Les jobs siem-*-preinstall dans l'espace de noms racine et org-1 du cluster d'administrateur racine échouent à plusieurs reprises.
Solution :
Il est normal que les jobs échouent lorsque le feature gate SIEMComponent est désactivé. Ces échecs n'indiquent pas que le composant est défaillant. La réconciliation du composant SIEM peut être suspendue si le bruit est perturbant, mais il est généralement recommandé de laisser le composant activé si possible. Si la réconciliation des composants est suspendue, elle doit être réactivée manuellement lorsque l'installation du composant SIEM n'est plus bloquée dans les futures mises à niveau.
Il est possible que vgs, blkid et gather_facts d'Ansible ne répondent pas. Ce problème affecte les systèmes d'exploitation Rocky et Ubuntu.
Suivez ces étapes si les nœuds sont déjà mis à niveau. Pour mettre à jour le fichier lvm.conf, procédez comme suit :
Obtenez la liste de tous les nœuds pour que ce correctif puisse leur être appliqué.
Créez un playbook Ansible et un fichier de règles OS.
Appliquez le correctif aux nœuds.
Vérifiez si le correctif a été appliqué.
Prérequis :
Suivez les étapes du runbook IAM-R0004 pour générer le ROOTCONFIG pour le cluster d'administrateur racine et le ORGCONFIG pour le cluster d'administrateur de l'organisation.
Suivez les étapes du runbook IAM-R0005 pour obtenir les rôles suivants de l'organisation.
Solution :
Identifiez les InventoryMachines qui correspondent aux clusters :
Séparez les résultats. Corrigez un cluster à la fois. Le résultat peut ressembler à ceci :
NAME
bm-2bca8e3f
bm-4caa4f4e
Créez un playbook et un fichier de règles :
apiVersion:system.private.gdc.goog/v1alpha1
kind:AnsiblePlaybook
metadata:
name:lvm-conf-device-filter-node-update
namespace:gpc-system
spec:
playbook:|-name:Addadevicefilterto/etc/lvm/lvm.conf
hosts:all
gather_facts:no
tasks:
# Change lvm.conf-name:Configurelvmforfilteringout"dm"and"sg"devices
ansible.builtin.lineinfile:
path:/etc/lvm/lvm.conf
insertafter:'^(\s+|)devices(\s+|)\{'line:' filter = [ \"r|/dev/dm.|\", \"r|/dev/sg.|\" ]'---
apiVersion:system.private.gdc.goog/v1alpha1
kind:OSPolicy
metadata:
name:lvm-conf-device-filter-node-update
namespace:gpc-system
spec:
interval:
period:1m
inventory:
# this is the inventory from step 1 above,# see the syntex belowpolicy:
installPlaybook:
name:lvm-conf-device-filter-node-update
La section "Inventaire" précédente doit être remplie comme dans cet exemple.
Ajoutez un paragraphe par nœud trouvé à l'étape 1. Vous allez travailler sur un cluster à la fois. Remplissez donc la section "inventory" avec les nœuds d'un seul cluster.
Ce problème se produit si l'environnement a été déployé précédemment avec la version 1.11, puis mis à niveau vers la version 1.12. Lorsque vous créez un cluster ou une organisation dans une version 1.12.x, Rocky OS est sélectionné plutôt qu'Ubuntu OS pour le provisionnement des nœuds Bare Metal et de machine virtuelle en raison de la version Rocky OS spécifiée dans les CR ReleaseMetadata et Userclustermetadata.
Solution :
Appliquez la solution de contournement suivante avant de créer une organisation :
Vérifiez s'il existe des CR OrganizationUpgrade qui ne sont pas à l'état Succeeded: true :
foritemin$(kubectl--kubeconfig=KUBECONFIGgetOrganizationUpgrade-A-ocustom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace--no-headers);doNAME=$(echo$item|awk'{print $1}')NAMESPACE=$(echo$item|awk'{print $2}')STATUS=$(kubectl--kubeconfig=KUBECONFIGgetorganizationupgrade${NAME}-n${NAMESPACE}-ojson|jq'.status.conditions[] | select(.type=="Succeeded") | .status')if[["$STATUS"!="True"]];thenecho"Not in Succeeded: true state, stop following operations"fidone
Si c'est le cas, escaladez le problème à l'équipe d'ingénieurs avant de passer aux étapes suivantes.
Supprimez tous les CR OrganizationUpgrade existants pour éviter les mises à niveau accidentelles de l'OS des nœuds :
foritemin$(kubectl--kubeconfig=KUBECONFIGgetOrganizationUpgrade-A-ocustom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace--no-headers);doNAME=$(echo$item|awk'{print $1}')NAMESPACE=$(echo$item|awk'{print $2}')echo"Deleting OrganizationUpgrade $NAME in namespace $NAMESPACE"kubectl--kubeconfig=KUBECONFIGdeleteOrganizationUpgrade$NAME-n$NAMESPACEdone
Définissez la version GDC cible pour la création de la nouvelle organisation. Il doit exister des métadonnées de version correspondantes pour cette version cible :
TARGET_RELEASE=
Identifiez la dernière CR OSImageMetadata pour l'OS Ubuntu cible dans le cluster d'administrateur racine et définissez la variable OS_VERSION :
Assurez-vous que la variable utilise la même version majeure.mineure.correctif, telle que 1.12.4, que TARGET_RELEASE. Si ce n'est pas le cas, contactez l'équipe d'ingénieurs avant de passer aux étapes suivantes.
Mettez à jour le ReleaseMetadata cible pour utiliser le OS_VERSION Ubuntu dans le cluster d'administrateur racine :
Mettez à jour le UserclusterMetadata cible pour utiliser le OS_VERSION Ubuntu dans le cluster d'administrateur racine et le cluster d'administrateur de l'organisation pour chaque organisation. Exécutez la commande suivante pour chaque cluster :
Lorsque des images de VM locales sont importées à l'aide de la CLI gdcloud compute images import, l'état de l'importation reste bloqué sur WaitingForTranslationVM ou ImportJobNotCreated. En effet, le disque temporaire créé pour la traduction ou l'importation utilise exactement la même taille que l'image qcow2 ou brute, mais LUKS ajoute une surcharge de quelques Mio, ce qui entraîne l'échec du provisionnement du disque.
Solution :
Créez manuellement un VirtualMachineImageImport avec le même nom d'image, mais avec un spec.minimumDiskSize plus grand. Par exemple, si la commande utilisée pour importer l'image était la suivante :
Si le VirtualMachineImageImport d'origine créé automatiquement par la CLI a minimumDiskSize comme X Gio, créez-en un avec X+1 Gio. La valeur est basée sur la taille de l'image importée. Dans le cas de qcow2, il s'agit de la taille virtuelle. Par exemple, 20 Gio doit être remplacé par 21 Gio.
Remplacez les valeurs des espaces réservés en fonction de la façon dont la CLI a été appelée.
Si l'objet n'est pas présent, déclenchez à nouveau la commande gdcloud compute images import .... Une fois que la sortie de la console passe de Uploading image to ... à Image import has started for ..., appuyez sur CTRL+C pour que l'image locale soit importée dans le stockage d'objets et que le VirtualMachineImageImport soit conservé pour référence afin d'en créer un.
Créez un VirtualMachineImageImport avec un minimumDiskSize plus grand :
Le pod importer-image-import-$VMII dans l'espace de noms du projet du cluster système plante avec l'erreur suivante : Unable to process data: Unable to transfer source data to target file: unable to write to file: stream error: stream ID 1; NO_ERROR; received from peer`). L'objet VMII VirtualMachineImageImport présente la condition Type Ready avec l'état False et le motif TranslationInProgress deux heures après le début de l'importation.
Solution :
Pour améliorer la vitesse, modifiez la taille de disque minimale de l'image sur 200 Gio comme suit :
Notez que pour supprimer et appliquer le ValidatingWebhookConfiguration, vous avez besoin du fichier kubeconfig de l'administrateur du cluster pour le cluster d'administrateur de l'organisation. Vous pouvez obtenir le runbook suivant : IAM-R0004.
Si vous utilisez gdcloud pour lancer l'importation, notez qu'il n'existe aucun moyen de fournir le paramètre minimumDiskSize. Vous devez créer un objet VMII et le modifier comme indiqué dans la commande précédente.
Le processus VirtualMachineImageImport se poursuit, mais se bloque à nouveau à une étape ultérieure. Dans l'espace de noms du projet du cluster système, le job image-import-$VMII échoue en permanence avec l'erreur error: stream error: stream ID x; NO_ERROR; received from peer. À ce stade, l'importation d'images est terminée. L'image finale est importée dans le stockage d'objets, mais le VirtualMachineImage est manquant. Vous pouvez créer manuellement un VirtualMachineImage comme suit :
`$NAME` doit correspondre à `VMII.ImageMetadata.Name`, et `$OS_NAME` peut être l'une des valeurs suivantes : [`ubuntu-2004`, `ubuntu-2204`, `windows-2019`, `rhel-8`]. Il doit correspondre au type d'image importée.
Le déploiement istio-eastwestgateway dans l'espace de noms istio-system est bloqué, et les événements de pod affichent une erreur Back-off pulling image "auto" provenant de kubelet.
Pour diagnostiquer le problème, vérifiez si le mutatingwebhookconfiguration nommé istio-revision-tag-default existe dans le même cluster que le déploiement de passerelle bloqué.
Si la configuration n'existe pas, attendez que le webhook existe, ce qui devrait se produire sous peu, car il se trouve dans une boucle de réconciliation.
Modifiez le configMap cortex-config dans le cluster système et définissez le délai avant expiration de memcached dans index_cache sur deux secondes afin que la configuration index_cache se présente comme suit :
Le nœud Bare Metal s'affiche sous la forme NotReady et le serveur est bloqué sur l'écran de démarrage avec le dernier message Retrieving encryption keys.
Solution :
Redémarrez iLO.
Une fois iLO de nouveau opérationnel, redémarrez le serveur.
L'emplacement de l'installateur fluent-bit est passé à operations_center\bin\fluent-bit-win64.msi.
Copy-ConfigHostFiles.ps1 s'attend à ce que le programme d'installation du client fluent-bit corresponde au modèle fluent-bit-*-win64.*.
Le programme d'installation ne trouve pas le programme d'installation, car ce modèle ne correspond plus.
L'emplacement du programme d'installation de Nessus a été modifié et se trouve désormais à l'adresse operations_center\bin\NessusAgent-x64.msi.
Copy-ConfigHostFiles.ps1 s'attend à ce que le programme d'installation du client corresponde au nom de fichier /NessusAgent-10.4.1-x64.msi.
Le programme d'installation ne trouve pas le programme d'installation, car ce modèle ne correspond plus.
Modifiez les lignes précédentes pour ajouter l'emplacement correct du programme d'installation, en remplaçant Nessus-10.4.1-x64.msi par NessusAgent-x64.msi :
Ce problème est dû à l'absence de configuration du point de terminaison S3 pour la nouvelle organisation.
Solution :
Créez manuellement un groupe HA pour la nouvelle organisation.
Grâce à la procédure de récupération d'urgence, obtenez un fichier kubeconfig du cluster administrateur racine qui dispose d'un accès en lecture aux ressources suivantes :
Récupérez les identifiants de connexion à l'interface utilisateur de gestion StorageGRID à partir du secret gpc-system/objectstorage-breakglass-root-level1 dans le cluster root-admin.
Connectez-vous à l'interface utilisateur de gestion StorageGRID avec les identifiants de l'étape précédente. L'URL est à l'état ObjectStorageSite :
Accédez à l'onglet Configuration, puis cliquez sur Groupes à haute disponibilité.
Ouvrez la vue détaillée de chaque groupe HA et notez son adresse IP virtuelle (VIP).
Créez un groupe HA :
Nom du groupe : le modèle de nom est ORGANIZATION_NAME-ha. Dans ce cas, il s'agit de org-2-ha.
Description du groupe : utilisez les groupes à haute disponibilité existants pour le modèle de description.
Interfaces : sélectionnez toutes les interfaces eth2.
Ordre de priorité : l'interface principale doit avoir la priorité la plus élevée.
SubnetCIDR : ce champ est rempli automatiquement par StorageGRID.
Vérifiez que le sous-réseau correspond à status.ipv4SubnetStatus.cidrBlock dans SubnetClaimexternal-objectstorage-client-lif-cidr.
Adresse IP virtuelle : prochaine adresse IP disponible dans la plage d'adresses IP. L'adresse IP ne peut pas entrer en conflit avec l'adresse IP réservée, l'adresse IP du client du nœud d'administration ni les adresses IP virtuelles des groupes HA existants.
Effectuez une rotation des identifiants StorageGRID "break glass".
Lorsque vous mettez à niveau l'organisation racine de la version 1.12.2 vers la version 1.12.4, le sous-composant iac-gitlab présente un état de réconciliation en cours.
Pour diagnostiquer le problème, consultez les journaux Prometheus, par exemple :
Si ce problème se produit lors de la mise à niveau, supprimez le job de migration, car il a un délai d'expiration de 3 600 secondes, puis poursuivez la mise à niveau :
Reportez-vous au message d'erreur précédent et notez l'espace de noms et le nom du déploiement. Dans cet exemple, NAME est iam-authzpdp-backend-server et NAMESPACE est iam-system.
Notez le pod dont tous les conteneurs ne sont pas prêts. Dans ce cas, POD_NAME est iam-authzpdp-backend-server-6875654c4b-pvscg, ce qui signifie que l'un des deux conteneurs n'est pas prêt, comme l'indique l'état 1/2. S'il existe plusieurs pods de ce type, répétez l'étape suivante pour chaque pod concerné.
Supprimez le pod qui n'est pas entièrement opérationnel :
kubectldeletepod-nNAMESPACEPOD_NAME>
Exécutez à nouveau la commande de l'étape 2. Notez que tous les pods devraient maintenant être opérationnels. Cette étape peut prendre quelques minutes.
Si le pod supprimé n'est pas remplacé par un pod opérationnel, ouvrez une demande d'assistance.
Lors de la mise à niveau de l'organisation locataire de la version 1.12.2 à la version 1.12.4, la mise à niveau du sous-composant opa gatekeeper échoue avec un ReconciliationError.
Solution :
Modifiez l'objet mutatingwebhookconfigurationedr-sidecar-injector-webhook-cfg du cluster d'utilisateur concerné. S'il existe plusieurs clusters d'utilisateur concernés, répétez les étapes pour chacun d'eux :
Modifiez la section webhooks > (edr-sidecar-injector.gpc-system.internal) > namespaceSelector > matchExpressions > (key: kubernetes.io/metadata.name) > values pour y ajouter les deux valeurs suivantes :
opa-system
cert-manager
L'objet mis à jour devrait se présenter comme suit :
Lors de la mise à niveau de la version 1.12.2 vers la version 1.12.4, le ansibleplaybook n'est pas mis à niveau en même temps que le cluster. Les correctifs mis à jour dans ansibleplaybook ne sont pas appliqués et bloquent la stratégie OS qui exécute la version précédente de ansibleplaybook.
Solution :
Supprimez le job Kubernetes create-ansible-playbooks :
Lorsque vous créez une organisation, le sous-composant core-dns peut expirer dans les journaux :
[INFO]192.0.2.0:60741-40400"A IN objectstorage-tenant-mgmt.gdch.example.com. udp 72 false 1232"--02.000828817s
[ERROR]plugin/errors:2objectstorage-tenant-mgmt.gdch.example.com.A:readudp10.244.4.184:59927->192.0.2.1:53:i/otimeout
[INFO]192.0.2.0:51401-5813"AAAA IN objectstorage-tenant-mgmt.gdch.example.com. udp 72 false 1232"--02.000585231s
[ERROR]plugin/errors:2objectstorage-tenant-mgmt.gdch.example.com.AAAA:readudp10.244.4.184:48542->192.0.2.1:53:i/otimeout
Solution :
Mettez à jour les services gpc-coredns-forwarder-udp et gpc-coredns-forwarder-tcp du cluster d'administrateur racine, et ajoutez vos nouvelles plages d'adresses IP dans les plages sources de l'équilibreur de charge.
Si les modifications du CR sont remplacées, mettez en veille le sous-composant dns-core avec l'annotation lcm.private.gdc.goog/paused="true".
Lors de la mise à niveau de la version 1.12.2 à la version 1.12.4, le sous-composant file-netapp-trident reste bloqué sur la suppression de StorageClasses. L'état suivant s'affiche :
status:
backendStatus:
conditions:
-lastTransitionTime:"2024-05-02T06:04:14Z"message:'E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks" found'observedGeneration:2reason:ReconciliationError
status:"True"type:Reconciling
-lastTransitionTime:"2024-04-08T00:12:53Z"message:Successfullypulledchart
observedGeneration:2reason:ChartPullDone
status:"True"type:ChartPull
-lastTransitionTime:"2024-05-01T10:10:08Z"message:Fetchedparametersfromdefault,runtime
observedGeneration:2reason:ParametersDone
status:"True"type:Parameters
-lastTransitionTime:"2024-05-02T06:04:04Z"message:'E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks" found'observedGeneration:2reason:DeployError
status:"False"type:Deployed
-lastTransitionTime:"2024-04-23T06:50:12Z"message:Readinesscheckjobpassed
observedGeneration:1reason:ReadinessCheckDone
status:"True"type:Ready
deploymentFinished:falselastDeployTimestamp:"2024-05-02T06:03:16Z"readyAfterDeploy:trueversion:""conditions:
-lastTransitionTime:"2024-05-02T06:04:14Z"message:'Reconciliation error: E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks" found'observedGeneration:2reason:ReconciliationError
status:"True"type:Reconciling
crdsStatus:
conditions:
-lastTransitionTime:"2024-04-07T08:02:33Z"message:Successfullypulledchart
observedGeneration:2reason:ChartPullDone
status:"True"type:ChartPull
-lastTransitionTime:"2024-04-07T08:02:33Z"message:Noparameterstofetch
observedGeneration:2reason:ParametersDone
status:"True"type:Parameters
-lastTransitionTime:"2024-04-07T08:02:34Z"message:Readinesssourceisempty
observedGeneration:2reason:ReadinessCheckSkipped
status:"True"type:Ready
-lastTransitionTime:"2024-05-01T18:37:52Z"message:Ready
observedGeneration:2reason:ReconciliationCompleted
status:"False"type:Reconciling
deploymentFinished:truelastDeployTimestamp:"2024-05-02T06:04:03Z"readyAfterDeploy:trueversion:1.12.3-gdch.312
Solution :
Mettez en veille le sous-composant file-netapp-trident :
## Set KUBECONFIG to root-admin KUBECONFIGexportKUBECONFIG=ROOT_ADMIN_KUBECONFIGkubectlannotatesubcomponentfile-netapp-trident-n$cluster_namespacelcm.private.gdc.goog/paused=true
Supprimez le StorageClasses que la tâche n'a pas réussi à créer, comme standard-rwo, standard-block, standard-rwo-non-luks et standard-block-non-luks :
Déclenchez la recréation de StorageClasses en redémarrant le contrôleur oclcm-backend-controller pour votre cluster (contrôleur root-admin pour les clusters root et d'administrateur d'organisation, contrôleur org-admin pour les clusters système et d'utilisateur) :
Les pods primary-prometheus-shardX-replicaX sont visibles dans l'espace de noms obs-system et dans l'espace de noms mon-system. Si le primary-prometheus-shardX-replicaX n'existe que dans l'espace de noms obs-system après une mise à niveau vers la version 1.12, il s'agit d'un autre problème inconnu et la solution de contournement ne doit pas être appliquée.
Le comportement prévu est que primary-prometheus-shardX-replicaX n'existe que dans l'espace de noms mon-system une fois la mise à niveau vers la version 1.12 terminée.
Solution :
Supprimez manuellement les StatefulSets primary-prometheus-shardX-replicaX dans l'espace de noms obs-system.
Ne supprimez pas les StatefulSets primary-prometheus-shardX-replicaX dans l'espace de noms mon-system.
Un ClusterCIDRConfig est un objet requis pour attribuer PodCIDRs. Bien que le ClusterCIDRConfig ait été créé, le PodCIDRs n'a pas été attribué. Ce problème se produit si un ClusterCIDRConfig est créé en même temps que les pods ipam-controller sont en cours d'amorçage. La création du cluster est bloquée dans l'état de rapprochement :
Vérifiez si l'objet ClusterCIDRConfig est créé sur le cluster :
Exécutez la commande "describe" pour l'un des objets de nœud du cluster qui est bloqué dans la réconciliation, puis vérifiez si un événement CIDRNotAvailable est présent sur l'objet de nœud :
L'MonitoringTarget affiche l'état Not Ready lorsque des clusters d'utilisateur sont en cours de création, ce qui entraîne l'affichage continu de l'état Enabling dans l'interface utilisateur pour les API pré-entraînées.
Solution :
Ouvrez le menu de votre navigateur Chrome (icône à trois points).
Cliquez sur Plus d'outils > Outils pour les développeurs pour ouvrir la console.
Cliquez sur l'onglet Réseau dans la console.
Recherchez les demandes ai-service-status.
Cliquez sur l'onglet Réponse d'une requête ai-service-status pour afficher le contenu de cette requête.
Vérifiez que tout semble prêt, à l'exception des composants MonitoringTarget et LoggingTarget.
Lorsque vous mettez à niveau le stockage d'objets, un avertissement semblable à celui-ci peut s'afficher :
TypeReasonAgeFromMessage
-------------------------
WarningReconcileError55m(x2over55m)ObjectStorageAdminNodeReconcilerReconcileerror,retrying:errorstoringthesshcreds:500InternalServerError:ErrorMessage:{"text":"The GDU service is currently busy. Try again later. Contact technical support if the issue persists.","key":"maintenance.gdu.gdu_server_locked
Solution :
Vérifiez que chaque nœud dispose d'identifiants SSH correspondants stockés dans un secret.
Lors des mises à niveau, le cluster de base de données Translation est recréé, ce qui entraîne l'obsolescence et la désynchronisation du secret secret-store du cluster système ODS. C'est pourquoi l'initialisation du pod et du service de l'interface de traduction échoue.
Le serveur ne peut pas se connecter au gestionnaire de clés, ce qui empêche l'état du serveur de devenir disponible. Ce problème entraîne l'échec du job server-encrypt-and-create-logical-drive et l'indisponibilité du cluster d'administrateur. Une erreur semblable à celle-ci peut s'afficher dans les journaux des tâches :
Loki ne dispose que d'un seul volume persistant (PV) pour les journaux WAL (Write-Ahead Logs) et les index. Le WAL peut remplir le PV si un pod Loki ne parvient pas à se connecter au bucket de stockage pendant des heures. Si le PV n'a plus d'espace, Loki ne peut pas récupérer, sauf si vous supprimez le PV et redémarrez StatefulSet.
Solution :
Pour récupérer un pod Loki dans cet état, vous devez réduire l'échelle du StatefulSet correspondant et supprimer le PV sans espace disponible.
Pour récupérer le pod Loki :
Assurez-vous que le conteneur d'outils d'E/S est installé sur le poste de travail. Pour en savoir plus, consultez le manuel d'utilisation OOPS-P0065.
Pour obtenir les autorisations nécessaires pour modifier les ressources, demandez à votre Administrateur de sécurité de vous accorder les rôles suivants :
observability-viewer
observability-admin
Définissez la variable d'environnement KUBECONFIG avec le chemin d'accès au fichier kubeconfig dans le cluster d'administrateur racine. Pour en savoir plus, consultez le runbook IAM-R0004.
Définissez la variable d'environnement ORG_NAME sur le nom de l'organisation concernée.
Enregistrez le contenu suivant dans un fichier YAML nommé log-admin-overrides.yaml :
Définissez la variable d'environnement KUBECONFIG avec le chemin d'accès au fichier kubeconfig dans le cluster où le pod Loki concerné est en cours d'exécution. Pour en savoir plus, consultez le runbook IAM-R0004.
Définissez la variable d'environnement LOKI_POD_NAME avec le nom du pod Loki concerné.
Définissez la variable d'environnement KUBECONFIG avec le chemin d'accès au fichier kubeconfig dans le cluster d'administrateur de l'organisation concernée. Pour en savoir plus, consultez le runbook IAM-R0004.
Modifiez le contenu du fichier YAML log-admin-overrides.yaml comme suit :
Les jobs sont planifiés en continu. Dès qu'une tâche est terminée, une nouvelle tâche est planifiée. Voici les jobs qui sont planifiés en continu :
unet-networkpolicy-assets-parameter
unet-nodenetworkpolicy-assets-parameter
unet-nodenetworkpolicy-assets-readiness
unet-userclusterpolicy-assets-parameter
unet-clustermesh-backend-parameter
unet-clustermesh-backend-readiness
Solution :
Mettez en veille les sous-composants suivants :
unet-networkpolicy
unet-nodenetworkpolicy
unet-nodenetworkpolicy
unet-userclusterpolicy
unet-clustermesh
Réactivez les sous-composants chaque fois que le secret fleet-info est modifié dans le cluster d'administrateur racine. Ce problème se produit lorsque les commutateurs de gestion de l'instance sont modifiés, par exemple kr get managementswitches -A, ou lorsqu'un cidrclaim est modifié dans l'espace de noms de l'organisation.
Réactivez les sous-composants chaque fois qu'une ressource NodePool est modifiée dans le cluster d'administration de l'organisation. Réactivez les sous-composants avant de commencer.
Lors de la mise à niveau de la version 1.12.2 vers la version 1.12.4, un upstream opérationnel pour ServiceNow n'est pas disponible. Le message suivant peut s'afficher : failed to stage volume: LUKS passphrase cannot be empty.
La classe de stockage system-performance-rwo n'est pas activée pour LUKS. La pièce jointe du volume indique que le PVC est compatible avec LUKS.
Le reconciler recherche un secret contenant les phrases secrètes LUKS. Étant donné que la pièce jointe du volume indique qu'il est compatible avec LUKS, mais que la classe de stockage ne l'est pas, le mot de passe secret n'est pas créé.
Solution :
Obtenez le Kubeconfig pour le cluster racine ou d'administrateur de l'organisation où le problème se produit :
exportKUBECONFIG=${ROOT_OR_ORG_ADMIN_KUBECONFIG}
Supprimez la classe de stockage system-performance-rwo et recréez-la :
Lors de la mise à niveau de la version 1.12.2 vers la version 1.12.4, la mise à niveau de l'organisation est bloquée à l'étape NodeUpgrade et la tâche de mise à niveau du nœud affiche l'erreur suivante :
Obtenez le Kubeconfig pour le cluster racine ou d'administrateur de l'organisation où la mise à niveau du nœud échoue, puis vérifiez si nodeupgradetask a échoué :
kubelet continue d'imprimer le journal de spam suivant :
May2223:08:00control-1--f1c6edcdeaa9e08-e387c07294a9d3ab.lab.anthoskubelet[3751]:time="2024-05-22T23:08:00Z"level=warningmsg="Failed to remove cgroup (will retry)"error="rmdir /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy"
……
May2223:09:04control-1kubelet[3751]:time="2024-05-22T23:09:04Z"level=warningmsg="Failed to remove cgroup (will retry)"error="rmdir /sys/fs/cgroup/net_cls,net_prio/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy"
Le processus runc init est figé, ce qui empêche kubelet de supprimer le pod cgroup.
Solution :
Utilisez le script suivant pour trouver le processus qui bloque la suppression de cgroup :
# Find matching cgroup directoriesMATCHING_CGROUPS=$(find/sys/fs/cgroup-typed-name"*74353c*")if[-z"$MATCHING_CGROUPS"];thenecho"No cgroups found containing 'd06aac'."exit0fiecho"Matching cgroups:"forcgroupin$MATCHING_CGROUPS;doecho"- $cgroup"# Print cgroup path# Check if cgroup.procs existsif[-f"$cgroup/cgroup.procs"];thenecho" Processes:"# List PIDs in cgroup.procsforpidin$(cat"$cgroup/cgroup.procs");do# Get process detailsps-opid,comm,cmd--no-headers$pid2>/dev/null# Suppress errors if process doesn't existdoneelseecho" No cgroup.procs file found."# Handle cases where cgroup.procs is missingfiecho# Add a newline for better readabilitydone
Vérifiez l'état du congélateur à l'aide de cat freezer.state. L'état doit être FROZEN.
Echo "THAWED" > freezer.state
cgroup a bien été supprimé. Kubelet arrête le spamming du journal.
PTaaS est déployé dans l'organisation gdchservices.
Inspectez les annotations et les libellés du projet PTaaS gdch-perftest et du bucket perftest-bucket-reports dans l'espace de noms perftest gdch-perftest. Il est possible que le bucket ne comporte pas le libellé app.kubernetes.io/managed-by=Helm ni les annotations meta.helm.sh/release-name=perf-ptaas-assets et meta.helm.sh/release-namespace=gdch-perftest.
Ajoutez manuellement les libellés et annotations suivants :
Inspectez les annotations du projet PTaaS gdch-perftest. Il est possible que le projet soit mal configuré avec l'annotation meta.helm.sh/release-name=perf-ptaas-assets.
Remplacez cette annotation par meta.helm.sh/release-name=perf-ptaas-backend :
Vérifiez que le sous-composant est réconcilié dans le cluster root-admin :
kubectlgetsubcomponent-ngdchservicesperf-ptaas
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/23 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/23 (UTC)."],[],[]]
