Cette page répertorie les problèmes connus du mode privé d'Anthos et vous explique comment les éviter ou les résoudre.
La création de clusters d'administrateur reste dans waiting for node update jobs
La création d'un cluster d'administrateur prend généralement environ 30 minutes. Si le cluster est bloqué pendant une longue période sur la phase "attente des tâches de mise à jour des nœuds", vous pouvez terminer le processus par Ctrl + C. Cette phase est la dernière étape de l'installation.
L'arrêt de ce processus n'affecte pas l'installation.
La création de cluster d'utilisateur est bloquée.
La création d'un cluster d'utilisateur prend généralement environ 10-30 minutes. Si le cluster semble bloqué, vous pouvez utiliser les commandes ci-dessous pour vérifier sa progression.
kubectl get pods -n cluster-USER_CLUSTER --kubeconfig=ADMIN_KUBECONFIG
kubectl get Cluster -n cluster-USER_CLUSTER -o yaml --kubeconfig=ADMIN_KUBECONFIG
La mise à niveau d'un cluster d'administrateur avec plusieurs nœuds de plan de contrôle est bloquée
La mise à niveau d'un cluster d'administrateur peut rester bloquée lorsque vous mettez à niveau des nœuds du plan de contrôle.
La commande de mise à niveau indique Waiting for upgrade to complete... Upgrading <control plane node IP>.
Le problème n'affecte le cluster d'administrateur que s'il est configuré avec toutes les conditions suivantes :
Le registre privé configuré utilise un certificat signé par une autorité de certification privée.
Le cluster d'administrateur est configuré avec plusieurs nœuds du plan de contrôle (par exemple, s'il est configuré pour la haute disponibilité).
dockerest installé sur les nœuds du plan de contrôle.
Ce problème est dû à une erreur de configuration lors de la tentative de récupération du fichier de l'autorité de certification du registre au mauvais emplacement. Pour le résoudre, vous devez répartir manuellement le fichier de l'autorité de certification dans chaque nœud. Par exemple, exécutez le script suivant à partir du poste de travail administrateur :
#!/bin/bash
# Docker login to generate the $HOME/.docker/config.json file
docker login REGISTRY_HOST
# List the IP addresses for all the control plane nodes, separated by whitespace.
IPs=( NODE_IPS_SEPARATED_BY_SPACE )
for ip in "${IPs[@]}"; do
# Copy the docker config over to the nodes.
scp $HOME/.docker/config.json USER_NAME@${ip}:docker-config.json
# Fix the image pull credentials issue
ssh USER_NAME@${ip} "sudo mkdir -p /root/.docker && sudo cp docker-config.json /root/.docker/config.json"
# Fix the cert issue, only needed for private registry with self-signed certs.
ssh USER_NAME@${ip} "sudo mkdir -p /etc/docker/certs.d && sudo cp -r /etc/containerd/certs.d/REGISTRY_HOST /etc/docker/certs.d/"
done
Remplacez USER_NAME et REGISTRY_HOST par les valeurs configurées dans la configuration du cluster d'administrateur.
Erreur d'autorisation 400 pour l'accès avec une adresse IP privée
Après avoir configuré l'authentification Open ID Connect (OIDC), si vous utilisez toujours une adresse IP pour accéder au centre de gestion, vous êtes redirigé vers la page d'authentification et obtenez une erreur liée à l'autorisation pour l'accès avec adresse IP privée. Exemple :
En utilisant le nom de domaine que vous avez configuré au lieu de l'adresse IP pour accéder à la plate-forme, exécutez actl platform management-center describe pour récupérer l'adresse complète. Le domaine est requis pour la redirection. Votre domaine peut pointer vers l'adresse privée.
Réponse d'échec HTTP 500 lors de la création de l'administrateur initial de la plate-forme
Lors de l'application d'un profil OIDC aux clusters, vous pouvez recevoir une réponse d'échec HTTP 500 après avoir cliqué sur Envoyer si le nom d'utilisateur ou le préfixe de groupe du profil contient le caractère "/".
Pour résoudre ce problème, supprimez et créez un profil sans le caractère "/" dans le nom d'utilisateur et dans le préfixe de groupe, puis essayez d'appliquer le nouveau profil aux clusters.
RBAC: accès refusé
Si le message RBAC: access denied s'affiche après vous être connecté avec un compte administrateur de plate-forme, il se peut qu'il y ait une erreur dans les paramètres OIDC. Consultez la section Réinitialiser la configuration d'authentification.
Utiliser des images d'un registre privé lorsque la configuration de mise en miroir du registre est utilisée
Si le cluster est configuré à l'aide de la configuration de mise en miroir du registre, notez le chemin d'accès de l'image lorsque vous utilisez une image directement du registre privé.
Par exemple, si le cluster d'administrateur est créé à l'aide de la configuration de mise en miroir:
registryMirrors:
- endpoint: https://10.200.0.2/v2/library
Une image est importée dans le registre privé par docker push 10.200.0.2/library/test-image:test-tag. Lors de la création d'un déploiement ou d'un pod, l'image 10.200.0.2/library/test-image:test-tag ne peut pas être utilisée directement telle quelle. En effet, la configuration containerd du nœud (/etc/containerd/config.toml) est configurée pour mettre en miroir toutes les extractions d'images à partir de 10.200.0.2/library. containerd tente ensuite d'extraire l'image de 10.200.0.2/library/library/test-image:test-tag.
Pour contourner ce problème, essayez l'une des procédures suivantes :
- Transférer l'image sous le point de terminaison
docker push 10.200.0.2/library/library/test-image:test-tag - Utiliser le chemin d'accès de l'image
10.200.0.2/test-image:test-tag
Impossible de mettre à jour le centre de gestion de 0,8 vers 0,9 lorsqu'OIDC est défini
La mise à jour du centre de gestion de 0,8 vers 0,9 lorsqu'OIDC est défini échoue avec le message d'erreur suivant :
level=fatal msg="Unable to initialize options: unable to resolve management center cluster: The given \"management center\" cluster \"admin-admin@admin\" does not appear to be a valid management center cluster. Did you choose the right cluster?\nunable to list DomainIDPMapping objects: the server could not find the requested resource"
Pour contourner ce problème, créez un fichier avec le CRD DomainIDPMapping.
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: v0.4.0
creationTimestamp: null
name: domainidpmappings.managementcenter.anthos.cloud.google.com
spec:
group: managementcenter.anthos.cloud.google.com
names:
kind: DomainIDPMapping
listKind: DomainIDPMappingList
plural: domainidpmappings
singular: domainidpmapping
scope: Cluster
versions:
- name: v1alpha1
schema:
openAPIV3Schema:
description: DomainIDPMapping is the Schema for the domainidpmappings API
properties:
apiVersion:
description: 'APIVersion defines the versioned schema of this representation
of an object. Servers should convert recognized schemas to the latest
internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
type: string
kind:
description: 'Kind is a string value representing the REST resource this
object represents. Servers may infer this from the endpoint the client
submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
type: string
metadata:
type: object
spec:
description: DomainIDPMappingSpec is the struct that contains the mapping
from the domain to the authentication method name specified in the AIS
ClientConfig.
properties:
authMethodName:
description: AuthMethodName is the name of the authentication method
configured in the AIS ClientConfig.
type: string
domainName:
description: DomainName is the domain used to serve the Anthos web
endpoints. The domain should not include the protocol such as http
or https. Wild cards are not supported in the domain name.
type: string
required:
- authMethodName
- domainName
type: object
type: object
served: true
storage: true
status:
acceptedNames:
kind: ""
plural: ""
conditions: []
storedVersions: []
Appliquez l'objet CRD.
kubectl --kubeconfig=ADMIN_KUBECONFIG apply -f domainIDPMappingCRD.yaml
Supprimez les espaces de noms EnvoyFilter et oauth2-proxy.
kubectl --kubeconfig=ADMIN_KUBECONFIG delete envoyfilter istio-ingressgateway -n istio-system
kubectl --kubeconfig=ADMIN_KUBECONFIG delete namespace oauth2-proxy
Erreur lors de l'extraction de l'image pour les pods avec le préfixe anthos-log-forwarder
Si --private-registry est activé lors de l'installation du cluster, le chemin d'accès à l'image utilisé par initContainer dans le chemin anthos-log-forwarder ne sera pas écrasé par le chemin spécifié dans le fichier --private-registry. Cette opération ne se produira que dans le cluster d'administrateur.
Par exemple, si vous rencontrez l'erreur suivante dans le cluster d'administrateur :
kubectl -n kube-system get pods --selector=app=anthos-log-forwarder
anthos-log-forwarder-2n96b 0/1 Init:ErrImagePull 0 16s
anthos-log-forwarder-8fxm8 0/1 Init:ErrImagePull 0 16s
anthos-log-forwarder-bh7rb 0/1 Init:ImagePullBackOff 0 16s
Seul le cluster d'administrateur dont la propriété --private-registry est définie sera affecté par ce problème, qui sera corrigé dans la prochaine version.
Échecs de connectivité du pod et filtrage du chemin d'accès inverse
Le mode privé d'Anthos configure le filtrage du chemin d'accès inverse sur les nœuds pour désactiver la validation de la source (net.ipv4.conf.all.rp_filter=0). Si le paramètre rp_filter est défini sur 1 ou 2, les pods échouent en raison de délais de communication hors nœud.
Le filtrage du chemin d'accès inverse est défini par les fichiers rp_filter dans le dossier de configuration IPv4 (net/ipv4/conf/all). Cette valeur peut également être remplacée par sysctl, qui stocke les paramètres de filtrage du chemin d'accès inverse dans un fichier de configuration de sécurité réseau, tel que /etc/sysctl.d/60-gce-network-security.conf.
Pour restaurer la connectivité du pod, redéfinissez net.ipv4.conf.all.rp_filter manuellement sur 0 ou redémarrez le pod anetd pour redéfinir net.ipv4.conf.all.rp_filter sur 0. Pour redémarrer le pod anetd, exécutez les commandes suivantes afin de localiser et de supprimer le pod anetd, et un nouveau pod anetd démarrera à sa place :
kubectl get pods -n kube-system
kubectl delete pods -n kube-system ANETD_XYZ
Remplacez ANETD_XYZ par le nom du pod anetd.
La page "Machines" ne liste aucune machine après la mise à niveau
Redémarrez le pod anthos-cluster-operator.
kubectl --kubeconfig ADMIN_KUBECONFIG delete pods -l control-plane=anthos-cluster-operator -n kube-system
Impossible de modifier les clusters d'utilisateur après la mise à niveau
Redémarrez le pod anthos-cluster-operator.
kubectl --kubeconfig ADMIN_KUBECONFIG delete pods -l control-plane=anthos-cluster-operator -n kube-system