Die App braucht verwaltete Replikate? Namespace erstellen und Anwendung bereitstellen

#kubernetes #aks #deployments #pods

Du möchtest drei Kopien deiner Webanwendung betreiben, ohne beim Verlust eines Pods selbst einen Ersatz starten zu müssen. Ein Kubernetes-Deployment beschreibt diesen gewünschten Zustand. Es verwaltet ein ReplicaSet, das die angegebene Anzahl von Pods aufrechterhält.

In diesem Lab läuft pro Pod ein NGINX-Container. Drei Replikate bedeuten somit drei Pods mit derselben Anwendung. Sie nutzen die vorhandenen Nodes des Clusters; drei Pods benötigen keine drei VMs. Kubernetes bestimmt die Platzierung. Mehrere Replikate können auf demselben Node laufen.

Ein Namespace gruppiert Ressourcen innerhalb des Clusters. Wir verwenden ct-apps, um die Anwendungsressourcen von der Infrastruktur in kube-system zu trennen. Ein Namespace ist keine Azure-Ressourcengruppe und blockiert für sich genommen keinen Netzwerkverkehr zwischen Anwendungen.

Verwende aks-ctlab-weu in UK West und deinen Zugriff als Azure Kubernetes Service RBAC Cluster Admin aus dem Cluster-Trip. Starte den Cluster bei Bedarf über Overview. Für die laufenden Nodes fallen weiterhin Kosten an.

Wir verwenden das öffentliche Image nginx:stable-alpine. Diese Übung benötigt daher weder Registry-Zugangsdaten noch eine ACR-Integration. AKS lädt das Image direkt; deine lokalen Docker-Images sind daran nicht beteiligt.

Namespace im Portal erstellen

Öffne Kubernetes services → aks-ctlab-weu → Kubernetes resources → Namespaces.

Öffne den YAML-Editor über Create → Apply a YAML. Falls diese Option unter Namespaces fehlt, öffne stattdessen Kubernetes resources → Services and ingresses → Create → Apply a YAML. Der Editor kann unterschiedliche Kubernetes-Ressourcentypen anlegen; das Feld kind bestimmt den Typ.

Füge dieses Manifest ein und wähle Add oder Apply, je nach Anzeige im Portal:

apiVersion: v1
kind: Namespace
metadata:
  name: ct-apps

Ein Manifest beschreibt die Ressource, die Kubernetes verwalten soll. Hier erstellt kind: Namespace einen Namespace namens ct-apps. Aktualisiere Namespaces und prüfe, ob er mit dem Status Active erscheint.

AKS Namespaces mit dem aktiven Namespace ct-apps.

Drei Replikate bereitstellen

Öffne erneut Create → Apply a YAML im Portal. Ersetze den Inhalt des Editors durch dieses vollständige Manifest und wende es an:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ct-web
  namespace: ct-apps
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ct-web
  template:
    metadata:
      labels:
        app: ct-web
    spec:
      nodeSelector:
        kubernetes.io/os: linux
      containers:
        - name: nginx
          image: nginx:stable-alpine
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 100m
              memory: 64Mi
            limits:
              cpu: 250m
              memory: 128Mi
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 2
            periodSeconds: 5

Einstellung	Bedeutung in diesem Lab
`namespace: ct-apps`	Ordnet das Deployment und seine Pods unserem Anwendungs-Namespace zu
`replicas: 3`	Fordert drei Pods an; dies ist ein fester Sollwert und keine automatische Skalierung nach Auslastung
`selector.matchLabels` und `template.metadata.labels`	Verbinden das Deployment mit Pods mit dem Label `app: ct-web`; diese Werte müssen übereinstimmen
`template`	Beschreibt die zu erstellenden Pods einschließlich ihres Container-Images
`requests`	Reserviert Kapazität für die Planung pro Container: 100m entspricht 0,1 CPU-Kern und 64Mi entspricht 64 Mebibyte Arbeitsspeicher
`limits`	Begrenzt jeden Container auf 0,25 CPU-Kern und 128Mi Arbeitsspeicher; ein Überschreiten des Speicherlimits kann zur Beendigung führen
`readinessProbe`	Prüft HTTP `/` auf Port 80, damit Kubernetes den Container bei einer erfolgreichen NGINX-Antwort als bereit markieren kann

