Mejores prácticas

• 1: Consideraciones para clústeres grandes
• 2: Validar la configuración del nodo
• 3: Aplicar los estándares de seguridad de Pods

1 - Consideraciones para clústeres grandes

Un clúster es un conjunto de nodos (máquinas físicas o virtuales) que ejecutan agentes de Kubernetes y que administra el plano de control. Kubernetes v1.37 admite clústeres de hasta 5.000 nodos. Más específicamente, Kubernetes está diseñado para admitir configuraciones que cumplan todos los siguientes criterios:

• No más de 110 pods por nodo
• No más de 5.000 nodos
• No más de 150.000 pods en total
• No más de 300.000 contenedores en total

Puedes escalar tu clúster agregando o eliminando nodos. La forma de hacerlo depende de cómo se haya desplegado tu clúster.

Cuotas de recursos del proveedor de la nube

Para evitar problemas con las cuotas del proveedor de la nube, al crear un clúster con muchos nodos, considera lo siguiente:

• Solicitar un aumento de cuota para recursos de la nube como:
  • Instancias de cómputo
  • CPU
  • Volúmenes de almacenamiento
  • Direcciones IP en uso
  • Conjuntos de reglas de filtrado de paquetes
  • Número de balanceadores de carga
  • Subredes de red
  • Flujos de registros
• Controlar las acciones de escalado del clúster para iniciar nodos nuevos en lotes, con una pausa entre lotes, porque algunos proveedores de la nube limitan la velocidad de creación de instancias nuevas.

Componentes del plano de control

Para un clúster grande, necesitas un plano de control con suficiente capacidad de cómputo y otros recursos.

Normalmente ejecutarías una o dos instancias del plano de control por zona de fallo, escalando primero esas instancias verticalmente y después horizontalmente cuando alcancen el punto de rendimientos decrecientes del escalado vertical.

Debes ejecutar al menos una instancia por zona de fallo para proporcionar tolerancia a fallos. Los nodos de Kubernetes no dirigen automáticamente el tráfico hacia los endpoints del plano de control que están en la misma zona de fallo; sin embargo, tu proveedor de la nube puede tener sus propios mecanismos para hacerlo.

Por ejemplo, usando un balanceador de carga administrado, configuras el balanceador para que envíe el tráfico que se origina en el kubelet y los Pods de la zona de fallo A únicamente a los hosts del plano de control que también están en la zona A. Si un solo host o endpoint del plano de control en la zona de fallo A se desconecta, eso significa que todo el tráfico del plano de control para los nodos de la zona A es ahora enviado entre zonas. Ejecutar varios hosts del plano de control en cada zona hace que este resultado sea menos probable.

Almacenamiento de etcd

Para mejorar el rendimiento de los clústeres grandes, puedes almacenar los objetos Event en una instancia de etcd separada y dedicada.

Al crear un clúster, puedes (usando herramientas personalizadas):

• iniciar y configurar una instancia adicional de etcd
• configurar el servidor de API para que la use para almacenar eventos

Consulta Operar clústeres de etcd para Kubernetes y Configurar un clúster de etcd de alta disponibilidad con kubeadm para obtener detalles sobre cómo configurar y administrar etcd para un clúster grande.

Recursos de los addons

Los límites de recursos de Kubernetes ayudan a minimizar el impacto de las fugas de memoria y otras situaciones en las que los pods y contenedores pueden afectar a otros componentes. Estos límites de recursos se aplican a los recursos de los addons del mismo modo que a las cargas de trabajo de las aplicaciones.

Por ejemplo, puedes establecer límites de CPU y memoria para un componente de registro:

  ...
  containers:
  - name: fluentd-cloud-logging
    image: fluent/fluentd-kubernetes-daemonset:v1
    resources:
      limits:
        cpu: 100m
        memory: 200Mi

Los límites predeterminados de los addons normalmente se basan en datos recopilados a partir de la experiencia al ejecutar cada addon en clústeres de Kubernetes pequeños o medianos. Al ejecutar addons en clústeres grandes, a menudo consumen más recursos que los límites predeterminados. Si se despliega un clúster grande sin ajustar estos valores, el addon puede morir continuamente porque alcanza repetidamente el límite de memoria. Como alternativa, el addon puede ejecutarse, pero con un rendimiento bajo debido a las restricciones de la fracción de tiempo de CPU.

