Usar um contêiner sidecar no Kubernetes

Selecione uma versão da documentação:

Se o banco de dados for executado em um cluster do Kubernetes, você poderá adicionar contêineres de arquivo secundário ao cluster de banco de dados. Os contêineres secundários são executados de forma independente ao lado do contêiner principal e atendem solicitações de monitoramento, geração de registros e rastreamento de aplicativos. É possível exportar registros, métricas e rastros para o back-end de sua escolha usando agentes personalizados para o AlloyDB Omni.

Se o banco de dados for executado em um cluster do Kubernetes, você poderá adicionar contêineres de arquivo secundário ao cluster de banco de dados usando o operador do AlloyDB Omni no Kubernetes. Os contêineres de arquivo secundário do operador do AlloyDB Omni são contêineres normais do Kubernetes contêineres que são executados de forma independente ao lado do contêiner principal do aplicativo no mesmo pod. É possível usar esses contêineres secundários para atender solicitações de monitoramento, geração de registros e rastreamento de aplicativos.

Os contêineres de arquivo secundário do operador do AlloyDB Omni são diferentes dos contêineres de arquivo secundário integrados do Kubernetes .

Para adicionar manualmente um contêiner secundário a uma instalação do AlloyDB Omni, crie um recurso personalizado (CR) de contêiner secundário e adicione-o ao cluster de banco de dados.

Criar um CR de arquivo secundário

  1. Aplique o seguinte manifesto:

    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

    Substitua:

    • SIDECAR_CR_NAME: o nome a ser aplicado ao contêiner secundário.
    • CONTAINER_IMAGE: o nome do arquivo que contém a imagem a ser executada no contêiner secundário, por exemplo, busybox.
    • CONTAINER_COMMAND: o comando do contêiner executado no pod. O comando pode ser uma lista de strings entre aspas. Para mais informações, consulte Definir um comando e argumentos ao criar um pod.
    • CONTAINER_ARGS: os argumentos do comando do contêiner executado no pod.
    • CONTAINER_NAME: o nome do contêiner. É possível ter vários contêineres no mesmo CR de arquivo secundário, e cada contêiner tem um nome, imagem, comando e argumentos diferentes.

  2. Para verificar se o CR de arquivo secundário foi criado, execute o seguinte comando:

    kubectl describe SIDECAR_CR_NAME

    O resultado será assim:

    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>

Registrar um contêiner secundário

Para registrar o nome do contêiner secundário no cluster de banco de dados, siga estas etapas:

  1. Adicione o atributo sidecarRef à especificação do objeto spec do cluster de banco de dados no manifesto:

    sidecarRef:
  name: SIDECAR_CR_NAME

  2. Use o seguinte comando para aplicar a especificação atualizada:

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

    Substitua:

    • DB_CLUSTER_NAME: o nome do cluster de banco de dados.
    • SIDECAR_CR_NAME: o nome a ser aplicado ao contêiner secundário.

A seguir