Bilanciamento del carico nativo del container tramite Ingress

Questa pagina spiega come utilizzare il bilanciamento del carico nativo del container in Google Kubernetes Engine (GKE). Il bilanciamento del carico nativo del container consente ai bilanciatori del carico scegliere come target i pod Kubernetes direttamente e distribuire uniformemente il traffico ai pod.

Per ulteriori informazioni su vantaggi, requisiti e limitazioni di il bilanciamento del carico nativo del container, Bilanciamento del carico nativo del container.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Attiva l'API Google Kubernetes Engine.
    • Abilita l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, install e poi inizializzare con gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.

Utilizza il bilanciamento del carico nativo del container

Le sezioni seguenti illustrano il bilanciamento del carico nativo del container. configurazione su GKE. Tieni presente che per i cluster GKE con la versione 1.17 o successive e in determinate condizioni, il bilanciamento del carico nativo del container è predefinito e non richiede una richiesta Annotazione del servizio cloud.google.com/neg: '{"ingress": true}'.

Crea un cluster nativo di VPC

Per usare il bilanciamento del carico nativo del container, il cluster GKE deve avere IP alias abilitati.

Ad esempio, il comando seguente crea un cluster GKE, neg-demo-cluster, con una subnet di cui è stato eseguito il provisioning automatico:

  • Per la modalità Autopilot, gli indirizzi IP alias sono abilitati per impostazione predefinita:

    gcloud container clusters create-auto neg-demo-cluster \
    --location=COMPUTE_LOCATION

    Sostituisci COMPUTE_LOCATION con Località di Compute Engine per il cluster.

  • In modalità Standard, abilita gli indirizzi IP alias quando crei cluster:

    gcloud container clusters create neg-demo-cluster \
    --enable-ip-alias \
    --create-subnetwork="" \
    --network=default \
    --zone=us-central1-a

Creazione di un deployment

Il seguente esempio Deployment, neg-demo-app esegue una singola istanza di un server HTTP containerizzato. Me di utilizzare carichi di lavoro che utilizzano Idoneità dei pod feedback.

Utilizzo del feedback sull'idoneità dei pod

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: neg-demo-app # Label for the Deployment
  name: neg-demo-app # Name of Deployment
spec:
  selector:
    matchLabels:
      run: neg-demo-app
  template: # Pod template
    metadata:
      labels:
        run: neg-demo-app # Labels Pods from this Deployment
    spec: # Pod specification; each Pod created by this Deployment has this specification
      containers:
      - image: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname # Container name
        ports:
        - containerPort: 9376
          protocol: TCP

Utilizzo del ritardo impostato come hardcoded

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: neg-demo-app # Label for the Deployment
  name: neg-demo-app # Name of Deployment
spec:
  minReadySeconds: 60 # Number of seconds to wait after a Pod is created and its status is Ready
  selector:
    matchLabels:
      run: neg-demo-app
  template: # Pod template
    metadata:
      labels:
        run: neg-demo-app # Labels Pods from this Deployment
    spec: # Pod specification; each Pod created by this Deployment has this specification
      containers:
      - image: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname # Container name
      # Note: The following line is necessary only on clusters running GKE v1.11 and lower.
      # For details, see https://cloud.google.com/kubernetes-engine/docs/how-to/container-native-load-balancing#align_rollouts
        ports:
        - containerPort: 9376
          protocol: TCP
      terminationGracePeriodSeconds: 60 # Number of seconds to wait for connections to terminate before shutting down Pods

In questo deployment, ogni container esegue un server HTTP. Il server HTTP restituisce il nome host del server delle applicazioni (il nome del pod su cui server web) come risposta.

Salva questo manifest con il nome neg-demo-app.yaml, quindi crea il deployment:

kubectl apply -f neg-demo-app.yaml

Crea un servizio per un bilanciatore del carico nativo del container

Dopo aver creato un deployment, devi raggrupparne i pod in un Servizio.

Il seguente servizio di esempio, neg-demo-svc, ha come target il deployment di esempio che creato nella sezione precedente:

apiVersion: v1
kind: Service
metadata:
  name: neg-demo-svc # Name of Service
  annotations:
    cloud.google.com/neg: '{"ingress": true}' # Creates a NEG after an Ingress is created
