Configurar serviços em vários clusters

Esta página mostra como ativar e usar serviços multi-cluster (MCS). Para saber mais sobre como funciona o MCS e as respetivas vantagens, consulte os serviços multicluster.

A funcionalidade MCS (Multi-Cluster Services) do Google Kubernetes Engine (GKE) expande o alcance do serviço do Kubernetes para além do limite do cluster e permite-lhe descobrir e invocar serviços em vários clusters do GKE. Pode exportar um subconjunto de serviços existentes ou novos serviços.

Quando exporta um serviço com o MCS, esse serviço fica disponível em todos os clusters na sua frota.

Esta página explica como configurar o MCS com um único projeto. Para a configuração de VPC partilhada com vários projetos, siga o artigo Configurar serviços com vários clusters com a VPC partilhada.

Google Cloud recursos geridos pelo MCS

O MCS gere os seguintes componentes do Google Cloud:

  • Cloud DNS: o MCS configura zonas e registos do Cloud DNS para cada serviço exportado nos seus clusters de frotas. Isto permite-lhe estabelecer ligação a serviços que estão a ser executados noutros clusters. Estas zonas e registos são criados, lidos, atualizados e eliminados com base nos serviços que optar por exportar entre clusters.

  • Regras de firewall: o MCS configura regras de firewall que permitem que os pods comuniquem entre si em clusters na sua frota. As regras de firewall são criadas, lidas, atualizadas e eliminadas com base nos clusters que adiciona à sua frota. Estas regras são semelhantes às regras que o GKE cria para permitir a comunicação entre Pods num cluster do GKE.

  • Cloud Service Mesh: o MCS usa o Cloud Service Mesh como um plano de controlo para monitorizar os pontos finais e o respetivo estado em todos os clusters.

Requisitos

O MCS tem os seguintes requisitos:

  • O MCS só suporta a exportação de serviços de clusters do GKE nativos da VPC no Google Cloud. Para mais informações, consulte o artigo Criar um cluster nativo da VPC. Não pode usar clusters padrão do GKE que não sejam nativos de VPC.

  • A conetividade entre clusters depende de clusters em execução na mesma rede VPC, em redes VPC partilhadas ou com intercâmbio. Se os clusters estiverem em redes separadas e não ligadas, as chamadas para serviços externos são bloqueadas. Recomendamos que ative o MCS em projetos onde os clusters estão na mesma rede VPC.

    Para configurar o MCS numa frota entre projetos com uma VPC partilhada, siga as instruções em Configurar serviços multicluster com a VPC partilhada.

  • Embora uma frota possa abranger vários Google Cloud projetos e redes VPC, um único serviço multicluster tem de ser exportado a partir de um único projeto e de uma única rede VPC.

  • O MCS não é suportado com políticas de rede.

  • Os clusters têm de ter o suplemento HttpLoadBalancing ativado. Certifique-se de que o suplemento HttpLoadBalancing está ativado. O suplemento HttpLoadBalancing está ativado por predefinição e não deve ser desativado.

Preços

Os serviços de vários clusters estão incluídos na taxa de gestão de clusters do GKE e não têm custos adicionais de utilização. Tem de ativar a API Traffic Director, mas o MCS não incorre em custos de ponto final do Cloud Service Mesh.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

  1. Instale o SDK do Google Cloud.

  2. Ative a API Google Kubernetes Engine:

    Ative a API Google Kubernetes Engine

  3. Ligue as suas redes VPC com o intercâmbio da rede da VPC, o Cloud Interconnect ou o Cloud VPN.

  4. Ative as APIs MCS, fleet (hub), Resource Manager, Cloud Service Mesh e Cloud DNS:

    gcloud services enable \
    multiclusterservicediscovery.googleapis.com \
    gkehub.googleapis.com \
    cloudresourcemanager.googleapis.com \
    trafficdirector.googleapis.com \
    dns.googleapis.com \
    --project=PROJECT_ID

    Substitua PROJECT_ID pelo ID do projeto do projeto onde planeia registar os seus clusters numa frota.

