website/content/de/docs/concepts/workloads/pods/_index.md

---
title: Pods
content_type: concept
weight: 10
no_list: true
card:
 name: concepts
 weight: 60
---

<!-- overview -->

_Pods_ sind die kleinsten einsetzbaren Einheiten, die in Kubernetes
erstellt und verwaltet werden können.

Ein _Pod_ (übersetzt Gruppe/Schote, wie z. B. eine Gruppe von Walen oder eine 
Erbsenschote) ist eine Gruppe von einem oder mehreren 
{{< glossary_tooltip text="Containern" term_id="container" >}} mit gemeinsam 
genutzten Speicher- und Netzwerkressourcen und einer Spezifikation für die 
Ausführung der Container. Die Ressourcen eines Pods befinden sich immer auf dem 
gleichen (virtuellen) Server, werden gemeinsam geplant und in einem
gemeinsamen Kontext ausgeführt. Ein Pod modelliert einen anwendungsspezifischen 
"logischen Server": Er enthält eine oder mehrere containerisierte Anwendungen, 
die relativ stark voneinander abhängen. 
In Nicht-Cloud-Kontexten sind Anwendungen, die auf
demselben physischen oder virtuellen Server ausgeführt werden, vergleichbar zu 
Cloud-Anwendungen, die auf demselben logischen Server ausgeführt werden.

Ein Pod kann neben Anwendungs-Containern auch sogenannte 
[Initialisierungs-Container](/docs/concepts/workloads/pods/init-containers/)
enthalten, die beim Starten des Pods ausgeführt werden.
Es können auch 
kurzlebige/[ephemere Container](/docs/concepts/workloads/pods/ephemeral-containers/)
zum Debuggen gestartet werden, wenn dies der Cluster anbietet.

<!-- body -->

## Was ist ein Pod?

