Implementa Apache Kafka en GKE mediante Confluent

Autopilot Estándar

---

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.

Nota: El operador de CFK y la mayoría de los componentes de la plataforma Confluent se distribuyen con una licencia de Сonfluent Enterprise, y las restricciones de licencias requieren que los usuarios tengan una suscripción activa después de los 30 días de prueba para seguir usando el operador. La licencia de desarrollador también está disponible por un tiempo indefinido. Sin embargo, se limita a una única configuración de agente por clúster.

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:

• GKE
• Servicio administrado para Prometheus
• Compute Engine

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. 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.
2. Instala Google Cloud CLI.

3. Para inicializar la CLI de gcloud, ejecuta el siguiente comando:

   gcloud init

   Nota: Si ya instalaste la CLI de gcloud, asegúrate de que tienes la versión más reciente mediante la ejecución de gcloud components update.

4. Crea o selecciona un proyecto de Google Cloud.

   Nota: Si no planeas conservar los recursos que creaste durante este procedimiento, crea un proyecto en lugar de seleccionar uno existente. Cuando termines, puedes borrar el proyecto y quitar todos los recursos asociados con él.

   • Crea un proyecto de Google Cloud:

     gcloud projects create PROJECT_ID

     Reemplaza PROJECT_ID por un nombre para el proyecto de Google Cloud que estás creando.

   • Selecciona el proyecto de Google Cloud que creaste:

     gcloud config set project PROJECT_ID

     Reemplaza PROJECT_ID por el nombre del proyecto de Google Cloud.

5. Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.

6. Habilita las APIs de 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

7. Instala Google Cloud CLI.

8. Para inicializar la CLI de gcloud, ejecuta el siguiente comando:

   gcloud init

   Nota: Si ya instalaste la CLI de gcloud, asegúrate de que tienes la versión más reciente mediante la ejecución de gcloud components update.

9. Crea o selecciona un proyecto de Google Cloud.

   Nota: Si no planeas conservar los recursos que creaste durante este procedimiento, crea un proyecto en lugar de seleccionar uno existente. Cuando termines, puedes borrar el proyecto y quitar todos los recursos asociados con él.

   • Crea un proyecto de Google Cloud:

     gcloud projects create PROJECT_ID

     Reemplaza PROJECT_ID por un nombre para el proyecto de Google Cloud que estás creando.

   • Selecciona el proyecto de Google Cloud que creaste:

     gcloud config set project PROJECT_ID

     Reemplaza PROJECT_ID por el nombre del proyecto de Google Cloud.

10. Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.

11. Habilita las APIs de 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

12. Otorga roles a tu Cuenta de Google. Ejecuta el siguiente comando una vez para cada uno de los siguientes roles de IAM: 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:EMAIL_ADDRESS" --role=ROLE

    • Reemplaza PROJECT_ID con el ID del proyecto.
    • Reemplaza EMAIL_ADDRESS por tu dirección de correo electrónico.
    • Reemplaza ROLE por cada rol individual.

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

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.

1. Agrega el repositorio de gráficos 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 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).

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

   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.

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

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

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

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. 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 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 nuevo de Kubernetes.
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

Precaución: Borrar un proyecto tiene estas consecuencias:

• Se borra todo en el proyecto. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
• Se pierden los ID personalizados de proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URL que utilizan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo el proyecto.

Si planeas explorar varias infraestructuras, instructivos y guías de inicio rápido la reutilización de proyectos puede ayudarte a evitar exceder los límites de las cuotas del 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.

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.