Deployment di Ingress in diversi cluster

Questa pagina mostra come eseguire il deployment di un Ingress che fornisce un'applicazione su più cluster GKE. Per scoprire di più su Ingress multi-cluster, consulta Ingress multi-cluster.

Per un confronto dettagliato tra Ingress multi-cluster (MCI), gateway multi-cluster (MCG) e bilanciatore del carico con gruppi di endpoint di rete autonomi (LB e NEG autonomi), consulta Scegliere l'API di bilanciamento del carico multi-cluster per GKE.

Tutorial sul deployment

Nelle attività seguenti, eseguirai il deployment di un'app fittizia denominata whereami e di un MultiClusterIngress in due cluster. Ingress fornisce un indirizzo IP virtuale (VIP) condiviso per i deployment delle app.

Questa pagina si basa sul lavoro svolto in Configurazione di Ingress multi-cluster, dove hai creato e registrato due cluster. Verifica di avere due cluster registrati anche in un parco risorse:

gcloud container clusters list

L'output è simile al seguente:

NAME    LOCATION        MASTER_VERSION  MASTER_IP       MACHINE_TYPE   NODE_VERSION     NUM_NODES  STATUS
gke-eu  europe-west1-b  1.16.8-gke.9    ***             e2-medium      1.16.8-gke.9     2          RUNNING
gke-us  us-central1-b   1.16.8-gke.9    ***             e2-medium      1.16.6-gke.13 *  2          RUNNING

Creazione dello spazio dei nomi

Poiché i parchi hanno la proprietà di uguaglianza dello spazio dei nomi, ti consigliamo di coordinare la creazione e la gestione degli spazi dei nomi nei vari cluster in modo che gli spazi dei nomi identici siano di proprietà e gestiti dallo stesso gruppo. Puoi creare spazi dei nomi per team, ambiente, applicazione o componente dell'applicazione. Gli spazi dei nomi possono essere granulari quanto necessario, purché uno spazio dei nomi ns1 in un cluster abbia lo stesso significato e utilizzo di ns1 in un altro cluster.

In questo esempio, crei uno spazio dei nomi whereami per ogni applicazione in ogni cluster.

  1. Crea un file denominato namespace.yaml con i seguenti contenuti:

    apiVersion: v1
kind: Namespace
metadata:
  name: whereami

  2. Passa al contesto gke-us:

    kubectl config use-context gke-us

  3. Crea lo spazio dei nomi:

    kubectl apply -f namespace.yaml

  4. Passa al contesto gke-eu:

    kubectl config use-context gke-eu

  5. Crea lo spazio dei nomi:

    kubectl apply -f namespace.yaml

    L'output è simile al seguente:

    namespace/whereami created

Esegui il deployment dell'app

  1. Crea un file denominato deploy.yaml con i seguenti contenuti:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: whereami-deployment
  namespace: whereami
  labels:
    app: whereami
spec:
  selector:
    matchLabels:
      app: whereami
  template:
    metadata:
      labels:
        app: whereami
    spec:
      containers:
      - name: frontend
        image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
        ports:
        - containerPort: 8080

  2. Passa al contesto gke-us:

    kubectl config use-context gke-us

  3. Esegui il deployment dell'app whereami:

    kubectl apply -f deploy.yaml

  4. Passa al contesto gke-eu:

    kubectl config use-context gke-eu

  5. Esegui il deployment dell'app whereami:

    kubectl apply -f deploy.yaml

  6. Verifica che l'app whereami sia stata implementata correttamente in ogni cluster:

    kubectl get deployment --namespace whereami

    L'output dovrebbe essere simile al seguente in entrambi i cluster:

    NAME           READY   UP-TO-DATE   AVAILABLE   AGE
whereami-deployment   1/1     1            1           12m

Deployment tramite il cluster di configurazione

Ora che l'applicazione è dipiattata su gke-us e gke-eu, devi eseguire il deployment di un bilanciatore del carico tramite le risorse MultiClusterIngress e MultiClusterService nel cluster di configurazione. Si tratta degli equivalenti multi-cluster delle risorse Ingress e Service.

Nella guida alla configurazione, hai configurato il cluster gke-us come cluster di configurazione. Il cluster di configurazione viene utilizzato per eseguire il deployment e configurare Ingress in tutti i cluster.

  1. Imposta il contesto sul cluster di configurazione.

    kubectl config use-context gke-us

MultiClusterService

  1. Crea un file denominato mcs.yaml con i seguenti contenuti:

    apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: whereami-mcs
  namespace: whereami
spec:
  template:
    spec:
      selector:
        app: whereami
      ports:
      - name: web
        protocol: TCP
        port: 8080
        targetPort: 8080

  2. Esegui il deployment della risorsa MultiClusterService corrispondente all'app whereami:

    kubectl apply -f mcs.yaml

  3. Verifica che la risorsa whereami-mcs sia stata dispiata correttamente nel cluster di configurazione:

    kubectl get mcs -n whereami

    L'output è simile al seguente:

    NAME       AGE
