Gewinne:
- Fähigkeit, die grundlegenden Objekte (Pod, Deployment, Service, ConfigMap, Secret, Namespace) und die deklarative Philosophie von Kubernetes zu verstehen und solide Manifeste für künstliche Intelligenz zu erstellen
- Möglichkeit, Manifeste produktionsbereit zu machen und mit Ressourcenlimits, Integritätsprüfungen (Probes), festen Bild-Tags und engem RBAC zu sichern
- Fähigkeit, vor der Ausführung den korrekten Kontext zu überprüfen und mit dry-run/diff Probelauf-Disziplin anzuwenden
Es ist einfach, einen Container zu betreiben. Aber ein System einrichten, das Hunderte von Containern auf Dutzende Server verteilt, automatisch neu startet, wenn einer von ihnen abstürzt, es repliziert, wenn die Last steigt, und es ohne Ausfallzeiten aktualisiert? Das ist Orchestrierung, und das branchenübliche Standardtool ist Kubernetes (kurz K8s) – die Plattform, die Container automatisch in einem Cluster bereitstellt, skaliert und verwaltet. Kubernetes ist leistungsstark, aber komplex: Alles wird durch lange, einrückungsempfindliche YAML-Dateien – sogenannte Manifeste – definiert. Hier sorgt KI für frischen Wind; Mit dem richtigen Kontext werden diese Manifeste schnell erstellt und ihre mysteriösen Fehler entschlüsselt.
Aber in Kubernetes bedeutet ein falsches Manifest, dass ein gesamter Dienst nicht bereitgestellt werden kann, eine falsche Skalierung vorliegt oder eine Schwachstelle verbleibt. Es liegt in Ihrer Verantwortung, jedes von der KI erzeugte Manifest zu verstehen und zu überprüfen – insbesondere vor der Anwendung von kubectl.
Kubernetes-Kernobjekte
Um Kubernetes zu prüfen, sollten Sie die Hauptkonzepte kennen:
- Pod: Kleinste Arbeitseinheit; Es enthält einen oder mehrere Container. Im Allgemeinen wird der Pod nicht direkt verwendet, sondern die übergeordneten Objekte, die ihn verwalten.
- Bereitstellung: Definiert, wie viele Kopien einer Anwendung ausgeführt werden, welches Image sie verwendet und wie sie aktualisiert wird. Wenn ein Pod abstürzt, wird er automatisch neu erstellt.
- Dienst: Stellt eine feste Netzwerkadresse und Lastausgleich für die Pods bereit; Auch wenn Pods kommen und gehen, ändert sich die Zugriffsadresse nicht.
- ConfigMap und Secret: Hält Konfigurationswerte und geheime Informationen von Pods getrennt. ConfigMap ist für explizite Einstellungen, Secret für sensible Werte.
- Namespace: Der Bereich, der Ressourcen logisch unterteilt und isoliert (z. B. dev, prod).
- Ingress: Der Regelsatz, der HTTP-Verkehr von der Außenwelt an Dienste im Cluster weiterleitet.
Helm ist der „Paketmanager“ von Kubernetes: Er ermöglicht es Ihnen, wiederkehrende Manifeste (Diagramme) als Vorlage zu erstellen und diese mit unterschiedlichen Werten in verschiedenen Umgebungen mit einem einzigen Befehl zu installieren. AI erstellt sowohl Rohmanifest als auch Helm-Diagramm.
Warum gibt es so viele Objekte? Denn die Kernphilosophie von Kubernetes ist deklarativ: Sie definieren, „wie das System letztendlich aussehen soll“ (z. B. „Immer drei Kopien dieser Anwendung laufen“), während Kubernetes den aktuellen Zustand kontinuierlich näher an den gewünschten Zustand verschiebt. Wenn ein Pod stirbt, erstellt er einen neuen; Wenn ein Knoten ausfällt, wird die Arbeitslast auf einen anderen Knoten verlagert. Aus diesem Grund sind Manifeste keine „Tun“-Befehle, sondern „Lass es so sein“-Rezepte. Das Erfassen dieser Unterscheidung ist von entscheidender Bedeutung, wenn man die von der KI erzeugten Manifeste liest: Jede Domäne beschreibt einen Teil des gewünschten Zustands des Systems. Eine falsche Domäne bedeutet, dass Kubernetes auf ein falsches Ziel hinarbeitet – und dieses Ziel stillschweigend und beharrlich durchgesetzt wird.
Tipp: In Kubernetes ist kubectl apply --dry-run=server -f file.yaml das wichtigste sichere Testtool: Es zeigt an, ob der Server akzeptiert und was zu tun ist, ohne das Manifest tatsächlich anzuwenden. Stellen Sie sicher, dass Sie dry-run und kubectl diff ausführen, bevor Sie ein Manifest auf prod anwenden.
Schritt für Schritt: Manifeste mit KI erstellen
- Beschreiben Sie die Anwendung und den Bedarf. Image-Name, Port, Anzahl der Replikate, Ressourcenlimits (CPU/Speicher).
- Fordern Sie Bereitstellung + Service an. Normalerweise ist beides zusammen erforderlich.
- Separate Konfiguration und Geheimnis. Einstellungen auf ConfigMap, sensible Werte auf Secret.
- Fügen Sie Gesundheitsprüfungen hinzu. LivenessProbe (ist es live) und ReadinessProbe (ist es für den Datenverkehr bereit) sind von entscheidender Bedeutung.
- Legen Sie ein Ressourcenlimit fest. Ohne Anfragen/Limits kann ein Pod den gesamten Knoten verbrauchen.
- Mit „--dry-run“ und „diff“ überprüfen und dann anwenden. Zuerst im Test-Namespace.
Sicherheit: Kubernetes-spezifische Risiken
- Geheimnis ist nicht wirklich geheim – es ist nur base64. Das Kubernetes Secret-Objekt base64 kodiert Werte; Dies ist keine Verschlüsselung, es ist leicht zu entschlüsseln. Für echten Datenschutz sind etcd-Verschlüsselung und ein externer Tresor (Vault, Cloud Secret Manager) erforderlich. Übertragen Sie geheime Manifeste niemals direkt an Git (es gibt hierfür Lösungen wie Sealed Secrets/External Secrets).
- Legen Sie ein Ressourcenlimit fest. Ein Pod ohne Einschränkungen kann den gesamten Knoten mit einem Speicherverlust zum Absturz bringen.
- Mindestautorität (RBAC). Mit der rollenbasierten Zugriffskontrolle verfügt jeder Dienst/Benutzer nur über die Berechtigungen, die er benötigt. KI gibt manchmal großen Cluster-Administrator; Grenzen Sie dies ein.
- Verwenden Sie nicht das Bild-Tag „latest“. Sie wissen nicht, welche Version ausgeführt wird, und können sie nicht zurücksetzen.
Achtung: Das Löschen von kubectl oder eine falsche Anwendung kann eine Live-Bereitstellung zerstören. Stellen Sie sicher, dass Sie überprüfen, in welchem Namespace Sie sich befinden (kubectl config current-context), bevor Sie die Befehle ausführen. Arbeitsunfälle sind im Produktionskontext eine häufige Katastrophe.
Rohmanifest vs. Helm-Tabelle
Kriterium
Rohes YAML-Manifest
Helmkarte
Installation
kubectl apply -f
Helm installieren
Multimedia (Entwicklung/Produktion)
Kopieren und Einfügen, fehleranfällig
Einzelnes Diagramm, verschiedene Werte.yaml
Version/Rollback
von Hand
einfach mit Helm-Rollback
Lernkurve
niedrig
mittel
wann
Kleine, einzelne Umgebung
Multimedialer, sich wiederholender Service
drei Mini-Koffer
Fall 1 – das Geheimnis des abgestürzten Dienstes. Ein Pod wurde ständig neu gestartet (CrashLoopBackOff). Das Team gab die Protokolle und das Manifest an die KI weiter; Die KI zeigte, dass der Pod nie als „bereit“ galt, da die readinessProbe auf den falschen Port schaute. Sie reparierten den Port, der Dienst war innerhalb von 10 Minuten stabil. Das manuelle Einrichten dieser Beziehung kann Stunden dauern.
Fall 2 – keine Grenzen zu setzen, hat den Knoten geplatzt. Bei einem Einsatz gab es keine Grenzen; Ein Speicherverlust hat den Pod aufgebläht und den gesamten Knoten zum Absturz gebracht, wodurch auch benachbarte Dienste zum Erliegen kamen. Nach dem Vorfall forderten sie die KI auf, „allen Bereitstellungen angemessene CPU-/Speicheranforderungen und -beschränkungen hinzuzufügen“ und machten dies zum Standard. Eine fehlende Leitung kostete stundenlange Ausfallzeit.
Fall 3 – großes RBAC erfasst. Bei einer Untersuchung wurde festgestellt, dass ein von AI generiertes ServiceAccount-Manifest mit der Cluster-Administratorrolle verknüpft war – was bedeutete, dass der Dienst den gesamten Cluster verwalten konnte. Das Team hat die Berechtigung darauf beschränkt, nur Pods in ihrem Namensraum zu lesen. Das Prinzip der geringsten Rechte schloss eine Sicherheitslücke.
Vier kopierbare Vorlagen
1) Bereitstellung + Serviceproduktion:
Schreiben Sie ein Bereitstellungs- und Servicemanifest für Kubernetes. Anwendung: [AD], Bild: [Bild: feste Version], Port: [X], Replik: [N]. Regeln: - CPU-/Speicheranforderungen und -beschränkungen hinzufügen. - LivenessProbe und ReadinessProbe definieren. - Konfiguration aus ConfigMap lesen, Geheimnis aus Secret-Objekt; Betten Sie keine Werte in das Manifest ein, sondern verwenden Sie Platzhalter. - Verwenden Sie KEIN Bild-Tag „:latest“. Mit Beschreibung angeben.
2) Lösung manifester Fehler:
Der aktuelle Pod befindet sich im Status [CrashLoopBackOff / Pending / ImagePullBackOff]. Listen Sie gemäß dem folgenden Manifest und der Ausgabe von „kubectl discover“ die möglichen Grundursachen in der Reihenfolge ihrer Wahrscheinlichkeit auf und geben Sie für jede den Verifizierungsbefehl aus. Manifestieren: [YAML] Beschreiben: [OUTPUT]
3) Sicherheits-/Integritätsprüfung:
Überprüfen Sie dieses Kubernetes-Manifest: Fehlt das Ressourcenlimit, fehlt ein Problem, gibt es ein :latest-Tag, gibt es eine zu weit gefasste RBAC/Berechtigung, ist das Geheimnis im Manifest eingebettet? Schreiben Sie die Ergebnisse in der Reihenfolge ihrer Wichtigkeit und mit Korrektur auf. Manifest: [YAML]
4) Konvertierung in Helm-Diagramm:
Konvertieren Sie die folgenden Rohmanifeste in ein wiederverwendbares Helm-Diagramm: Welche Werte sollen an die Datei „values.yaml“ gesendet werden (Bild, Replikat, Quelle, Umgebung)? Diagrammstruktur und Beispielwerte anzeigen.yaml.Manifests: [YAML]
Schwache Eingabeaufforderung / Starke Eingabeaufforderung
Schwach: „Schreibe Kubernetes YAML für meine Anwendung.“
Ergebnis: eine No-Probe-No-Limit-Bereitstellung mit dem Tag „:latest“, die die geheime Ebene einbettet; Unsicher und zerbrechlich im Produkt.
Stark: „Schreiben Sie Kubernetes Deployment + Service. Image myapp:1.4.2, 3 Replikate, 8080 Ports. CPU 100 - 500 m, Arbeitsspeicher 128 Mi-512 Mi. Fügen Sie Anfragen/Limits hinzu. Setzen Sie einen Liveness-Test für /healthz, einen Bereitschaftstest für /ready. Lesen Sie das Geheimnis aus dem Secret-Objekt, betten Sie es nicht in das Manifest ein. Geben Sie es mit einer Beschreibung an.“
Unterschied: Die zweite Eingabeaufforderungsversion gibt Skalierung, Ressourcenlimits, Gesundheitsprüfungen und geheime Regeln an. Die Ausgabe ist produktionsnah und sicher.
Häufige Fehler
- Es werden keine Ressourcenlimits festgelegt. Ein einzelner Pod kann den gesamten Knoten verbrauchen.
- Keine Gesundheitsprüfung (Sonde) hinzugefügt. Kubernetes kann einen abgestürzten/nicht bereiten Pod nicht erkennen.
- `:latest`-Tag. Es wird unklar, welche Version läuft, ein Rollback ist nicht möglich.
- Das Geheimnis direkt an Git übergeben. Base64 ist keine Verschlüsselung; Jeder löst es.
- Befehle im falschen Kontext/Namespace ausführen. Die häufigste Ursache für einen Produktabsturz.
- Überspringen von „--dry-run“/„diff“. Ich sehe nicht, was vor der Umsetzung passieren wird.
Zusammenfassend
Kubernetes ist ein leistungsstarker, aber komplexer Orchestrator, der Container in einem Cluster automatisch bereitstellt, skaliert und optimiert. Alles wird durch manifeste YAMLs definiert, die Helm als Vorlagen erstellt. KI erstellt schnell Bereitstellungs-/Dienstmanifeste und Helm-Diagramme und löst mysteriöse Fehler – Sie müssen jedoch explizit nach Ressourcenlimit, Gesundheitsprüfung, unveränderlichem Image-Tag, engem RBAC und geheimen Sicherheitsregeln fragen. --dry-run, diff und korrekte Kontextprüfung sind Gewohnheiten, die Produktabstürze verhindern.
Anwendungsaufgabe
Lassen Sie AI ein Manifest für eine Beispielanwendung mit der Vorlage „Bereitstellung + Dienstgenerierung“ generieren. Dann: (1) Lassen Sie es mit der Vorlage „Sicherheits-/Gesundheitsprüfung“ auf Ressourcenlimit, Probe, :latest und Geheimnis prüfen; (2) Führen Sie kubectl apply --dry-run=server nach Möglichkeit auf einem Testcluster/Minikube aus und lesen Sie die Ausgabe. (3) Beachten Sie die beiden wichtigsten Sicherheits-/Robustheitselemente, die Ihnen fehlen.
Checkliste
- [ ] Ich habe meiner Anfrage die Image-Version, die Anzahl der Replikate, den Port und die Ressourcenbeschränkungen hinzugefügt.
- [ ] Ich habe dem Manifest eine Liveness- und Readiness-Sonde hinzugefügt.
- [ ] Bild-Tag behoben; Ich habe :latest nicht verwendet.
- [ ] Secret ist nicht in das Manifest eingebettet; Ich habe Secret Object/External Vault verwendet.
- [ ] Ich habe RBAC/Berechtigungen auf minimale Berechtigungen eingegrenzt.
- [ ] Vor der Bewerbung habe ich überprüft, ob ich mich im richtigen Kontext befinde und dass --dry-run/diff ausgegeben wird.