Installer AlloyDB Omni à l'aide de l'orchestrateur de conteneurs

Sélectionnez une version de la documentation :

Cette page présente l'opérateur Kubernetes AlloyDB Omni et explique comment l'utiliser pour déployer AlloyDB Omni sur un cluster Kubernetes. Cette page suppose une connaissance de base du fonctionnement de Kubernetes.

Pour obtenir des instructions sur l'installation d'AlloyDB Omni dans un environnement Linux standard, consultez Installer AlloyDB Omni.

Présentation

Pour déployer AlloyDB Omni sur un cluster Kubernetes, installez l'opérateur Kubernetes AlloyDB Omni, une extension de l'API Kubernetes fournie par Google.

Vous configurez et contrôlez un cluster de bases de données AlloyDB Omni basé sur Kubernetes en associant des fichiers manifestes déclaratifs à l'utilitaire kubectl, comme pour tout autre déploiement basé sur Kubernetes. Vous n'utilisez pas la CLI AlloyDB Omni, qui est destinée aux déploiements sur des machines Linux individuelles et non sur des clusters Kubernetes.

Image de base

À partir de la version 1.5.0, les images Kubernetes de l'opérateur AlloyDB Omni sont basées sur l'image de base universelle (UBI) 9 de Red Hat. Cette transition améliore la sécurité, la cohérence et la conformité de vos déploiements.

Références d'images de condensé SHA

Pour éviter les attaques de la chaîne d'approvisionnement et répondre aux exigences de certification OpenShift, l'opérateur AlloyDB Omni utilise des condensés SHA-256 au lieu de tags de version pour toutes les références d'images de conteneurs.

  • Mises à niveau automatiques : l'opérateur AlloyDB Omni utilise un ImageCatalog interne pour gérer ces condensés et garantir des rollbacks fiables du plan de données en cas d'échec des mises à niveau.

  • Activation : bien qu'elle soit activée par défaut pour le package certifié OpenShift, les utilisateurs des packages OLM ou Helm peuvent activer manuellement les références de condensé en définissant la ENABLE_DIGEST_IMAGE_REFS variable d'environnement sur true à l'aide de la configuration d'abonnement pour OLM ou de la valeur enableDigestImageRefs dans le chart Helm.

Avant de commencer

Avant d'installer AlloyDB Omni sur un cluster Kubernetes avec l'opérateur AlloyDB Omni, assurez-vous de respecter les conditions suivantes.

Choisir une option de téléchargement ou d'installation

Lorsque vous gérez des charges de travail sur un cluster Kubernetes générique, vous pouvez utiliser Helm ou OLM. Helm est un gestionnaire de packages universel qui utilise des charts Helm pour installer n'importe quelle charge de travail, y compris les opérateurs, sur toutes les variantes de Kubernetes. OLM, le choix standard et préféré sur les plates-formes OpenShift, gère les cycles de vie des opérateurs avec des bundles OLM spécialisés.

En fonction de votre environnement et de vos outils, choisissez l'une des méthodes de déploiement suivantes :

Média Emplacements de téléchargement et guides d'installation Déploiement vers
Opérateur AlloyDB Omni avec chart Helm Installer AlloyDB Omni sur Kubernetes Environnement de conteneurs Kubernetes que vous fournissez vous-même, par exemple, sur site, dans des clouds publics, GKE, Amazon EKS et Azure AKS.

Conseil : Si votre outil de livraison continue (CD) est intégré à Helm, utilisez cette option.
Opérateur AlloyDB Omni avec bundle OLM OperatorHub.io Environnement de conteneurs Kubernetes que vous fournissez vous-même, par exemple, sur site, dans des clouds publics, Google Kubernetes Engine, Amazon EKS et Azure AKS.

Pour utiliser un bundle OLM, installez OLM sur le cluster Kubernetes avant d'installer l'opérateur. Pour en savoir plus, consultez olm.operatorframework.io.

Conseil : Si votre outil de livraison continue (CD) utilise déjà OLM, choisissez cette option.
Opérateur OpenShift avec bundle OLM Console Web de la plate-forme de conteneurs OpenShift Environnement OpenShift

OpenShift, une variante de Kubernetes, utilise OLM comme méthode standard intégrée pour empaqueter et déployer des opérateurs.

Vérifier l'accès

Vérifiez que vous avez accès aux éléments suivants :

