Dépannage et opérations Ingress multicluster

Le contrôleur d'entrée GKE Enterprise gère les ressources Compute Engine. Les ressources MultiClusterIngress et MultiClusterService correspondent à différentes ressources Compute Engine. Par conséquent, comprendre la relation entre ces ressources vous aide à résoudre les problèmes. Par exemple, examinez la ressource MultiClusterIngress suivante :

apiVersion: extensions/v1beta1
kind: MultiClusterIngress
metadata:
  name: foo-ingress
spec:
  template:
    spec:
      rules:
      - host: store.foo.com
        http:
          paths:
          - backend:
              serviceName: store-foo
              servicePort: 80
      - host: search.foo.com
        http:
          paths:
          - backend:
              serviceName: search-foo
              servicePort: 80

Mappages de ressources Compute Engine vers un entrée multicluster

Le tableau ci-dessous montre le mappage des ressources Fleet avec les ressources créées dans les clusters Kubernetes et Google Cloud :

Ressource Kubernetes Ressource Google Cloud Description
MultiClusterIngress Règle de transfert IPV de l'équilibreur de charge HTTP(S).
Proxy cible Paramètres de terminaison HTTP/S issus des annotations et du bloc TLS.
Mappage d'URL Mappage du chemin de l'hôte virtuel à partir de la section des règles.
MultiClusterService Service Kubernetes Ressource dérivée du modèle.
Service de backend Un service de backend est créé pour chaque paire (Service, ServicePort).
Groupes de points de terminaison du réseau Ensemble de pods backend participant au service.

Inspecter les ressources de l'équilibreur de charge Compute Engine

Après avoir créé un équilibreur de charge, l'état du Multi Cluster Ingress contient les noms de chaque ressource Compute Engine créée pour construire l'équilibreur de charge. Par exemple :

Name:         shopping-service
Namespace:    prod
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1beta1
Kind:         MultiClusterIngress
Metadata:
  Creation Timestamp:  2019-07-16T17:23:14Z
  Finalizers:
    mci.finalizer.networking.gke.io
Spec:
  Template:
    Spec:
      Backend:
        Service Name:  shopping-service
        Service Port:  80
Status:
  VIP:  34.102.212.68
  CloudResources:
    Firewalls: "mci-l7"
    ForwardingRules: "mci-abcdef-myforwardingrule"
    TargetProxies: "mci-abcdef-mytargetproxy"
    UrlMap: "mci-abcdef-myurlmap"
    HealthChecks: "mci-abcdef-80-myhealthcheck"
    BackendServices: "mci-abcdef-80-mybackendservice"
    NetworkEndpointGroups: "k8s1-neg1", "k8s1-neg2", "k8s1-neg3"

IPV non créée

Si vous ne voyez pas d'adresse IPV, une erreur s'est peut-être produite lors de sa création. Pour voir si une erreur s'est produite, exécutez la commande suivante :

kubectl describe mci shopping-service

Le résultat peut ressembler à ceci :

Name:         shopping-service
Namespace:    prod
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1beta1
Kind:         MultiClusterIngress
Metadata:
  Creation Timestamp:  2019-07-16T17:23:14Z
  Finalizers:
    mci.finalizer.networking.gke.io
Spec:
  Template:
    Spec:
      Backend:
        Service Name:  shopping-service
        Service Port:  80
Status:
  VIP:  34.102.212.68
Events:
  Type     Reason  Age   From                              Message
  ----     ------  ----  ----                              -------
  Warning  SYNC    29s   multi-cluster-ingress-controller  error translating MCI prod/shopping-service: exceeded 4 retries with final error: error translating MCI prod/shopping-service: multiclusterservice prod/shopping-service does not exist

Dans cet exemple, l'erreur vient du fait que l'utilisateur n'a pas créé la ressource MultiClusterService référencée par un objet MultiClusterIngress.

Réponse 502

Si votre équilibreur de charge possède une adresse IPV, mais génère systématiquement une réponse 502, cela peut indiquer que les vérifications d'état de l'équilibrage de charge échouent. Les vérifications d'état peuvent échouer pour deux raisons :

  1. Les pods d'application ne sont pas opérationnels. Pour en savoir plus, consultez la section Débogage de Cloud Console.
  2. Un pare-feu mal configuré empêche les vérificateurs d'état de Google d'effectuer des vérifications d'état.

Dans le cas numéro 1, assurez-vous que votre application diffuse bien une réponse 200 sur le chemin d'accès "/".

Dans le cas numéro 2, assurez-vous qu'un pare-feu nommé "mci-default-l7" existe dans votre VPC. Le contrôleur d'entrée crée le pare-feu dans votre VPC afin de garantir que les vérificateurs d'état de Google peuvent bien atteindre vos backends. Si le pare-feu n'existe pas, assurez-vous qu'aucun processus automatique externe ne le supprime à l'issue de sa création.

