¿Qué son los pods en Ku­be­r­ne­tes?

Un pod en Ku­be­r­ne­tes puede contener uno o más co­n­te­ne­do­res que están es­tre­cha­me­n­te co­ne­c­ta­dos y comparten recursos. Por tanto, sirven como entorno coor­di­na­do para las apli­ca­cio­nes.

Pods en Ku­be­r­ne­tes

Los pods son las unidades básicas de de­s­plie­gue en Ku­be­r­ne­tes que co­m­pre­n­den uno o más co­n­te­ne­do­res in­te­r­co­ne­c­ta­dos. Un pod comparte el mismo espacio de red, memoria y otros recursos, por lo que re­pre­se­n­ta una agru­pa­ción lógica de co­n­te­ne­do­res. Los co­n­te­ne­do­res dentro de un pod en Ku­be­r­ne­tes trabajan en estrecha co­la­bo­ra­ción y pueden co­mu­ni­car­se entre sí.

Modelo de un co­n­te­ne­dor

Existen pods que contienen un único co­n­te­ne­dor. Esta es­tru­c­tu­ra se utiliza a menudo cuando una apli­ca­ción o mi­cro­se­r­vi­cio necesita eje­cu­tar­se en un entorno aislado sin necesidad de compartir recursos y red con otros co­n­te­ne­do­res. Un pod de este tipo es la forma más sencilla en Ku­be­r­ne­tes y sigue ofre­cie­n­do las ventajas de or­que­s­ta­ción, escalado y gestión.

Pods con varios co­n­te­ne­do­res

Los pods que ejecutan varios co­n­te­ne­do­res alojan más de un co­n­te­ne­dor dentro del mismo pod. Estos co­n­te­ne­do­res trabajan juntos y comparten el mismo espacio de red y los mismos recursos. Suelen uti­li­zar­se cuando los co­n­te­ne­do­res están es­tre­cha­me­n­te co­ne­c­ta­dos y cumplen una tarea o función común. Por ejemplo, un co­n­te­ne­dor de apli­ca­ción principal y un co­n­te­ne­dor sidecar para registro o mo­ni­to­ri­za­ción podrían eje­cu­tar­se en un pod en Ku­be­r­ne­tes. Esto pe­r­mi­ti­ría una coor­di­na­ción y co­mu­ni­ca­ción más estrecha entre los co­n­te­ne­do­res sin dejar de tratarlos como una entidad única dentro del clúster de Ku­be­r­ne­tes.

Crear un pod en Ku­be­r­ne­tes

Para poder crear un pod en Ku­be­r­ne­tes necesitas un archivo YAML que describa la es­pe­ci­fi­ca­ció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 co­n­te­ne­dor llamado nginx-container. El co­n­te­ne­dor 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 Ku­be­r­ne­tes

Se re­co­mie­n­da el uso de niveles de ab­s­tra­c­ción su­pe­rio­res como de­plo­y­me­nts o Sta­te­fu­l­Sets para gestionar pods en un entorno pro­du­c­ti­vo. Estos co­n­tro­la­do­res asumen la de­fi­ni­ción del estado deseado de la apli­ca­ción y se aseguran de que éste coincida con el estado real. Esto incluye la es­ca­la­bi­li­dad, la ac­tua­li­za­ción gradual y la re­cu­pe­ra­ción au­to­má­ti­ca de los pods.

Al crear un pod, ya sea di­re­c­ta­me­n­te por el ad­mi­ni­s­tra­dor o in­di­re­c­ta­me­n­te a través de un co­n­tro­la­dor, se programa en un nodo es­pe­cí­fi­co dentro del clúster. El pod permanece en ese nodo asignado hasta que ocurre uno de los si­guie­n­tes casos: termina su ejecución, el objeto de pod asociado se elimina ma­nua­l­me­n­te, hay escasez de recursos u otros problemas que requieren la eva­cua­ción del pod a otro nodo, o el nodo actual ex­pe­ri­me­n­ta un fallo. En este último caso, el pod se reinicia en otro nodo di­s­po­ni­ble para ga­ra­n­ti­zar su ejecución continua.

El nombre de un pod debe estar es­ta­ble­ci­do como un valor válido de su­b­do­mi­nio DNS. Esto es crucial para asegurar que el pod sea ide­n­ti­fi­ca­ble de manera única dentro del clúster de Ku­be­r­ne­tes. Las etiquetas DNS tienen que tener menos de 253 ca­ra­c­te­res, pueden contener solo ca­ra­c­te­res al­fa­nu­mé­ri­cos y guiones, y deben comenzar y terminar con un carácter al­fa­nu­mé­ri­co.

Pod OS

Los pods de Ku­be­r­ne­tes no­r­ma­l­me­n­te se co­n­fi­gu­ran para eje­cu­tar­se 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 apli­ca­ción o una parte es­pe­cí­fi­ca de ella requiere funciones es­pe­cí­fi­cas de Windows. Puedes es­pe­ci­fi­car el sistema operativo en el campo .spec.os.name de la es­pe­ci­fi­ca­ción del pod en el archivo YAML.

