Merge pull request #36053 from krol3/merged-main-dev-1.25

Merged main dev 1.25

Author: k8s-ci-robot

.gitignore

@@ -27,14 +27,14 @@ kubernetes.github.io.iml
 nohup.out
 
 # Hugo output
-public/
-resources/
+/public/
+/resources/
 .hugo_build.lock
 
 # Netlify Functions build output
 package-lock.json
-functions/
-node_modules/
+/functions/
+/node_modules/
 
 # Generated files when building with make container-build
 .config/

OWNERS

@@ -7,12 +7,13 @@ approvers:
 - sig-docs-en-owners # Defined in OWNERS_ALIASES
 
 emeritus_approvers:
+# - celestehorgan, commented out to disable PR assignments
 # - chenopis, commented out to disable PR assignments
 # - irvifa, commented out to disable PR assignments
 # - jaredbhatti, commented out to disable PR assignments
 # - kbarnard10, commented out to disable PR assignments
 # - steveperry-53, commented out to disable PR assignments
-- stewart-yu 
+- stewart-yu
 # - zacharysarah, commented out to disable PR assignments
 
 labels:

OWNERS_ALIASES

@@ -20,7 +20,6 @@ aliases:
   sig-docs-en-owners: # Admins for English content
     - annajung
     - bradtopol
-    - celestehorgan
     - divya-mohan0209
     - jimangel
     - jlbutler
@@ -33,10 +32,8 @@ aliases:
     - savitharaghunathan
     - sftim
     - tengqm
-    - zacharysarah
   sig-docs-en-reviews: # PR reviews for English content
     - bradtopol
-    - celestehorgan
     - daminisatya
     - divya-mohan0209
     - jimangel
@@ -48,7 +45,6 @@ aliases:
     - sftim
     - shannonxtreme
     - tengqm
-    - zacharysarah
   sig-docs-es-owners: # Admins for Spanish content
     - raelga
     - electrocucaracha
@@ -86,11 +82,10 @@ aliases:
   sig-docs-hi-owners: # Admins for Hindi content
     - anubha-v-ardhan
     - divya-mohan0209
-    - mittalyashu
   sig-docs-hi-reviews: # PR reviews for Hindi content
     - anubha-v-ardhan
     - divya-mohan0209
-    - mittalyashu
+    - Garima-Negi
     - verma-kunal
   sig-docs-id-owners: # Admins for Indonesian content
     - ariscahyadi
@@ -130,12 +125,14 @@ aliases:
     - nasa9084
     # oke-py
     - ptux
+    - t-inu
   sig-docs-ko-owners: # Admins for Korean content
     - ClaudiaJKang
     - gochist
     - ianychoi
     - jihoon-seo
     - seokho-son
+    - yoonian
     - ysyukr
   sig-docs-ko-reviews: # PR reviews for Korean content
     - ClaudiaJKang

config.toml

@@ -15,7 +15,7 @@ disableKinds = ["taxonomy", "taxonomyTerm"]
 
 ignoreFiles = [ "(?:^|/)OWNERS$", "README[-]+[a-z]*\\.md", "^node_modules$", "content/en/docs/doc-contributor-tools" ]
 
-timeout = 3000
+timeout = "180s"
 
 # Highlighting config.
 pygmentsCodeFences = true

content/de/docs/concepts/_index.md

@@ -20,14 +20,14 @@ welche Anwendungen oder anderen Workloads Sie ausführen möchten, welche Contai
 
 Sobald Sie den gewünschten Status eingestellt haben, wird das *Kubernetes Control Plane* dafür sorgen, dass der aktuelle Status des Clusters mit dem gewünschten Status übereinstimmt. Zu diesem Zweck führt Kubernetes verschiedene Aufgaben automatisch aus, z. B. das Starten oder Neustarten von Containern, Skalieren der Anzahl der Repliken einer bestimmten Anwendung und vieles mehr. Das Kubernetes Control Plane besteht aus einer Reihe von Prozessen, die in Ihrem Cluster ausgeführt werden:
 
-* Der **Kubernetes Master** bestehet aus drei Prozessen, die auf einem einzelnen Node in Ihrem Cluster ausgeführt werden, der als Master-Node bezeichnet wird. Diese Prozesse sind:[kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) und [kube-scheduler](/docs/admin/kube-scheduler/).
+* Der **Kubernetes Master** besteht aus drei Prozessen, die auf einem einzelnen Node in Ihrem Cluster ausgeführt werden, der als Master-Node bezeichnet wird. Diese Prozesse sind: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) und [kube-scheduler](/docs/admin/kube-scheduler/).
 * Jeder einzelne Node in Ihrem Cluster, welcher nicht der Master ist, führt zwei Prozesse aus:
   * **[kubelet](/docs/admin/kubelet/)**, das mit dem Kubernetes Master kommuniziert.
   * **[kube-proxy](/docs/admin/kube-proxy/)**, ein Netzwerk-Proxy, der die Netzwerkdienste von Kubernetes auf jedem Node darstellt.
 
 ## Kubernetes Objects
 
