Los recursos de cargas de trabajo denominados «controladoras» crean los pods y gestionan la implementación, la replicación y el estado de los pods en el clúster. Por ejemplo, si un nodo del clúster falla, una controladora detecta que los pods de ese nodo no responden y crea pods de sustitución en otros nodos.

Los tres tipos más comunes de controladoras son los siguientes:

• Jobs: para trabajos por lotes que son efímeros y que ejecutarán una tarea hasta su finalización
• Deployments: para aplicaciones sin estado y persistentes, como servidores web (servidores HTTP)
• StatefulSets: para aplicaciones con estado y persistentes, como las bases de datos

Si un pod tiene varios contenedores, todos se programan juntos en el mismo servidor del clúster, ya sea una máquina virtual o un servidor físico. Todos los contenedores del pod comparten recursos y dependencias, y pueden coordinar su ejecución y finalización. Por ejemplo, los pods pueden contener contenedores «init» que se ejecutan antes de que se ejecuten los contenedores de aplicaciones, lo que configura el entorno para las aplicaciones posteriores.

Los pods casi siempre los crean las controladoras que pueden gestionar automáticamente el ciclo de vida de los pods, lo que incluye reemplazar los pods que fallan, replicar los pods cuando sea necesario y desalojar el pod de los nodos del clúster cuando su ejecución llegue a su fin o ya no se necesiten.

Las controladoras utilizan la información de una plantilla de pods para crear los pods y se aseguran de que los pods en ejecución coincidan con la implementación definida en la plantilla de pods, por ejemplo, creando réplicas que coinciden con el número definido en la implementación.

Cuando se crea un pod, se le asigna su propia dirección IP única. Si hay varios contenedores dentro del pod, pueden comunicarse entre sí simplemente utilizando localhost. Las comunicaciones externas al módulo se logran gracias a los puertos. Las comunicaciones entre los pods de un clúster aprovechan el hecho de que Kubernetes asigna una dirección IP privada de clúster a cada pod de un clúster, lo que elimina la necesidad de crear enlaces explícitos entre los pods o de asignar puertos de contenedores a puertos de host. De esta forma, todos los pods de un clúster pueden «verse» entre sí sin necesidad de recurrir a procesos NAT.

kubectl proporciona una serie de comandos que permiten al usuario crear pods, ejecutarlos mediante implementaciones, comprobar el estado de los pods en ejecución y detener los pods que ya no se necesitan. Los comandos JavaScript Object Notation (JSON) o YAML Ain’t Markup Language (YAML) son válidos para codificar comandos.

Los comandos de kubectl más utilizados se enumeran a continuación:

Get

El comando «kubectl get» mostrará información tabular sobre uno o más recursos. La información se puede filtrar mediante selectores de etiquetas. La información que se muestra puede ser de solo el espacio de nombres existente o de todos los espacios de nombres del clúster.
El comando «kubectl api-resources» generará una lista de todos los recursos compatibles sobre los que puede obtener información. El formato general del comando «kubectl get» es:

$ kubectl get [(-o|--output=)json|yaml|wide|custom-columns=...|custom-columns-file=...|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...] (TYPE[.VERSION][.GROUP] [NAME | -l label] | TYPE[.VERSION][.GROUP]/NAME ...) [flags]

Create Pods

Los pods se crean utilizando el comando «create» con el siguiente formato:

$ kubectl create -f FILENAME, donde «FILENAME» es el nombre del archivo.

Por ejemplo, el comando:

kubectl create -f ./mypod.yaml creará un pod nuevo a partir del archivo YAML «mypod».

Delete Pods

El comando «kubectl delete -f ./mypod.yaml» eliminará el pod «mypod» del clúster. Eliminar pods es un proceso sencillo; los pods seguirán ejecutándose durante un periodo de gracia (30 segundos de forma predeterminada) antes de dejar de funcionar por la fuerza. El valor del periodo de gracia se puede sobrescribir con el marcador –grace-period si se desea.