containerd Examples
Diese Beispiele folgen dem Format der Kubernetes-Workshop-Beispiele. Jedes Beispiel besitzt ein Haupt-README, deutsche und englische Detaildokumentation sowie sichere, prüfbare Artefakte.
Alle Laufzeitergebnisse entstehen unter work/ und werden nicht versioniert.
cd examples/00-lab-skeleton
./run.sh
find work -maxdepth 3 -type f | sort
Offizielle Referenzen
- containerd Dokumentation: https://containerd.io/docs/2.3/getting-started/
- containerd Registry-Konfiguration: 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
Beispielanhang: Evidence, Betrieb und Transfer
Dieser Zusatzteil macht das Beispiel als Trainingsbaustein vollständig. Er beschreibt, wie aus einem lokalen Modell eine belastbare Runtime-Analyse entsteht, ohne produktive Nodes oder Zugangsdaten zu berühren.
B.1 Scope bestimmen
Scope bestimmen ist für dieses Beispiel notwendig, weil containerd-Labs sonst leicht von einem sicheren Modell zu einer unkontrollierten Node-Änderung werden. Die Bewertung muss klar sagen, ob ein Artefakt nur erklärt, lokal prüft oder auf einem echten Node angewendet würde.
| Frage | Erwartung |
|---|---|
| Was ist betroffen? | Host, Daemon, Plugin, Content, Snapshotter, Runtime, CRI, CNI oder Kubernetes ist genannt. |
| Was ist belegt? | Eine Datei oder Ausgabe unter work/evidence/ zeigt den Befund. |
| Was bleibt offen? | Voraussetzungen für echte Nodes sind als Grenze dokumentiert. |
Reviewpunkte:
- keine produktiven Secrets
- keine ungeprüften Socket- oder Systemd-Änderungen
- keine Registry-Ausnahmen ohne Begründung
- keine Verwechslung von
ctr,crictlundnerdctl - Cleanup durch Entfernen von
work/möglich
B.2 Artefakte validieren
Artefakte validieren ist für dieses Beispiel notwendig, weil containerd-Labs sonst leicht von einem sicheren Modell zu einer unkontrollierten Node-Änderung werden. Die Bewertung muss klar sagen, ob ein Artefakt nur erklärt, lokal prüft oder auf einem echten Node angewendet würde.
| Frage | Erwartung |
|---|---|
| Was ist betroffen? | Host, Daemon, Plugin, Content, Snapshotter, Runtime, CRI, CNI oder Kubernetes ist genannt. |
| Was ist belegt? | Eine Datei oder Ausgabe unter work/evidence/ zeigt den Befund. |
| Was bleibt offen? | Voraussetzungen für echte Nodes sind als Grenze dokumentiert. |
Reviewpunkte:
- keine produktiven Secrets
- keine ungeprüften Socket- oder Systemd-Änderungen
- keine Registry-Ausnahmen ohne Begründung
- keine Verwechslung von
ctr,crictlundnerdctl - Cleanup durch Entfernen von
work/möglich
B.3 Runtime-Schicht benennen
Runtime-Schicht benennen ist für dieses Beispiel notwendig, weil containerd-Labs sonst leicht von einem sicheren Modell zu einer unkontrollierten Node-Änderung werden. Die Bewertung muss klar sagen, ob ein Artefakt nur erklärt, lokal prüft oder auf einem echten Node angewendet würde.
| Frage | Erwartung |
|---|---|
| Was ist betroffen? | Host, Daemon, Plugin, Content, Snapshotter, Runtime, CRI, CNI oder Kubernetes ist genannt. |
| Was ist belegt? | Eine Datei oder Ausgabe unter work/evidence/ zeigt den Befund. |
| Was bleibt offen? | Voraussetzungen für echte Nodes sind als Grenze dokumentiert. |
Reviewpunkte:
- keine produktiven Secrets
- keine ungeprüften Socket- oder Systemd-Änderungen
- keine Registry-Ausnahmen ohne Begründung
- keine Verwechslung von
ctr,crictlundnerdctl - Cleanup durch Entfernen von
work/möglich
B.4 Kubernetes-Bezug prüfen
Kubernetes-Bezug prüfen ist für dieses Beispiel notwendig, weil containerd-Labs sonst leicht von einem sicheren Modell zu einer unkontrollierten Node-Änderung werden. Die Bewertung muss klar sagen, ob ein Artefakt nur erklärt, lokal prüft oder auf einem echten Node angewendet würde.
| Frage | Erwartung |
|---|---|
| Was ist betroffen? | Host, Daemon, Plugin, Content, Snapshotter, Runtime, CRI, CNI oder Kubernetes ist genannt. |
| Was ist belegt? | Eine Datei oder Ausgabe unter work/evidence/ zeigt den Befund. |
| Was bleibt offen? | Voraussetzungen für echte Nodes sind als Grenze dokumentiert. |
Reviewpunkte:
- keine produktiven Secrets
- keine ungeprüften Socket- oder Systemd-Änderungen
- keine Registry-Ausnahmen ohne Begründung
- keine Verwechslung von
ctr,crictlundnerdctl - Cleanup durch Entfernen von
work/möglich
B.5 Security-Grenzen festhalten
Security-Grenzen festhalten ist für dieses Beispiel notwendig, weil containerd-Labs sonst leicht von einem sicheren Modell zu einer unkontrollierten Node-Änderung werden. Die Bewertung muss klar sagen, ob ein Artefakt nur erklärt, lokal prüft oder auf einem echten Node angewendet würde.
| Frage | Erwartung |
|---|---|
| Was ist betroffen? | Host, Daemon, Plugin, Content, Snapshotter, Runtime, CRI, CNI oder Kubernetes ist genannt. |
| Was ist belegt? | Eine Datei oder Ausgabe unter work/evidence/ zeigt den Befund. |
| Was bleibt offen? | Voraussetzungen für echte Nodes sind als Grenze dokumentiert. |
Reviewpunkte:
- keine produktiven Secrets
- keine ungeprüften Socket- oder Systemd-Änderungen
- keine Registry-Ausnahmen ohne Begründung
- keine Verwechslung von
ctr,crictlundnerdctl - Cleanup durch Entfernen von
work/möglich
B.6 Rollback formulieren
Rollback formulieren ist für dieses Beispiel notwendig, weil containerd-Labs sonst leicht von einem sicheren Modell zu einer unkontrollierten Node-Änderung werden. Die Bewertung muss klar sagen, ob ein Artefakt nur erklärt, lokal prüft oder auf einem echten Node angewendet würde.
| Frage | Erwartung |
|---|---|
| Was ist betroffen? | Host, Daemon, Plugin, Content, Snapshotter, Runtime, CRI, CNI oder Kubernetes ist genannt. |
| Was ist belegt? | Eine Datei oder Ausgabe unter work/evidence/ zeigt den Befund. |
| Was bleibt offen? | Voraussetzungen für echte Nodes sind als Grenze dokumentiert. |
Reviewpunkte:
- keine produktiven Secrets
- keine ungeprüften Socket- oder Systemd-Änderungen
- keine Registry-Ausnahmen ohne Begründung
- keine Verwechslung von
ctr,crictlundnerdctl - Cleanup durch Entfernen von
work/möglich
B.7 Evidence bereinigen
Evidence bereinigen ist für dieses Beispiel notwendig, weil containerd-Labs sonst leicht von einem sicheren Modell zu einer unkontrollierten Node-Änderung werden. Die Bewertung muss klar sagen, ob ein Artefakt nur erklärt, lokal prüft oder auf einem echten Node angewendet würde.
| Frage | Erwartung |
|---|---|
| Was ist betroffen? | Host, Daemon, Plugin, Content, Snapshotter, Runtime, CRI, CNI oder Kubernetes ist genannt. |
| Was ist belegt? | Eine Datei oder Ausgabe unter work/evidence/ zeigt den Befund. |
| Was bleibt offen? | Voraussetzungen für echte Nodes sind als Grenze dokumentiert. |
Reviewpunkte:
- keine produktiven Secrets
- keine ungeprüften Socket- oder Systemd-Änderungen
- keine Registry-Ausnahmen ohne Begründung
- keine Verwechslung von
ctr,crictlundnerdctl - Cleanup durch Entfernen von
work/möglich
B.8 Transfer begrenzen
Transfer begrenzen ist für dieses Beispiel notwendig, weil containerd-Labs sonst leicht von einem sicheren Modell zu einer unkontrollierten Node-Änderung werden. Die Bewertung muss klar sagen, ob ein Artefakt nur erklärt, lokal prüft oder auf einem echten Node angewendet würde.
| Frage | Erwartung |
|---|---|
| Was ist betroffen? | Host, Daemon, Plugin, Content, Snapshotter, Runtime, CRI, CNI oder Kubernetes ist genannt. |
| Was ist belegt? | Eine Datei oder Ausgabe unter work/evidence/ zeigt den Befund. |
| Was bleibt offen? | Voraussetzungen für echte Nodes sind als Grenze dokumentiert. |
Reviewpunkte:
- keine produktiven Secrets
- keine ungeprüften Socket- oder Systemd-Änderungen
- keine Registry-Ausnahmen ohne Begründung
- keine Verwechslung von
ctr,crictlundnerdctl - Cleanup durch Entfernen von
work/möglich
B.9 Review abschließen
Review abschließen ist für dieses Beispiel notwendig, weil containerd-Labs sonst leicht von einem sicheren Modell zu einer unkontrollierten Node-Änderung werden. Die Bewertung muss klar sagen, ob ein Artefakt nur erklärt, lokal prüft oder auf einem echten Node angewendet würde.
| Frage | Erwartung |
|---|---|
| Was ist betroffen? | Host, Daemon, Plugin, Content, Snapshotter, Runtime, CRI, CNI oder Kubernetes ist genannt. |
| Was ist belegt? | Eine Datei oder Ausgabe unter work/evidence/ zeigt den Befund. |
| Was bleibt offen? | Voraussetzungen für echte Nodes sind als Grenze dokumentiert. |
Reviewpunkte:
- keine produktiven Secrets
- keine ungeprüften Socket- oder Systemd-Änderungen
- keine Registry-Ausnahmen ohne Begründung
- keine Verwechslung von
ctr,crictlundnerdctl - Cleanup durch Entfernen von
work/möglich
B.10 Cleanup durchführen
Cleanup durchführen ist für dieses Beispiel notwendig, weil containerd-Labs sonst leicht von einem sicheren Modell zu einer unkontrollierten Node-Änderung werden. Die Bewertung muss klar sagen, ob ein Artefakt nur erklärt, lokal prüft oder auf einem echten Node angewendet würde.
| Frage | Erwartung |
|---|---|
| Was ist betroffen? | Host, Daemon, Plugin, Content, Snapshotter, Runtime, CRI, CNI oder Kubernetes ist genannt. |
| Was ist belegt? | Eine Datei oder Ausgabe unter work/evidence/ zeigt den Befund. |
| Was bleibt offen? | Voraussetzungen für echte Nodes sind als Grenze dokumentiert. |
Reviewpunkte:
- keine produktiven Secrets
- keine ungeprüften Socket- oder Systemd-Änderungen
- keine Registry-Ausnahmen ohne Begründung
- keine Verwechslung von
ctr,crictlundnerdctl - Cleanup durch Entfernen von
work/möglich
B.11 Abschluss
Ein Beispiel gilt als fertig, wenn das Skript erfolgreich läuft, alle Modellartefakte syntaktisch gültig sind, die betroffene Runtime-Schicht benannt ist und die Evidence keine vertraulichen Daten enthält.