Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Plano de datos de Kubernetes

La selección de los tipos de instancias EC2 es posiblemente una de las decisiones más difíciles a las que se enfrentan los clientes, ya que se trata de clústeres con múltiples cargas de trabajo. No existe una solución única para todos los casos. Estos son algunos consejos que le ayudarán a evitar los errores más comunes relacionados con el escalado de la computación.

Escalado automático de nodos

Te recomendamos que utilices el escalado automático de nodos, ya que reduce el esfuerzo y se integra perfectamente con Kubernetes. Los grupos de nodos gestionados y Karpenter se recomiendan para clústeres de gran escala.

Los grupos de nodos administrados le brindarán la flexibilidad de los grupos de Auto Scaling de Amazon EC2, con beneficios adicionales para las actualizaciones y la configuración administradas. Se puede escalar con el escalador automático de clústeres de Kubernetes y es una opción común para los clústeres que tienen diversas necesidades informáticas.

Karpenter es un escalador automático de nodos de código abierto y nativo de cargas de trabajo creado por AWS. Escala los nodos de un clúster en función de los requisitos de carga de trabajo en cuanto a los recursos (p. ej., la GPU) y de las limitaciones y tolerancias (p. ej., la dispersión de zonas) sin gestionar grupos de nodos. Los nodos se crean directamente desde EC2, lo que evita las cuotas de grupos de nodos predeterminadas (450 nodos por grupo) y proporciona una mayor flexibilidad en la selección de instancias con menos gastos operativos. Recomendamos a los clientes que usen Karpenter siempre que sea posible.

Utilice muchos tipos de instancias EC2 diferentes

Cada región de AWS tiene un número limitado de instancias disponibles por tipo de instancia. Si crea un clúster que usa solo un tipo de instancia y escala el número de nodos más allá de la capacidad de la región, recibirá un error que le indicará que no hay ninguna instancia disponible. Para evitar este problema, no debes limitar arbitrariamente el tipo de instancias que se pueden usar en tu clúster.

Karpenter utilizará un amplio conjunto de tipos de instancias compatibles de forma predeterminada y elegirá una instancia en el momento del aprovisionamiento en función de los requisitos de carga de trabajo pendientes, la disponibilidad y el costo. Puede ampliar la lista de tipos de instancias utilizados en la clave de. karpenter.k8s.aws/instance-category NodePools

El escalador automático de clústeres de Kubernetes requiere que los grupos de nodos tengan un tamaño similar para poder escalarlos de manera uniforme. Debes crear varios grupos en función del tamaño de la CPU y la memoria y escalarlos de forma independiente. Usa el ec2-instance-selector para identificar las instancias que tienen un tamaño similar para tus grupos de nodos.

ec2-instance-selector --service eks --vcpus-min 8 --memory-min 16
a1.2xlarge
a1.4xlarge
a1.metal
c4.4xlarge
c4.8xlarge
c5.12xlarge
c5.18xlarge
c5.24xlarge
c5.2xlarge
c5.4xlarge
c5.9xlarge
c5.metal

Prefiere nodos más grandes para reducir la carga del servidor de API

A la hora de decidir qué tipos de instancias usar, un menor número de nodos grandes supondrá menos carga en el plano de control de Kubernetes, ya que habrá menos kubelets en ejecución. DaemonSets Sin embargo, es posible que los nodos grandes no se utilicen por completo como los nodos más pequeños. Los tamaños de los nodos deben evaluarse en función de los requisitos de escalabilidad y disponibilidad de la carga de trabajo.

Un clúster con tres instancias U-24tb1.metal (24 TB de memoria y 448 núcleos) tiene 3 kubelets y estaría limitado a 110 pods por nodo de forma predeterminada. Si los pods utilizan 4 núcleos cada uno, es lo normal (4 núcleos x 110 = 440). cores/node Con un clúster de 3 nodos, tu capacidad para gestionar un incidente de instancia sería baja, ya que la interrupción 1/3 de una instancia podría afectar al clúster. Debes especificar los requisitos de los nodos y la distribución de los pods en tus cargas de trabajo para que el programador de Kubernetes pueda colocar las cargas de trabajo correctamente.

Las cargas de trabajo deben definir los recursos que necesitan y la disponibilidad requerida mediante restricciones, tolerancias y. PodTopologySpread Deberían preferir los nodos más grandes que puedan utilizarse al máximo y cumplir los objetivos de disponibilidad para reducir la carga del plano de control, reducir las operaciones y reducir los costos.

El programador de Kubernetes intentará distribuir automáticamente las cargas de trabajo entre las zonas de disponibilidad y los hosts si hay recursos disponibles. Si no hay capacidad disponible, el escalador automático de clústeres de Kubernetes intentará agregar nodos en cada zona de disponibilidad de manera uniforme. Karpenter intentará agregar nodos de la manera más rápida y económica posible, a menos que la carga de trabajo especifique otros requisitos.

