Si tu base de datos se ejecuta en un clúster de Kubernetes, puedes agregar contenedores complementarios a tu clúster de bases de datos con el operador de Kubernetes de AlloyDB Omni. Los contenedores de sidecar del operador de AlloyDB Omni son contenedores de Kubernetes normales que se ejecutan de forma independiente junto con el contenedor principal de la aplicación dentro del mismo Pod. Puedes usar estos contenedores sidecar para entregar solicitudes de supervisión, registro y seguimiento de aplicaciones.
Los contenedores de sidecar del operador de AlloyDB Omni son distintos de los contenedores de sidecar integrados de Kubernetes.
Para agregar manualmente un contenedor de sidecar a una instalación existente de AlloyDB Omni, crea un recurso personalizado (CR) de sidecar y agrégalo a tu clúster de base de datos.
Crea un CR de sidecar
Aplica el siguiente manifiesto:
apiVersion: alloydbomni.dbadmin.goog/v1 kind: Sidecar metadata: name: SIDECAR_CR_NAME spec: sidecars: - image: CONTAINER_IMAGE command: ["CONTAINER_COMMAND"] args: ["CONTAINER_ARGS"] name: CONTAINER_NAME
Reemplaza las siguientes variables:
SIDECAR_CR_NAME
: Es el nombre de tu contenedor de archivo adicional.CONTAINER_IMAGE
: Es el nombre del archivo de imagen que se ejecutará en tu contenedor de archivo adicional. Por ejemplo,busybox
CONTAINER_COMMAND
: Es el comando para el contenedor que se ejecuta en el Pod. El comando puede ser una lista de cadenas entre comillas. Para obtener más información, consulta Cómo definir un comando y argumentos cuando creas un Pod.CONTAINER_ARGS
: Argumentos paraCONTAINER_COMMAND
.CONTAINER_NAME
: Es el nombre del contenedor. Puedes tener varios contenedores en el mismo CR de sidecar, y cada uno de ellos tendrá un nombre, una imagen, un comando y argumentos diferentes.
Para verificar que se haya creado el CR de sidecar, ejecuta el siguiente comando:
kubectl describe Sidecar/SIDECAR_CR_NAME
El resultado es similar a este:
Name: SIDECAR_CR_NAME Labels: <none> Annotations: <none> API Version: alloydbomni.dbadmin.goog/v1 Kind: Sidecar Metadata: Creation Timestamp: 2024-04-15T21:49:00Z Finalizers: sidecars.dbadmin.goog/finalizer Generation: 2 Resource Version: 2561336 UID: e57f2e13-20c5-4905-b13b-39203bab36b4 Spec: Sidecars: Args: CONTAINER_ARGS Command: CONTAINER_COMMAND Image: CONTAINER_IMAGE Name: CONTAINER_NAME Resources: Status: Observed Generation: 2 Reconciled: true Events: <none>
Registra un contenedor secundario
Para registrar el nombre del contenedor secundario en tu clúster de base de datos, usa el siguiente comando para aplicar la especificación actualizada:
kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -p '{"spec":{"primarySpec":{"sidecarRef":{"name":"SIDECAR_CR_NAME"}}}}' --type=merge
Reemplaza las siguientes variables:
DB_CLUSTER_NAME
: Es el nombre de tu clúster de base de datos.SIDECAR_CR_NAME
: Es el nombre de tu contenedor de archivo adicional.
Accede a los registros de un contenedor de sidecar
Crea o modifica un contenedor adicional existente para que
spec.sidecars.volumeMounts.name
se establezca enobsdisk
yspec.sidecars.volumeMounts.mountPath
en una ruta de acceso visible dentro del contenedor adicional.apiVersion: alloydbomni.dbadmin.goog/v1 kind: Sidecar metadata: name: SIDECAR_CR_NAME spec: sidecars: - image: CONTAINER_IMAGE command: ["CONTAINER_COMMAND"] args: ["CONTAINER_ARGS"] name: CONTAINER_NAME volumeMounts: - name: obsdisk mountPath: LOGS_PATH
Reemplaza lo siguiente:
SIDECAR_CR_NAME
: Es el nombre de tu contenedor de archivo adicional.CONTAINER_IMAGE
: Es el nombre del archivo de imagen que se ejecutará en tu contenedor de archivo adicional. Por ejemplo,busybox
CONTAINER_COMMAND
: Es el comando para el contenedor que se ejecuta en el Pod. El comando puede ser una lista de cadenas entre comillas. Para obtener más información, consulta Cómo definir un comando y argumentos cuando creas un Pod.CONTAINER_ARGS
: Son los argumentos deCONTAINER_COMMAND
.CONTAINER_NAME
: Es el nombre del contenedor. Puedes tener varios contenedores en el mismo CR de sidecar, y cada contenedor tiene un nombre, una imagen, un comando y argumentos diferentes.LOGS_PATH
: Es la ruta de acceso dentro del contenedor de archivo adicional en la que AlloyDB Omni debe generar registros.
Registra el contenedor sidecar nuevo o modificado.