Etiqueta: docker

KubeCon Europe 2024: resumen del segundo día

Compartimos nuestras impresiones sobre el segundo día de la recién finalizada KubeCon Europe 2024, ahora ya de vuelta en casa. Aunque el cansancio y la emoción nos han dejado poco espacio para plasmar todo lo vivido, aquí estamos, contando, finalmente, lo que experimentamos día a día.

La organización de la KubeCon sigue siendo impecable, como desde el principio del evento. Desde primera hora, miles de personas nos esforzamos por conseguir un buen lugar en las KeyNotes que, aun celebrándose en un espacio colosal, suelen llenarse rápidamente debido al gran interés que generan. Esta vez, el enfoque principal ha sido la inteligencia artificial. Explorando diversas áreas como el funcionamiento de cargas de trabajo en Kubernetes y las últimas novedades en hardware, destacando especialmente la presentación de NVIDIA, apoyada por Intel como Diamond Sponsor.

KubeCon Europe 2024

Las charlas han sido variadas y enriquecedoras, abordando temas como CoreDNS, OpenTelemetry, OCI, OAuth2, Crossplane o GitOps, entre otros. El programa completo se puede revisar en el canal de Youtube oficial de KubeCon. Durante este día se discutieron algunos de los que, en mi opinión personal, son los temas clave de la industria: seguridad transversal, observabilidad y optimización de recursos y costes.

Los stands de exhibición ofrecían una amplia gama de productos y soluciones. Además de la valiosa interacción con los desarrolladores y creadores, pudimos obtener información directamente de la fuente, cosa que pocas veces ocurre. Algunos incluso tuvieron la oportunidad de obtener un autógrafo de figuras destacadas, como ha hecho nuestro compañero Alberto con Viktor Farcic.

El día fue largo, de 7 de la mañana a 7 de la tarde, pero gratificante. Cubrir todo el evento era un desafío, así que priorizamos nuestras actividades y nos dividimos el trabajo. Nos enfocamos en resolver dudas, descubrir nuevas soluciones y aprender cómo otros abordan problemas comunes. Algunos de estos serían la gestión de cientos de nodos sobre miles de clústeres, y cómo se maneja la gran escala, el multitenancy y la comunicación segura entre ellos.

Aunque no pudimos abarcar todo, nos sentimos satisfechos con nuestra participación. Nos hemos dado cuenta de que estamos en sintonía con las necesidades del cliente y la industria, pero siempre buscamos mejorar. Esta conferencia nos ha inspirado a adoptar un enfoque más orgánico y funcional en nuestro trabajo diario, así como a organizar mejor nuestra visión y misión. Para nuestros clientes, esperamos ofrecer productos y servicios más definidos y estructurados que satisfagan sus necesidades y les brinden mejor cobertura y más seguridad.

En resumen, ha sido un día intenso y enriquecedor. Reconocemos que aún tenemos mucho por mejorar, pero estamos en el camino correcto hacia la excelencia. ¡Mañana más, con lo acontecido el día 21!

KubeCon + CloudNativeCon Europe 2024: una semana de inmersión en la vanguardia tecnológica

El KubeCon + CloudNativeCon Europe 2024 ha comenzado con una intensidad que rivaliza con las luces de la Torre Eiffel. Nuestro equipo, junto con colegas de todo el mundo, se ha sumergido en una semana de aprendizaje, descubrimiento y conexiones.

La toma de contacto

El 19 de marzo marcó el inicio de nuestra odisea. Arrancamos el día con un control de acceso fluido y con un auto check-in súper sencillo para adquirir el budget que nos acompañará todos estos días. Fue un día de orientación, de familiarizarnos con los pasillos, los salones y las dinámicas del evento. Por el momento, no hubo intercambio de tarjetas, pero sí pequeñas charlas puntuales en los stands de algunas startups y de proyectos consolidados. Tuvimos la oportunidad de hablar con gente de Cilium, de Dagger o Komodor. Nos encontramos con caras conocidas y nos presentamos a los nuevos.

CloudNativeCon Europe 2024 - entrada

El laberinto de charlas

El schedule es un mapa complejo con gran diversidad de charlas, por lo que el primer paso es organizarnos para encontrar cuáles se adaptan mejor a nuestras preferencias. Las ponencias son de lo más intensas y se notan los nervios y el entusiasmo, ya que las empresas quieren dar a conocer sus productos y servicios, y no quieren perder la oportunidad de generar un impacto en nosotros. En este laberinto, todos somos exploradores, y cada charla es un tesoro por descubrir.

Pudimos conocer cómo implementa eBPF de la mano de Cilium, unas pinceladas de cómo implementar Istio o el nuevo sistema de autenticación de Backstage. Pudimos también conocer cómo otros implementan soluciones de plataforma e infraestructura o, incluso, cómo los desarrolladores experimentan con estas desde sus necesidades particulares. En general han sido charlas técnicas, que nos han acercado a los creadores de los productos que usamos en nuestro día a día, y eso nos ha hecho sentir cerca del tejido productivo que sostiene esta industria.

Desafíos comunes

Las voces de los speakers transmiten mensajes universales y descubrimos que los problemas que enfrentamos en nuestra empresa son los mismos que aquejan a los gigantes tecnológicos. Se repiten conceptos como la escalabilidad, la seguridad o la gestión de recursos. Gracias a este encuentro, nos damos cuenta de que no estamos solos en el camino, ¡todos compartimos las mismas luchas!

CloudNativeCon Europe 2024

Tecnologías de vanguardia

Las palabras clave flotan en el aire: observabilidad, IA nativa en la nube, eBPF. Son las herramientas que están dando forma al futuro y sabemos que nuestras decisiones aquí afectarán nuestro rumbo en los próximos meses. Estamos adoptando tecnologías que están en la vanguardia, y eso nos llena de energía.

Vengo a vender mi libro

Hemos podido disfrutar de las Lightning Talks, durante las cuales, cada 10 minutos, una empresa o un proyecto intenta darse a conocer. En estas sesiones se aprecia el entusiasmo, las ganas por hacer algo que cubra una necesidad y la forma en que la gente del sector está constantemente renovando el mercado desde las bases. Ha sido un placer poder sentir de cerca lo que también somos nosotros.

Aprendizaje y networking

En el plano del aprendizaje, nos sumergimos en los detalles técnicos. Tomamos notas, hacemos preguntas y debatimos sobre las mejores prácticas. Los pasillos son como corredores de conocimiento, y cada encuentro es una oportunidad para aprender.

El networking no se limita a las tarjetas de presentación. Es un flujo constante de conversaciones, risas y conexiones. En los cócteles y las cenas compartimos historias y experiencias. Nos convertimos en nodos en una red global, conectados por nuestra pasión por la tecnología.

En resumen, el KubeCon + CloudNativeCon Europe 2024 es un viaje que abarca una semana completa. Aprendemos, nos conectamos y nos inspiramos. Nuestra empresa está en sintonía con los líderes de la industria, y estamos listos para enfrentar los desafíos que nos esperan. Hasta mañana, ¡esto no ha hecho más que comenzar!

DE LOS NAMESPACES EN LINUX (II)

EL NAMESPACE DE UTS

El espacio de nombres de UTS permite gestionar dos recursos: el hostname y el NIS. El primero de ellos, hostname o nombre de equipo, sirve para identificar una máquina en una red.Se puede interactuar con él a través de comandos como [set/get]hostname o uname Gracias al namespace, cada proceso o grupo de procesos puede disponer de su propio hostname dentro de la máquina. En un ejemplo:

use strict;
use Eixo::Zone;

my $pid = Eixo::Zone->init(

    init=>sub {

        `hostname MAQUINA-HIJO`;

        print “El hostname [en el espacio de hijo] es ” . `hostname`;

        exit (0);
    },

    self_uts=>1
);

waitpid($pid, 0); 

print “El hostname [en el espacio de padre es] es ” . `hostname`;

Lo cual producirá la siguiente salida (dependiendo del hostname real de la máquina)

El hostname [en el espacio de hijo] es MAQUINA-HIJO

El hostname [en el espacio de padre] es ejemplos

¿QUÉ HA PASADO?

¿Qué ha pasado? Se ha creado un proceso con clone pasando el flag CLONE_NEWUTS. Esto implica que el proceso hijo “disfruta” de su propio espacio de UTS La llamada a sethostname se realiza desde el espacio UTS del hijo, por lo que el nombre que se modifica es el de ese espacio. Si se llama a gethostname desde el espacio del padre, se obtendrá el hostname original. Se puede concluir que: el Kernel contextualiza las llamadas a [set/get]hostname en función del espacio desde donde se llamen. En un diagrama:

Llamadas desde ambos namespaces al Kernel

CREACIÓN DE UN PROCESO “VISITANTE”

Imaginémonos que queremos saber cuál es el hostname empleado dentro del namespace UTS privado de un proyecto. Linux nos va a permitir que un proceso se “introduzca” dentro del espacio de un proceso o grupo de procesos y pueda ejecutar llamadas al Kernel dentro del mismo. Veamos el siguiente código:

use strict;
use Eixo::Zone;

my $pid = Eixo::Zone->init(

    init=>sub {
        `hostname MAQUINA-HIJO`;
        print “El hostname [en el espacio de hijo] es ” . `hostname`;
        sleep (2);
    },

    self_uts=>1
);

# nos introducimos en el espacio UTS del hijo

sleep (1);

Eixo::Zone->join(
    
    $pid,
    uts=>1
);

# Ahora estamos dentro del hostname del proceso

print “El hostname [en el espacio del hijo] es ” . `hostname`;

waitpid($pid, 0);

Esto produce la siguiente salida:

El hostname [en el espacio de hijo] es MAQUINA-HIJO

El hostname [en el espacio del hijo] es MAQUINA-HIJO

¿CÓMO SE EXPLICA ESTO?

El proceso hijo ha ejecutado la misma operación de la sección anterior. Esto es:

Se crean ambos procesos y un nuevo namespaceLa diferencia estriba en el proceso padre. Mediante la ejecución de una llamada a setns, el proceso padre se ha unido al namespace de UTS del hijo. Desde ese momento, su llamada gethostname, es relativa al mismo. En un diagrama: 

El proceso padre se “une” al espacio UTS del hijoEn otras palabras, mediante llamadas a setns un proceso puede “visitar” otros namespaces.

DE LOS NAMESPACES EN LINUX (I)

EL NAMESPACE DE PIDS

El identificador de proceso (PID) es un número empleado por el Kernel para referirse de manera unívoca a los procesos que corren en un máquina. Los PIDs se emplean para interactuar con los procesos, por ejemplo, mediante el envío de señales o su repriorización con la utilidad nice. Cada proceso tiene asignado un PID que es único (ningún otro proceso activo puede tener el mismo PID) No obstante, con la introducción del namespace de PIDs (en Linux 2.6.24) esta situación ha variado. En un ejemplo en Perl:

# Un proceso clona un proceso hijo y espera su terminación.

use strict;

use Eixo::Zone; 

my $pid_hijo = Eixo::Zone->init(

    init=>sub {
        print “Soy el proceso hijo y (en mi namespace) tengo pid ” . &Eixo::Zone::getPid() . “\n“;
        sleep (1);
        exit (0);
    }

);

print “Soy el proceso padre y mi hijo tiene pid $pid_hijo \n“;

waitpid($pid_hijo, 0);

Salida:

Soy el proceso padre y mi hijo tiene pid 26708

Soy el proceso hijo y (en mi namespace) tengo pid 1

¿QUÉ HA PASADO?

A) CREACIÓN TRADICIONAL DE UN PROCESO HIJO

Empecemos por una creación de hijo normal a través de fork. 

Fork tradicional de un procesoEl proceso hijo es una copia exacta de su padre que se inicia desde la llamada a fork().

B) CREACIÓN DE UN PROCESO HIJO A TRAVÉS DE CLONE

En el ejemplo de Perl, se ha empleado clone. Esta llamada, entre otras cosas, nos permite crear nuevos namespaces a la hora de producir un proceso hijo. Esto es, indicamos en la creación del hijo qué namespaces propios debe tener Si le indicamos que cree su propio namespace para PIDs: 

Llamada a clone y creación de un namespace nuevo de pidsAhora, nuestro proceso hijo “vive” en su propio namespace y tiene, por tanto, dos PIDs: uno en el espacio de su padre y otro en el suyo propio. Para conocer su PID, un proceso realiza una llamada al Kernel: getpid(). Si el proceso hijo llama al Kernel para pedir su pid:

print “Soy el proceso hijo y (en mi namespace) tengo pid ” . &Eixo::Zone::getPid() . “\n“;

El Kernel devuelve el PID que el hijo tiene dentro de su namespace (PID = 1)

Es decir: El kernel contextualiza las llamadas de los procesos de acuerdo a su namespace El proceso padre quiere esperar a que el proceso hijo termine su ejecución. Para ello, emplea la llamada a waitpid.

waitpid ($pid_hijo, 0);

Espera mientras no termina el proceso hijo ¿Qué PID empleará? Desde su punto de vista (desde su namespace) el PID del proceso hijo será el que recibió en la llamada a clone y ese será el que emplee para esperar.

PROCESOS CON PID = 1

El primer proceso que entra en un namespace de PIDs recibirá (dentro del espacio) el PID 1. Esto tiene importancia, así:

  • El proceso se comporta, en cierto sentido, como el init del sistema
  • Los procesos huérfanos dentro del namespace creado serán adoptados por este proceso y no por el init del sistema
  • La llamada getppid(), desde dentro del namespace, para obtener el padre de este proceso devolverá siempre 0.
  • Este proceso puede “matarse” normalmente terminando todo su árbol de procesos (y el namespace)

¿QUÉ ES UN CONTAINER?

Un container es una técnica de virtualización a nivel de sistema operativo que aísla un proceso o grupo de procesos ofreciéndoles un contexto de ejecución “completo”. Se entiende por contexto o entorno de ejecución el conjunto de recursos (PIDs, red, sockets, puntos de montaje…) que le son relevantes al proceso.

 

A medio camino entre el chroot y las soluciones del tipo de KVM, el container no incurre en el coste de virtualizar el hardware o el kernel del SO ofreciendo, no obstante, un nivel de control y aislamiento muy superiores a los del chroot.

El container es más rápido en ser aprovisionado que el VM, no necesita arrancar una emulación de dispositivos ni el núcleo del sistema operativo, a costa de un nivel de aislamiento mucho menor: procesos en distintos containers comparten el mismo kernel.

Lo que sigue es una introducción a la idea general de los containers…

1. Proceso y Kernel: los recursos
El kernel de Linux tiene como misión fundamental la de mediar entre los programas que corren en una máquina, los procesos, y los distintos dispositivos físicos y virtuales que la componen. Para ello, se crea una abstracción fundamental: el recurso.

Los recursos pueden tener una disponibilidad limitada, un acceso restringido y un empleo privativo. Es tarea del kernel la de impedir que existan monopolizaciones de los mismos, que se produzcan accesos indebidos o que se simultanee el uso de recursos de utilización exclusiva.

Comunicación con los componentes del ordenador
Además, el kernel realiza un importante trabajo de homogeneización, ocultando los detalles de funcionamiento de los distintos dispositivos y ofreciendo a los procesos interfaces limpias y unificadas que estandarizan el empleo de hardware de distinta procedencia.

Podemos concluir, por tanto, que los procesos no “ven” los dispositivos que conforman la máquina donde corren sino la representación que de los mismos les ofrece el kernel.

Recursos de un proceso
Ese conjunto de recursos con los que interactúa el proceso, y que son los que le “interesan”, conforman su contexto de ejecución. En un SO funcionando de manera tradicional dicho contexto es único; esto es, todos los procesos comparten y ven el mismo entorno de SO.

Recursos compartidos por varios procesos
Así encontramos, por ejemplo, que un pid es único por máquina, como lo es un semáforo o un recurso de red. Independientemente de los derechos de acceso, los recursos existentes en una máquina son globales y, en principio, visibles para todos los procesos que viven en ella.

2. La virtualización de plataforma
Las técnicas de virtualización de plataforma (como KVM) simulan una máquina mediante software, y eventualmente algún hardware especial de emulación como el vt-x de Intel, de manera que la replican totalmente: se abstraen los dispositivos, se arranca un kernel y, sobre todo ello, se inician por fin los procesos de usuario.

Virtualización de servidores en una máquina
3. Los containers
Los containers suponen un nuevo enfoque: no se pretende virtualizar la máquina, sino el contexto de ejecución del proceso; esto es, los recursos que el sistema le expone y con los que interactúa.
El contexto ya no es único dentro de una máquina, por lo tanto varios procesos pueden tener el mismo pid (siempre que se encuentren en distintos contextos) cada proceso corriendo en un container puede realizar su propio IPC o montar sus sistemas de ficheros.

El container se centra en aislar el proceso y evita el coste de virtualizar los dispositivos o el kernel que le son indiferentes al primero puesto que ya se encuentran abstraídos por el núcleo del SO.

Dos son los fundamentos tecnológicos de los containers: los cgroups y los namespaces. Ambas tecnologías se encuentran subsumidas dentro del kernel. Las introduciremos en el siguiente artículo.