Deployment di Ingress in diversi cluster

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

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

Tutorial sul deployment

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

Questa pagina si basa sul lavoro svolto in Configurare una risorsa Ingress multi-cluster, in cui hai creato e registrato due cluster. Conferma di avere due cluster registrati a 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 risorse hanno la proprietà spazio dei nomi uguale, ti consigliamo di coordinare la creazione e la gestione dello spazio dei nomi nei 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 il più granulari necessari, purché uno spazio dei nomi ns1 in un cluster abbia lo stesso significato e lo stesso 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
    

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.2.9
            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 il deployment dell'app whereami sia stato eseguito 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 viene eseguito il deployment dell'applicazione in gke-us e gke-eu, eseguirai il deployment di un bilanciatore del carico eseguendo il deployment delle 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 che corrisponde all'app whereami:

    kubectl apply -f mcs.yaml
    
  3. Verifica che il deployment della risorsa whereami-mcs sia stato eseguito 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. Come puoi vedere, esiste 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
    

Un servizio headless simile esisterà anche in gke-eu. Questi servizi locali vengono utilizzati per selezionare in modo dinamico gli endpoint dei pod per programmare il bilanciatore del carico Ingress globale con i backend.

Ingress multicluster

  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 indirizza tutto il traffico al MultiClusterService con nome 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 Kubernetes Ingress. Anche la semantica della risorsa Ingress è la stessa, ad eccezione del campo backend.serviceName.

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

Convalida dello stato di deployment riuscito

Il deployment del bilanciatore del carico Google 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 nel dettaglio le risorse Compute Engine sottostanti create per conto di MultiClusterIngress.

  1. Verifica che il deployment sia riuscito:

    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 deployment Ingress:

    • Events è il primo posto in cui guardare. Se si è verificato un errore, verrà elencato qui.

    • Cloud Resourceelenca le risorse Compute Engine, ad esempio 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 controllare le singole risorse di Compute Engine con la console o il comando gcloud per verificarne lo stato.

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

    Se gli eventi di output sono Normal, è probabile che il deployment MultiClusterIngress abbia esito positivo, ma l'unico modo per determinare che il percorso del traffico completo sia funzionale è testarlo.

  2. Verifica che l'applicazione utilizzi il 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 dovrebbe 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 l'area geografica da cui viene utilizzato.

    Il cluster a cui viene inoltrato il traffico dipende dalla località. GCLB è progettato per inoltrare il traffico client al backend più vicino disponibile con capacità.

Specifiche della risorsa

Specifica MultiClusterService

La definizione di MultiClusterService è costituita da due parti:

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

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

Il file manifest seguente descrive uno standard MultiClusterService:

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 di MultiClusterService. Questo nome fa riferimento al campo serviceName nelle risorse MultiClusterIngress.
  • NAMESPACE: lo spazio dei nomi Kubernetes in cui viene eseguito il deployment di MultiClusterService. Deve corrispondere allo stesso spazio dei nomi di MultiClusterIngress e dei pod in tutti i cluster nel parco risorse.
  • POD_LABEL: l'etichetta che determina quali pod vengono selezionati come backend per questa MultiClusterService in tutti i cluster del parco risorse.
  • PORT: deve corrispondere alla porta indicata da MultiClusterIngress che fa riferimento a questo MultiClusterService.
  • TARGET_PORT: la porta utilizzata per inviare traffico al pod da GCLB. In ogni cluster viene creato un NEG con questa porta come porta di pubblicazione.

Specifica 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 viene eseguito il deployment di MultiClusterIngress. Deve trovarsi nello stesso spazio dei nomi di MultiClusterService e dei pod in tutti i cluster del parco risorse.
  • DEFAULT_SERVICE: agisce come backend predefinito per tutto il traffico che non corrisponde ad alcuna regola dell'host o del percorso. Questo è un campo obbligatorio e devi specificare un backend predefinito in MultiClusterIngress anche se hai configurato altre corrispondenze host o percorso.
  • PORT: qualsiasi numero di porta valido. Deve corrispondere al campo port delle risorse MultiClusterService.
  • HOST_HEADER: corrisponde al traffico in base al campo di intestazione dell'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 viene eseguito il deployment nello stesso spazio dei nomi e nel cluster di configurazione di questo MultiClusterIngress.

Funzionalità Ingress multi-cluster

Questa sezione mostra come configurare funzionalità aggiuntive di Ingress per più cluster.

Selezione del cluster

Per impostazione predefinita, i servizi derivati da Ingress multi-cluster vengono pianificati su ogni cluster membro. Tuttavia, potresti voler applicare regole in entrata a cluster specifici. Alcuni casi d'uso includono:

  • Applicazione di Ingress multi-cluster a tutti i cluster tranne al cluster di configurazione per l'isolamento del cluster.
  • Migrazione dei carichi di lavoro tra cluster in modo blu/verde.
  • Routing ai backend delle applicazioni esistenti solo in un sottoinsieme dei cluster.
  • Utilizzo di un unico VIP L7 per il routing host/percorso a backend che risiedono su diversi cluster.

