Funciones de redes de Distributed Cloud conectado

En esta página, se describen las funciones de redes de Google Distributed Cloud connected, 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 Connected, excepto el balanceo de cargas, que se aplica tanto a los racks de Distributed Cloud Connected como a los servidores de Distributed Cloud Connected.

Herramientas de redes de pila doble IPv4/IPv6

Distributed Cloud Connected te permite crear clústeres que usan redes de pila doble IPv4/IPv6. Para aprovechar esta funcionalidad, debes pedir Distributed Cloud con redes de pila doble IPv4/IPv6 habilitadas. No puedes reconfigurar una implementación existente solo para IPv4 de Distributed Cloud conectada a redes de pila doble IPv4/IPv6. Para verificar si tu implementación admite herramientas de redes de pila doble IPv4/IPv6, sigue las instrucciones que se indican en Cómo obtener información sobre una máquina y verifica el valor devuelto de la etiqueta dualstack_capable.

En un clúster de pila doble, la pila IPv4 usa el modo isla, mientras que la pila IPv6 usa el modo plano. Por este motivo, debes especificar direcciones IPv6 discretas e individuales de nodos y Pods que pertenezcan a la misma subred. Para obtener más información, consulta Modelos de red de modo plano y de modo isla.

Por ejemplo, si tus nodos conectados de Distributed Cloud y otras máquinas locales residen en el mismo dominio de capa 2, podrías especificar tus bloques CIDR de IPv6 para el clúster de la siguiente manera:

Propósito del bloqueo	Rango de bloqueo	Tamaño de los bloques
Subred IPv6	fd12::/56	2^72
Pods	fd12::1:0/59	2^69
Servicios	fd12::2:0/59	2^69

En este ejemplo, se supone lo siguiente:

• Los bloques CIDR del nodo, el pod y el servicio pertenecen a la superred fd:12::/56.
• Las direcciones IP del nodo, el pod y el servicio son subredes del bloque CIDR especificado.
• Ninguna de las subredes se superpone.

Las redes de pila doble IPv4/IPv6 requieren balanceo de cargas de capa 2 para el peering de BGP IPv4 y balanceo de cargas de capa 3 para el peering de IPv6. Para obtener más información, consulta Balanceo de cargas.

Para obtener más información sobre la implementación de cargas de trabajo en clústeres de pila doble IPv4/IPv6, consulta lo siguiente:

• Herramientas de redes de pila doble IPv4/IPv6
• Pila doble IPv4/IPv6

Habilita la API de Distributed Cloud Edge Network

Antes de configurar las redes en una implementación conectada 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 conectado 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 en Distributed Cloud conectado

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

Se aplican las siguientes limitaciones a los servidores conectados 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 Connected 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 las cápsulas a la red.

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

Debes inicializar la configuración de red de tu zona conectada de Distributed Cloud inmediatamente después de que se haya instalado el hardware conectado de Distributed Cloud en tus instalaciones. La inicialización de la configuración de red de una zona es un procedimiento único.

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 Interconnects que solicitaste cuando pediste el hardware conectado de Distributed Cloud creando los archivos adjuntos de interconexión correspondientes. Esta configuración proporciona a tu implementación conectada de Distributed Cloud conectividad básica de vínculo ascendente a tu red local.

Para obtener instrucciones, 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 conectados de Distributed Cloud se conecten a la red.

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 conectados 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 correspondientes subredes, estas son locales para su zona conectada 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 conectado 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 peering de BGP de salida entre tus routers perimetrales de peering 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 el rack conectado 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 en tu rack conectado 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 tus pods a la red y configurar funciones de red avanzadas, sigue las instrucciones en Operador de funciones de red. Esta funcionalidad no está disponible para las cargas de trabajo de máquina virtual.

Configura el aislamiento de la red del clúster (opcional)

Distributed Cloud Connected admite el aislamiento de la red del clúster. Los nodos asignados a un clúster aislado de la red no pueden comunicarse con ningún otro nodo dentro de la misma zona conectada de Distributed Cloud. Para habilitar el aislamiento de la red del clúster, usa la marca --enable-cluster-isolation cuando crees o modifiques un clúster. Para obtener más información, consulta Crea y administra clústeres.

Configura el modo isla (opcional)

