Recursos de rede do Distributed Cloud conectado

Esta página descreve os recursos de rede do Google Distributed Cloud Connected, incluindo sub-redes, sessões de peering BGP e balanceamento de carga.

Os procedimentos nesta página se aplicam apenas aos racks conectados do Distributed Cloud, exceto o balanceamento de carga, que se aplica aos racks e servidores conectados do Distributed Cloud.

Rede de pilha dupla IPv4/IPv6

Com o Distributed Cloud Connected, é possível criar clusters que usam rede de pilha dupla IPv4/IPv6. Para aproveitar essa funcionalidade, você precisa pedir o Distributed Cloud conectado com a rede de pilha dupla IPv4/IPv6 ativada. Não é possível reconfigurar uma implantação somente IPv4 do Distributed Cloud conectada a uma rede de pilha dupla IPv4/IPv6. Para verificar se sua implantação é compatível com a rede de pilha dupla IPv4/IPv6, siga as instruções em Receber informações sobre uma máquina e verifique o valor retornado do rótulo dualstack_capable.

Em um cluster de pilha dupla, a pilha IPv4 usa o modo de ilha, enquanto a pilha IPv6 usa o modo simples. Por isso, é necessário especificar endereços IPv6 individuais e discretos de nós e pods que pertencem à mesma sub-rede. Para mais informações, consulte Modelos de rede no modo plano x ilha.

Por exemplo, se os nós conectados do Distributed Cloud e outras máquinas locais residirem no mesmo domínio da camada 2, especifique os blocos CIDR IPv6 para o cluster da seguinte maneira:

Finalidade do bloqueio	Intervalo de bloqueio	Tamanho do bloco
Sub-rede IPv6	fd12::/56	2^72
Pods	fd12::1:0/59	2^69
Serviços	fd12::2:0/59	2^69

Este exemplo pressupõe o seguinte:

• Os blocos CIDR de nó, pod e serviço pertencem à super-rede fd:12::/56.
• Os endereços IP de nó, pod e serviço são sub-redes do bloco CIDR especificado.
• Nenhuma das sub-redes se sobrepõe.

A rede de pilha dupla IPv4/IPv6 requer balanceamento de carga da camada 2 para o peering BGP IPv4 e balanceamento de carga da camada 3 para o peering IPv6. Para mais informações, consulte Balanceamento de carga.

Para mais informações sobre como implantar cargas de trabalho em clusters de pilha dupla IPv4/IPv6, consulte o seguinte:

• Rede de pilha dupla IPv4/IPv6
• Pilha dupla IPv4/IPv6

Ativar a API Distributed Cloud Edge Network

Antes de configurar a rede em uma implantação conectada do Distributed Cloud, é necessário ativar a API Distributed Cloud Edge Network. Para isso, siga as etapas nesta seção. Por padrão, os servidores do Distributed Cloud connected são enviados com a API Distributed Cloud Edge Network já ativada.

Console

1. No console do Google Cloud , acesse a página da API Distributed Cloud Edge Network.

   Ativar a API

2. Clique em Ativar.

gcloud

Use o comando a seguir:

gcloud services enable edgenetwork.googleapis.com

Configurar a rede no Google Distributed Cloud conectado

Nesta seção, descrevemos como configurar os componentes de rede na implantação conectada do Distributed Cloud.

As seguintes limitações se aplicam aos servidores conectados do Distributed Cloud:

• Só é possível configurar sub-redes, e
• As sub-redes só são compatíveis com IDs de VLAN. Sub-redes baseadas em CIDR não são compatíveis.

Uma configuração de rede típica para o Distributed Cloud Connected consiste nas seguintes etapas:

1. Opcional: inicialize a configuração de rede da zona de destino, se necessário.

2. Criar uma rede.

3. Crie uma ou mais sub-redes na rede.

4. Estabeleça sessões de peering do BGP de sentido norte com seus roteadores PE usando os anexos de interconexão correspondentes.

5. Estabeleça sessões de peering BGP southbound com os pods que executam suas cargas de trabalho usando as sub-redes correspondentes.

6. Opcional: estabeleça sessões de peering BGP de loopback para alta disponibilidade.

7. Teste sua configuração.

8. Conecte os pods à rede.

Inicializar a configuração de rede da zona do Distributed Cloud

