Migra cargas de trabajo a diferentes tipos de máquina

En este instructivo, se muestra cómo migrar las cargas de trabajo que se ejecutan en un clúster de Google Kubernetes Engine (GKE) a un nuevo conjunto de nodos dentro del mismo clúster sin incurrir en tiempo de inactividad para tu aplicación. Esta migración puede ser útil si deseas migrar tus cargas de trabajo a nodos con un tipo de máquina diferente.

Contexto

Un grupo de nodos es un subconjunto de máquinas que tienen la misma configuración, incluidos los alcances de autorización del tipo de máquina (CPU y memoria). Los grupos de nodos representan un subconjunto de nodos dentro de un clúster; un clúster del contenedor puede contener uno o más grupos de nodos.

Cuando necesites cambiar el perfil de máquina de tu clúster de Compute Engine, puedes crear un grupo de nodos y luego migrar tus cargas de trabajo al nuevo grupo de nodos.

Para migrar tus cargas de trabajo sin incurrir en tiempo de inactividad, debes hacer lo siguiente:

• Marca el grupo de nodos existente como no programable.
• Desvía las cargas de trabajo que se ejecutan en el grupo de nodos existente.
• Borra el grupo de nodos existente.

Kubernetes, que es el sistema de organización de clústeres de GKE, reprograma de manera automática los pods expulsados al nuevo grupo de nodos a medida que desvía el grupo de nodos existente.

Nota: Este instructivo solo aplica si tu contenedor no tiene ajuste de escala automático de clúster habilitado. Si el escalador automático agrega o quita nodos mientras estás intentando realizar una migración, es posible que no puedas marcar todos los nodos del grupo como no programables y desviarlos de forma correcta.

Objetivos

• Crear un clúster de GKE.
• Implementar la aplicación web de muestra en el clúster
• Crear un grupo de nodos nuevo
• Migrar pods al grupo de nodos nuevo sin generar tiempo de inactividad

Antes de comenzar

Sigue los pasos que se indican a continuación para habilitar la API de Kubernetes Engine:

1. Consulta la página de Kubernetes Engine en Google Cloud Console.
2. Crea o selecciona un proyecto.
3. Espera a que la API y los servicios relacionados se habiliten. Esto puede tardar varios minutos.

4. Asegúrate de que la facturación esté habilitada para tu proyecto de Cloud. Descubre cómo confirmar que tienes habilitada la facturación en un proyecto.

Instala las siguientes herramientas de línea de comandos de este instructivo:

• gcloud se usa para crear y borrar clústeres de Kubernetes Engine. gcloud se incluye en el SDK de Google Cloud.
• kubectl se usa para administrar Kubernetes, el sistema de organización de clústeres que emplea Kubernetes Engine. Puedes instalar kubectl con gcloud:

  gcloud components install kubectl

Clona el código de ejemplo desde GitHub:

git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
cd kubernetes-engine-samples/migrating-node-pool

Establece valores predeterminados para la herramienta de línea de comandos de gcloud

Para ahorrar tiempo cuando escribes las opciones del ID del proyecto y la zona de Compute Engine en la herramienta de línea de comandos de gcloud, puedes establecer valores predeterminados:

gcloud config set project project-id
gcloud config set compute/zone compute-zone

Crea un clúster de GKE

El primer paso es crear un clúster del contenedor para ejecutar las cargas de trabajo de la aplicación. Con el siguiente comando, se crea un clúster nuevo con cinco nodos con el tipo de máquina predeterminado (e2-medium):

gcloud container clusters create migration-tutorial --num-nodes=5

Nota: Si usas un clúster de Google Kubernetes Engine existente o si creaste uno a través de Google Cloud Console, debes ejecutar el siguiente comando para recuperar sus credenciales y configurar la herramienta de línea de comandos de kubectl con ellas:

gcloud container clusters get-credentials migration-tutorial

Si ya creaste un clúster con el comando gcloud container clusters create que se mostró antes, este paso no es necesario.

Ejecuta una implementación de una aplicación replicada

En el siguiente manifiesto, se describe un Deployment de seis réplicas de la imagen de contenedor de la aplicación web de muestra:

migrating-node-pool/node-pools-deployment.yaml

