Entrada em vários clusters

A entrada de vários clusters (MCI) é um controlador da entrada de vários clusters hospedado na nuvem para clusters do Anthos GKE. É um serviço hospedado pelo Google compatível com a implantação de recursos de balanceamento de carga compartilhados entre clusters e regiões. Para implantar a entrada em vários clusters em vários clusters, conclua Como configurar a entrada de vários clusters e consulte Como implantar a entrada em vários clusters.

Rede de vários clusters

Muitos fatores impulsionam as topologias de vários clusters, incluindo a proximidade do usuário para apps, alta disponibilidade de cluster e regional, segurança e separação organizacional, migração de clusters e localidade de dados. Esses casos de uso raramente são isolados. À medida que os motivos para vários clusters aumentam, a necessidade de uma plataforma de vários clusters formal e produtiva se torna mais urgente.

A entrada de vários clusters foi projetado para atender às necessidades de balanceamento de carga de ambientes de vários clusters e multirregionais. É um controlador para o balanceador de carga HTTP(S) externo que fornece entrada para o tráfego proveniente da Internet em um ou mais clusters.

O suporte a vários clusters da entrada atende a muitos casos de uso, inclusive estes:

  • Um IP virtual (VIP, na sigla em inglês) único e consistente para um app, independentemente de onde o app seja implantado globalmente
  • Disponibilidade multirregional e de vários clusters por meio de verificação de integridade e failover de tráfego
  • Roteamento por proximidade por meio de VIPs Anycast públicos para baixa latência do cliente
  • Migração de cluster transparente para upgrades ou recriações de cluster.

Preços e avaliações

A entrada de vários clusters requer o licenciamento do Anthos no Google Cloud para todos os clusters que participam como back-ends de MCI. Cada cluster registrado é cobrado com base na capacidade de vCPU dele.

O MCI pode ser usado com pagamento por utilização ou por meio de licenciamento de assinatura do Anthos. Os preços do balanceador de carga padrão do Compute Engine se aplicam ao tráfego de entrada e às regras de encaminhamento criadas por meio da entrada.

Se você for um cliente novo do Anthos, poderá testá-lo no GKE no Google Cloud gratuitamente por até 30 dias ou até alcançar o equivalente a US$ 900 de uso, o que ocorrer primeiro. Durante o teste, você será cobrado e ressarcido ao mesmo tempo, pelas taxas aplicáveis até o valor de US$ 900. Para fazer o login, acesse a página do Anthos no Cloud Marketplace e clique em Iniciar o teste.

Como a entrada de vários clusters funciona

A entrada de vários clusters se baseia na arquitetura do balanceamento de carga HTTP(S) externo. O balanceamento de carga HTTP(S) é um balanceador de carga distribuído globalmente com proxies implantados em mais de 100 pontos de presença (PoPs, na sigla em inglês) do Google em todo o mundo. Esses proxies, chamados de Google Front Ends (GFEs, na sigla em inglês), ficam na borda da rede do Google, posicionados perto dos clientes. A entrada de vários clusters cria balanceadores de carga HTTP(S) externos no nível Premium. Esses balanceadores de carga usam endereços IP externos globais anunciados usando anycast. As solicitações são exibidas por GFEs e pelo cluster mais próximo do cliente. O tráfego da Internet vai para o PoP do Google mais próximo e usa o backbone do Google para chegar a um cluster do GKE. Essa configuração de balanceamento de carga resulta em latência menor do cliente para o GFE. É possível reduzir a latência entre os clusters do GKE e os GFEs. Basta executar os clusters do GKE em regiões mais próximas aos seus clientes.

O encerramento de conexões HTTP e HTTPS no perímetro permite que o balanceador de carga do Google decida para onde direcionar o tráfego determinando a disponibilidade do back-end antes que o tráfego entre em um data center ou região. Isso dá ao tráfego o caminho mais eficiente do cliente para o back-end, considerando a integridade e a capacidade dos back-ends.

A entrada de vários clusters é um controlador da entrada que programa o balanceador de carga TTP(S) externo usando grupos de endpoints da rede (NEGs, na sigla em inglês). Quando você cria um recurso MultiClusterIngress, o GKE implanta recursos do balanceador de carga do Compute Engine e configura os pods adequados nos clusters como back-ends. Os NEGs são usados para rastrear os endpoints do pod dinamicamente para que o balanceador de carga do Google tenha o conjunto certo de back-ends íntegros.

Fluxo de tráfego da entrada de vários clusters

Conforme você implanta aplicativos em clusters no GKE, a entrada de vários clusters garante que o balanceador de carga esteja em sincronia com os eventos que ocorrem no cluster:

  • Uma implantação é criada com os rótulos correspondentes à direita.
  • O processo de um pod morre e falha na verificação de integridade.
  • Um cluster é removido do pool de back-ends.

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

