Virtualización y contenedores en Kubernetes: NetworkPolicies.

1 La necesidad de escenarios intermedios de migración a Cloud Native

Hace unos días empezamos una serie de post, sobre virtualización y contenedores en Kubernetes: despliegue y networking, donde profundizamos en esta problemática.

En la transformación digital, los roadmaps incluyen estrategias de transición como "lift and shift" o "improve and move" para minimizar riesgos en la migración hacia la nube. Sin embargo, desafíos como soluciones propietarias, aplicaciones complejas o regulaciones pueden exigir una transición más suave.

Migrar completamente a plataformas basadas en contenedores puede no ser siempre posible o recomendable, siendo pragmáticos con la adopción de Kubernetes. La estrategia usual, que fuerza la migración a contenedores, podría resultar en máquinas virtuales disfrazadas de contenedores y no aprovechar los beneficios de la plataforma cloud native.

Una estrategia más razonable implica una mezcla de servicios virtualizados y contenedores, permitiendo diferentes velocidades de transición y una adopción segura de la nube. Este enfoque híbrido plantea el desafío de gestionar ambas tecnologías.

Aunque puede ser tentador desplegar una plataforma de virtualización junto a Kubernetes, esta arquitectura mixta puede resultar en una gestión duplicada. Esto impacta la velocidad de entrega y aumenta la complejidad. Para aplicaciones híbridas, el despliegue queda dividido en dos plataformas separadas.

Kubernetes como plataforma única de virtualización y contenedores: KubeVirt

KubeVirt es un operador de Kubernetes que permite desplegar y administrar máquinas virtuales en Kubernetes, extendiendo sus capacidades para gestionar cargas virtualizadas, permitiendo así combinar máquinas virtuales y contenedores en un clúster de Kubernetes.

Gracias a esta tecnología, es posible simplificar la gestión y eliminar la necesidad de plataformas separadas para los servicios virtualizados y los contenedores. El dominio de una aplicación cloud native híbrida se circunscribe a la Kubernetes, permitiendo una gestión unificada de la aplicación.

Las ventajas de KubeVirt son numerosas, pero destacan las siguientes:

• Integración nativa con Kubernetes: KubeVirt opera como cualquier otro recurso de Kubernetes, lo que permite gestionar las máquinas virtuales de la misma manera que los contenedores. Se estandariza así toda la operación, tooling y procesos para las aplicaciones.
• Plataforma única de orquestación: se elimina la gestión duplicada asociada a disponer de dos plataformas separadas (virtualización, contenedores). KubeVirt permite unificar la gestión de la virtualización y la contenerización sobre Kubernetes.
• Adaptación a diferentes velocidades de modernización: KubeVirt permite que cada aplicación pueda trabajar a un ritmo diferente de modernización sin por ello lastrar el reto de modernización.

Retomando el ejemplo aplicación cloud native híbrida

En el post anterior se definió una aplicación cloud native híbrida con el objetivo de resolver el despliegue completo de la misma, donde convivirán contenedores con máquinas virtuales.

Una aplicación cloud native híbrida es aquella cuyo dominio está compuesto de servicios virtualizados y contenedores.

La aplicación tiene dos componentes fundamentales:

• Una aplicación python que expone un endpoint. La aplicación imprime un mensaje de bienvenida que incluye un nombre extraído de una base de datos mongoDB.
• Una base de datos MongoDB con una colección de datos que contiene un nombre.

En este escenario, la aplicación python ya está migrada a contenedores, pero la base de datos aún está virtualizada.

Implementación con Kubevirt

Nota: Esta es una aplicación de ejemplo desarrollada para la demostración de este caso de uso. No se han aplicado prácticas de seguridad o gestión de la configuración, entre otros asuntos.

En la primera parte de esta serie de post resolvimos tanto el despliegue conjunto como la comunicación entre los componentes de la aplicación cloud native híbrida.

El escenario final simplificado era el siguiente:

Protegiendo el acceso a la base de datos

En este escenario, todos los pods dentro del namespace podrían comunicarse con la base de datos virtualizada, pero podríamos necesitar proteger aún más este acceso añadiendo restricciones más específicas para controlar qué elementos del clúster pueden comunicarse con la base de datos virtualizada. Por ejemplo:

• No permitir la comunicación desde otros namespaces.
• Solo permitir la comunicación de ciertos pods del mismo namespace.

Para lograrlo podemos emplear recursos nativos de Kubernetes, como las NetworkPolicy.

Al definir una NetworkPolicy, se puede especificar explícitamente qué tráfico se permite entre los pods y, en este caso concreto, garantizar que solo la aplicación Python pueda comunicarse con la base de datos virtualizada.

Utilizar NetworkPolicies es una buena práctica de seguridad, ya que proporciona un mayor control sobre las comunicaciones entre los pods en el clúster y ayuda a proteger los recursos y aplicaciones frente a accesos no autorizados o no deseados.

Network Policy

Definamos una política para impedir que los pods del mismo namespace que no cumplan con el criterio de la regla Ingress accedan a la base de datos.

La regla de Ingress definida solo permite la comunicación desde pods que cumplen el criterio definido incluso dentro del mismo namespace.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: mongodb-network-policy
  namespace: kubevirt-networking-poc
spec:
  podSelector:
    matchLabels:
      kubevirt.io/domain: mongodb-vm
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: kubevirt-networking-poc
    ports:
    - protocol: TCP
      port: 27017

La especificación del recurso NetworkPolicy incluye la siguiente información:

• Metadatos: el NetworkPolicy se llama mongodb-network-policy.
• Selector de pods: el selector de pods utiliza la etiqueta kubevirt.io/domain: mongodb-vm para aplicar la política de red a la máquina virtual que ejecuta MongoDB. Esto asegura que las reglas definidas en esta política solo afecten a la máquina virtual en cuestión.
• Tipos de política: la política se aplica al tráfico entrante (Ingress), lo que significa que controla cómo otros pods en el clúster pueden comunicarse con la máquina virtual que ejecuta MongoDB.
• Reglas de ingress: la regla de ingress especifica que solo los pods que tienen una determinada label dentro del namespace ("app: kubevirt-networking-poc") tienen permitido el acceso a la base de datos. El resto de pods incluso en el mismo namespace no pueden acceder a la base de datos.

Explicación del flujo de red desde una petición externa

Cuando un usuario realiza una solicitud a la URL de la aplicación web, el flujo de red en términos de comunicación entre los componentes del despliegue es el siguiente:

Donde se puede apreciar cómo la Network Policy regula la comunicación y permite la conexión entre el Pod de la aplicación Python y el servicio virtualizado Mongodb.

Resultado final

El resultado final para un usuario no varía respecto a lo que vimos en la primera parte.

Cuando un usuario invoque el endpoint que expone el servicio asociado a la aplicación Python, recibirá esta respuesta:

Show me the code!

Todo el código está disponible en este repositorio.

2 Ventajas de la convivencia de virtualización y contenedores en Kubernetes

Combinación de recursos de Kubernetes con virtualización

Esta serie de posts pretende demostrar cómo unificar la operación de una aplicación cloud native híbrida en Kubernetes.

En este caso, hemos añadido una NetworkPolicy para aplicar políticas más específicas de acceso a la base de datos virtualizada.

Esta NetworkPolicy nos permite regular el acceso de diferentes formas, bien por namespaces, bien por selección de pods vía etiquetas

KubeVirt dispone también de documentación y recomendaciones sobre el uso de Network Policies en el contexto de la virtualización.

Conclusiones

• KubeVirt permite combinar recursos de Kubernetes junto con los servicios virtualizados, simplificando la operativa.
• La virtualización queda definida como un recurso de Kubernetes que puede combinarse a su vez con otras capacidades del clúster (storage, networking).
• Se elimina la necesidad de una plataforma de virtualización aislada y una doble gestión en la operación de una aplicación híbrida.
• Se garantiza un escenario de transición a cloud native que permitirá adoptar diferentes velocidades a los equipos de desarrollo sin sacrificar por ello la operación de la plataforma o la experiencia de desarrollo.
• El equipo de desarrollo y el equipo de plataforma pueden definir una estrategia kubernetes-centric para la modernización de aplicaciones, sin renunciar a la virtualización.
• Se simplifican todas las capacidades transversales, como observabilidad, seguridad, gobierno o disaster recovery.

Evolución de aplicaciones cloud native híbridas

¿Queréis profundizar aún más en el uso de virtualización en Kubernetes? Entonces, no os perdáis el próximo post en que añadiremos más complejidad a esta aplicación de ejemplo para abordar temas como el uso de certificados, observabilidad o políticas.