Ver en GitHub

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 6
  selector:
    matchLabels:
      app: hello-app
  template:
    metadata:
      labels:
        app: hello-app
    spec:
      containers:
      - name: hello-app
        image: gcr.io/google-samples/hello-app:1.0

Para implementar este manifiesto, ejecuta lo siguiente:

kubectl apply -f node-pools-deployment.yaml

Puedes recuperar la lista de los pods iniciados si ejecutas lo siguiente:

kubectl get pods

Salida:

NAME                   READY     STATUS    RESTARTS   AGE
web-2212180648-80q72   1/1       Running   0          10m
web-2212180648-jwj0j   1/1       Running   0          10m
web-2212180648-pf67q   1/1       Running   0          10m
web-2212180648-pqz73   1/1       Running   0          10m
web-2212180648-rrd3b   1/1       Running   0          10m
web-2212180648-v3b18   1/1       Running   0          10m

Crea un grupo de nodos con un tipo de máquina grande

De forma predeterminada, GKE crea un grupo de nodos llamado default-pool para cada nuevo clúster:

gcloud container node-pools list --cluster migration-tutorial

Salida:

NAME          MACHINE_TYPE   DISK_SIZE_GB  NODE_VERSION
default-pool  e2-medium      100           1.16.13-gke.401

Para ingresar instancias con una configuración diferente, como un tipo de máquina diferente o permisos de autenticación diferentes, necesitas crear un grupo de nodos nuevo.

Con el siguiente comando, se crea un nuevo grupo de nodos llamado larger-pool con cinco instancias de memoria alta del tipo de máquina e2-highmem-2:

gcloud container node-pools create larger-pool \
  --cluster=migration-tutorial \
  --machine-type=e2-highmem-2 \
  --num-nodes=5

Tu clúster del contenedor ahora debería tener dos grupos de nodos:

gcloud container node-pools list --cluster migration-tutorial

Resultado:

NAME          MACHINE_TYPE   DISK_SIZE_GB  NODE_VERSION
default-pool  e2-medium      100           v1.16.13-gke.401
larger-pool   e2-highmem-2   100           v1.16.13-gke.401

Puedes ver las instancias del nuevo grupo de nodos agregado a tu clúster de GKE:

kubectl get nodes

Salida:

NAME                                                STATUS    AGE       VERSION
gke-migration-tutorial-default-pool-56e3af9a-059q   Ready     40m       v1.16.13-gke.401
gke-migration-tutorial-default-pool-56e3af9a-0ng4   Ready     40m       v1.16.13-gke.401
gke-migration-tutorial-default-pool-56e3af9a-k6jm   Ready     40m       v1.16.13-gke.401
gke-migration-tutorial-default-pool-56e3af9a-lkrv   Ready     40m       v1.16.13-gke.401
gke-migration-tutorial-default-pool-56e3af9a-p9j4   Ready     40m       v1.16.13-gke.401
gke-migration-tutorial-larger-pool-b8ec62a6-2rhk    Ready     4m        v1.16.13-gke.401
gke-migration-tutorial-larger-pool-b8ec62a6-4bb2    Ready     4m        v1.16.13-gke.401
gke-migration-tutorial-larger-pool-b8ec62a6-7fl0    Ready     4m        v1.16.13-gke.401
gke-migration-tutorial-larger-pool-b8ec62a6-cx9q    Ready     4m        v1.16.13-gke.401
gke-migration-tutorial-larger-pool-b8ec62a6-hs6p    Ready     4m        v1.16.13-gke.401

Migra las cargas de trabajo

Después de crear un nuevo grupo de nodos, tus cargas de trabajo todavía seguirán en ejecución en default-pool. Kubernetes no reprograma los pods mientras estén activos y disponibles.

Ejecuta el siguiente comando para ver en qué nodo se están ejecutando los pods (consulta la columna NODE):

kubectl get pods -o=wide

Salida:

NAME                          READY     STATUS    IP         NODE
web-2212180648-80q72          1/1       Running   10.8.3.4   gke-migration-tutorial-default-pool-56e3af9a-k6jm
web-2212180648-jwj0j          1/1       Running   10.8.2.5   gke-migration-tutorial-default-pool-56e3af9a-0ng4
web-2212180648-pf67q          1/1       Running   10.8.4.4   gke-migration-tutorial-default-pool-56e3af9a-lkrv
web-2212180648-pqz73          1/1       Running   10.8.2.6   gke-migration-tutorial-default-pool-56e3af9a-0ng4
web-2212180648-rrd3b          1/1       Running   10.8.4.3   gke-migration-tutorial-default-pool-56e3af9a-lkrv
web-2212180648-v3b18          1/1       Running   10.8.1.4   gke-migration-tutorial-default-pool-56e3af9a-p9j4

Para migrar estos pods al nuevo grupo de nodos, debes realizar los siguientes pasos:

1. Acordona el grupo de nodos existente: esta operación marca los nodos en el grupo de nodos existente (default-pool) como no programables. Kubernetes deja de programar los pods nuevos en estos nodos una vez que los marcas como no programables.

2. Desvía el grupo de nodos existente: esta operación expulsa las cargas de trabajo que se ejecutan en los nodos del grupo de nodos existente (default-pool) con facilidad.

Si sigues los pasos anteriores, harás que los pods que se ejecutan en tu grupo de nodos existentes se finalicen de forma correcta y Kubernetes los reprograme en otros nodos disponibles. En este caso, los únicos nodos disponibles están en el grupo de nodos larger-pool.

Nota: Si tu carga de trabajo tiene un servicio LoadBalancer con externalTrafficPolicy establecido en Local, acordonar el grupo de nodos existente puede provocar que no se pueda acceder a la carga de trabajo. Cambia externalTrafficPolicy a Cluster o asegúrate de que la carga de trabajo se vuelva a implementar en el grupo de nodos nuevo antes de acordonar el grupo existente.

A fin de asegurarte de que Kubernetes finalice tus aplicaciones con éxito, tus contenedores deben manipular la señal SIGTERM. Esto se puede usar para cerrar conexiones activas con los clientes y confirmar o anular las transacciones de la base de datos de una manera limpia. En el manifiesto de tu pod, puedes usar el campo spec.terminationGracePeriodSeconds para especificar cuánto debe esperar Kubernetes antes de detener los contenedores en el pod. Esto se encuentra predeterminado a 30 segundos. Puedes leer más sobre la finalización de pods en la documentación de Kubernetes.

Primero, acordona los nodos en el default-pool. Puedes ejecutar el siguiente comando para obtener una lista de nodos en este grupo de nodos:

kubectl get nodes -l cloud.google.com/gke-nodepool=default-pool

Luego, acordona cada nodo mediante la ejecución de un comando kubectl cordon NODE (sustituye NODE por los nombres del comando anterior). El siguiente comando itera sobre cada nodo y los marca como no programados:

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=default-pool -o=name); do
  kubectl cordon "$node";
done

Salida:

node "gke-migration-tutorial-default-pool-56e3af9a-059q" cordoned
node "gke-migration-tutorial-default-pool-56e3af9a-0ng4" cordoned
node "gke-migration-tutorial-default-pool-56e3af9a-k6jm" cordoned
node "gke-migration-tutorial-default-pool-56e3af9a-lkrv" cordoned
node "gke-migration-tutorial-default-pool-56e3af9a-p9j4" cordoned

Precaución: kubectl cordon marca un nodo como “no programable”, que tiene el efecto secundario en el que el controlador de servicios quita el nodo de cualquier lista de destino de nodo de LoadBalancer para el cual era apto antes. De este modo, quita de manera efectiva el tráfico del balanceador de cargas entrante de los nodos conectados. Esto se aplica a las versiones 1.18 y anteriores de GKE.

Ahora deberías ver que los nodos default-pool tienen el estado SchedulingDisabled en la lista de nodos:

kubectl get nodes

Resultado:

NAME                                                STATUS                     AGE       VERSION
gke-migration-tutorial-default-pool-56e3af9a-059q   Ready,SchedulingDisabled   1h        v1.16.13-gke.401
gke-migration-tutorial-default-pool-56e3af9a-0ng4   Ready,SchedulingDisabled   1h        v1.16.13-gke.401
gke-migration-tutorial-default-pool-56e3af9a-k6jm   Ready,SchedulingDisabled   1h        v1.16.13-gke.401
gke-migration-tutorial-default-pool-56e3af9a-lkrv   Ready,SchedulingDisabled   1h        v1.16.13-gke.401
gke-migration-tutorial-default-pool-56e3af9a-p9j4   Ready,SchedulingDisabled   1h        v1.16.13-gke.401
gke-migration-tutorial-larger-pool-b8ec62a6-2rhk    Ready                      1h        v1.16.13-gke.401
gke-migration-tutorial-larger-pool-b8ec62a6-4bb2    Ready                      1h        v1.16.13-gke.401
gke-migration-tutorial-larger-pool-b8ec62a6-7fl0    Ready                      1h        v1.16.13-gke.401
gke-migration-tutorial-larger-pool-b8ec62a6-cx9q    Ready                      1h        v1.16.13-gke.401
gke-migration-tutorial-larger-pool-b8ec62a6-hs6p    Ready                      1h        v1.16.13-gke.401

A continuación, desvía los pods en cada nodo con éxito. Para realizar el desvío, usa el comando kubectl drain que expulsa pods en cada nodo.

Nota: Kubernetes no reprograma los pods que no administra un controlador, como una implementación, ReplicationController, ReplicaSet, Job, DaemonSet o StatefulSet. Estos pods evitan que se ejecuten los comandos kubectl drain; por lo tanto, debes implementar tus pods con estos controladores. En este instructivo, ejecuta kubectl drain con la opción --force para limpiar algunos pods del sistema de GKE como kube-proxy y fluend-cloud-logging.

Puedes ejecutar kubectl drain --force NODE si sustituyes NODE por la misma lista de nombres pasados al comando kubectl cordon.

El siguiente comando de shell itera todos los nodos en default-pool y los desvía; para eso, desaloja los pods con un período de finalización con éxito asignado de 10 segundos:

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=default-pool -o=name); do
  kubectl drain --force --ignore-daemonsets --delete-local-data --grace-period=10 "$node";
done

Una vez que se complete este comando, deberías ver que los pods se están ejecutando en los nodos larger-pool:

kubectl get pods -o=wide

Salida:

NAME                   READY     STATUS    IP         NODE
web-2212180648-3n9hz   1/1       Running   10.8.9.4   gke-migration-tutorial-larger-pool-b8ec62a6-cx9q
web-2212180648-88q1c   1/1       Running   10.8.7.4   gke-migration-tutorial-larger-pool-b8ec62a6-2rhk
web-2212180648-dlmjc   1/1       Running   10.8.9.3   gke-migration-tutorial-larger-pool-b8ec62a6-cx9q
web-2212180648-hcv46   1/1       Running   10.8.5.4   gke-migration-tutorial-larger-pool-b8ec62a6-hs6p
web-2212180648-n0nht   1/1       Running   10.8.6.4   gke-migration-tutorial-larger-pool-b8ec62a6-7fl0
web-2212180648-s51jb   1/1       Running   10.8.8.4   gke-migration-tutorial-larger-pool-b8ec62a6-4bb2

Borra el grupo de nodos anterior

Una vez que Kubernetes reprogramó todos los pods en la implementación web en larger-pool, es seguro borrar default-pool dado que ya no es necesario. Ejecuta el siguiente comando para borrar default-pool:

gcloud container node-pools delete default-pool --cluster migration-tutorial

Una vez que se complete esta operación, debes tener un solo grupo de nodos para tu clúster del contenedor, que es el larger-pool:

gcloud container node-pools list --cluster migration-tutorial

Resultado:

NAME          MACHINE_TYPE   DISK_SIZE_GB  NODE_VERSION
larger-pool   e2-highmem-2   100           1.16.13-gke.401

Realice una limpieza

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

• Borra el clúster del contenedor: En este paso, se borran los recursos que conforman el clúster del contenedor, como las instancias de procesamiento, los discos y los recursos de red.

  gcloud container clusters delete migration-tutorial

¿Qué sigue?

• Explora otros instructivos de Kubernetes Engine.

• Prueba otras funciones de Google Cloud. Consulta nuestros instructivos.