Documentation de référence sur les codes d'erreur d'Anthos

Les messages d'erreur d'Anthos se composent d'un ID d'erreur au format APME1234 où 1234 est un numéro unique, suivi d'une description du problème et d'une suggestion pour le résoudre. Ce document répertorie chacun de ces messages d'erreur.

APME1000 ImageAccessError

Cette erreur indique que le composant qui a généré l'erreur ne trouve pas une ou plusieurs des images requises dans le registre spécifié.

Veuillez procéder aux vérifications suivantes :

Les images requises existent dans Container Registry.
Le registre est accessible depuis l'origine de l'erreur.
Le poste de travail est autorisé à lire et à extraire du registre.
Le poste de travail contient le fichier ${HOME}/.docker/config.json et il est correctement configuré pour accéder au registre.

APME1001 InvalidRegistryInputError

La valeur de l'indicateur --private-registry doit respecter le format hostname[:port]/repository/location et ne peut pas commencer par un schéma (tel que https://). Le nom d'hôte ne peut pas être localhost ou 127.0.0.1. La valeur est utilisée par Kubernetes pour récupérer les images.

Exemples de valeurs d'options :

fictional.registry.example/repository/location
fictional.registry.example:10443/repository/location
10.200.0.2/library

APME2000 KubeContextNotFoundError

Cette erreur indique que le kubecontext spécifié est introuvable.

Veuillez vérifier que :

Le fichier KUBECONFIG existe.
Le fichier $HOME/.kube/config existe lorsque la variable d'environnement KUBECONFIG n'est pas spécifiée.
Le contexte existe dans le fichier KUBECONFIG.

APME2001 UserClusterKubeconfigError

Cette erreur indique que le fichier kubeconfig du cluster d'utilisateur est introuvable.

Veuillez vérifier que :

L'espace de noms cluster-CLUSTER_NAME existe dans le cluster d'administrateur.
Les objets de cluster existent sous l'espace de noms cluster-CLUSTER_NAME.
Le secret CLUSTER_NAME-kubeconfig existe sous l'espace de noms cluster-CLUSTER_NAME.
Vous disposez de toutes les autorisations nécessaires pour accéder aux objets mentionnés ci-dessus.

APME2002 ManagementCenterNotSchedulableError

Cette erreur indique que le centre de gestion Anthos ne peut pas être programmé pour s'exécuter sur les nœuds d'un cluster.

Cette erreur peut généralement se produire si le cluster d'administrateur ne comporte aucun nœud de calcul. Par défaut, votre cluster ne planifie pas les charges de travail sur le nœud du plan de contrôle pour des raisons de sécurité.

Pour résoudre ce problème :

[À privilégier] Ajoutez un pool de nœuds de calcul au cluster d'administrateur.

KUBECONFIG=${ADMIN_KUBECONFIG} kubectl apply -f <path/to/example-nodepool.yaml>

Exemple de code YAML :

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: node-pool-1
  namespace: cluster-admin
spec:
  clusterName: admin
  nodes:
  - address: <IP address of the worker node machine. e.g. 10.200.0.4>

Supprimez le rejet de plan de contrôle des nœuds du plan de contrôle afin de permettre aux charges de travail non système de s'exécuter sur ces nœuds.

REMARQUE : gardez à l'esprit les inconvénients de cette solution :
- Disponibilité du plan de contrôle : l'exécution de charges de travail supplémentaires augmente l'entropie sur les nœuds du plan de contrôle. Si la machine est déjà limitée par des ressources, si elle est mal configurée ou si la charge de travail présente un comportement inattendu, cela peut avoir un impact négatif sur le serveur d'API Kubernetes.
- Sécurité : les conteneurs ne constituent pas une limite de sécurité élevée. Si une charge de travail malveillante échappe du conteneur, elle peut prendre le contrôle du plan de contrôle du cluster. Si le cluster gère d'autres clusters d'utilisateur, le pirate peut accéder aux identifiants du cluster d'administrateur et prendre le contrôle des clusters d'utilisateur.
- Coût : le mode déconnecté d'Anthos ne facture pas les nœuds de plan de contrôle tant que le rejet node-role.kubernetes.io/master:NoSchedule est présent. Une fois que vous avez supprimé le rejet et activé l'exécution des charges de travail d'utilisateur sur les nœuds du plan de contrôle, la facturation s'applique de façon identique à tous les autres nœuds. Consultez la page Tarifs pour en savoir plus.
Exemple de commande permettant aux charges de travail de s'exécuter sur tous les nœuds du plan de contrôle :
```
KUBECONFIG=${ADMIN_KUBECONFIG} kubectl taint nodes --all node-role.kubernetes.io/master:NoSchedule-
```

