Cómo ejecutar Cassandra y Kubernetes juntos

Los contenedores se han vuelto cada vez más populares para los desarrolladores que desean implementar aplicaciones en la nube. Para administrar estas nuevas aplicaciones, Kubernetes se ha convertido en un estándar de facto para la orquestación de contenedores. Kubernetes permite a los desarrolladores crear aplicaciones distribuidas que escalan automáticamente de forma elástica, según la demanda.

Kubernetes se desarrolló para implementar, escalar y administrar sin esfuerzo cargas de trabajo de aplicaciones sin estado en producción. Cuando se trata de datos nativos de la nube con estado, ha existido la necesidad de la misma facilidad de implementación y escala.

En bases de datos distribuidas, Cassandra atrae a los desarrolladores que saben que tendrán que escalar sus datos: proporciona una base de datos totalmente tolerante y un enfoque de gestión de datos que puede ejecutarse de la misma manera en múltiples ubicaciones y servicios en la nube. Como todos los nodos de Cassandra son iguales y cada nodo es capaz de manejar solicitudes de lectura y escritura, no existe un punto único de falla en el modelo de Cassandra. Los datos se replican automáticamente entre zonas de falla para evitar la pérdida de una sola instancia que afecte a la aplicación.

Conectando Cassandra a Kubernetes

El siguiente paso lógico es usar Cassandra y Kubernetes juntos. Después de todo, hacer que una base de datos distribuida se ejecute junto con un entorno de aplicaciones distribuidas facilita que las operaciones de datos y aplicaciones se realicen cerca unas de otras. Esto no solo evita la latencia, sino que también puede ayudar a mejorar el rendimiento a escala.

Sin embargo, lograr esto significa comprender qué sistema está a cargo. Cassandra ya tiene el tipo de tolerancia a fallas y ubicación de nodos que Kubernetes puede ofrecer, por lo que es importante saber qué sistema está a cargo de tomar las decisiones. Esto se logra mediante el uso de un operador de Kubernetes.

Los operadores automatizan el proceso de implementación y administración de aplicaciones más complejas que requieren información específica del dominio y necesitan interactuar con sistemas externos. Hasta que se desarrollaron los operadores, los componentes de aplicaciones con estado, como las instancias de bases de datos, generaron responsabilidades adicionales para los equipos de DevOps, ya que tenían que realizar un trabajo manual para preparar y ejecutar sus instancias de forma con estado.

Hay varios operadores para Cassandra que han sido desarrollados por la comunidad de Cassandra. Para este ejemplo, usaremos cass-operator, que fue elaborado y de código abierto por DataStax. Es compatible con Kubernetes de código abierto, Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) y Pivotal Container Service (PKS), por lo que puede utilizar el servicio de Kubernetes que mejor se adapte a su entorno.

La instalación de un operador de cass en su propio clúster de Kubernetes es un proceso simple si tiene conocimientos básicos sobre cómo ejecutar un clúster de Kubernetes. Una vez que su clúster de Kubernetes esté autenticado, usando kubectl, la herramienta de línea de comandos del clúster de Kubernetes, y su instancia de nube de Kubernetes (ya sea Kubernetes de código abierto, GKE, EKS o PKS) esté conectada a su máquina local, puede comenzar a aplicar cass- archivos YAML de configuración del operador a su clúster.

Configuración de las definiciones de operador de cass

La siguiente etapa es aplicar las definiciones para el manifiesto de operador de cass, la clase de almacenamiento y el centro de datos al clúster de Kubernetes.

Una nota rápida sobre la definición del centro de datos. Esto se basa en las definiciones utilizadas en Cassandra en lugar de una referencia a un centro de datos físico.

La jerarquía para esto es la siguiente:

  • Un nodo se refiere a un sistema informático que ejecuta una instancia de Cassandra. Un nodo puede ser un host físico, una instancia de máquina en la nube o incluso un contenedor Docker.
  • Un bastidor se refiere a un conjunto de nodos Cassandra cercanos entre sí. Un bastidor puede ser un bastidor físico que contiene nodos conectados a un conmutador de red común. Sin embargo, en las implementaciones en la nube, un rack a menudo se refiere a una colección de instancias de máquinas que se ejecutan en la misma zona de disponibilidad.
  • Un centro de datos se refiere a una colección de racks lógicos, que generalmente residen en el mismo edificio y están conectados por una red confiable. En las implementaciones en la nube, los centros de datos generalmente se asignan a una región de la nube.
  • Un clúster se refiere a una colección de centros de datos que admiten la misma aplicación. Los clústeres de Cassandra pueden ejecutarse en un solo entorno de nube o centro de datos físico, o distribuirse en múltiples ubicaciones para una mayor resiliencia y una latencia reducida.

Ahora que hemos confirmado nuestras convenciones de nomenclatura, es hora de configurar las definiciones. Nuestro ejemplo usa GKE, pero el proceso es similar para otros motores de Kubernetes. Hay tres pasos. 

Paso 1

Primero, necesitamos ejecutar un comando kubectl que hace referencia a un archivo de configuración YAML. Esto aplica las definiciones del manifiesto de operador de cass al clúster de Kubernetes conectado. Los manifiestos son descripciones de objetos de la API, que describen el estado deseado del objeto, en este caso, su operador de Cassandra. Para obtener un conjunto completo de manifiestos específicos de la versión, consulte esta página de GitHub.