É necessário inicializar a configuração de rede da zona conectada do Distributed Cloud imediatamente após a instalação do hardware conectado do Distributed Cloud no local. A inicialização da configuração de rede de uma zona é um procedimento único.

A inicialização da configuração de rede de uma zona cria um roteador padrão chamado default e uma rede padrão chamada default. Ele também configura o roteador default para fazer peering com todas as interconexões solicitadas ao pedir o hardware conectado do Distributed Cloud, criando anexos de interconexão correspondentes. Essa configuração fornece à sua implantação conectada do Distributed Cloud conectividade de uplink básica com sua rede local.

Para instruções, consulte Inicializar a configuração de rede de uma zona.

Criar uma rede

Para criar uma rede, siga as instruções em Criar uma rede. Você também precisa criar pelo menos uma sub-rede dentro da rede para permitir que os nós conectados do Distributed Cloud se conectem a ela.

Criar uma ou mais sub-redes

Para criar uma sub-rede, siga as instruções em Criar uma sub-rede. É preciso criar pelo menos uma sub-rede na sua rede para permitir que os nós acessem a rede. A VLAN correspondente a cada sub-rede criada fica disponível automaticamente para todos os nós na zona.

Para servidores conectados do Distributed Cloud, só é possível configurar sub-redes usando IDs de VLAN. Sub-redes baseadas em CIDR não são compatíveis.

Estabelecer sessões de peering do BGP de saída

Quando você cria uma rede e as sub-redes correspondentes, elas são locais para a zona conectada do Distributed Cloud. Para ativar a conectividade de saída, estabeleça pelo menos uma sessão de peering do BGP de saída entre a rede e os roteadores de borda de peering.

Para estabelecer uma sessão de peering do BGP de saída, faça o seguinte:

1. Liste as interconexões disponíveis na sua zona e selecione a interconexão de destino para esta sessão de peering.

2. Crie um ou mais anexos de interconexão na interconexão selecionada. Os anexos de interconexão vinculam o roteador que você cria na próxima etapa com a interconexão selecionada.

3. Crie um roteador. Esse roteador encaminha o tráfego entre a interconexão e sua rede usando os anexos de interconexão criados na etapa anterior.

4. Adicione uma interface ao roteador para cada anexo de interconexão criado anteriormente neste procedimento. Para cada interface, use o endereço IP do switch ToR (top-of-rack) correspondente no rack conectado do Distributed Cloud. Para instruções, consulte Estabelecer uma sessão de peering de saída.

5. Adicione um peer para cada interface criada no roteador na etapa anterior.

Estabelecer sessões de peering do BGP southbound

Para ativar a conectividade de entrada aos seus workloads da rede local, você precisa estabelecer uma ou mais sessões de peering BGP de saída entre os roteadores de borda de peering e a sub-rede a que seus pods pertencem. O endereço IP do gateway de cada sub-rede é o endereço IP do switch ToR correspondente no rack conectado do Distributed Cloud.

Para estabelecer uma sessão de peering do BGP southbound, faça o seguinte:

1. Adicione uma interface ao roteador na rede de destino para cada sub-rede que você quer provisionar com conectividade de entrada. Para instruções, consulte Estabelecer uma sessão de peering southbound.

2. Adicione um peer para cada interface criada no roteador na etapa anterior.

Opcional: estabelecer sessões de peering BGP de loopback

Para ativar a conectividade de alta disponibilidade entre suas cargas de trabalho e sua rede local, estabeleça uma sessão de peering BGP de loopback entre o pod de destino e os dois switches ToR no rack conectado do Distributed Cloud. Uma sessão de peering de loopback estabelece duas sessões de peering independentes para o pod, uma com cada switch ToR.

Para estabelecer uma sessão de peering BGP de loopback, faça o seguinte:

1. Adicione uma interface de loopback ao roteador na rede de destino. Para instruções, consulte Estabelecer uma sessão de peering de loopback.

2. Adicione um peer para a interface de loopback.

Testar a configuração

Para testar a configuração dos componentes de rede que você criou, faça o seguinte:

1. Verifique o status operacional da rede.

2. Verifique o status de provisionamento de cada sub-rede.

3. Verifique o status operacional das interconexões.

4. Verifique o status operacional dos anexos de interconexão.

