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
ImportanteTodos 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=trueativada no parâmetrofeatureGatesdo 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:
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.Caso o pod não possua esse rótulo, a injeção não ocorre.
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
-
Verifique se o pod possui dois containers para confirmar a injeção do sidecar:
kubectl get podSaída esperada:
NAME READY STATUS RESTARTS AGE echo-server-f8bdc5844-r44nj 2/2 Running 0 14m -
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.logSaída esperada:
2025-04-29T11:26:06.783205694+08:00 stderr F 2025/04/29 03:26:06 Server is listening on :8080 -
Valide se o sidecar consegue ler o ConfigMap entre namespaces:
kubectl exec echo-server-f8bdc5844-r44nj -c filebeat -- cat /etc/filebeat.yml
Próximos passos
ACK Virtual Node — Gerencie componentes e configurações de nó virtual
OpenKruise SidecarSet — Referência completa de recursos do SidecarSet
Montar um volume stdlog para coletar logs de saída padrão de um container — Coleta de logs de pods de nó virtual
Customize control plane component parameters — Ative feature gates no Kube API Server