spec: # Service's specification
  type: ClusterIP
  selector:
    run: neg-demo-app # Selects Pods labelled run: neg-demo-app
  ports:
  - name: http
    port: 80 # Service's port
    protocol: TCP
    targetPort: 9376

L'annotazione del servizio, cloud.google.com/neg: '{"ingress": true}', consente il bilanciamento del carico nativo del container. Tuttavia, il bilanciatore del carico non viene creato finché crei una risorsa Ingress per il servizio.

Salva questo manifest come neg-demo-svc.yaml, quindi crea il servizio:

kubectl apply -f neg-demo-svc.yaml

Crea una risorsa Ingress per il servizio

Il seguente esempio In entrata, neg-demo-ing ha come target il servizio che hai creato:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: neg-demo-ing
spec:
  defaultBackend:
    service:
      name: neg-demo-svc # Name of the Service targeted by the Ingress
      port:
        number: 80 # Should match the port used by the Service

Salva questo manifest come neg-demo-ing.yaml, quindi crea l'oggetto Ingress:

kubectl apply -f neg-demo-ing.yaml

Al momento della creazione dell'Ingress, viene creato un bilanciatore del carico delle applicazioni nel progetto. e i gruppi di endpoint di rete(NEG) vengono creati in ciascuna zona in cui viene eseguito il cluster. Gli endpoint in il NEG e gli endpoint del servizio siano sincronizzati.

Verifica il traffico in entrata

Dopo aver eseguito il deployment di un carico di lavoro, raggruppato i suoi pod in un servizio e creato una risorsa Ingress per il servizio, devi verificare che sia stato eseguito il provisioning di una risorsa Ingress con il bilanciatore del carico nativo del container.

Recupera lo stato dell'oggetto Ingress:

kubectl describe ingress neg-demo-ing

L'output include eventi ADD e CREATE:

Events:
Type     Reason   Age                From                     Message
----     ------   ----               ----                     -------
Normal   ADD      16m                loadbalancer-controller  default/neg-demo-ing
Normal   Service  4s                 loadbalancer-controller  default backend set to neg-demo-svc:32524
Normal   CREATE   2s                 loadbalancer-controller  ip: 192.0.2.0

Testa il bilanciatore del carico

Le sezioni seguenti spiegano come testare la funzionalità di un il bilanciatore del carico nativo del container.

Visita l'indirizzo IP Ingress

Attendi alcuni minuti per la configurazione del bilanciatore del carico delle applicazioni.

Puoi verificare che il bilanciatore del carico nativo del container funzioni visitando l'Ingress Indirizzo IP.

Per ottenere l'indirizzo IP Ingress, esegui questo comando:

kubectl get ingress neg-demo-ing

Nell'output comando, il campo L'indirizzo IP viene visualizzato in ADDRESS colonna. Visita l'indirizzo IP in un browser web.

Controlla lo stato di integrità del servizio di backend

Puoi anche ottenere lo stato di integrità del bilanciatore del carico servizio di backend.

  1. Recupera un elenco dei servizi di backend in esecuzione nel tuo progetto:

    gcloud compute backend-services list

    Annota il nome del servizio di backend che include il nome del Servizio, ad esempio neg-demo-svc.

  2. Ottieni lo stato di integrità del servizio di backend:

    gcloud compute backend-services get-health BACKEND_SERVICE_NAME --global

    Sostituisci BACKEND_SERVICE_NAME con il nome del di servizio di backend.

Testa Ingress

Un altro modo per verificare che il bilanciatore del carico funzioni come previsto è scalare il deployment di esempio, inviare richieste di test a Ingress verificando che risponda il numero corretto di repliche.

  1. Scala il deployment neg-demo-app da un'istanza a due istanze:

    kubectl scale deployment neg-demo-app --replicas 2

    Il completamento di questo comando potrebbe richiedere diversi minuti.

  2. Verifica che l'implementazione sia completa:

    kubectl get deployment neg-demo-app

    L'output dovrebbe includere due repliche disponibili:

    NAME           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
neg-demo-app   2         2         2            2           26m

  3. Ottieni l'indirizzo IP Ingress:

    kubectl describe ingress neg-demo-ing

    Se il comando restituisce un errore 404, attendi qualche minuto che il caricamento bilanciatore del carico, quindi riprova.

  4. Conta il numero di risposte distinte dal bilanciatore del carico:

    for i in `seq 1 100`; do \
  curl --connect-timeout 1 -s IP_ADDRESS && echo; \
