Merge pull request #51454 from rashansmith/merged-main-dev-1.34

Merge main branch into dev-1.34

Author: k8s-ci-robot

content/bn/examples/secret/tls-auth-secret.yaml

@@ -6,23 +6,6 @@ type: kubernetes.io/tls
 data:
   # values are base64 encoded, which obscures them but does NOT provide
   # any useful level of confidentiality
-  tls.crt: |
-    LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNVakNDQWJzQ0FnMytNQTBHQ1NxR1NJYjNE
-    UUVCQlFVQU1JR2JNUXN3Q1FZRFZRUUdFd0pLVURFT01Bd0cKQTFVRUNCTUZWRzlyZVc4eEVEQU9C
-    Z05WQkFjVEIwTm9kVzh0YTNVeEVUQVBCZ05WQkFvVENFWnlZVzVyTkVSRQpNUmd3RmdZRFZRUUxF
-    dzlYWldKRFpYSjBJRk4xY0hCdmNuUXhHREFXQmdOVkJBTVREMFp5WVc1ck5FUkVJRmRsCllpQkRR
-    VEVqTUNFR0NTcUdTSWIzRFFFSkFSWVVjM1Z3Y0c5eWRFQm1jbUZ1YXpSa1pDNWpiMjB3SGhjTk1U
-    TXcKTVRFeE1EUTFNVE01V2hjTk1UZ3dNVEV3TURRMU1UTTVXakJMTVFzd0NRWURWUVFHREFKS1VE
-    RVBNQTBHQTFVRQpDQXdHWEZSdmEzbHZNUkV3RHdZRFZRUUtEQWhHY21GdWF6UkVSREVZTUJZR0Ex
-    VUVBd3dQZDNkM0xtVjRZVzF3CmJHVXVZMjl0TUlHYU1BMEdDU3FHU0liM0RRRUJBUVVBQTRHSUFE
-    Q0JoQUo5WThFaUhmeHhNL25PbjJTbkkxWHgKRHdPdEJEVDFKRjBReTliMVlKanV2YjdjaTEwZjVN
-    Vm1UQllqMUZTVWZNOU1vejJDVVFZdW4yRFljV29IcFA4ZQpqSG1BUFVrNVd5cDJRN1ArMjh1bklI
-    QkphVGZlQ09PekZSUFY2MEdTWWUzNmFScG04L3dVVm16eGFLOGtCOWVaCmhPN3F1TjdtSWQxL2pW
-    cTNKODhDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUVVGQUFPQmdRQU1meTQzeE15OHh3QTUKVjF2T2NS
-    OEtyNWNaSXdtbFhCUU8xeFEzazlxSGtyNFlUY1JxTVQ5WjVKTm1rWHYxK2VSaGcwTi9WMW5NUTRZ
-    RgpnWXcxbnlESnBnOTduZUV4VzQyeXVlMFlHSDYyV1hYUUhyOVNVREgrRlowVnQvRGZsdklVTWRj
-    UUFEZjM4aU9zCjlQbG1kb3YrcE0vNCs5a1h5aDhSUEkzZXZ6OS9NQT09Ci0tLS0tRU5EIENFUlRJ
-    RklDQVRFLS0tLS0K
-  # In this example, the key data is not a real PEM-encoded private key
-  tls.key: |
-    RXhhbXBsZSBkYXRhIGZvciB0aGUgVExTIGNydCBmaWVsZA==
+  # Note: Replace the following values with your own base64-encoded certificate and key.
+  tls.crt: "REPLACE_WITH_BASE64_CERT" 
+  tls.key: "REPLACE_WITH_BASE64_KEY"

content/en/blog/_posts/2025-06-25-image-compatibility-in-cloud-native-environments/index.md

@@ -27,7 +27,7 @@ A container image is built on a base image, which provides a minimal runtime env
   Host driver versions must match the supported range of a library version inside the container to avoid compatibility problems. Examples include GPUs and network drivers.
 - **Libraries or Software**:
   The container must come with a specific version or range of versions for a library or software to run optimally in the environment. Examples from high performance computing are MPI, EFA, or Infiniband.
