View a markdown version of this page

Plano de datos de EKS - Amazon EKS
Recomendaciones

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 EKS

Para operar aplicaciones resilientes y de alta disponibilidad, necesita un plano de datos resiliente y de alta disponibilidad. Un plano de datos elástico garantiza que Kubernetes pueda escalar y reparar sus aplicaciones automáticamente. Un plano de datos resiliente está formado por dos o más nodos de trabajo, puede crecer y reducirse con la carga de trabajo y recuperarse automáticamente de las fallas.

Tiene varias opciones para los nodos de trabajo con EKS: los nodos administrados en modo automático de EKS, las instancias EC2 y https://docs.aws.amazon.com/eks/latest/userguide/fargate.html Fargate.

El modo automático de EKS ofrece la ruta más sencilla hacia un plano de datos resiliente. El modo automático amplía la administración de AWS de los clústeres de Kubernetes más allá del propio clúster, para que AWS también pueda configurar y administrar la infraestructura que permite el buen funcionamiento de sus cargas de trabajo. El modo automático escala automáticamente el plano de datos hacia arriba o hacia abajo a medida que Kubernetes escala los pods, y trabaja continuamente para garantizar que los nodos del clúster tengan el tamaño adecuado y rentable para las cargas de trabajo que se están ejecutando actualmente.

Si eliges las instancias EC2, puedes administrar los nodos de trabajo tú mismo o usar los grupos de nodos administrados por EKS. https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html Puede tener un clúster con una combinación de nodos de trabajo en modo automático, nodos de trabajo gestionados y autogestionados y Fargate.

Fargate ejecuta cada pod en un entorno informático aislado. Cada pod que se ejecuta en Fargate tiene su propio nodo de trabajo. Fargate escala automáticamente el plano de datos a medida que Kubernetes escala los pods. Puedes escalar tanto el plano de datos como la carga de trabajo mediante el escalador automático de módulos horizontales. https://docs.aws.amazon.com/eks/latest/userguide/horizontal-pod-autoscaler.html

La forma preferida de escalar los nodos de trabajo de EC2 (si no se utiliza EKS Auto Mode, donde AWS lo realiza automáticamente) es mediante los grupos Karpenter, Kubernetes Cluster Autoscaler o EC2 Auto Scaling. https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html

Recomendaciones

Distribuya los nodos de trabajo y las cargas de trabajo en varias zonas de disponibilidad

Puede proteger sus cargas de trabajo de los errores en una zona de disponibilidad individual ejecutando nodos de trabajo y pods en varias zonas de disponibilidad. Puedes controlar la zona de disponibilidad en la que se crean los nodos de trabajo mediante las subredes en las que creas los nodos.

El método recomendado para distribuir los pods entre las zonas de disponibilidad es utilizar las restricciones de dispersión de topología para los pods. Auto-scaling funcionalidades como EKS Auto Mode y Karpenter son conscientes de las restricciones de dispersión de la topología y lanzan automáticamente los nodos en las zonas de disponibilidad correctas para cumplir con las restricciones.

La siguiente implementación distribuye los pods entre las zonas de disponibilidad, si es posible, y permite que esos pods se ejecuten de todos modos si no es así:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          whenUnsatisfiable: ScheduleAnyway
          topologyKey: topology.kubernetes.io/zone
          labelSelector:
            matchLabels:
              app: web-server
      containers:
      - name: web-app
        image: nginx
        resources:
          requests:
            cpu: 1
nota

kube-schedulersolo conoce los dominios de topología a través de los nodos que existen con esas etiquetas. Si la implementación anterior se implementa en un clúster con nodos solo en una zona, todos los pods se programarán en esos nodos, ya que kube-scheduler no conoce las demás zonas. Para que esta distribución de topología funcione según lo previsto con el planificador, los nodos ya deben existir en todas las zonas. La minDomains propiedad de las restricciones de dispersión de topología se utiliza para informar al programador del número de dominios aptos, incluso si hay un nodo ejecutándose allí, para evitar este problema.

aviso

Si DoNotSchedule se establece whenUnsatisfiable en, los pods no se podrán programar si no se puede cumplir la restricción de dispersión de la topología. Solo debe configurarse si es preferible que los pods no se ejecuten en lugar de infringir la restricción de dispersión de la topología.

