Sobre as opções de configuração de clusters

Nesta página, explicamos as principais opções de configuração de cluster que podem ser feitas ao criar um cluster no Google Kubernetes Engine (GKE), seja usando o console do Google Cloud, a Google Cloud CLI ou o Terraform. Essas opções permitem personalizar uma ampla gama de atributos e comportamentos do cluster para atender às suas necessidades, desde se o cluster é acessível de redes públicas até como você quer que ele receba upgrades de versão.

Muitas das opções discutidas neste guia não podem ser alteradas depois que um cluster é criado. Isso inclui escolhas que afetam a disponibilidade e a rede de um cluster. Se você precisar mudar essas opções, crie um novo cluster e migre o tráfego para ele, o que pode causar interrupções.

Prática recomendada:

Como muitas opções de configuração de cluster não podem ser alteradas após a criação do cluster, planeje e projete a configuração do cluster com administradores e arquitetos da organização, arquitetos de nuvem, administradores de rede ou qualquer outra equipe responsável por definir, implementar e manter a arquitetura do GKE e do Google Cloud.

Esta página é destinada a administradores e arquitetos que definem soluções de TI e arquitetura de sistemas de acordo com a estratégia da empresa. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud, consulte Funções e tarefas de usuário comuns do GKE Enterprise.

Antes de ler esta página, você precisa conhecer os seguintes conceitos e conceitos básicos do Kubernetes:

Nível de gerenciamento do cluster

Antes de discutir as opções de cluster, é importante entender o nível de flexibilidade, responsabilidade e controle necessários para o cluster. O nível de controle necessário determina o modo de operação a ser usado no GKE e as opções de configuração de cluster que você precisa fazer.

Ao criar um cluster no GKE, você usa um dos seguintes modos de operação:

  • Autopilot (recomendado): fornece uma configuração de cluster totalmente provisionada e gerenciada. Os clusters do Autopilot são pré-configurados com uma configuração de cluster otimizada pronta para cargas de trabalho de produção.

  • Padrão: oferece flexibilidade de configuração avançada sobre a infraestrutura subjacente do cluster. Para clusters criados usando o modo Standard, você determina a configuração necessária para as cargas de trabalho de produção.

Para mais informações sobre esses modos e saber mais sobre o Autopilot, consulte Modos de operação do GKE e a visão geral do Autopilot.

Confira uma comparação detalhada dos dois modos em Comparar o GKE Standard e o Autopilot.

Opções de configuração do cluster

Depois de escolher um modo de operação, selecione a configuração necessária para o cluster. Como os clusters do Autopilot são mais gerenciados e configurados pelo Google Cloud do que os clusters padrão, eles têm menos opções de configuração disponíveis.

As opções de configuração de todos os clusters se enquadram nas seguintes categorias:

  • Nome e outros metadados: cada cluster precisa ter um nome de identificação exclusivo no projeto. Também é possível adicionar uma descrição e rótulos do cluster.
  • Disponibilidade e escalonabilidade: especifique onde você quer que o plano de controle e os nós do cluster sejam executados e se você quer várias réplicas do plano de controle. Todos os clusters do Autopilot são regionais, o que significa que eles têm vários planos de controle em várias zonas de computação em uma região do Google Cloud.
  • Assinatura da frota: escolha se o cluster vai ser membro de uma frota.
  • Rede: opções de rede, incluindo a rede e a sub-rede de nuvem privada virtual (VPC) em que o cluster está e se você quer que o cluster seja acessível por redes públicas.
  • Gerenciamento de versões e upgrades: use os canais de lançamento para escolher o equilíbrio entre novos recursos e estabilidade ao fazer upgrade do software do cluster e definir janelas e exclusões de manutenção para escolher quando os upgrades podem e não podem ocorrer.
  • Segurança: inclui se o cluster usa a federação de identidade da carga de trabalho do GKE e a conta de serviço usada pelos nós do cluster para autenticação no Google Cloud.
  • Recursos do cluster: ative e configure outros recursos do GKE e do Google Cloud para este cluster, incluindo backups e observabilidade. O modo padrão também permite criar clusters Alfa de curta duração para testar os recursos Alfa do Kubernetes.

