Lösung: Intermediate containerd
1. containerd-Komponenten
Eine gute Antwort zu containerd-Komponenten benennt die konkrete containerd-Ebene, ordnet den Bezug zu OCI, CRI oder Kubernetes ein und liefert mindestens einen reproduzierbaren Nachweis. Sie vermeidet produktive Endpunkte und dokumentiert, ob die Aussage aus einem echten Kommando, einer statischen Konfiguration oder einem Modellartefakt stammt.
| Bewertungspunkt | Erwartung |
|---|---|
| Fachlichkeit | Begriff und Schicht sind korrekt. |
| Evidence | Ein Kommando, Log, TOML/YAML/JSON oder Review-Auszug belegt die Aussage. |
| Risiko | Auswirkung auf Node, Runtime, Registry oder Workload ist beschrieben. |
| Sicherheit | Secrets und produktive Systeme werden ausgeschlossen. |
2. OCI-Image-Modell
Eine gute Antwort zu OCI-Image-Modell benennt die konkrete containerd-Ebene, ordnet den Bezug zu OCI, CRI oder Kubernetes ein und liefert mindestens einen reproduzierbaren Nachweis. Sie vermeidet produktive Endpunkte und dokumentiert, ob die Aussage aus einem echten Kommando, einer statischen Konfiguration oder einem Modellartefakt stammt.
| Bewertungspunkt | Erwartung |
|---|---|
| Fachlichkeit | Begriff und Schicht sind korrekt. |
| Evidence | Ein Kommando, Log, TOML/YAML/JSON oder Review-Auszug belegt die Aussage. |
| Risiko | Auswirkung auf Node, Runtime, Registry oder Workload ist beschrieben. |
| Sicherheit | Secrets und produktive Systeme werden ausgeschlossen. |
3. Content Store
Eine gute Antwort zu Content Store benennt die konkrete containerd-Ebene, ordnet den Bezug zu OCI, CRI oder Kubernetes ein und liefert mindestens einen reproduzierbaren Nachweis. Sie vermeidet produktive Endpunkte und dokumentiert, ob die Aussage aus einem echten Kommando, einer statischen Konfiguration oder einem Modellartefakt stammt.
| Bewertungspunkt | Erwartung |
|---|---|
| Fachlichkeit | Begriff und Schicht sind korrekt. |
| Evidence | Ein Kommando, Log, TOML/YAML/JSON oder Review-Auszug belegt die Aussage. |
| Risiko | Auswirkung auf Node, Runtime, Registry oder Workload ist beschrieben. |
| Sicherheit | Secrets und produktive Systeme werden ausgeschlossen. |
4. Snapshotter
Eine gute Antwort zu Snapshotter benennt die konkrete containerd-Ebene, ordnet den Bezug zu OCI, CRI oder Kubernetes ein und liefert mindestens einen reproduzierbaren Nachweis. Sie vermeidet produktive Endpunkte und dokumentiert, ob die Aussage aus einem echten Kommando, einer statischen Konfiguration oder einem Modellartefakt stammt.
| Bewertungspunkt | Erwartung |
|---|---|
| Fachlichkeit | Begriff und Schicht sind korrekt. |
| Evidence | Ein Kommando, Log, TOML/YAML/JSON oder Review-Auszug belegt die Aussage. |
| Risiko | Auswirkung auf Node, Runtime, Registry oder Workload ist beschrieben. |
| Sicherheit | Secrets und produktive Systeme werden ausgeschlossen. |
5. Container und Task
Eine gute Antwort zu Container und Task benennt die konkrete containerd-Ebene, ordnet den Bezug zu OCI, CRI oder Kubernetes ein und liefert mindestens einen reproduzierbaren Nachweis. Sie vermeidet produktive Endpunkte und dokumentiert, ob die Aussage aus einem echten Kommando, einer statischen Konfiguration oder einem Modellartefakt stammt.
| Bewertungspunkt | Erwartung |
|---|---|
| Fachlichkeit | Begriff und Schicht sind korrekt. |
| Evidence | Ein Kommando, Log, TOML/YAML/JSON oder Review-Auszug belegt die Aussage. |
| Risiko | Auswirkung auf Node, Runtime, Registry oder Workload ist beschrieben. |
| Sicherheit | Secrets und produktive Systeme werden ausgeschlossen. |
6. Namespace-Verwechslung
Eine gute Antwort zu Namespace-Verwechslung benennt die konkrete containerd-Ebene, ordnet den Bezug zu OCI, CRI oder Kubernetes ein und liefert mindestens einen reproduzierbaren Nachweis. Sie vermeidet produktive Endpunkte und dokumentiert, ob die Aussage aus einem echten Kommando, einer statischen Konfiguration oder einem Modellartefakt stammt.
| Bewertungspunkt | Erwartung |
|---|---|
| Fachlichkeit | Begriff und Schicht sind korrekt. |
| Evidence | Ein Kommando, Log, TOML/YAML/JSON oder Review-Auszug belegt die Aussage. |
| Risiko | Auswirkung auf Node, Runtime, Registry oder Workload ist beschrieben. |
| Sicherheit | Secrets und produktive Systeme werden ausgeschlossen. |
7. CRI und Kubernetes
Eine gute Antwort zu CRI und Kubernetes benennt die konkrete containerd-Ebene, ordnet den Bezug zu OCI, CRI oder Kubernetes ein und liefert mindestens einen reproduzierbaren Nachweis. Sie vermeidet produktive Endpunkte und dokumentiert, ob die Aussage aus einem echten Kommando, einer statischen Konfiguration oder einem Modellartefakt stammt.
| Bewertungspunkt | Erwartung |
|---|---|
| Fachlichkeit | Begriff und Schicht sind korrekt. |
| Evidence | Ein Kommando, Log, TOML/YAML/JSON oder Review-Auszug belegt die Aussage. |
| Risiko | Auswirkung auf Node, Runtime, Registry oder Workload ist beschrieben. |
| Sicherheit | Secrets und produktive Systeme werden ausgeschlossen. |
8. Registry-Konfiguration
Eine gute Antwort zu Registry-Konfiguration benennt die konkrete containerd-Ebene, ordnet den Bezug zu OCI, CRI oder Kubernetes ein und liefert mindestens einen reproduzierbaren Nachweis. Sie vermeidet produktive Endpunkte und dokumentiert, ob die Aussage aus einem echten Kommando, einer statischen Konfiguration oder einem Modellartefakt stammt.
| Bewertungspunkt | Erwartung |
|---|---|
| Fachlichkeit | Begriff und Schicht sind korrekt. |
| Evidence | Ein Kommando, Log, TOML/YAML/JSON oder Review-Auszug belegt die Aussage. |
| Risiko | Auswirkung auf Node, Runtime, Registry oder Workload ist beschrieben. |
| Sicherheit | Secrets und produktive Systeme werden ausgeschlossen. |
9. CNI-Übergang
Eine gute Antwort zu CNI-Übergang benennt die konkrete containerd-Ebene, ordnet den Bezug zu OCI, CRI oder Kubernetes ein und liefert mindestens einen reproduzierbaren Nachweis. Sie vermeidet produktive Endpunkte und dokumentiert, ob die Aussage aus einem echten Kommando, einer statischen Konfiguration oder einem Modellartefakt stammt.
| Bewertungspunkt | Erwartung |
|---|---|
| Fachlichkeit | Begriff und Schicht sind korrekt. |
| Evidence | Ein Kommando, Log, TOML/YAML/JSON oder Review-Auszug belegt die Aussage. |
| Risiko | Auswirkung auf Node, Runtime, Registry oder Workload ist beschrieben. |
| Sicherheit | Secrets und produktive Systeme werden ausgeschlossen. |
10. Runtime v2 und Shim
Eine gute Antwort zu Runtime v2 und Shim benennt die konkrete containerd-Ebene, ordnet den Bezug zu OCI, CRI oder Kubernetes ein und liefert mindestens einen reproduzierbaren Nachweis. Sie vermeidet produktive Endpunkte und dokumentiert, ob die Aussage aus einem echten Kommando, einer statischen Konfiguration oder einem Modellartefakt stammt.
| Bewertungspunkt | Erwartung |
|---|---|
| Fachlichkeit | Begriff und Schicht sind korrekt. |
| Evidence | Ein Kommando, Log, TOML/YAML/JSON oder Review-Auszug belegt die Aussage. |
| Risiko | Auswirkung auf Node, Runtime, Registry oder Workload ist beschrieben. |
| Sicherheit | Secrets und produktive Systeme werden ausgeschlossen. |
11. cgroups und Systemd
Eine gute Antwort zu cgroups und Systemd benennt die konkrete containerd-Ebene, ordnet den Bezug zu OCI, CRI oder Kubernetes ein und liefert mindestens einen reproduzierbaren Nachweis. Sie vermeidet produktive Endpunkte und dokumentiert, ob die Aussage aus einem echten Kommando, einer statischen Konfiguration oder einem Modellartefakt stammt.
| Bewertungspunkt | Erwartung |
|---|---|
| Fachlichkeit | Begriff und Schicht sind korrekt. |
| Evidence | Ein Kommando, Log, TOML/YAML/JSON oder Review-Auszug belegt die Aussage. |
| Risiko | Auswirkung auf Node, Runtime, Registry oder Workload ist beschrieben. |
| Sicherheit | Secrets und produktive Systeme werden ausgeschlossen. |
12. Rootless
Eine gute Antwort zu Rootless benennt die konkrete containerd-Ebene, ordnet den Bezug zu OCI, CRI oder Kubernetes ein und liefert mindestens einen reproduzierbaren Nachweis. Sie vermeidet produktive Endpunkte und dokumentiert, ob die Aussage aus einem echten Kommando, einer statischen Konfiguration oder einem Modellartefakt stammt.
| Bewertungspunkt | Erwartung |
|---|---|
| Fachlichkeit | Begriff und Schicht sind korrekt. |
| Evidence | Ein Kommando, Log, TOML/YAML/JSON oder Review-Auszug belegt die Aussage. |
| Risiko | Auswirkung auf Node, Runtime, Registry oder Workload ist beschrieben. |
| Sicherheit | Secrets und produktive Systeme werden ausgeschlossen. |
13. RuntimeClass
Eine gute Antwort zu RuntimeClass benennt die konkrete containerd-Ebene, ordnet den Bezug zu OCI, CRI oder Kubernetes ein und liefert mindestens einen reproduzierbaren Nachweis. Sie vermeidet produktive Endpunkte und dokumentiert, ob die Aussage aus einem echten Kommando, einer statischen Konfiguration oder einem Modellartefakt stammt.
| Bewertungspunkt | Erwartung |
|---|---|
| Fachlichkeit | Begriff und Schicht sind korrekt. |
| Evidence | Ein Kommando, Log, TOML/YAML/JSON oder Review-Auszug belegt die Aussage. |
| Risiko | Auswirkung auf Node, Runtime, Registry oder Workload ist beschrieben. |
| Sicherheit | Secrets und produktive Systeme werden ausgeschlossen. |
14. Image-Verifikation
Eine gute Antwort zu Image-Verifikation benennt die konkrete containerd-Ebene, ordnet den Bezug zu OCI, CRI oder Kubernetes ein und liefert mindestens einen reproduzierbaren Nachweis. Sie vermeidet produktive Endpunkte und dokumentiert, ob die Aussage aus einem echten Kommando, einer statischen Konfiguration oder einem Modellartefakt stammt.
| Bewertungspunkt | Erwartung |
|---|---|
| Fachlichkeit | Begriff und Schicht sind korrekt. |
| Evidence | Ein Kommando, Log, TOML/YAML/JSON oder Review-Auszug belegt die Aussage. |
| Risiko | Auswirkung auf Node, Runtime, Registry oder Workload ist beschrieben. |
| Sicherheit | Secrets und produktive Systeme werden ausgeschlossen. |
15. Garbage Collection
Eine gute Antwort zu Garbage Collection benennt die konkrete containerd-Ebene, ordnet den Bezug zu OCI, CRI oder Kubernetes ein und liefert mindestens einen reproduzierbaren Nachweis. Sie vermeidet produktive Endpunkte und dokumentiert, ob die Aussage aus einem echten Kommando, einer statischen Konfiguration oder einem Modellartefakt stammt.
| Bewertungspunkt | Erwartung |
|---|---|
| Fachlichkeit | Begriff und Schicht sind korrekt. |
| Evidence | Ein Kommando, Log, TOML/YAML/JSON oder Review-Auszug belegt die Aussage. |
| Risiko | Auswirkung auf Node, Runtime, Registry oder Workload ist beschrieben. |
| Sicherheit | Secrets und produktive Systeme werden ausgeschlossen. |
16. Upgrade
Eine gute Antwort zu Upgrade benennt die konkrete containerd-Ebene, ordnet den Bezug zu OCI, CRI oder Kubernetes ein und liefert mindestens einen reproduzierbaren Nachweis. Sie vermeidet produktive Endpunkte und dokumentiert, ob die Aussage aus einem echten Kommando, einer statischen Konfiguration oder einem Modellartefakt stammt.
| Bewertungspunkt | Erwartung |
|---|---|
| Fachlichkeit | Begriff und Schicht sind korrekt. |
| Evidence | Ein Kommando, Log, TOML/YAML/JSON oder Review-Auszug belegt die Aussage. |
| Risiko | Auswirkung auf Node, Runtime, Registry oder Workload ist beschrieben. |
| Sicherheit | Secrets und produktive Systeme werden ausgeschlossen. |
17. Incident Response
Eine gute Antwort zu Incident Response benennt die konkrete containerd-Ebene, ordnet den Bezug zu OCI, CRI oder Kubernetes ein und liefert mindestens einen reproduzierbaren Nachweis. Sie vermeidet produktive Endpunkte und dokumentiert, ob die Aussage aus einem echten Kommando, einer statischen Konfiguration oder einem Modellartefakt stammt.
| Bewertungspunkt | Erwartung |
|---|---|
| Fachlichkeit | Begriff und Schicht sind korrekt. |
| Evidence | Ein Kommando, Log, TOML/YAML/JSON oder Review-Auszug belegt die Aussage. |
| Risiko | Auswirkung auf Node, Runtime, Registry oder Workload ist beschrieben. |
| Sicherheit | Secrets und produktive Systeme werden ausgeschlossen. |
18. Evidence
Eine gute Antwort zu Evidence benennt die konkrete containerd-Ebene, ordnet den Bezug zu OCI, CRI oder Kubernetes ein und liefert mindestens einen reproduzierbaren Nachweis. Sie vermeidet produktive Endpunkte und dokumentiert, ob die Aussage aus einem echten Kommando, einer statischen Konfiguration oder einem Modellartefakt stammt.
| Bewertungspunkt | Erwartung |
|---|---|
| Fachlichkeit | Begriff und Schicht sind korrekt. |
| Evidence | Ein Kommando, Log, TOML/YAML/JSON oder Review-Auszug belegt die Aussage. |
| Risiko | Auswirkung auf Node, Runtime, Registry oder Workload ist beschrieben. |
| Sicherheit | Secrets und produktive Systeme werden ausgeschlossen. |
Offizielle Quellen und Abgrenzung
- containerd Dokumentation, Getting Started und Konfiguration: 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 und Shim-Modell: 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/
Dieser Workshop führt keine eigene containerd-API ein. Er ordnet offizielle Konzepte in Labs, Reviewfragen und Betriebsabläufe ein. Wenn eine Datei ein Modell beschreibt, ist sie explizit als Modell oder Lab-Artefakt formuliert.
Praxisanhang: containerd-Nachweisführung für Assessment
Dieser Anhang verbindet das Dokument mit wiederholbarer Runtime-Evidence. Er ist bewusst praktisch formuliert: Jede Aussage soll auf eine konkrete Schicht, ein Artefakt, eine Auswirkung und eine Betriebsentscheidung zurückgeführt werden können.
A.1 Schichtenmodell
containerd muss als Runtime-Schicht verstanden werden: Host, Systemd, containerd-Daemon, Plugins, Content Store, Snapshotter, Runtime v2, Shim, runc, CRI, CNI und Kubernetes erfüllen unterschiedliche Aufgaben.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu Schichtenmodell. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.2 Daemon und Socket
Der containerd-Daemon stellt eine gRPC API über einen Unix Socket bereit. Jede Änderung am Socket, an Rechten oder am Service beeinflusst, welche Werkzeuge und Orchestratoren mit der Runtime sprechen können.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu Daemon und Socket. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.3 Plugin-System
containerd lädt Funktionen über Plugins. CRI, Snapshotter, Diff Service, Content Service, Runtime Task Service und Image-Verifikation müssen anhand der aktiven Plugins bewertet werden.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu Plugin-System. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.4 Content Store
Der Content Store speichert OCI-Inhalte über Digests. Tags sind Namen, Digests sind Inhaltsadressen. Diese Trennung ist zentral für Reproduzierbarkeit und Supply-Chain-Review.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu Content Store. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.5 Snapshotter
Snapshotter erzeugen nutzbare Root Filesystems aus Image-Layern. OverlayFS ist der typische Standard, Remote Snapshotter wie Stargz oder Nydus verändern Startzeit, IO-Verhalten und Fehlermuster.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu Snapshotter. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.6 Container und Task
Ein Container ist ein Metadatenobjekt; eine Task ist die laufende Ausführung. Viele Debuggingfehler entstehen, weil diese beiden Ebenen vermischt werden.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu Container und Task. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.7 Runtime v2 und Shim
containerd startet Container über Runtime-v2-Shims. Der Shim hält IO, Exit-Status und Prozessbezug stabil und entkoppelt laufende Tasks teilweise vom containerd-Daemon.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu Runtime v2 und Shim. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.8 OCI Runtime
runc oder alternative Runtimes implementieren die OCI Runtime Specification. Sie starten den isolierten Prozess mit Namespaces, Mounts, Cgroups und Security-Profilen.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu OCI Runtime. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.9 CRI
Kubernetes spricht nicht direkt ctr, sondern CRI. crictl ist deshalb für Node-Diagnose oft passender als ctr, während ctr tiefer in containerd intern arbeitet.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu CRI. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.10 CNI
containerd selbst ist nicht das komplette Kubernetes-Netzwerk. Beim Pod-Start ruft die CRI-Schicht CNI-Plugins auf, die Netzwerk-Namespace, IPAM, Routen und Portmapping konfigurieren.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu CNI. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.11 Registry und Resolver
Registry-Verhalten wird über Resolver, Host-Namespace und hosts.toml gesteuert. Mirror, TLS, Authentifizierung und Capabilities müssen separat geprüft werden.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu Registry und Resolver. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.12 Cgroups und Systemd
Auf Systemd-Systemen sollten kubelet und Runtime konsistent mit dem Systemd-Cgroup-Modell arbeiten. Gemischte Cgroup-Driver führen zu schwer nachvollziehbaren Node-Problemen.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu Cgroups und Systemd. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.13 Namespaces
containerd-Namespaces sind Metadaten-Namespaces, keine Linux-Namespaces. Kubernetes nutzt typischerweise k8s.io; direkte ctr-Experimente sollten eigene Namespaces verwenden.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu Namespaces. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.14 Rootless
Rootless containerd reduziert bestimmte Host-Risiken, hat aber klare Grenzen bei Netzwerk, Cgroups, Storage und Kubernetes-Integration. Rootless ist ein Betriebsmodell, kein pauschales Sicherheitsversprechen.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu Rootless. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.15 Image Trust
Signaturen, Verifikation, SBOM und Vulnerability-Scanning sind Supply-Chain-Kontrollen. Sie müssen vor Pull, vor Start oder über Admission-/Policy-Mechanismen in den Prozess eingebunden werden.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu Image Trust. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.16 Security Profile
Seccomp, AppArmor, SELinux, Capabilities und RuntimeClass begrenzen Containerverhalten. Diese Kontrollen ergänzen sich, ersetzen aber weder sichere Images noch Host-Härtung.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu Security Profile. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.17 Garbage Collection
Garbage Collection darf nicht nur freien Speicher betrachten. Content, Snapshots, Images, Container, Tasks und Leases müssen gemeinsam bewertet werden, damit keine aktiven Workloads beschädigt werden.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu Garbage Collection. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.18 Observability
Gute Runtime-Diagnose sammelt Versionen, Service-Status, Logs, Events, Plugins, Namespaces, Registry-Fehler, Snapshotter-Zustand und CRI-Ausgaben als zusammenhängendes Evidence-Paket.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu Observability. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.19 Upgrade und Rollback
Runtime-Upgrades betreffen laufende Workloads und Kubernetes Nodes. Ein sauberer Ablauf enthält Backup, Drain, Versionstest, Service-Restart, Smoke-Test, Rollback und Post-Change-Review.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu Upgrade und Rollback. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.20 Incident Response
Registry-Ausfall, TLS-Fehler, Pull-Rate-Limits, beschädigte Snapshots oder Runtime-Fehler brauchen getrennte Runbooks. Ein Incident ist erst abgeschlossen, wenn Ursache, Workaround, Fix und Prävention dokumentiert sind.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu Incident Response. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.21 Modell und Realität
Viele Beispiele sind sichere Modelle. Der Transfer auf echte Nodes braucht zusätzliche Prüfung: Distribution, containerd-Version, Kubernetes-Version, CNI, Registry, Security-Policy und Change-Prozess.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu Modell und Realität. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.22 Evidence
Evidence enthält Befehlsausgaben, Konfigurationen, Logs, Hashes, Versionen und Reviewnotizen. Sie enthält keine produktiven Secrets, Tokens, Client-Zertifikate oder Pull-Credentials.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu Evidence. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.23 Performance
Performance hängt von Snapshotter, Registry-Latenz, Layer-Struktur, Deduplizierung, Dateisystem, IO, CPU, Cgroups und Remote-Snapshottern ab. Jede Optimierung braucht ein Messziel.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu Performance. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.24 Produktionsübertrag
Der Produktionsübertrag ist kein Kopieren von Lab-Dateien. Er braucht Ownership, Change Ticket, Rollback, Monitoring, Security-Freigabe, Wartungsfenster und dokumentierte Abnahmekriterien.
Diese Perspektive muss im Review konkret werden. Ein allgemeiner Satz wie "Runtime prüfen" reicht nicht; erwartet wird eine nachweisbare Beobachtung mit Werkzeug, Datei, Risiko und Entscheidung.
| Prüffeld | Erwartung |
|---|---|
| Kontext | 02-intermediate-containerd-solution-DE.md benennt den Bezug zu Produktionsübertrag. |
| Nachweis | Kommandoausgabe, TOML, YAML, JSON, Log oder Runbook ist vorhanden. |
| Betriebswirkung | Auswirkung auf Pods, Images, Snapshots, Registry, Netzwerk oder Node ist beschrieben. |
| Sicherheitswirkung | Secrets, Privilegien, Runtime-Rechte und Host-Grenzen sind geprüft. |
Konkrete Reviewfragen:
- Welche Runtime-Schicht ist betroffen?
- Welche Datei oder Ausgabe belegt die Aussage?
- Ist das Verhalten direkt containerd, CRI, OCI, CNI oder Kubernetes?
- Welche Änderung wäre auf einem produktiven Node riskant?
- Welche Rollback-Möglichkeit existiert?
- Welche Evidence darf keine Secrets enthalten?
- Welche Versionen müssen genannt werden?
- Welche Abnahme beweist den Erfolg?
Typische Evidence:
evidence/
tooling.txt
runtime-layer.md
config-or-model.txt
risk-note.md
rollback.md
A.25 Minimaler Abschlussnachweis
- containerd-, ctr- und runc-Versionen sind dokumentiert, soweit installiert.
- Der Scope ist klar als Modell, lokaler Host oder Kubernetes-Node beschrieben.
- TOML, YAML, JSON und Shell-Artefakte sind syntaktisch validiert.
- Registry-, Runtime-, Snapshotter- oder CRI-Änderungen haben eine Rollback-Notiz.
- Evidence enthält keine produktiven Zugangsdaten.
- Offizielle Quellen sind referenziert und nicht durch erfundene Annahmen ersetzt.