whereami-mcs   9m26s

    Questo MultiClusterService crea un servizio headless derivato in ogni cluster che corrisponde ai pod con app: whereami. Puoi vedere che ne esiste uno nel cluster gke-us kubectl get service -n whereami.

    L'output è simile al seguente:

    NAME                                TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
mci-whereami-mcs-svc-lgq966x5mxwwvvum   ClusterIP   None          <none>        8080/TCP         4m59s

In gke-eu esisterà anche un servizio headless simile. Questi servizi locali vengono utilizzati per selezionare dinamicamente gli endpoint dei pod al fine di programmare il bilanciatore del carico Ingress globale con i backend.

MultiClusterIngress

  1. Crea un file denominato mci.yaml con i seguenti contenuti:

    apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: whereami-ingress
  namespace: whereami
spec:
  template:
    spec:
      backend:
        serviceName: whereami-mcs
        servicePort: 8080

    Tieni presente che questa configurazione instrada tutto il traffico all'MultiClusterService whereami-mcs esistente nello spazio dei nomi whereami.

  2. Esegui il deployment della risorsa MultiClusterIngress che fa riferimento a whereami-mcs come backend:

    kubectl apply -f mci.yaml

    L'output è simile al seguente:

    multiclusteringress.networking.gke.io/whereami-ingress created

    Tieni presente che MultiClusterIngress ha lo stesso schema di Ingress di Kubernetes. Anche la semantica della risorsa Ingress è la stessa, ad eccezione del campo backend.serviceName.

Il campo backend.serviceName in un MultiClusterIngress fa riferimento a un MultiClusterService nell'API fleet anziché a un servizio in un cluster Kubernetes. Ciò significa che qualsiasi impostazione di Ingress, come la terminazione TLS, può essere configurata nello stesso modo.

Convalida di uno stato di deployment riuscito

Il deployment di un bilanciatore del caricoGoogle Cloud potrebbe richiedere diversi minuti per i nuovi bilanciatori del carico. L'aggiornamento dei bilanciatori del carico esistenti viene completato più rapidamente perché non è necessario eseguire il deployment di nuove risorse. La risorsa MultiClusterIngress descrive le risorse Compute Engine sottostanti che sono state create per conto di MultiClusterIngress.

  1. Verifica che il deployment sia andato a buon fine:

    kubectl describe mci whereami-ingress -n whereami

    L'output è simile al seguente:

    Name:         whereami-ingress
