Arquitetura do cluster do GKE

Nesta página, descrevemos a arquitetura dos clusters do Google Kubernetes Engine (GKE) que executam 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 papéis de usuário comuns do GKE.

Antes de ler esta página, você precisa ter familiaridade com 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 de API Kubernetes, os controladores de carga de trabalho, o escalonador 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 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 de API Kubernetes, o escalonador 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 de 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 de 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 de 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 o 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 etcd que são executadas em cada máquina virtual (VM) 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.

Independentemente do tipo de banco de dados, todo cluster do GKE disponibiliza a API etcd no plano de controle. O servidor de API do 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 falha temporária 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 as solicitações para uma zona ou região que não seja afetada pela interrupção.

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

Prática recomendada:

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.

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:

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 do Google Cloud . Veja os nós usando o kubectl, a CLI gcloud 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.

Registro de nós com a API Kubernetes

Quando um nó é criado em um cluster do GKE, o processo kubelet nesse nó estabelece uma conexão TLS com o servidor de API Kubernetes. Durante a inicialização do nó, o kubelet cria uma CertificateSigningRequest para solicitar um certificado do cliente exclusivo do servidor de API. O kubelet usa o certificado para criar um objeto Node na API Kubernetes.

Um recurso do GKE chamado Nós protegidos do GKE, que é ativado por padrão em todos os novos clusters, aumenta a segurança desse processo de autorregistro de nós usando um módulo de plataforma confiável virtual (vTPM) no nó para verificar criptograficamente a identidade do nó. Essa verificação garante que o plano de controle emita credenciais apenas para nós legítimos.

Se quiser, você pode exigir que um componente confiável do plano de controle do GKE crie esses objetos Node em vez do kubelet, o que reduz o impacto potencial se um nó for comprometido. Para mais informações, consulte Criação de nós do plano de controle (pré-lançamento).

A seguir