Configure o gateway de conetividade de rede

Pré-visualização

Este produto ou funcionalidade está sujeito aos "Termos das Ofertas de Pré-DG" na secção Termos Gerais de Serviço dos Termos Específicos do Serviço. Os produtos e as funcionalidades pré-GA estão disponíveis "tal como estão" e podem ter apoio técnico limitado. Para mais informações, consulte as descrições das fases de lançamento.

Este documento mostra como configurar o Network Connectivity Gateway para um cluster no Google Distributed Cloud.

Por vezes, tem pods em execução num cluster que têm de comunicar com cargas de trabalho em execução numa nuvem virtual privada (VPC). Esta comunicação tem de ser segura. Além disso, talvez precise que esta comunicação ocorra numa rede simples sem usar um servidor proxy. O gateway de conetividade de rede permite este tipo de comunicação.

O Network Connectivity Gateway é executado como um pod no seu cluster. Conforme mostrado no diagrama seguinte, esta solução fornece túneis IPsec para tráfego de pods no seu cluster para VMs numa VPC. Quando o pod de gateway recebe prefixos para sub-redes da VPC através de uma sessão do Border Gateway Protocol (BGP), configura o encaminhamento através do Dataplane V2. Quando outros pods enviam tráfego para um endereço com um desses prefixos, o tráfego é direcionado para o pod de gateway. Em seguida, o pod de gateway encaminha o tráfego através de um túnel IPsec para Google Cloud.

Nota: o Google Distributed Cloud em execução no Ubuntu 18.04 não é suportado para o Network Connectivity Gateway, mas todos os outros SOs suportados pelo Google Distributed Cloud são suportados. Para ver a lista das distribuições e versões do Linux suportadas pelo Google Distributed Cloud, consulte o artigo Selecione o seu sistema operativo.

O gateway de conetividade de rede não suporta as seguintes funcionalidades e capacidades:

• IPv6 para VPN de alta disponibilidade (e BGP)
• MD5 para BGP
• Deteção de encaminhamento bidirecional (BFD) para BGP

Crie Google Cloud recursos

Antes de ativar o Network Connectivity Gateway num cluster, tem de ter os seguintes Google Cloud recursos:

• Um Cloud Router

• Um gateway de HA VPN

• Um gateway de VPN de pares: uma interface

• Dois túneis de VPN

• Duas sessões BGP: uma para cada um dos seus túneis de VPN

Para obter informações sobre como criar e configurar estes recursos, consulte o artigo Criar um gateway de VPN de alta disponibilidade para um gateway de VPN de pares.

À medida que cria estes recursos, reúna as seguintes informações e tenha-as disponíveis para mais tarde:

• Os dois endereços IP externos que Google Cloud foram atribuídos ao seu gateway de VPN de alta disponibilidade.

• O endereço IP público para o tráfego IPsec/VPN que sai da sua organização. Este endereço pode ser o resultado de uma tradução de endereços de rede (NAT).

• A sua chave pré-partilhada.

• O número do sistema autónomo (ASN) que atribuiu ao seu Cloud Router para sessões BGP.

• O ASN que escolheu usar no seu cluster no local para sessões BGP.

• Para cada sessão BGP, o endereço local do link>, como 169.254.1.1, a ser usado pelo seu Cloud Router e o endereço local do link a ser usado no seu cluster no local.

Para ver informações sobre como encontrar os detalhes da configuração da sessão de BGP, consulte o artigo Veja a configuração da sessão de BGP.

Requisitos de clusters

A transferência da ferramenta de linha de comandos do Network Connectivity Gateway ncgctl-v1.12.0-linux-amd64.tar.gz é compatível apenas com a versão 1.12 do Google Distributed Cloud. Se estiver a criar um cluster da versão 1.12.0, ativa o Network Connectivity Gateway com uma anotação no ficheiro de configuração do cluster.

Nota: se tiver um cluster existente com a versão 1.12.0 ou superior, pode usar um comando ncgctl para ativar o gateway de conetividade de rede. Para mais informações, consulte o artigo Instalar.

Para ativar o Network Connectivity Gateway durante a criação do cluster:

1. No ficheiro de configuração do cluster, adicione a anotação baremetal.cluster.gke.io/enable-gng: "true".

   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     annotations:
       baremetal.cluster.gke.io/enable-gng: "true"
     name: my-cluster
     namespace: cluster-my-cluster
   spec:
   ...
     anthosBareMetalVersion: 1.12.0
     ...
   

2. Use bmctl create para criar o cluster:

   bmctl create cluster -c CLUSTER_NAME
   

   Substitua CLUSTER_NAME pelo nome que especificou quando criou o ficheiro de configuração do cluster. Para mais informações sobre a criação de clusters, consulte o artigo Vista geral da criação de clusters.

Transferir

Para transferir o ncgctl, a ferramenta de linha de comandos do Network Connectivity Gateway, siga estes passos:

