1. Goal

A safe working structure for containerd labs with separate areas for configuration, models, evidence and cleanup.

2. What is done

The example creates local evidence below work/, validates artifacts and collects optional runtime output when the tools are installed. It remains safe to run even when containerd is not running as a service.

3. Why it is done

containerd problems often come from mixing layers: Docker workflow, containerd API, CRI, OCI, CNI and Kubernetes have different responsibilities. This example makes the relevant boundary visible.

4. Typical commands

containerd --version 2>/dev/null || true
ctr version 2>/dev/null || true
ctr plugins ls 2>/dev/null || true
ctr namespaces ls 2>/dev/null || true
ctr -n k8s.io images ls 2>/dev/null || true
journalctl -u containerd -n 50 --no-pager 2>/dev/null || true

5. Verify success

• Artifacts are syntactically valid.
• Evidence exists below work/evidence/.
• No real secrets are used.
• Scope is clear: model, local host or Kubernetes node.
• Risks and cleanup are traceable.

6. Common mistakes

• wrong namespace in ctr.
• crictl without matching runtime endpoint.
• registry hosts in the wrong host namespace.
• TOML for the wrong containerd major version.
• snapshotter or RuntimeClass configured while the runtime is missing on the node.

7. Security aspects

containerd often runs very close to the host. Runtime changes can affect all pods on a node. Configuration changes are therefore reviewed as models before being transferred to real nodes.

8. Realistic use

This example transfers to node runbooks, platform reviews, Kubernetes troubleshooting, registry incident analysis and security hardening.

9. Workshop flow

1. Read the goal.
2. Open artifacts.
3. Run run.sh.
4. Inspect evidence.
5. Name the affected runtime layer.
6. Write down risk.
7. Document cleanup.
8. Review the result with a second person.

10. Review matrix

Official References

• containerd documentation: https://containerd.io/docs/2.3/getting-started/
• containerd registry configuration: https://github.com/containerd/containerd/blob/main/docs/hosts.md
• containerd runtime v2: https://github.com/containerd/containerd/blob/main/docs/runtime-v2.md
• Kubernetes container runtimes: https://kubernetes.io/docs/setup/production-environment/container-runtimes/
• Kubernetes CRI: https://kubernetes.io/docs/concepts/containers/cri/
• OCI Image Specification: https://github.com/opencontainers/image-spec
• OCI Runtime Specification: https://github.com/opencontainers/runtime-spec

Example Appendix: Evidence, Operations and Transfer

This appendix makes the example complete as a training component. It describes how a local model becomes reliable runtime analysis without touching production nodes or credentials.

B.1 Define scope

Define scope is needed here because containerd labs can otherwise drift from a safe model into uncontrolled node changes. The assessment must state whether an artifact only explains, validates locally or would be applied on a real node.

Review points:

• no production secrets
• no unreviewed socket or systemd changes
• no registry exceptions without justification
• no confusion between ctr, crictl and nerdctl
• cleanup possible by removing work/

B.2 Validate artifacts

Validate artifacts is needed here because containerd labs can otherwise drift from a safe model into uncontrolled node changes. The assessment must state whether an artifact only explains, validates locally or would be applied on a real node.

Review points:

• no production secrets
• no unreviewed socket or systemd changes
• no registry exceptions without justification
• no confusion between ctr, crictl and nerdctl
• cleanup possible by removing work/

B.3 Name runtime layer

Name runtime layer is needed here because containerd labs can otherwise drift from a safe model into uncontrolled node changes. The assessment must state whether an artifact only explains, validates locally or would be applied on a real node.

Review points:

• no production secrets
• no unreviewed socket or systemd changes
• no registry exceptions without justification
• no confusion between ctr, crictl and nerdctl
• cleanup possible by removing work/

B.4 Check Kubernetes relation

Check Kubernetes relation is needed here because containerd labs can otherwise drift from a safe model into uncontrolled node changes. The assessment must state whether an artifact only explains, validates locally or would be applied on a real node.

Review points:

• no production secrets
• no unreviewed socket or systemd changes
• no registry exceptions without justification
• no confusion between ctr, crictl and nerdctl
• cleanup possible by removing work/

B.5 Record security boundaries

Record security boundaries is needed here because containerd labs can otherwise drift from a safe model into uncontrolled node changes. The assessment must state whether an artifact only explains, validates locally or would be applied on a real node.

Review points:

• no production secrets
• no unreviewed socket or systemd changes
• no registry exceptions without justification
• no confusion between ctr, crictl and nerdctl
• cleanup possible by removing work/

B.6 Write rollback

Write rollback is needed here because containerd labs can otherwise drift from a safe model into uncontrolled node changes. The assessment must state whether an artifact only explains, validates locally or would be applied on a real node.

Review points:

• no production secrets
• no unreviewed socket or systemd changes
• no registry exceptions without justification
• no confusion between ctr, crictl and nerdctl
• cleanup possible by removing work/

B.7 Clean evidence

Clean evidence is needed here because containerd labs can otherwise drift from a safe model into uncontrolled node changes. The assessment must state whether an artifact only explains, validates locally or would be applied on a real node.

Review points:

• no production secrets
• no unreviewed socket or systemd changes
• no registry exceptions without justification
• no confusion between ctr, crictl and nerdctl
• cleanup possible by removing work/

B.8 Limit transfer

Limit transfer is needed here because containerd labs can otherwise drift from a safe model into uncontrolled node changes. The assessment must state whether an artifact only explains, validates locally or would be applied on a real node.

Review points:

• no production secrets
• no unreviewed socket or systemd changes
• no registry exceptions without justification
• no confusion between ctr, crictl and nerdctl
• cleanup possible by removing work/

B.9 Complete review

Complete review is needed here because containerd labs can otherwise drift from a safe model into uncontrolled node changes. The assessment must state whether an artifact only explains, validates locally or would be applied on a real node.

Review points:

• no production secrets
• no unreviewed socket or systemd changes
• no registry exceptions without justification
• no confusion between ctr, crictl and nerdctl
• cleanup possible by removing work/

B.10 Run cleanup

Run cleanup is needed here because containerd labs can otherwise drift from a safe model into uncontrolled node changes. The assessment must state whether an artifact only explains, validates locally or would be applied on a real node.

Review points:

• no production secrets
• no unreviewed socket or systemd changes
• no registry exceptions without justification
• no confusion between ctr, crictl and nerdctl
• cleanup possible by removing work/

B.11 Completion

An example is complete when the script runs successfully, all model artifacts are syntactically valid, the affected runtime layer is named and evidence contains no confidential data.