Namespace:    whereami
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"networking.gke.io/v1","kind":"MultiClusterIngress","metadata":{"annotations":{},"name":"whereami-ingress","namespace":"whe...
API Version:  networking.gke.io/v1
Kind:         MultiClusterIngress
Metadata:
  Creation Timestamp:  2020-04-10T23:35:10Z
  Finalizers:
    mci.finalizer.networking.gke.io
  Generation:        2
  Resource Version:  26458887
  Self Link:         /apis/networking.gke.io/v1/namespaces/whereami/multiclusteringresses/whereami-ingress
  UID:               62bec0a4-8a08-4cd8-86b2-d60bc2bda63d
Spec:
  Template:
    Spec:
      Backend:
        Service Name:  whereami-mcs
        Service Port:  8080
Status:
  Cloud Resources:
    Backend Services:
      mci-8se3df-8080-whereami-whereami-mcs
    Firewalls:
      mci-8se3df-default-l7
    Forwarding Rules:
      mci-8se3df-fw-whereami-whereami-ingress
    Health Checks:
      mci-8se3df-8080-whereami-whereami-mcs
    Network Endpoint Groups:
      zones/europe-west1-b/networkEndpointGroups/k8s1-e4adffe6-whereami-mci-whereami-mcs-svc-lgq966x5m-808-88670678
      zones/us-central1-b/networkEndpointGroups/k8s1-a6b112b6-whereami-mci-whereami-mcs-svc-lgq966x5m-808-609ab6c6
    Target Proxies:
      mci-8se3df-whereami-whereami-ingress
    URL Map:  mci-8se3df-whereami-whereami-ingress
  VIP:        34.98.102.37
Events:
  Type    Reason  Age                    From                              Message
  ----    ------  ----                   ----                              -------
  Normal  ADD     3m35s                  multi-cluster-ingress-controller  whereami/whereami-ingress
  Normal  UPDATE  3m10s (x2 over 3m34s)  multi-cluster-ingress-controller  whereami/whereami-ingress

    Esistono diversi campi che indicano lo stato di questo dispiegamento di Ingress:

    • Events è il primo posto da controllare. Se si è verificato un errore, verrà elencato qui.

    • Cloud Resourceelenca le risorse Compute Engine come regole di forwarding, servizi di backend e regole firewall create dal controller Ingress multi-cluster. Se non sono presenti nell'elenco, significa che non sono ancora stati creati. Puoi ispezionare le singole risorse Compute Engine con la console o il comando gcloud per ottenere lo stato.

    • VIP elenca un indirizzo IP quando ne è stato allocato uno. Tieni presente che il bilanciamento del carico potrebbe non essere ancora in grado di elaborare il traffico anche se il VIP esiste. Se non vedi un VIP dopo un paio di minuti o se il bilanciatore del carico non invia una risposta 200 entro 10 minuti, consulta la sezione Risoluzione dei problemi e operazioni.

    Se gli eventi di output sono Normal, è probabile che il deployment di MultiClusterIngress sia riuscito, ma l'unico modo per determinare che il percorso di traffico completo sia funzionante è testarlo.

  2. Verifica che l'applicazione venga pubblicata sul VIP con l'endpoint /ping:

    curl INGRESS_VIP/ping

    Sostituisci INGRESS_VIP con l'indirizzo IP virtuale (VIP).

    L'output è simile al seguente:

    {
"cluster_name": "gke-us",
"host_header": "34.120.175.141",
"pod_name": "whereami-deployment-954cbf78-mtlpf",
"pod_name_emoji": "😎",
"project_id": "my-project",
"timestamp": "2021-11-29T17:01:59",
"zone": "us-central1-b"
}

    L'output deve indicare la regione e il backend dell'applicazione.

  3. Puoi anche andare all'URL http://INGRESS_VIP nel browser per visualizzare una versione grafica dell'applicazione che mostra la regione da cui viene pubblicata.

    Il cluster a cui viene inoltrato il traffico dipende dalla tua posizione. Il bilanciatore del carico Google Cloud è progettato per inoltrare il traffico client al backend disponibile più vicino con capacità.

Specifiche delle risorse

Specifiche di MultiClusterService

La definizione di MultiClusterService è composta da due parti:

  1. Una sezione template che definisce il servizio da creare nei cluster Kubernetes. Tieni presente che, sebbene la sezione template contenga i campi supportati in un servizio tipico, in un MultiClusterService sono supportati solo due campi: selector e ports. Gli altri campi vengono ignorati.

  2. Una sezione facoltativa clusters che definisce i cluster che ricevono il traffico e le proprietà di bilanciamento del carico per ciascun cluster. Se non viene specificata alcuna sezione clusters o se non sono elencati cluster, per impostazione predefinita vengono utilizzati tutti i cluster.

Il seguente manifest descrive un MultiClusterService standard:

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: NAME
  namespace: NAMESPACE
spec:
  template:
    spec:
      selector:
        app: POD_LABEL
      ports:
      - name: web
        protocol: TCP
        port: PORT
        targetPort: TARGET_PORT

Sostituisci quanto segue:

  • NAME: il nome del MultiClusterService. A questo nome fa riferimento il campo serviceName nelle risorse MultiClusterIngress.
  • NAMESPACE: lo spazio dei nomi Kubernetes in cui è dipiegato MultiClusterService. Deve trovarsi nello stesso spazio dei nomi di MultiClusterIngress e dei pod in tutti i cluster del parco risorse.
  • POD_LABEL: l'etichetta che determina quali pod vengono selezionati come backend per questo MultiClusterService in tutti i cluster del parco risorse.
  • PORT: deve corrispondere alla porta a cui fa riferimento il MultiClusterIngress che fa riferimento a questo MultiClusterService.
  • TARGET_PORT: la porta utilizzata per inviare traffico al pod dal GCLB. In ogni cluster viene creato un NEG con questa porta come porta di servizio.

Specifiche MultiClusterIngress

Il seguente mci.yaml descrive il frontend del bilanciatore del carico:

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: NAME
  namespace: NAMESPACE
spec:
  template:
    spec:
      backend:
       serviceName: DEFAULT_SERVICE
       servicePort: PORT
      rules:
        - host: HOST_HEADER
          http:
            paths:
            - path: PATH
              backend:
                serviceName: SERVICE
                servicePort: PORT

Sostituisci quanto segue:

  • NAME: il nome della risorsa MultiClusterIngress.
  • NAMESPACE: lo spazio dei nomi Kubernetes in cui è dipiegato MultiClusterIngress. Deve trovarsi nello stesso spazio dei nomi di MultiClusterService e dei pod in tutti i cluster nel parco risorse.
  • DEFAULT_SERVICE: funge da backend predefinito per tutto il traffico che non corrisponde a nessuna regola host o percorso. Si tratta di un campo obbligatorio e in MultiClusterIngress deve essere specificato un backend predefinito anche se sono configurate altre corrispondenze di host o percorso.
  • PORT: qualsiasi numero di porta valido. Deve corrispondere al campo port delle risorse MultiClusterService.
  • HOST_HEADER: trova una corrispondenza del traffico in base al campo dell'intestazione host HTTP. Il campo host è facoltativo.
  • PATH: associa il traffico in base al percorso dell'URL HTTP. Il campo path è facoltativo.
  • SERVICE: il nome di un MultiClusterService di cui è stato eseguito il deployment nello stesso Namespace e nello stesso cluster di configurazione di questo MultiClusterIngress.

Funzionalità di Ingress multi-cluster

Questa sezione mostra come configurare funzionalità aggiuntive di Ingress multi-cluster.

Selezione dei cluster

Per impostazione predefinita, i servizi derivati da Ingress multi-cluster vengono pianificati su ogni cluster membro. Tuttavia, ti consigliamo di applicare le regole di ingresso a cluster specifici. Ecco alcuni casi d'uso:

  • Applicazione di Ingress multi-cluster a tutti i cluster tranne al cluster di configurazione per l'isolamento del cluster di configurazione.
  • Esegui la migrazione dei carichi di lavoro tra i cluster in modalità blue-green.
  • Routing ai backend delle applicazioni esistenti solo in un sottoinsieme di cluster.
  • Utilizzo di un singolo VIP L7 per il routing di host o percorsi ai backend che si trovano su cluster diversi.

La selezione dei cluster ti consente di selezionare i cluster per regione o nome nell'oggetto MultiClusterService. Questo controlla i cluster a cui fa riferimento MultiClusterIngress e dove sono pianificati i servizi derivati. I cluster all'interno della stessa flotta e della stessa regione non devono avere lo stesso nome, in modo da poter fare riferimento ai cluster in modo univoco.

  1. Apri mcs.yaml

    apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: whereami-mcs
  namespace: whereami
spec:
  template:
    spec:
      selector:
        app: whereami
      ports:
      - name: web
        protocol: TCP
        port: 8080
        targetPort: 8080

    Questa specifica crea servizi derivati in tutti i cluster, il comportamento predefinito.

  2. Aggiungi le seguenti righe alla sezione dei cluster:

    apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: whereami-mcs
  namespace: whereami
spec:
  template:
    spec:
      selector:
        app: whereami
      ports:
      - name: web
        protocol: TCP
        port: 8080
        targetPort: 8080
  clusters:
  - link: "us-central1-b/gke-us"
  - link: "europe-west1-b/gke-eu"

    Questo esempio crea risorse di servizi derivati solo nei cluster gke-us e gke-eu. Devi selezionare i cluster a cui applicare in modo selettivo le regole di ingresso. Se la sezione "cluster" del MultiClusterService non è specificata o se non sono elencati cluster, viene interpretata come cluster predefiniti "tutti".

Supporto HTTPS

Il Secret Kubernetes supporta HTTPS. Prima di attivare il supporto HTTPS, devi creare un indirizzo IP statico. Questo IP statico consente a HTTP e HTTPS di condividere lo stesso indirizzo IP. Per ulteriori informazioni, consulta Creare un indirizzo IP statico.

Dopo aver creato un indirizzo IP statico, puoi creare un secret.

  1. Crea un secret:

    kubectl -n whereami create secret tls SECRET_NAME --key PATH_TO_KEYFILE --cert PATH_TO_CERTFILE

    Sostituisci quanto segue:

    • SECRET_NAME con il nome del tuo secret.
    • PATH_TO_KEYFILE con il percorso del file della chiave TLS.
    • PATH_TO_CERTFILE con il percorso del file del certificato TLS.

  2. Aggiorna il file mci.yaml con il nome del secret:

    apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: whereami-ingress
  namespace: whereami
  annotations:
    networking.gke.io/static-ip: STATIC_IP_ADDRESS
spec:
  template:
    spec:
      backend:
        serviceName: whereami-mcs
        servicePort: 8080
      tls:
      - secretName: SECRET_NAME

    Sostituisci SECRET_NAME con il nome del segreto. STATIC_IP_ADDRESS è l'indirizzo IP o l'URL completo dell'indirizzo che hai allocato nella sezione Creare un indirizzo IP statico.

  3. Riapplica la risorsa MultiClusterIngress:

    kubectl apply -f mci.yaml

    L'output è simile al seguente:

    multiclusteringress.networking.gke.io/whereami-ingress configured

Supporto di BackendConfig

La seguente risorsa CRD BackendConfig ti consente di personalizzare le impostazioni della risorsa Compute Engine BackendService:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: whereami-health-check-cfg
  namespace: whereami
spec:
  healthCheck:
    checkIntervalSec: [int]
    timeoutSec: [int]
    healthyThreshold: [int]
    unhealthyThreshold: [int]
    type: [HTTP | HTTPS | HTTP2 | TCP]
    port: [int]
    requestPath: [string]
  timeoutSec: [int]
  connectionDraining:
    drainingTimeoutSec: [int]
  sessionAffinity:
    affinityType: [CLIENT_IP | CLIENT_IP_PORT_PROTO | CLIENT_IP_PROTO | GENERATED_COOKIE | HEADER_FIELD | HTTP_COOKIE | NONE]
    affinityCookieTtlSec: [int]
  cdn:
    enabled: [bool]
    cachePolicy:
      includeHost: [bool]
      includeQueryString: [bool]
      includeProtocol: [bool]
      queryStringBlacklist: [string list]
      queryStringWhitelist: [string list]
  securityPolicy:
    name: ca-how-to-security-policy
  logging:
    enable: [bool]
    sampleRate: [float]
  iap:
    enabled: [bool]
    oauthclientCredentials:
      secretName: [string]

Per utilizzare BackendConfig, allegalo alla risorsa MultiClusterService utilizzando un'annotazione:

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: whereami-mcs
  namespace: whereami
  annotations:
    cloud.google.com/backend-config: '{"ports": {"8080":"whereami-health-check-cfg"}}'
spec:
 template:
   spec:
     selector:
       app: whereami
     ports:
     - name: web
       protocol: TCP
       port: 8080
       targetPort: 8080

Per ulteriori informazioni sulla semantica di BackendConfig, consulta Associare una porta di servizio a un BackendConfig.

Supporto gRPC

La configurazione delle applicazioni gRPC su Ingress multi-cluster richiede una configurazione molto specifica. Ecco alcuni suggerimenti per assicurarti che il bilanciatore del carico sia configurato correttamente:

  1. Assicurati che il traffico dal bilanciatore del carico all'applicazione sia HTTP/2. Utilizza i protocolli di applicazione per configurare questa opzione.
  2. Assicurati che l'applicazione sia configurata correttamente per SSL, poiché si tratta di un requisito di HTTP/2. Tieni presente che l'utilizzo di certificati autofirmati è accettabile.
  3. Devi disattivare mTLS nella tua applicazione perché non è supportato per i bilanciatori del carico esterni L7.

Ciclo di vita delle risorse

Modifiche alla configurazione

Le risorse MultiClusterIngress e MultiClusterService si comportano come oggetti Kubernetes standard, pertanto le modifiche agli oggetti vengono applicate in modo asincrono nel sistema. Eventuali modifiche che generano una configurazione non valida fanno sì che gli oggetti associatiGoogle Cloud rimangano invariati e generino un errore nello stream di eventi degli oggetti. Gli errori associati alla configurazione verranno segnalati come eventi.

Gestione delle risorse Kubernetes

L'eliminazione dell'oggetto Ingress comporta il teardown del bilanciatore del carico HTTP(S), pertanto il traffico non viene più inoltrato a nessun MultiClusterService definito.

L'eliminazione di MultiClusterService comporta la rimozione dei servizi derivati associati in ciascuno dei cluster.

Gestione dei cluster

L'insieme di cluster di destinazione del bilanciatore del carico può essere modificato aggiungendo o rimuovendo cluster dal parco risorse.

Ad esempio, per rimuovere il cluster gke-eu come backend per un ingress, esegui:

gcloud container fleet memberships unregister CLUSTER_NAME \
  --gke-uri=URI

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del tuo cluster.
  • URI: l'URI del cluster GKE.

Per aggiungere un cluster in Europa, esegui:

gcloud container fleet memberships register europe-cluster \
  --context=europe-cluster --enable-workload-identity

Per scoprire di più sulle opzioni di registrazione dei cluster, consulta Registrare un cluster GKE.

Tieni presente che la registrazione o la disattivazione di un cluster ne modifica lo stato come backend per tutti gli ingressi. Se annulli la registrazione del cluster gke-eu, questo viene rimosso come backend disponibile per tutti gli ingressi che crei. Il contrario è vero per la registrazione di un nuovo cluster.

Disabilitazione di Ingress multi-cluster

Prima di disattivare Ingress multi-cluster, devi assicurarti di eliminare prima le risorse MultiClusterIngress e MultiClusterService e verificare che vengano eliminate anche le risorse di rete associate.

Per disattivare Ingress multi-cluster, utilizza il seguente comando:

gcloud container fleet ingress disable

Se non elimini le risorse MultiClusterIngress e MultiClusterService prima di disattivare Ingress multi-cluster, potresti riscontrare un errore simile al seguente:

Feature has associated resources that should be cleaned up before deletion.

Se vuoi forzare la disattivazione di Ingress multi-cluster, utilizza il seguente comando:

gcloud container fleet ingress disable --force

Annotazioni

Le seguenti annotazioni sono supportate nelle risorse MultiClusterIngress e MultiClusterService.

Annotazioni MultiClusterIngress

Annotazione Descrizione
networking.gke.io/frontend-config Fa riferimento a una risorsa FrontendConfig nello stesso spazio dei nomi della risorsa MultiClusterIngress.
networking.gke.io/static-ip Si riferisce all'indirizzo IP letterale di un IP statico globale.
networking.gke.io/pre-shared-certs Si riferisce a una risorsa SSLCertificate globale.

Annotazioni MultiClusterService

Annotazione Descrizione
networking.gke.io/app-protocols Utilizza questa annotazione per impostare il protocollo per la comunicazione tra il bilanciatore del carico e l'applicazione. I protocolli possibili sono HTTP, HTTPS e HTTP/2. Consulta HTTPS tra il bilanciatore del carico e l'applicazione e HTTP/2 per il bilanciamento del carico con Ingress.
cloud.google.com/backend-config Utilizza questa annotazione per configurare il servizio di backend associato a una porta di servizio. Per ulteriori informazioni, consulta la sezione Configurazione di Ingress.

Criteri SSL e reindirizzamenti HTTPS

Puoi utilizzare la risorsa FrontendConfig per configurare i criteri SSL e i reindirizzamenti HTTPS. I criteri SSL ti consentono di specificare quali suite di crittografia e versioni TLS sono accettate dal bilanciatore del carico. I reindirizzamenti HTTPS ti consentono di obbligare il reindirizzamento da HTTP o dalla porta 80 a HTTPS o alla porta 443. I passaggi che seguono consentono di configurare insieme un criterio SSL e un reindirizzamento HTTPS. Tieni presente che possono anche essere configurati in modo indipendente.

  1. Crea un criterio SSL che rifiuti le richieste che utilizzano una versione precedente a TLS 1.2.

    gcloud compute ssl-policies create tls-12-policy \
 --profile MODERN \
 --min-tls-version 1.2 \
 --project=PROJECT_ID

    Sostituisci PROJECT_ID con l'ID progetto in cui sono in esecuzione i tuoi cluster GKE.

  2. Visualizza il criterio per assicurarti che sia stato creato.

    gcloud compute ssl-policies list --project=PROJECT_ID

    L'output è simile al seguente:

    NAME           PROFILE  MIN_TLS_VERSION
tls-12-policy  MODERN   TLS_1_2

  3. Crea un certificato per foo.example.com come nell'esempio. Una volta ottenuti key.pem e cert.pem, archivia queste credenziali come un segreto a cui farà riferimento la risorsa MultiClusterIngress.

    kubectl -n whereami create secret tls SECRET_NAME --key key.pem --cert cert.pem

  4. Salva la seguente risorsa FrontendConfig come frontendconfig.yaml. Per ulteriori informazioni sui campi supportati in un FrontendConfig, consulta Configurare le risorse FrontendConfig.

    apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: frontend-redirect-tls-policy
  namespace: whereami
spec:
  sslPolicy: tls-12-policy
  redirectToHttps:
    enabled: true

    Questo FrontendConfig attiverà i reindirizzamenti HTTPS e un criterio SSL che applica una versione TLS minima di 1.2.

  5. Esegui il deployment di frontendconfig.yaml nel cluster di configurazione.

    kubectl apply -f frontendconfig.yaml --context MCI_CONFIG_CLUSTER

    Sostituisci MCI_CONFIG_CLUSTER con il nome del cluster di configurazione.

  6. Salva il seguente MultiClusterIngress come mci-frontendconfig.yaml.

    apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: foo-ingress
  namespace: whereami
  annotations:
    networking.gke.io/frontend-config: frontend-redirect-tls-policy
    networking.gke.io/static-ip: STATIC_IP_ADDRESS
spec:
  template:
    spec:
      backend:
        serviceName: default-backend
        servicePort: 8080
      rules:
      - host: foo.example.com
        http:
          paths:
            - backend:
                serviceName: whereami-mcs
                servicePort: 8080
      tls:
      - secretName: SECRET_NAME
    • Sostituisci STATIC_IP_ADDRESS con un indirizzo IP globale statico di cui hai già eseguito il provisioning.
    • Sostituisci SECRET_NAME con il secret in cui è archiviato il certificato foo.example.com.

    Esistono due requisiti per l'attivazione dei reindirizzamenti HTTPS:

    • TLS deve essere abilitato tramite il campo spec.tls o tramite l'annotazione del certificato pre-condiviso networking.gke.io/pre-shared-certs. MultiClusterIngress non verrà disegnato se i reindirizzamenti HTTPS sono abilitati, ma non lo è HTTPS.
    • Deve essere fatto riferimento a un indirizzo IP statico tramite l'annotazione networking.gke.io/static-ip. Gli IP statici sono obbligatori per attivare HTTPS su un MultiClusterIngress.

  7. Esegui il deployment di MultiClusterIngress nel cluster di configurazione.

    kubectl apply -f mci-frontendconfig.yaml --context MCI_CONFIG_CLUSTER

  8. Attendi un paio di minuti e controlla foo-ingress.

    kubectl describe mci foo-ingress --context MCI_CONFIG_CLUSTER

    Un output corretto è simile al seguente:

    • Lo stato Cloud Resources viene compilato con i nomi delle risorse
    • Il campo VIP viene compilato con l'indirizzo IP del bilanciatore del carico
    Name:         foobar-ingress
Namespace:    whereami

...

Status:
  Cloud Resources:
    Backend Services:
      mci-otn9zt-8080-whereami-bar
      mci-otn9zt-8080-whereami-default-backend
      mci-otn9zt-8080-whereami-foo
    Firewalls:
      mci-otn9zt-default-l7
    Forwarding Rules:
      mci-otn9zt-fw-whereami-foobar-ingress
      mci-otn9zt-fws-whereami-foobar-ingress
    Health Checks:
      mci-otn9zt-8080-whereami-bar
      mci-otn9zt-8080-whereami-default-backend
      mci-otn9zt-8080-whereami-foo
    Network Endpoint Groups:
      zones/europe-west1-b/networkEndpointGroups/k8s1-1869d397-multi-cluste-mci-default-backend-svc--80-9e362e3d
      zones/europe-west1-b/networkEndpointGroups/k8s1-1869d397-multi-cluster--mci-bar-svc-067a3lzs8-808-89846515
      zones/europe-west1-b/networkEndpointGroups/k8s1-1869d397-multi-cluster--mci-foo-svc-820zw3izx-808-8bbcb1de
      zones/us-central1-b/networkEndpointGroups/k8s1-a63e24a6-multi-cluste-mci-default-backend-svc--80-a528cc75
      zones/us-central1-b/networkEndpointGroups/k8s1-a63e24a6-multi-cluster--mci-bar-svc-067a3lzs8-808-36281739
      zones/us-central1-b/networkEndpointGroups/k8s1-a63e24a6-multi-cluster--mci-foo-svc-820zw3izx-808-ac733579
    Target Proxies:
      mci-otn9zt-whereami-foobar-ingress
      mci-otn9zt-whereami-foobar-ingress
    URL Map:  mci-otn9zt-rm-whereami-foobar-ingress
  VIP:        34.149.29.76
Events:
  Type     Reason  Age                From                              Message
  ----     ------  ----               ----                              -------
  Normal   UPDATE  38m (x5 over 62m)  multi-cluster-ingress-controller  whereami/foobar-ingress

  9. Verifica che i reindirizzamenti HTTPS funzionino correttamente inviando una richiesta HTTP tramite curl.

    curl VIP

    Sostituisci VIP con l'indirizzo IP di MultiClusterIngress.

    L'output dovrebbe indicare che la richiesta è stata reindirizzata alla porta HTTPS, il che indica che i reindirizzamenti funzionano correttamente.

  10. Verifica che il criterio TLS funzioni correttamente inviando una richiesta HTTPS utilizzando la versione TLS 1.1. Poiché il DNS non è configurato per questo dominio, utilizza l'opzione --resolve per indicare a curl di risolvere direttamente l'indirizzo IP.

    curl https://foo.example.com --resolve foo.example.com:443:VIP --cacert CERT_FILE -v

    Questo passaggio richiede il file PEM del certificato utilizzato per proteggere MultiClusterIngress. Un output corretto sarà simile al seguente:

    ...
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
*  subject: O=example; CN=foo.example.com
*  start date: Sep  1 10:32:03 2021 GMT
*  expire date: Aug 27 10:32:03 2022 GMT
*  common name: foo.example.com (matched)
*  issuer: O=example; CN=foo.example.com
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fa10f00e400)
> GET / HTTP/2
> Host: foo.example.com
> User-Agent: curl/7.64.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
< content-type: application/json
< content-length: 308
< access-control-allow-origin: *
< server: Werkzeug/1.0.1 Python/3.8.6
< date: Wed, 01 Sep 2021 11:39:06 GMT
< via: 1.1 google
< alt-svc: clear
<
{"cluster_name":"gke-us","host_header":"foo.example.com","metadata":"foo","node_name":"gke-gke-us-default-pool-22cb07b1-r5r0.c.mark-church-project.internal","pod_name":"foo-75ccd9c96d-dkg8t","pod_name_emoji":"👞","project_id":"mark-church-project","timestamp":"2021-09-01T11:39:06","zone":"us-central1-b"}
* Connection #0 to host foo.example.com left intact
* Closing connection 0

    Il codice di risposta è 200 e viene utilizzato TLSv1.2, il che indica che tutto funziona correttamente.

    Successivamente, puoi verificare che la policy SSL imponga la versione TLS corretta tentando di connetterti con TLS 1.1. Affinché questo passaggio funzioni, il criterio SSL deve essere configurato per una versione minima di 1.2.

  11. Invia la stessa richiesta del passaggio precedente, ma applica una versione TLS 1.1.

    curl https://foo.example.com --resolve foo.example.com:443:VIP -v \
  --cacert CERT_FILE \
  --tls-max 1.1

    Un output corretto sarà simile al seguente:

    * Added foo.example.com:443:34.149.29.76 to DNS cache
* Hostname foo.example.com was found in DNS cache
*   Trying 34.149.29.76...
* TCP_NODELAY set
* Connected to foo.example.com (34.149.29.76) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: cert.pem
  CApath: none
* TLSv1.1 (OUT), TLS handshake, Client hello (1):
* TLSv1.1 (IN), TLS alert, protocol version (582):
* error:1400442E:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert protocol version
* Closing connection 0
curl: (35) error:1400442E:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert protocol version

    Il mancato completamento dell'handshake TLS indica che il criterio SSL ha bloccato correttamente TLS 1.1.

Creazione di un IP statico

  1. Alloca un IP statico:

    gcloud compute addresses create ADDRESS_NAME --global

    Sostituisci ADDRESS_NAME con il nome dell'IP statico da allocare.

    L'output contiene l'URL completo dell'indirizzo che hai creato, simile al seguente:

    Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/addresses/ADDRESS_NAME].

  2. Visualizza l'indirizzo IP appena creato:

    gcloud compute addresses list

    L'output è simile al seguente:

    NAME          ADDRESS/RANGE  TYPE      STATUS
ADDRESS_NAME  STATIC_IP_ADDRESS  EXTERNAL  RESERVED

    Questo output include:

    • Il valore ADDRESS_NAME che hai definito.
    • STATIC_IP_ADDRESS allocati.

  3. Aggiorna il file mci.yaml con l'IP statico:

    apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: whereami-ingress
  namespace: whereami
  annotations:
    networking.gke.io/static-ip: STATIC_IP_ADDRESS
