Plano de datos 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 consta de dos o más nodos de trabajo, puede crecer y reducirse con la carga de trabajo y recuperarse automáticamente de los fallos.

Con EKS, tiene varias opciones para los nodos de trabajo: nodos gestionados en modo automático de EKS, EC2 instancias y Fargate.

El modo automático de EKS ofrece la ruta más sencilla hacia un plano de datos resiliente. El modo automático extiende la administración de los clústeres de Kubernetes en AWS más allá del propio clúster, para permitir que AWS también configure y administre 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 garantiza continuamente 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 EC2 instancias, puedes gestionar los nodos de trabajo tú mismo o utilizar los grupos de nodos gestionados por EKS. Puede tener un clúster con una combinación de nodos de trabajo en modo automático, 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. Puede escalar tanto el plano de datos como su carga de trabajo mediante el escalador automático de cápsulas horizontales.

La forma preferida de escalar los EC2 nodos de trabajo (si no se utiliza el modo automático de EKS, donde AWS lo realiza automáticamente) es mediante grupos de Karpenter, Kubernetes Cluster Autoscaler o Auto Scaling. EC2

Recomendaciones

Distribuya los nodos de trabajo y las cargas de trabajo entre varios AZs

Puede proteger sus cargas de trabajo de los errores en una zona de disponibilidad individual ejecutando nodos de trabajo y pods en varios nodos. AZs Puede controlar la zona de disponibilidad en la que se crean los nodos de trabajo mediante las subredes en las que crea los nodos.

El método recomendado para distribuir los pods AZs es utilizar las restricciones de dispersión topológica para los pods. Las funciones de escalado automático, como el modo automático de EKS y Karpenter, conocen las restricciones de dispersión de la topología y lanzan automáticamente los nodos en la dirección correcta AZs para poder cumplir con las restricciones.

La siguiente implementación distribuye los módulos entre sí, AZs si es posible, y permite que esos módulos 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 módulos se programarán en esos nodos, al kube-scheduler igual que en las demás zonas. Para que esta distribución de topología funcione según lo previsto con el programador, los nodos deben existir ya en todas las zonas. La minDomains propiedad de las restricciones de dispersión de una topología se utiliza para informar al planificador del número de dominios aptos, incluso si hay un nodo funcionando allí para evitar este problema.

aviso

Si DoNotSchedule se establece whenUnsatisfiable en, los pods no se podrán programar si no se cumple 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 varios pods en varios. AZs En el siguiente manifiesto se indica al programador de Kubernetes que prefiera programar los pods por separado. AZs

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 es necesario que los pods se programen de AZs forma distinta; de lo contrario, la cantidad de pods en una implementación nunca superará la cantidad de. AZs

Asegúrese de poder lanzar nodos en cada zona de disponibilidad cuando utilice volúmenes de EBS

Si utilizas Amazon EBS para proporcionar volúmenes persistentes, debes asegurarte 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 persistentes respaldados por EBS ubicados en una zona de disponibilidad diferente. El programador de Kubernetes sabe en qué zona de disponibilidad se encuentra un nodo trabajador a partir de las etiquetas que aparecen en el nodo y siempre programa 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 donde se encuentra el volumen, no se puede programar el pod.

Si utiliza el modo automático EKS o Karpenter, tendrá que asegurarse de seleccionar las subredes en NodeClass cada zona de disponibilidad. Si utiliza grupos de nodos gestionados, debe asegurarse de tener un grupo de nodos en cada zona de disponibilidad.

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

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

El modo automático de EKS agiliza 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 el número de nodos en función de los pods que se ejecuten en el clúster. Los nodos se actualizan automáticamente con parches y correcciones de software, y las actualizaciones se realizan de acuerdo con los ajustes de NodePoolinterrupción configurados y los presupuestos de interrupción de los módulos.

Ejecute el agente de supervisión de nodos

El agente de supervisió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.

El modo automático de EKS, los grupos de nodos gestionados y Karpenter tienen la capacidad de detectar las condiciones fatales de los nodos notificadas por el agente de supervisión de nodos y reparar esos nodos automáticamente cuando se producen esas condiciones.

Implemente QoS

En el caso de las aplicaciones críticas, considere la posibilidad de definir requests = limits para el contenedor del pod. Esto garantizará que el contenedor no se destruya si otro pod solicita recursos.

Se recomienda implementar límites de CPU y memoria para 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 pautas generales para dimensionar las solicitudes de recursos y los límites de las cargas de trabajo:

• No especifique los límites de recursos de la CPU. Si no hay límites, la solicitud actúa como un indicador del tiempo relativo de CPU que ocupan los contenedores. Esto permite que sus cargas de trabajo utilicen toda la CPU sin límites artificiales ni privaciones de recursos.

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

• En el caso de los recursos que no sean de la CPU, no especifique un límite que sea mucho mayor que el solicitado. Cuanto mayor sea limits la configuración relativa arequests, mayor será la probabilidad de que los nodos estén sobrecargados, lo que aumentará las probabilidades de que se interrumpa la carga de trabajo.

• Las solicitudes del tamaño correcto son particularmente importantes cuando se utiliza una solución de autoescalado de nodos como 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 mayores, es posible que tus cargas de trabajo se desalojen o que la OOM se cancele si se encuentran agrupadas en un nodo.

Determinar las solicitudes de recursos puede resultar difícil, pero herramientas como el escalador automático Vertical Pod 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:

• Ricitos de oro

• Parca

• Prodfiler

• rsg

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 margen 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 ResourceQuotaobjeto puede limitar por tipo la cantidad de objetos que se pueden crear en un espacio de nombres, así como la cantidad total de recursos informáticos que pueden consumir los recursos de ese proyecto. Puede limitar la suma total de los 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 para un espacio de nombres para los 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.

Considere la posibilidad de configurar cuotas para cada espacio de nombres. Considere la posibilidad de LimitRanges aplicar automáticamente 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 LimitRangeobjeto puede ayudarte a implementar los recursos mínimos y máximos que un contenedor puede solicitar. Al usarlo, LimitRange puede 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 su organización. Como su nombre indica, LimitRange puede imponer un uso mínimo y máximo de los recursos de cómputo por pod o contenedor en un espacio de nombres. Además, impone una solicitud de almacenamiento mínima y máxima por cada espacio de PersistentVolumeClaim 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. Al establecer estos límites, se garantizará que un contenedor o un espacio de nombres no afecte a los recursos utilizados por otros inquilinos del clúster.

Utilice NodeLocal DNSCache

Puede mejorar el rendimiento del DNS del clúster ejecutando NodeLocalDNSCache. Esta función ejecuta un agente de almacenamiento en caché de DNS en los nodos del clúster como unDaemonSet. 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 EKS.

Configurar CoredNS con autoescalado

Otro método para mejorar el rendimiento del DNS del clúster consiste en habilitar el autoscalamiento 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.