Warum Kubernetes, und warum unser Stack Container Apps vorzieht

Die Kladde läuft seit K3 auf Azure Container Apps. Sie skaliert nach der Länge einer Warteschlange bis auf null, sie bekommt ihre Geheimnisse über eine verwaltete Identität, und eine Pipeline liefert sie ohne gespeichertes Kennwort aus. Trotzdem taucht in fast jedem Gespräch über Container früher oder später das Wort Kubernetes auf: als Stellenanforderung, als Wunsch eines Kunden, als „das macht man heute so“.

Dieser Kurs geht ehrlich damit um. Er bringt Ihnen bei, wie Kubernetes arbeitet, und er baut dafür die Kladde auf einem AKS-Cluster auf. Aber die erste Lektion stellt die Frage, die vor allem anderen steht: Braucht die Kladde Kubernetes überhaupt? Am Ende der Lektion steht die Antwort schriftlich in docs/entscheidungen.md, mit Gründen und mit den Bedingungen, unter denen sie kippen würde. Erwartet wird, dass dort steht: Der Stack der Akademie bleibt Container Apps. AKS ist die Übung und die Entscheidungshilfe, nicht das Ziel.

Was Container, Images und Registry sind, steht in K1 und in den Lektionen 3.1 und 3.2; Container Apps, Revisionen und Skalierung kennen Sie aus K3. Diese Lektion wiederholt das nicht, sie setzt es voraus.

Was Kubernetes löst

Kubernetes ist nach Microsofts Beschreibung eine quelloffene Plattform, die Bereitstellung, Skalierung und Verwaltung containerisierter Anwendungen automatisiert. Das klingt nach einem Werbesatz. Konkret meint es drei Dinge.

Orchestrierung. Ein Container läuft irgendwo. Bei zwei Containern auf zwei Rechnern fragen Sie schon: Auf welchem läuft was, wohin geht der Verkehr, was passiert, wenn ein Rechner ausfällt? Kubernetes beantwortet das für Dutzende oder Tausende Container. Es verteilt sie auf Knoten (Rechner), gibt ihnen Netzadressen und Namen und sorgt dafür, dass Verkehr nur dorthin geht, wo ein Container bereit ist.

Selbstheilung. Stürzt ein Container ab, startet Kubernetes ihn neu. Fällt ein Knoten aus, baut es die Container auf anderen Knoten wieder auf. Antwortet ein Container nicht mehr auf seine Gesundheitsabfrage, nimmt es ihn aus der Verteilung. Das alles geschieht ohne Ihr Zutun, aber nach Regeln, die Sie vorher aufgeschrieben haben.

Deklarativer Zustand. Sie sagen Kubernetes nicht, was es tun soll („starte drei Container“), sondern wie es aussehen soll („drei Replikate dieses Images laufen“). Der Wunsch heißt Soll-Zustand, der tatsächliche Zustand Ist-Zustand. Dazwischen arbeitet eine Regelschleife: Ein Controller vergleicht beide, und weicht der Ist-Zustand ab, handelt er, bis beide wieder gleich sind. Das ist die Idee, auf der alles andere ruht. Sie erklärt, warum ein gelöschter Pod von selbst wiederkommt und warum man Kubernetes mit Dateien füttert statt mit Befehlen.

Die Bauteile in einem Satz

Ein Cluster besteht nach der AKS-Dokumentation aus zwei Teilen: der Steuerungsebene (control plane), die den Zustand hält und über Platzierung entscheidet, und den Knoten (nodes), den virtuellen Maschinen, auf denen Ihre Anwendungen laufen. Zur Steuerungsebene gehören der API-Server (jede Anfrage an den Cluster geht durch ihn), etcd (der Speicher des Zustands), der Scheduler (er wählt für jeden neuen Pod einen Knoten) und der Controller-Manager (er betreibt die Regelschleifen). Auf jedem Knoten arbeiten der kubelet, der dafür sorgt, dass Container im Pod laufen, und eine Laufzeitumgebung für Container. Ein Pod ist eine Gruppe von einem oder mehreren Containern, die Netz und Speicher teilen. Lektion W1.2 baut diese Begriffe mit Händen auf.