Trafic non ajouté au cluster ou supprimé de celui-ci

Lors de l'ajout d'un membre, le trafic doit atteindre les backends du cluster sous-jacent, le cas échéant. De même, si un membre est supprimé, aucun trafic ne doit atteindre les backends dans le cluster sous-jacent. Si vous n'observez pas ce comportement, recherchez des erreurs sur les ressources MultiClusterIngress et MultiClusterService.

Cette erreur se produit généralement lorsque vous ajoutez un membre à un cluster GKE qui n'est pas en mode VPC natif ou que vous en ajoutez un sans déployer d'application dans le cluster GKE.

  1. Décrivez la ressource MultiClusterService :

    kubectl describe mcs zone-svc

  2. Décrivez la ressource MultiClusterIngress :

    kubectl describe mci zone-mci

Migration du cluster de configuration

Pour en savoir plus sur les cas d'utilisation de la migration, consultez la page Principes de conception du cluster de configuration.

La migration du cluster de configuration peut être une opération perturbatrice si elle n'est pas gérée correctement. Suivez ces consignes lors de la migration d'un cluster de configuration :

  1. Assurez-vous d'utiliser l'annotation static-ip sur vos ressources MultiClusterIngress. À défaut, le trafic sera interrompu lors de la migration. Les adresses IP éphémères seront recréées lors de la migration des clusters de configuration.
  2. Les ressources MultiClusterIngress et MultiClusterService doivent être déployées de manière identique sur le cluster de configuration existant et le nouveau cluster de configuration. Des différences de déploiement entraîneront le rapprochement des ressources MultiClusterService et MultiClusterIngress qui sont différentes dans le nouveau cluster de configuration.
  3. Un seul cluster de configuration est actif à tout moment. Tant que le cluster de configuration n'est pas modifié, les ressources MultiClusterIngress et MultiClusterService du nouveau cluster de configuration n'ont pas d'incidence sur les ressources de l'équilibreur de charge.

Pour migrer le cluster de configuration, exécutez la commande suivante :

  gcloud container fleet ingress update \
    --config-membership=projects/project_id/locations/global/memberships/new_config_cluster

Vérifiez que la commande a fonctionné en vérifiant qu'aucune erreur n'est visible dans l'état de la fonctionnalité :

  gcloud container fleet ingress describe

Débogage de Cloud Console

Dans la plupart des cas, vérifier l'état exact de l'équilibreur de charge lors du débogage d'un problème s'avère utile. Pour examiner l'équilibreur de charge, accédez à la page Équilibrage de charge dans la console Google Cloud.

Codes d'erreur/d'avertissement

L'objet Ingress multicluster émet des codes d'erreur et d'avertissement sur les ressources MultiClusterIngress et MultiClusterService, ainsi que le champ de description gcloud multiclusteringress pour les problèmes connus. Ces messages contiennent des codes d'erreur et d'avertissement pour faciliter votre compréhension lorsque quelque chose ne fonctionne pas comme prévu. Chaque code est constitué d'un identifiant d'erreur au format AVMBR123, où 123 est un nombre unique qui correspond à une erreur ou un avertissement, accompagné de suggestions pour résoudre le problème.

AVMBR101 : Annotation [NAME] not recognized

Cette erreur s'affiche lorsqu'une annotation est indiquée dans un objet MultiClusterIngress ou un fichier manifeste MultiClusterService non reconnu. L'annotation peut ne pas être reconnue pour plusieurs raisons :

  1. L'annotation n'est pas compatible avec l'objet Ingress multicluster. Cela peut se produire si vous annotez des ressources qui ne devraient pas être utilisées par le contrôleur d'entrée GKE Enterprise.

  2. L'annotation est acceptée, mais elle est mal orthographiée et n'est donc pas reconnue.

Dans les deux cas, reportez-vous à la documentation pour comprendre les annotations compatibles et leur spécification.

AVMBR102 : [RESOURCE_NAME] not found

Cette erreur s'affiche lorsqu'une ressource supplémentaire est spécifiée dans un objet MultiClusterIngress, mais introuvable dans la configuration de l'appartenance. Par exemple, cette erreur est générée lorsqu'un MultiClusterIngress fait référence à un MultiClusterService introuvable ou qu'un MultiClusterService fait référence à un BackendConfig introuvable. Une ressource est introuvable pour plusieurs raisons :

  1. Elle ne se trouve pas dans l'espace de noms approprié. Assurez-vous que les ressources qui font référence les unes aux autres se trouvent dans le même espace de noms.
  2. Le nom de la ressource est mal orthographié.
  3. La ressource n'existe pas avec l'espace de noms et le nom appropriés. Dans ce cas, vous devez la créer.

