Arquitetura do cluster

Um cluster é a base do Google Kubernetes Engine (GKE): os objetos do Kubernetes que representam seus aplicativos em contêiner são todos executados em um cluster.

No GKE, um cluster consiste em pelo menos um mestre do cluster e várias máquinas de worker chamadas nós. Esse mestre e as máquinas de nós executam o sistema de orquestração de cluster do Kubernetes (em inglês).

O diagrama a seguir fornece uma visão geral da arquitetura de um cluster zonal no GKE.

Mestre do cluster

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

Mestre do cluster e API Kubernetes

O mestre é o ponto de extremidade unificado para o cluster. Todas as interações com o cluster são feitas por meio de chamadas da API Kubernetes, e o mestre executa o processo do servidor da API Kubernetes Server para lidar com essas solicitações. É possível fazer chamadas da API Kubernetes diretamente, por meio do HTTP/gRPC, ou indiretamente, executando comandos do cliente de linha de comando do Kubernetes (kubectl) ou interagindo com a IU no Console do Cloud.

O processo do servidor da API do mestre do cluster é o hub para todas as comunicações do cluster. Todos os processos internos do cluster (como os nodes, sistema e componentes do cluster, controladores de aplicativos) atuam como clientes do servidor da API. O servidor da API é a "fonte de verdade" única para todo o cluster.

Interação entre mestre e node

O mestre do cluster é responsável por decidir o que é executado em todos os nodes do cluster. Isso pode incluir a programação de cargas de trabalho, como aplicativos em contêineres, e o gerenciamento do ciclo de vida, da escala e dos upgrades das cargas de trabalho. O mestre também gerencia recursos de rede e de armazenamento para essas cargas de trabalho.

O mestre e os nós também se comunicam usando as APIs do Kubernetes.

Interações principais com o registro do contêiner gcr.io

Quando você cria ou atualiza um cluster, as imagens de contêiner do software Kubernetes em execução nos mestres (e nós) são extraídas do registro do contêiner gcr.io. Uma interrupção que afeta o registro gcr.io pode causar os seguintes tipos de falhas:

  • A criação de novos clusters falhará durante a interrupção.
  • A atualização de clusters falhará durante a interrupção.
  • 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.

No caso de uma interrupção zonal ou regional do registro do contêiner gcr.io, o Google pode redirecionar as solicitações para uma zona ou região não afetada pela interrupção.

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

Nós

Um cluster geralmente tem um ou mais nós, que são as máquinas do worker que executam os aplicativos em contêineres e outras cargas de trabalho. As máquinas individuais são instâncias de VMs do Compute Engine que o GKE cria em seu nome quando você cria um cluster.

Cada nó é gerenciado pelo mestre, que recebe atualizações sobre o status informado automaticamente por cada um deles. É possível ter controle manual do ciclo de vida do nó ou fazer com que o GKE realize reparos automáticos e upgrades automáticos nos nós do cluster.

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

No GKE, também há uma série de contêineres especiais que são executados como agentes por nó para fornecer funcionalidades, como coleta de registros e a conexão de rede intracluster.

Tipo de máquina de nó

Cada nó é de um padrão de tipo de máquina do Compute Engine. O tipo padrão é n1-standard-1, com 1 CPU virtual e 3,75 GB de memória. É possível selecionar um tipo de máquina diferente ao criar um cluster.

Imagens do sistema operacional de nó

Cada nó executa uma imagem do sistema operacional especializada para executar os contêineres. Você pode especificar qual imagem do SO os clusters e pools de nós usam.

Plataforma mínima de CPU

Ao criar um cluster ou pool de nós, especifique uma plataforma mínima de CPU de valor de referência para os nós dele. A escolha de uma plataforma de CPU específica pode ser vantajosa para cargas de trabalho avançadas ou intensivas em computação. Para mais informações, consulte Plataforma mínima de CPU.

Recursos alocáveis de nó

Alguns dos recursos de um nó são utilizados para executar os componentes do nó do GKE e do Kubernetes necessários para que ele funcione como parte do cluster. Assim, é possível observar uma disparidade entre os recursos totais do nó, conforme especificado na documentação do tipo de máquina, e os recursos alocáveis do nó no GKE.

Como tipos de máquinas maiores tendem a executar mais contêineres (e, por extensão, mais pods), a quantidade de recursos que o GKE reserva para componentes do Kubernetes é escalonada para máquinas maiores. Os nós do Windows Server também exigem mais recursos do que um nó comum do Linux. Os nós precisam de recursos extras para executar o sistema operacional Windows e para os componentes do Windows Server que não podem ser executados em contêineres.

É possível fazer uma solicitação de recursos para os pods ou limitar o uso deles. Para saber como solicitar ou limitar o uso de recursos para pods, consulte Como gerenciar recursos de computação para contêineres.

Para inspecionar os recursos alocáveis de nó disponíveis em um cluster, execute o seguinte comando:

kubectl describe node node-name | grep Allocatable -B 7 -A 6

Em que node-name é o nome do nó a ser inspecionado.

A saída retornada contém campos Capacity e Allocatable com medidas para armazenamento temporário, memória e CPU.

Limite de remoção

Para determinar a quantidade de memória disponível para pods, considere também o limite de remoção. O GKE reserva uma memória extra de 100 MiB em cada nó para remoção de kubelet (em inglês).

