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.

Computación y escalado automático

Como desarrollador, harás estimaciones sobre las necesidades de recursos de tu aplicación, por ejemplo, de CPU y memoria, pero si no las ajustas continuamente, es posible que queden anticuadas, lo que podría aumentar tus costes y empeorar el rendimiento y la fiabilidad. Es más importante ajustar continuamente los requisitos de recursos de una aplicación que hacerlos bien la primera vez.

Las mejores prácticas que se mencionan a continuación le ayudarán a crear y operar cargas de trabajo rentables que logren resultados empresariales y, al mismo tiempo, minimicen los costos y permitan a su organización maximizar el retorno de la inversión. Un orden de importancia de alto nivel para optimizar los costos de cómputo de los clústeres es:

Dimensione sus cargas de trabajo de forma adecuada

En la mayoría de los clústeres de EKS, la mayor parte del costo proviene de las EC2 instancias que se utilizan para ejecutar las cargas de trabajo en contenedores. No podrá dimensionar correctamente sus recursos informáticos sin comprender los requisitos de sus cargas de trabajo. Por este motivo, es esencial que utilice las solicitudes y los límites adecuados y que realice los ajustes necesarios en esos ajustes. Además, las dependencias, como el tamaño de la instancia y la selección del almacenamiento, pueden afectar al rendimiento de la carga de trabajo, lo que puede tener diversas consecuencias imprevistas en los costes y la fiabilidad.

Las solicitudes deben ajustarse a la utilización real. Si las solicitudes de un contenedor son demasiado altas, habrá capacidad no utilizada, lo que constituye un factor importante en los costos totales del clúster. Cada contenedor de un módulo, por ejemplo, una aplicación o un sidecar, debe tener sus propias solicitudes y límites establecidos para garantizar que los límites totales de los módulos sean lo más precisos posible.

Utilice herramientas como Goldilocks, KRR y Kubecost, que calculan las solicitudes de recursos y los límites de sus contenedores. Según la naturaleza de las aplicaciones, performance/cost los requisitos y la complejidad, debe evaluar qué métricas son las mejores para escalar, en qué punto se degrada el rendimiento de la aplicación (punto de saturación) y cómo ajustar las solicitudes y los límites en consecuencia. Consulte el artículo sobre el tamaño correcto de las aplicaciones para obtener más información sobre este tema.

Recomendamos usar el escalador automático de pods horizontales (HPA) para controlar cuántas réplicas de la aplicación deben ejecutarse, el escalador automático de pods verticales (VPA) para ajustar el número de solicitudes y los límites que la aplicación necesita por réplica, y un escalador automático de nodos como Karpenter o Cluster Autoscaler para ajustar continuamente el número total de nodos del clúster. Las técnicas de optimización de costos que utilizan Karpenter y Cluster Autoscaler se documentan en una sección posterior de este documento.

El escalador automático Vertical Pod puede ajustar las solicitudes y los límites asignados a los contenedores para que las cargas de trabajo se ejecuten de manera óptima. Debe ejecutar el VPA en modo de auditoría para que no realice cambios automáticamente ni reinicie los pods. Sugerirá cambios en función de las métricas observadas. Si se producen cambios que afecten a las cargas de trabajo de producción, primero debe revisarlos y probarlos en un entorno que no sea de producción, ya que pueden afectar a la fiabilidad y el rendimiento de la aplicación.

Reduzca el consumo

