Karpenter

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.

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.

Karpenter es un proyecto de código abierto diseñado para mejorar la gestión del ciclo de vida de los nodos en los clústeres de Kubernetes. Automatiza el aprovisionamiento y el desaprovisionamiento de los nodos en función de las necesidades de programación específicas de los pods, lo que permite un escalado eficiente y una optimización de costes. Sus funciones principales son:

Con Karpenter, puede definir NodePools con restricciones el aprovisionamiento de nodos, como las restricciones, las etiquetas, los requisitos (tipos de instancias, zonas, etc.) y los límites del total de recursos aprovisionados. Al implementar cargas de trabajo, puede especificar varias restricciones de programación en las especificaciones del módulo, como las requests/limits, node selectors, node/pod afinidades de los recursos, las tolerancias y las restricciones de distribución de la topología. Luego, Karpenter aprovisionará nodos del tamaño correcto en función de estas especificaciones.

Razones para usar Karpenter

Antes del lanzamiento de Karpenter, los usuarios de Kubernetes dependían principalmente de los grupos de Amazon EC2 Auto Scaling y del escalador automático de clústeres (CAS) de Kubernetes para ajustar dinámicamente la capacidad de procesamiento de sus clústeres. Con Karpenter, no es necesario crear docenas de grupos de nodos para lograr la flexibilidad y la diversidad que ofrece Karpenter. A diferencia de CAS, Karpenter no está tan estrechamente vinculado a las versiones de Kubernetes y no requiere que cambies entre AWS y Kubernetes. APIs

Karpenter consolida las responsabilidades de organización de instancias en un único sistema, que es más simple, estable y compatible con los clústeres. Karpenter se diseñó para superar algunos de los desafíos que presentaba Cluster Autoscaler al proporcionar formas simplificadas de:

Para obtener información y documentación sobre el uso de Karpenter, visite el sitio karpenter.sh.

Recomendaciones

Las mejores prácticas se dividen en secciones sobre Karpenter en sí y sobre la programación de módulos NodePools.

Mejores prácticas de Karpenter

Las siguientes mejores prácticas abarcan temas relacionados con el propio Karpenter.

Bloquee los clústeres AMIs de producción

Le recomendamos encarecidamente que fije las conocidas Amazon Machine Images (AMIs) utilizadas por Karpenter para los clústeres de producción. Si se utiliza amiSelector un alias definido como@latest, o si se utiliza algún otro método que dé como resultado una implementación que no se haya probado a AMIs medida que se publiquen, se corre el riesgo de que se produzcan fallos en la carga de trabajo y se produzcan tiempos de inactividad en los clústeres de producción. Por ello, recomendamos encarecidamente fijar las versiones probadas que funcionen AMIs para sus clústeres de producción y, al mismo tiempo, probar las versiones más recientes en clústeres que no sean de producción. Por ejemplo, puedes establecer un alias en tu cuenta de la NodeClass siguiente manera:

amiSelectorTerms
  - alias: al2023@v20240807

Para obtener información sobre cómo administrar y fijar datos AMIs en Karpenter, consulte Administración AMIs en la documentación de Karpenter.

Utilice Karpenter para cargas de trabajo con necesidades de capacidad cambiantes

Karpenter acerca la gestión del escalado a la versión nativa de Kubernetes que a los grupos de escalado automático () y a los grupos APIs de nodos gestionados (). ASGs MNGs ASGs y MNGs son abstracciones nativas de AWS en las que el escalado se activa en función de las métricas de nivel de AWS, como EC2 la carga de la CPU. El escalador automático de clústeres une las abstracciones de Kubernetes con las abstracciones de AWS, pero pierde algo de flexibilidad debido a eso, por ejemplo, la programación para una zona de disponibilidad específica.

Karpenter elimina una capa de abstracción de AWS para aportar parte de la flexibilidad directamente a Kubernetes. Karpenter se utiliza mejor para clústeres con cargas de trabajo que se enfrentan a períodos de alta demanda o que presentan diversos requisitos de procesamiento. MNGs y ASGs son ideales para clústeres que ejecutan cargas de trabajo que tienden a ser más estáticas y consistentes. Puede utilizar una combinación de nodos gestionados de forma dinámica y estática, en función de sus necesidades.

Considere otros proyectos de escalado automático cuando...

Necesita funciones que aún se estén desarrollando en Karpenter. Debido a que Karpenter es un proyecto relativamente nuevo, considere la posibilidad de realizar otros proyectos de escalado automático por el momento si necesita funciones que aún no forman parte de Karpenter.

Ejecute el controlador Karpenter en EKS Fargate o en un nodo de trabajo que pertenezca a un grupo de nodos

Karpenter se instala mediante un [diagrama de Helm] (https://karpenter). sh/docs/getting-started/getting-started-with-karpenter/#4 -install-karpenter). El diagrama de Helm instala el controlador Karpenter y un módulo de webhook como una implementación que debe ejecutarse antes de poder utilizar el controlador para escalar el clúster. Recomendamos un grupo de nodos pequeño como mínimo con al menos un nodo trabajador. Como alternativa, puedes ejecutar estos pods en EKS Fargate creando un perfil de Fargate para el espacio de nombres. karpenter Si lo hace, todos los pods desplegados en este espacio de nombres se ejecutarán en EKS Fargate. No ejecute Karpenter en un nodo gestionado por Karpenter.

Karpenter no admite plantillas de lanzamiento personalizadas

La versión 1 no admite plantillas de lanzamiento personalizadas. APIs Puede utilizar datos de usuario personalizados o especificar directamente la personalización AMIs en el EC2NodeClass. Encontrará más información sobre cómo hacerlo en NodeClasses.

Excluya los tipos de instancias que no se ajusten a su carga de trabajo

Considera la posibilidad de excluir tipos de instancias específicos con la node.kubernetes.io/instance-type clave si las cargas de trabajo que se ejecutan en tu clúster no los requieren.

En el siguiente ejemplo, se muestra cómo evitar el aprovisionamiento de instancias de Graviton de gran tamaño.

- key: node.kubernetes.io/instance-type
  operator: NotIn
  values:
  - m6g.16xlarge
  - m6gd.16xlarge
  - r6g.16xlarge
  - r6gd.16xlarge
  - c6g.16xlarge

Habilite la gestión de interrupciones al usar Spot

Karpenter admite la gestión nativa de las interrupciones y puede gestionar los eventos de interrupción involuntarios, como las interrupciones de instancias puntuales, los eventos de mantenimiento programado y los eventos de terminación o detención de instancias que podrían interrumpir sus cargas de trabajo. Cuando Karpenter detecta este tipo de eventos en los nodos, contamina, agota y cierra automáticamente los nodos afectados con antelación para empezar a limpiar las cargas de trabajo sin problemas antes de que se produzcan interrupciones. En el caso de las interrupciones detectadas con 2 minutos de antelación, Karpenter inicia rápidamente un nuevo nodo para poder mover los pods antes de recuperar la instancia. Para habilitar la gestión de interrupciones, configure el argumento --interruption-queue CLI con el nombre de la cola de SQS aprovisionada para este fin. No se recomienda utilizar el sistema de gestión de interrupciones de Karpenter junto con el gestor de terminaciones de nodos, tal y como se explica aquí.

Los módulos que requieran puntos de control u otras formas de drenaje correcto (es decir, 2 minutos antes de apagarlos) deberían permitir a Karpenter gestionar las interrupciones en sus clústeres.

Clúster privado Amazon EKS sin acceso a Internet saliente

Al aprovisionar un clúster de EKS en una VPC sin ruta a Internet, debe asegurarse de haber configurado su entorno de acuerdo con los requisitos de clúster privado que aparecen en la documentación de EKS. Además, debe asegurarse de haber creado un punto de enlace regional de VPC de STS en su VPC. De lo contrario, verá errores similares a los que aparecen a continuación.

{"level":"FATAL","time":"2024-02-29T14:28:34.392Z","logger":"controller","message":"Checking EC2 API connectivity, WebIdentityErr: failed to retrieve credentials\ncaused by: RequestError: send request failed\ncaused by: Post \"https://sts.<region>.amazonaws.com/\": dial tcp 54.239.32.126:443: i/o timeout","commit":"596ea97"}

Estos cambios son necesarios en un clúster privado porque el controlador de Karpenter usa las funciones de IAM para las cuentas de servicio (IRSA). Los pods configurados con IRSA adquieren credenciales mediante una llamada a la API AWS Security Token Service (AWS STS). Si no hay acceso saliente a Internet, debe crear y usar un punto de enlace de VPC de AWS STS en su VPC.

Los clústeres privados también requieren que crees un punto de conexión de VPC para SSM. Cuando Karpenter intenta aprovisionar un nodo nuevo, consulta las configuraciones de la plantilla de Launch y un parámetro de SSM. Si no tiene un punto final de VPC de SSM en su VPC, se producirá el siguiente error:

{"level":"ERROR","time":"2024-02-29T14:28:12.889Z","logger":"controller","message":"Unable to hydrate the AWS launch template cache, RequestCanceled: request context canceled\ncaused by: context canceled","commit":"596ea97","tag-key":"karpenter.k8s.aws/cluster","tag-value":"eks-workshop"}
...
{"level":"ERROR","time":"2024-02-29T15:08:58.869Z","logger":"controller.nodeclass","message":"discovering amis from ssm, getting ssm parameter \"/aws/service/eks/optimized-ami/1.27/amazon-linux-2/recommended/image_id\", RequestError: send request failed\ncaused by: Post \"https://ssm.<region>.amazonaws.com/\": dial tcp 67.220.228.252:443: i/o timeout","commit":"596ea97","ec2nodeclass":"default","query":"/aws/service/eks/optimized-ami/1.27/amazon-linux-2/recommended/image_id"}

No hay ningún punto final de VPC para la API de consulta de listas de precios. Como resultado, los datos de precios se quedarán obsoletos con el paso del tiempo. Karpenter soluciona este problema al incluir los datos de precios bajo demanda en su binario, pero solo actualiza esos datos cuando Karpenter se actualiza. Las solicitudes fallidas de datos de precios generarán los siguientes mensajes de error:

{"level":"ERROR","time":"2024-02-29T15:08:58.522Z","logger":"controller.pricing","message":"retreiving on-demand pricing data, RequestError: send request failed\ncaused by: Post \"https://api.pricing.<region>.amazonaws.com/\": dial tcp 18.196.224.8:443: i/o timeout; RequestError: send request failed\ncaused by: Post \"https://api.pricing.<region>.amazonaws.com/\": dial tcp 18.185.143.117:443: i/o timeout","commit":"596ea97"}

Consulte esta documentación para usar Karpenter en clústeres EKS completamente privados y para saber qué puntos finales de VPC se deben crear.

Creando NodePools

Las siguientes prácticas recomendadas abarcan temas relacionados con la creación NodePools.

Crea varios NodePools cuando...

Cuando distintos equipos compartan un clúster y necesiten ejecutar sus cargas de trabajo en distintos nodos de trabajo o tengan distintos requisitos de sistema operativo o tipo de instancia, cree varios NodePools. Por ejemplo, un equipo puede querer usar Bottlerocket, mientras que otro puede querer usar Amazon Linux. Del mismo modo, un equipo podría tener acceso a un hardware de GPU caro que otro equipo no necesitaría. El uso de varias unidades NodePools garantiza que cada equipo disponga de los recursos más adecuados.

Cree NodePools que sean mutuamente excluyentes o ponderados

Se recomienda crear programas NodePools que se excluyan mutuamente o que estén ponderados para proporcionar un comportamiento de programación coherente. Si no lo son y varios NodePools coinciden, Karpenter elegirá aleatoriamente cuál usar, lo que provocará resultados inesperados. Entre los ejemplos útiles para crear varios se NodePools incluyen los siguientes:

Crear una NodePool con GPU y permitir que solo se ejecuten cargas de trabajo especiales en estos nodos (caros):

# NodePool for GPU Instances with Taints
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu
spec:
  disruption:
    consolidateAfter: 1m
    consolidationPolicy: WhenEmptyOrUnderutilized
  template:
    metadata: {}
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      expireAfter: Never
      requirements:
      - key: node.kubernetes.io/instance-type
        operator: In
        values:
        - p3.8xlarge
        - p3.16xlarge
      - key: kubernetes.io/os
        operator: In
        values:
        - linux
      - key: kubernetes.io/arch
        operator: In
        values:
        - amd64
      - key: karpenter.sh/capacity-type
        operator: In
        values:
        - on-demand
      taints:
      - effect: NoSchedule
        key: nvidia.com/gpu
        value: "true"

Despliegue con tolerancia a la contaminación:

# Deployment of GPU Workload will have tolerations defined
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate-gpu
spec:
    spec:
      tolerations:
      - key: "nvidia.com/gpu"
        operator: "Exists"
        effect: "NoSchedule"

Para un despliegue general para otro equipo, la NodePool especificación podría incluir NodeAffinity. Entonces, un despliegue podría ser igual. nodeSelectorTerms billing-team

# NodePool for regular EC2 instances
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: generalcompute
spec:
  template:
    metadata:
      labels:
        billing-team: my-team
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      expireAfter: Never
      requirements:
      - key: node.kubernetes.io/instance-type
        operator: In
        values:
        - m5.large
        - m5.xlarge
        - m5.2xlarge
        - c5.large
        - c5.xlarge
        - c5a.large
        - c5a.xlarge
        - r5.large
        - r5.xlarge
      - key: kubernetes.io/os
        operator: In
        values:
        - linux
      - key: kubernetes.io/arch
        operator: In
        values:
        - amd64
      - key: karpenter.sh/capacity-type
        operator: In
        values:
        - on-demand

Despliegue mediante NodeAffinity:

# Deployment will have spec.affinity.nodeAffinity defined
kind: Deployment
metadata:
  name: workload-my-team
spec:
  replicas: 200
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                - key: "billing-team"
                  operator: "In"
                  values: ["my-team"]

Utilice temporizadores (TTL) para eliminar automáticamente los nodos del clúster

Puede usar temporizadores en los nodos aprovisionados para establecer cuándo eliminar los nodos que no tienen módulos de carga de trabajo o que han alcanzado su fecha de caducidad. La caducidad de los nodos se puede utilizar como medio de actualización, de modo que los nodos se retiren y se sustituyan por versiones actualizadas. Consulte la sección Vencimiento en la documentación de Karpenter para obtener información sobre cómo configurar la caducidad de spec.template.spec los nodos.

Evite restringir demasiado los tipos de instancias que Karpenter puede aprovisionar, especialmente cuando utilice Spot

Al utilizar Spot, Karpenter utiliza la estrategia de asignación optimizada de precio y capacidad para aprovisionar las instancias. EC2 Esta estrategia indica EC2 que hay que aprovisionar las instancias de los grupos más profundos según el número de instancias que vaya a lanzar y que tengan el menor riesgo de interrupción. EC2 A continuación, Fleet solicita instancias puntuales de los grupos con el precio más bajo. Cuantos más tipos de instancias permita que utilice Karpenter, mejor EC2 podrá optimizar el tiempo de ejecución de su instancia puntual. De forma predeterminada, Karpenter utilizará todos los tipos de instancias que EC2 ofrezca la región y las zonas de disponibilidad en las que esté desplegado el clúster. Karpenter selecciona de forma inteligente entre todos los tipos de instancias en función de los pods pendientes para asegurarse de que los pods estén programados en instancias del tamaño y el equipamiento adecuados. Por ejemplo, si su pod no requiere una GPU, Karpenter no programará su pod para un tipo de instancia que admita una EC2 GPU. Cuando no estés seguro de qué tipos de instancias usar, puedes ejecutar Amazon ec2-instance-selector para generar una lista de tipos de instancias que coincidan con tus requisitos de procesamiento. Por ejemplo, la CLI toma la memoria, la vCPU, la arquitectura y la región como parámetros de entrada y le proporciona una lista de EC2 instancias que cumplen con esas restricciones.

$ ec2-instance-selector --memory 4 --vcpus 2 --cpu-architecture x86_64 -r ap-southeast-1
c5.large
c5a.large
c5ad.large
c5d.large
c6i.large
t2.medium
t3.medium
t3a.medium

No debes imponer demasiadas restricciones a Karpenter cuando utilices instancias puntuales, ya que hacerlo puede afectar a la disponibilidad de tus aplicaciones. Supongamos, por ejemplo, que se recuperan todas las instancias de un tipo concreto y no hay alternativas adecuadas disponibles para sustituirlas. Los pods permanecerán en estado pendiente hasta que se reponga la capacidad puntual para los tipos de instancias configurados. Puedes reducir el riesgo de que se produzcan errores de capacidad insuficiente distribuyendo las instancias entre distintas zonas de disponibilidad, ya que los grupos de puntos son diferentes entre AZs sí. Dicho esto, la mejor práctica general es permitir que Karpenter utilice un conjunto diverso de tipos de instancias al usar Spot.

¿Programar pods?

Las siguientes prácticas recomendadas se refieren a la implementación de pods en un clúster mediante Karpenter para el aprovisionamiento de nodos.

Siga las prácticas recomendadas de EKS para obtener una alta disponibilidad

Si necesita ejecutar aplicaciones de alta disponibilidad, siga las recomendaciones generales de mejores prácticas de EKS. Consulte Topology Spread en la documentación de Karpenter para obtener más información sobre cómo distribuir los pods entre nodos y zonas. Usa los presupuestos de disrupción para establecer el número mínimo de pods disponibles que deben mantenerse, en caso de que se intente desalojar o eliminar los pods.

Utilice restricciones en capas para restringir las funciones informáticas disponibles en su proveedor de servicios en la nube

El modelo de restricciones en capas de Karpenter le permite crear un conjunto complejo de restricciones de despliegue de módulos NodePool y módulos para obtener las mejores adaptaciones posibles a la programación de los módulos. Entre los ejemplos de restricciones que puede solicitar una especificación de pod se incluyen los siguientes:

Cree alarmas de facturación para monitorizar su gasto informático

Cuando configure su clúster para que escale automáticamente, debe crear alarmas de facturación que le avisen cuando su gasto haya superado un umbral y añadir límites de recursos a su configuración de Karpenter. Establecer límites de recursos con Karpenter es similar a establecer la capacidad máxima de un grupo de escalado automático de AWS, ya que representa la cantidad máxima de recursos informáticos que puede instanciar un Karpenter. NodePool

El siguiente fragmento le indica a Karpenter que solo aprovisione un máximo de 1000 núcleos de CPU y 1000 Gi de memoria. Karpenter dejará de añadir capacidad solo cuando se alcance o supere el límite. Cuando se supera un límite, el controlador Karpenter memory resource usage of 1001 exceeds limit of 1000 escribirá un mensaje similar en los registros del controlador. Si estás redireccionando los registros de tu contenedor a CloudWatch registros, puedes crear un filtro de métricas para buscar patrones o términos específicos en tus registros y, a continuación, crear una CloudWatchalarma que te avise cuando se supere el umbral de métricas configurado.

Para obtener más información sobre el uso de límites con Karpenter, consulta Cómo establecer límites de recursos en la documentación de Karpenter.

spec:
  limits:
    cpu: 1000
    memory: 1000Gi

Si no utilizas límites ni restringes los tipos de instancias que Karpenter puede aprovisionar, Karpenter seguirá añadiendo capacidad de cómputo a tu clúster según sea necesario. Si bien configurar Karpenter de esta manera permite que el clúster se escale libremente, también puede tener importantes implicaciones en cuanto a los costos. Por este motivo, recomendamos configurar las alarmas de facturación. Las alarmas de facturación te permiten recibir alertas y notificaciones proactivas cuando los cargos estimados calculados en tu (s) cuenta (s) superen un umbral definido. Consulta Cómo configurar una alarma de CloudWatch facturación de Amazon para supervisar de forma proactiva los cargos estimados para obtener más información.

Es posible que también desee habilitar la detección de anomalías en los costos, que es una función de administración de costos de AWS que utiliza el aprendizaje automático para monitorear continuamente sus costos y su uso a fin de detectar gastos inusuales. Puede encontrar más información en la guía de introducción a AWS Cost Anomaly Detection. Si ha llegado a crear un presupuesto en AWS Budgets, también puede configurar una acción para que le notifique cuando se supere un umbral específico. Con las medidas presupuestarias, puede enviar un correo electrónico, publicar un mensaje en un tema de SNS o enviar un mensaje a un chatbot como Slack. Para obtener más información, consulte Configuración de las acciones de AWS Budgets.

Utilice la do-not-disrupt anotación karpenter.sh/ para evitar que Karpenter desaprovisione un nodo

Si ejecutas una aplicación crítica en un nodo aprovisionado por Karpenter, como un trabajo por lotes de larga duración o una aplicación con estado, y el TTL del nodo ha caducado, la aplicación se interrumpirá cuando se cierre la instancia. Al añadir una karpenter.sh/do-not-disrupt anotación al pod, le indica a Karpenter que conserve el nodo hasta que se cierre el pod o se elimine la anotación. karpenter.sh/do-not-disrupt Consulte la documentación de distribución para obtener más información.

Si los únicos módulos que no son de Daemonset que quedan en un nodo son los que están asociados a las tareas, Karpenter puede atacar y terminar esos nodos siempre que el estado de la tarea sea correcto o fallido.

Configure requests=limits para todos los recursos que no sean de CPU cuando utilice la consolidación

La consolidación y la programación, en general, funcionan comparando las solicitudes de recursos de los pods con la cantidad de recursos asignables en un nodo. No se tienen en cuenta los límites de recursos. Por ejemplo, los pods que tienen un límite de memoria superior a la solicitud de memoria pueden superar la solicitud. Si varios pods del mismo nodo se rompen al mismo tiempo, es posible que algunos de los pods se cierren debido a una falta de memoria (OOM). La consolidación puede aumentar las probabilidades de que esto ocurra, ya que se suele empaquetar los pods en los nodos teniendo en cuenta únicamente sus solicitudes.

Se utiliza LimitRanges para configurar los valores predeterminados de las solicitudes y los límites de recursos

Como Kubernetes no establece solicitudes ni límites predeterminados, el consumo de recursos del host, la CPU y la memoria subyacentes por parte de un contenedor no está limitado. El programador de Kubernetes analiza el total de solicitudes de un pod (cuanto mayor sea el total de solicitudes de los contenedores del pod o el total de recursos de los contenedores de inicio del pod) para determinar en qué nodo de trabajo programar el pod. Del mismo modo, Karpenter considera las solicitudes de un pod para determinar qué tipo de instancia aprovisiona. Puedes usar un rango de límites para aplicar un valor predeterminado razonable a un espacio de nombres, en caso de que algunos pods no especifiquen las solicitudes de recursos.

Consulte Configurar las solicitudes y los límites de memoria predeterminados para un espacio de nombres

Aplique solicitudes de recursos precisas a todas las cargas de trabajo

Karpenter puede lanzar los nodos que mejor se adapten a sus cargas de trabajo cuando la información sobre sus requisitos de carga de trabajo es precisa. Esto es particularmente importante si se utiliza la función de consolidación de Karpenter.

Consulte Configurar y dimensionar las solicitudes/límites de recursos para todas las cargas de trabajo

Recomendaciones de CoredNS

Actualice la configuración de CoredNS para mantener la confiabilidad

Al implementar pods de CoreDNS en nodos gestionados por Karpenter, dada la naturaleza dinámica de Karpenter a la hora de terminar o crear nuevos nodos rápidamente para adaptarlos a la demanda, es recomendable seguir las siguientes prácticas recomendadas:

Duración lamentable de CoredNS

Sonda de preparación de CoredNS

Esto garantizará que las consultas de DNS no se dirijan a un pod de CoreDNS que aún no esté listo o que haya finalizado.

Planos de Karpenter

Dado que Karpenter adopta un enfoque centrado en las aplicaciones para aprovisionar la capacidad de cómputo en el plano de datos de Kubernetes, hay situaciones de carga de trabajo habituales en las que quizás se pregunte cómo configurarlas correctamente. Karpenter Blueprints es un repositorio que incluye una lista de escenarios de carga de trabajo comunes siguiendo las mejores prácticas que se describen aquí. Dispondrá de todos los recursos que necesita incluso para crear un clúster de EKS con Karpenter configurado y probar cada uno de los planos incluidos en el repositorio. Puede combinar diferentes planos para crear finalmente el que necesite para sus cargas de trabajo.

Recursos adicionales