Ativar o MCS no seu projeto

O MCS requer que os clusters do GKE participantes estejam registados na mesma frota. Depois de a funcionalidade MCS ser ativada para uma frota, todos os clusters podem exportar serviços entre clusters na frota.

Ativar o MCS no seu cluster do GKE

  1. Ative a funcionalidade MCS para a frota do seu projeto:

    gcloud container fleet multi-cluster-services enable \
    --project PROJECT_ID

    Substitua PROJECT_ID pelo ID do projeto do projeto onde planeia registar os seus clusters numa frota. Este é o seu projeto de anfitrião da frota.

    A ativação de serviços multicluster no projeto anfitrião da frota cria ou garante que a conta de serviço service-PROJECT_NUMBER@gcp-sa-mcsd.iam.gserviceaccount.com existe.

  2. Registe os seus clusters do GKE na frota. Recomendamos vivamente que registe o seu cluster com a Federação de identidades de cargas de trabalho para o GKE ativada. Se não ativar a Workload Identity Federation para o GKE, tem de registar o cluster com uma Google Cloud conta de serviço para autenticação e concluir os passos adicionais em Autenticar contas de serviço.

    Para registar o seu cluster na Workload Identity Federation para o GKE, execute o seguinte comando:

    gcloud container fleet memberships register MEMBERSHIP_NAME \
   --gke-cluster CLUSTER_LOCATION/CLUSTER_NAME \
   --enable-workload-identity \
   --project PROJECT_ID

    Substitua o seguinte:

    • MEMBERSHIP_NAME: o nome do membro que escolhe para representar o cluster de forma exclusiva na frota. Normalmente, o nome de membro da frota de um cluster é o nome do cluster, mas pode ter de especificar um novo nome se já existir outro cluster com o nome original na frota.
    • CLUSTER_LOCATION: a zona ou a região onde o cluster está localizado.
    • CLUSTER_NAME: o nome do cluster.

  3. Conceda as autorizações da gestão de identidade e de acesso (IAM) necessárias para o importador do MCS:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/gke-mcs/sa/gke-mcs-importer" \
    --role "roles/compute.networkViewer"

    Substitua o seguinte:

    • PROJECT_ID: o ID do projeto do projeto anfitrião da frota.
    • PROJECT_NUMBER: o número do projeto do projeto anfitrião da frota.

  4. Certifique-se de que cada cluster na frota tem um namespace para partilhar serviços. Se necessário, crie um espaço de nomes com o seguinte comando:

    kubectl create ns NAMESPACE

    Substitua NAMESPACE por um nome para o espaço de nomes.

  5. Para verificar se o MCS está ativado, execute o seguinte comando:

    gcloud container fleet multi-cluster-services describe \
    --project PROJECT_ID

    O resultado é semelhante ao seguinte:

    createTime: '2021-08-10T13:05:23.512044937Z'
membershipStates:
  projects/PROJECT_ID/locations/global/memberships/MCS_NAME:
    state:
      code: OK
      description: Firewall successfully updated
      updateTime: '2021-08-10T13:14:45.173444870Z'
name: projects/PROJECT_NAME/locations/global/features/multiclusterservicediscovery
resourceState:
  state: ACTIVE
spec: {}

    Se o valor de state não for ACTIVE, consulte a secção de resolução de problemas.

Autenticação de contas de serviço

Se registou os seus clusters do GKE numa frota através de uma conta de serviço, tem de realizar passos adicionais para autenticar a conta de serviço. O MCS implementa um componente denominado gke-mcs-importer. Este componente recebe atualizações de pontos finais do Cloud Service Mesh. Por isso, como parte da ativação do MCS, tem de conceder à sua conta de serviço autorização para ler informações do Cloud Service Mesh.

Quando usa uma conta de serviço, pode usar a conta de serviço predefinida do Compute Engine ou a sua própria conta de serviço do nó:

Usar o MCS

As secções seguintes mostram como usar o MCS. O MCS usa a API de serviços de vários clusters do Kubernetes.

