Orthevs Orthevs Fathom new horizons
Μενού

Wiki workshop · Γερμανικά και αγγλικά

11 CNI-Bridge-Modell

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.

Γλώσσα περιεχομένου · Γερμανικά και αγγλικάΜέγεθος · 12.9 KBexamples/11-cni-bridge-model/README.md
Παραδείγματα workshop σε ZIP
Πρόοδος μάθησης στη web app

Σημειώστε κεφάλαια ως αναγνωσμένα, δείτε την πρόοδο ανάγνωσης και ολοκληρώστε πρακτικές ενότητες αφού ενεργοποιήσετε την προαιρετική web app. Η πρόοδος του workshop υπολογίζεται από τα κεφάλαια όλων των σελίδων τεκμηρίωσης. Οι επιλογές μένουν σε αυτή τη συσκευή· δεν υπάρχει λογαριασμός ή συγχρονισμός με server. Δεν απαιτείται εγκατάσταση. Η ανάκληση στις Ρυθμίσεις απορρήτου διαγράφει την πρόοδο.

Πρόοδος ανάγνωσης0%
0%
0 / 11 κεφάλαια που διαβάστηκαν
Άλλη γλωσσική έκδοσηΕλληνικά ↗

11 CNI-Bridge-Modell

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

Eine CNI-Conflist zeigt Bridge, Host-Local-IPAM und Portmap als Pod-Netzwerkbasis.

Das Beispiel ist als isoliertes Lab oder Modell aufgebaut. Es verändert keine produktive Runtime-Konfiguration und schreibt Laufzeitergebnisse ausschließlich nach work/.

01 / 11

2. Voraussetzungen

  • Linux, WSL, VM oder vergleichbare Testumgebung.
  • python3 für JSON/TOML/YAML-Validierung.
  • Optional containerd, ctr, runc, nerdctl und crictl für zusätzliche Evidence.
  • Keine produktiven Nodes, Registries, Credentials oder Pull Secrets verwenden.
02 / 11

3. Dateien

  • README.md
  • README-EL.md
  • docs/de/README.md
  • docs/en/README.md
  • docs/el/README.md
  • run.sh
  • cni/10-containerd-bridge.conflist
03 / 11

4. Ausführung

bash
cd examples/11-cni-bridge-model
chmod +x run.sh
./run.sh
find work -maxdepth 3 -type f | sort
04 / 11

5. Erwartetes Ergebnis

  • run.sh endet mit Exit-Code 0.
  • TOML, JSON und YAML werden syntaktisch geprüft.
  • Shell-Skripte werden mit bash -n geprüft.
  • Wenn containerd lokal verfügbar ist, werden Version und optional ctr-Evidence gesammelt.
  • Alle Laufzeitartefakte entstehen unter work/.
05 / 11

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.

06 / 11

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
07 / 11

8. Sicherheitsaspekte

  • Keine produktiven Sockets, Registry-Credentials oder Cluster-Endpunkte in Labs eintragen.
  • Registry-TLS nicht mit skip_verify = true kaschieren, 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.
08 / 11

9. Review und Evidence

Eine vollständige Abgabe enthält mindestens:

text
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.

09 / 11

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.
10 / 11

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, crictl und nerdctl
  • 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, crictl und nerdctl
  • 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, crictl und nerdctl
  • 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, crictl und nerdctl
  • 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, crictl und nerdctl
  • 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, crictl und nerdctl
  • 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, crictl und nerdctl
  • 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, crictl und nerdctl
  • 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, crictl und nerdctl
  • 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, crictl und nerdctl
  • 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.

11 / 11

CTR · Orthevs Academy

31 modules ως ενιαία διαδρομή μάθησης.

Η σειρά παραμένει αμετάβλητη: από τη βασική δομή του lab μέσω τεχνικών θεμελίων και λειτουργικών μοντέλων έως το τελικό troubleshooting. Τα τεχνικά ονόματα καταλόγων διατηρούνται σκόπιμα.

Πρακτικά modules

Το Orthevs ως εφαρμογή

Εγκατάσταση του Orthevs

Η web app του Orthevs μπορεί να εγκατασταθεί σε υποστηριζόμενες κινητές συσκευές και browsers υπολογιστή.

iPhone και iPad

Ανοίξτε το Orthevs στο Safari. Πατήστε Κοινή χρήση και μετά Προσθήκη στην οθόνη αφετηρίας. Ενεργοποιήστε το Άνοιγμα ως web app, αν εμφανίζεται, και πατήστε Προσθήκη.

Android

Για τη web app, ανοίξτε το μενού του browser και επιλέξτε Εγκατάσταση εφαρμογής ή Προσθήκη στην αρχική οθόνη. Επιβεβαιώστε την εγκατάσταση.

Browser υπολογιστή

Ανοίξτε το μενού του browser ή το εικονίδιο εγκατάστασης στη γραμμή διευθύνσεων και επιλέξτε Εγκατάσταση εφαρμογής ή Προσθήκη στο Dock.

Η εγκατάσταση της web app εξαρτάται από τον browser. Αν δεν εμφανιστεί διάλογος εγκατάστασης, ακολουθήστε τα βήματα του browser που αναφέρονται παραπάνω.