Acerca das opções de configuração de clusters

Esta página explica as principais opções de configuração do cluster que pode fazer quando cria um cluster no Google Kubernetes Engine (GKE), quer esteja a usar a Google Cloud consola, a CLI Google Cloud ou o Terraform. Estas opções permitem-lhe personalizar uma vasta gama de atributos e comportamentos de clusters para satisfazer as suas necessidades, desde se o cluster é acessível a partir de redes públicas até à forma como quer que receba atualizações de versões.

Muitas das opções abordadas neste guia não podem ser alteradas após a criação de um cluster. Estas incluem escolhas que afetam a disponibilidade e a rede de um cluster. Se precisar de alterar estas opções, tem de criar um novo cluster e, em seguida, migrar o tráfego para o mesmo, o que pode ser disruptivo.

Prática recomendada:

Uma vez que muitas opções de configuração do cluster não podem ser alteradas após a criação do cluster, planeie e crie a configuração do cluster com os administradores e os arquitetos da sua organização, os arquitetos da nuvem, os administradores de rede ou qualquer outra equipa responsável por definir, implementar e manter a arquitetura do GKE e doGoogle Cloud .

Esta página destina-se a administradores e arquitetos que definem soluções de TI e a arquitetura de sistemas de acordo com a estratégia da empresa. Para saber mais sobre as funções comuns e exemplos de tarefas a que fazemos referência no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Google Cloud

Antes de ler esta página, deve estar familiarizado com o seguinte, bem como com os conceitos básicos do Kubernetes:

Nível de gestão do cluster

Antes de discutir as opções de cluster, é importante compreender o nível de flexibilidade, responsabilidade e controlo que precisa para o seu cluster. O nível de controlo que precisa determina o modo de funcionamento a usar no GKE e as opções de configuração do cluster que tem de fazer.

Quando cria um cluster no GKE, fá-lo através de um dos seguintes modos de funcionamento:

  • Autopilot (recomendado): oferece uma configuração de cluster totalmente aprovisionada e gerida. Os clusters do Autopilot estão pré-configurados com uma configuração de cluster otimizada que está 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 com o modo padrão, determina a configuração necessária para as suas cargas de trabalho de produção.

Para mais informações sobre estes modos e para saber mais sobre o Autopilot, consulte os modos de funcionamento do GKE e a vista geral do Autopilot.

Pode encontrar uma comparação detalhada lado a lado dos dois modos em Compare o GKE Standard e o Autopilot.

Opções de configuração do cluster

Depois de escolher um modo de funcionamento, selecione a configuração necessária para o seu cluster. Uma vez que os clusters do Autopilot são mais totalmente geridos e configurados pelo Google Kubernetes Engine do que os clusters padrão, têm menos opções de configuração disponíveis. Google Cloud

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

  • Nome e outros metadados: cada cluster tem de ter um nome identificador exclusivo no respetivo projeto. Também pode adicionar opcionalmente uma descrição e etiquetas do cluster.
  • Disponibilidade e escalabilidade: especifique onde quer que o plano de controlo e os nós do cluster sejam executados e se quer várias réplicas do plano de controlo. Todos os clusters do Autopilot são regionais, o que significa que têm vários planos de controlo em várias zonas de computação numa Google Cloud região.
  • Associação a uma frota: escolha se quer que o cluster seja membro de uma frota.
  • Redes: opções de redes, incluindo a rede de nuvem virtual privada (VPC) e a sub-rede em que o cluster se encontra, e se quer que o cluster seja acessível a partir de redes públicas.
  • Gestão de versões e atualizações: use canais de lançamento para escolher o seu equilíbrio preferencial entre novas funcionalidades e estabilidade ao atualizar o software deste cluster, e defina janelas de manutenção e exclusões para escolher quando as atualizações podem e não podem ocorrer.
  • Segurança: isto inclui se o cluster usa a Workload Identity Federation para o GKE e a conta de serviço usada pelos nós do cluster para autenticar noGoogle Cloud.
  • Funcionalidades do cluster: ative e configure funcionalidades adicionais do GKE eGoogle Cloud para este cluster, incluindo cópias de segurança e observabilidade. O modo padrão também lhe permite criar clusters alfa de curta duração para experimentar funcionalidades alfa do Kubernetes.

Além destas, 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, o sistema operativo dos nós e o dimensionamento dos nós.

As secções seguintes analisam algumas destas categorias mais detalhadamente, especialmente as que têm opções em que não pode alterar a definição depois de criar o cluster. Para ver uma lista completa das opções de configuração, consulte a Referência de configuração.

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