La mejor forma de ahorrar dinero es aprovisionar menos recursos. Una forma de hacerlo es ajustar las cargas de trabajo en función de sus requisitos actuales. Debe comenzar cualquier esfuerzo de optimización de costos asegurándose de que sus cargas de trabajo definan sus requisitos y escalen de forma dinámica. Para ello, será necesario obtener las métricas de las aplicaciones y configurar configuraciones (por ejemplo, Pod Readiness Gates) para garantizar que la aplicación pueda ampliarse y reducirse de forma dinámica y segura. PodDisruptionBudgets Es importante tener en cuenta que las restricciones PodDisruptionBudgets pueden impedir que Cluster Autoscaler y Karpenter reduzcan la escala de los nodos, ya que tanto Cluster Autoscaler como Karpenter respetan. PodDisruptionBudgets El valor «minAvailable» en el campo «minAvailable» siempre PodDisruptionBudget debe ser inferior al número de pods de la implementación y se debe mantener una buena separación entre ambos, por ejemplo, en un despliegue de 6 pods en el que desee tener un mínimo de 4 pods en funcionamiento en todo momento, establezca el valor «minAvailable» en 4. PodDisruptionBidget Esto permitirá que Cluster Autoscaler y Karpenter drenen y desalojen de forma segura los pods de los nodos infrautilizados durante un evento de reducción de escala de nodos. Consulte el documento de preguntas frecuentes sobre Cluster Autoscaler.

El escalador automático horizontal Pod es un escalador automático de cargas de trabajo flexible que puede ajustar el número de réplicas que se necesitan para cumplir con los requisitos de rendimiento y confiabilidad de su aplicación. Cuenta con un modelo flexible para definir cuándo escalar hacia arriba y hacia abajo en función de varias métricas, como la CPU o la memoria, o métricas personalizadas, por ejemplo, la profundidad de la cola, el número de conexiones a un pod, etc.

El Kubernetes Metrics Server permite el escalado en respuesta a métricas integradas, como el uso de la CPU y la memoria, pero si quieres escalar en función de otras métricas, como la profundidad de colas de Amazon CloudWatch o SQS, deberías considerar proyectos de escalado automático basados en eventos, como KEDA. Consulte esta entrada de blog sobre cómo utilizar KEDA con las métricas. CloudWatch Si no está seguro de qué métricas debe monitorizar y en qué base escalar, consulte las mejores prácticas de monitorización de las métricas más importantes.

Reducir el consumo de carga de trabajo crea un exceso de capacidad en un clúster y, con una configuración de escalado automático adecuada, puede reducir los nodos automáticamente y reducir el gasto total. Le recomendamos que no intente optimizar la capacidad de cómputo manualmente. El programador de Kubernetes y los escaladores automáticos de nodos se diseñaron para gestionar este proceso por ti.

Reduzca la capacidad no utilizada

Una vez que haya determinado el tamaño correcto de las aplicaciones y reduzca el exceso de solicitudes, puede empezar a reducir la capacidad informática aprovisionada. Debería poder hacerlo de forma dinámica si se ha tomado el tiempo de dimensionar correctamente sus cargas de trabajo según las secciones anteriores. Hay dos escaladores automáticos de nodos principales que se utilizan con Kubernetes en AWS.

Karpenter y Cluster Autoscaler

Tanto Karpenter como el escalador automático de clústeres de Kubernetes escalarán la cantidad de nodos del clúster a medida que se creen o eliminen los pods y cambien los requisitos de procesamiento. El objetivo principal de ambos es el mismo, pero Karpenter adopta un enfoque diferente para la administración de nodos, el aprovisionamiento y el desaprovisionamiento, lo que puede ayudar a reducir los costos y optimizar el uso en todo el clúster.

A medida que los clústeres aumentan de tamaño y la variedad de cargas de trabajo, se hace más difícil configurar previamente los grupos de nodos y las instancias. Al igual que ocurre con las solicitudes de carga de trabajo, es importante establecer un punto de referencia inicial y ajustarlo continuamente según sea necesario.

Si utiliza Cluster AutoScaler, respetará los valores «mínimo» y «máximo» de cada grupo de Auto Scaling (ASG) y solo ajustará el valor «deseado». Es importante prestar atención al establecer estos valores para el ASG subyacente, ya que Cluster Autoscaler no podrá reducir un ASG más allá de su recuento «mínimo». Defina el recuento «deseado» como el número de nodos que necesita durante el horario laboral normal y «mínimo» como el número de nodos que necesita fuera del horario laboral. Consulte el documento de preguntas frecuentes sobre Cluster Autoscaler.

