Risoluzione dei problemi e operazioni per Ingress multi-cluster

Il controller Ingress di GKE Enterprise gestisce Compute Engine Google Cloud. Le risorse MultiClusterIngress e MultiClusterService vengono mappate a a varie risorse Compute Engine, quindi è importante capire la relazione tra queste risorse è utile per la risoluzione dei problemi. Ad esempio, esamina il seguente MultiClusterIngress risorsa:

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

Mappature delle risorse da Compute Engine a Ingress multi-cluster

La tabella seguente mostra la mappatura delle risorse del parco risorse alle risorse create nella Cluster Kubernetes e Google Cloud:

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

Ispezione delle risorse del bilanciatore del carico di Compute Engine

Dopo aver creato un bilanciatore del carico, lo stato Ingress multi-cluster conterrà nomi di ogni risorsa Compute Engine creata per costruire con il bilanciatore del carico di rete passthrough esterno regionale. 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 era che l'utente non ha creato un MultiClusterService risorsa a cui fa riferimento un MultiClusterIngress.

Risposta 502

Se il bilanciatore del carico ha acquisito un VIP, ma fornisce costantemente una risposta 502, è possibile che i controlli di integrità del bilanciatore del carico non vadano a buon fine. I controlli di integrità potrebbero non riuscire per due motivi:

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

Nel caso del passaggio 1, assicurati che la tua applicazione stia effettivamente pubblicando 200 risposta sulla barra "/" del tuo percorso di apprendimento.

Nel caso del passaggio #2, assicurati che un firewall denominato "mci-default-l7" esiste in del tuo VPC. Il controller Ingress crea il firewall nel tuo VPC per garantire che i controlli di integrità di Google possano raggiungere i tuoi backend. Se il firewall non assicurati che non esistano automazioni esterne che eliminano questo firewall al momento della sua creazione.

Traffico non aggiunto o rimosso dal cluster

Quando aggiungi una nuova appartenenza, il traffico deve raggiungere i backend nella cluster sottostante, quando possibile. Analogamente, se un abbonamento viene rimosso, il traffico deve raggiungere i backend nel cluster sottostante. Se non sei osservando questo comportamento, verifica la presenza di errori in MultiClusterIngress e MultiClusterService risorsa.

I casi comuni in cui si verifica questo errore includono l'aggiunta di una nuova appartenenza su un cluster GKE che non è in modalità VPC nativa o che aggiunge un nuova appartenenza ma senza eseguire il deployment di un'applicazione in GKE in un cluster Kubernetes.

  1. Descrivi MultiClusterService:

    kubectl describe mcs zone-svc

  2. Descrivi MultiClusterIngress:

    kubectl describe mci zone-mci

Migrazione dei cluster di configurazione

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

La migrazione dei cluster di configurazione può essere un'operazione invasiva se non viene gestita correttamente. Segui queste linee guida quando esegui la migrazione di un cluster di configurazione:

  1. Assicurati di utilizzare annotazione IP statico sulle tue risorse MultiClusterIngress. In caso contrario, ha subito interruzioni del traffico durante la migrazione. Gli IP temporanei verranno ricreati quando migrazione dei cluster di configurazione.
  2. Le risorse MultiClusterIngress e MultiClusterService devono essere il deployment è identico a quello del cluster di configurazione esistente e di quello nuovo. Differenze tra di loro comporterà la riconciliazione di MultiClusterService e MultiClusterIngress risorse diverse nel nuovo cluster di configurazione.
  3. È attivo un solo cluster di configurazione alla volta. Fino al cluster di configurazione viene modificato, le risorse MultiClusterIngress e MultiClusterService in il nuovo cluster di configurazione non influirà 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 abbia funzionato verificando che non siano presenti errori visibili nel Stato della funzionalità:

  gcloud container fleet ingress describe

Debug della console

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

Codici di errore/avviso

Ingress multi-cluster emette codici di errore e di avviso su MultiClusterIngress e MultiClusterService e gcloud multiclusteringress Campo della descrizione dei problemi noti. Questi messaggi contengono errori documentati codici di avviso per facilitare la comprensione di cosa significa 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 avvisi e suggerimenti su come risolverlo.

AVMBR101: Annotation [NAME] not recognized

