Grundlegende Kubernetes-Konzepte für Azure Kubernetes Service

Die Anwendungsentwicklung setzt zunehmend auf eine containerbasierte Vorgehensweise, sodass es immer wichtiger wird, die Ressourcen zu orchestrieren und zu verwalten. Als führende Plattform bietet Kubernetes eine zuverlässige Planung fehlertoleranter Anwendungsworkloads. Azure Kubernetes Service (AKS), ein Managed Kubernetes-Angebot, vereinfacht die containerbasierte Anwendungsbereitstellung und -verwaltung noch weiter.

In diesem Artikel werden Kernkonzepte vorgestellt:

• Komponenten der Kubernetes-Infrastruktur:

  • Steuerungsebene
  • Knoten
  • Knotenpools

• Workloadressourcen:

  • Pods
  • Bereitstellungen
  • Sets

• Gruppieren Sie Ressourcen mithilfe von Namespaces.

Was ist Kubernetes?

Kubernetes ist eine schnell wachsende Plattform, die containerbasierte Anwendungen und die zugehörigen Netzwerk- und Speicherkomponenten verwaltet. Kubernetes konzentriert sich die Anwendungsworkloads, nicht auf die zugrunde liegenden Infrastrukturkomponenten. Kubernetes bietet einen deklarativen Ansatz für Bereitstellungen und wird durch einen stabilen Satz an APIs für Verwaltungsvorgänge unterstützt.

Sie können moderne, portierbare, auf Microservices basierende Anwendungen erstellen und ausführen, wobei Kubernetes zum Orchestrieren und Verwalten der Verfügbarkeit der Anwendungskomponenten verwendet wird. Kubernetes unterstützt sowohl zustandslose als auch zustandsbehaftete Anwendungen für Teams, die zunehmend auf Microservices basierende Anwendungen entwickeln.

Als offene Plattform ermöglicht Kubernetes Ihnen, Ihre Anwendungen mit Ihren bevorzugten Programmiersprachen, Betriebssystemen, Bibliotheken oder Messagingbussen zu erstellen. Vorhandene CI/CD-Tools (Continuous Integration/Continuous Delivery) können in Kubernetes integriert werden, um Releases zu planen und bereitzustellen.

AKS bietet einen Managed Kubernetes-Dienst, der die Komplexität von Bereitstellungs- und wichtigen Verwaltungsaufgaben reduziert, z. B. die Koordination von Upgrades. Die Azure-Plattform verwaltet die AKS-Steuerungsebene, und Sie zahlen nur für die AKS-Knoten, die Ihre Anwendungen ausführen.

Kubernetes-Cluster – Architektur

Ein Kubernetes-Cluster ist in zwei Komponenten unterteilt:

• Steuerungsebene: Diese stellt die grundlegenden Kubernetes-Dienste und Orchestrierungsfunktionen für Anwendungsworkloads bereit.
• Knoten: Diese führen Ihre Anwendungsworkloads aus.

Steuerungsebene

Wenn Sie einen AKS-Cluster erstellen, wird automatisch eine Steuerungsebene erstellt und konfiguriert. Diese Steuerungsebene wird kostenlos als verwaltete Azure-Ressource bereitgestellt, die für den Benutzer abstrahiert wird. Sie zahlen nur für die Knoten, die an den AKS-Cluster angefügt sind. Die Steuerungsebene und ihre Ressourcen befinden sich nur in der Region, in der Sie den Cluster erstellt haben.

Die Steuerungsebene umfasst die folgenden Kubernetes-Kernkomponenten:

Komponente	BESCHREIBUNG
kube-apiserver	Über den API-Server werden die zugrunde liegenden Kubernetes-APIs verfügbar gemacht. Diese Komponente ermöglicht die Interaktion für Verwaltungstools, z.B. kubectl oder das Kubernetes-Dashboard.
etcd	Für die Verwaltung des Zustands Ihres Kubernetes-Clusters und Ihrer Kubernetes-Konfiguration ist etcd ein hoch verfügbarer Schlüssel-Wert-Speicher in Kubernetes.
kube-scheduler	Wenn Sie Anwendungen erstellen oder skalieren, ermittelt der Scheduler, welche Knoten die Workload ausführen können, und startet diese.
kube-controller-manager	Der Controller Manager überwacht eine Reihe kleinerer Controller, die Aktionen wie beispielsweise das Replizieren von Pods und das Verarbeiten von Knotenvorgängen ausführen.

