Esta página foi traduzida pela API Cloud Translation.

Configurar interconexão multizonal

Nesta página, descrevemos a configuração necessária que você precisa fazer nas zonas atuais de uma implantação multizonal quando uma nova zona entra na implantação. Essa configuração permite estabelecer conexões com a nova zona.

1. Antes de começar

Você precisa ter o seguinte para configurar o interconexão de várias zonas no Google Distributed Cloud (GDC) com isolamento físico:

Um arquivo kubeconfig gerado e uma variável de ambiente. Para mais detalhes, consulte o runbook IAM-R0004.
Um operador de infraestrutura (IO) com acesso temporário ao cluster de administrador raiz. Para mais detalhes, consulte o runbook IAM-R0005.

2. Configurar interconexão multizonal

Configure um recurso MultiZoneNetworkConfig em cada zona da implantação multizonal:

Encontre o cluster correto para interagir. Se o cluster de administrador raiz estiver em execução, use o kubeconfig para ele. Caso contrário, use kubeconfig para o cluster de inicialização. Para mais detalhes, consulte o runbook IAM-R0004. Preencha o caminho do kubeconfig aqui:
```
KUBECONFIG=KUBECONFIG_PATH
```
Crie um arquivo YAML chamado multizone_network_config.yaml.
Adicione o seguinte conteúdo ao arquivo:
```
apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkConfig
metadata:
  name: multizone-network-config
  namespace: gpc-system
spec:
  carrierType: CARRIER_TYPE
  zones:
    - zoneID: ZONE_1_ID
      asn: ZONE_1_ASN
      externalSubnets:
        - METERING_SUBNET_1
    - zoneID: ZONE_2_ID
      asn: ZONE_2_ASN
      externalSubnets:
        - METERING_SUBNET_2
  ports:
    - port: PORT_1
    - port: PORT_2
  portSetting:
    mtu: MTU
```
Substitua:
- CARRIER_TYPE: o tipo de operadora de backbone multizonal. Precisa ser L2 ou L3.
  
  Importante: para o tipo de operadora L2, o Google recomenda não exceder três zonas.
- ZONE_1_ID: o ID da primeira zona na região do GDC.
- ZONE_1_ASN: o número do sistema autônomo (ASN, na sigla em inglês) do BGP da rede de dados da primeira zona na região do GDC.
- METERING_SUBNET_1: a sub-rede medida desta zona. Esse campo precisa ser preenchido com a sub-rede do recurso zone-infra-cidr CIDRClaim no cluster de administrador raiz da zona associada. Esse campo é apenas para fins de medição e não tem efeito no controle da divulgação da sub-rede. Mantenha esse campo sincronizado com as sub-redes reais que estão sendo anunciadas. Se esse campo não for especificado, nenhum tráfego será medido para essa zona.
- ZONE_2_ID: o ID da segunda zona na região do GDC.
- ZONE_2_ASN: o ASN do BGP da rede de dados da segunda zona na região do GDC.
- METERING_SUBNET_2: a sub-rede medida desta zona. Esse campo precisa ser preenchido com a sub-rede do recurso zone-infra-cidr CIDRClaim no cluster de administrador raiz da zona associada. Esse campo é apenas para fins de medição e não tem efeito no controle da divulgação da sub-rede. Mantenha esse campo sincronizado com as sub-redes reais que estão sendo anunciadas. Se esse campo não for especificado, nenhum tráfego será medido para essa zona.
- PORT_1: a primeira porta que participa da interconexão multizona. Consulte Configurar as portas para mais informações.
- PORT_2: a segunda porta que participa da interconexão multizona . Consulte Configurar as portas para mais informações.
- MTU: o valor da MTU aplicado a todas as portas. Se não for especificado, o valor padrão será 9216.
Atenção: todas as zonas, incluindo a atual, precisam ser incluídas no campo zones.
Observação: os ASNs da zona precisam ser os mesmos que o dataASN das zonas associadas.

Consulte Exemplos de configuração multizona para conferir exemplos comuns de implantação.

Aplique o arquivo multizone_network_config.yaml ao cluster:

kubectl apply -f multizone_network_config.yaml --kubeconfig=KUBECONFIG_PATH

Verifique se a criação do recurso MultiZonetNetworkConfig foi bem-sucedida:

kubectl get multizonenetworkconfig -n gpc-system --kubeconfig=KUBECONFIG_PATH

O exemplo a seguir mostra uma saída com links de interconexão:

NAME                       AGE   READY
multizone-network-config   26h   True

Opcional: verifique o recurso MultiZoneNetworkPeeringConfig para conferir a configuração e o status do BGP de interconexão.

A configuração real do BGP é definida pelo reconciliador de rede e armazenada no recurso MultiZoneNetworkPeeringConfig. Cada recurso MultiZoneNetworkPeeringConfig representa todas as configurações do BGP de uma zona para outra. Exemplo:

Um recurso MultiZoneNetworkPeeringConfig chamado zone-1-zone-2-peering-config pode ter esta aparência:

apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkPeeringConfig
metadata:
  name: zone-1-zone-2-peering-config
  namespace: gpc-system
spec: ...
status:
  borderLeafSwitches:
  - blswID: 1
    blswName: aa-aa-blsw01
    evpnBGPSessions:
    - bgpSessionConfig:
        addressFamily: EVPN
        bfdConfig:
          bfdMode: MultiHopBFD
        localASN: 65501
        localIP: 192.168.201.65/32
        md5SecretRef:
          name: zone-1-blsw-1-zone-2-blsw-1-evpn-bgp-password
          namespace: gpc-system
        peerASN: 65502
        peerIP: 192.168.202.65
        sourceInterface: loopback2
      bgpSessionStatus:
        prefixCounters:
          received: 4
          sent: 23
        sessionStatus: Up
        uptime: P6DT20H26M59S
    ipv4BGPSessions:
    - bgpSessionConfig:
        addressFamily: IPv4
        bfdConfig:
          bfdMode: PlainBFD
        localASN: 65501
        localIP: 192.168.208.0/31
        md5SecretRef:
          name: zone-1-blsw-1-zone-2-blsw-1-ipv4-bgp-password
          namespace: gpc-system
        peerASN: 65502
        peerIP: 192.168.208.1
      bgpSessionStatus:
        prefixCounters:
          received: 11
          sent: 11
        sessionStatus: Up
        uptime: P6DT20H27M1S
      port:
        port: 6

O status deste exemplo contém todas as configurações e os status de sessão do BGP da zona 1 à zona 2.

Para o modo de operadora da camada 3, um recurso MultiZoneNetworkPeeringConfig chamado zone-1-ipv4-peering-config que representa todas as sessões IPv4 do BGP de uma zona para a operadora da camada 3 pode ter esta aparência:

apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkPeeringConfig
metadata:
  name: zone-1-ipv4-peering-config
  namespace: gpc-system
spec: ...
status:
  borderLeafSwitches:
  - blswID: 1
    blswName: aa-aa-blsw01
    ipv4BGPSessions:
    - bgpSessionConfig:
        addressFamily: IPv4
        bfdConfig:
          bfdMode: PlainBFD
        localASN: 65501
        localIP: 192.168.208.0/31
        md5SecretRef:
          name: zone-1-blsw-1-port-6-ipv4-bgp-password
          namespace: gpc-system
        peerASN: 65502
        peerIP: 192.168.208.1
      bgpSessionStatus:
        prefixCounters:
          received: 11
          sent: 11
        sessionStatus: Up
        uptime: P6DT20H27M1S
      port:
        port: 6

2.1. Configurar as portas

A configuração do ports depende do tipo de operadora. Siga estas regras ao definir seu ports:

Se o tipo de operadora for L2, especifique n portas em Spec.Ports, em que n é igual ao número de zonas multiplicado por dois. A primeira porta precisa se conectar ao primeiro switch leaf de borda (classificado por nome do switch) da primeira zona vizinha (classificada por ID da zona). A segunda porta precisa se conectar ao segundo switch de borda da primeira zona vizinha. A terceira porta se conecta ao primeiro switch de borda da segunda zona vizinha. Outras conexões seguem esse padrão. Consulte Implantação de operadora L2 para ver uma ilustração.

Importante: para o tipo de operadora L2, o Google recomenda não exceder três zonas.
Se o tipo de operadora for L3, especifique duas portas em Spec.Ports. Os dois switches de borda na zona atual precisam usar a primeira porta para se conectar individualmente ao primeiro dispositivo de borda do provedor e a segunda porta para se conectar individualmente ao segundo dispositivo de borda do provedor. Consulte a implantação de operadora da camada 3 para mais detalhes.

2.2. Exemplos de configuração multizonal

Esta seção contém exemplos comuns de implantação.

2.2.1. Implantação de operadora L2

Esta implantação tem a seguinte configuração:

Três zonas com ASN 65501, 65502, 65503
Uma operadora L2
As conexões lógicas para essa implantação são mostradas neste diagrama:

Importante: este exemplo ilustra uma implantação de operadora L2 de três zonas. O Google recomenda não exceder três zonas para tipos de operadora da camada 2.

Confira abaixo um exemplo de arquivo YAML MultiZoneNetworkConfig:

apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkConfig
metadata:
  name: multizone-network-config
  namespace: gpc-system
spec:
  carrierType: L2
  zones:
    - zoneID: 1
      asn: 65501
    - zoneID: 2
      asn: 65502
    - zoneID: 3
      asn: 65503
  ports:
    - port: 10
    - port: 11
    - port: 12
    - port: 13

2.2.2. Implantação de operadora L3

Esta implantação tem a seguinte configuração:

Três zonas com ASN 65501, 65502, 65503
Operadora L3
As conexões lógicas para essa implantação são mostradas neste diagrama:

Confira abaixo um exemplo de arquivo YAML MultiZoneNetworkConfig:

  apiVersion: system.private.gdc.goog/v1alpha1
  kind: MultiZoneNetworkConfig
  metadata:
    name: multizone-network-config
    namespace: gpc-system
  spec:
    carrierType: L3
    zones:
      - zoneID: 1
        asn: 65501
        carrierASN: 60010
      - zoneID: 2
        asn: 65502
        carrierASN: 60010
      - zoneID: 3
        asn: 65503
        carrierASN: 60010
    ports:
      - port: 10
      - port: 11

2.3. Opcional: configurar a autenticação BFD multizona

A detecção de encaminhamento bidirecional (BFD, na sigla em inglês) é configurada em todas as sessões IPv4 e EVPN multizonais. Por padrão, o BFD simples de salto único é configurado. Siga as instruções nesta seção para implantar o BFD de vários saltos com autenticação:

Ative a autenticação de detecção de encaminhamento bidirecional (BFD) para sessões de BGP EVPN multizona. Para estabelecer e ativar sessões do BFD, verifique se as sessões pareadas do BGP nas duas zonas estão configuradas com o mesmo ID de chave de autenticação e string de chave do BFD:

Defina o tipo de chave. Recomendamos executar esse comando na máquina de bootstrap. Use pelo menos SHA-1 para a chave por motivos de segurança. Use uma chave mais segura para sua configuração, se necessário:
```
export KEY_TYPE=SHA1
```
Defina o ID e a string da chave. O ID da chave precisa ser exclusivo entre as sessões de interconexão pareadas em todas as zonas. Determine um ID de chave não usado e atribua-o à variável:
```
export KEY_ID=1
```

Gere uma chave de autenticação SHA-1 usando chronyc keygen:

CHRONY_OUTPUT=$(chronyc keygen ${KEY_ID:?} ${KEY_TYPE:?})

Exemplo de saída:

echo $CHRONY_OUTPUT
1 SHA1 HEX:887F1B88085BD0BDE4458EA7C2C4393C50A498EF

Extraia e verifique a chave de autenticação:

export KEY_STR=$(echo ${CHRONY_OUTPUT:?} | awk '{ split($3,key,":"); print key[2]}')

echo $KEY_STR
887F1B88085BD0BDE4458EA7C2C4393C50A498EF

Adicione um patch nas informações de autenticação do BFD às sessões de interconexão selecionadas:

kubectl --kubeconfig=KUBECONFIG_PATH patch secret zone-LOCAL_ZONE_ID-blsw-LOCAL_BLSW_ID-zone-REMOTE_ZONE_ID-blsw-REMOTE_BLSWID-bfd-auth-key -n gpc-system -p='{
  "stringData": {
    "bfdKeyID": "'"${KEY_ID}"'",
    "bfdKeyValue": "'"${KEY_STR}"'"
  }
}'

Verifique se a sessão do BFD está em execução:
```
switch# show bfd neighbors vrf default
```

Verifique se o campo State mostra um valor de Up e se o campo Type é SH ou MH:

OurAddr         NeighAddr       LD/RD                 RH/RS           Holdown(mult)     State       Int                   Vrf                              Type     BSID
192.168.208.31  192.168.208.30  1090519041/1090519042 Up              5237(3)           Up          Eth1/11               default                          SH       N/A
192.168.208.91  192.168.208.90  1090519042/1090519042 Up              5624(3)           Up          Eth1/12               default                          SH       N/A
192.168.202.66  192.168.201.65  1090519071/1090519060 Up              629(3)            Up          Lo2                   default                          MH       N/A
192.168.202.66  192.168.201.66  1090519072/1090519061 Up              545(3)            Up          Lo2                   default                          MH       N/A

2.4. Opcional: configurar senha do BGP multizona

Há dois tipos de senhas do Border Gateway Protocol (BGP): a senha da sessão BGP IPv4 e a senha da sessão BGP EVPN.

Por padrão, todas as senhas do BGP estão vazias. Siga as instruções nesta seção para atualizar as senhas.

2.4.1. Atualizar a senha do BGP IPv4

Se uma operadora L2 for usada, atualize a senha do BGP IPv4 aplicada à sessão BGP IPv4 entre um switch leaf de borda na zona atual e outro switch leaf de borda em outra zona:

kubectl patch secret zone-LOCAL_ZONE_ID-blsw-LOCAL_BLSW_ID-zone-REMOTE_ZONE_ID-blsw-REMOTE_BLSWID-ipv4-bgp-password -p='{"stringData":{"password":"PASSWORD"}}'

Substitua:

LOCAL_ZONE_ID: o ID numérico da zona atual.
LOCAL_BLSW_ID: o ID numérico do switch de borda da zona atual. Esse valor precisa ser 1 ou 2.
REMOTE_ZONE_ID: o ID numérico da zona remota.
REMOTE_BLSW_ID: o ID numérico do switch de borda da zona remota. Esse valor precisa ser 1 ou 2.
PASSWORD: a senha do BGP aplicada à sessão IPv4 do BGP entre o switch de borda local e o switch de borda remoto.

Se uma operadora de camada 3 for usada, atualize a senha do BGP IPv4 aplicada à sessão do BGP IPv4 entre um switch leaf de borda na zona atual e um dispositivo de borda do provedor na operadora de camada 3:

kubectl patch secret zone-LOCAL_ZONE_ID-blsw-LOCAL_BLSW_ID-port-PORT_ID-ipv4-bgp-password -p='{"stringData":{"password":"PASSWORD"}}' -n gpc-system --kubeconfig=KUBECONFIG_PATH

Substitua:

LOCAL_ZONE_ID: o ID numérico da zona atual.
LOCAL_BLSW_ID: o ID numérico do switch de borda da zona atual. Esse valor precisa ser 1 ou 2.
PORT_ID: o índice da porta Ethernet que se conecta ao dispositivo de borda do provedor.
PASSWORD: a senha do BGP aplicada à sessão IPv4 do BGP entre o switch leaf de borda local e o dispositivo de borda do provedor.

