Migración desde Karpenter al modo automático de EKS mediante kubectl

Ayude a mejorar esta página

Para contribuir a esta guía del usuario, elija el enlace Edit this page on GitHub que se encuentra en el panel derecho de cada página.

Ayude a mejorar esta página

Para contribuir a esta guía del usuario, elija el enlace Edit this page on GitHub que se encuentra en el panel derecho de cada página.

En este tema se explica el proceso para migrar cargas de trabajo de Karpenter al modo automático de Amazon EKS mediante kubectl. La migración se puede realizar de forma gradual, lo que le permite trasladar las cargas de trabajo a su propio ritmo y, al mismo tiempo, mantener la estabilidad del clúster y la disponibilidad de las aplicaciones durante la transición.

El enfoque paso a paso que se describe a continuación permite ejecutar Karpenter y el modo automático de EKS paralelamente durante el periodo de migración. Esta estrategia de doble operación ayuda a garantizar una transición fluida, ya que permite validar el comportamiento de la carga de trabajo en el modo automático de EKS antes de desmantelar completamente Karpenter. Puede migrar aplicaciones individualmente o en grupos, lo que proporciona flexibilidad para acomodar los requisitos operativos específicos y el nivel de tolerancia al riesgo.

Requisitos previos

Antes de iniciar la migración, asegúrese de que dispone de:

En este tema se presupone que ya está familiarizado con Karpenter y NodePools. Para obtener más información, consulte la documentación de Karpenter.

Paso 1: Habilitación del modo automático de EKS en el clúster

Habilite el modo automático de EKS en el clúster existente mediante AWS CLI o la Consola de administración. Para obtener más información, consulte Cómo habilitar el modo automático de EKS en un clúster existente.

Paso 2: Creación de un NodePool del modo automático de EKS con taints aplicadas

Cree un nuevo NodePool para el modo automático de EKS con una taint. Con esto se garantiza que los pods existentes no se programarán automáticamente en los nuevos nodos del modo automático de EKS. Este grupo de nodos utiliza la NodeClass default integrada en el modo automático de EKS. Para obtener más información, consulte Cómo crear una clase de nodos para Amazon EKS.

Ejemplo de grupo de nodos con taint aplicada:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: eks-auto-mode
spec:
  template:
    spec:
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m", "r"]
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      taints:
        - key: "eks-auto-mode"
          effect: "NoSchedule"

Actualice los requisitos del grupo de nodos de modo que coincidan con la configuración de Karpenter a partir de la cual se va a migrar. Necesita al menos un requisito.

Paso 3: Actualización de las cargas de trabajo para la migración

Identifique y actualice las cargas de trabajo que desea migrar al modo automático de EKS. Agregue tanto las tolerancias como los selectores de nodos a estas cargas de trabajo:

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      tolerations:
      - key: "eks-auto-mode"
        effect: "NoSchedule"
      nodeSelector:
        eks.amazonaws.com/compute-type: auto

Este cambio permite programar la carga de trabajo en los nuevos nodos del modo automático de EKS.

El modo automático de EKS utiliza etiquetas diferentes a las de Karpenter. Las etiquetas relacionadas con las instancias administradas por EC2 comienzan con eks.amazonaws.com. Para obtener más información, consulte Creación de un grupo de nodos para el modo automático de EKS.

Paso 4: Migración de las cargas de trabajo de forma gradual

Repita el paso 3 para cada carga de trabajo que desee migrar. Esto permite trasladar las cargas de trabajo de forma individual o en grupos, según los requisitos y la tolerancia al riesgo.

Paso 5: Eliminación del NodePool de Karpenter original

Una vez que se hayan migrado todas las cargas de trabajo, podrá eliminar el NodePool de Karpenter original:

kubectl delete nodepool <original-nodepool-name>

Paso 6: Eliminación de la taint del NodePool del modo automático de EKS (opcional)

Si desea que el modo automático de EKS se convierta en el modo predeterminado para las nuevas cargas de trabajo, puede eliminar la taint del NodePool del modo automático de EKS:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: eks-auto-mode
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      # Remove the taints section

Paso 7: Eliminación de los selectores de nodos de las cargas de trabajo (opcional)

Si ha eliminado la taint del NodePool del modo automático de EKS, puede optar por eliminar los selectores de nodos de las cargas de trabajo, ya que el modo automático de EKS es ahora la opción predeterminada:

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      # Remove the nodeSelector section
      tolerations:
      - key: "eks-auto-mode"
        effect: "NoSchedule"

Paso 8: Desinstalación de Karpenter del clúster

Los pasos que se deben seguir para eliminar Karpenter dependen de cómo se haya instalado. Para obtener más información, consulte las Instrucciones de instalación de Karpenter y el comando de desinstalación de Helm.