Implementar Apache Kafka en GKE mediante Confluent

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 Control Center de Confluent basado en la Web, Schema Registry o KsqlDB. Sin embargo, esta guía solo se enfoca 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 cambios de configuración.
  • Actualizaciones progresivas automatizadas sin afectar la disponibilidad de Kafka.
  • Si se produce una falla, CFK restablece un Pod de Kafka con el mismo ID de agente de Kafka, la misma configuración y los mismos volúmenes de almacenamiento persistentes.
  • Conocimiento automático de los bastidores 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 dependen de 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 progresivos, a la vez que proporciona ANS de tiempo de actividad y 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. Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.

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

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

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

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:

  1. Para iniciar una sesión de Cloud Shell desde la consola de Google Cloud, haz clic en Ícono de activación de Cloud ShellActivar Cloud Shell en la consola de Google Cloud. Esto inicia una sesión en el panel inferior de la consola de Google Cloud.

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

  3. Clona el repositorio de GitHub:

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

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

Estándar

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 para Kubernetes (CFK) mediante un gráfico de Helm y, luego, implementarás un clúster de Kafka.

  1. Agrega el repositorio de gráfico de Confluent Helm:

    helm repo add confluentinc https://packages.confluent.io/helm

  2. Agrega un espacio de nombres para el operador CFK y el clúster de Kafka:

    kubectl create ns kafka

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

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

  1. Genera un par de AC:

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

  2. 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 es predefinido.

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

    Con este comando, se crean un recurso personalizado de Kafka y un recurso personalizado de Zookeeper del operador de CFK que incluyen solicitudes y límites de CPU y memoria, solicitudes de almacenamiento en bloque, y taints y afinidades para distribuir los Pods aprovisionados en los nodos de Kubernetes.

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

  5. 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 no disponible máxima para la coherencia del clúster.
  • El Service 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 Service zookeeper, que permite a los agentes de Kafka conectarse a los 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 del lado del 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 hacer referencia a 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 LCA 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

  1. 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"
}

  2. Configura el clúster de Kafka para usar un objeto de escucha con autenticación basada en contraseña SCRAM-SHA-512 en el puerto 9094:

    kubectl apply -n kafka -f kafka-confluent/manifests/02-auth/my-cluster.yaml

  3. Configura un tema y un Pod cliente para interactuar con tu clúster de Kafka y ejecuta 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 volumen.

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

  5. Genera un mensaje con las credenciales de my-user y, luego, consúmelo 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 error Connect refused, espera unos minutos y vuelve a intentarlo.

  6. 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 o Connect
  • 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:

  1. Aplica los recursos personalizados de Confluent existentes (Kafka, KafkaTopic, Zookeeper, etc.) a un clúster de Kubernetes nuevo.
  2. 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

    Delete a Google Cloud project:

    gcloud projects delete PROJECT_ID

Borra los recursos individuales

Si usaste un proyecto existente y no quieres borrarlo, borra los recursos individuales.

  1. Establece las variables de entorno:

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

  2. 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 por gke-autopilot o gke-standard.

    Cuando se te solicite, escribe yes.

  3. 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)")

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