updated button_path

Author: pranav-pandey0804

OWNERS_ALIASES

@@ -49,14 +49,15 @@ aliases:
     - windsonsea
   sig-docs-es-owners: # Admins for Spanish content
     - 92nqb
-    - krol3
     - electrocucaracha
+    - krol3
     - raelga
     - ramrodo
   sig-docs-es-reviews: # PR reviews for Spanish content
     - 92nqb
-    - krol3
     - electrocucaracha
+    - jossemarGT
+    - krol3
     - raelga
     - ramrodo
   sig-docs-fr-owners: # Admins for French content

content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md

@@ -64,7 +64,7 @@ time to review the [dockershim migration documentation](/docs/tasks/administer-c
 and consult your Kubernetes hosting vendor (if you have one) what container runtime options are available for you.
 Read up [container runtime documentation with instructions on how to use containerd and CRI-O](/docs/setup/production-environment/container-runtimes/#container-runtimes)
 to help prepare you when you're ready to upgrade to 1.24. CRI-O, containerd, and
-Docker with [Mirantis cri-dockerd](https://github.com/Mirantis/cri-dockerd) are
+Docker with [Mirantis cri-dockerd](https://mirantis.github.io/cri-dockerd/) are
 not the only container runtime options, we encourage you to explore the [CNCF landscape on container runtimes](https://landscape.cncf.io/?group=projects-and-products&view-mode=card#runtime--container-runtime)
 in case another suits you better.
 

content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md

@@ -109,7 +109,7 @@ Kubernetes clusters. Containers make this kind of interoperability possible.
 
 Mirantis and Docker have [committed][mirantis] to maintaining a replacement adapter for
 Docker Engine, and to maintain that adapter even after the in-tree dockershim is removed
-from Kubernetes. The replacement adapter is named [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd).
+from Kubernetes. The replacement adapter is named [`cri-dockerd`](https://mirantis.github.io/cri-dockerd/).
 
 You can install `cri-dockerd` and use it to connect the kubelet to Docker Engine. Read [Migrate Docker Engine nodes from dockershim to cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/) to learn more.
 

content/en/blog/_posts/2023-08-15-pkgs-k8s-io-introduction.md

@@ -173,6 +173,8 @@ publishing packages to the Google-hosted repository in the future.
    curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.28/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
    ```
 
+_Update: In releases older than Debian 12 and Ubuntu 22.04, the folder `/etc/apt/keyrings` does not exist by default, and it should be created before the curl command._
+
 3. Update the `apt` package index:
 
    ```shell

content/en/docs/concepts/scheduling-eviction/api-eviction.md

@@ -11,11 +11,11 @@ using a client of the {{<glossary_tooltip term_id="kube-apiserver" text="API ser
 creates an `Eviction` object, which causes the API server to terminate the Pod.
 
 API-initiated evictions respect your configured [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/)
-and [`terminationGracePeriodSeconds`](/docs/concepts/workloads/pods/pod-lifecycle#pod-termination). 
+and [`terminationGracePeriodSeconds`](/docs/concepts/workloads/pods/pod-lifecycle#pod-termination).
 
 Using the API to create an Eviction object for a Pod is like performing a
 policy-controlled [`DELETE` operation](/docs/reference/kubernetes-api/workload-resources/pod-v1/#delete-delete-a-pod)
-on the Pod. 
+on the Pod.
 
 ## Calling the Eviction API
 
@@ -75,13 +75,13 @@ checks and responds in one of the following ways:
 * `429 Too Many Requests`: the eviction is not currently allowed because of the
   configured {{<glossary_tooltip term_id="pod-disruption-budget" text="PodDisruptionBudget">}}.
   You may be able to attempt the eviction again later. You might also see this
-  response because of API rate limiting. 
+  response because of API rate limiting.
 * `500 Internal Server Error`: the eviction is not allowed because there is a
   misconfiguration, like if multiple PodDisruptionBudgets reference the same Pod.
 
 If the Pod you want to evict isn't part of a workload that has a
 PodDisruptionBudget, the API server always returns `200 OK` and allows the
-eviction. 
+eviction.
 
 If the API server allows the eviction, the Pod is deleted as follows:
 
@@ -103,12 +103,12 @@ If the API server allows the eviction, the Pod is deleted as follows:
 ## Troubleshooting stuck evictions
 
 In some cases, your applications may enter a broken state, where the Eviction
-API will only return `429` or `500` responses until you intervene. This can 
-happen if, for example, a ReplicaSet creates pods for your application but new 
+API will only return `429` or `500` responses until you intervene. This can
+happen if, for example, a ReplicaSet creates pods for your application but new
 pods do not enter a `Ready` state. You may also notice this behavior in cases
 where the last evicted Pod had a long termination grace period.
 
-If you notice stuck evictions, try one of the following solutions: 
+If you notice stuck evictions, try one of the following solutions:
 
 * Abort or pause the automated operation causing the issue. Investigate the stuck
   application before you restart the operation.

content/en/docs/concepts/scheduling-eviction/assign-pod-node.md

@@ -96,7 +96,7 @@ define. Some of the benefits of affinity and anti-affinity include:
 The affinity feature consists of two types of affinity:
 
 - *Node affinity* functions like the `nodeSelector` field but is more expressive and
-  allows you to specify soft rules. 
+  allows you to specify soft rules.
 - *Inter-pod affinity/anti-affinity* allows you to constrain Pods against labels
   on other Pods.
 
@@ -254,13 +254,13 @@ the node label that the system uses to denote the domain. For examples, see
 [Well-Known Labels, Annotations and Taints](/docs/reference/labels-annotations-taints/).
 
 {{< note >}}
-Inter-pod affinity and anti-affinity require substantial amount of
+Inter-pod affinity and anti-affinity require substantial amounts of
 processing which can slow down scheduling in large clusters significantly. We do
 not recommend using them in clusters larger than several hundred nodes.
 {{< /note >}}
 
 {{< note >}}
-Pod anti-affinity requires nodes to be consistently labelled, in other words,
+Pod anti-affinity requires nodes to be consistently labeled, in other words,
 every node in the cluster must have an appropriate label matching `topologyKey`.
 If some or all nodes are missing the specified `topologyKey` label, it can lead
 to unintended behavior.
@@ -305,22 +305,22 @@ Pod affinity rule uses the "hard"
 `requiredDuringSchedulingIgnoredDuringExecution`, while the anti-affinity rule
 uses the "soft" `preferredDuringSchedulingIgnoredDuringExecution`.
 
-The affinity rule specifies that the scheduler is allowed to place the example Pod 
+The affinity rule specifies that the scheduler is allowed to place the example Pod
 on a node only if that node belongs to a specific [zone](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
-where other Pods have been labeled with `security=S1`. 
-For instance, if we have a cluster with a designated zone, let's call it "Zone V," 
-consisting of nodes labeled with `topology.kubernetes.io/zone=V`, the scheduler can 
-assign the Pod to any node within Zone V, as long as there is at least one Pod within 
-Zone V already labeled with `security=S1`. Conversely, if there are no Pods with `security=S1` 
+where other Pods have been labeled with `security=S1`.
+For instance, if we have a cluster with a designated zone, let's call it "Zone V,"
+consisting of nodes labeled with `topology.kubernetes.io/zone=V`, the scheduler can
+assign the Pod to any node within Zone V, as long as there is at least one Pod within
+Zone V already labeled with `security=S1`. Conversely, if there are no Pods with `security=S1`
 labels in Zone V, the scheduler will not assign the example Pod to any node in that zone.
 
-The anti-affinity rule specifies that the scheduler should try to avoid scheduling the Pod 
+The anti-affinity rule specifies that the scheduler should try to avoid scheduling the Pod
 on a node if that node belongs to a specific [zone](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
-where other Pods have been labeled with `security=S2`. 
-For instance, if we have a cluster with a designated zone, let's call it "Zone R," 
-consisting of nodes labeled with `topology.kubernetes.io/zone=R`, the scheduler should avoid 
-assigning the Pod to any node within Zone R, as long as there is at least one Pod within 
-Zone R already labeled with `security=S2`. Conversely, the anti-affinity rule does not impact 
+where other Pods have been labeled with `security=S2`.
+For instance, if we have a cluster with a designated zone, let's call it "Zone R,"
+consisting of nodes labeled with `topology.kubernetes.io/zone=R`, the scheduler should avoid
+assigning the Pod to any node within Zone R, as long as there is at least one Pod within
+Zone R already labeled with `security=S2`. Conversely, the anti-affinity rule does not impact
 scheduling into Zone R if there are no Pods with `security=S2` labels.
 
 To get yourself more familiar with the examples of Pod affinity and anti-affinity,
@@ -364,19 +364,19 @@ null `namespaceSelector` matches the namespace of the Pod where the rule is defi
 
 {{< note >}}
 <!-- UPDATE THIS WHEN PROMOTING TO BETA -->
-The `matchLabelKeys` field is a alpha-level field and is disabled by default in
+The `matchLabelKeys` field is an alpha-level field and is disabled by default in
 Kubernetes {{< skew currentVersion >}}.
 When you want to use it, you have to enable it via the
 `MatchLabelKeysInPodAffinity` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
 {{< /note >}}
 
 Kubernetes includes an optional `matchLabelKeys` field for Pod affinity
-or anti-affinity. The field specifies keys for the labels that should  match with the incoming Pod's labels, 
+or anti-affinity. The field specifies keys for the labels that should  match with the incoming Pod's labels,
 when satisfying the Pod (anti)affinity.
 
 The keys are used to look up values from the pod labels; those key-value labels are combined
 (using `AND`) with the match restrictions defined using the `labelSelector` field. The combined
-filtering selects the set of existing pods that will be taken into Pod (anti)affinity calculation. 
+filtering selects the set of existing pods that will be taken into Pod (anti)affinity calculation.
 
 A common use case is to use `matchLabelKeys` with `pod-template-hash` (set on Pods
 managed as part of a Deployment, where the value is unique for each revision).
@@ -405,7 +405,7 @@ spec:
             # Only Pods from a given rollout are taken into consideration when calculating pod affinity.
             # If you update the Deployment, the replacement Pods follow their own affinity rules
             # (if there are any defined in the new Pod template)
-            matchLabelKeys: 
+            matchLabelKeys:
             - pod-template-hash
 ```
 
@@ -415,14 +415,14 @@ spec:
 
 {{< note >}}
 <!-- UPDATE THIS WHEN PROMOTING TO BETA -->
-The `mismatchLabelKeys` field is a alpha-level field and is disabled by default in
+The `mismatchLabelKeys` field is an alpha-level field and is disabled by default in
 Kubernetes {{< skew currentVersion >}}.
 When you want to use it, you have to enable it via the
 `MatchLabelKeysInPodAffinity` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
 {{< /note >}}
 
 Kubernetes includes an optional `mismatchLabelKeys` field for Pod affinity
-or anti-affinity. The field specifies keys for the labels that should **not** match with the incoming Pod's labels, 
+or anti-affinity. The field specifies keys for the labels that should **not** match with the incoming Pod's labels,
 when satisfying the Pod (anti)affinity.
 
 One example use case is to ensure Pods go to the topology domain (node, zone, etc) where only Pods from the same tenant or team are scheduled in.
@@ -438,22 +438,22 @@ metadata:
 ...
 spec:
   affinity:
-    podAffinity:      
+    podAffinity:
       requiredDuringSchedulingIgnoredDuringExecution:
       # ensure that pods associated with this tenant land on the correct node pool
       - matchLabelKeys:
           - tenant
         topologyKey: node-pool
-    podAntiAffinity:  
+    podAntiAffinity:
       requiredDuringSchedulingIgnoredDuringExecution:
       # ensure that pods associated with this tenant can't schedule to nodes used for another tenant
       - mismatchLabelKeys:
-        - tenant # whatever the value of the "tenant" label for this Pod, prevent  
+        - tenant # whatever the value of the "tenant" label for this Pod, prevent
                  # scheduling to nodes in any pool where any Pod from a different
                  # tenant is running.
         labelSelector:
           # We have to have the labelSelector which selects only Pods with the tenant label,
-          # otherwise this Pod would hate Pods from daemonsets as well, for example, 
+          # otherwise this Pod would hate Pods from daemonsets as well, for example,
           # which aren't supposed to have the tenant label.
           matchExpressions:
           - key: tenant
@@ -561,7 +561,7 @@ where each web server is co-located with a cache, on three separate nodes.
 | *webserver-1* | *webserver-2* | *webserver-3* |
 |   *cache-1*   |   *cache-2*   |   *cache-3*   |
 
-The overall effect is that each cache instance is likely to be accessed by a single client, that
+The overall effect is that each cache instance is likely to be accessed by a single client that
 is running on the same node. This approach aims to minimize both skew (imbalanced load) and latency.
 
 You might have other reasons to use Pod anti-affinity.
@@ -589,7 +589,7 @@ Some of the limitations of using `nodeName` to select nodes are:
 {{< note >}}
 `nodeName` is intended for use by custom schedulers or advanced use cases where
 you need to bypass any configured schedulers. Bypassing the schedulers might lead to
-failed Pods if the assigned Nodes get oversubscribed. You can use [node affinity](#node-affinity) or a the [`nodeselector` field](#nodeselector) to assign a Pod to a specific Node without bypassing the schedulers.
+failed Pods if the assigned Nodes get oversubscribed. You can use the [node affinity](#node-affinity) or the [`nodeselector` field](#nodeselector) to assign a Pod to a specific Node without bypassing the schedulers.
 {{</ note >}}
 
 Here is an example of a Pod spec using the `nodeName` field:
@@ -633,13 +633,13 @@ The following operators can only be used with `nodeAffinity`.
 
 |    Operator    |    Behaviour    |
 | :------------: | :-------------: |
-| `Gt` | The supplied value will be parsed as an integer, and that integer is less than the integer that results from parsing the value of a label named by this selector | 
-| `Lt` | The supplied value will be parsed as an integer, and that integer is greater than the integer that results from parsing the value of a label named by this selector | 
+| `Gt` | The supplied value will be parsed as an integer, and that integer is less than the integer that results from parsing the value of a label named by this selector |
+| `Lt` | The supplied value will be parsed as an integer, and that integer is greater than the integer that results from parsing the value of a label named by this selector |
 
 
 {{<note>}}
-`Gt` and `Lt` operators will not work with non-integer values. If the given value 
-doesn't parse as an integer, the pod will fail to get scheduled. Also, `Gt` and `Lt` 
+`Gt` and `Lt` operators will not work with non-integer values. If the given value
+doesn't parse as an integer, the pod will fail to get scheduled. Also, `Gt` and `Lt`
 are not available for `podAffinity`.
 {{</note>}}
 

content/en/docs/concepts/scheduling-eviction/dynamic-resource-allocation.md

@@ -41,14 +41,14 @@ ResourceClass
   driver.
 
 ResourceClaim
-: Defines a particular resource instances that is required by a
+: Defines a particular resource instance that is required by a
   workload. Created by a user (lifecycle managed manually, can be shared
   between different Pods) or for individual Pods by the control plane based on
   a ResourceClaimTemplate (automatic lifecycle, typically used by just one
   Pod).
 
 ResourceClaimTemplate
-: Defines the spec and some meta data for creating
+: Defines the spec and some metadata for creating
   ResourceClaims. Created by a user when deploying a workload.
 
 PodSchedulingContext

content/en/docs/concepts/scheduling-eviction/kube-scheduler.md

@@ -62,7 +62,7 @@ kube-scheduler selects a node for the pod in a 2-step operation:
 
 The _filtering_ step finds the set of Nodes where it's feasible to
 schedule the Pod. For example, the PodFitsResources filter checks whether a
-candidate Node has enough available resource to meet a Pod's specific
+candidate Node has enough available resources to meet a Pod's specific
 resource requests. After this step, the node list contains any suitable
 Nodes; often, there will be more than one. If the list is empty, that
 Pod isn't (yet) schedulable.

content/en/docs/concepts/scheduling-eviction/node-pressure-eviction.md

@@ -171,7 +171,7 @@ The kubelet has the following default hard eviction thresholds:
 - `nodefs.inodesFree<5%` (Linux nodes)
 
 These default values of hard eviction thresholds will only be set if none
-of the parameters is changed. If you changed the value of any parameter,
+of the parameters is changed. If you change the value of any parameter,
 then the values of other parameters will not be inherited as the default
 values and will be set to zero. In order to provide custom values, you
 should provide all the thresholds respectively.