1. Transfira os componentes do Network Connectivity Gateway e as definições de recursos personalizados:

   gcloud storage cp gs://ncg-release/anthos-baremetal/ncgctl-v1.12.0-linux-amd64.tar.gz .
   

2. Extraia o arquivo:

   tar -xvzf ncgctl-v1.12.0-linux-amd64.tar.gz
   

Instalação

Para instalar o ncgctl, siga estes passos:

1. Execute verificações de pré-publicação para se certificar de que o cluster cumpre os pré-requisitos. Por exemplo, certifique-se de que o Dataplane V2 está ativado.

   ./bin/ncgctl --verify --kubeconfig CLUSTER_KUBECONFIG
   

   Substitua CLUSTER_KUBECONFIG pelo caminho do ficheiro kubeconfig do cluster.

2. Instale o gateway de conetividade de rede.

   ./bin/ncgctl --install --kubeconfig CLUSTER_KUBECONFIG
   

   Nota: se estiver a criar um novo cluster da versão 1.12.0, pode ignorar os passos seguintes. Quando cria clusters, recomendamos que adicione a anotação baremetal.cluster.gke.io/enable-gng: "true" ao ficheiro de configuração do cluster para ativar o gateway de conetividade de rede. Para mais informações, consulte os requisitos de cluster.

3. Se tiver um cluster da versão 1.12.0 existente, pode usar o seguinte comando ncgctl para ativar o gateway de conetividade de rede:

   ./bin/ncgctl --enable-ncg-on-existing-cluster
   

   O comando ncgctl aceita -e como uma versão abreviada da flag de ativação.

4. Para ver atalhos adicionais e ajuda com outros comandos, use o seguinte comando:

   ./bin/ncgctl --help
   

Crie um segredo para a sua chave pré-partilhada

Os gateways em cada extremidade dos túneis IPsec usam um Secret que contém a sua chave partilhada previamente para autenticação.

Para criar o segredo, siga estes passos:

1. Crie um ficheiro denominado psk-secret.yaml com os seguintes detalhes do manifesto secreto:

   apiVersion: v1
   kind: Secret
   metadata:
     name: "ike-key"
     namespace: "kube-system"
   data:
     psk: PRE_SHARED_KEY
   

   Substitua PRE_SHARED_KEY por uma chave pré-partilhada codificada em base64. Se tiver uma chave em texto simples, codifique-a no formato base64 antes de criar este segredo. Por exemplo, se a Google Cloud consola gerou uma chave para si, esta está em texto simples e tem de a codificar. Para codificar uma chave em base64:

   echo -n PLAINTEXT_KEY | base64
   

2. Crie o Secret:

   kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f psk-secret.yaml
   

Crie 2 recursos personalizados OverlayVPNTunnel

Para iniciar duas sessões IPsec, crie OverlayVPNTunnelrecursos personalizados.

1. Crie um ficheiro denominado overlay-vpn-tunnels.yaml com os seguintes OverlayVPNTunnel detalhes do manifesto:

   apiVersion: networking.gke.io/v1alpha1
   kind: OverlayVPNTunnel
   metadata:
     namespace: "kube-system"
     name: TUNNEL_1_NAME
   spec:
     ikeKey:
       name: "ike-key"
       namespace: "kube-system"
     peer:
       publicIP: PEER_PUBLIC_IP_1
     self:
       publicIP: SELF_PUBLIC_IP
     localTunnelIP: SELF_LOCAL_TUNNEL_IP_1
   ---
   apiVersion: networking.gke.io/v1alpha1
   kind: OverlayVPNTunnel
   metadata:
     namespace: "kube-system"
     name: TUNNEL_2_NAME
   spec:
     ikeKey:
       name: "ike-key"
       namespace: "kube-system"
     peer:
       publicIP: PEER_PUBLIC_IP_2
     self:
       publicIP: SELF_PUBLIC_IP
     localTunnelIP: SELF_LOCAL_TUNNEL_IP_2
   

   Substitua o seguinte:

   • TUNNEL_NAME_1: um nome à sua escolha para o primeiro OverlayVPNTunnel.

   • TUNNEL_NAME_2: um nome à sua escolha para o segundo OverlayVPNTunnel.

   • PEER_PUBLIC_IP_1: o endereço IP público de uma interface no seu gateway de HA VPN. Especificou esta interface quando criou o seu primeiro túnel de VPN.

   • PEER_PUBLIC_IP_2: o endereço IP público da outra interface no seu gateway de HA VPN. Especificou esta interface quando criou o segundo túnel VPN.

   • SELF_LOCAL_TUNNEL_IP_1: o endereço local do link a ser usado no seu cluster para sessões BGP no primeiro túnel.

   • SELF_LOCAL_TUNNEL_IP_2: o endereço local do link a usar no cluster para sessões BGP através do segundo túnel.

   • SELF_PUBLIC_IP: o endereço IP público para o tráfego IPsec/VPN que sai da sua organização. Este endereço pode ser o resultado de uma tradução de endereços de rede (NAT).