done  | sort | uniq -c

    Sostituisci IP_ADDRESS con l'indirizzo IP Ingress.

    L'output è simile al seguente:

    44 neg-demo-app-7f7dfd7bc6-dcn95
56 neg-demo-app-7f7dfd7bc6-jrmzf

    In questo output, il numero di risposte distinte è uguale al numero di repliche, il che indica che tutti i pod di backend gestiscono il traffico.

Esegui la pulizia

Dopo aver completato le attività in questa pagina, segui questi passaggi per rimuovere per evitare addebiti indesiderati sul tuo account:

Elimina il cluster

gcloud

gcloud container clusters delete neg-demo-cluster

Console

  1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

    Vai a Google Kubernetes Engine

  2. Seleziona neg-demo-cluster e fai clic su Elimina.

  3. Quando ti viene richiesto di confermare, fai clic su Elimina.

Risoluzione dei problemi

Utilizza le tecniche riportate di seguito per verificare la configurazione della rete. La le seguenti sezioni spiegano come risolvere problemi specifici relativi a: il bilanciamento del carico nativo del container.

  • Consulta la documentazione sul bilanciamento del carico su come elencare i gruppi di endpoint di rete.

  • Puoi trovare il nome e le zone del NEG che corrisponde a un servizio in l'annotazione neg-status del servizio. Ottieni la specifica del servizio con:

    kubectl get svc SVC_NAME -o yaml

    L'annotazione metadata:annotations:cloud.google.com/neg-status elenca nome del NEG corrispondente al servizio e delle zone del NEG.

  • Puoi controllare l'integrità del servizio di backend che corrisponde a un NEG con il seguente comando:

    gcloud compute backend-services --project PROJECT_NAME \
    get-health BACKEND_SERVICE_NAME --global

    Il servizio di backend ha lo stesso nome del relativo NEG.

  • Per stampare i log eventi di un servizio:

    kubectl describe svc SERVICE_NAME

    La stringa del nome del servizio include il nome e lo spazio dei nomi dell'oggetto servizio GKE.

Impossibile creare un cluster con IP alias

Sintomi

Quando tenti di creare un cluster con IP alias, potresti riscontrare il seguente errore:

ResponseError: code=400, message=IP aliases cannot be used with a legacy network.
Potenziali cause

Questo errore si verifica se tenti di creare un cluster con IP alias che utilizza anche una rete legacy.

Risoluzione

Assicurati di non creare un cluster con IP alias e una rete legacy attivate contemporaneamente. Per ulteriori informazioni sull'uso degli IP alias, consulta Crea un cluster nativo di VPC.

Il traffico non raggiunge gli endpoint

Sintomi
Errori 502/503 o connessioni rifiutate.
Potenziali cause

In genere, i nuovi endpoint diventano raggiungibili dopo averli collegati al carico di fatturazione, purché rispondano ai controlli di integrità. Potresti riscontrare l'errore 502 errori o connessioni rifiutate se il traffico non può raggiungere gli endpoint.

Gli errori 502 e le connessioni rifiutate possono essere causati anche da un container che non gestisce SIGTERM. Se un container non gestisce esplicitamente SIGTERM, termina immediatamente e interrompe la gestione delle richieste. Il bilanciatore del carico continua a inviare traffico in entrata al container terminato, causando errori.

Il bilanciatore del carico nativo del container ha un solo endpoint di backend. Durante un aggiornamento in sequenza, il vecchio endpoint viene deprogrammato prima di quello nuovo vengono programmati.

Il deployment dei pod di backend viene eseguito in una nuova zona per la prima volta dopo viene eseguito il provisioning del bilanciatore del carico nativo del container. Infrastruttura del bilanciatore del carico è programmato in una zona quando è presente almeno un endpoint. Quando un nuovo endpoint viene aggiunto a una zona, l'infrastruttura del bilanciatore del carico sono stati programmati e causano interruzioni del servizio.

Risoluzione

Configura i container per gestire SIGTERM e continuare a rispondere alle richieste durante il periodo di tolleranza per la risoluzione (30 secondi per impostazione predefinita). Configura i pod per iniziare a non superare i controlli di integrità quando ricevono SIGTERM. Ciò segnala dell'endpoint per interrompere l'invio di traffico al pod mentre la deprogrammazione dell'endpoint è in corso.

