Esegui il deployment di Apache Kafka in GKE utilizzando Confluent

La guida mostra come utilizzare l'operatore Confluent for Kubernetes (CFK) per eseguire il deployment di cluster Apache Kafka su Google Kubernetes Engine (GKE).

Kafka è un sistema di messaggistica di pubblicazione/sottoscrizione distribuito e open source per la gestione di flussi di dati in tempo reale ad alto volume e 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 è destinata ad amministratori di piattaforme, architetti cloud e professionisti delle operazioni interessati al deployment di cluster Kafka su GKE.

Puoi anche utilizzare l'operatore CFK per eseguire il deployment di altri componenti di Confluent Platform, come Confluent Control Center basato sul web, Schema Registry o KsqlDB. 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 automatici in sequenza per le modifiche alla configurazione.
  • Upgrade in sequenza automatizzati senza alcun impatto sulla disponibilità di Kafka.
  • Se si verifica un errore, CFK ripristina un pod Kafka con lo stesso ID broker Kafka, la stessa configurazione e gli stessi volumi di archiviazione permanenti.
  • Rilevamento automatico dei rack per distribuire le repliche di una partizione in rack (o zone) diversi, migliorando la disponibilità dei broker Kafka e limitando il rischio di perdita di dati.
  • Supporto per l'esportazione di 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 operazioni di lettura e scrittura 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 aiuta a eleggere un leader tra i broker e a attivare 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 di supporto per le risorse KafkaTopic e dell'autenticazione delle credenziali.

Disponibilità e ripristino di emergenza

Questo tutorial utilizza pool di nodi e zone separati per i cluster Kafka e ZooKeeper per garantire l'alta disponibilità e prepararsi al ripristino di emergenza.

I cluster Kubernetes ad alta disponibilità in Google Cloud si basano su cluster regionali che si estendono su più nodi e zone di disponibilità. Questa configurazione migliora la tolleranza di errore, la scalabilità e la ridondanza geografica. Questa configurazione consente inoltre di eseguire aggiornamenti e manutenzione in sequenza, fornendo SLA per il tempo di attività e la disponibilità. Per saperne di più, 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 di Kafka viene distribuito su tre nodi in tre zone diverse. Puoi controllare questa configurazione impostando le regole di affinità e distribuzione della topologia del pod richiesto 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 cluster ZooKeeper StatefulSet di cui è stato eseguito il deployment su tre nodi in tre zone diverse:

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il calcolatore prezzi.

I nuovi utenti di Google Cloud potrebbero avere diritto a una prova senza costi.

Al termine delle attività descritte in questo documento, puoi evitare l'addebito di ulteriori costi eliminando le risorse che hai creato. Per ulteriori informazioni, vedi Pulizia.

