Questa pagina è stata tradotta dall'API Cloud Translation.

Esegui il deployment di un cluster Kafka a disponibilità elevata su GKE

Autopilota Standard

Kafka è un sistema di messaggistica distribuito open source di tipo publish-subscribe per la gestione di dati in streaming in tempo reale di elevato volume e con un'elevata velocità in transito. Puoi usare Kafka per creare pipeline di dati in modalità flusso che trasferiscono i dati in modo affidabile tra diversi sistemi applicazioni per l'elaborazione e l'analisi.

Questo tutorial è destinato agli amministratori di piattaforma, ai cloud architect e professionisti delle operazioni interessati al deployment di Kafka a disponibilità elevata cluster su Google Kubernetes Engine (GKE).

Obiettivi

In questo tutorial imparerai a:

Utilizzare Terraform per creare un cluster GKE a livello di regione.
Esegui il deployment di un cluster Kafka a disponibilità elevata.
Eseguire l'upgrade dei programmi binari Kafka.
Esegui il backup e il ripristino del cluster Kafka.
Simula l'interruzione dei nodi GKE e il failover del broker Kafka.

Architettura

Questa sezione descrive l'architettura della soluzione che creerai in questo durante il tutorial.

Un cluster Kafka è un gruppo di uno o più server (chiamati broker) che lavorano insieme per gestire i flussi di dati in entrata e la messaggistica publish-subscribe per i client Kafka (chiamati consumer).

Ogni partizione di dati in un cluster Kafka ha un broker leader e può avere uno o più follower broker. Il broker leader gestisce tutte le letture e le scritture sul della partizione di testo. Ogni broker follower replica passivamente il broker leader.

In una tipica configurazione Kafka, usi anche un servizio open source chiamato ZooKeeper per coordinare Kafka cluster. Questo servizio consente di eleggere un leader tra i broker e di attivare il failover in caso di errori.

In questo tutorial eseguirai il deployment dei cluster Kafka su GKE configurando i broker Kafka e il servizio Zookeeper come singoli StatefulSets: Per eseguire il provisioning di cluster Kafka ad alta disponibilità e prepararti al disaster recovery, configurerai i StatefulSet di Kafka e Zookeeper in modo da utilizzare pool di nodi e zone distinti.

Il seguente diagramma mostra come il StatefulSet Kafka viene eseguito su più nodi e zone nel cluster GKE.

Il diagramma mostra un'architettura di esempio di un StatefulSet Kafka su GKE di cui è stato eseguito il deployment in più zone. — **Figura 1**: deployment di uno StatefulSet Kafka su nodi GKE in tre zone diverse.

Il seguente diagramma mostra come viene eseguito Zookeeper StatefulSet più nodi e zone nel tuo cluster GKE.

Il diagramma mostra un'architettura di esempio di uno Zookeeper StatefulSet su GKE di cui è stato eseguito il deployment in più zone. — **Figura 2**: dispiegamento di Zookeeper di Kafka sui nodi GKE in tre zone diverse.

Provisioning dei nodi e pianificazione dei pod

Se utilizzi i cluster Autopilot, Autopilot gestisce il provisioning dei nodi e la pianificazione dei pod per i tuoi carichi di lavoro. Utilizzerai l'anti-affinità dei pod per assicurarti che nessun altro pod dello stesso StatefulSet sia pianificato sullo stesso nodo e nella stessa zona.

Se utilizzi cluster Standard, devi configurare il pod tolleranza e dell'affinità nodo. Per saperne di più, consulta Isolare i carichi di lavoro in pool di nodi dedicati.

Costi

In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi basata sull'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

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

Configura il progetto

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.

In the Google Cloud console, on the project selector page, click Create project to begin creating a new Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the Google Kubernetes Engine, Backup for GKE, Artifact Registry, Compute Engine, and IAM APIs.

Enable the APIs

In the Google Cloud console, on the project selector page, click Create project to begin creating a new Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the Google Kubernetes Engine, Backup for GKE, Artifact Registry, Compute Engine, and IAM APIs.

Enable the APIs

Configurare i ruoli

Grant roles to your user account. Run the following command once for each of the following IAM roles: role/storage.objectViewer, role/logging.logWriter, role/artifactregistry.Admin, 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.

Configura l'ambiente