Gestión de pods

Aunque es posible crear pods ma­nua­l­me­n­te, debido a la creciente co­m­ple­ji­dad de las apli­ca­cio­nes y cargas de trabajo, esto a menudo no es práctico. Los co­n­tro­la­do­res de Ku­be­r­ne­tes pro­po­r­cio­nan un nivel de ab­s­tra­c­ción basado en una co­n­fi­gu­ra­ción de­cla­ra­ti­va. Existen varios tipos de co­n­tro­la­res:

• Ku­be­r­ne­tes De­plo­y­me­nt
• Ku­be­r­ne­tes Sta­te­fu­l­Set
• Ku­be­r­ne­tes DaemonSet

El co­n­tro­la­dor de de­s­plie­gue mo­ni­to­ri­za co­n­ti­nua­me­n­te el estado del clúster. Esto permite acciones au­to­ma­ti­za­das como escalar, ac­tua­li­zar y mantener apli­ca­cio­nes. Los Re­pli­ca­Sets aseguran que haya una cantidad constante de pods idénticos en fu­n­cio­na­mie­n­to. Los Sta­te­fu­l­Set son ese­n­cia­les para apli­ca­cio­nes con datos in­te­n­si­vos, ya que ga­ra­n­ti­zan ide­n­ti­da­des de red estables para los pods.

Pla­n­ti­llas de pods

Una plantilla de pod es una parte de la co­n­fi­gu­ra­ción de un co­n­tro­la­dor que describe las pro­pie­da­des deseadas de un pod de Ku­be­r­ne­tes. Estas incluyen co­n­te­ne­do­res, la imagen Docker, variables de entorno, re­qui­si­tos de recursos y más. El co­n­tro­la­dor utiliza la plantilla de pod para co­n­fi­gu­rar o ac­tua­li­zar pods. Por ejemplo, durante un de­s­plie­gue, crea nuevos pods cuando se requiere escalado o actualiza los pods exi­s­te­n­tes durante una ac­tua­li­za­ció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, co­n­fi­gu­ra­mos un job con el nombre new-job. La plantilla de pod crea un único pod con un co­n­te­ne­dor que utiliza la imagen de Ubuntu y ejecuta el comando echo "Hello from Kubernetes". El job tendrá un máximo de tres re­in­te­n­tos si se produce un error debido a la co­n­fi­gu­ra­ción de backoffLimit.

Ac­tua­li­zar pods de Ku­be­r­ne­tes

En Ku­be­r­ne­tes existen varios métodos para ac­tua­li­zar los recursos, incluidos los dos métodos más uti­li­za­dos: patch y replace.

El método Patch se utiliza para realizar ac­tua­li­za­cio­nes puntuales y parciales de un recurso sin re­em­pla­zar toda la de­fi­ni­ción del recurso. Para ello, se pro­po­r­cio­na un parche que solo contiene los campos que deben mo­di­fi­car­se. Esto permite ac­tua­li­zar partes es­pe­cí­fi­cas de un recurso sin modificar otras. Este método pro­po­r­cio­na una forma eficaz de realizar cambios mínimos en un recurso, es­pe­cia­l­me­n­te si solo es necesario ac­tua­li­zar de­te­r­mi­na­dos campos.

En cambio, el método Replace sustituye todos los campos del recurso por los campos co­rre­s­po­n­die­n­tes de la nueva de­fi­ni­ción. El método replace se utiliza cuando se requiere una ac­tua­li­za­ción exhau­s­ti­va o se realizan cambios es­tru­c­tu­ra­les fu­n­da­me­n­ta­les en el recurso.

Algunos metadatos y campos de las de­fi­ni­cio­nes YAML de los recursos Ku­be­re­ne­tes son in­mu­ta­bles. Estos incluyen:

• apiVersion und kind: estos metadatos definen el tipo y la versión del recurso y no­r­ma­l­me­n­te no deberían cambiarse.
• metadata.name y metadata.namespace: el nombre y el espacio de nombres de un recurso son no­r­ma­l­me­n­te inal­te­ra­bles para asegurar la ide­n­ti­fi­ca­ción única del recurso.
• metadata.creationTimestamp: la fecha de creación de un recurso es in­va­ria­ble e indica cuándo se creó el recurso.

Compartir recursos

Los pods pueden utilizar volúmenes para compartir datos entre co­n­te­ne­do­res dentro del mismo pod. Un volumen es un sistema de archivos o di­re­c­to­rio que es co­m­pa­r­ti­do por uno o más co­n­te­ne­do­res en el pod. Los volúmenes son me­ca­ni­s­mos efectivos para almacenar datos que se extienden más allá del ciclo de vida de un único co­n­te­ne­dor.

