DaemonSet no Kubernetes: tutorial, casos de uso e boas práticas

Tutorial de DaemonSet no Kubernetes

Este tutorial explica como criar e trabalhar com um DaemonSet. Ele foi adaptado da documentação do Kubernetes.

1. Crie um DaemonSet do Kubernetes

Para criar um DaemonSet do Kubernetes, defina-o em um manifesto YAML usando apiVersion: apps/v1 e kind: DaemonSet. O manifesto deve incluir os campos padrão do Kubernetes, como metadata e spec, além de um template de pod em .spec.template. O .spec.selector do DaemonSet deve corresponder aos rótulos atribuídos ao template do pod; depois que o DaemonSet é criado, esse seletor não pode mais ser alterado. O Kubernetes também exige que a política de reinicialização do pod seja Always, seja explicitamente ou pela configuração padrão.

Por exemplo, o manifesto a seguir cria um DaemonSet simples que executa um contêiner em cada nó elegível:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: example-daemonset
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: example
  template:
    metadata:
      labels:
        app.kubernetes.io/name: example
    spec:
      containers:
      - name: pause
        image: registry.k8s.io/pause

Administradores podem estender o template do pod com opções como requests de recursos, montagens de volumes, tolerations, node selectors e afinidade de nós. Essas configurações determinam como os pods do DaemonSet são executados e, quando restrições de agendamento são especificadas, quais nós são elegíveis para hospedá-los. A documentação do Kubernetes traz um exemplo básico em que o DaemonSet agenda um pod em cada nó aplicável.

2. Implante um DaemonSet

Depois de criar o manifesto do DaemonSet, implante-o no cluster com kubectl apply. Se o manifesto estiver salvo localmente como daemonset.yaml, execute:

kubectl apply -f daemonset.yaml

O Kubernetes também demonstra como aplicar um DaemonSet diretamente a partir de um manifesto YAML hospedado. Por exemplo:

kubectl apply -f https://k8s.io/examples/application/basic-daemonset.yaml

O comando kubectl apply envia a configuração para a API do Kubernetes, e o controlador do DaemonSet determina quais nós são elegíveis e cria os pods necessários. À medida que nós elegíveis adicionais entram no cluster, o controlador cria automaticamente os pods do DaemonSet para eles. Pods associados a nós removidos são posteriormente eliminados pelo garbage collection.

Após a implantação, as alterações no DaemonSet geralmente podem ser gerenciadas modificando o manifesto e executando kubectl apply novamente. Para DaemonSets que usam a estratégia RollingUpdate, alterações no template do pod acionam uma atualização gradual dos pods gerenciados. O Kubernetes também suporta a estratégia de atualização OnDelete, para quando os administradores querem que os pods de substituição sejam criados somente depois que os existentes forem excluídos manualmente.

3. Verifique os pods do DaemonSet

Depois de implantar um DaemonSet, verifique se seus pods estão rodando nos nós esperados. A documentação do Kubernetes recomenda listar os pods com a opção -o wide, que inclui o nó atribuído a cada pod:

kubectl get pods -o wide

Para um DaemonSet projetado para rodar em todo o cluster, a saída deve mostrar um pod do DaemonSet em cada nó elegível. A coluna NODE facilita confirmar que os pods estão distribuídos conforme esperado.

Em ambientes com muitos workloads, use os rótulos definidos no template do pod do DaemonSet para limitar os resultados. Para o exemplo acima, o comando seria:

kubectl get pods -l app.kubernetes.io/name=example -o wide

Você também pode inspecionar o recurso DaemonSet em si com:

kubectl get daemonset example-daemonset

ou usar o nome abreviado do recurso:

kubectl get ds example-daemonset

O status do DaemonSet ajuda os administradores a comparar o número desejado de pods com o número de pods atuais, prontos e disponíveis. Se pods individuais não estiverem rodando corretamente, comandos como kubectl describe pod <pod-name> e kubectl logs <pod-name> podem ser usados para investigar problemas de agendamento ou de contêiner. O tutorial básico de DaemonSet do Kubernetes verifica o sucesso da implantação checando se a lista de pods resultante contém um pod para cada nó aplicável.

Boas práticas de DaemonSet no Kubernetes

1. Faça o right-sizing de requests e limits de CPU e memória

Definir requests e limits apropriados de CPU e memória é fundamental para a estabilidade do DaemonSet. Requests definem os recursos mínimos que um pod exige, enquanto limits definem o máximo que ele pode consumir. O superprovisionamento desperdiça recursos e pode causar falhas de agendamento em nós com recursos limitados. O subprovisionamento traz risco de despejo (eviction) de pods ou degradação de desempenho. Analise o perfil de recursos do workload para determinar padrões razoáveis, garantindo que cada pod do DaemonSet caiba confortavelmente em todos os nós de destino.

Revise e ajuste regularmente as configurações de recursos conforme a aplicação evolui. Os requisitos de recursos podem mudar devido a novas funcionalidades, aumento de carga ou mudanças na infraestrutura subjacente. Em ambientes Kubernetes dinâmicos, o ajuste periódico de requests e limits evita a contenção de recursos e favorece a utilização eficiente do cluster. Integre as revisões de recursos ao seu processo de gestão de mudanças para uma otimização contínua.

2. Baseie as configurações de recursos no uso histórico