2. Crie os dois OverlayVPNTunnels:

   kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f overlay-vpn-tunnels.yaml
   

3. Verifique o estado dos túneis:

   kubectl --kubeconfig CLUSTER_KUBECONFIG get OverlayVPNTunnel \
       --namespace kube-system --output yaml
   

Crie 2 recursos personalizados OverlayBGPPeer

Para iniciar uma sessão BGP em cada um dos túneis, crie dois OverlayBGPPeerrecursos personalizados.

1. Crie um ficheiro denominado overlay-bgp-peers.yaml com os seguintes detalhes do manifesto OverlayBGPPeer.

   apiVersion: networking.gke.io/v1alpha1
   kind: OverlayBGPPeer
   metadata:
     namespace: "kube-system"
     name: BGP_PEER_1_NAME
   spec:
     localASN: LOCAL_ASN
     localIP: LOCAL_IP
     peerIP: PEER_IP_1
     peerASN: PEER_ASN
     vpnTunnel: TUNNEL_1_NAME
   ---
   apiVersion: networking.gke.io/v1alpha1
   kind: OverlayBGPPeer
   metadata:
     namespace: "kube-system"
     name: BGP_PEER_2_NAME
   spec:
     localASN: LOCAL_ASN
     localIP: LOCAL_IP
     peerIP: PEER_IP_2
     peerASN: PEER_ASN
     vpnTunnel: TUNNEL_2_NAME
   

   Substitua o seguinte:

   • BGP_PEER_1_NAME: um nome à sua escolha para o primeiro OverlayBGPPeer.

   • BGP_PEER_2_NAME: um nome à sua escolha para a segunda OverlayBGPPeer.

   • LOCAL_ASN: o ASN a usar no seu cluster para sessões de BGP.

   • LOCAL_IP: o endereço IP público para o tráfego de IPsec/VPN que sai da sua organização. Este endereço pode ser o resultado de uma tradução de endereços de rede (NAT).

   • PEER_IP_1: o endereço IP público de uma interface no seu gateway de HA VPN. Especificou esta interface quando criou o seu primeiro túnel de VPN.

   • PEER_IP_2: o endereço IP público da outra interface no seu gateway de HA VPN. Especificou esta interface quando criou o segundo túnel de VPN.

   • PEER_ASN: o ASN atribuído ao seu Cloud Router para sessões BGP.

   • TUNNEL_1_NAME: o nome do primeiro OverlayVPNTunnel que criou anteriormente.

   • TUNNEL_2_NAME: o nome do segundo OverlayVPNTunnel que criou anteriormente.

2. Crie os OverlayBGPPeer recursos personalizados:

   kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f overlay-bgp-peers.yaml
   

3. Verifique o estado das sessões de BGP:

   kubectl --kubeconfig CLUSTER_KUBECONFIG get OverlayBGPPeer --namespace kube-system \
       --output yaml
   

Verifique o estado do Network Connectivity Gateway

A instalação criou um recurso personalizado NetworkConnectivityGateway.

• Veja o NetworkConnectivityGateway recurso personalizado:

  kubectl --kubeconfig CLUSTER_KUBECONFIG get NetworkConnectivityGateway --namespace kube-system \
      --output yaml
  

  O resultado é semelhante ao seguinte. Verifique se vê Status: Healthy:

  apiVersion: networking.gke.io/v1alpha1
  kind: NetworkConnectivityGateway
  metadata:
    namespace: kube-system
    name: default
  spec:
  status:
      CurrNode: worker1-node
      CreatedTime: 2021-09-07T03:18:15Z
      LastReportTime: 2021-09-21T23:57:54Z
      Status:  Healthy
  

Verifique os registos do gateway de conetividade de rede

O pod de gateway pertence a um DaemonSet denominado ncgd, pelo que o nome do pod começa com ncgd.

Para ver os registos do Network Connectivity Gateway, siga estes passos:

1. Encontre o nome do pod de gateway:

   kubectl --kubeconfig CLUSTER_KUBECONFIG pods --namespace kube-system | grep ncgd
   

2. Veja os registos do pod de gateway:

   kubectl --kubeconfig CLUSTER_KUBECONFIG logs GATEWAY_POD --namespace kube-system \
       --output yaml
   

   Substitua GATEWAY_POD pelo nome do pod da gateway.

Desinstalar

Para desinstalar o Network Connectivity Gateway de um cluster:

./bin/ncgctl –-uninstall --kubeconfig CLUSTER_KUBECONFIG

Resolução de problemas

Para ver sugestões de resolução de problemas relacionados com o gateway de conetividade de rede, consulte o artigo Resolva problemas do gateway de conetividade de rede.