AVMBR103 : [CLUSTER_SELECTOR] is invalid

Cette erreur s'affiche lorsqu'un sélecteur de cluster spécifié sur un MultiClusterService n'est pas valide. Ce sélecteur peut être incorrect pour plusieurs raisons :

  1. La chaîne fournie contient une faute de frappe.
  2. La chaîne fournie fait référence à une appartenance du cluster qui n'existe plus dans le parc.

AVMBR104 : Cannot find NEGs for Service Port [SERVICE_PORT]

Cette erreur est renvoyée lorsque les éléments NEG (NetworkEndpointGroup) d'un MultiClusterService et d'une paire service/port donnés sont introuvables. Les NEG sont les ressources qui contiennent les points de terminaison du pod dans chacun de vos clusters de backend. La principale raison pour laquelle les NEG peuvent ne pas exister est qu'une erreur s'est produite lors de la création ou de la mise à jour des services dérivés dans vos clusters de backend. Consultez les événements de votre ressource MultiClusterService pour en savoir plus.

AVMBR105 : Missing GKE Enterprise license.

Cette erreur s'affiche sous "État de la fonctionnalité" et indique que l'API GKE Enterprise (anthos.googleapis.com) n'est pas activée.

AVMBR106 : Derived service is invalid: [REASON].

Cette erreur s'affiche sous les événements de la ressource MultiClusterService. L'une des raisons courantes de cette erreur est que la ressource Service dérivée de MultiClusterService a une spécification non valide.

Par exemple, ce service MultiClusterService ne bénéficie d'aucun ServicePort dans ses spécifications.

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: zone-mcs
  namespace: whereami
spec:
  clusters:
  - link: "us-central1-a/gke-us"
  - link: "europe-west1-c/gke-eu"

Cette erreur s'affiche sous "État de la fonctionnalité" et se produit parce qu'aucun cluster GKE n'est sous-jacent à la ressource Membership. Vous pouvez le vérifier en exécutant la commande suivante :

gcloud container fleet memberships describe membership-name

et en vérifiant qu'il n'y a pas de lien de ressource de cluster GKE sous le champ du point de terminaison.

AVMBR108 : GKE cluster [NAME] not found.

Cette erreur s'affiche sous "État de la fonctionnalité" et survient si le cluster GKE sous-jacent de Membership n'existe pas.

AVMBR109 : [NAME] is not a VPC-native GKE cluster.

Cette erreur s'affiche sous "État de la fonctionnalité". Cette erreur est générée si le cluster GKE spécifié est un cluster basé sur le routage. Le contrôleur Multi Cluster Ingress crée un équilibreur de charge natif en conteneurs à l'aide des NEG. Les clusters doivent être de type VPC natif pour utiliser un équilibreur de charge natif en conteneurs.

Pour en savoir plus, consultez la page Créer un cluster de VPC natif.

AVMBR110 : [IAM_PERMISSION] permission missing for GKE cluster [NAME].

Cette erreur s'affiche sous "État de la fonctionnalité". Plusieurs raisons peuvent expliquer cette erreur :

  1. Le cluster GKE sous-jacent de Membership se trouve dans un projet différent de la ressource Membership elle-même.
  2. L'autorisation IAM spécifiée a été supprimée de l'agent de service MultiClusterIngress.

AVMBR111 : Failed to get Config Membership: [REASON].

Cette erreur s'affiche sous "État de la fonctionnalité". Cette erreur est principalement due au fait que l'abonnement Config a été supprimé alors que la fonctionnalité est activée.

Vous ne devriez jamais avoir à supprimer la configuration de l'appartenance. Si vous souhaitez la modifier, suivez les étapes de migration du cluster de configuration.

AVMBR112 : HTTPLoadBalancing Addon is disabled in GKE Cluster [NAME].

Cette erreur s'affiche sous "État de la fonctionnalité" et se produit lorsque le module complémentaire HTTPLoadBalancing est désactivé dans un cluster GKE. Vous pouvez mettre à jour votre cluster GKE pour activer le module complémentaire HTTPLoadBalancing :

gcloud container clusters update name --update-addons=HttpLoadBalancing=ENABLED

AVMBR113 : This resource is orphaned.

Dans certains cas, l'utilité d'une ressource dépend de sa référence à une autre ressource. Cette erreur est générée lorsqu'une ressource Kubernetes est créée mais n'est pas référencée par une autre ressource. Par exemple, cette erreur s'affiche si vous créez une ressource BackendConfig qui n'est pas référencée par un MultiClusterService.