Merge pull request #47304 from hacktivist123/merged-main-dev-1.31

Merged main dev 1.31

Author: k8s-ci-robot

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,11 +1,6 @@
 <!--
-
  Hello!
 
- Remember to ADD A DESCRIPTION and delete this note before submitting
- your pull request. The description should explain what will change,
- and why.
-
  PLEASE title the FIRST commit appropriately, so that if you squash all
  your commits into one, the combined commit message makes sense.
  For overall help on editing and submitting pull requests, visit:
@@ -20,5 +15,24 @@
 
  If you're documenting a feature that will be part of a future release, see
  https://kubernetes.io/docs/contribute/new-content/new-features/ for advice.
+-->
+### Description
 
+<!--
+ Remember to ADD A DESCRIPTION and delete this note before submitting
+ your pull request. The description should explain what will change,
+ and why.
+-->
+
+### Issue
+
+<!--
+ If this pull request resolves an open issue, please link the issue in the PR
+ description so it will automatically close when the PR is merged.
+
+ See the GitHub documentation for more details and other options:
+
+ https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword
 -->
+
+Closes: #

OWNERS_ALIASES

@@ -127,6 +127,7 @@ aliases:
     - bells17
     - inductor
     - nasa9084
+    - Okabe-Junya
   sig-docs-ja-reviews: # PR reviews for Japanese content
     - atoato88
     - bells17

content/bn/examples/service/networking/example-ingress.yaml

@@ -2,8 +2,6 @@ apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: example-ingress
-  annotations:
-    nginx.ingress.kubernetes.io/rewrite-target: /$1
 spec:
   ingressClassName: nginx
   rules:

content/de/docs/reference/glossary/cloud-controller-manager.md

@@ -11,7 +11,7 @@ tags:
 - architecture
 - operation
 ---
- Eine Kubernetes {{< glossary_tooltip text="Control Plane" term_id="control-plane" >}} Komponente, die Cloud spezifische Kontrolllogik einbettet. Der [Cloud Controller Manager](/docs/concepts/architecture/cloud-controller/) lässt Sie Ihr Cluster in die Cloud Provider API einbinden, und trennt die Komponenten die mit der Cloud Platform interagieren von Komponenten, die nur mit Ihrem Cluster interagieren.
+ Eine Kubernetes {{< glossary_tooltip text="Control Plane" term_id="control-plane" >}} Komponente, die Cloud spezifische Kontrolllogik einbettet. Der Cloud Controller Manager lässt Sie Ihr Cluster in die Cloud Provider API einbinden, und trennt die Komponenten die mit der Cloud Platform interagieren von Komponenten, die nur mit Ihrem Cluster interagieren.
 
 <!--more-->
 

content/en/docs/concepts/configuration/secret.md

@@ -524,7 +524,7 @@ have Kubernetes make the value of that Secret be available as a file inside
 the filesystem of one or more of the Pod's containers.
 
 For instructions, refer to