-Kubernetes enthält eine Reihe von Abstraktionen, die den Status Ihres Systems darstellen: im Container eingesetzte Anwendungen und Workloads, die zugehörigen Netzwerk- und Festplattenressourcen sowie weitere Informationen zu den Aufgaben Ihres Clusters. Diese Abstraktionen werden durch Objekte in der Kubernetes-API dargestellt; Lesen Sie [Kubernetes Objects Überblick](/docs/concepts/abstractions/overview/) für weitere Details.
+Kubernetes enthält eine Reihe von Abstraktionen, die den Status Ihres Systems darstellen: im Container eingesetzte Anwendungen und Workloads, die zugehörigen Netzwerk- und Festplattenressourcen sowie weitere Informationen zu den Aufgaben Ihres Clusters. Diese Abstraktionen werden durch Objekte in der Kubernetes-API dargestellt. Lesen Sie [Kubernetes Objects Überblick](/docs/concepts/abstractions/overview/) für weitere Details.
 
 Die Basisobjekte von Kubernetes umfassen:
 

content/de/docs/concepts/containers/images.md

@@ -5,7 +5,7 @@ weight: 10
 ---
 <!-- overview -->
 
-Sie erstellen ihr Docker Image und laden es in eine Registry hoch, bevor es in einem Kubernetes Pod referenziert werden kann.
+Sie erstellen Ihr Docker Image und laden es in eine Registry hoch, bevor es in einem Kubernetes Pod referenziert werden kann.
 
 Die `image` Eigenschaft eines Containers unterstüzt die gleiche Syntax wie die des `docker` Kommandos, inklusive privater Registries und Tags.
 
@@ -75,7 +75,7 @@ Authentifizierungsdaten können auf verschiedene Weisen hinterlegt werden:
     - Alle Pods können jedes gecachte Image auf einem Node nutzen
     - Setzt root - Zugriff auf allen Nodes zum Einrichten voraus
   - Spezifizieren eines ImagePullSecrets auf einem Pod
-    - Nur Pods, die eigene Secret tragen, haben Zugriff auf eine private Registry
+    - Nur Pods, die eigene Secrets tragen, haben Zugriff auf eine private Registry
 
 Jede Option wird im Folgenden im Detail beschrieben
 
@@ -246,7 +246,7 @@ Falls jedoch die `imagePullPolicy` Eigenschaft der Containers auf `IfNotPresent`
 
 Wenn Sie sich auf im Voraus heruntergeladene Images als Ersatz für eine Registry - Authentifizierung verlassen möchten, müssen sie sicherstellen, dass alle Knoten die gleichen, im Voraus heruntergeladenen Images aufweisen.
 
-Diese Medthode kann dazu genutzt werden, bestimmte Images aus Geschwindigkeitsgründen im Voraus zu laden, oder als Alternative zur Authentifizierung an einer eigenen Registry zu nutzen.
+Diese Methode kann dazu genutzt werden, bestimmte Images aus Geschwindigkeitsgründen im Voraus zu laden, oder als Alternative zur Authentifizierung an einer eigenen Registry zu nutzen.
 
 Alle Pods haben Leserechte auf alle im Voraus geladenen Images.
 

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

@@ -130,13 +130,13 @@ enthaltenen Container bereit:
 
 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 
+Einweg-Einheiten konzipiert sind. Wenn 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. 
+mangelnder Ressourcen *evakuiert* wird oder der Node ausfällt. 
 
 {{< note >}}
 Das Neustarten eines Containers in einem Pod sollte nicht mit dem Neustarten 
@@ -163,20 +163,20 @@ verwalten:
 * {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
 * {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}
 
-### Pod Vorlagen
+### 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.
+erstellen Pods von einer _Pod-Vorlage_ und verwalten diese Pods für dich.
 
-Pod Vorlagen 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 Pod Vorlage innerhalb 
-des Workload-Objektes, um Pods zu erzeugen. Die Pod Vorlage ist Teil des 
+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.
 
@@ -191,45 +191,45 @@ metadata:
  name: hello
 spec:
  template:
- # Dies is the Pod Vorlage
+ # 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
+ # 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
+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 
+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, 
+Ä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 
+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
+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, 
@@ -366,4 +366,4 @@ kannst du Artikel zu früheren Technologien lesen, unter anderem:
  * [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/).
+ * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).

content/en/blog/_posts/2022-08-04-kubernetes-1.24-deprecations-and-removals.md renamed to content/en/blog/_posts/2022-08-04-kubernetes-1.25-deprecations-and-removals.md

