Instala AlloyDB Omni con el organizador de contenedores

Selecciona una versión de la documentación:

En esta página, se proporciona una descripción general del operador de Kubernetes de AlloyDB Omni, con instrucciones para usarlo en la implementación de AlloyDB Omni en un clúster de Kubernetes. En esta página, se supone que tienes conocimientos básicos sobre la operación de Kubernetes.

Para obtener instrucciones sobre cómo instalar AlloyDB Omni en un entorno de Linux estándar, consulta Instala AlloyDB Omni.

Descripción general

Para implementar AlloyDB Omni en un clúster de Kubernetes, instala el operador de Kubernetes de AlloyDB Omni, una extensión de la API de Kubernetes que proporciona Google.

Configura y controla un clúster de base de datos de AlloyDB Omni basado en Kubernetes vinculando archivos de manifiesto declarativos con la utilidad kubectl, tal como lo harías con cualquier otra implementación basada en Kubernetes. No usas la CLI de AlloyDB Omni, que está diseñada para implementaciones en máquinas de Linux individuales y no en clústeres de Kubernetes.

Imagen base

A partir de la versión 1.5.0, las imágenes de Kubernetes del operador de AlloyDB Omni se compilan en la imagen base universal (UBI) 9 de Red Hat. Esta transición mejora la seguridad, la coherencia y el cumplimiento de tus implementaciones.

Referencias de imágenes de resumen SHA

Para evitar ataques de suministro y cumplir con los requisitos de la certificación de OpenShift, el operador de AlloyDB Omni usa resúmenes SHA-256 en lugar de etiquetas de versión para todas las referencias de imágenes de contenedor.

  • Actualizaciones automáticas: El operador de AlloyDB Omni usa un ImageCatalog interno para administrar estos resúmenes y garantizar reversiones confiables del plano de datos durante las actualizaciones con errores.

  • Habilitación: Si bien está habilitada de forma predeterminada para el paquete certificado de OpenShift, los usuarios de los paquetes de OLM o Helm pueden habilitar de forma manual las referencias de resumen configurando la variable de entorno ENABLE_DIGEST_IMAGE_REFS como true con la configuración de suscripción para OLM o el valor enableDigestImageRefs en el gráfico de Helm.

Antes de comenzar

Antes de instalar AlloyDB Omni en un clúster de Kubernetes con el operador de AlloyDB Omni, asegúrate de cumplir con los siguientes requisitos.

Elige una opción de descarga o instalación

Cuando administras cargas de trabajo en un clúster de Kubernetes genérico, puedes usar Helm o OLM. Helm es un administrador de paquetes universal que usa gráficos de Helm para instalar cualquier carga de trabajo, incluidos los operadores, en todas las variantes de Kubernetes. OLM, la opción estándar y preferida en las plataformas de OpenShift, administra los ciclos de vida de los operadores con paquetes de OLM especializados.

Según tu entorno y tus herramientas, elige uno de los siguientes métodos de implementación:

Medios Ubicaciones de descarga y guías de instalación Implementación en
Operador de AlloyDB Omni con gráfico de Helm Instala AlloyDB Omni en Kubernetes Entorno de contenedores de Kubernetes propio, por ejemplo, local, nubes públicas, GKE, Amazon EKS y Azure AKS.

Sugerencia: Si tus herramientas de entrega continua (CD) están integradas en Helm, usa esta opción.
Operador de AlloyDB Omni con paquete de OLM OperatorHub.io Entorno de contenedores de Kubernetes propio, por ejemplo, local, nubes públicas, Google Kubernetes Engine, Amazon EKS y Azure AKS.

Para usar un paquete de OLM, instala OLM en el clúster de Kubernetes antes de instalar el operador. Para obtener más información, consulta olm.operatorframework.io.

Sugerencia: Si tus herramientas de entrega continua (CD) ya usan OLM, elige esta opción.
Operador de OpenShift con paquete de OLM Consola web de OpenShift Container Platform Entorno de OpenShift

OpenShift, una variante de Kubernetes, usa OLM como su método estándar integrado para empaquetar e implementar operadores.

Verifica el acceso

Verifica que tengas acceso a lo siguiente:

Cumple con los requisitos de hardware y software

Cada nodo del clúster de Kubernetes debe tener lo siguiente:

  • Al menos dos CPU x86 o AMD64
  • Al menos 8 GB de RAM
  • Versión de kernel de Linux 4.18 o posterior.
  • Se habilitó el grupo de control (cgroup) v2.

Instala el operador de AlloyDB Omni

Si quieres implementar AlloyDB Omni en tu entorno de producción, consulta Ejecuta AlloyDB Omni en producción.

Puedes instalar el operador de AlloyDB Omni con diferentes métodos, incluidos Helm y Operator Lifecycle Manager (OLM).

Helm

Para instalar el operador de AlloyDB Omni, sigue estos pasos:

  1. Instala el operador de AlloyDB Omni desde el registro de OCI: 
    helm install alloydbomni-operator oci://gcr.io/alloydb-omni/alloydbomni-operator \
--version 1.9.0 \
--create-namespace \
--namespace alloydb-omni-system \
$(helm install --help | grep -q -- '--rollback-on-failure' && echo '--rollback-on-failure' || echo '--atomic') \
--timeout 5m

    Si la instalación se realiza correctamente, se muestra el siguiente resultado:

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

OLM

Para instalar el operador de AlloyDB Omni con Operator Lifecycle Manager, sigue estos pasos:

  1. Ve a la página Operador de AlloyDB Omni.

  2. Haz clic en Instalar. Si aún no lo hiciste, sigue las instrucciones para instalar solo el operador de OLM y el catálogo de OperatorHub.io.

  3. Crea el espacio de nombres alloydb-omni-system si aún no existe.

    kubectl create ns alloydb-omni-system

  4. Configura el OLM OperatorGroup para asegurarte de que el operador tenga alcance de clúster.

    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. Instala el operador con un recurso de suscripción de 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. Instala el certificado predeterminado ClusterIssuer. Este paso es opcional si usas emisores de certificados personalizados.

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

OLM

Para instalar el operador de AlloyDB Omni en tu entorno de Red Hat OpenShift con OLM, sigue estos pasos:

  1. Accede a la consola web de Red Hat OpenShift.
  2. Para los usuarios sin conexión o desconectados, debes duplicar de forma manual las imágenes requeridas en tu registro privado con herramientas que conserven los resúmenes SHA, como oc image mirror. Debes configurar un ImageDigestMirrorSet para redireccionar las extracciones de imágenes del repositorio público de gcr.io a tu registro privado. Esto garantiza que el operador de AlloyDB Omni pueda extraer las imágenes requeridas con sus resúmenes de SHA256 inmutables.

  3. En la consola web de OpenShift, navega a Operators > OperatorHub. El operador de AlloyDB Omni aparece en los catálogos Certificado y Comunidad.

  4. En el panel del operador de AlloyDB Omni, haz clic en Instalar.

  5. Instala el certificado predeterminado ClusterIssuer ejecutando los siguientes comandos. Este paso es opcional si usas emisores de certificados personalizados.

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

Configura el almacenamiento de GDC conectado

Para instalar el operador de AlloyDB Omni en GDC conectado, debes seguir pasos adicionales para configurar el almacenamiento, ya que los clústeres conectados de GDC no establecen una clase de almacenamiento predeterminada. Debes establecer una clase de almacenamiento predeterminada antes de crear un clúster de base de datos de AlloyDB Omni.

Para obtener información sobre cómo configurar Symcloud Storage como la clase de almacenamiento predeterminada, consulta Configura Symcloud Storage como la clase de almacenamiento predeterminada.

Para obtener más información sobre cómo cambiar la configuración predeterminada de todas las demás clases de almacenamiento, consulta Cambia la StorageClass predeterminada.

Crea un clúster de base de datos

Un clúster de base de datos de AlloyDB Omni contiene todos los recursos de almacenamiento y procesamiento necesarios para ejecutar un servidor de AlloyDB Omni, incluidos el servidor principal, las réplicas y todos tus datos.

Después de instalar el operador de AlloyDB Omni en tu clúster de Kubernetes, puedes crear un clúster de base de datos de AlloyDB Omni en el clúster de Kubernetes aplicando un manifiesto similar al siguiente:

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