-[Distribute credentials securely using Secrets](/docs/tasks/inject-data-application/distribute-credentials-secure/#create-a-pod-that-has-access-to-the-secret-data-through-a-volume).
+[Create a Pod that has access to the secret data through a Volume](/docs/tasks/inject-data-application/distribute-credentials-secure/#create-a-pod-that-has-access-to-the-secret-data-through-a-volume).
 
 When a volume contains data from a Secret, and that Secret is updated, Kubernetes tracks
 this and updates the data in the volume, using an eventually-consistent approach.

content/en/docs/concepts/containers/container-lifecycle-hooks.md

@@ -64,11 +64,10 @@ When a Container lifecycle management hook is called,
 the Kubernetes management system executes the handler according to the hook action,
 `httpGet` , `tcpSocket` and `sleep` are executed by the kubelet process, and `exec` is executed in the container.
 
-Hook handler calls are synchronous within the context of the Pod containing the Container.
-This means that for a `PostStart` hook,
-the Container ENTRYPOINT and hook fire asynchronously.
-However, if the hook takes too long to run or hangs,
-the Container cannot reach a `running` state.
+The `PostStart` hook handler call is initiated when a container is created,
+meaning the container ENTRYPOINT and the `PostStart` hook are triggered simultaneously. 
+However, if the `PostStart` hook takes too long to execute or if it hangs,
+it can prevent the container from transitioning to a `running` state.
 
 `PreStop` hooks are not executed asynchronously from the signal to stop the Container; the hook must
 complete its execution before the TERM signal can be sent. If a `PreStop` hook hangs during

content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md

@@ -161,8 +161,9 @@ The [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/cu
 API resource allows you to define custom resources.
 Defining a CRD object creates a new custom resource with a name and schema that you specify.
 The Kubernetes API serves and handles the storage of your custom resource.
-The name of a CRD object must be a valid
-[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+The name of the CRD object itself must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) derived from the defined resource name and its API group; see [how to create a CRD](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions#create-a-customresourcedefinition) for more details.
+Further, the name of an object whose kind/resource is defined by a CRD must also be a valid DNS subdomain name.
 
 This frees you from writing your own API server to handle the custom resource,
 but the generic nature of the implementation means you have less flexibility than with
@@ -223,6 +224,7 @@ Aggregated APIs offer more advanced API features and customization of other feat
 | strategic-merge-patch | The new endpoints support PATCH with `Content-Type: application/strategic-merge-patch+json`. Useful for updating objects that may be modified both locally, and by the server. For more information, see ["Update API Objects in Place Using kubectl patch"](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) | No | Yes |
 | Protocol Buffers | The new resource supports clients that want to use Protocol Buffers | No | Yes |
 | OpenAPI Schema | Is there an OpenAPI (swagger) schema for the types that can be dynamically fetched from the server? Is the user protected from misspelling field names by ensuring only allowed fields are set? Are types enforced (in other words, don't put an `int` in a `string` field?) | Yes, based on the [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) schema (GA in 1.16). | Yes |
+| Instance Name | Does this extension mechanism impose any constraints on the names of objects whose kind/resource is defined this way? | Yes, such an object's name must be a valid DNS subdomain name. | No |
 
 ### Common Features
 

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

@@ -132,7 +132,7 @@ Kubernetes. In the future, this list may be expanded.
 
 In Kubernetes v{{< skew currentVersion >}}, the value of `.spec.os.name` does not affect
 how the {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}
-picks a Pod to run a node. In any cluster where there is more than one operating system for
+picks a node for the Pod to run on. In any cluster where there is more than one operating system for
 running nodes, you should set the
 [kubernetes.io/os](/docs/reference/labels-annotations-taints/#kubernetes-io-os)
 label correctly on each node, and define pods with a `nodeSelector` based on the operating system
@@ -410,4 +410,4 @@ To understand the context for why Kubernetes wraps a common Pod API in other res
 * [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/docs/reference/command-line-tools-reference/feature-gates/container-checkpoint.md

@@ -9,6 +9,10 @@ stages:
   - stage: alpha
     defaultValue: false
     fromVersion: "1.25"
+    toVersion: "1.29"
+  - stage: beta
+    defaultValue: true
+    fromVersion: "1.30"
 ---
 Enables the kubelet `checkpoint` API.
 See [Kubelet Checkpoint API](/docs/reference/node/kubelet-checkpoint-api/) for more details.

content/en/docs/reference/command-line-tools-reference/feature-gates/evented-pleg.md

@@ -8,11 +8,7 @@ _build:
 stages:
   - stage: alpha
     defaultValue: false
-    fromVersion: "1.26"
-    toVersion: "1.26"
-  - stage: beta
-    defaultValue: false
-    fromVersion: "1.27"
+    fromVersion: "1.25"
 ---
 Enable support for the kubelet to receive container life cycle events from the
 {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} via