A continuación, se muestra un comando de kubectl de ejemplo para la nube de GKE que ejecuta Kubernetes 1.16:

kubectl create -f //raw.githubusercontent.com/datastax/cass-operator/v1.3.0/docs/user/cass-operator-manifests-v1.16.yaml

Paso 2

El siguiente comando de kubectl aplica una configuración YAML que define la configuración de almacenamiento que se utilizará para los nodos de Cassandra en un clúster. Kubernetes utiliza el recurso StorageClass como una capa de abstracción entre los pods que necesitan almacenamiento persistente y los recursos de almacenamiento físico que puede proporcionar un clúster de Kubernetes específico. El ejemplo usa SSD como tipo de almacenamiento. Para obtener más opciones, consulte esta página de GitHub. Aquí está el enlace directo al YAML aplicado en la configuración de almacenamiento, a continuación:

apiVersion: storage.k8s.io/v1

tipo: StorageClass

metadatos:

  nombre: servidor-almacenamiento

aprovisionador: kubernetes.io/gce-pd

parámetros:

  tipo: pd-ssd

  tipo de replicación: ninguna

volumeBindingMode: WaitForFirstConsumer

reclaimPolicy: Eliminar

Paso 3

Finalmente, usando kubectl nuevamente, aplicamos YAML que define nuestro Cassandra Datacenter.

# Tamaño para trabajar en 3 nodos de trabajadores k8s con 1 núcleo / 4 GB de RAM

# Consulte el vecino example-cassdc-full.yaml para obtener los documentos de cada parámetro

apiVersion: cassandra.datastax.com/v1beta1

tipo: CassandraDatacenter

metadatos:

  nombre: dc1

Especificaciones:

  clusterName: cluster1

  serverType: cassandra

  serverVersion: "3.11.6"

  managementApiAuth:

    inseguro: {}

  tamaño: 3

  storageConfig:

    cassandraDataVolumeClaimSpec:

      storageClassName: servidor-almacenamiento

      accessModes:

        - ReadWriteOnce

      recursos:

        peticiones:

          almacenamiento: 5Gi

  config:   

    cassandra-yaml:

      autenticador: org.apache.cassandra.auth.PasswordAuthenticator

      autorizador: org.apache.cassandra.auth.CassandraAuthorizer

      role_manager: org.apache.cassandra.auth.CassandraRoleManager

    jvm-opciones:

      initial_heap_size: "800M"

      max_heap_size: "800M"

Este YAML de ejemplo es para una imagen Apache Cassandra 3.11.6 de código abierto, con tres nodos en un bastidor, en el clúster de Kubernetes. Aquí está el enlace directo. Hay un conjunto completo de configuraciones de centros de datos específicas de la base de datos en esta página de GitHub.

En este punto, podrá ver los recursos que ha creado. Estos serán visibles en su consola en la nube. En Google Cloud Console, por ejemplo, puede hacer clic en la pestaña Clústeres para ver qué se está ejecutando y ver las cargas de trabajo. Se trata de unidades informáticas desplegables que se pueden crear y gestionar en el clúster de Kubernetes.

Para conectarse a una base de datos de Cassandra implementada, puede usar cqlsh, el shell de línea de comandos, y consultar a Cassandra usando CQL desde su clúster de Kubernetes. Una vez autenticado, podrá enviar comandos DDL para crear o alterar tablas, etc. y manipular datos con instrucciones DML, como insertar y actualizar en CQL.

¿Qué sigue para Cassandra y Kubernetes?

Si bien hay varios operadores disponibles para Apache Cassandra, ha existido la necesidad de un operador común. Las empresas involucradas en la comunidad de Cassandra, como Sky, Orange, DataStax e Instaclustr, están colaborando para establecer un operador común para Apache Cassandra en Kubernetes. Este esfuerzo de colaboración va de la mano de los operadores de código abierto existentes, y el objetivo es proporcionar a las empresas y usuarios una pila de escalamiento horizontal consistente para cómputo y datos.

Con el tiempo, el cambio a aplicaciones nativas de la nube también tendrá que ser compatible con datos nativos de la nube. Esto dependerá de una mayor automatización, impulsada por herramientas como Kubernetes. Al usar Kubernetes y Cassandra juntos, puede hacer que su enfoque de datos sea nativo de la nube.

Para obtener más información sobre Cassandra y Kubernetes, visite //www.datastax.com/dev/kubernetes. Para obtener más información sobre cómo ejecutar Cassandra en la nube, consulte DataStax Astra. 

Patrick McFadin es el vicepresidente de relaciones con desarrolladores en DataStax, donde dirige un equipo dedicado a hacer que los usuarios de Apache Cassandra tengan éxito. También ha trabajado como evangelista jefe de Apache Cassandra y consultor de DataStax, donde ayudó a construir algunas de las implementaciones más grandes y emocionantes en producción. Antes de DataStax, fue arquitecto en jefe en Hobsons y desarrollador / DBA de Oracle durante más de 15 años.

-

New Tech Forum proporciona un lugar para explorar y discutir la tecnología empresarial emergente con una profundidad y amplitud sin precedentes. La selección es subjetiva, basada en nuestra selección de las tecnologías que creemos que son importantes y de mayor interés para los lectores. no acepta material de marketing para su publicación y se reserva el derecho de editar todo el contenido contribuido. Envíe todas sus consultas a [email protected]