Installa AlloyDB Omni utilizzando l'orchestratore dei container

Seleziona una versione della documentazione:

Questa pagina fornisce una panoramica dell'operatore AlloyDB Omni Kubernetes, con istruzioni per utilizzarlo per eseguire il deployment di AlloyDB Omni su un cluster Kubernetes. Questa pagina presuppone una conoscenza di base del funzionamento di Kubernetes.

Per istruzioni sull'installazione di AlloyDB Omni in un ambiente Linux standard, consulta Installare AlloyDB Omni.

Panoramica

Per eseguire il deployment di AlloyDB Omni su un cluster Kubernetes, installa l'operatore AlloyDB Omni Kubernetes, un'estensione dell'API Kubernetes fornita da Google.

Configura e controlla un cluster di database AlloyDB Omni basato su Kubernetes associando i file manifest dichiarativi all'utilità kubectl, proprio come qualsiasi altro deployment basato su Kubernetes. Non utilizzi l'interfaccia a riga di comando AlloyDB Omni, che è destinata ai deployment su singole macchine Linux e non su cluster Kubernetes.

Immagine di base

A partire dalla versione 1.5.0, le immagini Kubernetes dell'operatore AlloyDB Omni sono basate su Universal Base Image (UBI) 9 di Red Hat. Questa transizione migliora la sicurezza, la coerenza e la conformità dei deployment.

Riferimenti alle immagini del digest SHA

Per prevenire gli attacchi alla supply chain e soddisfare i requisiti di certificazione OpenShift, l'operatore AlloyDB Omni utilizza i digest SHA-256 anziché i tag di versione per tutti i riferimenti alle immagini container.

  • Upgrade automatici: l'operatore AlloyDB Omni utilizza un ImageCatalog interno per gestire questi digest e garantire rollback affidabili del piano dati durante gli upgrade non riusciti.

  • Abilitazione: anche se è abilitata per impostazione predefinita per il pacchetto certificato OpenShift, gli utenti dei pacchetti OLM o Helm possono abilitare manualmente i riferimenti ai digest impostando la ENABLE_DIGEST_IMAGE_REFS variabile di ambiente su true utilizzando la configurazione dell'abbonamento per OLM o il valore enableDigestImageRefs nel grafico Helm.

Prima di iniziare

Prima di installare AlloyDB Omni su un cluster Kubernetes con l'operatore AlloyDB Omni, assicurati di soddisfare i seguenti requisiti.

Scegliere un'opzione di download o installazione

Quando gestisci i carichi di lavoro su un cluster Kubernetes generico, puoi utilizzare Helm o OLM. Helm è un gestore di pacchetti universale che utilizza i grafici Helm per installare qualsiasi carico di lavoro, inclusi gli operatori, in tutte le varianti di Kubernetes. OLM, la scelta standard e preferita sulle piattaforme OpenShift, gestisce i cicli di vita degli operatori con bundle OLM specializzati.

In base all'ambiente e agli strumenti, scegli uno dei seguenti metodi di deployment:

Media Posizioni di download e guide all'installazione Deployment su
Operatore AlloyDB Omni con grafico Helm Installare AlloyDB Omni su Kubernetes Ambiente container Kubernetes di tipo Bring Your Own, ad esempio, on-premise, cloud pubblici, GKE, Amazon EKS e Azure AKS.

Suggerimento: se gli strumenti di distribuzione continua (CD) sono integrati con Helm, utilizza questa opzione.
Operatore AlloyDB Omni con bundle OLM OperatorHub.io Ambiente container Kubernetes di tipo Bring Your Own, ad esempio, on-premise, cloud pubblici, Google Kubernetes Engine, Amazon EKS e Azure AKS.

Per utilizzare un bundle OLM, installa OLM sul cluster Kubernetes prima di installare l'operatore. Per saperne di più, consulta olm.operatorframework.io.

Suggerimento: se gli strumenti di distribuzione continua (CD) utilizzano già OLM, scegli questa opzione.
Operatore OpenShift con bundle OLM Console web OpenShift Container Platform Ambiente OpenShift

