Todos os produtos
Search
Central de documentação

Container Service for Kubernetes:Injetar containers sidecar em pods de nó virtual

Última atualização: Sep 14, 2026

Nós virtuais não suportam DaemonSets. Por isso, não é possível executar agentes por nó, como coletores de logs ou sondas de monitoramento, da maneira tradicional. Use o recurso SidecarSet do OpenKruise para injetar automaticamente containers sidecar em pods agendados para nós virtuais. O SidecarSet gerencia os containers injetados independentemente da especificação do pod da aplicação. Assim, você pode atualizar um agente de logs em todos os pods de nó virtual sem modificar os deployments da aplicação.

Conceitos principais

  • O SidecarSet é um recurso central do OpenKruise, mecanismo de automação de aplicações cloud-native open source da Alibaba Cloud. Um SidecarSet define quais containers sidecar injetar e quais pods atingir. Ele gerencia todo o ciclo de vida dos containers injetados independentemente do container da aplicação.

  • O SidecarSetResourceBinding é um recurso personalizado do ACK que concede ao SidecarSet acesso somente leitura (Get, List, Watch) a ConfigMaps ou Secrets em outros namespaces. O acesso entre namespaces exige autorização explícita por meio desse recurso.

  • Os nós virtuais suportam tanto Elastic Container Instance (ECI) quanto poder computacional ACS. O ACS suporta cargas de trabalho de CPU e GPU.

    Nós virtuais não suportam DaemonSets. Use containers sidecar injetados via SidecarSet como equivalente funcional.

Pré-requisitos

Antes de começar, verifique se você tem:

  • Um cluster gerenciado ACK Pro ou cluster dedicado ACK executando Kubernetes 1.22 ou superior

  • O componente ack-virtual-node na versão v2.10.0 ou superior. Consulte ACK Virtual Node

  • O componente ack-kruise na versão v1.3.0 ou superior. Consulte OpenKruise

    Importante

    Todos os recursos do SidecarSet do OpenKruise v1.3.0 e anteriores têm suporte total em cenários de nó virtual. Novos recursos do SidecarSet introduzidos após a v1.3.0 não são suportados.

  • A feature gate SidecarSetServerlessPod=true ativada no parâmetro featureGates do Kube API Server. Consulte Customize control plane component parameters

Como funciona a injeção

O controlador do SidecarSet determina se deve injetar containers em um pod com base nos rótulos do pod:

  1. Se o pod tiver o rótulo serverless.alibabacloud.com/virtual-node: "true", o SidecarSet identifica a correspondência e injeta os containers sidecar definidos.

  2. Caso o pod não possua esse rótulo, a injeção não ocorre.

  3. O ACK adiciona o rótulo automaticamente após confirmar o agendamento do pod para um nó virtual.

Para excluir um pod específico da injeção, remova esse rótulo da especificação do pod ou use um selector mais direcionado no SidecarSet.

Capacidades

Identificar pods de nó virtual

Use o rótulo serverless.alibabacloud.com/virtual-node: "true" como seletor do SidecarSet para corresponder a todos os pods em nós virtuais:

apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
metadata:
  name: filebeat-sidecarset
spec:
  selector:
    matchLabels:
      serverless.alibabacloud.com/virtual-node: "true" # Matches all pods scheduled to virtual nodes.

Para obter todas as opções de seletor do SidecarSet, consulte SidecarSet.

Referenciar ConfigMaps e Secrets entre namespaces

Como nós virtuais não suportam DaemonSets, os containers sidecar substituem os containers principais do DaemonSet. Esses containers frequentemente precisam acessar ConfigMaps, como arquivos de configuração de agente, residentes em um namespace diferente do pod da aplicação.

Referencie um ConfigMap ou Secret de outro namespace usando o formato Namespace/Name na definição do volume:

volumes:
- name: config
  configMap:
    name: kube-system/filebeat-config # Use the Namespace/Name format to reference a ConfigMap in another namespace.

O acesso entre namespaces requer uma autorização SidecarSetResourceBinding. Consulte Authorize cross-namespace access abaixo.

Autorizar acesso entre namespaces

Crie um SidecarSetResourceBinding para conceder ao SidecarSet acesso somente leitura a ConfigMaps ou Secrets em outro namespace. Crie o recurso no namespace proprietário do ConfigMap ou Secret:

# Authorizes filebeat-sidecarset. Pods matching the SidecarSet can access the filebeat-config ConfigMap in the kube-system namespace.
apiVersion: sidecarset.alibabacloud.com/v1alpha1
kind: SidecarSetResourceBinding
metadata:
  name: filebeat-sidecarset-resourcebinding
  namespace: kube-system # This SidecarSetResourceBinding only authorizes resources in the kube-system namespace.
  labels:
spec:
  subjects:
    - kind: SidecarSet
      name: filebeat-sidecarset
  resourceRefs:
    - kind: ConfigMap # Only grants read-only permission (Get, List, Watch).
      name: filebeat-config

