Grundlegende Kubernetes-Konzepte für Azure Kubernetes Service (AKS)

In diesem Artikel werden die grundlegenden Konzepte von Azure Kubernetes Service (AKS) beschrieben, einem verwalteten Kubernetes-Dienst, mit dem Sie containerisierte Anwendungen im großen Stil in Azure bereitstellen und betreiben können. Er hilft Ihnen, mehr über die Infrastrukturkomponenten von Kubernetes zu erfahren und ein tieferes Verständnis der Funktionsweise von Kubernetes in AKS zu erhalten.

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 und 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 zustandslose und zustandsbehaftete Anwendungen.

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

• Die Steuerungsebene stellt die grundlegenden Kubernetes-Dienste und Orchestrierungsfunktionen für Anwendungsworkloads und
• Knoten, die Ihre Anwendungsworkloads ausführen.

Steuerungsebene

Wenn Sie einen AKS-Cluster erstellen, erstellt und konfiguriert die Azure-Plattform automatisch die zugeordnete Steuerungsebene. Diese Steuerungsebene mit Einzelmandant 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 ausschließlich in der Region, in der Sie den Cluster erstellt haben.

Die Steuerungsebene umfasst die folgenden Kubernetes-Kernkomponenten:

Komponente	BESCHREIBUNG
kube-apiserver	Der API-Server macht die zugrunde liegenden Kubernetes-APIs verfügbar und stellt die Interaktion für Verwaltungstools wie kubectl oder das Kubernetes-Dashboard bereit.
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 die identifizierten Knoten.
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.

Denken Sie daran, dass Sie nicht direkt auf die Steuerungsebene zugreifen können. 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 die Steuerungsebenenprotokolle überprüfen.

Nodes

Zum Ausführen Ihrer Anwendungen und der unterstützenden Dienste benötigen Sie einen Kubernetes-Knoten. Jeder 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.

Die Knoten umfassen die folgenden grundlegenden Kubernetes-Komponenten:

Komponente	Beschreibung
kubelet	Der Kubernetes-Agent, der die Orchestrierungsanforderungen der Steuerungsebene sowie die Planung und Ausführung der angeforderten Container verarbeitet
kube-proxy	Der Proxy behandelt virtuelle Netzwerke auf jedem Knoten, Routing des Netzwerkdatenverkehrs und die Verwaltung der IP-Adressierung für Dienste und Pods.
Containerruntime	Die Containerruntime ermöglicht die Ausführung von containerisierten Anwendungen und die Interaktion mit weiteren Ressourcen, wie z. B. dem virtuellen Netzwerk oder Speicher. Weitere Informationen finden Sie unter den Containerlaufzeitkonfiguration.

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

Standardmäßig werden Größe und Leistung für verwaltete Datenträger entsprechend der Anzahl der ausgewählten VM-SKU und vCPU zugewiesen. Weitere Informationen finden Sie unter Standardmäßige Festplattengröße des Betriebssystems.

Betriebssystemkonfiguration

AKS unterstützt Ubuntu 22.04 und Azure Linux 2.0 als Knotenbetriebssystem (OS) für Cluster mit Kubernetes 1.25 und höher. Ubuntu 18.04 kann auch bei der Knotenpoolerstellung für Kubernetes-Versionen 1.24 und niedriger angegeben werden.

AKS unterstützt Windows Server 2022 als Standardbetriebssystem für Windows-Knotenpools in Clustern mit Kubernetes 1.25 und höher. Windows Server 2019 kann auch bei der Knotenpoolerstellung für Kubernetes-Versionen 1.32 und niedriger angegeben werden. Windows Server 2019 wird eingestellt, nachdem Kubernetes Version 1.32 das Ende der Lebensdauer erreicht hat, und wird in zukünftigen Releases nicht mehr unterstützt. Weitere Informationen zu dieser Einstellung finden Sie in den AKS-Versionshinweisen.

Konfiguration der Containerruntime

Eine Containerruntime ist eine Software, die Container ausführt und Containerimages auf einem Knoten verwaltet. Die Runtime erleichtert die Abstraktion von sys-Aufrufen oder betriebssystemspezifischen Funktionen zum Ausführen von Containern unter Linux oder Windows. Bei Linux-Knotenpools wird containerd für Kubernetes Version 1.19 und höher verwendet. Für Windows Server 2019- und 2022-Knotenpools ist containerd allgemein verfügbar, und die einzige Container-Laufzeitumgebung in Kubernetes Version 1.23 oder höher. Seit Mai 2023 ist Docker eingestellt und nicht mehr unterstützt. Weitere Informationen zu dieser Einstellung finden Sie in den AKS-Versionshinweisen.