Além disso, os clusters padrão também têm opções na seguinte categoria:

  • Pools de nós: especifique detalhes sobre os nós do cluster, incluindo pools de nós, sistema operacional do nó e dimensionamento do nó.

As seções a seguir analisam algumas dessas categorias em mais detalhes, principalmente aquelas com opções que não podem ser alteradas após a criação do cluster. Para conferir uma lista completa de opções de configuração, consulte a Referência de configuração.

A tabela a seguir compara as opções disponíveis em algumas áreas importantes para clusters Autopilot e Standard:

Opções de cluster Modo
Piloto automático Standard
Tipo de disponibilidade Regional Regional ou Por zona
Canal de lançamento Rápida, Normal ou Estável Qualquer canal
Versões do cluster Padrão ou outra versão disponível Padrão ou outra versão disponível
Roteamento de rede Cluster nativo de VPC Nativo de VPC ou Baseado em rotas
Isolamento de rede Personalizável Personalizável
Recursos do Kubernetes Production Produção ou Alfa

Tipo de disponibilidade do cluster

Com o GKE, é possível criar um cluster adaptado aos requisitos de disponibilidade da sua carga de trabalho e seu orçamento. É possível escolher entre clusters regionais com várias réplicas do plano de controle em várias zonas de computação em uma região do Google Cloud ou clusters zonais com um único plano de controle em uma única zona. Os clusters do Autopilot são sempre regionais.

Para ajudar você a escolher qual tipo de cluster criar no modo Standard, consulte Como escolher um plano de controle regional ou por zona.

Não é possível atualizar essas configurações após a criação do cluster: um cluster zonal não pode se tornar regional, e um cluster regional não pode se tornar zonal.

Prática recomendada:

Para cargas de trabalho de produção, use clusters regionais, porque eles geralmente oferecem maior disponibilidade do que os clusters zonais. Para ambientes de desenvolvimento, use clusters regionais com pools de nós zonais. Um cluster com um plano de controle regional e pools de nós zonais tem os mesmos custos que um cluster zonal. Para saber mais sobre regiões, consulte Regiões e zonas.

Clusters regionais

Um cluster regional tem várias réplicas do plano de controle, em execução em várias zonas na região especificada do Google Cloud. Sempre é necessário especificar uma região ao criar um cluster regional ou do Autopilot.

Somente para clusters padrão regionais, você também pode escolher em quais zonas os nós do cluster são executados. Os nós em um cluster regional podem ser executados em várias zonas ou em uma única zona, dependendo dos locais configurados do nó. Por padrão, o GKE replica cada pool de nós em três zonas da região do plano de controle. Ao criar um cluster padrão ou adicionar um novo pool de nós, é possível mudar a configuração padrão especificando as zonas em que os nós do cluster são executados. Todas as zonas precisam estar na mesma região que o plano de controle.

Use clusters regionais para executar cargas de trabalho de produção, porque eles oferecem maior disponibilidade do que os clusters zonais.

Não é possível mudar a região de um cluster regional após a criação.

Clusters zonais (somente clusters padrão)

Os clusters de zona têm somente um plano de controle em uma única zona. Dependendo dos requisitos de disponibilidade da carga de trabalho, é possível distribuir os nós para o cluster de zona em uma única ou em várias zonas.

Para criar um cluster zonal, consulte Como criar um cluster zonal.

Clusters de zona única

Um cluster de zona única tem um único plano de controle em execução em uma zona. Este plano de controle gerencia cargas de trabalho em nós em execução na mesma zona. Se você executar uma carga de trabalho em uma única zona, ela ficará indisponível no caso de uma interrupção temporária zonal.

Clusters com várias zonas

Um cluster com várias zonas tem uma única réplica do plano de controle em execução em uma única zona e tem nós em execução em várias zonas. Durante um upgrade do cluster ou uma interrupção da zona em que o plano de controle é executado, as cargas de trabalho ainda são executadas. No entanto, o cluster, os nós e as cargas de trabalho não podem ser configurados até que o plano de controle esteja disponível. Clusters em várias zonas equilibram a disponibilidade e o custo para cargas de trabalho consistentes. Se você quiser manter a disponibilidade, e o número de nós, e os pools de nós mudarem com frequência, avalie a possibilidade de usar um cluster regional. Se você executar uma carga de trabalho em várias zonas e houver uma interrupção zonal, ela será interrompida nessa zona, mas vai permanecer disponível em outras.

