Recursos de rede do Distributed Cloud

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

Ativar a API Distributed Cloud Edge Network

Antes de configurar a rede do Distributed Cloud, é necessário ativar a API Distributed Cloud Edge Network. Para isso, siga as etapas nesta seção.

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

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

Uma configuração de rede típica para o Distributed Cloud 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.

Opcional: inicializar a configuração de rede da zona do Distributed Cloud

É necessário inicializar a configuração de rede da sua zona do Distributed Cloud nos seguintes casos:

• Imediatamente após a instalação do hardware do Distributed Cloud no local.
• Você fez upgrade para a versão 1.3.0 ou mais recente do Distributed Cloud em uma implantação do Distributed Cloud, mas não participou da prévia particular da API Distributed Cloud Edge Network.

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 do Distributed Cloud, criando anexos de interconexão correspondentes. Essa configuração fornece à sua implantação do Distributed Cloud conectividade de uplink básica com sua rede local.

A inicialização da configuração de rede de uma zona é um procedimento único. Para instruções completas, 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. Também é necessário criar pelo menos uma sub-rede dentro da rede para permitir que os nós 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.

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 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 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 do 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 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, é possível estabelecer uma sessão de peering BGP de loopback entre o pod de destino e os dois switches ToR no rack 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.

Conectar os 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 é 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ço IPv4 virtual 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. Para clusters de plano de controle remoto, edite o ConfigMap metallb-config no namespace metallb-system usando o comando kubectl edit ou kubectl replace. Não use o comando kubectl apply porque o Distributed Cloud substitui suas mudanças se você fizer isso.

   O exemplo a seguir ilustra uma configuração desse 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
   

   Para clusters de plano de controle local, especifique os pools de VIP usando a flag --external-lb-ipv4-address-pools ao criar o cluster. Para mais informações, consulte Modo de capacidade de sobrevivência.

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. Os nós do plano de controle do Distributed Cloud que são executados em Google Cloud não funcionam como nós de balanceador de carga.

Entrada da Distributed Cloud

Além do balanceamento de carga, o Distributed Cloud também oferece suporte a 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 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>

Desativar o recurso padrão do Distributed Cloud Ingress

Pré-lançamento

Este recurso está sujeito aos "Termos da Oferta Pré-GA" na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os recursos pré-GA estão disponíveis no estado em que se encontram e podem ter assistência limitada. Para mais informações, consulte as descrições das fases de lançamento.

Por padrão, quando você cria um cluster do Distributed Cloud, o Distributed Cloud configura automaticamente o serviço istio-ingress para o cluster. Você pode criar um cluster 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.

Compatibilidade com SCTP

Pré-lançamento

Este recurso está sujeito aos "Termos da Oferta Pré-GA" na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os recursos pré-GA estão disponíveis no estado em que se encontram e podem ter assistência limitada. Para mais informações, consulte as descrições das fases de lançamento.

O Distributed Cloud é 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 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

Módulos do kernel SCTP

A partir da versão 1.5.0, o Distributed Cloud 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 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

Pré-lançamento

Este recurso está sujeito aos "Termos da Oferta Pré-GA" na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os recursos pré-GA estão disponíveis no estado em que se encontram e podem ter assistência limitada. Para mais informações, consulte as descrições das fases de lançamento.

O Distributed Cloud é 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.

A seguir

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