Questa pagina è stata tradotta dall'API Cloud Translation.

Esegui il deployment di Apache Kafka in GKE utilizzando Strimzi

Autopilot Standard

La guida illustra come utilizzare l'operatore Strimzi per eseguire il deployment di cluster Apache Kafka.

Kafka è un sistema di messaggistica distribuito open source progettato per gestire dati in streaming in tempo reale di elevato volume e con un'elevata velocità in uscita. Consente di creare pipeline di dati in modalità flusso per trasferire dati in modo affidabile tra diversi sistemi e applicazioni, al fine di supportare le attività di elaborazione e analisi.

Gli operatori sono estensioni software che utilizzano risorse personalizzate per gestire le applicazioni e i relativi componenti. Per saperne di più sul motivo per cui utilizzare gli operatori, consulta Pattern di operatori nella documentazione di Kubernetes open source. L'operatore Strimzi offre flessibilità nelle opzioni di deployment e ti consente di utilizzare le contaminazioni e le tolleranze di Kubernetes per eseguire Kafka su nodi dedicati.

Questa guida è rivolta ad amministratori della piattaforma, architetti cloud e professionisti delle operazioni interessati a eseguire il deployment di cluster Kafka su GKE.

Questa soluzione è un buon punto di partenza se vuoi scoprire come eseguire il deployment di cluster Kafka utilizzando un operatore di terze parti per automatizzare la gestione e ridurre gli errori. Se preferisci un controllo operativo più granulare, consulta Esegui il deployment di un cluster Kafka ad alta disponibilità su GKE.

Obiettivi

Pianifica ed esegui il deployment dell'infrastruttura GKE per Apache Kafka
Esegui il deployment e configura l'operatore Strimzi
Configura Apache Kafka utilizzando l'operatore Strimzi

Vantaggi

Strimzi offre i seguenti vantaggi:

Gli operatori Strimzi forniscono un approccio semplificato e nativo di Kubernetes per la gestione dei cluster Kafka. Strimzi utilizza risorse personalizzate che rappresentano argomenti e utenti Kafka, semplificando notevolmente la gestione del cluster e allineandola alle best practice di Kubernetes.
Per impostazione predefinita, Strimzi dà la priorità alla sicurezza generando certificati per gli ascoltatori e supportando metodi di autenticazione sicuri come TLS, SCRAM-SHA e OAuth. Strimzi gestisce anche NetworkPolicies per tutti gli ascoltatori Kafka.
Strimzi non si basa su dipendenze esterne. Include cluster Kafka e ZooKeeper con esportatori di metriche integrati, che ti consentono di gestire strumenti aggiuntivi. Puoi anche perfezionare le configurazioni dei broker per soddisfare requisiti specifici.

Architettura di deployment

Un cluster Kafka è costituito da uno o più server, noti come broker, che collaborano per gestire i flussi di dati in entrata e semplificare la messaggistica Pub/Sub per i client Kafka, denominati consumer.

A ogni partizione di dati all'interno del cluster Kafka è assegnato un broker leader, responsabile della gestione di tutte le operazioni di lettura e scrittura nella partizione. La partizione può anche avere uno o più broker follower che riproducono passivamente le azioni del broker leader.

In una configurazione tipica, ZooKeeper coordina i cluster Kafka aiutando a scegliere un leader tra i broker e garantendo un failover regolare in caso di problemi.

Puoi anche eseguire il deployment della configurazione di Kafka senza Zookeeper attivando la modalità KRaft, ma questo metodo non è considerato pronto per la produzione dalla community di Strimzi perché non include il supporto delle risorse KafkaTopic, dell'autenticazione delle credenziali e altro ancora.

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.

L'utilizzo di più nodi e zone è fondamentale per ottenere un cluster Kubernetes ad alta disponibilità in Google Cloud per i seguenti motivi:

Tolleranza agli errori: più nodi distribuiscono il carico di lavoro nel cluster, garantendo che, in caso di errore di un nodo, gli altri possano assumere il controllo delle attività, evitando tempi di inattività e interruzioni del servizio.
Scalabilità: l'utilizzo di più nodi garantisce che la scalabilità orizzontale possa aggiungere o rimuovere i nodi in base alle esigenze, garantendo un'allocazione ottimale delle risorse e adattandosi all'aumento del traffico o delle richieste del carico di lavoro.
Alta disponibilità: l'utilizzo di più zone all'interno di una regione garantisce la ridondanza e riduce al minimo il rischio di un singolo punto di défaillance. Se un'intera zona di disponibilità presenta un'interruzione, il cluster può continuare a funzionare in altre zone, mantenendo la disponibilità del servizio.
Ridondanza geografica: poiché i nodi si estendono su più regioni, i dati e i servizi del cluster sono distribuiti geograficamente, offrendo resilienza contro calamità naturali, interruzioni di corrente o altre interruzioni locali che potrebbero interessare una singola zona.
Aggiornamenti e manutenzione incrementali: l'utilizzo di più zone consente di eseguire aggiornamenti e manutenzione incrementali sui singoli nodi senza influire sulla disponibilità complessiva del cluster. Ciò garantisce un servizio continuo, consentendo al contempo di applicare senza problemi gli aggiornamenti e le patch necessari.
Accordi sul livello del servizio (SLA): Google Cloud fornisce SLA per i deployment multizona, garantendo un livello minimo di uptime e disponibilità.

Diagramma di deployment

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

Nel diagramma, Kafka StrimziPodSet 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 StrimziPodSet.

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 StrimziPodSet di cui è stato eseguito il deployment su tre node in tre zone diverse:

La risorsa personalizzata `StrimziPodSet`

Questo tutorial utilizza la risorsa personalizzata StrimziPodSet introdotta nella versione 0.29 di Strimzi anziché StatefulSets.

Le risorse StrimziPodSet offrono una scalabilità migliorata per il cluster e consentono di passare le opzioni di configurazione, in modo da apportare modifiche più granulari ai pod. La risorsa StrimziPodSet è abilitata per impostazione predefinita nelle versioni di Strimzi 0.35 e successive.

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. I nuovi Google Cloud utenti potrebbero avere diritto a una prova gratuita.

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

Note: If you installed the gcloud CLI previously, make sure you have the latest version by running

gcloud components
      update

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 Compute Engine, IAM, GKE, Backup for GKE, 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

Note: If you installed the gcloud CLI previously, make sure you have the latest version by running

gcloud components
      update

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 Compute Engine, IAM, GKE, Backup for GKE, 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: roles/storage.objectViewer, roles/logging.logWriter, roles/container.clusterAdmin, roles/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.

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 strimzi-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 strimzi-cluster --region us-central1"

Connessione 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 Strimzi nel cluster

In questa sezione esegui il deployment dell'operatore Strimzi utilizzando un grafico Helm. Esistono anche diversi altri modi per eseguire il deployment di Strimzi.

Aggiungi il repository del grafico Helm Strimzi:

helm repo add strimzi https://strimzi.io/charts/

Aggiungi uno spazio dei nomi per l'operatore Strimzi e il cluster Kafka:
```
kubectl create ns kafka
```
Esegui il deployment dell'operatore di cluster Strimzi utilizzando Helm:
```
helm install strimzi-operator strimzi/strimzi-kafka-operator -n kafka
```
Per eseguire il deployment di Strimzi Cluster Operator e dei cluster Kafka in diversi spazi dei nomi, aggiungi il parametro --set watchNamespaces="{kafka-namespace,kafka-namespace-2,...}" al comando helm.

Verifica che l'operatore di cluster Strimzi sia stato disegnato correttamente utilizzando Helm:

helm ls -n kafka

L'output è simile al seguente:

NAME            NAMESPACE    REVISION    UPDATED                              STATUS    CHART                        APP VERSION
strimzi-operator    kafka      1       2023-06-27 11:22:15.850545 +0200 CEST    deployed    strimzi-kafka-operator-0.35.0    0.35.0

Esegui il deployment di Kafka

