Esegui il deployment di servizi LoadBalancer multirete

Questo documento mostra come esporre i pod multirete a client interni o esterni creando risorse di bilanciatore del carico di rete passthrough esterno e bilanciatore del carico di rete passthrough interno in GKE. Google Cloud Descrive la configurazione, le funzionalità e i limiti richiesti dei servizi LoadBalancer multi-rete.

Se connetti i carichi di lavoro a più reti VPC, utilizza un servizio Kubernetes di tipo LoadBalancer per instradare il traffico ai pod su una rete secondaria specifica. Quando crei il servizio, GKE crea un bilanciatore del carico di rete pass-through per gestire questo traffico.

Per saperne di più sul multi-networking in GKE, consulta Informazioni sul supporto di più reti per i pod.

Come funzionano i servizi LoadBalancer multi-rete

Per esporre un carico di lavoro multirete, crea un Service di type: LoadBalancer. Il servizio deve includere un selettore speciale che ha come target i pod in base alla rete della loro interfaccia secondaria. Aggiungi un'annotazione per specificare se creare un bilanciatore del carico interno o esterno.

L'etichetta networking.gke.io/network nel selettore filtra gli endpoint in base alla rete. Questa etichetta garantisce che il bilanciatore del carico invii il traffico solo alle interfacce del pod connesse alla rete specificata.

Limitazioni

I bilanciatori del carico multirete presentano le seguenti limitazioni:

  • I servizi che utilizzano externalTrafficPolicy: Cluster non sono supportati.
  • I servizi che hanno come target i pod hostNetwork non sono supportati.
  • Il networking IPv6 e dual-stack non è supportato.
  • Non puoi modificare l'emittente di un servizio esistente.
  • Sono supportate solo le reti di livello 3.
  • I bilanciatori del carico basati su pool di destinazione o backend di gruppi di istanze non sono supportati.
  • I servizi ClusterIP e NodePort non sono supportati sulle reti secondarie (non predefinite).

Prima di iniziare

Prima di iniziare, completa le seguenti attività:

  1. Segui i passaggi descritti in Configura il supporto di più reti per i pod per preparare le reti VPC e creare un cluster GKE con una rete aggiuntiva.
  2. Assicurati che il cluster abbia abilitato l'impostazione secondaria per i bilanciatori del carico interni di livello 4. Per attivare questa funzionalità, utilizza il flag --enable-l4-ilb-subsetting quando crei o aggiorni il cluster.
  3. Assicurati che sul cluster sia in esecuzione GKE versione 1.37 o successiva.

Esegui il deployment di pod multi-rete

Per collegare i pod a una rete aggiuntiva, crea un deployment con l'annotazione networking.gke.io/interfaces. Questa annotazione specifica le reti e le interfacce per i pod.

  1. Salva il seguente manifest come web-app-deployment.yaml:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: web-app
      labels:
        app: web-app
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: web-app
      template:
        metadata:
          labels:
            app: web-app
          annotations:
            networking.gke.io/default-interface: 'eth1'
            networking.gke.io/interfaces: '[
              {"interfaceName":"eth0","network":"default"},
              {"interfaceName": "eth1","network": "dmz"}
            ]'
    spec:
      containers:
      - name: whereami
        image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
        ports:
        - containerPort: 8080
    

    Questo manifest crea un deployment denominato web-app con tre pod. I pod hanno due interfacce: eth0 connessa alla rete default e eth1 connessa alla rete dmz. L'annotazione networking.gke.io/default-interface imposta eth1 come interfaccia predefinita per i pod.

  2. Applica il manifest al cluster:

    kubectl apply -f web-app-deployment.yaml
    

Se utilizzi un'interfaccia non predefinita per il tuo servizio, devi configurare il routing all'interno del pod. Per configurare il routing, aggiungi un initContainer alla specifica del pod con la funzionalità NET_ADMIN.