APME2003 AdminClusterNotUpgradedError

Cette erreur indique que le cluster d'administrateur doit être mis à niveau avant de mettre à niveau le centre de gestion.

Le centre de gestion de la nouvelle version d'Anthos en mode déconnecté peut nécessiter une exécution sur la nouvelle version du cluster d'administrateur.

Mettez à jour le fichier de configuration du cluster d'administrateur et exécutez la commande actl clusters baremetal upgrade admin pour terminer la mise à niveau. Pour obtenir des instructions détaillées, consultez la section Mettre à niveau le cluster d'administrateur.

APME3000 AISLoginClientValidationError

Obsolète dans Anthos 1.9

APME3001 PermissionDeniedError

L'erreur indique que les autorisations sont insuffisantes pour effectuer l'action.

Pour tenter de résoudre le problème de façon plus poussée :

Identifiez le rôle attribué.

Méthode 1 : Utiliser la console du centre de gestion Anthos
- Ouvrez l'onglet Identity and Access dans la console du centre de gestion.
- Accédez à l'onglet Access de l'écran Identity and Access pour afficher le rôle attribué.
Méthode 2 : Utiliser la commande kubectl

kubectl get
    rolebinding,clusterrolebinding --all-namespaces -o jsonpath='{range
    .items[?(@.subjects[0].name=="{your
    account}")]}[{.roleRef.kind},{.roleRef.name}]{end}'

Example: kubectl get rolebinding,clusterrolebinding --all-namespaces -o
jsonpath='{range
.items[?(@.subjects[0].name=="foo@bar.com")]}[{.roleRef.kind},{.roleRef.name}]{end}'
[ClusterRole,anthos-platform-admin-read-only]

Consultez la section Rôles d'autorisation prédéfinis et autorisations pour afficher les autorisations disponibles pour les rôles d'autorisation prédéfinis.
Si un rôle de moindre privilège est attribué et qu'un rôle de privilège plus élevé est nécessaire pour effectuer une action donnée ou que le rôle a été mal attribué, demandez aux administrateurs de vérifier si l'accès peut être accordé.
Si le rôle dispose des autorisations suffisantes pour l'action conformément aux rôles d'autorisation prédéfinis et que les autorisations APME3001-PermissionDeniedError sont incorrectement signalées, signalez un bug à l'adresse anthos-private-mode-feedback@google.com.

APME3002 AuthMethodPreflightCheckError

L'erreur indique que le paramètre de méthode d'authentification fourni ne peut pas passer l'étape de vérification préliminaire.

Si vous avez fourni un paramètre OIDC :

Vérifiez que l'URL d'accès au fournisseur OIDC est correcte.
Assurez-vous que la page de découverte de configuration OpenID https://<your OIDC provider URL>/.well-known/openid-configuration est accessible et contient une configuration valide.
Si votre fournisseur OIDC utilise un certificat SSL autosigné, veillez à le saisir dans le champ de certificat du fournisseur OIDC.

APME3003 UserCredentialNotFoundError

Cette erreur indique que l'action demandée ne peut pas être effectuée sans identifiant utilisateur.

Pour effectuer la requête, activez l'authentification ou demandez à votre administrateur de l'activer. Consultez la page S'authentifier avec OIDC pour configurer l'authentification OIDC.

APME4001 ObservabilityOperatorUpgradeError

Cette erreur indique qu'une défaillance s'est produite lors de la mise à niveau des composants d'observabilité (dans le cadre de la mise à niveau du mode déconnecté d'Anthos). La pile d'observabilité mise à niveau peut toujours fonctionner malgré l'apparition de cette erreur.

Pour vérifier si la pile d'observabilité mise à niveau fonctionne, vérifiez le status de la condition Installed sur l'objet default du type Observability dans l'espace de noms anthos-management-center :

kubectl get -n anthos-management-center observability default -o jsonpath='
{.status.conditions[?(@..type=="Installed")].status}{"\n"}'

Si la valeur de status est True, la pile d'observabilité fonctionne toujours. Les procédures d'atténuation mentionnées dans le rapport d'erreurs sont facultatives. Si l'état n'est pas True, suivez les procédures d'atténuation mentionnées dans le rapport d'erreurs.

Étapes suivantes

En savoir plus sur les problèmes connus.