Déployer Apache Kafka sur GKE à l'aide de Strimzi

Le guide vous explique comment utiliser l'opérateur Strimzi pour déployer des clusters Apache Kafka.

Kafka est un système de messagerie Open Source distribué conçu pour gérer des données en streaming à volume élevé, à haut débit et en temps réel. Il vous permet de créer des pipelines de données en streaming pour garantir un transfert des données fiable entre différents systèmes et applications afin de faciliter les tâches de traitement et d'analyse.

Les opérateurs sont des extensions logicielles qui utilisent des ressources personnalisées pour gérer les applications et leurs composants. Pour en savoir plus sur les raisons d'utiliser les opérateurs, consultez la section Modèle d'opérateur dans la documentation Open Source Kubernetes. L'opérateur Strimzi offre une grande flexibilité dans le choix des options et vous permet d'utiliser des rejets et des tolérances Kubernetes pour exécuter Kafka sur des nœuds dédiés.

Ce guide est destiné aux administrateurs de plate-forme, aux architectes cloud et aux professionnels des opérations qui souhaitent déployer des clusters Kafka sur GKE.

Cette solution est un bon point de départ si vous souhaitez apprendre à déployer des clusters Kafka à l'aide d'un opérateur tiers pour automatiser la gestion et réduire les erreurs. Si vous préférez un contrôle opérationnel plus précis, consultez la page Déployer un cluster Kafka à disponibilité élevée sur GKE.

Objectifs

  • Planifier et déployer l'infrastructure GKE pour Apache Kafka
  • Déployer et configurer l'opérateur Strimzi
  • Configurer Apache Kafka à l'aide de l'opérateur Strimzi

Avantages

Strimzi offre les avantages suivants :

  • Les opérateurs Strimzi fournissent une approche simplifiée et native à Kubernetes pour gérer les clusters Kafka. Strimzi utilise des ressources personnalisées qui représentent des sujets et des utilisateurs Kafka, ce qui simplifie considérablement la gestion des clusters et est conforme aux bonnes pratiques Kubernetes.
  • Strimzi donne la priorité à la sécurité par défaut en générant des certificats pour les écouteurs et en acceptant les méthodes d'authentification sécurisées telles que TLS, SCRAM-SHA et OAuth. Strimzi gère également les NetworkPolicies pour tous les écouteurs Kafka.
  • Strimzi ne repose pas sur des dépendances externes. Il comprend les clusters Kafka et ZooKeeper avec des exportateurs de métriques intégrés, ce qui vous évite d'avoir à gérer des outils supplémentaires. Vous pouvez également ajuster les configurations d'agent pour répondre à des exigences spécifiques.

Architecture de déploiement

Un cluster Kafka comprend un ou plusieurs serveurs, appelés agents, qui collaborent à la gestion des flux de données entrants et facilitent la messagerie Pub/Sub pour les clients Kafka, également appelés consommateurs.

Chaque partition de données du cluster Kafka se voit attribuer un agent responsable chargé de gérer toutes les opérations de lecture et d'écriture sur cette partition. La partition peut également comporter un ou plusieurs agents subordonnés qui répliquent passivement les actions de l'agent responsable.

Dans une configuration type, ZooKeeper coordonne les clusters Kafka en aidant à choisir un responsable chez les agents et en assurant un basculement fluide en cas de problème.

Vous pouvez également déployer la configuration Kafka sans Zookeeper en activant le mode KRaft. Cette méthode n'est toutefois pas considérée comme prête pour la production par la communauté Strimzi, car elle ne prend pas en charge les ressources KafkaTopic, l'authentification des identifiants et d'autres fonctionnalités.

Disponibilité et reprise après sinistre

Dans ce tutoriel, nous utilisons des pools de nœuds et des zones distincts pour les clusters Kafka et ZooKeeper afin de garantir la haute disponibilité et de préparer la reprise après sinistre.