Arquitetura da entrada de vários clusters

A entrada de vários clusters usa um servidor centralizado da API Kubernetes para implantar a entrada em vários clusters. Esse servidor de API centralizado é chamado de 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 implantar esses recursos no cluster de configuração, o controlador de entrada do Anthos implanta balanceadores de carga em vários clusters.

Os conceitos e componentes a seguir compõem a entrada de vários clusters:

  • Controlador de entrada do Anthos: é um plano de controle distribuído globalmente que é executado como um serviço fora dos clusters. Isso permite que o ciclo de vida e as operações do controlador sejam independentes dos clusters do GKE.

  • Cluster de configuração: é um cluster do GKE escolhido em execução no Google Cloud em que os recursos MultiClusterIngress e MultiClusterService são implantados. Esse é um ponto de controle centralizado para esses recursos de vários clusters. Esses recursos de vários clusters existem e são acessíveis por meio de uma API lógica para manter a consistência em todos os clusters. O controlador de entrada observa o cluster de configuração e reconcilia a infraestrutura de balanceamento de carga.

  • Frota (anteriormente, environ): uma frota é um domínio que agrupa clusters e infraestrutura, gerencia recursos e mantém uma política consistente entre eles. O MCI usa o conceito de frotas para a aplicação do Ingress em diferentes clusters. Os clusters que você registra em uma frota ficam visíveis no MCI para que possam ser usados como back-ends para o Ingress.

  • Cluster de membros: os clusters registrados em uma frota são chamados de clusters de membros. Os clusters de membros na frota compreendem o escopo completo dos back-ends que o MCI reconhece. A visualização de gerenciamento de cluster do Google Kubernetes Engine fornece um console seguro para ver o estado de todos os clusters registrados.

Arquitetura da entrada de vários clusters

Fluxo de trabalho de implantação

As etapas a seguir ilustram um fluxo de trabalho de alto nível para usar a entrada de vários clusters em vários clusters.

  1. Registre clusters do GKE como clusters de membros.

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

  3. Implante aplicativos nos clusters do GKE em que eles precisam ser executados.

  4. Implante um ou mais recursos MultiClusterService no cluster de configuração com correspondências de rótulo e cluster para selecionar clusters, namespaces e pods considerados back-ends para um determinado serviço. Isso cria os NEGs no Compute Engine, que começa a registrar e gerenciar os endpoints do serviço.

  5. Implante um recurso MultiClusterIngress no cluster de configuração que referencia um ou mais recursos MultiClusterService como back-ends para o balanceador de carga. Isso implanta os recursos externos do balanceador de carga do Compute Engine e expõe os endpoints em clusters por meio de um único balanceador de carga VIP.

Conceitos do Ingress

A entrada de vários clusters usa um servidor centralizado da API Kubernetes para implantar a entrada em vários clusters. As seções a seguir descrevem o modelo de recursos da entrada em vários clusters, como implantar a entrada e conceitos importantes para gerenciar esse plano de controle de rede altamente disponível.

Recursos MultiClusterService

Um MultiClusterService (MCS) é um recurso personalizado usado pela entrada de vários clusters, que é uma representação lógica de um serviço em vários clusters. Um MCS é semelhante, mas substancialmente diferente do tipo de serviço principal. Um MCS existe apenas no cluster de configuração e gera serviços derivados nos clusters de destino. Um MCS não encaminha nada como um ClusterIP, LoadBalancer ou serviço NodePort. Ele simplesmente permite que a MCI se refira a um recurso distribuído singular. Veja a seguir um MCS simples para o aplicativo 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

Como um serviço, um MCS é um seletor de pods, mas também é capaz de selecionar rótulos e clusters. O pool de clusters que ele seleciona são chamados de clusters de membros e são todos os clusters registrados na frota. Esse MCS implanta um serviço derivado em todos os clusters de membros com o seletor app: foo. Se houver pods app: foo nesse cluster, esses IPs de pod serão adicionados como back-ends para a MCI.

O mci-zone1-svc-j726y6p1lilewtu7 a seguir é um serviço derivado que o MCS gerou em um dos clusters de destino. Esse serviço cria um NEG que rastreia endpoints de pods para todos os pods que correspondem ao seletor de rótulos especificado nesse cluster. Um serviço derivado e o NEG existirão em cada cluster de destino para cada MCS (a menos que você use seletores de cluster). Se não houver pods correspondentes em um cluster de destino, o serviço e o NEG estarão vazios. Os serviços derivados são totalmente gerenciados pelo MCS e não são gerenciados diretamente pelos usuários.

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-frontend
  ports:
  - name: web
    protocol: TCP
    port: 80
    targetPort: 80

