AlloyDB Omni mit dem Container-Orchestrator installieren

Wählen Sie eine Dokumentationsversion aus:

Auf dieser Seite finden Sie eine Übersicht über den AlloyDB Omni Kubernetes-Operator sowie eine Anleitung zur Verwendung des Operators zum Bereitstellen von AlloyDB Omni in einem Kubernetes-Cluster. Auf dieser Seite werden Grundkenntnisse im Umgang mit Kubernetes-Vorgängen vorausgesetzt.

Eine Anleitung zum Installieren von AlloyDB Omni in einer Standard-Linux-Umgebung finden Sie unter AlloyDB Omni installieren.

Übersicht

Wenn Sie AlloyDB Omni in einem Kubernetes-Cluster bereitstellen möchten, installieren Sie den AlloyDB Omni Kubernetes-Operator, eine von Google bereitgestellte Erweiterung der Kubernetes API.

Sie konfigurieren und steuern einen Kubernetes-basierten AlloyDB Omni-Datenbankcluster, indem Sie deklarative Manifestdateien mit dem kubectl-Dienstprogramm kombinieren, genau wie bei jeder anderen Kubernetes-basierten Bereitstellung. Sie verwenden nicht die AlloyDB Omni-CLI, die für die Bereitstellung auf einzelnen Linux-Maschinen und nicht auf Kubernetes-Clustern vorgesehen ist.

Basis-Image

Ab Version 1.5.0 basieren die Kubernetes-Images des AlloyDB Omni-Operators auf dem Universal Base Image (UBI) 9 von Red Hat. Diese Umstellung verbessert die Sicherheit, Konsistenz und Compliance Ihrer Bereitstellungen.

SHA-Digest-Bildreferenzen

Um Supply-Chain-Angriffe zu verhindern und die Anforderungen der OpenShift-Zertifizierung zu erfüllen, verwendet der AlloyDB Omni-Operator für alle Container-Image-Referenzen SHA-256-Digests anstelle von Versions-Tags.

  • Automatische Upgrades: Der AlloyDB Omni-Operator verwendet einen internen ImageCatalog, um diese Digests zu verwalten und zuverlässige Rollbacks der Datenebene bei fehlgeschlagenen Upgrades zu ermöglichen.

  • Aktivierung: Die Funktion ist standardmäßig für das OpenShift Certified-Paket aktiviert. Nutzer der OLM- oder Helm-Pakete können Digest-Referenzen manuell aktivieren, indem sie die Umgebungsvariable ENABLE_DIGEST_IMAGE_REFS auf true setzen. Verwenden Sie dazu die Abokonfiguration für OLM oder den Wert enableDigestImageRefs im Helm-Diagramm.

Hinweis

Bevor Sie AlloyDB Omni mit dem AlloyDB Omni-Operator in einem Kubernetes-Cluster installieren, müssen die folgenden Anforderungen erfüllt sein.

Download- oder Installationsoption auswählen

Wenn Sie Arbeitslasten in einem generischen Kubernetes-Cluster verwalten, können Sie entweder Helm oder OLM verwenden. Helm ist ein universeller Paketmanager, der Helm-Diagramme verwendet, um beliebige Arbeitslasten, einschließlich Operatoren, in allen Kubernetes-Varianten zu installieren. OLM ist die Standard- und bevorzugte Wahl auf OpenShift-Plattformen und verwaltet Operator-Lebenszyklen mit speziellen OLM-Bundles.

Wählen Sie je nach Umgebung und Tools eine der folgenden Bereitstellungsmethoden aus:

Medien Downloadorte und Installationsanleitungen Bereitstellung für
AlloyDB Omni-Operator mit Helm-Diagramm AlloyDB Omni in Kubernetes installieren Sie können Ihre eigene Kubernetes-Containerumgebung verwenden, z. B. lokal, in öffentlichen Clouds, in GKE, Amazon EKS und Azure AKS.

