"La mejor forma de definir qué es un contenedor, para mí, es que se trata de una forma de empaquetar y distribuir tu aplicación de forma que sea lo más independiente posible del ordenador donde se va a ejecutar." Así definía un contenedor Eduard Tomás, Developer Technologies MVP, Certified Kubernetes Application Developer y autor y tutor de nuestro curso de 🐳 Docker y Kubernetes en la charla que tuvimos en directo con él.
Durante esta charla, mientras comparaba el aislamiento de los contenedores con el de las máquinas virtuales, Eduard nos advirtió que ese aislamiento no es total y que pueden surgir incidencias de saturación de recursos o incluso de incursiones malintencionadas a través del kernel del sistema operativo.
Y es que al fin y al cabo, aunque usa sus propias librerías, el contenedor hace uso del kernel del sistema operativo del ordenador anfitrión.
Seguridad de los contenedores vs máquinas virtuales
Pero esto no quiere decir que los contenedores sean inseguros. Tras el susto inicial Eduard nos tranquilizó porque se trata de casos muy poco frecuentes y que simplemente lo apuntaba para que se tenga en cuenta a la hora de ponderar en cada proyecto si se quiere dar preferencia a la seguridad (usando máquinas virtuales, que tampoco son inexpugnables ante un bug) frente al gran rendimiento de los contenedores.
Porque si bien dos máquinas virtuales son entes independientes, dos contenedores al final van a compartir el mismo kernel del sistema operativo. Pero, ¿esa seguridad extra te va a compensar la pérdida de rendimiento? Por lo general y para un uso normal, NO.
Por otro lado, Eduard nos abrió una tercera vía en el caso de que la seguridad sea crítica y no quieras renunciar a los contenedores, que es el caso de los motores de contenedores que hacen uso de hipervisores ligeros y nos permiten tener lo mejor de ambos mundos. Después de la charla, Eduard nos dejó varios ejemplos en un hilo de twitter que hemos recopilado para ti a continuación.
Motores de contenedores con hipervisores
Los contenedores "normales" (vamos a llamarlos así) funcionan gracias a dos mecanismos del kernel de Linux: cgroups y namespaces.
Los cgroups permiten limitar y aislar el consumo de ciertos recursos (CPU, memoria, I/O, etc) de un grupo de procesos, de forma que podemos limitar el consumo de memoria de un contenedor a, por ejemplo, 200Mib.
Los namespaces por su lado "particionan" determinados objetos del kernel, de forma que cada proceso ve su propio "espacio de nombres" de ese objeto. Es gracias a los namespaces que dos contenedores pueden abrir su puerto 80: cada uno ve el puerto 80 de un namespace distinto. Hay algunos objetos del kernel que no están namespaceados, es decir que son compartidos por todos los procesos del host (incluyendo los contenedores), aunque cada vez menos (kernels más modernos de Linux soportan más objetos en namespaces).
Para el día a día normal, el aislamiento que dan los contenedores es más que suficiente, teniendo en cuenta las ventajas de rendimiento al compararlos con máquinas virtuales: el footprint de un contenedor es muy pequeño. Pero pueden existir entornos que requieran medidas mucho más estrictas, y en donde queramos usar un hipervisor. Ahí es donde entran esos motores de contenedores, que usan hipervisores para ejecutarlos.
-
gVisor
Empecemos por gVisor de Google. Técnicamente no usa un hipervisor, sino que reimplementa las llamadas del kernel de Linux para que se ejecuten en espacio de usuario. Eso da un "plus" de aislamiento. La app (el contenedor) hace llamadas kernel a gVisor y ese es la que hace las llamadas reales al kernel de Linux. gVisor puede filtrar llamadas y dotar así de mayor aislamiento.
-
VIC Engine
VIC son las siglas de vSphere Integrated Containers, que es un ejemplo de runtime de contenedores que usa un hipervisor: realmente tenemos micromáquinas virtuales que nos ejecutan los contenedores.
-
Kata Containers
Kata Containers es otro runtime de contenedores que usa un microhipervisor para ejecutar los contenedores. Es el heredero del ya obsoleto "Clear Containers"
Todos esos motores (y más) son un ejemplo de que el mundo de los contenedores es mucho más que "Docker" y que no solo hay un runtime, sino que hay muchos y que funcionan con variadas tecnologías subyacentes. Por suerte tenemos un estándar, llamado OCI (Open Container Initiative) que define un estándar de imagen de contenedor. De forma que si uso un builder OCI (por ejemplo, BuildKit que es "docker build") podré ejecutar esa imagen en varios motores.
Todos esos motores los podemos ejecutar con Kubernetes, claro. Las últimas versiones de Kubernetes suelen venir con containerd (el motor de ejecución que usa Docker) pero se le pueden enchufar otros motores, usando un estándar llamado CRI. Existe incluso una implementación de CRI, llamada CRI-O que facilita enchufar cualquier motor de contenedores OCI a Kubernetes. OOB soporta Kata Containers y runc (el motor de bajo nivel usado por containerd), pero se pueden enchufar otros motores OCI.
En fin, que eso de los contenedores es todo un mundo y hay mucho, muchísimo más detrás de Docker... ¡por suerte! 😀
Y si quieres abrir la puerta al maravilloso mundo de los contenedores 🐳 Docker y Kubernetes, ninguna otra opción es mejor que dejarse llevar de la mano de Eduard. Exige esfuerzo, pero te aseguramos que si te interesa esta tecnología merecerá la pena.
Fecha de publicación: