Esta página foi traduzida pela API Cloud Translation.

Configure a interligação multizona

Esta página descreve a configuração necessária que tem de fazer nas zonas existentes de uma implementação multizona quando uma nova zona se junta à implementação. Esta configuração permite-lhe estabelecer ligações à nova zona.

1. Antes de começar

Tem de ter o seguinte para configurar a interligação multizona no Google Distributed Cloud (GDC) air-gapped:

Um ficheiro kubeconfig gerado e uma variável de ambiente. Para obter detalhes, consulte o manual de procedimentos IAM-R0004.
Um operador de infraestrutura (IO) com acesso temporário ao cluster de administrador principal. Para obter detalhes, consulte o manual de procedimentos IAM-R0005.

2. Configure a interligação multizona

Configure um recurso MultiZoneNetworkConfig em cada zona da implementação de várias zonas:
1. Encontre o cluster correto com o qual interagir. Se o cluster de administrador raiz estiver em execução, use o kubeconfig para o cluster de administrador raiz. Caso contrário, use o kubeconfig para o cluster do tipo bootstrap. Para obter detalhes, consulte o manual de procedimentos IAM-R0004. Preencha o caminho do kubeconfig aqui:
```
KUBECONFIG=KUBECONFIG_PATH
```
2. Crie um ficheiro YAML com o nome multizone_network_config.yaml.
3. Adicione o seguinte conteúdo ao ficheiro:
```
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 o seguinte:
  - CARRIER_TYPE: o tipo de operadora de backbone de várias zonas. Tem de ser L2 ou L3.
    
    Importante: para o tipo de operadora L2, a Google recomenda vivamente que não exceda as 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) do BGP da rede de dados da primeira zona na região do GDC.
  - METERING_SUBNET_1: a sub-rede medida desta zona. Este campo tem de ser preenchido com a sub-rede do recurso zone-infra-cidr CIDRClaim no cluster de administrador raiz da zona associada. Este campo destina-se apenas a fins de medição e não tem qualquer efeito no controlo do anúncio de sub-rede. Tem de manter este campo sincronizado com as sub-redes reais que estão a ser anunciadas. Se este campo não estiver especificado, não é medido tráfego para esta zona.
  - ZONE_2_ID: o ID da segunda zona na região do GDC.
  - ZONE_2_ASN: o ASN BGP da rede de dados da segunda zona na região do GDC.
  - METERING_SUBNET_2: a sub-rede medida desta zona. Este campo tem de ser preenchido com a sub-rede do recurso zone-infra-cidr CIDRClaim no cluster de administrador raiz da zona associada. Este campo destina-se apenas a fins de medição e não tem qualquer efeito no controlo do anúncio de sub-rede. Tem de manter este campo sincronizado com as sub-redes reais que estão a ser anunciadas. Se este campo não estiver especificado, não é medido tráfego para esta zona.
  - PORT_1: a primeira porta que participa na interligação de várias zonas. Consulte o artigo Configure as portas para mais informações.
  - PORT_2: a segunda porta que participa na interligação de várias zonas . Consulte o artigo Configure as portas para mais informações.
  - MTU: o valor de MTU aplicado a todas as portas. Se não for especificado, o valor predefinido é 9216.
  Atenção: todas as zonas, incluindo a zona atual, têm de ser incluídas no campo zones.
  Nota: os ASNs da zona têm de ser iguais ao dataASN das zonas associadas.
  
  Consulte Exemplos de configuração de várias zonas para ver exemplos de implementação comuns.
4. Aplique o ficheiro multizone_network_config.yaml ao cluster:
```
kubectl apply -f multizone_network_config.yaml --kubeconfig=KUBECONFIG_PATH
```
5. Verifique se a criação do recurso MultiZonetNetworkConfig foi bem-sucedida:
```
kubectl get multizonenetworkconfig -n gpc-system --kubeconfig=KUBECONFIG_PATH
```
  O exemplo seguinte mostra um resultado com links de interconexão:
```
NAME                       AGE   READY
multizone-network-config   26h   True
```
6. Opcional: verifique o recurso MultiZoneNetworkPeeringConfig para a configuração e o estado do BGP da interligação.
  
  A configuração de BGP real é definida pelo reconciliador de rede e armazenada no recurso MultiZoneNetworkPeeringConfig. Cada recurso MultiZoneNetworkPeeringConfig representa todas as configurações de BGP de uma zona para a outra. Por exemplo:
  - Um recurso MultiZoneNetworkPeeringConfig com o nome zone-1-zone-2-peering-config pode ter o seguinte aspeto:
```
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 estado deste exemplo contém todas as configurações da sessão BGP e os estados da sessão BGP da zona um para a zona dois.
  - Para o modo de operadora L3, um recurso MultiZoneNetworkPeeringConfig denominado zone-1-ipv4-peering-config que representa todas as sessões BGP IPv4 de uma zona para a operadora L3 pode ter o seguinte aspeto:
