Configurazione di un mesh multi-cluster su GKE

Questa guida spiega come unire due cluster in un unico Anthos Service Mesh utilizzando Mesh CA o Istio CA e come abilitare il bilanciamento del carico tra cluster. Puoi estendere facilmente questo processo per incorporare un numero qualsiasi di cluster nel tuo mesh.

Una configurazione multi-cluster Anthos Service Mesh può risolvere diversi scenari aziendali cruciali, come scalabilità, località e isolamento. Per maggiori informazioni, consulta Casi d'uso multi-cluster.

Prerequisiti

Questa guida presuppone che tu disponga di due o più cluster Google Cloud GKE che soddisfano i seguenti requisiti:

Impostazione delle variabili di progetto e cluster

  1. Imposta una cartella di lavoro sugli esempi che utilizzi per verificare il funzionamento del bilanciamento del carico cross-cluster. Gli esempi si trovano in una sottodirectory della directory --output_dir specificata nel comando asmcli install. Nel seguente comando, modifica OUTPUT_DIR nella directory specificata in --output_dir e modifica ASM_VERSION in modo che corrisponda alla versione Anthos Service Mesh, ad esempio: 1.12.9-asm.3.

    export SAMPLES_DIR=OUTPUT_DIR/istio-ASM_VERSION
    
  2. Crea le seguenti variabili di ambiente per l'ID progetto, la zona o la regione del cluster, il nome del cluster e il contesto.

    export PROJECT_1=PROJECT_ID_1
    export LOCATION_1=CLUSTER_LOCATION_1
    export CLUSTER_1=CLUSTER_NAME_1
    export CTX_1="gke_${PROJECT_1}_${LOCATION_1}_${CLUSTER_1}"
    
    export PROJECT_2=PROJECT_ID_2
    export LOCATION_2=CLUSTER_LOCATION_2
    export CLUSTER_2=CLUSTER_NAME_2
    export CTX_2="gke_${PROJECT_2}_${LOCATION_2}_${CLUSTER_2}"
    
  3. Se si tratta di cluster appena creati, assicurati di recuperare le credenziali per ogni cluster con i seguenti comandi gcloud, altrimenti il cluster context associato non sarà disponibile per l'utilizzo nei passaggi successivi di questa guida.

    I comandi dipendono dal tipo di cluster, a livello di regione o zona:

    Regionale

    gcloud container clusters get-credentials ${CLUSTER_1} --region ${LOCATION_1}
    gcloud container clusters get-credentials ${CLUSTER_2} --region ${LOCATION_2}
    

    Zonale

    gcloud container clusters get-credentials ${CLUSTER_1} --zone ${LOCATION_1}
    gcloud container clusters get-credentials ${CLUSTER_2} --zone ${LOCATION_2}
    

Crea regola firewall

In alcuni casi, devi creare una regola firewall per consentire il traffico tra cluster. Ad esempio, devi creare una regola firewall se:

  • Nella rete mesh utilizzi subnet diverse per i cluster.
  • I pod aprono porte diverse da 443 e 15002.

GKE aggiunge automaticamente regole firewall a ciascun nodo per consentire il traffico all'interno della stessa subnet. Se la rete mesh contiene più subnet, devi configurare esplicitamente le regole firewall per consentire il traffico tra subnet. Devi aggiungere una nuova regola firewall per ogni subnet per consentire ai blocchi CIDR degli IP di origine e alla destinazione delle porte di tutto il traffico in entrata.

