Funciones de redes de Distributed Cloud

En esta página, se describen las funciones de redes de Google Distributed Cloud, incluidas las subredes, las sesiones de intercambio de tráfico de BGP y el balanceo de cargas.

Los procedimientos de esta página solo se aplican a los racks de Distributed Cloud, excepto el balanceo de cargas, que se aplica tanto a los racks de Distributed Cloud como a los servidores de redes de Distributed Cloud.

Habilita la API de Distributed Cloud Edge Network

Antes de configurar las redes de Distributed Cloud, debes habilitar la API de Distributed Cloud Edge Network. Para ello, completa los pasos de esta sección. De forma predeterminada, los servidores de Distributed Cloud se envían con la API de Distributed Cloud Edge Network ya habilitada.

Console

  1. En la consola de Google Cloud , ve a la página de la API de Distributed Cloud Edge Network.

    Habilitar la API

  2. Haz clic en Habilitar.

gcloud

Usa el siguiente comando:

gcloud services enable edgenetwork.googleapis.com

Configura las redes de Distributed Cloud

En esta sección, se describe cómo configurar los componentes de redes de Distributed Cloud.

Se aplican las siguientes limitaciones a los servidores de Distributed Cloud:

  • Solo puedes configurar subredes.
  • Las subredes solo admiten IDs de VLAN; no se admiten las subredes basadas en CIDR.

Una configuración de red típica para Distributed Cloud consta de los siguientes pasos:

  1. Opcional: Inicializa la configuración de red de la zona de destino, si es necesario.

  2. Crear una red

  3. Crea una o más subredes dentro de la red.

  4. Establece sesiones de intercambio de tráfico de BGP en dirección norte con tus routers PE usando los adjuntos de interconexión correspondientes.

  5. Establece sesiones de peering de BGP de sur a norte con los Pods que ejecutan tus cargas de trabajo a través de las subredes correspondientes.

  6. Opcional: Establece sesiones de peering de BGP de bucle invertido para lograr alta disponibilidad.

  7. Prueba la configuración.

  8. Conecta los Pods a la red.

Opcional: Inicializa la configuración de red de la zona de Distributed Cloud

Debes inicializar la configuración de red de tu zona de Distributed Cloud en los siguientes casos:

  • Inmediatamente después de que se instale el hardware de Distributed Cloud en tus instalaciones
  • Actualizaste a la versión 1.3.0 o posterior de Distributed Cloud en una implementación existente de Distributed Cloud, pero no participaste en la versión preliminar privada de la API de Distributed Cloud Edge Network.

Cuando se inicializa la configuración de red de una zona, se crea un router predeterminado llamado default y una red predeterminada llamada default. También configura el router default para que se conecte con todos los dispositivos de interconexión que solicitaste cuando pediste el hardware de Distributed Cloud, creando los archivos adjuntos de interconexión correspondientes. Esta configuración proporciona a tu implementación de Distributed Cloud conectividad básica de vínculo ascendente a tu red local.

La inicialización de la configuración de red de una zona es un procedimiento que se realiza una sola vez. Para obtener instrucciones completas, consulta Inicializa la configuración de red de una zona.

Crea una red

Para crear una red nueva, sigue las instrucciones en Cómo crear una red. También debes crear al menos una subred dentro de la red para permitir que los nodos de Distributed Cloud se conecten a ella.

Crea una o más subredes

Para crear una subred, sigue las instrucciones en Crea una subred. Debes crear al menos una subred en tu red para permitir que los nodos accedan a ella. La VLAN correspondiente a cada subred que crees estará disponible automáticamente para todos los nodos de la zona.

En el caso de los servidores de Distributed Cloud, solo puedes configurar subredes con IDs de VLAN. No se admiten subredes basadas en CIDR.

Establece sesiones de intercambio de tráfico de BGP de dirección norte

