Esegui il deployment di Apache Kafka in GKE utilizzando Confluent

Autopilot Standard

---

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 distribuito e open source open source per la gestione di volumi elevati, velocità effettiva elevata e flussi di dati in tempo reale. Puoi utilizzare Kafka per creare pipeline di dati in modalità flusso che trasferiscono i dati in modo affidabile tra diversi sistemi e applicazioni per l'elaborazione e l'analisi.

Questa guida è rivolta agli amministratori di piattaforma, ai Cloud Architect e ai professionisti operativi interessati al deployment dei cluster Kafka su GKE.

Puoi utilizzare l'operatore CFK anche per eseguire il deployment di altri componenti della piattaforma Confluent, come Confluent Control Center, registro di schemi o KsqlDB basato sul web. Tuttavia, questa guida si concentra solo sui deployment di Kafka.

Nota: l'operatore CFK e la maggior parte dei componenti della piattaforma Confluent sono distribuiti ai sensi di una licenza ?onfluent Enterprise e le limitazioni della licenza richiedono agli utenti di avere un abbonamento attivo dopo 30 giorni di prova per continuare a utilizzare l'operatore. La Licenza sviluppatore è disponibile anche per una durata indefinita, ma è limitata a una singola configurazione di broker per cluster.

Obiettivi

• Pianifica ed esegui il deployment dell'infrastruttura GKE per Apache Kafka
• Deployment e configurazione dell'operatore CFK
• Configura Apache Kafka utilizzando l'operatore CFK per garantire disponibilità, sicurezza, osservabilità e prestazioni

Vantaggi

CFK offre i seguenti vantaggi:

• Aggiornamenti in sequenza automatici per le modifiche alla configurazione.
• Upgrade in sequenza automatici senza 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 permanente.
• Rilevamento automatico del rack per distribuire le repliche di una partizione tra 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 dei follower replica passivamente il broker leader.

In una configurazione tipica di Kafka, puoi utilizzare anche un servizio open source chiamato ZooKeeper per coordinare i cluster Kafka. Questo servizio aiuta a scegliere un leader tra i broker e ad attivare il failover in caso di errore.

Puoi anche eseguire il deployment della configurazione 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 distinti per i cluster Kafka e ZooKeeper per garantire l'alta disponibilità e prepararsi per il ripristino di emergenza.

I cluster Kubernetes ad alta disponibilità in Google Cloud si basano su cluster a livello di regione che comprendono 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 in sequenza e manutenzione, fornendo al contempo SLA (accordi sul livello del servizio) per uptime e disponibilità. Per ulteriori informazioni, consulta la sezione Cluster a livello di regione.

Diagramma di deployment

Il seguente diagramma mostra un cluster Kafka in esecuzione su più nodi e zone in un cluster GKE:

Nel diagramma, il deployment dello StatefulSet Kafka viene eseguito in tre nodi in tre zone diverse. Puoi controllare questa configurazione impostando le regole necessarie per l'affinità e la dispersione della topologia dei pod nella specifica delle risorse personalizzate Kafka.

Se in una zona si verifica un errore, utilizzando la configurazione consigliata, GKE ripianifica i pod su nuovi nodi e replica i dati delle repliche rimanenti, sia per Kafka che per Zookeeper.

Il seguente diagramma mostra un StatefulSet di ZooKeeper eseguito su tre nodi in tre zone diverse:

Costi

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

• GKE
• Managed Service per Prometheus
• Compute Engine

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud possono essere idonei a una prova senza costi aggiuntivi.

Una volta completate le attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la pagina Pulizia.

Prima di iniziare

1. Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.
2. Installa Google Cloud CLI.

3. Per initialize gcloud CLI, esegui questo comando:

   gcloud init

   Nota: se hai già installato gcloud CLI in precedenza, assicurati di disporre della versione più recente eseguendo gcloud components update.

4. Create or select a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the 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.

5. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

6. Abilita le API GKE, Backup for GKE, Compute Engine, Identity and Access Management, and Resource Manager.

   gcloud services enable compute.googleapis.com iam.googleapis.com container.googleapis.com gkebackup.googleapis.com cloudresourcemanager.googleapis.com

7. Installa Google Cloud CLI.

8. Per initialize gcloud CLI, esegui questo comando:

   gcloud init

   Nota: se hai già installato gcloud CLI in precedenza, assicurati di disporre della versione più recente eseguendo gcloud components update.

9. Create or select a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the 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.

10. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

11. Abilita le API GKE, Backup for GKE, Compute Engine, Identity and Access Management, and Resource Manager.

    gcloud services enable compute.googleapis.com iam.googleapis.com container.googleapis.com gkebackup.googleapis.com cloudresourcemanager.googleapis.com

12. Concedi i ruoli al tuo Account Google. Esegui questo comando una volta per ciascuno dei seguenti ruoli IAM: 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:EMAIL_ADDRESS" --role=ROLE

    • Sostituisci PROJECT_ID con l'ID progetto.
    • Sostituisci EMAIL_ADDRESS con il tuo indirizzo email.
    • Sostituisci ROLE con ogni singolo ruolo.

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, inclusi kubectl, gcloud CLI, Helm e Terraform.

Per configurare il tuo ambiente con Cloud Shell, segui questi passaggi:

1. Avvia una sessione di 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.

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

In questa sezione eseguirai uno script Terraform per creare un cluster GKE privato a disponibilità elevata a livello di regione. I seguenti passaggi 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 Standard a livello di regione privato di cui è stato eseguito il deployment in tre zone diverse:

Per eseguire il deployment di questa infrastruttura, esegui i comandi seguenti 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. Potrebbero essere necessari diversi minuti per completare il comando e prima che il cluster mostri lo stato Pronto.

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 scalabilità automatica abilitata (1-2 nodi per zona, 1 nodo per zona minimo)
• 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 a livello di regione 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. Potrebbero essere necessari diversi minuti per completare il comando e prima che il cluster mostri lo stato Pronto.

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 eseguirai il deployment dell'operatore Confluent for Kubernetes (CFK) utilizzando un grafico Helm, quindi eseguirai il deployment di un cluster Kafka.

1. Aggiungi il repository di grafici Confluent Helm:

   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 abilitare CFK a gestire le risorse in tutti gli spazi dei nomi, aggiungi il parametro --set-namespaced=false al comando Helm.

4. Verifica che il deployment dell'operatore Confluent sia stato eseguito 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 eseguirai il deployment di Kafka in una configurazione di base e quindi proverai 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 necessarie 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.
• Java MaxHeapSize e MinHeapSize impostato su 4 GB per Kafka.
• Allocazione delle risorse della CPU di 1 richiesta di CPU e 2 limiti di 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 allocato a ogni pod utilizzando il valore di storageClass premium-rwo, 100 per i dati Kafka e 90/10 per i dati/log di Zookeeper.
• Tolleranze, 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.
• Comunicazione all'interno del cluster protetta da certificati autofirmati mediante un'autorità di certificazione fornita da te.

Questa configurazione rappresenta la configurazione minima richiesta per creare un cluster Kafka pronto per la produzione. Le seguenti sezioni mostrano configurazioni personalizzate per affrontare 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 per 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 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 di blocco, incompatibilità 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 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 ZooKeeper.
• Due risorse PodDisruptionBudget, garantendo 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. Tutti gli ascoltatori Kafka interni sono disponibili in questo servizio.
• Il servizio zookeeper, che consente ai broker Kafka di connettersi ai nodi di ZooKeeper come client.

Autenticazione e gestione utenti

Questa sezione mostra come abilitare l'autenticazione e l'autorizzazione per proteggere i listener Kafka e condividere le credenziali con i client.

Confluent per Kubernetes supporta vari metodi di autenticazione per Kafka, tra cui:

• Autenticazione SASL/PLAIN: i client utilizzano un nome utente e una password per l'autenticazione. Il nome utente e la password sono memorizzati sul lato server in un secret di 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 nei secret e fare riferimento ai secret nelle specifiche dei listener.
• Anche se non esiste una risorsa personalizzata per gestire direttamente gli ACL, il sito Confluent for Kubernetes ufficiale fornisce indicazioni su come configurare gli ACL utilizzando l'interfaccia a riga di comando di 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
• A KafkaTopiccon 3 repliche
• Credenziali utente con autorizzazioni di lettura e scrittura

1. Crea un secret con 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 per l'utilizzo di un listener con autenticazione basata su password SCRAM-SHA-512 dell'autenticazione 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 di 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.

4. Quando il pod client è pronto, connettiti al pod e inizia a produrre e utilizzare 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 di my-user, quindi utilizza il messaggio 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 il processo del consumatore. Se viene visualizzato 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 in fase di backup.
• Volumi che corrispondono alle risorse PersistentVolumeClaim trovate nei manifest.

Per ulteriori informazioni su come eseguire il backup e ripristinare i cluster Kafka utilizzando Backup per GKE, consulta Prepararsi per il ripristino di emergenza.

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

• La configurazione Kafka, che include tutte le risorse personalizzate dell'API Confluent come KafkaTopicsoConnect
• I dati, che vengono archiviati negli oggetti PersistentVolume 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 Kafka, poiché le risorse possono essere applicate nuovamente a un nuovo cluster Kubernetes quando necessario.

Per salvaguardare il recupero dei dati di Kafka in situazioni in cui viene persa un'istanza del server Kafka, o il cluster Kubernetes in cui è stato eseguito il deployment di Kafka, ti consigliamo di configurare la classe di archiviazione di Kubernetes utilizzata per il provisioning dei volumi per i broker Kafka con l'opzione reclaimPolicy impostata su Retain. Ti consigliamo inoltre di acquisire istantanee dei volumi dei broker Kafka.

Il seguente manifest descrive un oggetto 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 l'oggetto StorageClass aggiunto a spec di una risorsa personalizzata del cluster Kafka:

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

Con questa configurazione, gli oggetti PersistentVolume di cui è stato eseguito il provisioning utilizzando la classe di archiviazione non vengono eliminati anche quando viene eliminato l'oggetto PersistentVolumeClaim corrispondente.

Per recuperare l'istanza Kafka su un nuovo cluster Kubernetes utilizzando i dati dell'istanza di configurazione e broker esistenti:

1. Applica le risorse personalizzate Confluent esistenti (Kafka, KafkaTopic, Zookeeper e così via) a un nuovo cluster Kubernetes
2. Aggiorna gli oggetti PersistentVolumeClaim con i nomi delle nuove istanze del broker Kafka ai vecchi oggetti PersistentVolume utilizzando la proprietà spec.volumeName nell'oggetto 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

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

• L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività in questo documento, quando lo elimini elimini anche qualsiasi altro lavoro svolto nel progetto.
• Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

Elimina un progetto Google Cloud:

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 le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.