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.

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 consoleGoogle 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: your Google Cloud par votre ID de projet.

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