En las versiones anteriores de Kubernetes, puedes usar las reglas de antiafinidad de los pods para programar los pods en varias zonas de disponibilidad. En el siguiente manifiesto se indica al programador de Kubernetes que prefiere programar los pods en distintas zonas de disponibilidad. 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
  labels:
    app: web-server
spec:
  replicas: 4
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - web-server
              topologyKey: failure-domain.beta.kubernetes.io/zone
            weight: 100
      containers:
      - name: web-app
        image: nginx
aviso

No exija que los pods se programen en distintas zonas de disponibilidad; de lo contrario, la cantidad de pods de una implementación nunca superará la cantidad de zonas de disponibilidad.

Garantice la capacidad de lanzar nodos en cada zona de disponibilidad cuando utilice volúmenes de EBS

Si usa Amazon EBS para proporcionar volúmenes persistentes, debe asegurarse de que los pods y el volumen de EBS asociado estén ubicados en la misma zona de disponibilidad. Un pod no puede acceder a los volúmenes EBS-backed persistentes ubicados en una AZ diferente. El programador de Kubernetes sabe en qué zona de disponibilidad se encuentra un nodo de trabajo a partir de las etiquetas que hay en el nodo y siempre programará un pod que requiera un volumen de EBS en la misma zona de disponibilidad que el volumen. Sin embargo, si no hay nodos de trabajo disponibles en la zona de disponibilidad en la que se encuentra el volumen, el pod no se puede programar.

Si utilizas EKS Auto Mode o Karpenter, tendrás que asegurarte de seleccionar las subredes en NodeClass cada zona de disponibilidad. Si utiliza grupos de nodos administrados, debe asegurarse de tener un grupo de nodos en cada zona de disponibilidad.

El modo automático de EKS incorpora una capacidad de almacenamiento de EBS, pero si utiliza Karpenter o grupos de nodos gestionados, también será necesario instalar el CSI de EBS.

Utilice el modo automático de EKS para administrar los nodos de trabajo

El modo automático de EKS optimiza la administración de EKS al proporcionar clústeres listos para la producción con una sobrecarga operativa mínima. El modo automático se encarga de aumentar o reducir la cantidad de nodos en función de los pods que se estén ejecutando en el clúster. Los nodos se mantienen actualizados automáticamente con parches y correcciones de software, y las actualizaciones se realizan de acuerdo con los ajustes de NodePool interrupción configurados y los presupuestos de interrupción de los pods.

Ejecute el agente de monitoreo de nodos

El agente de monitorización de nodos supervisa los problemas de estado de los nodos y reacciona ante ellos publicando los eventos de Kubernetes y actualizando el estado de los nodos. El agente de monitoreo de nodos se incluye en los nodos de modo automático de EKS y se puede instalar como un complemento de EKS para los nodos que no se administran mediante el modo automático.

EKS Auto Mode, Managed Node Groups y Karpenter tienen la capacidad de detectar las condiciones fatales de los nodos notificadas por el agente de monitoreo de nodos y reparar esos nodos automáticamente cuando se producen esas condiciones.

Implemente la QoS

Para las aplicaciones críticas, considera definir requests = limits para el contenedor del pod. Esto garantizará que el contenedor no se cierre si otro pod solicita recursos.

Se recomienda implementar límites de CPU y memoria en todos los contenedores, ya que así se evita que un contenedor consuma recursos del sistema de forma inadvertida y afecte a la disponibilidad de otros procesos ubicados en el mismo lugar.

Configure y dimensione los recursos para todas las cargas de trabajo Requests/Limits

