changes suggested by code reviewer

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.
 
@@ -61,8 +58,8 @@ 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.
+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:
 
@@ -99,7 +96,7 @@ Workload-Ressource und deren
 {{<glossary_tooltip text="Controller" term_id="controller">}} 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 {{<glossary_tooltip text="Initialisierungs-Container" 
-term_id = "init-container">}} als auch {{<glossary_tooltip text = 
-"Anwendungs-Container" term_id = "app-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-networking) und [Speicher](#pod-storage).
+[Netzwerk](#pod-netzwerk) und [Speicher](#datenspeicherung-in-pods).
 
 
 ## Mit Pods arbeiten
@@ -265,7 +262,7 @@ 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-
 {{<glossary_tooltip text="Volumes" term_id="volume">}} spezifizieren. Alle 
@@ -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 {{<glossary_tooltip text = "Mirror-Pod" term_id = "mirror-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.