AKS stellt eine Steuerungsebene mit Einzelmandant, einem dedizierten API-Server, einem Scheduler usw. bereit. Sie definieren die Anzahl und Größe der Knoten, und die Azure-Plattform konfiguriert die sichere Kommunikation zwischen Steuerungsebene und Knoten. Die Interaktion mit der Steuerungsebene erfolgt über Kubernetes-APIs, z.B. kubectl, oder das Kubernetes-Dashboard.

Bei dieser verwalteten Steuerungsebene müssen Sie zwar keine Komponenten konfigurieren (z. B. hoch verfügbaren etcd-Speicher), doch Sie können nicht direkt auf die Steuerungsebene zugreifen. Upgrades der Kubernetes-Steuerungsebene und -Knoten werden über die Azure CLI oder das Azure-Portal orchestriert. Zum Beheben möglicher Probleme können Sie über Azure Monitor-Protokolle die Steuerungsebenenprotokolle überprüfen.

Um eine Steuerungsebene zu konfigurieren oder direkt darauf zuzugreifen, stellen Sie einen selbst verwalteten Kubernetes-Cluster mithilfe des Cluster-API-Anbieters in Azure bereit.

Entsprechende bewährte Methoden finden Sie unter Best Practices für Clustersicherheit und Upgrades in Azure Kubernetes Service (AKS).

Informationen zur AKS-Kostenverwaltung finden Sie unter AKS-Kostengrundlagen und Preise für AKS.

Knoten und Knotenpools

Zum Ausführen Ihrer Anwendungen und der unterstützenden Dienste benötigen Sie einen Kubernetes-Knoten. Ein AKS-Cluster besteht aus mindestens einem Knoten, bei dem es sich um einen virtuellen Azure-Computer (Azure-VM) handelt, der die Kubernetes-Knotenkomponenten und die Containerruntime ausführt.

Komponente	Beschreibung
kubelet	Der Kubernetes-Agent, der die Orchestrierungsanforderungen der Steuerungsebene sowie die Planung und Ausführung der angeforderten Container verarbeitet
kube-proxy	Verarbeitet virtuelle Netzwerkfunktionen auf jedem Knoten. Der Proxy leitet den Netzwerkdatenverkehr weiter und verwaltet die IP-Adressen für Dienste und Pods.
Containerruntime	Ermöglicht die Ausführung von containerisierten Anwendungen und die Interaktion mit zusätzlichen Ressourcen, wie z. B. dem virtuellen Netzwerk oder Speicher. AKS-Cluster, die Kubernetes Version 1.19 und höher für Linux-Knotenpools verwenden, nutzen containerd als Containerruntime. Ab Kubernetes Version 1.20 für Windows-Knotenpools kann containerd in der Vorschauversion für die Containerruntime verwendet werden, auch wenn weiterhin Docker als Standardcontainerruntime verwendet wird. AKS-Cluster, die frühere Versionen von Kubernetes für Knotenpools verwenden, verwenden Docker als Containerruntime.

Die Größe der Azure-VMs für Ihre Knoten definiert die CPUs, den Arbeitsspeicher, die Größe und den Typ des verfügbaren Speichers (z. B. hochleistungsfähige SSDs oder reguläre HDDs). Planen Sie die Knotengröße danach, ob Ihre Anwendungen möglicherweise große Mengen an CPUs und Arbeitsspeicher oder Hochleistungsspeicher erfordern. Skalieren Sie die Anzahl von Knoten in Ihrem AKS-Cluster auf, um Anforderungen zu erfüllen. Weitere Informationen zur Skalierung finden Sie unter Skalierungsoptionen für Anwendungen in AKS.

In AKS basiert das VM-Image für die Knoten in Ihrem Cluster auf Ubuntu Linux, Azure Linux oder Windows Server 2019. Wenn Sie einen AKS-Cluster erstellen oder die Anzahl von Knoten aufskalieren, erstellt und konfiguriert die Azure-Plattform automatisch die angeforderte Anzahl von VMs. Agent-Knoten werden als Standard-VMs in Rechnung gestellt, sodass alle etwaigen Rabatte für VM-Größen (einschließlich Azure-Reservierungen) automatisch angewendet werden.

Für verwaltete Datenträger werden die standardmäßige Datenträgergröße und -leistung gemäß der ausgewählten VM-SKU und vCPU-Anzahl zugewiesen. Weitere Informationen finden Sie unter Standardmäßige Festplattengröße des Betriebssystems.

