Versión 1.0. Esta versión ya no es compatible como se describe en la política de compatibilidad de versiones de Anthos. Para obtener los últimos parches y actualizaciones de vulnerabilidades de seguridad, exposiciones y problemas que afectan a clústeres de Anthos alojados en VMware (GKE On-Prem), actualiza a una versión compatible. Puedes encontrar la versión más reciente aquí.

Versiones disponibles

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 de inmediato.

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 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 usan BGP (a través del complemento de la CNI de Calico) para formar una malla de nodo a nodo completa en los nodos del clúster, lo que permite que el Pod llegue a otros Pods dentro del clúster de forma directa.

Todo el tráfico de salida del Pod a destinos fuera del clúster se NAT por la IP del nodo. GKE On-Prem incluye un balanceador de cargas L7 con un controlador de Ingress basado en Envoy que controla las reglas de los objetos Ingress para los servicios 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.

Arquitectura de las herramientas de redes

Diagrama en el que se describe la arquitectura de GKE On-Prem ^{Figura: 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 servicio para el servicio de entrada y diez o más IP para los servicios de Kubernetes, como DNS del clúster, etcétera.
VIP de objetos Service: La cantidad de direcciones IP enrutables que se configurarán en F5 para la entrada L4 cuando expongas un Service. Estas VIP son iguales al valor loadBalancerIP que generaste para crear servicios 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: 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.

Configuración `network`

Estos parámetros se capturan en el campo network del archivo de configuración del clúster.

A continuación, se muestra un ejemplo de un campo network que especifica la mayoría de los parámetros:

# Example of a network section with static node IPs
network:
  clusterip:
    servicecidr: 10.96.232.0/24
    podcidr: 192.168.0.0/16
  nodeip:
    mode: static
    addressblock:
      hostconfig:
        dns: 8.8.8.8
        tod: 192.138.210.214
      blocks:
        - netmask: 255.255.252.0
          gateway: 10.116.232.0
          ips:
            - ip: 10.116.232.23
              hostname: host1.enterprise.net
            - ip: 10.116.232.65
              hostname: host2.enterprise.net
            - ip: 10.116.232.66
              hostname: host3.enterprise.net
  loadbalancer:
    controlplaneip: 10.115.231.45
    ingressip: 10.115.231.54
    kind: F5BigIP
    f5bigip:
      server: 10.113.24.12
      username: # encoded value
      password: # encoded value
      partition: admin-partition

El campo network consta de tres subcampos, clusterip, nodeip y loadbalancer, que establecen diferentes parámetros de configuración de red para el clúster. El subcampo nodeip.blocks es opcional. Solo debes especificar este campo si nodeip.mode está configurado como estático.

Si los nodos están configurados para obtener las IP a través de DHCP, debes configurar el campo network de la siguiente manera:

# Example of a network section using DHCP for node IPs
network:
  clusterip:
    servicecidr: 10.96.232.0/24
    podcidr: 192.168.0.0/16
  nodeip:
    mode: dhcp
  loadbalancer:
    controlplaneip: 10.115.231.45
    ingressip: 10.115.231.54
    kind: F5BigIP
    f5bigip:
      server: 10.113.24.12
      username: admin
      password: secret
      partition: user-partition

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.

Descripción general de GKE On-Prem

Conectarse a Google