Cada pod de Ku­be­r­ne­tes tiene su propia dirección IP, que es única dentro de la red del clúster. Esta dirección IP permite la co­mu­ni­ca­ción directa entre los pods. Si varios co­n­te­ne­do­res se están eje­cu­ta­n­do en un pod, pueden co­mu­ni­car­se entre sí a través del localhost y di­fe­re­n­tes puertos. Esto si­m­pli­fi­ca la in­ter­ac­ción entre las di­fe­re­n­tes partes de una apli­ca­ción en el mismo pod.

Modo pri­vi­le­gia­do

Si un co­n­te­ne­dor se ejecuta en modo pri­vi­le­gia­do, tiene mayores derechos y puede acceder a recursos del sistema que no­r­ma­l­me­n­te no están di­s­po­ni­bles en un co­n­te­ne­dor aislado estándar. En Ku­be­r­ne­tes, el modo pri­vi­le­gia­do se activa co­n­fi­gu­ra­n­do la opción securityContext.privileged en las es­pe­ci­fi­ca­cio­nes del co­n­te­ne­dor.

Es im­po­r­ta­n­te tener en cuenta que el uso del modo pri­vi­le­gia­do está asociado a riesgos de seguridad si­g­ni­fi­ca­ti­vos. Debido a au­to­ri­za­cio­nes excesivas, un co­n­te­ne­dor co­m­pro­me­ti­do o una apli­ca­ción maliciosa en el sistema host podría causar serios problemas de seguridad. Por lo tanto, el modo pri­vi­le­gia­do solo debe usarse si es necesario y se han co­n­si­de­ra­do los posibles riesgos de seguridad.

Pods estáticos

Los pods estáticos en Ku­be­r­ne­tes son pods que no son su­pe­r­vi­sa­dos ni ge­s­tio­na­dos por el plano de control central del clúster. A di­fe­re­n­cia de los pods regulares, que dependen de los co­n­tro­la­do­res de Ku­be­r­ne­tes, los pods estáticos son iniciados di­re­c­ta­me­n­te por un nodo. Estos pods están vi­n­cu­la­dos a un nodo es­pe­cí­fi­co y sus de­fi­ni­cio­nes se colocan en el propio nodo, ge­ne­ra­l­me­n­te en un di­re­c­to­rio como /etc/kubernetes/manifests/. Kubelet en el nodo supervisa e inicia el pod estático, re­ini­ciá­n­do­lo au­to­má­ti­ca­me­n­te si se cae.

A di­fe­re­n­cia de los pods regulares, los pods estáticos no son co­n­tro­la­dos por la API de Ku­be­r­ne­tes y son in­vi­si­bles para el plano de control central del clúster. Los pods estáticos son un método sencillo para desplegar apli­ca­cio­nes o servicios en un nodo sin un clúster central de Ku­be­r­ne­tes. Sin embargo, no tienen todas las fu­n­cio­na­li­da­des de los pods regulares que son ge­s­tio­na­dos por el ad­mi­ni­s­tra­dor de co­n­tro­la­do­res de Ku­be­r­ne­tes.

Pruebas de co­n­te­ne­do­res

Las pruebas de co­n­te­ne­do­res son me­ca­ni­s­mos en Ku­be­r­ne­tes que mo­ni­to­rean el estado y la salud de un co­n­te­ne­dor.

Para realizar un dia­g­nó­s­ti­co, Kubelet puede llevar a cabo varias acciones:

• Exe­cA­c­tion (ejecutado mediante el entorno de ejecución del co­n­te­ne­dor): esta acción permite a Kubelet ejecutar un comando dentro del co­n­te­ne­dor. Esto es es­pe­cia­l­me­n­te útil para realizar ve­ri­fi­ca­cio­nes pe­r­so­na­li­za­das o pruebas dentro del co­n­te­ne­dor. Si el comando se ejecuta co­rre­c­ta­me­n­te, la prueba se considera exitosa.
• TC­P­So­c­ke­tA­c­tion (ve­ri­fi­ca­do di­re­c­ta­me­n­te por Kubelet): esta acción permite a Kubelet verificar la ac­ce­si­bi­li­dad de un puerto TCP es­pe­cí­fi­co dentro del co­n­te­ne­dor. Si el puerto es­pe­ci­fi­ca­do está abierto, la prueba se considera exitosa.
• HT­T­P­Ge­tA­c­tion (ve­ri­fi­ca­do di­re­c­ta­me­n­te por Kubelet): en esta acción, Kubelet realiza una solicitud HTTP-GET a una ruta y puerto es­pe­cí­fi­cos dentro del co­n­te­ne­dor. Esta acción se utiliza co­mú­n­me­n­te para endpoints HTTP para asegurar que una apli­ca­ción responda co­rre­c­ta­me­n­te a las so­li­ci­tu­des. Si la solicitud devuelve un código de estado 2xx, la prueba se considera exitosa.