Solução de problemas e operações da Entrada para Anthos

O controlador de Entrada do Anthos gerencia os recursos do Compute Engine. Os recursos MultiClusterIngress (MCI) e MultiClusterService (MCS) são mapeados para diferentes recursos do Compute Engine. Portanto, entender a relação entre esses recursos ajuda a resolver problemas. Por exemplo, examine o recurso MCI a seguir:

apiVersion: extensions/v1beta1
kind: MultiClusterIngress
metadata:
  name: foo-ingress
spec:
  rules:
  - host: store.foo.com
    http:
      paths:
      - backend:
          serviceName: store-foo
          servicePort: 80
  - host: search.foo.com
    http:
      paths:
      - backend:
          serviceName: search-foo
          servicePort: 80

Compute Engine para mapeamentos de recursos do Ingress for Anthos

Na tabela a seguir, mostramos o mapeamento de recursos do Environ para recursos criados nos clusters do Kubernetes e no Google Cloud:

Recurso do Kubernetes Recurso do Google Cloud Descrição
MultiClusterIngress Regra de encaminhamento VIP do balanceador de carga HTTP(S).
Proxy de destino Configurações de terminações HTTP/S conseguidas pelas anotações e do bloco TLS.
Mapa de URL Mapeamento de caminho do host virtual na seção de regras.
MultiClusterService Serviço do Kubernetes Recurso derivado do modelo.
Serviço de back-end Um serviço de back-end é criado para cada par (Service, ServicePort).
Grupos de endpoint de rede Conjunto de pods de back-end que participam do serviço.

No diagrama a seguir, demonstramos a relação entre os recursos do MCI/MCS e do balanceador de carga do Compute Engine em dois clusters de membros:

Relação do balanceador de carga MCI/MCS

Como inspecionar recursos do balanceador de carga do Compute Engine

Depois de criar um balanceador de carga, o status da Entrada conterá os nomes de cada recurso do Compute Engine criado para construir o balanceador de carga. Exemplo:

Name:         shopping-service
Namespace:    prod
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1beta1
Kind:         MultiClusterIngress
Metadata:
  Creation Timestamp:  2019-07-16T17:23:14Z
  Finalizers:
    mci.finalizer.networking.gke.io
Spec:
  Template:
    Spec:
      Backend:
        Service Name:  shopping-service
        Service Port:  80
Status:
  VIP:  34.102.212.68
  CloudResources:
    Firewalls: "mci-l7"
    ForwardingRules: "mci-abcdef-myforwardingrule"
    TargetProxies: "mci-abcdef-mytargetproxy"
    UrlMap: "mci-abcdef-myurlmap"
    HealthChecks: "mci-abcdef-80-myhealthcheck"
    BackendServices: "mci-abcdef-80-mybackendservice"
    NetworkEndpointGroups: "k8s1-neg1", "k8s1-neg2", "k8s1-neg3"

VIP não criado

Se você não vir um VIP, talvez tenha ocorrido um erro durante a criação. Para ver se ocorreu um erro, execute o comando a seguir:

kubectl describe mci shopping-service

A saída pode ser semelhante a:

Name:         shopping-service
Namespace:    prod
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1beta1
Kind:         MultiClusterIngress
Metadata:
  Creation Timestamp:  2019-07-16T17:23:14Z
  Finalizers:
    mci.finalizer.networking.gke.io
Spec:
  Template:
    Spec:
      Backend:
        Service Name:  shopping-service
        Service Port:  80
Status:
  VIP:  34.102.212.68
Events:
  Type     Reason  Age   From                              Message
  ----     ------  ----  ----                              -------
  Warning  SYNC    29s   multi-cluster-ingress-controller  error translating MCI prod/shopping-service: exceeded 4 retries with final error: error translating MCI prod/shopping-service: multiclusterservice prod/shopping-service does not exist

Neste exemplo, o erro foi que o usuário não criou um recurso MultiClusterService que foi referenciado por um MultiClusterIngress.

Na maioria dos casos, a mensagem de erro indica o problema original. Caso isso não aconteça, entre em contato com gke-mci-feedback@google.com para receber ajuda.

Resposta 502

Se o balanceador de carga tiver recebido um VIP, mas exibir consistentemente uma resposta 502, as verificações de integridade do balanceador de carga poderão falhar. As verificações de integridade podem falhar por dois motivos:

  1. Os pods de aplicativos não são íntegros. Consulte a depuração do Console do Cloud, por exemplo.
  2. Um firewall configurado incorretamente está impedindo que os verificadores de integridade do Google realizem verificações de integridade.

