La guida mostra come utilizzare l'operatore Strimzi per eseguire il deployment dei cluster Apache Kafka.
Kafka è un sistema di messaggistica distribuito open source, progettato per gestire volumi di dati elevati, velocità effettiva elevata e flussi di dati in tempo reale. Consente di creare pipeline di dati in modalità flusso per un trasferimento affidabile di dati tra diversi sistemi e applicazioni, per supportare le attività di elaborazione e analisi.
Gli operatori sono estensioni software che utilizzano risorse personalizzate per gestire le applicazioni e i loro componenti. Per ulteriori informazioni sulla motivazione per l'utilizzo degli operatori, consulta Pattern operatore nella documentazione open source di Kubernetes. L'operatore di Strimzi offre flessibilità nelle opzioni di deployment e consente di utilizzare incompatibilità e tolleranze di Kubernetes per eseguire Kafka su nodi dedicati.
Questa guida è rivolta agli amministratori di piattaforma, ai Cloud Architect e ai professionisti operativi interessati al deployment dei cluster Kafka su GKE.
Questa soluzione è un buon punto di partenza se vuoi imparare a eseguire il deployment dei cluster Kafka utilizzando un operatore di terze parti per automatizzare la gestione e ridurre gli errori. Se preferisci un controllo operativo più granulare, consulta Deployment di cluster Kafka ad alta disponibilità su GKE.
Obiettivi
- Pianifica ed esegui il deployment dell'infrastruttura GKE per Apache Kafka
- Deployment e configurazione dell'operatore Strimzi
- Configurare Apache Kafka utilizzando l'operatore Strimzi
Vantaggi
Strimzi offre i seguenti vantaggi:
- Gli operatori di Strimzi forniscono un approccio semplificato e nativo di Kubernetes alla gestione dei cluster Kafka. Strimzi utilizza risorse personalizzate che rappresentano argomenti e utenti Kafka, rendendo la gestione dei cluster molto più semplice e allineata alle best practice di Kubernetes.
- Strimzi dà priorità alla sicurezza per impostazione predefinita 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, così non dovrai preoccuparti di usare 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, chiamati broker, che collaborano per gestire i flussi di dati in entrata e facilitano la messaggistica pubblica-sottoscritta per i client Kafka, detti consumer.
A ogni partizione dei dati all'interno del cluster Kafka viene assegnato un leader broker, che è responsabile della gestione di tutte le operazioni di lettura e scrittura su quella partizione. La partizione può anche avere uno o più broker follower che replicano 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 fluido in caso di problemi.
Puoi anche eseguire il deployment della configurazione 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 per le risorse KafkaTopic, l'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 per il 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 nodi possano prendere il controllo delle attività, evitando tempi di inattività e interruzioni del servizio.
- Scalabilità: l'utilizzo di più nodi assicura che la scalabilità orizzontale possa aggiungere o rimuovere nodi secondo necessità, garantendo un'allocazione ottimale delle risorse e facendo fronte a un aumento del traffico o delle esigenze dei carichi 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 single point of failure. Se si verifica un'interruzione in un'intera zona di disponibilità, il cluster può continuare a essere eseguito in altre zone, mantenendo la disponibilità del servizio.
- Ridondanza geografica: coprendo i nodi tra le 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 influire su una singola zona.
- Aggiornamenti e manutenzione in sequenza: l'utilizzo di più zone assicura che gli aggiornamenti e la manutenzione in sequenza possano essere eseguiti su singoli nodi senza influire sulla disponibilità complessiva del cluster. Ciò garantisce un servizio continuo, consentendo al contempo l'applicazione senza interruzioni degli aggiornamenti e delle patch necessari.
- Accordi sul livello del servizio (SLA): Google Cloud fornisce SLA (accordi sul livello del servizio) 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, il deployment di Kafka StrimziPodSet
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 StrimziPodSet
.
Se una zona si guasta, 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 StrimziPodSet
di ZooKeeper eseguito su tre nodi 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 scalabilità avanzata per il cluster e
consentono di passare le opzioni di configurazione, consentendoti di 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 vengono utilizzati i seguenti componenti fatturabili di Google Cloud:
Per generare una stima dei costi basata sull'utilizzo previsto,
utilizza il Calcolatore prezzi.
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
- 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.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
Create or select a Google Cloud project.
-
Create a Google Cloud project:
gcloud projects create PROJECT_ID
Replace
PROJECT_ID
with a name for the Google Cloud project you are creating. -
Select the Google Cloud project that you created:
gcloud config set project PROJECT_ID
Replace
PROJECT_ID
with your Google Cloud project name.
-
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
Abilita le API Compute Engine, IAM, GKE, Backup for GKE, and Resource Manager.
gcloud services enable compute.googleapis.com
iam.googleapis.com container.googleapis.com gkebackup.googleapis.com cloudresourcemanager.googleapis.com - Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
Create or select a Google Cloud project.
-
Create a Google Cloud project:
gcloud projects create PROJECT_ID
Replace
PROJECT_ID
with a name for the Google Cloud project you are creating. -
Select the Google Cloud project that you created:
gcloud config set project PROJECT_ID
Replace
PROJECT_ID
with your Google Cloud project name.
-
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
Abilita le API Compute Engine, IAM, GKE, Backup for GKE, and Resource Manager.
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_IDENTIFIER" --role=ROLE
- Replace
PROJECT_ID
with your project ID. -
Replace
USER_IDENTIFIER
with the identifier for your user account. For example,user:[email protected]
. - Replace
ROLE
with each individual role.
- Replace
Prepara l'ambiente
In questo tutorial utilizzerai Cloud Shell per gestire le risorse ospitate su Google Cloud. Cloud Shell è preinstallato con il software necessario per questo tutorial, inclusi kubectl
, gcloud CLI, Helm e Terraform.
Per configurare il tuo ambiente con Cloud Shell, segui questi passaggi:
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.
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 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 il completamento di questo 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 strimzi-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 il completamento di questo 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 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, eseguirai il deployment dell'operatore Strimzi utilizzando un grafico Helm. Esistono anche diversi altri modi per implementare Strimzi.
Aggiungi il repository di grafici Strimzi Helm:
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 cluster Strimzi Cluster Operator e Kafka in spazi dei nomi diversi, aggiungi il parametro
--set watchNamespaces="{kafka-namespace,kafka-namespace-2,...}"
al comando helm.Verifica che il deployment dell'operatore cluster Strimzi sia stato eseguito 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 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 Strimzi.
- Java MaxHeapSize e MinHeapSize impostato su 4 GB per Kafka e 2 GB per ZooKeeper.
- Allocazione delle risorse della CPU pari a 1 richiesta di CPU e 2 limiti di CPU sia per Kafka che 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 di CPU e 128 Mi di memoria.topicOperator
: CPU da 100 m/500 m e memoria da 512 Mi.userOperator
: 500 m di CPU e 2 Gi di memoria.
- 100 GB di spazio di archiviazione allocato a ogni pod utilizzando
premium-rwo
storageClass
. - 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: autorità di certificazione (CA) separate per cluster e client (mTLS). Puoi anche configurare l'utilizzo di un'autorità di certificazione diversa.
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
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 Kafka personalizzata dell'operatore Strimzi che include richieste e limiti di CPU e memoria, richieste di archiviazione a blocchi e una combinazione di incompatibilità 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 ZooKeeper.
- Due
PodDisruptionBudgets
, garantendo 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 i listener Kafka interni sono disponibili in questo servizio. - Un servizio headless denominato
my-cluster-kafka-brokers
che consente la risoluzione DNS direttamente degli indirizzi IP dei pod del broker Kafka. Questo servizio viene utilizzato per le comunicazioni 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 direttamente degli indirizzi IP dei pod di ZooKeeper. Questo servizio viene utilizzato per la connessione tra repliche ZooKeeper. - Un deployment denominato
my-cluster-entity-operator
che contiene l'operatore dell'argomento e l'operatore dell'utente e facilita la gestione delle risorse personalizzateKafkaTopics
eKafkaUsers
.
Puoi anche configurare due NetworkPolicies
per facilitare la connettività ai listener Kafka da qualsiasi pod e spazio dei nomi. Questi criteri limitano anche le connessioni a ZooKeeper ai broker e consentono la comunicazione tra i pod del cluster e le porte interne del servizio esclusive per la comunicazione del cluster.
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.
Strimzi fornisce un metodo nativo di Kubernetes per la gestione degli utenti utilizzando un elemento User Operator
separato e la corrispondente risorsa personalizzata Kubernetes, KafkaUser
, che definisce la configurazione dell'utente. La configurazione utente include le impostazioni di autenticazione e autorizzazione ed esegue il provisioning dell'utente corrispondente in Kafka.
Strimzi può creare listener 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'uso di password o certificati per l'autenticazione per motivi di sicurezza e della gestione delle credenziali esterne.
Esegui il deployment di un cluster Kafka
Questa sezione mostra come eseguire il deployment di un operatore Strimzi che dimostra le capacità di gestione degli utenti, tra cui:
- Un cluster Kafka con autenticazione basata su password (SCRAM-SHA-512) abilitata su uno dei listener.
- 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 tuo cluster Kafka per utilizzare un listener 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
Topic
,User
e un pod client per eseguire i 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
my-user
Secret
con le credenziali utente viene montato sul pod client sotto forma di volume.Queste credenziali confermano che l'utente dispone delle autorizzazioni per pubblicare messaggi nell'argomento utilizzando il listener con l'autenticazione basata su password (SCRAM-SHA-512) abilitata.
Crea un pod client:
kubectl apply -n kafka -f kafka-strimzi/manifests/03-auth/kafkacat.yaml
Attendi qualche minuto che 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 di
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 di 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 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 il backup di un cluster Kafka di cui è stato eseguito il deployment utilizzando l'operatore Strimzi. Devi eseguire il backup di:
- La configurazione Kafka, che include tutte le risorse personalizzate dell'API
Strimzi come
KafkaTopics
eKafkaUsers
. - Dati archiviati nei PersistentVolume dei broker Kafka.
L'archiviazione dei manifest delle risorse Kubernetes, incluse le configurazioni di Strimzi, nei repository Git può eliminare la necessità di un backup separato per la configurazione Kafka, poiché le risorse possono essere riapplicate a un nuovo cluster Kubernetes quando 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 viene eseguito il deployment di 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 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:
kafka:
# ...
storage:
type: persistent-claim
size: 100Gi
class: 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:
- Applica le risorse personalizzate Strimzi Kafka esistenti (
Kakfa
,KafkaTopic
,KafkaUser
e così via) a un nuovo cluster Kubernetes - 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
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.
Imposta le variabili di ambiente.
export PROJECT_ID=${PROJECT_ID} export KUBERNETES_CLUSTER_PREFIX=kafka export REGION=us-central1
Esegui il comando
terraform destroy
:export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token) terraform -chdir=kafka/terraform/FOLDER destroy -var project_id=${PROJECT_ID} \ -var region=${REGION} \ -var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}
Sostituisci
FOLDER
congke-autopilot
ogke-standard
.Quando richiesto, digita
yes
.Trova tutti i dischi scollegati:
export disk_list=$(gcloud compute disks list --filter="-users:* AND labels.name=${KUBERNETES_CLUSTER_PREFIX}-cluster" --format "value[separator=|](name,zone)")
Questo passaggio è necessario perché, per impostazione predefinita Strimzi utilizza il parametro
deleteClaim: false
per l'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 le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.