Migración a un nuevo grupo de nodos

En este tema, se describe cómo crear un nuevo grupo de nodos, migrar de forma correcta las aplicaciones existentes al nuevo grupo y eliminar el antiguo grupo de nodos del clúster. Puede migrar a un nuevo grupo de nodos mediante eksctl o la AWS Management Console.

eksctl

Para migrar sus aplicaciones a un nuevo grupo de nodos con eksctl

Para obtener más información sobre el uso de eksctl para la migración, consulte Nodos no administrados en la documentación de eksctl.

En este procedimiento, se requiere la versión 0.183.0 o posterior de eksctl. Puede verificar la versión con el siguiente comando:

eksctl version

Para obtener instrucciones sobre cómo instalar o actualizar eksctl, consulte Instalación en la documentación de eksctl.

nota

Este procedimiento solo funciona para los clústeres y grupos de nodos que se crearon con eksctl.

1. Recupere el nombre de los grupos de nodos existentes al sustituir my-cluster por el nombre del clúster.

   eksctl get nodegroups --cluster=my-cluster
   

   Un ejemplo de salida sería el siguiente.

   CLUSTER      NODEGROUP          CREATED               MIN SIZE      MAX SIZE     DESIRED CAPACITY     INSTANCE TYPE     IMAGE ID
   default      standard-nodes   2019-05-01T22:26:58Z  1             4            3                    t3.medium         ami-05a71d034119ffc12

2. Lance un nuevo grupo de nodos con eksctl mediante el siguiente comando. En el comando, sustituya cada example value por valores propios. El número de versión no puede ser posterior a la versión de Kubernetes del plano de control. Además, no puede ser más de dos versiones secundarias anteriores a la versión de Kubernetes para el plano de control. Recomendamos que utilice la misma versión que el plano de control.

   Se recomienda bloquear el acceso del Pod al IMDS si se cumplen las siguientes condiciones:

   • Tiene previsto asignar roles de IAM a todas sus cuentas de servicio de Kubernetes para que los Pods solo tengan los permisos mínimos que necesitan.

   • Ninguno de los Pods del clúster requiere acceso al servicio de metadatos de la instancia de Amazon EC2 (IMDS) por otros motivos, como la recuperación de la Región de AWS actual.

   Para obtener más información, consulte Restringir el acceso al perfil de instancias asignado al nodo de trabajo.

   Si desea bloquear el acceso del Pod a IMDS, agregue la opción --disable-pod-imds al siguiente comando.

   nota

   Para obtener más marcadores disponibles y sus descripciones, consulte https://eksctl.io/.

   eksctl create nodegroup \
     --cluster my-cluster \
     --version 1.30 \
     --name standard-nodes-new \
     --node-type t3.medium \
     --nodes 3 \
     --nodes-min 1 \
     --nodes-max 4 \
     --managed=false
   

3. Cuando se complete el comando anterior, verifique con el siguiente comando que todos los nodos tengan el estado Ready (Listo):

   kubectl get nodes
   

4. Elimine el grupo de nodos original con el siguiente comando. En el comando, sustituya cada example value con los nombres del clúster y grupo de nodos:

   eksctl delete nodegroup --cluster my-cluster --name standard-nodes-old
   

AWS Management Console and AWS CLI

Para migrar sus aplicaciones a un nuevo grupo de nodos con la AWS Management Console y la AWS CLI

1. Lance un nuevo grupo de nodos mediante los pasos que se indican en Lanzar nodos autoadministrados de Amazon Linux.

2. Una vez completada la creación de la pila, selecciónela en la consola y elija Salidas.

3. Anote el valor de NodeInstanceRoles correspondiente al grupo de nodos creado. Lo necesita para agregar los nuevos nodos de Amazon EKS al clúster.

   nota

   Si ha adjuntado políticas de IAM adicionales al rol de IAM del grupo de nodos anterior, debe adjuntar esas mismas políticas al rol de IAM del nuevo grupo de nodos para mantener esa funcionalidad en el nuevo grupo. Esto se aplica si ha agregado permisos para el Autoescalador del clúster de Kubernetes, por ejemplo.

