Hace un par de semanas visité Barcelona para participar en la KubeCon + CloudNativeCon Europe 2019.

Si no pudiste ir, muchas de las láminas así como los vídeos de las sesiones ya están disponibles.

Estas son 5 cosas (algunas bastante inesperadas) que aprendí en KubeCon Europe, Barcelona 2019.

Kubernetes usa controladores para poder escalar mejor

Kubernetes es un proyecto de software muy complejo, con más de 2 millones de líneas de código, múltiples componentes y mecanismos de extensión. Y sigue creciendo.

En su charla The Kubernetes Control Plane for Busy People Who Like Pictures, Daniel Smith explica por qué en un sistema distribuído como Kubernetes es muy difícil de escalar su monitoreo con una máquina de estado convencional.

Mediante el uso de ciclos de control, Kubernetes puede agregar nuevas características y escalar de forma lineal en vez de exponencial.

Además, en su charla describe varias categorías de controladores (clásicos, inyección, biyección, unión) e incluso describe como ejemplos varios de los controladores más populares. No me esperaba que iba a interesarme por teoría de control en una charla de Kubernetes en Barcelona...

topologyKey ayuda a mejorar la disponibilidad de tus aplicaciones en la nube

Improving Availability for Stateful Applications in Kubernetes de Michelle Au fue mi charla favorita de este evento.

La razón es que en vez de asumir que la audiencia está escogiendo el mejor mecanismo de almacenamiento para sus aplicaciones en Kubernetes, Michelle describe cómo cada tipo de almacenamiento (ya sea tradicional o de nube) encaja (o no) con Kubernetes.

Si tienes una NAS, una SAN, un disco administrado en la nube o algo distinto, Kubernetes utiliza conceptos y lógica diferentes para garantizar que el estado de tus aplicaciones está distribuído y es resiliente.

Por ejemplo, el uso del valor failure-domain en topologyKey te permite asignar zonas a los recursos de manera que Kubernetes esté consciente de dónde está tu almacenamiento y qué hacer en caso de fallos.

CNAB agrupa los elementos que describen una aplicación moderna compleja

Un tópico del que hablo en The Future of Linux Packaging es que hoy en día una aplicación ya no está compuesta por un paquete o un proyecto con código fuente, sino que se ha vuelto un concepto complejo que a veces requiere múltiples servidores o sistemas, servicios administrados y más.

Chris Crone dio una excelente introducción a CNAB en Barcelona donde explicó que hoy en día desplegar una aplicación requiere de varios pasos incluyendo herramientas como apt, terraform, helm, kubectl, aws|gcloud|az y más.

CNAB ataca este problema agrupando los recursos que describen una aplicación y creando el concepto de una imagen "lanzadera" que despliega la aplicación. No dejes de darle una mirada a su presentación y darle feedback al equipo de CNAB.

(Por cierto, ¿ya probaste Helm 3?)

No es suficiente solo con dejar de usar root en tus contenedores

Si ya trabajas con contenedores de seguro te has preguntado cómo puedes confiar en todos los layers que tu runtime se baja cuando construyes tus imágenes. Es un tema muy importante, porque al fin y al cabo se trata de tu aplicación, de los datos de tus usuarios y de tus sistemas de producción donde podría estar entrando código malicioso o defectuoso.

En Rootless, Reproducible, and Hermetic: Secure Container Build Showdown, Andrew describe varios vectores de ataque que incluyen el uso de un FROM malicioso, ataques al servidor donde se construye la imagen a través de RUN, uso de --privileged e incluso ataques dentro del contenedor.

Además, Andrew revisa nueve herramientas distintas (diferentes a docker build) que si bien funcionan sin necesidad de root, tienen distintos niveles de soporte para Docker y Kubernetes así como distintos niveles de protección. Andrew también habla sobre el proceso de estandarizar la interfaz de construcción de imágenes a través del Container Build Interface.

Slack es el principal mecanismo de colaboración de Kubernetes

Por último, me pasé por State of Kubernetes Contributor Community donde Paris Pittman habló sobre la salud del proyecto.

Aquí descubrí que Slack es el principal medio de colaboración de Kubernetes (las listas de correo, websites y sobre todo GitHub o Twitter vienen muy por detrás...) y cómo ya me había visto la presentación de Rael García sobre el grupo de trabajo de documentación donde también está el equipo kubernetes-docs-es, decidí pasarme por Slack.

¡Y vaya comunidad! Al cabo de un par de días ya había hecho mis primeros pull requests y empecé a escribir un documento de tips and tricks que quizás también te anime a contribuir al proyecto.

¿Qué has aprendido sobre Kubernetes recientemente? Compártelo en Twitter