spec:
  template:
    spec:
      backend:
        serviceName: whereami-mcs
        servicePort: 8080

    Sostituisci STATIC_IP_ADDRESS con:

    • L'indirizzo IP assegnato, simile a: 34.102.201.47
    • L'URL completo dell'indirizzo che hai creato, simile a: "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/addresses/ADDRESS_NAME"

    STATIC_IP_ADDRESS non è il nome della risorsa (ADDRESS_NAME).

  4. Riapplica la risorsa MultiClusterIngress:

    kubectl apply -f mci.yaml

    L'output è simile al seguente:

    multiclusteringress.networking.gke.io/whereami-ingress configured

  5. Segui i passaggi descritti in Convalidare lo stato di un deployment riuscito per verificare che il deployment venga eseguito su STATIC_IP_ADDRESS.

Certificati precondivisi

I certificati precompartiti sono certificati caricati su Google Cloud che possono essere utilizzati dal bilanciatore del carico per la terminazione TLS anziché i certificati archiviati in Kubernetes Secrets. Questi certificati vengono caricati out of band da GKE in Google Cloud e a cui viene fatto riferimento da una risorsa MultiClusterIngress. Sono supportati anche più certificati, tramite certificati precompartiti o secret di Kubernetes.

L'utilizzo dei certificati in Ingress multi-cluster richiede l'annotazione networking.gke.io/pre-shared-certs e i nomi dei certificati. Quando vengono specificati più certificati per un determinato MultiClusterIngress, un ordine predeterminato regola il certificato da presentare al client.

