Saltar al contenido principal

la red en Kubernetes administrado

Objetivos​

Este tutorial tiene como objetivo familiarizarle con los conceptos de red fundamentales de la oferta Managed Kubernetes. Al final de esta guía, podrá:

  • Comprender el plan de direccionamiento IP de su clúster (nodos, pods, servicios).
  • Conocer los diferentes mecanismos para exponer sus aplicaciones (Ingress, LoadBalancer).
  • Visualizar los flujos de red y las políticas de seguridad con Hubble.

Tomaremos como ejemplo un clúster "ctodev", cuyo rango asignado es 10.20.0.0/22

:::warning[definición de rangos ] Este rango de IP privadas X.Y.Z.0/22 (RFC 1918) se define con el cliente durante la implementación del clúster. No se puede modificar posteriormente. :::

Plan de direccionamiento IP​

Su clúster de Kubernetes gestionado dispone de un VLAN multi-zona con un rango de direcciones IPv4 /22.

El rango de nuestro ejemplo 10.20.0.0/22 se divide lógicamente en subrangos.

  • 10.20.0.0/24 está asignado a los Nodos del clúster:

    • 10.20.0.10 : ctodev-gitrunner (la machine qui pilote l'infrastructure)

    • 10.20.0.20 : IP virtual (load balancée) del servicio API de Kubernetes

    • 10.20.0.21 : ctodev-cp-01 (control plane 01)

    • 10.20.0.22 : ctodev-cp-02 (control plane 02)

    • 10.20.0.23 : ctodev-cp-03 (control plane 03)

    • 10.20.0.41 : ctodev-ceph-01 (Ceph Storage 01)

    • 10.20.0.42 : ctodev-ceph-02 (Ceph Storage 02)

    • 10.20.0.43 : ctodev-ceph-03 (Ceph Storage 03)

    • 10.20.0.51 : ctodev-wrk-01 (Worker 01)

    • 10.20.0.52 : ctodev-wrk-02 (Worker 02)

    • 10.20.0.53 : ctodev-wrk-03 (Worker 03)

    • ...

    • 10.20.0.151 : ctodev-wrk-100 (Worker 100)

  • MetalLB interno : 10.20.1.1 – 10.20.1.127

    • 10.20.1.1 : ingress nginx-internal

  • MetalLB externo : 10.20.1.128 – 10.20.1.254

    • 10.20.1.128 : ingress nginx-external
    • 10.20.1.129 : ingress nginx-external-secure

  • Pods: 10.241.0.0/16

  • Servicios: 10.95.0.0/12

:::warning[Ranges Pods et Services ] Los rangos de Pods y Servicios se definen junto con el cliente durante el despliegue del clúster. No se pueden modificar posteriormente. :::

Uso de MetalLB​

MetalLB es el componente que permite exponer servicios de capa 3 (no web / L7) directamente en una dirección IP, ya sea interna o externa, utilizando el tipo de servicio LoadBalancer. Es una alternativa a los Ingress para aplicaciones no HTTP o para casos de uso específicos.

Para utilizar MetalLB, solo necesitas crear un servicio de tipo LoadBalancer. MetalLB le asignará automáticamente una dirección IP desde los rangos preconfigurados. La distinción entre los rangos interno y externo es una medida de seguridad para garantizar que una aplicación destinada al uso interno no se exponga por error en una red pública.

Ejemplo: Exponer un servicio en la red interna

apiVersion: v1
kind: Service
metadata:
  name: mon-service-interne
  namespace: mon-namespace
spec:
  selector:
    app: mon-app
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 80
  type: LoadBalancer

Una vez aplicado este manifiesto, tu servicio recibirá una dirección IP en el rango 10.20.1.1 – 10.20.1.127 y será accesible desde tu red interna conectada al clúster.

Ejemplo: Exponer un servicio en la red externa

Para solicitar una dirección IP desde el rango externo (10.20.1.128 – 10.20.1.254), debes agregar la etiqueta lb-type: external a tu servicio.

apiVersion: v1
kind: Service
metadata:
  name: mon-service-externe
  namespace: mon-namespace
  labels:
    lb-type: external
spec:
  selector:
    app: mon-app
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 80
  type: LoadBalancer

Importante: Este rango permanece dentro de un espacio de direccionamiento privado. Para una exposición pública, es necesario crear una regla NAT (DNAT) en el firewall de tu infraestructura para redirigir el tráfico de una de tus IPs públicas externas hacia la dirección IP privada asignada por MetalLB.

Direcciones IP Públicas​

Su clúster de Kubernetes administrado se entregó originalmente con 2 direcciones IPv4 públicas.

La 1ª IP se utiliza en el puerto 6443 para la API de Kubernetes (en nuestro ejemplo ctodev.mk.ms-cloud-temple.com:6443)

Esta misma IP también está NATeada en el controlador de ingress "nginx-external-secured" para el puerto 443. Esto permite la exposición de las diferentes consolas puestas a su disposición (consulte la guía de inicio rápido). Los accesos a esta IP pública están filtrados mediante una lista de IPs permitidas.

La 2ª IP pública está NATeada en el controlador de ingress "nginx-external", en los puertos 80 y 443.

Las aplicaciones expuestas con la clase de ingress "nginx-external" serán directamente accesibles desde Internet a través de esta IP.

Si desea modificar las reglas del firewall (agregar/eliminar IPs permitidas), debe realizar una solicitud de soporte.

Es posible agregar otras IPs públicas si lo desea.

DNS​

Para el DNS interno (CoreDNS), el clúster tendrá estos parámetros:

  • Nombre del clúster: <identificador del clúster>
  • Dominio interno: <identificador del clúster>-cluster.local (dans notre exemple : ctodev-cluster.local)

Este dominio interno es crucial para la comunicación entre servicios dentro del clúster. Permite que una aplicación se comunique con otra utilizando simplemente su nombre de servicio de Kubernetes, sin necesidad de conocer su dirección IP interna.

Por ejemplo, un servicio llamado api-backend en el namespace production será automáticamente resuelto en la dirección api-backend.production.svc.ctodev-cluster.local.

La zona DNS pública utilizada para los clústeres de Kubernetes administrados es .mk.ms-cloud-temple.com

El ingress "nginx-external" (mappé sur l'IP publique n°2) es accesible en "*.external.<votre identifiant de cluster>.mk.ms-cloud-temple.com". Si publica una aplicación con este ingress-class, podrá acceder a ella directamente mediante este nombre de dominio. Consulte el tutorial: Despliegue de su primera aplicación

Hubble : La observabilidad de red al alcance de la mano​

Hubble es una interfaz gráfica y de línea de comandos para visualizar y comprender los flujos de red de tu cluster. Basado en Cilium, te ofrece un mapa detallado de los servicios, las dependencias y las políticas de red en tiempo real.

Con Hubble, puedes :

  • Visualizar los flujos de tráfico entre tus pods y servicios.
  • Identificar problemas de conectividad y errores de red.
  • Verificar la aplicación de tus políticas de seguridad (Network Policies).
  • Explorar las dependencias entre tus diferentes aplicaciones.

Acceder a la interfaz de Hubble​

La interfaz gráfica de Hubble está expuesta en una URL interna de su clúster. El acceso no es posible mediante un port-forwarding kubectl ya que los usuarios no tienen los permisos suficientes en el namespace kube-system.

Para acceder, debe estar conectado a la red interna del clúster (por ejemplo, a través de un bastión o una VPN). La URL a utilizar es la siguiente:

http://hubble.internal.<votre-identifiant-de-cluster>.mk.ms-cloud-temple.com

Para que esta URL sea resoluble por su estación de trabajo, probablemente deberá agregar una entrada en su archivo hosts o en su DNS interno. Puede obtener la dirección IP interna del Ingress de Hubble con el siguiente comando:

kubectl get ingress hubble-ui -n kube-system

Creación de zonas DNS internas (clúster privado)​

Para reforzar la seguridad y simplificar el acceso a sus servicios y a la API de Kubernetes desde su red interna, se recomienda crear una zona DNS interna. Esta zona permitirá resolver los nombres de dominio de sus Ingress y de la API de Kubernetes hacia sus direcciones IP privadas correspondientes, evitando así el tránsito por redes públicas.

Ejemplo de configuración con nuestro clúster "ctodev", cuyo rango asignado es 10.20.0.0/22 :

Basándose en las URLs proporcionadas en la guía de inicio, puede configurar su DNS interno de la siguiente manera:

  1. Cree la zona DNS privada en sus servidores DNS internos para .<identifiant du cluster>.mk.ms-cloud-temple.com

  2. Agregue los registros de tipo A siguientes :

    • Para la API de Kubernetes :

      • . -> 10.20.0.20 (IP virtual de la API)

    • Para los servicios internos (vía el Ingress nginx-internal) :

      • hubble.internal -> 10.20.1.1
      • argocd.internal -> 10.20.1.1
      • ceph.internal -> 10.20.1.1

    • Para los servicios seguros (vía el Ingress nginx-external-secure) :

      • k10.external-secured -> 10.20.1.129
      • grafana.external-secured -> 10.20.1.129
      • harbor.external-secured -> 10.20.1.129
      • opencost.external-secured -> 10.20.1.129
      • opencost-mcp.external-secured -> 10.20.1.129

Esta configuración garantiza que el tráfico hacia la API y los servicios internos permanezca confinado a su red privada, conforme a las mejores prácticas de seguridad.

Tutoriel : Déployer votre première application

Suivez notre guide détaillé pour apprendre à exposer une application en utilisant un Ingress.

Voir le tutoriel →

:::warning[Para ir más allá: la seguridad en producción ] Este documento explica los conceptos de red fundamentales. Para un despliegue en producción, es crucial aplicar medidas de seguridad adicionales:

  • Utilice imágenes seguras : Priorice imágenes provenientes de su registro de empresa seguro como Harbor en lugar de imágenes públicas.
  • Controle los flujos de red : Implemente NetworkPolicies para controlar las comunicaciones únicamente a los flujos necesarios entre sus aplicaciones.
  • Aplique políticas de gobernanza : Utilice herramientas como Kyverno para imponer reglas de seguridad (ej: prohibir contenedores "root", exigir requests y limits de recursos, etc.). :::