Una Guía Kubernetes es necesaria para englobar en un tema un conjunto de temas que desde hace tiempo le hacemos seguimiento para efectos de monitorización
En una actualización reciente, la NG 724, incluimos un complemento o «plugin» especialmente diseñado para Docker Swarm, el cual si traducimos literalmente del idioma inglés significa «enjambre de trabajadores portuarios»: ¡diantres! ¿por qué lo nombramos para hablar de Kubernetes? ¿qué tiene que ver eso con la monitorización? Pues como os describimos en el resumen del encabezado, son varios conceptos que van encadenados y que os describiremos paso a paso -enlaces web incluidos para ahondar en cada concepto, dado el caso-.
Guía Kubernetes: historia subyacente
La cual es muy interesante, esto que os narraremos no va de tema técnico sino histórico: bien rompemos con lo establecido en monitorización, también hacemos otro tanto en la escritura de este vuestro blog. Cuando los ferrocarriles modernos nacen en Inglaterra alrededor del año 1800, para luego expandirse a Europa y de allí al resto del mundo, surgió una revolución en el transporte de mercancía. Ya era posible trasladar grandes cantidades de manera relativamente rápida y segura, lo cual ayudó a implementar la revolución industrial y el desarrollo de las naciones.
Los vagones de simples plataformas con sujetadores fueron evolucionando y especializando: tanques para todo tipo de líquidos, de estacas para madera, enjaulados para ganado, cerrados con asientos para pasajeros y también cerrados para mercancía preciada. Las personas adineradas incluso tenían sus propios vagones personalizados y con todos los lujos y gustos, que simplemente enganchaban junto con los demás vagones. Incluso vehículos y camiones fueron -y son llevados actualmente- en tren a donde necesitemos. Precisamente entre Londres y París, a principios de 1900, un transporte de lujo de pasajeros ofreció un cómodo traslado a quien no podía costear la compra de un vagón completo, y para mayor rapidez en el abordaje de su distinguida clientela se fijaron en los camiones cargados de mercancía que iban sobre rieles: inventaron los contenedores de equipaje y al llegar la locomotora rápidamente subían las personas y más rápido aun su equipaje.
Pronto se hizo patente la idea de hacer contenedores más grandes y aligerar la carga evitando montar los camiones en los trenes, así era más rápido la llegada de los ferrocarriles a las estaciones por medio de grúas orquestadas. No fue sino hasta 1950 que en Estados Unidos, donde todo es para ayer en su acelerado estilo de vida, patentaron el uso de los contenedores que hoy vemos en los puertos marítimos de todo el planeta.
¿Qué ventajas supone un contenedor de mercancía? Pues que lo podemos cargar con sumo cuidado con la certeza que irá bien protegido a su destino, ahorrando tiempo y dinero… ¿Qué tal si hacemos lo mismo con contenedores de software?
Contenedores de software
Un contenedor de software (como concepto análogo a ferrocarriles, camiones y barcos) nos permite empaquetar nuestras aplicaciones garantizando así que funcionarán en cualquier sistema operativo que tenga un programa especializado que maneje dichos contenedores. Hay sutiles diferencias entre una máquina virtual y un contenedor, pero indicamos que la cantidad de memoria y procesador utilizado es muchísimo menor en el caso de un contenedor.
Un programa muy popular hecho en 2008 para manejar contenedores es Docker, que en inglés significa estibador o trabajador portuario (o mejor dicho, operador de grúa en puertos marítimos): no más problemas con aplicaciones que corren estupendamente de CentOS y que cascan en Debian, por ejemplo. Con Docker solo tenemos que crear un perfil, publicarlo en Docker Registry para que sea descargado y la aplicación se encargará de crear un entorno cerrado que será al igual que usamos cuando creamos la aplicación y ésta se correrá sin problemas.
Los contenedores de software ya existían antes de Docker, Linux ofrece un soporte nativo desde el año 2001 pero tampoco era una novedad: el año anterior había nacido la idea de jaulas o «jails» en FreeBSD que impedía que aplicaciones accedieran a otros recursos del ordenador. La genialidad de Docker fue la simplificación en su manejo: este gran acierto permitió la masificación y uso de Docker.
Evidentemente que la evolución natural conllevó a ofrecer incluso los Contenedores como Servicio o «CaaS» («Containers as a Service») bajo el producto Docker Cloud y en este enlace explicamos en detalle sobre cómo funciona. Explicado esto, ya tenemos descifrado nuestra primera capa en el esquema de nuestra Guía Kubernetes.
Monitorización de contenedores de software
En otro artículo analizamos cómo es la monitorización de contenedores: esencialmente no es necesario ir uno por uno sino observar la central que controla todo un grupo de contenedores, lo cual nos lleva al siguiente paso.
Enjambre de contenedores de software
Docker Cloud fue posible de implementar por medio del Docker Swarm con el que abrimos este artículo. El concepto es que los contenedores se puedan comunicar con protocolos especiales, compartir recursos y características particulares y mucho más con una función muy importante: ser administrados de una manera centralizada y masiva. Así como en Pandora FMS tenemos nuestro propio protocolo de comunicación llamado Tentacle, Docker Swarm también estableció una forma segura de comunicar todos los contenedores en uno o más ordenadores. Aprovechando esto hemos creado un complemento o plugin especialmente diseñado para que esté en un contenedor y sea parte de todo el enjambre para poder recoger todas las métricas necesarias. Para mayor información en este enlace web publicamos los pormenores (¡también os ofrecemos todas las posibilidades de monitorización que están disponibles con Pandora FMS! ).
Ahora sí, Guía Kubernetes 🙂
Os hemos tenido en ascuas hablando sobre Docker, pero era necesario para ahora sí hablar nuestra Guía Kubernetes.
Kubernetes es un software para desplegar y administrar enjambres de aplicaciones basadas en contenedores de software. Docker Swarm es apenas una de esas aplicaciones, pero ¿acaso es suficiente una herramienta, para qué necesitamos dos entonces?
Pues resulta que Kubernetes centraliza aún más lo que ya tenemos centralizado, además de que nos permite manejar cuantos enjambres -o racimos, «clusters» en idioma inglés- tengamos, ¡una herramienta de herramientas en grado superlativo!
Breve historia de Kubernetes
Nuestra Guía Kubernetes no puede estar completa sin saber de dónde venimos para saber hacia dónde vamos. Como dijimos en 2001 al kernel Linux se le agregó la capacidad de manejar contenedores con cgroups a instancias de una compañía bien famosa: Google®. Actualmente la tecnología de contenedores de software mantiene trabajando a dicha empresa, gracias a una visión a futuro que tuvieron sus ingenieros de desarrollo.
El predecesor de Kubernetes fue Borg (llamado así por un colectivo de furiosos extraterrestres de la popular serie de televisión «Star Trek®» y quienes se comunicaban entre sí mismos y entre todos de manera fluida) y fue desarrollado también por Google®: de allí sacaron muchos de los conceptos que hoy definen a Kubernetes. El logotipo de Kubernetes, que significa timonel en idioma griego, tiene siete asideros en referencia al Proyecto Siete De Nueve el cual a su vez obtuvo su nombre de otro personaje de la serie de televisión, una humana asimilada por los Borg y rescatada luego para la causa terráquea. En 2015 cuando Google® publica la primera versión de Kubernetes dicho proyecto fue donado a la recién formada «Fundación para la Computación en Nube de manera Nativa» («Cloud Native Computing Foundation«), fundación que ha mantenido como proyecto de código abierto hasta el día de hoy.
Conceptos claves de Kubernetes
Vimos que Kubernetes opera directamente sobre Docker, sin este software simplemente no tendríamos aplicaciones contenidas a las cuales administrar y/o mantener, pero ¿cómo opera Kubernetes? Aunque pueda sonar anacrónico, utilizaremos el concepto cliente-servidor que es ampliamente conocido por todos y todas:
Servidor
- Kubernetes corre sobre un ordenador central o nodo central (el cual también puede ser un racimo de ordenadores configurados en alta redundancia y con carga distribuida). Evidentemente que es el componente más importante porque interactúa con los usuarios por medio de la «Interfaz de programación de aplicaciones» o API y es conocido como kube-apiserver (por cierto, notad este prefijo Kube-, y que por el cual también a veces se refieren a Kubernetes).
- kube-ctl: se encarga de conectar a los usuarios al kube-apiserver, tal como línea de comandos.
- Se vale de etcd para almacenar valores distribuidos que puedan ser leídos también por los clientes.
- kube-controller-manager: también se vale de etcd para realizar una auditoría con el panorama general del enjambre o los enjambres. Se asegura que las reglas que hemos especificados se cumplan: si ordenamos correr 7 capullos con sus correspondientes aplicaciones contenidas, ese va a ser el número exacto que tendremos en funcionamiento. Si configuramos todo correctamente podrá ser capaz de reiniciar, eliminar o crear nuevos nodos virtuales a fin de mantener en funcionamiento los 7 capullos de ejemplo que especificamos. Acá también podremos colocar un Agente Software de Pandora FMS para recoger las métricas que necesitemos.
- kube-scheduler: otro componente que se encarga de medir la capacidad total declarada en la infraestructura contra la carga de trabajo que está ejecutando. Si es necesario se encarga de replanificar para que el kube-controller-manager lea nuevas especificaciones necesarias. Realmente tiene funciones de monitorización parecidas con lo que en Pandora FMS conocemos como «autovalidación de eventos» y «respuestas de eventos».
- cloud-controller-manager: se encarga de interactuar con el proveedor que alberga al sistema completo y puede ser muy personalizado, dependiendo del proveedor.
Cliente
- Los nodos son controlados por un nodo central y ejecutan aplicaciones en contenedores de software por medio de Docker.
- Los capullos («pods» en idioma inglés) agrupan una serie de aplicaciones en un contenedor de software, cada nodo puede albergar uno o más capullos.
- Kubelet: es el que se encarga de verificar si los capullos programados se están ejecutando en su propio nodo. Comparándolo con la arquitectura de Pandora FMS vienen a ser unos Agentes Software que funcionan de manera inversa ya que leen del nodo central (con ayuda de etcd) los manifiestos y los comparan con lo que están ejecutando. Una vez hecho esto devuelven su estado al nodo central. Notemos esto para la monitorización ya que es un buen comienzo recoger métricas por medio de Agentes Software de Pandora FMS instalados en los nodos.
- kube-proxy: corre en cada nodo y son coordinados por el nodo central, su función es declarar vía UDP y/o TCP dónde está realmente ubicado cada capullo. Esto es necesario porque el kube-controller-manager puede reubicar uno o varios capullos a otro nodo o repartirlos en diferentes nodos (actúa como una suerte de «Inventario», funcionalidad integrada de Pandora FMS).
Configuración de Kubernetes
Kubernetes no es un ente aislado, necesitaremos muchos otros programas de código abierto:
- Ansible para aprovisionar los nodos (para empezar instalando Docker en cada uno de ellos si no se tienen imágenes con ello incluido, amén de otros software que necesitemos).
- Seguridad robusta con el uso de LDAP, SELinux, RBAC, y OAUTH.
- Telemetría como Heapster, Kibana, Hawkular y Elastic.
- Entorno de red con OpenvSwitch.
- Uso de registros públicos como Atomic Registry o Docker Registry.
Más importante aún: Kubernetes no solamente trabaja con Docker, existen otras alternativas como krt (Kubernetes Juggernaut) e incluso con las futuras aplicaciones que sigan las especificaciones APPC «App Container spec» (especificaciones de aplicaciones de contenedores).
Otros componentes de Kubernetes
Como es simplemente una Guía Kubernetes, no presentamos absolutamente todos los componentes, y además como pudieron notar siempre desde el punto de vista a una introducción a la monitorización con Pandora FMS, esto siempre de pura manera conceptual.
¿Creéis que sea capaz Pandora FMS de superar el reto de Kubernetes, teniendo en cuenta que ya cubrimos Docker y Docker Swarm? ¿Tenéis nuevas ideas, dudas -o comentarios- acerca de ello? Haced clic aquí y os atenderemos.
| Título | Enlace |
|---|---|
| What's a Linux container? | https://www.redhat.com/en/topics/containers/whats-a-linux-container |
| What is kubernetes? | https://www.redhat.com/en/topics/containers/what-is-kubernetes |
| Borg: The Predecessor to Kubernetes | https://kubernetes.io/blog/2015/04/borg-predecessor-to-kubernetes/ |
| Why Red Hat Chose Kubernetes for OpenShift | https://blog.openshift.com/red-hat-chose-kubernetes-openshift/ |
| Container Wars: Docker vs. Rkt | http://www.devx.com/blog/dev_issues/container-wars-docker-vs.-rkt.html |
| An Introduction to Kubernetes | https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes |
| Kubernetes reference | https://kubernetes.io/docs/reference/ |
| rkt, appc, and Docker: A Take on the Linux Container Upstream | https://rhelblog.redhat.com/2015/05/05/rkt-appc-and-docker-a-take-on-the-linux-container-upstream/ |
| What is the App Container spec? | https://github.com/appc/spec |
| Container Wars: Docker vs. Rkt | http://www.devx.com/blog/dev_issues/container-wars-docker-vs.-rkt.html |
https://pandorafms.com/guides/public/books/kubernetes-enterprise-plugin
https://pandorafms.com/blog/es/guia-kubernetes/
https://pandorafms.com/guides/public/books/kubernetes-enterprise-plugin-d9d/page/configuracion
https://pandorafms.com/library/wp-content/uploads/2019/08/EN-Kubernetes-plugin.pdf