1. containerd components

A good answer for containerd components names the concrete containerd layer, relates it to OCI, CRI or Kubernetes and provides at least one reproducible piece of evidence. It avoids production endpoints and documents whether the statement comes from a real command, static configuration or model artifact.

2. OCI image model

A good answer for OCI image model names the concrete containerd layer, relates it to OCI, CRI or Kubernetes and provides at least one reproducible piece of evidence. It avoids production endpoints and documents whether the statement comes from a real command, static configuration or model artifact.

3. content store

A good answer for content store names the concrete containerd layer, relates it to OCI, CRI or Kubernetes and provides at least one reproducible piece of evidence. It avoids production endpoints and documents whether the statement comes from a real command, static configuration or model artifact.

4. snapshotter

A good answer for snapshotter names the concrete containerd layer, relates it to OCI, CRI or Kubernetes and provides at least one reproducible piece of evidence. It avoids production endpoints and documents whether the statement comes from a real command, static configuration or model artifact.

5. container and task

A good answer for container and task names the concrete containerd layer, relates it to OCI, CRI or Kubernetes and provides at least one reproducible piece of evidence. It avoids production endpoints and documents whether the statement comes from a real command, static configuration or model artifact.

6. namespace confusion

A good answer for namespace confusion names the concrete containerd layer, relates it to OCI, CRI or Kubernetes and provides at least one reproducible piece of evidence. It avoids production endpoints and documents whether the statement comes from a real command, static configuration or model artifact.

7. CRI and Kubernetes

A good answer for CRI and Kubernetes names the concrete containerd layer, relates it to OCI, CRI or Kubernetes and provides at least one reproducible piece of evidence. It avoids production endpoints and documents whether the statement comes from a real command, static configuration or model artifact.

8. registry configuration

A good answer for registry configuration names the concrete containerd layer, relates it to OCI, CRI or Kubernetes and provides at least one reproducible piece of evidence. It avoids production endpoints and documents whether the statement comes from a real command, static configuration or model artifact.

9. CNI handoff

A good answer for CNI handoff names the concrete containerd layer, relates it to OCI, CRI or Kubernetes and provides at least one reproducible piece of evidence. It avoids production endpoints and documents whether the statement comes from a real command, static configuration or model artifact.

10. runtime v2 and shim

A good answer for runtime v2 and shim names the concrete containerd layer, relates it to OCI, CRI or Kubernetes and provides at least one reproducible piece of evidence. It avoids production endpoints and documents whether the statement comes from a real command, static configuration or model artifact.

11. cgroups and systemd

A good answer for cgroups and systemd names the concrete containerd layer, relates it to OCI, CRI or Kubernetes and provides at least one reproducible piece of evidence. It avoids production endpoints and documents whether the statement comes from a real command, static configuration or model artifact.

12. rootless

A good answer for rootless names the concrete containerd layer, relates it to OCI, CRI or Kubernetes and provides at least one reproducible piece of evidence. It avoids production endpoints and documents whether the statement comes from a real command, static configuration or model artifact.

13. RuntimeClass

A good answer for RuntimeClass names the concrete containerd layer, relates it to OCI, CRI or Kubernetes and provides at least one reproducible piece of evidence. It avoids production endpoints and documents whether the statement comes from a real command, static configuration or model artifact.

14. image verification

A good answer for image verification names the concrete containerd layer, relates it to OCI, CRI or Kubernetes and provides at least one reproducible piece of evidence. It avoids production endpoints and documents whether the statement comes from a real command, static configuration or model artifact.

15. garbage collection

A good answer for garbage collection names the concrete containerd layer, relates it to OCI, CRI or Kubernetes and provides at least one reproducible piece of evidence. It avoids production endpoints and documents whether the statement comes from a real command, static configuration or model artifact.

16. upgrade

A good answer for upgrade names the concrete containerd layer, relates it to OCI, CRI or Kubernetes and provides at least one reproducible piece of evidence. It avoids production endpoints and documents whether the statement comes from a real command, static configuration or model artifact.

17. incident response

A good answer for incident response names the concrete containerd layer, relates it to OCI, CRI or Kubernetes and provides at least one reproducible piece of evidence. It avoids production endpoints and documents whether the statement comes from a real command, static configuration or model artifact.

18. evidence

A good answer for evidence names the concrete containerd layer, relates it to OCI, CRI or Kubernetes and provides at least one reproducible piece of evidence. It avoids production endpoints and documents whether the statement comes from a real command, static configuration or model artifact.

Official Sources and Boundary

• containerd documentation, getting started and configuration: https://containerd.io/docs/2.3/getting-started/
• containerd registry hosts.toml: https://github.com/containerd/containerd/blob/main/docs/hosts.md
• containerd runtime v2 and shim model: https://github.com/containerd/containerd/blob/main/docs/runtime-v2.md
• Kubernetes container runtimes: https://kubernetes.io/docs/setup/production-environment/container-runtimes/
• Kubernetes Container Runtime Interface: 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
• Open Container Initiative: https://opencontainers.org/