L'esempio seguente mostra un initContainer che aggiunge una route predefinita per l'interfaccia eth1:

initContainers:
      - name: init-routes-busybox
        image: busybox
        command: ['sh', '-c', 'ip route add default dev eth1 table 200 && ip rule add from 172.16.1.0/24 table 200']
        securityContext:
          capabilities:
            add: ["NET_ADMIN"]

Nel comando initContainer, sostituisci 172.16.1.0/24 con l'intervallo di indirizzi IP secondari della rete dei pod.

Esegui il deployment di un servizio LoadBalancer interno

Per esporre il deployment web-app sulla rete dmz, crea un servizio LoadBalancer interno.

  1. Salva il seguente manifest come internal-lb-service.yaml:

    apiVersion: v1
    kind: Service
    metadata:
      name: web-app-internal-lb
      namespace: default
      annotations:
        networking.gke.io/load-balancer-type: "Internal"
    spec:
      externalTrafficPolicy: Local
      ports:
      -   port: 80
        protocol: TCP
        targetPort: 8080
      selector:
        networking.gke.io/network: dmz
        app: web-app
      type: LoadBalancer
    

    Questo manifest crea un servizio con le seguenti proprietà:

    • networking.gke.io/load-balancer-type: "Internal": specifica un bilanciatore del carico di rete passthrough interno.
    • selector: seleziona i pod con l'etichetta app: web-app connessi alla rete dmz.
  2. Applica il manifest al cluster:

    kubectl apply -f internal-lb-service.yaml
    

Esegui il deployment di un servizio LoadBalancer esterno

Per esporre il deployment web-app a client esterni, crea un servizio LoadBalancer esterno.

  1. Salva il seguente manifest come external-lb-service.yaml:

    apiVersion: v1
    kind: Service
    metadata:
      name: web-app-external-lb
      namespace: default
      annotations:
        cloud.google.com/l4-rbs: "enabled"
    spec:
      externalTrafficPolicy: Local
      ports:
      -   port: 80
        protocol: TCP
        targetPort: 8080
      selector:
        networking.gke.io/network: dmz
        app: web-app
      type: LoadBalancer
    

    Questo manifest crea un servizio con le seguenti proprietà:

    • cloud.google.com/l4-rbs: "enabled": specifica un bilanciatore del carico di rete passthrough esterno basato su un servizio di backend.
    • selector: seleziona i pod con l'etichetta app: web-app connessi alla rete dmz.
  2. Applica il manifest al cluster:

    kubectl apply -f external-lb-service.yaml
    

Verificare i servizi

Dopo aver eseguito il deployment dei servizi, verifica che i bilanciatori del carico siano stati creati e configurati correttamente.

  1. Controlla lo stato dei servizi:

    kubectl get services
    

    L'output è simile al seguente:

    NAME                  TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)        AGE
    web-app-external-lb   LoadBalancer   10.8.47.77    35.239.57.231   80:31550/TCP   5m
    web-app-internal-lb   LoadBalancer   10.8.43.251   172.16.0.43     80:32628/TCP   6m
    kubernetes            ClusterIP      10.8.32.1     <none>          443/TCP        43h
    

    L'indirizzo EXTERNAL-IP per il bilanciatore del carico interno appartiene alla rete dmz.

  2. Elenca le regole di forwarding nel progetto:

    gcloud compute forwarding-rules list
    

    L'output è simile al seguente:

    NAME                                                   REGION        IP_ADDRESS     IP_PROTOCOL  TARGET
    af901673cc0f24907a6aa8c3ce4afc21                       us-central1   35.239.57.231  TCP          us-central1/backendServices/k8s2-xhvzqabw-default-web-app-external-lb-u4xbs4ot
    k8s2-tcp-xhvzqabw-default-web-app-internal-lb-vp1x1d6a us-central1   172.16.0.43    TCP          us-central1/backendServices/k8s2-xhvzqabw-default-web-app-internal-lb-vp1x1d6a
    
  3. Descrivi la regola di forwarding per il bilanciatore del carico interno per verificare che sia collegata alla rete corretta:

    gcloud compute forwarding-rules describe k8s2-tcp-xhvzqabw-default-web-app-internal-lb-vp1x1d6a --region=$REGION
    

    Sostituisci REGION con la regione del tuo cluster.

    L'output è simile al seguente. Verifica che i campi network e subnetwork corrispondano ai dettagli della rete dmz.

    IPAddress: 172.16.0.43
    IPProtocol: TCP
    ...
    loadBalancingScheme: INTERNAL
    name: k8s2-tcp-xhvzqabw-default-web-app-internal-lb-vp1x1d6a
    network: https://www.googleapis.com/compute/v1/projects/projectId/global/networks/dmz-vpc
    ...
    subnetwork: https://www.googleapis.com/compute/v1/projects/projectId/regions/us-central1/subnetworks/dmz-subnet
    

