Questa pagina mostra come eseguire il deployment di una risorsa Ingress che gestisce un'applicazione in più cluster GKE. Per scoprire di più su Ingress multi-cluster, consulta In entrata 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 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 del traffico in entrata multi-cluster, in cui hai creato e registrato due cluster. Conferma 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 dei nomi hanno la proprietà dell'identicità dello spazio dei nomi, ti consigliamo di coordinare la creazione e la gestione dello spazio dei nomi tra i cluster in modo che gli spazi dei nomi identici siano di proprietà e gestiti dallo stesso gruppo. Puoi creare spazi dei nomi per team, per ambiente, per applicazione o per componente dell'applicazione. Gli spazi dei nomi possono essere granulari come necessario, 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, creerai uno spazio dei nomi whereami
per ogni applicazione in ogni cluster.
Crea un file denominato
namespace.yaml
con i seguenti contenuti:apiVersion: v1 kind: Namespace metadata: name: whereami
Passa al contesto gke-us:
kubectl config use-context gke-us
Crea lo spazio dei nomi:
kubectl apply -f namespace.yaml
Passa al contesto gke-eu:
kubectl config use-context gke-eu
Crea lo spazio dei nomi:
kubectl apply -f namespace.yaml
L'output è simile al seguente:
namespace/whereami created
Deployment dell'app
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.20 ports: - containerPort: 8080
Passa al contesto gke-us:
kubectl config use-context gke-us
Esegui il deployment dell'app
whereami
:kubectl apply -f deploy.yaml
Passa al contesto gke-eu:
kubectl config use-context gke-eu
Esegui il deployment dell'app
whereami
:kubectl apply -f deploy.yaml
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 il deployment dell'applicazione è stato eseguito su 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. Questi sono gli 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.
Imposta il contesto sul cluster di configurazione.
kubectl config use-context gke-us
MultiClusterService
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
Esegui il deployment della risorsa
MultiClusterService
che corrisponde all'appwhereami
:kubectl apply -f mcs.yaml
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 conapp: whereami
. Puoi vedere che ne esiste una nel clustergke-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
Esisterà un servizio headless simile anche in gke-eu
. Questi servizi locali vengono utilizzati per selezionare dinamicamente gli endpoint dei pod per programmare il bilanciatore del carico globale Ingress con i backend.
MultiClusterIngress
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 al
MultiClusterService
denominatowhereami-mcs
che esiste nello spazio dei nomiwhereami
.Esegui il deployment della risorsa
MultiClusterIngress
che fa riferimento awhereami-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 campobackend.serviceName
.
Il campo backend.serviceName
in un MultiClusterIngress
fa riferimento a 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 allo stesso modo.
Convalida di uno 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 in dettaglio le risorse Compute Engine sottostanti che sono state create per conto di MultiClusterIngress
.
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 in entrata:
Events
è il primo posto da cercare. Se si è verificato un errore, verrà elencato qui.Cloud Resource
elenca le risorse di Compute Engine, come regole di forwarding, servizi di backend e regole firewall create dal controller Ingress multi-cluster. Se non sono presenti, significa che non sono stati ancora creati. Puoi esaminare le singole risorse di Compute Engine con la console o il comandogcloud
per ottenerne lo stato.VIP
elenca un indirizzo IP quando ne è stato allocato uno. Tieni presente che il bilanciatore del carico potrebbe non 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 fornisce una risposta 200 entro 10 minuti, consulta Risoluzione dei problemi e operazioni.
Se gli eventi di output sono
Normal
, è probabile che il deployment diMultiClusterIngress
vada a buon fine, ma l'unico modo per determinare che l'intero percorso del traffico sia funzionante è testarlo.Verifica che l'applicazione venga gestita 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 dovrebbe indicare la regione e il backend dell'applicazione.
Puoi anche accedere all'URL
http://INGRESS_VIP
nel browser per vedere una versione grafica dell'applicazione che mostra la regione da cui viene pubblicata.Il cluster a cui viene inoltrato il traffico dipende dalla tua località. GCLB è progettato per inoltrare il traffico del client al backend più vicino disponibile con capacità.
Specifiche delle risorse
Specifica MultiClusterService
La definizione di MultiClusterService
è composta da due parti:
Una sezione
template
che definisce il servizio da creare nei cluster Kubernetes. Tieni presente che sebbene la sezionetemplate
contenga campi supportati in un servizio tipico, ci sono solo due campi supportati in unMultiClusterService
:selector
eports
. Gli altri campi vengono ignorati.Una sezione
clusters
facoltativa che definisce i cluster che ricevono traffico e le proprietà di bilanciamento del carico per ciascun cluster. Se non viene specificata alcuna sezioneclusters
o se non sono elencati cluster, per impostazione predefinita vengono utilizzati tutti i cluster.
Il seguente file manifest descrive un elemento 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 delMultiClusterService
. A questo nome fa riferimento il camposerviceName
nelle risorseMultiClusterIngress
.NAMESPACE
: lo spazio dei nomi Kubernetes in cui viene eseguito il deployment diMultiClusterService
. Deve corrispondere nello spazio dei nomi diMultiClusterIngress
e nei pod in tutti i cluster del parco risorse.POD_LABEL
: l'etichetta che determina quali pod vengono selezionati come backend per questoMultiClusterService
in tutti i cluster del parco risorse.PORT
: deve corrispondere alla porta indicata dalMultiClusterIngress
che fa riferimento a questoMultiClusterService
.TARGET_PORT
: la porta utilizzata per inviare il traffico al pod da GCLB. In ogni cluster viene creato un NEG con questa porta come porta di gestione.
Specifiche Ingress Multi-Cluster
Quanto segue 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 risorsaMultiClusterIngress
.NAMESPACE
: lo spazio dei nomi Kubernetes in cui viene eseguito il deployment diMultiClusterIngress
. Deve trovarsi nello stesso spazio dei nomi diMultiClusterService
e nei pod in tutti i cluster del parco risorse.DEFAULT_SERVICE
: funge da backend predefinito per tutto il traffico che non corrisponde a nessuna regola host o percorso. Questo è un campo obbligatorio e deve essere specificato un backend predefinito inMultiClusterIngress
anche se sono configurate altre corrispondenze di host o percorsi.PORT
: qualsiasi numero di porta valido. Deve corrispondere al campoport
delle risorseMultiClusterService
.HOST_HEADER
: corrisponde al traffico proveniente dal campo intestazione dell'host HTTP. Il campohost
è facoltativo.PATH
: associa il traffico in base al percorso dell'URL HTTP. Il campopath
è facoltativo.SERVICE
: il nome di un elementoMultiClusterService
di cui viene eseguito il deployment nello stesso spazio dei nomi e nello stesso cluster di configurazione diMultiClusterIngress
.
Funzionalità di Ingress multi-cluster
Questa sezione mostra come configurare funzionalità aggiuntive di Ingress multi-cluster.
Selezione del cluster
Per impostazione predefinita, i servizi derivati da Ingress multi-cluster sono pianificati su ogni cluster membro. Tuttavia, ti consigliamo di applicare regole in entrata a cluster specifici. Alcuni casi d'uso includono:
- Applicazione di Ingress multi-cluster a tutti i cluster, ad eccezione del cluster di configurazione per l'isolamento del cluster di configurazione.
- Migrazione dei carichi di lavoro tra cluster in modo blu/verde.
- Routing a backend di applicazioni che esistono solo in un sottoinsieme di cluster.
- Utilizzo di un singolo VIP L7 per il routing dell'host o del percorso a backend che risiedono su cluster diversi.
La selezione dei cluster consente di selezionarli per regione o nome nell'oggetto MultiClusterService
. Questa operazione controlla a quali cluster punta MultiClusterIngress
e dove sono pianificati i servizi derivati.
I cluster all'interno dello stesso parco risorse e della stessa regione non devono avere lo stesso nome, in modo che sia possibile fare riferimento ai cluster in modo univoco.
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.
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"
In questo esempio, vengono create risorse del servizio derivato solo nei cluster gke-us e gke-eu. Devi selezionare i cluster per applicare selettivamente le regole in entrata. Se la sezione "cluster" di
MultiClusterService
non è specificata o se non sono elencati cluster, viene interpretato 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 saperne di più, consulta Creazione di un IP statico.
Dopo aver creato un indirizzo IP statico, puoi creare un secret.
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.
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 allocato nella sezione Creazione di un IP statico.Esegui di nuovo il deployment della risorsa
MultiClusterIngress
:kubectl apply -f mci.yaml
L'output è simile al seguente:
multiclusteringress.networking.gke.io/whereami-ingress configured
Supporto di BackendConfig
Il seguente CRD BackendConfig consente di personalizzare le impostazioni della risorsa BackendService di Compute Engine:
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 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 saperne di più 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:
- Assicurati che il traffico dal bilanciatore del carico all'applicazione sia HTTP/2. Utilizza i protocolli applicativi per la configurazione.
- Assicurati che la tua applicazione sia configurata correttamente per SSL, poiché questo è un requisito di HTTP/2. Tieni presente che è accettabile l'utilizzo di certificati autofirmati.
- Devi disattivare mTLS nella tua applicazione poiché 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, pertanto le modifiche apportate agli oggetti vengono riflesse in modo asincrono nel sistema. Eventuali modifiche che generano una configurazione non valida fanno sì che gli oggetti Google Cloud associati rimangano invariati e generino 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 comporta l'eliminazione del bilanciatore del carico HTTP(S), in modo che il traffico non venga più inoltrato a un MultiClusterService
definito.
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, consulta Registrare un cluster GKE.
Tieni presente che la registrazione o l'annullamento della registrazione di un cluster ne modifica lo stato di backend per tutte le risorse Ingress. L'annullamento della registrazione del cluster gke-eu
lo rimuove come backend disponibile per tutte le risorse Ingress che crei. Il contrario è vero per la registrazione di un nuovo cluster.
Disabilitazione del traffico in entrata multi-cluster
Prima di disabilitare il Ingress multi-cluster, devi eliminare le risorse MultiClusterIngress
e MultiClusterService
e verificare che le risorse di networking associate siano state eliminate.
Quindi, per disabilitare il 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 disattivazione del traffico in 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 | Description |
---|---|
networking.gke.io/frontend-config | Fa riferimento a una risorsa FrontendConfig nello stesso spazio dei nomi della risorsa MultiClusterIngress. |
networking.gke.io/static-ip | Fa riferimento 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 | Description |
---|---|
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 le pagine 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 servicePort. Per maggiori informazioni, consulta la pagina relativa alla configurazione 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 ti consentono di applicare il reindirizzamento da HTTP o dalla porta 80 a HTTPS o dalla porta 443. I passaggi seguenti consentono di configurare insieme un criterio SSL e un reindirizzamento HTTPS. Tieni presente che possono anche essere configurati in modo indipendente.
Crea un criterio SSL che rifiuterà le richieste che utilizzano una versione precedente a TLS v1.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.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
Crea un certificato per
foo.example.com
come nell'esempio. Una volta ottenutikey.pem
ecert.pem
, archivia queste credenziali come Secret a cui la risorsa MultiClusterIngress fa riferimento.kubectl -n whereami create secret tls SECRET_NAME --key key.pem --cert cert.pem
Salva la seguente risorsa FrontendConfig come
frontendconfig.yaml
. Per saperne di più sui campi supportati in un 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
Questo FrontendConfig abiliterà i reindirizzamenti HTTPS e un criterio SSL che applica una versione TLS minima pari a 1.2.
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 tuo cluster di configurazione.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 certificatofoo.example.com
.
Sono due i requisiti per l'attivazione dei reindirizzamenti HTTPS:
- È necessario abilitare TLS tramite il campo
spec.tls
o tramite l'annotazione del certificato precondivisonetworking.gke.io/pre-shared-certs
. MultiClusterIngress non verrà eseguito se i reindirizzamenti HTTPS sono abilitati, ma HTTPS non lo è. - È necessario fare riferimento a un IP statico tramite l'annotazione
networking.gke.io/static-ip
. Gli IP statici sono obbligatori per l'attivazione di HTTPS su un MultiClusterIngress.
- Sostituisci
Esegui il deployment di MultiClusterIngress nel tuo cluster di configurazione.
kubectl apply -f mci-frontendconfig.yaml --context MCI_CONFIG_CLUSTER
Attendi un paio di minuti ed esamina
foo-ingress
.kubectl describe mci foo-ingress --context MCI_CONFIG_CLUSTER
Un output riuscito è 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
- Lo stato
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, che indica che i reindirizzamenti funzionano correttamente.
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 indicare acurl
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 il valore MultiClusterIngress. Un output 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, il che indica che tutto funziona correttamente.
Puoi quindi verificare che il criterio SSL applichi la versione TLS corretta provando a connetterti con TLS 1.1. Affinché questo passaggio funzioni, il criterio SSL deve essere configurato su una versione minima pari a 1.2.
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 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 correttamente.
Creazione di un IP statico
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].
Visualizza l'indirizzo IP che hai 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. STATIC_IP_ADDRESS
allocato.
- Il
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 allocato, simile a:
34.102.201.47
- L'URL completo dell'indirizzo che hai creato, simile a questo:
"https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/addresses/ADDRESS_NAME"
STATIC_IP_ADDRESS
non è il nome della risorsa (ADDRESS_NAME
).- L'indirizzo IP allocato, simile a:
Esegui di nuovo il deployment della risorsa
MultiClusterIngress
:kubectl apply -f mci.yaml
L'output è simile al seguente:
multiclusteringress.networking.gke.io/whereami-ingress configured
Segui i passaggi in Convalida dello stato di un deployment riuscito per verificare che il deployment venga pubblicato sul
STATIC_IP_ADDRESS
.
Certificati precondivise
I certificati precondivise sono certificati caricati in Google Cloud che possono essere utilizzati dal bilanciatore del carico per la terminazione TLS anziché quelli archiviati nei secret di Kubernetes. Questi certificati vengono caricati fuori 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.
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 prestabilito 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 corrispondente al nome comune dei certificati precondivise, in modo che venga visualizzato 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 multi-cluster supporta il collegamento di certificati gestiti da Google a una risorsa MultiClusterIngress
. Tuttavia, a differenza dell'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 effettuata direttamente tramite l'API compute ssl-certificates create
prima di poter essere collegato a un MultiClusterIngress
. Per farlo, segui questi passaggi:
Crea un certificato gestito da Google come descritto nel passaggio 1 qui. Non andare al passaggio 2, poiché Ingress multi-cluster collegherà questo certificato per te.
gcloud compute ssl-certificates create my-google-managed-cert \ --domains=my-domain.gcp.com \ --global
Fai riferimento al nome del certificato in
MultiClusterIngress
utilizzando l'annotazionenetworking.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 collega il certificato a MultiClusterIngress
in modo che possa terminare il traffico per i cluster GKE di backend.
Google Cloud rinnoverà automaticamente il certificato prima della sua scadenza. I rinnovi avvengono in modo trasparente e non richiedono aggiornamenti al traffico in Ingress multi-cluster.
Protocolli di 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
fa riferimento 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
Consulta la sezione sopra per informazioni su come configurare l'annotazione.
Passaggi successivi
- Leggi la panoramica della rete GKE.
- Scopri di più sulla configurazione del bilanciamento del carico HTTP con Ingress.
- Implementa Ingress multi-cluster con HTTPS end-to-end.