From dc75539de039b769e97add6144a56493cda20f62 Mon Sep 17 00:00:00 2001 From: flo-oss Date: Thu, 21 Jan 2021 19:42:24 -0800 Subject: [PATCH 1/6] added German translation for pod overview --- .../de/docs/concepts/workloads/pods/_index.md | 372 ++++++++++++++++++ 1 file changed, 372 insertions(+) create mode 100644 content/de/docs/concepts/workloads/pods/_index.md diff --git a/content/de/docs/concepts/workloads/pods/_index.md b/content/de/docs/concepts/workloads/pods/_index.md new file mode 100644 index 0000000000..d2a2009f8c --- /dev/null +++ b/content/de/docs/concepts/workloads/pods/_index.md @@ -0,0 +1,372 @@ +--- +reviewers: +- erictune +title: Pods +content_type: concept +weight: 10 +no_list: true +card: + name: concepts + weight: 60 +--- + + + +_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. + + + +## Was ist ein Pod? + +{{< note >}} +Obwohl Kubernetes abgesehen von [Docker](https://www.docker.com/) auch andere +{{}} unterstützt, ist Docker am bekanntesten und + es ist hilfreich, Pods mit der Terminologie von Docker zu beschreiben. +{{}} + +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 {{}} oder {{}} erzeugt. Für Pods, die von einem Systemzustand +abhängen, erwägen Sie die Nutzung von {{}}-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. + +{{}} +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. +{{}} + +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 {{}} 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 {{}} als auch {{}}. +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 +{{}}), wird die +Ausführung auf einem {{}} 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. + +{{}} +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. +{{}} + +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 +{{}}-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- +{{}} 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. + +{{}} +Ihre +{{}} +muss das Konzept eines privilegierten Containers unterstützen, damit diese +Einstellung relevant ist. +{{}} + + +## Statische Pods + +_Statische Pods_ werden direkt vom Kubelet-Daemon auf einem bestimmten Node +verwaltet ohne dass sie vom +{{}} ü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 {{}} 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 {{}}) +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/). \ No newline at end of file From f213353b3028d6fc8099b7232346321a5f63ed66 Mon Sep 17 00:00:00 2001 From: flo-oss Date: Thu, 21 Jan 2021 20:45:13 -0800 Subject: [PATCH 2/6] added German translation for pod overview page --- .../de/docs/concepts/workloads/pods/_index.md | 49 ++++++++++--------- 1 file changed, 25 insertions(+), 24 deletions(-) diff --git a/content/de/docs/concepts/workloads/pods/_index.md b/content/de/docs/concepts/workloads/pods/_index.md index d2a2009f8c..b1aec877c9 100644 --- a/content/de/docs/concepts/workloads/pods/_index.md +++ b/content/de/docs/concepts/workloads/pods/_index.md @@ -12,7 +12,7 @@ card: -_Pods_ sind die kleinsten installierbaren Softwareeinheiten, die in Kubernetes +_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 @@ -42,13 +42,13 @@ zum Debuggen gestartet werden, wenn dies der Cluster anbietet. {{< note >}} Obwohl Kubernetes abgesehen von [Docker](https://www.docker.com/) auch andere -{{}} unterstützt, ist Docker am bekanntesten und es ist hilfreich, Pods mit der Terminologie von Docker zu beschreiben. {{}} Der gemeinsame Kontext eines Pods besteht aus einer Reihe von Linux-Namespaces, -Cgroups und möglicherweise andere Aspekten der Isolation, also die gleichen +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. @@ -89,18 +89,19 @@ verwenden, wenn Ihre Container stark voneinander abhängen. {{}} Jeder Pod sollte eine einzelne Instanz einer gegebenen Anwendung ausführen. Wenn -Sie Ihre Anwendung horizontal skalieren wollen (also mehr Instanzen auszuführen +Sie Ihre Anwendung horizontal skalieren wollen (um 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 {{}} erstellt +Replizierte Pods werden normalerweise als eine Gruppe durch eine +Workload-Ressource und deren +{{}} 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. +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 @@ -121,12 +122,12 @@ Abbildung: Einige Pods haben sowohl {{}} als auch {{}}. -Initialisierungs-Container werden gestartet und angehalten bevor die +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-networking) und [Speicher](#pod-storage).. +[Netzwerk](#pod-networking) und [Speicher](#pod-storage). ## Mit Pods arbeiten @@ -179,7 +180,7 @@ Workload-Ressourcen enthalten wie z. B. [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 +des Workload-Objektes, um Pods zu erzeugen. Die Podvorlage ist Teil des gewünschten Zustands der Workload-Ressource, mit der Sie Ihre Anwendung ausgeführt haben. @@ -217,8 +218,8 @@ 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) +lesen Sie die Seite +[Update-Strategien](/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets) im Tutorial StatefulSet Basics. @@ -243,9 +244,9 @@ 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 +- Die meisten Metadaten zu einem Pod können nicht verändert werden. Zum Beispiel können Sie nicht die Felder `namespace`, `name`, `uid`, oder `creationTimestamp` - ändern. Das `generation`-Feld ist eindeutig. Es werden nur Aktualisierungen + ä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. @@ -272,8 +273,8 @@ 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. +Informationen, wie Kubernetes gemeinsam genutzten Speicher implementiert und +Pods zur Verfügung stellt. ### Pod-Netzwerk @@ -284,10 +285,10 @@ 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 +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 +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 @@ -306,7 +307,7 @@ 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 +die gleichen Rechte wie sie Prozessen außerhalb eines Containers zur Verfügung stehen. {{}} @@ -324,7 +325,7 @@ verwaltet ohne dass sie vom {{}} überwacht werden. . -Die meisten Pods werden von der Control Plane verwaltet (z. B. +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). @@ -333,7 +334,7 @@ Statische Pods sind immer an ein {{}} 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). +[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 @@ -348,7 +349,7 @@ sichtbar sind jedoch von dort nicht gesteuert werden können. [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. + Container-Laufzeitumgebungen 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 From 90cc7f10d4413ebbb1a33f0624138fb862e9d864 Mon Sep 17 00:00:00 2001 From: flo-oss Date: Tue, 2 Feb 2021 22:20:15 -0800 Subject: [PATCH 3/6] changes suggested by code reviewer --- .../de/docs/concepts/workloads/pods/_index.md | 67 +++++++++---------- 1 file changed, 32 insertions(+), 35 deletions(-) diff --git a/content/de/docs/concepts/workloads/pods/_index.md b/content/de/docs/concepts/workloads/pods/_index.md index b1aec877c9..4080f460f9 100644 --- a/content/de/docs/concepts/workloads/pods/_index.md +++ b/content/de/docs/concepts/workloads/pods/_index.md @@ -1,6 +1,4 @@ --- -reviewers: -- erictune title: Pods content_type: concept weight: 10 @@ -22,10 +20,9 @@ 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 +"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. @@ -42,10 +39,10 @@ zum Debuggen gestartet werden, wenn dies der Cluster anbietet. {{< note >}} Obwohl Kubernetes abgesehen von [Docker](https://www.docker.com/) auch andere -{{}} unterstützt, ist Docker am bekanntesten und +{{}} 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 @@ -59,10 +56,10 @@ die gemeinsame Namespaces und Dateisystem-Volumes nutzen. Normalerweise müssen keine Pods erzeugt werden, auch keine Singleton-Pods. Stattdessen werden sie mit Workload-Ressourcen wie {{}} oder {{}} erzeugt. Für Pods, die von einem Systemzustand -abhängen, erwägen Sie die Nutzung von {{}}-Ressourcen. +text="Deployment" term_id="deployment">}} oder {{}} erzeugt. Für Pods, die von einem Systemzustand +abhängen, erwägen Sie die Nutzung von {{}}-Ressourcen. Pods in einem Kubernetes-Cluster werden hauptsächlich auf zwei Arten verwendet: @@ -81,12 +78,12 @@ 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 (um mehr Instanzen auszuführen @@ -96,10 +93,10 @@ 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 -{{}} erstellt +{{}} erstellt und verwaltet. -Die Seite [Pods und Controller](#pods-and-controllers) beschreibt, wie +Der Abschnitt [Pods und Controller](#pods-und-controller) beschreibt, wie Kubernetes Workload-Ressourcen und deren Controller verwendet, um Anwendungen zu skalieren und zu heilen. @@ -117,17 +114,17 @@ 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%" >}} +{{< figure src="/images/docs/pod.svg" alt="Pod-Beispieldiagramm" width="50%" >}} -Einige Pods haben sowohl {{}} als auch {{}}. +Einige Pods haben sowohl {{}} als auch {{}}. 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-networking) und [Speicher](#pod-storage). +[Netzwerk](#pod-netzwerk) und [Speicher](#datenspeicherung-in-pods). ## Mit Pods arbeiten @@ -136,17 +133,17 @@ 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 -{{}}), wird die -Ausführung auf einem {{}} in Ihrem Cluster +{{}}), wird die +Ausführung auf einem {{}} 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 @@ -170,7 +167,7 @@ verwalten: ### Podvorlagen Controller für -{{}}-Ressourcen +{{}}-Ressourcen erstellen Pods von einer _Podvorlage_ und verwalten diese Pods für sie. Podvorlagen sind Spezifikationen zum Erstellen von Pods und sind in @@ -265,10 +262,10 @@ einige Einschränkungen: Pods ermöglichen den Datenaustausch und die Kommunikation zwischen den Containern, die im Pod enthalten sind. -### Datenspeicherung in Pods {#pod-storage} +### Datenspeicherung in Pods Ein Pod kann eine Reihe von gemeinsam genutzten Speicher- -{{}} spezifizieren. Alle +{{}} 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. @@ -310,19 +307,19 @@ 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 -{{}} +{{}} 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 -{{}} überwacht +{{}} überwacht werden. . Die meisten Pods werden von der Kontrollebene verwaltet (z. B. @@ -330,7 +327,7 @@ Die meisten Pods werden von der Kontrollebene verwaltet (z. B. statische Pods überwacht das Kubelet jeden statischen Pod direkt (und startet ihn neu, wenn er ausfällt). -Statische Pods sind immer an ein {{}} auf +Statische Pods sind immer an ein {{}} 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 @@ -338,7 +335,7 @@ Worten: Das Kubelet dient zur Überwachung der einzelnen Das Kubelet versucht automatisch auf dem Kubernetes API-Server für jeden statischen Pod einen spiegelbildlichen Pod -(im Englischen {{}}) +(im Englischen: {{}}) 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. From 99aa654d8be21ab928177a05a70514d586abd030 Mon Sep 17 00:00:00 2001 From: flo-oss Date: Tue, 2 Feb 2021 22:53:55 -0800 Subject: [PATCH 4/6] changes suggested by code reviewer, part 2 --- content/de/docs/concepts/workloads/pods/_index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/de/docs/concepts/workloads/pods/_index.md b/content/de/docs/concepts/workloads/pods/_index.md index 4080f460f9..837a1f1571 100644 --- a/content/de/docs/concepts/workloads/pods/_index.md +++ b/content/de/docs/concepts/workloads/pods/_index.md @@ -192,14 +192,14 @@ metadata: name: hello spec: template: - # This is the pod template + # Dies is the Podvorlage spec: containers: - name: hello image: busybox command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] restartPolicy: OnFailure - # The pod template ends here + # Die Podvorlage endet hier ``` 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 @@ -248,8 +248,8 @@ einige Einschränkungen: - 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.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: From 5b127f07612d45ba0a142370e4e58f9e859c3830 Mon Sep 17 00:00:00 2001 From: flo-oss Date: Tue, 16 Feb 2021 21:07:07 -0800 Subject: [PATCH 5/6] changes suggested by code reviewer (sie -> du, Pod Vorlage, ....) --- .../de/docs/concepts/workloads/pods/_index.md | 97 +++++++++---------- 1 file changed, 48 insertions(+), 49 deletions(-) diff --git a/content/de/docs/concepts/workloads/pods/_index.md b/content/de/docs/concepts/workloads/pods/_index.md index 837a1f1571..e6adce49a6 100644 --- a/content/de/docs/concepts/workloads/pods/_index.md +++ b/content/de/docs/concepts/workloads/pods/_index.md @@ -57,15 +57,15 @@ die gemeinsame Namespaces und Dateisystem-Volumes nutzen. Normalerweise müssen keine Pods erzeugt werden, auch keine Singleton-Pods. Stattdessen werden sie mit Workload-Ressourcen wie {{}} oder {{}} erzeugt. Für Pods, die von einem Systemzustand -abhängen, erwägen Sie die Nutzung von {{}}-Ressourcen. +text="Job" term_id="job">}} erzeugt. Für Pods, die von einem Systemzustand +abhängen, ist die Nutzung von {{}}-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 können Sie sich einen Pod als einen Behälter vorstellen, der einen +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 @@ -81,16 +81,15 @@ 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. +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 -Sie Ihre Anwendung horizontal skalieren wollen (um 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. +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 {{}} erstellt @@ -109,7 +108,7 @@ 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 +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: @@ -129,7 +128,7 @@ enthaltenen Container bereit: ## Mit Pods arbeiten -Sie werden selten einzelne Pods direkt in Kubernetes erstellen, selbst +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 @@ -145,16 +144,16 @@ 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 +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 können Sie mehrere Pods erstellen und verwalten. Ein +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 Heilung im Fall von Podfehlern. Wenn beispielsweise ein Node +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 @@ -164,22 +163,22 @@ verwalten: * {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} * {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} -### Podvorlagen +### Pod Vorlagen Controller für {{}}-Ressourcen -erstellen Pods von einer _Podvorlage_ und verwalten diese Pods für sie. +erstellen Pods von einer _Pod Vorlage_ und verwalten diese Pods für dich. -Podvorlagen sind Spezifikationen zum Erstellen von Pods und sind in +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 Podvorlage innerhalb -des Workload-Objektes, um Pods zu erzeugen. Die Podvorlage ist Teil des -gewünschten Zustands der Workload-Ressource, mit der Sie Ihre Anwendung -ausgeführt haben. +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 @@ -192,37 +191,37 @@ metadata: name: hello spec: template: - # Dies is the Podvorlage + # Dies is the Pod Vorlage spec: containers: - name: hello image: busybox command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] restartPolicy: OnFailure - # Die Podvorlage endet hier + # Die Pod Vorlage endet hier ``` -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 +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 Podvorlage -übereinstimmen. Wenn Sie das StatefulSet bearbeiten und die Vorlage ändern, +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 Podvorlage. Wenn Sie mehr über StatefulSet erfahren möchten, -lesen Sie die Seite +Ä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 Podvorlagen und Updates. Diese Details sind +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. @@ -230,10 +229,10 @@ 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 +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 Sie nicht daran, Pods direkt zu verwalten. Es ist möglich, +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), @@ -241,8 +240,8 @@ 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 können - Sie nicht die Felder `namespace`, `name`, `uid`, oder `creationTimestamp` +- 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 @@ -250,7 +249,7 @@ einige Einschränkungen: - 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 + `spec.tolerations`. Für `spec.tolerations` kannnst du nur neue Einträge hinzufügen. - Für `spec.activeDeadlineSeconds` sind nur zwei Änderungen erlaubt: @@ -269,7 +268,7 @@ Ein Pod kann eine Reihe von gemeinsam genutzten Speicher- 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 +Im Kapitel [Datenspeicherung](/docs/concepts/storage/) findest du weitere Informationen, wie Kubernetes gemeinsam genutzten Speicher implementiert und Pods zur Verfügung stellt. @@ -321,7 +320,7 @@ _Statische Pods_ werden direkt vom Kubelet-Daemon auf einem bestimmten Node verwaltet ohne dass sie vom {{}} ü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 @@ -342,16 +341,16 @@ sichtbar sind jedoch von dort nicht gesteuert werden können. ## {{% heading "whatsnext" %}} -* Erfahren Sie mehr über den +* Lerne 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-Laufzeitumgebungen konfigurieren können. -* Lesen sie mehr über +* Lerne die [RuntimeClass](/docs/concepts/containers/runtime-class/) + und wie du damit verschiedene Pods mit unterschiedlichen + Container-Laufzeitumgebungen konfigurieren kannst. +* Lese [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 +* 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. @@ -362,7 +361,7 @@ 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: +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) From 363545ef9673242e21eacad2c6259a0be803a33c Mon Sep 17 00:00:00 2001 From: flo-oss Date: Mon, 22 Feb 2021 21:35:48 -0800 Subject: [PATCH 6/6] Slightly more creative translation to make it sound less repetitive and less commanding :-) --- content/de/docs/concepts/workloads/pods/_index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/de/docs/concepts/workloads/pods/_index.md b/content/de/docs/concepts/workloads/pods/_index.md index e6adce49a6..956190e6c7 100644 --- a/content/de/docs/concepts/workloads/pods/_index.md +++ b/content/de/docs/concepts/workloads/pods/_index.md @@ -341,12 +341,12 @@ sichtbar sind jedoch von dort nicht gesteuert werden können. ## {{% heading "whatsnext" %}} -* Lerne den +* Verstehe den [Lebenszyklus eines Pods](/docs/concepts/workloads/pods/pod-lifecycle/). -* Lerne die [RuntimeClass](/docs/concepts/containers/runtime-class/) +* Erfahre mehr über [RuntimeClass](/docs/concepts/containers/runtime-class/) und wie du damit verschiedene Pods mit unterschiedlichen Container-Laufzeitumgebungen konfigurieren kannst. -* Lese +* 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/)