Se la tua applicazione non si arresta normalmente e smette di rispondere a alle richieste quando si riceve un SIGTERM, gancio pre-interruzione può essere utilizzato per gestire SIGTERM e continuare a gestire il traffico mentre l'endpoint è in corso la deprogrammazione.

lifecycle:
  preStop:
    exec:
      # if SIGTERM triggers a quick exit; keep serving traffic instead
      command: ["sleep","60"]

Consulta le documentazione sulla terminazione dei pod.

Se il backend del bilanciatore del carico ha una sola istanza, configura il rollback la strategia per evitare di eliminare l'unica istanza prima della nuova sia completamente programmato. Per i pod delle applicazioni gestiti dal carico di lavoro Deployment, puoi farlo configurando l'implementazione strategia con parametro maxUnavailable uguale a 0.

strategy:
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

Per risolvere i problemi relativi al traffico che non raggiunge gli endpoint, verifica che le regole firewall consenti il traffico TCP in entrata verso gli endpoint in 130.211.0.0/22 e Intervalli 35.191.0.0/16. Per saperne di più, consulta: Aggiunta di controlli di integrità nel documentazione di Cloud Load Balancing.

Visualizza i servizi di backend nel tuo progetto. La stringa del nome del segmento include il nome e lo spazio dei nomi del servizio di backend Servizio GKE:

gcloud compute backend-services list

Recupera lo stato di integrità del backend dal servizio di backend:

gcloud compute backend-services get-health BACKEND_SERVICE_NAME

Se tutti i backend sono in stato non integro, il firewall, Ingress o il servizio potrebbe essere configurazione errata.

Se alcuni backend non sono integri per un breve periodo di tempo, la programmazione di rete potrebbe essere la causa.

Se alcuni backend non compaiono nell'elenco dei servizi di backend, la programmazione potrebbe essere la causa. Puoi verificarlo eseguendo questo dove NEG_NAME è il nome del servizio di backend. (I NEG e i servizi di backend condividono lo stesso nome):

gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME

Controlla se tutti gli endpoint previsti si trovano nel NEG.

Se hai un numero ridotto di backend (ad esempio 1 pod) selezionati da un bilanciatore del carico nativo del container, valuta la possibilità di aumentare il numero e distribuire i pod di backend in tutte le zone di cluster Kubernetes. Questo garantirà che l'infrastruttura sottostante del bilanciatore del carico sia completamente programmato. In caso contrario, valuta la possibilità di limitare i pod di backend in una singola zona.

Se configuri un criterio di rete per l'endpoint, assicurati che il traffico in entrata dalla subnet solo proxy è consentita.

Implementazione bloccata

Sintomi
L'implementazione di blocchi di deployment aggiornati e il numero di pod di repliche non corrisponde al numero desiderato di repliche.
Potenziali cause

I controlli di integrità del deployment non sono riusciti. L'immagine container potrebbe non essere valida o che il controllo di integritàà non sia configurato correttamente. La sostituzione in sequenza dei pod attende che il pod appena avviato superi Limite di idoneità dei pod. Questo si verifica solo se il pod risponde ai controlli di integrità del bilanciatore del carico. Se il pod non risponde o, se il controllo di integrità non è configurato correttamente, il controllo di condizioni non possono essere soddisfatte e l'implementazione non può continuare.

Se utilizzi kubectl 1.13 o versioni successive, puoi controllare lo stato della pod i limiti di idoneità con il seguente comando:

kubectl get pod POD_NAME -o wide

Controlla la colonna READINESS GATES.

Questa colonna non esiste in kubectl 1.12 e versioni precedenti. Un pod contrassegnato in quanto nello stato READY potrebbe avere un limite di idoneità non superato. Per eseguire la verifica utilizza questo comando:

kubectl get pod POD_NAME -o yaml

I gate di idoneità e il relativo stato sono elencati nell'output.

Risoluzione

Verifica che l'immagine container nella specifica dei pod del deployment sia funziona correttamente ed è in grado di rispondere ai controlli di integrità. Verifica che che i controlli di integrità siano configurati correttamente.

Errori di modalità con prestazioni ridotte

Sintomi