Recursos alocáveis de CPU e memória

Os recursos alocáveis são calculados da seguinte maneira:

Allocatable = Capacity - Reserved - Eviction Threshold

Para recursos de memória, o GKE reserva o seguinte:

  • 255 MiB de memória para máquinas com menos de 1 GB de memória
  • 25% dos primeiros 4 GB de memória
  • 20% dos próximos 4 GB de memória (até 8 GB)
  • 10% dos próximos 8 GB de memória (até 16 GB)
  • 6% dos próximos 112 GB de memória (até 128 GB)
  • 2% de qualquer memória acima de 128 GB

Para recursos de CPU, o GKE reserva o seguinte:

  • 6% do primeiro núcleo
  • 1% do próximo núcleo (até dois núcleos)
  • 0,5% dos próximos dois núcleos (até quatro núcleos)
  • 0,25% de todos os núcleos acima de quatro núcleos

A tabela a seguir mostra a quantidade de memória e recursos de CPU alocáveis disponíveis para programar cargas de trabalho do Linux para cada tipo de máquina de nó padrão.

Tipo de máquina Capacidade de memória (GB) Memória alocável (GB) Capacidade da CPU (núcleos) CPU alocável (núcleos)
e2-micro 1 0,62 2 0,941
e2-small 2 1,35 2 0,941
e2-medium 4 2,76 2 0,941
g1-small 1,7 1,2 1 0,94
n1-standard-1 (padrão) 3,75 2,7 1 0,94
n1-standard-2 7,5 5,7 2 1,93
n1-standard-4 15 12,3 4 3,92
n1-standard-8 30 26,6 8 7,91
n1-standard-16 60 54,7 16 15,89
n1-standard-32 120 111,2 32 31,85
n1-standard-64 240 228,4 64 63,77
n1-standard-96 360 346,4 96 95,69
n1-highmem-2 13 10,7 2 1,93
n1-highmem-4 26 22,8 4 3,92
n1-highmem-8 52 47,2 8 7,91
n1-highmem-16 104 96,0 16 15,89
n1-highmem-32 208 197,4 32 31,85
n1-highmem-64 416 400,8 64 63,77
n1-highmem-96 624 605,1 96 95,69
n1-highcpu-2 1,8 1,3 2 1,93
n1-highcpu-4 3,6 2,6 4 3,92
n1-highcpu-8 7,2 5,5 8 7,91
n1-highcpu-16 14,4 11,9 16 15,89
n1-highcpu-32 28,8 25,3 32 31,85
n1-highcpu-64 57,6 52,5 64 63,77
n1-highcpu-96 86,4 79,6 96 95,69
n2-standard-2 8 6,1 2 1,93
n2-standard-4 16 13,3 4 3,92
n2-standard-8 32 28,6 8 7,91
n2-standard-16 64 58,7 16 15,89
n2-standard-32 128 118,6 32 31,85
n2-standard-48 192 182,6 48 47,85
n2-standard-64 256 244,4 64 63,77
n2-standard-80 320 308,4 80 79,77
n2-highmem-2 16 13,3 2 1,93
n2-highmem-4 32 28,6 4 3,92
n2-highmem-8 64 58,7 8 7,91
n2-highmem-16 128 118,6 16 15,89
n2-highmem-32 256 244,4 32 31,85
n2-highmem-48 384 370,4 48 47,85
n2-highmem-64 512 496,8 64 63,77
n2-highmem-80 640 621,1 80 79,77
n2-highcpu-2 2 1,5 2 1,93
n2-highcpu-4 4 2,9 4 3,92
n2-highcpu-8 8 6,1 8 7,91
n2-highcpu-16 16 13,3 16 15,89
n2-highcpu-32 32 28,6 32 31,85
n2-highcpu-48 48 44,6 48 47,85
n2-highcpu-64 64 58,7 64 63,77
n2-highcpu-80 80 74,7 80 79,77

1O GKE decidiu reduzir os recursos de CPU alocáveis disponíveis para programar cargas de trabalho de usuários (conhecidas como recursos alocáveis de nós) em tipos de máquina e2-micro, e2-small e e2-medium. Para mais detalhes, consulte as notas de lançamento do GKE.

Recursos alocáveis de armazenamento temporário local

A partir da versão 1.10 do GKE, é possível gerenciar os recursos de armazenamento temporário local assim como gerencia os recursos de CPU e memória. As reservas do sistema para armazenamento local são feitas principalmente para o espaço em disco usado por imagens de contêiner.

Se o nó não consumir todo o armazenamento reservado, os pods ainda poderão usar o espaço. Isso não impede que o espaço em disco seja usado em qualquer cenário.

Os recursos alocáveis de armazenamento temporário local ​​são calculados com a fórmula a seguir, com um limite de remoção de 10% da capacidade de armazenamento:

Allocatable = Capacity - Reserved - Eviction Threshold

Capacidade de disco (GB) Reservado (GB) Alocável (GB)
8 4 3,2
16 8 6,4
32 16 12,8
64 28,4 29,2
128 50,8 64,4
256 95,6 134,8
512 100 360,8
1024 100 821,6
2048 100 1743,2
4096 100 3586,4