Controlar a ordem de inicialização e encerramento dos containers

Containers sidecar geralmente precisam iniciar antes dos containers da aplicação e encerrar depois deles. Configure a ordem de inicialização e encerramento para:

Encerrar containers sidecar em pods de Job

Em pods do tipo Job, um container sidecar que continua em execução após o encerramento do container da aplicação impede a conclusão do Job. Defina a variável de ambiente ECI_SIDECAR_CONTAINER como "true" para encerrar o container sidecar automaticamente quando o container da aplicação finalizar:

containers:
- name: filebeat
  image: busybox
  env:
  - name: ECI_SIDECAR_CONTAINER  # Causes the sidecar container to exit after the application container exits.
    value: "true"

Para detalhes completos de configuração, consulte Forcibly terminate the sidecar container and ignore the container exit code.

Atualizar containers sidecar sem tempo de inatividade

O OpenKruise suporta atualizações a quente para containers sidecar, permitindo atualizações contínuas sem afetar a disponibilidade do pod. Esse mecanismo é totalmente compatível com nós virtuais. Consulte Sidecar hot upgrade na documentação do OpenKruise para detalhes de configuração.

Coletar logs de saída padrão

Monte os logs de saída padrão do pod como um volume stdlog no container sidecar para coletar logs do container da aplicação:

apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
metadata:
  name: filebeat-sidecarset
spec:
  selector:
    matchLabels:
      serverless.alibabacloud.com/virtual-node: "true" # Matches all pods scheduled to virtual nodes.
  updateStrategy:
    type: NotUpdate
  containers:
  - name: filebeat
    image: busybox
    imagePullPolicy: IfNotPresent
    args: [
      "/bin/sh",
      "-c",
      "cat /var/log/std/filebeat/0.log && sleep 36000",
    ]
    volumeMounts:
    - name: stdlog # Mounts the pod's standard output log volume for the sidecar container to read.
      mountPath: /var/log/std
      readOnly: true
  volumes:
  - name: stdlog
    csi:
      driver: stdlogplugin.csi.alibabacloud.com

Os logs ficam disponíveis em /var/log/std/<container-name>/0.log dentro do container sidecar. Para mais informações, consulte Mount container logs by using stdlog.

Exemplo de ponta a ponta

Este exemplo injeta um container sidecar filebeat em um pod da aplicação echo-server em um nó virtual. O sidecar monta um ConfigMap entre namespaces e coleta os logs de saída padrão do pod da aplicação.

Etapa 1: Implantar o ConfigMap

Crie o arquivo filebeat-config.yaml com o conteúdo a seguir e aplique-o. Este exemplo monta o arquivo de configuração no container sidecar para demonstração. As variáveis neste arquivo são espaços reservados e não estão ativas.

kubectl apply -f filebeat-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: filebeat-config
  namespace: kube-system
  labels:
    k8s-app: filebeat