L'utilisation de plusieurs nœuds et zones est essentielle pour obtenir un cluster Kubernetes à haute disponibilité dans Google Cloud, pour les raisons suivantes :

  • Tolérance aux pannes : plusieurs nœuds répartissent la charge de travail sur le cluster. Ainsi, en cas de défaillance d'un nœud, les autres nœuds peuvent prendre le relais, ce qui évite les temps d'arrêt et les interruptions de service.
  • Évolutivité : l'utilisation de plusieurs nœuds garantit que le scaling horizontal peut ajouter ou supprimer des nœuds selon les besoins, ce qui garantit une allocation optimale des ressources et permet d'augmenter le trafic ou les demandes.
  • Haute disponibilité : l'utilisation de plusieurs zones au sein d'une région garantit la redondance et réduit le risque de point de défaillance unique. Si toute une zone de disponibilité subit une défaillance, le cluster peut continuer à s'exécuter dans d'autres zones et maintenir la disponibilité du service.
  • Redondance géographique : en répartissant des nœuds entre les régions, les données et les services du cluster sont répartis géographiquement, ce qui permet de résister aux catastrophes naturelles, aux pannes de courant ou à d'autres perturbations locales susceptibles d'affecter une seule zone.
  • Mises à jour progressives et maintenance : l'utilisation de plusieurs zones permet de s'assurer que les mises à jour progressives et la maintenance peuvent être effectuées sur des nœuds individuels sans affecter la disponibilité globale du cluster. Cela garantit un service continu tout en permettant l'application transparente des mises à jour et des correctifs.
  • Contrats de niveau de service (SLA) : Google Cloud fournit, pour les déploiements multizones, des contrats de niveau de service qui garantissent un niveau minimal de temps d'activité et de disponibilité.

Schéma de déploiement

Le schéma suivant montre un cluster Kafka s'exécutant sur plusieurs nœuds et zones dans un cluster GKE :

Dans le schéma, le StrimziPodSet Kafka est déployé sur trois nœuds dans trois zones différentes. Vous pouvez contrôler cette configuration en définissant les règles d'affinité des pods et de répartition de topologie requises sur la spécification de ressources personnalisées StrimziPodSet.

En cas de défaillance d'une zone, à l'aide de la configuration recommandée, GKE replanifie les pods sur les nouveaux nœuds et réplique les données des instances dupliquées restantes pour Kafka et Zookeeper.

Le schéma suivant montre un StrimziPodSet ZooKeeper déployé sur trois nœuds dans trois zones différentes :

Ressource personnalisée StrimziPodSet

Ce tutoriel utilise la ressource personnalisée StrimziPodSet introduite dans la version 0.29 de Strimzi, en lieu et place de StatefulSets.

Les ressources StrimziPodSet offrent une évolutivité améliorée pour le cluster et vous permettent de transmettre des options de configuration, ce qui vous permet d'apporter des modifications plus précises aux pods. La ressource StrimziPodSet est activée par défaut dans les versions 0.35 et ultérieures de Strimzi.

Coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Une fois que vous avez terminé les tâches décrites dans ce document, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Avant de commencer

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
  2. Install the Google Cloud CLI.

  3. To initialize the gcloud CLI, run the following command: 

    gcloud init

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

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

  6. 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
  7. Install the Google Cloud CLI.

  8. To initialize the gcloud CLI, run the following command: 

    gcloud init

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

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

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

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

Préparer l'environnement

Dans ce tutoriel, vous utilisez Cloud Shell pour gérer les ressources hébergées sur Google Cloud. Les logiciels dont vous avez besoin pour ce tutoriel sont préinstallés sur Cloud Shell, y compris kubectl, gcloud CLI, Helm et Terraform.

