La guida mostra come utilizzare l'operatore Confluent per Kubernetes (CFK) per eseguire il deployment di cluster Apache Kafka su Google Kubernetes Engine (GKE).
Kafka è un sistema di messaggistica publish-subscribe distribuito open source per la gestione di dati in streaming in tempo reale ad alto volume e ad alta velocità effettiva. Puoi utilizzare Kafka per creare pipeline di dati in streaming che spostano i dati in modo affidabile tra diversi sistemi e applicazioni per l'elaborazione e l'analisi.
Questa guida è rivolta ad amministratori della piattaforma, architetti cloud e professionisti delle operazioni interessati a eseguire il deployment di cluster Kafka su GKE.
Puoi anche utilizzare l'operatore CFK per eseguire il deployment di altri componenti della piattaforma Confluent, come il Confluent Control Center, Schema Registry o KsqlDB basati sul web. Tuttavia, questa guida si concentra solo sui deployment di Kafka.
Obiettivi
- Pianifica ed esegui il deployment dell'infrastruttura GKE per Apache Kafka
- Esegui il deployment e configura l'operatore CFK
- Configura Apache Kafka utilizzando l'operatore CFK per garantire disponibilità, sicurezza, osservabilità e prestazioni
Vantaggi
CFK offre i seguenti vantaggi:
- Aggiornamenti incrementali automatici per le modifiche alla configurazione.
- Aggiornamenti in sequenza automatici senza impatto sulla disponibilità di Kafka.
- In caso di errore, CFK ripristina un pod Kafka con lo stesso ID broker Kafka, la stessa configurazione e gli stessi volumi di archiviazione permanente.
- Rilevamento automatico dei rack per distribuire le repliche di una partizione su diversi rack (o zone), migliorando la disponibilità dei broker Kafka e limitando il rischio di perdita di dati.
- Supporto per l'esportazione delle metriche aggregate in Prometheus.
Architettura di deployment
Ogni partizione di dati in un cluster Kafka ha un broker leader e può avere uno o più broker follower. Il broker leader gestisce tutte le letture e le scritture nella partizione. Ogni broker follower replica passivamente il broker leader.
In una configurazione Kafka tipica, utilizzi anche un servizio open source chiamato ZooKeeper per coordinare i cluster Kafka. Questo servizio è utile perché elegge un leader tra i broker e attiva il failover in caso di errori.
Puoi anche eseguire il deployment della configurazione di Kafka senza Zookeeper attivando la modalità KRaft, ma questo metodo non è considerato pronto per la produzione a causa della mancanza del supporto per le risorse KafkaTopic e per l'autenticazione delle credenziali.
Disponibilità e ripristino di emergenza
Questo tutorial utilizza pool di nodi e zone distinti per i cluster Kafka e ZooKeeper per garantire l'alta disponibilità e prepararsi al ripristino di emergenza.
I cluster Kubernetes ad alta disponibilità si basano su cluster regionali che coprono più nodi e zone di disponibilità. Google Cloud Questa configurazione migliora la tolleranza di errore, la scalabilità e la ridondanza geografica. Questa configurazione consente inoltre di eseguire aggiornamenti e manutenzione incrementali, nonché di fornire SLA per il tempo di attività e la disponibilità. Per ulteriori informazioni, consulta Cluster regionali.
Diagramma di deployment
Il seguente diagramma mostra un cluster Kafka in esecuzione su più nodi e zone in un cluster GKE:
Nel diagramma, il StatefulSet Kafka viene distribuito su tre nodi
in tre zone diverse. Puoi controllare questa configurazione impostando le regole di affinità e di distribuzione della topologia dei pod richieste nella specifica della risorsa personalizzata Kafka
.
Se una zona non funziona, utilizzando la configurazione consigliata, GKE riprogramma i pod sui nuovi nodi e replica i dati dalle repliche rimanenti sia per Kafka che per Zookeeper.
Il seguente diagramma mostra un'istanza ZooKeeper StatefulSet
di cui è stato eseguito il deployment su tre node in tre zone diverse:
Costi
In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:
Per generare una stima dei costi in base all'utilizzo previsto,
utilizza il Calcolatore prezzi.
Al termine delle attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la sezione Pulizia.
Prima di iniziare
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
Create or select a Google Cloud project.
-
Create a Google Cloud project:
gcloud projects create PROJECT_ID
Replace
PROJECT_ID
with a name for the Google Cloud project you are creating. -
Select the Google Cloud project that you created:
gcloud config set project PROJECT_ID
Replace
PROJECT_ID
with your Google Cloud project name.
-
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the GKE, Backup for GKE, Compute Engine, Identity and Access Management, and Resource Manager APIs:
gcloud services enable compute.googleapis.com
iam.googleapis.com container.googleapis.com gkebackup.googleapis.com cloudresourcemanager.googleapis.com - Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
Create or select a Google Cloud project.
-
Create a Google Cloud project:
gcloud projects create PROJECT_ID
Replace
PROJECT_ID
with a name for the Google Cloud project you are creating. -
Select the Google Cloud project that you created:
gcloud config set project PROJECT_ID
Replace
PROJECT_ID
with your Google Cloud project name.
-
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the GKE, Backup for GKE, Compute Engine, Identity and Access Management, and Resource Manager APIs:
gcloud services enable compute.googleapis.com
iam.googleapis.com container.googleapis.com gkebackup.googleapis.com cloudresourcemanager.googleapis.com -
Grant roles to your user account. Run the following command once for each of the following IAM roles:
role/storage.objectViewer, role/logging.logWriter, roles/container.clusterAdmin, role/container.serviceAgent, roles/iam.serviceAccountAdmin, roles/serviceusage.serviceUsageAdmin, roles/iam.serviceAccountAdmin
gcloud projects add-iam-policy-binding PROJECT_ID --member="user:USER_IDENTIFIER" --role=ROLE
- Replace
PROJECT_ID
with your project ID. -
Replace
USER_IDENTIFIER
with the identifier for your user account. For example,user:myemail@example.com
. - Replace
ROLE
with each individual role.
- Replace
Prepara l'ambiente
In questo tutorial utilizzerai
Cloud Shell
per gestire le risorse ospitate su Google Cloud. Cloud Shell è preinstallato con il software necessario per questo tutorial, tra cui kubectl
, gcloud CLI, Helm e Terraform.
Per configurare l'ambiente con Cloud Shell:
Avvia una sessione Cloud Shell dalla console Google Cloud facendo clic su
Attiva Cloud Shell nella console Google Cloud. Viene avviata una sessione nel riquadro inferiore della console Google Cloud.
Imposta le variabili di ambiente:
export PROJECT_ID=PROJECT_ID export KUBERNETES_CLUSTER_PREFIX=kafka export REGION=us-central1
Sostituisci
PROJECT_ID
: il tuo Google Cloud con il tuo ID progetto.Clona il repository GitHub:
git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
Passa alla directory di lavoro:
cd kubernetes-engine-samples/streaming
Crea l'infrastruttura del cluster
In questa sezione esegui uno script Terraform per creare un cluster GKE regionale privato e ad alta disponibilità. I passaggi che seguono consentono l'accesso pubblico al piano di controllo. Per limitare l'accesso, crea un cluster privato.
Puoi installare l'operatore utilizzando un cluster standard o Autopilot.
Standard
Il seguente diagramma mostra un cluster GKE regionale privato standard di cui è stato eseguito il deployment in tre zone diverse:
Per eseguire il deployment di questa infrastruttura, esegui i seguenti comandi da Cloud Shell:
export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform -chdir=kafka/terraform/gke-standard init
terraform -chdir=kafka/terraform/gke-standard apply -var project_id=${PROJECT_ID} \
-var region=${REGION} \
-var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}
Quando richiesto, digita yes
. Il completamento di questo comando potrebbe richiedere diversi minuti e il cluster potrebbe mostrare uno stato di disponibilità.
Terraform crea le seguenti risorse:
- Una rete VPC e una subnet privata per i nodi Kubernetes.
- Un router per accedere a internet tramite NAT.
- Un cluster GKE privato nella regione
us-central1
. - 2 pool di nodi con la scalabilità automatica abilitata (1-2 nodi per zona, minimo 1 nodo per zona)
- Un
ServiceAccount
con autorizzazioni di logging e monitoraggio. - Backup per GKE per il ripristino di emergenza.
- Google Cloud Managed Service per Prometheus per il monitoraggio dei cluster.
L'output è simile al seguente:
...
Apply complete! Resources: 14 added, 0 changed, 0 destroyed.
Outputs:
kubectl_connection_command = "gcloud container clusters get-credentials kafka-cluster --region us-central1"
Autopilot
Il seguente diagramma mostra un cluster GKE Autopilot regionale privato:
Per eseguire il deployment dell'infrastruttura, esegui i seguenti comandi da Cloud Shell:
export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform -chdir=kafka/terraform/gke-autopilot init
terraform -chdir=kafka/terraform/gke-autopilot apply -var project_id=${PROJECT_ID} \
-var region=${REGION} \
-var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}
Quando richiesto, digita yes
. Il completamento di questo comando potrebbe richiedere diversi minuti e il cluster potrebbe mostrare uno stato di disponibilità.
Terraform crea le seguenti risorse:
- Rete VPC e subnet privata per i nodi Kubernetes.
- Un router per accedere a internet tramite NAT.
- Un cluster GKE privato nella regione
us-central1
. - Un
ServiceAccount
con autorizzazioni di logging e monitoraggio - Google Cloud Managed Service per Prometheus per il monitoraggio dei cluster.
L'output è simile al seguente:
...
Apply complete! Resources: 12 added, 0 changed, 0 destroyed.
Outputs:
kubectl_connection_command = "gcloud container clusters get-credentials kafka-cluster --region us-central1"
Connettiti al cluster
Configura kubectl
per comunicare con il cluster:
gcloud container clusters get-credentials ${KUBERNETES_CLUSTER_PREFIX}-cluster --region ${REGION}
Esegui il deployment dell'operatore CFK nel cluster
In questa sezione esegui il deployment dell'operatore Confluent per Kubernetes (CFK) utilizzando un grafico Helm e poi esegui il deployment di un cluster Kafka.
Aggiungi il repository del grafico Helm di Confluent:
helm repo add confluentinc https://packages.confluent.io/helm
Aggiungi uno spazio dei nomi per l'operatore CFK e il cluster Kafka:
kubectl create ns kafka
Esegui il deployment dell'operatore di cluster CFK utilizzando Helm:
helm install confluent-operator confluentinc/confluent-for-kubernetes -n kafka
Per consentire a CFK di gestire le risorse in tutti gli spazi dei nomi, aggiungi il parametro
--set-namespaced=false
al comando Helm.Verifica che l'operatore Confluent sia stato disegnato correttamente utilizzando Helm:
helm ls -n kafka
L'output è simile al seguente:
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION confluent-operator kafka 1 2023-07-07 10:57:45.409158 +0200 CEST deployed confluent-for-kubernetes-0.771.13 2.6.0
Esegui il deployment di Kafka
In questa sezione esegui il deployment di Kafka in una configurazione di base, quindi prova vari scenari di configurazione avanzata per soddisfare i requisiti di disponibilità, sicurezza e osservabilità.
Configurazione di base
La configurazione di base per l'istanza Kafka include i seguenti componenti:
- Tre repliche di broker Kafka, con un minimo di due repliche disponibili obbligatorie per la coerenza del cluster.
- Tre repliche di nodi ZooKeeper che formano un cluster.
- Due listener Kafka: uno senza autenticazione e uno che utilizza l'autenticazione TLS con un certificato generato da CFK.
- MaxHeapSize e MinHeapSize di Java impostati su 4 GB per Kafka.
- Alloca risorse CPU di 1 richiesta CPU e 2 limiti CPU, nonché richieste e limiti di memoria di 5 GB per Kafka (4 GB per il servizio principale e 0,5 GB per l'esportatore di metriche) e 3 GB per Zookeeper (2 GB per il servizio principale e 0,5 GB per l'esportatore di metriche).
- 100 GB di spazio di archiviazione allocati a ciascun pod utilizzando
premium-rwo
storageClass, 100 per i dati di Kafka e 90/10 per i dati/i log di Zookeeper. - Tolleranza, nodeAffinities e podAntiAffinities configurati per ogni carico di lavoro, garantendo una distribuzione adeguata tra i nodi, utilizzando i rispettivi pool di nodi e zone diverse.
- La comunicazione all'interno del cluster è protetta da certificati autofirmati che utilizzano un'autorità di certificazione fornita da te.
Questa configurazione rappresenta la configurazione minima richiesta per creare un cluster Kafka pronto per la produzione. Le sezioni seguenti mostrano configurazioni personalizzate per gestire aspetti quali la sicurezza del cluster, gli elenchi di controllo dell'accesso (ACL), la gestione degli argomenti, la gestione dei certificati e altro ancora.
Crea un cluster Kafka di base
Genera una coppia di CA:
openssl genrsa -out ca-key.pem 2048 openssl req -new -key ca-key.pem -x509 \ -days 1000 \ -out ca.pem \ -subj "/C=US/ST=CA/L=Confluent/O=Confluent/OU=Operator/CN=MyCA"
Confluent per Kubernetes fornisce certificati generati automaticamente per i componenti della piattaforma Confluent da utilizzare per la crittografia di rete TLS. Devi generare e fornire un'autorità di certificazione (CA).
Crea un secret di Kubernetes per l'autorità di certificazione:
kubectl create secret tls ca-pair-sslcerts --cert=ca.pem --key=ca-key.pem -n kafka
Il nome del secret è predefinito
Crea un nuovo cluster Kafka utilizzando la configurazione di base:
kubectl apply -n kafka -f kafka-confluent/manifests/01-basic-cluster/my-cluster.yaml
Questo comando crea una risorsa personalizzata Kafka e una risorsa personalizzata Zookeeper dell'operatore CFK che includono richieste e limiti di CPU e memoria, richieste di archiviazione bloccate, nonché contaminazioni e affinità per distribuire i pod di cui è stato eseguito il provisioning tra i nodi Kubernetes.
Attendi qualche minuto mentre Kubernetes avvia i carichi di lavoro richiesti:
kubectl wait pods -l app=my-cluster --for condition=Ready --timeout=300s -n kafka
Verifica che i carichi di lavoro Kafka siano stati creati:
kubectl get pod,svc,statefulset,deploy,pdb -n kafka
L'output è simile al seguente:
NAME READY STATUS RESTARTS AGE pod/confluent-operator-864c74d4b4-fvpxs 1/1 Running 0 49m pod/my-cluster-0 1/1 Running 0 17m pod/my-cluster-1 1/1 Running 0 17m pod/my-cluster-2 1/1 Running 0 17m pod/zookeeper-0 1/1 Running 0 18m pod/zookeeper-1 1/1 Running 0 18m pod/zookeeper-2 1/1 Running 0 18m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/confluent-operator ClusterIP 10.52.13.164 <none> 7778/TCP 49m service/my-cluster ClusterIP None <none> 9092/TCP,8090/TCP,9071/TCP,7203/TCP,7777/TCP,7778/TCP,9072/TCP 17m service/my-cluster-0-internal ClusterIP 10.52.2.242 <none> 9092/TCP,8090/TCP,9071/TCP,7203/TCP,7777/TCP,7778/TCP,9072/TCP 17m service/my-cluster-1-internal ClusterIP 10.52.7.98 <none> 9092/TCP,8090/TCP,9071/TCP,7203/TCP,7777/TCP,7778/TCP,9072/TCP 17m service/my-cluster-2-internal ClusterIP 10.52.4.226 <none> 9092/TCP,8090/TCP,9071/TCP,7203/TCP,7777/TCP,7778/TCP,9072/TCP 17m service/zookeeper ClusterIP None <none> 2181/TCP,7203/TCP,7777/TCP,3888/TCP,2888/TCP,7778/TCP 18m service/zookeeper-0-internal ClusterIP 10.52.8.52 <none> 2181/TCP,7203/TCP,7777/TCP,3888/TCP,2888/TCP,7778/TCP 18m service/zookeeper-1-internal ClusterIP 10.52.12.44 <none> 2181/TCP,7203/TCP,7777/TCP,3888/TCP,2888/TCP,7778/TCP 18m service/zookeeper-2-internal ClusterIP 10.52.12.134 <none> 2181/TCP,7203/TCP,7777/TCP,3888/TCP,2888/TCP,7778/TCP 18m NAME READY AGE statefulset.apps/my-cluster 3/3 17m statefulset.apps/zookeeper 3/3 18m NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/confluent-operator 1/1 1 1 49m NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE poddisruptionbudget.policy/my-cluster N/A 1 1 17m poddisruptionbudget.policy/zookeeper N/A 1 1 18m
L'operatore crea le seguenti risorse:
- Due StatefulSet per Kafka e ZooKeeper.
- Tre pod per le repliche del broker Kafka.
- Tre pod per le repliche di ZooKeeper.
- Due risorse
PodDisruptionBudget
, che garantiscono al massimo una replica non disponibile per la coerenza del cluster. - Il servizio
my-cluster
che funge da server di bootstrap per i client Kafka che si connettono dall'interno del cluster Kubernetes. In questo servizio sono disponibili tutti gli ascoltatori Kafka interni. - Il servizio
zookeeper
che consente ai broker Kafka di connettersi ai nodi ZooKeeper come client.
Autenticazione e gestione degli utenti
Questa sezione mostra come attivare l'autenticazione e l'autorizzazione per proteggere gli ascoltatori Kafka e condividere le credenziali con i client.
Confluent per Kubernetes supporta vari metodi di autenticazione per Kafka, ad esempio:
- Autenticazione SASL/PLAIN: i client utilizzano un nome utente e una password per l'autenticazione. Il nome utente e la password vengono archiviati lato server in un secret Kubernetes.
- SASL/PLAIN con autenticazione LDAP: i client utilizzano un nome utente e una password per l'autenticazione. Le credenziali vengono memorizzate in un server LDAP.
- Autenticazione mTLS: i client utilizzano i certificati TLS per l'autenticazione.
Limitazioni
- CFK non fornisce risorse personalizzate per la gestione degli utenti. Tuttavia, puoi memorizzare le credenziali in Secret e fare riferimento ai secret nelle specifiche degli ascoltatori.
- Sebbene non esista una risorsa personalizzata per gestire direttamente le ACL, la documentazione ufficiale di Confluent per Kubernetes fornisce indicazioni sulla configurazione delle ACL utilizzando Kafka CLI.
Crea un utente
Questa sezione mostra come eseguire il deployment di un operatore CFK che dimostri le funzionalità di gestione degli utenti, tra cui:
- Un cluster Kafka con autenticazione basata su password (SASL/PLAIN) abilitata su uno degli ascoltatori
- Un
KafkaTopic
con 3 repliche - Credenziali utente con autorizzazioni di lettura e scrittura
Crea un secret con le credenziali utente:
export USERNAME=my-user export PASSWORD=$(openssl rand -base64 12) kubectl create secret generic my-user-credentials -n kafka \ --from-literal=plain-users.json="{\"$USERNAME\":\"$PASSWORD\"}"
Le credenziali devono essere memorizzate nel seguente formato:
{ "username1": "password1", "username2": "password2", ... "usernameN": "passwordN" }
Configura il cluster Kafka in modo che utilizzi un ascoltatore con autenticazione basata su password e autenticazione SCRAM-SHA-512 sulla porta 9094:
kubectl apply -n kafka -f kafka-confluent/manifests/02-auth/my-cluster.yaml
Configura un argomento e un pod client per interagire con il cluster Kafka ed eseguire i comandi Kafka:
kubectl apply -n kafka -f kafka-confluent/manifests/02-auth/my-topic.yaml kubectl apply -n kafka -f kafka-confluent/manifests/02-auth/kafkacat.yaml
GKE monta il secret
my-user-credentials
sul pod client come volume.Quando il pod client è pronto, connettiti e inizia a produrre e consumere messaggi utilizzando le credenziali fornite:
kubectl wait pod kafkacat --for=condition=Ready --timeout=300s -n kafka kubectl exec -it kafkacat -n kafka -- /bin/sh
Genera un messaggio utilizzando le credenziali
my-user
, quindi utilizzalo per verificare la ricezione.export USERNAME=$(cat /my-user/plain-users.json|cut -d'"' -f 2) export PASSWORD=$(cat /my-user/plain-users.json|cut -d'"' -f 4) echo "Message from my-user" |kcat \ -b my-cluster.kafka.svc.cluster.local:9094 \ -X security.protocol=SASL_SSL \ -X sasl.mechanisms=PLAIN \ -X sasl.username=$USERNAME \ -X sasl.password=$PASSWORD \ -t my-topic -P kcat -b my-cluster.kafka.svc.cluster.local:9094 \ -X security.protocol=SASL_SSL \ -X sasl.mechanisms=PLAIN \ -X sasl.username=$USERNAME \ -X sasl.password=$PASSWORD \ -t my-topic -C
L'output è simile al seguente:
Message from my-user % Reached end of topic my-topic [1] at offset 1 % Reached end of topic my-topic [2] at offset 0 % Reached end of topic my-topic [0] at offset 0
Digita
CTRL+C
per interrompere il processo del consumatore. Se ricevi un erroreConnect refused
, attendi qualche minuto e riprova.Esci dalla shell del pod
exit
Backup e ripristino di emergenza
Con l'operatore Confluent, puoi implementare strategie di backup efficienti seguendo determinati pattern.
Puoi utilizzare Backup per GKE per eseguire il backup di:
- Manifest delle risorse Kubernetes.
- Risorse personalizzate dell'API Confluent e relative definizioni estratte dal server API Kubernetes del cluster di cui viene eseguito il backup.
- Volumi corrispondenti alle risorse PersistentVolumeClaim presenti nei manifest.
Per ulteriori informazioni su come eseguire il backup e il ripristino dei cluster Kafka utilizzando Backup per GKE, consulta Prepararsi al ripristino di emergenza.
Puoi anche eseguire un backup manuale del cluster Kafka. Dovresti eseguire il backup di:
- La configurazione di Kafka, che include tutte le risorse personalizzate dell'API Confluent, come
KafkaTopics
oConnect
- I dati archiviati nei volumi permanenti dei broker Kafka
L'archiviazione dei manifest delle risorse Kubernetes, incluse le configurazioni di Confluent, nei repository Git può eliminare la necessità di un backup separato per la configurazione di Kafka, poiché le risorse possono essere riapplicate a un nuovo cluster Kubernetes, se necessario.
Per salvaguardare il recupero dei dati di Kafka negli scenari in cui viene persa un'istanza del server Kafka o un cluster Kubernetes in cui è implementato Kafka, ti consigliamo di configurare la classe di archiviazione Kubernetes utilizzata per il provisioning dei volumi per i broker Kafka con l'opzione reclaimPolicy
impostata su Retain
. Ti abbiamo anche consigliato di acquisire snapshot dei volumi del broker Kafka.
Il seguente manifest descrive una classe di archiviazione che utilizza l'reclaimPolicy
opzione Retain
:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: premium-rwo-retain
...
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
L'esempio seguente mostra StorageClass aggiunto a spec
di una risorsa personalizzata del cluster Kafka:
...
spec:
...
dataVolumeCapacity: 100Gi
storageClass:
name: premium-rwo-retain
Con questa configurazione, i volumi permanenti di cui è stato eseguito il provisioning utilizzando la classe di archiviazione non vengono eliminati anche quando viene eliminato il PersistentVolumeClaim corrispondente.
Per recuperare l'istanza Kafka su un nuovo cluster Kubernetes utilizzando i dati esistenti della configurazione e dell'istanza del broker:
- Applica le risorse personalizzate Confluent esistenti (
Kafka
,KafkaTopic
,Zookeeper
e così via) a un nuovo cluster Kubernetes - Aggiorna i PersistentVolumeClaim con il nome delle nuove istanze di broker Kafka ai vecchi PersistentVolume utilizzando la proprietà
spec.volumeName
sul PersistentVolumeClaim.
Esegui la pulizia
Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.
Elimina il progetto
Delete a Google Cloud project:
gcloud projects delete PROJECT_ID
Elimina le singole risorse
Se hai utilizzato un progetto esistente e non vuoi eliminarlo, elimina le singole risorse.
Imposta le variabili di ambiente:
export PROJECT_ID=PROJECT_ID export KUBERNETES_CLUSTER_PREFIX=kafka export REGION=us-central1
Esegui il comando
terraform destroy
:export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token) terraform -chdir=kafka/terraform/FOLDER destroy -var project_id=${PROJECT_ID} \ -var region=${REGION} \ -var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}
Sostituisci
FOLDER
congke-autopilot
ogke-standard
.Quando richiesto, digita
yes
.Trova tutti i dischi scollegati:
export disk_list=$(gcloud compute disks list --filter="-users:* AND labels.name=${KUBERNETES_CLUSTER_PREFIX}-cluster" --format "value[separator=|](name,zone)")
Elimina i dischi:
for i in $disk_list; do disk_name=$(echo $i| cut -d'|' -f1) disk_zone=$(echo $i| cut -d'|' -f2|sed 's|.*/||') echo "Deleting $disk_name" gcloud compute disks delete $disk_name --zone $disk_zone --quiet done
Passaggi successivi
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.