17 nerdctl-Workflow
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
nerdctl wird als nutzerfreundliche CLI über containerd eingeordnet, ohne Docker Engine zu verwechseln.
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.shcommands/nerdctl-workflow.shcompose/compose.yaml
4. Ausführung
cd examples/17-nerdctl-workflow
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.