Un pod es la unidad mínima de despliegue.
Comandos útiles para trabajar con pods. Los usaremos bastante durante el curso.
Descripción de la arquitectura de Kubernetes, necesaria para entender los conceptos que se abordarán en los siguientes capítulos.
Una vez hemos visto cuáles son las piezas de un cluster y tenemos una idea general de cómo funciona el nodo maestro y los nodos de trabajo, vamos a desplegar nuestra aplicación y a pedir a nuestro cluster que mantenga activas un número determinado de réplicas.
En la sección anterior vimos cómo mantener levantadas en kubernetes un número de replicas de nuestra aplicación. Sin embargo, el objeto ReplicaSet es engorroso de utilizar y tiene algunas limitaciones. Por eso surgió el objeto Deployment. Esta es la forma recomendada de desplegar los Pods, y en esta sección veremos cómo utilizarlos.
La manera que tiene Kubernetes de seleccionar objetos.
Ya somos capaces de desplegar nuestras aplicaciones en Pods dentro de nuestro cluster. Ahora ¿Cómo accedemos a ellas?
Una vez hemos visto cómo podemos acceder a nuestros Pods, tanto desde dentro como desde fuera
del cluster, ha llegado el momento de entender cuál es el ciclo de vida de un Pod.
Entenderlo nos ayudará a comprender mejor la información que Kubernetes nos da de los Pods,
diagnosticar los problemas con más precisión y saber qué está pasando cuando las cosas se tuerzan.
Comprobaciones de estado permitirán a los servicios saber si los pods están operativos o no. Con esta información pueden decidir si les envían peticiones de forma dinámica.
En esta sección veremos el objeto Namespace y cómo nos puede ayudar a organizar y compartimentar
nuestro cluster.
En esta sección veremos las herramientas de las que disponemos para gestionar la configuración de nuestras aplicaciones. Kubernetes nos facilita un mecanismo para almacenar la configuración e información sensible, como contraseñas, de nuestra aplicación. Lo hace, además, de forma que nos facilita aplicar el principio de separación de configuración y código.
Si tenemos multiples Pods que tienen que comunicarse entre sí, y estos Pods
son efímeros ¿Cómo conseguimos que se puedan encontrar entre sí? ¿Cómo hacemos que nuestros Pods
se conecten a nuestra base de datos sin saber a priori cuál es su IP o su nombre interno? Kubernetes proporciona un servicio
DNS que se encarga de ofrecer nombres para poder acceder tanto a los objetos Service
como a los Pods.
Veremos el funcionamiento de Ingress en Kubernetes como alternativa a los servicios de balanceo de carga que nos ofrecen los proveedores de clusters gestionados.
Una vez hemos desplegado nuestros servicios ¿Cómo accedemos a ellos desde fuera? Lo habitual es que utilicemos
un registro DNS que apunte o bien al Service o al Ingres (o al NodePort
si los estamos utilizando). ¿Cómo hacemos para que estos registros se creen (o se actualicen) directamente desde
Kubernetes? Eso es lo que veremos en esta sección.
Hasta ahora hemos trabajado con aplicaciones sin estado. Las aplicaciones con estado necesitan de un mecanismo que les
permita almacenarlo para poder recuperarlo cuando los Pods se reinician o reprograman. Los Volúmenes
son la manera de conseguir esta persistencia.
Estas dos herramientas nos permiten desacoplar los Pods de la técnología de almanecenamiento
que se utilza para crear los volúmenes.
- Diapositivas 🔗
-
Taller - Arsys: Uso de
PersistentVolumeyPersistentVolumeClaim🔗 -
Taller - Arsys: Failed
PersistentVolumes🔗 -
Taller - Arsys: Encuentra el error (
PersistentVolumeyPersistentVolumeClaim) 🔗 - Taller - Arsys: Dynamic volume provisioning 🔗
- Taller - Arsys: Resolver incidencia con los modos de acceso (ROX, RWO y RWX) 🔗
- Taller - Arsys: Deployment con PVC en modo de acceso RWO 🔗
PodPreset nos permite inyectar recursos como Secrets,
ConfigMaps, variables de entorno o
Volumes en un conjunto de Pods usando un selector.
Obsoleto. Alternativa: Mutation Webhooks
El StatefulSet es un recurso de Kubernetes diseñado para facilitar la implementación
de aplicaciones con estado dentro de Kubernetes.
Los objetos DaemonSet nos garantizan que una instancia de un Pod
se ejecuta en cada nodo del cluster.
Kubernetes nos facilita mecanismos para examinar los recursos utlizados por nuestros
nodos, Pods`, Services y contenedores. Veremos en esta sección cómo podemos acceder
a esta información. En la siguiente sección, veremos cómo utilizar esta información para
escalar nuestra aplicación.
Kubernetes dispone de mecanismos para escalar nuestra aplicación y poder adaptarla al tráfico que está recibiendo
en cada momento. En esta sección veremos los mecanismos para escalar horizontalmente (aumentando el número de réplicas)
y verticalmente (aumentando los límites de memoria y CPU de los Pods). También permite
escalar el cluster, aumentado y reduciendo el número de nodos.
Kubernetes nos facilita diversos mecanismos para influir en el algoritmo de programación de los Pods.
En esta sección veremos los conceptos de Affinity y AntiAffinity, que nos permiten
decirle al kube-scheduler donde queremos que se ejecuten nuestros Pods.
Los Taints y Tolerations nos permiten establecer condiciones para quere
los nodos repelan los Pods. Nos ayudan a evitar que los Pods acaben
ejecutándose en determinados nodos.
El gestor de paquetes para kubernetes