Was Container Apps davon schon verwaltet

Container Apps ist kein Gegenentwurf zu Kubernetes, sondern ein Dienst, der darauf aufbaut. Die Dokumentation sagt: Container Apps wird von Kubernetes und quelloffenen Technologien wie Dapr, KEDA und Envoy angetrieben und unterstützt „Kubernetes-artige“ Anwendungen und Microservices mit Dienstentdeckung und Verkehrsaufteilung. Dazu gehören Skalieren nach Verkehr und nach Ereignisquellen wie Warteschlangen, auch bis auf null, sowie Aufträge, die auf Abruf, nach Zeitplan oder durch Ereignisse starten. Genau diese Teile haben Sie in K3 benutzt.

Was Sie dort nicht getan haben: Sie haben nie einen Knoten gesehen, nie einen Knotenpool gewählt, nie ein Kubernetes-Manifest geschrieben. Die Dokumentation nennt das offen: Container Apps gibt keinen direkten Zugriff auf die Kubernetes-API. Wer sie oder die Steuerungsebene braucht, soll AKS nehmen. Wer „Kubernetes-artige“ Anwendungen bauen will, ohne alle nativen Schnittstellen zu brauchen, bekommt mit Container Apps eine vollständig verwaltete Umgebung nach bewährten Mustern. Aus diesem Grund beginnen laut Dokumentation viele Teams mit Container Apps.

Die folgende Tabelle ordnet zu, was Ihnen aus K3 bekannt ist, und was Kubernetes dafür sagt. Sie ist ein Wegweiser für die nächsten Lektionen, keine Gleichung: Die Dinge sind verwandt, nicht gleich.

Ein Beispiel macht den Unterschied greifbar. Dieselbe Aussage „zwei Replikate der Web-App, mindestens eins immer erreichbar“ steht in Container Apps als Teil der Bicep-Beschreibung der App:

// Container Apps (K3): the platform decides on which node a replica runs; you never see the node.
template: {
  containers: [
    { name: 'web', image: webImage, resources: { cpu: json('0.25'), memory: '0.5Gi' } }
  ]
  scale: {
    minReplicas: 2
    maxReplicas: 4
  }
}

In Kubernetes schreiben Sie sie als Deployment. Lesen Sie das Beispiel nur zum Vergleichen; in Lektion W1.2 bauen Sie es Zeile für Zeile auf:

# Kubernetes (W1.2): you describe the state; the cluster's controllers work towards it.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kladde-web
  namespace: kladde
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: kladde-web
  template:
    metadata:
      labels:
        app.kubernetes.io/name: kladde-web
    spec:
      containers:
        - name: web
          image: acrkladdeabc123.azurecr.io/kladde-web:1.0.0

Sie sehen: Dieselben Gedanken, aber in Kubernetes liegen sie auf der Oberfläche. Das ist Stärke und Last zugleich. Jede Einstellung, die Container Apps für Sie trifft, treffen Sie hier selbst, oder Sie lassen sie von AKS Automatic treffen.

Was Container Apps nicht bietet

„Kein Zugriff auf die Kubernetes-API“ ist abstrakt. Fassen Sie es als Liste dessen, was Sie ohne die API nicht tun können:

• Fremde Software installieren, die Kubernetes voraussetzt. Viele Werkzeuge werden als Helm-Chart oder als Operator ausgeliefert: eigene Ressourcentypen, die ein Controller im Cluster auswertet. Ohne Cluster gibt es dafür keinen Platz.
• GitOps nach Kubernetes-Art. Ein Konfigurations-Repository, aus dem ein Controller im Cluster den Zustand herstellt (W1.7), setzt einen Cluster voraus. Container Apps kennen Sie aus K3 mit Pipelines, die per Push ausliefern.
• Knoten, Netzwerk und Richtlinien selbst formen. Eigene Knotenpools, eigene Netzrichtlinien auf Schicht 7, eigene Eingänge: Das ist Aufgabe eines Plattformteams, und Container Apps nimmt Ihnen sie ab, indem es sie Ihnen nicht gibt.
• Dasselbe Manifest an mehreren Orten. Kubernetes läuft bei den großen Cloud-Anbietern und im eigenen Rechenzentrum. Wer Wert darauf legt, dass seine Beschreibung dort unverändert gilt, spricht für Kubernetes. Beachten Sie die Einschränkung: Manifeste sind übertragbar, die Dienste ringsum (Identität, Registry, Warteschlange, Eingang) sind es nicht. Die Kladde braucht dafür in W1.3 eine Handvoll Azure-Besonderheiten.

Wo die Grenze genau verläuft, ändert sich mit den Diensten. Prüfen Sie ein konkretes Bedürfnis darum immer an der aktuellen Dokumentation von Container Apps, nicht an dieser Liste; die Prüfliste unten verlangt dafür einen Beleg.

AKS: Automatic und Standard

Azure Kubernetes Service (AKS) ist der verwaltete Kubernetes-Dienst von Azure. Die Steuerungsebene betreibt Azure in beiden Varianten. Was sich unterscheidet, ist, wer den Rest betreibt. Die Dokumentation nennt zwei Modi:

• AKS Automatic: Azure richtet den Cluster ein und betreibt Knoten, Skalierung, Sicherheitsvoreinstellungen und Upgrades mit Voreinstellungen nach den Empfehlungen des Well-Architected Frameworks von AKS. Es ist für Produktionsanwendungen ausgelegt.
• AKS Standard: Sie haben „maximale Flexibilität“ und direkte Kontrolle über Knotenpools, Skalierung, Netz und Betrieb, und Sie tragen sie.

Die Dokumentation enthält eine lange Vergleichstabelle. Die Zeilen, die für die Entscheidung zählen, in Ihren Worten:

Das Wort „vorkonfiguriert“ hat in der Dokumentation eine genaue Bedeutung: Vorkonfigurierte Funktionen sind immer eingeschaltet, und Sie können sie weder abschalten noch ihre Einstellungen ändern. „Standard“ (Default) heißt: eingestellt, aber änderbar. Wer AKS Automatic nimmt, kauft sich also Sicherheit mit weniger Spielraum. Das ist für die Kladde ein guter Tausch, und es hat Folgen, die Sie in W1.2 und W1.3 an Fehlermeldungen sehen werden.

Drei Grenzen von AKS Automatic sollten Sie vor der Entscheidung kennen, weil sie sich später nicht mehr beheben lassen:

• Die Wahl ist endgültig. Die Dokumentation sagt ausdrücklich: Eine Migration von der Basis-SKU (Standard) zur Automatic-SKU wird nicht unterstützt. Wer mit AKS Standard beginnt und später die Voreinstellungen von Automatic will, baut einen neuen Cluster.
• Windows-Knoten werden nicht unterstützt, und die Erweiterungen Dapr und Azure Machine Learning nicht.
• Die Region muss Automatic anbieten. germanywestcentral, die Region der Kladde, steht in der Liste der Regionen mit allgemeiner Verfügbarkeit.

Eine Verwechslung vermeiden Sie am besten gleich: „AKS Standard“ ist ein Clustermodus, „Standard“ ist außerdem der Name einer Preisstufe der Clusterverwaltung (Free, Standard, Premium). AKS Automatic läuft in der Standard-Stufe. Beides hat nichts miteinander zu tun.

Was es kostet, ohne eine Zahl zu nennen

Zahlen ändern sich, deshalb steht in dieser Lektion keine. Wohin das Geld geht, ändert sich selten:

Container Apps rechnet dagegen nach Sekunden, in denen eine Replik läuft, und kennt ein Freikontingent (K3, Lektion 3.5.7). Eine App auf null kostet keine Rechenzeit. Ein Cluster hat dieses „auf null“ nur für Ihre Pods, nicht für sich selbst. Das ist der wichtigste Kostenunterschied für ein kleines Büro, und er gehört in die Prüfliste. Den aktuellen Preis lesen Sie im Preisrechner.

Die Prüfliste

Eine Entscheidung braucht Fragen, auf die es Antworten mit Belegen gibt. Die Prüfliste dieser Lektion hat zwei Teile:

• Muss-Kriterien: Bedürfnisse, die nur ein Cluster erfüllt. Ein belegtes „Ja“ genügt, um AKS ernsthaft zu prüfen.
• Gegenkriterien: Umstände, die für Container Apps sprechen. Sie entscheiden nicht allein, sie gehören aber in die Begründung.

Die Fragen stehen als Daten in einer Datei, damit eine Entscheidung sich später wiederholen und vergleichen lässt:

{
  "mussKriterien": [
    { "id": "M1", "frage": "Braucht die Anwendung die Kubernetes-API, etwa Operatoren oder eigene Ressourcentypen?" },
    { "id": "M2", "frage": "Verlangt ein Kunde oder ein Werkzeug Helm-Charts oder GitOps im Cluster?" },
    { "id": "M3", "frage": "Brauchen wir Kontrolle über Knoten, Netzrichtlinien oder Eingänge, die Container Apps nicht bietet?" },
    { "id": "M4", "frage": "Muss dieselbe Beschreibung in mehreren Clouds oder im eigenen Rechenzentrum gelten?" }
  ],
  "gegenKriterien": [
    { "id": "G1", "frage": "Fehlt uns ein Team, das eine Plattform betreibt, also Versionen, Knoten und Richtlinien beobachtet?" },
    { "id": "G2", "frage": "Hat die Last lange Pausen, in denen nichts laufen müsste?" },
    { "id": "G3", "frage": "Sind es wenige Dienste, die sich in Container Apps schon vollständig ausdrücken lassen?" }
  ]
}

Das Skript liest die Datei und die Antworten, prüft beide und gibt ein Urteil aus. Es entscheidet nichts, es macht die Entscheidung nachvollziehbar. Wichtig ist der Exit-Code: Er sagt, ob die Eingabe in Ordnung war, nicht, was herauskam.

# scripts/aks-entscheidung.ps1 - evaluates the checklist; the exit code reports the input, never the verdict.
[CmdletBinding()]
param(
    [string] $Checklist = 'docs/aks-pruefliste.json',
    [string] $Answers = 'docs/aks-antworten.json'
)

$ErrorActionPreference = 'Stop'

try {
    $list = Get-Content -Raw -LiteralPath $Checklist | ConvertFrom-Json
    $answers = Get-Content -Raw -LiteralPath $Answers | ConvertFrom-Json
}
catch {
    Write-Error "Eingabe nicht lesbar: $($_.Exception.Message)"
    exit 2
}

$problems = @()
$yesMust = @()
$yesAgainst = @()

foreach ($group in 'mussKriterien', 'gegenKriterien') {
    foreach ($item in $list.$group) {
        $answer = $answers.($item.id)
        if (-not $answer -or $answer.antwort -notin 'ja', 'nein') {
            $problems += "$($item.id): antwort muss 'ja' oder 'nein' sein."
        }
        elseif ([string]::IsNullOrWhiteSpace($answer.beleg)) {
            $problems += "$($item.id): ohne Beleg gilt keine Antwort."
        }
        elseif ($answer.antwort -eq 'ja') {
            if ($group -eq 'mussKriterien') { $yesMust += $item.id } else { $yesAgainst += $item.id }
        }
    }
}

if ($problems) {
    $problems | ForEach-Object { Write-Error $_ -ErrorAction Continue }
    exit 2
}