Os requests de recursos devem refletir como os pods do DaemonSet se comportam sob workloads reais, em vez de depender apenas de estimativas iniciais. Use métricas históricas de CPU e memória de ferramentas como Prometheus, Grafana ou sua plataforma de monitoramento na nuvem para identificar o uso típico, a demanda de pico e as diferenças entre nós. Defina requests altos o suficiente para sustentar a operação normal, evitando reservas desnecessárias de recursos em cada nó de destino.

Analise métricas baseadas em percentis ao longo de períodos representativos, em vez de usar médias de curto prazo. Os requests de CPU geralmente podem se basear no uso sustentado, com margem para picos, enquanto os requests de memória devem considerar os picos observados. Como os DaemonSets multiplicam seu consumo de recursos por todos os nós, até pequenas melhorias nas configurações por pod podem liberar uma capacidade significativa do cluster.

3. Trate a memória com mais cautela do que a CPU

Os limits de CPU e memória têm modos de falha diferentes no Kubernetes. Quando um contêiner atinge seu limit de CPU, o Kubernetes limita (throttle) o uso de CPU, o que normalmente causa processamento mais lento. Quando um contêiner ultrapassa seu limit de memória, porém, ele pode ser encerrado pelo kernel com um erro de falta de memória (OOM). Para agentes em nível de nó, reinicializações repetidas podem criar lacunas na cobertura de logging, monitoramento ou segurança.

Defina requests e limits de memória com margem suficiente para picos temporários e para o crescimento do workload. Monitore o uso de pico de memória e os eventos de OOM antes de reduzir as alocações. Para agentes com requisitos de memória imprevisíveis, um limit de memória restritivo pode ser mais prejudicial do que uma superalocação moderada; portanto, valide os limits com base nos padrões de uso em produção.

4. Use a estratégia de atualização adequada

Os DaemonSets suportam as estratégias de atualização RollingUpdate e OnDelete. A RollingUpdate, que é o padrão, substitui automaticamente os pods existentes quando o template do pod do DaemonSet muda. Configurações como maxUnavailable e maxSurge podem controlar quantos pods do DaemonSet ficam indisponíveis ou são adicionados temporariamente durante uma atualização.

Use OnDelete quando a substituição de pods precisar ser controlada explicitamente. Com essa estratégia, atualizar o template do pod não substitui automaticamente os pods existentes; os administradores devem excluí-los antes que o Kubernetes crie pods a partir do novo template. Seja qual for a estratégia escolhida, considere o impacto de agentes indisponíveis na cobertura de logging, monitoramento, rede ou segurança durante as atualizações.

5. Monitore continuamente a eficiência conforme o cluster muda

O consumo de recursos de um DaemonSet cresce com o número de nós elegíveis. Um pod que usa recursos modestos em um nó pode representar um consumo agregado substancial de CPU e memória em um cluster grande. Acompanhe tanto o uso por pod quanto o total de recursos consumidos por cada DaemonSet para entender seu impacto na capacidade do cluster.

Reavalie os DaemonSets quando os tipos de nó, os workloads ou o tamanho do cluster mudarem. Fique atento a requests de recursos não utilizados, throttling de CPU, pressão de memória, eventos de OOM, reinicializações e pods que não conseguem ser agendados. O monitoramento contínuo ajuda a identificar quando as configurações de recursos ou as regras de agendamento deixam de corresponder às condições reais de operação.

Otimizando o uso de recursos de DaemonSets com o PerfectScale

Como um DaemonSet posiciona um pod em cada nó elegível, até pequenas quantidades de super ou subprovisionamento se multiplicam pelo cluster. O PerfectScale by DoiT é uma plataforma de otimização de Kubernetes que é implantada com um único comando Helm e, a partir daí, entrega insights acionáveis e otimização autônoma em toda a stack K8s, para que agentes em nível de nó, como coletores de logs, exportadores de monitoramento e daemons de segurança, rodem com os recursos de que realmente precisam.

Principais recursos do PerfectScale:

• Right-sizing autônomo de workloads: o Podfit oferece uma visão granular da saúde e dos custos do cluster, prioriza as áreas que exigem atenção e otimiza workloads de forma autônoma com recomendações de right-sizing baseadas em dados, que podem ser aplicadas automaticamente.
• Otimização da utilização dos nós: o Infrafit fornece visibilidade abrangente da utilização dos nós e insights granulares que identificam e eliminam capacidade ociosa, além de ajudar a selecionar os nós certos para os seus workloads.
• Alinhamento com autoscalers: funciona em conjunto com HPA, KEDA, Karpenter, Cluster Autoscaler, EKS Auto Mode, Fargate, Node Auto Provisioning e Google Autopilot, com recomendações acionáveis para melhorar suas configurações.
• Alertas em tempo real com priorização: a autopriorização avançada destaca os riscos de resiliência, picos de custo e anomalias de maior impacto antes que afetem os usuários ou a fatura da nuvem, com alertas enviados para Slack, Datadog, MS Teams ou PagerDuty.
• Relatórios de tendências e governança: o relatório de Trends oferece visibilidade aprofundada das métricas de custo, desperdício e risco ao longo do tempo, por clusters, grupos de nós, namespaces e workloads, apoiando previsões e análise de causa raiz.
• Amplo suporte a ambientes: funciona em clusters on-premise e na nuvem, incluindo OpenShift, EKS, GKE e AKS, e suporta contêineres baseados em Windows, além de workloads efêmeros e de ML.

Saiba mais sobre a plataforma PerfectScale