Pour configurer votre environnement avec Cloud Shell, procédez comme suit :

  1. Lancez une session Cloud Shell depuis la console Google Cloud en cliquant sur Icône d'activation Cloud Shell Activer Cloud Shell dans la console Google Cloud. Une session s'ouvre dans le volet inférieur de la console Google Cloud.

  2. Définissez les variables d'environnement :

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

    Remplacez PROJECT_ID par votre ID de projet Google Cloud.

  3. Clonez le dépôt GitHub.

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

  4. Accédez au répertoire de travail :

    cd kubernetes-engine-samples/streaming/

Créer l'infrastructure de votre cluster

Dans cette section, vous allez exécuter un script Terraform pour créer un cluster GKE régional, privé et à disponibilité élevée. Les étapes suivantes autorisent l'accès public au plan de contrôle. Pour restreindre l'accès, créez un cluster privé.

Vous pouvez installer l'opérateur à l'aide d'un cluster standard ou Autopilot.

Standard

Le schéma suivant présente un cluster GKE standard régional privé déployé sur trois zones différentes :

Pour déployer cette infrastructure, exécutez les commandes suivantes à partir de 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}

Lorsque vous y êtes invité, saisissez yes. L'exécution de cette commande et le passage du cluster à l'état prêt peuvent prendre plusieurs minutes.

Terraform crée les ressources suivantes :

  • Un réseau VPC et un sous-réseau privé pour les nœuds Kubernetes.
  • Un routeur pour accéder à Internet via NAT.
  • Un cluster GKE privé dans la région us-central1.
  • Deux pools de nœuds avec l'autoscaling activé (1 à 2 nœuds par zone, 1 nœud par zone au minimum).
  • Un ServiceAccount avec les autorisations de journalisation et de surveillance.
  • Sauvegarde pour GKE pour la reprise après sinistre.
  • Google Cloud Managed Service pour Prometheus pour la surveillance du cluster.

Le résultat ressemble à ce qui suit :

...
Apply complete! Resources: 14 added, 0 changed, 0 destroyed.

Outputs:

kubectl_connection_command = "gcloud container clusters get-credentials strimzi-cluster --region us-central1"

Autopilot

Le schéma suivant présente un cluster GKE Autopilot régional privé :

Pour déployer l'infrastructure, exécutez les commandes suivantes à partir de 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}

Lorsque vous y êtes invité, saisissez yes. L'exécution de cette commande et le passage du cluster à l'état prêt peuvent prendre plusieurs minutes.

Terraform crée les ressources suivantes :

  • Un réseau VPC et un sous-réseau privé pour les nœuds Kubernetes.
  • Un routeur pour accéder à Internet via NAT.
  • Un cluster GKE privé dans la région us-central1.
  • Un ServiceAccount avec les autorisations de journalisation et de surveillance.
  • Google Cloud Managed Service pour Prometheus pour la surveillance du cluster.

Le résultat ressemble à ce qui suit :

...
Apply complete! Resources: 12 added, 0 changed, 0 destroyed.

Outputs:

kubectl_connection_command = "gcloud container clusters get-credentials strimzi-cluster --region us-central1"

Se connecter au cluster

Configurez kubectl pour communiquer avec le cluster :

gcloud container clusters get-credentials ${KUBERNETES_CLUSTER_PREFIX}-cluster --region ${REGION}

Déployer l'opérateur Strimzi sur votre cluster

Dans cette section, vous allez déployer l'opérateur Strimzi à l'aide d'un chart Helm. Il existe également plusieurs autres méthodes de déploiement de Strimzi.

  1. Ajoutez le dépôt du chart Helm Strimzi :

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

  2. Ajoutez un espace de noms pour l'opérateur Strimzi et le cluster Kafka :

    kubectl create ns kafka

  3. Déployez l'opérateur de cluster Strimzi à l'aide de Helm :

    helm install strimzi-operator strimzi/strimzi-kafka-operator -n kafka

    Pour déployer l'opérateur de cluster Strimzi et les clusters Kafka dans différents espaces de noms, ajoutez le paramètre --set watchNamespaces="{kafka-namespace,kafka-namespace-2,...}" à la commande Helm.

  4. Vérifiez que l'opérateur de cluster Strimzi a bien été déployé à l'aide de Helm :

    helm ls -n kafka

    Le résultat ressemble à ce qui suit :

    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

