Usa un contenedor secundario en Kubernetes

Si tu base de datos se ejecuta en un clúster de Kubernetes, puedes agregar contenedores secundarios a tu clúster de base de datos. Los contenedores Sidecar se ejecutan de forma independiente junto con el contenedor principal y entregan solicitudes de supervisión, registro y seguimiento de aplicaciones. Puedes exportar registros, métricas y seguimientos al backend que elijas con agentes personalizados a AlloyDB Omni.

Si tu base de datos se ejecuta en un clúster de Kubernetes, puedes agregar contenedores secundarios 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 normales de Kubernetes que se ejecutan de forma independiente junto con el contenedor de la aplicación principal dentro del mismo pod. Puedes usar estos contenedores de 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

  1. 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 lo siguiente:

    • SIDECAR_CR_NAME: Es el nombre que se aplicará a tu contenedor del archivo adicional.
    • CONTAINER_IMAGE: Es el nombre del archivo que contiene la imagen que se ejecutará en el contenedor del archivo adicional, por ejemplo, busybox.
    • CONTAINER_COMMAND: Es el comando del contenedor que se ejecuta en el Pod. El comando puede ser una lista de cadenas con comillas. Para obtener más información, consulta Cómo definir un comando y argumentos cuando creas un pod.
    • CONTAINER_ARGS: Los argumentos del comando para el contenedor que se ejecuta en el Pod.
    • CONTAINER_NAME: Es el nombre del contenedor. Puedes tener varios contenedores en el mismo CR de contenedor lateral, y cada uno tiene un nombre, una imagen, un comando y argumentos diferentes.

  2. Para verificar que se creó el CR del contenedor secundario, ejecuta el siguiente comando:

    kubectl describe 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 sidecar

Para registrar el nombre del contenedor del contenedor lateral en tu clúster de base de datos, completa los siguientes pasos:

  1. Agrega el atributo sidecarRef a la especificación del objeto spec del clúster de bases de datos en su manifiesto:

    sidecarRef:
  name: SIDECAR_CR_NAME

  2. 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 lo siguiente:

    • DB_CLUSTER_NAME: Es el nombre de tu clúster de bases de datos.
    • SIDECAR_CR_NAME: Es el nombre que se aplicará a tu contenedor del archivo adicional.

¿Qué sigue?