Se pueden aplicar algunas directrices generales para dimensionar las solicitudes de recursos y los límites de las cargas de trabajo:

  • No especifiques los límites de recursos de la CPU. En ausencia de límites, la solicitud actúa como una ponderación del tiempo relativo de CPU que dedican los contenedores. Esto permite que las cargas de trabajo utilicen toda la CPU sin límites artificiales ni falta de recursos.

  • Para los recursos que no son de CPU, configuration requests = limits proporciona el comportamiento más predecible. ¡Si! requests =limits, la QOS del contenedor también se reduce de garantizada a explotable, por lo que es más probable que se desaloje en caso de presión en los nodos.

  • En el caso de los recursos que no son de CPU, no especifique un límite que sea mucho mayor que la solicitud. Cuanto más grande limits esté configurado en relación conrequests, es más probable que los nodos se comprometan en exceso, lo que aumenta la probabilidad de que se interrumpa la carga de trabajo.

  • El tamaño correcto de las solicitudes es especialmente importante cuando se utiliza una solución de escalado automático de nodos, como https://aws.github.io/aws-eks-best-practices/karpenter/ Karpenter o Cluster. AutoScaler Estas herramientas analizan las solicitudes de carga de trabajo para determinar la cantidad y el tamaño de los nodos que se van a aprovisionar. Si tus solicitudes son demasiado pequeñas y los límites son más altos, es posible que tus cargas de trabajo se desalojen o se cancele el OOM si están empaquetadas de forma compacta en un nodo.

Determinar las solicitudes de recursos puede resultar difícil, pero herramientas como el escalador automático de módulos verticales pueden ayudarte a «ajustar el tamaño» de las solicitudes al observar el uso de los recursos del contenedor durante el tiempo de ejecución. Otras herramientas que pueden resultar útiles para determinar el tamaño de las solicitudes son:

Configure las cuotas de recursos para los espacios de nombres

Los espacios de nombres se utilizan en entornos con muchos usuarios distribuidos en varios equipos o proyectos. Proporcionan un ámbito para los nombres y son una forma de dividir los recursos del clúster entre varios equipos, proyectos y cargas de trabajo. Puedes limitar el consumo total de recursos en un espacio de nombres. El ResourceQuota objeto puede limitar la cantidad de objetos que se pueden crear en un espacio de nombres por tipo, así como la cantidad total de recursos informáticos que pueden consumir los recursos de ese proyecto. Puedes limitar la suma total de recursos and/or informáticos de almacenamiento (CPU y memoria) que se pueden solicitar en un espacio de nombres determinado.

Si la cuota de recursos está habilitada en un espacio de nombres para recursos informáticos como la CPU y la memoria, los usuarios deben especificar las solicitudes o los límites para cada contenedor de ese espacio de nombres.

Considera la posibilidad de configurar cuotas para cada espacio de nombres. Considere la posibilidad de LimitRanges utilizarlos para aplicar automáticamente los límites preconfigurados a los contenedores dentro de un espacio de nombres.

Limite el uso de los recursos del contenedor dentro de un espacio de nombres

Las cuotas de recursos ayudan a limitar la cantidad de recursos que puede usar un espacio de nombres. El LimitRange objeto puede ayudarlo a implementar los recursos mínimos y máximos que puede solicitar un contenedor. LimitRangeUsándolo puedes establecer una solicitud y límites predeterminados para los contenedores, lo que resulta útil si establecer límites de recursos informáticos no es una práctica estándar en tu organización. Como su nombre indica, LimitRange puedes imponer un uso mínimo y máximo de recursos informáticos por pod o contenedor en un espacio de nombres. Además, exige una solicitud de almacenamiento mínima y máxima por espacio PersistentVolumeClaim de nombres.

Considere la posibilidad LimitRange de usarlo junto con ResourceQuota para hacer cumplir los límites tanto a nivel de contenedor como de espacio de nombres. Establecer estos límites garantizará que un contenedor o un espacio de nombres no afecten a los recursos utilizados por otros inquilinos del clúster.

Utilice DNSCache NodeLocal

Puede mejorar el rendimiento del DNS del clúster ejecutando NodeLocal DNSCache. Esta función ejecuta un agente de almacenamiento en caché de DNS en los nodos del clúster como un. DaemonSet Todos los pods utilizan el agente de almacenamiento en caché de DNS que se ejecuta en el nodo para la resolución de nombres en lugar de utilizar kube-dns el servicio. Esta función se incluye automáticamente en el modo automático de EKS.

Configure el escalado automático de CoreDNS

Otro método para mejorar el rendimiento del DNS del clúster es habilitar el escalado automático integrado de los pods de CoreDNS.

Esta función monitorea continuamente el estado del clúster, incluida la cantidad de nodos y núcleos de CPU. En función de esa información, el controlador adaptará dinámicamente el número de réplicas de la implementación de CoreDNS en un clúster de Amazon EKS.