1. Descripción general
No siempre es posible o factible reescribir o rediseñar las aplicaciones existentes para que funcionen en Kubernetes de forma manual. Migrate for Anthos puede ayudarte a modernizar tus aplicaciones existentes y ejecutarlas en Kubernetes. En este codelab, migrarás una app web existente alojada en Compute Engine a Kubernetes Engine con Migrate for Anthos.
Qué aprenderás
- Cómo implementar Migrate for Anthos en un clúster de Kubernetes
- Cómo crear un contenedor en un conjunto con estado a partir de una instancia existente de Compute Engine
- Cómo implementar tu contenedor en Kubernetes y configurarlo con un balanceador de cargas
Requisitos
- Un proyecto de Google Cloud con la facturación configurada. Si no tienes una, deberás crearla.
2. Cómo prepararte
Este codelab se puede ejecutar completamente en Google Cloud Platform sin necesidad de instalación ni configuración local.
Habilita las APIs
Antes de comenzar, asegúrate de habilitar las APIs necesarias en tu proyecto de Google Cloud:
Crea un servidor web de instancia de Compute
Creemos una instancia de procesamiento que usaremos para alojar nuestro servidor web nginx inicial, junto con las reglas de firewall que nos permitirán ver la página de destino predeterminada del servidor web. Existen varias formas de hacerlo, pero, para mayor facilidad de uso, usaremos Cloud Shell.
Ejecute los siguientes comandos en Cloud Shell:
gcloud compute instances create webserver --zone=us-central1-a && \ gcloud compute firewall-rules create default-allow-http --allow=tcp:80
La primera mitad de este comando creará una instancia de Google Cloud en la zona us-central1-a, mientras que la segunda mitad creará una regla de firewall llamada "default-allow-http" que permitirá el tráfico HTTP en nuestra red.
Cuando la instancia se cree correctamente, se mostrará una tabla con sus detalles. Toma nota de la IP externa, ya que la necesitaremos más adelante para verificar que nuestro servidor web se esté ejecutando.
Una vez que la instancia esté en funcionamiento, podemos establecer una conexión SSH a ella desde Cloud Shell para instalar NGINX y, luego, iniciar el servidor web:
gcloud compute ssh --zone us-central1-a webserver
Una vez que hayas accedido a nuestra instancia de procesamiento, instala nginx:
sudo apt install nginx
Sal de la sesión SSH con el comando logout.
Verifiquemos que nuestro servidor web se esté ejecutando. Para ello, ingresa la IP externa de la instancia que obtuviste antes en tu navegador. Deberías ver la pantalla de bienvenida predeterminada de nginx:
Este servidor web actuará como la app web heredada que migraremos a Kubernetes con Migrate for Anthos.
3. Clúster de Kubernetes con Migrate for Anthos
A continuación, crearemos un clúster de GKE, que es donde, en última instancia, migraremos el servidor web de Compute Engine. En la consola de Cloud, ejecuta lo siguiente:
gcloud container clusters create my-gke-cluster \ --zone us-central1-a \ --cluster-version 1.13 \ --machine-type n1-standard-4 \ --image-type "UBUNTU" \ --num-nodes 1 \ --enable-stackdriver-kubernetes
Espera unos minutos para que se complete este comando. Una vez que se cree el clúster, recibirás un resultado con sus detalles:
A continuación, navega a GCP Marketplace para implementar Migrate for Anthos:
En la página de Marketplace de Migrate for Anthos, haz clic en Configurar y, si se te solicita, selecciona tu proyecto de la lista. En la página siguiente, se mostrará un formulario con algunos valores predeterminados ingresados. Asegúrate de que el clúster seleccionado sea el que acabamos de crear y haz clic en Implementar:
Migrate for Anthos ahora debería estar implementado en nuestro clúster de Kubernetes. Cuando finalice la implementación, verás el estado "OK" en la página de aplicaciones de Kubernetes Engine:
4. De la instancia de procesamiento al conjunto con estado
Tenemos un clúster de Kubernetes que ejecuta Migrate for Anthos, por lo que ahora podemos comenzar el proceso de migración. Para implementar nuestra instancia de procesamiento en un clúster de Kubernetes, apagaremos nuestra instancia de Compute Engine para poder tomar instantáneas de los discos. Antes de continuar, toma nota del ID de la instancia, que necesitaremos más adelante:
gcloud compute instances describe webserver --zone us-central1-a | grep ^id
Cerraremos nuestra instancia de procesamiento:
gcloud compute instances stop webserver --zone us-central1-a
Ahora que la instancia está detenida, podemos crear instantáneas de los discos de forma segura ejecutando la siguiente secuencia de comandos. Asegúrate de insertar tu ID del proyecto y tu ID de instancia:
python3 /google/migrate/anthos/gce-to-gke/clone_vm_disks.py \ -p <project-id> -i <instance-id> \ -z us-central1-a \ -T us-central1-a \ -A webserver-statefulset \ -o containerized-webserver.yaml
Con esas marcas, clone_vm_disks.py hará lo siguiente:
- Verifica que tu instancia de GCE esté apagada
- Crea una instantánea de cada uno de los discos de tu instancia
- Crea un disco nuevo a partir de cada instantánea
- Borra las instantáneas que creó.
- Genera un archivo YAML en tu directorio de trabajo actual para implementar un conjunto con estado que alojará tu servidor web.
El archivo YAML generado aprovisionará un conjunto con estado en nuestro clúster de Kubernetes, junto con las reclamaciones de volumen persistente necesarias para montar los discos copiados en nuestro contenedor de servidor web. Podemos aplicar estos cambios con kubectl:
kubectl apply -f containerized-webserver.yaml
Verifica el estado del conjunto de réplicas con estado del servidor web en la página Workloads:
Es normal que el estado indique "Los Pods están pendientes" durante unos minutos después de ejecutar kubectl apply. Continúa cuando el estado indique "OK".
5. Expón el clúster al balanceador de cargas
En este punto, nuestro clúster de Kubernetes debería ejecutar nuestro servidor web como un conjunto con estado, pero también tendremos que exponer su contenedor a un balanceador de cargas para acceder a nuestro servidor web a través de una dirección IP externa. En Cloud Shell, crea un archivo nuevo llamado loadbalancer.yaml con el siguiente contenido:
loadbalancer.yaml
apiVersion: v1
kind: Service
metadata:
name: webserver-loadbalancer
spec:
type: LoadBalancer
selector:
app: webserver-statefulset
ports:
- protocol: TCP
port: 80
targetPort: 80
Ahora, aplícalo con kubectl:
kubectl apply -f loadbalancer.yaml
Podemos usar kubectl para recuperar la dirección IP externa del servicio webserver-container:
kubectl get services
Si ingresamos la dirección IP externa en nuestro navegador, deberíamos obtener la misma pantalla de bienvenida predeterminada de nginx que antes:
¡Lo logramos! Nuestro servidor web de GCE ahora está alojado en Kubernetes. ¡Genial!
6. Stackdriver Monitoring
Métricas
Como servicio administrado de Kubernetes, Kubernetes Engine se instrumenta automáticamente para el registro y la supervisión con Stackdriver. Veamos algunas de las métricas que Stackdriver captura automáticamente.
Haz clic en el vínculo de Monitoring en el menú de productos. Si es la primera vez que accedes a él desde tu proyecto, es posible que tarde unos minutos en configurar tu lugar de trabajo.
Una vez cargado, coloca el cursor sobre Recursos en el panel izquierdo y selecciona "Kubernetes Engine NEW" en el menú.
Cada fila del panel que se muestra aquí representa un recurso de Kubernetes. Puedes alternar entre la vista de infraestructura, cargas de trabajo o servicios con los vínculos que se encuentran arriba del panel.
En la vista Cargas de trabajo, expande “my-gke-cluster” y explora default > webserver-statefulset > webserver-statefulset-0 > webserver-statefulset. Haz clic en el contenedor del conjunto con estado del servidor web. Aquí encontrarás algunas métricas listas para usar que Stackdriver captura, incluido el uso de memoria y el uso de CPU.
Los gráficos que se muestran en este panel son los que podremos usar para crear un panel personalizado.
Paneles personalizados
Stackdriver nos permite crear paneles personalizados que podemos usar para organizar gráficos de cualquier dato de métrica disponible. Creemos un panel personalizado para proporcionar una vista rápida de algunas de las métricas de nuestro servidor web.
En el panel lateral izquierdo, coloca el cursor sobre Paneles y, luego, haz clic en Crear panel.
Ahora que tenemos nuestro panel vacío, podemos agregar las métricas que queremos supervisar. Asignemos a nuestro panel sin título un nombre útil, como "Mis contenedores de servidores web", y hagamos clic en "Agregar gráfico" en la parte superior derecha:
¿Recuerdas las métricas listas para usar? Agreguemos un gráfico para el uso de CPU del contenedor. En el campo Título del gráfico, ingresa "Utilización de la CPU". En el cuadro "Buscar tipo de recurso y métrica", escribe request_utilization y selecciona Utilización de solicitud de CPU en la lista filtrada. Esta selección completará los campos Tipo de recurso y Métrica.
A continuación, querrás filtrar por project_id (si tienes varios proyectos) y container_name. En el cuadro Filtro, escribe project_id, selecciónalo en la lista filtrada y elige tu proyecto en el campo Valor. También debemos filtrar por container_name. En el cuadro Filtro, escribe container_name, selecciónalo en la lista filtrada y selecciona webserver-statefulset en el campo Valor. Haz clic en Guardar.
Ahora tenemos un panel con nuestro primer gráfico.
7. Política de alertas y verificaciones de tiempo de actividad
Con Stackdriver, podemos configurar alertas para que nos notifiquen cuando alguna métrica alcance los valores de umbral que especifiquemos. Por ejemplo, podemos hacer que Stackdriver nos envíe un correo electrónico cuando el uso de CPU del último paso supere un umbral determinado durante un período prolongado, lo que podría indicar un problema con nuestra app. Para demostrar cómo se ven estas alertas, configuremos una verificación de tiempo de actividad y, luego, simulemos una interrupción.
En el panel izquierdo, selecciona Verificaciones de tiempo de actividad y, luego, Descripción general de las verificaciones de tiempo de actividad:
Como sugiere la página Verificaciones de tiempo de actividad, configuremos nuestra primera verificación de tiempo de actividad. Haz clic en el botón Agregar verificación de tiempo de actividad en la parte superior derecha de la página.
En el formulario siguiente, ingresa "Tiempo de actividad del extremo" como el título y la dirección IP externa de tu balanceador de cargas como el nombre de host.
Haz clic en Guardar y se te pedirá que crees una Política de alertas complementaria:
Haz clic en Crear política de alertas.
Asignémosle el nombre "Política de tiempo de actividad del extremo". En la sección Configuración, establece “La condición se activa si” en “Alguna serie temporal es una infracción” y haz clic en Guardar.
Aún no terminamos. A continuación, especificaremos un canal de notificaciones para que se nos notifique cuando se incumpla nuestra política de alertas. En el menú desplegable Tipo de canal de notificación, selecciona Correo electrónico y, luego, ingresa una dirección de correo electrónico válida.
Haz clic en Agregar canal de notificación. Por último, en la parte inferior del formulario, asígnale el nombre "Tiempo de actividad de la app web" a la política y haz clic en Guardar.
Para ver cómo se verá una alerta, en la consola de Cloud, vuelve a abrir Cloud Shell. El siguiente comando detendrá el servicio de nginx que se ejecuta en nuestro Pod de servidor web:
kubectl exec -t webserver-statefulset-0 -- /bin/bash -c "nginx -s stop"
Después de unos minutos, deberías recibir un correo electrónico en el que se te alerta sobre la interrupción:
Deshagamos eso. De vuelta en Cloud Shell, reiniciemos nginx:
kubectl exec -t webserver-statefulset-0 -- /bin/bash -c "nginx"
Después de unos minutos , recibirás otro correo electrónico de Stackdriver, esta vez con mejores noticias que antes:
8. Limpieza
Ahora que migramos de GCE a GKE con Migrate for Anthos, limpiemos nuestro proyecto de todos los recursos que creamos.
Borra el proyecto
Si lo prefieres, puedes borrar todo el proyecto. En GCP Console, ve a la página Cloud Resource Manager.
En la lista de proyectos, selecciona el proyecto en el que hemos estado trabajando y haz clic en Borrar. Se te pedirá que ingreses el ID del proyecto. Ingrésalo y haz clic en Cerrar.
Si prefieres borrar los diferentes componentes uno por uno, continúa con la siguiente sección.
Stackdriver
Panel
En la página del panel, haz clic en el ícono de configuración 
en la parte superior de la página y selecciona Borrar panel.
Política de alertas
En la página Políticas, selecciona Borrar en el menú Acciones 
a la derecha de cada política que creaste.
Verificación de tiempo de actividad
En la página Verificaciones de tiempo de actividad, selecciona Borrar en el menú Acciones que se encuentra a la derecha de cada verificación que creaste.
GCE y Kubernetes
Instancia de Google Compute Engine
gcloud compute instances delete webserver --zone=us-central1-a
Clúster de Kubernetes (incluye Migrate for Anthos, conjunto con estado y servicio de balanceador de cargas)
gcloud container clusters delete my-gke-cluster --zone=us-central1-a
Discos
Nuestro conjunto con estado usó un disco que creamos. Usa lo siguiente para recuperar el nombre:
gcloud compute disks list --filter=webserver
Usa tu nombre de disco en lugar del mío y bórralo con el siguiente comando:
gcloud compute disks delete vls-690d-webserver --zone=us-central1-a
¡Todo limpio!
9. ¡Felicitaciones!
¡Buen trabajo! Migraste tu servidor web de una instancia de GCE a un clúster de Kubernetes con Migrate for Anthos.
Temas abordados
- Migramos un servidor web de GCE a un clúster de Kubernetes con Migrate for Anthos
- Abrimos nuestro servidor web de conjunto con estado al mundo exponiéndolo a través de un servicio de balanceador de cargas de Kubernetes.
- Habilitamos Stackdriver y creamos un panel personalizado
- Configuramos una verificación de tiempo de actividad junto con una política de alertas para que nos avise cuando nuestro servidor web deje de funcionar.