"Muss-Kriterien mit Ja:   $($yesMust.Count) $($yesMust -join ', ')"
"Gegenkriterien mit Ja:   $($yesAgainst.Count) $($yesAgainst -join ', ')"
if ($yesMust.Count -gt 0) {
    'Urteil: AKS ernsthaft prüfen. Mindestens ein Bedürfnis hat nur ein Cluster.'
}
else {
    'Urteil: Container Apps bleibt. Kein Bedürfnis verlangt einen Cluster.'
}
exit 0

Zwei Zeilen darin sind absichtlich streng. Eine Antwort ohne Beleg gilt nicht: „Wir brauchen vielleicht Helm“ ist kein Beleg, „Kunde X verlangt laut Vertrag Y ein Helm-Chart“ ist einer. Und der Exit-Code 2 trennt kaputte Eingabe vom Urteil, damit eine Pipeline oder ein Review beides unterscheiden kann. Dasselbe Prinzip kennen Sie aus K3: Der Exit-Code zählt, nie nur die Ausgabe.

Wann AKS die richtige Wahl ist

Kehren Sie die Prüfliste um, dann beschreibt sie, wann AKS gewinnt:

• Ihre Software, oder die, die Sie betreiben müssen, ist für Kubernetes gemacht (Operatoren, Charts), und ein Austausch kostet mehr als ein Cluster.
• Sie haben ein Plattformteam, das Versionsfristen, Knoten und Richtlinien als Alltag betreibt. AKS unterstützt jede GA-Version zwölf Monate; wer länger auf einer nicht mehr unterstützten Version bleibt, wird nach einer Gnadenfrist von der Plattform selbst aktualisiert, ohne Wartungsfenster und ohne Halt bei veralteten Schnittstellen. Das Datum, ab dem das gilt, steht in der Dokumentation der unterstützten Versionen; lesen Sie es dort, nicht in dieser Lektion.
• Sie brauchen dieselbe Beschreibung an mehreren Orten oder eine Fähigkeit, die Container Apps nicht kennt.
• Ihr Betrieb ist groß genug, dass der Aufwand für einen Cluster sich verteilt: viele Dienste, mehrere Teams, ein gemeinsamer Unterbau.

Und wenn AKS, dann zuerst Automatic. Die Dokumentation empfiehlt Automatic als Standardweg für Produktionsanwendungen. Standard wählen Sie nur, wenn Ihnen eine Voreinstellung im Weg steht, die Automatic nicht ändern lässt: etwa Windows-Knoten, eine nicht unterstützte Erweiterung oder die Warnstufe der Richtlinien. Weil die Wahl endgültig ist (siehe oben), gehört der Grund dafür in die Entscheidung.

Denkfehler

{
  "M1": { "antwort": "nein", "beleg": "Kladde.Web und Kladde.Worker sind gewöhnliche Container; kein Operator, keine eigenen Ressourcentypen (Lektion 3.5)" },
  "M2": { "antwort": "nein", "beleg": "Kein Kunde und kein Werkzeug verlangt Helm oder GitOps; die Auslieferung läuft mit azd und einer Pipeline (3.7)" },
  "M3": { "antwort": "nein", "beleg": "Eingang über Front Door und Container Apps genügt; keine Netzrichtlinien auf Schicht 7 gefordert (3.3.4)" },
  "M4": { "antwort": "nein", "beleg": "Die Kladde läuft nur in Azure; kein zweiter Anbieter, kein Rechenzentrum" },
  "G1": { "antwort": "ja", "beleg": "Das Büro hat kein Plattformteam; Versionen und Knoten würden an einer Person hängen" },
  "G2": { "antwort": "ja", "beleg": "Der Worker hat Arbeit nur nach dem nächtlichen Abruf und bei Uploads; in Container Apps läuft er auf null (3.5.7)" },
  "G3": { "antwort": "ja", "beleg": "Zwei Dienste, Web und Worker, plus ein geplanter Job; alles ist in Container Apps ausgedrückt" }
}