Déployer Kafka

Une fois l'opérateur déployé sur le cluster, vous êtes prêt à déployer une instance de cluster Kafka.

Dans cette section, vous allez déployer Kafka dans une configuration de base puis tester divers scénarios de configuration avancés pour répondre aux exigences de disponibilité, de sécurité et d'observabilité.

Configuration de base

La configuration de base de l'instance Kafka comprend les composants suivants :

  • Trois instances dupliquées des agents Kafka, avec au moins deux instances dupliquées disponibles pour la cohérence de cluster.
  • Trois instances dupliquées des nœuds ZooKeeper, formant un cluster.
  • Deux écouteurs Kafka : l'un sans authentification et l'autre utilisant l'authentification TLS avec un certificat généré par Strimzi.
  • Java MaxHeapSize et MaxHeapSize définis sur 4 Go pour Kafka et 2 Go pour ZooKeeper.
  • Allocation de ressources de processeur de 1 requête de processeur et 2 limites de processeur pour Kafka et ZooKeeper, ainsi que 5 Go de mémoire pour les requêtes et limites Kafka (4 Go pour le service principal et 0,5 Go pour l'exportateur de métriques) et 2,5 Go pour ZooKeeper (2 Go pour le service principal et 0,5 Go pour l'exportateur de métriques).
  • Entity-operator avec les requêtes et limites suivantes :
    • tlsSidecar : processeur 100 m/500 m et mémoire 128 Mi.
    • topicOperator : processeur 100 m/500 m et mémoire 512 Mi.
    • userOperator : processeur 500 m et mémoire 2 Gi.
  • 100 Go d'espace de stockage alloué à chaque pod à l'aide de la storageClass premium-rwo.
  • Les tolérances, nodeAffinities et podAntiAffinities configurées pour chaque charge de travail afin de garantir une répartition appropriée des nœuds, en utilisant leurs pools de nœuds respectifs et des zones différentes.
  • Communication au sein du cluster sécurisée par des certificats autosignés : autorités de certification (CA) distinctes pour le cluster et les clients (mTLS). Vous pouvez également configurer une autre autorité de certification.

Cette configuration représente la configuration minimale requise pour créer un cluster Kafka prêt pour la production. Les sections suivantes présentent des configurations personnalisées pour des aspects tels que la sécurité des clusters, les listes de contrôle d'accès (LCA), la gestion des sujets, la gestion des certificats, etc…

Créer un cluster Kafka de base

  1. Créez un cluster Kafka en utilisant la configuration de base :

    kubectl apply -n kafka -f kafka-strimzi/manifests/01-basic-cluster/my-cluster.yaml

    Cette commande crée une ressource Kafka personnalisée de l'opérateur Strimzi qui inclut les demandes et limites de processeurs et de mémoire, les requêtes de stockage de blocs, et une combinaison de rejets et d'affinités pour répartir les pods provisionnés sur les nœuds Kubernetes.

  2. Attendez quelques minutes pendant que Kubernetes démarre les charges de travail requises :

    kubectl wait kafka/my-cluster --for=condition=Ready --timeout=600s -n kafka

  3. Vérifiez que les charges de travail Kafka ont bien été créées :

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

    Le résultat ressemble à ce qui suit :

    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'opérateur crée les ressources suivantes :

  • Deux StrimziPodSets pour Kafka et ZooKeeper.
  • Trois pods pour les instances dupliquées d'agents Kafka.
  • Trois pods pour les instances dupliquées ZooKeeper.
  • Deux PodDisruptionBudgets afin de garantir une disponibilité minimale de deux instances dupliquées pour la cohérence du cluster.
  • Un service nommé my-cluster-kafka-bootstrap, qui sert de serveur d'amorçage pour les clients Kafka se connectant à partir du cluster Kubernetes. Tous les écouteurs Kafka internes sont disponibles dans ce service.
  • Un service sans interface graphique nommé my-cluster-kafka-brokers qui active la résolution DNS directe des adresses IP des pods de l'agent Kafka. Ce service est utilisé pour les communications entre agents.
  • Un service nommé my-cluster-zookeeper-client qui permet aux agents Kafka de se connecter aux nœuds ZooKeeper en tant que clients.
  • Un service sans interface graphique nommé my-cluster-zookeeper-nodes qui active la résolution DNS directe des adresses IP des pods ZooKeeper Ce service permet de créer une connexion entre instances dupliquées ZooKeeper.
  • Un déploiement nommé my-cluster-entity-operator contenant topic-operator et user-operator et facilitant la gestion des ressources personnalisées KafkaTopics et KafkaUsers.