Expansor prioritario de escalador automático de clústeres

El escalador automático de clústeres de Kubernetes funciona escalando grupos de nodos (denominados grupo de nodos) hacia arriba y hacia abajo a medida que las aplicaciones se escalan hacia arriba y hacia abajo. Si no escala las cargas de trabajo de forma dinámica, el escalador automático de clústeres no le ayudará a ahorrar dinero. El escalador automático de clústeres requiere que un administrador de clústeres cree grupos de nodos con antelación para que las cargas de trabajo se consuman. Los grupos de nodos deben configurarse para usar instancias que tengan el mismo «perfil», es decir, aproximadamente la misma cantidad de CPU y memoria.

Puede tener varios grupos de nodos y el escalador automático de clústeres se puede configurar para establecer niveles de escalado prioritarios, y cada grupo de nodos puede contener nodos de diferentes tamaños. Los grupos de nodos pueden tener diferentes tipos de capacidad y el expansor de prioridad se puede usar para escalar primero los grupos menos costosos.

A continuación, se muestra un ejemplo de un fragmento de configuración de clúster que utiliza ConfigMap` a para priorizar la capacidad reservada antes de usar instancias bajo demanda. Puede utilizar la misma técnica para dar prioridad a las instancias Graviton o puntual frente a otros tipos.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-cluster
managedNodeGroups:
  - name: managed-ondemand
    minSize: 1
    maxSize: 7
    instanceType: m5.xlarge
  - name: managed-reserved
    minSize: 2
    maxSize: 10
    instanceType: c5.2xlarge

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-priority-expander
  namespace: kube-system
data:
  priorities: |-
    10:
      - .*ondemand.*
    50:
      - .*reserved.*

El uso de grupos de nodos puede ayudar a los recursos informáticos subyacentes a cumplir lo esperado de forma predeterminada, es decir, distribuir los nodos entre sí AZs, pero no todas las cargas de trabajo tienen los mismos requisitos o expectativas, por lo que es mejor dejar que las aplicaciones declaren sus requisitos de forma explícita. Para obtener más información sobre el escalador automático de clústeres, consulta la sección de prácticas recomendadas.

Desprogramador

El escalador automático de clústeres puede añadir y eliminar la capacidad de los nodos de un clúster en función de la necesidad de programar nuevos pods o de la infrautilización de los nodos. No adopta una visión holística de la ubicación de los pods una vez que se han programado en un nodo. Si utiliza el escalador automático de clústeres, también debería utilizar el desprogramador de Kubernetes para evitar desperdiciar capacidad en su clúster.

Si tiene 10 nodos en un clúster y cada nodo se utiliza en un 60%, no está utilizando el 40% de la capacidad aprovisionada en el clúster. Con el escalador automático de clústeres, puede establecer el umbral de utilización por nodo en un 60%, pero solo intentará reducir la escala de un nodo si la utilización cayera por debajo del 60%.

Con el desprogramador, puede analizar la capacidad y la utilización del clúster una vez que se hayan programado los pods o se hayan agregado nodos al clúster. Intenta mantener la capacidad total del clúster por encima de un umbral específico. También puede eliminar los pods en función de la contaminación de los nodos o de los nuevos nodos que se unan al clúster para garantizar que los pods se ejecuten en su entorno informático óptimo. Ten en cuenta que el desprogramador no programa el reemplazo de los pods desalojados, sino que se basa en el programador predeterminado para ello.

Consolidación de Karpenter

Karpenter adopta un enfoque «sin grupos» para la gestión de nodos. Este enfoque es más flexible para los diferentes tipos de carga de trabajo y requiere una configuración inicial menor para los administradores de clústeres. En lugar de predefinir los grupos y escalar cada grupo según las necesidades de las cargas de trabajo, Karpenter utiliza aprovisionadores y plantillas de nodos para definir en términos generales qué tipo de EC2 instancias se pueden crear y la configuración de las instancias a medida que se crean.

El empaquetado en contenedores es la práctica de utilizar más recursos de la instancia, agrupando más cargas de trabajo en un menor número de instancias con un tamaño óptimo. Si bien esto ayuda a reducir los costos de procesamiento al aprovisionar únicamente los recursos que utilizan sus cargas de trabajo, tiene su contrapartida. El inicio de nuevas cargas de trabajo puede tardar más tiempo, ya que hay que añadir capacidad al clúster, especialmente durante eventos de gran escalado. Tenga en cuenta el equilibrio entre la optimización de costos, el rendimiento y la disponibilidad al configurar el embalaje en contenedores.

Karpenter puede monitorear y empaquetar archivos de forma continua para mejorar la utilización de los recursos de las instancias y reducir los costos de procesamiento. Karpenter también puede seleccionar un nodo de trabajadores más rentable para su carga de trabajo. Esto se puede lograr activando el indicador de «consolidación» en true en el aprovisionador (véase un fragmento de código de ejemplo a continuación). En el siguiente ejemplo, se muestra un ejemplo de aprovisionador que permite la consolidación. En el momento de escribir esta guía, Karpenter no sustituirá una instancia de Spot en ejecución por una instancia de Spot más económica. Para obtener más información sobre la consolidación de Karpenter, consulta este blog.

apiVersion: karpenter.sh/v1
kind: Provisioner
metadata:
  name: enable-binpacking
spec:
  consolidation:
    enabled: true

En el caso de cargas de trabajo que podrían no ser interrumpibles, por ejemplo, trabajos por lotes de larga duración sin puntos de control, considere la posibilidad de anotar los módulos con esa anotación. do-not-evict Al optar por no desalojar los módulos, le estás diciendo a Karpenter que no debe eliminar voluntariamente los nodos que contengan este módulo. Sin embargo, si se do-not-evict añade un módulo a un nodo mientras éste se está vaciando, los módulos restantes se seguirán desalojando, pero ese módulo bloqueará la terminación hasta que se elimine. En cualquier caso, se acordonará el nodo para evitar que se programen trabajos adicionales en el nodo. A continuación se muestra un ejemplo que muestra cómo configurar la anotación:

apiVersion: v1
kind: Pod
metadata:
  name: label-demo
  labels:
    environment: production
  annotations: +
    "karpenter.sh/do-not-evict": "true"
spec:
  containers:

* name: nginx
image: nginx
ports:
 ** containerPort: 80

Elimine los nodos infrautilizados ajustando los parámetros del escalador automático del clúster

La utilización de los nodos se define como la suma de los recursos solicitados dividida por la capacidad. De forma predeterminada, scale-down-utilization-threshold se establece en el 50%. Este parámetro se puede utilizar junto con yscale-down-unneeded-time, que determina cuánto tiempo no se necesitará un nodo antes de que pueda ser reducido (el valor predeterminado es de 10 minutos). Kube-scheduler programará los pods que sigan ejecutándose en un nodo reducido en otros nodos. Ajustar esta configuración puede ayudar a eliminar los nodos que están infrautilizados, pero es importante que primero pruebes estos valores para no forzar al clúster a reducir su escala prematuramente.

Para evitar que se produzca una reducción de tamaño, asegúrese de que los módulos cuyo desalojo resulta caro estén protegidos por una etiqueta reconocida por el escalador automático de clústeres. Para ello, asegúrese de que los módulos cuyo desalojo resulta caro tengan la anotación correspondiente. cluster-autoscaler.kubernetes.io/safe-to-evict=false A continuación se muestra un ejemplo de yaml para configurar la anotación:

apiVersion: v1
kind: Pod
metadata:
  name: label-demo
  labels:
    environment: production
  annotations: +
    "cluster-autoscaler.kubernetes.io/safe-to-evict": "false"
spec:
  containers:

* name: nginx
image: nginx
ports:
 ** containerPort: 80

Etiquete los nodos con Cluster Autoscaler y Karpenter

Las etiquetas de recursos de AWS se utilizan para organizar los recursos y realizar un seguimiento detallado de los costes de AWS. No se correlacionan directamente con las etiquetas de Kubernetes para el seguimiento de los costos. Se recomienda empezar con el etiquetado de los recursos de Kubernetes y utilizar herramientas como Kubecost para obtener informes sobre los costes de infraestructura basados en las etiquetas de Kubernetes en los pods, los espacios de nombres, etc.

Los nodos de trabajo deben tener etiquetas para mostrar la información de facturación en AWS Cost Explorer. Con Cluster AutoScaler, etiquete sus nodos de trabajo dentro de un grupo de nodos administrado mediante una plantilla de lanzamiento. En el caso de los grupos de nodos autogestionados, etiquete las instancias mediante un grupo de escalado EC2 automático. En el caso de las instancias aprovisionadas por Karpenter, etiquétalas con spec.tags en la plantilla de nodos.

Clústeres con varios inquilinos

Cuando trabajas en clústeres que comparten diferentes equipos, es posible que no puedas ver otras cargas de trabajo que se ejecutan en el mismo nodo. Si bien las solicitudes de recursos pueden ayudar a aislar algunos problemas de «vecinos ruidosos», como el uso compartido de la CPU, es posible que no aíslen todos los límites de los recursos, como el I/O agotamiento del disco. No todos los recursos consumibles de una carga de trabajo pueden aislarse o limitarse. Las cargas de trabajo que consumen recursos compartidos a un ritmo mayor que otras cargas de trabajo deben aislarse teniendo en cuenta las limitaciones y tolerancias de los nodos. Otra técnica avanzada para este tipo de carga de trabajo es la fijación de la CPU, que garantiza la utilización exclusiva de la CPU en lugar de una CPU compartida para el contenedor.

Aislar las cargas de trabajo a nivel de nodo puede resultar más caro, pero es posible programar los BestEfforttrabajos o aprovechar los ahorros adicionales mediante el uso de instancias reservadas, procesadores Graviton o Spot.

Los clústeres compartidos también pueden tener limitaciones de recursos a nivel de clúster, como el agotamiento de la IP, los límites de servicio de Kubernetes o las solicitudes de escalado de las API. Deberías revisar la guía de prácticas recomendadas de escalabilidad para asegurarte de que tus clústeres eviten estos límites.

Puedes aislar los recursos a nivel de un espacio de nombres o de un aprovisionador de Karpenter. Las cuotas de recursos proporcionan una forma de establecer límites sobre la cantidad de recursos que pueden consumir las cargas de trabajo en un espacio de nombres. Esta puede ser una buena barrera inicial, pero debe evaluarse continuamente para garantizar que no restrinja artificialmente el escalamiento de las cargas de trabajo.

Los aprovisionadores de Karpenter pueden establecer límites para algunos de los recursos consumibles de un clúster (por ejemplo, la CPU o la GPU), pero tendrá que configurar las aplicaciones arrendatarias para que utilicen el aprovisionador adecuado. Esto puede evitar que un solo aprovisionador cree demasiados nodos en un clúster, pero debe evaluarse continuamente para garantizar que el límite no sea demasiado bajo y, a su vez, evitar que las cargas de trabajo se escalen.

Escalado automático programado

Es posible que tenga que reducir la escala de sus clústeres los fines de semana y fuera del horario laboral. Esto es especialmente importante para los clústeres de prueba y los que no son de producción, en los que se desea reducir la escala a cero cuando no están en uso. Soluciones como la reducción del tamaño de los clústeres permiten reducir las réplicas a cero en función de una programación cron. También puede lograrlo con Karpenter, tal y como se describe en el siguiente blog de AWS.

Optimice los tipos de capacidad informática

Tras optimizar la capacidad total de procesamiento de su clúster y utilizar el empaquetado en contenedores, debe analizar qué tipo de procesamiento ha aprovisionado en sus clústeres y cómo paga esos recursos. AWS cuenta con planes de ahorro informático que pueden reducir el coste de su procesamiento, que clasificaremos en los siguientes tipos de capacidad:

Cada tipo de capacidad tiene diferentes desventajas en cuanto a los gastos generales de administración, la disponibilidad y los compromisos a largo plazo, y tendrá que decidir cuál es la adecuada para su entorno. Ningún entorno debe depender de un solo tipo de capacidad y puede combinar varios tipos de ejecución en un solo clúster para optimizar los costos y los requisitos de carga de trabajo específicos.

Spot

El tipo de capacidad puntual aprovisiona EC2 instancias a partir de la capacidad sobrante de una zona de disponibilidad. Spot ofrece los mayores descuentos (hasta un 90%), pero esas instancias se pueden interrumpir cuando se necesiten en otros lugares. Además, es posible que no siempre haya capacidad para aprovisionar nuevas instancias de Spot y las instancias de Spot existentes se pueden recuperar con un aviso de interrupción de 2 minutos. Si su aplicación tiene un proceso de inicio o cierre prolongado, es posible que las instancias puntuales no sean la mejor opción.

La computación puntual debe utilizar una amplia variedad de tipos de instancias para reducir la probabilidad de no disponer de capacidad puntual. Las interrupciones de las instancias deben gestionarse para cerrar los nodos de forma segura. Los nodos aprovisionados con Karpenter o que forman parte de un grupo de nodos gestionado admiten automáticamente las notificaciones de interrupción de instancias. Si utilizas nodos autogestionados, tendrás que ejecutar el controlador de terminación de nodos por separado para cerrar correctamente las instancias puntuales.

Es posible equilibrar las instancias puntuales y bajo demanda en un solo clúster. Con Karpenter, puede crear aprovisionadores ponderados para lograr un equilibrio entre los diferentes tipos de capacidad. Con Cluster Autoscaler, puede crear grupos de nodos mixtos con instancias puntuales y bajo demanda o reservadas.

A continuación, se muestra un ejemplo del uso de Karpenter para priorizar las instancias puntuales antes que las instancias bajo demanda. Al crear un aprovisionador, puede especificar las opciones puntuales, bajo demanda o ambas (como se muestra a continuación). Si especificas ambas opciones, y si el pod no especifica explícitamente si necesita usar Spot o On-Demand, Karpenter prioriza Spot al aprovisionar un nodo con una estrategia de asignación. price-capacity-optimization

apiVersion: karpenter.sh/v1
kind: Provisioner
metadata:
  name: spot-prioritized
spec:
  requirements:
    - key: "karpenter.sh/capacity-type"
      operator: In
        values: ["spot", "on-demand"]

Savings Plans, Reserved Instances y AWS EDP

Puede reducir su gasto informático mediante un plan de ahorro informático. Los planes de ahorro ofrecen precios reducidos con un compromiso de uso informático de 1 o 3 años. El uso se puede aplicar a EC2 las instancias de un clúster de EKS, pero también se aplica a cualquier uso informático, como Lambda y Fargate. Con los planes de ahorro, puede reducir los costos y seguir eligiendo cualquier tipo de EC2 instancia durante su período de compromiso.

El plan de ahorro informático puede reducir sus EC2 costes hasta en un 66% sin tener que comprometerse con los tipos de instancias, las familias o las regiones que desee utilizar. Los ahorros se aplican automáticamente a las instancias a medida que las usa.

EC2 Instance Savings Plans ofrece hasta un 72% de ahorro en cómputo con un compromiso de uso en una región y EC2 familia específicas, por ejemplo, instancias de la familia C. Puede cambiar el uso a cualquier zona de disponibilidad de la región, utilizar cualquier generación de la familia de instancias, por ejemplo, c5 o c6, y utilizar instancias de cualquier tamaño dentro de la familia. El descuento se aplicará automáticamente a cualquier instancia de tu cuenta que cumpla con los criterios del plan de ahorro.

Las instancias reservadas son similares a EC2 Instance Savings Plan, pero también garantizan la capacidad en una zona o región de disponibilidad y reducen los costos (hasta un 72%) en comparación con las instancias bajo demanda. Una vez que calcule la cantidad de capacidad reservada que necesitará, puede seleccionar durante cuánto tiempo desea reservarla (1 o 3 años). Los descuentos se aplicarán automáticamente a medida que ejecute esas EC2 instancias en su cuenta.

Los clientes también tienen la opción de suscribirse a un acuerdo empresarial con AWS. Los contratos Enterprise ofrecen a los clientes la opción de personalizar los acuerdos que mejor se adapten a sus necesidades. Los clientes pueden disfrutar de descuentos en los precios basados en AWS EDP (Enterprise Discount Program). Para obtener información adicional sobre los acuerdos empresariales, póngase en contacto con su representante de ventas de AWS.

Bajo demanda

EC2 Las instancias bajo demanda ofrecen la ventaja de estar disponibles sin interrupciones (en comparación con las instancias puntuales) y de no tener compromisos a largo plazo (en comparación con los planes de ahorro). Si desea reducir los costos en un clúster, debe reducir el uso de EC2 instancias bajo demanda.

Tras optimizar los requisitos de carga de trabajo, debería poder calcular la capacidad mínima y máxima de los clústeres. Este número puede cambiar con el tiempo, pero rara vez disminuye. Considere la posibilidad de utilizar un Savings Plan para todo lo que esté por debajo del mínimo y busque una capacidad que no afecte a la disponibilidad de su solicitud. Cualquier otra cosa que no se utilice de forma continua o que sea necesaria para garantizar su disponibilidad se puede utilizar bajo demanda.

Como se menciona en esta sección, la mejor manera de reducir el uso es consumir menos recursos y utilizar los recursos que aprovisiona en la mayor medida posible. Con el escalador automático de clústeres, puede eliminar los nodos infrautilizados con esta configuración. scale-down-utilization-threshold Con Karpenter, se recomienda habilitar la consolidación.

Para identificar manualmente los tipos de EC2 instancias que se pueden usar con sus cargas de trabajo, debe usar ec2-instance-selector, que puede mostrar las instancias que están disponibles en cada región, así como las instancias compatibles con EKS. Ejemplo de uso para instancias con arquitectura de procesos x86, 4 Gb de memoria, 2 v CPUs y disponibles en la región us-east-1.

ec2-instance-selector --memory 4 --vcpus 2 --cpu-architecture x86_64 \
  -r us-east-1 --service eks
c5.large
c5a.large
c5ad.large
c5d.large
c6a.large
c6i.large
t2.medium
t3.medium
t3a.medium

Para los entornos que no son de producción, puede hacer que los clústeres se reduzcan automáticamente durante las horas no utilizadas, como la noche y los fines de semana. El proyecto kubecost cluster-turndown es un ejemplo de un controlador que puede reducir automáticamente la escala del clúster en función de un cronograma establecido.

Computación Fargate

Fargate Compute es una opción de procesamiento totalmente gestionada para los clústeres EKS. Proporciona aislamiento de pods mediante la programación de un pod por nodo en un clúster de Kubernetes. Le permite ajustar el tamaño de sus nodos de procesamiento a los requisitos de CPU y RAM de su carga de trabajo para controlar estrictamente el uso de la carga de trabajo en un clúster.

Fargate puede escalar cargas de trabajo tan pequeñas como 0,25 vCPU con 0,5 GB de memoria y tan grandes como 16 vCPU con 120 GB de memoria. Hay límites en cuanto a la cantidad de variaciones de tamaño de cápsula disponibles y tendrá que entender cuál es la mejor manera de adaptar su carga de trabajo a una configuración de Fargate. Por ejemplo, si su carga de trabajo requiere 1 vCPU con 0,5 GB de memoria, el pod Fargate más pequeño será 1 vCPU con 2 GB de memoria.

Si bien Fargate tiene muchas ventajas, como la ausencia de administración de EC2 instancias o sistemas operativos, es posible que requiera más capacidad de procesamiento que EC2 las instancias tradicionales debido a que cada pod implementado está aislado como un nodo independiente en el clúster. Esto requiere una mayor duplicación en el caso de elementos como el Kubelet, los agentes de registro y todos los DaemonSets que se suelen implementar en un nodo. DaemonSets no son compatibles con Fargate y deberán convertirse en un pod «`sidecars"` y ejecutarse junto con la aplicación.