Tipp: Wenn Ihre Continuous Delivery-Tools (CD) in Helm eingebunden sind, verwenden Sie diese Option.
AlloyDB Omni-Operator mit OLM-Bundle OperatorHub.io Sie können Ihre eigene Kubernetes-Containerumgebung verwenden, z. B. lokal, in öffentlichen Clouds, in Google Kubernetes Engine, Amazon EKS und Azure AKS.

Wenn Sie ein OLM-Bundle verwenden möchten, installieren Sie OLM auf dem Kubernetes-Cluster, bevor Sie den Operator installieren. Weitere Informationen finden Sie unter olm.operatorframework.io.

Tipp: Wenn Ihre CD-Tools (Continuous Delivery) bereits OLM verwenden, wählen Sie diese Option aus.
OpenShift-Operator mit OLM-Bundle Openshift Container Platform Web Console OpenShift-Umgebung

OpenShift, eine Variante von Kubernetes, verwendet OLM als Standardmethode zum Verpacken und Bereitstellen von Operatoren.

Zugriff überprüfen

Prüfen Sie, ob Sie Zugriff auf Folgendes haben:

Hardware- und Softwareanforderungen erfüllen

Jeder Knoten im Kubernetes-Cluster muss Folgendes haben:

  • Mindestens zwei x86- oder AMD64-CPUs
  • Mindestens 8 GB RAM
  • Linux-Kernel-Version 4.18 oder höher
  • Kontrollgruppe (cgroup) v2 aktiviert.

AlloyDB Omni-Operator installieren

Wenn Sie AlloyDB Omni in Ihrer Produktionsumgebung bereitstellen möchten, lesen Sie den Hilfeartikel AlloyDB Omni in der Produktion ausführen.

Sie können den AlloyDB Omni-Operator mit verschiedenen Methoden installieren, darunter Helm und Operator Lifecycle Manager (OLM).

Helm

So installieren Sie den AlloyDB Omni-Operator:

  1. Installieren Sie den AlloyDB Omni-Operator aus der OCI-Registry: 
    helm install alloydbomni-operator oci://gcr.io/alloydb-omni/alloydbomni-operator \
--version 1.8.2 \
--create-namespace \
--namespace alloydb-omni-system \
$(helm install --help | grep -q -- '--rollback-on-failure' && echo '--rollback-on-failure' || echo '--atomic') \
--timeout 5m

    Bei einer erfolgreichen Installation wird die folgende Ausgabe angezeigt:

    NAME: alloydbomni-operator
LAST DEPLOYED: CURRENT_TIMESTAMP
NAMESPACE: alloydb-omni-system
STATUS: deployed
REVISION: 1
TEST SUITE: None

OLM

So installieren Sie den AlloyDB Omni-Operator mit dem Operator Lifecycle Manager:

  1. Rufen Sie die Seite AlloyDB Omni-Operator auf.

  2. Klicken Sie auf Installieren. Falls noch nicht geschehen, folgen Sie der Anleitung, um nur den OLM-Operator und den OperatorHub.io-Katalog zu installieren.

  3. Erstellen Sie den Namespace alloydb-omni-system, falls er noch nicht vorhanden ist.

    kubectl create ns alloydb-omni-system

  4. Richten Sie den OLM OperatorGroup ein, um sicherzustellen, dass der Operator clusterbezogen ist.

    kubectl apply -f - <<EOF
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: operator-sdk-og
  namespace: alloydb-omni-system
spec:
  upgradeStrategy: Default
EOF

  5. Installieren Sie den Operator mithilfe einer OLM-Abo-Ressource.

    kubectl apply -f - <<EOF
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: my-alloydb-omni-operator
  namespace: alloydb-omni-system
spec:
  channel: stable
  name: alloydb-omni-operator
  source: operatorhubio-catalog
  sourceNamespace: olm
EOF

  6. Installieren Sie das Standardzertifikat ClusterIssuer. Dieser Schritt ist optional, wenn Sie benutzerdefinierte Zertifikatsaussteller verwenden.

    kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: alloydbomni-selfsigned-cluster-issuer
spec:
  selfSigned: {}
EOF

OLM

So installieren Sie den AlloyDB Omni-Operator in Ihrer Red Hat OpenShift-Umgebung mit dem OLM:

  1. Melden Sie sich in Ihrer Red Hat OpenShift-Webkonsole an.
  2. Für Offline- oder nicht verbundene Nutzer müssen Sie die erforderlichen Images manuell in Ihre private Registry spiegeln. Verwenden Sie dazu Tools, die SHA-Digests beibehalten, z. B. oc image mirror. Sie müssen einen ImageDigestMirrorSet konfigurieren, um Image-Abrufe aus dem öffentlichen gcr.io-Repository an Ihre private Registry weiterzuleiten. So kann der AlloyDB Omni-Operator die erforderlichen Images mithilfe ihrer unveränderlichen SHA256-Digests abrufen.

  3. Rufen Sie in der OpenShift-Webkonsole Operators > OperatorHub auf. Der AlloyDB Omni-Operator ist in den Katalogen Zertifiziert und Community aufgeführt.

  4. Klicken Sie im Bereich „AlloyDB Omni-Operator“ auf Installieren.

  5. Installieren Sie das Standardzertifikat ClusterIssuer mit den folgenden Befehlen. Dieser Schritt ist optional, wenn Sie benutzerdefinierte Zertifikatsaussteller verwenden.

    kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: alloydbomni-selfsigned-cluster-issuer
spec:
  selfSigned: {}
EOF

GDC Connected Storage konfigurieren

Wenn Sie den AlloyDB Omni-Operator auf einem GDC Connected-Cluster installieren möchten, müssen Sie zusätzliche Schritte ausführen, um den Speicher zu konfigurieren, da für GDC Connected-Cluster keine Standardspeicherklasse festgelegt ist. Sie müssen eine Standardspeicherklasse festlegen, bevor Sie einen AlloyDB Omni-Datenbankcluster erstellen.

Informationen zum Festlegen von Symcloud Storage als Standardspeicherklasse finden Sie unter Symcloud Storage als Standardspeicherklasse festlegen.

Weitere Informationen zum Ändern der Standardeinstellung für alle anderen Speicherklassen finden Sie unter Standard-Speicherklasse ändern.

Datenbankcluster erstellen

Ein AlloyDB Omni-Datenbankcluster enthält alle Speicher- und Rechenressourcen, die zum Ausführen eines AlloyDB Omni-Servers erforderlich sind, einschließlich des primären Servers, aller Replikate und aller Ihrer Daten.

Nachdem Sie in Ihrem Kubernetes-Cluster den AlloyDB Omni-Operator installiert haben, können Sie einen AlloyDB Omni-Datenbankcluster im Kubernetes-Cluster erstellen, indem Sie ein Manifest anwenden, das dem folgenden ähnelt:

apiVersion: v1
kind: Secret
metadata:
  name: db-pw-DB_CLUSTER_NAME
type: Opaque
data:
  DB_CLUSTER_NAME: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: DB_CLUSTER_NAME
spec:
  databaseVersion: "18.3.0"
  primarySpec:
    adminUser:
      passwordRef:
        name: db-pw-DB_CLUSTER_NAME
    resources:
      cpu: CPU_COUNT
      memory: MEMORY_SIZE
      disks:
      - name: DataDisk
        size: DISK_SIZE

Ersetzen Sie Folgendes:

  • DB_CLUSTER_NAME: Der Name dieses Datenbankclusters, z. B. my-db-cluster.

  • ENCODED_PASSWORD: Das Datenbank-Anmeldepasswort für die Standardnutzerrolle postgres, codiert als Base64-String, z. B. Q2hhbmdlTWUxMjM= für ChangeMe123.

  • CPU_COUNT: Die Anzahl der CPUs, die für jede Datenbankinstanz in diesem Datenbankcluster verfügbar sind.

  • MEMORY_SIZE: Die Menge an Arbeitsspeicher pro Datenbankinstanz dieses Datenbankclusters. Wir empfehlen, diesen Wert auf 8 GB pro CPU festzulegen. Wenn Sie beispielsweise cpu weiter oben in diesem Manifest auf 2 gesetzt haben, empfehlen wir, memory auf 16Gi zu setzen.

  • DISK_SIZE: Die Laufwerksgröße pro Datenbankinstanz, z. B. 10Gi.

