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 consoleTrusted Cloud , a Google Cloud CLI ou o Terraform. Essas opções permitem personalizar uma ampla variedade de atributos e comportamentos do cluster para atender às suas necessidades, desde se o cluster está acessível em 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 opções 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 ser prejudicial.

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 Trusted Cloud by S3NS .

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 Trusted Cloud by S3NS , consulte Funções e tarefas de usuário comuns do GKE Enterprise.

Antes de ler esta página, você precisa conhecer o seguinte, além dos 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.

  • Standard: 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 suas 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 totalmente gerenciados e configurados pelo Trusted Cloud by S3NS do que os clusters padrão, eles têm menos opções de configuração disponíveis.

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

  • Nome e outros metadados: cada cluster precisa ter um nome de identificação exclusivo no projeto. Você também pode adicionar uma descrição e rótulos ao 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 Trusted Cloud by S3NS.
  • Assinatura da frota: escolha se você quer que o cluster seja membro de uma frota.
  • Rede: opções de rede, incluindo a rede de nuvem privada virtual (VPC) e a sub-rede em que o cluster está, e se você quer que o cluster seja acessível em redes públicas.
  • Gerenciamento de versões e upgrades: use canais de lançamento para escolher o equilíbrio preferido entre novos recursos e estabilidade ao fazer upgrade do software do cluster. Além disso, defina janelas e exclusões de manutenção para escolher quando os upgrades podem ou não ocorrer.
  • Segurança: inclui se o cluster usa a federação de identidade da carga de trabalho para GKE e a conta de serviço usada pelos nós do cluster para autenticar noTrusted Cloud by S3NS.
  • Recursos do cluster: ative e configure outros recursos do GKE e do Trusted Cloud by S3NS para esse cluster, incluindo backups e observabilidade. O modo Padrão também permite criar clusters Alfa de curta duração para testar 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 e dimensionamento.

As seções a seguir analisam algumas dessas categorias em mais detalhes, principalmente aquelas com opções em que não é possível mudar a configuração depois de criar o cluster. Para 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 principais para clusters do Autopilot e Standard:

Opções de cluster Modo
Piloto automático Standard
Tipo de disponibilidade Regional Regional ou Por zona
Canal de lançamento Rapid, Regular 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

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 Trusted Cloud by S3NS região 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 estas configurações após a criação do cluster: um cluster zonal não pode se tornar um cluster regional, e um cluster regional não pode se tornar um cluster 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 de um cluster zonal. Para mais informações sobre considerações específicas de cada região, consulte Geografia e regiões.

Clusters regionais

Um cluster regional tem várias réplicas do plano de controle, em execução em várias zonas dentro da Trusted Cloud by S3NS região especificada. É sempre necessário especificar uma região ao criar um cluster do Autopilot ou outro cluster regional.

Somente para clusters regionais Standard, também é possível escolher em quais zonas os nós do cluster serã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 regional 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 depois da criação dele.

Clusters zonais

Os clusters de zona têm somente um plano de controle em uma única zona. As cargas de trabalho ainda são executadas durante um upgrade do cluster ou uma interrupção da zona em que o plano de controle é executado. 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. 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.

Localização e distribuição dos nós

Se você usa clusters regionais ou zonais, é possível determinar com precisão a localização e a distribuição dos nós em todas as zonas. É possível configurar as zonas padrão para todos os futuros pools de nós, além de atribuir ou mudar as zonas específicas para nós em pools de nós atuais.

Clusters de zona única

Um cluster de zona única, que pode ser regional ou zonal, executa cargas de trabalho em nós localizados em apenas uma zona. Se essa zona sofrer uma interrupção, todas as cargas de trabalho ficarão indisponíveis.

Os clusters zonais são criados por padrão como clusters de zona única, mas é possível atualizar essa configuração para clusters multizonais.

Clusters com várias zonas

Um cluster de várias zonas, que pode ser regional ou zonal, aumenta a disponibilidade da carga de trabalho distribuindo nós em várias zonas dentro de uma única região. Isso permite executar cargas de trabalho em várias zonas de uma região. Se você executar uma carga de trabalho em várias zonas e ocorrer uma interrupção temporária zonal, ela será interrompida nessa zona, mas vai permanecer disponível em outras.

