Wie man Cassandra und Kubernetes zusammen laufen lässt

Container sind bei Entwicklern, die Anwendungen in der Cloud bereitstellen möchten, immer beliebter geworden. Um diese neuen Anwendungen zu verwalten, ist Kubernetes ein De-facto-Standard für die Container-Orchestrierung geworden. Mit Kubernetes können Entwickler verteilte Anwendungen erstellen, die je nach Bedarf automatisch elastisch skaliert werden.

Kubernetes wurde entwickelt, um zustandslose Anwendungs-Workloads in der Produktion mühelos bereitzustellen, zu skalieren und zu verwalten. Wenn es um zustandsbehaftete, Cloud-native Daten geht, war die gleiche einfache Bereitstellung und Skalierung erforderlich.

In verteilten Datenbanken spricht Cassandra Entwickler an, die wissen, dass sie ihre Daten skalieren müssen. Es bietet einen vollständig fehlertoleranten Datenbank- und Datenverwaltungsansatz, der auf mehrere Standorte und Cloud-Services hinweg auf dieselbe Weise ausgeführt werden kann. Da alle Knoten in Cassandra gleich sind und jeder Knoten Lese- und Schreibanforderungen verarbeiten kann, gibt es im Cassandra-Modell keinen einzelnen Fehlerpunkt. Daten werden automatisch zwischen Fehlerzonen repliziert, um den Verlust einer einzelnen Instanz zu verhindern, die sich auf die Anwendung auswirkt.

Cassandra mit Kubernetes verbinden

Der logische nächste Schritt besteht darin, Cassandra und Kubernetes zusammen zu verwenden. Wenn eine verteilte Datenbank zusammen mit einer verteilten Anwendungsumgebung ausgeführt wird, ist es schließlich einfacher, Daten- und Anwendungsvorgänge nahe beieinander auszuführen. Dies vermeidet nicht nur Latenz, sondern kann auch dazu beitragen, die Leistung im Maßstab zu verbessern.

Um dies zu erreichen, muss man jedoch verstehen, welches System zuständig ist. Cassandra verfügt bereits über die Fehlertoleranz und Knotenplatzierung, die Kubernetes liefern kann. Daher ist es wichtig zu wissen, welches System für die Entscheidungsfindung zuständig ist. Dies wird durch die Verwendung eines Kubernetes-Operators erreicht.

Bediener automatisieren den Prozess der Bereitstellung und Verwaltung komplexerer Anwendungen, die domänenspezifische Informationen erfordern und mit externen Systemen interagieren müssen. Bis zur Entwicklung von Operatoren führten zustandsbehaftete Anwendungskomponenten wie Datenbankinstanzen zu zusätzlichen Verantwortlichkeiten für Entwicklerteams, da sie manuelle Arbeit leisten mussten, um ihre Instanzen auf zustandsbehaftete Weise vorzubereiten und auszuführen.

Es gibt mehrere Operatoren für Cassandra, die von der Cassandra-Community entwickelt wurden. In diesem Beispiel verwenden wir den Cass-Operator, der von DataStax zusammengestellt und als Open-Source-Version bereitgestellt wurde. Es unterstützt Open-Source-Kubernetes, Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) und Pivotal Container Service (PKS), sodass Sie den Kubernetes-Dienst verwenden können, der am besten zu Ihrer Umgebung passt.

Das Installieren eines Cass-Operators in Ihrem eigenen Kubernetes-Cluster ist ein einfacher Vorgang, wenn Sie über Grundkenntnisse zum Ausführen eines Kubernetes-Clusters verfügen. Sobald Ihr Kubernetes-Cluster mithilfe von kubectl, dem Kubernetes-Cluster-Befehlszeilentool und Ihrer Kubernetes-Cloud-Instanz (ob Open-Source-Kubernetes, GKE, EKS oder PKS) mit Ihrem lokalen Computer verbunden ist, können Sie mit der Anwendung von Cass- beginnen. YAML-Dateien für die Bedienerkonfiguration in Ihrem Cluster.

Einrichten Ihrer Cass-Operator-Definitionen

In der nächsten Phase werden die Definitionen für das Cass-Operator-Manifest, die Speicherklasse und das Rechenzentrum auf den Kubernetes-Cluster angewendet.

