Problèmes liés à l'installation du mode privé Anthos

Cette page explique comment résoudre les problèmes que vous pouvez rencontrer lors de l'installation ou de la mise à niveau du mode privé d'Anthos.

Conditions préalables au dépannage

Le mode privé d'Anthos nécessite une connexion à un poste de travail d'administrateur pour que vous puissiez commencer à résoudre les problèmes. Pour vous connecter à votre poste de travail d'administrateur, exécutez la commande suivante :

ssh <USERNAME>@<WORKSTATION>
cd ./anthos-baremetal-private-mode
export PATH=$PWD/bin:$PATH

Remarque : La commande SSH exacte peut varier en fonction de votre environnement.

Créer un cluster

Cette section explique comment résoudre les problèmes liés à la création de clusters en mode privé d'Anthos.

Échec de la création du cluster d'administrateur

Cette section présente les erreurs courantes de configuration du cluster d'administrateur et les erreurs préliminaires, ainsi que des suggestions pour les corriger.

Erreurs de configuration

Les problèmes de configuration courants du cluster d'administrateur incluent une annotation manquante dans la configuration, l'absence de configuration d'authentification pour le registre et une erreur lors de la création du cluster d'amorçage.

Annotation manquante dans la configuration

Si lors de la création de ressources du pool de nœuds, votre fichier de configuration n'inclut pas d'annotation, vous pouvez rencontrer l'erreur suivante :

Cluster.baremetal.cluster.gke.io "admin" is invalid: [Spec.LoadBalancer.AddressPools: Forbidden: Field not allowed for admin clusters, Spec.GKEConnect: Required value: Field is required].

Pour résoudre ce problème, ajoutez une annotation à votre fichier de configuration de cluster d'administrateur et définissez l'annotation sur true :

annotations:
    baremetal.cluster.gke.io/private-mode: "true"

Consultez la section Cluster d'administrateur et pool de nœuds pour obtenir un exemple d'annotation appliquée dans un fichier de configuration de cluster d'administrateur.

Configuration de l'authentification manquante pour le registre

Si la configuration de l'authentification est manquante, vous pouvez rencontrer l'erreur no auth config found for the registry.

Assurez-vous que la valeur pullCredentialConfigPath spécifiée dans le fichier admin.yaml contient la configuration d'authentification pour le point de terminaison. Par exemple, si le point de terminaison est https://10.200.0.2 et que la valeur de pullCredentialConfigPath est /root/.docker/config.json, le fichier config.json contient l'entrée d'authentification suivante :

{
        "auths": {
                "10.200.0.2": {
                        "auth": "<base64 encoded auth>"
                }
        }
}

Si l'entrée d'authentification du registre est absente, mettez à jour le fichier config.json en vous connectant au registre :

docker login <registry> -u <username> -p <password>

Erreur lors de la création du cluster d'amorçage

Vous pouvez rencontrer l'erreur suivante lors de la création de votre cluster :

failed: error creating bootstrap cluster: failed to pull kind image kindest/node:v0.11.1-gke.7-v1.20.9-gke.101 from registry mirror(s)

Si vous rencontrez une erreur lors de la création du cluster d'amorçage, assurez-vous que toutes les images sont importées dans le registre privé :

actl images push --private-registry=<registry>

Voici un exemple de commande :

actl images push --private-registry=10.200.0.2/library

Échecs préliminaires

Lorsque vous créez un cluster d'administrateur sur le mode privé d'Anthos, vous devrez peut-être corriger un échec lié à la création du cluster avec des erreurs préliminaires, au blocage de la création du cluster, ou effectuer des opérations de dépannage générales.

Échec de la création du cluster avec des erreurs préliminaires

Si la vérification préliminaire a échoué, le message d'erreur suivant peut s'afficher :

unable to create cluster: unable to create cluster: preflight check failed

Le mode privé d'Anthos collecte les journaux d'erreur correspondants dans le répertoire actl-workspace/admin/log/preflight-<timestamp>/, par exemple actl-workspace/admin/log/preflight-20210907-205726/.

Pour résoudre le problème, vérifiez les points suivants :

• Chaque journal de nœuds ayant échoué dans le fichier nommé comme étant l'adresse IP du nœud
• Les journaux liés au réseau dans le fichier node-network

En fonction des données des journaux, assurez-vous qu'il n'y a pas d'erreur évidente (par exemple, des exigences minimales de machine non remplies ou des ports en conflit). Mettez à jour les machines, puis réessayez.

Blocage de la création du cluster

Si la création d'un cluster à trois nœuds prend beaucoup de temps, par exemple plus de 30 minutes, vérifiez que le cluster d'amorçage local ne comporte pas d'erreurs lors de l'extraction de l'image :

kubectl --kubeconfig actl-workspace/.kindkubeconfig get pods -A

Si les pods affichent l'état ImagePullErr, assurez-vous que ces images sont importées dans le registre :

actl images push --private-registry=<registry>

Voici un exemple de commande :

actl images push --private-registry=10.200.0.2/library