Registar um serviço para exportação

Para registar um serviço para exportação para outros clusters na sua frota, conclua os seguintes passos:

  1. Crie um objeto ServiceExport com o nome export.yaml:

    # export.yaml
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
 namespace: NAMESPACE
 name: SERVICE_EXPORT_NAME

    Substitua o seguinte:

    • NAMESPACE: o espaço de nomes do objeto ServiceExport. Este espaço de nomes tem de corresponder ao espaço de nomes do serviço que está a exportar.
    • SERVICE_EXPORT_NAME: o nome de um serviço no seu cluster que quer exportar para outros clusters na sua frota.

  2. Crie o recurso ServiceExport executando o seguinte comando:

    kubectl apply -f export.yaml

A exportação inicial do seu serviço demora aproximadamente cinco minutos a sincronizar com os clusters registados na sua frota. Após a exportação de um serviço, as sincronizações de pontos finais subsequentes ocorrem imediatamente.

Pode exportar o mesmo serviço de vários clusters para criar um único ponto final de serviço em vários clusters de alta disponibilidade com distribuição de tráfego entre clusters. Antes de exportar serviços com o mesmo nome e espaço de nomes, certifique-se de que quer que sejam agrupados desta forma. Recomendamos que não exporte serviços nos espaços de nomes default e kube-system devido à alta probabilidade de conflitos de nomes não intencionais e ao agrupamento não intencional resultante. Se estiver a exportar mais de cinco serviços com o mesmo nome e espaço de nomes, a distribuição de tráfego nos serviços importados pode estar limitada a cinco serviços exportados.

Consumir serviços entre clusters

O MCS só suporta ClusterSetIP e serviços sem interface. Apenas os registos "A" de DNS estão disponíveis.

Depois de criar um objeto ServiceExport, o seguinte nome de domínio é resolvido para o seu serviço exportado a partir de qualquer pod em qualquer cluster de frotas:

 SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

A saída inclui os seguintes valores:

  • SERVICE_EXPORT_NAME e NAMESPACE: os valores que define no objeto ServiceExport.

Para os serviços ClusterSetIP, o domínio é resolvido para o ClusterSetIP. Pode encontrar este valor localizando o objeto ServiceImport num cluster no espaço de nomes em que o objeto ServiceExport foi criado. O objeto ServiceImport é criado automaticamente.

Por exemplo:

kind: ServiceImport
apiVersion: net.gke.io/v1
metadata:
 namespace: EXPORTED-SERVICE-NAMESPACE
 name: SERVICE-EXPORT-TARGET
status:
 ports:
 - name: https
   port: 443
   protocol: TCP
   targetPort: 443
 ips: CLUSTER_SET_IP

O MCS cria um objeto Endpoints como parte da importação de um Service para um cluster. Ao investigar este objeto, pode monitorizar o progresso de uma importação de serviços. Para encontrar o nome do objeto Endpoints, procure o valor da anotação net.gke.io/derived-service num objeto ServiceImport correspondente ao seu serviço importado. Por exemplo:

kind: ServiceImport
apiVersion: net.gke.io/v1
annotations: net.gke.io/derived-service: DERIVED_SERVICE_NAME
metadata:
 namespace: EXPORTED-SERVICE-NAMESPACE
 name: SERVICE-EXPORT-TARGET

Em seguida, procure o objeto Endpoints para verificar se o MCS já propagou os pontos finais para o cluster de importação. O objeto Endpoints é criado no mesmo espaço de nomes que o objeto ServiceImport, com o nome armazenado na anotação net.gke.io/derived-service. Por exemplo:

kubectl get endpoints DERIVED_SERVICE_NAME -n NAMESPACE

Substitua o seguinte:

  • DERIVED_SERVICE_NAME: o valor da anotação net.gke.io/derived-service no objeto ServiceImport.
  • NAMESPACE: o espaço de nomes do objeto ServiceExport.

Pode saber mais sobre o estado de integridade dos pontos finais através do painel de controlo do Cloud Service Mesh na Google Cloud consola.