Répondre aux exigences matérielles et logicielles

Chaque nœud du cluster Kubernetes doit disposer des éléments suivants :

  • Au moins deux processeurs x86 ou AMD64.
  • Au moins 8 Go de mémoire RAM.
  • Version de noyau Linux 4.18 ou ultérieure.
  • Le groupe de contrôle (cgroup) v2 est activé.

Installer l'opérateur AlloyDB Omni

Si vous souhaitez déployer AlloyDB Omni dans votre environnement de production, consultez Exécuter AlloyDB Omni en production.

Vous pouvez installer l'opérateur AlloyDB Omni à l'aide de différentes méthodes, y compris Helm et le gestionnaire de cycle de vie des opérateurs (OLM).

Helm

Pour installer l'opérateur AlloyDB Omni, procédez comme suit :

  1. Installez l'opérateur AlloyDB Omni à partir du registre OCI : 
    helm install alloydbomni-operator oci://gcr.io/alloydb-omni/alloydbomni-operator \
--version 1.8.1 \
--create-namespace \
--namespace alloydb-omni-system \
$(helm install --help | grep -q -- '--rollback-on-failure' && echo '--rollback-on-failure' || echo '--atomic') \
--timeout 5m

    Si l'installation aboutit, la sortie suivante devrait s'afficher :

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

OLM

Pour installer l'opérateur AlloyDB Omni à l'aide du gestionnaire de cycle de vie des opérateurs, procédez comme suit :

  1. Accédez à la page AlloyDB Omni Operator (Opérateur AlloyDB Omni).

  2. Cliquez sur Install (Installer). Si ce n'est pas déjà fait, suivez les instructions pour n'installer que l'opérateur OLM et le catalogue OperatorHub.io.

  3. Créez l'espace de noms alloydb-omni-system s'il n'existe pas déjà.

    kubectl create ns alloydb-omni-system

  4. Configurez l'OperatorGroup OLM pour vous assurer que l'opérateur est limité au 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. Installez l'opérateur à l'aide d'une ressource d'abonnement 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. Installez le certificat par défaut ClusterIssuer. Cette étape est facultative si vous utilisez des émetteurs de certificats personnalisés.

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

OLM

Pour installer l'opérateur AlloyDB Omni dans votre environnement Red Hat OpenShift à l'aide d'OLM, procédez comme suit :

  1. Connectez-vous à votre console Web Red Hat OpenShift.
  2. Pour les utilisateurs hors connexion ou déconnectés, vous devez mettre en miroir manuellement les images requises dans votre registre privé à l'aide d'outils qui conservent les condensés SHA, tels que oc image mirror. Vous devez configurer un ImageDigestMirrorSet pour rediriger les extractions d'images du dépôt public gcr.io vers votre registre privé. Cela garantit que l'opérateur AlloyDB Omni peut extraire les images requises à l'aide de leurs condensés SHA256 immuables.

  3. Dans la console Web OpenShift, accédez à Operators > OperatorHub (Opérateurs > OperatorHub). L'opérateur AlloyDB Omni est répertorié dans les catalogues Certified (Certifié) et Community (Communauté).

  4. Dans le volet de l'opérateur AlloyDB Omni, cliquez sur Install (Installer).

  5. Installez le certificat par défaut ClusterIssuer en exécutant les commandes suivantes. Cette étape est facultative si vous utilisez des émetteurs de certificats personnalisés.

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

Configurer le stockage connecté GDC

Pour installer l'opérateur AlloyDB Omni sur GDC connecté, vous devez suivre des étapes supplémentaires pour configurer le stockage, car les clusters GDC connectés ne définissent pas de classe de stockage par défaut. Vous devez définir une classe de stockage par défaut avant de créer un cluster de bases de données AlloyDB Omni.

Pour savoir comment définir Symcloud Storage comme classe de stockage par défaut, consultez Définir Symcloud Storage comme classe de stockage par défaut.

Pour en savoir plus sur la modification de la valeur par défaut pour toutes les autres classes de stockage, consultez Modifier la ressource StorageClass par défaut.

Créer un cluster de bases de données

Un cluster de bases de données AlloyDB Omni contient toutes les ressources de stockage et de calcul nécessaires pour exécuter un serveur AlloyDB Omni, y compris le serveur principal, toutes les instances répliquées et toutes vos données.