4. Actualice los grupos de seguridad de ambos grupos de nodos para que puedan comunicarse entre sí. Para obtener más información, consulte Requisitos y consideraciones sobre grupos de seguridad de Amazon EKS.

   1. Anote los ID de grupo de seguridad de ambos grupos de nodos. Esto se muestra como el valor NodeSecurityGroup en los resultados de la pila de AWS CloudFormation.

      Puede utilizar los siguientes comandos de la AWS CLI para obtener los ID de grupo de seguridad de los nombres de pilas. En estos comandos, oldNodes es el nombre de pila de AWS CloudFormation de la pila de nodos antigua y newNodes es el nombre de la pila a la que migrará. Reemplace cada example value con valores propios.

      oldNodes="old_node_CFN_stack_name"
      newNodes="new_node_CFN_stack_name"
      
      oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \
      --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
      --output text)
      newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \
      --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
      --output text)
      

   2. Agregue reglas de entrada a cada grupo de seguridad de nodos para que acepten tráfico de los otros grupos.

      Los siguientes comandos de la AWS CLI agregan reglas de entrada a cada grupo de seguridad que permiten todo el tráfico en todos los protocolos del otro grupo de seguridad. Esta configuración permite que los Pods de cada grupo de nodos se comuniquen entre ellos mientras migra la carga de trabajo al nuevo grupo.

      aws ec2 authorize-security-group-ingress --group-id $oldSecGroup \
      --source-group $newSecGroup --protocol -1
      aws ec2 authorize-security-group-ingress --group-id $newSecGroup \
      --source-group $oldSecGroup --protocol -1
      

5. Edite el mapa de configuración de aws-auth para asignar el rol de la instancia del nuevo nodo en RBAC.

   kubectl edit configmap -n kube-system aws-auth
   

   Agregue una nueva entrada mapRoles para el nuevo grupo de nodos. Si su clúster está en las Regiones de AWS AWS GovCloud (Este de EE. UU.) o AWS GovCloud (Oeste de EE. UU.), reemplace arn:aws: con arn:aws-us-gov:.

   apiVersion: v1
   data:
     mapRoles: |
       - rolearn: ARN of instance role (not instance profile)
         username: system:node:{{EC2PrivateDNSName}}
         groups:
           - system:bootstrappers
           - system:nodes>
       - rolearn: arn:aws:iam::111122223333:role/nodes-1-16-NodeInstanceRole-U11V27W93CX5
         username: system:node:{{EC2PrivateDNSName}}
         groups:
           - system:bootstrappers
           - system:nodes

   Sustituya el fragmento ARN of instance role (not instance profile) con el valor de NodeInstanceRole que registró en un paso anterior. A continuación, guarde y cierre el archivo para aplicar el configmap actualizado.

6. Examine el estado de los nodos y espere a que los nuevos nodos se unan al clúster y tengan el estado Ready (Listo).

   kubectl get nodes --watch
   

7. (Opcional) Si utiliza el escalador automático del clúster de Kubernetes, escale la implementación a cero (0) réplicas para evitar acciones de escalado en conflicto.

   kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system
   

8. Utilice el siguiente comando para agregar taints en cada uno de los nodos que desee eliminar con NoSchedule. Esto es para que los nuevos Pods no se programen ni se vuelvan a programar en los nodos que va a reemplazar. Para obtener más información, consulte Taints y toleraciones en la documentación de Kubernetes.

   kubectl taint nodes node_name key=value:NoSchedule
   

   Si va a actualizar los nodos a una nueva versión de Kubernetes, puede identificar y agregar taints en todos los nodos de una determinada versión de Kubernetes (en este caso 1.28) con el siguiente fragmento de código. El número de versión no puede ser posterior a la versión de Kubernetes del plano de control. Además, no puede ser más de dos versiones secundarias anteriores a la versión de Kubernetes del plano de control. Recomendamos que utilice la misma versión que el plano de control.

   K8S_VERSION=1.28
   nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}")
   for node in ${nodes[@]}
   do
       echo "Tainting $node"
       kubectl taint nodes $node key=value:NoSchedule
   done
   

9. Identifique el proveedor de DNS del clúster.

   kubectl get deployments -l k8s-app=kube-dns -n kube-system
   

   Un ejemplo de salida sería el siguiente. Este clúster utiliza CoreDNS para la resolución DNS, pero el clúster puede devolver kube-dns en su lugar:

   NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
   coredns   1         1         1            1           31m

