Usa un contenedor secundario en Kubernetes

Si tu base de datos se ejecuta en un clúster de Kubernetes, puedes agregar contenedores de Sidecar a tu clúster de base 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 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 un contenedor lateral de forma manual a una instalación existente de AlloyDB Omni, crea un recurso personalizado (CR) lateral 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 las siguientes variables:

    • SIDECAR_CR_NAME: Es el nombre de tu contenedor del archivo adicional.
    • CONTAINER_IMAGE: Es el nombre del archivo de imagen que se ejecutará en tu 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: Son argumentos para CONTAINER_COMMAND.
    • CONTAINER_NAME: Es el nombre del contenedor. Puedes tener varios contenedores en el mismo CR de contenedor lateral, y cada contenedor 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/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 bases 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 bases de datos.
  • SIDECAR_CR_NAME: Es el nombre de tu contenedor del archivo adicional.

Accede a los registros desde un contenedor de sidecar

  1. Crea o modifica un contenedor adicional existente para que spec.sidecars.volumeMounts.name se establezca en obsdisk y spec.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 del archivo adicional.
    • CONTAINER_IMAGE: Es el nombre del archivo de imagen que se ejecutará en tu 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 para CONTAINER_COMMAND.
    • CONTAINER_NAME: Es el nombre del contenedor. Puedes tener varios contenedores en el mismo CR de contenedor lateral, y cada contenedor tiene un nombre, una imagen, un comando y argumentos diferentes.
    • LOGS_PATH: Es la ruta de acceso dentro del contenedor del archivo adicional al que AlloyDB Omni debe enviar los registros.
  2. Registra tu contenedor lateral nuevo o modificado.

¿Qué sigue?