Para forzar que las cargas de trabajo se distribuyan con el planificador y que se creen nuevos nodos en todas las zonas de disponibilidad, debe utilizar la topología: SpreadConstraints

spec:
  topologySpreadConstraints:
    - maxSkew: 3
      topologyKey: "topology.kubernetes.io/zone"
      whenUnsatisfiable: ScheduleAnyway
      labelSelector:
        matchLabels:
          dev: my-deployment
    - maxSkew: 2
      topologyKey: "kubernetes.io/hostname"
      whenUnsatisfiable: ScheduleAnyway
      labelSelector:
        matchLabels:
          dev: my-deployment

Utilice tamaños de nodo similares para lograr un rendimiento uniforme de las cargas de trabajo

Las cargas de trabajo deben definir el tamaño de los nodos en los que deben ejecutarse para permitir un rendimiento uniforme y un escalado predecible. Una carga de trabajo que solicite 500 millones de CPU tendrá un rendimiento diferente en una instancia con 4 núcleos y en una con 16 núcleos. Evita los tipos de instancia que utilizan CPU con ráfagas, como las instancias de la serie T.

Para garantizar que tus cargas de trabajo obtengan un rendimiento uniforme, una carga de trabajo puede usar las etiquetas Karpenter compatibles para adaptarse a tamaños de instancia específicos.

kind: deployment
...
spec:
  template:
    spec:
    containers:
    nodeSelector:
      karpenter.k8s.aws/instance-size: 8xlarge

Las cargas de trabajo que se programan en un clúster con el escalador automático de clústeres de Kubernetes deben hacer coincidir un selector de nodos con los grupos de nodos en función de la coincidencia de etiquetas.

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/nodegroup
            operator: In
            values:
            - 8-core-node-group    # match your node group name

Usa los recursos informáticos de manera eficiente

Los recursos informáticos incluyen instancias EC2 y zonas de disponibilidad. El uso eficaz de los recursos informáticos aumentará la escalabilidad, la disponibilidad y el rendimiento y reducirá el costo total. El uso eficiente de los recursos es extremadamente difícil de predecir en un entorno de escalado automático con múltiples aplicaciones. Karpenter se creó para aprovisionar instancias bajo demanda en función de las necesidades de carga de trabajo a fin de maximizar la utilización y la flexibilidad.

Karpenter permite que las cargas de trabajo declaren el tipo de recursos informáticos que necesitan sin crear primero grupos de nodos ni configurar etiquetas contaminadas para nodos específicos. Consulte las mejores prácticas de Karpenter para obtener más información. Considere habilitar la consolidación en su aprovisionador Karpenter para reemplazar los nodos que están infrautilizados.

Automatice las actualizaciones de Amazon Machine Image (AMI)

Si mantienes actualizados los componentes de los nodos de trabajo, te asegurarás de que dispones de los parches de seguridad más recientes y de las funciones compatibles con la API de Kubernetes. La actualización del kubelet es el componente más importante para la funcionalidad de Kubernetes, pero la automatización de los parches del sistema operativo, el kernel y las aplicaciones instaladas localmente reducirá el mantenimiento a medida que escales.

Se recomienda utilizar la última AMI de Amazon Linux 2 optimizada para Amazon EKS o Bottlerocket optimizada para Amazon EKS para la imagen de nodo. Karpenter utilizará automáticamente la AMI más reciente disponible para aprovisionar nuevos nodos en el clúster. Los grupos de nodos administrados actualizarán la AMI durante la actualización de un grupo de nodos, pero no actualizarán el ID de la AMI en el momento del aprovisionamiento de los nodos.

En el caso de los grupos de nodos gestionados, debes actualizar la plantilla de lanzamiento del grupo de Auto Scaling (ASG) con nuevos ID de AMI cuando estén disponibles para la publicación de los parches. Las versiones secundarias de la AMI (por ejemplo, la 1.23.5 a la 1.24.3) estarán disponibles en la consola y la API de EKS como actualizaciones para el grupo de nodos. Las versiones de lanzamiento de parches (por ejemplo, la 1.23.5 a la 1.23.6) no se presentarán como actualizaciones para los grupos de nodos. Si quieres mantener tu grupo de nodos actualizado con las versiones de los parches de la AMI, debes crear una nueva versión de la plantilla de lanzamiento y dejar que el grupo de nodos sustituya las instancias por la nueva versión de la AMI.

Puedes encontrar la AMI más reciente disponible en esta página o usar la CLI de AWS.

aws ssm get-parameter \
  --name /aws/service/eks/optimized-ami/1.24/amazon-linux-2/recommended/image_id \
  --query "Parameter.Value" \
  --output text

Utilice varios volúmenes de EBS para contenedores