Prima di iniziare

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

  2. Install the Google Cloud CLI.

  3. Se utilizzi un provider di identità (IdP) esterno, devi prima accedere a gcloud CLI con la tua identità federata.

  4. Per inizializzare gcloud CLI, esegui questo comando: 

    gcloud init

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

  6. Verify that billing is enabled for your Google Cloud project.

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

  8. Install the Google Cloud CLI.

  9. Se utilizzi un provider di identità (IdP) esterno, devi prima accedere a gcloud CLI con la tua identità federata.

  10. Per inizializzare gcloud CLI, esegui questo comando: 

    gcloud init

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

  12. Verify that billing is enabled for your Google Cloud project.

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

  14. 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 the following:

    • PROJECT_ID: your project ID.
    • USER_IDENTIFIER: the identifier for your user account—for example, myemail@example.com.
    • ROLE: the IAM role that you grant to your user account.

    15. 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:

    1. Avvia una sessione di Cloud Shell dalla console Google Cloud facendo clic su Icona di attivazione di Cloud Shell Attiva Cloud Shell nella consoleGoogle Cloud . Viene avviata una sessione nel riquadro inferiore della console Google Cloud .

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

    3. Clona il repository GitHub:

      git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples

    4. 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 ad alta disponibilità. I seguenti passaggi consentono l'accesso pubblico al control plane. 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 Standard regionale privato di cui è stato eseguito il deployment in tre zone diverse:

    Per eseguire il deployment di questa infrastruttura, esegui questi 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 e la visualizzazione dello stato pronto del cluster potrebbero richiedere diversi minuti.

    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 node pool con 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 del 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 questi 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 e la visualizzazione dello stato pronto del cluster potrebbero richiedere diversi minuti.

    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 del 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 tuo cluster

    In questa sezione, esegui il deployment dell'operatore Confluent for Kubernetes (CFK) utilizzando un grafico Helm e poi esegui il deployment di un cluster Kafka.

    1. Aggiungi il repository del grafico Helm di Confluent:

      helm repo add confluentinc https://packages.confluent.io/helm

    2. Aggiungi uno spazio dei nomi per l'operatore CFK e il cluster Kafka:

      kubectl create ns kafka

    3. Esegui il deployment dell'operatore del 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.

    4. Verifica che l'operatore Confluent sia stato eseguito il deployment 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 e poi 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 dei broker Kafka, con un minimo di due repliche disponibili necessarie per la coerenza del cluster.
    • Tre repliche dei 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.
    • Allocazione delle risorse CPU di 1 richiesta CPU e 2 limiti CPU e 5 GB di richieste e limiti di memoria 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 allocato a ogni pod utilizzando premium-rwo storageClass, 100 per i dati Kafka e 90/10 per i dati/log di Zookeeper.
    • Tolleranze, nodeAffinity e podAntiAffinity configurati per ogni workload, garantendo una distribuzione corretta tra i nodi, utilizzando i rispettivi pool di nodi e zone diverse.
    • Comunicazione all'interno del cluster protetta da certificati autofirmati utilizzando 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

    1. 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 for Kubernetes fornisce certificati generati automaticamente per i componenti di Confluent Platform da utilizzare per la crittografia di rete TLS. Devi generare e fornire un'autorità di certificazione (CA).

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

    3. 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 a blocchi e taint e affinità per distribuire i pod di cui è stato eseguito il provisioning tra i nodi Kubernetes.

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

    5. Verifica che siano stati creati i carichi di lavoro Kafka:

      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 un massimo di 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. Tutti i listener Kafka interni sono disponibili in questo servizio.
    • 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 i listener Kafka e condividere le credenziali con i client.

    Confluent for 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 sono 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 archiviare le credenziali in Secrets e farvi riferimento nelle specifiche del listener.
    • Sebbene non esista una risorsa personalizzata per gestire direttamente gli ACL, la guida ufficiale di Confluent for Kubernetes fornisce indicazioni sulla configurazione degli ACL utilizzando la CLI Kafka.

    Crea un utente

    Questa sezione mostra come eseguire il deployment di un operatore CFK che dimostra le funzionalità di gestione degli utenti, tra cui:

    • Un cluster Kafka con autenticazione basata su password (SASL/PLAIN) abilitata su uno dei listener
    • Un KafkaTopic con 3 repliche
    • Credenziali utente con autorizzazioni di lettura e scrittura

    1. 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 archiviate nel seguente formato:

      {
"username1": "password1",
"username2": "password2",
...
"usernameN": "passwordN"
}

    2. Configura il cluster Kafka in modo che utilizzi un listener con autenticazione basata su password SCRAM-SHA-512 sulla porta 9094:

      kubectl apply -n kafka -f kafka-confluent/manifests/02-auth/my-cluster.yaml

    3. 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 nel pod client come volume.

    4. Quando il pod client è pronto, connettiti e inizia a produrre e utilizzare i messaggi utilizzando le credenziali fornite:

      kubectl wait pod kafkacat --for=condition=Ready --timeout=300s -n kafka
kubectl exec -it kafkacat -n kafka -- /bin/sh

    5. Produci un messaggio utilizzando le credenziali my-user e poi consumalo per verificarne 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 la procedura consumer. Se ricevi un errore Connect refused, attendi qualche minuto e riprova.

    6. Esci dalla shell del pod

      exit

    Backup e ripristino di emergenza

    Utilizzando 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 sottoposto a backup.
    • Volumi che corrispondono alle risorse PersistentVolumeClaim trovate nei manifest.

    Per maggiori informazioni su come eseguire il backup e il ripristino dei cluster Kafka utilizzando Backup per GKE, consulta Prepararsi per il disaster recovery.

    Puoi anche eseguire un backup manuale del cluster Kafka. Devi eseguire il backup di:

    • La configurazione di Kafka, che include tutte le risorse personalizzate dell'API Confluent, come KafkaTopics o Connect
    • I dati, archiviati nei PersistentVolume dei broker Kafka

    L'archiviazione dei manifest delle risorse Kubernetes, incluse le configurazioni 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 Kafka negli scenari in cui viene persa un'istanza del server Kafka o il cluster Kubernetes in cui è distribuito 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 creare snapshot dei volumi del broker Kafka.

    Il seguente manifest descrive una StorageClass che utilizza l'opzione reclaimPolicy Retain:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: premium-rwo-retain
...
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer

    L'esempio seguente mostra la StorageClass aggiunta a spec di una risorsa personalizzata del cluster Kafka:

    ...
spec:
  ...
  dataVolumeCapacity: 100Gi
  storageClass:
  name: premium-rwo-retain

    Con questa configurazione, i PersistentVolume 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 la configurazione esistente e i dati dell'istanza del broker:

    1. Applica le risorse personalizzate Confluent esistenti (Kafka, KafkaTopic, Zookeeper e così via) a un nuovo cluster Kubernetes
    2. Aggiorna PersistentVolumeClaims con il nome delle nuove istanze del broker Kafka ai vecchi PersistentVolumes utilizzando la proprietà spec.volumeName in 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.

    1. Imposta le variabili di ambiente:

      export PROJECT_ID=PROJECT_ID
export KUBERNETES_CLUSTER_PREFIX=kafka
export REGION=us-central1

    2. 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 con gke-autopilot o gke-standard.

      Quando richiesto, digita yes.

    3. 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)")

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