Create a DaemonSet - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Serviços no nível do nó, como coletores de log e agentes de monitoramento, devem ser executados em todos os nós do cluster. O DaemonSet garante a execução de exatamente um pod em cada nó: ao adicionar um nó ao cluster, o DaemonSet cria um pod nele automaticamente; ao remover um nó, o sistema limpa o pod. Este tópico explica o funcionamento do agendamento do DaemonSet e como criá-lo pelo console ou kubectl.

Casos de uso comuns:

Daemons de coleta de log (por exemplo, Fluentd)
Agentes de monitoramento de nó (por exemplo, Prometheus Node Exporter)

Para workloads que exigem contagem de réplicas ou agendamento avançado além da alocação de um pod por nó, use um Deployment . Para a especificação completa do DaemonSet, consulte a documentação do Kubernetes .

Funcionamento do agendamento

Por padrão, o DaemonSet aloca um pod em cada nó. Três mecanismos podem restringir quais nós recebem pods.

Taints e tolerations

Os pods do DaemonSet respeitam as taints dos nós. O pod não é executado em um nó se não tolerar as taints desse nó. As seguintes tolerations são adicionadas automaticamente aos pods do DaemonSet:

Chave da toleration	Efeito	Comportamento
`node.kubernetes.io/unschedulable`	`NoSchedule`	Os pods são agendados em nós não agendáveis.
`node.kubernetes.io/not-ready`	`NoExecute`	Os pods são executados em nós que não estão prontos. Pods em execução não são evacuados por 300 segundos.
`node.kubernetes.io/unreachable`	`NoExecute`	Os pods são executados em nós inacessíveis. Pods em execução não são evacuados por 300 segundos.

nodeSelector

Se um DaemonSet incluir um nodeSelector, os pods serão executados apenas em nós correspondentes ao rótulo. Por exemplo, nodeSelector: { disktype: ssd } limita o DaemonSet a nós rotulados com disktype=ssd.

Affinity e anti-affinity

Regras de affinity de nó, affinity de pod e anti-affinity de pod também se aplicam aos pods do DaemonSet.

Pré-requisitos

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

Um cluster ACK com pelo menos um nó
(Para kubectl) Uma conexão kubectl com o cluster. Consulte Conectar-se a um cluster usando kubectl
Acesso à rede pública para o cluster ou nós, pois a imagem do exemplo é pública. Configure uma das seguintes opções:
- (Recomendado) Ative acesso à rede pública para o cluster criando um gateway NAT de Internet para a VPC do cluster
- Atribuir um endereço IP público estático a cada nó onde o workload é executado

Crie um DaemonSet pelo console

Faça login no Container Service Management Console. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique em no nome do cluster. No painel de navegação à esquerda, escolha Workloads > DaemonSets.
Na página DaemonSets, clique em Create from Image.
Configure o DaemonSet. O formulário é idêntico ao de um Deployment, com duas diferenças: Para todas as outras opções de configuração, consulte Criar um Deployment.
- Basic Information: Não há configuração de Replicas. O número de pods depende da quantidade de nós.
- Advanced: Não há configuração de Scaling.

Crie um DaemonSet com kubectl

Salve o YAML a seguir em um arquivo chamado daemonset.yaml.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-test
  namespace: default  # Change the namespace as needed.
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        resources:
          limits:
            cpu: '1'
            memory: 2Gi
          requests:
            cpu: 500m
            memory: 512Mi

Aplique o manifesto.

kubectl apply -f daemonset.yaml

Saída esperada:

daemonset.apps/nginx-test created

Verifique se há um pod em execução em cada nó.

kubectl get pods --all-namespaces -o wide | grep nginx-test

A saída lista um pod por nó, cada um atribuído a um endereço IP de nó diferente.

default     nginx-test-8mqvh     1/1     Running     0          3m38s   192.168.*.**    cn-shanghai.192.168.**.250   <none>           <none>
default     nginx-test-ltlx6     1/1     Running     0          3m38s   192.168.*.**    cn-shanghai.192.168.**.98    <none>           <none>
default     nginx-test-n6zrv     1/1     Running     0          3m38s   192.168.*.**    cn-shanghai.192.168.**.17    <none>           <none>

Exemplo: visualize pods do kube-proxy

O componente kube-proxy do Kubernetes é implantado como um DaemonSet, com um pod por nó. Execute o comando a seguir para inspecioná-lo:

kubectl get pods --all-namespaces -o wide | grep kube-proxy

Saída esperada:

kube-system     kube-proxy-worker-hfzkh     1/1     Running     0          2d21h   192.168.*.92    cn-shanghai.192.168.*.92   <none>           <none>
kube-system     kube-proxy-worker-pxnnf     1/1     Running     0          2d21h   192.168.*.11    cn-shanghai.192.168.*.11   <none>           <none>
kube-system     kube-proxy-worker-r2t26     1/1     Running     0          2d21h   192.168.*.7     cn-shanghai.192.168.*.7    <none>           <none>

Como o kube-proxy usa hostNetwork: true, o endereço IP de cada pod corresponde ao endereço IP do respectivo nó.

Próximos passos

Se um pod não iniciar ou apresentar comportamento inesperado, consulte Solucionar problemas de pods.
Para problemas gerais na criação de workloads, consulte Perguntas frequentes sobre workloads.
Para obter informações detalhadas sobre agendamento, consulte Agendamento.