¿Qué son los pods en Kubernetes?

Un pod en Kubernetes puede contener uno o más contenedores que están estrechamente conectados y comparten recursos. Por tanto, sirven como entorno coordinado para las aplicaciones.

Pods en Kubernetes

Los pods son las unidades básicas de despliegue en Kubernetes que comprenden uno o más contenedores interconectados. Un pod comparte el mismo espacio de red, memoria y otros recursos, por lo que representa una agrupación lógica de contenedores. Los contenedores dentro de un pod en Kubernetes trabajan en estrecha colaboración y pueden comunicarse entre sí.

Modelo de un contenedor

Existen pods que contienen un único contenedor. Esta estructura se utiliza a menudo cuando una aplicación o microservicio necesita ejecutarse en un entorno aislado sin necesidad de compartir recursos y red con otros contenedores. Un pod de este tipo es la forma más sencilla en Kubernetes y sigue ofreciendo las ventajas de orquestación, escalado y gestión.

Pods con varios contenedores

Los pods que ejecutan varios contenedores alojan más de un contenedor dentro del mismo pod. Estos contenedores trabajan juntos y comparten el mismo espacio de red y los mismos recursos. Suelen utilizarse cuando los contenedores están estrechamente conectados y cumplen una tarea o función común. Por ejemplo, un contenedor de aplicación principal y un contenedor sidecar para registro o monitorización podrían ejecutarse en un pod en Kubernetes. Esto permitiría una coordinación y comunicación más estrecha entre los contenedores sin dejar de tratarlos como una entidad única dentro del clúster de Kubernetes.

Crear un pod en Kubernetes

Para poder crear un pod en Kubernetes necesitas un archivo YAML que describa la especificación del pod. He aquí un ejemplo sencillo de un pod Nginx:

apiVersion: v1 
kind: Pod 
metadata: 
    name: nginx-pod 
spec: 
    containers: 
    - name: nginx-container 
        image: nginx:latest

Este documento YAML define un pod llamado nginx-pod que contiene un único contenedor llamado nginx-container. El contenedor utiliza la última imagen de Nginx del Docker Hub.

Introduce el siguiente comando para crear el pod:

kubectl apply -f nginx-pod.yaml

Uso de los pods en Kubernetes

Se recomienda el uso de niveles de abstracción superiores como deployments o StatefulSets para gestionar pods en un entorno productivo. Estos controladores asumen la definición del estado deseado de la aplicación y se aseguran de que éste coincida con el estado real. Esto incluye la escalabilidad, la actualización gradual y la recuperación automática de los pods.

Al crear un pod, ya sea directamente por el administrador o indirectamente a través de un controlador, se programa en un nodo específico dentro del clúster. El pod permanece en ese nodo asignado hasta que ocurre uno de los siguientes casos: termina su ejecución, el objeto de pod asociado se elimina manualmente, hay escasez de recursos u otros problemas que requieren la evacuación del pod a otro nodo, o el nodo actual experimenta un fallo. En este último caso, el pod se reinicia en otro nodo disponible para garantizar su ejecución continua.

El nombre de un pod debe estar establecido como un valor válido de subdominio DNS. Esto es crucial para asegurar que el pod sea identificable de manera única dentro del clúster de Kubernetes. Las etiquetas DNS tienen que tener menos de 253 caracteres, pueden contener solo caracteres alfanuméricos y guiones, y deben comenzar y terminar con un carácter alfanumérico.

Pod OS

Los pods de Kubernetes normalmente se configuran para ejecutarse en un sistema operativo Linux. Sin embargo, hay casos en los que puede ser necesario ejecutar un pod en un sistema operativo Windows, por ejemplo, si tu aplicación o una parte específica de ella requiere funciones específicas de Windows. Puedes especificar el sistema operativo en el campo .spec.os.name de la especificación del pod en el archivo YAML.

Gestión de pods

Aunque es posible crear pods manualmente, debido a la creciente complejidad de las aplicaciones y cargas de trabajo, esto a menudo no es práctico. Los controladores de Kubernetes proporcionan un nivel de abstracción basado en una configuración declarativa. Existen varios tipos de controlares:

• Kubernetes Deployment
• Kubernetes StatefulSet
• Kubernetes DaemonSet

El controlador de despliegue monitoriza continuamente el estado del clúster. Esto permite acciones automatizadas como escalar, actualizar y mantener aplicaciones. Los ReplicaSets aseguran que haya una cantidad constante de pods idénticos en funcionamiento. Los StatefulSet son esenciales para aplicaciones con datos intensivos, ya que garantizan identidades de red estables para los pods.

Plantillas de pods

Una plantilla de pod es una parte de la configuración de un controlador que describe las propiedades deseadas de un pod de Kubernetes. Estas incluyen contenedores, la imagen Docker, variables de entorno, requisitos de recursos y más. El controlador utiliza la plantilla de pod para configurar o actualizar pods. Por ejemplo, durante un despliegue, crea nuevos pods cuando se requiere escalado o actualiza los pods existentes durante una actualización.

apiVersion: batch/v1 
kind: Job 
metadata: 
    name: new-job 