data:
  filebeat.yml: |-
    filebeat.inputs:
    - type: log
      paths:
        - /var/log/std/*.log
      processors:
        - add_kubernetes_metadata:
            host: ${NODE_NAME} # Not effective. Do not modify. Use directly.
            matchers:
            - logs_path:
                logs_path: "/var/log/std/"

    # To enable hints based autodiscover, remove `filebeat.inputs` configuration and uncomment this:
    #filebeat.autodiscover:
    #  providers:
    #    - type: kubernetes
    #      node: ${NODE_NAME}
    #      hints.enabled: true
    #      hints.default_config:
    #        type: container
    #        paths:
    #          - /var/log/containers/*${data.kubernetes.container.id}.log

    processors:
      - add_cloud_metadata:
      - add_host_metadata:

    cloud.id: ${ELASTIC_CLOUD_ID}  # Not effective. Do not modify. Use directly.
    cloud.auth: ${ELASTIC_CLOUD_AUTH}  # Not effective. Do not modify. Use directly.

    output.elasticsearch:
      hosts: ['${ELASTICSEARCH_HOST:elasticsearch}:${ELASTICSEARCH_PORT:9200}']
      username: ${ELASTICSEARCH_USERNAME}  # Not effective. Do not modify. Use directly.
      password: ${ELASTICSEARCH_PASSWORD}  # Not effective. Do not modify. Use directly.

Etapa 2: Implantar o SidecarSet

Crie o arquivo sidecarset.yaml com o conteúdo a seguir e aplique-o. O container filebeat usa busybox para demonstração em vez do binário real do filebeat e imprime o arquivo de configuração montado.

kubectl apply -f sidecarset.yaml
apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
metadata:
  name: filebeat-sidecarset
spec:
  selector:
    matchLabels:
      serverless.alibabacloud.com/virtual-node: "true" # Matches all pods scheduled to virtual nodes.
  updateStrategy:
    type: NotUpdate
  containers:
  # This example does not actually run filebeat; it uses busybox cat instead.
  #- name: filebeat
  #  image: docker.elastic.co/beats/filebeat:8.6.1
  #  args: [
  #    "-c", "/etc/filebeat.yml",
  #    "-e",
  #  ]
  - name: filebeat
    image: busybox
    imagePullPolicy: IfNotPresent
    args: [
      "/bin/sh",
      "-c",
      "cat /etc/filebeat.yml && sleep 36000",
    ]
    env:
    - name: ECI_SIDECAR_CONTAINER         # Causes the sidecar container to exit after the application container exits.
      value: "true"
    volumeMounts:
    - name: config
      mountPath: /etc/filebeat.yml
      readOnly: true
      subPath: filebeat.yml
    - name: stdlog                        # Mounts the pod's standard output logs for the sidecar container to read.
      mountPath: /var/log/std
      readOnly: true
  volumes:
  - name: config
    configMap:
      name: kube-system/filebeat-config  # Uses the Namespace/Name format to reference a ConfigMap in another namespace.
  - name: stdlog
    csi:
      driver: stdlogplugin.csi.alibabacloud.com

Etapa 3: Autorizar acesso ao ConfigMap entre namespaces

O pod da aplicação executa no namespace default, enquanto o ConfigMap está em kube-system. Crie um SidecarSetResourceBinding para autorizar o acesso.

Crie o arquivo sidecarset-resourcebinding.yaml com o conteúdo a seguir e aplique-o:

kubectl apply -f sidecarset-resourcebinding.yaml
# Authorizes filebeat-sidecarset. Pods matching the SidecarSet can access the filebeat-config ConfigMap in the kube-system namespace.
apiVersion: sidecarset.alibabacloud.com/v1alpha1
kind: SidecarSetResourceBinding
metadata:
  name: filebeat-sidecarset-resourcebinding
  namespace: kube-system # This SidecarSetResourceBinding only authorizes resources in the kube-system namespace.
  labels:
spec:
  subjects:
    - kind: SidecarSet
      name: filebeat-sidecarset
  resourceRefs:
    - kind: ConfigMap
      name: filebeat-config

Etapa 4: Implantar o pod da aplicação

Crie o arquivo echo-server.yaml com o conteúdo a seguir e aplique-o. O rótulo alibabacloud.com/eci: "true" agenda o pod para um nó virtual.

kubectl apply -f echo-server.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo-server
  labels:
    app: echo-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: echo-server
  template:
    metadata:
      labels:
        app: echo-server
        alibabacloud.com/eci: "true"
    spec:
      containers:
        - name: echo-server
          image: hashicorp/http-echo
          imagePullPolicy: IfNotPresent
          args:
            - -listen=:8080
            - -text="hello world"

Etapa 5: Verificar a injeção

  1. Verifique se o pod possui dois containers para confirmar a injeção do sidecar:

    kubectl get pod

    Saída esperada:

    NAME                          READY   STATUS    RESTARTS   AGE
    echo-server-f8bdc5844-r44nj   2/2     Running   0          14m
  2. Confirme se o sidecar consegue ler os logs de saída padrão do pod da aplicação:

    kubectl exec echo-server-f8bdc5844-r44nj -c filebeat -- cat /var/log/std/echo-server/0.log

    Saída esperada:

    2025-04-29T11:26:06.783205694+08:00 stderr F 2025/04/29 03:26:06 Server is listening on :8080
  3. Valide se o sidecar consegue ler o ConfigMap entre namespaces:

    kubectl exec echo-server-f8bdc5844-r44nj -c filebeat -- cat /etc/filebeat.yml

    Expandir para visualizar a saída de exemplo

    filebeat.inputs:
    - type: log
      paths:
        - /var/log/std/*.log
      processors:
        - add_kubernetes_metadata:
            host: ${NODE_NAME} # Not effective. Do not modify. Use directly.
            matchers:
            - logs_path:
                logs_path: "/var/log/std/"
    
    # To enable hints based autodiscover, remove `filebeat.inputs` configuration and uncomment this:
    #filebeat.autodiscover:
    #  providers:
    #    - type: kubernetes
    #      node: ${NODE_NAME}
    #      hints.enabled: true
    #      hints.default_config:
    #        type: container
    #        paths:
    #          - /var/log/containers/*${data.kubernetes.container.id}.log
    
    processors:
      - add_cloud_metadata:
      - add_host_metadata:
    
    cloud.id: ${ELASTIC_CLOUD_ID}  # Not effective. Do not modify. Use directly.
    cloud.auth: ${ELASTIC_CLOUD_AUTH}  # Not effective. Do not modify. Use directly.
    
    output.elasticsearch:
      hosts: ['${ELASTICSEARCH_HOST:elasticsearch}:${ELASTICSEARCH_PORT:9200}']
      username: ${ELASTICSEARCH_USERNAME}  # Not effective. Do not modify. Use directly.
      password: ${ELASTICSEARCH_PASSWORD}  # Not effective. Do not modify. Use directly.

Próximos passos