-- **Kernel Modules or Features:**:
+- **Kernel Modules or Features**:
   Specific kernel features or modules must be present. Examples include having support of write protected huge page faults, or the presence of VFIO
 - And more…
 
@@ -121,33 +121,41 @@ Additionally, it could potentially enable automatic node configuration to some e
 
 ### Examples of usage
 
-1. **Define image compatibility metadata**  
-A [container image](/docs/concepts/containers/images) can have metadata that describes its requirements based on features discovered from nodes, like kernel modules or CPU models.
-The previous compatibility specification example in this article exemplified this use case.
-
-2. **Attach the artifact to the image**  
-The image compatibility specification is stored as an OCI artifact.
-You can attach this metadata to your container image using the [oras](https://oras.land/) tool.
-The registry only needs to support OCI artifacts, support for arbitrary types is not required.
-Keep in mind that the container image and the artifact must be stored in the same registry.
-Use the following command to attach the artifact to the image:
-
-```bash
-oras attach \ 
---artifact-type application/vnd.nfd.image-compatibility.v1alpha1 <image-url> \ 
-<path-to-spec>.yaml:application/vnd.nfd.image-compatibility.spec.v1alpha1+yaml
-```
+1. **Define image compatibility metadata**
+
+   A [container image](/docs/concepts/containers/images) can have metadata that describes
+   its requirements based on features discovered from nodes, like kernel modules or CPU models.
+   The previous compatibility specification example in this article exemplified this use case.
+
+2. **Attach the artifact to the image**
+
+   The image compatibility specification is stored as an OCI artifact.
+   You can attach this metadata to your container image using the [oras](https://oras.land/) tool.
+   The registry only needs to support OCI artifacts, support for arbitrary types is not required.
+   Keep in mind that the container image and the artifact must be stored in the same registry.
+   Use the following command to attach the artifact to the image:
+
+   ```bash
+   oras attach \
+   --artifact-type application/vnd.nfd.image-compatibility.v1alpha1 <image-url> \ 
+   <path-to-spec>.yaml:application/vnd.nfd.image-compatibility.spec.v1alpha1+yaml
+   ```
+
+3. **Validate image compatibility**
+
+   After attaching the compatibility specification, you can validate whether a node meets the
+   image's requirements. This validation can be done using the
+   [nfd client](https://kubernetes-sigs.github.io/node-feature-discovery/v0.17/reference/node-feature-client-reference.html):
 
-3. **Validate image compatibility**  
-After attaching the compatibility specification, you can validate whether a node meets the image's requirements.
-This validation can be done using the [nfd client](https://kubernetes-sigs.github.io/node-feature-discovery/v0.17/reference/node-feature-client-reference.html):
+   ```bash
+   nfd compat validate-node --image <image-url>
+   ```
 
-`nfd compat validate-node --image <image-url>`
+4. **Read the output from the client**
 
-4. **Read the output from the client**  
-Finally you can read the report generated by the tool or use your own tools to act based on the generated JSON report.
+   Finally you can read the report generated by the tool or use your own tools to act based on the generated JSON report.
 
-![validate-node command output](validate-node-output.png)
+   ![validate-node command output](validate-node-output.png)
 
 ## Conclusion
 

content/en/blog/_posts/2025-01-14-devices-failure-handling/index.md renamed to content/en/blog/_posts/2025-07-03-devices-failure-handling/index.md

@@ -1,9 +1,9 @@
 ---
 layout: blog
 title: "Navigating Failures in Pods With Devices"
-date: 2025-04-01
+date: 2025-07-03
 slug: navigating-failures-in-pods-with-devices
-draft: true
+draft: false
 author: >
   Sergey Kanzhelev (Google)
   Mrunal Patel (RedHat)

content/en/blog/_posts/2025-01-14-devices-failure-handling/inplace-pod-restarts.svg renamed to content/en/blog/_posts/2025-07-03-devices-failure-handling/inplace-pod-restarts.svg

@@ -26,25 +26,22 @@ each Node in your cluster, so that the
 The kubelet acts as a client when connecting to the container runtime via gRPC.
 The runtime and image service endpoints have to be available in the container
 runtime, which can be configured separately within the kubelet by using the
-`--image-service-endpoint` [command line flags](/docs/reference/command-line-tools-reference/kubelet).
+`--container-runtime-endpoint`
+[command line flag](/docs/reference/command-line-tools-reference/kubelet/).
 
-For Kubernetes v{{< skew currentVersion >}}, the kubelet prefers to use CRI `v1`.
-If a container runtime does not support `v1` of the CRI, then the kubelet tries to
-negotiate any older supported version.
-The v{{< skew currentVersion >}} kubelet can also negotiate CRI `v1alpha2`, but
-this version is considered as deprecated.
-If the kubelet cannot negotiate a supported CRI version, the kubelet gives up
-and doesn't register as a node.
+For Kubernetes v1.26 and later, the kubelet requires that the container runtime
+supports the `v1` CRI API. If a container runtime does not support the `v1` API,
+the kubelet will not register the node.
 
 ## Upgrading
 
-When upgrading Kubernetes, the kubelet tries to automatically select the
-latest CRI version on restart of the component. If that fails, then the fallback
-will take place as mentioned above. If a gRPC re-dial was required because the
-container runtime has been upgraded, then the container runtime must also
-support the initially selected version or the redial is expected to fail. This
-requires a restart of the kubelet.
+When upgrading the Kubernetes version on a node, the kubelet restarts. If the
+container runtime does not support the `v1` CRI API, the kubelet will fail to
+register and report an error. If a gRPC re-dial is required because the container
+runtime has been upgraded, the runtime must support the `v1` CRI API for the
+connection to succeed. This might require a restart of the kubelet after the
+container runtime is correctly configured.
 
 ## {{% heading "whatsnext" %}}
 
-- Learn more about the CRI [protocol definition](https://github.com/kubernetes/cri-api/blob/c75ef5b/pkg/apis/runtime/v1/api.proto)
+- Learn more about the CRI [protocol definition](https://github.com/kubernetes/cri-api/blob/v0.33.1/pkg/apis/runtime/v1/api.proto)

content/en/blog/_posts/2025-01-14-devices-failure-handling/k8s-infra-devices.svg renamed to content/en/blog/_posts/2025-07-03-devices-failure-handling/k8s-infra-devices.svg

@@ -82,6 +82,9 @@ installation instructions. The list does not try to be exhaustive.
 * [Spiderpool](https://github.com/spidernet-io/spiderpool) is an underlay and RDMA
   networking solution for Kubernetes. Spiderpool is supported on bare metal, virtual machines,
   and public cloud environments.
+* [Terway](https://github.com/AliyunContainerService/terway/) is a suite of CNI plugins
+  based on AlibabaCloud's VPC and ECS network products. It provides native VPC networking
+  and network policies in AlibabaCloud environments.
 * [Weave Net](https://github.com/rajch/weave#using-weave-on-kubernetes)
   provides networking and network policy, will carry on working on both sides
   of a network partition, and does not require an external database.

content/en/blog/_posts/2025-01-14-devices-failure-handling/k8s-infra-failures.svg renamed to content/en/blog/_posts/2025-07-03-devices-failure-handling/k8s-infra-failures.svg

@@ -18,7 +18,7 @@ _Resource quotas_ are a tool for administrators to address this concern.
 
 A resource quota, defined by a ResourceQuota object, provides constraints that limit
 aggregate resource consumption per {{< glossary_tooltip text="namespace" term_id="namespace" >}}. A ResourceQuota can also
-limit the [quantity of objects that can be created in a namespace](#quota-on-object-count) by API kind, as well as the total
+limit the [quantity of objects that can be created in a namespace](#object-count-quota) by API kind, as well as the total
 amount of {{< glossary_tooltip text="infrastructure resources" term_id="infrastructure-resource" >}} that may be consumed by
 API objects found in that namespace.
 

content/en/docs/concepts/architecture/cri.md

@@ -975,7 +975,7 @@ spec:
 
 ## Resources
 
-The storage media (such as Disk or SSD) of an `emptyDir` volume is determined by the
+The storage medium (such as Disk or SSD) of an `emptyDir` volume is determined by the
 medium of the filesystem holding the kubelet root dir (typically
 `/var/lib/kubelet`). There is no limit on how much space an `emptyDir` or
 `hostPath` volume can consume, and no isolation between containers or