La selezione dei cluster ti consente di selezionare i cluster per regione/nome nell'oggetto MultiClusterService. In questo modo puoi controllare i cluster a cui punta MultiClusterIngress e la pianificazione dei servizi derivati. I cluster all'interno dello stesso parco risorse 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 attualmente crea servizi derivati in tutti i cluster, il comportamento predefinito.

  2. Aggiungi le seguenti righe nella 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 del servizio derivato solo nei cluster gke-us e gke-eu. Devi selezionare i cluster per applicare le regole in entrata in modo selettivo. Se la sezione "cluster" di MultiClusterService non è specificata o se non sono elencati cluster, viene interpretata come "tutti" i cluster predefiniti.

Supporto HTTPS

Il secret di 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 scoprire di più, consulta l'articolo Creazione di un 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 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 tuo secret. STATIC_IP_ADDRESS è l'indirizzo IP o l'URL completo dell'indirizzo che hai assegnato nella sezione Creazione di un IP statico.

  3. Esegui nuovamente il deployment della risorsa MultiClusterIngress:

    kubectl apply -f mci.yaml
    

    L'output è simile al seguente:

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

Supporto BackendConfig

Il CRD di BackendConfig consente di personalizzare le impostazioni nella risorsa BackendService di Compute Engine. Le specifiche supportate sono riportate di seguito:

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, collegalo alla tua 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 BackendConfig, consulta l'articolo Associare una porta di servizio a una 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 alla tua applicazione sia HTTP/2. Utilizza protocolli dell'applicazione per configurare questa opzione.
  2. Assicurati che la tua applicazione sia configurata correttamente per SSL poiché si tratta di un requisito di HTTP/2. Tieni presente che è accettabile utilizzare i certificati autofirmati.
  3. Devi disattivare mTLS nella tua applicazione perché mTLS 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, quindi le modifiche agli oggetti vengono applicate in modo asincrono nel sistema. Qualsiasi modifica che provochi una configurazione non valida mantiene invariati gli oggetti Google Cloud associati e genera un errore nel flusso di eventi dell'oggetto. Gli errori associati alla configurazione verranno segnalati come eventi.

Gestione delle risorse Kubernetes

L'eliminazione dell'oggetto Ingress scompone il bilanciatore del carico HTTP(S) in modo che il traffico non venga più inoltrato a MultiClusterService definiti.

L'eliminazione di MultiClusterService rimuove i servizi derivati associati in ciascuno dei cluster.

Gestione dei cluster

L'insieme di cluster scelti come target dal 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 traffico in entrata, 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 saperne di più sulle opzioni di registrazione dei cluster, vedi Registrare un cluster GKE.

Tieni presente che la registrazione o l'annullamento della registrazione di un cluster ne modifica lo stato come backend per tutte le Ingress. Nel caso precedente, l'annullamento della registrazione del cluster gke-eu ne comporta la rimozione come backend disponibile per tutte le risorse Ingress create. Il contrario è vero per la registrazione di un nuovo cluster.

Disabilitazione dell'Ingress multi-cluster

Prima di disabilitare la funzionalità Ingress in cluster multipli, devi assicurarti di eliminare le risorse MultiClusterIngress e MultiClusterService e verificare che le risorse di networking associate siano eliminate.

Quindi, per disabilitare Ingress multi-cluster, utilizza il seguente comando:

gcloud container fleet ingress disable

Se non elimini le risorse MultiClusterIngress e MultiClusterService prima di disabilitare il 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 disabilitazione del Ingress multi-cluster, utilizza il seguente comando:

gcloud container fleet ingress disable --force

Annotazioni

Le seguenti annotazioni sono supportate sulle 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 Fa riferimento 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 la tua 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 un servicePort. Per maggiori informazioni, consulta la pagina Funzionalità in entrata.

Criteri SSL e reindirizzamenti HTTPS

