08 CRI und Pod Sandbox
Dieses Beispiel ist Teil des containerd-Workshops und folgt dem Format der Kubernetes-Beispiele: ein Haupt-README, Detaildokumentation auf Deutsch, Englisch und Griechisch sowie kleine prüfbare Artefakte.
1. Ziel
crictl-Konfiguration, Pod Sandbox und Containerstatus werden als Kubernetes-Node-Diagnose modelliert.
Das Beispiel ist als isoliertes Lab oder Modell aufgebaut. Es verändert keine produktive Runtime-Konfiguration und schreibt Laufzeitergebnisse ausschließlich nach work/.
2. Voraussetzungen
- Linux, WSL, VM oder vergleichbare Testumgebung.
python3für JSON/TOML/YAML-Validierung.- Optional
containerd,ctr,runc,nerdctlundcrictlfür zusätzliche Evidence. - Keine produktiven Nodes, Registries, Credentials oder Pull Secrets verwenden.
3. Dateien
README.mdREADME-EL.mddocs/de/README.mddocs/en/README.mddocs/el/README.mdrun.shcri/crictl.yamlcri/pod-sandbox.json
4. Ausführung
cd examples/08-cri-crictl-sandbox
chmod +x run.sh
./run.sh
find work -maxdepth 3 -type f | sort
5. Erwartetes Ergebnis
run.shendet mit Exit-Code0.- TOML, JSON und YAML werden syntaktisch geprüft.
- Shell-Skripte werden mit
bash -ngeprüft. - Wenn containerd lokal verfügbar ist, werden Version und optional
ctr-Evidence gesammelt. - Alle Laufzeitartefakte entstehen unter
work/.
6. Erklärung
containerd-Arbeit muss sauber zwischen mehreren Ebenen unterscheiden: Host, containerd-Daemon, API, Content Store, Snapshotter, Runtime, CRI, CNI und Kubernetes. Dieses Beispiel isoliert genau einen Ausschnitt davon und macht die Reviewfragen nachvollziehbar.
7. Typische Fehler
| Fehler | Ursache | Diagnose |
|---|---|---|
ctr zeigt keine Kubernetes-Images |
falscher containerd-Namespace | ctr namespaces ls, ctr -n k8s.io images ls |
| Pull schlägt fehl | Registry, TLS, Auth oder Mirror | hosts.toml, Logs, Resolver prüfen |
| Pod startet nicht | CRI, CNI, Snapshotter oder Runtime | crictl, journalctl, Events prüfen |
| Config wirkt korrekt, wird aber ignoriert | falsche Plugin-ID oder falscher Pfad | containerd config dump, Version prüfen |
| Disk Pressure | Content, Snapshots, Leases oder Logs | ctr content ls, ctr snapshots ls, ctr leases ls |
8. Sicherheitsaspekte
- Keine produktiven Sockets, Registry-Credentials oder Cluster-Endpunkte in Labs eintragen.
- Registry-TLS nicht mit
skip_verify = truekaschieren, außer als klar markiertes Negativbeispiel. - Sandbox-Runtimes, Seccomp und AppArmor sind zusätzliche Kontrollen, kein Ersatz für sichere Images.
- Runtime-Konfigurationsänderungen auf Kubernetes-Nodes brauchen Drain, Rollback und Abnahme.
9. Review und Evidence
Eine vollständige Abgabe enthält mindestens:
work/evidence/
tooling.txt
result.txt
config-review.txt
risk-note.md
cleanup.md
Nicht jede Datei entsteht in jedem Beispiel. Entscheidend ist, dass die Evidence zum Lernziel passt und keine Geheimnisse enthält.
10. Erweiterungsmöglichkeiten
- Beispiel mit echter Test-Registry erweitern.
- CRI-Ausgaben aus einem Lab-Node ergänzen.
- RuntimeClass-Variante für Kata oder gVisor hinzufügen.
- Image-Verifikation mit Cosign oder Notation als separates Lab ergänzen.
- Evidence in CI gegen TOML/JSON/YAML validieren.
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.