Per elencare i certificati SSL disponibili, esegui:

gcloud compute ssl-certificates list

L'esempio seguente descrive il traffico client verso uno degli host specificati che corrisponde al nome comune dei certificati precompartiti, in modo che venga presentato il rispettivo certificato corrispondente al nome di dominio.

kind: MultiClusterIngress
metadata:
  name: shopping-service
  namespace: whereami
  annotations:
    networking.gke.io/pre-shared-certs: "domain1-cert, domain2-cert"
spec:
  template:
    spec:
      rules:
      - host: my-domain1.gcp.com
        http:
          paths:
          - backend:
              serviceName: domain1-svc
              servicePort: 443
      - host: my-domain2.gcp.com
        http:
          paths:
          - backend:
              serviceName: domain2-svc
              servicePort: 443

Certificati gestiti da Google

I certificati gestiti da Google sono supportati nelle risorse MultiClusterIngress tramite l'annotazione networking.gke.io/pre-shared-certs. Ingress multi-cluster supporta l'attacco di certificati gestiti da Google a una risorsa MultiClusterIngress. Tuttavia, a differenza di Ingress a cluster singolo, la generazione dichiarativa di una risorsa ManagedCertificate Kubernetes non è supportata nelle risorse MultiClusterIngress. La creazione originale del certificato gestito da Google deve essere eseguita direttamente tramite l'API compute ssl-certificates create prima di poterlo collegare a un MultiClusterIngress. Per farlo, segui questi passaggi:

  1. Crea un certificato gestito da Google come descritto nel passaggio 1. Non andare al passaggio 2 perché Ingress multi-cluster allegherà questo certificato per te.

    gcloud compute ssl-certificates create my-google-managed-cert \
    --domains=my-domain.gcp.com \
    --global

  2. Fai riferimento al nome del certificato in MultiClusterIngress utilizzando l'annotazione networking.gke.io/pre-shared-certs.

    kind: MultiClusterIngress
