Bilanciamento del carico nativo del container tramite Ingress

Autopilot Standard

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

Per saperne di più sui vantaggi, sui requisiti e sulle limitazioni del bilanciamento del carico nativo dei container, consulta Bilanciamento del carico nativo dei container.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

• Attiva l'API Google Kubernetes Engine.
Attiva l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
  Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare la proprietà compute/region. Se utilizzi principalmente cluster zonali, imposta invece compute/zone. Se imposti una località predefinita, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location. Potresti dover specificare la posizione in determinati comandi se la posizione del cluster è diversa da quella predefinita che hai impostato.

• Assicurati di avere un cluster nativo di VPC esistente. Se ne hai bisogno, crea un cluster. I cluster GKE sono VPC nativi per impostazione predefinita.

Utilizza il bilanciamento del carico nativo del container

Le sezioni seguenti illustrano una configurazione del bilanciamento del carico nativo del container su GKE.

Creazione di un deployment

Il seguente esempio di deployment, neg-demo-app, esegue una singola istanza di un server HTTP in container. Ti consigliamo di utilizzare carichi di lavoro che utilizzano il feedback sulla prontezza dei pod.

Utilizzo del feedback sulla preparazione del 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
  

Utilizzare il ritardo 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 viene eseguito il server) come risposta.

Salva questo manifest come neg-demo-app.yaml, poi 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 raggruppare i relativi pod in un servizio.

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

apiVersion: v1
kind: Service
metadata:
  name: neg-demo-svc # Name of Service
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

Nota: il servizio è esposto sulla porta 80 e reindirizza il traffico alla porta 9376, targetPort. targetPort corrisponde a un containerPort in un pod di servizio. È anche possibile utilizzare un servizio di tipo NodePort con il bilanciamento del carico nativo del container. È consigliabile un servizio di tipo ClusterIP, a meno che non sia necessario in modo esplicito il nodePort fornito da un servizio NodePort. I servizi LoadBalancer non sono supportati come backend Ingress.

Il bilanciatore del carico non viene creato finché non crei un Ingress per il servizio.

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

kubectl apply -f neg-demo-svc.yaml

Crea un Ingress per il servizio

Il seguente esempio di Ingress, 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, poi crea l'ingresso:

kubectl apply -f neg-demo-ing.yaml

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

Verifica l'ingresso

Dopo aver eseguito il deployment di un workload, raggruppato i relativi pod in un servizio e creato un Ingress per il servizio, devi verificare che l'Ingress abbia eseguito il provisioning del bilanciatore del carico nativo del container.

Recupera lo stato dell'ingresso:

kubectl describe ingress neg-demo-ing

L'output include gli 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 bilanciatore del carico nativo dei container.

Visita l'indirizzo IP in entrata

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'indirizzo IP di Ingress.

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

kubectl get ingress neg-demo-ing

Nell'output del comando, l'indirizzo IP di Ingress viene visualizzato nella colonna ADDRESS. Visita l'indirizzo IP in un browser web.

Controllare lo stato di integrità del servizio di backend

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

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

   gcloud compute backend-services list
   

   Registra 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 servizio di backend.

Testa l'ingresso

Un altro modo per verificare che il bilanciamento del carico funzioni come previsto è scalare il deployment di esempio, inviare richieste di test all'ingresso e verificare 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 completata:

   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 in entrata:

   kubectl describe ingress neg-demo-ing
   

   Se questo comando restituisce un errore 404, attendi qualche minuto l'avvio del bilanciamento del carico, poi 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 le risorse ed 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.

Passaggi successivi

• Scopri come utilizzare il bilanciamento del carico nativo del container tramite NEG standalone a livello di zona.
• Scopri di più sui cluster nativi di VPC.
• Scopri di più sulla configurazione di Ingress.
• Scopri come utilizzare i certificati SSL gestiti da Google.