Le istruzioni seguenti consentono la comunicazione tra tutti i cluster nel progetto o solo tra $CLUSTER_1 e $CLUSTER_2.

  1. Raccogli informazioni sulla rete dei tuoi cluster.

    Tutti i cluster di progetto

    Se i cluster si trovano nello stesso progetto, puoi utilizzare il seguente comando per consentire la comunicazione tra tutti i cluster nel tuo progetto. Se nel progetto sono presenti cluster che non vuoi esporre, utilizza il comando nella scheda Cluster specifici.

    function join_by { local IFS="$1"; shift; echo "$*"; }
    ALL_CLUSTER_CIDRS=$(gcloud container clusters list --project $PROJECT_1 --format='value(clusterIpv4Cidr)' | sort | uniq)
    ALL_CLUSTER_CIDRS=$(join_by , $(echo "${ALL_CLUSTER_CIDRS}"))
    ALL_CLUSTER_NETTAGS=$(gcloud compute instances list --project $PROJECT_1 --format='value(tags.items.[0])' | sort | uniq)
    ALL_CLUSTER_NETTAGS=$(join_by , $(echo "${ALL_CLUSTER_NETTAGS}"))
    

    Cluster specifici

    Il seguente comando consente la comunicazione tra $CLUSTER_1 e $CLUSTER_2 e non espone altri cluster nel progetto.

    function join_by { local IFS="$1"; shift; echo "$*"; }
    ALL_CLUSTER_CIDRS=$(for P in $PROJECT_1 $PROJECT_2; do gcloud --project $P container clusters list --filter="name:($CLUSTER_1,$CLUSTER_2)" --format='value(clusterIpv4Cidr)'; done | sort | uniq)
    ALL_CLUSTER_CIDRS=$(join_by , $(echo "${ALL_CLUSTER_CIDRS}"))
    ALL_CLUSTER_NETTAGS=$(for P in $PROJECT_1 $PROJECT_2; do gcloud --project $P compute instances list  --filter="name:($CLUSTER_1,$CLUSTER_2)" --format='value(tags.items.[0])' ; done | sort | uniq)
    ALL_CLUSTER_NETTAGS=$(join_by , $(echo "${ALL_CLUSTER_NETTAGS}"))
    
  2. Crea la regola firewall.

    GKE

    gcloud compute firewall-rules create istio-multicluster-pods \
        --allow=tcp,udp,icmp,esp,ah,sctp \
        --direction=INGRESS \
        --priority=900 \
        --source-ranges="${ALL_CLUSTER_CIDRS}" \
        --target-tags="${ALL_CLUSTER_NETTAGS}" --quiet \
        --network=YOUR_NETWORK
    

    Autopilot

    TAGS=""
    for CLUSTER in ${CLUSTER_1} ${CLUSTER_2}
    do
        TAGS+=$(gcloud compute firewall-rules list --filter="Name:$CLUSTER*" --format="value(targetTags)" | uniq) && TAGS+=","
    done
    TAGS=${TAGS::-1}
    echo "Network tags for pod ranges are $TAGS"
    
    gcloud compute firewall-rules create asm-multicluster-pods \
        --allow=tcp,udp,icmp,esp,ah,sctp \
        --network=gke-cluster-vpc \
        --direction=INGRESS \
        --priority=900 --network=VPC_NAME \
        --source-ranges="${ALL_CLUSTER_CIDRS}" \
        --target-tags=$TAGS
    

Configura il rilevamento degli endpoint tra i cluster

I passaggi necessari per configurare il rilevamento degli endpoint dipendono dal fatto che tu preferisca utilizzare l'API dichiarativa nei vari cluster di un parco risorse o abilitarla manualmente su cluster pubblici o cluster privati.

Per configurare il rilevamento degli endpoint tra cluster GKE, esegui asmcli create-mesh. Questo comando:

  • Registra tutti i cluster nello stesso parco risorse.
  • Configura il mesh in modo che consideri attendibile l'identità dei carichi di lavoro del parco risorse.
  • Crea secret remoti.

Puoi specificare l'URI di ciascun cluster o il percorso del file kubeconfig.

URI cluster

Nel comando seguente, sostituisci FLEET_PROJECT_ID con l'ID progetto del progetto host del parco risorse e l'URI del cluster con il nome del cluster, la zona o la regione e l'ID progetto di ogni cluster. Questo esempio mostra solo due cluster, ma puoi eseguire il comando per consentire il rilevamento degli endpoint su altri cluster, in base al numero massimo consentito di cluster che puoi aggiungere al tuo parco risorse.

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    ${PROJECT_1}/${LOCATION_1}/${CLUSTER_1} \
    ${PROJECT_2}/${LOCATION_2}/${CLUSTER_2}

file kubeconfig

