Risoluzione dei problemi e operazioni per Ingress multi-cluster

Il controller Ingress di GKE Enterprise gestisce le risorse di Compute Engine. Le risorse MultiClusterIngress e MultiClusterService vengono mappate a risorse Compute Engine diverse, quindi comprendere la relazione tra queste risorse ti aiuta a risolvere i problemi. Ad esempio, esamina la seguente risorsa MultiClusterIngress:

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

Mapping delle risorse di Compute Engine a Ingress multi-cluster

La tabella seguente mostra il mapping delle risorse del parco risorse alle risorse create nei cluster Kubernetes e Google Cloud:

Risorsa Kubernetes Google Cloud risorsa Descrizione
MultiClusterIngress Regola di forwarding VIP del bilanciatore del carico HTTP(S).
Proxy di destinazione Impostazioni di terminazione HTTP/S prese dalle annotazioni e dal blocco TLS.
Mappa URL Mappatura del percorso dell'host virtuale dalla sezione delle regole.
MultiClusterService Servizio Kubernetes Risorsa derivata dal modello.
Servizio di backend Viene creato un servizio di backend per ogni coppia (Service, ServicePort).
Gruppi di endpoint di rete Set di pod di backend che partecipano al servizio.

Ispezione delle risorse del bilanciatore del carico Compute Engine

Dopo aver creato un bilanciatore del carico, lo stato di Ingress multi-cluster conterrà i nomi di ogni risorsa Compute Engine creata per costruire il bilanciatore del carico. Ad esempio:

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"

VIP non creato

Se non vedi un VIP, è possibile che si sia verificato un errore durante la sua creazione. Per verificare se si è verificato un errore, esegui questo comando:

kubectl describe mci shopping-service

L'output potrebbe essere simile al seguente:

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

In questo esempio, l'errore è che l'utente non ha creato una risorsa MultiClusterService a cui fa riferimento un MultiClusterIngress.

Risposta 502

Se il bilanciatore del carico ha acquisito un VIP, ma restituisce costantemente una risposta 502, i controlli di integrità del bilanciatore del carico potrebbero non riuscire. I controlli di integrità potrebbero non riuscire per due motivi:

  1. I pod dell'applicazione non sono integri (vedi ad esempio il debug della console Google Cloud).
  2. Un firewall configurato in modo errato impedisce ai controlli di integrità di Google di eseguire i controlli di integrità.

Nel caso del punto 1, assicurati che la tua applicazione restituisca una risposta 200 nel percorso "/".

Nel caso del punto 2, assicurati che nella tua VPC esista un firewall denominato "mci-default-l7". Il controller Ingress crea il firewall nel tuo VPC per assicurarsi che i controlli di integrità di Google possano raggiungere i tuoi backend. Se il firewall non esiste, assicurati che non esista un'automazione esterna che lo elimini al momento della creazione.

Traffico non aggiunto o rimosso dal cluster

Quando aggiungi un nuovo abbonamento, il traffico deve raggiungere i backend nel cluster sottostante, se applicabile. Analogamente, se un Membership viene rimosso, nessun traffico deve raggiungere i backend nel cluster sottostante. Se non osservi questo comportamento, controlla la presenza di errori nella risorsa MultiClusterIngress e MultiClusterService.

I casi comuni in cui si verifica questo errore includono l'aggiunta di un nuovo abbonamento su un cluster GKE che non è in modalità VPC nativo o l'aggiunta di un nuovo abbonamento senza il deployment di un'applicazione nel cluster GKE.

  1. Descrivi MultiClusterService:

    kubectl describe mcs zone-svc

  2. Descrivi MultiClusterIngress:

    kubectl describe mci zone-mci

Migrazione del cluster di configurazione

Per saperne di più sui casi d'uso per la migrazione, consulta il concetto di progettazione del cluster di configurazione.

La migrazione del cluster di configurazione può essere un'operazione distruttiva se non gestita correttamente. Segui queste linee guida quando esegui una migrazione del cluster di configurazione:

  1. Assicurati di utilizzare l'annotazione static-ip sulle risorse MultiClusterIngress. In caso contrario, il traffico verrà interrotto durante la migrazione. Gli IP temporanei verranno ricreati durante la migrazione dei cluster di configurazione.
  2. Le risorse MultiClusterIngress e MultiClusterService devono essere deployate in modo identico al cluster di configurazione esistente e a quello nuovo. Le differenze tra loro comporteranno la riconciliazione delle risorse MultiClusterService e MultiClusterIngress diverse nel nuovo cluster di configurazione.
  3. In qualsiasi momento è attivo un solo cluster di configurazione. Finché il cluster di configurazione non viene modificato, le risorse MultiClusterIngress e MultiClusterService nel nuovo cluster di configurazione non influiranno sulle risorse del bilanciatore del carico.

Per eseguire la migrazione del cluster di configurazione, esegui questo comando:

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

Verifica che il comando funzioni assicurandoti che non siano presenti errori visibili in Stato funzionalità:

  gcloud container fleet ingress describe

Debug della console

Nella maggior parte dei casi, controllare lo stato esatto del bilanciatore del carico è utile per eseguire il debug di un problema. Puoi trovare il bilanciatore del carico andando a Bilanciamento del carico nella console Google Cloud .

Codici di errore/avviso

Ingress multi-cluster genera codici di errore e avviso sulle risorse MultiClusterIngress e MultiClusterService, nonché sul campo Descrizione multiclusteringress di gcloud per i problemi noti. Questi messaggi contengono codici di errore e avviso documentati per facilitare la comprensione di cosa significa quando qualcosa non funziona come previsto. Ogni codice è composto da un ID errore nel formato AVMBR123, dove 123 è un numero univoco che corrisponde a un errore o avviso e suggerimenti su come risolverlo.

