Ayude a mejorar esta página
¿Quiere contribuir a esta guía del usuario? Desplácese hasta el final de esta página y seleccione Editar esta página en GitHub. Sus contribuciones ayudarán a que nuestra guía del usuario sea mejor para todos.
Migración de aplicaciones 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.187.0
o posterior deeksctl
. Puede verificar la versión con el siguiente comando:eksctl version
Para obtener instrucciones sobre cómo instalar o actualizar
eksctl
, consulte Instalaciónen la documentación de eksctl
.nota
Este procedimiento solo funciona para los clústeres y grupos de nodos que se crearon con
eksctl
.-
Recupere el nombre de los grupos de nodos existentes al sustituir
por el nombre del clúster.my-cluster
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
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.example value
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
\ --version1.30
\ --namestandard-nodes-new
\ --node-typet3.medium
\ --nodes3
\ --nodes-min1
\ --nodes-max4
\ --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
con los nombres del clúster y grupo de nodos:example value
eksctl delete nodegroup --cluster
my-cluster
--namestandard-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
-
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.
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 Escalador automático de clústeres
de Kubernetes, por ejemplo. -
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.
-
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 ynewNodes
es el nombre de la pila a la que migrará. Reemplace cada
con valores propios.example value
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) -
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
-
-
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.), reemplacearn:aws:
conarn: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:nodesSustituya el fragmento
con el valor de NodeInstanceRole que registró en un paso anterior. A continuación, guarde y cierre el archivo para aplicar el configmap actualizado.ARN of instance role (not instance profile)
-
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 de clústeres
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 toleracionesen la documentación de Kubernetes. kubectl taint nodes
node_name
key=value:NoScheduleSi 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
porcoredns
si el resultado del comando anterior ha devuelto ese valor.kubedns
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-dataSi 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
) con el siguiente fragmento de código.1.28
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.
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 de clústeres de Kubernetes
, desconecte esas políticas adicionales del rol antes de eliminar la pila de AWS CloudFormation. -
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 ynewNodes
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 Abra la consola de AWS CloudFormation en https://console.aws.amazon.com/cloudformation
. -
Seleccione la pila de nodos antigua.
-
Elija Eliminar.
-
En el cuadro de diálogo de confirmación Eliminar pila, elija Eliminar pila.
-
-
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.), reemplacearn:aws:
conarn: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.
-
(Opcional) Si utiliza el Escalador automático de clústeres
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/
) y actualizar el comando de implementación del Escalador automático de clústeres 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 AWSmy-cluster
. 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 Trabajar con el complemento Amazon VPC CNI plugin for Kubernetes de Amazon EKS. -
Si el clúster utiliza
kube-dns
para la resolución DNS (consulte el paso anterior), escale la implementación dekube-dns
a una réplica.kubectl scale deployments/kube-dns --replicas=1 -n kube-system
-