CRI — kubelet sem containerd
O crate delonix-cri implementa o Container Runtime Interface
(runtime.v1) do Kubernetes.
O kubelet não sabe correr containers — delega num runtime via CRI (gRPC sobre socket unix).
Normalmente esse runtime é o containerd ou o CRI-O; com o Delonix, é o binário
delonix-cri: pods e containers do Kubernetes a correr directamente sobre o motor
Delonix, sem mais nenhuma peça.
Como se liga
# o serviço (a imagem VM dourada já o traz como unit systemd)
DELONIX_CRI_ADDR=/run/delonix-cri.sock delonix-cri
# o kubelet aponta para lá
kubelet --container-runtime-endpoint=unix:///run/delonix-cri.sock …
O que implementa
| Área CRI | Suporte |
|---|---|
| RuntimeService — sandboxes (pods) | criação do pod sandbox com netns partilhado
(os containers do pod juntam-se à rede do sandbox via join_netns), labels/annotations,
estado e remoção |
| RuntimeService — containers | create/start/stop/remove, exec, logs em formato CRI
(<rfc3339nano> stdout F linha), limites cpu/memória por pod via cgroups v2 |
| ImageService | pull (digest verificado), list, status, remove — sobre o
ImageStore normal do Delonix |
| Rede | compatibilidade CNI (attach/detach por conf JSON) |
Conformidade — medida, não afirmada
«Serve um kubelet» é uma alegação; 79 de 103 specs nomeados é um facto que
outra pessoa verifica. O delonix-cri é corrido contra o
critest do cri-tools, a
suite de upstream, e o número é publicado:
Ran 103 of 122 Specs
79 Passed | 24 Failed | 19 Skipped # rootless, cgroup v2
Reproduz com tests/compat/cri-conformance.sh. O detalhe completo do que falha e
porquê — incluindo o que não é nosso — está em
docs/cri-conformance.md.
Cerca de metade das falhas restantes não são lacunas do motor: nove são specs de AppArmor, que
exigem CAP_MAC_ADMIN no user namespace inicial (o Docker e o containerd têm
exactamente o mesmo limite), e quatro são testes de montagem em que a própria suite não consegue
montar no host sem root.
Uma divergência é deliberada e não muda para ganhar um spec: um container sem perfil seccomp declarado corre sob o allowlist embutido do motor, não unconfined. É mais apertado do que a especificação pede.
Do zero a um cluster
É esta peça que fecha o ciclo do delonix cluster: a imagem VM dourada
(delonix image --vm build) já traz kubeadm/kubelet/kubectl e o
delonix-cri activo; delonix cluster kubeadm provisiona as VMs e faz o
bootstrap — o cluster resultante corre Kubernetes com o Delonix como runtime de ponta a ponta.