In questo tutorial utilizzerai Cloud Shell per gestire le risorse ospitate in Google Cloud. Cloud Shell è preinstallato con il software necessario per questo tutorial, tra cui Docker, kubectl, gcloud CLI, Helm e Terraform.

Per configurare l'ambiente con Cloud Shell:

Avvia una sessione di Cloud Shell dalla console Google Cloud. clic su Attiva Cloud Shell nella console Google Cloud. Verrà avviata una sessione nel riquadro inferiore della console Google Cloud.
Imposta le variabili di ambiente.
```
export PROJECT_ID=PROJECT_ID
export REGION=us-central1
```
Sostituisci i seguenti valori:
- PROJECT_ID: il tuo ID progetto Google Cloud.
Imposta le variabili di ambiente predefinite.
```
gcloud config set project PROJECT_ID
```

Clona il repository di codice.

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

Passa alla directory di lavoro.

cd kubernetes-engine-samples/streaming/gke-stateful-kafka

Crea l'infrastruttura del tuo cluster

In questa sezione, eseguirai uno script Terraform per creare due cluster GKE a livello di regione. Il deployment del cluster principale verrà eseguito in us-central1.

Per creare il cluster:

Autopilot

In Cloud Shell, esegui questi comandi:

terraform -chdir=terraform/gke-autopilot init
terraform -chdir=terraform/gke-autopilot apply -var project_id=$PROJECT_ID

Quando richiesto, digita yes.

Standard

In Cloud Shell, esegui questi comandi:

terraform -chdir=terraform/gke-standard init
terraform -chdir=terraform/gke-standard apply -var project_id=$PROJECT_ID

Quando richiesto, digita yes.

I file di configurazione Terraform creano le seguenti risorse per eseguire il deployment dell'infrastruttura:

Creare un repository Artifact Registry per archiviare le immagini Docker.
Crea la rete VPC e la subnet per all'interfaccia di rete della VM.
Crea due cluster GKE.

Terraform crea un cluster privato nelle due regioni. abilita Backup per GKE per il ripristino di emergenza.

Esegui il deployment di Kafka sul tuo cluster

In questa sezione eseguirai il deployment di Kafka su GKE utilizzando una Grafico Helm. L'operazione crea le seguenti risorse:

Gli StatefulSet Kafka e Zookeeper.
Un esportatore Kafka e deployment continuo. L'esportatore raccoglie le metriche di Kafka per il consumo di Prometheus.
Un budget per l'interruzione dei pod (PDB) che limita il numero di pod offline durante un'interruzione volontaria.

Per utilizzare il grafico Helm per eseguire il deployment di Kafka:

Configurare l'accesso a Docker.

gcloud auth configure-docker us-docker.pkg.dev

Compila Artifact Registry con le immagini Kafka e Zookeeper.

./scripts/gcr.sh bitnami/kafka 3.3.2-debian-11-r0
./scripts/gcr.sh bitnami/kafka-exporter 1.6.0-debian-11-r52
./scripts/gcr.sh bitnami/jmx-exporter 0.17.2-debian-11-r41
./scripts/gcr.sh bitnami/zookeeper 3.8.0-debian-11-r74

Configura l'accesso alla riga di comando kubectl al cluster principale.

gcloud container clusters get-credentials gke-kafka-us-central1 \
    --region=${REGION} \
    --project=${PROJECT_ID}

Crea uno spazio dei nomi.

export NAMESPACE=kafka
kubectl create namespace $NAMESPACE

Installa Kafka utilizzando la versione 20.0.6 del grafico Helm.

cd helm
../scripts/chart.sh kafka 20.0.6 && \
rm -rf Chart.lock charts && \
helm dependency update && \
helm -n kafka upgrade --install kafka . \
--set global.imageRegistry="us-docker.pkg.dev/$PROJECT_ID/main"

L'output è simile al seguente:

NAME: kafka
LAST DEPLOYED: Thu Feb 16 03:29:39 2023
NAMESPACE: kafka
STATUS: deployed
REVISION: 1
TEST SUITE: None

