Recursos de rede do Distributed Cloud conectado

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

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

Ativar a API Distributed Cloud Edge Network

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

Console

  1. No Google Cloud console, 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 Distributed Cloud conectado

Esta seção descreve 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ó oferecem suporte a IDs de VLAN. As sub-redes baseadas em CIDR não são compatíveis.

Uma configuração de rede típica para o Distributed Cloud conectado 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 BGP de saída com seus roteadores PE usando os anexos de interconexão correspondentes.

  5. Estabeleça sessões de peering BGP de entrada 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 seus pods à rede.

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

Você precisa inicializar a configuração de rede da zona conectada do Distributed Cloud nos seguintes casos:

  • Imediatamente após a instalação do hardware conectado do Distributed Cloud no local.
  • Você fez upgrade para a versão 1.3.0 ou mais recente do Distributed Cloud conectado em uma implantação conectada do Distributed Cloud, mas não participou da prévia privada 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. Ela também configura o roteador default para fazer peering com todas as interconexões solicitadas ao fazer o pedido do hardware conectado do Distributed Cloud, criando anexos de interconexão correspondentes. Essa configuração fornece à implantação conectada do Distributed Cloud conectividade de uplink básica à 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. Você também precisa criar pelo menos uma sub-rede na rede para permitir que os nós conectados do Distributed Cloud se conectem à rede.

Criar uma ou mais sub-redes

Para criar uma sub-rede, siga as instruções em Criar uma sub-rede. Você precisa criar pelo menos uma sub-rede na 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. As sub-redes baseadas em CIDR não são compatíveis.

Estabelecer sessões de peering 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 BGP de saída entre a rede e os roteadores de borda de peering.

Para estabelecer uma sessão de peering 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 essa 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 criado na próxima etapa à interconexão selecionada.

  3. Crie um roteador. Esse roteador encaminha o tráfego entre a interconexão e a 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 de rack superior (ToR, na sigla em inglês) correspondente no rack conectado do Distributed Cloud. Para instruções, consulte Estabelecer uma sessão de peering de saída.

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

Estabelecer sessões de peering BGP de entrada

Para ativar a conectividade de entrada para suas cargas de trabalho da rede local, estabeleça uma ou mais sessões de peering BGP de entrada 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 BGP de entrada, 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 de entrada.

  2. Adicione um par 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 as cargas de trabalho e a 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 par para a interface de loopback.

Testar a configuração

Para testar a configuração dos componentes de rede criados, 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.

Balanceamento de carga

O Distributed Cloud é fornecido com uma solução de balanceamento de carga de rede agrupada com base no MetalLB no modo da camada 2. É possível usar essa solução para expor serviços executados na 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 isso antes da entrega. Tenha o seguinte em mente:
    • Essa sub-rede VIP é compartilhada entre todos os clusters do Kubernetes executados na zona do Distributed Cloud.
    • Uma rota para a sub-rede VIP solicitada é anunciada pelas sessões BGP entre a zona do Distributed Cloud e a rede local.
    • O primeiro (ID da rede), o segundo (gateway padrão) e o último (endereço de transmissão ) endereços na 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 zona do Distributed Cloud, o administrador do cluster especifica os pools de endereços de pod e serviço ClusterIP usando a notação CIDR. O administrador de rede fornece a sub-rede VIP LoadBalancer apropriada ao administrador do cluster.

  3. Depois que o cluster é criado, o administrador do cluster configura os pools de VIP 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 as mudanças se você fizer isso.

    O exemplo a seguir ilustra essa configuração:

    # 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 Kubernetes LoadBalancer apropriados.

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

Ingresso do Distributed Cloud

Além do balanceamento de carga, o Distributed Cloud conectado também oferece suporte a recursos Ingress do Kubernetes. Um recurso Ingress do Kubernetes controla o fluxo de tráfego HTTP(S) para os serviços do Kubernetes executados nos 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 VIP 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 Ingress padrão do Distributed Cloud

Por padrão, ao criar um cluster conectado do Distributed Cloud, o Distributed Cloud configura automaticamente o serviço istio-ingress para o cluster. Você tem a opção de 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. É necessário usar a versão gcloud alpha para usar esse recurso. 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 do cluster conforme descrito em Criar um cluster.

Suporte a SCTP

O Distributed Cloud conectado oferece suporte ao Stream Control Transmission Protocol (SCTP) na interface de rede principal para redes internas e externas. O suporte a 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 conectado configura o módulo do kernel do SO de borda 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 conectado 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

Recurso ClusterDNS

O Distributed Cloud conectado oferece suporte ao 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