Distributed Cloud conectado admite el modo aislado para su subsistema de redes virtuales. El modo isla te permite especificar un rango de direcciones IP aislado en la interfaz de red secundaria de un Pod. Este rango de direcciones aislado es independiente del rango de direcciones de la VLAN de la interfaz de red principal. A los Pods configurados para el modo aislado solo se les asignan direcciones de este rango de direcciones "aislado". Para obtener más información, consulta Modelos de red de modo plano y de modo isla.

El rango de direcciones IP aislado que especifiques para el modo isla no debe entrar en conflicto con los siguientes rangos de direcciones IP:

• CIDR de VLAN principal para cualquier red configurada en el clúster
• El rango de direcciones IP virtuales del balanceador de cargas especificado en la anotación networking.gke.io/gdce-lb-service-vip-cidrs del recurso Network
• Son los rangos de direcciones IP que se usan para el modo de isla en cualquier otra red del clúster.

Cómo configurar el modo isla

Para configurar el modo de isla a nivel del Pod, agrega la anotación networking.gke.io/gdce-pod-cidr al recurso personalizado Network correspondiente. Establece el valor de la anotación en el rango de direcciones IP aisladas de destino y aplica el recurso Network modificado a tu clúster. Por ejemplo:

networking.gke.io/gdce-pod-cidr: 172.15.10.32/27

También debes establecer los siguientes parámetros:

• type debe establecerse en L3.
• IPAMMode debe establecerse en Internal.

Por ejemplo:

apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: my-network
  annotations:
    # Enable island mode and specify the isolated address range.
    networking.gke.io/gdce-pod-cidr: 172.15.10.32/27
    # Specify the VLAN ID for this secondary network.
    networking.gke.io/gdce-vlan-id: "561"
    # Specify the CIDR block for load balancer services on this network.
    networking.gke.io/gdce-lb-service-vip-cidrs: 172.20.5.180/30
spec:
  # Network type must be L3 for island mode.
  type: L3
  # IPAMMode must be Internal for island mode.
  IPAMMode: Internal
  nodeInterfaceMatcher:
    interfaceName: gdcenet0.561 # The name for the target network interface.
  gateway4: 172.20.5.177 # Gateway IP address; must be unique in this CR.
  externalDHCP4: false
  dnsConfig:
    nameservers:
    - 8.8.8.8

Para verificar que el modo isla esté habilitado, haz lo siguiente:

1. Crea un Pod de prueba y aplícalo a tu clúster. Por ejemplo:

   apiVersion: v1
   kind: Pod
   metadata:
     name: island-pod-tester
     annotations:
       networking.gke.io/interfaces: '[{"interfaceName":"eth1","network":"test-network-vlan561"}]'
       networking.gke.io/default-interface: "eth1"
   spec:
     containers:
     - name: sample-container
       image: busybox
       command: ["/bin/sh", "-c", "sleep 3600"]
   

2. Obtén la dirección IP del Pod:

   kubectl get pod island-pod-tester -o wide
   

   El comando devuelve la dirección IP del Pod, que se encuentra dentro del rango de direcciones aislado que especificaste.

Configura el modo isla con el servicio ClusterIP

Para configurar el modo de isla con el servicio ClusterIP, completa los pasos de la sección anterior, luego agrega la anotación networking.gke.io/gke-gateway-clusterip-cidr a tu recurso Network y establece su valor según las necesidades de tu empresa. Los rangos de direcciones especificados en el recurso Network no deben superponerse. Por ejemplo:

apiVersion: networking.gke.io/v1
kind: Network
metadata:
  annotations:
    networking.gke.io/gdce-lb-service-vip-cidrs: 172.20.5.180/30
    networking.gke.io/gdce-pod-cidr: 172.15.10.32/27
    networking.gke.io/gdce-vlan-id: "561"
    networking.gke.io/gke-gateway-clusterip-cidr: 10.20.1.0/28
  name: test-network-vlan561
spec:
  IPAMMode: Internal
  dnsConfig:
    nameservers:
    - 8.8.8.8
  externalDHCP4: false
  gateway4: 172.20.5.177
  nodeInterfaceMatcher:
    interfaceName: gdcenet0.561
  type: L3

Balanceo de cargas

Distributed Cloud Connected se entrega con las siguientes soluciones de balanceo de cargas:

• Balanceo de cargas de la capa 2 con MetalLB
• Balanceo de cargas de capa 3 con balanceadores de cargas de Google Distributed Cloud

