Configura un mesh multi-cloud o ibrido
Questa pagina spiega come configurare un mesh multi-cloud o ibrido per le seguenti piattaforme:
- Ibrido: GKE su Google Cloud e Google Distributed Cloud (anteprima)
- Ibrido: GKE su Google Cloud e Google Distributed Cloud (anteprima)
- Multi-cloud: GKE su Google Cloud e Amazon EKS (anteprima)
Seguendo queste istruzioni, configuri due cluster, ma puoi estendere questa procedura per incorporare un numero qualsiasi di cluster nella tua mesh.
Prerequisiti
- Tutti i cluster devono essere registrati nello stesso progetto host del parco risorse.
- Tutti i cluster GKE devono trovarsi una configurazione VPC condivisa sulla stessa rete.
- L'indirizzo del piano di controllo Kubernetes del cluster e l'indirizzo del gateway devono sia raggiungibile da ogni cluster nel mesh. Il progetto Google Cloud in cui La posizione dei cluster GKE deve essere consentita per la creazione tipi di bilanciamento del carico esterni. Ti consigliamo di utilizzare le reti autorizzate e le regole firewall VPC per limitare l'accesso.
- I cluster privati, inclusi i cluster privati GKE, non sono supportati. Se usi cluster on-premise, tra cui Google Distributed Cloud e Google Distributed Cloud, L'indirizzo del piano di controllo Kubernetes e quello del gateway devono essere raggiungibili dai pod nei cluster GKE. Ti consigliamo di utilizzare CloudVPN per connettere Subnet del cluster GKE con la rete del cluster on-premise.
- Se utilizzi la CA Istio, utilizza lo stesso certificato principale personalizzato per tutti i cluster.
Prima di iniziare
Questa guida presuppone che tu abbia installato Cloud Service Mesh utilizzando lo strumento asmcli
. Ti servono
asmcli
e il pacchetto di configurazione scaricato da asmcli
nella directory
specificato in --output_dir quando hai eseguito asmcli install
. Per maggiori informazioni
le informazioni, vedi
Installa strumenti dipendenti e convalida il cluster
a:
- Installare gli strumenti richiesti
- Scarica asmcli
- Concedi le autorizzazioni di amministratore del cluster
- Convalida il progetto e il cluster
Devi avere accesso ai file kubeconfig di tutti i cluster che stai configurando nel mesh. Per il cluster GKE, per creare un nuovo file kubeconfig per il cluster, puoi esportare l'ambiente KUBECONFIG
con il percorso completo del file come valore nel terminale e generare la voce kubeconfig.
Configurare variabili di ambiente e segnaposto
Quando installi il gateway est-ovest, sono necessarie le seguenti variabili di ambiente.
Crea variabili di ambiente per i nomi delle reti:
Per impostazione predefinita, i cluster GKE utilizzano il nome della rete del cluster:
export NETWORK_1="PROJECT_ID-CLUSTER_NETWORK" ``````
Altri cluster utilizzano
default
:export NETWORK_2="default" ``````
Se hai installato Cloud Service Mesh su altri cluster con valori diversi per --network_id
, devi passare gli stessi valori a NETWORK_2
.
Installa il gateway est-ovest
Installa un gateway in CLUSTER_1 (il tuo cluster GKE) che sia dedicata all'area east-west traffico a CLUSTER_2 (il tuo cluster multi-cloud o on-premise):
asm/istio/expansion/gen-eastwest-gateway.sh \ --network ${NETWORK_1} \ --revision asm-1187-26 | \ ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_1 install -y -f -
Tieni presente che questo gateway è pubblico su internet per impostazione predefinita. Produzione sistemi potrebbero richiedere ulteriori limitazioni di accesso, come e regole per prevenire gli attacchi esterni.
Installa un gateway in CLUSTER_2 dedicato al traffico est-ovest per CLUSTER_1.
asm/istio/expansion/gen-eastwest-gateway.sh \ --network ${NETWORK_2} \ --revision asm-1187-26 | \ ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 install -y -f -
Esporre i servizi
Poiché i cluster si trovano su reti separate, devi esporre tutti i servizi
(\*.local
) sul gateway est-ovest in entrambi i cluster. Mentre questo gateway è
su internet, i servizi sottostanti sono accessibili solo
un certificato mTLS attendibile e un ID carico di lavoro, proprio come se si trovassero sullo stesso indirizzo
in ogni rete.
Esponi i servizi tramite il gateway est-ovest per ogni cluster
kubectl --kubeconfig=PATH_TO_KUBECONFIG_1 apply -n istio-system -f \
asm/istio/expansion/expose-services.yaml
kubectl --kubeconfig=PATH_TO_KUBECONFIG_2 apply -n istio-system -f \
asm/istio/expansion/expose-services.yaml
Abilita rilevamento endpoint
Esegui il comando asmcli create-mesh
per abilitare il rilevamento degli endpoint. Questo
mostra solo due cluster, ma puoi eseguire il comando per abilitare
il rilevamento degli endpoint su cluster aggiuntivi, in base alle
Limite di servizio GKE Hub.
./asmcli create-mesh \
FLEET_PROJECT_ID \
PATH_TO_KUBECONFIG_1 \
PATH_TO_KUBECONFIG_2
Verifica la connettività multicluster
Questa sezione spiega come eseguire il deployment dei servizi HelloWorld
e Sleep
di esempio
nel tuo ambiente multi-cluster per verificare il funzionamento del bilanciamento del carico tra i cluster.
Attiva l'iniezione di sidecar
Individua il valore dell'etichetta di revisione, che utilizzerai nei passaggi successivi.
Usa questo comando per individuare l'etichetta di revisione, che dovrai nei passaggi successivi.
kubectl -n istio-system get pods -l app=istiod --show-labels
L'output è simile al seguente:
NAME READY STATUS RESTARTS AGE LABELS istiod-asm-173-3-5788d57586-bljj4 1/1 Running 0 23h app=istiod,istio.io/rev=asm-173-3,istio=istiod,pod-template-hash=5788d57586 istiod-asm-173-3-5788d57586-vsklm 1/1 Running 1 23h app=istiod,istio.io/rev=asm-173-3,istio=istiod,pod-template-hash=5788d57586
Nell'output, nella colonna LABELS
, prendi nota del valore dell'etichetta della revisione istiod
, che segue il prefisso istio.io/rev=
. In questo esempio,
Il valore è asm-173-3
. Utilizza il valore della revisione nei passaggi della sezione successiva.
Installa il servizio HelloWorld
Crea lo spazio dei nomi di esempio e la definizione del servizio in ogni cluster. Nella questo comando, sostituisci REVISION con
istiod
l'etichetta di revisione annotata nel passaggio precedente.for CTX in ${CTX_1} ${CTX_2} do kubectl create --context=${CTX} namespace sample kubectl label --context=${CTX} namespace sample \ istio-injection- istio.io/rev=REVISION --overwrite done
dove REVISION è l'etichetta di revisione
istiod
che hai annotato in precedenza.L'output è:
label "istio-injection" not found. namespace/sample labeled
Puoi ignorare tranquillamente
label "istio-injection" not found.
Crea il servizio HelloWorld in entrambi i cluster:
kubectl create --context=${CTX_1} \ -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \ -l service=helloworld -n sample
kubectl create --context=${CTX_2} \ -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \ -l service=helloworld -n sample
Esegui il deployment di HelloWorld v1 e v2 in ogni cluster
Esegui il deployment di
HelloWorld v1
inCLUSTER_1
e div2
suCLUSTER_2
, che consentono di verificare in un secondo momento il bilanciamento del carico tra cluster:kubectl create --context=${CTX_1} \ -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \ -l version=v1 -n sample
kubectl create --context=${CTX_2} \ -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \ -l version=v2 -n sample
Verifica che
HelloWorld v1
ev2
siano in esecuzione utilizzando i seguenti comandi. Verifica che l'output sia simile a quello mostrato:kubectl get pod --context=${CTX_1} -n sample
NAME READY STATUS RESTARTS AGE helloworld-v1-86f77cd7bd-cpxhv 2/2 Running 0 40s
kubectl get pod --context=${CTX_2} -n sample
NAME READY STATUS RESTARTS AGE helloworld-v2-758dd55874-6x4t8 2/2 Running 0 40s
esegui il deployment del servizio Sleep
Esegui il deployment del servizio
Sleep
in entrambi i cluster. Questo pod genera traffico di rete artificiale a scopo dimostrativo:for CTX in ${CTX_1} ${CTX_2} do kubectl apply --context=${CTX} \ -f ${SAMPLES_DIR}/samples/sleep/sleep.yaml -n sample done
Attendi l'avvio del servizio
Sleep
in ogni cluster. Verifica che l'output sia simile a quello mostrato:kubectl get pod --context=${CTX_1} -n sample -l app=sleep
NAME READY STATUS RESTARTS AGE sleep-754684654f-n6bzf 2/2 Running 0 5s
kubectl get pod --context=${CTX_2} -n sample -l app=sleep
NAME READY STATUS RESTARTS AGE sleep-754684654f-dzl9j 2/2 Running 0 5s
Verificare il bilanciamento del carico tra cluster
Chiama più volte il servizio HelloWorld
e controlla l'output per verificare
risposte alternate da v1 a v2:
Chiama il servizio
HelloWorld
:kubectl exec --context="${CTX_1}" -n sample -c sleep \ "$(kubectl get pod --context="${CTX_1}" -n sample -l \ app=sleep -o jsonpath='{.items[0].metadata.name}')" \ -- /bin/sh -c 'for i in $(seq 1 20); do curl -sS helloworld.sample:5000/hello; done'
L'output è simile a quello mostrato:
Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8 Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv ...
Chiama di nuovo il servizio
HelloWorld
:kubectl exec --context="${CTX_2}" -n sample -c sleep \ "$(kubectl get pod --context="${CTX_2}" -n sample -l \ app=sleep -o jsonpath='{.items[0].metadata.name}')" \ -- /bin/sh -c 'for i in $(seq 1 20); do curl -sS helloworld.sample:5000/hello; done'
L'output è simile a quello mostrato:
Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8 Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv ...
Congratulazioni, hai verificato il tuo Cloud Service Mesh multi-cluster bilanciato in base al carico.
Esegui la pulizia
Al termine della verifica del bilanciamento del carico, rimuovi HelloWorld
e Sleep
dal tuo cluster.
kubectl delete ns sample --context ${CTX_1} kubectl delete ns sample --context ${CTX_2}