Ein kurzer Hinweis zur Definition des Rechenzentrums. Dies basiert auf den in Cassandra verwendeten Definitionen und nicht auf einem physischen Rechenzentrum.

Die Hierarchie hierfür lautet wie folgt:

  • Ein Knoten bezieht sich auf ein Computersystem, auf dem eine Instanz von Cassandra ausgeführt wird. Ein Knoten kann ein physischer Host, eine Maschineninstanz in der Cloud oder sogar ein Docker-Container sein.
  • Ein Rack bezieht sich auf eine Reihe von Cassandra-Knoten in der Nähe. Ein Rack kann ein physisches Rack sein, das Knoten enthält, die mit einem gemeinsamen Netzwerk-Switch verbunden sind. In Cloud-Bereitstellungen bezieht sich ein Rack jedoch häufig auf eine Sammlung von Computerinstanzen, die in derselben Verfügbarkeitszone ausgeführt werden.
  • Ein Rechenzentrum bezieht sich auf eine Sammlung logischer Racks, die sich im Allgemeinen im selben Gebäude befinden und über ein zuverlässiges Netzwerk verbunden sind. In Cloud-Bereitstellungen werden Rechenzentren im Allgemeinen einer Cloud-Region zugeordnet.
  • Ein Cluster bezieht sich auf eine Sammlung von Rechenzentren, die dieselbe Anwendung unterstützen. Cassandra-Cluster können in einer einzelnen Cloud-Umgebung oder einem physischen Rechenzentrum ausgeführt oder auf mehrere Standorte verteilt werden, um die Ausfallsicherheit zu erhöhen und die Latenz zu verringern

Nachdem wir unsere Namenskonventionen bestätigt haben, ist es Zeit, Definitionen einzurichten. In unserem Beispiel wird GKE verwendet, aber der Prozess ist für andere Kubernetes-Engines ähnlich. Es gibt drei Schritte. 

Schritt 1

Zuerst müssen wir einen kubectl-Befehl ausführen, der auf eine YAML-Konfigurationsdatei verweist. Dadurch werden die Definitionen des Cass-Operator-Manifests auf den verbundenen Kubernetes-Cluster angewendet. Manifeste sind API-Objektbeschreibungen, die den gewünschten Status des Objekts beschreiben, in diesem Fall Ihren Cassandra-Operator. Auf dieser GitHub-Seite finden Sie einen vollständigen Satz versionenspezifischer Manifeste.

Hier ist ein Beispiel für einen kubectl-Befehl für die GKE-Cloud, auf der Kubernetes 1.16 ausgeführt wird:

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

Schritt 2

Der nächste Befehl kubectl wendet eine YAML-Konfiguration an, die die Speichereinstellungen definiert, die für Cassandra-Knoten in einem Cluster verwendet werden sollen. Kubernetes verwendet die StorageClass-Ressource als Abstraktionsschicht zwischen Pods, die dauerhaften Speicher benötigen, und den physischen Speicherressourcen, die ein bestimmter Kubernetes-Cluster bereitstellen kann. In diesem Beispiel wird SSD als Speichertyp verwendet. Weitere Optionen finden Sie auf dieser GitHub-Seite. Hier ist der direkte Link zu der YAML, die in der Speicherkonfiguration unten angewendet wird:

apiVersion: storage.k8s.io/v1

Art: StorageClass

Metadaten:

  Name: Server-Speicher

Provisioner: kubernetes.io/gce-pd

Parameter:

  Typ: pd-ssd

  Replikationstyp: keine

volumeBindingMode: WaitForFirstConsumer

reclaimPolicy: Löschen

Schritt 3

Schließlich wenden wir mit kubectl wieder YAML an, das unser Cassandra-Datencenter definiert.

# Größe für 3 k8s-Worker-Knoten mit 1 Kern / 4 GB RAM

# Dokumente für jeden Parameter finden Sie im benachbarten Beispiel-cassdc-full.yaml

apiVersion: cassandra.datastax.com/v1beta1

Art: CassandraDatacenter

Metadaten:

  Name: dc1

