Entrada em vários clusters

Autopilot Padrão

A entrada em vários clusters é um controlador alojado na nuvem para clusters do Google Kubernetes Engine (GKE). É um serviço alojado na Google que suporta a implementação de recursos de equilíbrio de carga partilhados em clusters e regiões. Para implementar a entrada em vários clusters em vários clusters, conclua a configuração da entrada em vários clusters e, de seguida, consulte o artigo Implementar a entrada em vários clusters.

Para uma comparação detalhada entre o Multi Cluster Ingress (MCI), o Multi-cluster Gateway (MCG) e o balanceador de carga com grupos de pontos finais de rede autónomos (LB e NEGs autónomos), consulte o artigo Escolha a sua API de balanceamento de carga de vários clusters para o GKE.

Rede em vários clusters

Muitos fatores determinam as topologias de vários clusters, incluindo a proximidade dos utilizadores para apps, a alta disponibilidade regional e de clusters, a separação organizacional e de segurança, a migração de clusters e a localidade dos dados. Estes exemplos de utilização são raramente isolados. À medida que os motivos para ter vários clusters aumentam, a necessidade de uma plataforma de vários clusters formal e comercializada torna-se mais urgente.

A entrada em vários clusters foi concebida para satisfazer as necessidades de equilíbrio de carga de ambientes multicluster e multirregionais. É um controlador para o balanceador de carga HTTP(S) externo para fornecer entrada para o tráfego proveniente da Internet em um ou mais clusters.

O suporte de vários clusters da entrada em vários clusters satisfaz muitos exemplos de utilização, incluindo:

• Um IP virtual (VIP) único e consistente para uma app, independentemente do local onde a app é implementada a nível global.
• Disponibilidade em várias regiões e vários clusters através da verificação do estado de funcionamento e da comutação por falha de tráfego.
• Encaminhamento baseado na proximidade através de VIPs Anycast públicos para uma baixa latência do cliente.
• Migração de cluster transparente para atualizações ou reconstruções de clusters.

Quotas predefinidas

A Entrada em vários clusters tem as seguintes quotas predefinidas:

• Para ver detalhes sobre os limites de membros para frotas, consulte as quotas de gestão de frotas. para saber quantos membros são suportados numa frota.
• 100 recursos MultiClusterIngress e 100 recursos MultiClusterService por projeto. Pode criar até 100 recursos MultiClusterIngress e 100 MultiClusterService num cluster de configuração para qualquer número de clusters de back-end até ao máximo de clusters por projeto.

Preços e avaliações

Para saber mais sobre os preços da Entrada em vários clusters, consulte o artigo Preços da Entrada em vários clusters.

Como funciona a entrada em vários clusters

A entrada em vários clusters baseia-se na arquitetura do balanceador de carga de aplicações externo global. O balanceador de carga de aplicações externo global é um balanceador de carga distribuído globalmente com proxies implementados em mais de 100 pontos de presença (PoPs) da Google em todo o mundo. Estes proxies, denominados front-ends da Google (GFEs), estão localizados no limite da rede da Google, posicionados perto dos clientes. A entrada em vários clusters cria balanceadores de carga de aplicações externos no nível Premium. Estes balanceadores de carga usam endereços IP externos globais anunciados através de anycast. Os pedidos são servidos por GFEs e pelo cluster mais próximo do cliente. O tráfego da Internet vai para o PoP da Google mais próximo e usa a rede principal da Google para chegar a um cluster do GKE. Esta configuração de balanceamento de carga resulta numa latência inferior do cliente para o GFE. Também pode reduzir a latência entre a publicação de clusters do GKE e GFEs executando os clusters do GKE em regiões mais próximas dos seus clientes.

A terminação das ligações HTTP e HTTPS no limite permite que o balanceador de carga da Google decida para onde encaminhar o tráfego determinando a disponibilidade do back-end antes de o tráfego entrar num centro de dados ou numa região. Isto dá ao tráfego o caminho mais eficiente do cliente para o back-end, tendo em conta o estado e a capacidade dos back-ends.