A distribuição de nós do GKE em várias zonas pode gerar cobranças de saída de rede entre zonas quando os nós precisam se comunicar com peers localizados em uma zona diferente dentro da região.

Os clusters regionais são criados por padrão como clusters multizonais, mas é possível atualizar essa configuração para clusters de zona única.

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íveis 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 se baseiam no gerenciamento de frotas do GKE.

Para clusters do GKE no Trusted Cloud by S3NS, você seleciona se 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 com ele. Se você não especificar um nível de cluster, o cluster usará o nível padrão por padrão, com algumas exceções.

Ao selecionar o nível do cluster, entenda o seguinte:

  • Muitos recursos do GKE Enterprise exigem a associação à frota para funcionar. É possível registrar um cluster em uma frota durante a criação dele ou depois que ele for criado. Se você quiser usar recursos do GKE Enterprise com frota em um cluster, recomendamos registrar o cluster em uma frota durante a criação dele. Assim, o cluster herda as configurações no nível da frota para recursos empresariais. Saiba mais em Assinatura da frota.
  • Só é possível ativar o nível empresarial 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 sua organização usa vários clusters, simplifique o gerenciamento de vários clusters adicionando-os a uma frota: um agrupamento lógico de clusters do Kubernetes. Criar uma frota ajuda sua organização a melhorar o gerenciamento de clusters individuais para grupos inteiros de clusters e permite usar recursos ativados para frotas, como Ingress de vários clusters, Config Sync e 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 de cluster. Isso ocorre porque esses clusters "nascidos na frota" são criados com as configurações padrão no nível da frota escolhidas 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 você quer que os nós do cluster sejam acessíveis em 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 depois da criação do cluster. Se você for um administrador de rede, saiba muito mais sobre a rede do GKE em Sobre a rede do GKE, com práticas recomendadas para opções de rede em Práticas recomendadas para rede do GKE. Esta seção descreve apenas um subconjunto das nossas opções de rede possíveis.

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 projeto. No entanto, é possível escolher outra rede se você ou seu administrador tiverem criado uma. Se disponível, você pode especificar que quer que seu cluster pertença a uma sub-rede VPC específica. Caso contrário, a sub-rede padrão será usada. Também é possível especificar que você quer usar um intervalo de endereços IP específico nessa sub-rede para seus pods e serviços.

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

Opções de isolamento de rede

É possível personalizar o isolamento de rede no cluster considerando os dois aspectos a seguir:

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

    • Desative os endpoints externos e internos e use apenas o endpoint de 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 do 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 Standard) ou da carga de trabalho (para Autopilot). Ativar nós particulares 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 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 Trusted Cloud by S3NS rotas é 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 Standard. 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 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. Por padrão, novos clusters (Autopilot e Standard) são inscritos no canal de lançamento Regular, mas é possível 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 essa opção 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.

É possível 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 Standard)

Os novos recursos no Kubernetes estão listados como Alfa, Beta ou Estável, dependendo do status deles no 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 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 com 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 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 Conta de serviço de nó padrão do Kubernetes Engine (roles/container.defaultNodeServiceAccount) no seu projeto. Por padrão, o GKE usa a conta de serviço padrão do Compute Engine, que é criada automaticamente no seu projeto, como a conta de serviço do nó.

Se a 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 projeto talvez não receba 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 projeto ou na organização, ela poderá ter mais permissões do que o GKE precisa, 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 Standard após a criação.

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

Como você sabe pela Visão geral da administração de clusters e pelos Modos de operação do GKE, se você usa o Autopilot para seus clusters, não precisa 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 (SO) do nó.

Se você optar por criar um cluster Standard, poderá especificar várias opções de nós ao criar um cluster, incluindo:

  • O nome, o número, o tamanho e a localização 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 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 nós, conforme descrito em Configurações de segurança.

Algumas configurações do pool de nós de um cluster podem ser alteradas após a criação dele, mas todos os clusters Standard 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 dele vai consistir em três nós em cada uma das zonas do cluster, com a imagem do nó padrão cos_containerd e um tipo de máquina de uso geral.

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

Referência de configuração

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

A seguir