No primeiro caso, certifique-se de que seu aplicativo esteja realmente exibindo uma resposta 200 no caminho "/".

No segundo caso, verifique se existe um firewall chamado “mci-default-l7” na sua VPC. O controlador de entrada cria o firewall na sua VPC para garantir que os verificadores de integridade do Google alcancem seus back-ends. Se o firewall não existir, certifique-se de que não haja automação externa que exclua esse firewall após sua criação.

Tráfego não adicionado ou removido do cluster

Ao adicionar uma nova associação, o tráfego precisa alcançar os back-ends no cluster original quando aplicável. Da mesma forma, se uma associação for removida, nenhum tráfego deverá alcançar os back-ends no cluster original. Se você não estiver observando esse comportamento, verifique se há erros nos recursos MultiClusterIngress e MultiClusterService.

Casos comuns em que esse erro ocorreria incluem adicionar uma nova assinatura a um cluster do GKE que não está no modo nativo de VPC ou adicionar uma nova assinatura, mas não implantar um aplicativo no cluster do GKE.

  1. Descreva o MultiClusterService:

    kubectl describe mcs zone-svc
    
  2. Descreva o MultiClusterIngress:

    kubectl describe mci zone-mci
    

Se os comandos acima não revelarem o erro, entre em contato com gke-mci-feedback@google.com para receber ajuda.

Migração do cluster de configuração

Para entender mais sobre os casos de uso da migração, consulte o conceito de design do cluster de configuração.

A migração do cluster de configuração pode ser uma operação de interrupção se não for processada corretamente. Siga estas diretrizes ao realizar uma migração de cluster de configuração:

  1. Use a anotação static-ip nos recursos da MCI. Se isso não for feito, o tráfego será interrompido durante a migração. Os IPs temporários serão recriados ao migrar clusters de configuração.
  2. Os recursos MultiClusterIngress e MultiClusterService precisam ser implantados de maneira idêntica nos clusters de configuração novo e atual. As diferenças entre eles resultarão na reconciliação de recursos MCS e MCI que são diferentes no novo cluster de configuração.
  3. Apenas um cluster de configuração fica ativo por vez. Até que o cluster de configuração seja alterado, os recursos de MCI e MCS no novo cluster de configuração não afetarão os recursos do balanceador de carga.

Para migrar o cluster de configuração, execute o comando a seguir:

  gcloud alpha container hub ingress update \
    --config-membership=projects/project_id/locations/global/memberships/new_config_cluster

Verifique se o comando funcionou, garantindo que não haja erros visíveis no estado do recurso:

  gcloud alpha container hub ingress describe

Depuração do console

Na maioria dos casos, é útil verificar o estado exato do balanceador de carga ao depurar um problema. Para encontrar o balanceador de carga, acesse Balanceamento de carga no Console do Google Cloud.

Códigos de erro/aviso

O Ingress for Anthos emite códigos de erro e aviso em recursos MCI e MCS, bem como no campo gcloud multiclusteringress Descrição para problemas conhecidos. Essas mensagens têm códigos de erro e alerta documentados para facilitar a compreensão do que significa quando algo não está funcionando como esperado. Cada código consiste em um código de erro no formato AVMBR123, em que 123 é um número exclusivo que corresponde a um erro ou alerta e sugestões sobre como resolvê-lo.

AVMBR101: "Anotação [NAME] não reconhecida"

Esse erro é exibido quando uma anotação é especificada em uma especificação MCI/MCS que não é reconhecida. Há alguns motivos para a anotação não ser reconhecida:

  1. A anotação não é compatível com o Ingress for Anthos. Isso pode ser esperado se você anota recursos que não se espera que sejam usados pelo controlador de entrada do Anthos.

  2. A anotação é compatível, mas está incorreta e, portanto, não é reconhecida.

Nos dois casos, consulte a documentação para entender as anotações compatíveis e como elas são especificadas.

AVMBR102: "[RESOURCE_NAME] não encontrado"