Nível do cluster

Como você sabe pelas edições do GKE, o GKE tem dois níveis de recursos: um nível padrão de recursos disponível para todos os usuários do GKE e um nível empresarial que adiciona recursos avançados para trabalhar em escala empresarial, muitos dos quais são baseados no gerenciamento de frota do GKE.

Para clusters do GKE no Google Cloud, selecione se você quer adicionar o nível extra de recursos por cluster. Depois que um cluster é registrado no nível do GKE Enterprise, você tem o direito de usar todos os recursos empresariais disponíveis. Se você não especificar um nível de cluster, o cluster vai usar o nível padrão por padrão, com algumas exceções.

Entenda o seguinte ao selecionar o nível do cluster:

  • Muitos recursos do GKE Enterprise exigem associação à frota para funcionamento. É possível registrar um cluster em uma frota durante a criação dele ou depois que ele for criado. Se você quiser usar os recursos do GKE Enterprise com frota ativada em um cluster, recomendamos registrar o cluster em uma frota durante a criação, porque isso significa que o cluster vai herdar as configurações no nível da frota para recursos empresariais. Saiba mais sobre isso em Assinatura da frota.
  • Só é possível ativar o nível Enterprise para um cluster se a API GKE Enterprise (Anthos) estiver ativada no projeto do cluster.

Essa configuração pode ser alterada após a criação do cluster.

Para mais detalhes sobre os recursos incluídos no GKE Enterprise, incluindo o subconjunto de recursos que não exigem associação à frota, consulte Opções de implantação do GKE Enterprise.

Assinatura da frota

Se a organização usar vários clusters, simplifique o gerenciamento de vários clusters adicionando os clusters a uma frota: um agrupamento lógico de clusters do Kubernetes. A criação de uma frota ajuda sua organização a melhorar o gerenciamento de clusters individuais para grupos inteiros de clusters e permite usar recursos ativados por frota, como o Ingress de vários clusters, o Config Sync e o Controlador de políticas.

Embora seja possível adicionar clusters a uma frota a qualquer momento, se você ativou o GKE Enterprise, é altamente recomendável registrar novos clusters de nível empresarial em uma frota durante a criação deles. Isso ocorre porque esses clusters "nascidos na frota" são criados com as configurações padrão no nível da frota escolhida para vários recursos empresariais e com os registros e as métricas recomendados já ativados. Saiba mais sobre isso nos seguintes guias:

Essa configuração pode ser atualizada após a criação do cluster para registrar ou cancelar o registro do cluster, embora não recomendemos mover clusters com cargas de trabalho ativas de uma frota para outra.

Saiba mais sobre como adicionar clusters a frotas em Criar frotas para simplificar o gerenciamento de vários clusters.

Configurações de rede

Ao criar um cluster do GKE, é possível especificar várias configurações de rede, incluindo a rede em que o cluster está, o modo de roteamento de rede e se os nós do cluster precisam ser acessíveis de redes públicas.

Se você não for um administrador de rede, consulte os especialistas em rede da sua organização antes de criar um cluster pronto para produção, já que muitas dessas opções não podem ser alteradas após a criação do cluster. Se você for um administrador de rede, poderá saber mais sobre as redes do GKE em Sobre as redes do GKE, com práticas recomendadas para opções de rede em Práticas recomendadas para redes do GKE. Esta seção descreve apenas um subconjunto das nossas possíveis opções de rede.

Rede e sub-rede

A rede de nuvem privada virtual (VPC) em que um cluster está localizado determina com quais outros recursos do Compute Engine ele pode se comunicar. Por padrão, os clusters do GKE são criados na rede padrão do seu projeto, mas você pode escolher outra rede, caso você ou seu administrador tenha criado uma. Se disponível, você pode especificar que o cluster pertence a uma sub-rede VPC específica. Caso contrário, a sub-rede padrão será usada. Também é possível especificar um intervalo de endereços IP específico nessa sub-rede para seus pods e serviços.