containerPort: 80 dokumentiert den Port, auf dem die Anwendung lauscht. Dadurch entsteht kein öffentlicher Endpunkt. Dieser Trip prüft die laufenden Replikate; für den Zugriff auf die Anwendung brauchst du einen Service oder eine andere Zugriffsmethode.

Deployment und Pods prüfen

Öffne Kubernetes resources → Workloads → Deployments. Setze den Namespace-Filter auf ct-apps, aktualisiere die Ansicht und öffne ct-web. Warte, bis Images geladen und Container gestartet sind. Prüfe, ob die gewünschte Anzahl 3 beträgt und die Anzahl bereiter beziehungsweise verfügbarer Replikate 3 erreicht.

Verwende unter Workloads → Replica sets denselben Namespace-Filter. Dort sollte ein ReplicaSet erscheinen, dessen Name mit ct-web- beginnt. Die Verwaltungskette lautet Deployment → ReplicaSet → Pods.

Öffne Workloads → Pods, filtere nach ct-apps und prüfe die drei ct-web-…-Pods. Ihre automatisch erzeugten Namensendungen unterscheiden sich. Jeder Pod sollte Running und Ready 1/1 anzeigen: ein bereiter Container von einem Container in diesem Pod. Running allein bestätigt noch keine erfolgreiche Bereitschaftsprüfung.

AKS Workloads mit drei ct-web-Pods in ct-apps, jeweils Running und Ready.

Öffne einen Pod und prüfe seine Details oder sein YAML:

Image: nginx:stable-alpine.
Node: die Worker-VM, auf der dieser Pod läuft.
Pod IP: eine interne Adresse, kein öffentlicher Browser-Endpunkt.
Owner / ownerReferences: das ReplicaSet, das diesen Pod verwaltet.
Events: Ereignisse zu Platzierung, Image-Download und Containerstart.

Öffne die Logs-Ansicht des Pods und wähle bei Bedarf den Container nginx aus. Hier können Startmeldungen und Anfragen der Readiness-Probe erscheinen. Logs zeigen die Ausgabe der Anwendung; Events beschreiben, was Kubernetes mit dem Pod gemacht hat.

Beobachten, wie Kubernetes einen Pod ersetzt

Notiere unter Workloads → Pods mit ausgewähltem Namespace ct-apps den Namen eines ct-web-…-Pods. Wähle nur diesen Pod aus, klicke auf Delete und bestätige. Lasse Deployment und ReplicaSet bestehen.

Aktualisiere die Liste. Das ReplicaSet hat weiterhin einen Sollwert von drei Replikaten. Deshalb erstellt Kubernetes einen Ersatz-Pod mit einem neuen Namen. Kurzzeitig kann der alte Pod noch beendet werden, während der neue auf seinen Start wartet. Warte, bis wieder drei Pods bereit sind.

AKS Pods mit einem neuen, jüngeren ct-web-Pod als Ersatz für den gelöschten Pod.

Vergleiche Namen und Alter mit dem gelöschten Pod. Es handelt sich um einen neuen Pod, nicht um einen Neustart des ursprünglichen Pods. Sein Restart-Zähler kann deshalb null sein. Der Ersatz kann auf demselben oder einem anderen Node laufen.

Die Kernidee: Du legst die gewünschte Anzahl von Replikaten im Deployment fest; Kubernetes hält die passenden Pods bereit. Dafür braucht es freie Clusterkapazität und Zugriff auf das Image. Replikate synchronisieren nicht automatisch Anwendungsdaten und bewahren keine Dateien aus einem gelöschten Container auf.

Lab behalten oder aufräumen

Behalte ct-apps und ct-web für weitere Kubernetes-Übungen. Pausiere den Cluster zwischen Sitzungen über aks-ctlab-weu → Overview → Stop. Für verbleibende Datenträger und andere Ressourcen können weiterhin Kosten anfallen.

Um nur dieses Lab zu entfernen, öffne Kubernetes resources → Namespaces, wähle ct-apps und anschließend Delete. Dadurch werden der Namespace und alle enthaltenen Ressourcen gelöscht, einschließlich Deployment, ReplicaSet und Pods. Das Löschen einzelner Pods allein verhindert nicht, dass dieses Deployment sie ersetzt.

Der AKS-Cluster und seine Worker-VMs bleiben nach dem Löschen des Namespace bestehen. Lösche die Ressourcengruppe des Clusters im Portal erst, wenn du den Cluster nicht mehr benötigst.