Selbstverwalteter Couchbase auf Kubernetes
Couchbase Kubernetes-Operator
Der Kubernetes-Operator stellt Couchbase für Sie bereit, skaliert sie, repariert sie und aktualisiert sie. Ihr Plattformteam verwaltet die Datenbank wie jede andere Arbeitslast – mit der Ausnahme, dass die Seiten um 2 Uhr morgens nicht mehr benötigt werden.

Kubernetes kennt Pods. Wir kennen Couchbase.
Kubernetes ist hervorragend bei der Ersetzung von Pods. Eine Datenbank muss ebenfalls neu ausgerichtet, die Replika-Placements angepasst und sichere Upgrades durchgeführt werden. Unser Operator übernimmt diese Aufgaben für Sie.

Fahren Sie schneller auf der Plattform, die Sie bereits verwenden
Wenn die Datenbank außerhalb Ihrer Plattform läuft, wartet jede Änderung auf ein Ticket. Hier handelt es sich um YAML in Git, das überprüft und als Code bereitgestellt wird.

Bleiben Sie ohne Wochenendwartungsfenster auf dem neuesten Stand
Auf die Aktualisierungen verzichten lohnt sich nicht, da die Sicherheitsrisiken steigen. Die Aktualisierungen werden nacheinander durchgeführt, während die Apps laufen, und man kann sie auch jederzeit rückgängig machen.

Weniger Ausfälle, weniger 2 Uhr-Seiten
Wenn ein Pod oder ein Knoten fehlschlägt, ersetzt der Operator ihn, nutzt seine Speicherkapazität erneut und stellt die Daten neu aus. Nur das wird angezeigt, was eine menschliche Überprüfung erfordert.