O Multi Cluster Ingress é um controlador Ingress que programa o balanceador de carga de HTTP(S) externo através de grupos de pontos finais de rede (NEGs). Quando cria um recurso MultiClusterIngress, o GKE implementa recursos do balanceador de carga do Compute Engine e configura os pods adequados em todos os clusters como back-ends. Os NEGs são usados para acompanhar os pontos finais dinamicamente, para que o balanceador de carga da Google tenha o conjunto certo de back-ends em bom estado.

À medida que implementa aplicações em clusters no GKE, o Multi Cluster Ingress garante que o equilibrador de carga está sincronizado com os eventos que ocorrem no cluster:

• É criada uma implementação com as etiquetas de correspondência corretas.
• O processo de um pod termina e a respetiva verificação de funcionamento falha.
• Um cluster é removido do conjunto de back-ends.

A entrada em vários clusters atualiza o balanceador de carga, mantendo-o consistente com o ambiente e o estado pretendido dos recursos do Kubernetes.

Arquitetura de entrada em vários clusters

A entrada em vários clusters usa um servidor da API Kubernetes centralizado para implementar a entrada em vários clusters. Este servidor de API centralizado chama-se cluster de configuração. Qualquer cluster do GKE pode atuar como o cluster de configuração. O cluster de configuração usa dois tipos de recursos personalizados: MultiClusterIngress e MultiClusterService. Ao implementar estes recursos no cluster de configuração, o controlador Multi Cluster Ingress implementa equilibradores de carga em vários clusters.

Os seguintes conceitos e componentes constituem o Multi Cluster Ingress:

• Controlador Multi Cluster Ingress: trata-se de um painel de controlo distribuído globalmente que é executado como um serviço fora dos seus clusters. Isto permite que o ciclo de vida e as operações do controlador sejam independentes dos clusters do GKE.

• Cluster de configuração: este é um cluster do GKE escolhido que é executado emGoogle Cloud onde os recursos MultiClusterIngress e MultiClusterService são implementados. Este é um ponto de controlo centralizado para estes recursos de vários clusters. Estes recursos de vários clusters existem e são acessíveis a partir de uma única API lógica para manter a consistência em todos os clusters. O controlador Ingress monitoriza o cluster de configuração e reconcilia a infraestrutura de balanceamento de carga.

• Uma frota permite agrupar e normalizar logicamente os clusters do GKE, o que facilita a administração da infraestrutura e permite a utilização de funcionalidades de vários clusters, como o Multi Cluster Ingress. Pode saber mais acerca das vantagens das frotas e como criá-las na documentação de gestão de frotas. Um cluster só pode ser membro de uma única frota.

• Cluster membro: os clusters registados numa frota são denominados clusters membros. Os clusters membros na frota compreendem o âmbito completo dos back-ends de que a entrada em vários clusters tem conhecimento. A vista de gestão de clusters do Google Kubernetes Engine oferece uma consola segura para ver o estado de todos os seus clusters registados.

Fluxo de trabalho de implementação

Os passos seguintes ilustram um fluxo de trabalho de nível elevado para usar o Multi Cluster Ingress em vários clusters.

1. Registe clusters do GKE numa frota no projeto escolhido.

2. Configure um cluster do GKE como o cluster de configuração central. Este cluster pode ser um plano de controlo dedicado ou pode executar outras cargas de trabalho.

3. Implemente aplicações nos clusters do GKE onde têm de ser executadas.

4. Implemente um ou mais recursos MultiClusterService no cluster de configuração com etiquetas e correspondências de clusters para selecionar clusters, espaços de nomes e pods que são considerados back-ends para um determinado serviço. Isto cria NEGs no Compute Engine, que começa a registar e gerir pontos finais de serviço.

5. Implemente um recurso MultiClusterIngress no cluster de configuração que faça referência a um ou mais recursos MultiClusterService como back-ends para o equilibrador de carga. Isto implementa os recursos do balanceador de carga externo do Compute Engine e expõe os pontos finais em clusters através de um único VIP do balanceador de carga.

Conceitos de entrada

A entrada em vários clusters usa um servidor de API Kubernetes centralizado para implementar a entrada em vários clusters. As secções seguintes descrevem o modelo de recursos do Multi Cluster Ingress, como implementar o Ingress e os conceitos importantes para gerir este plano de controlo de rede de alta disponibilidade.

Recursos MultiClusterService

Um MultiClusterService é um recurso personalizado usado pelo Multi Cluster Ingress para representar serviços de partilha entre clusters. Um recurso MultiClusterService seleciona pods, semelhante ao recurso de serviço, mas um MultiClusterService também pode selecionar etiquetas e clusters. O conjunto de clusters que um MultiClusterService seleciona é denominado clusters membros. Todos os clusters registados na frota são clusters membros.

Um MultiClusterService só existe no cluster de configuração e não encaminha nada como um serviço ClusterIP, LoadBalancer ou NodePort. Em alternativa, permite que o controlador de entrada em vários clusters consulte um recurso distribuído singular.

O manifesto de exemplo seguinte descreve um MultiClusterService para uma aplicação com o nome foo:

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: foo
  namespace: blue
spec:
  template:
    spec:
      selector:
        app: foo
      ports:
      - name: web
        protocol: TCP
        port: 80
        targetPort: 80

Este manifesto implementa um serviço em todos os clusters membros com o seletor app: foo. Se existirem app: foopods nesse cluster, os respetivos endereços IP são adicionados como back-ends para o MultiClusterIngress.

O seguinte mci-zone1-svc-j726y6p1lilewtu7 é um serviço derivado gerado num dos clusters de destino. Este serviço cria um NEG que acompanha os pontos finais do agrupamento para todos os agrupamentos que correspondem ao seletor de etiquetas especificado neste cluster. Existe um serviço derivado e um NEG em todos os clusters de destino para cada MultiClusterService (exceto se usar seletores de clusters). Se não existirem Pods correspondentes num cluster de destino, o serviço e o NEG ficam vazios. Os serviços derivados são totalmente geridos pela MultiClusterService e não são geridos diretamente pelos utilizadores.

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports":{"8080":{}}}'
    cloud.google.com/neg-status: '{"network_endpoint_groups":{"8080":"k8s1-a6b112b6-default-mci-zone1-svc-j726y6p1lilewt-808-e86163b5"},"zones":["us-central1-a"]}'
    networking.gke.io/multiclusterservice-parent: '{"Namespace":"default","Name":"zone1"}'
  name: mci-zone1-svc-j726y6p1lilewtu7
  namespace: blue
spec:
  selector:
    app: foo
  ports:
  - name: web
    protocol: TCP
    port: 80
    targetPort: 80

Algumas notas sobre o serviço derivado:

• A sua função é a de um agrupamento lógico de pontos finais como back-ends para a entrada em vários clusters.
• Gere o ciclo de vida do NEG para um determinado cluster e aplicação.
• É criado como um serviço sem interface. Tenha em atenção que apenas os campos Selector e Ports são transferidos do MultiClusterService para o serviço derivado.
• O controlador Ingress gere o respetivo ciclo de vida.

Recurso MultiClusterIngress

Um recurso MultiClusterIngress comporta-se de muitas formas de forma idêntica ao recurso Ingress principal. Ambos têm a mesma especificação para definir anfitriões, caminhos, encerramento de protocolo e back-ends.

O manifesto seguinte descreve um MultiClusterIngress que encaminha o tráfego para os back-ends foo e bar, consoante os cabeçalhos do anfitrião HTTP:

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: foobar-ingress
  namespace: blue
spec:
  template:
    spec:
      backend:
        serviceName: default-backend
        servicePort: 80
      rules:
      - host: foo.example.com
        backend:
          serviceName: foo
          servicePort: 80
      - host: bar.example.com
        backend:
          serviceName: bar
          servicePort: 80

Este recurso MultiClusterIngress faz corresponder o tráfego ao endereço IP virtual em foo.example.com e bar.example.com enviando este tráfego para os recursos MultiClusterService denominados foo e bar. Este MultiClusterIngress tem um back-end predefinido que corresponde a todo o outro tráfego e envia esse tráfego para o back-end predefinido MultiClusterService.

O diagrama seguinte mostra como o tráfego flui de um Ingress para um cluster:

No diagrama, existem dois clusters, gke-us e gke-eu. O tráfego flui de foo.example.com para os pods que têm a etiqueta app:foo em ambos os clusters. A partir de bar.example.com, o tráfego flui para os pods que têm a etiqueta app:bar em ambos os clusters.

