Comment exécuter Cassandra et Kubernetes ensemble

Les conteneurs sont devenus de plus en plus populaires pour les développeurs qui souhaitent déployer des applications dans le cloud. Pour gérer ces nouvelles applications, Kubernetes est devenu un standard de facto pour l'orchestration de conteneurs. Kubernetes permet aux développeurs de créer des applications distribuées qui évoluent automatiquement de manière élastique, en fonction de la demande.

Kubernetes a été développé pour déployer, mettre à l'échelle et gérer sans effort les charges de travail des applications sans état en production. En ce qui concerne les données natives avec état et cloud, il était nécessaire d'avoir la même facilité de déploiement et d'évolutivité.

Dans les bases de données distribuées, Cassandra fait appel aux développeurs qui savent qu'ils devront étendre leurs données - il fournit une base de données et une approche de gestion des données totalement tolérantes aux pannes qui peuvent fonctionner de la même manière sur plusieurs sites et services cloud. Comme tous les nœuds de Cassandra sont égaux et que chaque nœud est capable de gérer les demandes de lecture et d'écriture, il n'y a pas de point de défaillance unique dans le modèle Cassandra. Les données sont automatiquement répliquées entre les zones de défaillance pour éviter la perte d'une seule instance affectant l'application.

Connecter Cassandra à Kubernetes

La prochaine étape logique consiste à utiliser Cassandra et Kubernetes ensemble. Après tout, faire fonctionner une base de données distribuée avec un environnement d'applications distribuées facilite la proximité des opérations de données et d'application. Non seulement cela évite la latence, mais cela peut aider à améliorer les performances à grande échelle.

Pour y parvenir, cependant, il faut comprendre quel système est en charge. Cassandra dispose déjà du type de tolérance aux pannes et de placement de nœuds que Kubernetes peut offrir, il est donc important de savoir quel système est chargé de prendre les décisions. Ceci est réalisé en utilisant un opérateur Kubernetes.

Les opérateurs automatisent le processus de déploiement et de gestion des applications plus complexes qui nécessitent des informations spécifiques au domaine et doivent interagir avec des systèmes externes. Jusqu'à ce que les opérateurs soient développés, les composants d'application avec état tels que les instances de base de données entraînaient des responsabilités supplémentaires pour les équipes de développement, car elles devaient entreprendre un travail manuel pour préparer et exécuter leurs instances avec état.

Il existe plusieurs opérateurs pour Cassandra qui ont été développés par la communauté Cassandra. Pour cet exemple, nous utiliserons cass-operator, qui a été mis en place et open-source par DataStax. Il prend en charge Kubernetes open source, Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) et Pivotal Container Service (PKS), afin que vous puissiez utiliser le service Kubernetes qui convient le mieux à votre environnement.