spec:

  clusterName: cluster1

  serverType: cassandra

  serverVersion: "3.11.6"

  managementApiAuth:

    unsicher: {}

  Größe: 3

  storageConfig:

    cassandraDataVolumeClaimSpec:

      storageClassName: Serverspeicher

      accessModes:

        - ReadWriteOnce

      Ressourcen:

        Anfragen:

          Lagerung: 5Gi

  config:   

    Cassandra-Yaml:

      Authentifikator: org.apache.cassandra.auth.PasswordAuthenticator

      Autorisierer: org.apache.cassandra.auth.CassandraAuthorizer

      role_manager: org.apache.cassandra.auth.CassandraRoleManager

    JVM-Optionen:

      initial_heap_size: "800M"

      max_heap_size: "800M"

Dieses Beispiel YAML ist für ein Open-Source-Image von Apache Cassandra 3.11.6 mit drei Knoten auf einem Rack im Kubernetes-Cluster. Hier ist der direkte Link. Auf dieser GitHub-Seite finden Sie einen vollständigen Satz datenbankspezifischer Datencenter-Konfigurationen.

An diesem Punkt können Sie die von Ihnen erstellten Ressourcen anzeigen. Diese werden in Ihrer Cloud-Konsole angezeigt. In der Google Cloud Console können Sie beispielsweise auf die Registerkarte Cluster klicken, um zu sehen, was ausgeführt wird, und die Workloads anzeigen. Hierbei handelt es sich um bereitstellbare Computereinheiten, die im Kubernetes-Cluster erstellt und verwaltet werden können.

Um eine Verbindung zu einer bereitgestellten Cassandra-Datenbank selbst herzustellen, können Sie cqlsh, die Befehlszeilen-Shell, verwenden und Cassandra mithilfe von CQL in Ihrem Kubernetes-Cluster abfragen. Nach der Authentifizierung können Sie DDL-Befehle zum Erstellen oder Ändern von Tabellen usw. senden und Daten mit DML-Anweisungen bearbeiten, z. B. Einfügen und Aktualisieren in CQL.

Was kommt als nächstes für Cassandra und Kubernetes?

Während für Apache Cassandra mehrere Operatoren verfügbar sind, wurde ein gemeinsamer Operator benötigt. An der Cassandra-Community beteiligte Unternehmen wie Sky, Orange, DataStax und Instaclustr arbeiten zusammen, um einen gemeinsamen Betreiber für Apache Cassandra auf Kubernetes zu etablieren. Diese Bemühungen zur Zusammenarbeit gehen mit den bestehenden Open-Source-Betreibern einher. Ziel ist es, Unternehmen und Benutzern einen konsistenten Scale-Out-Stack für Computer und Daten zur Verfügung zu stellen.

Mit der Zeit muss die Umstellung auf Cloud-native Anwendungen auch mit Cloud-nativen Daten unterstützt werden. Dies erfordert mehr Automatisierung, angetrieben von Tools wie Kubernetes. Wenn Sie Kubernetes und Cassandra zusammen verwenden, können Sie Ihren Ansatz für Data Cloud-native machen.

Um mehr über Cassandra und Kubernetes zu erfahren, besuchen Sie bitte //www.datastax.com/dev/kubernetes. Weitere Informationen zum Ausführen von Cassandra in der Cloud finden Sie unter DataStax Astra. 

Patrick McFadin ist Vice President für Entwicklerbeziehungen bei DataStax, wo er ein Team leitet, das sich dafür einsetzt, Benutzer von Apache Cassandra erfolgreich zu machen. Er hat auch als Chefevangelist für Apache Cassandra und Berater für DataStax gearbeitet, wo er beim Aufbau einiger der größten und aufregendsten Bereitstellungen in der Produktion half. Vor seiner Zeit bei DataStax war er über 15 Jahre lang Chefarchitekt bei Hobsons und Oracle DBA / Entwickler.

- -

Das New Tech Forum bietet einen Ort, an dem Sie neue Unternehmenstechnologien in beispielloser Tiefe und Breite erkunden und diskutieren können. Die Auswahl ist subjektiv, basierend auf unserer Auswahl der Technologien, die wir für wichtig und für die Leser von größtem Interesse halten. akzeptiert keine Marketingmaterialien zur Veröffentlichung und behält sich das Recht vor, alle eingebrachten Inhalte zu bearbeiten. Senden Sie alle Anfragen an [email protected]