Vous pouvez également configurer deux NetworkPolicies pour faciliter la connectivité aux écouteurs Kafka à partir de n'importe quel pod et espace de noms. Ces règles limitent également les connexions à ZooKeeper aux agents et permettent la communication entre les pods de cluster et les ports de service internes exclusifs à la communication de cluster.

Authentification et gestion des utilisateurs

Cette section explique comment activer l'authentification et l'autorisation pour sécuriser les écouteurs Kafka et partager des identifiants avec les clients.

Strimzi fournit une méthode native à Kubernetes pour la gestion des utilisateurs avec un User Operator distinct et sa ressource personnalisée Kubernetes correspondante,KafkaUser, qui définit la configuration utilisateur. La configuration utilisateur inclut des paramètres d'authentification et d'autorisation, et provisionne l'utilisateur correspondant dans Kafka.

Strimzi peut créer des écouteurs et des utilisateurs Kafka compatibles avec plusieurs mécanismes d'authentification, tels que l'authentification par nom d'utilisateur et mot de passe (SCRAM-SHA-512) ou le protocole TLS. Vous pouvez également utiliser l'authentification OAuth 2.0, qui est souvent considérée comme une meilleure approche que l'utilisation de mots de passe ou de certificats pour l'authentification, en raison de la sécurité et de la gestion externe des identifiants.

Déployer un cluster Kafka

Cette section vous explique comment déployer un opérateur Strimzi qui illustre les fonctionnalités de gestion des utilisateurs, y compris :

  • Un cluster Kafka avec authentification basée sur les mots de passe (SCRAM-SHA-512) activée sur l'un des écouteurs.
  • Un KafkaTopic avec trois instances dupliquées.
  • Un KafkaUser avec une LCA qui indique que l'utilisateur dispose des autorisations de lecture et d'écriture sur le sujet.

  1. Configurez votre cluster Kafka pour utiliser un écouteur avec l'authentification SCRAM-SHA-512 basée sur mot de passe sur le port 9094 et une autorisation simple :

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

  2. Créez un Topic, un User et un pod client pour exécuter des commandes sur le 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

    Le Secret my-user contenant les identifiants utilisateur est installé sur le pod client en tant que Volume.

    Ces identifiants confirment que l'utilisateur est autorisé à publier des messages dans le sujet en utilisant l'écouteur avec l'authentification par mot de passe (SCRAM-SHA-512) activée.

  3. Créez un pod client:

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

  4. Attendez quelques minutes que le pod client devienne Ready, puis connectez-vous à celui-ci :

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

  5. Générez un nouveau message avec les identifiants my-user et essayez de le consulter :

    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

    Le résultat ressemble à ce qui suit :

    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

    Saisissez CTRL+C pour arrêter le processus destiné au consommateur.

  6. Quittez l'interface système du pod.

    exit

Sauvegardes et reprise après sinistre

Bien que l'opérateur Strimzi ne propose pas de fonctionnalité de sauvegarde intégrée, vous pouvez mettre en œuvre des stratégies de sauvegarde efficaces en suivant certains modèles.