Wenn Sie erweiterte Konfigurations- und Steuerungsoptionen für die Runtime Ihres Kubernetes-Knotencontainers und Ihr Betriebssystem benötigen, können Sie einen selbstverwalteten Cluster mithilfe des Cluster-API-Anbieters in Azure bereitstellen.

Ressourcenreservierungen

AKS verwendet Knotenressourcen, damit der Knoten als Teil Ihres Clusters fungieren kann. Diese Verwendung kann zu einer Abweichung zwischen den Gesamtressourcen des Knotens und den Ressourcen führen, die in AKS zugewiesen werden können. Beachten Sie diese Informationen beim Festlegen von Anforderungen und Grenzwerten für vom Benutzer bereitgestellte Pods.

Führen Sie Folgendes aus, um die Ressourcen zu ermitteln, die einem Knoten zugewiesen werden können:

kubectl describe node [NODE_NAME]

Um die Leistung und Funktionalität des Knotens zu gewährleisten, reserviert AKS Ressourcen auf jedem Knoten. Wenn ein Knoten mehr Ressourcen nutzt, steigt die Anzahl der reservierten Ressourcen aufgrund eines höheren Verwaltungsbedarfs für vom Benutzer bereitgestellte Pods.

Hinweis

Durch die Verwendung von AKS-Add-Ons wie Container Insights (OMS) werden zusätzliche Knotenressourcen beansprucht.

Zwei Arten von Ressourcen sind reserviert:

CPU

Die reservierten CPU-Ressourcen hängen vom Knotentyp und der Clusterkonfiguration ab. Diese können dazu führen, dass weniger CPU-Ressourcen zugewiesen werden können, da zusätzliche Features ausgeführt werden.

CPU-Kerne auf dem Host	1	2	4	8	16	32	64
Kube-reserviert (Millicore)	60	100	140	180	260	420	740

Arbeitsspeicher

Der von AKS genutzte Arbeitsspeicher umfasst die Summe aus zwei Werten.

Wichtig

AKS 1.29 wird im Januar 2024 veröffentlicht und enthält einige Änderungen an den Speicherreservierungen. Diese Änderungen werden im folgenden Abschnitt beschrieben.

AKS 1.29 und höher

1. kubelet Daemon verfügt standardmäßig über die memory.available<100Mi Entfernungsregel. Dadurch wird sichergestellt, dass ein Knoten immer über mindestens 100 Mi verfügt. Wenn sich ein Host unter dem verfügbaren Speicherschwellenwert befindet, löst die kubelet das Beenden eines der ausgeführten Pods aus und gibt Arbeitsspeicher auf dem Hostcomputer frei.

2. Eine Rate der Speicherreservierungen gemäß dem niedrigeren Wert von: 20 MB * Max Pods unterstützt auf dem Node + 50 MB oder 25 % der gesamten Systemspeicherressourcen.

   Beispiele:

   • Wenn die VM 8 GB Arbeitsspeicher bereitstellt und der Knoten bis zu 30 Pods unterstützt, reserviert AKS 20 MB * 30 Max Pods + 50 MB = 650 MB für kube-reserviert. Allocatable space = 8GB - 0.65GB (kube-reserved) - 0.1GB (eviction threshold) = 7.25GB or 90.625% allocatable.
   • Wenn die VM 4 GB Arbeitsspeicher bereitstellt und der Knoten bis zu 70 Pods unterstützt, reserviert AKS 25 % * 4 GB = 1000 MB für kube-reserviert, da dies kleiner als 20 MB * 70 Max Pods + 50 MB = 1450 MBist.

   Weitere Informationen finden Sie unter Konfigurieren der maximalen Pods pro Knoten in einem AKS-Cluster.

AKS-Versionen vor 1.29

1. kubeletDer Daemon wird auf allen Kubernetes-Agent-Knoten installiert, um die Erstellung und Beendigung von Containern zu verwalten. Standardmäßig verfügt der kubelet-Daemon in AKS über die memory.available<750Mi-Entfernungs-Regel, die sicherstellt, dass einem Knoten immer mindestens 750 Mi zuweisbar sein müssen. Wenn ein Host diesen Schwellenwert des verfügbaren Arbeitsspeichers unterschreitet, wird kubelet ausgelöst, um einen der ausgeführten Pods zu beenden und Arbeitsspeicher auf dem Hostcomputer freizugeben.

2. Eine regressive Rate von Arbeitsspeicherreservierungen für den Kubelet-Daemon, damit er ordnungsgemäß funktioniert (kube-reserved)

   • 25 % der ersten 4 GB Arbeitsspeicher
   • 20 % der nächsten 4 GB Arbeitsspeicher (bis zu 8 GB)
   • 10 % des nächsten 8 GB Arbeitsspeichers (bis zu 16 GB)
   • 6 % der nächsten 112 GB Arbeitsspeicher (bis zu 128 GB)
   • 2 % des Arbeitsspeichers über 128 GB