Cuando creas una red y sus subredes correspondientes, estas son locales para su zona de Distributed Cloud. Para habilitar la conectividad saliente, debes establecer al menos una sesión de BGP de intercambio de tráfico ascendente entre la red y tus routers perimetrales de intercambio de tráfico.

Para establecer una sesión de peering de BGP de norte a sur, haz lo siguiente:

  1. Enumera las interconexiones disponibles en tu zona y, luego, selecciona la interconexión de destino para esta sesión de peering.

  2. Crea uno o más archivos adjuntos de interconexión en la interconexión seleccionada. Los adjuntos de interconexión vinculan el router que creas en el siguiente paso con la interconexión seleccionada.

  3. Crea un router. Este router enruta el tráfico entre la interconexión y tu red a través de los archivos adjuntos de interconexión que creaste en el paso anterior.

  4. Agrega una interfaz al router para cada adjunto de interconexión que creaste anteriormente en este procedimiento. Para cada interfaz, usa la dirección IP del conmutador de la parte superior del rack (ToR) correspondiente en tu rack de Distributed Cloud. Para obtener instrucciones, consulta Cómo establecer una sesión de intercambio de tráfico de salida.

  5. Agrega un par para cada interfaz que creaste en el router en el paso anterior.

Establece sesiones de intercambio de tráfico de BGP de sur a norte

Para habilitar la conectividad entrante a tus cargas de trabajo desde tu red local, debes establecer una o más sesiones de BGP de intercambio de tráfico de salida entre tus routers perimetrales de intercambio de tráfico y la subred a la que pertenecen tus Pods. La dirección IP de la puerta de enlace para cada subred es la dirección IP del conmutador TOR correspondiente en tu rack de Distributed Cloud.

Para establecer una sesión de peering de BGP de sur a norte, haz lo siguiente:

  1. Agrega una interfaz al router en la red de destino para cada subred que desees aprovisionar con conectividad entrante. Para obtener instrucciones, consulta Cómo establecer una sesión de intercambio de tráfico de salida.

  2. Agrega un par para cada interfaz que creaste en el router en el paso anterior.

Opcional: Establece sesiones de peering de BGP de bucle invertido

Para habilitar la conectividad de alta disponibilidad entre tus cargas de trabajo y tu red local, puedes establecer una sesión de intercambio de tráfico de BGP de bucle invertido entre el Pod de destino y ambos conmutadores ToR de tu rack de Distributed Cloud. Una sesión de intercambio de tráfico de bucle invertido establece dos sesiones de intercambio de tráfico independientes para el Pod, una con cada conmutador ToR.

Para establecer una sesión de peering de BGP de bucle invertido, haz lo siguiente:

  1. Agrega una interfaz de bucle invertido al router en la red de destino. Para obtener instrucciones, consulta Cómo establecer una sesión de intercambio de tráfico de bucle invertido.

  2. Agrega un par para la interfaz de bucle invertido.

Prueba la configuración

Para probar la configuración de los componentes de red que creaste, haz lo siguiente:

  1. Verifica el estado operativo de la red.

  2. Verifica el estado de aprovisionamiento de cada subred.

  3. Verifica el estado operativo de las interconexiones.

  4. Verifica el estado operativo de los adjuntos de interconexión.

  5. Verifica el estado operativo del router.

Conecta los Pods a la red

Para conectar los Pods a la red y configurar funciones de red avanzadas, sigue las instrucciones en Operador de funciones de red.

Balanceo de cargas