OpenShift, una variante di Kubernetes, utilizza OLM come metodo standard e integrato per la creazione di pacchetti e il deployment degli operatori.

Verifica l'accesso

Verifica di avere accesso a quanto segue:

Soddisfare i requisiti hardware e software

Ogni nodo del cluster Kubernetes deve avere quanto segue:

  • Un minimo di due CPU x86 o AMD64.
  • Almeno 8 GB di RAM.
  • Versione kernel Linux 4.18 o successive.
  • Gruppo di controllo (cgroup) v2 abilitato.

Installare l'operatore AlloyDB Omni

Se vuoi eseguire il deployment di AlloyDB Omni nel tuo ambiente di produzione, consulta Eseguire AlloyDB Omni in produzione.

Puoi installare l'operatore AlloyDB Omni utilizzando diversi metodi, tra cui Helm e Operator Lifecycle Manager (OLM).

Helm

Per installare l'operatore AlloyDB Omni:

  1. Installa l'operatore AlloyDB Omni dal registro OCI: 
    helm install alloydbomni-operator oci://gcr.io/alloydb-omni/alloydbomni-operator \
--version 1.7.0 \
--create-namespace \
--namespace alloydb-omni-system \
--atomic \
--timeout 5m

    L'installazione riuscita mostra il seguente output:

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

OLM

Per installare l'operatore AlloyDB Omni utilizzando Operator Lifecycle Manager:

  1. Vai alla pagina Operatore AlloyDB Omni.

  2. Fai clic su Installa. Se non l'hai ancora fatto, segui le istruzioni per installare solo l'operatore OLM e il catalogo OperatorHub.io.

  3. Crea lo spazio dei nomi alloydb-omni-system se non esiste già.

    kubectl create ns alloydb-omni-system

  4. Configura OperatorGroup di OLM per assicurarti che l'operatore sia con ambito cluster.

    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. Installa l'operatore utilizzando una risorsa di abbonamento OLM.

    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. Installa il certificato predefinito ClusterIssuer. Questo passaggio è facoltativo se utilizzi emittenti di certificati personalizzati.

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

OLM

Per installare l'operatore AlloyDB Omni nel tuo ambiente Red Hat OpenShift utilizzando OLM:

  1. Accedi alla console web Red Hat OpenShift.
  2. Per gli utenti offline o disconnessi, devi eseguire manualmente il mirroring delle immagini richieste nel tuo registro privato utilizzando strumenti che conservano i digest SHA come oc image mirror. Devi configurare un ImageDigestMirrorSet per reindirizzare i pull delle immagini dal repository pubblico gcr.io al tuo registro privato. In questo modo, l'operatore AlloyDB Omni può eseguire il pull delle immagini richieste utilizzando i digest SHA256 immutabili.

  3. Nella console web OpenShift, vai a Operatori > OperatorHub. L'operatore AlloyDB Omni è elencato nei cataloghi Certificati e Community.

  4. Nel riquadro dell'operatore AlloyDB Omni, fai clic su Installa.

  5. Installa il certificato predefinito ClusterIssuer eseguendo i seguenti comandi. Questo passaggio è facoltativo se utilizzi emittenti di certificati personalizzati.

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

Configurare l'archiviazione connessa GDC

Per installare l'operatore AlloyDB Omni su GDC Connected, devi seguire passaggi aggiuntivi per configurare l'archiviazione perché i cluster GDC Connected non impostano una classe di archiviazione predefinita. Devi impostare una classe di archiviazione predefinita prima di creare un cluster di database AlloyDB Omni.

Per scoprire come impostare Symcloud Storage come classe di archiviazione predefinita, consulta Impostare Symcloud Storage come classe di archiviazione predefinita.

Per saperne di più su come modificare l'impostazione predefinita per tutte le altre classi di archiviazione, consulta Modificare la StorageClass predefinita.

Creare un cluster di database

Un cluster di database AlloyDB Omni contiene tutte le risorse di archiviazione e di calcolo necessarie per eseguire un server AlloyDB Omni, inclusi il server principale, le eventuali repliche e tutti i dati.