AVMBR101: Annotation [NAME] not recognized

Questo errore viene visualizzato quando viene specificata un'annotazione in un manifest MultiClusterIngress o MultiClusterService non riconosciuto. Esistono un paio di motivi per cui l'annotazione potrebbe non essere riconosciuta:

  1. L'annotazione non è supportata in Ingress multi-cluster. Questo comportamento potrebbe essere previsto se annotando risorse che non dovrebbero essere utilizzate dal controller Ingress di GKE Enterprise.

  2. L'annotazione è supportata, ma è scritta in modo errato e quindi non viene riconosciuta.

In entrambi i casi, consulta la documentazione per comprendere le annotazioni supportate e come vengono specificate.

AVMBR102: [RESOURCE_NAME] not found

Questo errore viene visualizzato quando una risorsa supplementare viene specificata in un MultiClusterIngress, ma non è possibile trovarla in Config Membership. Ad esempio, questo errore viene generato quando un MultiClusterIngress fa riferimento a un MultiClusterService che non può essere trovato o un MultiClusterService fa riferimento a un BackendConfig che non può essere trovato. Esistono un paio di motivi per cui una risorsa non è stata trovata:

  1. Non si trova nello spazio dei nomi corretto. Assicurati che le risorse che fanno riferimento l'una all'altra si trovino nello stesso spazio dei nomi.
  2. Il nome della risorsa non è scritto correttamente.
  3. La risorsa non esiste davvero con lo spazio dei nomi e il nome corretti. In questo caso, crealo.

AVMBR103: [CLUSTER_SELECTOR] is invalid

Questo errore viene visualizzato quando un selettore di cluster specificato in un MultiClusterService non è valido. Esistono un paio di motivi per cui questo selettore potrebbe non essere valido:

  1. La stringa fornita contiene un errore di battitura.
  2. La stringa fornita fa riferimento a un'appartenenza al cluster che non esiste più nel parco risorse.

AVMBR104: Cannot find NEGs for Service Port [SERVICE_PORT]

Questo errore viene generato quando non è possibile trovare i NetworkEndpointGroup (NEG) per una determinata coppia di porte di servizio e MultiClusterService. I NEG sono le risorse che contengono gli endpoint dei pod in ciascuno dei cluster di backend. Il motivo principale per cui le NEG potrebbero non esistere è che si è verificato un errore durante la creazione o l'aggiornamento dei servizi derivati nei cluster di backend. Per saperne di più, consulta la sezione Eventi della risorsa MultiClusterService.

AVMBR105: Missing GKE Enterprise license.

Questo errore viene visualizzato in Stato funzionalità e indica che l'API GKE Enterprise (anthos.googleapis.com) non è abilitata.

AVMBR106: Derived service is invalid: [REASON].

Questo errore viene visualizzato sotto gli eventi della risorsa MultiClusterService. Un motivo comune di questo errore è che la risorsa Service derivata da MultiClusterService ha una specifica non valida.

Ad esempio, questo MultiClusterService non ha ServicePort definiti nelle specifiche.

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"

Questo errore viene visualizzato in Stato funzionalità e si verifica perché non esiste un cluster GKE sottostante la risorsa Membership. Puoi verificarlo eseguendo questo comando:

gcloud container fleet memberships describe membership-name

e assicurandoti che non ci sia alcun link alla risorsa cluster GKE nel campo endpoint.

AVMBR108: GKE cluster [NAME] not found.

Questo errore viene visualizzato in Stato funzionalità e viene generato se il cluster GKE sottostante per l'abbonamento non esiste.

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

Questo errore viene visualizzato in Stato funzionalità. Questo errore viene generato se il cluster GKE specificato è un cluster basato su route. Il controller Ingress multi-cluster crea un bilanciatore del carico nativo del container utilizzando i NEG. Per utilizzare un bilanciatore del carico nativo del container, i cluster devono essere VPC nativi.

Per saperne di più, consulta la sezione Creazione di un cluster nativo di VPC.

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

Questo errore viene visualizzato in Stato funzionalità. Questo errore si può verificare per alcuni motivi:

  1. Il cluster GKE sottostante per l'abbonamento si trova in un progetto diverso dall'abbonamento stesso.
  2. L'autorizzazione IAM specificata è stata rimossa dall'agente di servizio MultiClusterIngress.

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

Questo errore viene visualizzato in Stato funzionalità. Il motivo principale per cui si verifica questo errore è perché l'appartenenza alla configurazione è stata eliminata mentre la funzionalità è abilitata.

Non dovresti mai dover eliminare l'appartenenza alla configurazione. Se vuoi modificarlo, segui i passaggi per la migrazione del cluster di configurazione.

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

Questo errore viene visualizzato in Stato funzionalità e si verifica quando il componente aggiuntivo HTTPLoadBalancing è disattivato in un cluster GKE. Puoi aggiornare il cluster GKE per abilitare il componente aggiuntivo HTTPLoadBalancing:

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

AVMBR113: This resource is orphaned.

In alcuni casi, l'utilità di una risorsa dipende dal fatto che venga citata da un'altra risorsa. Questo errore viene generato quando viene creata una risorsa Kubernetes, ma non viene fatto riferimento a un'altra risorsa. Ad esempio, visualizzerai questo errore se crei una risorsa BackendConfig a cui non fa riferimento un MultiClusterService.