Escolhas de clusters Modo
Piloto automático Standard
Tipo de disponibilidade Regional Regional ou Zonal
Canal de lançamento Rápido, Normal ou Estável Qualquer canal
Versões de cluster Predefinição ou outra versão disponível Predefinição ou outra versão disponível
Encaminhamento de rede Nativo de VPC Nativo de VPC ou baseado em rotas
Isolamento de rede Personalizável Personalizável
Funcionalidades do Kubernetes Produção Produção ou Alfa

Disponibilidade do cluster

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

Para ajudar a escolher o tipo de cluster a criar no modo padrão, consulte o artigo Escolher um plano de controlo regional ou zonal.

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

Prática recomendada:

Para cargas de trabalho de produção, use clusters regionais porque, 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 controlo regional e pools de nós zonais tem os mesmos custos que um cluster zonal. Para mais informações sobre considerações específicas da região, consulte o artigo Geografia e regiões.

Clusters regionais

Um cluster regional tem várias réplicas do plano de controlo, em execução em várias zonas na sua Google Cloud região especificada. Tem sempre de especificar uma região quando cria um cluster do Autopilot ou outro cluster regional.

Apenas para clusters padrão regionais, também pode escolher em que zonas os nós do cluster são executados. Os nós num cluster regional podem ser executados em várias zonas ou numa única zona, consoante as localizações dos nós configuradas. Por predefinição, o GKE replica cada conjunto de nós em três zonas da região do plano de controlo. Quando cria um cluster padrão regional ou quando adiciona um novo conjunto de nós, pode alterar a configuração predefinida especificando as zonas nas quais os nós do cluster são executados. Todas as zonas têm de estar na mesma região que o plano de controlo.

Use clusters regionais para executar as suas cargas de trabalho de produção, uma vez que oferecem maior disponibilidade do que os clusters zonais.

Não pode alterar a região de um cluster regional após a criação do cluster.

Clusters zonais

Os clusters zonais têm um único plano de controlo numa única zona. As cargas de trabalho continuam a ser executadas durante uma atualização do cluster ou uma indisponibilidade da zona onde o plano de controlo é executado. No entanto, não é possível configurar o cluster, os respetivos nós e as respetivas cargas de trabalho até que o plano de controlo esteja disponível. Consoante os requisitos de disponibilidade da carga de trabalho, pode optar por distribuir os nós do cluster zonal numa única zona ou em várias zonas.

Para criar um cluster zonal, consulte o artigo Criar um cluster zonal.

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

Quer use clusters regionais ou zonais, pode determinar com precisão a localização e a distribuição dos seus nós em várias zonas. Pode configurar as zonas predefinidas para todos os futuros conjuntos de nós, bem como atribuir ou alterar as zonas específicas para nós em conjuntos de nós existentes.

Clusters de zona única

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

Os clusters zonais são criados por predefinição como clusters de zona única, mas pode atualizar esta configuração para clusters multizonais.

Clusters multizonais

Um cluster multizonal, que pode ser um cluster regional ou zonal, melhora a disponibilidade da carga de trabalho distribuindo nós por várias zonas numa única região. Isto permite-lhe executar cargas de trabalho em várias zonas numa região. Se executar uma carga de trabalho em várias zonas e ocorrer uma indisponibilidade zonal, a carga de trabalho é interrompida nessa zona, mas permanece disponível noutras zonas.

A distribuição de nós do GKE em várias zonas pode incorrer em custos de saída da rede entre zonas quando os nós precisam de comunicar com pares localizados numa zona diferente na região.

Os clusters regionais são criados por predefinição como clusters multizonais, mas pode atualizar esta configuração para clusters de zona única.

Subscrição de frota

Se a sua organização usar vários clusters, pode simplificar a gestão 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 a sua organização a melhorar a gestão de clusters individuais para grupos completos de clusters e permite-lhe usar funcionalidades ativadas para frotas, como o Multi Cluster Ingress, o Config Sync e o Policy Controller.

Embora possa adicionar clusters a uma frota em qualquer altura, se tiver ativado o GKE Enterprise, recomendamos vivamente que registe novos clusters de nível empresarial numa frota durante a criação de clusters. Isto deve-se ao facto de estes clusters "nascidos na frota" serem criados com as predefinições ao nível da frota escolhidas por si para várias funcionalidades empresariais e com as métricas e os registos recomendados já ativados. Pode saber mais sobre estes aspetos nos seguintes guias:

Esta definição pode ser atualizada após a criação do cluster para registar ou anular o registo do cluster, embora não recomendemos mover clusters com cargas de trabalho em direto de uma frota para outra.

