Versión 1.7. Esta versión es compatible como se describe en la política de asistencia de la versión de Anthos, que ofrece los últimos parches y actualizaciones de vulnerabilidades de seguridad, exposiciones y problemas que afectan a los clústeres de Anthos alojados en VMware (GKE On-Prem). Consulta las notas de la versión para obtener más detalles. Esta no es la versión más reciente.

Redes

Los clústeres de Anthos alojados en VMware (GKE On-Prem) usan conceptos de herramientas de redes de Kubernetes, como Service e Ingress. En este documento, se describe cómo se configuran de forma inmediata las herramientas de redes de los clústeres de Anthos alojados en VMware.

Operaciones de servicios de clúster y modo isla

Los clústeres de Anthos alojados en VMware usan una configuración de modo Island en el que los pods pueden comunicarse directamente entre sí dentro de un clúster, pero no se puede acceder 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. Los clústeres de Anthos alojados en VMware incluyen un balanceador de cargas L7 con un controlador de entrada basado en Envoy que controla las reglas de objetos de Ingress para los servicios ClusterIP implementados dentro del 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 configura en el balanceador de cargas y se vinculará con los NodePorts del Service.

Los clústeres de Anthos alojados en VMware admiten varias opciones de balanceo de cargas:

  • Balanceo de cargas en paquetes con Seesaw
  • Balanceo de cargas integrado con F5 BIG-IP
  • Balanceo de cargas manual con BIG-IP de F5
  • Balanceo manual de cargas con Citrix

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.

Compatibilidad con VMware NSX-T

A partir de la versión 1.2.0-gke.6, los clústeres de Anthos en VMware admiten la versión 2.4.2 de VMware NSX-T.

Arquitectura de las herramientas de redes

Diagrama que describe la arquitectura de los clústeres de Anthos alojados en VMware Herramientas de redes de clústeres de Anthos alojados en VMware

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
Es 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
Es 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, especifica tus preferencias en el archivo de configuración del clúster.

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
  annotations:
    kubernetes.io/ingress.class: istio
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.