{{< note >}}
Obwohl Kubernetes abgesehen von [Docker](https://www.docker.com/) auch andere
{{<glossary_tooltip text="Container-Laufzeitumgebungen" 
term_id="container-runtime">}} unterstützt, ist Docker am bekanntesten und
 es ist hilfreich, Pods mit der Terminologie von Docker zu beschreiben.
{{< /note >}}

Der gemeinsame Kontext eines Pods besteht aus einer Reihe von Linux-Namespaces, 
Cgroups und möglicherweise anderen Aspekten der Isolation, also die gleichen
Dinge, die einen Dockercontainer isolieren. Innerhalb des Kontexts eines Pods 
können die einzelnen Anwendungen weitere Unterisolierungen haben. 

Im Sinne von Docker-Konzepten ähnelt ein Pod einer Gruppe von Docker-Containern, 
die gemeinsame Namespaces und Dateisystem-Volumes nutzen.

## Pods verwenden

Normalerweise müssen keine Pods erzeugt werden, auch keine Singleton-Pods. 
Stattdessen werden sie mit Workload-Ressourcen wie {{<glossary_tooltip 
text="Deployment" term_id="deployment">}} oder {{<glossary_tooltip 
text="Job" term_id="job">}} erzeugt. Für Pods, die von einem Systemzustand
abhängen, ist die Nutzung von {{<glossary_tooltip text="StatefulSet" 
term_id="statefulset">}}-Ressourcen zu erwägen.

Pods in einem Kubernetes-Cluster werden hauptsächlich auf zwei Arten verwendet:

* **Pods, die einen einzelnen Container ausführen**. Das 
"Ein-Container-per-Pod"-Modell ist der häufigste Kubernetes-Anwendungsfall. In 
diesem Fall kannst du dir einen einen Pod als einen Behälter vorstellen, der einen 
einzelnen Container enthält; Kubernetes verwaltet die Pods anstatt die 
Container direkt zu verwalten.
* **Pods, in denen mehrere Container ausgeführt werden, die zusammenarbeiten
müssen**. Wenn eine Softwareanwendung aus co-lokaliserten Containern besteht, 
die sich gemeinsame Ressourcen teilen und stark voneinander abhängen, kann ein 
Pod die Container verkapseln. 
Diese Container bilden eine einzelne zusammenhängende 
Serviceeinheit, z. B. ein Container, der Daten in einem gemeinsam genutzten 
Volume öffentlich verfügbar macht, während ein separater _Sidecar_-Container 
die Daten aktualisiert. Der Pod fasst die Container, die Speicherressourcen
und eine kurzlebiges Netzwerk-Identität als eine Einheit zusammen.

{{< note >}}
Das Gruppieren mehrerer gemeinsam lokalisierter und gemeinsam verwalteter
Container in einem einzigen Pod ist ein relativ fortgeschrittener 
Anwendungsfall. Du solltest diese Architektur nur in bestimmten  Fällen 
verwenden, wenn deine Container stark voneinander abhängen.
{{< /note >}}

Jeder Pod sollte eine einzelne Instanz einer gegebenen Anwendung ausführen. Wenn 
du deine Anwendung horizontal skalieren willst (um mehr Instanzen auszuführen
und  dadurch mehr Gesamtressourcen bereitstellen), solltest du mehrere Pods 
verwenden, einen für jede Instanz. 
In Kubernetes wird dies typischerweise als Replikation bezeichnet.
Replizierte Pods werden normalerweise als eine Gruppe durch eine 
Workload-Ressource und deren 
{{<glossary_tooltip text="Controller" term_id="controller">}} erstellt 
und verwaltet.

Der Abschnitt [Pods und Controller](#pods-und-controller) beschreibt, wie 
Kubernetes Workload-Ressourcen und deren Controller verwendet, um Anwendungen 
zu skalieren und zu heilen.

### Wie Pods mehrere Container verwalten

Pods unterstützen mehrere kooperierende Prozesse (als Container), die eine 
zusammenhängende Serviceeinheit bilden. Kubernetes plant und stellt automatisch 
sicher, dass sich die Container in einem Pod  auf demselben physischen oder 
virtuellen Server im Cluster befinden. Die Container können Ressourcen und
Abhängigkeiten gemeinsam nutzen, miteinander kommunizieren und
ferner koordinieren wann und wie sie beendet werden.

Zum Beispiel könntest du einen Container haben, der als Webserver für Dateien in
einem gemeinsamen Volume arbeitet. Und ein separater "Sidecar" -Container 
aktualisiert die Daten von einer externen Datenquelle, siehe folgenden 
Abbildung:

{{< figure src="/images/docs/pod.svg" alt="Pod-Beispieldiagramm" width="50%" >}}

Einige Pods haben sowohl {{<glossary_tooltip text="Initialisierungs-Container" 
term_id="init-container">}} als auch {{<glossary_tooltip 
text="Anwendungs-Container" term_id="app-container">}}. 
Initialisierungs-Container werden gestartet und beendet bevor die 
Anwendungs-Container gestartet werden.

Pods stellen standardmäßig zwei Arten von gemeinsam Ressourcen für die 
enthaltenen Container bereit:
[Netzwerk](#pod-netzwerk) und [Speicher](#datenspeicherung-in-pods).


## Mit Pods arbeiten

Du wirst selten einzelne Pods direkt in Kubernetes erstellen, selbst 
Singleton-Pods. Das liegt daran, dass Pods als relativ kurzlebige 
Einweg-Einheiten konzipiert sind. Wann Ein Pod erstellt wird (entweder direkt 
von Ihnen oder indirekt von einem
{{<glossary_tooltip text="Controller" term_id="controller">}}), wird die 
Ausführung auf einem {{<glossary_tooltip term_id="node">}} in Ihrem Cluster 
geplant. Der Pod bleibt auf diesem (virtuellen) Server, bis entweder der Pod die
Ausführung beendet hat, das Pod-Objekt gelöscht wird, der Pod aufgrund 
mangelnder Ressourcen *evakuiert* wird oder oder der Node ausfällt. 

{{< note >}}
Das Neustarten eines Containers in einem Pod sollte nicht mit dem Neustarten 
eines Pods verwechselt werden. Ein Pod ist kein Prozess, sondern eine Umgebung 
zur Ausführung von Containern. Ein Pod bleibt bestehen bis er gelöscht wird.
{{< /note >}}

Stelle beim Erstellen des Manifests für ein Pod-Objekt sicher, dass der 
angegebene Name ein gültiger
[DNS-Subdomain-Name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)
ist.

### Pods und Controller

Mit Workload-Ressourcen kannst du mehrere Pods erstellen und verwalten. Ein 
Controller für die Ressource kümmert sich um Replikation, Roll-Out sowie 
automatische Wiederherstellung im Fall von versagenden Pods. Wenn beispielsweise ein Node 
ausfällt, bemerkt ein Controller, dass die Pods auf dem Node nicht mehr laufen 
und plant die Ausführung eines Ersatzpods auf einem funktionierenden Node.
Hier sind einige Beispiele für Workload-Ressourcen, die einen oder mehrere Pods 
verwalten:

* {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}

### Pod Vorlagen

Controller für 
{{<glossary_tooltip text="Workload" term_id="workload">}}-Ressourcen 
erstellen Pods von einer _Pod Vorlage_ und verwalten diese Pods für dich.

Pod Vorlagen sind Spezifikationen zum Erstellen von Pods und sind in 
Workload-Ressourcen enthalten wie z. B.
[Deployments](/docs/concepts/workloads/controllers/deployment/),
[Jobs](/docs/concepts/workloads/controllers/job/), and
[DaemonSets](/docs/concepts/workloads/controllers/daemonset/).

Jeder Controller für eine Workload-Ressource verwendet die Pod Vorlage innerhalb 
des Workload-Objektes, um Pods zu erzeugen. Die Pod Vorlage ist Teil des 
gewünschten Zustands der Workload-Ressource, mit der du deine Anwendung 
ausgeführt hast.

Das folgende Beispiel ist ein Manifest für einen einfachen Job mit einer 
`Vorlage`, die einen Container startet. Der Container in diesem Pod druckt 
eine Nachricht und pausiert dann.

```yaml
apiVersion: batch/v1
kind: Job
metadata:
 name: hello
spec:
 template:
 # Dies is the Pod Vorlage
 spec:
 containers:
 - name: hello
 image: busybox
 command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
 restartPolicy: OnFailure
 # Die Pod Vorlage endet hier
```
Das Ändern der Pod Vorlage oder der Wechsel zu einer neuen Pod Vorlage hat keine 
direkten Auswirkungen auf bereits existierende Pods. Wenn du die Pod Vorlage für
eine Workload-Ressource änderst, dann muss diese Ressource die Ersatz-Pods
erstellen, welche die aktualisierte Vorlage verwenden. 

Beispielsweise stellt der StatefulSet-Controller sicher, dass für jedes
StatefulSet-Objekt die ausgeführten Pods mit der aktueller Pod Vorlage 
übereinstimmen. Wenn du das StatefulSet bearbeitest und die Vorlage änderst, 
beginnt das StatefulSet mit der Erstellung neuer Pods basierend auf der 
aktualisierten Vorlage. Schließlich werden alle alten Pods durch neue Pods 
ersetzt, und das Update ist abgeschlossen.

Jede Workload-Ressource implementiert eigenen Regeln für die Umsetzung von 
Änderungen der Pod Vorlage. Wenn du mehr über StatefulSet erfahren möchtest, 
dann lese die Seite
[Update-Strategien](/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets) 
im Tutorial StatefulSet Basics.


Auf Nodes beobachtet oder verwaltet das 
{{< glossary_tooltip term_id="kubelet" text="Kubelet" >}}
nicht direkt die Details zu Pod Vorlagen und Updates. Diese Details sind 
abstrahiert. Die Abstraktion und Trennung von Aufgaben vereinfacht die 
Systemsemantik und ermöglicht so das Verhalten des Clusters zu ändern ohne 
vorhandenen Code zu ändern.

## Pod Update und Austausch

Wie im vorherigen Abschnitt erwähnt, erstellt der Controller neue Pods basierend
auf der aktualisierten Vorlage, wenn die Pod Vorlage für eine Workload-Ressource
geändert wird anstatt die vorhandenen Pods zu aktualisieren oder zu patchen.

Kubernetes hindert dich nicht daran, Pods direkt zu verwalten. Es ist möglich, 
einige Felder eines laufenden Pods zu aktualisieren. Allerdings haben 
Pod-Aktualisierungsvorgänge wie zum Beispiel
[`patch`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#patch-pod-v1-core), 
und
[`replace`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replace-pod-v1-core)
einige Einschränkungen:

- Die meisten Metadaten zu einem Pod können nicht verändert werden. Zum Beispiel kannst
  du nicht die Felder `namespace`, `name`, `uid`, oder `creationTimestamp` 
  ändern. Das `generation`-Feld muss eindeutig sein. Es werden nur Aktualisierungen 
  akzeptiert, die den Wert des Feldes inkrementieren.
- Wenn das Feld `metadata.deletionTimestamp` gesetzt ist, kann kein neuer 
  Eintrag zur Liste `metadata.finalizers` hinzugefügt werden.
- Pod-Updates dürfen keine Felder ändern, die Ausnahmen sind 
  `spec.containers[*].image`,
 `spec.initContainers[*].image`,` spec.activeDeadlineSeconds` oder
 `spec.tolerations`. Für `spec.tolerations` kannnst du nur neue Einträge 
  hinzufügen.
- Für `spec.activeDeadlineSeconds` sind nur zwei Änderungen erlaubt:

  1. ungesetztes Feld in eine positive Zahl
  1. positive Zahl in eine kleinere positive Zahl, die nicht negativ ist
  
## Gemeinsame Nutzung von Ressourcen und Kommunikation 

Pods ermöglichen den Datenaustausch und die Kommunikation zwischen den 
Containern, die im Pod enthalten sind.

### Datenspeicherung in Pods

Ein Pod kann eine Reihe von gemeinsam genutzten Speicher-
{{<glossary_tooltip text="Volumes" term_id="volume">}} spezifizieren. Alle 
Container im Pod können auf die gemeinsamen Volumes zugreifen und dadurch Daten 
austauschen. Volumes ermöglichen auch, dass Daten ohne Verlust gespeichert 
werden, falls einer der Container neu gestartet werden muss. 
Im Kapitel [Datenspeicherung](/docs/concepts/storage/) findest du weitere 
Informationen, wie Kubernetes gemeinsam genutzten Speicher implementiert und 
Pods zur Verfügung stellt.

### Pod-Netzwerk

Jedem Pod wird für jede Adressenfamilie eine eindeutige IP-Adresse zugewiesen. 
Jeder Container in einem Pod nutzt den gemeinsamen Netzwerk-Namespace, 
einschließlich der IP-Adresse und der Ports. In einem Pod (und **nur** dann) 
können die Container, die zum Pod gehören, über `localhost` miteinander 
kommunizieren. Wenn Container in einem Pod mit Entitäten *außerhalb des Pods* 
kommunizieren, müssen sie koordinieren, wie die gemeinsam genutzten 
Netzwerkressourcen (z. B. Ports) verwenden werden. Innerhalb eines Pods teilen 
sich Container eine IP-Adresse und eine Reihe von Ports und können sich 
gegenseitig über `localhost` finden. Die Container in einem Pod können auch die 
üblichen Kommunikationsverfahren zwischen Prozessen nutzen, wie z. B. 
SystemV-Semaphoren oder "POSIX Shared Memory". Container in verschiedenen Pods 
haben unterschiedliche IP-Adressen und können nicht per IPC ohne 
[spezielle Konfiguration](/docs/concepts/policy/pod-security-policy/) 
kommunizieren. Container, die mit einem Container in einem anderen Pod 
interagieren möchten, müssen IP Netzwerke verwenden.

Für die Container innerhalb eines Pods stimmt der "hostname" mit dem 
konfigurierten `Namen` des Pods überein. Mehr dazu im Kapitel 
[Netzwerke](/docs/concepts/cluster-administration/networking/).

## Privilegierter Modus für Container

Jeder Container in einem Pod kann den privilegierten Modus aktivieren, indem 
das Flag `privileged` im 
[Sicherheitskontext](/docs/tasks/configure-pod-container/security-context/)
der Container-Spezifikation verwendet wird.
Dies ist nützlich für Container, die Verwaltungsfunktionen des Betriebssystems 
verwenden möchten, z. B. das Manipulieren des Netzwerk-Stacks oder den Zugriff 
auf Hardware. Prozesse innerhalb eines privilegierten Containers erhalten fast 
die gleichen Rechte wie sie Prozessen außerhalb eines Containers zur Verfügung 
stehen.

{{< note >}}
Ihre 
{{<glossary_tooltip text="Container-Umgebung" term_id="container-runtime">}} 
muss das Konzept eines privilegierten Containers unterstützen, damit diese 
Einstellung relevant ist.
{{< /note >}}


## Statische Pods

_Statische Pods_ werden direkt vom Kubelet-Daemon auf einem bestimmten Node 
verwaltet ohne dass sie vom 
{{<glossary_tooltip text="API Server" term_id="kube-apiserver">}} überwacht 
werden.

Die meisten Pods werden von der Kontrollebene verwaltet (z. B.
{{< glossary_tooltip text="Deployment" term_id="deployment" >}}). Aber für 
statische Pods überwacht das Kubelet jeden statischen Pod direkt (und startet 
ihn neu, wenn er ausfällt).

Statische Pods sind immer an ein {{<glossary_tooltip term_id="kubelet">}} auf 
einem bestimmten Node gebunden. Der Hauptanwendungsfall für statische Pods 
besteht darin, eine selbst gehostete Steuerebene auszuführen. Mit anderen 
Worten: Das Kubelet dient zur Überwachung der einzelnen 
[Komponenten der Kontrollebene](/docs/concepts/overview/components/#control-plane-components).

Das Kubelet versucht automatisch auf dem Kubernetes API-Server für jeden 
statischen Pod einen spiegelbildlichen Pod 
(im Englischen: {{<glossary_tooltip text="mirror pod" term_id="mirror-pod">}}) 
zu erstellen.
Das bedeutet, dass die auf einem Node ausgeführten Pods auf dem API-Server 
sichtbar sind jedoch von dort nicht gesteuert werden können.

## {{% heading "whatsnext" %}}

* Verstehe den 
  [Lebenszyklus eines Pods](/docs/concepts/workloads/pods/pod-lifecycle/).
* Erfahre mehr über [RuntimeClass](/docs/concepts/containers/runtime-class/) 
  und wie du damit verschiedene Pods mit unterschiedlichen 
  Container-Laufzeitumgebungen konfigurieren kannst.
* Mehr zum Thema 
  [Restriktionen für die Verteilung von Pods](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
* Lese
  [Pod-Disruption-Budget](/docs/concepts/workloads/pods/disruptions/) 
  und wie du es verwenden kannst, um die Verfügbarkeit von Anwendungen bei 
  Störungen zu verwalten. Die 
  [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
  -Objektdefinition beschreibt das Objekt im Detail.
* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) 
  erläutert allgemeine Layouts für Pods mit mehr als einem Container.

Um den Hintergrund zu verstehen, warum Kubernetes eine gemeinsame Pod-API in 
andere Ressourcen, wie z. B. 
{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} 
oder {{< glossary_tooltip text="Deployments" term_id="deployment" >}} einbindet, 
kannst du Artikel zu früheren Technologien lesen, unter anderem: 
 * [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
 * [Borg](https://research.google.com/pubs/pub43438.html)
 * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
 * [Omega](https://research.google/pubs/pub41684/)
 * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).