Distributed Cloud se entrega con una solución de balanceo de cargas de red incluida basada en MetalLB en modo de capa 2. Puedes usar esta solución para exponer los servicios que se ejecutan en tu zona de Distributed Cloud al mundo exterior con direcciones IP virtuales (VIP) de la siguiente manera:

  1. El administrador de red planifica la topología de red y especifica la subred de direcciones IPv4 virtuales requerida cuando solicita Distributed Cloud. Google configura el hardware de Distributed Cloud según corresponda antes de la entrega. Ten en cuenta lo siguiente:
    • Esta subred de VIP se comparte entre todos los clústeres de Kubernetes que se ejecutan en tu zona de Distributed Cloud.
    • Se anuncia una ruta para la subred del VIP solicitada a través de las sesiones de BGP entre la zona de Distributed Cloud y tu red local.
    • La primera (ID de red), la segunda (puerta de enlace predeterminada) y la última (dirección de transmisión) direcciones de la subred están reservadas para la funcionalidad principal del sistema. No asignes esas direcciones a los grupos de direcciones de tus configuraciones de MetalLB.
    • Cada clúster debe usar un rango de VIP independiente que se encuentre dentro de la subred de VIP configurada.
  2. Cuando creas un clúster en tu zona de Distributed Cloud, el administrador del clúster especifica los grupos de direcciones de Pod y de ClusterIP Service con la notación CIDR. El administrador de red proporciona la subred de VIP LoadBalancer adecuada al administrador del clúster.

  3. Después de crear el clúster, el administrador del clúster configura los grupos de VIP correspondientes. Para los clústeres de plano de control remoto, debes editar el ConfigMap metallb-config en el espacio de nombres metallb-system con el comando kubectl edit o kubectl replace. No uses el comando kubectl apply, ya que Distributed Cloud sobrescribe tus cambios si lo haces.

    En el siguiente ejemplo, se ilustra una configuración de este tipo:

    # metallb-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: metallb-config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.1.2-192.168.1.254

    En el caso de los clústeres del plano de control local, debes especificar los grupos de VIP con la marca --external-lb-ipv4-address-pools cuando crees el clúster. Para obtener más información, consulta Modo de supervivencia.

  4. El administrador del clúster crea los servicios de LoadBalancer de Kubernetes adecuados.

Los nodos de Distributed Cloud en un solo grupo de nodos comparten un dominio de capa 2 común y, por lo tanto, también son nodos del balanceador de cargas de MetalLB. Los nodos del plano de control de Distributed Cloud que se ejecutan enGoogle Cloud no funcionan como nodos del balanceador de cargas.

Entrada de Distributed Cloud

Además del balanceo de cargas, Distributed Cloud también admite recursos de Kubernetes Ingress. Un recurso Ingress de Kubernetes controla el flujo de tráfico HTTP(S) a los servicios de Kubernetes que se ejecutan en tus clústeres de Distributed Cloud. En el siguiente ejemplo, se ilustra un recurso Ingress típico:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - backend:
          service:
            name: my-service
            port:
              number: 80
        path: /foo
        pathType: Prefix

Cuando se configura, el tráfico de red fluye a través del servicio istio-ingress, al que, de forma predeterminada, se le asigna una dirección IP aleatoria de los grupos de VIP especificados en la configuración de MetalLB. Puedes seleccionar una dirección IP específica o una dirección IP virtual de la configuración de MetalLB con el campo loadBalancerIP en la definición del servicio istio-ingress. Por ejemplo:

apiVersion: v1
kind: Service
metadata:
  labels:
    istio: ingress-gke-system
    release: istio
  name: istio-ingress
  namespace: gke-system
spec:
  loadBalancerIP: <targetLoadBalancerIPaddress>

Esta funcionalidad no está disponible en los servidores de Distributed Cloud.

Inhabilita el recurso Ingress predeterminado de Distributed Cloud

De forma predeterminada, cuando creas un clúster de Distributed Cloud, Distributed Cloud configura automáticamente el servicio istio-ingress para el clúster. Tienes la opción de crear un clúster de Distributed Cloud sin el servicio istio-ingress. Para ello, completa los siguientes pasos:

gcloud

  1. Crea un archivo de configuración YAML llamado SystemsAddonConfig.yaml con el siguiente contenido:

    systemAddonsConfig:
 ingress:
   disabled: true

  2. Pasa el archivo SystemsAddonConfig.yaml con la marca --system-addons-config en el comando de creación del clúster. Debes usar la versión gcloud alpha para usar esta función. Por ejemplo:

    gcloud alpha edge-cloud container clusters create MyGDCECluster1 --location us-west1 \
    --system-addons-config=SystemsAddonConfig.yaml

    Para obtener más información sobre cómo crear un clúster de Distributed Cloud, consulta Crea un clúster.

API

  1. Agrega el siguiente contenido JSON a la carga útil de JSON en la solicitud de creación del clúster:

    "systemAddonConfig" {
   "ingress" {
           "disabled": true
   }
}

  2. Envía la solicitud de creación del clúster como se describe en Crea un clúster.

Compatibilidad con SCTP

Distributed Cloud admite el Protocolo de transmisión de control de flujo (SCTP) en la interfaz de red principal para las redes internas y externas. La compatibilidad con SCTP incluye los tipos de servicio NodePort, LoadBalancer y ClusterIP. Los Pods pueden usar SCTP para comunicarse con otros Pods y recursos externos. En el siguiente ejemplo, se muestra cómo configurar IPERF como un servicio ClusterIP con SCTP:

apiVersion: v1
kind: Pod
metadata:
  name: iperf3-sctp-server-client
  labels:
    app.kubernetes.io/name: iperf3-sctp-server-client
spec:
  containers:
  - name: iperf3-sctp-server
    args: ['-s', '-p 31390']
    ports:
      - containerPort: 31390
        protocol: SCTP
        name: server-sctp
  - name: iperf3-sctp-client
    ...

---

apiVersion: v1
kind: Service
metadata:
  name: iperf3-sctp-svc
spec:
  selector:
    app.kubernetes.io/name: iperf3-sctp-server-client
  ports:
    - port: 31390
      protocol: SCTP
      targetPort: server-sctp

Esta funcionalidad no está disponible en los servidores de Distributed Cloud.

Módulos de kernel de SCTP

A partir de la versión 1.5.0, Distributed Cloud configura el módulo del kernel del SO de sctp Edge como cargable. Esto te permite cargar tus propias pilas de protocolos SCTP en el espacio del usuario del kernel.

Además, Distributed Cloud carga los siguientes módulos en el kernel de forma predeterminada:

Nombre del módulo Nombre de la configuración
fou CONFIG_NET_FOU
nf_conntrack_proto_gre CONFIG_NF_CT_PROTO_GRE
nf_conntrack_proto_sctp CONFIG_NF_CT_PROTO_SCTP
inotify CONFIG_INOTIFY_USER
xt_redirect CONFIG_NETFILTER_XT_TARGET_REDIRECT
xt_u32 CONFIG_NETFILTER_XT_MATCH_U32
xt_multiport CONFIG_NETFILTER_XT_MATCH_MULTIPORT
xt_statistic CONFIG_NETFILTER_XT_MATCH_STATISTIC
xt_owner CONFIG_NETFILTER_XT_MATCH_OWNER
xt_conntrack CONFIG_NETFILTER_XT_MATCH_CONNTRACK
xt_mark CONFIG_NETFILTER_XT_MARK
ip6table_mangle CONFIG_IP6_NF_MANGLE
ip6_tables CONFIG_IP6_NF_IPTABLES
ip6table_filter CONFIG_IP6_NF_FILTER
ip6t_reject CONFIG_IP6_NF_TARGET_REJECT
iptable_mangle CONFIG_IP_NF_MANGLE
ip_tables CONFIG_IP_NF_IPTABLES
iptable_filter CONFIG_IP_NF_FILTER

ClusterDNS recurso

Distributed Cloud admite el recurso ClusterDNS de Google Distributed Cloud para configurar servidores de nombres ascendentes para dominios específicos con la sección spec.domains. Para obtener más información sobre cómo configurar este recurso, consulta spec.domains.

Esta funcionalidad no está disponible en los servidores de Distributed Cloud.

¿Qué sigue?