Hinweis

AKS reserviert zusätzliche 2 GB für Systemprozesse in Windows-Knoten, die nicht Teil des berechneten Arbeitsspeichers sind.

Speicher- und CPU-Zuteilungsregeln sind für die folgende Aktion konzipiert:

• Gewährleisten Sie die Integrität der Agent-Knoten, von denen einige Systempods hosten, die für die Clusterintegrität wichtig sind.
• Dafür sorgen, dass der Knoten weniger zuteilbaren Arbeitsspeicher und CPU meldet, als wenn er nicht Teil eines Kubernetes-Clusters wäre.

Die obigen Ressourcenreservierungen können nicht geändert werden.

Wenn ein Knoten beispielsweise 7 GB bietet, werden 34 % des Arbeitsspeichers einschließlich des festen Entfernungsschwellenwerts von 750 Mi als nicht zuteilbar angegeben.

0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 7GB = 33.57% reserved

Zusätzlich zu den Reservierungen für Kubernetes selbst reserviert das zugrunde liegende Knotenbetriebssystem ebenfalls CPU- und Arbeitsspeicherressourcen für die Aufrechterhaltung der Betriebssystemfunktionen.

Entsprechende bewährte Methoden finden Sie unter Best Practices für grundlegende Schedulerfunktionen in Azure Kubernetes Service (AKS).

Knotenpools

Hinweis

Der Azure Linux-Knotenpool ist jetzt allgemein verfügbar (GA). Informationen zu den Vorteilen und Bereitstellungsschritten finden Sie in der Einführung in den Azure Linux-Containerhost für AKS.

Knoten mit der gleichen Konfiguration werden in Knotenpools gruppiert. Ein Kubernetes-Cluster enthält mindestens einen Knotenpool. Die anfängliche Knotenanzahl und -größe wird beim Erstellen eines AKS-Clusters definiert, wobei ein Standardknotenpool erstellt wird. Dieser Standardknotenpool in AKS enthält die zugrunde liegenden VMs, die Ihre Agent-Knoten ausführen.

Hinweis

Um zu gewährleisten, dass Ihr Cluster zuverlässig funktioniert, sollten Sie mindestens zwei (2) Knoten im Standardknotenpool ausführen.

Sie führen eine Skalierung oder ein Upgrade eines AKS-Clusters im Standardknotenpool durch. Sie können eine Skalierung oder ein Upgrade eines bestimmten Knotenpools auswählen. Bei Upgradevorgängen wird die Ausführung von Containern in anderen Knoten im Knotenpool geplant, bis das Upgrade für alle Knoten erfolgreich durchgeführt wurde.

Weitere Informationen zur Verwendung mehrerer Knotenpools in AKS finden Sie unter Erstellen mehrerer Knotenpools für einen Cluster in AKS.

Knotenselektoren

In einem AKS-Cluster mit mehreren Knotenpools müssen Sie dem Kubernetes-Scheduler möglicherweise mitteilen, welcher Knotenpool für eine bestimmte Ressource verwendet werden soll. Beispielsweise sollten Eingangscontroller nicht auf Windows Server-Knoten ausgeführt werden.

Mit Knotenselektoren können Sie verschiedene Parameter festlegen, z. B. das Betriebssystem des Knotens, um zu steuern, wo ein Pod geplant werden soll.

Das folgende einfache Beispiel plant eine NGINX-Instanz auf einem Linux-Knoten unter Verwendung des Knotenselektors "kubernetes.io/os": linux:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine
  nodeSelector:
    "kubernetes.io/os": linux

Weitere Informationen zum Steuern, wo Pods geplant werden, finden Sie unter Best Practices für erweiterte Schedulerfunktionen in Azure Kubernetes Service (AKS).

Knotenressourcengruppe

Wenn Sie einen AKS-Cluster erstellen, müssen Sie eine Ressourcengruppe angeben, in der die Clusterressource erstellt werden soll. Zusätzlich zu dieser Ressourcengruppe erstellt und verwaltet der AKS-Ressourcenanbieter auch eine separate Ressourcengruppe, die Knotenressourcengruppe genannt wird. Die Knotenressourcengruppe enthält die folgenden Infrastrukturressourcen:

• Die VM-Skalierungsgruppen und VMs für jeden Knoten in den Knotenpools
• Das virtuelle Netzwerk für den Cluster
• Den Speicher für den Cluster

Der Knotenressourcengruppe wird standardmäßig ein Name zugewiesen, z. B. MC_myResourceGroup_myAKSCluster_eastus. Während der Clustererstellung haben Sie auch die Möglichkeit, den Namen anzugeben, der Ihrer Knotenressourcengruppe zugewiesen wird. Wenn Sie Ihren AKS-Cluster löschen, löscht der AKS-Ressourcenanbieter automatisch die Knotenressourcengruppe.

Für die Knotenressourcengruppe gelten die folgenden Einschränkungen:

• Sie können keine vorhandene Ressourcengruppe als Knotenressourcengruppe angeben.
• Sie können kein anderes Abonnement für die Knotenressourcengruppe angeben.
• Sie können den Namen der Knotenressourcengruppe nicht ändern, nachdem der Cluster erstellt wurde.
• Sie können keine Namen für die verwalteten Ressourcen innerhalb der Knotenressourcengruppe angeben.
• Sie können von Azure erstellte Tags für verwaltete Ressourcen innerhalb der Knotenressourcengruppe nicht ändern oder löschen.

Wenn Sie die in Azure erstellten Tags und andere Ressourceneigenschaften in der Knotenressourcengruppe ändern oder löschen, kann dies zu unerwarteten Ergebnissen wie Skalierungs- und Aktualisierungsfehlern führen. Wenn AKS den Lebenszyklus der Infrastruktur in der Knotenressourcengruppe verwaltet, wird Ihr Cluster durch alle Änderungen in einen nicht unterstützten Zustand versetzt.

Ein häufiges Szenario, in dem Kunden Ressourcen ändern möchten, ist die Verwendung von Tags. Mit AKS können Sie Tags erstellen und ändern, die für Ressourcen in der Knotenressourcengruppe vorgesehen sind, und Sie können diese Tags beim Erstellen oder Aktualisieren des Clusters hinzufügen. Sie können benutzerdefinierte Tags erstellen oder ändern, um beispielsweise eine Geschäftseinheit oder eine Kostenstelle zuzuweisen. Dies können Sie auch durch Erstellen von Azure-Richtlinien erreichen, die auf die verwaltete Ressourcengruppe ausgerichtet sind.

Von Azure erstellte Tags für Ressourcen unter der Knotenressourcengruppe im AKS-Cluster dürfen nicht geändert werden, da dies zu einer Verletzung des Servicelevelziels (Service-Level Objective, SLO) führt. Weitere Informationen finden Sie unter Bietet AKS eine Vereinbarung zum Servicelevel?

Um die Wahrscheinlichkeit von Änderungen an der Knotenressourcengruppe, die sich auf Ihre Cluster auswirken, zu verringern, können Sie die Sperrung von Knotenressourcengruppen aktivieren, um eine Ablehnungszuweisung auf Ihre AKS-Ressourcen anzuwenden. Weitere Informationen finden Sie unter Clusterkonfiguration in AKS.

Warnung

Wenn Sie die Sperre für Knotenressourcengruppen nicht aktiviert haben, können Sie jede Ressource in der Knotenressourcengruppe direkt ändern. Das direkte Ändern von Ressourcen in der Knotenressourcengruppe kann dazu führen, dass Ihr Cluster instabil wird oder nicht mehr reagiert.

Pods

Kubernetes verwendet Pods, um eine Instanz Ihrer Anwendung auszuführen. Ein Pod repräsentiert eine einzelne Instanz der Anwendung.

Pods weisen in der Regel eine 1:1-Zuordnung mit einem Container auf. In erweiterten Szenarien kann ein Pod mehrere Container enthalten. Pods mit mehreren Containern werden zusammen auf dem gleichen Knoten geplant und ermöglichen es Containern, zugehörige Ressourcen gemeinsam zu nutzen.

Wenn Sie einen Pod erstellen, können Sie Ressourcenanforderungen definieren, um eine bestimmte Menge an CPU- oder Arbeitsspeicherressourcen anzufordern. Der Kubernetes-Scheduler versucht, die Anforderung zu erfüllen, indem er die Ausführung der Pods auf einem Knoten mit verfügbaren Ressourcen plant. Sie können auch maximale Ressourcenlimits angeben, um zu verhindern, dass ein Pod zu viele Computeressourcen des zugrunde liegenden Knotens verbraucht. Eine bewährte Methode ist es, Ressourcenlimits für alle Pods einzurichten, um den Kubernetes-Scheduler beim Identifizieren benötigter, zulässiger Ressourcen zu unterstützen.

Weitere Informationen finden Sie unter Kubernetes Pods (Kubernetes-Pods) und Kubernetes Pod Lifecycle (Lebenszyklus von Kubernetes-Pods).

Ein Pod ist eine logische Ressource, aber die Anwendungsworkloads werden in den Containern ausgeführt. Pods sind in der Regel kurzlebige Ressourcen, die gelöscht werden können. Einzeln geplante Pods bieten nicht alle Hochverfügbarkeits- und Redundanzfeatures von Kubernetes. Stattdessen werden Pods von Kubernetes-Controllern bereitgestellt und verwaltet, beispielsweise dem Bereitstellungscontroller.

Bereitstellungen und YAML-Manifeste

Eine Bereitstellung repräsentiert identische Pods, die vom Kubernetes-Bereitstellungscontroller verwaltet werden. Eine Bereitstellung definiert die Anzahl von Pod-Replikaten, die erstellt werden sollen. Der Kubernetes-Scheduler stellt sicher, dass zusätzliche Pods auf fehlerfreien Knoten geplant werden, wenn auf Pods oder Knoten Probleme auftreten.

Sie können Bereitstellungen aktualisieren, um die Konfiguration von Pods, das verwendete Containerimage oder den angeschlossenen Speicher zu ändern. Der Bereitstellungscontroller:

• Leert und beendet eine bestimmte Anzahl von Replikaten.
• Erstellt Replikate gemäß der neuen Bereitstellungsdefinition.
• Setzt den Prozess so lange fort, bis alle Replikate in der Bereitstellung aktualisiert wurden.

Die meisten zustandslosen Anwendungen in AKS sollten das Bereitstellungsmodell verwenden, anstatt einzelne Pods zu planen. Kubernetes kann die Integrität und den Status von Bereitstellungen überwachen, um sicherzustellen, dass die erforderliche Anzahl von Replikaten im Cluster ausgeführt wird. Beim Planen einzelner Pods werden diese nach dem Auftreten eines Problems nicht neu gestartet. Außerdem werden die Pods nicht auf fehlerfreien Knoten erneut geplant, wenn auf dem aktuellen Knoten ein Problem auftritt.

Sie möchten nicht, dass Verwaltungsentscheidungen durch einen Updateprozess unterbrochen werden, wenn Ihre Anwendung eine Mindestanzahl verfügbarer Instanzen erfordert. Budgets für die Unterbrechung von Pods definieren, wie viele Replikate in einer Bereitstellung während einer Aktualisierung oder eines Knotenupgrades heruntergefahren werden können. Ein Beispiel: Wenn Sie in Ihrer Bereitstellung über fünf (5) Replikate verfügen, können Sie eine Podunterbrechung für vier (4) Replikate definieren, damit jeweils nur ein Replikat gelöscht oder neu geplant werden darf. Ebenso wie bei Podressourcenlimits besteht eine bewährte Methode darin, Budgets für die Unterbrechung von Pods für Anwendungen zu definieren, für die immer eine bestimmte Mindestanzahl von Replikaten vorhanden sein muss.

Bereitstellungen werden in der Regel mit kubectl create oder kubectl apply erstellt und verwaltet. Erstellen Sie eine Bereitstellung, indem Sie eine Manifestdatei im YAML-Format definieren.

Das folgende Beispiel erstellt eine grundlegende Bereitstellung eines NGINX-Webservers. Die Bereitstellung gibt an, dass 3 Replikate erstellt werden sollen und dass Port 80 auf dem Container geöffnet sein muss. Es werden auch Ressourcenanforderungen und -limits für CPU und Arbeitsspeicher definiert.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: mcr.microsoft.com/oss/nginx/nginx:1.15.2-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
            memory: 64Mi
          limits:
            cpu: 500m
            memory: 256Mi

Die Bereitstellungsspezifikationen in der YAML-Manifestdatei lassen sich wie folgt aufschlüsseln:

Spezifikation	BESCHREIBUNG
.apiVersion	Gibt die API-Gruppe und API-Ressource an, die Sie beim Erstellen der Ressource verwenden möchten.
.kind	Gibt die Art der zu erstellenden Ressource an.
.metadata.name	Gibt den Namen der Bereitstellung an. Diese Datei führt das nginx-Image aus Docker Hub aus.
.spec.replicas	Gibt an, wie viele Pods erstellt werden sollen. Diese Datei erstellt drei duplizierte Pods.
.spec.selector	Gibt an, welche Pods von dieser Bereitstellung betroffen sind.
.spec.selector.matchLabels	Sie enthält eine Zuordnung von {Schlüssel, Wert}-Paaren, die es der Bereitstellung ermöglicht, die erstellten Pods zu finden und zu verwalten.
.spec.selector.matchLabels.app	Muss mit .spec.template.metadata.labels übereinstimmen.
.spec.template.labels	Gibt die {Schlüssel, Wert}-Paare an, die dem Objekt angefügt sind.
.spec.template.app	Muss mit .spec.selector.matchLabels übereinstimmen.
.spec.spec.containers	Gibt die Liste der Container an, die zum Pod gehören.
.spec.spec.containers.name	Gibt den Namen des angegebenen Containers als DNS-Bezeichnung an.
.spec.spec.containers.image	Gibt den Namen des Containerimages an.
.spec.spec.containers.ports	Gibt die Liste der Ports an, die über den Container verfügbar gemacht werden sollen.
.spec.spec.containers.ports.containerPort	Sie gibt die Anzahl der Ports an, die an der IP-Adresse des Pods verfügbar gemacht werden sollen.
.spec.spec.resources	Gibt die für den Container erforderlichen Computeressourcen an.
.spec.spec.resources.requests	Gibt die Mindestmenge der erforderlichen Computeressourcen an.
.spec.spec.resources.requests.cpu	Gibt die Mindestmenge der erforderlichen CPU-Ressourcen an.
.spec.spec.resources.requests.memory	Gibt die Mindestmenge des erforderlichen Arbeitsspeichers an.
.spec.spec.resources.limits	Gibt die maximal zulässige Menge an Computeressourcen an. Dieser Grenzwert wird von Kubelet erzwungen.
.spec.spec.resources.limits.cpu	Gibt die maximal zulässige Menge an CPU-Ressourcen an. Dieser Grenzwert wird von Kubelet erzwungen.
.spec.spec.resources.limits.memory	Gibt die maximal zulässige Menge an Arbeitsspeicher an. Dieser Grenzwert wird von Kubelet erzwungen.

Indem Sie Dienste (z. B. Lastenausgleichsmodule) im YAML-Manifest angeben, können Sie auch komplexere Anwendungen erstellen.

Weitere Informationen finden Sie unter Kubernetes-Bereitstellungen.

Paketverwaltung mit Helm

Helm wird häufig zum Verwalten von Anwendungen in Kubernetes verwendet. Sie können Ressourcen bereitstellen, indem Sie vorhandene öffentliche Helm-Charts erstellen und verwenden, die eine gepackte Version des Anwendungscodes und der Kubernetes-YAML-Manifeste enthalten. Sie können Helm-Charts entweder lokal oder in einem Remoterepository speichern, z. B. einem Helm-Chart-Repository in Azure Container Registry.

Um Helm zu verwenden, installieren Sie den Helm-Client auf Ihrem Computer, oder verwenden Sie den Helm-Client in Azure Cloud Shell. Suchen oder erstellen Sie Helm-Charts, und installieren Sie diese dann in Ihrem Kubernetes-Cluster. Weitere Informationen finden Sie unter Installieren vorhandener Anwendungen mit Helm in AKS.

StatefulSets und DaemonSets

Mithilfe des Kubernetes-Schedulers führt der Bereitstellungscontroller Replikate auf einem beliebigen verfügbaren Knoten mit verfügbaren Ressourcen aus. Dieser Ansatz mag zwar für zustandslose Anwendungen genügen, doch ist der Bereitstellungscontroller für Anwendungen, die Folgendes erfordern, nicht optimal geeignet:

• Eine permanente Namenskonvention oder einen permanenten Speicher
• Ein vorhandenes Replikat auf jedem ausgewählten Knoten in einem Cluster

Mit zwei Kubernetes-Ressourcen können Sie jedoch diese Arten von Anwendungen verwalten:

• StatefulSets verwalten den Zustand von Anwendungen über den Lebenszyklus eines einzelnen Pods hinaus.
• DaemonSets stellen zu einem frühen Zeitpunkt im Kubernetes-Bootstrapprozess eine ausgeführte Ressource auf jedem Knoten sicher.

StatefulSets

Die moderne Anwendungsentwicklung strebt häufig nach zustandslosen Anwendungen. Für zustandsbehafte Anwendungen, z. B. solche, die Datenbankkomponenten enthalten, können Sie StatefulSets verwenden. Wie bei Bereitstellungen erstellt und verwaltet ein StatefulSet mindestens einen identischen Pod. Replikate in einem StatefulSet folgen einem ordnungsgemäßen, sequenziellen Verfahren für Bereitstellung, Skalierung, Upgrade und Beendigung. Namenskonvention, Netzwerknamen und Speicher bleiben permanent erhalten, wenn Replikate mit einem StatefulSet neu geplant werden.

Definieren Sie die Anwendung im YAML-Format mit kind: StatefulSet. Ab diesem Punkt übernimmt der StatefulSet-Controller die Bereitstellung und Verwaltung der erforderlichen Replikate. Daten werden in permanenten Speicher geschrieben, der von Azure Managed Disks oder Azure Files bereitgestellt wird. Bei StatefulSets bleibt der zugrunde liegende permanente Speicher erhalten, auch wenn das StatefulSet gelöscht wird.

Weitere Informationen finden Sie unter Kubernetes StatefulSets.

Replikate in einem StatefulSet werden auf einem beliebigen verfügbaren Knoten in einem AKS-Cluster geplant und ausgeführt. Um sicherzustellen, dass mindestens ein Pod in Ihrem Set auf einem Knoten ausgeführt wird, verwenden Sie stattdessen ein DaemonSet.

DaemonSets

Für bestimmte Protokollsammlungen oder -überwachungen müssen Sie möglicherweise einen Pod auf allen Knoten oder eine ausgewählte Menge von Knoten ausführen. Sie können DaemonSets verwenden, um eine oder mehrere identische Pods bereitzustellen. Der DaemonSet-Controller stellt sicher, dass jeder angegebene Knoten eine Instanz des Pods ausführt.

Der DaemonSet-Controller kann Pods auf Knoten zu einem frühen Zeitpunkt im Clusterstartprozess planen, bevor der Kubernetes Scheduler gestartet wird. Dies stellt sicher, dass die Pods in einem DaemonSet gestartet wurden, bevor herkömmliche Pods in einer Bereitstellung oder einem StatefulSet geplant werden.

Ähnlich wie StatefulSets wird auch ein DaemonSet mit kind: DaemonSet als Teil einer YAML-Definition definiert.

Weitere Informationen finden Sie unter Kubernetes DaemonSets.

Hinweis

Wenn Sie das Add-On für virtuelle Knoten verwenden, erstellen DaemonSets keine Pods auf dem virtuellen Knoten.

Namespaces

Kubernetes-Ressourcen wie Pods und Bereitstellungen werden logisch in einem Namespace gruppiert, um einen AKS-Cluster zu unterteilen und den Zugriff auf Ressourcen zu erstellen, anzuzeigen oder zu verwalten. Sie können z. B. Namespaces erstellen, um Unternehmensgruppen voneinander zu trennen. Benutzer können nur mit den Ressourcen innerhalb der ihnen zugewiesenen Namespaces interagieren.

Wenn Sie einen AKS-Cluster erstellen, stehen Ihnen folgende Namespaces zur Verfügung:

Namespace	BESCHREIBUNG
default	Hier werden Pods und Bereitstellungen standardmäßig erstellt, wenn kein anderer Namespace angegeben wird. In kleineren Umgebungen können Sie Anwendungen direkt im Standardnamespace bereitstellen, ohne weitere logische Unterteilungen zu erstellen. Wenn Sie mit der Kubernetes-API interagieren, z.B. mit kubectl get pods, wird der Standardnamespace verwendet, wenn kein anderer Namespace angegeben wurde.
kube-system	Hier befinden sich grundlegende Ressourcen, beispielsweise Netzwerkfeatures wie DNS und Proxy oder das Kubernetes-Dashboard. In diesem Namespace stellen Sie in der Regel keine eigenen Anwendungen bereit.
kube-public	Dieser Namespace wird in der Regel nicht genutzt. Er kann jedoch für Ressourcen verwendet werden, die über den gesamten Cluster hinweg sichtbar sein sollen, und er kann von allen Benutzern angezeigt werden.

Weitere Informationen finden Sie unter Kubernetes-Namespaces.

Nächste Schritte

In diesem Artikel wurden einige der wichtigsten Kubernetes-Komponenten sowie deren Anwendung in AKS-Clustern beschrieben. Weitere Informationen zu den wesentlichen Konzepten von Kubernetes und AKS finden Sie in den folgenden Artikeln:

• AKS Zugriff und Identität
• AKS-Sicherheit
• AKS Virtuelle Netzwerke
• AKS Speicher
• AKS Skalierung