Merge pull request #26192 from flo-oss/pod_overview_german

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

Author: k8s-ci-robot

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

@@ -0,0 +1,369 @@
+---
+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/).