Come eseguire Cassandra e Kubernetes insieme

I contenitori sono diventati sempre più popolari per gli sviluppatori che desiderano distribuire applicazioni nel cloud. Per gestire queste nuove applicazioni, Kubernetes è diventato uno standard de facto per l'orchestrazione dei container. Kubernetes consente agli sviluppatori di creare applicazioni distribuite che scalano automaticamente in modo elastico, a seconda della domanda.

Kubernetes è stato sviluppato per distribuire, scalare e gestire senza problemi i carichi di lavoro delle applicazioni senza stato in produzione. Quando si tratta di dati con stato e nativi del cloud, è stata necessaria la stessa facilità di distribuzione e scalabilità.

Nei database distribuiti, Cassandra è interessante per gli sviluppatori che sanno che dovranno scalare i propri dati: fornisce un database completamente tollerante ai guasti e un approccio alla gestione dei dati che può essere eseguito allo stesso modo su più posizioni e servizi cloud. Poiché tutti i nodi in Cassandra sono uguali e ogni nodo è in grado di gestire richieste di lettura e scrittura, non esiste un singolo punto di errore nel modello Cassandra. I dati vengono replicati automaticamente tra le zone di errore per evitare la perdita di una singola istanza che influisce sull'applicazione.

Collegamento di Cassandra a Kubernetes

Il passaggio logico successivo consiste nell'utilizzare Cassandra e Kubernetes insieme. Dopotutto, far funzionare un database distribuito insieme a un ambiente applicativo distribuito rende più facile che i dati e le operazioni dell'applicazione avvengano l'uno vicino all'altro. Ciò non solo evita la latenza, ma può aiutare a migliorare le prestazioni su larga scala.

Per raggiungere questo obiettivo, tuttavia, significa capire quale sistema è in carica. Cassandra ha già il tipo di tolleranza agli errori e posizionamento dei nodi che Kubernetes può fornire, quindi è importante sapere quale sistema è responsabile di prendere le decisioni. Ciò si ottiene utilizzando un operatore Kubernetes.

Gli operatori automatizzano il processo di distribuzione e gestione di applicazioni più complesse che richiedono informazioni specifiche del dominio e devono interagire con sistemi esterni. Fino a quando gli operatori non sono stati sviluppati, i componenti delle applicazioni stateful come le istanze di database hanno comportato responsabilità aggiuntive per i team devops, poiché dovevano intraprendere un lavoro manuale per preparare ed eseguire le loro istanze in modo stateful.

Esistono più operatori per Cassandra che sono stati sviluppati dalla comunità di Cassandra. Per questo esempio, useremo cass-operator, che è stato messo insieme e reso open source da DataStax. Supporta Kubernetes open-source, Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) e Pivotal Container Service (PKS), quindi puoi utilizzare il servizio Kubernetes più adatto al tuo ambiente.

L'installazione di un operatore cass sul tuo cluster Kubernetes è un processo semplice se hai conoscenze di base sull'esecuzione di un cluster Kubernetes. Una volta che il tuo cluster Kubernetes è stato autenticato, utilizzando kubectl, lo strumento da riga di comando del cluster Kubernetes e la tua istanza cloud Kubernetes (sia Kubernetes open-source, GKE, EKS o PKS) è connessa alla tua macchina locale, puoi iniziare ad applicare cass- file YAML di configurazione dell'operatore nel tuo cluster.

Impostazione delle definizioni dell'operatore cass

La fase successiva consiste nell'applicazione delle definizioni per il manifesto dell'operatore cass, la classe di archiviazione e il data center al cluster Kubernetes.

Una breve nota sulla definizione del data center. Questo si basa sulle definizioni utilizzate in Cassandra piuttosto che su un riferimento a un data center fisico.

La gerarchia per questo è la seguente:

  • Un nodo si riferisce a un sistema di computer che esegue un'istanza di Cassandra. Un nodo può essere un host fisico, un'istanza di macchina nel cloud o anche un contenitore Docker.
  • Un rack si riferisce a un insieme di nodi Cassandra vicini l'uno all'altro. Un rack può essere un rack fisico contenente nodi collegati a uno switch di rete comune. Nelle distribuzioni cloud, tuttavia, un rack fa spesso riferimento a una raccolta di istanze di macchine in esecuzione nella stessa zona di disponibilità.
  • Un data center si riferisce a una raccolta di rack logici, generalmente residenti nello stesso edificio e collegati da una rete affidabile. Nelle distribuzioni cloud, i data center generalmente mappano a una regione cloud.
  • Un cluster fa riferimento a una raccolta di data center che supportano la stessa applicazione. I cluster Cassandra possono essere eseguiti in un unico ambiente cloud o in un data center fisico oppure possono essere distribuiti su più posizioni per una maggiore resilienza e una latenza ridotta

Ora che abbiamo confermato le nostre convenzioni di denominazione, è il momento di impostare le definizioni. Il nostro esempio utilizza GKE, ma il processo è simile per altri motori Kubernetes. Ci sono tre passaggi. 

Passo 1

Per prima cosa, dobbiamo eseguire un comando kubectl che fa riferimento a un file di configurazione YAML. Questo applica le definizioni del manifesto dell'operatore cass al cluster Kubernetes connesso. I manifesti sono descrizioni di oggetti API, che descrivono lo stato desiderato dell'oggetto, in questo caso, l'operatore Cassandra. Per un set completo di manifesti specifici della versione, vedere questa pagina GitHub.

Ecco un esempio di comando kubectl per il cloud GKE che esegue Kubernetes 1.16:

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

Passo 2

Il prossimo comando kubectl applica una configurazione YAML che definisce le impostazioni di archiviazione da utilizzare per i nodi Cassandra in un cluster. Kubernetes utilizza la risorsa StorageClass come livello di astrazione tra i pod che necessitano di archiviazione persistente e le risorse di archiviazione fisica che un cluster Kubernetes specifico può fornire. L'esempio utilizza SSD come tipo di archiviazione. Per ulteriori opzioni, vedere questa pagina GitHub. Ecco il collegamento diretto allo YAML applicato nella configurazione di archiviazione, di seguito:

apiVersion: storage.k8s.io/v1

tipo: StorageClass

metadati:

  nome: server-storage

provisioner: kubernetes.io/gce-pd

parametri:

  digitare: pd-ssd

  tipo di replica: nessuno

volumeBindingMode: WaitForFirstConsumer

reclaimPolicy: Elimina

Passaggio 3

Infine, usando nuovamente kubectl, applichiamo YAML che definisce il nostro Cassandra Datacenter.

# Dimensionato per funzionare su 3 nodi di lavoro k8 con 1 core / 4 GB di RAM

# Vedere il vicino esempio-cassdc-full.yaml per i documenti per ogni parametro

apiVersion: cassandra.datastax.com/v1beta1

tipo: CassandraDatacenter

metadati:

  nome: dc1

spec:

  clusterName: cluster1

  serverType: cassandra

  serverVersion: "3.11.6"

  managementApiAuth:

    insicuro: {}

  dimensione: 3

  storageConfig:

    cassandraDataVolumeClaimSpec:

      storageClassName: server-storage

      accessModes:

        - ReadWriteOnce

      risorse:

        richieste:

          conservazione: 5Gi

  config:   

    cassandra-yaml:

      autenticatore: org.apache.cassandra.auth.PasswordAuthenticator

      autore: org.apache.cassandra.auth.CassandraAuthorizer

      role_manager: org.apache.cassandra.auth.CassandraRoleManager

    jvm-opzioni:

      dimensione_heap_iniziale: "800 M"

      max_heap_size: "800 M"

Questo esempio YAML è per un'immagine Apache Cassandra 3.11.6 open source, con tre nodi su un rack, nel cluster Kubernetes. Ecco il link diretto. In questa pagina GitHub è disponibile un set completo di configurazioni del data center specifiche del database.

A questo punto, sarai in grado di guardare le risorse che hai creato. Questi saranno visibili nella tua console cloud. Nella Google Cloud Console, ad esempio, puoi fare clic sulla scheda Cluster per vedere cosa è in esecuzione e guardare i carichi di lavoro. Si tratta di unità di elaborazione distribuibili che possono essere create e gestite nel cluster Kubernetes.

Per connetterti a un database Cassandra distribuito, puoi utilizzare cqlsh, la shell della riga di comando, ed eseguire query su Cassandra utilizzando CQL dal tuo cluster Kubernetes. Una volta autenticato, sarai in grado di inviare comandi DDL per creare o modificare tabelle, ecc., E manipolare i dati con istruzioni DML, come inserimento e aggiornamento in CQL.

Quali sono le prospettive per Cassandra e Kubernetes?

Sebbene siano disponibili diversi operatori per Apache Cassandra, è stato necessario un operatore comune. Le aziende coinvolte nella comunità di Cassandra, come Sky, Orange, DataStax e Instaclustr, stanno collaborando per stabilire un operatore comune per Apache Cassandra su Kubernetes. Questo sforzo di collaborazione va di pari passo con gli operatori open source esistenti e l'obiettivo è fornire alle aziende e agli utenti uno stack di scalabilità orizzontale coerente per elaborazione e dati.

Nel tempo, il passaggio ad applicazioni cloud native dovrà essere supportato anche con dati cloud-native. Ciò dipenderà da una maggiore automazione, guidata da strumenti come Kubernetes. Utilizzando Kubernetes e Cassandra insieme, puoi rendere il tuo approccio nativo al cloud di dati.

Per ulteriori informazioni su Cassandra e Kubernetes, visitare //www.datastax.com/dev/kubernetes. Per ulteriori informazioni sull'esecuzione di Cassandra nel cloud, consulta DataStax Astra. 

Patrick McFadin è il vicepresidente delle relazioni con gli sviluppatori presso DataStax, dove guida un team dedicato al successo degli utenti di Apache Cassandra. Ha anche lavorato come chief evangelist per Apache Cassandra e consulente per DataStax, dove ha contribuito a creare alcune delle più grandi ed entusiasmanti implementazioni in produzione. Prima di DataStax, è stato capo architetto presso Hobsons e sviluppatore / DBA Oracle per oltre 15 anni.

-

Il New Tech Forum offre un luogo per esplorare e discutere la tecnologia aziendale emergente in profondità e ampiezza senza precedenti. La selezione è soggettiva, in base alla nostra scelta delle tecnologie che riteniamo importanti e di maggiore interesse per i lettori. non accetta materiale di marketing per la pubblicazione e si riserva il diritto di modificare tutti i contenuti forniti. Invia tutte le richieste a [email protected]