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 fournit des instructions pour l'utiliser afin de déployer AlloyDB Omni sur un cluster Kubernetes. Cette page part du principe que vous connaissez les opérations Kubernetes de base.

Pour savoir comment installer 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'image 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 conteneur.

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

  • Activation : bien que les références de résumé soient activées par défaut pour le package certifié OpenShift, les utilisateurs des packages OLM ou Helm peuvent les activer manuellement en définissant la variable d'environnement ENABLE_DIGEST_IMAGE_REFS sur true à l'aide de la configuration de l'abonnement pour OLM ou de la valeur enableDigestImageRefs dans le graphique 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 paquets universel qui utilise des charts Helm pour installer n'importe quelle charge de travail, y compris les opérateurs, dans toutes les variantes de Kubernetes. OLM, le choix standard et privilégié 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édias Emplacements de téléchargement et guides d'installation Déploiement vers
Opérateur AlloyDB Omni avec chart Helm Installer AlloyDB Omni sur Kubernetes Apportez votre propre environnement de conteneurs Kubernetes (par exemple, sur site, dans des clouds publics, GKE, Amazon EKS et Azure AKS).

Remarque : Utilisez cette option si votre outil de CD (livraison continue) est intégré à Helm.
Opérateur AlloyDB Omni avec le bundle OLM OperatorHub.io Apportez votre propre environnement de conteneurs Kubernetes (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 CD (livraison continue) utilise déjà OLM, choisissez cette option.
Opérateur OpenShift avec le bundle OLM Console Web Openshift Container Platform 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 RAM.
  • Version 4.18 ou ultérieure du noyau Linux.
  • 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 de différentes manières, y compris avec Helm et l'Operator Lifecycle Manager (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.7.0 \
--create-namespace \
--namespace alloydb-omni-system \
--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 de l'Operator Lifecycle Manager, procédez comme suit :

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

  2. Cliquez sur Installer. Si vous ne l'avez pas déjà fait, suivez les instructions pour installer uniquement 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 OLM OperatorGroup 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 à la 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 préservent 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 permet de s'assurer que l'opérateur AlloyDB Omni peut extraire les images requises à l'aide de leurs résumés SHA256 immuables.

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

  4. Dans le volet de l'opérateur AlloyDB Omni, cliquez sur 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 Connected, vous devez suivre des étapes supplémentaires pour configurer le stockage, car les clusters GDC Connected 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 savoir comment modifier la classe de stockage 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 à l'exécution d'un serveur AlloyDB Omni, y compris le serveur principal, les réplicas et toutes vos données.

Après avoir 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.1.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 préinstallé.

Pour en savoir plus sur les fichiers manifestes Kubernetes et sur la façon de les appliquer, consultez Gérer les ressources.

Faire évoluer 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 scaling dépend de l'opération de scaling que vous choisissez (régulière ou avec un temps d'arrêt réduit).

Scaling régulier

Lorsque vous mettez à jour votre spécification de scaling 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.

Évolutivité avec un faible temps d'arrêt

Pour les clusters à haute disponibilité (HA) avec au moins un nœud de secours, vous pouvez minimiser les temps d'arrêt lors du scaling à l'aide de la stratégie de préparation et de bascule de maintenance à faible temps d'arrêt (LDTM). Cette stratégie applique d'abord les modifications de scaling au nœud de secours, effectue un basculement rapide, puis applique les modifications à l'instance principale d'origine. Vous pouvez augmenter ou diminuer vos dépenses grâce à la stratégie LDTM.

Pour activer et surveiller le scaling à faible temps d'arrêt, procédez comme suit :

  1. Activez le scaling 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 scaling 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 scaling. Vérifiez la condition d'é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 le scaling terminé, l'état de la condition passe à false.

Limites

  • Le scaling LDTM n'est compatible qu'avec les clusters HA comportant au moins un nœud 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 versions mineures, mais pas les deux en même temps.
  • Vous devez effectuer manuellement le rollback après l'échec d'une opération de scaling LDTM.

Étapes suivantes