Fargate no puede beneficiarse del empaquetado en contenedores ni del sobreaprovisionamiento de la CPU porque el límite de la carga de trabajo es un nodo que no se puede dividir ni compartir entre cargas de trabajo. Fargate le ahorrará tiempo de administración de EC2 instancias, lo que en sí mismo tiene un costo, pero los costos de CPU y memoria pueden ser más caros que otros tipos de EC2 capacidad. Los pods Fargate pueden aprovechar el plan de ahorro de cómputo para reducir el costo bajo demanda.

Optimice el uso de la computación

Otra forma de ahorrar dinero en su infraestructura de cómputo es utilizar un cómputo más eficiente para la carga de trabajo. Esto puede provenir de un cómputo de uso general de mayor rendimiento, como los procesadores Graviton, que son hasta un 20% más baratos y un 60% más eficientes desde el punto de vista energético que los x86, o de aceleradores específicos para cargas de trabajo, como y. GPUs FPGAs Necesitará crear contenedores que puedan ejecutarse en una arquitectura ARM y configurar los nodos con los aceleradores adecuados para sus cargas de trabajo.

EKS tiene la capacidad de ejecutar clústeres con arquitecturas mixtas (por ejemplo, amd64 y arm64) y, si sus contenedores están compilados para varias arquitecturas, puede aprovechar los procesadores Graviton con Karpenter y permitir que ambas arquitecturas estén integradas en su aprovisionador. Sin embargo, para mantener un rendimiento uniforme, se recomienda mantener cada carga de trabajo en una única arquitectura de cómputo y utilizar solo una arquitectura diferente si no hay capacidad adicional disponible.

