Solução de problemas e operações de entrada de vários clusters

O controlador de entrada do GKE Enterprise gerencia os recursos do Compute Engine. Os recursos MultiClusterIngress e MultiClusterService 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 MultiClusterIngress a seguir:

apiVersion: extensions/v1beta1
kind: MultiClusterIngress
metadata:
  name: foo-ingress
spec:
  template:
    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

Mapeamentos de recursos do Compute Engine para entrada de vários clusters

Na tabela a seguir, mostramos o mapeamento de recursos de frota 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.

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. Por 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.

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

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 MultiClusterIngress. 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 MultiClusterService e MultiClusterIngress 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 MultiClusterIngress e MultiClusterService 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 container fleet 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 container fleet 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

A entrada de vários clusters emite códigos de erro e aviso em recursos MultiClusterIngress e MultiClusterService, além do campo de descrição multiclusteringress da gcloud 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: Annotation [NAME] not recognized

Esse erro é exibido quando uma anotação é especificada em um manifesto MultiClusterIngress ou MultiClusterService que não é reconhecido. Há alguns motivos para a anotação não ser reconhecida:

  1. A anotação não é compatível com a entrada de vários clusters. Isso pode ser esperado se você anota recursos que não se espera que sejam usados pelo controlador de entrada do GKE Enterprise.

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

Nos dois casos, consulte a documentação para noções básicas das anotações compatíveis e como elas são especificadas.

AVMBR102: [RESOURCE_NAME] not found

Esse erro é exibido quando um recurso complementar é especificado em uma MultiClusterIngress, mas não pode ser encontrado na associação de configuração. Por exemplo, esse erro é gerado quando um MultiClusterIngress se refere a um MultiClusterService que não pode ser encontrado ou um MultiClusterService 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] is invalid

Esse erro é exibido quando um seletor de cluster especificado em um MultiClusterService é 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 de cluster que não existe mais na frota.

AVMBR104: Cannot find NEGs for Service Port [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: Missing GKE Enterprise license.

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

AVMBR106: Derived service is invalid: [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: whereami
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 fleet memberships describe membership-name

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

AVMBR108: GKE cluster [NAME] not found.

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

AVMBR109: [NAME] is not a VPC-native GKE cluster.

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 de vários clusters 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: [IAM_PERMISSION] permission missing for GKE cluster [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: Failed to get Config Membership: [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: HTTPLoadBalancing Addon is disabled in GKE Cluster [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: This resource is orphaned.

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.