Migración de aplicaciones a un nuevo grupo de nodos

Recupere el nombre de los grupos de nodos existentes al sustituir mi clúster 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

Lance un nuevo grupo de nodos con eksctl mediante el siguiente comando. En el comando, sustituya cada valor de ejemplo por sus 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:

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

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

kubectl get nodes

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

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

Lance un nuevo grupo de nodos mediante los pasos que se indican en Creación de nodos autoadministrados de Amazon Linux.

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

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

Actualice los grupos de seguridad de ambos grupos de nodos para que puedan comunicarse entre sí. Para obtener más información, consulte Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres.

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.

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) por el valor de NodeInstanceRole anotado en el procedimiento anterior. A continuación, guarde y cierre el archivo para aplicar el configmap actualizado.

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

(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

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

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

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

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

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.

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.

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.

(Opcional) Si utiliza el Cluster Autoscaler de Kubernetes, vuelva a escalar la implementación a una réplica.

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

(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 Asignación de direcciones IP a Pods con CNI de Amazon VPC.

Si el clúster utiliza kube-dns para la resolución DNS (consulte [migrate-determine-dns-step]), reduzca horizontalmente la implementación de kube-dns a una réplica.

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