Para os serviços sem interface, o domínio resolve-se na lista de endereços IP dos pontos finais nos clusters de exportação. Cada pod de back-end com um nome de anfitrião também é endereçável de forma independente com um nome de domínio do seguinte formulário:

 HOSTNAME.MEMBERSHIP_NAME.LOCATION.SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

A saída inclui os seguintes valores:

  • SERVICE_EXPORT_NAME e NAMESPACE: os valores que define no objeto ServiceExport.
  • MEMBERSHIP_NAME: o identificador exclusivo na frota do cluster no qual o Pod se encontra.
  • LOCATION: a localização da subscrição. Os membros são global ou a respetiva localização é uma das regiões ou zonas em que o Pod se encontra, como us-central1.
  • HOSTNAME: o nome do anfitrião do Pod.

Também pode direcionar um pod de back-end com um nome de anfitrião exportado de um cluster registado com uma associação global, usando um nome de domínio no seguinte formato:

HOSTNAME.MEMBERSHIP_NAME.SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

Desativar o MCS

Para desativar o MCS, conclua os seguintes passos:

  1. Para cada cluster na sua frota, elimine cada objeto ServiceExport que criou:

    kubectl delete serviceexport SERVICE_EXPORT_NAME \
    -n NAMESPACE

    Substitua o seguinte:

    • SERVICE_EXPORT_NAME: o nome do seu objeto ServiceExport.
    • NAMESPACE: o espaço de nomes do objeto ServiceExport.

  2. Verifique se o ServiceExport desaparece da lista em 30 minutos.

  3. Anule o registo dos seus clusters da frota se não precisarem de ser registados para outro fim.

  4. Desative a funcionalidade multiclusterservicediscovery:

    gcloud container fleet multi-cluster-services disable \
    --project PROJECT_ID

    Substitua PROJECT_ID pelo ID do projeto do projeto onde registou os clusters.

  5. Desative a API para o MCS:

    gcloud services disable multiclusterservicediscovery.googleapis.com \
    --project PROJECT_ID

    Substitua PROJECT_ID pelo ID do projeto do projeto onde registou os clusters.

Limitações

Número de clusters, pods e portas de serviço

Os seguintes limites não são aplicados e, em alguns casos, pode exceder estes limites, dependendo da carga nos seus clusters ou projeto e da taxa de rotatividade dos pontos finais. Pode ter problemas de desempenho quando estes limites são excedidos.

No Kubernetes, um serviço é identificado exclusivamente pelo respetivo nome e pelo espaço de nomes ao qual pertence. Este nome e o par de espaço de nomes são denominados nome com espaço de nomes.

  • Exportar clusters: um único serviço, identificado por um nome com espaço de nomes, pode ser exportado em segurança de até 5 clusters em simultâneo. Além desse limite, é possível que apenas um subconjunto de pontos finais possa ser importado para clusters de consumo. Pode exportar diferentes serviços de diferentes subconjuntos de clusters.

  • O número de pods atrás de um único serviço: é seguro se mantiver um número inferior a 250 pods atrás de um único serviço. Com cargas de trabalho relativamente estáticas e um pequeno número de serviços multi-cluster, pode ser possível exceder significativamente este número para milhares de pontos finais por serviço. Tal como acontece com os serviços de cluster único, todos os pontos finais são monitorizados pelo kube-proxy em todos os nós. Quando excede este limite, especialmente quando exporta de vários clusters em simultâneo, podem ser necessários nós maiores.

  • O número de serviços de vários clusters exportados em simultâneo: recomendamos que não exporte mais de 250 portas de serviço únicas em simultâneo.

    Uma porta de serviço única é identificada por um nome com espaço de nomes e um número da porta, ou seja, uma tupla (nome, espaço de nomes, número da porta). Isto significa que:

    • Os serviços com o mesmo nome e porta no espaço de nomes, exportados de vários clusters, contam como uma única porta de serviço exclusiva.

    • Dois serviços com o mesmo nome e porta, mas espaços de nomes diferentes, por exemplo, (name, ns1, port-80) e (name, ns2, port-80), são duas portas de serviço diferentes, que contam para o limite de 250 portas de serviço únicas.

    • Um serviço exportado que exponha duas portas, 80 e 443, conta para o limite de 250 portas de serviço únicas, independentemente do número de clusters na frota que exportam este serviço em simultâneo.

    Cada serviço de vários clusters conta para a sua quota de serviços de back-end, e cada zona de cada cluster de exportação cria um grupo de pontos finais de rede (NEG). O aumento destas quotas não altera o limite indicado para a contagem total de portas de serviço únicas.