Testa i bilanciatori del carico

  1. Per testare il bilanciatore del carico esterno, invia una richiesta al relativo indirizzo IP esterno:

    curl EXTERNAL_LB_IP:80
    

    Sostituisci EXTERNAL_LB_IP con l'indirizzo IP esterno del servizio web-app-external-lb.

  2. Per testare il bilanciatore del carico interno, invia una richiesta da un host nella stessa VPC del bilanciatore del carico:

    curl INTERNAL_LB_IP:80
    

    Sostituisci INTERNAL_LB_IP con l'indirizzo IP del servizio web-app-internal-lb.

Risoluzione dei problemi

Questa sezione descrive come risolvere i problemi relativi ai bilanciatori del carico multirete.

La creazione del bilanciatore del carico non riesce

Se la creazione del bilanciatore del carico non riesce, controlla i messaggi di errore in Eventi di servizio:

kubectl describe service SERVICE_NAME

Sostituisci SERVICE_NAME con il nome del tuo servizio.

Un messaggio di errore come network some-other-network does not exist indica che la rete specificata nel selettore del servizio non è definita nel cluster. Verifica che la rete esista:

kubectl get networks

Se la rete esiste, verifica che l'oggetto Network faccia riferimento correttamente a una risorsa GKENetworkParamSet valida. Per verificare la presenza di errori di configurazione, controlla lo stato della risorsa Network:

kubectl get networks NETWORK_NAME -o yaml

Sostituisci NETWORK_NAME con il nome della tua rete.

In una configurazione valida, le condizioni ParamsReady e Ready sono True. Se ParamsReady non è True, assicurati che parametersRef nella specifica Network corrisponda correttamente al nome, al tipo e al gruppo di una risorsa GKENetworkParamSet esistente.

Se la risorsa Network è corretta ma non è ancora pronta, controlla lo stato della risorsa GKENetworkParamSet a cui viene fatto riferimento per errori, ad esempio una subnet mancante:

kubectl get gkenetworkparamsets GNP_NAME -o yaml

Sostituisci GNP_NAME con il nome del tuo GKENetworkParamSet.

Il bilanciatore del carico non ha backend

Se il bilanciatore del carico viene sottoposto a provisioning, ma non ha backend integri, procedi nel seguente modo:

  1. Verifica che esista un pool di nodi con interfacce di rete nella rete utilizzata dal servizio.
  2. Verifica che i pod selezionati dal servizio siano in esecuzione.
  3. Controlla gli endpoint del servizio:

    kubectl describe endpointslice -l kubernetes.io/service-name=SERVICE_NAME
    

    Il controller multinet-endpointslice-controller.gke.io crea gli endpoint multirete. Gli indirizzi IP dei pod elencati in EndpointSlice appartengono alla rete utilizzata dal servizio. Se EndpointSlice non ha endpoint, verifica che le etichette del selettore del servizio corrispondano ai pod in esecuzione e che il selettore di rete corrisponda alla rete dei pod.

Passaggi successivi