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 diseñado para mejorar la administració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 y una optimización de costes eficientes. Sus funciones principales son:

Con Karpenter, puedes definir NodePools las restricciones en el aprovisionamiento de nodos, como las manchas, las etiquetas, los requisitos (tipos de instancias, zonas, etc.) y los límites del total de recursos aprovisionados. Al implementar cargas de trabajo, puedes especificar varias restricciones de programación en las especificaciones del pod, como los recursos, los selectores de nodos requests/limits, las node/pod afinidades, las tolerancias y las restricciones de dispersió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 confiaban principalmente en los grupos de Auto Scaling de Amazon EC2 y en el escalador automático de clústeres (CAS) de Kubernetes para ajustar de forma dinámica la capacidad informática 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 las API de AWS y de Kubernetes.

Karpenter consolida las responsabilidades de orquestació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 presenta 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 el propio Karpenter y sobre la programación de pods NodePools.

Mejores prácticas de Karpenter

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

Bloquee las AMI en los clústeres de producción

Le recomendamos encarecidamente que fije las imágenes de máquina de Amazon (AMI) conocidas que utiliza Karpenter para los clústeres de producción. Si se utiliza amiSelector un alias establecido en@latest, o si se utiliza algún otro método que dé lugar a la implementación de AMI no probadas a medida que se publican, se corre el riesgo de que se produzcan errores en la carga de trabajo y se produzcan tiempos de inactividad en los clústeres de producción. Por lo tanto, recomendamos encarecidamente fijar las versiones funcionales y probadas de las AMI a los clústeres de producción mientras pruebas las versiones más nuevas en los clústeres que no son de producción. Por ejemplo, puedes establecer un alias en tu de la NodeClass siguiente manera:

amiSelectorTerms
  - alias: al2023@v20240807

Para obtener información sobre la administración y la fijación de las AMI en Karpenter, consulte Administración de las AMI en la documentación de Karpenter.

Utilice Karpenter para cargas de trabajo con necesidades de capacidad cambiantes

Karpenter acerca la gestión de la escalabilidad a las API nativas de Kubernetes que a los grupos de ajuste de escala automático (ASG) y los grupos de nodos gestionados (MNG). https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html Los ASG y los MNG son AWS-native abstracciones en las que el escalado se activa en función de las métricas a nivel de AWS, como la carga de la CPU de EC2. Cluster Autoscaler une las abstracciones de Kubernetes con las abstracciones de AWS, pero por ello pierde cierta flexibilidad, como 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 usa mejor para clústeres con cargas de trabajo que se enfrentan a períodos de alta y alta demanda o que tienen diversos requisitos de procesamiento. Los MNG y los ASG son buenos para los clústeres que ejecutan cargas de trabajo que tienden a ser más estáticas y consistentes. Puede usar una combinación de nodos administrados de forma dinámica y estática, según sus requisitos.

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

Necesitas funciones que aún se estén desarrollando en Karpenter. Como Karpenter es un proyecto relativamente nuevo, considera otros proyectos de escalado automático por el momento si necesitas 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. https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#4-install-karpenter El diagrama de Helm instala el controlador Karpenter y un pod de webhooks como una implementación que debe ejecutarse antes de poder usar el controlador para escalar el clúster. Recomendamos un mínimo de un grupo de nodos pequeño con al menos un nodo de trabajo. Como alternativa, puede ejecutar estos pods en EKS Fargate creando un perfil de Fargate para el karpenter espacio de nombres. Si lo hace, todos los pods desplegados en este espacio de nombres se ejecutarán en EKS Fargate. No ejecute Karpenter en un nodo administrado por Karpenter.

Karpenter no admite plantillas de lanzamiento personalizadas

No se admiten plantillas de lanzamiento personalizadas con las API de la versión 1. Puede usar datos de usuario personalizados especificando and/or directamente las AMI personalizadas en 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 grandes instancias de Graviton.

- 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 cuando utilice Spot