Halten Sie die Kontrolle über Ihre Daten und Ihre Ausgaben bei
Nutzen Sie die bereits vorhandene Kubernetes-Kapazität, ob in Ihrem eigenen Rechenzentrum oder in einer Cloud. Führen Sie die Datensicherheits- und Compliance-Regeln nach Ihren Vorgaben durch.
Was ist der Couchbase Kubernetes Operator?
Couchbase Server wird für Sie auf Kubernetes ausgeführt. Sie geben einfach in YAML an, was Sie möchten, und der Operator stellt den Cluster so zusammen, dass er immer dieselbe Struktur hat.
Der Operator fügt Couchbase-Typen zu Kubernetes hinzu, wie CouchbaseCluster, CouchbaseBucket und CouchbaseBackup. Sie schreiben, was Sie möchten, und der Operator vergleicht dies mit dem, was bereits läuft, und korrigiert den Unterschied den ganzen Tag über. Ein Admission Controller weist schlechte Konfigurationen ab, bevor sie gespeichert werden, sodass Fehler in Ihrem Terminal angezeigt werden, nicht in Ihrem Incident Channel.
Ein generisches StatefulSet startet wieder neue Pods. Der Operator versteht Couchbase. Er rebalanciert die Daten, bevor er weiterläuft, platziert Repliken in verschiedenen Zonen und nutzt persistenten Datenträgern erneut, sodass ein ausgetauschter Pod nur die jüngsten Änderungen nachholen kann. Während Kubernetes-Upgrades kann nur ein Couchbase-Pod gleichzeitig gestartet werden, sodass Knotenverluste keine Datenverluste zur Folge haben.
Version 2.9 unterstützt Kubernetes 1.31 bis 1.36, Red Hat OpenShift 4.18 bis 4.20, Amazon EKS, Google GKE, Microsoft AKS, K3s und Bottlerocket OS auf x86 oder ARM. Sieht man etwas anderes? Ein Selbstzertifizierungstool prüft Ihre Plattform, Speicher und Netzwerk, und Couchbase überprüft die Ergebnisse. On-Premise-Funktionalität ist ebenfalls möglich, mit Bildern aus Ihrem eigenen Registry.
Der Anbieter verwendet die Couchbase Server Enterprise Edition, Versionen 7.2 bis 8.0. Das ist der gleiche Engine wie bei Capella, sodass Ihre SDKs, SQL++-Abfragen und Datenmodelle überall funktionieren. Die Cross-Data-Center-Replikation (XDCR) verbindet Cluster auf Kubernetes, VMs und Capella, sodass eine Hybrid- oder die Umstellung zwischen diesen eine Konfigurationsänderung ist und kein Migrationsprojekt darstellt.
Funktioniert im Autopilotmodus, jeweils eine vorsichtige Portion pro Mal
5 von 5
Kubernetes Operator-Funktionsstufe: Auto Pilot, die höchste Stufe
1 Pod
Die meisten Betreiber erlauben es Kubernetes, bei Upgrades sofort zu entfernen.
Ergebnisse der COUCHBASE-SERVER-KUNDEN
Entwickelt für Anwendungen, die nicht heruntergefahren werden können
Unter dem Deckel
Alles, was Operationsteams an Tag 2 benötigen, wird in YAML abgebildet.
Wie der Administrator Couchbase betreibt, skaliert, aktualisiert, schützt und sichert, damit Ihr Team dies nicht manuell erledigen muss.
- Betreiben
- Skala
- Upgrade
- Schützen
- Sicher
Installieren Sie mit Helm, verwalten Sie es über Git und überwachen Sie alles mit den Tools, die Ihr Plattformteam bereits verwendet.
Wichtige Funktionen, einschließlich der Neuerungen in Operator 2.9
Helm, GitOps und die CLI
Mit einem Helm-Chart kann der Administrator die Konfiguration des Operators, des Admission-Controllers, eines Clusters und sogar Sync Gateway vornehmen. Alle Änderungen werden in Git gespeichert.
Schlechte Konfiguration funktioniert nie
Der Zugriffscontroller überprüft jede Couchbase-Ressource, bevor Kubernetes sie speichert, einschließlich Vertraulichkeiten, Zertifikaten und Speicherklassen.
Alarme bei Bedarf an einem Menschen
Ein Überwachungsdienst meldet Probleme, die der Administrator allein nicht beheben kann, wie beispielsweise abgelaufene Zertifikate oder fehlendes Quorum, über Kubernetes-Events und -Metriken.
Skalieren Sie jede Couchbase-Dienste einzeln, automatisch falls Sie möchten, und deaktivieren Sie die Inaktivitätscluster.
Wichtige Funktionen, einschließlich der Neuerungen in Operator 2.9
Mehrdimensionale Skalierung
Geben Sie Daten-, Index-, Abfrage-, Such- und Analysetools eigene Pods und Hardware zu. Fügen Sie Such-Pods hinzu, ohne weitere Daten-Pods zu kaufen.
Autoscaling mit der Kubernetes HPA
Skalieren Sie jede Dienstleistung anhand von CPU-, Speicher- oder Couchbase-Metriken mithilfe des Horizontal Pod Autoscalers. Es kommt zu keiner Ausfallzeit bei der An- und Abfahrt von Pods.
Hibernate-Idle-Clustern
Stellen Sie Dev- und Testcluster mit einem Feld in den Ruhemodus. Die Berechnungen kehren zum Pool zurück, die Volumes bleiben erhalten, und der Cluster wird wie gewohnt wieder aktiviert.
Erweitern Sie Couchbase und Kubernetes ohne Unterbrechungen und verschieben Sie bestehende Cluster auf Kubernetes, während diese online bleiben.
Wichtige Funktionen, einschließlich der Neuerungen in Operator 2.9
Rollende Upgrades, die Sie steuern können
Ändern Sie das Bild-Tag und der Operator aktualisiert Pod für Pod. Legen Sie die Reihenfolge nach Zone, Klasse oder Service fest und nehmen Sie Pausen zwischen den Schritten.
Kubernetes-Upgrades ohne Datenverlust
Disruption-Budgets und Readiness-Gates ermöglichen es den Knotenstromabläufen, jeweils einen Couchbase-Pod zu verarbeiten und erst dann, wenn die Daten sicher neu verteilt sind.
VM-Clustern auf Kubernetes umstellen
Richten Sie den Operator auf einen Cluster an VMs oder EC2. Er tauscht die Knoten in Kubernetes nacheinander aus, während die Apps weiterhin laufen.
Planmäßige Sicherungen auf Objektspeicher, Replikation zwischen Clustern und Replikate, die über mehrere Zonen verteilt sind.
Wichtige Funktionen, einschließlich der Neuerungen in Operator 2.9
Planmäßige Sicherung und Wiederherstellung
Stellen Sie Pläne als Kubernetes-Ressourcen fest. Die Backups werden von Ihren Couchbase-Nodes ausgeführt und können in S3, Azure Blob oder Google Cloud Storage abgelegt werden.
XDCR zwischen den Clustern
Du kannst die Konfiguration auf einen anderen Kubernetes-Cluster, eine andere Region oder in der Cloud replizieren – entweder auf eine einzige oder auf beide. Neu in 2.9: Konfliktprotokollierung für aktive-aktive Konfigurationen.
Zonenbezogene Platzierung
Servergruppen entsprechen den Verfügbarkeitszonen, sodass die Replikate in einer anderen Zone als die Daten, die sie schützen, gespeichert werden. Sollte eine Zone verloren gehen, bleiben Ihre Daten sicher.
TLS, das sich selbst rotiert, Verschlüsselung im Ruhezustand mit eigenen Schlüsseln und Benutzer und Rollen, die im Code gespeichert sind.
Wichtige Funktionen, einschließlich der Neuerungen in Operator 2.9
TLS, das sich selbst dreht
Verwenden Sie Standard-Kubernetes-TLS-Szenarios oder cert-manager. Drehen Sie Server-, Client- oder CA-Zertifikate und verlangen Sie bei Bedarf eine gegenseitige TLS-Verschlüsselung.
Verschlüsselung im Ruhezustand, Ihre Schlüssel
Für Server 8.0: Verschlüsseln Sie Bucket-, Konfigurations- und Auditlogs mithilfe von Schlüsseln aus AWS KMS, einem KMIP-Schlüsselmanager oder Couchbase selbst.
Benutzer, Rollen und LDAP als Code
Benennen Sie Couchbase-Benutzer, -Gruppen und -Rollen als Kubernetes-Ressourcen, verknüpfen Sie LDAP-Gruppen und rotieren Sie das Administratorpasswort sicher.
- Produktion
- Hybrid
- Migrieren
ARCHITEKTUR
Eine Produktionsknotenstruktur in 3 Zonen