5. Verifique o status operacional do roteador.

Conecte seus pods à rede

Para conectar seus pods à rede e configurar funções de rede avançadas, siga as instruções em Operador de função de rede. Essa funcionalidade não está disponível para cargas de trabalho máquina virtual.

(Opcional) Configurar o isolamento de rede do cluster

O Distributed Cloud Connected oferece suporte ao isolamento de rede de cluster. Os nós atribuídos a um cluster isolado da rede não podem se comunicar com outros nós na mesma zona conectada do Distributed Cloud. Para ativar o isolamento da rede do cluster, use a flag --enable-cluster-isolation ao criar ou modificar um cluster. Para mais informações, consulte Criar e gerenciar clusters.

(Opcional) Configurar o modo isolado

O Distributed Cloud Connected oferece suporte ao modo isolado para o subsistema de rede virtual. O modo de ilha permite especificar um intervalo de endereços IP isolado em uma interface de rede secundária de um pod. Esse intervalo de endereços isolado é independente do intervalo de endereços da VLAN da interface de rede principal. Os pods configurados para o modo isolado recebem apenas endereços desse intervalo isolado. Para mais informações, consulte Modelos de rede no modo plano x ilha.

O intervalo de endereços IP isolado especificado para o modo isolado não pode entrar em conflito com os seguintes intervalos:

• O CIDR da VLAN principal para qualquer rede configurada no cluster
• O intervalo de endereços IP virtuais do balanceador de carga especificado na anotação networking.gke.io/gdce-lb-service-vip-cidrs no recurso Network
• Os intervalos de endereços IP usados para o modo isolado em outras redes no cluster

Configurar o modo isolado

Para configurar o modo isolado no nível do pod, adicione a anotação networking.gke.io/gdce-pod-cidr ao recurso personalizado Network correspondente. Defina o valor da anotação como o intervalo de endereços IP isolados de destino e aplique o recurso Network modificado ao cluster. Exemplo:

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

Você também precisa definir os seguintes parâmetros:

• O campo type precisa ser definido como L3.
• O campo IPAMMode precisa ser definido como Internal.

Exemplo:

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 se o modo isolado está ativado, faça o seguinte:

1. Crie um pod de teste e aplique-o ao cluster. Exemplo:

   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. Acesse o endereço IP do pod:

   kubectl get pod island-pod-tester -o wide
   

   O comando retorna o endereço IP do pod, que está dentro do intervalo de endereços isolados especificado.

Configurar o modo isolado com o serviço ClusterIP

Para configurar o modo ilha com o serviço ClusterIP, conclua as etapas na seção anterior, adicione a anotação networking.gke.io/gke-gateway-clusterip-cidr ao recurso Network e defina o valor de acordo com as necessidades da sua empresa. Os intervalos de endereços especificados no recurso Network não podem se sobrepor. Exemplo:

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

Balanceamento de carga

O Distributed Cloud Connected é fornecido com as seguintes soluções de balanceamento de carga:

• Balanceamento de carga da camada 2 com o MetalLB
• Balanceamento de carga da camada 3 com balanceadores de carga do Google Distributed Cloud

As soluções de balanceamento de carga integradas ao Distributed Cloud Connected não podem usar prefixos de IP virtual de serviço do Kubernetes sobrepostos. Se você tiver uma implantação conectada do Distributed Cloud que usa o balanceamento de carga MetalLB da camada 2 e quiser mudar para o balanceamento de carga da camada 3 com balanceadores de carga do Google Distributed Cloud, use um prefixo de IP virtual de serviço que não se sobreponha ao prefixo usado pela configuração de balanceamento de carga MetalLB da camada 2.

Balanceamento de carga da camada 2 com o MetalLB

O Distributed Cloud é fornecido com uma solução de balanceamento de carga de rede em pacote baseada no MetalLB no modo de Camada 2. É possível usar essa solução para expor serviços executados na sua zona do Distributed Cloud ao mundo externo usando endereços IP virtuais (VIPs) da seguinte maneira:

1. O administrador de rede planeja a topologia de rede e especifica a sub-rede de endereços IPv4 e IPv6 virtuais necessária ao fazer o pedido do Distributed Cloud. O Google configura o hardware do Distributed Cloud de acordo com suas necessidades antes da entrega. Lembre-se do seguinte:
   • Essa sub-rede de VIP é compartilhada entre todos os clusters do Kubernetes que são executados na sua zona do Distributed Cloud.
   • Uma rota para a sub-rede VIP solicitada é anunciada pelas sessões do BGP entre a zona do Distributed Cloud e sua rede local.
   • O primeiro (ID da rede), o segundo (gateway padrão) e o último (endereço de transmissão) endereços da sub-rede são reservados para a funcionalidade principal do sistema. Não atribua esses endereços aos pools de endereços das configurações do MetalLB.
   • Cada cluster precisa usar um intervalo de VIP separado que esteja dentro da sub-rede VIP configurada.
2. Ao criar um cluster na sua zona do Distributed Cloud, o administrador do cluster especifica os pools de endereços de serviço do pod e do ClusterIP usando a notação CIDR. O administrador de rede fornece a sub-rede VIP LoadBalancer adequada ao administrador do cluster.

3. Depois que o cluster é criado, o administrador configura os pools de VIPs correspondentes. É necessário especificar os pools de VIPs usando a flag --external-lb-address-pools ao criar o cluster. A flag aceita um arquivo com um payload YAML ou JSON no seguinte 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 um pool de endereços VIP, forneça as seguintes informações no payload:

   • name: um nome descritivo que identifica exclusivamente este pool de endereços VIP.
   • addresses: uma lista de endereços IPv4 e IPv6, intervalos de endereços e sub-redes a serem incluídos neste pool de endereços.
   • avoid_buggy_ips: exclui endereços IP que terminam com .0 ou .255.
   • manual_assign: permite atribuir manualmente endereços desse pool na configuração do serviço LoadBalancer de destino em vez de deixar que o controlador do MetalLB os atribua automaticamente.

   Para mais informações sobre como configurar pools de endereços VIP, consulte Especificar pools de endereços na documentação do MetalLB.

4. O administrador do cluster cria os serviços LoadBalancer do Kubernetes adequados.

Os nós do Distributed Cloud em um único pool de nós compartilham um domínio comum da camada 2 e, portanto, também são nós do balanceador de carga do MetalLB.

Balanceamento de carga da camada 3 com balanceadores de carga do Google Distributed Cloud

O Distributed Cloud Connected é fornecido com uma solução de balanceamento de carga de rede em pacote baseada nos balanceadores de carga em pacote do Google Distributed Cloud no modo da camada 3 configurados como falantes BGP. É possível usar essa solução para expor serviços executados na sua zona conectada do Distributed Cloud ao mundo externo usando VIPs.

É possível especificar os intervalos de VIP para os serviços LoadBalancer correspondentes usando o ConfigMap metallb-config. Exemplo:

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

No exemplo anterior, cada serviço LoadBalancer configurado recebe automaticamente um endereço IP virtual do intervalo 10.100.10.66/27 especificado no ConfigMap. Em seguida, esses VIPs são anunciados no sentido norte pelos speakers BGP do Distributed Cloud configurados nos switches ToR pelos recursos BGPPeer.

Quando você cria um cluster do Distributed Cloud, os seguintes recursos são criados automaticamente nele:

• Um recurso BGPLoadBalancer que cria uma instância do balanceador de carga do BGP.
• Um recurso NetworkGatewayGroup que especifica os endereços IP flutuantes locais a serem usados para os roteadores BGP. Esses endereços IP são definidos automaticamente como os dois últimos endereços IP da sub-rede do nó do Kubernetes atribuída ao cluster.

Com esses recursos, é possível configurar sessões do BGP para os switches ToR do Distributed Cloud configurando os recursos BGPPeer correspondentes. Para isso, você precisa ter os números de sistema autônomo (ASNs) e os endereços IP de loopback dos switches ToR. Esses endereços IP servem como endpoints da sessão BGP do switch ToR no recurso de rede padrão. O valor do parâmetro network precisa ser pod-network.

Confira a seguir um exemplo dos dois 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

Configurar a automação do balanceamento de carga do BGP da camada 3 para peering IPv6

Antes de começar a usar o peering IPv6 no cluster de rede de pilha dupla IPv4/IPv6, trabalhe com o suporte do Google para ativar a automação do balanceador de carga do Google Distributed Cloud na implantação do Distributed Cloud Connected.