metadata:
name: shopping-service
namespace: whereami
annotations:
  networking.gke.io/pre-shared-certs: "my-google-managed-cert"
spec:
template:
  spec:
    rules:
    - host: my-domain.gcp.com
      http:
        paths:
        - backend:
            serviceName: my-domain-svc
            servicePort: 8080

Il manifest precedente associa il certificato a MultiClusterIngress in modo che possa terminare il traffico per i cluster GKE di backend. Google Cloud rinnoverà automaticamente il tuo certificato prima della scadenza. I rinnovi avvengono in modo trasparente e non richiedono aggiornamenti a Ingress multi-cluster.

Protocolli di applicazione

La connessione dal proxy del bilanciatore del carico all'applicazione utilizza HTTP per impostazione predefinita. Utilizzando l'annotazione networking.gke.io/app-protocols, puoi configurare il bilanciatore del carico in modo che utilizzi HTTPS o HTTP/2 quando inoltra le richieste alla tua applicazione. Nel campo annotation dell'esempio seguente, http2 si riferisce al nome della porta MultiClusterService e HTTP2 al protocollo utilizzato dal bilanciatore del carico.

kind: MultiClusterService
metadata:
  name: shopping-service
  namespace: whereami
  annotations:
    networking.gke.io/app-protocols: '{"http2":"HTTP2"}'
spec:
  template:
    spec:
      ports:
      - port: 443
        name: http2

BackendConfig

Consulta la sezione sopra su come configurare l'annotazione.

Passaggi successivi