5. What is the difference
between Docker and
Kubernetes?
6. Kubernetes is meant to run
across a cluster while Docker
runs on a single node.
https://azure.microsoft.com/en-us/topic/kubernetes-vs-docker
“ “
7. Going back in time
https://kubernetes.io/docs/concepts/overview/what-is-kubernetes
Kubernetes is an open source project that results
from the need to orchestrate containers and
providing tools to manage infrastructure via code.
¡Buenas tardes a todos!
Bienvenidos al KCD y muchas gracias por asistir a esta charla donde daré una introducción a Kubernetes.
Comenzaré con una presentación.
Me llamo Juan Pablo pero todos me llaman Juampy. Ahí tenéis mi nick, juampynr, con el que podéis encontrarme en redes sociales.
Vivo en Cercedilla, un pueblo de la sierra de Madrid.
Trabajo en Lullabot como Senior Developer. Lullabot es una empresa de estrategia, diseño y desarrollo fundada hace 15 años en Estados Unidos. No hay oficina así que toda la empresa está distribuida.
Desde hace año y medio trabajo en uno de los equipos de NBC News. Empecé con soporte para sus portales de noticias y poco a poco me fui involucrando en otros proyectos y tecnologías.
Me encanta la integración contínua. He investigado y escrito artículos sobre el tema. Este proceso me ha llevado al mundo DevOps y así fue como descubrí Kubernetes.
Estos últimos meses he conseguido estas dos certificaciones a través de la Linux Foundation.
Aviso que mi experiencia en Kubernetes en producción es limitada. De momento lo que más he hecho es estudiar y leer. NBC News está migrando sus aplicaciones a Kubernetes y he tenido la oportunidad de echar una mano en algunas cosas pero aún me queda mucho por aprender.
Hecha ya la presentación, comencemos con la charla.
Primero, vamos a ver qué es Kubernetes.
Esta definición es de la web oficial. Dice:
Kubernetes es una plataforma de software libre portable y extensible para gestionar conjuntos de tareas y servicios en contenedores.
Es cierto que sea software libre, pues el código fuente está en GitHub. De hecho es uno de los proyectos más activos a nivel mundial.
Hace unos meses llegó al millón de pull requests. Para el que no haya oído este término, un pull request es una interfaz web donde
alguien sugiere cambios en código para que otros los revisen.
Kubernetes es portable puesto que funciona en multitud de nubes. Yo mismo hice este ejercicio y acabé escribiendo una serie de
artículos donde probé desplegar una aplicación con Kubernetes en la nube de Digital Ocean, la de Google, y la de AWS, y tuve que
cambiar muy poco.
Kubernetes es extensible puesto que ofrece una API sobre la que puedes programar para que se adapte a tu caso. Por ejemplo,
si tienes una nube híbrida, puedes crear un Cloud Controller Manager que especifique cómo gestionar los recursos de esa nube.
Otra de las preguntas comunes que la gente tiene al descubrir Kubernetes es la siguiente:
¿Cuál es la diferencia entre Docker y Kubernetes?
Tras buscar respuestas y leer varios artículos con el título Docker vs Kuberetes, llegué a la conclusión de que la pregunta no se puede
responder porque no tiene sentido. Docker y Kubernetes son tecnologías diferentes que pueden trabajar en conjunto.
Kubernetes puede utilizar Docker como motor para gestionar contenedores. También soporta otros sistemas de contenedores como
containerd o CRI-O.
Esta es la mejor respuesta que encontré, viene de la documentación de Azure, la nube de Microsoft, dice:
Kubernetes funciona en un cluster mientras que Docker en una sóla máquina.
Esta es la razón por la que el término “orquestración de contenedores” o “container orchestration” va ligado a Kubernetes, mientras que Docker se
asocia más con desarrollo local o integración contínua.
Personalmente, hace unos años empecé a usar Docker en Jenkins para ejecutar tests
automáticamente. Ya desde aquel entonces leía artículos sobre “Docker en producción”, y cómo era algo complejo y a veces inestable. Entiendo
que de ahí aparece Kubernetes.
Veamos el orígen de Kubernetes en más detalle para entenderlo mejor.
Kubernetes es una solución para gestionar contenedores en infraestructuras a través de código.
Aquí tenemos tres fases de la evolución gestión de aplicaciones, las tres aún válidas.
A la izquierda el modelo tradicional, donde tenemos servidores físicos que soportan aplicaciones.
En el centro, el siguiente paso: la virtualización, donde tenemos un cluster con máquinas virtuales. Cada máquina virtual representa una máquina que soporta una o varias aplicaciones.
Los contenedores comparten el sistema operativo con lo que son mucho más ligeros. Kubernetes, por tanto añade una capa de abstracción aquí, permitiendo que los contenedores
(y por tanto las aplicaciones que hay en ellos) se ejecuten de forma transparente en diferentes nubes y sistemas operativos.
Vamos a ver un ejemplo de arquitectura con Kubernetes.
La clave a la hora de realizar operaciones en Kubernetes es que la unidad más pequeña es el pod.
Dentro de un pod puede haber uno o varios contenedores.
En este ejemplo tenemos una serie de nodos en una nube.
En el lado izquierdo está el nodo que actúa como Kubernetes Master o Control Plane, mientras que en el derecho tenemos tres
nodos que soportan la carga de trabajo.
El node Control Plane se compone de una serie de servicios que controlan y monitorizan el cluster, tales como:
El kube-controller-manager realiza ciclos para regular el estado del cluster.
El cloud-controller-manager interactúa con la API de la nube o nubes.
El kube-api-server interactúa con los tres nodos a través de peticiones de red.
etcd es una base de datos distribuida que guarda el estado del cluster. Utiliza un protocolo que le permite replicarse y repararse en caso de error en múltiples control plane.
Por último, el kube-scheduler calcula y planifica los cambios a realizar en los worker nodes.
En cada uno de los worker nodes tenemos:
Un servicio kube-proxy, que gestiona la red de comunicación.
Un servicio kubelet, que monitoriza y controla los pods.
Uno o más pods.
Una vez vista la arquitectura, aquí tenemos un ejemplo de la vida de una aplicación en Kubernetes.
Comenzamos por crear un cluster. El cluster puede ser un cloud provider como AWS o Google, un servidor físico, o incluso una raspberry pi.
Una vez configurado, desplegamos una aplicación en el cluster. Hay varias formas de hacerlo pero la más sencilla es creando
un archivo de texto con un objeto llamado deployment (lo veremos en la siguiente diapositiva), y desplegándolo mediante
kubectl, la interfaz de comandos de Kubernetes.
Si queremos que nuestra aplicación pueda comunicarse con el exterior. Dependiendo de la aplicación crearemos otro archivo con un objeto
de Kubernetes llamado service o ingress controller donde especificamos las reglas que le permiten a la aplicación comunicarse.
Si lo necesitamos, podemos hacer que nuestra aplicación se replique dentro del cluster para soportar un mayor tráfico. Digamos que, en vez de un sólo servidor nginx, queremos 10.
Kubernetes se encarga de realizar la replicación y gestionar la carga de tráfico.
Finalmente, podemos actualizar la aplicación mediante rollout updates. Este proceso permite desplegar una nueva versión de la aplicación en el cluster y, una vez esté lista,
Kubernetes realiza los cambios de red pertinentes para que el tráfico se dirija a la nueva versión, mientras que comienza a destruir los pods con la versión antigua.
Aquí tenemos un ejemplo de cómo realizar un despliegue.
Supongamos que queremos desplegar una aplicación que símplemente contiene el servidor web nginx.
En el lado izquierdo vemos cómo realizar esto mediante un comando que:
Crea un objeto Deployment en el cluster llamado “nginx-deployment” con la imagen de Docker de nginx.
Especifica que se deben crear dos pods con esta aplicación.
Expone el puerto 80.
Tras ejecutar este comando, el kube-controller-manager lo interpretará y pedirá al kube-scheduler que calcule qué cambios se deben
hacer en el cluster para desplegar la aplicación. Con esta información, el kube-api-server envía peticiones de red a los worker nodes
para realizar el despliegue.
El comando de la izquierda se puede definir en un archivo YAML y luego ejecutarse mediante kubectl apply.
Ambos métodos son válidos. De hecho, una práctica común es ejecutar un comando como el de la derecha en modo dry-run (que es
una simulación) y guardando el resultado en un archivo YAML. Después se edita hasta que esté listo para ser ejecutado.
Una vez vistos los conceptos principales, veamos una demo.
Hay muchas formas de lanzar una aplicación a producción en Kubernetes.
Por simplicidad he escogido el ejemplo más sencillo. Se trata de una aplicación Drupal, un gestor de contenidos de software libre.
La aplicación se compone de el propio CMS, MariaDB como base de datos.
Para hacer el despliegue utilizo Helm, que es un gestor de dependencias de Kubernetes. Para que os hagáis una idea,
Helm es a Kubernetes lo que npm es a JavaScript, o composer es a PHP.
El ejemplo que hemos visto, aún sencillo, tiene un alto nivel de abstracción.
Aquí tenemos un diagrama que describe lo que ocurre en el vídeo.
Primero utilizamos helm repo add para registrar localmente un repositorio donde está una aplicación de ejemplo de Drupal.
La aplicación está definida mediante una serie de archivos YAML como los que vimos antes. Helm se encarga de
empaquetarlos en un chart, reemplazar algunas variables tales como el usuario de administración de Drupal o de la base de datos,
y finalmente realizar el despliegue mediante kubectl apply.
En este ejemplo he utilizado microk8s, una distribución ligera de Kubernetes que consiste en un cluster de un nodo que hace tanto de
control plane como de worker.
El control plane ha creado: un pod con MariaDB y un volúmen con la base de datos y otro pod con Drupal y nginx. Los archivos públicos de Drupal tales como imágenes van en un volúmen.
La comunicación con el exterior del cluster se realiza a través del puerto 80, el cual gestiona un Service, que es un objeto de Kubernetes.
Los volúmenes sirven para guardar datos que persistan incluso si el pod se destruye. En este caso los datos son los archivos de base de datos y el sistema de archivos públicos tales como las imágenes que suben los editores.
Aquí tenemos algunos ejemplos de plataformas con las que he experimentado y herramientas comunes en proyectos Kubernetes.
Respecto a las plataformas, puedo decir que estas tres son similares en la medida que las he utilizado. La mayor diferencia está en cómo te identificas ante ellas
por línea de comandos.
Respecto a las herramientas más comunes:
fluentd sirve para agregar y transformar logs.
HELM is es un gestor de dependencias para objetos de Kubernetes.
linkerd es un service mesh. Estoy comenzando a estudiar esto y de momento veo que es una especie de distribución que instalas en un cluster y añade monitorización, comunicación segura entre pods, y observabilidad.
Prometheus se utiliza para telemetría del cluster y de las aplicaciones.
Rancher ofrece una interfaz web para monitorizar y gestionar clústeres.
Vitess añade una capa de abstracción de base de datos que permite escalar horizontalmente. Leí un artículo en el blog de Slack donde comentan su experiencia con esta herramienta.
Terminamos con algunos recursos para continuar explorando.
La documentación oficial está genial. Muchas de las imágenes de esta presentación las he cogido de ahí.
El repositorio de Kubernetes es uno de los más activos en GitHub.
La Cloud Native Computing Foundation promueve proyectos de software libre para la nube. Organizan la KubeCon y la CloudNativeCon. Si os interesa profundizar más en
Kubernetes, or recomiendo registraros en el próximo evento.
La comunidad en Slack es muy activa. Es una buena forma de aprender viendo cómo la gente explica problemas y la comunidad les da feedback.
Por último, escribí una serie de artículos en el blog de Lullabot sobre las diferencias que encontré en la nube de Digital Ocean, Google, y AWS para Kubernetes..
¡Buenas tardes a todos!
Bienvenidos al KCD y muchas gracias por asistir a esta charla donde daré una introducción a Kubernetes.
Comenzaré con una presentación.