Une fois que vous avez installé l'opérateur AlloyDB Omni sur votre cluster Kubernetes, vous pouvez créer un cluster de bases de données AlloyDB Omni sur le cluster Kubernetes en appliquant un fichier manifeste semblable à celui-ci :

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

Remplacez les éléments suivants :

  • DB_CLUSTER_NAME : nom de ce cluster de bases de données, par exemple my-db-cluster.

  • ENCODED_PASSWORD : mot de passe de connexion à la base de données pour le rôle utilisateur postgres par défaut, encodé sous forme de chaîne base64 (par exemple, Q2hhbmdlTWUxMjM= pour ChangeMe123).

  • CPU_COUNT: nombre de processeurs disponibles pour chaque instance de base de données de ce cluster de bases de données.

  • MEMORY_SIZE: quantité de mémoire par instance de base de données de ce cluster de bases de données. Nous vous recommandons de définir cette valeur sur 8 gigaoctets par processeur. Par exemple, si vous avez défini cpu sur 2 plus haut dans ce fichier manifeste, nous vous recommandons de définir memory sur 16Gi.

  • DISK_SIZE : taille de disque par instance de base de données (par exemple, 10Gi).

Une fois ce fichier manifeste appliqué, votre cluster Kubernetes contient un cluster de bases de données AlloyDB Omni avec la configuration de mémoire, de processeur et de stockage spécifiée. Pour établir une connexion de test avec le nouveau cluster de bases de données, consultez Se connecter à l'aide de psql.

Pour en savoir plus sur les fichiers manifestes Kubernetes et sur leur application, consultez Gérer les ressources.

Mettre à l'échelle un cluster de bases de données

Pour mettre à l'échelle les ressources de calcul de votre cluster de bases de données, mettez à jour les valeurs cpu et memory dans votre fichier manifeste db-cluster.yaml, puis appliquez les modifications. Le processus de mise à l'échelle dépend de si vous optez pour une opération de mise à l'échelle régulière ou une opération de mise à l'échelle avec un temps d'arrêt réduit.

Mise à l'échelle régulière

Lorsque vous mettez à jour votre spécification de mise à l'échelle et que vous appliquez le fichier manifeste sans autre configuration, les pods de base de données redémarrent instantanément. Cela entraîne un bref temps d'arrêt sur les instances principale et de secours pendant que les nouvelles allocations de ressources prennent effet.

Mise à l'échelle avec un temps d'arrêt réduit

Pour les clusters à haute disponibilité (HA) avec au moins une instance de secours, vous pouvez réduire les temps d'arrêt lors de la mise à l'échelle à l'aide de la stratégie de préparation et de basculement de la maintenance à faible temps d'arrêt (LDTM). Cette stratégie applique d'abord les modifications de mise à l'échelle à l'instance de secours, effectue un basculement rapide, puis applique les modifications à l'instance principale d'origine. Vous pouvez effectuer un scaling ascendant ou descendant avec la stratégie LDTM.

Pour activer et surveiller la mise à l'échelle avec un temps d'arrêt réduit, procédez comme suit :

  1. Activez la mise à l'échelle avec un temps d'arrêt réduit. Ajoutez l'annotation enableLDTM à votre cluster de bases de données :

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

    Remplacez DB_CLUSTER_NAME par le nom de votre cluster de bases de données.

  2. Appliquez les spécifications de mise à l'échelle mises à jour. Mettez à jour les valeurs cpu et memory sous primarySpec.resources dans votre fichier manifeste, puis appliquez les modifications :

    kubectl apply -f db-cluster.yaml

  3. Surveillez le processus de mise à l'échelle. Vérifiez l'état LDTMScalingInProgress pour surveiller l'opération :

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

    Remplacez DB_CLUSTER_NAME par le nom de votre cluster de bases de données.

    Pendant le processus, l'état est true. Une fois la mise à l'échelle terminée, l'état de la condition passe à false.

Limites

  • La mise à l'échelle LDTM n'est compatible qu'avec les clusters HA comportant au moins une instance de secours.
  • Vous ne pouvez pas effectuer deux opérations LDTM simultanément. Par exemple, vous pouvez utiliser LDTM pour mettre à l'échelle des clusters de bases de données ou pour effectuer des mises à niveau de version mineure, mais pas les deux en même temps.
  • Vous devez effectuer manuellement un rollback après l'échec d'une opération de mise à l'échelle LDTM.

Étape suivante