Configurazione di un mesh multi-cluster su GKE
Questa guida spiega come unire due cluster in un singolo Anthos Service Mesh utilizzando Mesh CA o Istio CA e abilitare il bilanciamento del carico tra cluster. Puoi facilmente estendere questo processo per incorporare un numero qualsiasi di cluster nel tuo mesh.
Una configurazione multi-cluster Anthos Service Mesh è in grado di risolvere diversi scenari aziendali cruciali, come la scalabilità, la posizione e l'isolamento. Per ulteriori informazioni, consulta Casi d'uso multi-cluster.
Prerequisiti
Questa guida presuppone che tu abbia due o più cluster GKE di Google Cloud che soddisfano i seguenti requisiti:
Anthos Service Mesh 1.11 o versioni successive installato sui cluster utilizzando
asmcli install
. Sono necessariasmcli
, lo strumentoistioctl
e gli esempi cheasmcli
scarica nella directory specificata in--output_dir
quando hai eseguitoasmcli install
Se è necessaria la configurazione, segui i passaggi descritti in Installare gli strumenti dipendenti e convalidare il cluster per:I cluster nel mesh devono avere connettività tra tutti i pod prima di configurare Anthos Service Mesh. Inoltre, se unisci cluster che non si trovano nello stesso progetto, questi devono essere registrati nello stesso progetto host del parco risorse e i cluster devono trovarsi insieme in una configurazione di VPC condiviso sulla stessa rete. Ti consigliamo inoltre di avere un progetto per ospitare il VPC condiviso e due progetti di servizio per la creazione di cluster. Per ulteriori informazioni, consulta Configurazione di cluster con VPC condiviso.
Se utilizzi Istio CA, utilizza lo stesso certificato radice personalizzato per entrambi i cluster.
Se Anthos Service Mesh è basato su cluster privati, ti consigliamo di creare una singola subnet nello stesso VPC, altrimenti devi assicurarti che:
- I piani di controllo possono raggiungere quelli del cluster privato remoto tramite gli IP privati del cluster.
- Puoi aggiungere gli intervalli IP dei piani di controllo delle chiamate alle reti autorizzate dei cluster privati remoti. Per ulteriori informazioni, consulta Configurare il rilevamento degli endpoint tra cluster privati.
Il server API deve essere raggiungibile dalle altre istanze del piano di controllo Anthos Service Mesh nel mesh multi-cluster.
- Assicurati che nei cluster sia abilitato l'accesso globale.
- Assicurati che l'IP del piano di controllo di Anthos Service Mesh sia stato consentito correttamente tramite l'elenco consentito con la rete autorizzata master.
Impostazione delle variabili di progetto e cluster
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}"
Se si tratta di cluster appena creati, assicurati di recuperare le credenziali per ogni cluster con i seguenti comandi
gcloud
, altrimenti il relativocontext
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:
- Puoi utilizzare subnet diverse per i cluster nella tua rete mesh.
- 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 tua rete mesh contiene più subnet, devi configurare esplicitamente le regole del firewall per consentire il traffico tra subnet. Devi aggiungere una nuova regola firewall per ogni subnet per consentire i blocchi CIDR IP di origine e le porte di destinazione di tutto il traffico in entrata.
Le seguenti istruzioni consentono la comunicazione tra tutti i cluster nel progetto o solo tra $CLUSTER_1
e $CLUSTER_2
.
Raccogli informazioni sulla rete dei tuoi cluster.
Tutti i cluster di progetto
Se i cluster si trovano nello stesso progetto, puoi usare il comando seguente per consentire la comunicazione tra tutti i cluster del 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 tuo 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}"))
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
I passaggi necessari per configurare il rilevamento degli endpoint variano a seconda che tu preferisca utilizzare l'API dichiarativa nei vari cluster di un parco risorse o abilitarla manualmente su cluster pubblici o cluster privati.
Abilita il rilevamento degli endpoint tra cluster pubblici o privati con un'API dichiarativa (anteprima)
Puoi abilitare il rilevamento degli endpoint in cluster pubblici o privati in un parco risorse applicando la configurazione "multicluster_mode":"connected"
nella configmap di asm-options
. Per i cluster con questa configurazione abilitata nello stesso parco risorse, Service Discovery tra cluster sarà automaticamente abilitato tra loro.
Questo metodo è disponibile per le installazioni gestite di Anthos Service Mesh su tutti i canali di rilascio. Questo è anche il modo migliore per configurare il rilevamento degli endpoint multi-cluster se hai eseguito il provisioning di Anthos Service Mesh gestito utilizzando la funzionalità Abilita Anthos Service Mesh durante la creazione di un nuovo cluster GKE nella console Google Cloud.
Prima di procedere, devi aver creato una regola firewall.
Per più progetti, devi aggiungere manualmente FLEET_PROJECT_ID.svc.id.goog
a trustDomainAliases
nell'elemento meshConfig
della revisione, se non è già presente.
Abilita
Se la configmap asm-options
esiste già nel cluster, abilita
il rilevamento degli endpoint per il cluster:
kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'
Se la configmap asm-options
non esiste ancora nel cluster, creala con i dati associati e abilita il rilevamento degli endpoint per
il cluster:
kubectl --context ${CTX_1} create configmap asm-options -n istio-system --from-file <(echo '{"data":{"multicluster_mode":"connected"}}')
Disabilita
Disabilita il rilevamento degli endpoint per un cluster:
kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"manual"}}'
Se annulli la registrazione di un cluster dal parco risorse senza disabilitare il rilevamento degli endpoint, nel cluster potrebbero rimanere dei secret. Devi eseguire manualmente la pulizia di eventuali secret rimanenti.
Esegui questo comando per trovare i secret che richiedono la pulizia:
kubectl get secrets -n istio-system -l istio.io/owned-by=mesh.googleapis.com,istio/multiCluster=true
Elimina ogni secret:
kubectl delete secret SECRET_NAME
Ripeti questo passaggio per ogni secret rimanente.
Configura il rilevamento degli endpoint tra cluster pubblici
Per configurare il rilevamento degli endpoint tra i cluster GKE, esegui
asmcli create-mesh
. Questo comando:
- Registra tutti i cluster nello stesso parco risorse.
- Configura il mesh in modo che l'identità dei carichi di lavoro del parco risorse sia attendibile.
- Crea secret remoti.
Puoi specificare l'URI per ciascun cluster o il percorso del file kubeconfig.
URI cluster
Nel comando seguente, sostituisci FLEET_PROJECT_ID
con l'ID del progetto host del parco risorse e l'URI del cluster con il nome, la zona o la regione del cluster e l'ID progetto per ogni cluster.
Questo esempio mostra solo due cluster, ma puoi eseguire il comando per abilitare il rilevamento degli endpoint su cluster aggiuntivi, 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 numero massimo consentito di cluster che puoi aggiungere al tuo parco risorse.
./asmcli create-mesh \
FLEET_PROJECT_ID \
PATH_TO_KUBECONFIG_1 \
PATH_TO_KUBECONFIG_2
Configura il rilevamento degli endpoint tra cluster privati
Configura i secret remoti per consentire l'accesso del server API al cluster al piano di controllo Anthos Service Mesh dell'altro cluster. I comandi dipendono dal tipo di Anthos Service Mesh (in-cluster o gestito):
A. Per Anthos Service Mesh in-cluster, devi configurare gli IP privati anziché pubblici perché gli IP pubblici non sono accessibili:
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 Managed Anthos Service Mesh:
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
Applica i nuovi secret ai cluster:
kubectl apply -f ${CTX_1}.secret --context=${CTX_2}
kubectl apply -f ${CTX_2}.secret --context=${CTX_1}
Configura le reti autorizzate per i cluster privati
Segui questa sezione solo se al mesh si applicano tutte le seguenti condizioni:
- Stai utilizzando cluster privati.
- I cluster non appartengono alla stessa subnet.
- I cluster hanno abilitato le reti autorizzate.
Quando esegui il deployment di più cluster privati, il piano di controllo Anthos Service Mesh in ciascun 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.
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)"`
Aggiungi i blocchi CIDR IP del 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 ulteriori informazioni, consulta Creazione di un cluster con reti autorizzate.
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 l'accesso globale al piano di controllo
Segui questa sezione solo se al mesh si applicano tutte le seguenti condizioni:
- Stai utilizzando dei 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 ciascun cluster di chiamare il piano di controllo GKE dei cluster remoti.
Abilita l'accesso globale al 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
Verifica che l'accesso globale al piano di controllo sia abilitato:
gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1}
gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2}
La sezione
privateClusterConfig
nell'output mostra lo stato dimasterGlobalAccessConfig
.
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 che il bilanciamento del carico tra cluster funzioni.
Imposta variabile per la directory di esempio
Vai alla posizione in cui è stato scaricato
asmcli
ed esegui questo comando per impostareASM_VERSION
export ASM_VERSION="$(./asmcli --version)"
Imposta una cartella di lavoro per gli esempi che utilizzi per verificare che il bilanciamento del carico tra cluster funzioni. Gli esempi si trovano in una sottodirectory nella directory
--output_dir
che hai specificato nel comandoasmcli install
. Nel comando seguente, cambiaOUTPUT_DIR
nella directory che hai specificato in--output_dir
.export SAMPLES_DIR=OUTPUT_DIR/istio-${ASM_VERSION%+*}
Attiva inserimento file collaterale
Individua il valore dell'etichetta di revisione, che utilizzerai nei passaggi successivi. Il passaggio dipende dal tipo di Anthos Service Mesh (gestito o in-cluster).
Gestito
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 revisioneistiod
, che segue il prefissoistio.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. 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
indicata 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
Verifica il bilanciamento del carico tra cluster
Chiama più volte il servizio HelloWorld
e controlla l'output per verificare
le risposte alternative delle versioni 1 e 2:
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 Anthos Service Mesh multi-cluster con bilanciamento del carico.
Libera spazio nel servizio HelloWorld
Al termine della verifica del bilanciamento del carico, rimuovi i servizi HelloWorld
e Sleep
dal cluster.
kubectl delete ns sample --context ${CTX_1} kubectl delete ns sample --context ${CTX_2}