Arquitetura do cluster

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

Um cluster é a base do GKE: os objetos do Kubernetes que representam os aplicativos em contêineres são executados em um cluster.

Mestre do cluster

O mestre do cluster executa os processos do plano de controle do Kubernetes, incluindo o servidor da API do Kubernetes, o programador e os controladores de 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 do 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 do Kubernetes, e o mestre executa o processo do servidor da API do Kubernetes para lidar com essas solicitações. É possível fazer chamadas da API do Kubernetes diretamente via HTTP/gRPC ou indiretamente por meio da execução de comandos do cliente da linha de comando do Kubernetes (kubectl) ou da interação com a IU no Console do GCP.

O processo do servidor da API do mestre do cluster é a central de 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 afetada pela interrupção.

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

Nós

Um cluster geralmente tem um ou mais nós, que são as máquinas de trabalho 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 no seu nome quando você cria um cluster.

Cada nó é gerenciado pelo mestre, que recebe atualizações sobre o status autoinformado de cada nó. É 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 com os 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 conectividade de rede intracluster.

Tipo de máquina de nó

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

Imagens do SO de nó

Cada nó executa uma imagem do SO 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, você pode especificar 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 fazer com 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.

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 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 4 -A 3

A saída retornada contém os campos Capacity e Allocatable com medições de armazenamento temporário, memória e CPU.

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:

  • 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

O GKE reserva uma memória extra de 100 MiB em cada nó para remoção de kubelet.

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

Veja na tabela a seguir a quantidade de recursos alocáveis de CPU e memória disponíveis para programar as cargas de trabalho do cluster de 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)
f1-micro (isento de memória) 0,6 0,6 1 0,94
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

Recursos alocáveis de armazenamento temporário local

A partir da versão 1.10 do GKE, você pode 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
Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Kubernetes Engine