Dopo aver eseguito il deployment dell'operatore nel cluster, puoi eseguire il deployment di un'istanza del cluster 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 Strimzi.
MaxHeapSize e MinHeapSize di Java impostati su 4 GB per Kafka e 2 GB per ZooKeeper.
Alloca risorse CPU di 1 richiesta CPU e 2 limiti CPU sia per Kafka sia per ZooKeeper, oltre a 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 2,5 GB per ZooKeeper (2 GB per il servizio principale e 0,5 GB per l'esportatore di metriche).
Operatore di entità con le seguenti richieste e limiti:
- tlsSidecar: 100 m/500 m CPU e 128 Mi di memoria.
- topicOperator: 100 m/500 m CPU e 512 Mi di memoria.
- userOperator: 500 m CPU e 2 Gi di memoria.
100 GB di spazio di archiviazione allocati a ogni pod utilizzando premium-rwo storageClass.
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.
Comunicazione all'interno del cluster protetta da certificati autofirmati: autorità di certificazione (CA) distinte per il cluster e i client (mTLS). Puoi anche configurare l'utilizzo di un'altra autorità di certificazione.

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

Crea un nuovo cluster Kafka utilizzando la configurazione di base:
```
kubectl apply -n kafka -f kafka-strimzi/manifests/01-basic-cluster/my-cluster.yaml
```
Questo comando crea una risorsa personalizzata Kafka dell'operatore Strimzi che include richieste e limiti di CPU e memoria, richieste di archiviazione dei blocchi e una combinazione di 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 kafka/my-cluster --for=condition=Ready --timeout=600s -n kafka

Verifica che i carichi di lavoro Kafka siano stati creati:

kubectl get pod,service,deploy,pdb -l=strimzi.io/cluster=my-cluster -n kafka

L'output è simile al seguente:

NAME                                            READY   STATUS  RESTARTS   AGE
pod/my-cluster-entity-operator-848698874f-j5m7f   3/3   Running   0        44m
pod/my-cluster-kafka-0                          1/1   Running   0        5m
pod/my-cluster-kafka-1                          1/1   Running   0        5m
pod/my-cluster-kafka-2                          1/1   Running   0        5m
pod/my-cluster-zookeeper-0                      1/1   Running   0        6m
pod/my-cluster-zookeeper-1                      1/1   Running   0        6m
pod/my-cluster-zookeeper-2                      1/1   Running   0        6m

NAME                                TYPE      CLUSTER-IP   EXTERNAL-IP   PORT(S)                             AGE
service/my-cluster-kafka-bootstrap  ClusterIP   10.52.8.80   <none>      9091/TCP,9092/TCP,9093/TCP          5m
service/my-cluster-kafka-brokers    ClusterIP   None         <none>      9090/TCP,9091/TCP,9092/TCP,9093/TCP   5m
service/my-cluster-zookeeper-client   ClusterIP   10.52.11.144   <none>      2181/TCP                            6m
service/my-cluster-zookeeper-nodes  ClusterIP   None         <none>      2181/TCP,2888/TCP,3888/TCP          6m

NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/my-cluster-entity-operator   1/1   1          1         44m

NAME                                            MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
poddisruptionbudget.policy/my-cluster-kafka     2             N/A             1                   5m
poddisruptionbudget.policy/my-cluster-zookeeper   2             N/A             1                   6m

L'operatore crea le seguenti risorse:

Due StrimziPodSets per Kafka e ZooKeeper.
Tre pod per le repliche del broker Kafka.
Tre pod per le repliche di ZooKeeper.
Due PodDisruptionBudgets, per garantire una disponibilità minima di due repliche per la coerenza del cluster.
Un servizio denominato my-cluster-kafka-bootstrap, 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.
Un servizio headless denominato my-cluster-kafka-brokers che consente la risoluzione DNS degli indirizzi IP dei pod del broker Kafka direttamente. Questo servizio viene utilizzato per la comunicazione tra broker.
Un servizio denominato my-cluster-zookeeper-client che consente ai broker Kafka di connettersi ai nodi ZooKeeper come client.
Un servizio headless denominato my-cluster-zookeeper-nodes che consente la risoluzione DNS degli indirizzi IP dei pod ZooKeeper direttamente. Questo servizio viene utilizzato per collegare le repliche di ZooKeeper.
Un deployment denominato my-cluster-entity-operator che contiene operatore-argomento e operatore-utente e semplifica la gestione delle risorse personalizzate KafkaTopics e KafkaUsers.

Puoi anche configurare due NetworkPolicies per semplificare la connettività ai listener Kafka da qualsiasi pod e spazio dei nomi. Inoltre, questi criteri limiterebbero le connessioni a ZooKeeper ai broker e attiverebbero la comunicazione tra i pod del cluster e le porte di servizio interne esclusivamente per la comunicazione del cluster.

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.

Strimzi fornisce un metodo nativo di Kubernetes per la gestione degli utenti utilizzando un User Operator separato e la relativa risorsa personalizzata Kubernetes, KafkaUser, che definisce la configurazione dell'utente. La configurazione utente include le impostazioni per l'autenticazione e l'autorizzazione e esegue il provisioning dell'utente corrispondente in Kafka.

Strimzi può creare ascoltatori e utenti Kafka che supportano diversi meccanismi di autenticazione come l'autenticazione basata su nome utente e password (SCRAM-SHA-512) o TLS. Puoi anche utilizzare l'autenticazione OAuth 2.0, che è spesso considerata un approccio migliore rispetto all'utilizzo di password o certificati per l'autenticazione per motivi di sicurezza e gestione delle credenziali esterne.

Esegui il deployment di un cluster Kafka

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

Un cluster Kafka con autenticazione basata su password (SCRAM-SHA-512) attivata su uno degli ascoltatori.
Un KafkaTopic con 3 repliche.
Un KafkaUser con un ACL che specifica che l'utente dispone delle autorizzazioni di lettura e scrittura per l'argomento.

Configura il cluster Kafka in modo da utilizzare un ascoltatore con autenticazione SCRAM-SHA-512 basata su password sulla porta 9094 e autorizzazione semplice:
```
kubectl apply -n kafka -f kafka-strimzi/manifests/03-auth/my-cluster.yaml
```
Crea un Topic, un User e un pod client per eseguire comandi sul cluster Kafka:
```
kubectl apply -n kafka -f kafka-strimzi/manifests/03-auth/topic.yaml
kubectl apply -n kafka -f kafka-strimzi/manifests/03-auth/my-user.yaml
```
Il file Secret my-user con le credenziali utente viene montato sul pod client come volume.

Queste credenziali confermano che l'utente dispone delle autorizzazioni per pubblicare messaggi nell'argomento utilizzando l'ascoltatore con l'autenticazione basata su password attivata (SCRAM-SHA-512).

Crea un pod client:

kubectl apply -n kafka -f kafka-strimzi/manifests/03-auth/kafkacat.yaml

Attendi qualche minuto affinché il pod client diventi Ready, quindi connettiti:

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

Crea un nuovo messaggio con le credenziali my-user e prova a utilizzarlo:

echo "Message from my-user" |kcat \
  -b my-cluster-kafka-bootstrap.kafka.svc.cluster.local:9094 \
  -X security.protocol=SASL_SSL \
  -X sasl.mechanisms=SCRAM-SHA-512 \
  -X sasl.username=my-user \
  -X sasl.password=$(cat /my-user/password) \
  -t my-topic -P
kcat -b my-cluster-kafka-bootstrap.kafka.svc.cluster.local:9094 \
  -X security.protocol=SASL_SSL \
  -X sasl.mechanisms=SCRAM-SHA-512 \
  -X sasl.username=my-user \
  -X sasl.password=$(cat /my-user/password) \
  -t my-topic -C

L'output è simile al seguente:

Message from my-user
% Reached end of topic my-topic [0] at offset 0
% Reached end of topic my-topic [2] at offset 1
% Reached end of topic my-topic [1] at offset 0

Digita CTRL+C per interrompere il processo del consumatore.

Esci dalla shell del pod
```
exit
```

Backup e ripristino di emergenza

Sebbene l'operatore Strimzi non offra funzionalità di backup integrate, 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 Strimzi 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 il backup di un cluster Kafka di cui è stato eseguito il deployment utilizzando l'operatore Strimzi. Dovresti eseguire il backup di:

La configurazione di Kafka, che include tutte le risorse personalizzate dell'API Strimzi, come KafkaTopicse KafkaUsers.
I dati archiviati nei volumi permanenti dei broker Kafka.

La memorizzazione dei manifest delle risorse Kubernetes, incluse le configurazioni di Strimzi, nei repository Git può eliminare la necessità di un backup separato per la configurazione di Kafka, perché 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 è dipiegato 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 consigliamo inoltre 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:
  kafka:
    # ...
    storage:
      type: persistent-claim
      size: 100Gi
      class: 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 relativo PersistentVolumeClaim.

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 Kafka di Strimzi esistenti (Kakfa, KafkaTopic, KafkaUser 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

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à descritte in questo documento, quando lo elimini elimini anche tutto il 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, il riuso dei progetti può aiutarti a non superare i limiti di quota.

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 con gke-autopilot o gke-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)")
```
Questo passaggio è necessario perché, per impostazione predefinita, Strimzi utilizza il parametro deleteClaim: false per lo spazio di archiviazione. Se elimini il cluster, tutti i dischi rimangono disponibili.

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.

Esegui il deployment di Apache Kafka in GKE utilizzando Strimzi

Obiettivi

Vantaggi

Architettura di deployment

Disponibilità e ripristino di emergenza

Diagramma di deployment

La risorsa personalizzata StrimziPodSet

Costi

Prima di iniziare

Prepara l'ambiente

Crea l'infrastruttura del cluster

Standard

Autopilot

Connessione al cluster

Esegui il deployment dell'operatore Strimzi nel cluster

Esegui il deployment di Kafka

Configurazione di base

Crea un cluster Kafka di base

Autenticazione e gestione degli utenti

Esegui il deployment di un cluster Kafka

Backup e ripristino di emergenza

Esegui la pulizia

Elimina il progetto

Elimina le singole risorse

Passaggi successivi

La risorsa personalizzata `StrimziPodSet`