Herramientas de redes

GKE On-Prem usa conceptos de herramientas de redes de Kubernetes, como Ingress y Service. En este documento, se describe cómo se configuran las herramientas de redes de GKE On-Prem listas para usar.

Operaciones de servicios de clúster y modo isla

GKE On-Prem usa una configuración de modo isla en la que los Pods pueden comunicarse directamente entre sí dentro de un clúster, pero no se puede acceder a ellos desde fuera del clúster. Esta configuración forma una “isla” dentro de la red, que no está conectada a la red externa. Los clústeres forman una malla de nodo a nodo completa en los nodos del clúster, lo que permite que el Pod llegue directamente a otros Pods.

La IP del nodo aplica la NAT a todo el tráfico de salida del Pod a destinos fuera del clúster. GKE On-Prem incluye un balanceador de cargas de capa 7 con un controlador de Ingress basado en Envoy que controla las reglas de los objetos Ingress para los Services de tipo ClusterIP que se implementaron en el clúster. El controlador de Ingress se expone como un Service de tipo NodePort en el clúster.

Se puede acceder al Service de tipo NodePort de entrada a través de un balanceador de cargas de F5 de capa 3 y 4. La instalación configura una dirección IP virtual (VIP) (con los puertos 80 y 443) en el balanceador de cargas. La VIP apunta a los puertos en el Service de tipo NodePort para el controlador Ingress. Así es como los clientes externos pueden acceder a los servicios en el clúster.

Los clústeres de usuario pueden ejecutar Services de tipo LoadBalancer siempre que un campo loadBalancerIP esté configurado en la especificación del Service. En el campo loadBalancerIP, debes proporcionar la VIP que deseas usar. Esto se configurará en F5 y se vinculará con los NodePorts del Service.

Como alternativa al uso del balanceador de cargas de F5, puedes habilitar el modo de balanceo de cargas manual. Si eliges usar el balanceo de cargas manual, no puedes ejecutar servicios de tipo LoadBalancer. En su lugar, puedes crear Services de tipo NodePort y configurar de forma manual el balanceador de cargas para usarlos como backends. Además, puedes exponer Services a clientes externos mediante un objeto Ingress.

Nota: “externalTrafficPolicy”: “Local” no es compatible actualmente con la integración de BIG-IP de F5.

Compatibilidad con VMware NSX-T

A partir de la versión 1.2.0-gke.6, GKE On-Prem es compatible con VMware NSX-T versión 2.4.2.

Arquitectura de las herramientas de redes

^{Herramientas de redes de GKE On-Prem}

Direcciones IP de nodos

Son direcciones IP DHCP o asignadas de forma estática para los nodos (también denominados máquinas virtuales o VM). Deben ser enrutables dentro del centro de datos. Puedes asignar IP estáticas de forma manual.

Bloque CIDR del Pod

Es un bloque CIDR no enrutable para todos los Pods del clúster. Desde este rango, se asignan rangos de /24 más pequeños por nodo. Si necesitas un clúster de N nodos, asegúrate de que este bloque tenga el tamaño suficiente para admitir N bloques de /24.

Bloque CIDR de servicios

En modo isla, es similar al bloque CIDR del Pod, por lo que solo se usa dentro del clúster. Puede ser cualquier bloque CIDR privado que no se superponga con los nodos, VIP o el bloque CIDR de Pods. Puedes compartir el mismo bloque entre los clústeres. El tamaño del bloque determina la cantidad de servicios. Se necesita una IP de Service para el servicio de Ingress y diez o más IP para los servicios de Kubernetes, como el DNS del clúster, entre otros.

VIP de Services

Es la cantidad de direcciones IP enrutables que se configurarán en F5 para la entrada de capa 4 cuando expongas un Service. Estas VIP son las mismas que los valores de loadBalancerIP que configuras cuando creas Services de tipo LoadBalancer.

VIP del plano de control

