DaemonSet

En esta página, se describen objetos DaemonSet de Kubernetes y su uso en Google Kubernetes Engine.

¿Qué es un DaemonSet?

Como otros objetos de carga de trabajo, un DaemonSet administra grupos de pods replicados. Sin embargo, los DaemonSets intentan seguir un modelo de un pod por nodo, ya sea en todo el clúster o en un subconjunto de nodos. A medida que agregas nodos al grupo de nodos, los DaemonSets agregan pods de forma automática a los nuevos nodos según sea necesario.

Los objetos DaemonSets usan una plantilla de pod que contiene una especificación para sus pods. La especificación del Pod determina cómo debe verse cada Pod: qué aplicaciones se deben ejecutar en sus contenedores, qué volúmenes debe activar, sus etiquetas y selectores, y demás.

Los pods del DaemonSet están sujetos a las mismas reglas de prioridad que cualquier otro pod. Los pods del DaemonSet respetan los taints y las tolerancias. Sin embargo, tienen algunas tolerancias implícitas.

Patrones de uso

Los DaemonSets son útiles para implementar tareas continuas en segundo plano que necesitas ejecutar en todos los nodos o en algunos de ellos y que no requieren intervención del usuario. Entre los ejemplos de tareas, se incluyen los daemons de almacenamiento, como ceph, los daemons de recopilación de registros, como fluentd, y los daemons de supervisión de nodos, como collectd.

Por ejemplo, puedes ejecutar los DaemonSets para cada tipo de daemon en todos tus nodos. De forma alternativa, puedes ejecutar múltiples DaemonSets para un solo tipo de daemon, pero deben tener diferentes opciones de configuración para diferentes tipos de hardware y necesidades de recursos.

Crea objetos DaemonSets

Puedes crear un DaemonSet mediante kubectl apply o kubectl create.

El siguiente es un ejemplo de un archivo de manifiesto 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

En este ejemplo, sucede lo siguiente:

  • Se crea un DaemonSet llamado fluentd, que se indica mediante el campo metadata: name.
  • El pod del DaemonSet se etiqueta como fluentd.
  • Un selector de etiquetas de nodos (type: prod) declara en qué nodos etiquetados el DaemonSet programa su pod.
  • El contenedor del pod extrae la imagen fluentd-elasticsearch en la versión 1.20. La imagen de contenedor se aloja en Container Registry.
  • El contenedor solicita 100 m de CPU y 200 Mi de memoria, y se autolimita a 200 Mi totales de uso de memoria.

A modo de resumen, la especificación del pod contiene las siguientes instrucciones:

  • Etiquetar el pod como fluentd
  • Usar el selector de etiquetas de nodo type: prod a fin de programar el pod en los nodos correspondientes y no programarlo en nodos que no tengan el selector de etiquetas. (Otra opción es omitir el campo nodeSelector para programar en todos los nodos)
  • Ejecutar fluentd-elasticsearch en la versión 1.20
  • Solicitar algo de memoria y recursos de CPU

Para obtener más información sobre las opciones de configuración del DaemonSet, consulta la referencia de la API de DaemonSet.

Actualiza los DaemonSets

Puedes actualizar un DaemonSet si cambias su especificación de pod, sus límites y solicitudes de recursos, sus etiquetas y sus anotaciones.

Para decidir cómo manejar las actualizaciones, DaemonSet usa una estrategia de actualización definida en spec: updateStrategy. Hay dos estrategias, OnDelete y RollingUpdate:

  • OnDelete no borra y vuelve a crear los pods del DaemonSet de forma automática cuando cambia la configuración del objeto. En cambio, los pods deben borrarse de forma manual para que el controlador cree nuevos pods que reflejen tus cambios.
  • RollingUpdate borra y vuelve a crear los pods de DaemonSet de forma automática. Con esta estrategia, los cambios válidos activan un lanzamiento de forma automática. Esta es la estrategia de actualización predeterminada para los DaemonSets.

Puedes supervisar los lanzamientos de actualizaciones si ejecutas el siguiente comando:

kubectl rollout status ds daemonset-name

Para obtener más información sobre cómo actualizar los DaemonSets, consulta Realiza una actualización progresiva en un DaemonSet, en la documentación de Kubernetes.

Próximos pasos