Para obtener instrucciones sobre cómo instalar AlloyDB Omni en un entorno estándar de Linux, 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.
Para configurar y controlar un clúster de base de datos de AlloyDB Omni basado en Kubernetes, debes combinar archivos de manifiesto declarativos con la utilidad kubectl, al igual que cualquier otra implementación basada en Kubernetes. No usas la CLI de AlloyDB Omni, que está diseñada para implementaciones en máquinas 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 de SHA
Para evitar ataques a la cadena de suministro y cumplir con los requisitos de certificación de OpenShift, el operador de AlloyDB Omni usa resúmenes de 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 fallidas.
Habilitación: Si bien está habilitado de forma predeterminada para el paquete certificado de OpenShift, los usuarios de los paquetes de OLM o Helm pueden habilitar manualmente las referencias de resumen si configuran la
ENABLE_DIGEST_IMAGE_REFSvariable de entorno entruecon la configuración de suscripción para OLM o el valorenableDigestImageRefsen 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 del operador 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 contenedor de Kubernetes propio, por ejemplo, en la nube pública, local, GKE, Amazon EKS y
Azure AKS. Nota: Si tu herramienta de CD (entrega continua) está integrada con Helm, usa esta opción. |
| Operador de AlloyDB Omni con paquete de OLM | OperatorHub.io | Entorno de contenedor de Kubernetes propio, por ejemplo, en la nube pública, local, 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. Nota: Si tu herramienta de CD (entrega continua) ya usa 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:
- Un clúster de Kubernetes que ejecuta el siguiente software:
- Kubernetes versión 1.21 o posterior
- El servicio
cert-manager.
- La utilidad
kubectl. - El administrador de paquetes
helmo el Operator Lifecycle Manager.
Cumple con los requisitos de hardware y software
Cada nodo del clúster de Kubernetes debe tener lo siguiente:
- Un mínimo de dos CPUs x86 o AMD64
- Al menos 8 GB de RAM
- Versión 4.18 o posterior del kernel de Linux
- Grupo de control (cgroup) v2 habilitado
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 el Operator Lifecycle Manager (OLM).
Helm
Para instalar el operador de AlloyDB Omni, sigue estos pasos:
- Instala el operador de AlloyDB Omni desde el registro de 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
Una instalación exitosa 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 el Operator Lifecycle Manager, sigue estos pasos:
Ve a la página del operador de AlloyDB Omni.
Haz clic en Install. Si aún no lo hiciste, sigue las instrucciones para instalar solo el operador de OLM y el catálogo de OperatorHub.io.
Crea el espacio de nombres
alloydb-omni-systemsi aún no existe.kubectl create ns alloydb-omni-system
Configura el
OperatorGroupde OLM para asegurarte de que el operador tenga alcance del 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
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
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:
- Accede a la consola web de Red Hat OpenShift.
- En el caso de los usuarios sin conexión o desconectados, debes reflejar manualmente las
imágenes necesarias en tu registro privado con herramientas que conserven los resúmenes de SHA
como
oc image mirror. Debes configurar unImageDigestMirrorSetpara redireccionar las extracciones de imágenes del repositorio públicogcr.ioa tu registro privado. Esto garantiza que el operador de AlloyDB Omni pueda extraer las imágenes necesarias con sus resúmenes SHA256 inmutables. En la consola web de OpenShift, navega a Operators > OperatorHub. El operador de AlloyDB Omni aparece en los catálogos Certified y Community.
En el panel del operador de AlloyDB Omni, haz clic en Install.
Para instalar el certificado predeterminado
ClusterIssuer, ejecuta 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 conectado de GDC
Para instalar el operador de AlloyDB Omni en GDC conectado, debes seguir pasos adicionales para configurar el almacenamiento, ya que los cl101}ústeres de GDC conectados 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 establecer Symcloud Storage como la clase de almacenamiento predeterminada, consulta Establece 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 el recurso StorageClass predeterminado.
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, incluido 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 si aplicas 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.1.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 usuariopostgrespredeterminado, codificada como una cadena base64 (por ejemplo,Q2hhbmdlTWUxMjM=paraChangeMe123).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 establecistecpuen2anteriormente en este manifiesto, te recomendamos que establezcasmemoryen16Gi.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 nuevo
clúster de base de datos, consulta Conéctate con psql preinstalado.
Para obtener más información sobre los manifiestos de Kubernetes y cómo aplicarlos, consulta Administra recursos.
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 de cpu y memory en tu manifiesto db-cluster.yaml y aplica los cambios. El proceso de escalamiento depende de si eliges una operación de escalamiento normal o una operación de escalamiento con tiempo de inactividad bajo.
Escalamiento normal
Cuando actualizas tu especificación de escalamiento y aplicas el manifiesto sin ninguna otra configuración, 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 entran en vigencia las nuevas asignaciones de recursos.
Escalamiento con tiempo de inactividad bajo
Para 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 tiempo de inactividad bajo (LDTM). Esta estrategia aplica primero los cambios de escalamiento a la instancia en espera, realiza un cambio rápido y, luego, aplica los cambios a la instancia principal original. Puedes escalar verticalmente o disminuir la escala con la estrategia de LDTM.
Para habilitar y supervisar el escalamiento con tiempo de inactividad bajo, sigue estos pasos:
Habilita el escalamiento con tiempo de inactividad bajo. Agrega la sección
enableLDTMa tu clúster de base de datos:kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME dbcluster.dbadmin.goog/enableLDTM=true
Reemplaza
DB_CLUSTER_NAMEpor el nombre de tu clúster de base de datos.Aplica las especificaciones de escalamiento actualizadas. Actualiza los valores de
cpuymemoryenprimarySpec.resourcesen tu manifiesto y aplica los cambios:kubectl apply -f db-cluster.yaml
Supervisa el proceso de escalamiento. Verifica la condición de estado
LDTMScalingInProgresspara supervisar la operación:kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -o yaml | yq '.status.conditions[] | select(.type == "LDTMScalingInProgress")'
Reemplaza
DB_CLUSTER_NAMEpor 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 afalse.
Limitaciones
- El escalamiento de LDTM solo es compatible con clústeres de HA 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 base de datos o para realizar actualizaciones de versiones secundarias, pero no ambas al mismo tiempo.
- Debes revertir manualmente después de que falla una operación de escalamiento de LDTM.
¿Qué sigue?
- Ejecuta AlloyDB Omni y conéctate a él.
- Administra AlloyDB Omni.
- Administra la alta disponibilidad en Kubernetes.
- Crea un clúster habilitado para TDE.