Resolução de problemas e operações para a Entrada em vários clusters

O controlador Ingress do GKE Enterprise gere recursos do Compute Engine. Os recursos MultiClusterIngress e MultiClusterService são mapeados para diferentes recursos do Compute Engine, pelo que a compreensão da relação entre estes recursos ajuda a resolver problemas. Por exemplo, examine o seguinte recurso MultiClusterIngress:

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 a entrada em vários clusters

A tabela abaixo mostra o mapeamento dos recursos da frota para os recursos criados nos clusters do Kubernetes e Google Cloud:

Recurso do Kubernetes Google Cloud recurso Descrição
MultiClusterIngress Regra de encaminhamento VIP do balanceador de carga HTTP(S).
Proxy de destino Definições de terminações HTTP/S retiradas das anotações e do bloco TLS.
Mapa do URL Mapeamento do caminho do anfitrião virtual da secção de regras.
MultiClusterService Serviço do Kubernetes Recurso derivado do modelo.
Serviço de back-end É criado um serviço de back-end para cada par (Service, ServicePort).
Grupos de pontos finais da rede Conjunto de pods de back-end que participam no serviço.

Inspecionar recursos do balanceador de carga do Compute Engine

Depois de criar um equilibrador de carga, o estado do Multi Cluster Ingress contém os nomes de todos os recursos do Compute Engine que foram criados para construir o equilibrador 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"

O VIP não foi criado

Se não vir um VIP, pode ter ocorrido um erro durante a respetiva criação. Para ver se ocorreu um erro, execute o seguinte comando:

kubectl describe mci shopping-service

O resultado pode ter um aspeto semelhante ao seguinte:

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 o utilizador não ter criado um recurso MultiClusterService referenciado por um MultiClusterIngress.

Resposta 502

Se o seu equilibrador de carga adquiriu um IP virtual, mas está a publicar consistentemente uma resposta 502, as verificações de estado do equilibrador de carga podem estar a falhar. As verificações de funcionamento podem falhar por dois motivos:

  1. Os pods de aplicações não estão em bom estado (consulte a depuração da consola do Google Cloud, por exemplo).
  2. Uma firewall configurada incorretamente está a impedir que os verificadores de funcionamento da Google realizem verificações de funcionamento.

No caso do n.º 1, certifique-se de que a sua aplicação está a publicar uma resposta 200 no caminho "/".

No caso do ponto 2, certifique-se de que existe uma firewall denominada "mci-default-l7" na sua VPC. O controlador de entrada cria a firewall na sua VPC para garantir que os verificadores de estado de funcionamento da Google conseguem alcançar os seus back-ends. Se a firewall não existir, certifique-se de que não existe nenhuma automatização externa que elimine esta firewall após a respetiva criação.

O tráfego não foi adicionado nem removido do cluster

Quando adiciona uma nova subscrição, o tráfego deve alcançar os back-ends no cluster subjacente, quando aplicável. Da mesma forma, se uma associação for removida, nenhum tráfego deve alcançar os back-ends no cluster subjacente. Se não estiver a observar este comportamento, verifique se existem erros no recurso MultiClusterIngress e MultiClusterService.

Os casos comuns em que este erro ocorre incluem a adição de uma nova subscrição num cluster do GKE que não está no modo nativo da VPC ou a adição de uma nova subscrição, mas não a implementação de uma aplicação no cluster do GKE.

  1. Descreva o MultiClusterService:

    kubectl describe mcs zone-svc

  2. Descreva o MultiClusterIngress:

    kubectl describe mci zone-mci

Migração de cluster de configuração

Para compreender melhor os exemplos de utilização 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 disruptiva se não for processada corretamente. Siga estas diretrizes quando fizer uma migração de cluster de configuração:

  1. Certifique-se de que usa a anotação static-ip nos seus recursos MultiClusterIngress. Caso contrário, o tráfego é interrompido durante a migração. Os IPs efémeros são recriados quando migra clusters de configuração.
  2. Os recursos MultiClusterIngress e MultiClusterService têm de ser implementados de forma idêntica no cluster de configuração existente e no novo. As diferenças entre eles resultam na conciliação dos recursos MultiClusterService e MultiClusterIngress que são diferentes no novo cluster de configuração.
  3. Apenas um cluster de configuração está ativo em qualquer altura. Até que o cluster de configuração seja alterado, os recursos MultiClusterIngress e MultiClusterService no novo cluster de configuração não afetam os recursos do equilibrador de carga.

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

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

Verifique se o comando funcionou certificando-se de que não existem erros visíveis no Feature state:

  gcloud container fleet ingress describe

Depuração da consola

Na maioria dos casos, verificar o estado exato do equilibrador de carga é útil quando está a depurar um problema. Pode encontrar o balanceador de carga acedendo a Equilíbrio de carga na Google Cloud consola.

Códigos de erro/aviso

A entrada em vários clusters emite códigos de erro e aviso nos recursos MultiClusterIngress e MultiClusterService, bem como no campo multiclusteringress de descrição do gcloud para problemas conhecidos. Estas mensagens têm códigos de erro e aviso documentados para facilitar a compreensão do que significa quando algo não está a funcionar como esperado. Cada código consiste num ID de erro no formato AVMBR123, em que 123 é um número único que corresponde a um erro ou aviso e sugestões sobre como resolvê-lo.