L'installation d'un opérateur cass sur votre propre cluster Kubernetes est un processus simple si vous avez des connaissances de base sur l'exécution d'un cluster Kubernetes. Une fois votre cluster Kubernetes authentifié, à l'aide de kubectl, de l'outil de ligne de commande du cluster Kubernetes et de votre instance cloud Kubernetes (qu'elle soit open-source Kubernetes, GKE, EKS ou PKS) est connectée à votre machine locale, vous pouvez commencer à appliquer cass- les fichiers YAML de configuration d'opérateur vers votre cluster.

Configuration de vos définitions d'opérateur cass

L'étape suivante consiste à appliquer les définitions du manifeste de l'opérateur cass, de la classe de stockage et du centre de données au cluster Kubernetes.

Une note rapide sur la définition du centre de données. Ceci est basé sur les définitions utilisées dans Cassandra plutôt que sur une référence à un centre de données physique.

La hiérarchie pour cela est la suivante:

  • Un nœud fait référence à un système informatique exécutant une instance de Cassandra. Un nœud peut être un hôte physique, une instance de machine dans le cloud ou même un conteneur Docker.
  • Un rack fait référence à un ensemble de nœuds Cassandra proches les uns des autres. Un rack peut être un rack physique contenant des nœuds connectés à un commutateur réseau commun. Dans les déploiements cloud, cependant, un rack fait souvent référence à un ensemble d'instances de machine s'exécutant dans la même zone de disponibilité.
  • Un centre de données fait référence à un ensemble de racks logiques, résidant généralement dans le même bâtiment et connectés par un réseau fiable. Dans les déploiements cloud, les centres de données sont généralement mappés vers une région cloud.
  • Un cluster fait référence à un ensemble de centres de données prenant en charge la même application. Les clusters Cassandra peuvent s'exécuter dans un seul environnement cloud ou centre de données physique, ou être répartis sur plusieurs sites pour une plus grande résilience et une latence réduite

Maintenant que nous avons confirmé nos conventions de dénomination, il est temps de mettre en place des définitions. Notre exemple utilise GKE, mais le processus est similaire pour les autres moteurs Kubernetes. Il y a trois étapes. 

Étape 1

Tout d'abord, nous devons exécuter une commande kubectl qui fait référence à un fichier de configuration YAML. Cela applique les définitions du manifeste de l'opérateur cass au cluster Kubernetes connecté. Les manifestes sont des descriptions d'objets API, qui décrivent l'état souhaité de l'objet, dans ce cas, votre opérateur Cassandra. Pour obtenir un ensemble complet de manifestes spécifiques à la version, consultez cette page GitHub.

Voici un exemple de commande kubectl pour le cloud GKE exécutant Kubernetes 1.16:

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

Étape 2

La commande kubectl suivante applique une configuration YAML qui définit les paramètres de stockage à utiliser pour les nœuds Cassandra dans un cluster. Kubernetes utilise la ressource StorageClass comme couche d'abstraction entre les pods nécessitant un stockage persistant et les ressources de stockage physique qu'un cluster Kubernetes spécifique peut fournir. L'exemple utilise SSD comme type de stockage. Pour plus d'options, consultez cette page GitHub. Voici le lien direct vers le YAML appliqué dans la configuration de stockage, ci-dessous:

apiVersion: storage.k8s.io/v1

genre: StorageClass

métadonnées:

  nom: serveur-stockage

approvisionneur: kubernetes.io/gce-pd

paramètres:

  type: pd-ssd

  type de réplication: aucun

volumeBindingMode: WaitForFirstConsumer

reclaimPolicy: Supprimer

Étape 3

Enfin, en utilisant à nouveau kubectl, nous appliquons YAML qui définit notre centre de données Cassandra.

# Dimensionné pour fonctionner sur 3 nœuds de travail k8s avec 1 cœur / 4 Go de RAM

# Voir example-cassdc-full.yaml voisin pour la documentation de chaque paramètre

apiVersion: cassandra.datastax.com/v1beta1

genre: CassandraDatacenter

métadonnées:

  nom: dc1

spec:

  clusterName: cluster1

  serverType: cassandra

  serverVersion: "3.11.6"

  managementApiAuth:

    peu sûr: {}

  taille: 3

  storageConfig:

    cassandraDataVolumeClaimSpec:

      storageClassName: stockage-serveur

      accessModes:

        - ReadWriteOnce

      Ressources:

        demandes:

          stockage: 5Gi

  config:   

    cassandra-yaml:

      authentificateur: org.apache.cassandra.auth.PasswordAuthenticator

      autorisateur: org.apache.cassandra.auth.CassandraAuthorizer

      role_manager: org.apache.cassandra.auth.CassandraRoleManager

    jvm-options:

      initial_heap_size: "800M"

      max_heap_size: "800M"

Cet exemple YAML concerne une image Apache Cassandra 3.11.6 open-source, avec trois nœuds sur un rack, dans le cluster Kubernetes. Voici le lien direct. Il existe un ensemble complet de configurations de centre de données spécifiques à la base de données sur cette page GitHub.

À ce stade, vous pourrez consulter les ressources que vous avez créées. Ceux-ci seront visibles dans votre console cloud. Dans la console Google Cloud, par exemple, vous pouvez cliquer sur l'onglet Clusters pour voir ce qui est en cours d'exécution et consulter les charges de travail. Ce sont des unités informatiques déployables qui peuvent être créées et gérées dans le cluster Kubernetes.

Pour vous connecter à une base de données Cassandra déployée elle-même, vous pouvez utiliser cqlsh, le shell de ligne de commande, et interroger Cassandra à l'aide de CQL à partir de votre cluster Kubernetes. Une fois authentifié, vous pourrez soumettre des commandes DDL pour créer ou modifier des tables, etc., et manipuler des données avec des instructions DML, telles que l'insertion et la mise à jour dans CQL.

Quelle est la prochaine étape pour Cassandra et Kubernetes?

Bien qu'il existe plusieurs opérateurs disponibles pour Apache Cassandra, un opérateur commun a été nécessaire. Les entreprises impliquées dans la communauté Cassandra, telles que Sky, Orange, DataStax et Instaclustr, collaborent pour établir un opérateur commun pour Apache Cassandra sur Kubernetes. Cet effort de collaboration va de pair avec les opérateurs open source existants, et le but est de fournir aux entreprises et aux utilisateurs une pile évolutive cohérente pour le calcul et les données.

Au fil du temps, le passage aux applications cloud natives devra également être pris en charge avec des données cloud natives. Cela reposera sur plus d'automatisation, pilotée par des outils comme Kubernetes. En utilisant Kubernetes et Cassandra ensemble, vous pouvez rendre votre approche native du cloud de données.

Pour en savoir plus sur Cassandra et Kubernetes, rendez-vous sur //www.datastax.com/dev/kubernetes. Pour plus d'informations sur l'exécution de Cassandra dans le cloud, consultez DataStax Astra. 

Patrick McFadin est le vice-président des relations avec les développeurs chez DataStax, où il dirige une équipe dédiée à la réussite des utilisateurs d'Apache Cassandra. Il a également travaillé en tant qu'évangéliste en chef pour Apache Cassandra et consultant pour DataStax, où il a aidé à construire certains des déploiements les plus importants et passionnants en production. Avant DataStax, il a été architecte en chef chez Hobsons et développeur / DBA Oracle pendant plus de 15 ans.

-

Le New Tech Forum offre un lieu pour explorer et discuter des technologies d'entreprise émergentes avec une profondeur et une ampleur sans précédent. La sélection est subjective, basée sur notre choix des technologies que nous pensons importantes et qui intéressent le plus les lecteurs. n'accepte pas les supports marketing pour la publication et se réserve le droit de modifier tout le contenu fourni. Envoyez toutes vos demandes à [email protected]