From 01e46bfa37cfb318313c11fc6a5c837084ba50f5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Petazzoni?= Date: Thu, 11 Sep 2025 16:21:27 +0200 Subject: [PATCH] =?UTF-8?q?=F0=9F=94=A7=20Mention=20container=20engine=20l?= =?UTF-8?q?evels?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- slides/containers/Container_Engines.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/slides/containers/Container_Engines.md b/slides/containers/Container_Engines.md index 19ee062c..40a13213 100644 --- a/slides/containers/Container_Engines.md +++ b/slides/containers/Container_Engines.md @@ -209,3 +209,23 @@ We're not aware of anyone using it directly (i.e. outside of Kubernetes). * On Kubernetes clusters, containerd or CRI-O are better choices. * On Kubernetes clusters, the container engine is an implementation detail. + +--- + +## Different levels + +- Directly use namespaces, cgroups, capabilities with custom code or scripts + + *useful for troubleshooting/debugging and for educative purposes; e.g. pipework* + +- Use low-level engines like runc, crun, youki + + *useful when building custom architectures; e.g. a brand new orchestrator* + +- Use low-level APIs like CRI or containerd grpc API + + *useful to achieve high-level features like Docker, but without Docker; e.g. ctr, nerdctl* + +- Use high-level APIs like Docker and Kubernetes + + *that's what most people will do*