A partire dalla versione di GKE 1.29.2-gke.1643000, potresti ricevere i seguenti avvisi sul tuo servizio in Esplora log quando vengono aggiornati i NEG:

Entering degraded mode for NEG <service-namespace>/<service-name>-<neg-name>... due to sync err: endpoint has missing nodeName field
Potenziali cause

Questi avvisi indicano che GKE ha rilevato l'endpoint configurazioni errate durante un aggiornamento del NEG in base a EndpointSlice oggetti, che attivano un processo di calcolo più approfondito chiamato degrado . GKE continua ad aggiornare i NEG secondo il criterio del "best effort", correggendo l'errata configurazione o escludendo gli endpoint non validi dagli aggiornamenti del NEG.

Alcuni errori comuni sono:

  • endpoint has missing pod/nodeName field
  • endpoint corresponds to an non-existing pod/node
  • endpoint information for attach/detach operation is incorrect
Risoluzione

In genere, gli stati transitori causano questi eventi e sono fissi autonomamente. Tuttavia, gli eventi causati da configurazioni errate negli oggetti EndpointSlice personalizzati rimangono irrisolti. Per comprendere l'errata configurazione, esamina gli oggetti EndpointSlice corrispondenti al servizio:

kubectl get endpointslice -l kubernetes.io/service-name=<service-name>

Convalida ogni endpoint in base all'errore nell'evento.

Per risolvere il problema, devi modificare manualmente gli oggetti EndpointSlice. L'aggiornamento attiva un nuovo aggiornamento dei NEG. Quando l'errore di configurazione non esiste più, l'output è simile al seguente:

NEG <service-namespace>/<service-name>-<neg-name>... is no longer in degraded mode

Problemi noti

Il bilanciamento del carico nativo del container su GKE ha i seguenti problemi:

garbage collection incompleta

La garbage collection GKE raccoglie bilanciatori del carico nativi del container ogni due minuti. Se un cluster viene eliminato prima della rimozione completa dei bilanciatori del carico, devi eliminare manualmente i NEG del bilanciatore del carico.

Visualizza i NEG nel tuo progetto eseguendo questo comando:

gcloud compute network-endpoint-groups list

Nell'output comando, cerca i NEG pertinenti.

Per eliminare un NEG, esegui questo comando, sostituendo NEG_NAME con il nome del NEG:

gcloud compute network-endpoint-groups delete NEG_NAME

Allinea le implementazioni dei carichi di lavoro con la propagazione degli endpoint

Quando esegui il deployment di un carico di lavoro nel cluster o quando aggiorni un modello esistente carico di lavoro, il bilanciatore del carico nativo del container può impiegare più tempo a propagarsi di quello necessario per completare l'implementazione del carico di lavoro. Il deployment di esempio che distribuisci in questa guida usa due campi per allineare l'implementazione con propagazione degli endpoint: terminationGracePeriodSeconds e minReadySeconds.

terminationGracePeriodSeconds permette al pod arrestato in modo controllato attendendo che le connessioni vengano terminate dopo che un pod ne è stata pianificata l'eliminazione.

minReadySeconds aggiunge un periodo di latenza dopo che un pod è stato creato. Specifica il numero minimo di secondi di cui deve essere eseguito il nuovo pod nel Stato Ready, senza che si verifichi un arresto anomalo di nessuno dei suoi container, affinché il pod sia considerato disponibile.

Devi configurare i carichi di lavoro minReadySeconds e terminationGracePeriodSeconds di un valore pari o superiore a 60 secondi per garantire che il servizio non subisca interruzioni a causa delle implementazioni dei carichi di lavoro.

terminationGracePeriodSeconds è disponibile in tutte le specifiche dei pod minReadySeconds è disponibile per gli oggetti Deployment e DaemonSet.

Per scoprire di più sull'ottimizzazione delle implementazioni, consulta RollingUpdateStrategy.

initialDelaySeconds nel pod readinessProbe non rispettata

Potresti aspettarti la configurazione initialDelaySeconds nel pod readinessProbe il bilanciatore del carico nativo del container deve essere rispettato. tuttavia, readinessProbe è implementato da kubelet, mentre i controlli di configurazione initialDelaySeconds il controllo di integrità kubelet, non il bilanciatore del carico nativo del container. Nativo del container ha un proprio controllo di integrità del bilanciamento del carico.

Passaggi successivi