Verifica che le tue repliche Kafka siano in esecuzione (l'operazione potrebbe richiedere alcuni minuti).

kubectl get all -n kafka

L'output è simile al seguente:

---
NAME                    READY   STATUS    RESTARTS        AGE
pod/kafka-0             1/1     Running   2 (3m51s ago)   4m28s
pod/kafka-1             1/1     Running   3 (3m41s ago)   4m28s
pod/kafka-2             1/1     Running   2 (3m57s ago)   4m28s
pod/kafka-zookeeper-0   1/1     Running   0               4m28s
pod/kafka-zookeeper-1   1/1     Running   0               4m28s
pod/kafka-zookeeper-2   1/1     Running   0               4m28s

NAME                                   TYPE        CLUSTER-IP        EXTERNAL-IP   PORT(S)                      AGE
service/kafka                          ClusterIP   192.168.112.124   <none>        9092/TCP                     4m29s
service/kafka-app                      ClusterIP   192.168.75.57     <none>        9092/TCP                     35m
service/kafka-app-headless             ClusterIP   None              <none>        9092/TCP,9093/TCP            35m
service/kafka-app-zookeeper            ClusterIP   192.168.117.102   <none>        2181/TCP,2888/TCP,3888/TCP   35m
service/kafka-app-zookeeper-headless   ClusterIP   None              <none>        2181/TCP,2888/TCP,3888/TCP   35m
service/kafka-headless                 ClusterIP   None              <none>        9092/TCP,9093/TCP            4m29s
service/kafka-zookeeper                ClusterIP   192.168.89.249    <none>        2181/TCP,2888/TCP,3888/TCP   4m29s
service/kafka-zookeeper-headless       ClusterIP   None              <none>        2181/TCP,2888/TCP,3888/TCP   4m29s

NAME                               READY   AGE
statefulset.apps/kafka             3/3     4m29s
statefulset.apps/kafka-zookeeper   3/3     4m29s

Creare dati di test

In questa sezione testerai l'applicazione Kafka e genererai messaggi.

Creare un pod client consumer per interagire con l'applicazione Kafka.

kubectl run kafka-client -n kafka --rm -ti \
    --image us-docker.pkg.dev/$PROJECT_ID/main/bitnami/kafka:3.3.2-debian-11-r0 -- bash

Crea un argomento denominato topic1 con tre partizioni e un fattore di replica di tre.

kafka-topics.sh \
    --create \
    --topic topic1 \
    --partitions 3  \
    --replication-factor 3 \
    --bootstrap-server kafka-headless.kafka.svc.cluster.local:9092

Verifica che le partizioni degli argomenti siano replicate su tutti e tre i broker.

kafka-topics.sh \
    --describe \
    --topic topic1 \
    --bootstrap-server kafka-headless.kafka.svc.cluster.local:9092

L'output è simile al seguente:

Topic: topic1     TopicId: 1ntc4WiFS4-AUNlpr9hCmg PartitionCount: 3       ReplicationFactor: 3    Configs: flush.ms=1000,segment.bytes=1073741824,flush.messages=10000,max.message.bytes=1000012,retention.bytes=1073741824
       Topic: topic1    Partition: 0    Leader: 2       Replicas: 2,0,1 Isr: 2,0,1
       Topic: topic1    Partition: 1    Leader: 1       Replicas: 1,2,0 Isr: 1,2,0
       Topic: topic1    Partition: 2    Leader: 0       Replicas: 0,1,2 Isr: 0,1,2

Nell'output di esempio, nota che topic1 ha tre partizioni, ognuna con un leader e un insieme di repliche diversi. Questo perché Kafka utilizza la suddivisione in parti per distribuire i dati su più broker, consentendo una maggiore scalabilità e tolleranza di errore. Il fattore di replica pari a tre garantisce che ogni partizione abbia tre repliche, in modo che i dati siano ancora disponibili anche se uno o due broker non funzionano.

Esegui il seguente comando per generare collettivamente i numeri di messaggio in topic1.

ALLOW_PLAINTEXT_LISTENER=yes
for x in $(seq 0 200); do
  echo "$x: Message number $x"
done | kafka-console-producer.sh \
    --topic topic1 \
    --bootstrap-server kafka-headless.kafka.svc.cluster.local:9092 \
    --property parse.key=true \
    --property key.separator=":"

Esegui questo comando per utilizzare topic1 da tutte le partizioni.

kafka-console-consumer.sh \
    --bootstrap-server kafka.kafka.svc.cluster.local:9092 \
    --topic topic1 \
    --property print.key=true \
    --property key.separator=" : " \
    --from-beginning;

Digita CTRL+C per interrompere il processo consumer.

Benchmark Kafka

Per creare un modello accurato di un caso d'uso, puoi eseguire una simulazione del carico previsto sul cluster. Per testare il rendimento, utilizzerai gli strumenti inclusi nel pacchetto Kafka, ovvero gli script kafka-producer-perf-test.sh e kafka-consumer-perf-test.sh nella cartella bin.

Crea un argomento per il benchmarking.

kafka-topics.sh \
  --create \
  --topic topic-benchmark \
  --partitions 3  \
  --replication-factor 3 \
  --bootstrap-server kafka-headless.kafka.svc.cluster.local:9092

Creare un carico sul cluster Kafka.

KAFKA_HEAP_OPTS="-Xms4g -Xmx4g" kafka-producer-perf-test.sh \
    --topic topic-benchmark \
    --num-records 10000000 \
    --throughput -1 \
    --producer-props bootstrap.servers=kafka.kafka.svc.cluster.local:9092 \
          batch.size=16384 \
          acks=all \
          linger.ms=500 \
          compression.type=none \
    --record-size 100 \
    --print-metrics

Il produttore genererà 10.000.000 di record il giorno topic-benchmark. L'output è simile al seguente:

623821 records sent, 124316.7 records/sec (11.86 MB/sec), 1232.7 ms avg latency, 1787.0 ms max latency.
1235948 records sent, 247140.2 records/sec (23.57 MB/sec), 1253.0 ms avg latency, 1587.0 ms max latency.
1838898 records sent, 367779.6 records/sec (35.07 MB/sec), 793.6 ms avg latency, 1185.0 ms max latency.
2319456 records sent, 463242.7 records/sec (44.18 MB/sec), 54.0 ms avg latency, 321.0 ms max latency.

Una volta inviati tutti i record, dovresti vedere altre metriche nella simile al seguente:

producer-topic-metrics:record-send-rate:{client-id=perf-producer-client, topic=topic-benchmark}     : 173316.233
producer-topic-metrics:record-send-total:{client-id=perf-producer-client, topic=topic-benchmark}    : 10000000.000

Per uscire dallo smartwatch, digita CTRL + C.

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

Gestire gli upgrade

Gli aggiornamenti delle versioni per Kafka e Kubernetes vengono rilasciati regolarmente programmazione. Segui le best practice operative per eseguire regolarmente l'upgrade del tuo ambiente software.

Pianifica gli upgrade binari di Kafka

In questa sezione aggiornerai l'immagine Kafka utilizzando Helm e verificherai che i temi siano ancora disponibili.

Per eseguire l'upgrade dalla versione precedente di Kafka da del grafico Helm che hai utilizzato in Eseguire il deployment di Kafka nel tuo cluster, segui questi passaggi:

Completa Artifact Registry con l'immagine seguente:

../scripts/gcr.sh bitnami/kafka 3.4.0-debian-11-r2
../scripts/gcr.sh bitnami/kafka-exporter 1.6.0-debian-11-r61
../scripts/gcr.sh bitnami/jmx-exporter 0.17.2-debian-11-r49
../scripts/gcr.sh bitnami/zookeeper 3.8.1-debian-11-r0

Esegui questi passaggi per eseguire il deployment di un grafico Helm con le immagini Kafka e Zookeeper di cui è stato eseguito l'upgrade. Per indicazioni specifiche per la versione, consulta le istruzioni di Kafka per gli upgrade della versione.
1. Aggiorna la versione della dipendenza Chart.yaml:
```
../scripts/chart.sh kafka 20.1.0
```
1. Esegui il deployment del grafico Helm con le nuove immagini Kafka e Zookeeper, come mostrato nell'esempio seguente:
```
rm -rf Chart.lock charts && \
helm dependency update && \
helm -n kafka upgrade --install kafka ./ \
      --set global.imageRegistry="$REGION-docker.pkg.dev/$PROJECT_ID/main"
```
Guarda l'upgrade dei pod Kafka:
```
kubectl get pod -l app.kubernetes.io/component=kafka -n kafka --watch
```
Per uscire dallo smartwatch, digita CTRL + C.

Connettiti al cluster Kafka utilizzando un pod client.

kubectl run kafka-client -n kafka --rm -ti \
  --image us-docker.pkg.dev/$PROJECT_ID/main/bitnami/kafka:3.4.0-debian-11-r2 -- bash

Verifica di poter accedere ai messaggi da topic1.
```
kafka-console-consumer.sh \
  --topic topic1 \
  --from-beginning \
  --bootstrap-server kafka-headless.kafka.svc.cluster.local:9092
```
L'output dovrebbe mostrare i messaggi generati dalla precedente passaggio. Digita CTRL+C per uscire dal processo.
Esci dal pod del client.
```
exit
```

Preparati per il ripristino di emergenza

Per assicurarti che i carichi di lavoro di produzione rimangano disponibili in caso di un evento che interrompa il servizio, devi preparare un piano di ripristino di emergenza (RE). Per saperne di più sulla pianificazione di RE, consulta Guida alla pianificazione del ripristino di emergenza.

Per eseguire il backup e il ripristino dei carichi di lavoro sui cluster GKE, puoi utilizzare Backup per GKE.

Scenario di esempio di backup e ripristino di Kafka

In questa sezione verrà eseguito un backup del cluster da gke-kafka-us-central1 e ripristina il backup in gke-kafka-us-west1. Eseguirai il backup e ripristinare l'operazione nell'ambito dell'applicazione, utilizzando ProtectedApplication risorsa personalizzata.

Il seguente diagramma illustra i componenti della soluzione di disaster recovery e la loro interazione.

Il diagramma mostra un esempio di soluzione di backup e ripristino per un cluster Kafka ad alta disponibilità. — **Figura 3**: soluzione di backup e ripristino di esempio per un cluster Kafka a disponibilità elevata.

Per prepararti a eseguire il backup e il ripristino del cluster Kafka:

Configura le variabili di ambiente.

export BACKUP_PLAN_NAME=kafka-protected-app
export BACKUP_NAME=protected-app-backup-1
export RESTORE_PLAN_NAME=kafka-protected-app
export RESTORE_NAME=protected-app-restore-1
export REGION=us-central1
export DR_REGION=us-west1
export CLUSTER_NAME=gke-kafka-$REGION
export DR_CLUSTER_NAME=gke-kafka-$DR_REGION

Verifica che il cluster sia in uno stato RUNNING.
```
gcloud container clusters describe $CLUSTER_NAME --region us-central1 --format='value(status)'
```
Nota: prima di poter creare un backup, il cluster deve essere in stato RUNNING.

Crea un piano di backup.

gcloud beta container backup-restore backup-plans create $BACKUP_PLAN_NAME \
    --project=$PROJECT_ID \
    --location=$DR_REGION \
    --cluster=projects/$PROJECT_ID/locations/$REGION/clusters/$CLUSTER_NAME \
    --selected-applications=kafka/kafka,kafka/zookeeper \
    --include-secrets \
    --include-volume-data \
    --cron-schedule="0 3 * * *" \
    --backup-retain-days=7 \
    --backup-delete-lock-days=0

Creare manualmente un backup. Sebbene i backup pianificati siano generalmente regolati cron-schedule nel piano di backup, l'esempio seguente mostra come puoi avvia un'operazione di backup una tantum.

gcloud beta container backup-restore backups create $BACKUP_NAME \
    --project=$PROJECT_ID \
    --location=$DR_REGION \
    --backup-plan=$BACKUP_PLAN_NAME \
    --wait-for-completion

Crea un piano di ripristino.

gcloud beta container backup-restore restore-plans create $RESTORE_PLAN_NAME \
    --project=$PROJECT_ID \
    --location=$DR_REGION \
    --backup-plan=projects/$PROJECT_ID/locations/$DR_REGION/backupPlans/$BACKUP_PLAN_NAME \
    --cluster=projects/$PROJECT_ID/locations/$DR_REGION/clusters/$DR_CLUSTER_NAME \
    --cluster-resource-conflict-policy=use-existing-version \
    --namespaced-resource-restore-mode=delete-and-restore \
    --volume-data-restore-policy=restore-volume-data-from-backup \
    --selected-applications=kafka/kafka,kafka/zookeeper \
    --cluster-resource-scope-selected-group-kinds="storage.k8s.io/StorageClass"

Ripristina manualmente da un backup.

gcloud beta container backup-restore restores create $RESTORE_NAME \
    --project=$PROJECT_ID \
    --location=$DR_REGION \
    --restore-plan=$RESTORE_PLAN_NAME \
    --backup=projects/$PROJECT_ID/locations/$DR_REGION/backupPlans/$BACKUP_PLAN_NAME/backups/$BACKUP_NAME

Osserva l'applicazione ripristinata come visualizzata nel cluster di backup. Potrebbero essere necessari alcuni minuti prima che tutti i pod siano in esecuzione e pronti.
```
gcloud container clusters get-credentials gke-kafka-us-west1 \
    --region us-west1
kubectl get pod -n kafka --watch
```
Digita CTRL+C per uscire dallo smartwatch quando tutti i pod sono attivi e funzionanti.

Verifica che gli argomenti precedenti possano essere recuperati da un consumatore.

kubectl run kafka-client -n kafka --rm -ti \
    --image us-docker.pkg.dev/$PROJECT_ID/main/bitnami/kafka:3.4.0 -- bash

kafka-console-consumer.sh \
    --bootstrap-server kafka.kafka.svc.cluster.local:9092 \
    --topic topic1 \
    --property print.key=true \
    --property key.separator=" : " \
    --from-beginning;

L'output è simile al seguente:

192 :  Message number 192
193 :  Message number 193
197 :  Message number 197
200 :  Message number 200
Processed a total of 201 messages

Digita CTRL+C per uscire dalla procedura.

Esci dal pod.
```
exit
```

Simula un'interruzione del servizio Kafka

In questa sezione simulerai un errore del nodo sostituendo un nodo Kubernetes che ospita il broker. Questa sezione si applica solo a Standard. Autopilot gestisce i nodi per te, pertanto non è possibile simulare l'errore dei nodi.

Creare un pod client per connettersi all'applicazione Kafka.

kubectl run kafka-client -n kafka --restart='Never' -it \
--image us-docker.pkg.dev/$PROJECT_ID/main/bitnami/kafka:3.4.0 -- bash

Crea l'argomento topic-failover-test e genera traffico di prova.

kafka-topics.sh \
  --create \
  --topic topic-failover-test \
  --partitions 1  \
  --replication-factor 3  \
  --bootstrap-server kafka-headless.kafka.svc.cluster.local:9092

Determina quale broker è il leader per l'argomento topic-failover-test.

kafka-topics.sh --describe \
  --topic topic-failover-test \
  --bootstrap-server kafka-headless.kafka.svc.cluster.local:9092

L'output è simile al seguente:

Topic: topic-failover-test     Partition: 0    Leader: 1       Replicas: 1,0,2 Isr: 1,0,2

Nell'output riportato sopra, Leader: 1 indica che il leader per topic-failover-test è il broker 1. Corrisponde al pod kafka-1.

Apri un nuovo terminale e connettiti allo stesso cluster.

gcloud container clusters get-credentials gke-kafka-us-west1 --region us-west1 --project PROJECT_ID

Trova il nodo su cui è in esecuzione il pod kafka-1.

kubectl get pod -n kafka kafka-1 -o wide

L'output è simile al seguente:

NAME      READY   STATUS    RESTARTS      AGE   IP              NODE                                               NOMINATED NODE   READINESS GATES
kafka-1   2/2     Running   1 (35m ago)   36m   192.168.132.4   gke-gke-kafka-us-west1-pool-system-a0d0d395-nx72   <none>           <none>

Nell'output riportato sopra, puoi vedere che il pod kafka-1 è in esecuzione sul nodo gke-gke-kafka-us-west1-pool-system-a0d0d395-nx72.

Svuota il nodo per rimuovere i pod.

kubectl drain NODE \
  --delete-emptydir-data \
  --force \
  --ignore-daemonsets

Sostituisci NODE con il pod di nodo su cui è in esecuzione kafka-1. In questo esempio, il nodo è gke-gke-kafka-us-west1-pool-system-a0d0d395-nx72.

L'output è simile al seguente:

node/gke-gke-kafka-us-west1-pool-system-a0d0d395-nx72 cordoned
Warning: ignoring DaemonSet-managed Pods: gmp-system/collector-gjzsd, kube-system/calico-node-t28bj, kube-system/fluentbit-gke-lxpft, kube-system/gke-metadata-server-kxw78, kube-system/ip-masq-agent-kv2sq, kube-system/netd-h446k, kube-system/pdcsi-node-ql578
evicting pod kafka/kafka-1
evicting pod kube-system/kube-dns-7d48cb57b-j4d8f
evicting pod kube-system/calico-typha-56995c8d85-5clph
pod/calico-typha-56995c8d85-5clph evicted
pod/kafka-1 evicted
pod/kube-dns-7d48cb57b-j4d8f evicted
node/gke-gke-kafka-us-west1-pool-system-a0d0d395-nx72 drained

Trova il nodo su cui è in esecuzione il pod kafka-1.

kubectl get pod -n kafka kafka-1 -o wide

L'output dovrebbe essere simile al seguente:

NAME      READY   STATUS    RESTARTS   AGE     IP              NODE                                              NOMINATED NODE   READINESS GATES
kafka-1   2/2     Running   0          2m49s   192.168.128.8   gke-gke-kafka-us-west1-pool-kafka-700d8e8d-05f7   <none>           <none>

Dall'output precedente, puoi vedere che l'applicazione è in esecuzione su un nuovo nodo.

Nel terminale collegato al pod kafka-client, determina quale broker è il leader per topic-failover-test.

kafka-topics.sh --describe \
  --topic topic-failover-test \
  --bootstrap-server kafka-headless.kafka.svc.cluster.local:9092

L'output dovrebbe essere simile al seguente:

Topic: topic-failover-test     TopicId: bemKyqmERAuKZC5ymFwsWg PartitionCount: 1       ReplicationFactor: 3    Configs: flush.ms=1000,segment.bytes=1073741824,flush.messages=10000,max.message.bytes=1000012,retention.bytes=1073741824
    Topic: topic-failover-test     Partition: 0    Leader: 1       Replicas: 1,0,2 Isr: 0,2,1

Nell'output di esempio, il leader è ancora 1. Tuttavia, ora è in esecuzione un nuovo nodo.

Test dell'errore del leader Kafka

In Cloud Shell, connettiti al client Kafka e utilizza describe per visualizzare il leader eletto per ogni partizione in topic1.

kafka-topics.sh --describe \
  --topic topic1 \
  --bootstrap-server kafka-headless.kafka.svc.cluster.local:9092

L'output è simile al seguente:

Topic: topic1   TopicId: B3Jr_5t2SPq7F1jVHu4r0g PartitionCount: 3       ReplicationFactor: 3    Configs: flush.ms=1000,segment.bytes=1073741824,flush.messages=10000,max.message.bytes=1000012,retention.bytes=1073741824
    Topic: topic1   Partition: 0    Leader: 0       Replicas: 0,2,1 Isr: 0,2,1
    Topic: topic1   Partition: 1    Leader: 0       Replicas: 2,1,0 Isr: 0,2,1
    Topic: topic1   Partition: 2    Leader: 0       Replicas: 1,0,2 Isr: 0,2,1

In Cloud Shell non connesso al client Kafka, elimina il broker leader kafka-0 per forzare l'elezione di un nuovo leader. Dovresti eliminare l'indice mappato a uno dei responsabili nell'output precedente.
```
kubectl delete pod -n kafka kafka-0 --force
```
L'output è simile al seguente:
```
pod "kafka-0" force deleted
```

In Cloud Shell, connettiti al client Kafka e utilizza describe per visualizzare il leader eletto.

kafka-topics.sh --describe \
  --topic topic1 \
  --bootstrap-server kafka-headless.kafka.svc.cluster.local:9092

L'output è simile al seguente:

Topic: topic1   TopicId: B3Jr_5t2SPq7F1jVHu4r0g PartitionCount: 3       ReplicationFactor: 3    Configs: flush.ms=1000,segment.bytes=1073741824,flush.messages=10000,max.message.bytes=1000012,retention.bytes=1073741824
    Topic: topic1   Partition: 0    Leader: 2       Replicas: 0,1,2 Isr: 2,0,1
    Topic: topic1   Partition: 1    Leader: 2       Replicas: 2,0,1 Isr: 2,0,1
    Topic: topic1   Partition: 2    Leader: 2       Replicas: 1,2,0 Isr: 2,0,1

Nell'output, il nuovo leader per ogni partizione cambia, se è stato assegnato al leader interrotto (kafka-0). Ciò indica che il leader originale è stato sostituito quando il pod è stato eliminato e ricreato.

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

Il modo più semplice per evitare la fatturazione è eliminare il progetto per cui nel tutorial.

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 appspot.com URL, 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

Passaggi successivi

Per un servizio di messaggistica completamente gestito e scalabile, vedi Eseguire la migrazione da Kafka a Pub/Sub.