|
Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official. |
Perfilamento de Recursos
Esta seção captura os resultados dos testes para determinar os requisitos mínimos de recursos para o K3s.
Requisitos mínimos de recursos para K3s
Os resultados estão resumidos da seguinte forma:
| Componentes | Processador | Min CPU | Min RAM com Kine/SQLite | Min RAM com etcd Embutido |
|---|---|---|---|---|
Servidor K3s com uma carga de trabalho |
CPU Intel 8375C, 2.90 GHz |
6% de um núcleo |
1596 M |
1606 M |
Cluster K3s com um único agente |
CPU Intel 8375C, 2.90 GHz |
5% de um núcleo |
1428 M |
1450 M |
Agente K3s |
CPU Intel 8375C, 2.90 GHz |
3% de um núcleo |
275 M |
275 M |
Servidor K3s com uma carga de trabalho |
Pi4B BCM2711, 1.50 GHz |
30% de um núcleo |
1588 M |
1613 M |
Cluster K3s com um único agente |
Pi4B BCM2711, 1.50 GHz |
25% de um núcleo |
1215 M |
1413 M |
Agente K3s |
Pi4B BCM2711, 1.50 GHz |
10% de um núcleo |
268 M |
268 M |
Escopo de teste de recursos
Os testes de recursos foram destinados a abordar as seguintes declarações de problema:
-
Em um cluster de nó único, determine a quantidade mínima legítima de CPU, memória e IOPs que deve ser reservada para executar toda a pilha do servidor K3s, assumindo que uma carga de trabalho real será implantada no cluster.
-
Em um nó agente (trabalhador), determine a quantidade mínima legítima de CPU, memória e IOPs que deve ser reservada para os componentes do plano de controle do Kubernetes e K3s (o kubelet e o agente k3s).
Componentes incluídos para medições de referência
Os componentes testados são:
-
K3s v1.26.5 com todos os componentes empacotados habilitados
-
Pilha de monitoramento Prometheus + Grafana
Esses são os números de referência para um sistema estável usando apenas componentes empacotados do K3s (Traefik Ingress, Klipper lb, armazenamento local) executando uma pilha de monitoramento padrão (Prometheus e Grafana) e o aplicativo de exemplo Guestbook.
Os números de recursos, incluindo IOPS, são apenas para o datastore do Kubernetes e o plano de controle, e não incluem sobrecarga para agentes de gerenciamento em nível de sistema ou registro, gerenciamento de imagens de contêiner ou quaisquer requisitos específicos de carga de trabalho.
Metodologia
Uma instância autônoma do Prometheus v2.43.0 foi usada para coletar estatísticas de CPU, memória e IO de disco do host usando prometheus-node-exporter instalado via apt.
systemd-cgtop foi usado para verificar a utilização de CPU e memória em nível de cgroup do systemd. system.slice/k3s.service rastreia a utilização de recursos tanto para K3s quanto para containerd, enquanto pods individuais estão sob a hierarquia kubepods.
Dados adicionais detalhados de utilização de memória do K3s foram coletados de kubectl top node usando o metrics-server integrado para os processos do servidor e do agente.
Os números de utilização foram baseados em leituras do 95º percentil de operação em estado estacionário em nós executando as cargas de trabalho descritas.
Ambiente
| Arquitetura | OS | Sistema | CPU | RAM | Disco |
|---|---|---|---|---|---|
x86_64 |
Ubuntu 22.04 |
AWS c6id.xlarge |
CPU Intel Xeon Platinum 8375C, 4 núcleos, 2.90 GHz |
8 GB |
SSD NVME |
aarch64 |
Raspberry Pi OS 11 |
Raspberry Pi 4 Model B |
BCM2711, 4 núcleos, 1.50 GHz |
8 GB |
UHS-III SDXC |
Requisitos Básicos de Recursos
Esta seção captura os resultados de testes para determinar os requisitos mínimos de recursos para a operação básica do K3s.
Servidor K3s com uma Carga de Trabalho
Estes são os requisitos para um cluster de nó único no qual o servidor K3s compartilha recursos com uma carga de trabalho simples.
Os requisitos de CPU são:
| Sistema | Uso de Núcleos de CPU |
|---|---|
Intel 8375C |
6% de um núcleo |
Pi4B |
30% de um núcleo |
Os Requisitos de Memória são:
| Armazenamento Testado | Sistema | Memória |
|---|---|---|
Kine/SQLite |
Intel 8375C |
1596 M |
Pi4B |
1588 M |
|
etcd Embutido |
Intel 8375C |
1606 M |
Pi4B |
1613 M |
Os requisitos de Disco são:
| Armazenamento Testado | IOPS | KiB/sec | Latência |
|---|---|---|---|
Kine/SQLite |
10 |
500 |
< 10 ms |
etcd Embutido |
50 |
250 |
< 5 ms |
Cluster K3s com um único agente
Esses são os requisitos básicos para um cluster K3s com um nó servidor K3s e um agente K3s, mas sem carga de trabalho.
Análise dos principais fatores de utilização de recursos
Os números de utilização do servidor K3s são principalmente impulsionados pelo suporte ao datastore do Kubernetes (kine ou etcd), API Server, Controller-Manager e loops de controle do Scheduler, bem como quaisquer tarefas de gerenciamento necessárias para efetuar mudanças no estado do sistema. Operações que colocam carga adicional no plano de controle do Kubernetes, como criar/modificar/excluir recursos, causarão picos temporários na utilização. Usar operadores ou aplicativos que fazem uso extensivo do datastore do Kubernetes (como Rancher ou outros aplicativos do tipo Operator) aumentará os requisitos de recursos do servidor. Aumentar o cluster adicionando nós adicionais ou criando muitos recursos de cluster aumentará os requisitos de recursos do servidor.
Os números de utilização do agente K3s são principalmente impulsionados pelo suporte aos loops de controle de gerenciamento do ciclo de vida dos contêineres. Operações que envolvem gerenciar imagens, provisionar armazenamento ou criar/destruir contêineres causarão picos temporários na utilização. Pulls de imagem, em particular, são tipicamente muito exigentes em CPU e IO, pois envolvem descompactar o conteúdo da imagem para o disco. Se possível, o armazenamento de carga de trabalho (armazenamento efêmero de pod e volumes) deve ser isolado dos componentes do agente (/var/lib/rancher/k3s/agent) para garantir que não haja conflitos de recursos.
Impedindo que Agentes e Cargas de Trabalho interfiram no Datastore do Cluster
Ao operar em um ambiente onde o servidor também está hospedando pods de carga de trabalho, deve-se ter cuidado para garantir que os IOPS do agente e da carga de trabalho não interfiram no datastore.
Isso pode ser melhor realizado colocando os componentes do servidor (/var/lib/rancher/k3s/server) em um meio de armazenamento diferente dos componentes do agente (/var/lib/rancher/k3s/agent), que incluem o armazenamento de imagens do containerd.
O armazenamento de carga de trabalho (armazenamento efêmero de pod e volumes) também deve ser isolado do datastore.
A falha em atender aos requisitos de throughput e latência do datastore pode resultar em uma resposta atrasada do plano de controle e/ou na falha do plano de controle em manter o estado do sistema.
Requisitos de dimensionamento de servidor para K3s
Ambiente
-
Todos os agentes eram instâncias t3.medium do AWS EC2.
-
Um único agente era uma instância c5.4xlarge. Isso hospedava a pilha de monitoramento Grafana e impedia que interferisse nos recursos do plano de controle.
-
-
O servidor era uma instância c5 do AWS EC2. À medida que o número de agentes aumentava, o servidor fez upgrade para instâncias c5 maiores.
Metodologia
Esses dados foram recuperados sob condições de teste específicas. Isso variará dependendo do ambiente e das cargas de trabalho. Os passos abaixo fornecem uma visão geral do teste que foi realizado para recuperar isso. Foi realizado pela última vez na versão v1.31.0+k3s1. Todas as máquinas foram provisionadas na AWS com volumes gp3 padrão de 20 GiB. O teste foi realizado com os seguintes passos:
-
Monitore os recursos no Grafana usando a fonte de dados Prometheus.
-
Implante cargas de trabalho de forma a simular atividade contínua do cluster:
-
Uma carga de trabalho básica que escala para cima e para baixo continuamente
-
Uma carga de trabalho que é deletada e recriada em um loop
-
Uma carga de trabalho constante que contém vários outros recursos, incluindo CRDs.
-
-
Junte os nós agentes em lotes de 50-100 de cada vez.
-
Pare de adicionar agentes quando a CPU do servidor ultrapassar 90% de utilização ao juntar agentes, ou se a RAM estiver acima de 80% de utilização.
Observações
-
Ao juntar agentes, a CPU do servidor apresentou picos de ~20% acima da linha de base.
-
Normalmente, o fator limitante era a CPU, não a RAM. Para a maioria dos testes, quando a CPU atingiu 90% de utilização, a utilização da RAM estava em torno de 60%.
Uma nota sobre Alta Disponibilidade (HA)
No final de cada teste, dois servidores adicionais foram adicionados (formando um cluster HA básico de 3 nós) para observar qual efeito isso teve nos recursos do servidor original. O efeito foi:
-
Uma queda notável na utilização da CPU, geralmente de 30-50%.
-
A utilização da RAM permaneceu a mesma.
Embora não tenha sido testado, com a utilização da CPU como fator limitante em um único servidor, espera-se que o número de agentes que podem ser adicionados aumente em ~50% com um cluster HA de 3 nós.