Não é possível atualizar essas configurações após a criação do cluster.

Opções de isolamento de rede

É possível personalizar o isolamento de rede no cluster considerando os seguintes aspectos:

  • Acesso ao plano de controle: por padrão, o endpoint interno e o endpoint externo do plano de controle estão ativados, e o endpoint baseado em DNS está desativado. Você pode:

    • Desative o endpoint externo e interno e use apenas o endpoint DNS.
    • Desative o endpoint externo apenas para impedir o acesso a clientes externos.
    • Ative as redes autorizadas para controlar quais endereços IP alcançam os endpoints do plano de controle.

  • Configuração de rede de cluster: é possível ativar nós particulares no cluster para isolar completamente as cargas de trabalho das redes públicas. É possível ativar nós particulares para clusters inteiros ou no nível do pool de nós (para o Standard) ou da carga de trabalho (para o Autopilot). Ativar nós privados no nível do pool de nós ou da carga de trabalho substitui qualquer configuração de nó no nível do cluster.

Essas configurações podem ser alteradas após a criação do cluster.

Para mais informações sobre o isolamento de rede, consulte Sobre a personalização do isolamento de rede e Personalizar o isolamento de rede.

Prática recomendada:

Usar o Cloud NAT para fornecer aos pods do GKE acesso a recursos com endereços IP públicos. O Cloud NAT melhora a postura de segurança geral do cluster porque os pods não são expostos diretamente à Internet, mas ainda podem acessar recursos voltados à Internet.

Clusters nativos de VPC e baseados em rotas

No GKE, os clusters podem ser diferenciados de acordo com a maneira como direcionam o tráfego de um pod para outro. Um cluster que usa endereços IP de alias é chamado de cluster nativo de VPC. Um cluster que usa o Google Cloud Routes é chamado de cluster baseado em rotas.

Por padrão, todos os novos clusters do GKE usam o roteamento nativo da VPC, que é a opção recomendada. É possível mudar essa configuração na criação do cluster para criar um cluster baseado em rotas somente no modo padrão. Essa configuração não pode ser atualizada após a criação do cluster.

Saiba mais sobre os clusters nativos de VPC e os benefícios deles, incluindo os requisitos especiais, em Clusters nativos de VPC.

Prática recomendada:

Use o modo de rede nativo de VPC para seus clusters. Esse é o padrão para clusters do Autopilot.

Versões e upgrades

Com os canais de lançamento, o GKE escolhe versões de software para um cluster com o equilíbrio escolhido entre disponibilidade e estabilidade de recursos. Ao criar um cluster, você pode escolher o canal de lançamento que quiser. Os novos clusters (do Autopilot e padrão) são inscritos no canal de lançamento regular por padrão, mas você pode escolher uma versão específica durante a criação do cluster, se necessário.

Os clusters do Autopilot sempre usam canais de lançamento. Os clusters padrão usam canais de lançamento por padrão, mas você pode optar por não registrar seu cluster em um canal de lançamento. No entanto, não recomendamos isso, porque essa configuração limita o acesso aos recursos do cluster.

O GKE faz upgrade automático de todos os clusters ao longo do tempo, independentemente da inscrição no canal de lançamento. O GKE faz o upgrade automático do plano de controle do cluster e dos nós à medida que novas versões ficam disponíveis nesse canal de lançamento. É possível controlar o tempo e o escopo dos upgrades com janelas de manutenção e exclusões.

Você pode mudar o canal de lançamento de um cluster a qualquer momento.

Para informações sobre os próximos upgrades automáticos, consulte as notas da versão do GKE.

Prática recomendada:

Escolha um canal de lançamento para que o GKE selecione versões para seu cluster com o equilíbrio certo entre disponibilidade e estabilidade de recursos. Use janelas de manutenção e exclusões para controlar o tempo e o escopo dos upgrades automáticos.

Recursos Alfa (somente clusters padrão)