Containerd ist eine mit OCI (Open Container Initiative) kompatible Core-Containerruntime, die den Mindestsatz erforderlicher Funktionen zum Ausführen von Containern und zum Verwalten von Images auf einem Knoten bereitstellt. Bei Knoten und Knotenpools, die auf containerd basieren, kommuniziert das Kubelet direkt über das CRI-Plug-In (Container Runtime Interface) mit containerd. Gegenüber der Docker CRI-Implementierung benötigt der Datenfluss so weniger Hops. Daraus ergibt sich eine verringerte Wartezeit beim Podstart und eine geringere Ressourcenauslastung (CPU und Arbeitsspeicher).

Containerd funktioniert mit jeder allgemein verfügbaren Version von Kubernetes in AKS und mit jeder Upstream-Kubernetes-Version ab 1.19 und unterstützt alle Funktionen von Kubernetes und AKS.

Einschränkungen und Unterschiede von containerd

• Bei containerd wird empfohlen, crictl als Ersatz für die Docker-CLI für die Problembehandlung bei Pods, Containern und Containerimages auf Kubernetes-Knoten zu verwenden. Weitere Informationen zu crictl finden Sie unter Allgemeine Verwendung und Clientkonfigurationsoptionen.

  • Containerd unterstützt nicht alle Funktionen der Docker-CLI. Es ist nur für die Problembehandlung verfügbar.
  • crictl bietet eine für Kubernetes besser geeignete Ansicht von Containern mit Unterstützung von Konzepten wie Pods.

• Containerd richtet die Protokollierung mithilfe des standardisierten cri-Protokollierungsformats ein. Ihre Protokollierungslösung muss das cri-Protokollierungsformat unterstützen, wie z. B. Azure Monitor für Container.

• Sie können nicht mehr auf die Docker-Engine /var/run/docker.sock zugreifen oder Docker-in-Docker (DinD) verwenden.

  • Wenn Sie zurzeit Anwendungsprotokolle oder Überwachungsdaten aus der Docker-Engine extrahieren, verwenden Sie stattdessen Containererkenntnisse. AKS unterstützt die Ausführung von Out-of-Band-Befehlen auf den Agent-Knoten nicht, die zu Instabilität führen könnten.
  • Es wird nicht empfohlen, Images zu erstellen oder das Docker-Modul direkt zu verwenden. Kubernetes erkennt diese genutzten Ressourcen nicht vollständig, und diese Methoden bringen zahlreiche Probleme mit sich, die hier und hier erläutert werden.

• Beim Erstellen von Images können Sie Ihren aktuellen Docker-Buildworkflow weiterhin wie gewohnt verwenden, es sei denn, Sie erstellen Images in Ihrem AKS-Cluster. Erwägen Sie in diesem Fall die Umstellung auf die empfohlene Vorgehensweise zum Erstellen von Images mithilfe von ACR Tasks oder eine sicherere clusterinterne Option wie Docker Buildx.

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.

Um die zuweisbare Ressource eines Knotens zu finden, können Sie den Befehl kubectl describe node verwenden:

kubectl describe node [NODE_NAME]

Um die Leistung und Funktionalität des Knotens zu gewährleisten, reserviert AKS zwei Ressourcentypen auf jedem Knoten, CPU und Arbeitsspeicher. Wenn ein Knoten mehr Ressourcen nutzt, steigt die Anzahl der reservierten Ressourcen aufgrund eines höheren Verwaltungsbedarfs für vom Benutzer bereitgestellte Pods. Beachten Sie, dass die Ressourcenreservierungen nicht geändert werden können.

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. Die folgende Tabelle zeigt die CPU-Reservierung in Millicores:

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

Arbeitsspeicher

Der reservierte Arbeitsspeicher in AKS umfasst die Summe von zwei Werten:

AKS 1.29 und höher

1. kubelet Daemon verfügt standardmäßig über die memory.available<100Mi Entfernungsregel. Durch diese Regel 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. kubelet Daemon verfügt standardmäßig über die memory.available<750Mi-Entfernungsregel. Durch diese Regel wird sichergestellt, dass ein Knoten immer über mindestens 750 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 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

Speicher- und CPU-Zuteilungsregeln sind konzipiert für:

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

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

Knoten mit der gleichen Konfiguration werden in Knotenpools gruppiert. Jeder Kubernetes-Cluster enthält mindestens einen Knotenpool. Sie definieren die anfängliche Knotenanzahl und -größe beim Erstellen eines AKS-Clusters, wobei ein Standardknotenpool erstellt wird. Dieser Standardknotenpool in AKS enthält die zugrunde liegenden VMs, die Ihre Agent-Knoten 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 finden Sie unter Erstellen von Knotenpools und Verwalten von Knotenpools.

Standarddimensionierung von Betriebssystemdatenträgern

Wenn Sie einen neuen Cluster erstellen oder einen neuen Knotenpool zu einem vorhandenen Cluster hinzufügen, bestimmt die Anzahl der vCPUs standardmäßig die Größe des Betriebssystemdatenträgers. Die Anzahl der vCPUs basiert auf der VM-SKU. In der folgenden Tabelle ist die Standardgröße des Betriebssystemdatenträgers für jede VM-SKU aufgeführt:

VM-SKU-Kerne (vCPUs)	Standardebene von Betriebssystemdatenträgern	Bereitgestellte IOPS	Bereitgestellter Durchsatz (MBit/s)
1 bis 7	P10/128G	500	100
8 bis 15	P15/256G	1100	125
16 bis 63	P20/512G	2300	150
mehr als 64	P30/1024G	5.000	200

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. Sie können mit Knotenselektoren verschiedene Parameter definieren, 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 finden Sie unter Best Practices für erweiterte Schedulerfunktionen in Azure Kubernetes Service (AKS).

Knotenressourcengruppe

Wenn Sie einen AKS-Cluster erstellen, geben Sie eine Ressourcengruppe an, in der die Clusterressource erstellt werden soll. Zusätzlich zu dieser Ressourcengruppe erstellt und verwaltet der AKS-Ressourcenanbieter 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 mit dem folgenden Format zugewiesen: MC_resourceGroupName_clusterName_location. Während der Clustererstellung können Sie den Namen angeben, der Ihrer Knotenressourcengruppe zugewiesen wird. Wenn Sie eine Azure Resource Manager-Vorlage verwenden, können Sie den Namen mithilfe der nodeResourceGroup-Eigenschaft definieren. Bei Verwendung der Azure CLI verwenden Sie den Parameter --node-resource-group mit dem Befehl az aks create, wie im folgenden Beispiel gezeigt:

az aks create --name myAKSCluster --resource-group myResourceGroup --node-resource-group myNodeResourceGroup

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.

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. Wenn Sie die in Azure erstellten Tags oder 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. Weitere Informationen finden Sie unter Bietet AKS eine Vereinbarung zum Servicelevel?

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. Sie können auch Azure-Richtlinien mit einem Bereich erstellen, der die verwaltete Ressourcengruppe abdeckt.

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 Vollständig verwaltete Ressourcengruppe (Vorschau).

Pods

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

Pods weisen in der Regel ein 1:1-Mapping 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 für eine bestimmte Menge an CPU oder Arbeitsspeicher definieren. 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. Unsere empfohlene bewährte Methode ist, 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 Containerimage oder den angehängten Speicher zu ändern.

Der Bereitstellungscontroller verwaltet den Bereitstellungslebenszyklus und führt die folgenden Aktionen aus:

• 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 sie 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 Replikate verfügen, können Sie eine Podunterbrechung für vier Replikate definieren, damit jeweils nur ein Replikat gelöscht oder neu geplant werden darf. Ebenso wie bei Podressourcenlimits besteht eine empfohlene 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. Sie können eine Bereitstellung erstellen, indem Sie eine Manifestdatei im YAML-Format definieren. Das folgende Beispiel zeigt eine grundlegende Bereitstellungsmanifestdatei für einen NGINX-Webserver:

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. In diesem Beispiel wird das nginx-Image von Docker Hub ausgeführt.
.spec.replicas	Gibt an, wie viele Pods erstellt werden sollen. In diesem Beispiel erstellt die YAML-Datei 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. Das Kubelet erzwingt diesen Grenzwert.
.spec.spec.resources.limits.cpu	Gibt die maximal zulässige Menge an CPU-Ressourcen an. Das Kubelet erzwingt diesen Grenzwert.
.spec.spec.resources.limits.memory	Gibt die maximal zulässige Menge an Arbeitsspeicher an. Das Kubelet erzwingt diesen Grenzwert.

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

Der Bereitstellungscontroller verwendet den Kubernetes-Scheduler und führt 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 folgende Spezifikationen 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 und DaemonSets.

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.

Sie können die Anwendung im YAML-Format mit kind: StatefulSet definieren. 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.

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 können Sie auch einen DaemonSet mit kind: DaemonSet als Teil einer YAML-Definition definieren.

Weitere Informationen finden Sie unter Kubernetes DaemonSets.

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. Sie können ihn jedoch für Ressourcen verwenden, 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

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