Una dirección IP enrutable que se configurará en el balanceador de cargas de F5 para el servidor de la API de Kubernetes.

VIP de Ingress

Una dirección IP enrutable que se configurará en el balanceador de cargas de F5 para la entrada de capa 7 junto con los proxies de Envoy que se ejecutan en cada nodo.

Opciones de configuración de las herramientas de redes

Tienes varias opciones para configurar las herramientas de redes de los clústeres:

• Puedes elegir una red de vCenter global o usar una red de vCenter diferente para los clústeres de administrador y de usuario.
• Puedes usar un proxy HTTP y elegir qué direcciones deseas excluir del proxy.
• Puedes elegir la asignación de IP estática o DHCP.
• Puedes elegir el modo de balanceo de cargas integrado o manual.

Durante la instalación, debes especificar tus preferencias en el archivo de configuración de GKE On-Prem.

Configuración de la red de vCenter

El campo network del archivo de configuración determina qué red de vCenter se debe usar para los clústeres:

• El campo vcenter.network global especifica una red en particular.
• admincluster.vcenter.network anula el campo global y especifica la red que se usará para el clúster de administrador.
• usercluster.vcenter.network anula el campo global y especifica la red que se usará para el clúster de usuario.

Ejemplo: Accede a una aplicación web a través de una URL

Supongamos que tienes una aplicación web de libro de visitas que se ejecuta en el clúster como un Deployment llamado frontend. Quieres conectarte a la aplicación con una URL: www.guestbook.com. Necesitas alguna forma de mapear la URL al objeto Deployment que se ejecuta en el clúster. Puedes hacer esto con un objeto Ingress de Kubernetes.

Primero, debes crear una entrada de DNS comodín para *.guestbook.com que apunte a la VIP de entrada existente del clúster:

*.guestbook.com    A   [INGRESS_VIP]

A continuación, debes crear un Service para el Deployment de frontend. La ejecución de kubectl expose crea un Service que agrupa de forma lógica los Pods de Deployment y les proporciona una dirección IP común dentro del clúster:

kubectl expose deployment frontend

Esto crea un Service de tipo ClusterIP como el siguiente:

apiVersion: v1
kind: Service
metadata:
  labels:
    app: guestbook
  name: frontend
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: guestbook
  type: ClusterIP

Debes mapear la URL, www.guestbook.com, al Service de frontend que acabas de crear. Si aplicas el Ingress que aparece a continuación, se crea ese mapa:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: frontend
  labels:
    app: guestbook
spec:
  rules:
    - host: www.guestbook.com
      http:
        paths:
          - backend:
              serviceName: frontend   # name of the frontend Service
              servicePort: 80

Ahora, si visitas www.guestbook.com, se abrirá la aplicación web en el navegador.

A continuación, te mostramos cómo funciona de forma interna:

• Debido a que creaste esa entrada de DNS comodín, cuando visitas la URL, estás accediendo a la VIP de entrada del clúster.
• El clúster busca el objeto Ingress correcto según el nombre de host, que en este caso es www.guestbook.com.
• El tráfico se redirecciona a un Pod de frontend.

Ejemplo: Accede a una aplicación web a través de la dirección IP

Si la aplicación no es una aplicación web, o si tienes restricciones de herramientas de redes, es posible que prefieras crear una VIP específica para el servicio. Puedes hacerlo con un Service de Kubernetes de tipo LoadBalancer.

El Service que se muestra a continuación crea una VIP específica para la aplicación guestbook:

apiVersion: v1
kind: Service
metadata:
  labels:
    app: guestbook
  name: frontend
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: guestbook
  type: LoadBalancer
  loadBalancerIP: [IP_ADDRESS]
  

Después de aplicar este Service, verás la VIP en la consola de F5. En el menú Pools de la consola, verás las direcciones IP de los nodos. Si visitas la dirección IP, se cargará la aplicación.