Kubernetes multi-tenant com GPU fracionada: Kamaji e HAMi testados em hardware simulado

O problema é conhecido de quem opera GPU em Kubernetes. Um cluster por time significa pagar por um control plane por equipe. Um cluster único compartilhado entrega isolamento fraco. E o scheduler padrão trata a GPU como placa inteira, então um pod que precisa de 4 GB numa placa de 80 GB bloqueia o resto.

A proposta combina dois projetos. O Kamaji roda o control plane de cada tenant como pods dentro de um cluster de gerenciamento. O HAMi permite pedir fatias de GPU (memória em MB, compute em %). O ponto de integração é o mais delicado: o API server do tenant fica no cluster de gerenciamento, mas o webhook do HAMi roda no worker do tenant. Toda criação de pod com GPU depende do API server alcançar o tenant pelo túnel Konnectivity do Kamaji. Se esse salto falhar, os pods caem no scheduler padrão e o HAMi nunca os vê. No teste, funcionou de primeira.

O autor usou o mock device plugin do HAMi, sem GPU física, com duas configurações: tenant-a com uma A100 de 80 GB (81.920 MB, 100 cores) e tenant-b com duas L4 de 24 GB. Os oito testes passaram. Três pods de 20.000 MB e 30% dividiram a mesma placa. Um quarto pod de 30% ficou Pending por excesso de cores, e um pedido de 90.000 MB ficou Pending com CardInsufficientMemory. Cada tenant enxergou só o próprio worker, pods e capacidade de GPU.

Há limites claros. O laboratório não prova isolamento em runtime: sem limites reais de memória e compute, sem carga CUDA, sem dados de desempenho ou efeito de vizinho barulhento. O worker via contêiner kindest/node não é o caminho oficial do Kamaji, que indica kubeadm em máquinas reais ou Cluster API. E o mock plugin não libera o node lock do HAMi, que só expira em 5 minutos, então o autor liberou à mão. Ele classifica isso como artefato do mock, não bug do Kamaji ou do HAMi.

O HAMi já vinha sendo coberto pelo CEVIU. Em 17 de julho de 2026, o CEVIU noticiou "HAMi é Promovido a Projeto de Incubação da CNCF, Fortalecendo Virtualização de GPU no Kubernetes", e em 10 de agosto de 2026, "HAMi é incubado na CNCF e impulsiona compartilhamento de GPUs no Kubernetes". Naquelas matérias o foco era o fatiamento de GPU e o status do projeto. Agora aparece uma receita reproduzível que junta o HAMi a control planes hospedados do Kamaji.

Em 28 de agosto de 2026, a matéria "Fábrica de IA no Kubernetes: Maximizando GPUs com Isolamento e Open Source" já apontava os dois desafios, alta utilização de GPU e isolamento de tenants. O post de agora mostra uma implementação concreta, ainda em hardware simulado.

Para quem opera plataforma de GPU, a leitura é que dá para atacar custo de control plane e desperdício de placa ao mesmo tempo. Mas é um teste de encaixe e de decisões de agendamento, não de produção. Antes de levar a ideia adiante, vale validar em GPU real os limites de memória e compute e o efeito de vizinho barulhento, que o laboratório não cobre.