Ce guide vous explique comment utiliser l'opérateur Confluent for Kubernetes (CFK) pour déployer des clusters Apache Kafka sur Google Kubernetes Engine (GKE).
Kafka est un système de messagerie Pub/Sub distribué Open Source permettant de gérer des données en streaming volumineuses, à haut débit et en temps réel. Kafka vous permet de créer des pipelines de données en streaming qui déplacent des données de manière fiable entre différents systèmes et applications à des fins de traitement et d'analyse.
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.
Vous pouvez également utiliser l'opérateur CFK pour déployer d'autres composants de Confluent Platform, tels que le centre Web Confluent Control, Schema Registry ou KsqlDB. Toutefois, ce guide ne se concentre que sur les déploiements de Kafka.
Objectifs
- Planifier et déployer l'infrastructure GKE pour Apache Kafka
- Déployer et configurer l'opérateur CFK
- Configurer Apache Kafka à l'aide de l'opérateur CFK pour garantir la disponibilité, la sécurité, l'observabilité et les performances
Avantages
CFK offre les avantages suivants :
- Mises à jour progressives automatisées pour les modifications de configuration.
- Mises à niveau progressives automatisées sans impact sur la disponibilité de Kafka.
- En cas d'échec, CFK restaure un pod Kafka avec le même ID d'agent Kafka, la même configuration et les mêmes volumes de stockage persistants.
- Prise en compte automatisée des racks pour propager les répliques d'une partition sur différents racks (ou zones), ce qui améliore la disponibilité des agents Kafka et limite le risque de perte de données.
- Prise en charge de l'exportation de métriques agrégées vers Prometheus.
Architecture de déploiement
Chaque partition de données d'un cluster Kafka possède un agent principal et peut avoir un ou plusieurs agents subordonnés. L'agent principal gère toutes les lectures et écritures sur la partition. Chaque agent subordonné réplique l'agent principal de manière passive.
Dans une configuration Kafka classique, vous utilisez également un service Open Source appelé ZooKeeper pour coordonner vos clusters Kafka. Ce service permet de désigner un agent principal parmi les agents et de déclencher un basculement en cas d'échec.
Vous pouvez également déployer une configuration Kafka sans Zookeeper en activant le mode KRaft. Cette méthode n'est toutefois pas considérée comme utilisable en production en raison de l'absence de prise en charge des ressources KafkaTopic et de l'authentification des identifiants.
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.
Les clusters Kubernetes à disponibilité élevée dans Google Cloud s'appuient sur des clusters régionaux couvrant plusieurs nœuds et zones de disponibilité. Cette configuration améliore la tolérance aux pannes, l'évolutivité et la redondance géographique. Cette configuration vous permet également d'effectuer des mises à jour et des opérations de maintenance progressives, tout en fournissant des contrats de niveau de service pour les temps d'activité et la disponibilité. Pour en savoir plus, consultez la page Clusters régionaux.
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 StatefulSet 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 ressource personnalisée Kafka
.
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 répliquées restantes pour Kafka et Zookeeper.
Le schéma suivant montre un StatefulSet
ZooKeeper déployé sur trois nœuds dans trois zones différentes :
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.
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
- Connectez-vous à votre compte Google Cloud. Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.
- 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.
-
-
Vérifiez que la facturation est activée pour votre projet Google Cloud.
-
Activer les API GKE, Backup for GKE, Compute Engine, Identity and Access Management, 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.
-
-
Vérifiez que la facturation est activée pour votre projet Google Cloud.
-
Activer les API GKE, Backup for GKE, Compute Engine, Identity and Access Management, 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:
role/storage.objectViewer, role/logging.logWriter, 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_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.
- Replace
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 :
Lancez une session Cloud Shell depuis la console Google Cloud en cliquant sur
Activer Cloud Shell dans la console Google Cloud. Une session s'ouvre dans le volet inférieur de la console Google Cloud.
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.Clonez le dépôt GitHub.
git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
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 kafka-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 kafka-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 CFK sur votre cluster
Dans cette section, vous allez déployer l'opérateur Confluent for Kubernetes (CFK) à l'aide d'un chart Helm, puis déployer un cluster Kafka.
Ajoutez le dépôt de chart Helm Confluent :
helm repo add confluentinc https://packages.confluent.io/helm
Ajoutez un espace de noms pour l'opérateur CFK et le cluster Kafka :
kubectl create ns kafka
Déployez l'opérateur de cluster CFK à l'aide de Helm :
helm install confluent-operator confluentinc/confluent-for-kubernetes -n kafka
Pour permettre à CFK de gérer les ressources sur tous les espaces de noms, ajoutez le paramètre
--set-namespaced=false
à la commande Helm.Vérifiez que l'opérateur Confluent 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 confluent-operator kafka 1 2023-07-07 10:57:45.409158 +0200 CEST deployed confluent-for-kubernetes-0.771.13 2.6.0
Déployer 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 CFK.
- Java MaxHeapSize et MaxHeapSize définis sur 4 Go pour Kafka
- Allocation de ressources de processeur de 1 requête de processeur et 2 limites de processeur, 5 Go de requêtes et limites de mémoire pour Kafka (4 Go pour le service principal et 0,5 Go pour l'exportateur de métriques) et 3 Go pour Zookeeper (2 Go pour le service principal et 0,5 Go pour l'exportateur de métriques).
- 100 Go d'espace de stockage alloué à chaque pod à l'aide de la StorageClass
premium-rwo
, 100 pour les données Kafka et 90/10 pour les données et le journal Zookeeper. - 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 à l'aide d'une autorité de certification que vous fournissez.
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
Générez une paire d'autorités de certification :
openssl genrsa -out ca-key.pem 2048 openssl req -new -key ca-key.pem -x509 \ -days 1000 \ -out ca.pem \ -subj "/C=US/ST=CA/L=Confluent/O=Confluent/OU=Operator/CN=MyCA"
Confluent for Kubernetes fournit des certificats générés automatiquement pour les composants de la plateforme Confluent à utiliser pour le chiffrement du réseau TLS. Vous devez générer et fournir une autorité de certification (CA).
Créez un secret Kubernetes pour l'autorité de certification :
kubectl create secret tls ca-pair-sslcerts --cert=ca.pem --key=ca-key.pem -n kafka
Le nom du secret est prédéfini.
Créez un cluster Kafka en utilisant la configuration de base :
kubectl apply -n kafka -f kafka-confluent/manifests/01-basic-cluster/my-cluster.yaml
Cette commande crée une ressource personnalisée Kafka et une ressource personnalisée ZooKeeper de l'opérateur CFK qui inclut les demandes et limites de processeurs et de mémoire, les requêtes de stockage de blocs, ainsi que les rejets et les affinités pour répartir les pods provisionnés sur les nœuds Kubernetes.
Attendez quelques minutes pendant que Kubernetes démarre les charges de travail requises :
kubectl wait pods -l app=my-cluster --for condition=Ready --timeout=300s -n kafka
Vérifiez que les charges de travail Kafka ont bien été créées :
kubectl get pod,svc,statefulset,deploy,pdb -n kafka
Le résultat ressemble à ce qui suit :
NAME READY STATUS RESTARTS AGE pod/confluent-operator-864c74d4b4-fvpxs 1/1 Running 0 49m pod/my-cluster-0 1/1 Running 0 17m pod/my-cluster-1 1/1 Running 0 17m pod/my-cluster-2 1/1 Running 0 17m pod/zookeeper-0 1/1 Running 0 18m pod/zookeeper-1 1/1 Running 0 18m pod/zookeeper-2 1/1 Running 0 18m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/confluent-operator ClusterIP 10.52.13.164 <none> 7778/TCP 49m service/my-cluster ClusterIP None <none> 9092/TCP,8090/TCP,9071/TCP,7203/TCP,7777/TCP,7778/TCP,9072/TCP 17m service/my-cluster-0-internal ClusterIP 10.52.2.242 <none> 9092/TCP,8090/TCP,9071/TCP,7203/TCP,7777/TCP,7778/TCP,9072/TCP 17m service/my-cluster-1-internal ClusterIP 10.52.7.98 <none> 9092/TCP,8090/TCP,9071/TCP,7203/TCP,7777/TCP,7778/TCP,9072/TCP 17m service/my-cluster-2-internal ClusterIP 10.52.4.226 <none> 9092/TCP,8090/TCP,9071/TCP,7203/TCP,7777/TCP,7778/TCP,9072/TCP 17m service/zookeeper ClusterIP None <none> 2181/TCP,7203/TCP,7777/TCP,3888/TCP,2888/TCP,7778/TCP 18m service/zookeeper-0-internal ClusterIP 10.52.8.52 <none> 2181/TCP,7203/TCP,7777/TCP,3888/TCP,2888/TCP,7778/TCP 18m service/zookeeper-1-internal ClusterIP 10.52.12.44 <none> 2181/TCP,7203/TCP,7777/TCP,3888/TCP,2888/TCP,7778/TCP 18m service/zookeeper-2-internal ClusterIP 10.52.12.134 <none> 2181/TCP,7203/TCP,7777/TCP,3888/TCP,2888/TCP,7778/TCP 18m NAME READY AGE statefulset.apps/my-cluster 3/3 17m statefulset.apps/zookeeper 3/3 18m NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/confluent-operator 1/1 1 1 49m NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE poddisruptionbudget.policy/my-cluster N/A 1 1 17m poddisruptionbudget.policy/zookeeper N/A 1 1 18m
L'opérateur crée les ressources suivantes :
- Deux StatefulSets pour Kafka et ZooKeeper.
- Trois pods pour les instances dupliquées d'agents Kafka.
- Trois pods pour les instances dupliquées ZooKeeper.
- Deux ressources
PodDisruptionBudget
, garantissant ainsi une instance répliquée indisponible au maximum pour la cohérence du cluster. - Le service
my-cluster
, 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. - Le service
zookeeper
, qui permet aux agents Kafka de se connecter aux nœuds ZooKeeper en tant que clients.
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.
Confluent fo Kubernetes est compatible avec diverses méthodes d'authentification pour Kafka, dont voici quelques exemples :
- Authentification SASL/PLAIN : les clients utilisent un nom d'utilisateur et un mot de passe pour l'authentification. Le nom d'utilisateur et le mot de passe sont stockés côté serveur dans un secret Kubernetes.
- Authentification SASL/PLAIN avec LDAP : les clients utilisent un nom d'utilisateur et un mot de passe pour l'authentification. Les identifiants sont stockés sur un serveur LDAP.
- Authentification mTLS : les clients utilisent des certificats TLS pour l'authentification.
Limites
- CFK ne fournit pas de ressources personnalisées pour la gestion des utilisateurs. Toutefois, vous pouvez stocker les identifiants dans des secrets et y faire référence dans les spécifications de l'écouteur.
- Bien qu'il n'existe pas de ressource personnalisée pour gérer directement les LCA, le service Confluent for Kubernetes officiel fournit des conseils sur la configuration des LCA à l'aide de la CLI Kafka.
Créer un compte utilisateur
Cette section vous explique comment déployer un opérateur CFK qui illustre les fonctionnalités de gestion des utilisateurs, y compris :
- Un cluster Kafka avec authentification basée sur les mots de passe (SASL/PLAIN) activé sur l'un des écouteurs
- Un
KafkaTopic
avec trois instances répliquées. - Identifiants utilisateur avec autorisations de lecture et d'écriture
Créez un secret avec des identifiants utilisateur :
export USERNAME=my-user export PASSWORD=$(openssl rand -base64 12) kubectl create secret generic my-user-credentials -n kafka \ --from-literal=plain-users.json="{\"$USERNAME\":\"$PASSWORD\"}"
Les identifiants doivent être stockés au format suivant :
{ "username1": "password1", "username2": "password2", ... "usernameN": "passwordN" }
Configurez le cluster Kafka pour utiliser un écouteur avec authentification par mot de passe SCRAM-SHA-512 sur le port 9094 :
kubectl apply -n kafka -f kafka-confluent/manifests/02-auth/my-cluster.yaml
Configurez un sujet et un pod client pour interagir avec votre cluster Kafka et exécuter les commandes Kafka :
kubectl apply -n kafka -f kafka-confluent/manifests/02-auth/my-topic.yaml kubectl apply -n kafka -f kafka-confluent/manifests/02-auth/kafkacat.yaml
GKE installe le secret
my-user-credentials
sur le pod client en tant que volume.Lorsque le pod client est prêt, connectez-vous au pod et commencez à produire et à utiliser des messages à l'aide des identifiants fournis :
kubectl wait pod kafkacat --for=condition=Ready --timeout=300s -n kafka kubectl exec -it kafkacat -n kafka -- /bin/sh
Générez un message à l'aide des identifiants
my-user
, puis utilisez-le pour vérifier sa réception.export USERNAME=$(cat /my-user/plain-users.json|cut -d'"' -f 2) export PASSWORD=$(cat /my-user/plain-users.json|cut -d'"' -f 4) echo "Message from my-user" |kcat \ -b my-cluster.kafka.svc.cluster.local:9094 \ -X security.protocol=SASL_SSL \ -X sasl.mechanisms=PLAIN \ -X sasl.username=$USERNAME \ -X sasl.password=$PASSWORD \ -t my-topic -P kcat -b my-cluster.kafka.svc.cluster.local:9094 \ -X security.protocol=SASL_SSL \ -X sasl.mechanisms=PLAIN \ -X sasl.username=$USERNAME \ -X sasl.password=$PASSWORD \ -t my-topic -C
Le résultat ressemble à ce qui suit :
Message from my-user % Reached end of topic my-topic [1] at offset 1 % Reached end of topic my-topic [2] at offset 0 % Reached end of topic my-topic [0] at offset 0
Saisissez
CTRL+C
pour arrêter le processus destiné au consommateur. Si vous obtenez une erreurConnect refused
, attendez quelques minutes, puis réessayez.Quittez l'interface système du pod.
exit
Sauvegardes et reprise après sinistre
L'opérateur Confluent vous permet de 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 Confluent 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 manuelle de votre cluster Kafka. Vous devez sauvegarder :
- La configuration Kafka, qui inclut toutes les ressources personnalisées de l'API Confluent, telles que
KafkaTopics
ouConnect
- 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 Confluent) 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:
...
dataVolumeCapacity: 100Gi
storageClass:
name: 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 :
- Appliquez les ressources personnalisées Confluent existantes (
Kafka
,KafkaTopic
,Zookeeper
, etc.) à un nouveau cluster Kubernetes. - 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
Supprimez un projet Google Cloud :
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.
Définissez les variables d'environnement :
export PROJECT_ID=PROJECT_ID export KUBERNETES_CLUSTER_PREFIX=kafka export REGION=us-central1
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
pargke-autopilot
ougke-standard
.Lorsque vous y êtes invité, saisissez
yes
.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)")
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.