Merge branch 'kubernetes:main' into ADITYADAS1999-patch-1

Author: ADITYADAS1999

README-hi.md

@@ -3,11 +3,11 @@
 [![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
 [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
 
-स्वागत हे! इस रिपॉजिटरी में [कुबरनेट्स वेबसाइट और दस्तावेज](https://kubernetes.io/) बनाने के लिए आवश्यक सभी संपत्तियां हैं। हम बहुत खुश हैं कि आप योगदान करना चाहते हैं!
+स्वागत है! इस रिपॉजिटरी में [कुबरनेट्स वेबसाइट और दस्तावेज़](https://kubernetes.io/) बनाने के लिए आवश्यक सभी संपत्तियां हैं। हम बहुत खुश हैं कि आप योगदान करना चाहते हैं!
 
 ## डॉक्स में योगदान देना
 
-आप अपने GitHub खाते में इस रिपॉजिटरी की एक copy बनाने के लिए स्क्रीन के ऊपरी-दाएँ क्षेत्र में **Fork** बटन पर क्लिक करें। इस copy को *Fork* कहा जाता है। अपने fork में परिवर्तन करने के बाद जब आप उनको हमारे पास भेजने के लिए तैयार हों, तो अपने fork पर जाएं और हमें इसके बारे में बताने के लिए एक नया pull request बनाएं।
+आप अपने GitHub खाते में इस रिपॉजिटरी की एक copy बनाने के लिए स्क्रीन के ऊपरी-दाएँ क्षेत्र में **Fork** बटन पर क्लिक करें। इस copy को *Fork* कहा जाता है। अपने fork में परिवर्तन करने के बाद जब आप उनको हमारे पास भेजने के लिए तैयार हों, तो अपने fork पर जाएँ और हमें इसके बारे में बताने के लिए एक नया pull request बनाएं।
 
 एक बार जब आपका pull request बन जाता है, तो एक कुबरनेट्स समीक्षक स्पष्ट, कार्रवाई योग्य प्रतिक्रिया प्रदान करने की जिम्मेदारी लेगा। pull request के मालिक के रूप में, **यह आपकी जिम्मेदारी है कि आप कुबरनेट्स समीक्षक द्वारा प्रदान की गई प्रतिक्रिया को संबोधित करने के लिए अपने pull request को संशोधित करें।**
 

content/en/blog/_posts/2022-12-15-dynamic-resource-allocation-alpha/index.md

@@ -5,7 +5,7 @@ date: 2022-12-15
 slug: dynamic-resource-allocation
 ---
 
- **Authors:** Patrick Ohly (Intel), Kevin Klues (NVIDIA)
+**Authors:** Patrick Ohly (Intel), Kevin Klues (NVIDIA)
 
 Dynamic resource allocation is a new API for requesting resources. It is a
 generalization of the persistent volumes API for generic resources, making it possible to:
@@ -19,11 +19,11 @@ Third-party resource drivers are responsible for interpreting these parameters
 as well as tracking and allocating resources as requests come in.
 
 Dynamic resource allocation is an *alpha feature* and only enabled when the
-`DynamicResourceAllocation` [feature
-gate](/docs/reference/command-line-tools-reference/feature-gates/) and the
-`resource.k8s.io/v1alpha1` {{< glossary_tooltip text="API group"
-term_id="api-group" >}} are enabled. For details, see the
-`--feature-gates` and `--runtime-config` [kube-apiserver
+`DynamicResourceAllocation`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and the
+`resource.k8s.io/v1alpha1`
+{{< glossary_tooltip text="API group" term_id="api-group" >}} are enabled. For details,
+see the `--feature-gates` and `--runtime-config` [kube-apiserver
 parameters](/docs/reference/command-line-tools-reference/kube-apiserver/).
 The kube-scheduler, kube-controller-manager and kubelet components all need
 the feature gate enabled as well.
@@ -39,8 +39,8 @@ for end-to-end testing, but also can be run manually. See
 
 ## API
 
-The new `resource.k8s.io/v1alpha1` {{< glossary_tooltip text="API group"
-term_id="api-group" >}} provides four new types:
+The new `resource.k8s.io/v1alpha1` {{< glossary_tooltip text="API group" term_id="api-group" >}}
+provides four new types:
 
 ResourceClass
 : Defines which resource driver handles a certain kind of
@@ -77,7 +77,7 @@ this `.spec` (for example, inside a Deployment or StatefulSet) share the same
 ResourceClaim instance. When referencing a ResourceClaimTemplate, each Pod gets
 its own ResourceClaim instance.
 
-For a container defined within a Pod, the  `resources.claims` list 
+For a container defined within a Pod, the `resources.claims` list
 defines whether that container gets
 access to these resource instances, which makes it possible to share resources
 between one or more containers inside the same Pod. For example, an init container could
@@ -89,7 +89,7 @@ will get created for this Pod and each container gets access to one of them.
 Assuming a resource driver called `resource-driver.example.com` was installed
 together with the following resource class:
 
-```
+```yaml
 apiVersion: resource.k8s.io/v1alpha1
 kind: ResourceClass
 name: resource.example.com
@@ -151,8 +151,7 @@ spec:
 
 In contrast to native resources (such as CPU or RAM) and
 [extended resources](/docs/concepts/configuration/manage-resources-containers/#extended-resources)
-(managed by a
-device plugin, advertised by kubelet), the scheduler has no knowledge of what
+(managed by a device plugin, advertised by kubelet), the scheduler has no knowledge of what
 dynamic resources are available in a cluster or how they could be split up to
 satisfy the requirements of a specific ResourceClaim. Resource drivers are
 responsible for that. Drivers mark ResourceClaims as _allocated_ once resources
@@ -227,16 +226,16 @@ It is up to the driver developer to decide how these two components
 communicate. The [KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/3063-dynamic-resource-allocation/README.md) outlines an [approach using
 CRDs](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/3063-dynamic-resource-allocation#implementing-a-plugin-for-node-resources).
 
-Within SIG Node, we also plan to provide a complete [example
-driver](https://github.com/kubernetes-sigs/dra-example-driver) that can serve
+Within SIG Node, we also plan to provide a complete
+[example driver](https://github.com/kubernetes-sigs/dra-example-driver) that can serve
 as a template for other drivers.
 
 ## Running the test driver
 
 The following steps bring up a local, one-node cluster directly from the
 Kubernetes source code. As a prerequisite, your cluster must have nodes with a container
 runtime that supports the
-[Container Device Interface](https://github.com/container-orchestrated-devices/container-device-interface) 
+[Container Device Interface](https://github.com/container-orchestrated-devices/container-device-interface)
 (CDI). For example, you can run CRI-O [v1.23.2](https://github.com/cri-o/cri-o/releases/tag/v1.23.2) or later.
 Once containerd v1.7.0 is released, we expect that you can run that or any later version.
 In the example below, we use CRI-O.
@@ -259,15 +258,16 @@ $ RUNTIME_CONFIG=resource.k8s.io/v1alpha1 \
   PATH=$(pwd)/third_party/etcd:$PATH \
   ./hack/local-up-cluster.sh -O
 ...
+```
+
 To start using your cluster, you can open up another terminal/tab and run:
 
-  export KUBECONFIG=/var/run/kubernetes/admin.kubeconfig
-...
+```console
+$ export KUBECONFIG=/var/run/kubernetes/admin.kubeconfig
 ```
 
-Once the cluster is up, in another
-terminal run the test driver controller. `KUBECONFIG` must be set for all of
-the following commands.
+Once the cluster is up, in another terminal run the test driver controller.
+`KUBECONFIG` must be set for all of the following commands.
 
 ```console
 $ go run ./test/e2e/dra/test-driver --feature-gates ContextualLogging=true -v=5 controller
@@ -319,7 +319,7 @@ user_a='b'
 ## Next steps
 
 - See the
-[Dynamic Resource Allocation](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/3063-dynamic-resource-allocation/README.md)
+  [Dynamic Resource Allocation](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/3063-dynamic-resource-allocation/README.md)
   KEP for more information on the design.
 - Read [Dynamic Resource Allocation](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)
   in the official Kubernetes documentation.
@@ -328,6 +328,6 @@ user_a='b'
   and / or the [CNCF Container Orchestrated Device Working Group](https://github.com/cncf/tag-runtime/blob/master/wg/COD.md).
 - You can view or comment on the [project board](https://github.com/orgs/kubernetes/projects/95/views/1)
   for dynamic resource allocation.
- - In order to move this feature towards beta, we need feedback from hardware
-   vendors, so here's a call to action: try out this feature, consider how it can help
-   with problems that your users are having, and write resource drivers…
+- In order to move this feature towards beta, we need feedback from hardware
+  vendors, so here's a call to action: try out this feature, consider how it can help
+  with problems that your users are having, and write resource drivers…

content/en/blog/_posts/2023-08-15-kubernetes-1.28-blog.md

@@ -26,19 +26,37 @@ Much like a garden, our release has ever-changing growth, challenges and opportu
 # What's New (Major Themes)
 
 ## Changes to supported skew between control plane and node versions
-This enables testing and expanding the supported skew between core node and control plane components by one version from n-2 to n-3, so that node components (kubelet and kube-proxy) for the oldest supported minor version work with control plane components (kube-apiserver, kube-scheduler, kube-controller-manager, cloud-controller-manager) for the newest supported minor version.
 
-This is valuable for end users as control plane upgrade will be a little faster than node upgrade, which are almost always going to be the longer with running workloads.
+Kubernetes v1.28 expands the supported skew between core node and control plane
+components by one minor version, from _n-2_ to _n-3_, so that node components
+(kubelet and kube-proxy) for the oldest supported minor version work with
+control plane components (kube-apiserver, kube-scheduler, kube-controller-manager,
+cloud-controller-manager) for the newest supported minor version.
 
-The Kubernetes yearly support period already makes annual upgrades possible. Users can upgrade to the latest patch versions to pick up security fixes and do 3 sequential minor version upgrades once a year to "catch up" to the latest supported minor version.
+Some cluster operators avoid node maintenance and especially changes to node
+behavior, because nodes are where the workloads run. For minor version upgrades
+to a kubelet, the supported process includes draining that node, and hence
+disruption to any Pods that had been executing there. For Kubernetes end users
+with very long running workloads, and where Pods should stay running wherever
+possible, reducing the time lost to node maintenance is a benefit.
 
-However, since the tested/supported skew between nodes and control planes is currently limited to 2 versions, a 3-version upgrade would have to update nodes twice to stay within the supported skew.
+The Kubernetes yearly support period already made annual upgrades possible. Users can
+upgrade to the latest patch versions to pick up security fixes and do 3 sequential
+minor version upgrades once a year to "catch up" to the latest supported minor version.
+
+Previously, to stay within the supported skew, a cluster operator planning an annual
+upgrade would have needed to upgrade their nodes twice (perhaps only hours apart). Now,
+with Kubernetes v1.28, you have the option of making a minor version upgrade to
+nodes just once in each calendar year and still staying within upstream support.
+
+If you'd like to stay current and upgrade your clusters more often, that's
+fine and is still completely supported.
 
 ## Generally available: recovery from non-graceful node shutdown
 
-If a node shuts down down unexpectedly or ends up in a non-recoverable state (perhaps due to hardware failure or unresponsive OS), Kubernetes allows you to clean up afterwards and allow stateful workloads to restart on a different node. For Kubernetes v1.28, that's now a stable feature.
+If a node shuts down unexpectedly or ends up in a non-recoverable state (perhaps due to hardware failure or unresponsive OS), Kubernetes allows you to clean up afterward and allow stateful workloads to restart on a different node. For Kubernetes v1.28, that's now a stable feature.
 
-This allows stateful workloads to failover to a different node successfully after the original node is shut down or in a non-recoverable state, such as the hardware failure or broken OS.
+This allows stateful workloads to fail over to a different node successfully after the original node is shut down or in a non-recoverable state, such as the hardware failure or broken OS.
 
 Versions of Kubernetes earlier than v1.20 lacked handling for node shutdown on Linux, the kubelet integrates with systemd
 and implements graceful node shutdown (beta, and enabled by default). However, even an intentional
@@ -136,22 +154,24 @@ CDI provides a standardized way of injecting complex devices into a container (i
 ## API awareness of sidecar containers (alpha) {#sidecar-init-containers}
 
 Kubernetes 1.28 introduces an alpha `restartPolicy` field for [init containers](https://github.com/kubernetes/website/blob/main/content/en/docs/concepts/workloads/pods/init-containers.md),
-and uses that to indicate when an init container is also a _sidecar container_. The will start init containers with `restartPolicy: Always` in the order they are defined, along with other init containers. Instead of waiting for that sidecar container to complete before starting the main container(s) for the Pod, the kubelet only waits for
-the sidecar init container to have started.
-
-The condition for startup completion will be that the startup probe succeeded (or if no startup probe is defined) and postStart handler is completed. This condition is represented with the field Started of ContainerStatus type. See the section "Pod startup completed condition" for considerations on picking this signal.
+and uses that to indicate when an init container is also a _sidecar container_.
+The kubelet will start init containers with `restartPolicy: Always` in the order
+they are defined, along with other init containers.
+Instead of waiting for that sidecar container to complete before starting the main
+container(s) for the Pod, the kubelet only waits for the sidecar init container to have started.
+
+The kubelet will consider the startup for the sidecar container as being completed
+if the startup probe succeeds and the postStart handler is completed.
+This condition is represented with the field Started of ContainerStatus type.
+If you do not define a startup probe, the kubelet will consider the container
+startup to be completed immediately after the postStart handler completion.
 
 For init containers, you can either omit the `restartPolicy` field, or set it to `Always`. Omitting the field
 means that you want a true init container that runs to completion before application startup.
 
 Sidecar containers do not block Pod completion: if all regular containers are complete, sidecar
 containers in that Pod will be terminated.
 
-For sidecar containers, the restart behavior is more complex than for init containers. In a Pod with
-`restartPolicy` set to `Never`, a sidecar container that fails during Pod startup will **not** be restarted
-and the whole Pod is treated as having failed. If the Pod's `restartPolicy` is `Always` or `OnFailure`,
-a sidecar that fails to start will be retried.
-
 Once the sidecar container has started (process running, `postStart` was successful, and
 any configured startup probe is passing), and then there's a failure, that sidecar container will be
 restarted even when the Pod's overall `restartPolicy` is `Never` or `OnFailure`.
@@ -165,7 +185,7 @@ To learn more, read [API for sidecar containers](/docs/concepts/workloads/pods/i
 Kubernetes automatically sets a `storageClassName` for a PersistentVolumeClaim (PVC) if you don't provide
 a value. The control plane also sets a StorageClass for any existing PVC that doesn't have a `storageClassName`
 defined.
-Previous versions of Kubernetes also had this behavior; for Kubernetes v1.28 is is automatic and always
+Previous versions of Kubernetes also had this behavior; for Kubernetes v1.28 it is automatic and always
 active; the feature has graduated to stable (general availability).
 
 To learn more, read about [StorageClass](/docs/concepts/storage/storage-classes/) in the Kubernetes 
@@ -294,4 +314,4 @@ Have something you’d like to broadcast to the Kubernetes community? Share your
 
 * Read more about what’s happening with Kubernetes on the [blog](https://kubernetes.io/blog/).
 
-* Learn more about the [Kubernetes Release Team](https://github.com/kubernetes/sig-release/tree/master/release-team).
+* Learn more about the [Kubernetes Release Team](https://github.com/kubernetes/sig-release/tree/master/release-team).