```
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. Configure as portas

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

Se o tipo de transportadora for L2, tem de especificar n portas em Spec.Ports, em que n é igual ao número de zonas multiplicado por dois. A primeira porta tem de se ligar ao primeiro comutador de folha de limite (ordenado por nome do comutador) da primeira zona adjacente (ordenada por ID da zona). A segunda porta tem de se ligar ao segundo comutador de folha de limite da primeira zona vizinha. A terceira porta liga-se ao primeiro comutador folha de limite da segunda zona vizinha. As ligações adicionais seguem este padrão. Consulte a implementação da operadora L2 para ver uma ilustração.

Importante: para o tipo de operadora L2, a Google recomenda vivamente que não exceda as três zonas.
Se o tipo de transportadora for L3, tem de especificar duas portas em Spec.Ports. Ambos os comutadores de folhas de limite na zona atual têm de usar a primeira porta para se ligarem individualmente ao primeiro dispositivo de limite do fornecedor e têm de usar a segunda porta para se ligarem individualmente ao segundo dispositivo de limite do fornecedor. Consulte a implementação de operadora de nível 3 para ver mais detalhes.

2.2. Exemplos de configuração de várias zonas

Esta secção contém exemplos de implementação comuns.

2.2.1. Implementação de operador L2

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

Três zonas com ASN 65501, 65502 e 65503
Uma operadora L2
As associações lógicas para esta implementação são apresentadas neste diagrama:

Importante: este exemplo ilustra uma implementação de operadora de nível 2 de três zonas. A Google recomenda vivamente que não exceda as três zonas para tipos de operadoras de nível 2.

Segue-se um exemplo de um MultiZoneNetworkConfig ficheiro YAML:

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. Implementação de operador de nível 3

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

Três zonas com ASN 65501, 65502 e 65503
Operadora L3
As associações lógicas para esta implementação são apresentadas neste diagrama:

Segue-se um exemplo de um MultiZoneNetworkConfig ficheiro YAML:

  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: configure a autenticação BFD de várias zonas

A deteção de encaminhamento bidirecional (BFD) está configurada em todas as sessões IPv4 e EVPN de várias zonas. Por predefinição, o BFD simples de um salto está configurado. Siga as instruções nesta secção para implementar o BFD de vários saltos com autenticação:

Ative a autenticação de deteção de encaminhamento bidirecional (BFD) para sessões BGP EVPN de várias zonas. Para estabelecer e ativar sessões BFD, certifique-se de que as sessões BGP sincronizadas em ambas as zonas estão configuradas com o mesmo ID da chave de autenticação BFD e string da chave:

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

Gere uma chave de autenticação SHA-1 através do chronyc keygen:

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

Exemplo de saída:

echo $CHRONY_OUTPUT
1 SHA1 HEX:887F1B88085BD0BDE4458EA7C2C4393C50A498EF

Extraia a chave de autenticação e valide-a:

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

echo $KEY_STR
887F1B88085BD0BDE4458EA7C2C4393C50A498EF

Aplique patch às 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 BFD está em execução:
```
switch# show bfd neighbors vrf default
```

Verifique se o campo State apresenta 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: configure a palavra-passe BGP multizona

Existem dois tipos de palavras-passe do Border Gateway Protocol (BGP): a palavra-passe da sessão BGP IPv4 e a palavra-passe da sessão BGP EVPN.

Por predefinição, todas as palavras-passe BGP estão vazias. Siga as instruções nesta secção para atualizar as palavras-passe.

2.4.1. Atualize a palavra-passe de BGP IPv4

Se for usado um transportador L2, atualize a palavra-passe BGP IPv4 aplicada à sessão BGP IPv4 entre um comutador de folha de limite na zona atual e outro comutador de folha de limite noutra 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 o seguinte:

LOCAL_ZONE_ID: o ID numérico da zona atual.
LOCAL_BLSW_ID: o ID numérico do comutador de folha de limite da zona atual. Este valor tem de ser 1 ou 2
REMOTE_ZONE_ID: o ID numérico da zona remota.
REMOTE_BLSW_ID: o ID numérico do comutador de folha de limite da zona remota. Este valor tem de ser 1 ou 2
PASSWORD: A palavra-passe de BGP aplicada à sessão de BGP IPv4 entre o comutador de folha de limite local e o comutador de folha de limite remoto.

Se for usado um operador de Nível 3, atualize a palavra-passe de BGP IPv4 aplicada à sessão de BGP IPv4 entre um comutador de folha de limite na zona atual e um dispositivo de limite do fornecedor no operador de Nível 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 o seguinte:

LOCAL_ZONE_ID: o ID numérico da zona atual.
LOCAL_BLSW_ID: o ID numérico do comutador de folha de limite da zona atual. Este valor tem de ser 1 ou 2.
PORT_ID: o índice da porta Ethernet que se liga ao dispositivo de extremidade do fornecedor.
PASSWORD: a palavra-passe de BGP aplicada à sessão de BGP IPv4 entre o comutador de folha de limite local e o dispositivo de limite do fornecedor.

2.4.2. Atualize a palavra-passe do BGP EVPN

Para atualizar a palavra-passe BGP EVPN aplicada à sessão BGP EVPN entre um comutador de folha de limite na zona atual e outro comutador de folha de limite noutra 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 o seguinte:

LOCAL_ZONE_ID: o ID numérico da zona atual.
LOCAL_BLSW_ID: o ID numérico do comutador de folha de limite da zona atual. Este valor tem de ser 1 ou 2.
REMOTE_ZONE_ID: o ID numérico da zona remota.
REMOTE_BLSW_ID: o ID numérico do comutador de folha de limite da zona remota. Este valor tem de ser 1 ou 2.
PASSWORD: a palavra-passe de BGP aplicada à sessão de BGP evpn entre o comutador de folha de limite local e o comutador de folha de limite remoto.

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

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

3.1. Configure a substituição da configuração de BGP do operador

Por predefinição, os comutadores de folhas de limite estabelecem ligações de peering BGP com dispositivos PE de operadora através de uma atribuição de endereço IP predefinida. Pode encontrar o endereço IP de peering BGP específico em utilização inspecionando o recurso MultiZoneNetworkPeeringConfigzone-<ZONE_ID>-ipv4-peering-config. Por 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ços IP personalizado, substitua a configuração de BGP da operadora predefinida seguindo o passo abaixo:

Executar kubectl edit MultiZoneNetworkPeeringConfig zone-<ZONE_ID>-ipv4-peering-config -n gpc-system, adicionando a secçã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, a especificação de carrierBGPConfigOverride.peeringIP substitui a sub-rede de peering por 192.168.78.4/31.

3.2. Configure a substituição de portas

A Google recomenda que todos os comutadores de folha de limite em todas as zonas usem o mesmo conjunto de portas. Esta configuração de portas é útil para cenários em que é necessário um controlo detalhado das portas.

A zona local é a zona que está a implementar.

As zonas remotas são outras zonas no mesmo universo de várias zonas.

Por predefinição, tem de usar as mesmas portas para os dois comutadores de folha de limite de uma zona para se ligarem a outra zona ou à operadora. No entanto, pode ativar a opção de substituição de porta para especificar uma porta diferente a usar para esta ligação entre zonas.

Para configurar a funcionalidade de substituição de porta, siga estes passos:

Ative a funcionalidade portOverride:

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

Identifique o comutador de folhas de limite da zona local e o comutador de folhas de limite da zona remota, e modifique a porta do comutador de folhas de limite local:

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

Substitua o seguinte:

ZONE_1_ID: o ID da zona mais pequeno 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 de zona maior entre o ID de zona local e o ID de zona remoto.

Um recurso MultiZoneNetworkPeeringConfig pode ter o seguinte aspeto:

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

Tem de atualizar o valor da porta de um dos comutadores de folha de limite que compõem a interligação entre zonas. No campo Spec.peerings, procure o peering que abrange várias zonas. No exemplo, temos esta ligação de pares entre a zona dois e a zona três:

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

O resultado mostra dois comutadores de folhas de limite, identificados por blswID: 1 e blswID: 2. Para o primeiro comutador de folha de limite 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 comutador de folha de limite para port: 20.