Viendo Pods y Nodos

Objetivos

• Aprender sobre Pods Kubernetes.
• Aprender sobre Nodos Kubernetes.
• Solucionar problemas de aplicaciones desplegadas.

Pods

Cuando creamos un Deployment en el Módulo 2, Kubernetes creó un Pod para alojar la instancia de nuestra aplicación. Un Pod es una abstracción de Kubernetes que representa un grupo de uno o más contenedores de aplicación (por ejemplo Docker), y algunos recursos compartidos para esos contenedores. Esos recursos incluyen:

• Almacenamiento compartido, como volúmenes
• Redes, brindando una dirección IP de clúster única
• Información sobre cómo ejecutar cada contenedor, como podrían ser la versión de la imagen del contenedor o los puertos específicos a utilizar

Un Pod modela un "host lógico" específico de la aplicación y puede contener diferentes contenedores de aplicación que están relativamente estrechamente acoplados. Por ejemplo, un Pod podría incluir tanto el contenedor con su aplicación Node.js como un contenedor diferente que alimenta los datos que se publicarán mediante el servidor web Node.js. Los contenedores en un Pod comparten un espacio de direcciones IP y de puertos, siempre están ubicados y programados juntos, y se ejecutan en un contexto compartido en el mismo Nodo.

Los Pods son la unidad atómica en la plataforma Kubernetes. Cuando creamos un Deployment en Kubernetes, ese Deployment crea Pods con contenedores dentro (en lugar de crear contenedores directamente). Cada Pod está vinculado al Nodo donde se planifica y permanece allí hasta la terminación (según la política de reinicio) o eliminación. En caso de una falla del Nodo, Pods idénticos se planifican en otros Nodos disponibles en el clúster.

Nodos

Un pod siempre se ejecuta en un Nodo. Un Nodo es una máquina de trabajo en Kubernetes y puede ser una máquina virtual o física, dependiendo del clúster. Cada Nodo es administrado por el plano de control. Un Nodo puede tener varios pods, y el plano de control d e Kubernetes maneja automáticamente la planificaciṕon de los pods en los Nodos del clúster. La planificación automática del plano de control tiene en cuenta los recursos disponibles en cada Nodo.

En cada Nodo Kubernetes se ejecuta al menos:

• Kubelet, un proceso responsable de la comunicación entre el plano de control de Kubernetes y el Nodo; administra los Pods y los contenedores que se ejecutan en una máquina.
• Un motor de ejecución de contenedores (como Docker) responsable de extraer la imagen del contenedor de un registro, desempaquetar el contenedor y ejecutar la aplicación.

Diagnosticando aplicaciones con kubectl

En el Módulo 2, usamos la interfaz de línea de comandos kubectl. Continuaremos usándola en el Modulo 3 para obtener información sobre las aplicaciones desplegadas y sus entornos.

Las operaciones más comunes se pueden realizar con los siguientes subcomandos de kubectl:

• kubectl get - lista recursos
• kubectl describe - muestra información detallada sobre un recurso
• kubectl logs - muestra los logs de un contenedor en un Pod
• kubectl exec - ejecuta un comando en un contenedor de un Pod

Se pueden emplear estos comandos para ver cuándo se desplegaron las aplicaciones, cuál es su estado actual, dónde se están ejecutando y cuáles son sus configuraciones.

Ahora que conocemos mas sobre los componentes del cluster y la linea de comandos, exploremos nuestra aplicación.

Chequear la configuración de la aplicación

Verifiquemos que la aplicación que desplegamos en el escenario anterior se está ejecutando. Usaremos el comando kubectl get y buscaremos Pods existentes:

kubectl get pods

Si no hay Pods en ejecución, espere unos segundos y vuelva a listar los Pods. Puede continuar una vez que vea un Pod en ejecución.

A continuación, para ver qué contenedores hay dentro de ese Pod y qué imágenes se utilizan para construir esos contenedores, ejecutamos el comando kubectl describe pods:

kubectl describe pods

Veremos los detalles del contenedor del Pod: dirección IP, los puertos utilizados y una lista de eventos relacionados con el ciclo de vida del Pod.

La salida del subcomando describe es extensa y cubre algunos conceptos que aún no explicamos, pero no se preocupe, se volverán familiares al final de este bootcamp.

El subcomando describe se puede usar para obtener información detallada sobre la mayoría de los comandos de Kubernetes, incluidos Nodos, Pods y Despliegues. La salida de describe está diseñada para ser legible por humanos, no para ser usada en scripts.

Recuerde que los Pods se ejecutan en una red aislada y privada, por lo que necesitamos un proxy para acceder a ellos y poder depurarlos e interactuar con ellos. Para hacer esto, usaremos el comando kubectl proxy para ejecutar un proxy en una segunda terminal.

Abra una NUEVA ventana de terminal y, en esa nueva terminal, ejecute:

kubectl proxy

Nuevamente, obtendremos el nombre del Pod y consultaremos ese Pod directamente a través del proxy. Para obtener el nombre del Pod y almacenarlo en la variable de entorno POD_NAME:

export POD_NAME="$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')"

echo "Nombre del Pod: $POD_NAME"

Para ver la salida de nuestra aplicación, ejecute una solicitud con curl:

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME/proxy/

La URL es la ruta a la API del Pod.

Ver los logs del container

Cualquier cosa que la aplicación normalmente enviaría a la salida estándar se convierte en registros para el contenedor dentro del Pod. Podemos recuperar estos registros usando el comando kubectl logs:

kubectl logs "$POD_NAME"

No necesitamos especificar el nombre del contenedor, porque solo tenemos un contenedor dentro del pod.

Ejecutar un comando en el contenedor

Podemos ejecutar comandos directamente en el contenedor una vez que el Pod está en funcionamiento. Para esto, usamos el subcomando exec y usamos el nombre del Pod como parámetro. Ejecutemos el comando env para enumerar las variables de entorno:

kubectl exec "$POD_NAME" -- env

Nuevamente, vale la pena mencionar que el nombre del contenedor en sí se puede omitir ya que solo tenemos un contenedor en el Pod.

A continuacion, iniciemos una sesión bash en el contenedor del Pod:

kubectl exec -ti $POD_NAME -- bash

Tenemos ahora una consola abierta en el contenedor donde se ejecuta nuestra aplicación NodeJS. El código fuente de la aplicación esta en el archivo server.js:

cat server.js

Puede verificar que la aplicación esté activa ejecutando el comando curl:

curl http://localhost:8080

Nota: aquí usamos localhost porque ejecutamos el comando dentro del Pod NodeJS. Si no puede conectarse a localhost:8080, verifique que haya ejecutado el comando kubectl exec y esté ejecutando el comando desde dentro del Pod.

Para cerrar la conexión con el contenedor, escriba exit.

Una vez que esté listo, continúe con Usando Service para exponer su aplicación.