Para evitar problemas con los recursos de los addons del clúster, al crear un clúster con muchos nodos, considera lo siguiente:

• Algunos addons escalan verticalmente: hay una réplica del addon para el clúster o para toda una zona de fallo. Para estos addons, aumenta las solicitudes y los límites a medida que escalas tu clúster.
• Muchos addons escalan horizontalmente: agregas capacidad ejecutando más pods; pero con un clúster muy grande también puede ser necesario aumentar ligeramente los límites de CPU o memoria. El Vertical Pod Autoscaler puede ejecutarse en modo recommender para proporcionar valores sugeridos para las solicitudes y los límites.
• Algunos addons se ejecutan como una copia por nodo, controlados por un DaemonSet: por ejemplo, un agregador de registros a nivel de nodo. Al igual que en el caso de los addons escalados horizontalmente, también puede ser necesario aumentar ligeramente los límites de CPU o memoria.

Priorizar los componentes esenciales del clúster

Para garantizar que los componentes esenciales del clúster (como CoreDNS, metrics-server y otros addons críticos) se programen antes que otras cargas de trabajo y no sean desalojados por pods de menor prioridad, ejecútalos con una PriorityClass del sistema, como system-cluster-critical o system-node-critical.

¿Qué sigue?

• VerticalPodAutoscaler es un recurso personalizado que puedes desplegar en tu clúster para ayudarte a administrar las solicitudes y los límites de recursos de los pods. Aprende más sobre Vertical Pod Autoscaler y cómo puedes usarlo para escalar los componentes del clúster, incluidos los addons esenciales para el clúster.

• Lee sobre el escalado automático de nodos

• El addon resizer te ayuda a cambiar automáticamente el tamaño de los addons a medida que cambia la escala de tu clúster.

2 - Validar la configuración del nodo

Prueba de conformidad del nodo

La Prueba de conformidad del nodo es un framework de pruebas contenedorizadas que proporcionan un sistema de verificación y pruebas de funcionalidad para un nodo. La prueba valida que el nodo cumpla con los requerimientos mínimos de Kubernetes; un nodo que pase la prueba está cualificado para unirse a un clúster de Kubernetes.

Prerrequisitos del nodo

Para ejecutar una prueba de conformidad del nodo, el nodo debe satisfacer los mismos prerrequisitos que el nodo de Kubernetes estándar. Mínimo, el nodo debería tener los siguientes daemons instalados:

• Runtimes de contenedores compatibles con CRI como Docker, containerd y CRI-O
• kubelet

Ejecutar la prueba de conformidad del nodo

Para ejecutar la prueba de conformidad del nodo, realiza los siguientes pasos:

1. Establece el valor de la opción --kubeconfig para el kubelet; por ejemplo: --kubeconfig=/var/lib/kubelet/config.yaml. Dado que el framework de pruebas inicia un plano de control local para probar el kubelet, utiliza http://localhost:8080 como la URL del servidor API. Hay otros parámetros de la línea de comandos de kubelet que quisieras utilizar:

   • --cloud-provider: Si estás utilizando --cloud-provider=gce, deberías quitar el flag para ejecutar la prueba.

2. Ejecuta la prueba de conformidad de nodo con el comando:

   # $CONFIG_DIR es la ruta del manifiesto del pod de tu kubelet.
   # $LOG_DIR es la ruta de salida de la prueba.
   sudo docker run -it --rm --privileged --net=host \
     -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
     registry.k8s.io/node-test:0.2
   

Ejecutar la prueba de conformidad del nodo para otras arquitecturas

Kubernetes también proporciona imágenes de docker para la prueba de conformidad del nodo para otras arquitecturas:

Ejecutar pruebas seleccionadas

Para ejecutar pruebas específicas, sobreescribe la variable de entorno FOCUS con la expresión regular de las pruebas que quieres ejecutar.

sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  -e FOCUS=MirrorPod \ # Solo ejecuta la prueba MirrorPod
  registry.k8s.io/node-test:0.2

Para saltar pruebas específicas, sobreescribe la variable de entorno SKIP con la expresión regular de las pruebas que quieres saltar.

sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  -e SKIP=MirrorPod \ # Ejecuta todas las pruebas de conformidad pero omite la prueba MirrorPod
  registry.k8s.io/node-test:0.2