Si une tâche de création de cluster spécifique possède l'état Error, consultez les journaux du pod correspondant :

kubectl --kubeconfig actl-workspace/.kindkubeconfig get pods -n cluster-admin
kubectl --kubeconfig actl-workspace/.kindkubeconfig logs <pod-name> -n cluster-admin

Examinez les journaux pour voir si des erreurs peuvent être corrigées manuellement sur la machine. Vous pouvez obtenir des erreurs supplémentaires à partir de la machine elle-même en utilisant SSH pour vous connecter à la machine et en exécutant journalctl --no-pager -l. Pour vous assurer que les services importants fonctionnent, exécutez la commande suivante :

service containerd status
service kubelet status

journalctl -u containerd
journalctl -u kubelet

# If needed sudo systemctl restart <service> to fix issues.
# sudo service <service> restart
# e.g.,
# sudo service containerd restart

Problèmes d'ordre général

Pour dépanner un nœud en général, utilisez SSH pour vous connecter à un nœud et exécutez la commande suivante :

journalctl --no-pager -l

Recherchez d'éventuelles erreurs dans les journaux.

Échec de la création du cluster

Utilisez SSH pour vous connecter à la machine du plan de contrôle et consultez les pods du cluster :

sudo kubectl --kubeconfig /etc/kubernetes/admin.conf get po -A

Problèmes de réseau

Cette section décrit les problèmes de réseau les plus courants dans le mode privé d'Anthos et illustre les étapes à suivre pour les résoudre.

• Utilisez la commande ip route pour afficher les connexions entre chaque nœud et vérifier les erreurs liées au réseau.

• Lorsque l'adresse IP virtuelle du plan de contrôle n'est pas accessible, utilisez SSH pour vous connecter à un nœud du plan de contrôle et exécutez la commande suivante :

  journalctl -u containerd --no-pager -l
  # Check the logs of those pods as well.
  sudo kubectl --kubeconfig /etc/kubernetes/admin.conf -n kube-system get po | grep -E "haproxy|keepalived"
  sudo crictl logs `sudo crictl ps | grep anthos-baremetal-haproxy | awk '{print $1}'`
  sudo crictl logs `sudo crictl ps | grep anthos-baremetal-keepalived | awk '{print $1}'`
  

  Ce problème peut se produire si les images keepalived et haproxy ne sont pas chargées dans un registre privé.