2.4.2. Atualizar a senha do BGP EVPN

Para atualizar a senha do BGP EVPN aplicada à sessão do BGP EVPN entre um switch leaf de borda na zona atual e outro switch leaf de borda em outra zona, execute:

kubectl patch secret zone-LOCAL_ZONE_ID-blsw-LOCAL_BLSW_ID-zone-REMOTE_ZONE_ID-blsw-REMOTE_BLSWID-evpn-bgp-password -p='{"stringData":{"password":"PASSWORD"}}' -n gpc-system --kubeconfig=KUBECONFIG_PATH

Substitua:

LOCAL_ZONE_ID: o ID numérico da zona atual.
LOCAL_BLSW_ID: o ID numérico do switch de borda da zona atual. Esse valor precisa ser 1 ou 2.
REMOTE_ZONE_ID: o ID numérico da zona remota.
REMOTE_BLSW_ID: o ID numérico do switch de borda da zona remota. Esse valor precisa ser 1 ou 2.
PASSWORD: a senha do BGP aplicada à sessão do BGP EVPN entre o switch leaf de borda local e o switch leaf de borda remoto.

3. Opções de configuração avançada

Esta seção apresenta opções avançadas de configuração fornecidas pelas APIs de rede multizona.

3.1. Configurar a substituição da configuração do BGP da operadora

Por padrão, os switches de borda estabelecem conexões de peering BGP com dispositivos PE da operadora usando uma alocação de endereço IP padrão. Para encontrar o endereço IP de peering do BGP específico em uso, inspecione o recurso MultiZoneNetworkPeeringConfig zone-<ZONE_ID>-ipv4-peering-config. Exemplo:

   apiVersion: system.private.gdc.goog/v1alpha1
   kind: MultiZoneNetworkPeeringConfig
   metadata:
     name: zone-1-ipv4-peering-config
     namespace: gpc-system
   spec: ...
   status:
     borderLeafSwitches:
     - blswID: 1
       blswName: aa-aa-blsw01
       ipv4BGPSessions:
       - bgpSessionConfig:
           addressFamily: IPv4
           bfdConfig:
             bfdMode: PlainBFD
           localASN: 65501
           localIP: 192.168.208.0/31
           md5SecretRef:
             name: zone-1-blsw-1-port-6-ipv4-bgp-password
             namespace: gpc-system
           peerASN: 65502
           peerIP: 192.168.208.1
   ...

Para usar um plano de endereço IP personalizado, substitua a configuração padrão do BGP da operadora seguindo a etapa abaixo:

Execute kubectl edit MultiZoneNetworkPeeringConfig zone-<ZONE_ID>-ipv4-peering-config -n gpc-system, adicionando a seção carrierBGPConfigOverride em spec.Peerings. Exemplo:

apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkPeeringConfig
metadata:
  name: zone-1-ipv4-peering-config
  namespace: gpc-system
  ...
spec:
  peeringConfigType: L3-IPv4
  peerings:
  - carrierBGPConfigOverride:
      peeringIP:
        localIP: 192.168.78.5/31
        peerIP: 192.168.78.4
    peerA:
      blswID: 1
      port:
        port: 11
      zoneID: 1
    ...

Neste exemplo, especificar carrierBGPConfigOverride.peeringIP substitui a sub-rede de peering por 192.168.78.4/31.

3.2. Configurar a substituição de porta

O Google recomenda que todos os switches de borda leaf em todas as zonas usem o mesmo conjunto de portas. Essa configuração de porta é útil para cenários em que é necessário um controle refinado das portas.

A zona local é a que você está implantando.

As zonas remotas são outras zonas no mesmo universo multizonal.

Por padrão, é necessário usar as mesmas portas para os dois switches de borda de uma zona se conectar a outra zona ou à operadora. No entanto, é possível ativar a opção de substituição de porta para especificar uma porta diferente a ser usada nessa conexão entre zonas.

Para configurar o recurso de substituição de porta, siga estas etapas:

Ative o recurso portOverride:

kubectl patch MultiZoneNetworkConfig multizone-network-config -n gpc-system --type='merge' -p '{"spec":{"enablePortOverride":true}}' --kubeconfig=KUBECONFIG_PATH

Identifique o switch de folha de borda da zona local e o switch de folha de borda da zona remota e modifique a porta do switch de folha de borda local:

kubectl edit MultiZoneNetworkPeeringConfig zone-ZONE_1_ID-zone-ZONE_2_ID -n gpc-system --kubeconfig=KUBECONFIG_PATH

Substitua:

ZONE_1_ID: o ID da zona menor entre o ID da zona local e o ID da zona remota. Por exemplo, se o ID da zona local for 1 e o ID da zona remota for 2, forneça o valor 1 aqui.
ZONE_2_ID: o ID da zona maior entre o ID da zona local e o ID da zona remota.

Um recurso MultiZoneNetworkPeeringConfig pode ser parecido com este:

apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkPeeringConfig
metadata:
  name: zone-2-zone-3-peering-config
  namespace: gpc-system
spec:
  peeringConfigType: L2
  peerings:
  - peerA:
      blswID: 1
      port:
        port: 12
      zoneID: 2
    peerB:
      blswID: 1
      port:
        port: 12
      zoneID: 3
    secrets:
    - secretRef:
        name: zone-2-blsw-1-zone-3-blsw-1-ipv4-bgp-password
        namespace: gpc-system
      type: ipv4-bgp-password
    - secretRef:
        name: zone-2-blsw-1-zone-3-blsw-1-evpn-bgp-password
        namespace: gpc-system
      type: evpn-bgp-password
    - secretRef:
        name: zone-2-blsw-1-zone-3-blsw-1-bfd-auth-key
        namespace: gpc-system
      type: bfd-auth-key
  - peerA:
      blswID: 1
      port:
        port: 12
      zoneID: 2
    peerB:
      blswID: 2
      port:
        port: 12
      zoneID: 3
    secrets:
    - secretRef:
        name: zone-2-blsw-2-zone-3-blsw-2-ipv4-bgp-password
        namespace: gpc-system
      type: ipv4-bgp-password
    - secretRef:
        name: zone-2-blsw-2-zone-3-blsw-2-evpn-bgp-password
        namespace: gpc-system
      type: evpn-bgp-password
    - secretRef:
        name: zone-2-blsw-2-zone-3-blsw-2-bfd-auth-key
        namespace: gpc-system
      type: bfd-auth-key

É necessário atualizar o valor da porta de um dos switches de borda que compõem o peering entre zonas. No campo Spec.peerings, procure o peering que abrange várias zonas. No exemplo, temos esta conexão de peering entre a zona 2 e a zona 3:

peerA:
  blswID: 1
  port:
    port: 12
  zoneID: 2
peerB:
  blswID: 2
  port:
    port: 12
  zoneID: 3

A saída mostra dois switches de borda, identificados por blswID: 1 e blswID: 2. Para o primeiro switch de borda identificado por blswID: 1, atualize a porta para o novo valor de 20:

peerA:
  blswID: 1
  port:
    port: 20
  zoneID: 2
peerB:
  blswID: 2
  port:
    port: 12
  zoneID: 3

No exemplo, atualizamos o valor da porta do primeiro switch de borda para port: 20.

Configurar interconexão multizonal Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

1. Antes de começar

2. Configurar interconexão multizonal

2.1. Configurar as portas

2.2. Exemplos de configuração multizonal

2.2.1. Implantação de operadora L2

2.2.2. Implantação de operadora L3

2.3. Opcional: configurar a autenticação BFD multizona

2.4. Opcional: configurar senha do BGP multizona

2.4.1. Atualizar a senha do BGP IPv4

2.4.2. Atualizar a senha do BGP EVPN

3. Opções de configuração avançada

3.1. Configurar a substituição da configuração do BGP da operadora

3.2. Configurar a substituição de porta

Configurar interconexão multizonal