Este tópico descreve a arquitetura técnica, o modelo de recursos híbrido e a QoS no nível de nó para colocation de cargas de trabalho online e offline, ajudando você a compreender e utilizar esse recurso no ACK.
Contexto
A colocation implanta diferentes tipos de carga de trabalho no mesmo cluster e nó para melhorar a utilização de recursos. As cargas são classificadas por Service Level Objectives (SLOs): cargas sensíveis à latência (LS) geralmente possuem metas de QPS ou tempo de resposta (RT) e recebem QoS de alta prioridade. Já as cargas best-effort (BE) exigem uso intensivo de computação, toleram falhas e recebem QoS de baixa prioridade.
Cada função concentra-se em aspectos distintos da colocation:
Administrador de recursos do cluster: monitora limites, alocação e uso de recursos por carga de trabalho para aumentar a utilização e reduzir custos.
Administrador de cargas LS: mitiga a interferência entre containers causada pela disputa de recursos, que pode elevar a latência nos percentis 90 e 99 e degradar a qualidade do serviço.
Administrador de cargas BE: utiliza overcommitment classificado de recursos para atender aos SLOs da carga de trabalho.
O ACK oferece os seguintes mecanismos de colocation:
Modelo de QoS para colocation com prioridades de recursos configuráveis.
Overcommitment de recursos estável e confiável.
Orquestração e isolamento refinados de recursos do Kubernetes.
Agendamento aprimorado de cargas de trabalho.
Arquitetura
O ACK utiliza o ack-koordinator para cumprir os SLOs das cargas de trabalho em cenários de colocation. O ack-koordinator é composto por um controlador SLO (extensão do Kubernetes implantada como Deployment) e um agente SLO (implantado como DaemonSet), que estende o kubelet com capacidades de colocation.
A solução de colocation ciente de SLO usa CRDs para registrar métricas de nó, configurações de QoS e aplicação de políticas. Além disso, rastreia recursos disponíveis para overcommitment dinâmico como recursos estendidos padrão. Cada componente fornece os seguintes recursos:
Controlador SLO: monitora a carga dos nós, faz overcommitment de recursos e garante os SLOs com base em perfis de recursos.
Recommender: cria perfis de recursos e estima a demanda de pico da carga de trabalho para simplificar a configuração de recursos do container.
Koordlet: monitora a carga dos nós, detecta anomalias e isola recursos dinamicamente para suprimir interferências em ciclo fechado.
Agendador do ACK: otimiza a colocation ciente de SLO, por exemplo, distribuindo pods durante o overcommitment dinâmico.
Koordinator Descheduler: implantado como Deployment para reagendamento de pods.
Modelo de recursos
O Kubernetes gerencia recursos de containers por meio de solicitações e limites. Para evitar disputas, os administradores frequentemente provisionam cargas LS em excesso, deixando os recursos solicitados subutilizados.
O bloco verde indica os recursos disponíveis para overcommitment dinâmico. Esses recursos são alocados para cargas BE a fim de atender aos SLOs e melhorar a utilização geral.
O ack-koordinator quantifica os recursos passíveis de overcommitment, calcula os recursos recuperados em tempo real e os sincroniza como recursos estendidos padrão nos metadados do nó do Kubernetes.
Modelo YAML de exemplo para o nó:
status:
allocatable:
# milli-core
kubernetes.io/batch-cpu: 50000
# bytes
kubernetes.io/batch-memory: 50000
capacity:
kubernetes.io/batch-cpu: 50000
kubernetes.io/batch-memory: 100000Os pods BE têm prioridade menor que os pods LS. Para usar recursos recuperados, adicione os campos qos e batch ao YAML do pod BE. qos: LS define alta prioridade; qos: BE define baixa prioridade. Os campos batch-cpu e batch-memory especificam as solicitações de recursos do pod. Consulte Ativar overcommitment dinâmico de recursos.
Modelo YAML de exemplo para o pod BE:
metadata:
labels:
koordinator.sh/qosClass: "BE" # Set the QoS class to BE or LS.
spec:
containers:
- resources:
limits:
kubernetes.io/batch-cpu: 1000
kubernetes.io/batch-memory: 2048
requests:
kubernetes.io/batch-cpu: 1000
kubernetes.io/batch-memory: 2048QoS no nível de nó
CPU QoS
A CPU QoS, baseada no Alibaba Cloud Linux, reserva recursos de CPU para pods LS ao configurar prioridades de agendamento do Linux por meio do recurso group identity do ack-koordinator. Em ambientes de colocation, os pods LS recebem alta prioridade e os pods BE recebem baixa prioridade. Isso evita disputas por recursos e garante a qualidade do serviço LS.
Benefícios da CPU QoS:
Minimiza a latência de ativação de tarefas para cargas LS.
As ativações de tarefas BE não afetam o desempenho dos pods LS.
Tarefas BE não podem usar o agendador SMT para compartilhar núcleos de CPU, o que reduz ainda mais o impacto no desempenho dos pods LS.
CPU Suppress
A quantidade de recursos disponíveis para overcommitment dinâmico varia conforme o uso dos pods LS e pode ser alocada para pods BE. O CPU Suppress limita o uso de CPU dos pods BE para garantir que os pods LS no nó tenham recursos suficientes.
Na figura, CPU Threshold representa o limiar de uso de CPU do nó, Pod (LS).Usage é o uso de CPU pelos pods LS e CPU Restriction for BE corresponde ao uso de CPU pelos pods BE. A alocação de CPU para pods BE se ajusta às flutuações de uso dos pods LS. Assim, os pods BE aproveitam recursos ociosos, mas evitam disputas quando a carga LS aumenta.
CPU Burst
Os limites de CPU do Kubernetes restringem o uso de CPU do container por período de tempo. Por exemplo, CPU Limit=2 limita um container a 200 ms de tempo de CPU a cada período de 100 ms.
A figura mostra a alocação de threads para um container de aplicação web em um nó de quatro vCore com CPU limit definido como 2. Apesar da baixa utilização geral de CPU, a Thread 2 não consegue retomar até o terceiro período de 100 ms porque ocorre throttling de CPU no segundo período. Esse comportamento aumenta o tempo de resposta (RT) e causa latência de longa duração (long-tail latency).
O CPU Burst resolve a latência de longa duração em cargas LS ao permitir que containers acumulem fatias de tempo de CPU ociosas para lidar com picos de demanda. O ACK suporta CPU Burst em todas as versões compatíveis do kernel. Para kernels incompatíveis, o ACK monitora o throttling de CPU e ajusta dinamicamente os limites de CPU do container para obter um efeito semelhante.
Memory QoS
Os containers estão sujeitos aos seguintes limites de memória:
Limite de memória do container: quando o uso de memória (incluindo page cache) se aproxima do limite, o kernel do SO aciona a recuperação de memória. Isso pode impedir que a aplicação solicite ou libere memória conforme esperado.
Limite de memória do nó: quando o limite de memória de um container excede sua solicitação, ele pode fazer overcommitment de memória. Se a memória disponível no nó se tornar insuficiente, o kernel do SO recupera memória dos containers, o que pode degradar severamente o desempenho da aplicação em cenários de colocation.
O ack-koordinator integra-se ao Alibaba Cloud Linux para ativar a Memory QoS para pods. Ele configura automaticamente o memcg com base nas definições do container e habilita os recursos memcg QoS, recuperação assíncrona de backend e classificação global de watermark mínimo. Essa abordagem otimiza o desempenho de aplicações sensíveis à memória e garante um agendamento justo de memória.
Recursos da Memory QoS:
Quando o uso de memória do pod se aproxima do limite, o memcg recupera memória de forma assíncrona para evitar recuperação síncrona completa, minimizando o impacto no desempenho da aplicação.
Se a memória do nó estiver insuficiente, a recuperação ocorre preferencialmente em pods cujo uso excede a solicitação. Isso impede que pods com overcommitment degradem o desempenho dos demais.
-
As solicitações de memória dos pods LS têm prioridade, o que reduz a probabilidade de acionar a recuperação completa de memória do nó.
memory.limit_in_bytes: limite superior de memória que um pod pode utilizar.
memory.high: limiar de throttling de memória.
memory.wmark_high: limiar para recuperação de memória.
memory.min: limiar de bloqueio de memória.
Isolamento de recursos baseado em cache L3 e MBA
Containers em colocation compartilham o cache L3 do nó (cache de último nível), com largura de banda de memória controlada pelo Memory Bandwidth Allocation (MBA). A ECS Bare Metal Instance (EBM) fornece o recurso LLC para ajustar dinamicamente o cache de CPU do pod e o recurso MBA para controlar a distribuição da largura de banda de memória. O ack-koordinator limita ainda mais os recursos dos pods BE de maneira refinada para proteger o desempenho dos pods LS.
Próximos passos
Consulte Introdução para criar um ambiente de colocation LS e BE com o ack-koordinator. Recursos relacionados à colocation: