added German translation for pod overview
This commit is contained in:
flo-oss
parent
8263a332fd
commit
dc75539de0
|
|
@ -0,0 +1,372 @@
|
||||||
|
---
|
||||||
|
reviewers:
|
||||||
|
- erictune
|
||||||
|
title: Pods
|
||||||
|
content_type: concept
|
||||||
|
weight: 10
|
||||||
|
no_list: true
|
||||||
|
card:
|
||||||
|
name: concepts
|
||||||
|
weight: 60
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- overview -->
|
||||||
|
|
||||||
|
_Pods_ sind die kleinsten installierbaren Softwareeinheiten, 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-Laufzeitumgebung"
|
||||||
|
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 andere 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, erwägen Sie die Nutzung von {{<glossary_tooltip text
|
||||||
|
= "StatefulSet" term_id = "statefulset">}}-Ressourcen.
|
||||||
|
|
||||||
|
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 können Sie sich 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. Sie sollten diese Architektur nur in bestimmten Fällen
|
||||||
|
verwenden, wenn Ihre Container stark voneinander abhängen.
|
||||||
|
{{</ note>}}
|
||||||
|
|
||||||
|
Jeder Pod sollte eine einzelne Instanz einer gegebenen Anwendung ausführen. Wenn
|
||||||
|
Sie Ihre Anwendung horizontal skalieren wollen (also mehr Instanzen auszuführen
|
||||||
|
und dadurch mehr Gesamtressourcen bereitstellen), sollten Sie mehrere Pods
|
||||||
|
verwenden,
|
||||||
|
einen für jede Instanz. In Kubernetes wird dies typischerweise als Replikation
|
||||||
|
bezeichnet.
|
||||||
|
Replizierte Pods werden normalerweise als eine Gruppe von Workload-Ressource
|
||||||
|
und {{<glossary_tooltip text = "Controller" term_id = "controller">}} erstellt
|
||||||
|
und verwaltet.
|
||||||
|
|
||||||
|
Die Seite [Pods und Controller](#pods-and-controllers) 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önnten Sie 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="example pod diagram" 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 angehalten bevor die
|
||||||
|
Anwendungs-Container gestartet werden.
|
||||||
|
|
||||||
|
Pods stellen standardmäßig zwei Arten von gemeinsam Ressourcen für die
|
||||||
|
enthaltenen Container bereit:
|
||||||
|
[Netzwerk](#pod-networking) und [Speicher](#pod-storage)..
|
||||||
|
|
||||||
|
|
||||||
|
## Mit Pods arbeiten
|
||||||
|
|
||||||
|
Sie werden 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>}}
|
||||||
|
|
||||||
|
Stellen Sie 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 können Sie mehrere Pods erstellen und verwalten. Ein
|
||||||
|
Controller für die Ressource kümmert sich um Replikation, Roll-Out sowie
|
||||||
|
automatische Heilung im Fall von Podfehlern. 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" >}}
|
||||||
|
|
||||||
|
### Podvorlagen
|
||||||
|
|
||||||
|
Controller für
|
||||||
|
{{<glossary_tooltip text = "Workload" term_id = "workload">}}-Ressourcen
|
||||||
|
erstellen Pods von einer _Podvorlage_ und verwalten diese Pods für sie.
|
||||||
|
|
||||||
|
Podvorlagen 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 Podvorlage innerhalb
|
||||||
|
des Workload-Objektes, um Pods zu erzeugen. Die Podvorlage ist Bestandteil des
|
||||||
|
gewünschten Zustands der Workload-Ressource, mit der Sie Ihre Anwendung
|
||||||
|
ausgeführt haben.
|
||||||
|
|
||||||
|
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:
|
||||||
|
# This is the pod template
|
||||||
|
spec:
|
||||||
|
containers:
|
||||||
|
- name: hello
|
||||||
|
image: busybox
|
||||||
|
command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
|
||||||
|
restartPolicy: OnFailure
|
||||||
|
# The pod template ends here
|
||||||
|
```
|
||||||
|
Das Ändern der Podvorlage oder der Wechsel zu einer neuen Podvorlage hat keine
|
||||||
|
direkten Auswirkungen auf bereits existierende Pods. Wenn Sie die Podvorlage für
|
||||||
|
eine Workload-Ressource ändern, 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 Podvorlage
|
||||||
|
übereinstimmen. Wenn Sie das StatefulSet bearbeiten und die Vorlage ändern,
|
||||||
|
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 Podvorlage. Wenn Sie mehr über StatefulSet erfahren möchten,
|
||||||
|
lesen Sie
|
||||||
|
[Update strategy](/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 Podvorlagen 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 Podvorlage für eine Workload-Ressource
|
||||||
|
geändert wird anstatt die vorhandenen Pods zu aktualisieren oder zu patchen.
|
||||||
|
|
||||||
|
Kubernetes hindert Sie 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 sind unveränderlich. Zum Beispiel können
|
||||||
|
Sie nicht die Felder `namespace`, `name`, `uid`, oder `creationTimestamp`
|
||||||
|
ändern. Das `generation`-Feld ist eindeutig. 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` können Sie 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 {#pod-storage}
|
||||||
|
|
||||||
|
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/) finden Sie 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 einen 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 Prozesse 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 Control Plane 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
|
||||||
|
[control plane components](/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" %}}
|
||||||
|
|
||||||
|
* Erfahren Sie mehr über den
|
||||||
|
[Lebenszyklus eines Pods](/docs/concepts/workloads/pods/pod-lifecycle/).
|
||||||
|
* Erfahren Sie mehr über [RuntimeClass](/docs/concepts/containers/runtime-class/)
|
||||||
|
und wie Sie damit verschiedene Pods mit unterschiedlichen
|
||||||
|
Container-Laufzeitumgebung konfigurieren können.
|
||||||
|
* Lesen sie mehr über
|
||||||
|
[Restriktionen für die Verteilung von Pods](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
|
||||||
|
* Lesen sie mehr über sogenannte
|
||||||
|
[Pod-Disruption-Budgets](/docs/concepts/workloads/pods/disruptions/)
|
||||||
|
und wie Sie diese verwenden können, 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,
|
||||||
|
können sie 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/).
|
||||||
Loading…
Reference in New Issue