Puoi utilizzare la risorsa FrontendConfig per configurare i criteri SSL e i reindirizzamenti HTTPS. I criteri SSL consentono di specificare le suite di crittografia e le versioni TLS accettate dal bilanciatore del carico. I reindirizzamenti HTTPS consentono di forzare l'applicazione del reindirizzamento da HTTP/porta 80 a HTTPS/porta 443. I passaggi seguenti consentono di configurare contemporaneamente un criterio SSL e un reindirizzamento HTTPS. Tieni presente che possono essere configurati anche in modo indipendente.

  1. Crea un criterio SSL che rifiuti le richieste utilizzando 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 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 in questo esempio. Quando disponi di key.pem e cert.pem, archivia queste credenziali come secret a cui verrà fatto riferimento nella 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 all'interno di FrontendConfig, consulta Configurazione delle 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
    

    Questa frontend abilita i reindirizzamenti HTTPS e un criterio SSL che applica una versione TLS minima di 1.2.

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

    kubectl apply -f frontendconfig.yaml --context MCI_CONFIG_CLUSTER
    

    Sostituisci MCI_CONFIG_CLUSTER con il nome del tuo 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 precondivisa networking.gke.io/pre-shared-certs. Il protocollo MultiClusterIngress non viene eseguito se i reindirizzamenti HTTPS sono abilitati, ma non HTTPS.
    • È necessario fare riferimento a un IP statico tramite l'annotazione networking.gke.io/static-ip. Gli IP statici sono obbligatori per l'abilitazione di HTTPS su un MultiClusterIngress.
  7. Eseguire il deployment di MultiClusterIngress nel cluster di configurazione.

    kubectl apply -f mci-frontendconfig.yaml --context MCI_CONFIG_CLUSTER
    
  8. Attendi un minuto o due e ispeziona foo-ingress.

    kubectl describe mci foo-ingress --context MCI_CONFIG_CLUSTER
    

    Un output di operazione riuscita è simile al seguente:

    • Lo stato Cloud Resources è 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 MultiClusterIngress.

    L'output dovrebbe mostrare 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 TLS versione 1.1. Poiché il DNS non è configurato per questo dominio, utilizza l'opzione --resolve per comunicare 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 MultiMultiIngress. Un risultato riuscito 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, che indica che tutto funziona correttamente.

    In seguito, potrai verificare che il criterio SSL applichi la versione TLS corretta tentando di connettersi a TLS 1.1. Il criterio SSL deve essere configurato per una versione minima di 1.2 affinché questo passaggio funzioni.

  11. Invia la stessa richiesta indicata nel 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 risultato riuscito 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 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 ADDRESS_NAME che hai definito.
    • Gli STATIC_IP_ADDRESS assegnati.
  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 uno dei seguenti elementi:

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

    STATIC_IP_ADDRESS non è il nome della risorsa (ADDRESS_NAME).

  4. Esegui nuovamente il deployment della 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 uno stato di deployment riuscito per verificare che il deployment venga pubblicato su STATIC_IP_ADDRESS.

Certificati precondivisi

I certificati precondivisi sono certificati caricati in Google Cloud che possono essere utilizzati dal bilanciatore del carico per la terminazione TLS anziché dai certificati archiviati in Kubernetes Secret. Questi certificati vengono caricati dalla banda da GKE a Google Cloud e fanno riferimento a una risorsa MultiClusterIngress. Sono supportati anche più certificati, tramite certificati precondivisi o secret di Kubernetes.

Per utilizzare i certificati in Ingress multi-cluster sono necessari l'annotazione networking.gke.io/pre-shared-certs e i nomi dei certificati. Quando vengono specificati più certificati per un determinato elemento MultiClusterIngress, un ordine predeterminato stabilisce quale certificato deve essere presentato al client.

Puoi elencare i certificati SSL disponibili eseguendo:

gcloud compute ssl-certificates list

L'esempio seguente descrive il traffico client verso uno degli host specificati che corrisponde al nome comune dei certificati precondivisi in modo da presentare il rispettivo certificato che corrisponde 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 sulle risorse MultiClusterIngress tramite l'annotazione networking.gke.io/pre-shared-certs. Ingress in più cluster supporta il collegamento di certificati gestiti da Google a una risorsa MultiClusterIngress, tuttavia, a differenza di Ingress a cluster singolo, la generazione dichiarativa di una risorsa Kubernetes ManagedCertificate non è supportata su MultiClusterIngress risorse. La creazione originale del certificato gestito da Google deve essere eseguita direttamente tramite l'API compute ssl-certificates create prima di poter essere allegata a un MultiClusterIngress. A questo scopo, procedi nel seguente modo:

  1. Crea un certificato gestito da Google come passaggio 1 qui. Non andare al passaggio 2, perché Ingress multi-cluster allega questo certificato.

    gcloud compute ssl-certificates create my-google-managed-cert \
        --domains=my-domain.gcp.com \
        --global
    
  2. Fai riferimento al nome del certificato nel tuo 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 allega il certificato al tuo MultiClusterIngress in modo che possa terminare il traffico per i tuoi cluster GKE di backend. Google Cloud rinnoverà automaticamente il certificato prima della scadenza del certificato. I rinnovi avvengono in modo trasparente e non richiedono aggiornamenti a Ingress multi-cluster.

Protocolli dell'applicazione

La connessione dal proxy del bilanciatore del carico alla tua 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, mentre HTTP2 si riferisce 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

Per configurare l'annotazione, consulta la sezione sopra.

Passaggi successivi