Las soluciones de balanceo de cargas integradas en Distributed Cloud Connected no pueden usar prefijos de IP virtuales de servicio de Kubernetes superpuestos. Si tienes una implementación conectada existente de Distributed Cloud que usa el balanceo de cargas de MetalLB de capa 2 y deseas cambiar al balanceo de cargas de capa 3 con los balanceadores de cargas de Google Distributed Cloud, debes usar un prefijo de IP virtual de servicio que no se superponga con el prefijo que usa tu configuración de balanceo de cargas de MetalLB de capa 2.

Balanceo de cargas de la capa 2 con MetalLB

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 e IPv6 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 servicio de Pod y ClusterIP 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. Debes especificar los grupos de VIP con la marca --external-lb-address-pools cuando crees el clúster. La marca acepta un archivo con una carga útil en formato YAML o JSON con el siguiente formato:

    addressPools:
    - name: foo
      addresses:
      - 10.2.0.212-10.2.0.221
      - fd12::4:101-fd12::4:110
      avoid_buggy_ips: true
      manual_assign: false
   
    - name: bar
      addresses:
      - 10.2.0.202-10.2.0.203
      - fd12::4:101-fd12::4:102
      avoid_buggy_ips: true
      manual_assign: false
   

   Para especificar un grupo de direcciones VIP, proporciona la siguiente información en la carga útil:

   • name: Es un nombre descriptivo que identifica de forma única este grupo de direcciones VIP.
   • addresses: Es una lista de direcciones IPv4 e IPv6, rangos de direcciones y subredes que se incluirán en este grupo de direcciones.
   • avoid_buggy_ips: Excluye las direcciones IP que terminan en .0 o .255.
   • manual_assign: Te permite asignar manualmente direcciones de este grupo en la configuración del servicio LoadBalancer de destino en lugar de que el controlador de MetalLB las asigne automáticamente.

   Para obtener más información sobre la configuración de grupos de direcciones VIP, consulta Cómo especificar grupos de direcciones en la documentación de MetalLB.

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.

Balanceo de cargas de capa 3 con balanceadores de cargas de Google Distributed Cloud

Distributed Cloud conectado se entrega con una solución de balanceo de cargas de red incluida basada en los balanceadores de cargas incluidos en Google Distributed Cloud en modo de capa 3 configurados como interlocutores de BGP. Puedes usar esta solución para exponer los servicios que se ejecutan en tu zona conectada de Distributed Cloud al mundo exterior con VIP.

Puedes especificar los rangos de VIP para los servicios LoadBalancer correspondientes con el ConfigMap metallb-config. Por ejemplo:

kind: ConfigMap
apiVersion: v1
data:
  config: |
    address-pools:
    - name: default
      protocol: bgp
      addresses:
      - 10.100.10.66/27
metadata:
  name: metallb-config
  namespace: metallb-system

En el ejemplo anterior, a cada servicio LoadBalancer que configures se le asignará automáticamente una dirección IP virtual del rango 10.100.10.66/27 especificado en ConfigMap. Luego, los recursos BGPPeer anuncian estos VIP en dirección norte a través de los dispositivos de BGP de Distributed Cloud configurados en los conmutadores ToR.

Cuando creas un clúster de Distributed Cloud, se crean automáticamente los siguientes recursos en ese clúster:

• Un recurso BGPLoadBalancer que crea una instancia del balanceador de cargas de BGP.
• Es un recurso NetworkGatewayGroup que especifica las direcciones IP flotantes locales que se usarán para los routers BGP. Estas direcciones IP se configuran automáticamente en las dos últimas direcciones IP de la subred del nodo de Kubernetes asignada al clúster.

Con esos recursos implementados, puedes configurar sesiones de BGP para los conmutadores ToR de Distributed Cloud configurando los recursos BGPPeer correspondientes. Para ello, debes tener los números de sistema autónomo (ASN) necesarios y las direcciones IP de intercambio de tráfico de bucle invertido para los conmutadores ToR. Estas direcciones IP actúan como extremos de sesión de BGP del conmutador ToR en el recurso de red predeterminado. Ten en cuenta que el valor del parámetro network debe ser pod-network.

A continuación, se muestra un ejemplo de los dos recursos BGPPeer:

kind: BGPPeer
apiVersion: networking.gke.io/v1
metadata:
  name: bgppeertor1
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
  namespace: kube-system
spec:
  network: pod-network
  localASN: 64777
  peerASN: 64956
  peerIP: 10.112.0.10
  sessions: 1

kind: BGPPeer
apiVersion: networking.gke.io/v1
metadata:
  name: bgppeertor2
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
  namespace: kube-system
spec:
  network: pod-network
  localASN: 64777
  peerASN: 64956
  peerIP: 10.112.0.11
  sessions: 1

Configura la automatización del balanceo de cargas de BGP de capa 3 para el intercambio de tráfico IPv6

Antes de comenzar a usar el peering de IPv6 en tu clúster de redes de pila doble IPv4/IPv6, debes trabajar con el Atención al cliente de Google para habilitar la automatización del balanceador de cargas de Google Distributed Cloud en tu implementación conectada de Distributed Cloud.

Crea el servicio LoadBalancer de capa 3

Después de habilitar la automatización del balanceador de cargas de Google Distributed Cloud en tu implementación de Distributed Cloud Connected, crea una instancia del servicio LoadBalancer de capa 3. Por ejemplo:

apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    app.kubernetes.io/name: MyApp
spec:
  ipFamilyPolicy: PreferDualStack
  ipFamilies:
  - IPv6
  - IPv4
  selector:
    app.kubernetes.io/name: MyApp
  type: LoadBalancer
  ports:
    - protocol: TCP
      port: 80

Verifica el estado de la sesión de BGP y los servicios de balanceo de cargas

Para verificar el estado de tu sesión de BGP, usa el siguiente comando:

kubectl get bgpsessions.networking.gke.io -A

El comando muestra un resultado similar al siguiente ejemplo:

NAMESPACE     NAME                                                 LOCAL ASN   PEER ASN   LOCAL IP        PEER IP         STATE            LAST REPORT
kube-system   bgppeertor1-np-den6-120demo-den6-04-6ad5b6f4         64777       64956      10.100.10.61    10.112.0.10     Established      2s
kube-system   bgppeertor2-np-den6-120demo-den6-04-6ad5b6f4         64777       64956      10.100.10.61    10.112.0.11     Established      2s

Para verificar que los publicadores de BGP anuncian tus servicios de LoadBalancer, usa el siguiente comando:

kubectl get bgpadvertisedroutes.networking.gke.io -A

El comando muestra un resultado similar al siguiente ejemplo:

NAMESPACE      NAME                           PREFIX            METRIC
kube-system    bgplb-default-service-tcp      10.100.10.68/32
kube-system    bgplb-default-service-udp      10.100.10.77/32

Entrada de Distributed Cloud

Además del balanceo de cargas, Distributed Cloud Connected también admite recursos de Ingress de Kubernetes. 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 conectados 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 función no está disponible en los servidores conectados de Distributed Cloud.

Inhabilita el recurso Ingress predeterminado de Distributed Cloud

De forma predeterminada, cuando creas un clúster conectado 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 conectado de Distributed Cloud sin el servicio de 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.

Servicio NodePort

Distributed Cloud Connected admite el servicio NodePort de Kubernetes que escucha las conexiones en un nodo de Distributed Cloud en un número de puerto de tu elección. El servicio NodePort admite los protocolos TCP, UDP y SCTP. Por ejemplo:

apiVersion: v1
kind: pod
metadata:
  name: socat-nodeport-sctp
  labels:
    app.kubernetes.io/name: socat-nodeport-sctp
spec:
  containers:
  - name: socat-nodeport-sctp
    ...
    ports:
      - containerPort: 31333
        protocol: SCTP
        name: server-sctp

---

apiVersion: v1
kind: service
metadata:
  name: socat-nodeport-sctp-svc
spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: socat-nodeport-sctp
  ports:
    - port: 31333
      protocol: SCTP
      targetPort: server-sctp
      nodePort: 31333

Compatibilidad con SCTP

Distributed Cloud Connected admite el Protocolo de transmisión de control (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 función no está disponible en los servidores conectados de Distributed Cloud.

Módulos de kernel de SCTP

A partir de la versión 1.5.0, Distributed Cloud Connected 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 conectado 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 connected 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 función no está disponible en los servidores conectados de Distributed Cloud.

¿Qué sigue?

• Asignación de direcciones de red de Pods y servicios