Algumas observações sobre o serviço derivado:

  • A função dele é um agrupamento lógico de endpoints como back-ends para a entrada de vários clusters.
  • Ele gerencia o ciclo de vida do NEG para um determinado cluster e aplicativo.
  • Ele é criado como um serviço sem comando. Somente os campos Selector e Ports são transferidos da especificação MCS para a especificação de serviço derivada.
  • O controlador da entrada do Anthos gerencia o ciclo de vida dele.

Recurso MultiClusterIngress

Um recurso MultiClusterIngress (MCI) se comporta de maneira idêntica ao recurso principal do Ingress. Os dois têm a mesma especificação para definir hosts, caminhos, encerramento de protocolo e back-ends. Este é um exemplo simples de um recurso MCI que direciona o tráfego para os back-ends foo e bar, dependendo dos cabeçalhos do host 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

Essa MCI faz a correspondência do tráfego com o VIP em foo.example.com e bar.example.com enviando esse tráfego para os recursos MultiClusterService (MCS) chamados foo e bar. Essa MCI tem um back-end padrão que corresponde a todo o outro tráfego e o envia para o MCS de back-end padrão.

Correspondência de cabeçalho do host

Recursos de entrada em clusters

O cluster de configuração é o único que pode ter recursos MultiClusterIngress e MultiClusterService. Cada cluster de destino que tem pods que correspondem aos seletores de rótulo MCS também terá um serviço derivado correspondente programado neles. Se um cluster não for selecionado explicitamente por um MCS, um serviço derivado correspondente não será criado nesse cluster.

Um diagrama de um modelo de recursos do Ingress

Semelhança de namespace

Os clusters registrados do GKE se tornam membros de uma frota.

As frotas têm uma característica conhecida como semelhança de namespace, que pressupõe que os recursos com os mesmos nomes e namespace nos clusters são considerados instâncias do mesmo recurso. Na verdade, isso significa que os pods no namespace ns1 com os rótulos app: foo em diferentes clusters são considerados parte do mesmo pool de back-ends de aplicativos da perspectiva da entrada de vários clusters.

Isso tem implicações no funcionamento de diferentes equipes de desenvolvimento em um grupo de clusters. Equipes diferentes ainda podem aproveitar a mesma frota de clusters usando namespaces para segmentar cargas de trabalho mesmo entre limites de cluster. No entanto, é importante que cada equipe reserve os próprios namespaces explicitamente ou implicitamente em todos os clusters na frota.

No exemplo a seguir, uma equipe azul tem acesso para implantar em todos os namespaces azuis nos clusters da frota. O azul é considerado o mesmo namespace em cada cluster. O namespace azul também existe no cluster de configuração da entrada de vários clusters. Os recursos MultiClusterService implantados lá pela equipe azul só podem selecionar entre pods que também existem no namespace azul em diferentes clusters. Os recursos MCI e MCS não têm visibilidade ou acesso em namespaces em diferentes clusters e, portanto, a importância e a "semelhança" dos recursos são mantidas em clusters.

Um diagrama demonstrando a semelhança do namespace

Há ramificações de design na semelhança de namespace. Os seguintes princípios ajudarão os usuários a ter sucesso:

  • Os namespaces para finalidades diferentes não precisam ter o mesmo nome nos clusters.
  • Os namespaces precisam ser reservados explicitamente, alocando um namespace, ou implicitamente, por meio de políticas fora da banda, para equipes e clusters em uma frota.
  • Os namespaces para a mesma finalidade nos clusters precisam compartilhar o mesmo nome.
  • A permissão do usuário para namespaces em clusters precisa ser rigorosamente controlada para impedir o acesso não autorizado.
  • O namespace padrão ou os namespaces genéricos, como "prod" ou "dev", não podem ser usados para a implantação normal do aplicativo. É muito fácil para os usuários implantar recursos no namespace padrão acidentalmente e violar os princípios de segmentação dos namespaces.
  • O mesmo namespace precisa ser criado em clusters sempre que uma determinada equipe ou grupo de usuários precisar implantar recursos.

Design do cluster de configuração

O cluster de configuração da entrada de vários clusters é um único cluster do GKE que hospeda os recursos MCI e MCS e atua como o único ponto de controle da entrada em toda a frota de clusters do GKE de destino. Você escolhe o cluster de configuração ao ativar a entrada de vários clusters. É possível escolher qualquer cluster do GKE como o cluster de configuração e alterá-lo a qualquer momento.

Disponibilidade do cluster de configuração

Como o cluster de configuração é um ponto de controle único, os recursos da entrada de vários clusters não poderão ser criados ou atualizados se a API do cluster de configuração não estiver disponível. Os balanceadores de carga e o tráfego veiculados por eles não serão afetados por uma interrupção do cluster de configuração, mas as alterações em MCI e MCS não serão reconciliadas pelo controlador até que ele esteja disponível novamente.