Karpenter admite la gestión nativa de interrupciones y puede gestionar eventos de interrupción involuntarios, como las interrupciones de instancias puntuales, los eventos de mantenimiento programados y los eventos de instancia que podrían interrumpir sus termination/stopping cargas de trabajo. Cuando Karpenter detecta este tipo de eventos en los nodos, automáticamente contamina, agota y cierra los nodos afectados con antelación para empezar a limpiar correctamente las cargas de trabajo antes de que se produzcan interrupciones. En caso de interrupciones puntuales con 2 minutos de antelación, Karpenter inicia rápidamente un nuevo nodo para poder mover los pods antes de recuperar la instancia. Para permitir la gestión de interrupciones, configure el argumento de la --interruption-queue CLI con el nombre de la cola de SQS aprovisionada para este fin. No se recomienda utilizar el controlador de interrupciones de Karpenter junto con el controlador de terminación de nodos, como se explica aquí. https://karpenter.sh/docs/faq/#interruption-handling

Los módulos que requieren puntos de control u otras formas de vaciado correcto, que requieren 2 minutos antes de apagarse, deberían permitir que Karpenter gestione las interrupciones en sus clústeres.

Clúster privado de Amazon EKS sin acceso saliente a Internet

Al aprovisionar un clúster de EKS en una VPC sin conexión a Internet, debe asegurarse de haber configurado su entorno de acuerdo con los requisitos de clústeres privados que aparecen en la documentación de EKS. Además, debe asegurarse de haber creado un punto de enlace regional de la VPC de STS en su VPC. 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 Karpenter usa las funciones de IAM para las cuentas de servicio (IRSA). Los pods configurados con IRSA adquieren credenciales llamando a la API de AWS Security Token Service (AWS STS). Si no hay acceso saliente a Internet, debe crear y usar un punto final de VPC de AWS STS en su VPC.

Los clústeres privados también requieren que cree un punto de enlace de VPC para SSM. Cuando Karpenter intenta aprovisionar un nuevo nodo, consulta las configuraciones de la plantilla de lanzamiento y un parámetro 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 estancarán con el tiempo. Karpenter soluciona esto al incluir 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 de EKS completamente privados y para saber qué puntos finales de VPC se van a 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 requisitos de sistemas operativos o de tipo de instancia diferentes, cree varios NodePools. Por ejemplo, un equipo puede querer usar Bottlerocket, mientras que otro puede querer usar Amazon Linux. Del mismo modo, un equipo puede tener acceso a un hardware de GPU caro que otro equipo no necesitaría. El uso de varios dispositivos 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 hay varias NodePools coincidencias, Karpenter elegirá al azar cuál usar, lo que generará resultados inesperados. Algunos ejemplos útiles para crear varios NodePools son los siguientes:

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

# 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"

En el caso de un despliegue general para otro equipo, la NodePool especificación podría incluir NodeAffinity. Entonces, una implementación podría usar el nodo SelectorTerms para que coincida. 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

Implementación con 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

Puedes usar temporizadores en los nodos aprovisionados para establecer cuándo eliminar los nodos que carecen de pods de carga de trabajo o que han llegado a 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 caducidad en la documentación de Karpenter para obtener información sobre cómo utilizarla spec.template.spec para configurar la caducidad de los nodos.

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

Al usar Spot, Karpenter usa la estrategia de asignación optimizada para el precio y la capacidad para aprovisionar instancias EC2. Esta estrategia indica a EC2 que aprovisione las instancias de los grupos más profundos según la cantidad de instancias que esté lanzando y con el menor riesgo de interrupción. A continuación, EC2 Fleet solicita instancias puntuales de los grupos con el precio más bajo. Cuantos más tipos de instancias permita que Karpenter utilice, mejor podrá EC2 optimizar el tiempo de ejecución de su instancia puntual. De forma predeterminada, Karpenter utilizará todos los tipos de instancias que EC2 ofrece en la región y las zonas de disponibilidad en las que esté desplegado su clúster. Karpenter elige de forma inteligente entre el conjunto de todos los tipos de instancias en función de los pods pendientes para asegurarse de que los pods estén programados para instancias equipadas y del tamaño adecuado. Por ejemplo, si tu pod no requiere una GPU, Karpenter no programará tu pod para un tipo de instancia EC2 compatible con una GPU. Si no está seguro de qué tipos de instancias usar, puede ejecutar el selector de instancias de Amazon ec2 para generar una lista de los tipos de instancias que se ajusten a sus requisitos informáticos. Por ejemplo, la CLI toma la memoria, la vCPU, la arquitectura y la región como parámetros de entrada y proporciona una lista de instancias de EC2 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 esto puede afectar a la disponibilidad de tus aplicaciones. Supongamos, por ejemplo, que se recuperan todas las instancias de un tipo determinado y no hay alternativas adecuadas disponibles para sustituirlas. Los pods permanecerán en estado pendiente hasta que se reponga la capacidad puntual de los tipos de instancias configurados. Puedes reducir el riesgo de errores de capacidad insuficiente distribuyendo tus instancias en diferentes zonas de disponibilidad, ya que los grupos de puntos son diferentes en las zonas de disponibilidad. Dicho esto, la mejor práctica general es permitir que Karpenter utilice un conjunto diverso de tipos de instancias cuando utilice Spot.