Tipos de serviços

O MCS só suporta ClusterSetIP e serviços sem cabeça. Os serviços NodePort e LoadBalancer não são suportados e podem levar a um comportamento inesperado.

Usar o agente IPmasq com o MCS

O MCS funciona como esperado quando usa um intervalo de IPs de agrupamentos predefinido ou não mascarado.

Se usar um intervalo de IPs de pods personalizado ou um ConfigMap de agente IPmasq personalizado, o tráfego de MCS pode ser mascarado. Isto impede o funcionamento do MCS porque as regras de firewall só permitem tráfego de IPs de pods.

Para evitar este problema, deve usar o intervalo de IPs de pods predefinido ou especificar todos os intervalos de IPs de pods no campo nonMasqueradeCIDRs do ConfigMap do agente IPmasq. Se usar o Autopilot ou tiver de usar um intervalo de IPs de pods não predefinido e não puder especificar todos os intervalos de IPs de pods no ConfigMap, deve usar a política de NAT de saída para configurar a ocultação de IP.

Reutilizar números de porta num serviço MCS

Não pode reutilizar o mesmo número de porta num serviço MCS, mesmo que os protocolos sejam diferentes.

Isto aplica-se tanto num serviço Kubernetes como em todos os serviços Kubernetes para um serviço MCS.

MCS com clusters em vários projetos

Não pode exportar um serviço se esse serviço já estiver a ser exportado por outros clusters num projeto diferente na frota com o mesmo nome e espaço de nomes. Pode aceder ao serviço noutros clusters na frota noutros projetos, mas esses clusters não podem exportar o mesmo serviço no mesmo espaço de nomes.

Resolução de problemas

As secções seguintes oferecem-lhe dicas de resolução de problemas para o MCS.

Ver o estado da funcionalidade do MCS

A visualização do estado do recurso Feature pode ajudar a confirmar se o MCS foi configurado com êxito. Pode ver o estado com o seguinte comando:

gcloud container fleet multi-cluster-services describe

O resultado é semelhante ao seguinte:

createTime: '2021-08-10T13:05:23.512044937Z'
membershipStates:
 projects/PROJECT_ID/locations/global/memberships/MCS_NAME:
   state:
     code: OK
     description: Firewall successfully updated
     updateTime: '2021-08-10T13:14:45.173444870Z'
name: projects/PROJECT_NAME/locations/global/features/multiclusterservicediscovery
resourceState:
 state: ACTIVE
spec: {}

Consiste, entre outras informações, no estado geral da funcionalidade em resourceState e no estado das subscrições individuais em membershipStates.

Se ativou a funcionalidade MCS de acordo com a instrução Ativar o MCS no cluster do GKE, mas o valor de resourceState.state não for ACTIVE, contacte o apoio técnico.

O estado de cada apoio consiste no respetivo caminho e no campo state. Este último contém code e description, que são úteis para a resolução de problemas.

Códigos nos estados de subscrição

Um código, representado pelo campo state.code, indica o estado geral do membro em relação ao MCS. Existem quatro valores possíveis:

  • OK: A subscrição foi adicionada com êxito ao MCS e está pronta a ser usada.

  • WARNING: o MCS está a reconciliar a configuração da subscrição. O campo de descrição pode fornecer mais informações sobre o que causou este código.

  • FAILED: esta subscrição não foi adicionada ao MCS. Outras subscrições na frota com um código OK não são afetadas por esta subscrição FAILED. O campo de descrição pode fornecer mais informações sobre o que causou este código.

  • ERROR: este apoio não tem recursos. Outras subscrições na frota com um código OK não são afetadas por esta subscrição ERROR. O campo de descrição pode fornecer mais informações sobre o que causou este código.