Ein Ausfall einer Zone sollte Ihre App nicht lahmlegen. Jede Zone wird zu einer Couchbase-Servergruppe auf Knoten, die für Couchbase reserviert sind, zusammengefasst. Die Replikate befinden sich also anderswo. Jede Dienstleistung erhält ihre eigenen Pods und Speicher in einer eigenen Zone. cert-manager führt TLS-Rotationen durch und die Backups werden von den Datenbankknoten aus ausgeführt.
ARCHITEKTUR
Eine Topologie für alle Standorte

Einige Daten müssen zu Hause bleiben. Einige Apps leben in der Cloud. Führe dieselben Operator-YAML-Dateien in OpenShift, EKS, AKS oder GKE aus, und verknüpfe sie dann in beide Richtungen mit XDCR. Filter halten regulierte Dokumente im Landesinneren. Führe Capella ein, in Regionen, in denen du nichts ausführen möchtest.
ARCHITEKTUR
VM ohne Ausfall von der Netzwerkanbindung abmelden

Beschreiben Sie Ihren bestehenden Cluster in YAML und weisen Sie den Operator daraufhin. Er fügt ein Pod hinzu, rebalanciert die Daten darauf und entfernt dann Schritt für Schritt einen VM-Node, während die Apps weiterhin mit einem Cluster verbunden bleiben. Sie bestimmen die Reihenfolge und den Tempo, und Sie können bei einer Hybridkonfiguration einen Teilweg unterbrechen.