Nel comando seguente, sostituisci FLEET_PROJECT_ID con l'ID progetto del progetto host del parco risorse e PATH_TO_KUBECONFIG con il percorso di ogni file kubeconfig. Questo esempio mostra solo due cluster, ma puoi eseguire il comando per abilitare il rilevamento degli endpoint su cluster aggiuntivi, in base al limite di servizio GKE Hub.

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PATH_TO_KUBECONFIG_1 \
    PATH_TO_KUBECONFIG_2

Configura le reti autorizzate per i cluster privati

Segui questa sezione solo se tutte le condizioni seguenti si applicano al tuo mesh:

Quando esegui il deployment di più cluster privati, il piano di controllo Anthos Service Mesh in ogni cluster deve chiamare il piano di controllo GKE dei cluster remoti. Per consentire il traffico, devi aggiungere l'intervallo di indirizzi dei pod nel cluster di chiamata alle reti autorizzate dei cluster remoti.

  1. Ottieni il blocco CIDR IP del pod per ogni cluster:

    POD_IP_CIDR_1=`gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
      --format "value(ipAllocationPolicy.clusterIpv4CidrBlock)"`
    
    POD_IP_CIDR_2=`gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
      --format "value(ipAllocationPolicy.clusterIpv4CidrBlock)"`
    
  2. Aggiungi i blocchi CIDR IP dei pod del cluster Kubernetes ai cluster remoti:

    EXISTING_CIDR_1=`gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
     --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"`
    gcloud container clusters update ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
    --enable-master-authorized-networks \
    --master-authorized-networks ${POD_IP_CIDR_2},${EXISTING_CIDR_1//;/,}
    
    EXISTING_CIDR_2=`gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
     --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"`
    gcloud container clusters update ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
    --enable-master-authorized-networks \
    --master-authorized-networks ${POD_IP_CIDR_1},${EXISTING_CIDR_2//;/,}
    

    Per maggiori informazioni, consulta la sezione Creazione di un cluster con reti autorizzate.

  3. Verifica che le reti autorizzate siano aggiornate:

    gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
     --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"
    
    gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
     --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"
    

Abilita accesso globale piano di controllo

Segui questa sezione solo se tutte le condizioni seguenti si applicano al tuo mesh:

  • Stai utilizzando cluster privati.
  • Puoi utilizzare regioni diverse per i cluster nel tuo mesh.

Devi abilitare l'accesso globale al piano di controllo per consentire al piano di controllo Anthos Service Mesh in ogni cluster di chiamare il piano di controllo GKE dei cluster remoti.

  1. Abilita accesso globale piano di controllo:

    gcloud container clusters update ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
     --enable-master-global-access
    
    gcloud container clusters update ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
     --enable-master-global-access
    
  2. Verifica che l'accesso globale al piano di controllo sia abilitato:

    gcloud container clusters describe ${CLUSTER_1} --zone ${LOCATION_1}
    
    gcloud container clusters describe ${CLUSTER_2} --zone ${LOCATION_2}
    

    La sezione privateClusterConfig nell'output mostra lo stato di masterGlobalAccessConfig.

Configura il rilevamento degli endpoint tra cluster privati

Quando utilizzi cluster privati, devi configurare gli IP privati dei cluster remoti anziché gli IP pubblici perché gli IP pubblici non sono accessibili.

  1. Recuperare gli IP privati per i cluster privati e sostituire gli IP pubblici con loro nei secret dei file temporanei. I comandi dipendono dal tipo di Anthos Service Mesh (in-cluster o gestito):

    A. Per Anthos Service Mesh nel cluster:

    PRIV_IP=`gcloud container clusters describe "${CLUSTER_1}" --project "${PROJECT_1}" \
     --zone "${LOCATION_1}" --format "value(privateClusterConfig.privateEndpoint)"`
    
    ./istioctl x create-remote-secret --context=${CTX_1} --name=${CLUSTER_1} --server=https://${PRIV_IP} > ${CTX_1}.secret
    
    PRIV_IP=`gcloud container clusters describe "${CLUSTER_2}" --project "${PROJECT_2}" \
     --zone "${LOCATION_2}" --format "value(privateClusterConfig.privateEndpoint)"`
    
    ./istioctl x create-remote-secret --context=${CTX_2} --name=${CLUSTER_2} --server=https://${PRIV_IP} > ${CTX_2}.secret
    

    B. Per Anthos Service Mesh gestito:

    PUBLIC_IP=`gcloud container clusters describe "${CLUSTER_1}" --project "${PROJECT_1}" \
     --zone "${LOCATION_1}" --format "value(privateClusterConfig.publicEndpoint)"`
    
    ./istioctl x create-remote-secret --context=${CTX_1} --name=${CLUSTER_1} --server=https://${PUBLIC_IP} > ${CTX_1}.secret
    
    PUBLIC_IP=`gcloud container clusters describe "${CLUSTER_2}" --project "${PROJECT_2}" \
     --zone "${LOCATION_2}" --format "value(privateClusterConfig.publicEndpoint)"`
    
    ./istioctl x create-remote-secret --context=${CTX_2} --name=${CLUSTER_2} --server=https://${PUBLIC_IP} > ${CTX_2}.secret
    
  2. Applica i nuovi secret nei cluster:

    kubectl apply -f ${CTX_1}.secret --context=${CTX_2}
    
    kubectl apply -f ${CTX_2}.secret --context=${CTX_1}
    

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 cluster.

Imposta variabile per la directory degli esempi

  1. Vai alla posizione in cui è stato scaricato l'elemento asmcli ed esegui il comando seguente per impostare ASM_VERSION

    export ASM_VERSION="$(./asmcli --version)"
    
  2. Imposta una cartella di lavoro sugli esempi che utilizzi per verificare il funzionamento del bilanciamento del carico cross-cluster. Gli esempi si trovano in una sottodirectory della directory --output_dir specificata nel comando asmcli install. Nel comando seguente, imposta OUTPUT_DIR sulla directory specificata in --output_dir.

    export SAMPLES_DIR=OUTPUT_DIR/istio-${ASM_VERSION%+*}
    

Attiva inserimento sidecar

  1. Individua il valore dell'etichetta della revisione, che utilizzerai nei passaggi successivi. Il passaggio dipende dal tipo di Anthos Service Mesh (gestito o nel cluster).

    Gestita

    Utilizza il comando seguente per individuare l'etichetta di revisione, che utilizzerai nei passaggi successivi.

    kubectl get controlplanerevision -n istio-system

    L'output è simile al seguente:

     NAME                RECONCILED   STALLED   AGE
     asm-managed-rapid   True         False     89d
     

    Nell'output, sotto la colonna NAME, prendi nota del valore dell'etichetta di revisione. In questo esempio, il valore è asm-managed-rapid. Utilizza il valore di revisione nei passaggi della sezione successiva.

    Nel cluster

    Utilizza il comando seguente per individuare l'etichetta di revisione, che utilizzerai 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, sotto la colonna LABELS, prendi nota del valore dell'etichetta di 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

  1. Crea lo spazio dei nomi di esempio e la definizione del servizio in ogni cluster. Nel comando seguente, sostituisci REVISION con l'etichetta di revisione istiod che hai annotato 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 label "istio-injection" not found.

  2. 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 ciascun cluster

  1. Esegui il deployment di HelloWorld v1 in CLUSTER_1 e di v2 in CLUSTER_2, che consente 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
  2. Verifica che HelloWorld v1 e v2 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

  1. Esegui il deployment del servizio Sleep in entrambi i cluster. Questo pod genera traffico di rete artificiale a fini dimostrativi:

    for CTX in ${CTX_1} ${CTX_2}
    do
        kubectl apply --context=${CTX} \
            -f ${SAMPLES_DIR}/samples/sleep/sleep.yaml -n sample
    done
    
  2. 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

Verifica il bilanciamento del carico tra cluster

Chiama il servizio HelloWorld più volte e controlla l'output per verificare le risposte alternative da v1 e v2:

  1. 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}')" \
        -- curl -sS helloworld.sample:5000/hello
    

    L'output è simile a quello mostrato:

    Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8
    Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv
    ...
  2. 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}')" \
        -- curl -sS helloworld.sample:5000/hello
    

    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 Anthos Service Mesh multi-cluster con bilanciamento del carico.

Esegui la pulizia del servizio HelloWorld

Al termine della verifica del bilanciamento del carico, rimuovi il servizio HelloWorld e Sleep dal cluster.

kubectl delete ns sample --context ${CTX_1}
kubectl delete ns sample --context ${CTX_2}