AVMBR101: Annotation [NAME] not recognized

Este erro é apresentado quando é especificada uma anotação num manifesto MultiClusterIngress ou MultiClusterService que não é reconhecido. Existem alguns motivos pelos quais a anotação pode não ser reconhecida:

  1. A anotação não é suportada no Multi Cluster Ingress. Isto pode ser esperado se anotar recursos que não se espera que sejam usados pelo controlador Ingress do GKE Enterprise.

  2. A anotação é suportada, mas tem um erro ortográfico e, por isso, não é reconhecida.

Em ambos os casos, consulte a documentação para compreender as anotações suportadas e como são especificadas.

AVMBR102: [RESOURCE_NAME] not found

Este erro é apresentado quando é especificado um recurso suplementar num elemento MultiClusterIngress, mas não é possível encontrá-lo na associação de configuração. Por exemplo, este erro é apresentado quando um MultiClusterIngress se refere a um MultiClusterService que não é possível encontrar ou um MultiClusterService se refere a um BackendConfig que não é possível encontrar. Existem alguns motivos pelos quais não é possível encontrar um recurso:

  1. Não está no espaço de nomes adequado. Certifique-se de que os recursos que fazem referência uns aos outros estão todos no mesmo espaço de nomes.
  2. O nome do recurso está escrito de forma incorreta.
  3. O recurso não existe realmente com o espaço de nomes + nome adequados. Neste caso, crie-o.

AVMBR103: [CLUSTER_SELECTOR] is invalid

Este erro é apresentado quando um seletor de clusters especificado num MultiClusterService não é válido. Existem alguns motivos pelos quais este seletor pode ser inválido:

  1. A string fornecida contém um erro ortográfico.
  2. A string fornecida refere-se a uma associação de cluster que já não existe na frota.

AVMBR104: Cannot find NEGs for Service Port [SERVICE_PORT]

Este erro é apresentado quando não é possível encontrar os NetworkEndpointGroups (NEGs) para um determinado par de MultiClusterService e porta de serviço. Os NEGs são os recursos que contêm os pontos finais do pod em cada um dos seus clusters de back-end. O principal motivo pelo qual os NEGs podem não existir é porque ocorreu um erro ao criar ou atualizar os serviços derivados nos clusters de back-end. Consulte os Eventos no recurso MultiClusterService para mais informações.

AVMBR105: Missing GKE Enterprise license.

Este erro é apresentado em Feature state e indica que a API GKE Enterprise (anthos.googleapis.com) não está ativada.

AVMBR106: Derived service is invalid: [REASON].

Este erro é apresentado nos eventos do recurso MultiClusterService. Um motivo comum para este erro é o facto de o recurso Service derivado de MultiClusterService ter uma especificação inválida.

Por exemplo, este MultiClusterService não tem nenhum ServicePort definido na respetiva 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 é apresentado em Estado da funcionalidade e ocorre porque não existe nenhum cluster do GKE subjacente ao recurso Membership. Pode verificar esta situação executando o seguinte comando:

gcloud container fleet memberships describe membership-name

e garantir que não existe um link de recurso do cluster do GKE no campo do ponto final.

AVMBR108: GKE cluster [NAME] not found.

Este erro é apresentado em Estado da funcionalidade e é gerado se o cluster do GKE subjacente para a subscrição não existir.

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

Este erro é apresentado em Estado do elemento. Este erro é gerado se o cluster do GKE especificado for um cluster baseado em rotas. O controlador Multi Cluster Ingress cria um balanceador de carga nativa do contentor através de NEGs. Os clusters têm de ser nativos da VPC para usar um balanceador de carga nativo do contentor.

Para mais informações, consulte o artigo Criar um cluster nativo da VPC.

AVMBR110: [IAM_PERMISSION] permission missing for GKE cluster [NAME].

Este erro é apresentado em Estado do elemento. Existem alguns motivos para este erro:

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

AVMBR111: Failed to get Config Membership: [REASON].

Este erro é apresentado em Estado do elemento. O principal motivo pelo qual este erro ocorre é porque a associação de configuração foi eliminada enquanto a funcionalidade estava ativada.

Nunca deve ter de eliminar a associação da configuração. Se quiser alterá-lo, siga os passos de migração do cluster de configuração.

AVMBR112: HTTPLoadBalancing Addon is disabled in GKE Cluster [NAME].

Este erro é apresentado em Estado da funcionalidade e ocorre quando o suplemento HTTPLoadBalancing está desativado num cluster do GKE. Pode atualizar o seu cluster do GKE para ativar o suplemento HTTPLoadBalancing:

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

AVMBR113: This resource is orphaned.

Em alguns casos, a utilidade de um recurso depende de ser referenciado por outro recurso. Este erro é lançado quando um recurso do Kubernetes é criado, mas não é referenciado por outro recurso. Por exemplo, vê este erro se criar um recurso BackendConfig que não esteja a ser referenciado por um MultiClusterService.