Para informações sobre a versão, consulte as notas da versão do Distributed Cloud Connected.

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:

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

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

Ativar a API
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:

Opcional: inicialize a configuração de rede da zona de destino, se necessário.
Criar uma rede.
Crie uma ou mais sub-redes na rede.
Estabeleça sessões de peering do BGP de sentido norte com seus roteadores PE usando os anexos de interconexão correspondentes.
Estabeleça sessões de peering BGP southbound com os pods que executam suas cargas de trabalho usando as sub-redes correspondentes.
Opcional: estabeleça sessões de peering BGP de loopback para alta disponibilidade.
Teste sua configuração.
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:

Liste as interconexões disponíveis na sua zona e selecione a interconexão de destino para esta sessão de peering.
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.
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.
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.
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:

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.
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:

Adicione uma interface de loopback ao roteador na rede de destino. Para instruções, consulte Estabelecer uma sessão de peering de loopback.
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:

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.

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:

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

Crie um arquivo de configuração YAML chamado SystemsAddonConfig.yaml com o seguinte conteúdo:
```
systemAddonsConfig:
 ingress:
   disabled: true
```
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

Adicione o seguinte conteúdo JSON ao payload JSON na solicitação de criação do cluster:
```
"systemAddonConfig" {
   "ingress" {
           "disabled": true
   }
}
```
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

Recursos de rede do Distributed Cloud conectado Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Rede de pilha dupla IPv4/IPv6

Ativar a API Distributed Cloud Edge Network

Console

gcloud

Configurar a rede no Google Distributed Cloud conectado

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

Criar uma rede

Criar uma ou mais sub-redes

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

Estabelecer sessões de peering do BGP southbound

Opcional: estabelecer sessões de peering BGP de loopback

Testar a configuração

Conecte seus pods à rede

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

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

Criar serviço LoadBalancer da camada 3

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

Entrada da Distributed Cloud

Desativar o recurso padrão do Distributed Cloud Ingress

gcloud

API

Serviço NodePort

Compatibilidade com SCTP

Módulos do kernel SCTP

ClusterDNS recurso

A seguir

Recursos de rede do Distributed Cloud conectado

Criar serviço `LoadBalancer` da camada 3

Desativar o recurso padrão do Distributed Cloud `Ingress`

`ClusterDNS` recurso