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

Karpenter es un proyecto de código abierto que proporciona administración del ciclo de vida de los nodos para los clústeres de Kubernetes. Automatiza el aprovisionamiento y el desaprovisionamiento de los nodos en función de las necesidades de programación 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 restricciones de programación en la especificación 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 adecuado para esos pods.

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 de Kubernetes (CAS) 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. Además, Karpenter no está tan estrechamente vinculado a las versiones de Kubernetes (como sí lo CAS está) y no requiere que saltes entre Kubernetes y Kubernetes. AWS APIs

Karpenter consolida las responsabilidades de orquestación de instancias en un único sistema, que es más simple, estable y compatible con 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.

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 ASGsy MNGs son abstracciones AWS nativas en las que el escalado se activa en función de métricas de nivel, como la carga. AWS EC2 CPU El escalador automático de clústeres une las abstracciones de Kubernetes con las AWS abstracciones, pero pierde algo de flexibilidad debido a ello, por ejemplo, la programación para una zona de disponibilidad específica.

Karpenter elimina una capa de AWS abstracción 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 tienen diversos requisitos de procesamiento. MNGsy 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 gráfico de Helm. 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 v1beta1 (APIsv0.32+) no admite plantillas de lanzamiento personalizadas. Puede utilizar datos de usuario personalizados y/o especificar directamente la personalización en. AMIs 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 las interrupciones, debe configurar el --interruption-queue CLI argumento con el nombre de la SQS cola 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 EKS privado de Amazon sin acceso a Internet saliente

Al aprovisionar un EKS clúster en un lugar VPC sin ruta a Internet, debe asegurarse de haber configurado su entorno de acuerdo con los requisitos del clúster privado que aparecen en EKS la documentación. Además, debes asegurarte de haber creado un punto de conexión STS VPC regional en tuVPC. De lo contrario, verás 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 IAM roles para las cuentas de servicio ()IRSA. Los pods configurados para IRSA obtener las credenciales se obtienen mediante una llamada al AWS Security Token Service () AWSSTS. API Si no hay acceso saliente a Internet, debes crear y usar un AWSSTSVPCpunto final en tu VPC.

Los clústeres privados también requieren que cree un VPCpunto final para SSM. Cuando Karpenter intenta aprovisionar un nodo nuevo, consulta las configuraciones de la plantilla de Launch y un parámetro. SSM Si no tiene un SSM VPC punto final en su dispositivoVPC, 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 VPCpunto final para la consulta de la lista de precios API. Como resultado, los datos de precios se quedarán obsoletos con el 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 utilizar Karpenter en EKS clústeres completamente privados y para saber qué VPC puntos finales 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 GPU hardware caro que otro equipo no necesitaría. El uso de varios dispositivos NodePools garantiza que cada equipo disponga de los activos 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 un NodePool nodo GPU y permitir que solo se ejecuten cargas de trabajo especiales en estos (caros) nodos:

# NodePool for GPU Instances with Taints
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: gpu
spec:
  disruption:
    consolidateAfter: 1m0s
    consolidationPolicy: WhenEmpty
    expireAfter: Never
  template:
    metadata: {}
    spec:
      nodeClassRef:
        name: default
      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"

En el caso de un despliegue general para otro equipo, la NodePool especificación podría incluir: nodeAffinity Entonces, se podría utilizar un despliegue nodeSelectorTerms para que billing-team coincidiera.

# NodePool for regular EC2 instances
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: generalcompute
spec:
  disruption:
    expireAfter: Never
  template:
    metadata:
      labels:
        billing-team: my-team
    spec:
      nodeClassRef:
        name: default
      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 mediantenodeAffinity:

# 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 timers (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 una 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.disruption.expireAfter 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. EC2A 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 unGPU, Karpenter no programará su pod para un tipo de instancia que admita un. 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, CLI toma la memoria vCPU, la arquitectura y la región como parámetros de entrada y 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 EKS recomendadas para obtener una alta disponibilidad

Si necesita ejecutar aplicaciones de alta disponibilidad, siga las recomendaciones generales de EKS mejores prácticas. 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 AWS escalado automático, 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 CPU núcleos 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.

También puedes activar la detección de anomalías en los costes, que es una función de gestión de AWS costes que utiliza el aprendizaje automático para monitorizar continuamente los costes y el uso a fin de detectar gastos inusuales. Puede encontrar más información en la guía de introducción a la detección de anomalías de AWS costes. Si has llegado a crear un presupuesto en AWS Presupuestos, también puedes configurar una acción para que te notifique cuando se supere un umbral específico. Con las acciones presupuestarias, puedes enviar un correo electrónico, publicar un mensaje en un SNS tema o enviar un mensaje a un chatbot como Slack. Para obtener más información, consulta Cómo configurar las acciones de AWS los presupuestos.

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 nodo ha caducado, la aplicación se interrumpirá cuando se cierre la instancia. TTL Al añadir una karpenter.sh/do-not-disrupt anotación al pod, le estás dando instrucciones a Karpenter para 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 todo lo que no sea de recursos cuando utilice la consolidación CPU

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 ellos 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 subyacente y la memoria de un contenedor no están CPU limitados. 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 trabajador 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 principales DNS

Actualice la configuración de Core DNS para mantener la confiabilidad

Al implementar DNS módulos Core en nodos gestionados por Karpenter, dada la naturaleza dinámica de Karpenter, que consiste en cerrar o crear nuevos nodos rápidamente para adaptarse a la demanda, se recomienda seguir las siguientes prácticas recomendadas:

La DNS duración del núcleo es aburrida

Sonda de preparación básica DNS

Esto garantizará que DNS las consultas no se dirijan a un Core DNS Pod que aún no esté listo o que se haya cerrado.

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 para crear un EKS clúster con Karpenter configurado y probar cada uno de los planos incluidos en el repositorio. Puedes combinar diferentes planos para crear finalmente el que necesites para tus cargas de trabajo.

Recursos adicionales

📝 Edite esta página en GitHub