Nachdem Sie dieses Manifest angewendet haben, enthält Ihr Kubernetes-Cluster einen AlloyDB Omni-Datenbankcluster mit der angegebenen Arbeitsspeicher-, CPU- und Speicherkonfiguration. Informationen zum Herstellen einer Testverbindung mit dem neuen Datenbankcluster finden Sie unter Mit dem vorinstallierten psql verbinden.

Weitere Beispielmanifeste finden Sie unter Beispiele für Kubernetes-Konfigurationen. Weitere Informationen zu Kubernetes-Manifesten und dazu, wie Sie sie anwenden, finden Sie unter Ressourcen verwalten.

Datenbankcluster skalieren

Wenn Sie die Rechenressourcen für Ihren Datenbankcluster skalieren möchten, aktualisieren Sie die Werte cpu und memory in Ihrem db-cluster.yaml-Manifest und wenden Sie die Änderungen an. Der Skalierungsprozess hängt davon ab, ob Sie sich für einen regulären Skalierungsvorgang oder einen Skalierungsvorgang mit geringer Ausfallzeit entscheiden.

Reguläre Skalierung

Wenn Sie die Skalierungsspezifikation aktualisieren und das Manifest ohne weitere Konfiguration anwenden, werden die Datenbank-Pods sofort neu gestartet. Dies führt zu einer kurzen Ausfallzeit der primären und Stand-by-Instanzen, während die neuen Ressourcenzuweisungen wirksam werden.

Skalierung mit geringer Ausfallzeit

Bei Hochverfügbarkeitsclustern mit mindestens einem Standby-Knoten können Sie die Ausfallzeit während der Skalierung minimieren, indem Sie die Strategie „Vorbereiten und wechseln“ für die Wartung mit geringer Ausfallzeit (Low Downtime Maintenance, LDTM) verwenden. Bei dieser Strategie werden die Skalierungsänderungen zuerst auf die Standby-Instanz angewendet, dann wird ein schneller Wechsel durchgeführt und schließlich werden die Änderungen auf die ursprüngliche primäre Instanz angewendet. Mit der LDTM-Strategie können Sie die Anzahl der Instanzen erhöhen oder verringern.

So aktivieren und überwachen Sie die Skalierung mit geringer Ausfallzeit:

  1. Skalierung mit geringer Ausfallzeit aktivieren. Fügen Sie Ihrem Datenbankcluster die Annotation enableLDTM hinzu:

    kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME dbcluster.dbadmin.goog/enableLDTM=true

    Ersetzen Sie DB_CLUSTER_NAME durch den Namen Ihres Datenbankclusters.

  2. Wenden Sie die aktualisierten Skalierungsspezifikationen an. Aktualisieren Sie die Werte cpu und memory unter primarySpec.resources in Ihrem Manifest und wenden Sie die Änderungen an:

    kubectl apply -f db-cluster.yaml

  3. Beobachten Sie den Skalierungsvorgang. Prüfen Sie die Statusbedingung LDTMScalingInProgress, um den Vorgang zu überwachen:

    kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -o yaml | yq '.status.conditions[] | select(.type == "LDTMScalingInProgress")'

    Ersetzen Sie DB_CLUSTER_NAME durch den Namen Ihres Datenbankclusters.

    Während der Prozess läuft, lautet der Status true. Wenn die Skalierung abgeschlossen ist, ändert sich der Status der Bedingung in false.

Beschränkungen

  • Die LDTM-Skalierung wird nur für HA-Cluster mit mindestens einem Standby-Knoten unterstützt.
  • Sie können nicht zwei LDTM-Vorgänge gleichzeitig ausführen. Sie können LDTM beispielsweise entweder zum Skalieren von Datenbankclustern oder zum Durchführen von Upgrades auf Nebenversionen verwenden, aber nicht beides gleichzeitig.
  • Nach einem fehlgeschlagenen LDTM-Skalierungsvorgang müssen Sie manuell ein Rollback durchführen.

Nächste Schritte