Resolver problemas do Distributed Cloud conectado

O Google monitora e faz a manutenção remota do hardware conectado do Google Distributed Cloud. Para isso, os engenheiros do Google têm acesso Secure Shell (SSH) ao hardware conectado do Distributed Cloud. Se o Google detectar um problema, um engenheiro vai entrar em contato com você para resolver a questão. Se você tiver identificado um problema, entre em contato com o Suporte do Google imediatamente para diagnosticar e resolver a questão.

Corromper sessões do BGP em recursos do Cloud Router usados por conexões VPN

As conexões da Distributed Cloud VPN dependem de sessões do BGP estabelecidas e gerenciadas pelos recursos correspondentes do Cloud Router para anunciar rotas entre o cluster conectado da Distributed Cloud e Google Cloud. Se você modificar a configuração de um recurso do Cloud Router associado a uma conexão de VPN do Distributed Cloud, essa conexão poderá parar de funcionar.

Para recuperar a configuração corrompida da sessão do BGP no Cloud Router afetado, conclua as seguintes etapas:

  1. No console do Google Cloud , receba o nome da sessão do BGP corrompida. Exemplo:

    INTERFACE=anthos-mcc-34987234

  2. Receba os endereços IP do BGP de peering e do BGP do Cloud Router para a sessão do BGP corrompida, bem como o ASN de peering usado pela conexão afetada do Distributed Cloud VPN. Exemplo:

    GDCE_BGP_IP=168.254.208.74
CLOUD_ROUTER_BGP_IP=168.254.208.73
PEER_ASN=65506

    Se você excluiu a sessão do BGP, extraia essas informações do cluster conectado do Distributed Cloud:

    1. Consiga as credenciais do cluster:

      gcloud edge-cloud container clusters get-credentials CLUSTER_ID \
  --location REGION \
  --project PROJECT_ID

      Substitua:

      • CLUSTER_ID: o nome do cluster de destino.
      • REGION: a região do Google Cloud em que o cluster de destino é criado.
      • PROJECT_ID: o ID do projeto Google Cloud de destino.

    2. Receba a configuração do recurso MultiClusterConnectivityConfig:

      kubectl get multiclusterconnectivityconfig -A

      O comando retorna uma saída semelhante a esta:

       NAMESPACE     NAME                   LOCAL ASN              PEER ASN
 kube-system   MultiClusterConfig1    65505                   65506
 ```

    3. Receba o endereço IP do BGP do par, o endereço IP do Cloud Router e o ASN da sessão do BGP:

      kubectl describe multiclusterconnectivityconfig -n kube-system MCC_CONFIG_NAME

      Substitua MCC_CONFIG_NAME pelo nome do MultiClusterConfigResource que você recebeu na etapa anterior.

      O comando retorna uma saída semelhante a esta:

       ​​Spec:
 Asns:
   Peer:  65505
   Self:  65506 # GDCE ASN
 Tunnels:
   Ike Key:
     Name:       MCC_CONFIG_NAME-0
     Namespace:  kube-system
   Peer:
     Bgp IP:      169.254.208.73 # Cloud Router BGP IP
     Private IP:  34.157.98.148
     Public IP:   34.157.98.148
   Self:
     Bgp IP:      169.254.208.74 # GDCE BGP IP
     Private IP:  10.100.29.49
     Public IP:   208.117.254.68
 ```

  3. No console Google Cloud , receba o nome, a região e o nome do projetoGoogle Cloud do túnel da VPN corrompido. Exemplo:

    VPN_TUNNEL=VPNTunnel1
REGION=US-East1
VPC_PROJECT_ID=VPC-Project-1

  4. Exclua a sessão do BGP corrompida da configuração do Cloud Router.

  5. Crie uma interface do Cloud Router:

    gcloud compute routers add-interface --interface-name=INTERFACE_NAME \
   --vpn-tunnel=TUNNEL_NAME \ 
   --ip-address=ROUTER_BGP_IP \
   --project=VPC_PROJECT_ID \
   --region=REGION \      
   --mask-length=30

    Substitua:

    • INTERFACE_NAME: um nome descritivo que identifica exclusivamente essa interface.
    • TUNNEL_NAME: o nome do túnel da VPN que você obteve na etapa anterior.
    • ROUTER_BGP_IP: o endereço IP do BGP do Cloud Router que você obteve anteriormente neste procedimento.
    • VPC_PROJECT_ID: o ID do projeto da VPC de destinoGoogle Cloud .
    • REGION: a Google Cloud região em que o projeto da VPC de destino Google Cloud foi criado.

  6. Crie o peering do BGP:

    gcloud compute routers add-bgp-peer --interface=INTERFACE_NAME \
   --peer-name=TUNNEL_NAME \
   --region REGION \
   --project=VPC_PROJECT_ID \
   --peer-ip-address=GDCE_BGP_IP \
   --peer-asn=GDCE_BGP_ASN \
   --advertised-route-priority=100 \
   --advertisement-mode=DEFAULT

    Substitua:

    • INTERFACE_NAME: o nome da interface que você criou na etapa anterior.
    • TUNNEL_NAME: o nome do túnel VPN que você usou para criar a interface na etapa anterior.
    • REGION: a Google Cloud região em que o projeto da VPC de destino Google Cloud é criado.
    • VPC_PROJECT_ID: o ID do projeto da VPC de destinoGoogle Cloud .
    • GDCE_BGP_IP: o endereço IP do BGP do par do Distributed Cloud que você recebeu anteriormente neste procedimento.
    • GDCE_BGP_ASN: o ASN do BGP do peering do Distributed Cloud que você obteve anteriormente neste procedimento.

Nesse ponto, a sessão do BGP está de volta e operacional.

Nó travado no estado Ready,SchedulingDisabled

Quando você aplica ou exclui o recurso NodeSystemConfigUpdate ou SriovNetworkNodePolicy, o nó de destino pode ser reinicializado. Quando um nó é reinicializado, o status dele muda para NotReady ou Scheduling Disabled. Se um nó permanecer no estado Ready,SchedulingDisabled por mais de 30 minutos, faça o seguinte:

  1. Verifique a configuração e o status do recurso NodeSystemConfigUpdate ou SriovNetworkNodePolicy correspondente. Se o recurso SriovNetworkNodePolicy não existir, o nó não será compatível com SR-IOV.

  2. Se o status do recurso for Succeeded, ative o agendamento no nó usando o seguinte comando:

    kubectl uncordon NODE_NAME.

    Substitua NODE_NAME pelo nome do nó de destino.

  3. Se o problema persistir, entre em contato com o Suporte do Google.