Reemplaza lo siguiente:

  • DB_CLUSTER_NAME: Es el nombre de este clúster de base de datos, por ejemplo, my-db-cluster.

  • ENCODED_PASSWORD: Es la contraseña de acceso a la base de datos del rol de usuario postgres predeterminado, codificada como una cadena base64 (por ejemplo, Q2hhbmdlTWUxMjM= para ChangeMe123).

  • CPU_COUNT: Es la cantidad de CPU disponibles para cada instancia de base de datos en este clúster de base de datos.

  • MEMORY_SIZE: Es la cantidad de memoria por instancia de base de datos de este clúster de base de datos. Recomendamos establecer este valor en 8 gigabytes por CPU. Por ejemplo, si estableciste cpu en 2 anteriormente en este manifiesto, te recomendamos que establezcas memory en 16Gi.

  • DISK_SIZE: Es el tamaño del disco por instancia de base de datos, por ejemplo, 10Gi.

Después de aplicar este manifiesto, tu clúster de Kubernetes contendrá un clúster de base de datos de AlloyDB Omni con la configuración de memoria, CPU y almacenamiento especificada. Para establecer una conexión de prueba con el clúster de base de datos nuevo, consulta Conéctate con el psql preinstalado.

Para ver manifiestos de ejemplo adicionales, consulta Muestras de configuración de Kubernetes. Para obtener más información sobre los manifiestos de Kubernetes y cómo aplicarlos, consulta Administra recursos.

Secretos de extracción de imágenes

Si usas un registro privado para tus imágenes de contenedor, puedes especificar los secrets de extracción de imágenes para tu clúster de base de datos. El operador de AlloyDB Omni propaga los secretos de extracción de imágenes a la cuenta de servicio del clúster de base de datos, llamada DB_CLUSTER_NAME-sa.

Para configurar los secretos de extracción de imágenes, proporciona los nombres de los secretos en la especificación del clúster de la base de datos. El Secret debe existir en el mismo espacio de nombres que el clúster de base de datos.

spec:
  primarySpec:
    serviceAccount:
      imagePullSecrets:
      - name: PULL_SECRET_NAME

Reemplaza PULL_SECRET_NAME por el nombre del Secret de extracción de imágenes.

Escala un clúster de base de datos

Para escalar los recursos de procesamiento de tu clúster de base de datos, actualiza los valores cpu y memory en tu manifiesto db-cluster.yaml y aplica los cambios. El proceso de escalamiento depende de si optas por una operación de escalamiento normal o una con poco tiempo de inactividad.

Escalamiento regular

Cuando actualizas la especificación de escalamiento y aplicas el manifiesto sin ninguna configuración adicional, los Pods de la base de datos se reinician de inmediato. Esto genera un breve tiempo de inactividad en las instancias principal y en espera mientras se aplican las nuevas asignaciones de recursos.

Escalamiento con poco tiempo de inactividad

En el caso de los clústeres de alta disponibilidad (HA) con al menos una instancia en espera, puedes minimizar el tiempo de inactividad durante el escalamiento con la estrategia de preparación y cambio de mantenimiento con bajo tiempo de inactividad (LDTM). Esta estrategia aplica los cambios de escalamiento primero a la instancia en espera, realiza un cambio rápido y, luego, aplica los cambios a la instancia principal original. Puedes aumentar o disminuir la escala con la estrategia de LDTM.

Para habilitar y supervisar el escalamiento con poco tiempo de inactividad, sigue estos pasos:

  1. Habilitar el escalamiento con poco tiempo de inactividad Agrega la anotación enableLDTM a tu clúster de base de datos:

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

    Reemplaza DB_CLUSTER_NAME por el nombre de tu clúster de base de datos.

  2. Aplica las especificaciones de escalamiento actualizadas. Actualiza los valores de cpu y memory en primarySpec.resources en tu manifiesto y aplica los cambios:

    kubectl apply -f db-cluster.yaml

  3. Supervisar el proceso de escalamiento Verifica la condición de estado LDTMScalingInProgress para supervisar la operación:

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

    Reemplaza DB_CLUSTER_NAME por el nombre de tu clúster de base de datos.

    Mientras el proceso está en curso, el estado es true. Cuando se completa el escalamiento, el estado de la condición cambia a false.

Limitaciones

  • El escalamiento de LDTM solo se admite en clústeres de alta disponibilidad con al menos una instancia en espera.
  • No puedes realizar dos operaciones de LDTM de forma simultánea. Por ejemplo, puedes usar LDTM para escalar clústeres de bases de datos o para realizar actualizaciones de versiones secundarias, pero no ambas acciones al mismo tiempo.
  • Debes revertir de forma manual después de que falle una operación de escalamiento de LDTM.

¿Qué sigue?