Questo errore viene visualizzato quando viene specificata un'annotazione su un MultiClusterIngress o MultiClusterService non riconosciuto. Ci sono un paio di Motivi per cui l'annotazione potrebbe non essere riconosciuta:

  1. L'annotazione non è supportata in Ingress multi-cluster. Ciò potrebbe verificarsi se annotare le risorse che non si prevede vengano utilizzate da GKE Enterprise Controller Ingress.

  2. L'annotazione è supportata, ma contiene errori di ortografia e quindi non viene riconosciuta.

In entrambi i casi, fai riferimento alla documentazione per comprendere annotazioni supportate e come vengono specificati.

AVMBR102: [RESOURCE_NAME] not found

Questo errore viene visualizzato quando viene specificata una risorsa supplementare in MultiClusterIngress, ma impossibile trovare nell'abbonamento di configurazione. Ad esempio: questo errore viene generato quando MultiClusterIngress si riferisce a un MultiClusterService impossibile trovare o MultiClusterService si riferisce a una BackendConfig che impossibile trovare. Esistono due motivi per cui non è stato possibile trovare una risorsa:

  1. Non si trova nello spazio dei nomi corretto. Assicurati che le risorse che fanno riferimento a ognuna altre si trovano nello stesso spazio dei nomi.
  2. Il nome della risorsa non è scritto correttamente.
  3. La risorsa non esiste davvero con lo spazio dei nomi + il nome corretti. In questo caso, per favore crealo.

AVMBR103: [CLUSTER_SELECTOR] is invalid

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

  1. La stringa fornita contiene un errore di battitura.
  2. La stringa fornita si riferisce a un'appartenenza al cluster che non esiste più in della flotta.

AVMBR104: Cannot find NEGs for Service Port [SERVICE_PORT]

Questo errore viene generato quando i NEG (NetworkEndpointGroup) per una determinata Impossibile trovare MultiClusterService e la coppia di porte del servizio. I NEG sono che contengono gli endpoint dei pod in ciascuno dei tuoi cluster di backend. La Il motivo principale per cui i NEG potrebbero non esistere è che si è verificato un errore durante la creazione o aggiornare i servizi derivati nei cluster di backend. Controlla gli eventi su la tua risorsa MultiClusterService per ulteriori informazioni.

AVMBR105: Missing GKE Enterprise license.

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

AVMBR106: Derived service is invalid: [REASON].

Questo errore viene visualizzato sotto gli eventi della risorsa MultiClusterService. Uno. la causa più comune di questo errore è che la risorsa del servizio deriva MultiClusterService ha una specifica non valida.

Ad esempio, per MultiClusterService non è definito alcun ServicePort nelle sue 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 della funzionalità e si verifica perché non sono Cluster GKE sottostante la risorsa Membership. Puoi per verificarlo eseguendo questo comando:

gcloud container fleet memberships describe membership-name

e verificando che non esista un link alle risorse del cluster GKE nel campo dell'endpoint.

AVMBR108: GKE cluster [NAME] not found.

Questo errore viene visualizzato in Stato della funzionalità e viene generato se l'oggetto Non esiste un cluster GKE per l'appartenenza.

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

Questo errore viene visualizzato in Stato della funzionalità. Questo errore viene visualizzato se il cluster GKE specificato è basato su route. Ingress multi-cluster crea un bilanciatore del carico nativo del container utilizzando i NEG. I cluster devono essere Rete VPC nativa per l'utilizzo di un bilanciatore del carico nativo del container.

Per ulteriori informazioni, vedi Creazione di un cluster nativo di VPC.

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

Questo errore viene visualizzato in Stato della funzionalità. Questo errore si verifica per due motivi:

  1. Il cluster GKE sottostante per l'abbonamento si trova in un progetto diverso da quello dell'abbonamento.
  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 della 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'abbonamento di configurazione. Se desideri modificala, 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 della funzionalità e si verifica quando HTTPLoadBalancing è disabilitato in un cluster GKE. Puoi aggiornare 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 vi si faccia riferimento un'altra risorsa. Questo errore viene generato quando viene creata una risorsa Kubernetes, non fa riferimento a un'altra risorsa. Ad esempio, vedrai questo errore se crei una risorsa BackendConfig a cui non fa riferimento un MultiClusterService.