Criar serviço LoadBalancer da camada 3

Depois de ativar a automação do balanceador de carga do Google Distributed Cloud na sua implantação conectada do Distributed Cloud, crie uma instância do serviço de camada 3 LoadBalancer. Exemplo:

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

Verifique o estado da sessão do BGP e dos serviços de balanceamento de carga

Para verificar o estado da sua sessão do BGP, use o seguinte comando:

kubectl get bgpsessions.networking.gke.io -A

O comando retorna uma saída semelhante a este exemplo:

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 se os serviços LoadBalancer estão sendo anunciados pelos speakers BGP, use o seguinte comando:

kubectl get bgpadvertisedroutes.networking.gke.io -A

O comando retorna uma saída semelhante a este exemplo:

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 da Distributed Cloud

Além do balanceamento de carga, o Distributed Cloud Connected também é compatível com recursos do Kubernetes Ingress. Um recurso Ingress do Kubernetes controla o fluxo de tráfego HTTP(S) para serviços do Kubernetes executados nos seus clusters conectados do Distributed Cloud. O exemplo a seguir ilustra um 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

Quando configurado, o tráfego de rede flui pelo serviço istio-ingress, que, por padrão, recebe um endereço IP aleatório dos pools de VIPs especificados na configuração do MetalLB. É possível selecionar um endereço IP específico ou um endereço IP virtual na configuração do MetalLB usando o campo loadBalancerIP na definição do serviço istio-ingress. Exemplo:

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

Essa funcionalidade não está disponível em servidores conectados do Distributed Cloud.

Desativar o recurso padrão do Distributed Cloud Ingress

Por padrão, quando você cria um cluster conectado do Distributed Cloud, o Distributed Cloud configura automaticamente o serviço istio-ingress para o cluster. Você pode criar um cluster conectado do Distributed Cloud sem o serviço istio-ingress. Para isso, siga as etapas abaixo:

gcloud

1. Crie um arquivo de configuração YAML chamado SystemsAddonConfig.yaml com o seguinte conteúdo:

   systemAddonsConfig:
    ingress:
      disabled: true
   

2. Transmita o arquivo SystemsAddonConfig.yaml usando a flag --system-addons-config no comando de criação do cluster. Para usar esse recurso, é preciso usar a versão gcloud alpha. Exemplo:

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

   Para mais informações sobre como criar um cluster do Distributed Cloud, consulte Criar um cluster.

API

1. Adicione o seguinte conteúdo JSON ao payload JSON na solicitação de criação do cluster:

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

2. Envie a solicitação de criação de cluster conforme descrito em Criar um cluster.

Serviço NodePort

O Distributed Cloud Connected é compatível com o serviço NodePort do Kubernetes, que fica aguardando conexões em um nó do Distributed Cloud em um número de porta de sua escolha. O serviço NodePort é compatível com os protocolos TCP, UDP e SCTP. Exemplo:

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

Compatibilidade com SCTP

O Distributed Cloud Connected é compatível com o protocolo de transmissão de controle de fluxo (SCTP) na interface de rede principal para redes internas e externas. O suporte ao SCTP inclui os tipos de serviço NodePort, LoadBalancer e ClusterIP. Os pods podem usar o SCTP para se comunicar com outros pods e recursos externos. O exemplo a seguir ilustra como configurar o IPERF como um serviço ClusterIP usando o 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

Essa funcionalidade não está disponível em servidores conectados do Distributed Cloud.

Módulos do kernel SCTP

A partir da versão 1.5.0, o Distributed Cloud Connected configura o módulo do kernel do SO do Edge sctp como carregável. Isso permite carregar suas próprias pilhas de protocolo SCTP no espaço do usuário do kernel.

Além disso, o Distributed Cloud Connected carrega os seguintes módulos no kernel por padrão:

Nome do módulo	Nome da configuração
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

O Distributed Cloud Connected é compatível com o recurso ClusterDNS do Google Distributed Cloud para configurar servidores de nomes upstream para domínios específicos usando a seção spec.domains. Para mais informações sobre como configurar esse recurso, consulte spec.domains.

Essa funcionalidade não está disponível em servidores conectados do Distributed Cloud.

A seguir

• alocação de endereços de rede de pods e serviços