Arquitetura do cluster do GKE

Autopilot Standard

---

Nesta página, você verá a arquitetura de um cluster do Google Kubernetes Engine (GKE). Todas as cargas de trabalho conteinerizadas do Kubernetes são executadas em um cluster do GKE.

Esta página é para administradores, arquitetos e operadores que definem soluções de TI e arquitetura de sistemas. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud, consulte Tarefas e funções de usuário comuns do GKE Enterprise.

Um cluster do GKE consiste em um plano de controle e máquinas de worker chamadas nós. O plano de controle e os nós compõem o sistema de orquestração de clusters do Kubernetes. O Autopilot do GKE gerencia toda a infraestrutura subjacente de clusters, incluindo o plano de controle, os nós e todos os componentes do sistema. Se você usa o modo GKE Standard, o GKE gerencia o plano de controle e os componentes do sistema e você gerencia os nós. O diagrama a seguir mostra a arquitetura de um cluster do GKE:

Sobre o plano de controle

O plano de controle executa processos como o servidor da API Kubernetes, o programador e os controladores dos recursos principais. O GKE gerencia o ciclo de vida do plano de controle desde a criação até a exclusão do cluster. Isso inclui upgrades da versão do Kubernetes em execução no plano de controle, que o GKE realiza automaticamente. Se você preferir, também é possível fazer o upgrade manualmente, antes da programação automática.

O plano de controle e a API Kubernetes

O plano de controle é o endpoint unificado para o cluster. Você interage com o plano de controle por meio de chamadas da API Kubernetes. O plano de controle executa o processo do servidor da API Kubernetes (kube-apiserver) para lidar com solicitações de API. É possível fazer chamadas de API do Kubernetes das seguintes maneiras:

• Chamadas diretas: HTTP/gRPC
• Chamadas indiretas: clientes de linha de comando do Kubernetes, como kubectl, ou o console do Google Cloud.

O processo do servidor da API é o hub para todas as comunicações do cluster. Todos os componentes internos do cluster, como nós, processos do sistema e controladores de aplicativos, atuam como clientes do servidor da API.

As solicitações de API informam ao Kubernetes qual é o estado pretendido para os objetos no cluster. O Kubernetes tenta manter esse estado constantemente. O Kubernetes permite configurar objetos na API de maneira imperativa ou declarativa.

Para saber mais sobre o gerenciamento de objetos no Kubernetes, consulte as páginas a seguir:

• Noções básicas sobre objetos do Kubernetes
• Gerenciamento de objetos do Kubernetes

Plano de controle e interação do nó

O plano de controle decide o que é executado em todos os nós do cluster. O plano de controle programa cargas de trabalho e gerencia o ciclo de vida, o escalonamento e os upgrades delas. O plano de controle também gerencia recursos de rede e de armazenamento para essas cargas de trabalho. O plano de controle e os nós se comunicam usando as APIs do Kubernetes.

Interações do plano de controle com o Artifact Registry

Quando você cria ou atualiza um cluster, o GKE extrai imagens de contêiner para o software do sistema Kubernetes em execução no plano de controle e nos nós do pkg.dev Artifact Registry ou gcr.io Container Registry Uma falha temporária que afeta esses registros pode causar a falha das seguintes ações:

• Criação de novo cluster
• Upgrades de versão do cluster

As cargas de trabalho podem ter interrupções mesmo sem a intervenção do usuário, dependendo da natureza específica e da duração da interrupção.

Se a interrupção pkg.dev do Artifact Registry ou a gcr.io do Container Registry for regional, poderemos redirecionar as solicitações para uma zona ou região que não seja afetada pela interrupção.

Para verificar o status atual dos serviços do Google Cloud, acesse painel de status do Google Cloud.

Prática recomendada:

Implante em várias regiões para permitir a disponibilidade de aplicativos durante interrupções de região.

Atenção: o Container Registry foi descontinuado e está programado para ser desativado. As organizações que não usaram o Container Registry antes de 8 de janeiro de 2024 terão novos repositórios gcr.io hospedados no Artifact Registry por padrão. A partir de 15 de maio de 2024, os projetos do Google Cloud sem uso anterior do Container Registry só serão compatíveis com a hospedagem e o gerenciamento de imagens para o domínio gcr.io no Artifact Registry.

A desativação do Container Registry está programada para 18 de março de 2025. Para detalhes sobre a descontinuação, consulte Suspensão de uso do Container Registry.

Sobre os nós

Nós são as máquinas de worker que executam seus aplicativos conteinerizados e outras cargas de trabalho. As máquinas individuais são máquinas virtuais (VMs) do Compute Engine criadas pelo GKE. O plano de controle gerencia e recebe atualizações sobre o status informado de cada nó.

Um nó executa os serviços necessários para a compatibilidade dos contêineres que compõem as cargas de trabalho do cluster. Eles incluem o ambiente de execução e o agente do nó do Kubernetes, kubelet, que se comunica com o plano de controle e é responsável por iniciar e executar os contêineres programados nesse nó.

O GKE também executa vários contêineres do sistema que são executados como agentes por nó, chamados DaemonSets, que fornecem funcionalidades como coleta de registros e conectividade de rede intracluster.

Prática recomendada:

Use stdout para aplicativos conteinerizados, porque stdout permite que a plataforma gerencie os registros do aplicativo.

O gerenciamento de nós varia de acordo com o modo de operação do cluster, da seguinte maneira:

Componente do nó	Modo Autopilot	Modo padrão
Lifecycle	Totalmente gerenciado pelo GKE, incluindo: Upgrades automáticos reparos automáticos Verificações de integridade Escalonamento automático de nós Criação e exclusão de nós Redimensionamento Rotulagem para separação de carga de trabalho.	O GKE gerencia o seguinte: Upgrades automáticos reparos automáticos Verificações de integridade Você pode gerenciar o seguinte: Configuração de escalonamento automático de nós Upgrades de versão manuais Mudanças de configuração (como identificadores e redimensionamento). Criação e exclusão de pools de nós
Visibilidade	Confira os nós usando kubectl. Máquinas virtuais do Compute Engine subjacentes não visíveis ou acessíveis na CLI gcloud ou no console do Google Cloud.	Veja os nós usando o kubectl, a gcloud CLI e o console do Google Cloud. Ver e acessar VMs subjacentes do Compute Engine.
Conectividade	Sem conexão direta com as VMs subjacentes.	Conectar-se a VMs subjacentes usando SSH.
Sistema operacional (SO) do nó	Gerenciado pelo GKE. Todos os nós usam Container-Optimized OS com containerd (cos_containerd).	Escolha um sistema operacional para os nós.
Seleção de hardware de máquina	Solicite classes de computação em pods com base no caso de uso. O GKE gerencia a configuração, a programação, a quantidade e o ciclo de vida da máquina.	Escolha e configure os tipos de máquina do Compute Engine ao criar pools de nós. Defina configurações de dimensionamento, escalonamento, quantidade, programação e local com base nas necessidades.