Vous pouvez utiliser Sauvegarde pour GKE pour effectuer une sauvegarde des éléments suivants :

  • Fichiers manifestes de ressources Kubernetes.
  • Ressources personnalisées de l'API Strimzi et leurs définitions extraites du serveur d'API Kubernetes du cluster à sauvegarder.
  • Volumes correspondant aux ressources PersistentVolumeClaim trouvées dans les fichiers manifestes.

Pour en savoir plus sur la sauvegarde et la restauration des clusters Kafka à l'aide de Sauvegarde pour GKE, consultez la page Préparer la reprise après sinistre.

Vous pouvez également effectuer une sauvegarde d'un cluster Kafka déployé à l'aide de l'opérateur Strimzi. Vous devez sauvegarder :

  • La configuration Kafka, qui inclut toutes les ressources personnalisées de l'API Strimzi telles que KafkaTopics et KafkaUsers
  • Les données, qui sont stockées dans les PersistentVolumes des agents Kafka

Le stockage des fichiers manifestes de ressources Kubernetes (y compris des configurations Strimzi) dans des dépôts Git peut éliminer la nécessité d'une sauvegarde distincte pour la configuration Kafka, car les ressources peuvent être réappliquées à un nouveau cluster Kubernetes si nécessaire.

Pour protéger la récupération des données Kafka dans les scénarios où une instance de serveur Kafka ou un cluster Kubernetes où Kafka est déployé, nous vous recommandons de configurer la classe de stockage Kubernetes utilisée pour provisionner des volumes pour les agents Kafka avec l'option reclaimPolicy définie sur Retain. Nous vous recommandons également de prendre des instantanés des volumes de l'agent Kafka.

Le fichier manifeste suivant décrit une StorageClass qui utilise l'option de reclaimPolicy Retain :

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

L'exemple suivant montre la ressource StorageClass ajoutée au spec d'une ressource personnalisée de cluster Kafka :

# ...
spec:
  kafka:
    # ...
    storage:
      type: persistent-claim
      size: 100Gi
      class: premium-rwo-retain

Avec cette configuration, les ressources PersistentVolume provisionnées à l'aide de la classe de stockage ne sont pas supprimées, même lorsque l'objet PersistentVolumeClaim correspondant est supprimé.

Pour récupérer l'instance Kafka sur un nouveau cluster Kubernetes à l'aide des données de configuration et d'instance d'agent existantes, procédez comme suit :

  1. Appliquez les ressources personnalisées Strimzi Kafka existantes (Kakfa, KafkaTopic, KafkaUser, etc…) à un nouveau cluster Kubernetes.
  2. Mettez à jour les PersistentVolumeClaims avec le nom des nouvelles instances d'agent Kafka pour utiliser les anciens PersistentVolumes en utilisant la propriété spec.volumeName de la PersistentVolumeClaim.

Effectuer un nettoyage

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.

Supprimer le projet

    Delete a Google Cloud project:

    gcloud projects delete PROJECT_ID

Supprimer les ressources individuelles

Si vous avez utilisé un projet existant et que vous ne souhaitez pas le supprimer, supprimez les ressources individuelles.

  1. Définissez les variables d'environnement.

    export PROJECT_ID=${PROJECT_ID}
export KUBERNETES_CLUSTER_PREFIX=kafka
export REGION=us-central1

  2. Exécutez la commande 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}

    Remplacez FOLDER par gke-autopilot ou gke-standard.

    Lorsque vous y êtes invité, saisissez yes.

  3. Recherchez tous les disques non associés :

    export disk_list=$(gcloud compute disks list --filter="-users:* AND labels.name=${KUBERNETES_CLUSTER_PREFIX}-cluster" --format "value[separator=|](name,zone)")

    Cette étape est nécessaire, car Strimzi utilise par défaut le paramètre deleteClaim: false pour le stockage. Si vous supprimez le cluster, tous les disques restent disponibles.

  4. Supprimez les disques :

    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

Étapes suivantes

  • Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.