Esse erro é exibido quando um recurso complementar é especificado em uma MCI, mas não pode ser encontrado na associação de configuração. Por exemplo, esse erro é gerado quando uma MCI se refere a um MCS que não pode ser encontrado ou um MCS se refere a um BackendConfig que não pode ser encontrado. Há alguns motivos pelos quais um recurso não foi encontrado:

  1. Ele não está no namespace adequado. Verifique se os recursos que fazem referência entre si, estão no mesmo namespace.
  2. O nome do recurso está incorreto.
  3. O recurso realmente não existe com o namespace + nome adequado. Nesse caso, crie-o.

AVMBR103: "[CLUSTER_SELECTOR] inválido"

Esse erro é exibido quando um seletor de cluster especificado em um MCS é inválido. Há alguns motivos para esse seletor ser inválido:

  1. A string fornecida contém um erro de digitação.
  2. A string fornecida refere-se a uma assinatura que não existe mais no Environ.

AVMBR104: "Não é possível localizar os NEGs para a porta de serviço [SERVICE_PORT]"

Esse erro é gerado quando os NetworkEndpointGroups (NEGs, na sigla em inglês) de um determinado MultiClusterService e par de porta de serviço não podem ser encontrados. Os NEGs são os recursos que contêm os endpoints do pod em cada um dos clusters de back-end. O principal motivo para os NEGs não existirem é porque ocorreu um erro ao criar ou atualizar os serviços derivados nos clusters de back-end. Verifique os eventos no recurso MultiClusterService para ver mais informações.

AVMBR105: "Licença do Anthos ausente".

Este erro é exibido no estado de recurso e indica que a API do Anthos (anthos.googleapis.com) não está ativada.

AVMBR106: "Serviço derivado inválido: [REASON]."

Esse erro é exibido abaixo dos eventos do recurso MultiClusterService. Um motivo comum para esse erro é que o recurso de serviço derivado de MultiClusterService tem uma especificação inválida.

Por exemplo, este MultiClusterService não tem nenhum ServicePort definido na respectiva especificação.

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: zone-mcs
  namespace: zoneprinter
spec:
  clusters:
  - link: "us-central1-a/gke-us"
  - link: "europe-west1-c/gke-eu"

Este erro é exibido abaixo do estado do recurso e ocorre porque não há nenhum cluster do GKE subjacente ao recurso de assinatura. Para confirmar, execute o seguinte comando:

gcloud container hub memberships describe membership-name

e garanta que não haja nenhum link de recurso do cluster do GKE no campo de endpoint.

AVMBR108: "Cluster do GKE [NAME] não encontrado".

Esse erro será exibido em Estado do recurso e será gerado se o cluster do GKE subjacente à assinatura não existir.

AVMBR109: "[NAME] não é um cluster VPC nativo do GKE."

Esse erro é exibido em "Estado do recurso". Esse erro será gerado se o cluster do GKE especificado for baseado em rota. O controlador da Entrada do Anthos cria um balanceador de carga nativo de contêiner usando NEGs. Os clusters precisam ser nativos de VPC para usar um balanceador de carga nativo de contêiner.

Para mais informações, consulte Como criar um cluster nativo de VPC.

AVMBR110: "Permissão [IAM_PERMISS] ausente para o cluster do GKE [NAME]."

Esse erro é exibido em "Estado do recurso". Há alguns motivos para esse erro:

  1. O cluster do GKE subjacente para a assinatura está localizado em um projeto diferente da própria assinatura.
  2. A permissão de IAM especificada foi removida do agente de serviço MultiClusterIngress.

AVMBR111: "Falha ao obter assinatura de configuração: [REASON]."

Esse erro é exibido em "Estado do recurso". O principal motivo desse erro é que a assinatura de configuração foi excluída enquanto o recurso estava ativado.

Não é necessário excluir a assinatura de configuração. Se quiser alterá-la, siga as etapas de migração do cluster de configuração.

AVMBR112: "O complemento HTTPLoadBalancing está desativado no cluster do GKE [NAME]."

Esse erro é exibido em "Estado do recurso" e ocorre quando o complemento HTTPLoadBalancing está desativado em um cluster do GKE. Você pode atualizar o cluster do GKE para ativar o complemento HTTPLoadBalancing.

gcloud container clusters update name --update-addons=HttpLoadBalancing=ENABLED

AVMBR113: "Este recurso é órfão."

Em alguns casos, a utilidade de um recurso depende da referência dele por outro recurso. Esse erro ocorre quando um recurso do Kubernetes é criado, mas não é referenciado por outro recurso. Por exemplo, você verá esse erro se criar um recurso BackendConfig que não esteja sendo referenciado por um MultiClusterService.