JETZT LOSLEGEN
Von der Helm-Installation bis zum ersten Cluster
Fügen Sie das Couchbase Helm-Repo hinzu und installieren Sie einen Chart. Sie erhalten den Operator, den Admission Controller und einen funktionsfähigen Couchbase-Cluster, der direkt über die Webkonsole oder ein SDK verbunden werden kann. Sie möchten lieber Schritt für Schritt vorgehen? Die CLI installiert jedes Element einzeln auf Kubernetes oder OpenShift. Lesen Sie die Best Practices-Anleitung vor der Produktion. Sie behandelt Speicher, Scheduling und Fehler, die man besser vermeiden sollte.
Dieselmotor gleicher Bauart, drei verschiedene Betriebsarten
Selbstverantwortung
Couchbase Server
Der Motor, den der Administrator verwendet: JSON, Key-Value, SQL++, Suche, Vektor-Suche und Caching in einer Datenbank. Verwenden Sie ihn mit dem Administrator in Kubernetes oder auf VMs und Bare-Metal-Systemen, je nachdem, wie es für Sie besser passt.
MANAGED CLOUD
Couchbase Capella
Wünschen Sie sich Couchbase ohne die Verwendung von Kubernetes? Capella ist dieselbe Engine, vollständig auf AWS, Google Cloud und Azure verwaltet. Couchbase übernimmt die Einrichtung, die Sicherung, die Skalierung und die Upgrades.
MOBIL UND EDGE
Couchbase Mobile
Couchbase Lite sorgt dafür, dass Apps auch ohne Verbindung auf Smartphones und Edge-Geräten funktionieren. Mit demselben Helm-Chart kann Sync Gateway neben Ihrem Cluster bereitgestellt werden, um diese Geräte synchron zu halten.
FAQ zum Couchbase Kubernetes Operator
Antworten auf häufig gestellte Fragen zu der Nutzung von Couchbase auf Kubernetes und OpenShift.
Unser Kubernetes-Operator, auch als Couchbase Autonomous Operator (CAO) bekannt, stellt selbstverwaltete Couchbase-Server auf Kubernetes und OpenShift bereit, skaliert sie, repariert sie und sichert sie ab sowie aktualisiert sie.
Version 2.9 unterstützt Kubernetes 1.31 bis 1.36, OpenShift 4.18 bis 4.20, Amazon EKS, Google GKE, Microsoft AKS, K3s und Bottlerocket OS auf x86- und ARM-Nutzern.
Es unterstützt die Versionen 7.2 bis 8.0 von Couchbase Server Enterprise Edition. Operator 2.9 konfiguriert außerdem die Funktionen von Version 8.0, wie zum Beispiel die Verschlüsselung in der Ruhephase. Die Community Edition wird nicht unterstützt.
Das Operator Framework definiert fünf Leistungsstufen, von Basic Install bis Auto Pilot. Der Couchbase-Operator ist auf Level 5, Auto Pilot, eingestuft. Die Anbieter bewerten sich selbst, also probieren Sie es einfach aus und bewerten Sie es.
Ja. Richten Sie den Operator auf einen Cluster an VMs oder EC2 und er wird die Knoten einzeln in Kubernetes umstellen. Apps bleiben verbunden, und beide Seiten benötigen Netzwerkzugriff.
Beide verwenden dieselbe Couchbase-Engine. Mit dem Operator kann Ihr Team Couchbase auf Ihrem eigenen Kubernetes-System betreiben. Mit Capella kann Couchbase diese für Sie auf AWS, Google Cloud oder Azure bereitstellen.



