En la guía, se muestra cómo usar el operador Confluent para Kubernetes (CFK) para implementar clústeres de Apache Kafka en Google Kubernetes Engine (GKE).
Kafka es un sistema de mensajería de publicación y suscripción distribuido y de código abierto para administrar datos de transmisión de gran volumen, alta capacidad de procesamiento y tiempo real. Puedes usar Kafka para compilar canalizaciones de datos de transmisión que muevan datos de manera confiable en diferentes sistemas y aplicaciones para su procesamiento y análisis.
Esta guía está dirigida a administradores de plataformas, arquitectos de nube y profesionales de operaciones interesados en implementar clústeres de Kafka en GKE.
También puedes usar el operador de CFK para implementar otros componentes de la plataforma de Confluent, como el centro de control de Confluent basado en la Web, el Registro de esquemas o Kafka. Sin embargo, esta guía solo se centra en las implementaciones de Kafka.
Objetivos
- Planifica e implementa la infraestructura de GKE para Apache Kafka
- Implementa y configura el operador de CFK
- Configurar Apache Kafka con el operador de CFK para garantizar la disponibilidad, la seguridad, la observabilidad y el rendimiento
Ventajas
CFK ofrece los siguientes beneficios:
- Actualizaciones progresivas automatizadas para los cambios de configuración.
- Actualizaciones progresivas automatizadas sin afectar la disponibilidad de Kafka.
- Si se produce un error, CFK restablece un Pod de Kafka con el mismo ID de agente de Kafka, configuración y volúmenes de almacenamiento persistente.
- Conocimiento automático del bastidor para distribuir réplicas de una partición en diferentes bastidores (o zonas), lo que mejora la disponibilidad de los agentes de Kafka y limita el riesgo de pérdida de datos.
- Compatibilidad con la exportación de métricas agregadas a Prometheus.
Arquitectura de implementación
Cada partición de datos en un clúster de Kafka tiene un agente líder y puede tener uno o más agentes de seguidores. El agente líder maneja todas las operaciones de lectura y escritura en la partición. Cada agente de seguidores replica de forma pasiva el agente líder.
En una configuración típica de Kafka, también usas un servicio de código abierto llamado ZooKeeper para coordinar tus clústeres de Kafka. Este servicio ayuda a elegir un líder entre los agentes y activar la conmutación por error en caso de fallas.
También puedes implementar la configuración de Kafka sin Zookeeper mediante la activación.Modo KRAft, pero este método no se considera listo para la producción debido a la falta de compatibilidad para Recursos de KafkaTopic y la autenticación de credenciales.
Disponibilidad y recuperación ante desastres
En este instructivo, se usan grupos de nodos y zonas independientes para los clústeres de Kafka y ZooKeeper para garantizar una alta disponibilidad y prepararse para la recuperación ante desastres.
Los clústeres de Kubernetes con alta disponibilidad en Google Cloud se basan en clústeres regionales que abarcan varios nodos y zonas de disponibilidad. Esta configuración mejora la tolerancia a errores, la escalabilidad y la redundancia geográfica. Esta configuración también te permite realizar actualizaciones y mantenimiento progresivas mientras proporcionas ANS para el tiempo de actividad y la disponibilidad. Para obtener más información, consulta Clústeres regionales.
Diagrama de la implementación
En el siguiente diagrama, se muestra un clúster de Kafka que se ejecuta en varios nodos y zonas en un clúster de GKE:
En el diagrama, el StatefulSet de Kafka se implementa en tres nodos en tres zonas diferentes. Para controlar esta configuración, establece las reglas necesarias de afinidad y distribución de topología del Pod en la especificación de recursos personalizados de Kafka
.
Si una zona falla, mediante la configuración recomendada, GKE reprograma los Pods en nodos nuevos y replica los datos de las réplicas restantes, tanto para Kafka como para Zookeeper.
En el siguiente diagrama, se muestra un StatefulSet
de ZooKeeper implementado en tres nodos de tres zonas diferentes:
Costos
En este documento, usarás los siguientes componentes facturables de Google Cloud:
Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios.
Cuando finalices las tareas que se describen en este documento, puedes borrar los recursos que creaste para evitar que continúe la facturación. Para obtener más información, consulta Cómo realizar una limpieza.
Antes de comenzar
- Accede a tu cuenta de Google Cloud. Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.
- 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.
-
-
Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.
-
Enable the GKE, Backup for GKE, Compute Engine, Identity and Access Management, and Resource Manager APIs:
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.
-
-
Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.
-
Enable the GKE, Backup for GKE, Compute Engine, Identity and Access Management, and Resource Manager APIs:
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
Prepare el entorno
En este instructivo, usarás Cloud Shell para administrar recursos alojados en Google Cloud. Cloud Shell tiene preinstalado el software que necesitas para este instructivo, incluido kubectl
, la CLI de gcloud, Helm y Terraform.
Para configurar tu entorno con Cloud Shell, sigue estos pasos:
Para iniciar una sesión de Cloud Shell desde la consola de Google Cloud, haz clic en Activar Cloud Shell en la consola de Google Cloud. Esto inicia una sesión en el panel inferior de la consola de Google Cloud.
Establece las variables de entorno:
export PROJECT_ID=PROJECT_ID export KUBERNETES_CLUSTER_PREFIX=kafka export REGION=us-central1
Reemplaza
PROJECT_ID
por tu Google Cloud con el ID del proyecto.Clona el repositorio de GitHub:
git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
Cambia al directorio de trabajo:
cd kubernetes-engine-samples/streaming
Crea la infraestructura del clúster
En esta sección, debes ejecutar una secuencia de comandos de Terraform para crear un clúster de GKE privado y con alta disponibilidad. Los siguientes pasos permiten el acceso público al plano de control. Para restringir el acceso, crea un clúster privado.
Puedes instalar el operador mediante un clúster de Standard o Autopilot.
Standard
En el siguiente diagrama, se muestra un clúster de GKE estándar regional privado implementado en tres zonas diferentes:
Para implementar esta infraestructura, ejecuta los siguientes comandos desde 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}
Cuando se te solicite, escribe yes
. Es posible que este comando tarde varios minutos en completarse y que el clúster muestre un estado de preparación.
Terraform crea los siguientes recursos:
- Una red de VPC y una subred privada para los nodos de Kubernetes.
- Un router para acceder a Internet a través de NAT.
- Un clúster de GKE privado en la región
us-central1
. - 2 grupos de nodos con ajuste de escala automático habilitado (de 1 a 2 nodos por zona y 1 nodo por zona como mínimo)
- Un
ServiceAccount
con permisos de registro y supervisión. - Copia de seguridad para GKE para la recuperación ante desastres.
- Google Cloud Managed Service para Prometheus para la supervisión de clústeres.
El resultado es similar a este:
...
Apply complete! Resources: 14 added, 0 changed, 0 destroyed.
Outputs:
kubectl_connection_command = "gcloud container clusters get-credentials kafka-cluster --region us-central1"
Autopilot
En el siguiente diagrama, se muestra un clúster de GKE de Autopilot regional privado:
Para implementar la infraestructura, ejecuta los siguientes comandos desde 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}
Cuando se te solicite, escribe yes
. Es posible que este comando tarde varios minutos en completarse y que el clúster muestre un estado de preparación.
Terraform crea los siguientes recursos:
- La red de VPC y la subred privada para los nodos de Kubernetes.
- Un router para acceder a Internet a través de NAT.
- Un clúster de GKE privado en la región
us-central1
. - Un
ServiceAccount
con permisos de registro y supervisión - Google Cloud Managed Service para Prometheus para la supervisión de clústeres.
El resultado es similar a este:
...
Apply complete! Resources: 12 added, 0 changed, 0 destroyed.
Outputs:
kubectl_connection_command = "gcloud container clusters get-credentials kafka-cluster --region us-central1"
Conéctate al clúster
Configura kubectl
para comunicarse con el clúster:
gcloud container clusters get-credentials ${KUBERNETES_CLUSTER_PREFIX}-cluster --region ${REGION}
Implementa el operador de CFK en tu clúster
En esta sección, implementarás el operador Confluent for Kubernetes (CFK) mediante un gráfico de Helm y, luego, implementarás un clúster de Kafka.
Agrega el repositorio de gráficos de Confluent Helm:
helm repo add confluentinc https://packages.confluent.io/helm
Agrega un espacio de nombres para el operador CFK y el clúster de Kafka:
kubectl create ns kafka
Implementa el operador del clúster de CFK con Helm:
helm install confluent-operator confluentinc/confluent-for-kubernetes -n kafka
Para permitir que CFK administre recursos en todos los espacios de nombres, agrega el parámetro
--set-namespaced=false
al comando de Helm.Verifica que el operador Confluent se haya implementado de forma correcta mediante Helm:
helm ls -n kafka
El resultado es similar a este:
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
Implementa Kafka
En esta sección, implementarás Kafka en una configuración básica y, luego, probarás varias situaciones de configuración avanzada para abordar los requisitos de disponibilidad, seguridad y observabilidad.
Configuración básica
La configuración básica de la instancia de Kafka incluye los siguientes componentes:
- Tres réplicas de agentes de Kafka, con un mínimo de dos réplicas disponibles para la coherencia del clúster.
- Tres réplicas de los nodos de ZooKeeper, que forman un clúster.
- Dos objetos de escucha de Kafka: uno sin autenticación y otro con autenticación de TLS con un certificado generado por CFK.
- Java MaxHeapSize y MinHeapSize están configurados en 4 GB para Kafka.
- Asignación de recursos de CPU de 1 solicitud de CPU y 2 límites de CPU, y 5 GB de solicitudes de memoria y límites para Kafka (4 GB para el servicio principal y 0.5 GB para el exportador de métricas) y 3 GB para Zookeeper (2 GB para el servicio principal y 0.5 GB para el exportador de métricas).
- 100 GB de almacenamiento asignado a cada Pod mediante storageClass
premium-rwo
, 100 para datos de Kafka y 90/10 para Zookeeper Data/Log. - Tolerancias, nodeAffinities y podAntiAffinities configuradas para cada carga de trabajo, lo que garantiza una distribución adecuada entre nodos, con sus respectivos grupos de nodos y zonas diferentes.
- Comunicación dentro del clúster protegida por certificados autofirmados mediante la autoridad certificadora que proporcionas.
Esta configuración representa la configuración mínima necesaria para crear un clúster de Kafka listo para la producción. En las siguientes secciones, se muestran configuraciones personalizadas para abordar aspectos como la seguridad del clúster, las listas de control de acceso (LCA), la administración de temas, la administración de certificados y mucho más.
Crea un clúster básico de Kafka
Genera un par de CA:
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 para Kubernetes proporciona certificados generados automáticamente para que los componentes de Confluent Platform se usen para la encriptación de red TLS. Debes generar y proporcionar una autoridad certificadora (CA).
Crea un Secret de Kubernetes para la autoridad certificadora:
kubectl create secret tls ca-pair-sslcerts --cert=ca.pem --key=ca-key.pem -n kafka
El nombre del Secret está predefinido.
Crea un clúster de Kafka nuevo mediante la configuración básica:
kubectl apply -n kafka -f kafka-confluent/manifests/01-basic-cluster/my-cluster.yaml
Este comando crea un recurso personalizado de Kafka y un recurso personalizado de Zookeeper del operador CFK que incluye los requisitos y límites de CPU y memoria, las solicitudes de almacenamiento en bloque, y los taints y afinidades para distribuir los Pods aprovisionados en los nodos de Kubernetes.
Espera unos minutos mientras Kubernetes inicia las cargas de trabajo requeridas:
kubectl wait pods -l app=my-cluster --for condition=Ready --timeout=300s -n kafka
Verifica que se hayan creado las cargas de trabajo de Kafka:
kubectl get pod,svc,statefulset,deploy,pdb -n kafka
El resultado es similar a este:
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
El operador crea los siguientes recursos:
- Dos StatefulSets para Kafka y ZooKeeper.
- Tres Pods para las réplicas de agente de Kafka.
- Tres Pods para las réplicas de ZooKeeper.
- Dos recursos
PodDisruptionBudget
, lo que garantiza una réplica máxima no disponible para la coherencia del clúster. - El servicio
my-cluster
que funciona como el servidor de arranque para los clientes de Kafka que se conectan desde el clúster de Kubernetes. Todos los objetos de escucha internos de Kafka están disponibles en este servicio. - El servicio
zookeeper
, que permite que los agentes de Kafka se conecten a nodos de ZooKeeper como clientes
Autenticación y administración de usuarios
En esta sección, se muestra cómo habilitar la autenticación y la autorización para proteger los objetos de escucha de Kafka y compartir credenciales con los clientes.
Confluent para Kubernetes admite varios métodos de autenticación para Kafka, como los siguientes:
- Autenticación SASL/PLAIN: Los clientes usan un nombre de usuario y una contraseña para la autenticación. El nombre de usuario y la contraseña se almacenan en el servidor en un secreto de Kubernetes.
- SASL/PLAIN con autenticación LDAP: Los clientes usan un nombre de usuario y una contraseña para la autenticación. Las credenciales se almacenan en un servidor LDAP.
- Autenticación mTLS: Los clientes usan certificados TLS para la autenticación.
Limitaciones
- CFK no proporciona recursos personalizados para la administración de usuarios. Sin embargo, puedes almacenar credenciales en Secrets y consultar Secrets en las especificaciones de los objetos de escucha.
- Aunque no hay un recurso personalizado para administrar las LCA directamente, el Confluent para Kubernetes oficial proporciona orientación sobre la configuración de las LCAs mediante la CLI de Kafka.
Crea un usuario
En esta sección, se muestra cómo implementar un operador de CFK que demuestra las capacidades de administración de usuarios, lo que incluye lo siguiente:
- Un clúster de Kafka con autenticación basada en contraseña (SASL/PLAIN) habilitada en uno de los objetos de escucha
- Un
KafkaTopic
con 3 réplicas - Credenciales de usuario con permisos de lectura y escritura
Crea un Secret con credenciales de usuario:
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\"}"
Las credenciales deben almacenarse en el siguiente formato:
{ "username1": "password1", "username2": "password2", ... "usernameN": "passwordN" }
Configura el clúster de Kafka para usar un objeto de escucha con autenticación SCRAM-SHA-512 de autenticación basada en contraseña en el puerto 9094:
kubectl apply -n kafka -f kafka-confluent/manifests/02-auth/my-cluster.yaml
Configura un tema y un Pod de cliente para interactuar con tu clúster de Kafka y ejecutar los comandos de 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 activa el Secret
my-user-credentials
en el Pod cliente como un Volume.Cuando el Pod de cliente esté listo, conéctate a él y comienza a producir y consumir mensajes con las credenciales proporcionadas:
kubectl wait pod kafkacat --for=condition=Ready --timeout=300s -n kafka kubectl exec -it kafkacat -n kafka -- /bin/sh
Produce un mensaje con las credenciales
my-user
y, luego, consume el mensaje para verificar su recepción.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
El resultado es similar a este:
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
Escribe
CTRL+C
para detener el proceso del consumidor. Si recibes un errorConnect refused
, espera unos minutos y vuelve a intentarlo.Sal de la shell del Pod
exit
Copias de seguridad y recuperación ante desastres
Con el operador Confluent, puedes implementar estrategias de copia de seguridad eficientes si sigues ciertos patrones.
Puedes usar la Copia de seguridad para GKE para hacer una copia de seguridad:
- Manifiestos de recursos de Kubernetes.
- Recursos personalizados de la API de Confluent y sus definiciones extraídas del servidor de APIs de Kubernetes del clúster que se somete a una copia de seguridad.
- Volúmenes que corresponden a los recursos PersistentVolumeClaim que se encuentran en los manifiestos.
Para obtener más información sobre cómo crear una copia de seguridad y restablecer los clústeres de Kafka con la copia de seguridad para GKE, consulta Prepárate para la recuperación ante desastres.
También puedes realizar una copia de seguridad manual de tu clúster de Kafka. Debes crear una copia de seguridad:
- La configuración de Kafka, que incluye todos los recursos personalizados de la API de Confluent, como
KafkaTopics
oConnect
. - Los datos, que se almacenan en los PersistentVolumes de los agentes de Kafka
El almacenamiento de manifiestos de recursos de Kubernetes, incluidas las configuraciones de Confluent, en los repositorios de Git, puede eliminar la necesidad de realizar una copia de seguridad por separado para la configuración de Kafka, ya que los recursos se pueden volver a aplicar a un clúster de Kubernetes nuevo cuando sea necesario.
Para proteger la recuperación de datos de Kafka en situaciones en las que se pierde una instancia del servidor de Kafka o un clúster de Kubernetes en el que se implementa Kafka, te recomendamos que configures la clase de almacenamiento de Kubernetes que se usa para aprovisionar volúmenes para los agentes de Kafka con la opción reclaimPolicy
configurada como Retain
. También te recomendamos que tomes instantáneas de los volúmenes del agente de Kafka.
En el siguiente manifiesto, se describe una StorageClass que usa la opción Retain
de reclaimPolicy
:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: premium-rwo-retain
...
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
En el siguiente ejemplo, se muestra la StorageClass que se agregó al spec
de un recurso personalizado del clúster de Kafka:
...
spec:
...
dataVolumeCapacity: 100Gi
storageClass:
name: premium-rwo-retain
Con esta configuración, los PersistentVolumes aprovisionados mediante la clase de almacenamiento no se borran, incluso cuando se borra la PersistentVolumeClaim correspondiente.
Para recuperar la instancia de Kafka en un clúster de Kubernetes nuevo con la configuración existente y los datos de la instancia del agente, sigue estos pasos:
- Aplica los recursos personalizados de Confluent existentes (
Kafka
,KafkaTopic
,Zookeeper
, etc.) a un clúster nuevo de Kubernetes. - Actualiza las PersistentVolumeClaims con el nombre de las instancias nuevas del agente de Kafka a los PersistentVolumes anteriores mediante la propiedad
spec.volumeName
en PersistentVolumeClaim.
Limpia
Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.
Borra el proyecto
Borra un proyecto de Google Cloud:
gcloud projects delete PROJECT_ID
Borra los recursos individuales
Si usaste un proyecto existente y no quieres borrarlo, borra los recursos individuales.
Establece las variables de entorno:
export PROJECT_ID=PROJECT_ID export KUBERNETES_CLUSTER_PREFIX=kafka export REGION=us-central1
Ejecuta el 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}
Reemplaza
FOLDER
porgke-autopilot
ogke-standard
.Cuando se te solicite, escribe
yes
.Busca todos los discos no conectados:
export disk_list=$(gcloud compute disks list --filter="-users:* AND labels.name=${KUBERNETES_CLUSTER_PREFIX}-cluster" --format "value[separator=|](name,zone)")
Borra los discos:
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
¿Qué sigue?
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.