Dopo aver installato l'operatore AlloyDB Omni sul cluster Kubernetes, puoi creare un cluster di database AlloyDB Omni sul cluster Kubernetes applicando un manifest simile al seguente:

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.1.0"
  primarySpec:
    adminUser:
      passwordRef:
        name: db-pw-DB_CLUSTER_NAME
    resources:
      cpu: CPU_COUNT
      memory: MEMORY_SIZE
      disks:
      - name: DataDisk
        size: DISK_SIZE

Sostituisci quanto segue:

  • DB_CLUSTER_NAME: il nome di questo cluster di database, ad esempio my-db-cluster.

  • ENCODED_PASSWORD: la password di accesso al database per il ruolo utente postgres predefinito, codificata come stringa base64, ad esempio Q2hhbmdlTWUxMjM= per ChangeMe123.

  • CPU_COUNT: il numero di CPU disponibili per ogni istanza di database in questo cluster di database.

  • MEMORY_SIZE: la quantità di memoria per istanza di database di questo cluster di database. Ti consigliamo di impostare questo valore su 8 gigabyte per CPU. Ad esempio, se in precedenza in questo manifest hai impostato cpu su 2, ti consigliamo di impostare memory su 16Gi.

  • DISK_SIZE: le dimensioni del disco per istanza di database, ad esempio 10Gi.

Dopo aver applicato questo manifest, il cluster Kubernetes conterrà un cluster di database AlloyDB Omni con la configurazione di memoria, CPU e archiviazione specificata. Per stabilire una connessione di test con il nuovo cluster di database, consulta Connettersi utilizzando psql.

Per saperne di più sui manifest Kubernetes e su come applicarli, consulta Gestire le risorse.

Scalare un cluster di database

Per scalare le risorse di calcolo per il cluster di database, aggiorna i valori cpu e memory nel manifest db-cluster.yaml e applica le modifiche. La procedura di scalabilità dipende dalla scelta di un'operazione di scalabilità regolare o di un'operazione di scalabilità con tempi di inattività ridotti.

Scalabilità regolare

Quando aggiorni la specifica di scalabilità e applichi il manifest senza ulteriori configurazioni, i pod del database vengono riavviati immediatamente. Ciò comporta un breve periodo di inattività nelle istanze primaria e di standby mentre le nuove allocazioni di risorse diventano effettive.

Scalabilità con tempi di inattività ridotti

Per i cluster ad alta affidabilità (HA) con almeno un'istanza di standby, puoi ridurre al minimo i tempi di inattività durante la scalabilità utilizzando la strategia di preparazione e switchover della manutenzione con tempi di inattività ridotti (LDTM). Questa strategia applica prima le modifiche di scalabilità all'istanza di standby, esegue uno switchover rapido e poi applica le modifiche all'istanza primaria originale. Puoi fare lo scale up o lo scale down con la strategia LDTM.

Per abilitare e monitorare la scalabilità con tempi di inattività ridotti:

  1. Abilita la scalabilità con tempi di inattività ridotti. Aggiungi l'annotazione enableLDTM al cluster di database:

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

    Sostituisci DB_CLUSTER_NAME con il nome del cluster di database.

  2. Applica le specifiche di scalabilità aggiornate. Aggiorna i valori cpu e memory in primarySpec.resources nel manifest e applica le modifiche:

    kubectl apply -f db-cluster.yaml

  3. Monitora la procedura di scalabilità. Controlla la condizione di stato LDTMScalingInProgress per monitorare l'operazione:

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

    Sostituisci DB_CLUSTER_NAME con il nome del cluster di database.

    Durante la procedura, lo stato è true. Al termine della scalabilità, lo stato della condizione diventa false.

Limitazioni

  • La scalabilità LDTM è supportata solo per i cluster HA con almeno un'istanza di standby.
  • Non puoi eseguire due operazioni LDTM contemporaneamente. Ad esempio, puoi utilizzare LDTM per scalare i cluster di database o per eseguire upgrade di versioni secondarie, ma non entrambi contemporaneamente.
  • Devi eseguire manualmente il rollback dopo che un'operazione di scalabilità LDTM non è riuscita.

Passaggi successivi