DaemonSet

Nesta página, descrevemos os objetos DaemonSet do Kubernetes e o uso deles no Google Kubernetes Engine.

O que é um DaemonSet?

Assim como outros objetos de carga de trabalho, um DaemonSet gerencia grupos de pods replicados. No entanto, DaemonSets tentam aderir a um modelo de um pod por nó, seja em todo o cluster ou em um subconjunto de nós. À medida que você acrescenta nós a um pool, os DaemonSets automaticamente adicionam os pods aos novos nós, conforme necessário.

Os DaemonSets usam um modelo de pod que contém uma especificação (em inglês) para os respectivos pods. A especificação de pod determina como será cada pod: quais aplicativos serão executados dentro dos contêineres, quais volumes serão montados, rótulos, seletores e muito mais.

Os pods do DaemonSet estão sujeitos às mesmas regras de prioridade que qualquer outro pod. Os pods de DaemonSet respeitam os taints e as tolerâncias, no entanto, eles têm algumas tolerâncias implícitas.

Padrões de uso

Os DaemonSets são úteis para implantar tarefas contínuas em segundo plano que você precisa executar em todos ou em determinados nós e que não exigem intervenção do usuário. Exemplos dessas tarefas incluem daemons de armazenamento como ceph, daemons de coleta de registros como fluentd e daemons de monitoramento de nós como collectd.

Por exemplo, é possível ter DaemonSets para cada tipo de daemon executado em todos os nós. Como alternativa, você pode executar vários DaemonSets para um único tipo de daemon, mas fazer com que eles usem configurações diferentes para diferentes tipos de hardware e necessidades de recursos.

Como criar DaemonSets

É possível criar um DaemonSet usando kubectl apply ou kubectl create.

Veja a seguir um exemplo de um arquivo de manifesto de DaemonSet:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
spec:
  selector:
      matchLabels:
        name: fluentd # Label selector that determines which Pods belong to the DaemonSet
  template:
    metadata:
      labels:
        name: fluentd # Pod template's label selector
    spec:
      nodeSelector:
        type: prod # Node label selector that determines on which nodes Pod should be scheduled
                   # In this case, Pods are only scheduled to nodes bearing the label "type: prod"
      containers:
      - name: fluentd
        image: gcr.io/google-containers/fluentd-elasticsearch:1.20
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi

Neste exemplo:

  • um DaemonSet chamado fluentd é criado, indicado pelo campo metadata: name;
  • o pod do DaemonSet é rotulado como fluentd;
  • um seletor de rótulo de nó (type: prod) declara em quais nós rotulados o DaemonSet programa seu pod.
  • o contêiner do pod extrai a imagem fluentd-elasticsearch na versão 1.20. A imagem do contêiner é hospedada pelo Container Registry.
  • O contêiner solicita 100 m de CPU e 200 Mi de memória, limitando-se a um total de 200 Mi de uso de memória.

Em suma, a especificação do pod contém as seguintes instruções:

  • Rotular o pod como fluentd.
  • Usar o seletor de rótulos de nó type: prod programando o pod para nós correspondentes e não programar em nós que não tenham o seletor de rótulos. Como alternativa, omitir o campo nodeSelector para programar em todos os nós.
  • Executar fluentd-elasticsearch na versão 1.20.
  • Solicitar alguns recursos de memória e CPU.

Para mais informações sobre configurações de DaemonSet, consulte a referência da API DaemonSet.

Como atualizar DaemonSets

É possível atualizar os DaemonSets alterando a respectiva especificação de pod, as solicitações e os limites de recursos, os rótulos e as anotações.

Para decidir como lidar com atualizações, o DaemonSet usa uma estratégia de atualização definida em spec: updateStrategy. Há duas estratégias, OnDelete e RollingUpdate:

  • OnDelete não exclui e recria automaticamente os pods do DaemonSet quando a configuração do objeto é alterada. Em vez disso, é preciso excluir manualmente os pods para que o controlador crie novos pods que reflitam as alterações.
  • RollingUpdate exclui e recria automaticamente os pods do DaemonSet. Com essa estratégia, as alterações válidas acionam automaticamente um lançamento. Essa é a estratégia de atualização padrão para DaemonSets.

As implementações de atualização podem ser monitoradas executando o seguinte comando:

kubectl rollout status ds daemonset-name

Para mais informações sobre a atualização de DaemonSets, consulte Executar uma atualização gradual em um DaemonSet na documentação do Kubernetes.

A seguir