Pode saber muito mais sobre como adicionar clusters a frotas em Crie frotas para simplificar a gestão de vários clusters.

Definições de rede

Quando cria um cluster do GKE, pode especificar várias definições de rede, incluindo a rede em que o cluster se encontra, o modo de encaminhamento de rede e se quer que os nós do cluster sejam acessíveis a partir de redes públicas.

Se não for administrador de rede, deve consultar os especialistas de rede da sua organização antes de criar um cluster pronto para produção, uma vez que muitas destas opções não podem ser alteradas após a criação do cluster. Se for administrador de rede, pode saber muito mais sobre as redes do GKE em Acerca das redes do GKE, com as práticas recomendadas para as opções de rede em Práticas recomendadas para as redes do GKE. Esta secção descreve apenas um subconjunto das nossas possíveis opções de rede.

Rede e sub-rede

A rede da nuvem privada virtual (VPC) em que um cluster se encontra determina com que outros recursos do Compute Engine consegue comunicar. Por predefinição, os clusters do GKE são criados na rede predefinida do seu projeto, embora possa escolher outra rede se tiver sido criada por si ou pelo seu administrador. Se estiver disponível, pode especificar que quer que o seu cluster pertença a uma sub-rede da VPC específica. Caso contrário, é usada a sub-rede predefinida. Também pode especificar opcionalmente que quer usar um intervalo de endereços IP específico nessa sub-rede para os seus pods e serviços.

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

Opções de isolamento de rede

Pode personalizar o isolamento da rede no cluster tendo em conta os seguintes dois aspetos:

  • Acesso ao plano de controlo: por predefinição, o ponto final interno e o ponto final externo do plano de controlo estão ativados, e o ponto final baseado em DNS está desativado. Pode optar por:

    • Desative o ponto final externo e interno e use apenas o ponto final DNS.
    • Desative o ponto final externo apenas para impedir o acesso a clientes externos.
    • Ative as redes autorizadas para controlar os endereços IP que alcançam os pontos finais do plano de controlo.

  • Configuração de rede do cluster: pode optar por ativar nós privados no cluster para isolar completamente as cargas de trabalho das redes públicas. Pode ativar nós privados para clusters inteiros ou ao nível do conjunto de nós (para o modo Standard) ou da carga de trabalho (para o modo Autopilot). A ativação de nós privados ao nível do node pool ou da carga de trabalho substitui qualquer configuração de nós ao nível do cluster.

Pode alterar estas definições após a criação do cluster.

Para mais informações sobre o isolamento da rede, consulte os artigos Acerca da personalização do isolamento da rede e Personalize o isolamento da rede.

Prática recomendada:

Use o Cloud NAT para fornecer aos pods do GKE acesso a recursos com endereços IP públicos. O NAT na nuvem melhora a postura de segurança geral do cluster porque os pods não estão diretamente expostos à Internet, mas continuam a poder aceder a recursos virados para a Internet.

Clusters nativos de VPC e baseados em rotas

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

Por predefinição, todos os novos clusters do GKE usam o encaminhamento nativo da VPC, que é a nossa opção recomendada. Pode alterar esta definição na criação do cluster para criar um cluster baseado em rotas apenas no modo padrão. Não é possível atualizar esta definição após a criação do cluster.

Pode saber mais acerca dos clusters nativos de VPC e das respetivas vantagens, incluindo quaisquer requisitos especiais que tenham, em Clusters nativos de VPC.

Prática recomendada:

Use o modo de rede nativo de VPC para os seus clusters. Esta é a predefinição para clusters do Autopilot.

Versões e atualizações

Com os canais de lançamento, o GKE escolhe versões de software para um cluster com o seu equilíbrio escolhido entre a disponibilidade de funcionalidades e a estabilidade. Quando cria um cluster, pode escolher o canal de lançamento que quer. Os novos clusters (tanto no modo automático como no modo padrão) são inscritos no canal de lançamento normal por predefinição, embora possa escolher uma versão específica durante a criação do cluster, se necessário.

Os clusters do Autopilot usam sempre canais de lançamento. Os clusters padrão usam canais de lançamento por predefinição. No entanto, pode optar por não inscrever o cluster num canal de lançamento (embora não o recomendemos, uma vez que esta definição lhe dá um acesso mais limitado às funcionalidades do cluster).