Descrições nos estados de associação

Para ver informações sobre o estado da subscrição no GCS, verifique o campo state.description. Este campo fornece informações sobre a configuração do projeto e do hub, bem como o estado de funcionamento da frota e das associações. Para ver informações sobre serviços individuais e a respetiva configuração, consulte o campo Status.Conditions no objeto ServiceExport. Consulte a secção A analisar ServiceExport.

O campo state.description contém as seguintes informações:

  • Firewall successfully created: esta mensagem indica que a regra de firewall do membro foi criada e/ou atualizada com êxito. O código da subscrição é OK.

  • Firewall creation pending: esta mensagem indica que a regra da firewall do membro está pendente de criação ou atualização. O código da subscrição é WARNING. Esta subscrição pode ter problemas ao atualizar e estabelecer ligação a novos serviços e subscrições multicluster adicionados enquanto a regra da firewall estiver pendente.

  • GKE Cluster missing: esta mensagem indica que o cluster do GKE registado não está disponível ou foi eliminado. O código da subscrição é ERROR. Esta associação tem de ser anulada manualmente no registo da frota depois de um cluster do GKE ser eliminado.

  • Project that member lives in is missing required permissions and/or has not enabled all required APIs - additional setup steps are required: esta mensagem indica que existem erros StatusForbidden (403) internos e que o código da subscrição é FAILED. Este erro ocorre nos seguintes cenários:

    • Não ativou as APIs necessárias no projeto do membro.

      Se o cluster membro estiver num projeto separado da frota, consulte a configuração entre projetos para garantir que concluiu todos os passos necessários. Se concluiu todos os passos, certifique-se de que as seguintes APIs estão ativadas no projeto de registo com os seguintes comandos:

      gcloud services enable multiclusterservicediscovery.googleapis.com --project PROJECT_ID
gcloud services enable dns.googleapis.com --project PROJECT_ID
gcloud services enable trafficdirector.googleapis.com --project PROJECT_ID
gcloud services enable cloudresourcemanager.googleapis.com --project PROJECT_ID

      Substitua PROJECT_ID pelo ID do projeto do projeto onde registou os clusters.

    • A conta de serviço mcsd ou gkehub requer mais autorizações no projeto do membro.

      As contas de serviço mcsd e gkehub devem ter sido criadas automaticamente no projeto anfitrião da frota com todas as autorizações necessárias. Para verificar se as contas de serviço existem, execute os seguintes comandos:

      gcloud projects get-iam-policy PROJECT_ID | grep gcp-sa-mcsd
gcloud projects get-iam-policy PROJECT_ID | grep gcp-sa-gkehub

      Substitua PROJECT_ID pelo ID do projeto do projeto anfitrião da frota.

    Estes comandos devem mostrar o nome completo das contas de serviço mcsd e gkehub.

  • Multiple VPCs detected in the hub - VPC must be peered with other VPCs for successful connectivity: esta mensagem ocorre quando os clusters alojados em VPCs diferentes estão registados na mesma frota. O estado da subscrição é OK. A rede de VPC de um cluster é definida pela rede de NetworkConfig. Os serviços em vários clusters requerem uma rede simples e estas VPCs têm de estar em peering ativo para que os serviços em vários clusters se liguem corretamente entre si. Para saber mais, consulte o artigo Estabeleça uma relação de intercâmbio entre duas redes.

  • Member does not exist in the same project as hub - additional setup steps are required, errors may occur if not completed.: esta mensagem lembra que os clusters entre projetos requerem passos de configuração adicionais. O estado da subscrição é OK. As associações entre projetos são definidas como um cluster de membros que não está no mesmo projeto que a frota. Para mais informações, consulte a configuração entre projetos.

  • Non-GKE clusters are currently not supported: esta mensagem lembra que o MCS só suporta clusters do GKE. Não é possível adicionar clusters não GKE ao MCS. O estado da subscrição é FAILED.