Los volúmenes de EBS tienen una cuota input/output (I/O) basada en el tipo de volumen (por ejemplo, gp3) y el tamaño del disco. Si sus aplicaciones comparten un único volumen raíz de EBS con el host, esto puede agotar la cuota de disco de todo el host y provocar que otras aplicaciones esperen hasta agotar la capacidad disponible. Las aplicaciones escriben en el disco si escriben archivos en su partición superpuesta, montan un volumen local desde el host y también cuando inician sesión en modo estándar (STDOUT), según el agente de registro utilizado.

Para evitar que se I/O agote el disco, debe montar un segundo volumen en la carpeta de estado del contenedor (por ejemplo,/run/containerd), usar volúmenes de EBS independientes para almacenar la carga de trabajo y deshabilitar el registro local innecesario.

Para montar un segundo volumen en tus instancias EC2 mediante eksctl, puedes usar un grupo de nodos con esta configuración:

managedNodeGroups:
  - name: al2-workers
    amiFamily: AmazonLinux2
    desiredCapacity: 2
    volumeSize: 80
    additionalVolumes:
      - volumeName: '/dev/sdz'
        volumeSize: 100
    preBootstrapCommands:
    - |
      "systemctl stop containerd"
      "mkfs -t ext4 /dev/nvme1n1"
      "rm -rf /var/lib/containerd/*"
      "mount /dev/nvme1n1 /var/lib/containerd/"
      "systemctl start containerd"

Si utilizas terraform para aprovisionar tus grupos de nodos, consulta algunos ejemplos en EKS Blueprints for terraform. Si utilizas Karpenter para aprovisionar nodos, puedes usarlos blockDeviceMappings con los datos de usuario de los nodos para agregar volúmenes adicionales.

Para montar un volumen de EBS directamente en su pod, debe usar el controlador CSI de AWS EBS y consumir un volumen con una clase de almacenamiento.

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-sc
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ebs-sc
  resources:
    requests:
      storage: 4Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
  - name: app
    image: public.ecr.aws/docker/library/nginx
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: ebs-claim

Evite las instancias con límites de conexión de EBS bajos si las cargas de trabajo utilizan volúmenes de EBS

EBS es una de las maneras más sencillas de que las cargas de trabajo tengan un almacenamiento persistente, pero también tiene limitaciones de escalabilidad. Cada tipo de instancia tiene un número máximo de volúmenes de EBS que se pueden adjuntar. Las cargas de trabajo deben declarar los tipos de instancias en los que deben ejecutarse y limitar el número de réplicas en una sola instancia que esté contaminada con Kubernetes.

Inhabilita el registro innecesario en el disco

Evite el registro local innecesario al no ejecutar sus aplicaciones con el registro de depuración en producción y al deshabilitar el registro que lee y escribe en el disco con frecuencia. Journald es el servicio de registro local que mantiene un búfer de registros en la memoria y lo descarga en el disco periódicamente. Se prefiere Journald a syslog, que registra todas las líneas inmediatamente en el disco. La desactivación de syslog también reduce la cantidad total de almacenamiento que necesita y evita la necesidad de complicadas reglas de rotación de registros. Para deshabilitar syslog, puede agregar el siguiente fragmento a su configuración de cloud-init:

runcmd:
  - [ systemctl, disable, --now, syslog.service ]

Se aplican parches a las instancias en las que la velocidad de actualización del sistema operativo es necesaria

La instalación de un paquete en un host Linux existente lleva unos segundos sin interrumpir las cargas de trabajo en contenedores. El paquete se puede instalar y validar sin acordonar, agotar ni reemplazar la instancia.

Para reemplazar una instancia, primero debe crear, validar y distribuir nuevas AMI. Es necesario crear una instancia de reemplazo y acordonar y vaciar la instancia anterior. A continuación, es necesario crear las cargas de trabajo en la nueva instancia, verificarlas y repetirlas en todas las instancias que se deban parchear. Reemplazar las instancias de forma segura y sin interrumpir las cargas de trabajo lleva horas, días o semanas.

Amazon recomienda utilizar una infraestructura inmutable creada, probada y promovida a partir de un sistema declarativo y automatizado, pero si necesita aplicar parches a los sistemas rápidamente, tendrá que aplicar parches a los sistemas instalados y sustituirlos a medida que haya nuevas AMI disponibles. Debido a la gran diferencia de tiempo entre la aplicación de parches y la sustitución de los sistemas, recomendamos utilizar AWS Systems Manager Patch Manager para automatizar la instalación de parches en los nodos cuando sea necesario.

Los nodos de aplicación de parches le permitirán implementar rápidamente las actualizaciones de seguridad y reemplazar las instancias de forma regular una vez que se haya actualizado la AMI. Si utiliza un sistema operativo con un sistema de archivos raíz de solo lectura, como Flatcar Container Linux o Bottlerocket OS, le recomendamos que utilice los operadores de actualización que funcionan con esos sistemas operativos. El operador de actualizaciones de Flatcar Linux y el operador de actualizaciones de Bottlerocket reiniciarán las instancias para mantener los nodos actualizados automáticamente.