O GKE atualiza automaticamente todos os clusters ao longo do tempo, independentemente da inscrição no canal de lançamento. O GKE atualiza automaticamente o painel de controlo do cluster e os respetivos nós à medida que novas versões ficam disponíveis nesse canal de lançamento. Pode controlar o momento e o âmbito das atualizações com períodos de manutenção e exclusões.

Pode alterar o canal de lançamento de um cluster em qualquer altura.

Para obter informações sobre as atualizações automáticas futuras, consulte as notas de lançamento do GKE.

Prática recomendada:

Escolha um canal de lançamento do GKE para selecionar versões para o seu cluster com o equilíbrio escolhido entre a disponibilidade de funcionalidades e a estabilidade. Use janelas de manutenção e exclusões para controlar o momento e o âmbito das atualizações automáticas.

Funcionalidades alfa (apenas para clusters padrão)

As novas funcionalidades no Kubernetes são apresentadas como alfa, beta ou estáveis, consoante o respetivo estado de desenvolvimento. Na maioria dos casos, as funcionalidades do Kubernetes indicadas como beta ou estáveis estão incluídas nos clusters do GKE.

Se quiser experimentar funcionalidades muito recentes que não estão prontas para produção, as funcionalidades alfa estão disponíveis em clusters alfa especiais do GKE. Um cluster alfa tem todas as APIs alfa do Kubernetes (por vezes, denominadas feature gates) ativadas. Pode usar clusters alfa para testes e validação antecipados das funcionalidades do Kubernetes. Os clusters alfa não são suportados para cargas de trabalho de produção, não podem ser atualizados nem adicionados a canais de lançamento e expiram no prazo de 30 dias.

As funcionalidades alfa não estão disponíveis para clusters do Autopilot.

Para criar um cluster alfa, consulte o artigo Criar um cluster alfa.

Definições de segurança

O GKE tem várias definições de segurança que pode especificar na criação do cluster. Estas incluem definições de encriptação, funcionalidades de segurança, como a autorização binária, a conta de serviço que quer usar para os nós do cluster (abordada mais detalhadamente na secção seguinte) e se o cluster usa a Workload Identity Federation para o GKE.

Tal como acontece com outras definições, deve consultar colegas especialistas, neste caso, os especialistas em segurança da sua organização, antes de criar um cluster pronto para produção. Pode saber mais sobre a segurança do GKE na nossa vista geral da segurança e em Reforce a segurança do cluster.

Conta de serviço para nós

O GKE usa contas de serviço da IAM anexadas aos seus nós para executar tarefas do sistema, como registo e monitorização. No mínimo, estas contas de serviço de nós têm de ter a função Conta de serviço de nós predefinida do Kubernetes Engine (roles/container.defaultNodeServiceAccount) no seu projeto. Por predefinição, o GKE usa a conta de serviço predefinida do Compute Engine, que é criada automaticamente no seu 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 do Compute Engine predefinida no seu projeto pode não receber automaticamente as autorizações necessárias para o GKE.

Se usar a conta de serviço predefinida do Compute Engine para outras funções no seu projeto ou organização, a conta de serviço pode ter mais autorizações do que o GKE precisa, o que pode expô-lo a riscos de segurança.

Não pode alterar a conta de serviço para clusters do modo Autopilot nem para conjuntos de nós do modo Standard após a criação.

Definições do node pool (apenas clusters padrão)

Como sabe a partir da vista geral da administração de clusters e dos modos de funcionamento do GKE, se usar o piloto automático para os seus clusters, não tem de se preocupar com a configuração dos nós, uma vez que o GKE configura os nós por si. Todos os nós do cluster do Autopilot são totalmente geridos pelo GKE e usam o mesmo sistema operativo do nó (SO).

Se optar por criar um cluster padrão, pode 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 quer usar; os pools de nós são grupos de nós no seu cluster que partilham uma configuração comum.
  • O SO do nó que quer usar para novos nós.
  • Se quer usar VMs pontuais para nós.
  • O tipo de máquina do Compute Engine que quer usar para os nós.
  • A conta de serviço que quer usar para nós, conforme descrito nas definições de segurança.

Algumas das definições do conjunto de nós de um cluster podem ser alteradas após a criação do cluster, embora todos os clusters Standard exijam, pelo menos, um conjunto de nós. Se não especificar um número de nós e um tipo de máquina ao criar um cluster padrão, o respetivo node pool predefinido consiste em três nós em cada uma das zonas do cluster, com a imagem do nó cos_containerd predefinida e um tipo de máquina de uso geral.

Pode saber mais acerca da configuração de node pools em Acerca dos node pools e Adicione e faça a gestão de node pools.

Referência de configuração

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

O que se segue?