spec: 
    template: 
        metadata: 
            name: pod 
        spec: 
            containers: 
            - name: container 
                image: ubuntu:latest 
                command: ["echo", "Hello from Kubernetes"] 
    backoffLimit: 3

En este ejemplo, configuramos un job con el nombre new-job. La plantilla de pod crea un único pod con un contenedor que utiliza la imagen de Ubuntu y ejecuta el comando echo "Hello from Kubernetes". El job tendrá un máximo de tres reintentos si se produce un error debido a la configuración de backoffLimit.

Actualizar pods de Kubernetes

En Kubernetes existen varios métodos para actualizar los recursos, incluidos los dos métodos más utilizados: patch y replace.

El método Patch se utiliza para realizar actualizaciones puntuales y parciales de un recurso sin reemplazar toda la definición del recurso. Para ello, se proporciona un parche que solo contiene los campos que deben modificarse. Esto permite actualizar partes específicas de un recurso sin modificar otras. Este método proporciona una forma eficaz de realizar cambios mínimos en un recurso, especialmente si solo es necesario actualizar determinados campos.

En cambio, el método Replace sustituye todos los campos del recurso por los campos correspondientes de la nueva definición. El método replace se utiliza cuando se requiere una actualización exhaustiva o se realizan cambios estructurales fundamentales en el recurso.

Algunos metadatos y campos de las definiciones YAML de los recursos Kuberenetes son inmutables. Estos incluyen:

• apiVersion und kind: estos metadatos definen el tipo y la versión del recurso y normalmente no deberían cambiarse.
• metadata.name y metadata.namespace: el nombre y el espacio de nombres de un recurso son normalmente inalterables para asegurar la identificación única del recurso.
• metadata.creationTimestamp: la fecha de creación de un recurso es invariable e indica cuándo se creó el recurso.

Compartir recursos

Los pods pueden utilizar volúmenes para compartir datos entre contenedores dentro del mismo pod. Un volumen es un sistema de archivos o directorio que es compartido por uno o más contenedores en el pod. Los volúmenes son mecanismos efectivos para almacenar datos que se extienden más allá del ciclo de vida de un único contenedor.

Cada pod de Kubernetes tiene su propia dirección IP, que es única dentro de la red del clúster. Esta dirección IP permite la comunicación directa entre los pods. Si varios contenedores se están ejecutando en un pod, pueden comunicarse entre sí a través del localhost y diferentes puertos. Esto simplifica la interacción entre las diferentes partes de una aplicación en el mismo pod.

Modo privilegiado

Si un contenedor se ejecuta en modo privilegiado, tiene mayores derechos y puede acceder a recursos del sistema que normalmente no están disponibles en un contenedor aislado estándar. En Kubernetes, el modo privilegiado se activa configurando la opción securityContext.privileged en las especificaciones del contenedor.

Es importante tener en cuenta que el uso del modo privilegiado está asociado a riesgos de seguridad significativos. Debido a autorizaciones excesivas, un contenedor comprometido o una aplicación maliciosa en el sistema host podría causar serios problemas de seguridad. Por lo tanto, el modo privilegiado solo debe usarse si es necesario y se han considerado los posibles riesgos de seguridad.

Pods estáticos

Los pods estáticos en Kubernetes son pods que no son supervisados ni gestionados por el plano de control central del clúster. A diferencia de los pods regulares, que dependen de los controladores de Kubernetes, los pods estáticos son iniciados directamente por un nodo. Estos pods están vinculados a un nodo específico y sus definiciones se colocan en el propio nodo, generalmente en un directorio como /etc/kubernetes/manifests/. Kubelet en el nodo supervisa e inicia el pod estático, reiniciándolo automáticamente si se cae.

A diferencia de los pods regulares, los pods estáticos no son controlados por la API de Kubernetes y son invisibles para el plano de control central del clúster. Los pods estáticos son un método sencillo para desplegar aplicaciones o servicios en un nodo sin un clúster central de Kubernetes. Sin embargo, no tienen todas las funcionalidades de los pods regulares que son gestionados por el administrador de controladores de Kubernetes.

Pruebas de contenedores

Las pruebas de contenedores son mecanismos en Kubernetes que monitorean el estado y la salud de un contenedor.

Para realizar un diagnóstico, Kubelet puede llevar a cabo varias acciones:

• ExecAction (ejecutado mediante el entorno de ejecución del contenedor): esta acción permite a Kubelet ejecutar un comando dentro del contenedor. Esto es especialmente útil para realizar verificaciones personalizadas o pruebas dentro del contenedor. Si el comando se ejecuta correctamente, la prueba se considera exitosa.
• TCPSocketAction (verificado directamente por Kubelet): esta acción permite a Kubelet verificar la accesibilidad de un puerto TCP específico dentro del contenedor. Si el puerto especificado está abierto, la prueba se considera exitosa.
• HTTPGetAction (verificado directamente por Kubelet): en esta acción, Kubelet realiza una solicitud HTTP-GET a una ruta y puerto específicos dentro del contenedor. Esta acción se utiliza comúnmente para endpoints HTTP para asegurar que una aplicación responda correctamente a las solicitudes. Si la solicitud devuelve un código de estado 2xx, la prueba se considera exitosa.