La prueba de conformidad del nodo es una versión contenedorizada de la prueba e2e del nodo. Por predeterminado, ejecuta todas las pruebas de conformidad.

Teóricamente, puedes ejecutar cualquier prueba e2e del nodo si configuras el contenedor y montas los volúmenes requeridos apropiadamente. Pero se recomienda fuertemente solo ejecutar las pruebas de conformidad, porque requieren configuraciones mucho más complejas que ejecutar pruebas de no conformidad.

Advertencias

• Las pruebas dejan algunas imágenes de docker en el nodo, incluyendo la imagen de la prueba de conformidad del nodo e imágenes de contenedores utilizados en la prueba de funcionalidad.
• Las pruebas dejan contenedores inactivos en el nodo. Estos contenedores son creados durante la prueba de funcionalidad.

3 - Aplicar los estándares de seguridad de Pods

Esta página proporciona un resumen de las mejores prácticas para aplicar los estándares de seguridad de Pods.

Utilizar el controlador de admisión de seguridad de Pods nativo

El controlador de admisión de seguridad de Pods pretende reemplazar a las obsoletas PodSecurityPolicies.

Configurar todos los namespaces del clúster

Los namespaces que carecen de cualquier configuración deberían ser considerados una brecha significativa en el modelo de seguridad de tu clúster. Recomendamos tomar tiempo para analizar los tipos de cargas de trabajo que se ejecutan en cada namespace y, tomando como referencia los estándares de seguridad de Pods, decidir un nivel apropiado para cada una de ellas. Los namespaces sin etiquetas solo deberían indicar que todavía deben ser evaluados.

En el escenario en que todas las cargas de trabajo en todos los namespaces tienen los mismos requerimientos de seguridad, proporcionamos un ejemplo que ilustra cómo las etiquetas de PodSecurity pueden ser utilizadas de forma masiva.

Adoptar el principio de mínimo privilegio

En un mundo ideal, cada pod en cada namespace cumpliría los requerimientos de la política restricted. Sin embargo, esto no es posible ni práctico debido a que algunas cargas de trabajo requerirán privilegios elevados por razones legítimas.

• Los namespaces que permiten cargas de trabajo privileged deberían establecer y aplicar controles de acceso apropiados.
• Para cargas de trabajo que se ejecutan en aquellos namespaces permisivos, mantén documentación sobre sus requerimientos únicos de seguridad. Si es posible, considera cómo se podrían limitar aún más esos requerimientos.

Adoptar una estrategia multimodo

Los modos audit y warn del controlador de admisión de estándares de seguridad de Pods facilitan recopilar información de seguridad importante de tus pods sin romper tus cargas de trabajo existentes.

Es una buena práctica habilitar estos modos para todos los namespaces, configurando el nivel deseado y la versión que te gustaría eventualmente enforce. Las advertencias y anotaciones de auditoría generadas en esta fase pueden guiarte hacia ese estado. Si esperas que los autores de las cargas de trabajo hagan cambios para ajustarse al nivel deseado, habilita el modo warn. Si esperas utilizar los registros de auditoría para monitorear o gestionar cambios para ajustarse al nivel deseado, habilita el modo audit.

Cuando tienes configurado el modo enforce en tu valor deseado, estos modos todavía pueden ser útiles de diferentes maneras:

• Al establecer warn en el mismo nivel que enforce, los clientes recibirán advertencias cuando intenten crear Pods (o recursos que tienen plantillas de Pod) que no superen la validación. Esto les ayudará a actualizar aquellos recursos para que cumplan con la normativa.
• En los namespaces que fijan enforce a una versión específica que no sea la más reciente, configurar los modos audit y warn al mismo nivel que enforce, pero en la versión latest, proporciona visibilidad sobre las configuraciones que estaban permitidas en versiones anteriores pero que ya no se permiten según las mejores prácticas actuales.

Alternativas de terceros

Otras alternativas para aplicar perfiles de seguridad están siendo desarrolladas en el ecosistema de Kubernetes:

• Kubewarden.
• Kyverno.
• OPA Gatekeeper.

La decisión de optar por una solución nativa (ej. el controlador de admisión PodSecurity) en vez de una herramienta de terceros depende completamente de tu propia situación. Cuando evalúes cualquier solución, confiar en tu cadena de suministro es crucial. Finalmente, utilizar cualquiera de los enfoques mencionados anteriormente será mejor que no hacer nada.