Los aprovisionadores se pueden configurar con varias arquitecturas y las cargas de trabajo también pueden solicitar arquitecturas específicas en sus especificaciones de carga de trabajo.

apiVersion: karpenter.sh/v1
kind: Provisioner
metadata:
  name: default
spec:
  requirements:
  - key: "kubernetes.io/arch"
    operator: In
    values: ["arm64", "amd64"]

Con Cluster Autoscaler, necesitará crear un grupo de nodos para las instancias de Graviton y establecer tolerancias de nodos en su carga de trabajo para utilizar la nueva capacidad.

GPUs y FPGAs puede aumentar considerablemente el rendimiento de su carga de trabajo, pero será necesario optimizar la carga de trabajo para poder utilizar el acelerador. Se pueden usar muchos tipos de cargas de trabajo para el aprendizaje automático y la inteligencia artificial GPUs para la computación, y las instancias se pueden agregar a un clúster y montar en una carga de trabajo mediante solicitudes de recursos.

spec:
  template:
    spec:
    - containers:
      ...
      resources:
          limits:
            nvidia.com/gpu: "1"

Parte del hardware de la GPU se puede compartir entre varias cargas de trabajo, por lo que se puede aprovisionar y utilizar una sola GPU. Para ver cómo configurar el uso compartido de la GPU de la carga de trabajo, consulte el complemento del dispositivo de GPU virtual para obtener más información. También puedes consultar los siguientes blogs: