Anatomía de contenedores 101: ¿Qué es un clúster?

Desde una perspectiva de redes, los contenedores extienden el “borde” de la red, el límite entre las decisiones de reenvío de red y un paquete que llega a su destino final, profundamente en un host. El edge ya no es la interfaz de red de un host, sino que está en varias capas profundas en construcciones lógicas dentro de un host. Y la topología de red se abstrae y se adentra profundamente en estas construcciones lógicas dentro de un host, en forma de tunelización de red superpuesta, interfaces virtuales, límites NAT, equilibradores de carga y complementos de red. Los arquitectos de redes y seguridad ya no pueden ignorar los elementos internos del SO cuando diseñan sus arquitecturas. Los contenedores obligan a estas arquitecturas a comprender a dónde va un paquete después de pasar a través de la NIC de un host.

Sistemas de orquestación

Dicho esto, se requiere un sistema de orquestación para llevar algún tipo de orden a los entornos de contenedores. Un sistema de orquestación administra los detalles sobre la organización, el escalado y la automatización de contenedores, y crea construcciones lógicas alrededor de varios componentes que son relevantes para el comportamiento del contenedor. También son responsables de organizar los límites lógicos asociados con los tiempos de ejecución del contenedor y crear construcciones lógicas a las que se les puede asignar una dirección IP. Dicho esto, dichos sistemas son externos y en realidad no pueden implementar y administrar el ciclo de vida de instancias de tiempo de ejecución de contenedores específicos, que todavía son manejadas por Docker, por ejemplo.

Existen muchos sistemas de orquestación de contenedores, pero los dos más utilizados hoy en día son Kubernetes y OpenShift. Ambos logran los mismos objetivos básicos, con la principal diferencia de que uno es un proyecto y el otro es un producto: Kubernetes es un proyecto nacido en gran parte de Google, y OpenShift es un producto propiedad de Red Hat. En términos generales, Kubernetes se ve con mayor frecuencia en entornos de nube pública y OpenShift se ve con mayor frecuencia en centros de datos locales, pero hay una cantidad significativa de superposición entre los dos. En resumen, Kubernetes subyace a ambos enfoques, con alguna ligera diferencia en la terminología entre cada uno.

Una breve historia de los contenedores

Lo creas o no, los contenedores son anteriores a Kubernetes. Docker, por ejemplo, lanzó por primera vez su plataforma de contenedores en 2013, mientras que Kubernetes no lanzó su proyecto centrado en la nube pública hasta 2014. OpenShift se lanzó antes de ambos, con un enfoque en los hosts implementados en data centers locales.

La simple implementación de los tiempos de ejecución de contenedores en un host local generalmente satisface las necesidades de los desarrolladores, ya que los tiempos de ejecución pueden comunicarse entre sí a través de “localhost” y puertos únicos. A los tiempos de ejecución del contenedor no se les asignan direcciones IP específicas. Si está enfocado en escribir código rápido y eficiente e implementar su aplicación en una colección de tiempos de ejecución de contenedores asociados, este enfoque funciona bien. Pero si desea que esa aplicación acceda a recursos externos fuera del host local, o si desea que clientes externos accedan a esa aplicación, no puede ignorar los detalles de la red. Esta es una de las razones por las que se necesita un sistema de orquestación.

Kubernetes se creó en torno a un conjunto de bloques de construcción y un flujo de trabajo basado en API para organizar el comportamiento de los tiempos de ejecución de los contenedores. En este enfoque, Kubernetes crea una serie de construcciones lógicas dentro y entre hosts asociados con un entorno contenerizado específico, y crea un conjunto completamente nuevo de vocabulario para referirse a estas construcciones. Si bien Kubernetes aplica estos bloques de construcción y flujos de trabajo impulsados por API en torno a un conjunto de métricas de computación asociadas con la asignación de CPU, los requisitos de memoria y otras métricas como almacenamiento, autenticación y medición, la mayoría de los profesionales de seguridad y redes se centran en una cosa:

¿Por qué límites pasa un paquete IP cuando está en ruta hacia alguna construcción lógica a la que se le asigna una dirección IP?

Desde una perspectiva de networking, tanto Kubernetes como OpenShift crean constructos lógicos y relevantes en un enfoque jerárquico, con solo una ligera diferencia de vocabulario entre cada sistema. Esto se ilustra a continuación.

El ABC de los clústeres de contenedores

Este diagrama muestra la construcción lógica básica de un entorno Kubernetes. No explica lo que hace cada constructo, sino solo cómo se relacionan lógicamente entre sí.

Comenzando desde la construcción más amplia hasta la más pequeña, aquí hay explicaciones rápidas:

• Clúster: Un cluster es la colección de hosts asociados con una implementación en contenedores específica.
• Nodos: Dentro de un cluster, hay nodos. Un nodo es el host en el que residen los contenedores. Un host puede ser una computadora física o una máquina virtual, y puede residir en un centro de datos local o en una nube pública. Generalmente, hay dos categorías de nodos en un cluster: los “nodos maestros” y los “nodos de trabajo”. Para simplificar en exceso las cosas, un nodo maestro es el plano de control que proporciona la base de datos central del cluster y el servidor API. Los nodos de trabajo son las máquinas que ejecutan los pods de aplicaciones reales.
• Pods: Dentro de cada nodo, tanto Kubernetes como OpenShift crean pods. Cada pod abarca uno o más tiempos de ejecución de contenedores y es administrado por el sistema de orquestación. Kubernetes y OpenShift asignan direcciones IP a los pods.
• Contenedor: Dentro de las vainas es donde residen los tiempos de ejecución de los contenedores. Todos los contenedores dentro de un pod determinado comparten la misma dirección IP que ese pod y se comunican entre sí a través de Localhost, utilizando puertos únicos.
• Espacio de nombres: Una aplicación determinada se implementa “horizontalmente” sobre varios nodos en un cluster y define un límite lógico para asignar recursos y permisos. Los pods (y, por lo tanto, los contenedores) y los servicios, pero también los roles, secretos y muchas otras construcciones lógicas pertenecen a un espacio de nombres. OpenShift llama a esto un proyecto, pero es el mismo concepto. En términos generales, un espacio de nombres se asigna a una aplicación específica, que se implementa en todos los contenedores asociados dentro de ella. Un espacio de nombres no tiene nada que ver con una construcción de red y seguridad (diferente de un espacio de nombres IP de Linux)
• Servicio: Dado que los pods pueden ser efímeros (pueden desaparecer repentinamente y luego volver a implementarse dinámicamente), un servicio es un “front-end”, que se implementa frente a un conjunto de pods asociados y funciona como un equilibrador de carga con un VIP que no desaparece si desaparece un pod. Un servicio es una construcción lógica no efímera, con su propia dirección IP. Con solo unas pocas excepciones dentro de Kubernetes y OpenShift, las conexiones externas apuntan a la dirección IP de un servicio y luego se reenvían a los pods “backend”.
• Servidor API de Kubernetes: Aquí es donde se centraliza el flujo de trabajo de API, con Kubernetes administrando la creación y el ciclo de vida de todas estas construcciones lógicas.

Desafíos de seguridad con contenedores

Para crear segmentos de seguridad a lo largo de los límites de la carga de trabajo, es necesario comprender estas construcciones lógicas básicas creadas por Kubernetes. El tráfico de red externa que se mueve dentro y fuera de la aplicación alojada generalmente no apuntará a la dirección IP del host subyacente, el nodo. En su lugar, el tráfico de red apuntará a un servicio o a un pod dentro de ese host. Por lo tanto, los servicios y pods asociados a una carga de trabajo deben entenderse lo suficiente para crear un arquitectura de seguridad de segmentación efectiva.

¿Interesado en más? Echa un vistazo nuestro documento sobre los desafíos de los enfoques basados en la red para la segmentación de contenedores y cómo superarlos mediante la segmentación basada en host.