pwsh -NoProfile -File scripts/aks-entscheidung.ps1
$LASTEXITCODE

Muss-Kriterien mit Ja:   0
Gegenkriterien mit Ja:   3 G1, G2, G3
Urteil: Container Apps bleibt. Kein Bedürfnis verlangt einen Cluster.
0

## Container Apps oder AKS

Stand: <Datum> · Entschieden von: Betrieb der Kladde · Überprüfen: bei jeder Änderung in den Kippbedingungen

Entscheidung: Die Kladde läuft weiter auf Azure Container Apps. AKS betreiben wir nur als Übung (Kurs W1) und löschen den Cluster danach.

Warum:
- Kein Muss-Kriterium trifft zu (docs/aks-antworten.json, M1 bis M4, jeweils mit Beleg).
- Wir haben kein Plattformteam (G1): Versionsfristen, Knoten und Richtlinien eines Clusters hingen an einer Person.
- Der Worker hat lange Pausen (G2). Container Apps skaliert ihn auf null und rechnet nach Sekunden einer laufenden Replik ab;
  ein Cluster hat Knoten, die ohne Last weiterlaufen.
- Zwei Dienste und ein Job (G3) sind in Container Apps vollständig beschrieben; ein Cluster wäre mehr Plattform als Anwendung.

Was die Entscheidung kippen würde (jeweils prüfbar):
- Ein Kunde verlangt vertraglich ein Helm-Chart oder GitOps (Prüfung: Vertragsklausel liegt vor; docs/aks-antworten.json M2 wird "ja").
- Wir brauchen eine Software, die als Operator ausgeliefert wird (M1).
- Die Kladde soll in einem zweiten Rechenzentrum laufen (M4).
- Wir stellen jemanden ein, der die Plattform betreibt (G1 wird "nein").
Dann: Wechsel nach AKS Automatic. AKS Standard nur mit einem schriftlichen Grund, denn der Modus lässt sich nicht
nachträglich wechseln.

Was wir trotzdem tun: Kurs W1 baut die Kladde auf einem AKS-Automatic-Cluster in der Region germanywestcentral auf, jeweils an
einem Stück und mit Budget-Alarm vorher und Löschen der Ressourcengruppe danach.

Die Kladde nach dieser Lektion

• docs/aks-pruefliste.json, docs/aks-antworten.json und scripts/aks-entscheidung.ps1: eine Prüfliste mit Belegen, die sich wiederholen lässt.
• docs/aks-vergleich.md: die Begriffe von Kubernetes und Container Apps nebeneinander.
• Ein Eintrag „Container Apps oder AKS“ in docs/entscheidungen.md mit Kippbedingungen.
• Keine neue Ressource in Azure und kein Cluster: Diese Lektion kostet nichts.

Was Sie jetzt können

• Sie erklären Orchestrierung, Selbstheilung und den deklarativen Soll-Ist-Vergleich als Regelschleife.
• Sie benennen, was Container Apps von Kubernetes schon für Sie verwaltet, und was ohne Zugriff auf die Kubernetes-API fehlt.
• Sie unterscheiden AKS Automatic und AKS Standard nach Verantwortung und Grenzen und wissen, dass die Wahl endgültig ist.
• Sie wenden eine Prüfliste mit Belegen an und werten sie mit einem Skript aus, dessen Exit-Code die Eingabe meldet.
• Sie schreiben eine Entscheidung mit prüfbaren Kippbedingungen auf.

Weiterlesen

• Comparing Container Apps with other Azure container options: wann Container Apps, AKS und die anderen Dienste passen.
• What is Azure Kubernetes Service (AKS) Automatic?: was vorkonfiguriert ist, mit der vollständigen Vergleichstabelle.
• Core concepts for Azure Kubernetes Service (AKS): Steuerungsebene, Knoten, Pods, Namespaces und Preisstufen.
• Supported Kubernetes versions in AKS: Versionsfristen und plattformgesteuerte Upgrades.