A analisar ServiceExport

Para ver o estado de um serviço individual e potenciais erros, verifique o campo Status.Conditions no recurso ServiceExport desse serviço:

kubectl describe serviceexports PROJECT_ID -n NAMESPACE

O resultado é semelhante ao seguinte:

Name:         SERVICE_NAME
Namespace:    NAMESPACE
Labels:       <none>
Annotations:  <none>
API Version:  net.gke.io/v1
Kind:         ServiceExport
Metadata:
  Creation Timestamp:  2024-09-06T15:57:40Z
  Finalizers:
    serviceexport.net.gke.io
  Generation:        2
  Resource Version:  856599
  UID:               8ac44d88-4c08-4b3d-8524-976efc455e4e
Status:
  Conditions:
    Last Transition Time:  2024-09-06T16:01:53Z
    Status:                True
    Type:                  Initialized
    Last Transition Time:  2024-09-06T16:02:48Z
    Status:                True
    Type:                  Exported
Events:                    <none>

Quando o controlador MCS deteta um recurso ServiceExport, o controlador adiciona as seguintes condições ao campo Status.Conditions:

  • Initialized: verdadeiro se o controlador do MCS tiver detetado e tentado reconciliar o serviço representado pelo ServiceExport.

  • Exported: True se o serviço representado pelo ServiceExport tiver sido validado com êxito.

Cada condição contém os campos obrigatórios Type, Status e LastTransitionTime. À medida que o controlador do MCS reconcilia e valida o serviço, o campo Status para a condição correspondente muda de False para True.

Erros

Se ocorrer um erro com a validação, o controlador define o campo Status da condição Exported como False e adiciona um campo Reason e um campo Message com mais informações sobre o erro. O campo Reason pode ter um dos seguintes valores:

  • NoMatchingService: não foi encontrado nenhum serviço com o nome e o espaço de nomes do ServiceExport no cluster especificado.
    Verifique se o serviço Kubernetes que pretende exportar existe no mesmo cluster. Verifique se o nome e o espaço de nomes em ambos os recursos (Service e ServiceExport) correspondem exatamente.

  • Conflict: já existe um serviço exportado com o mesmo nome e espaço de nomes que não corresponde ao que está a ser exportado por este ServiceExport ou é exportado a partir de uma rede ou um projeto diferente, o que não é permitido. Consulte as limitações.
    Inspeccione o campo Message para ver os detalhes e consulte a secção Limitações, se necessário. Certifique-se de que o nome e o espaço de nomes de Service e ServiceExport correspondem entre si e que todos os recursos são criados na mesma rede e/ou projeto.

  • ReadinessProbeError: Existe um readinessProbe configurado num contentor num Pod que suporta o serviço. Kubernetes ReadinessProbes são traduzidos para Google cloud HealthChecks e têm de estar em conformidade com as mesmas restrições.

    Veja como os campos da verificação da disposição se alinham com os parâmetros da verificação de estado:

    • PeriodSeconds corresponde a CheckInterval
    • TimeoutSeconds corresponde a Timeout
    • SuccessThreshold corresponde a HealthyThreshold
    • FailureThreshold corresponde a UnhealthyThreshold

    Para alinhar ReadinessProbes com as restrições de HealthCheck, o MCS implementa o seguinte:

    • PeriodSeconds e TimeoutSeconds estão limitados a 300 segundos. Os valores que excedam este limite acionam um erro.
    • SuccessThreshold e FailureThreshold estão limitados a 10 segundos. Os valores que excedam este limite acionam um erro.
    • É comunicado um erro e a criação de recursos (potencialmente todos os recursos) falha se TimeoutSeconds for superior a PeriodSeconds.

    A justificação para estas restrições é evitar problemas de escalabilidade, sondagens subsequentes de sobreposição, lentidão na verificação de estado/prontidão, etc. Ajuste os parâmetros do readinessProbe de acordo com as validações acima. É importante corrigir estes erros para todos os serviços da frota. Consulte os problemas conhecidos para obter uma explicação mais detalhada.

  • ServiceError: ocorreu um erro ao obter o serviço correspondente.
    Normalmente, este erro está relacionado com um problema de infraestrutura do Google Cloud. Contacte o apoio técnico do Google Cloud se o problema persistir.

  • PodsError: Ocorreu um erro ao obter o pod ou os pods de back-end
    Este erro está normalmente relacionado com um problema de infraestrutura do Google Cloud. Contacte o apoio técnico do Google Cloud se o problema persistir.

  • EndpointsError: Foi encontrado um erro ao agregar pontos finais para um serviço sem interface gráfica
    Este erro está normalmente relacionado com um problema de infraestrutura do Google Cloud. Contacte o apoio técnico do Google Cloud se o problema persistir.