@@ -19,45 +19,42 @@ The Kubernetes project has a well-documented [deprecation policy](/docs/referenc
 
 Whether an API is removed as a result of a feature graduating from beta to stable or because that API simply did not succeed, all removals comply with this deprecation policy. Whenever an API is removed, migration options are communicated in the documentation. 
 
-## A Note About PodSecurityPolicy
+## A note about PodSecurityPolicy {#podsecuritypolicy-removal}
 
 In Kubernetes v1.25, we will be removing PodSecurityPolicy [after its deprecation in v1.21](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/). PodSecurityPolicy has served us honorably, but its complex and often confusing usage necessitated changes, which unfortunately would have been breaking changes. To address this, it is being removed in favor of a replacement, Pod Security Admission, which is graduating to stable in this release as well. If you are currently relying on PodSecurityPolicy, follow the instructions for [migration to Pod Security Admission](/docs/tasks/configure-pod-container/migrate-from-psp/).
 
 ## Major Changes for Kubernetes v1.25
 
-Kubernetes v1.25 includes several major changes, in addition to the removal of PodSecurityPolicy.
+Kubernetes v1.25 will include several major changes, in addition to the removal of PodSecurityPolicy.
 
 ### [CSI Migration](https://github.com/kubernetes/enhancements/issues/625)
 
 The effort to  move the in-tree volume plugins to out-of-tree CSI drivers continues, with the core CSI Migration feature going GA in v1.25. This is an important step towards removing the in-tree volume plugins entirely.
 
-### Volume Plugin Deprecations and Removals
+### Deprecations and removals for storage drivers
 
-Several volume are being deprecated or removed.
+Several volume plugins are being deprecated or removed.
 
 [GlusterFS will be deprecated in v1.25](https://github.com/kubernetes/enhancements/issues/3446). While a CSI driver was built for it, it has not been maintained. The possibility of migration to a compatible CSI driver [was discussed](https://github.com/kubernetes/kubernetes/issues/100897), but a decision was ultimately made to begin the deprecation of the GlusterFS plugin from in-tree drivers. The [Portworx in-tree volume plugin](https://github.com/kubernetes/enhancements/issues/2589) is also being deprecated with this release. The Flocker, Quobyte, and StorageOS in-tree volume plugins are being removed.
 
-### [Declare Unsupported vSphere Versions](https://github.com/kubernetes/kubernetes/pull/111255)
+[Flocker](https://github.com/kubernetes/kubernetes/pull/111618), [Quobyte](https://github.com/kubernetes/kubernetes/pull/111619), and [StorageOS](https://github.com/kubernetes/kubernetes/pull/111620) in-tree volume plugins will be removed in v1.25 as part of the [CSI Migration](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/625-csi-migration).
 
-From Kubernetes v1.25, the in-tree vSphere volume driver will not support any vSphere release before 7.0u2. Check the v1.25 detailed release notes for more advice on how to handle this.
+### [Change to vSphere version support](https://github.com/kubernetes/kubernetes/pull/111255)
 
-### [Signing Release Artifacts](https://github.com/kubernetes/enhancements/issues/3031)
-
-An additional step in improving the security posture of the release process, the signing of Kubernetes release artifacts will graduate to Beta in this release. This is in line with the proposed enhancement of targeting SLSA Level 3 compliance for the Kubernetes release process.
-
-### [Support for cgroup v2 Graduating to Stable](https://github.com/kubernetes/enhancements/issues/2254)
-
-The new kernel cgroups v2 API was declared stable more than two years ago, and in this release we're taking solid steps towards full adoption of it. While cgroup v1 will continue to be supported, this change makes us ready to deal with the eventual deprecation of cgroup v1 and its replacement by cgroup v2.
+From Kubernetes v1.25, the in-tree vSphere volume driver will not support any vSphere release before 7.0u2. Once Kubernetes v1.25 is released, check the v1.25 detailed release notes for more advice on how to handle this.
 
 ### [Cleaning up IPTables Chain Ownership](https://github.com/kubernetes/enhancements/issues/3178)
 
-From the Kubernetes 1.25 release, the iptables chains created by Kubernetes will only support for internal Kubernetes use cases. Starting with v1.25, the Kubelet will gradually move towards not creating the following iptables chains in the `nat` table:
+On Linux, Kubernetes (usually) creates iptables chains to ensure that network packets reach
+Although these chains and their names have been an internal implementation detail, some tooling
+has relied upon that behavior.
+will only support for internal Kubernetes use cases. Starting with v1.25, the Kubelet will gradually move towards not creating the following iptables chains in the `nat` table:
 
   - `KUBE-MARK-DROP`
   - `KUBE-MARK-MASQ`
   - `KUBE-POSTROUTING`
 
-This change will be phased in via the `IPTablesCleanup` feature gate.
+This change will be phased in via the `IPTablesCleanup` feature gate. Although this is not formally a deprecation, some end users have come to rely on specific internal behavior of `kube-proxy`. The Kubernetes project overall wants to make it clear that depending on these internal details is not supported, and that future implementations will change their behavior here.
 
 ## Looking ahead