This workshop does not introduce a containerd API. It maps official concepts into labs, review questions and operational workflows. When a file describes a model, it is explicitly framed as a model or lab artifact.

Practice Appendix: containerd Evidence for this assessment

This appendix connects the file with repeatable runtime evidence. It is deliberately practical: every statement should map to a concrete layer, artifact, impact and operational decision.

A.1 Layer Model

containerd must be understood as runtime layer: host, systemd, containerd daemon, plugins, content store, snapshotter, runtime v2, shim, runc, CRI, CNI and Kubernetes all have different responsibilities.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.2 Daemon and Socket

The containerd daemon exposes a gRPC API through a Unix socket. Changes to the socket, permissions or service determine which tools and orchestrators can talk to the runtime.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.3 Plugin System

containerd loads functionality through plugins. CRI, snapshotters, diff service, content service, runtime task service and image verification must be evaluated through the active plugins.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.4 Content Store

The content store keeps OCI content by digest. Tags are names; digests are content addresses. This separation is central for reproducibility and supply-chain review.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.5 Snapshotter

Snapshotters create usable root filesystems from image layers. OverlayFS is the common default, while remote snapshotters such as Stargz or Nydus change startup time, IO behavior and failure modes.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.6 Container and Task

A container is a metadata object; a task is the running execution. Many debugging mistakes come from mixing these two layers.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.7 Runtime v2 and Shim

containerd starts containers through runtime-v2 shims. The shim preserves IO, exit status and process relationship and partially decouples running tasks from the containerd daemon.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.8 OCI Runtime

runc or alternative runtimes implement the OCI Runtime Specification. They start the isolated process with namespaces, mounts, cgroups and security profiles.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.9 CRI

Kubernetes does not talk directly to ctr; it talks CRI. crictl is often better for node diagnosis, while ctr works deeper inside containerd.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.10 CNI

containerd is not the full Kubernetes network. During pod startup the CRI layer calls CNI plugins that configure network namespace, IPAM, routes and port mapping.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.11 Registry and Resolver

Registry behavior is controlled through resolver, host namespace and hosts.toml. Mirror, TLS, authentication and capabilities must be reviewed separately.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.12 Cgroups and Systemd

On systemd hosts, kubelet and runtime should use a consistent systemd cgroup model. Mixed cgroup drivers lead to hard-to-debug node problems.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.13 Namespaces

containerd namespaces are metadata namespaces, not Linux namespaces. Kubernetes typically uses k8s.io; direct ctr experiments should use dedicated namespaces.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.14 Rootless

Rootless containerd reduces some host risks, but has clear limits around networking, cgroups, storage and Kubernetes integration. Rootless is an operating model, not a blanket security promise.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.15 Image Trust

Signatures, verification, SBOM and vulnerability scanning are supply-chain controls. They must be integrated before pull, before start or through admission and policy mechanisms.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.16 Security Profiles

Seccomp, AppArmor, SELinux, capabilities and RuntimeClass limit container behavior. These controls complement each other, but do not replace safe images or host hardening.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.17 Garbage Collection

Garbage collection must not only look at free disk space. Content, snapshots, images, containers, tasks and leases must be evaluated together to avoid damaging active workloads.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.18 Observability

Good runtime diagnosis collects versions, service status, logs, events, plugins, namespaces, registry failures, snapshotter state and CRI output as one evidence package.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.19 Upgrade and Rollback

Runtime upgrades affect running workloads and Kubernetes nodes. A safe path includes backup, drain, version test, service restart, smoke test, rollback and post-change review.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.20 Incident Response

Registry outage, TLS errors, pull rate limits, damaged snapshots or runtime failures need separate runbooks. An incident ends only when cause, workaround, fix and prevention are documented.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.21 Model and Reality

Many examples are safe models. Transfer to real nodes needs additional review: distribution, containerd version, Kubernetes version, CNI, registry, security policy and change process.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.22 Evidence

Evidence contains command output, configuration, logs, hashes, versions and review notes. It does not contain production secrets, tokens, client certificates or pull credentials.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.23 Performance

Performance depends on snapshotter, registry latency, layer structure, deduplication, filesystem, IO, CPU, cgroups and remote snapshotters. Every optimization needs a measurement goal.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.24 Production Transfer

Production transfer is not copying lab files. It needs ownership, change ticket, rollback, monitoring, security approval, maintenance window and documented acceptance criteria.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.25 Minimal Completion Evidence

• containerd, ctr and runc versions are documented where installed.
• Scope is clearly described as model, local host or Kubernetes node.
• TOML, YAML, JSON and shell artifacts are syntactically validated.
• Registry, runtime, snapshotter or CRI changes have a rollback note.
• Evidence contains no production credentials.
• Official sources are referenced and not replaced by invented assumptions.