Os novos recursos no Kubernetes estão listados como Alfa, Beta ou Estável, dependendo do status deles em desenvolvimento. Na maioria dos casos, os recursos do Kubernetes listados como Beta ou Estável estão incluídos nos clusters do GKE.

Se você quiser testar recursos muito novos que ainda não estão prontos para produção, os recursos Alfa estão disponíveis em clusters Alfa especiais do GKE. Um cluster alfa tem todas as APIs Alfa do Kubernetes (às vezes chamadas de portões de recursos) ativadas. Use clusters Alfa para testar e validar os recursos do Kubernetes. Os clusters Alfa não são compatíveis com cargas de trabalho de produção, não podem ser atualizados nem adicionados a canais de lançamento e expiram em 30 dias.

Os recursos Alfa não estão disponíveis para clusters do Autopilot.

Para criar um cluster Alfa, consulte Como criar um cluster Alfa.

Configurações de segurança

O GKE tem várias configurações de segurança que podem ser especificadas na criação do cluster. Isso inclui configurações de criptografia, recursos de segurança, como a Autorização binária, a conta de serviço que você quer usar para os nós do cluster (discutida em mais detalhes na próxima seção) e se o cluster usa a Federação de identidade da carga de trabalho para o GKE.

Assim como em outras configurações, consulte colegas especialistas, neste caso, os especialistas em segurança da sua organização, antes de criar um cluster pronto para produção. Saiba mais sobre a segurança do GKE na Visão geral da segurança e em Aumentar a segurança do cluster.

Conta de serviço para nós

O GKE usa contas de serviço do IAM anexadas aos seus nós para executar tarefas do sistema, como geração de registros e monitoramento. No mínimo, essas contas de serviço de nó precisam ter o papel de conta de serviço de nó padrão do Kubernetes Engine (roles/container.defaultNodeServiceAccount) no projeto. Por padrão, o GKE usa a conta de serviço padrão do Compute Engine, que é criada automaticamente no projeto, como a conta de serviço do nó.

Se a sua organização aplicar a restrição da política da organização iam.automaticIamGrantsForDefaultServiceAccounts, a conta de serviço padrão do Compute Engine no seu projeto pode não receber automaticamente as permissões necessárias para o GKE.

Se você usar a conta de serviço padrão do Compute Engine para outras funções no seu projeto ou organização, ela poderá ter mais permissões do que o necessário para o GKE, o que pode expor você a riscos de segurança.

Não é possível mudar a conta de serviço para clusters do modo Autopilot ou para pools de nós do modo padrão após a criação.

Configurações do pool de nós (somente clusters padrão)

Como você sabe, de acordo com a Visão geral da administração de clusters e os modos de operação do GKE, se você usar o Autopilot para seus clusters, não precisará se preocupar com a configuração de nós, porque o GKE configura os nós para você. Os nós do cluster do Autopilot são totalmente gerenciados pelo GKE e usam o mesmo sistema operacional de nó (SO).

Se você optar por criar um cluster padrão, poderá especificar várias opções de nó, incluindo:

  • O nome, o número, o tamanho e o local dos pools de nós que você quer usar. Os pools de nós são grupos de nós no cluster que compartilham uma configuração comum.
  • O SO do nó que você quer usar para novos nós.
  • Se você quer usar VMs do Spot temporárias para nós.
  • O tipo de máquina do Compute Engine que você quer usar para os nós.
  • A conta de serviço que você quer usar para os nós, conforme descrito nas Configurações de segurança.

Algumas das configurações do pool de nós de um cluster podem ser alteradas após a criação, mas todos os clusters padrão exigem pelo menos um pool de nós. Se você não especificar um número de nós e um tipo de máquina ao criar um cluster padrão, o pool de nós padrão vai consistir em três nós em cada uma das zonas do cluster, com a imagem de nó padrão cos_containerd e um tipo de máquina de uso geral.

Saiba mais sobre a configuração pool de nós em Sobre os pools de nós e Adicionar e gerenciar pools de nós.

Referência de configuração

Encontre uma lista completa de opções de configuração possíveis nos seguintes guias de referência:

A seguir