Veja alguns princípios de design para usar e gerenciar o cluster de configuração:

  • O cluster de configuração precisa ser escolhido de modo que esteja altamente disponível. Os clusters regionais têm preferência sobre os clusters zonais.
  • O cluster de configuração não precisa ser um cluster dedicado para a entrada de vários clusters. O cluster de configuração pode hospedar cargas de trabalho administrativas ou até mesmo de aplicativos, embora seja necessário tenha cuidado para garantir que os aplicativos hospedados não afetem a disponibilidade do servidor da API do cluster de configuração. O cluster de configuração pode ser um cluster de destino que hospeda back-ends para MCIs. No entanto, se forem necessárias precauções extras, o cluster de configuração também poderá ser excluído como um back-end MCI por meio da seleção de cluster.
  • Os clusters de configuração precisam ter todos os namespaces usados pelos back-ends de cluster de destino. Um MCS só pode referir-se a pods no mesmo namespace em clusters para que o namespace precise estar presente no cluster de configuração.
  • Os usuários que implantam o Ingress em vários clusters precisam ter acesso ao cluster de configuração para implantar recursos MCI e MCS. No entanto, os usuários só precisam ter acesso aos namespaces que têm permissão para usar.

Como selecionar e migrar o cluster de configuração

Escolha o cluster de configuração ao ativar a entrada de vários clusters. Qualquer cluster membro de uma frota pode ser selecionado como o cluster de configuração. Atualize o cluster de configuração a qualquer momento, mas tenha cuidado para garantir que ele não causará interrupções. O controlador de entrada do Anthos reconciliará todos os recursos MCI e MCS existentes no cluster de configuração. Ao migrar o cluster de configuração do atual para o próximo, os recursos MCI e MCS precisam ser idênticos. Se os recursos não forem idênticos, os balanceadores de carga do Compute Engine poderão ser atualizados ou destruídos após a atualização do cluster de configuração.

No diagrama a seguir, um sistema de CI/CD centralizado aplica recursos MCI e MCS ao servidor da API GKE para o cluster de configuração (gke-us) e um cluster de backup (gke-eu) em todos os momentos para que os recursos sejam idênticos nos dois clusters. Se for necessário alterar o cluster de configuração, para emergências ou tempo de inatividade planejado, ele poderá ser atualizado sem qualquer impacto, porque os recursos MCI e MCS são idênticos.

Um sistema de CI/CD centralizado que aplica recursos MCI e MCS

Seleção de cluster

Os recursos do MCS conseguem selecionar explicitamente os clusters. Por padrão, um MCS agendará serviços derivados em cada cluster de destino. A seleção de cluster define uma lista explícita de clusters para um determinado MCS em que os serviços derivados precisam ser programados. Todos os outros clusters de destino serão ignorados. Consulte Como configurar a entrada de vários clusters para configurar a seleção de clusters.

Há muitos casos de uso em que convém aplicar regras de entrada a clusters específicos:

  • isolar o cluster de configuração para impedir que os MCSs selecionem entre eles;
  • controlar o tráfego entre clusters de maneira azul-verde para a migração de aplicativos;
  • rotear para back-ends de aplicativos que existem apenas em um subconjunto de clusters;
  • usar um VIP L7 único para roteamento de host/caminho para back-ends que residem em clusters diferentes.

A seleção de cluster é feita por meio do campo clusters no MCS. Os clusters são explicitamente referenciados por <region | zone>/<name>. Os clusters de membro dentro da mesma frota e região precisam ter nomes exclusivos para que não haja conflitos de nomenclatura.

No exemplo a seguir, o MCS foo tem um campo clusters que refere-se a europe-west1-c/gke-eu e asia-northeast1-a/gke-asia. Como resultado, os pods com os rótulos correspondentes nos clusters gke-asia e gke-eu podem ser incluídos como back-ends para uma determinada MCI. Isso excluirá o cluster gke-us do Ingress, mesmo que ele tenha pods com o rótulo app: foo. Isso pode ser útil para integrar ou migrar novos clusters e controlar o tráfego independentemente da implantação do pod.

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"

O diagrama a seguir mostra três clusters: gke-eu, gke-asia-1 e gke-asia-2. O gke-asia-2 é excluído como um back-end, mesmo que os pods com rótulos correspondentes já estejam lá. Isso permite que o cluster seja excluído do tráfego para manutenção ou outras operações. Se o campo "clusters" for omitido de um MCS, ele selecionará todos os clusters de membros implicitamente.

Um diagrama que mostra um back-end excluído

A seguir