Recursos de entrada em clusters

O cluster de configuração é o único cluster que pode ter recursos MultiClusterIngress e MultiClusterService. Cada cluster de destino que tenha pods que correspondam aos seletores de etiquetas MultiClusterService também tem um serviço derivado correspondente agendado neles. Se um cluster não for selecionado explicitamente por um MultiClusterService, não é criado um serviço derivado correspondente nesse cluster.

Identidade do espaço de nomes

A igualdade do espaço de nomes é uma propriedade dos clusters do Kubernetes em que um espaço de nomes se estende pelos clusters e é considerado o mesmo espaço de nomes.

No diagrama seguinte, o espaço de nomes blue existe nos clusters do GKE gke-cfg, gke-eu e gke-us. A igualdade do namespace considera que o namespace blue é o mesmo em todos os clusters. Isto significa que um utilizador tem os mesmos privilégios para os recursos no espaço de nomes blue em todos os clusters. A igualdade do espaço de nomes também significa que os recursos de serviço com o mesmo nome em vários clusters no espaço de nomes blue são considerados o mesmo serviço.

O gateway trata o serviço como um único conjunto de pontos finais nos três clusters. Uma vez que os recursos Routes e MultiClusterIngress só podem encaminhar para serviços no mesmo espaço de nomes, isto oferece uma multi-posse consistente para a configuração em todos os clusters na frota. Os fleets oferecem um elevado grau de portabilidade, uma vez que os recursos podem ser implementados ou movidos entre clusters sem alterações à respetiva configuração. A implementação no mesmo namespace da frota oferece consistência entre clusters.

Considere os seguintes princípios de design para a igualdade de espaços de nomes:

• Os espaços de nomes para fins diferentes não devem ter o mesmo nome em todos os clusters.
• Os espaços de nomes devem ser reservados de forma explícita, através da atribuição de um espaço de nomes, ou implícita, através de políticas fora da banda, para equipas e clusters numa frota.
• Os espaços de nomes para o mesmo objetivo em vários clusters devem partilhar o mesmo nome.
• A autorização do utilizador para os espaços de nomes em todos os clusters deve ser rigorosamente controlada para evitar o acesso não autorizado.
• Não deve usar o espaço de nomes predefinido nem espaços de nomes genéricos, como "prod" ou "dev", para a implementação normal de aplicações. É demasiado fácil para os utilizadores implementarem recursos no espaço de nomes predefinido acidentalmente e violarem os princípios de segmentação dos espaços de nomes.
• O mesmo espaço de nomes deve ser criado em todos os clusters sempre que uma determinada equipa ou grupo de utilizadores tiver de implementar recursos.

Design do cluster de configuração

O cluster de configuração da entrada em vários clusters é um único cluster do GKE que aloja os recursos MultiClusterIngress e MultiClusterService e atua como o único ponto de controlo para a entrada na frota de clusters do GKE de destino. Escolhe o cluster de configuração quando ativa a entrada em vários clusters. Pode escolher qualquer cluster do GKE como o cluster de configuração e alterar o cluster de configuração em qualquer altura.

Disponibilidade do cluster de configuração

Uma vez que o cluster de configuração é um único ponto de controlo, não é possível criar nem atualizar recursos de entrada de vários clusters se a API do cluster de configuração não estiver disponível. Os balanceadores de carga e o tráfego fornecido por estes não são afetados por uma indisponibilidade do cluster de configuração, mas as alterações aos recursos MultiClusterIngress e MultiClusterService não são reconciliadas pelo controlador até que este esteja novamente disponível.

Considere os seguintes princípios de design para clusters de configuração:

• O cluster de configuração deve ser escolhido de forma a ter uma elevada disponibilidade. Os clusters regionais são preferíveis aos clusters zonais.
• Para ativar a entrada em vários clusters, o cluster de configuração não tem de ser um cluster dedicado. O cluster de configuração pode alojar cargas de trabalho administrativas ou até mesmo de aplicações, embora deva garantir que as aplicações alojadas não afetam a disponibilidade do servidor da API do cluster de configuração. O cluster de configuração pode ser um cluster de destino que aloja back-ends para recursos, embora, se forem necessárias precauções adicionais, o cluster de configuração também possa ser excluído como um back-end através da seleção de clusters.MultiClusterService
• Os clusters de configuração devem ter todos os espaços de nomes usados pelos back-ends do cluster de destino. Um recurso MultiClusterService só pode referenciar pods no mesmo espaço de nomes em todos os clusters, pelo que esse espaço de nomes tem de estar presente no cluster de configuração.
• Os utilizadores que implementam a entrada em vários clusters têm de ter acesso ao cluster de configuração para implementar recursos MultiClusterIngress e MultiClusterService. No entanto, os utilizadores só devem ter acesso aos espaços de nomes que têm autorização para usar.

Selecionar e migrar o cluster de configuração

Tem de escolher o cluster de configuração quando ativa o Multi Cluster Ingress. Qualquer cluster membro de uma frota pode ser selecionado como o cluster de configuração. Pode atualizar o cluster de configuração em qualquer altura, mas deve ter cuidado para garantir que não causa interrupções. O controlador Ingress reconcilia todos os recursos existentes no cluster de configuração. Quando migrar o cluster de configuração do atual para o seguinte, os recursos MultiClusterIngress e MultiClusterService têm de ser idênticos. Se os recursos não forem idênticos, os equilibradores de carga do Compute Engine podem ser atualizados ou destruídos após a atualização do cluster de configuração.

O diagrama seguinte mostra como um sistema de CI/CD centralizado aplica recursos MultiClusterIngress e MultiClusterService ao servidor da API GKE para o cluster de configuração (gke-us) e um cluster de cópia de segurança (gke-eu) em todos os momentos, para que os recursos sejam idênticos nos dois clusters. Pode alterar o cluster de configuração para emergências ou tempo de inatividade planeado em qualquer altura sem qualquer impacto, porque os recursos MultiClusterIngress e MultiClusterService são idênticos.

Seleção de clusters

MultiClusterService recursos podem selecionar em clusters. Por predefinição, o controlador agenda um serviço derivado em cada cluster de destino. Se não quiser um serviço derivado em todos os clusters de destino, pode definir uma lista de clusters através do campo spec.clusters no manifesto MultiClusterService.

É recomendável definir uma lista de clusters se precisar de:

• Isole o grupo de configuração para impedir que os recursos MultiClusterService sejam selecionados no grupo de configuração.
• Controlar o tráfego entre clusters para a migração de aplicações.
• Encaminhar para back-ends de aplicações que só existem num subconjunto de clusters.
• Use um único endereço IP virtual HTTP(S) para o encaminhamento para back-ends que residem em clusters diferentes.

Tem de garantir que os clusters de membros na mesma frota e região têm nomes exclusivos para evitar colisões de nomes.

Para saber como configurar a seleção de clusters, consulte o artigo Configurar o Multi Cluster Ingress.

O manifesto seguinte descreve um MultiClusterService que tem um campo clusters que faz referência a europe-west1-c/gke-eu e asia-northeast1-a/gke-asia:

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: foo
  namespace: blue
spec:
  template:
    spec:
      selector:
        app: foo
      ports:
      - name: web
        protocol: TCP
        port: 80
        targetPort: 80
  clusters:
  - link: "europe-west1-c/gke-eu"
  - link: "asia-northeast1-a/gke-asia-1"

Este manifesto especifica que os Pods com as etiquetas correspondentes nos clusters gke-asia e gke-eu podem ser incluídos como backends para o MultiClusterIngress. Quaisquer outros clusters são excluídos, mesmo que tenham pods com a etiqueta app: foo.

O diagrama seguinte mostra um exemplo de configuração do MultiClusterService com o manifesto anterior:

No diagrama, existem três clusters: gke-eu, gke-asia-1 e gke-asia-2. O cluster gke-asia-2 não está incluído como um back-end, mesmo que existam Pods com etiquetas correspondentes, porque o cluster não está incluído na lista spec.clusters do manifesto. O cluster não recebe tráfego para manutenção nem outras operações.

O que se segue?

• Saiba como configurar o Ingress de vários clusters.
• Saiba como implementar gateways de vários clusters.
• Saiba como implementar o Multi Cluster Ingress.
• Implemente a entrada em vários clusters para o balanceamento de carga externo.