O campo Message fornece contexto adicional para o erro.

Problemas de autorizações comuns

  • As APIs necessárias não estão ativadas no projeto.

    Certifique-se de que ativou as APIs necessárias, conforme indicado na secção Antes de começar.

    Para uma frota entre projetos, siga a secção adequada Ative as APIs necessárias em Configurar serviços de vários clusters com a VPC partilhada.

  • A conta de serviço mcsd ou gkehub não tem autorizações suficientes

    Para uma configuração de projeto único, todas as autorizações necessárias são automaticamente concedidas às contas de serviço criadas automaticamente pelo GKE Hub e pelo MCS.

    Para uma frota entre projetos, tem de criar associações de IAM adicionais. Siga a secção Crie associações de IAM adequada em Configurar serviços de vários clusters com VPC partilhada.

Problemas conhecidos

Serviços MCS com várias portas

Existe um problema conhecido com os serviços de vários clusters com várias portas (TCP/UDP) no GKE Dataplane V2, em que alguns pontos finais não são programados no plano de dados. Este problema afeta as versões do GKE anteriores à 1.26.3-gke.400.

Como solução alternativa, quando usar o GKE Dataplane V2, use vários MCS com uma única porta em vez de um MCS com várias portas.

Número da porta reutilizado num serviço MCS

Não pode reutilizar o mesmo número de porta num serviço MCS, mesmo que os protocolos sejam diferentes.

Isto aplica-se tanto num serviço Kubernetes como em todos os serviços Kubernetes para um serviço MCS.

MCS com VPC partilhada

Com a implementação atual do MCS, se implementar mais do que uma frota na mesma VPC partilhada, os metadados são partilhados entre as frotas. Quando um serviço é criado numa frota, os metadados do serviço são exportados ou importados em todas as outras frotas que fazem parte da mesma VPC partilhada e são visíveis para o utilizador.

A verificação de funcionamento usa a porta predefinida em vez de containerPort

Quando implementa um serviço com um campo targetPort que faz referência a uma porta com nome numa implementação, o MCS configura a porta predefinida para a verificação de estado em vez do containerPort especificado.

Para evitar este problema, use valores numéricos no campo Serviço ports.targetPort e no campo Implementação readinessProbe.httpGet.port em vez de valores com nomes.

A sondagem de disponibilidade inválida para um único serviço interrompe outros serviços

Existe um potencial erro de configuração conhecido da readinessProbe descrito em Examinar ServiceExports. Com a implementação atual do MCS, este erro, se introduzido para um único serviço exportado, pode impedir que alguns ou todos os outros serviços na frota sejam sincronizados.

É importante manter as configurações de todos os serviços em bom estado. Se um serviço MCS não estiver a ser atualizado, certifique-se de que nenhum dos ServiceExports em qualquer um dos clusters em qualquer um dos espaços de nomes comunica ReadinessProbeError como o motivo da condição de estado Exported ser False. Consulte a secção Examinar ServiceExports para saber como verificar as condições.

O que se segue?