Esta página descreve a arquitetura dos clusters do Google Kubernetes Engine (GKE) que executam as suas cargas de trabalho em contentores. Use esta página para saber mais sobre o plano de controlo, os nós e como os vários componentes do cluster do GKE interagem entre si.
Esta página destina-se a administradores, arquitetos e operadores que definem soluções de TI e arquitetura de sistemas. Para saber mais sobre as funções comuns e exemplos de tarefas que referimos no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Google Cloud
Antes de ler esta página, certifique-se de que conhece a arquitetura do cluster do Kubernetes.
Um cluster do GKE consiste num painel de controlo e em máquinas de trabalho denominadas nós. O plano de controlo e os nós compõem o sistema de orquestração do cluster do Kubernetes. O GKE Autopilot gere toda a infraestrutura subjacente dos clusters, incluindo o plano de controlo, os nós e todos os componentes do sistema.
Se usar o modo padrão do GKE, o GKE gere o plano de controlo e os componentes do sistema, e o utilizador gere os nós.
O diagrama seguinte mostra a arquitetura de um cluster do GKE:
Este diagrama mostra os seguintes componentes:
- Plano de controlo: gerido pelo GKE. Executa o servidor da API Kubernetes, controladores de cargas de trabalho, o programador do Kubernetes e o armazenamento do estado do cluster.
- Nós: geridos pelo GKE no modo Autopilot e geridos pelos clientes no modo Standard. Todos os seus pods são executados em nós.
- Outros Google Cloud serviços: disponíveis para integração com o GKE.
Acerca do plano de controlo
O plano de controlo executa processos como o servidor da API Kubernetes, o programador e os controladores de recursos principais. O GKE gere o ciclo de vida do plano de controlo desde a criação até à eliminação do cluster. Isto inclui atualizações à versão do Kubernetes em execução no plano de controlo, que o GKE realiza automaticamente ou manualmente a seu pedido, se preferir atualizar antes da programação automática.
Plano de controlo e API Kubernetes
O painel de controlo é o ponto final unificado do seu cluster. Interage com o plano de controlo através de chamadas à API Kubernetes. O plano de controlo executa o processo do servidor da API Kubernetes (kube-apiserver) para processar pedidos de API. Pode fazer chamadas à API Kubernetes das seguintes formas:
- Chamadas diretas: HTTP/gRPC
- Chamadas indiretas: clientes de linha de comandos do Kubernetes, como
kubectl, ou a consolaGoogle Cloud .
O processo do servidor da API é o centro de todas as comunicações do cluster. Todos os componentes do cluster interno, como nós, processos do sistema e controladores de aplicações, atuam como clientes do servidor da API.
Os seus pedidos de API indicam ao Kubernetes qual é o estado desejado para os objetos no seu cluster. O Kubernetes tenta manter constantemente esse estado. O Kubernetes permite-lhe configurar objetos na API de forma imperativa ou declarativa.
Para saber mais sobre a gestão de objetos no Kubernetes, consulte as seguintes páginas:
Plano de controlo e base de dados do estado do cluster
O projeto Kubernetes de código aberto usa o etcd como a base de dados de armazenamento para todos os dados do cluster por predefinição. O estado do cluster é mantido num armazenamento de chave-valor que contém informações sobre o estado de cada objeto da API Kubernetes no seu cluster. Por exemplo, a base de dados do estado do cluster armazena todos os segredos, os ConfigMaps e as implementações.
Os clusters do GKE armazenam o estado do cluster num 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áquinas virtuais (VMs) do plano de controlo.
- Spanner: o GKE armazena o estado do cluster no Spanner. A base de dados do Spanner não é executada no plano de controlo do cluster.
Independentemente do tipo de base de dados, todos os clusters do GKE publicam a API etcd no plano de controlo. O servidor da API Kubernetes usa a API etcd para comunicar com a base de dados de estado do cluster de back-end.
Interação entre o plano de controlo e os nós
O plano de controlo gere o que é executado em todos os nós do cluster. O plano de controlo agenda cargas de trabalho e gere o ciclo de vida, o escalamento e as atualizações das cargas de trabalho. O plano de controlo também gere os recursos de rede e de armazenamento para essas cargas de trabalho. O plano de controlo e os nós comunicam entre si através das APIs Kubernetes.
Interações do plano de controlo com o Artifact Registry
Quando cria ou atualiza um cluster, o GKE extrai imagens de contentores
para o software do sistema Kubernetes em execução no plano de controlo e nos nós a partir de
repositórios do Artifact Registry no domínio pkg.dev ou gcr.io. Uma indisponibilidade
que afete estes registos pode fazer com que as seguintes ações falhem:
- Criação de novo cluster
- Atualizações da versão do cluster
As interrupções nas cargas de trabalho podem ocorrer mesmo sem a sua intervenção, consoante a natureza e a duração específicas da indisponibilidade.
Se a indisponibilidade do repositório do Artifact Registry for regional, podemos redirecionar pedidos para uma zona ou uma região que não seja afetada pela indisponibilidade.
Para verificar o estado dos Google Cloud serviços, aceda ao Google Cloud painel de controlo de estado.
Implemente em várias regiões para permitir a disponibilidade de aplicações durante interrupções regionais.
Acerca dos nós
Os nós são as máquinas de trabalho que executam as suas aplicações contentorizadas e outras cargas de trabalho. As máquinas individuais são máquinas virtuais (VMs) do Compute Engine criadas pelo GKE. O plano de controlo gere e recebe atualizações sobre o estado autorreferido de cada nó.
Um nó executa os serviços necessários para suportar os contentores que compõem as cargas de trabalho do seu cluster. Estes incluem o tempo de execução e o agente do nó do Kubernetes (kubelet), que comunica com o plano de controlo e é responsável por iniciar e executar contentores agendados no nó.
O GKE também executa vários contentores do sistema que são executados como agentes por nó, denominados DaemonSets, que oferecem funcionalidades como a recolha de registos e a conetividade de rede no cluster.
Use stdout para aplicações contentorizadas porque stdout permite que a sua plataforma processe os registos de aplicações.
A gestão de nós varia consoante o modo de funcionamento do cluster, da seguinte forma:
| Componente de nó | Modo Autopilot | Modo padrão |
|---|---|---|
| Ciclo de vida | Totalmente gerido pelo GKE, incluindo:
|
O GKE gere o seguinte:
Pode gerir o seguinte:
|
| Visibilidade | Veja os nós através de kubectl. Máquinas virtuais do Compute Engine subjacentes não visíveis nem acessíveis na CLI gcloud ou na consola Google Cloud . |
Veja os nós através do kubectl, da CLI gcloud e da
consola Google Cloud . Ver e aceder às VMs do Compute Engine
subjacentes. |
| Conetividade | Não existe uma ligação direta às VMs subjacentes. | Estabeleça ligação às VMs subjacentes através de SSH. |
| Sistema operativo (SO) do nó | Gerido pelo GKE. Todos os nós usam o
SO otimizado para contentores com o containerd (cos_containerd). |
Escolha um sistema operativo para os seus nós. |
| Seleção de hardware da máquina | Pedir classes de computação em pods com base no exemplo de utilização. O GKE gere a configuração, o planeamento, a quantidade e o ciclo de vida das máquinas. |
Escolha e configure os tipos de máquinas do Compute Engine quando criar pools de nós. Configure as definições de dimensionamento, escala, quantidade, programação e localização com base na necessidade. |