• (À n'utiliser qu'après la création réussie du cluster d'administrateur). Si les adresses IP de services ne sont pas accessibles, consultez les journaux des pods metallb :

  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -l app=metallb -l component=controller -n kube-system
  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -l app=metallb -l component=speaker -n kube-system
  

• Si tous les pods sont bloqués lors de la création du conteneur, effectuez l'une des opérations suivantes :

  • Vérifiez les déploiements anetd-operator et les journaux anetd daemonset.

  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get pods -l name=cilium-operator -n kube-system
  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -l name=cilium-operator -n kube-system
  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get pods -l k8s-app=cilium -n kube-system
  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -l k8s-app=cilium -n kube-system
  

  • Si aucune passerelle par défaut n'est définie, les iptables risquent de ne pas fonctionner correctement et anetd-operator pourrait ne pas pouvoir accéder au serveur kube-api.

  ip route add default via <some-ip>
  iptables-save -t nat
  iptables-save -t filter
  

• Redémarrez le nœud pour voir si le problème est résolu.

Erreurs fréquentes

Les commandes kubectl ne fonctionnent pas

Si vous n'avez pas configuré l'outil de ligne de commande kubectl pour vous connecter à un serveur d'API Kubernetes distant, le message d'erreur suivant s'affiche :

$ kubectl ...
The connection to the server localhost:8080 was refused - did you specify the right host or port?

Assurez-vous d'avoir défini un fichier kubeconfig. Pour ce faire, définissez la variable d'environnement KUBECONFIG ou exécutez les commandes avec l'option --kubeconfig.
Par exemple, pour définir le fichier kubeconfig d'administrateur, effectuez l'une des opérations suivantes :

• Définissez la variable d'environnement sur le fichier kubeconfig d'administrateur :

export KUBECONFIG=$HOME/anthos-baremetal-private-mode/actl-workspace/admin/admin-kubeconfig

• Utilisez l'option de ligne de commande kubeconfig :

kubectl --kubeconfig=$HOME/anthos-baremetal-private-mode/actl-workspace/admin/admin-kubeconfig

Pour en savoir plus, consultez la section Organiser l'accès au cluster à l'aide de fichiers kubeconfig.

Échec de la création du cluster d'utilisateur

Sur votre poste de travail, pour accéder au cluster d'administrateur et afficher les pods associés au cluster d'utilisateur, utilisez la commande suivante :

kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get po -n cluster-CLUSTER_NAME

Remplacez CLUSTER_NAME par le nom de votre cluster.

Si le cluster d'utilisateur échoue toujours, essayez de supprimer un cluster d'utilisateur et appliquez à nouveau la configuration suivante :

# Delete user cluster
export ADMIN_KUBECONFIG=$(pwd)/actl-workspace/admin/admin-kubeconfig
export USER_CLUSTER_NAME=user-1
kubectl -n cluster-${USER_CLUSTER_NAME} delete Cluster $USER_CLUSTER_NAME --kubeconfig=${ADMIN_KUBECONFIG}

# Re-apply the user cluster YAML file
KUBECONFIG=${ADMIN_KUBECONFIG} kubectl apply -f user.yaml

# Wait until client config ready and stored in the path "$(pwd)/${USER_CLUSTER_NAME}-kubeconfig"
export USER_KUBECONFIG=$(pwd)/${USER_CLUSTER_NAME}-kubeconfig
waittime="5 minutes"
endtime=$(date -ud "$waittime" +%s)
while ! KUBECONFIG=${ADMIN_KUBECONFIG} actl clusters baremetal get-credentials -c "${USER_CLUSTER_NAME}" -o "${USER_KUBECONFIG}"; do
  if [[ $endtime -le $(date -u +%s) ]]; then
    echo "Client config not ready in $waittime, terminating"
    exit 1
  fi
  echo "client config not ready, sleeping 30s"
  sleep 30
done

# Check the user cluster status until all nodes are ready
KUBECONFIG=${USER_KUBECONFIG} kubectl get nodes

Créer un centre de gestion Anthos

Ressources insuffisantes sur le cluster d'administrateur

La ressource personnalisée AdminOperator configure l'installation du centre de gestion Anthos. Pour savoir si le contrôleur a rencontré des problèmes lors de l'installation du centre de gestion, consultez les événements et les journaux Google Kubernetes Engine liés à cette ressource et à ce contrôleur personnalisés :

kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig describe adminoperator admin-operator
kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -n anthos-management-center-operator -l control-plane=admin-operator

Erreurs d'extraction d'image

Le démarrage de pods sur le cluster peut entraîner des problèmes qui empêchent AdminOperator de signaler que l'opération a réussi.

# Get all pods that aren't in a Running state or have succeeded.
kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get pods --field-selector=status.phase!=Running,status.phase!=Succeeded -A

# Examine the pods of interest that are failing...
kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig describe pod --namespace [NAMESPACE] [POD_OF_INTEREST]

Passage à une édition supérieure

Anthos sur solution Bare Metal

Pour en savoir plus sur la résolution des problèmes liés à une mise à niveau dans Anthos sur solution Bare Metal, consultez la section Restaurer une mise à niveau ayant échoué dans Anthos sur solution Bare Metal.

Remarque : pour les clusters en mode privé d'Anthos, vous devez remplacer la commande bmctl par actl lorsque vous appliquez des correctifs répertoriés pour Anthos sur Bare Metal. Par exemple, utilisez actl clusters baremetal upgrade au lieu de bmctl upgrade cluster.

Centre de gestion Anthos

Pour vérifier la version du composant installée, exécutez la commande suivante :

kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get adminoperator admin-operator -o yaml

Voici un exemple de résultat :

apiVersion: managementcenter.anthos.cloud.google.com/v1
kind: AdminOperator
spec:
  updateConfigOverride:
    policies:
    - name: anthos-config-management
      versionConstraint: <=1.8.0-gke.0
status:
  components:
  - name: anthos-bare-metal
    version: 1.8.0-gke.0
    versionConstraint: <=1.8.0-gke.0
  - name: anthos-config-management
    version: 1.8.0-gke.0
    versionConstraint: <=1.8.0-gke.0
  - name: anthos-service-mesh
    version: 1.8.0-gke.0
    versionConstraint: <=1.8.0-gke.0
  version: 1.8.0-gke.0

Dans un environnement Anthos en mode privé déployé, la partie status.version de l'objet AdminOperator indique la version d'Anthos en mode privé.

Par exemple, 1.8.0-gke.0. status.components indique l'état de la version pour chaque composant. Il identifie la version observée et la contrainte de version pour chaque composant déployé.

status.version et status.components doivent toujours être disponibles, sinon l'installation est corrompue. spec.updateConfigOverride est facultatif. Il n'est présent que si les opérateurs d'infrastructure définissent manuellement le champ pour mettre à niveau un composant spécifique. Lorsque le champ est omis, tous les composants s'exécutent sur la même version que AdminOperator.

Vérifier les packages dans le centre de mise à jour

Seuls les packages proposés dans le centre de mise à jour sont déployés dans le centre de gestion.

Par exemple, si vous installez initialement le cluster d'administrateur avec la version 1.8.0-gke.0, puis que vous passez ensuite à la version 1.8.1-gke.0, le centre de mise à jour contient deux ensembles de packages. La suppression de la ressource UpdateItem pour un composant utilisé activement peut corrompre l'installation du mode privé Anthos.

kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get updateitems -n anthos-management-center

Voici un exemple de résultat :

NAME                                  AGE
anthos-config-management-1.8.0-gke.0  13d
anthos-service-mesh-1.8.0-gke.0       13d

Étapes suivantes

• En savoir plus sur les problèmes connus du mode privé d'Anthos