Programación de 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 lograr una alta disponibilidad

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

Usa restricciones por capas para restringir las funciones informáticas disponibles en tu proveedor de servicios en la nube

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

Crea alarmas de facturación para supervisar tu gasto informático

Cuando configures tu clúster para que escale automáticamente, debes crear alarmas de facturación que te avisen cuando tu gasto haya superado un umbral y añadir límites de recursos a tu 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 un Karpenter puede instanciar. NodePool

El siguiente fragmento 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 se supere el límite. Cuando se supera un límite, el controlador Karpenter escribirá un mensaje memory resource usage of 1001 exceeds limit of 1000 o un mensaje similar en los registros del controlador. Si estás redirigiendo los registros de tus contenedores 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 CloudWatch alarma que te avise cuando se supere el umbral de métricas configurado.

Para obtener más información sobre el uso de los 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 usas límites ni restringes los tipos de instancias que Karpenter puede aprovisionar, Karpenter seguirá añadiendo capacidad de procesamiento a tu clúster según sea necesario. Si bien configurar Karpenter de esta manera permite que tu clúster se escale libremente, también puede tener importantes implicaciones financieras. Por este motivo, recomendamos configurar las alarmas de facturación. Las alarmas de facturación le permiten recibir alertas y notificaciones proactivas cuando los cargos estimados calculados en sus cuentas superen un umbral definido. Para obtener más información, consulta Cómo configurar una alarma CloudWatch de facturación de Amazon para supervisar de forma proactiva los cargos estimados.

También puede 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 los costos y el 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 acciones 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 el karpenter. sh/doanotación -not-disrupt para evitar que Karpenter desaprovisione un nodo

Si está ejecutando una aplicación crítica en un Karpenter-provisioned nodo, como un trabajo por lotes que se está ejecutando durante mucho tiempo o una aplicación con estado, y el TTL del nodo ha caducado, la aplicación se interrumpirá cuando finalice la instancia. Al añadir una karpenter.sh/do-not-disrupt anotación al pod, le estás indicando a Karpenter que conserve el nodo hasta que el pod finalice o se elimine la anotación. karpenter.sh/do-not-disrupt Consulta la documentación de Distruption para obtener más información.

Si los únicos pods que no son daemonset que quedan en un nodo son los que están asociados a tareas, Karpenter puede seleccionar esos nodos y terminarlos 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

En general, la consolidación y la programación funcionan comparando las solicitudes de recursos de los pods con la cantidad de recursos asignables a 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 en ráfagas. Si varios pods del mismo nodo se rompen al mismo tiempo, es posible que algunos de los pods se cierren debido a una situación de falta de memoria (OOM). La consolidación puede aumentar las probabilidades de que esto ocurra, ya que se trata de empaquetar los pods en los nodos teniendo en cuenta únicamente sus solicitudes.

Se usa 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 es independiente. El programador de Kubernetes analiza el total de solicitudes de un pod (el mayor entre 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 se debe programar el pod. Del mismo modo, Karpenter considera las solicitudes de un pod para determinar qué tipo de instancia aprovisiona. Puedes usar un rango límite para aplicar un valor predeterminado razonable a un espacio de nombres, en caso de que algunos pods no especifiquen las solicitudes de recursos.

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

Aplica 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 los requisitos de sus cargas de trabajo es precisa. Esto es particularmente importante si se utiliza la función de consolidación de Karpenter.

Consulte Configurar y dimensionar los recursos Requests/Limits 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 los nodos gestionados por Karpenter, dada la naturaleza dinámica de Karpenter, que permite crear nodos con rapidez terminating/creating para adaptarse a la demanda, se recomienda seguir las siguientes prácticas recomendadas:

La duración de CoreDNS es baja

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 procesamiento del plano de datos de Kubernetes, hay situaciones de carga de trabajo comunes en las que quizás se pregunte cómo configurarlos 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 por fin el que necesita para sus cargas de trabajo.

Recursos adicionales