Use a sidecar container in Kubernetes

If your database runs in a Kubernetes cluster, then you can add sidecar containers to your database cluster. Sidecar containers run independently alongside the main container and serve requests for application monitoring, logging, and tracing. You can export logs, metrics, and traces to the backend of your choice using custom agents to AlloyDB Omni.

If your database runs in a Kubernetes cluster, then you can add sidecar containers to your database cluster using the AlloyDB Omni Kubernetes Operator. AlloyDB Omni Operator sidecar containers are regular Kubernetes containers that run independently alongside the main application container within the same Pod. You can use these sidecar containers to serve requests for application monitoring, logging, and tracing.

AlloyDB Omni Operator sidecar containers are distinct from Kubernetes built-in sidecar containers.

To manually add a sidecar container to an existing AlloyDB Omni installation, you create a sidecar custom resource (CR) and add it to your database cluster.

Create a sidecar CR

  1. Apply the following manifest:

    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
    

    Replace the following:

    • SIDECAR_CR_NAME: the name to apply to your sidecar container.
    • CONTAINER_IMAGE: the name of the file containing the image to run in the sidecar container, for example, busybox.
    • CONTAINER_COMMAND: the command for the container that runs in the Pod. The command can be a list of quoted strings. For more information, see Define a command and arguments when you create a Pod.
    • CONTAINER_ARGS: the arguments for the command for the container that runs in the Pod.
    • CONTAINER_NAME: the name of the container. You can have multiple containers in the same sidecar CR, and each container has a different container name, image, command, and arguments.
  2. To verify that the sidecar CR is created, run the following command:

    kubectl describe SIDECAR_CR_NAME
    

    The output is similar to the following:

    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>
    

Register a sidecar container

To register the sidecar container name to your database cluster, complete the following steps:

  1. Add the sidecarRef attribute to your database cluster spec object specification in its manifest:

    sidecarRef:
      name: SIDECAR_CR_NAME
    
  2. Use the following command to apply the updated specification:

      kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -p '{"spec":{"primarySpec":{"sidecarRef":{"name":SIDECAR_CR_NAME}}}}' --type=merge

    Replace the following:

    • DB_CLUSTER_NAME: the name of your database cluster.
    • SIDECAR_CR_NAME: the name to apply to your sidecar container.

What's next