Nesta página, descrevemos a arquitetura dos clusters do Google Kubernetes Engine (GKE) que executam suas cargas de trabalho conteinerizadas. Use esta página para saber mais sobre o plano de controle, os nós e como os vários componentes do cluster do GKE interagem entre si.
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.
Antes de ler esta página, você precisa conhecer a arquitetura de cluster do Kubernetes.
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:
Este diagrama mostra os seguintes componentes:
- Plano de controle: gerenciado pelo GKE. Executa o servidor da API Kubernetes, os controladores de carga de trabalho, o programador do Kubernetes e o armazenamento de estado do cluster.
- Nós: gerenciados pelo GKE no modo Autopilot e pelos clientes no modo Standard. Todos os seus pods são executados em nós.
- Outros serviços do Google Cloud : disponíveis para integração com o 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 doGoogle Cloud .
O processo do servidor da API é o hub central 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:
Plano de controle e banco de dados de estado do cluster
O projeto de código aberto do Kubernetes usa o etcd como banco de dados de armazenamento para todos os dados do cluster por padrão. O estado do cluster é mantido em um armazenamento de chave-valor que contém informações sobre o estado de cada objeto da API Kubernetes no cluster. Por exemplo, o banco de dados de estado do cluster armazena todos os Secrets, ConfigMaps e implantações.
Os clusters do GKE armazenam o estado do cluster em um dos seguintes armazenamentos de chave-valor:
- etcd: o GKE armazena o estado do cluster em instâncias do etcd que são executadas em todas as máquina virtual (VMs) do plano de controle.
- Spanner: o GKE armazena o estado do cluster no Spanner. O banco de dados do Spanner não é executado no plano de controle do cluster.
Independente do tipo de banco de dados, todos os cluster do GKE atendem à API etcd no plano de controle. O servidor da API Kubernetes usa a API etcd para se comunicar com o banco de dados de estado do cluster de back-end.
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
dos repositórios do Artifact Registry no domínio pkg.dev ou gcr.io. Uma interrupção que afeta esses registros pode causar a falha das seguintes ações:
- Criação de clusters novos
- 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 do repositório do Artifact Registry for regional, poderemos redirecionar solicitações para uma zona ou região que não tenha sido afetada.
Para verificar o status dos serviços do Google Cloud , acesse o painel de status doGoogle Cloud .
Implante em várias regiões para permitir a disponibilidade de aplicativos durante interrupções de região.
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.
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:
|
O GKE gerencia o seguinte:
Você pode gerenciar o seguinte:
|
| 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 Google Cloud . |
Veja os nós usando o kubectl, a CLI gcloud e
o console 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. |