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 v2Reproduz 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.
CRI — kubelet with no containerd
The delonix-cri crate implements Kubernetes' Container Runtime
Interface (runtime.v1).
The kubelet doesn't know how to run containers — it delegates to a runtime over CRI (gRPC over
a unix socket). Usually that runtime is containerd or CRI-O; with Delonix, it's the
delonix-cri binary: Kubernetes pods and containers running directly on the
Delonix engine, with no other piece involved.
How it connects
# the service (the golden VM image already ships it as a systemd unit)
DELONIX_CRI_ADDR=/run/delonix-cri.sock delonix-cri
# the kubelet points at it
kubelet --container-runtime-endpoint=unix:///run/delonix-cri.sock …What it implements
| CRI area | Support |
|---|---|
| RuntimeService — sandboxes (pods) | pod sandbox creation with shared netns
(the pod's containers join the sandbox's network via join_netns), labels/annotations,
status and removal |
| RuntimeService — containers | create/start/stop/remove, exec, logs in CRI format
(<rfc3339nano> stdout F line), per-pod cpu/memory limits via cgroups v2 |
| ImageService | pull (digest verified), list, status, remove — over Delonix's normal
ImageStore |
| Networking | CNI compatibility (attach/detach via JSON conf) |
Conformance — measured, not claimed
"Serves a kubelet" is a claim; 79 of 103 named specs is a fact someone else
can verify. delonix-cri is run against cri-tools'
critest, the upstream suite, and the number is published:
Ran 103 of 122 Specs
79 Passed | 24 Failed | 19 Skipped # rootless, cgroup v2Reproduce it with tests/compat/cri-conformance.sh. Full detail on what fails and
why — including what isn't ours to fix — is in
docs/cri-conformance.md.
About half of the remaining failures aren't engine gaps: nine are AppArmor specs, which need
CAP_MAC_ADMIN in the initial user namespace (Docker and containerd hit
exactly the same limit), and four are mount tests where the suite itself can't mount on the host
without root.
One divergence is deliberate and doesn't change just to pass a spec: a container with no declared seccomp profile runs under the engine's built-in allowlist, not unconfined. That's stricter than the spec asks for.
From zero to a cluster
This is the piece that closes the delonix cluster loop: the golden VM image
(delonix image vm build) already ships kubeadm/kubelet/kubectl and
delonix-cri running; delonix cluster kubeadm provisions the VMs and does
the bootstrap — the resulting cluster runs Kubernetes with Delonix as the runtime end to end.