10. Si su implementación actual está ejecutando menos de dos réplicas, escale la implementación a dos réplicas. Cambie coredns por kubedns si el resultado del comando anterior ha devuelto ese valor.

    kubectl scale deployments/coredns --replicas=2 -n kube-system
    

11. Vacíe cada uno de los nodos que desea eliminar de su clúster con el siguiente comando:

    kubectl drain node_name --ignore-daemonsets --delete-local-data
    

    Si va a actualizar los nodos a una nueva versión de Kubernetes, identifique y vacíe todos los nodos de una determinada versión de Kubernetes (en este caso 1.28) con el siguiente fragmento de código.

    K8S_VERSION=1.28
    nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}")
    for node in ${nodes[@]}
    do
        echo "Draining $node"
        kubectl drain $node --ignore-daemonsets --delete-local-data
    done
    

12. Una vez que haya terminado de vaciar los nodos antiguos, revoque las reglas de entrada del grupo de seguridad que autorizó anteriormente. A continuación, elimine la pila de AWS CloudFormation para terminar las instancias.

    nota

    Si ha adjuntado políticas de IAM adicionales al rol de IAM del grupo de nodos anterior, como agregar permisos para el escalador automático del clúster de Kubernetes, desconecte esas políticas adicionales del rol antes de eliminar la pila de AWS CloudFormation.

    1. Revoque las reglas de entrada que creó anteriormente para los grupos de seguridad de nodos. En estos comandos, oldNodes es el nombre de pila de AWS CloudFormation de la pila de nodos antigua y newNodes es el nombre de la pila a la que migrará.

       oldNodes="old_node_CFN_stack_name"
       newNodes="new_node_CFN_stack_name"
       
       oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \
       --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
       --output text)
       newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \
       --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
       --output text)
       aws ec2 revoke-security-group-ingress --group-id $oldSecGroup \
       --source-group $newSecGroup --protocol -1
       aws ec2 revoke-security-group-ingress --group-id $newSecGroup \
       --source-group $oldSecGroup --protocol -1
       

    2. Abra la consola de AWS CloudFormation en https://console.aws.amazon.com/cloudformation.

    3. Seleccione la pila de nodos antigua.

    4. Elija Eliminar.

    5. En el cuadro de diálogo de confirmación Eliminar pila, elija Eliminar pila.

13. Edite el mapa de configuración de aws-auth para eliminar el rol de la instancia del nodo anterior de RBAC.

    kubectl edit configmap -n kube-system aws-auth
    

    Elimine la entrada mapRoles del grupo de nodos antiguo. Si su clúster está en las Regiones de AWS AWS GovCloud (Este de EE. UU.) o AWS GovCloud (Oeste de EE. UU.), reemplace arn:aws: con arn:aws-us-gov:.

    apiVersion: v1
    data:
      mapRoles: |
        - rolearn: arn:aws:iam::111122223333:role/nodes-1-16-NodeInstanceRole-W70725MZQFF8
          username: system:node:{{EC2PrivateDNSName}}
          groups:
            - system:bootstrappers
            - system:nodes
        - rolearn: arn:aws:iam::111122223333:role/nodes-1-15-NodeInstanceRole-U11V27W93CX5
          username: system:node:{{EC2PrivateDNSName}}
          groups:
            - system:bootstrappers
            - system:nodes>

    Guarde y cierre el archivo para aplicar el mapa de configuración actualizado.

14. (Opcional) Si utiliza el Autoescalador del clúster de Kubernetes, vuelva a escalar la implementación a una réplica.

    nota

    También debe etiquetar el nuevo grupo de Auto Scaling de forma correcta (por ejemplo, k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster) y actualizar el comando de implementación del escalador automático del clúster para que señale el grupo de Auto Scaling recién etiquetado. Para obtener más información, consulte Escalador automático de clústeres en AWS.

    kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system
    

15. (Opcional) Verifique que utiliza la última versión del complemento CNI de Amazon VPC para Kubernetes. Es posible que tenga que actualizar la versión de CNI para utilizar los tipos de instancia admitidos más recientes. Para obtener más información, consulte Trabajar con el complemento Amazon VPC CNI plugin for Kubernetes de Amazon EKS.

16. Si el clúster utiliza kube-dns para la resolución DNS (consulte el paso anterior), escale la implementación de kube-dns a una réplica.

    kubectl scale deployments/kube-dns --replicas=1 -n kube-system