Como configurar serviços de vários clusters

Esta página mostra como ativar e usar serviços de vários clusters (MCS, na sigla em inglês). Para saber mais sobre como o MCS funciona e os benefícios dele, consulte Serviços de vários clusters.

O recurso de MCS do Google Kubernetes Engine (GKE) estende o alcance do Serviço do Kubernetes além do limite do cluster e permite descobrir e invocar Serviços em vários clusters do GKE. É possível exportar um subconjunto de serviços existentes ou novos.

Quando você exporta um serviço com MCS, esse serviço é disponibilizado em todos os clusters da frota.

Nesta página, explicamos como configurar o MCS com um único projeto. Para configurar a VPC compartilhada em vários projetos, siga as instruções em Como configurar serviços de vários clusters com a VPC compartilhada.

Google Cloud recursos gerenciados pela MCS

O MCS gerencia os seguintes componentes do Google Cloud:

  • Cloud DNS: o MCS configura zonas e registros do Cloud DNS para cada serviço exportado nas frotas do environ. Isso permite que você se conecte a serviços em execução em outros clusters. Essas zonas e registros são criados, lidos, atualizados e excluídos com base nos serviços escolhidos para exportação entre clusters.

  • Regras de firewall: o MCS configura regras de firewall que permitem que os pods se comuniquem uns com os outros entre clusters na frota. As regras de firewall são criadas, lidas, atualizadas e excluídas com base nos clusters adicionados à frota. Essas regras são semelhantes às regras que o GKE cria para permitir a comunicação entre pods em um cluster do GKE.

  • Cloud Service Mesh: o MCS usa o Cloud Service Mesh como plano de controle para acompanhar os endpoints e a integridade deles nos clusters.

Requisitos

O MCS tem os seguintes requisitos:

  • O MCS só é compatível com a exportação de serviços de clusters nativos do GKE no Google Cloud. Para mais informações, consulte Como criar um cluster nativo de VPC. Não é possível usar clusters padrão do GKE que não sejam nativos de VPC.

  • A conectividade entre clusters depende dos clusters em execução na mesma rede VPC, nas redes VPC com peering ou compartilhadas. Se os clusters estiverem em redes separadas e não conectadas, as chamadas para serviços externos serão bloqueadas. Recomendamos que você ative o MCS em projetos em que os clusters estão na mesma rede VPC.

    Para configurar o MCS em uma frota entre projetos com uma VPC compartilhada, siga Como configurar serviços de vários clusters com a VPC compartilhada.

  • Uma frota pode abranger vários projetos do Google Cloud e redes VPC. No entanto, um único serviço de vários clusters precisa ser exportado de um único projeto e uma única rede VPC.

  • O MCS não oferece suporte às políticas de rede.

  • Os clusters precisam ter o complemento HttpLoadBalancing ativado. Verifique se o complemento HttpLoadBalancing está ativado. O complemento HttpLoadBalancing é ativado por padrão e não pode ser desativado.

Preços

Os serviços de vários clusters estão incluídos como parte da taxa de gerenciamento de cluster do GKE e não têm custo extra para uso. Você precisa ativar a API Traffic Director, mas o MCS não gera cobranças de endpoint do Cloud Service Mesh.

Antes de começar

Antes de começar, veja se você realizou as seguintes tarefas:

  1. Instale o SDK do Google Cloud.

  2. Ative a API Google Kubernetes Engine:

    Ativar a API Google Kubernetes Engine

  3. Conecte suas redes VPC com o peering de rede VPC, o Cloud Interconnect ou o Cloud VPN.

  4. Ative as APIs MCS, frota (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 em que você pretende registrar os clusters em uma frota.

Como ativar o MCS no projeto

O MCS exige que os clusters do GKE participantes sejam registrados na mesma frota. Depois que o recurso MCS for ativado para uma frota, qualquer cluster poderá exportar serviços entre os clusters na frota.

Como ativar o MCS no cluster do GKE

  1. Ative o recurso MCS para a frota do seu projeto:

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

    Substitua PROJECT_ID pelo ID do projeto em que você pretende registrar os clusters em uma frota. Este é seu projeto host de frota.

    A ativação de serviços de vários clusters no projeto host da frota cria ou garante que a conta de serviço service-PROJECT_NUMBER@gcp-sa-mcsd.iam.gserviceaccount.com exista.

  2. Registre os clusters do GKE em uma frota. É altamente recomendável registrar o cluster com a federação de identidade da carga de trabalho para o GKE ativada. Se você não ativar a federação de identidade da carga de trabalho, precisará registrar o cluster com uma Google Cloud conta de serviço para autenticação e concluir as outras etapas em Como autenticar contas de serviço.

    Para registrar o cluster com a federação de identidade da carga de trabalho do 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:

    • MEMBERSHIP_NAME: o nome da assinatura que você escolhe para representar o cluster de maneira exclusiva na frota. Normalmente, o nome da assinatura da frota do cluster é o nome do cluster, mas talvez seja necessário especificar um novo nome se outro cluster com o nome original já existir na frota.
    • CLUSTER_LOCATION: a zona ou região em que o cluster está localizado.
    • CLUSTER_NAME: o nome do cluster.

  3. Conceda as permissões do Identity and Access Management (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:

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

  4. Certifique-se de que cada cluster na frota tenha um namespace em que compartilhar serviços. Se necessário, crie um namespace usando o seguinte comando:

    kubectl create ns NAMESPACE

    Substitua NAMESPACE por um namespace.

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

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

    A saída será assim:

    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 seção Solução de problemas.

Como autenticar contas de serviço

Se você registrou os clusters do GKE em uma frota usando uma conta de serviço, será necessário seguir etapas adicionais para autenticar a conta de serviço. O MCS implanta um componente chamado gke-mcs-importer. Esse componente recebe atualizações de endpoint do Cloud Service Mesh. Por isso, como parte da ativação do MCS, é necessário conceder permissão à conta de serviço para ler informações do Cloud Service Mesh.

Ao usar uma conta de serviço, utilize a conta de serviço padrão do Compute Engine ou sua própria conta de serviço de nó:

Como usar o MCS

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

Como registrar um serviço para exportação

Para registrar um serviço para exportação em outros clusters na frota, conclua as etapas a seguir:

  1. Crie um objeto ServiceExport chamado export.yaml:

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

    Substitua:

    • NAMESPACE: o namespace do objeto ServiceExport. Esse namespace precisa corresponder ao namespace do serviço que você está exportando.
    • SERVICE_EXPORT_NAME: o nome de um serviço no cluster que você quer exportar para outros clusters na frota.

  2. Crie o recurso ServiceExport executando o seguinte comando:

    kubectl apply -f export.yaml

A exportação inicial do serviço leva aproximadamente cinco minutos para sincronizar com os clusters registrados na frota. Depois que um serviço é exportado, as sincronizações de endpoint subsequentes ocorrem imediatamente.

É possível exportar o mesmo serviço de vários clusters para criar um único endpoint de serviço de vários clusters altamente disponível com distribuição de tráfego entre clusters. Antes de exportar serviços com o mesmo nome e o mesmo namespace, considere se realmente quer que eles estejam agrupados dessa maneira. Não recomendamos a exportação de serviços nos namespaces default e kube-system devido à alta probabilidade de conflitos de nomes não intencionais e ao agrupamento não intencional resultante. Se você estiver exportando mais de cinco serviços com o mesmo nome e o mesmo namespace, a distribuição de tráfego em serviços importados poderá ser limitada a cinco serviços exportados.

Como consumir serviços entre clusters

O MCS é compatível apenas com ClusterSetIP e serviços headless. Somente os registros de DNS "A" estão disponíveis.

Depois de criar um objeto ServiceExport, o nome de domínio a seguir será resolvido para o serviço exportado de qualquer pod em qualquer cluster da frota:

 SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

A saída inclui os seguintes valores:

  • SERVICE_EXPORT_NAME e NAMESPACE: os valores definidos no objeto ServiceExport.

Para os serviços do ClusterSetIP, o domínio é resolvido para o ClusterSetIP. Para encontrar esse valor, localize o objeto ServiceImport em um cluster no namespace em que o objeto ServiceExport foi criado. O objeto ServiceImport é criado automaticamente.

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 esse objeto, é possível monitorar o progresso de uma importação de serviço. Para encontrar o nome do objeto Endpoints, procure o valor da anotação net.gke.io/derived-service em um objeto ServiceImport correspondente ao serviço importado. 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 endpoints para o cluster de importação. O objeto Endpoints é criado no mesmo namespace que o objeto ServiceImport, com o nome armazenado na anotação net.gke.io/derived-service. Exemplo:

kubectl get endpoints DERIVED_SERVICE_NAME -n NAMESPACE

Substitua:

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

Saiba mais sobre o status de integridade dos endpoints usando o painel do Cloud Service Mesh no console do Google Cloud .

Para os serviços sem comando, o domínio resolve para a lista de endereços IP dos endpoints nos clusters de exportação. Cada pod de back-end com um nome do host também pode ser endereçado de forma independente com um nome de domínio da seguinte forma:

 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 definidos no objeto ServiceExport.
  • MEMBERSHIP_NAME: o identificador exclusivo na frota do cluster em que o pod está.
  • LOCATION: o local da assinatura. As assinaturas são global, ou o local delas é uma das regiões ou zonas em que o pod está, como us-central1.
  • HOSTNAME: o nome do host do pod.

Também é possível endereçar um pod de back-end com um nome do host exportado de um cluster, registrado com uma assinatura global, usando um nome de domínio do seguinte formato:

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

Como desativar o MCS

Para desativar o MCS, siga estas etapas:

  1. Para cada cluster na frota, exclua cada objeto ServiceExport que você criou:

    kubectl delete serviceexport SERVICE_EXPORT_NAME \
    -n NAMESPACE

    Substitua:

    • SERVICE_EXPORT_NAME: nome do objeto ServiceExport.
    • NAMESPACE: o namespace do objeto ServiceExport.

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

  3. Cancele o registro dos clusters da frota se eles não precisarem ser registrados para outra finalidade.

  4. Desative o recurso multiclusterservicediscovery:

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

    Substitua PROJECT_ID pelo ID do projeto em que você registrou os clusters.

  5. Desative a API do MCS:

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

    Substitua PROJECT_ID pelo ID do projeto em que você registrou os clusters.

Limitações

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

Os limites a seguir não são aplicados e, em alguns casos, é possível exceder esses limites dependendo da carga nos clusters ou no projeto e na taxa de desligamento de endpoints. Podem ocorrer problemas de desempenho quando esses limites são excedidos.

No Kubernetes, um serviço é identificado exclusivamente pelo nome e pelo namespace a que pertence. Esse nome e o par de namespace são chamados de nome com namespace.

  • Exportação de clusters: um único serviço, identificado por um nome de namespace, pode ser exportado com segurança de até cinco clusters simultaneamente. Além desse limite, é possível que apenas um subconjunto de endpoints possa ser importado para clusters de consumo. É possível exportar serviços diferentes de subconjuntos variados de clusters.

  • O número de pods por trás de um único serviço: é seguro quando você continuar com menos de 250 pods em um único serviço. Com cargas de trabalho relativamente estáticas e um pequeno número de serviços com vários clusters, é possível exceder significativamente esse número em milhares de endpoints por serviço. Como acontece com os serviços de cluster único, todos os endpoints são monitorados por kube-proxy em cada nó. Ao ultrapassar esse limite, especialmente ao exportar de vários clusters simultaneamente, nós maiores podem ser necessários.

  • O número de serviços de vários clusters exportados simultaneamente: recomendamos que você exporte simultaneamente não mais de 250 portas de serviço exclusivas.

    Uma porta de serviço exclusiva é identificada por um nome com namespace e um número de porta, ou seja, uma tupla (nome, namespace, número de porta). Isso significa que:

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

    • Dois serviços com o mesmo nome e porta, mas namespaces diferentes, por exemplo, (name, ns1, port-80) e (name, ns2, port-80) são duas portas de serviço diferentes, contando para dois dos 250 limites de portas de serviço exclusivas.

    • Um serviço exportado que expõe duas portas, 80 e 443, conta como duas do limite de 250 portas de serviço exclusivas, independente do número de clusters na frota que exportam esse serviço simultaneamente.

    Cada serviço de vários clusters é contabilizado na cota dos serviços de back-end e cada zona de cada cluster de exportação cria um grupo de endpoints da rede (NEG, na sigla em inglês). Aumentar essas cotas não muda o limite declarado para a contagem total de portas de serviço exclusivas.

Tipos de serviço

O MCS é compatível apenas com ClusterSetIP e serviços headless. Os serviços NodePort e LoadBalancer não são compatíveis e podem causar um comportamento inesperado.

Como usar o agente IPmasq com o MCS

O MCS opera conforme esperado quando você usa um intervalo de IP de pod padrão ou não mascarado.

Se você usar um intervalo de IP de pod personalizado ou um ConfigMap do agente IPmasq personalizado, será possível mascarar o tráfego do MCS. Isso impede que o MCS funcione porque as regras de firewall só permitem o tráfego de IPs de pod.

Para evitar esse problema, use o intervalo de IP de pod padrão ou especifique todos os intervalos de IP de pod no campo nonMasqueradeCIDRs do ConfigMap do agente IPmasq. Se você usar o Autopilot ou se precisar usar um intervalo de IP de pod não padrão e não puder especificar todos os intervalos de IP de pod no ConfigMap, use a política de NAT de saída para configurar o mascaramento de IP.

Reutilizar números de porta em um serviço MCS

Não é possível reutilizar o mesmo número de porta em um serviço MCS, mesmo que os protocolos sejam diferentes.

Isso se aplica a um serviço do Kubernetes e a todos os serviços do Kubernetes para um serviço do MCS.

MCS com clusters em vários projetos

Não será possível exportar um serviço se ele já estiver sendo exportado por outros clusters em um projeto diferente na frota com o mesmo nome e namespace. É possível acessar o serviço em outros clusters da frota em outros projetos, mas esses clusters não podem exportar o mesmo serviço no mesmo namespace.

Solução de problemas

As seções a seguir fornecem dicas de solução de problemas para o MCS.

Como visualizar o status do recurso do MCS

A visualização do status do recurso pode confirmar se o MCS foi configurado. Use o comando a seguir para conferir o status:

gcloud container fleet multi-cluster-services describe

O resultado será assim:

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: {}

Ele consiste, entre outras informações, no estado geral do recurso em resourceState e no status das assinaturas individuais em membershipStates.

Se você ativou o recurso do MCS de acordo com a instrução Como ativar o MCS no cluster do GKE, mas o valor de resourceState.state não é ACTIVE, entre em contato com o suporte.

O status de cada associação consiste no caminho e no campo state. O último contém code e description, que são úteis para a solução de problemas.

Códigos nos estados de assinatura

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

  • OK: a assinatura foi adicionada ao MCS e está pronta para uso.

  • WARNING: o MCS está em processo de reconciliação da configuração da assinatura. O campo de descrição pode fornecer mais informações sobre o que causou esse código.

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

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

Descrições nos estados de associação

Para conferir informações sobre o estado da assinatura no MCS, verifique o campo state.description. Esse campo fornece informações sobre a configuração do projeto e do hub, além do status de integridade da frota e das associações. Para conferir informações sobre serviços individuais e a configuração deles, consulte o campo Status.Conditions no objeto ServiceExport. Consulte a seção Como examinar ServiceExport.

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

  • Firewall successfully created: essa mensagem indica que a regra de firewall do membro foi criada e atualizada. O código da assinatura é OK.

  • Firewall creation pending: essa mensagem indica que a regra de firewall do membro está com criação ou atualização pendente. O código da assinatura é WARNING. Essa assinatura pode ter problemas para atualizar e se conectar a novos serviços de vários clusters e assinaturas adicionados enquanto a regra de firewall está pendente.

  • GKE Cluster missing: essa mensagem indica que o cluster registrado do GKE está indisponível e/ou excluído. O código da assinatura é ERROR. Essa assinatura precisa ser manualmente cancelada do registro da frota depois que um cluster do GKE for excluído.

  • 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 há erros internos StatusForbidden (403) e o código da assinatura é FAILED. Esse erro ocorre nos seguintes cenários:

    • Você não ativou as APIs necessárias no projeto do membro.

      Se o cluster do membro residir em um projeto separado da frota, consulte configuração entre projetos para garantir que você concluiu todas as etapas necessárias. Se você concluiu todas as etapas, verifique se as seguintes APIs estão ativadas no projeto de registro 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 em que você registrou os clusters.

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

      As contas de serviço mcsd e gkehub precisam ter sido criadas automaticamente no projeto host da frota com todas as permissõ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 host da frota.

    Esses comandos mostram 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: essa mensagem ocorre quando os clusters hospedados em VPCs diferentes são registrados na mesma frota. O status da assinatura é OK. A rede VPC de um cluster é definida pela rede do NetworkConfig dele. Os serviços de vários clusters precisam de uma rede simples, e essas VPCs precisam estar ativamente em peering para que os serviços de vários clusters se conectem uns aos outros adequadamente. Para saber mais, consulte Fazer peering de duas redes.

  • Member does not exist in the same project as hub - additional setup steps are required, errors may occur if not completed.: essa mensagem enfatiza que os clusters entre projetos exigem etapas de configuração adicionais. O status da assinatura é OK. As associações entre projetos são definidas como um cluster de membro 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 enfatiza que o MCS é compatível apenas com clusters do GKE. Clusters que não são do GKE não podem ser adicionados ao MCS. O status da assinatura é FAILED.

Analisando ServiceExport

Para conferir o status de um serviço específico e possíveis erros, verifique o campo Status.Conditions no recurso ServiceExport desse serviço:

kubectl describe serviceexports PROJECT_ID -n NAMESPACE

O resultado será assim:

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 do MCS percebe um recurso ServiceExport, ele adiciona as seguintes condições ao campo Status.Conditions:

  • Initialized: "True" se o controlador do MCS tiver captado e tentado reconciliar o serviço representado pelo ServiceExport.

  • Exported: verdadeiro se o serviço representado pelo ServiceExport tiver sido validado.

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

Erros

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

  • NoMatchingService: nenhum serviço com o nome e o namespace do ServiceExport foi encontrado no cluster especificado.
    Verifique se o serviço do Kubernetes que você quer exportar existe no mesmo cluster. Verifique se o nome e o namespace nos dois recursos (Service e ServiceExport) são exatamente iguais.

  • Conflict: já existe um serviço exportado com o mesmo nome e namespace que não correspondem ao exportado por este ServiceExport ou que é exportado de uma rede ou projeto diferente, o que não é permitido. Consulte Limitações.
    Inspecione o campo Message para ver os detalhes e consulte a seção Limitações, se necessário. Verifique se o nome e o namespace de Service e ServiceExport correspondem entre si e se todos os recursos foram criados na mesma rede e/ou projeto.

  • ReadinessProbeError: há um readinessProbe configurado em um contêiner em um pod que oferece suporte ao serviço. Kubernetes ReadinessProbes são traduzidos para Google cloud HealthChecks e precisam obedecer às mesmas restrições.

    Veja como os campos de verificação de prontidão se alinham aos parâmetros de verificação de integridade:

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

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

    • PeriodSeconds e TimeoutSeconds têm um limite de 300 segundos. Valores que excedem esse limite acionam um erro.
    • SuccessThreshold e FailureThreshold têm um limite de 10 segundos. Valores que excedem esse limite acionam um erro.
    • Um erro é informado, e a criação de recursos (potencialmente todos os recursos) falha se TimeoutSeconds for maior que PeriodSeconds.

    O motivo dessas restrições é evitar problemas de escalonabilidade, sobreposição de sondagens subsequentes, lentidão na verificação de integridade/prontidão etc. Ajuste os parâmetros do readinessProbe de acordo com as validações acima. É importante corrigir esses erros em todos os serviços da frota. Consulte Problemas conhecidos para mais explicações.

  • ServiceError: ocorreu um erro ao buscar o serviço correspondente.
    Esse erro geralmente está relacionado a um problema de infraestrutura do Google Cloud. Entre em contato com o suporte do Google Cloud se o problema persistir.

  • PodsError: um erro encontrado ao buscar o pod ou os pods de back-end
    . Esse erro geralmente está relacionado a um problema de infraestrutura do Google Cloud. Entre em contato com o suporte do Google Cloud se o problema persistir.

  • EndpointsError: um erro encontrado ao agregar endpoints para um serviço sem cabeçalho
    Esse erro geralmente está relacionado a um problema de infraestrutura do Google Cloud. Entre em contato com o suporte do Google Cloud se o problema persistir.

O campo Message fornece mais contexto sobre o erro.

Problemas comuns de permissão

Problemas conhecidos

Serviços MCS com várias portas

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

Como solução alternativa, ao 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 em um serviço MCS

Não é possível reutilizar o mesmo número de porta em um serviço do MCS, mesmo que os protocolos sejam diferentes.

Isso se aplica a um serviço do Kubernetes e a todos os serviços do Kubernetes para um serviço do MCS.

MCS com VPC compartilhada

Com a implementação atual do MCS, se você implantar mais de uma frota na mesma VPC compartilhada, os metadados serão compartilhados entre as frotas. Quando um serviço é criado em uma frota, os metadados dele são exportados ou importados em todas as outras frotas que fazem parte da mesma VPC compartilhada e visíveis ao usuário.

A verificação de integridade usa a porta padrão em vez de containerPort

Quando você implanta um Serviço com um campo targetPort que faz referência a uma porta nomeada em uma implantação, o MCS configura a porta padrão para a verificação de integridade em vez do containerPort especificado.

Para evitar esse problema, use valores numéricos no campo de serviço ports.targetPort e no campo de implantação readinessProbe.httpGet.port em vez de valores nomeados.

Uma sondagem de prontidão inválida para um único serviço interrompe outros serviços

Há um possível erro conhecido de configuração do readinessProbe descrito em Como examinar ServiceExports. Com a implementação atual do MCS, esse 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 cada serviço em bom estado. Se um serviço do MCS não estiver sendo atualizado, verifique se nenhuma das ServiceExports em qualquer um dos clusters em qualquer um dos namespaces informa ReadinessProbeError como o motivo de a condição de status Exported ser "False". Consulte Como examinar ServiceExports para saber como verificar as condições.

A seguir