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 plano de controle e várias máquinas worker chamadas de nós. Esse plano de controle e máquinas de nó 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.

O GKE provisiona, mantém e opera tudo no plano de controle de zona e só provisiona os nós.

Plano de controle

O plano de controle executa os processos do plano de controle, incluindo o servidor da API Kubernetes, o programador e os controladores dos recursos principais. O GKE gerencia o ciclo de vida do plano de controle ao criar ou excluir um 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. Todas as interações com o cluster são feitas por meio de chamadas da API Kubernetes, e o plano de controle executa o processo do servidor da API Kubernetes 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 é 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.

Plano de controle e interação do nó

O plano de controle é responsável por decidir o que é executado em todos os nós 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 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 também se comunicam usando as Kubernetes APIs.

Controlar interações do plano 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 no plano de controle (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 plano de controle, 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 plano de controle 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 é e2-medium. É possível selecionar um tipo de máquina diferente ao criar um cluster.

Imagens do SO do 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.

Você pode 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 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)
c2-standard-4 16 13,3 4 3,92
c2-standard-8 32 28,6 8 7,91
c2-standard-16 64 58,7 16 15,89
c2-standard-30 120 111,2 30 29,89
c2-standard-60 240 228,4 60 59,85
e2-micro 1 0,62 2 0,941
e2-small 2 1,35 2 0,941
e2-medium (padrão) 4 2,76 2 0,941
e2-standard-2 8 6,1 2 1,93
e2-standard-4 16 13,3 4 3,92
e2-standard-8 32 28,6 8 7,91
e2-standard-16 64 58,7 16 15,89
e2-highmem-2 16 13,3 2 1,93
e2-highmem-4 32 28,6 4 3,92
e2-highmem-8 64 58,7 8 7,91
e2-highmem-16 128 118,6 16 15,89
e2-highcpu-2 2 1,5 2 1,93
e2-highcpu-4 4 2,9 4 3,92
e2-highcpu-8 8 6,1 8 7,91
e2-highcpu-16 16 13,3 16 15,89
g1-small 1,7 1,2 1 0,94
m1-megamem-96 1.433,6 1.414,7 96 95,69
m1-ultramem-40 961 942,1 40 39,85
m1-ultramem-80 1922 1.903,1 80 79,77
m1-ultramem-160 3.844 3.825,1 160 159,69
m1-ultramem-208 5888 5.869,1 208 207,69
m1-ultramem-416 11.776 11.757,1 416 415,69
n1-standard-1 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
n2d-standard-2 8 6,1 2 1,93
n2d-standard-4 16 13,3 4 3,92
n2d-standard-8 32 28,6 8 7,91
n2d-standard-16 64 58,7 16 15,89
n2d-standard-32 128 118,6 32 31,85
n2d-standard-48 192 182,6 48 47,85
n2d-standard-64 256 244,4 64 63,77
n2d-standard-80 320 308,4 80 79,77
n2d-standard-96 384 370,4 96 95,69
n2d-standard-128 512 496,8 128 127,69
n2d-standard-224 896 877,1 224 223,69
n2d-highmem-2 16 13,3 2 1,93
n2d-highmem-4 32 28,6 4 3,92
n2d-highmem-8 64 58,7 8 7,91
n2d-highmem-16 128 118,6 16 15,89
n2d-highmem-32 256 244,4 32 31,85
n2d-highmem-48 384 370,4 48 47,85
n2d-highmem-64 512 496,8 64 63,77
n2d-highmem-80 640 621,1 80 79,77
n2d-highmem-96 780 761,1 96 95,69
n2d-highcpu-2 2 1,5 2 1,93
n2d-highcpu-4 4 2,9 4 3,92
n2d-highcpu-8 8 6,1 8 7,91
n2d-highcpu-16 16 13,3 16 15,89
n2d-highcpu-32 32 28,6 32 31,85
n2d-highcpu-48 48 44,6 48 47,85
n2d-highcpu-64 64 58,7 64 63,77
n2d-highcpu-80 80 74,7 80 79,77
n2d-highcpu-96 96 89,2 96 95,69
n2d-highcpu-128 128 118,6 128 127,69
n2d-highcpu-224 224 213,4 224 223,69

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. Para saber como fazer com que os pods especifiquem solicitações e limites de armazenamento temporário e para saber como eles são realizados, consulte Armazenamento temporário local na documentação do Kubernetes.

O GKE geralmente configura os nós com um único sistema de arquivos e verificação periódica. Uma parte do disco de inicialização que depende do tamanho é reservada para uso do sistema.

O armazenamento temporário pode consumir até a capacidade do disco de inicialização, exceto por uma parte reservada para uso do sistema e um limite de remoção. O tamanho total reservado depende do tamanho do disco de inicialização de acordo com a seguinte fórmula:

10% * BOOT-DISK-CAPACITY + Min(50% * BOOT-DISK-CAPACITY, 6K + 35% * BOOT-DISK-CAPACITY, 100G)

Para uma representação aproximada da quantidade de armazenamento temporário alocável disponível conforme a capacidade do disco de inicialização aumenta, consulte o gráfico a seguir:

Um gráfico que mostra como o armazenamento temporário aumenta com a capacidade do disco de inicialização. A relação é aproximadamente linear.