Tipos de clusters

Nesta página, você vê os principais tipos de clusters que podem ser criados no Google Kubernetes Engine. Como regra, as opções abordadas nesta página não podem ser alteradas depois que um cluster é criado. Essas opções afetam a disponibilidade do cluster, a estabilidade da versão, se o cluster é nativo da VPC ou baseado em rotas e o isolamento das cargas de trabalho.

Opções de disponibilidade de cluster

Com o GKE, é possível criar um cluster ajustado aos requisitos de disponibilidade da sua carga de trabalho e orçamento.

Clusters de zona única

Um cluster de zona única tem um plano de controle (mestre) em execução em uma zona. Esse plano de controle gerencia as cargas de trabalho nos nós em execução na mesma zona.

É possível criar um cluster de zona única.

Clusters com várias zonas

Um cluster em várias zonas tem uma réplica do plano de controle que funciona em uma 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 funciona, as cargas de trabalho ainda são executadas. No entanto, não é possível configurar o cluster, os nós e as cargas de trabalho dele até que o plano de controle esteja disponível. Os clusters em várias zonas equilibram a disponibilidade e o custo de cargas de trabalho consistentes. Se você quer manter a disponibilidade, e o número de nós e pools de nós são alterados com frequência, use um cluster regional.

É possível criar um cluster com várias zonas.

Clusters regionais

Um cluster regional tem várias réplicas do plano de controle em execução em muitas zonas de uma determinada região. Os nós também funcionam em cada zona em que uma réplica do plano de controle é executada. Como um cluster regional replica o plano de controle e os nós, ele consome mais recursos do Compute Engine do que um cluster similar de zona única ou com várias delas.

É possível criar um cluster regional.

Opções da versão do cluster

Ao criar um cluster, escolha a versão específica do Kubernetes ou determine a combinação geral de estabilidade e recursos dele.

Seja qual for a forma como você gerencia a versão do cluster, é recomendada a ativação do upgrade automático do cluster e dos nós.

Canal de lançamento

Se você sabe o nível de estabilidade necessário em um determinado cluster, basta inscrevê-lo em um canal de lançamento. O Google faz automaticamente o upgrade do cluster e dos respectivos nós quando uma atualização fica disponível nesse canal. O canal rápido recebe várias atualizações por mês, enquanto o estável recebe apenas algumas por ano.

É possível inscrever um cluster em um canal de lançamento.

Versão padrão

Se você não usar um canal de lançamento ou escolher uma versão do cluster, a versão padrão atual será utilizada. Ela é selecionada com base na estabilidade e no desempenho real e é alterada regularmente. As alterações na versão padrão são anunciadas em uma nota da versão.

Versão específica

Se você sabe que precisa usar uma versão específica compatível do Kubernetes em uma determinada carga de trabalho, basta determiná-la ao criar o cluster.

Se você não precisa controlar a versão de patch específica usada, inscreva o cluster em um canal de lançamento em vez de gerenciar diretamente a versão dele.

É possível criar um cluster com uma versão específica.

Cluster Alfa

Um cluster Alfa tem todas as APIs Alfa do Kubernetes ativadas. Às vezes, elas são chamadas de portões de recursos. Use os clusters Alfa para testar e validar os recursos do Kubernetes antecipadamente. Os clusters Alfa não são compatíveis com cargas de trabalho de produção, não podem ser atualizados e expiram em até 30 dias.

É possível criar um cluster alfa.

Clusters nativos de VPC e baseados em rotas

No Google Kubernetes Engine, os clusters são diferenciados de acordo com a forma como encaminham o tráfego de um pod para outro. Um cluster que usa IPs de alias é chamado de cluster nativo de VPC. Já um que usa o Google Cloud Routes é chamado de cluster baseado em rotas.

Nativo de VPC é o modo de rede recomendado para novos clusters.

O modo de rede padrão do cluster depende da maneira como o cluster é criado. Veja os detalhes neste gráfico.

Opções de isolamento de rede

Por padrão, é possível configurar o acesso de redes públicas às cargas de trabalho do seu cluster. Os trajetos não são criados automaticamente. Os clusters privados atribuem endereços IP internos RFC 1918 aos pods e nós, e as cargas de trabalho são completamente isoladas das redes públicas.

É possível criar um cluster particular.

Segurança da cadeia de suprimentos da carga de trabalho

A autorização binária fornece à segurança da cadeia de suprimentos do software as cargas de trabalho do GKE. Essa autorização funciona com imagens que você implanta no GKE a partir do Container Registry ou de outro registro de imagens de contêiner. Com a autorização binária, você garante que os processos internos que protegem a qualidade e a integridade do software sejam concluídos com sucesso antes que um aplicativo seja implantado no ambiente de produção.

Para mais informações, consulte Como criar um cluster com a autorização binária ativada na documentação relacionada.