Merge branch 'kubernetes:main' into hi-running-multiple-zone

Author: kundan2707

OWNERS_ALIASES

@@ -1,17 +1,16 @@
 aliases:
   sig-docs-blog-owners: # Approvers for blog content
-    - onlydole
     - mrbobbytables
-    - sftim
     - nate-double-u
+    - onlydole
+    - sftim
   sig-docs-blog-reviewers: # Reviewers for blog content
     - mrbobbytables
+    - nate-double-u
     - onlydole
     - sftim
-    - nate-double-u
   sig-docs-localization-owners: # Admins for localization content
     - a-mccarthy
-    - bradtopol
     - divya-mohan0209
     - jimangel
     - kbhawkey
@@ -33,7 +32,6 @@ aliases:
     - bradtopol
     - divya-mohan0209
     - jimangel
-    - jlbutler
     - kbhawkey
     - krol3
     - natalisucks
@@ -44,15 +42,13 @@ aliases:
     - tengqm
   sig-docs-en-reviews: # PR reviews for English content
     - bradtopol
-    - daminisatya
     - divya-mohan0209
     - jimangel
     - kbhawkey
     - mehabhalodiya
     - natalisucks
     - nate-double-u
     - onlydole
-    - rajeshdeshpande02
     - reylejano
     - sftim
     - shannonxtreme

SECURITY_CONTACTS

@@ -11,5 +11,9 @@
 # INSTRUCTIONS AT https://kubernetes.io/security/
 
 divya-mohan0209
-jimangel
+reylejano
 sftim
+tengqm
+onlydole
+kbhawkey
+natalisucks

content/en/blog/_posts/2021-04-06-PodSecurityPolicy-Past-Present-and-Future.md

@@ -4,9 +4,12 @@ title: "PodSecurityPolicy Deprecation: Past, Present, and Future"
 date: 2021-04-06
 slug: podsecuritypolicy-deprecation-past-present-and-future
 ---
-
 **Author:** Tabitha Sable (Kubernetes SIG Security)
 
+{{% pageinfo color="primary" %}}
+**Update:** *With the release of Kubernetes v1.25, PodSecurityPolicy has been removed.* *You can read more information about the removal of PodSecurityPolicy in the [Kubernetes 1.25 release notes](/blog/2022/08/23/kubernetes-v1-25-release/#pod-security-changes).*
+{{% /pageinfo %}}
+
 PodSecurityPolicy (PSP) is being deprecated in Kubernetes 1.21, to be released later this week. This starts the countdown to its removal, but doesn’t change anything else. PodSecurityPolicy will continue to be fully functional for several more releases before being removed completely. In the meantime, we are developing a replacement for PSP that covers key use cases more easily and sustainably.
 
 What are Pod Security Policies? Why did we need them? Why are they going away, and what’s next? How does this affect you? These key questions come to mind as we prepare to say goodbye to PSP, so let’s walk through them together. We’ll start with an overview of how features get removed from Kubernetes.

content/en/docs/concepts/policy/resource-quotas.md

@@ -39,6 +39,18 @@ Resource quotas work like this:
   See the [walkthrough](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
   for an example of how to avoid this problem.
 
+{{< note >}}
+- For `cpu` and `memory` resources, ResourceQuotas enforce that **every**
+(new) pod in that namespace sets a limit for that resource.
+If you enforce a resource quota in a namespace for either `cpu` or `memory`,
+you, and other clients, **must** specify either `requests` or `limits` for that resource,
+for every new Pod you submit. If you don't, the control plane may reject admission
+for that Pod.
+- For other resources: ResourceQuota works and will ignore pods in the namespace without setting a limit or request for that resource. It means that you can create a new pod without limit/request ephemeral storage if the resource quota limits the ephemeral storage of this namespace.
+You can use a [LimitRange](/docs/concepts/policy/limit-range/) to automatically set
+a default request for these resources.
+{{< /note >}}
+
 The name of a ResourceQuota object must be a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 

content/en/docs/reference/access-authn-authz/certificate-signing-requests.md

@@ -268,7 +268,7 @@ The certificate value is in Base64-encoded format under `status.certificate`.
 
 Export the issued certificate from the CertificateSigningRequest.
 
-```
+```shell
 kubectl get csr myuser -o jsonpath='{.status.certificate}'| base64 -d > myuser.crt
 ```
 
@@ -295,20 +295,20 @@ The last step is to add this user into the kubeconfig file.
 
 First, you need to add new credentials:
 
-```
+```shell
 kubectl config set-credentials myuser --client-key=myuser.key --client-certificate=myuser.crt --embed-certs=true
 
 ```
 
 Then, you need to add the context:
 
-```
+```shell
 kubectl config set-context myuser --cluster=kubernetes --user=myuser
 ```
 
 To test it, change the context to `myuser`:
 
-```
+```shell
 kubectl config use-context myuser
 ```
 

content/en/docs/reference/kubectl/cheatsheet.md

@@ -266,6 +266,7 @@ kubectl expose rc nginx --port=80 --target-port=8000
 kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -
 
 kubectl label pods my-pod new-label=awesome                      # Add a Label
+kubectl label pods my-pod new-label-                             # Remove a label
 kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq       # Add an annotation
 kubectl autoscale deployment foo --min=2 --max=10                # Auto scale a deployment "foo"
 ```

content/en/docs/tasks/run-application/horizontal-pod-autoscale.md

@@ -47,7 +47,30 @@ horizontal pod autoscaling.
 
 ## How does a HorizontalPodAutoscaler work?
 
-{{< figure src="/images/docs/horizontal-pod-autoscaler.svg" caption="HorizontalPodAutoscaler controls the scale of a Deployment and its ReplicaSet" class="diagram-medium">}}
+{{< mermaid >}}
+graph BT
+
+hpa[Horizontal Pod Autoscaler] --> scale[Scale]
+
+subgraph rc[RC / Deployment]
+    scale
+end
+
+scale -.-> pod1[Pod 1]
+scale -.-> pod2[Pod 2]
+scale -.-> pod3[Pod N]
+
+classDef hpa fill:#D5A6BD,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D;
+classDef rc fill:#F9CB9C,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D;
+classDef scale fill:#B6D7A8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D;
+classDef pod fill:#9FC5E8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D;
+class hpa hpa;
+class rc rc;
+class scale scale;
+class pod1,pod2,pod3 pod
+{{< /mermaid >}}
+
+Figure 1. HorizontalPodAutoscaler controls the scale of a Deployment and its ReplicaSet
 
 Kubernetes implements horizontal pod autoscaling as a control loop that runs intermittently
 (it is not a continuous process). The interval is set by the

content/fr/docs/concepts/storage/persistent-volumes.md

@@ -242,7 +242,7 @@ Au lieu de cela, un volume existant est redimensionné.
 
 #### Redimensionnement de volume CSI
 
-{{< feature-state for_k8s_version="v1.16" state="beta" >}}
+{{< feature-state for_k8s_version="v1.24" state="stable" >}}
 
 La prise en charge du redimensionnement des volumes CSI est activée par défaut, mais elle nécessite également un pilote CSI spécifique pour prendre en charge le redimensionnement des volumes.
 Reportez-vous à la documentation du pilote CSI spécifique pour plus d'informations.

content/pt-br/docs/reference/glossary/csi.md

@@ -0,0 +1,22 @@
+---
+title: Interface de Armazenamento de Contêiner
+id: csi
+date: 2018-06-25
+full_link: /pt-br/docs/concepts/storage/volumes/#csi
+short_description: >
+ A Interface de Armazenamento de Contêiner (_Container Storage Interface_, CSI) define um padrão de interface para expor sistemas de armazenamento a contêineres.
+
+aka: 
+tags:
+- storage 
+---
+ A Interface de Armazenamento de Contêiner (_Container Storage Interface_, CSI) define um padrão de interface para expor sistemas de armazenamento a contêineres.
+
+<!--more--> 
+
+O CSI permite que os fornecedores criem plugins personalizados de armazenamento para o Kubernetes sem adicioná-los ao repositório Kubernetes (plugins fora da árvore). 
+Para usar um driver CSI de um provedor de armazenamento, você deve primeiro [instalá-lo no seu cluster](https://kubernetes-csi.github.io/docs/deploying.html). 
+Você poderá então criar uma {{< glossary_tooltip text="Classe de Armazenamento" term_id="storage-class" >}} que use esse driver CSI.
+
+* [CSI na documentação do Kubernetes](/pt-br/docs/concepts/storage/volumes/#csi)
+* [Lista de drivers CSI disponíveis](https://kubernetes-csi.github.io/docs/drivers.html)

content/zh-cn/docs/concepts/architecture/cgroups.md

@@ -17,7 +17,7 @@ constrain resources that are allocated to processes.
 
 The {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} and the
 underlying container runtime need to interface with cgroups to enforce
-[resource mangement for pods and containers](/docs/concepts/configuration/manage-resources-containers/) which
+[resource management for pods and containers](/docs/concepts/configuration/manage-resources-containers/) which
 includes cpu/memory requests and limits for containerized workloads.
 
 There are two versions of cgroups in Linux: cgroup v1 and cgroup v2. cgroup v2 is
@@ -204,7 +204,7 @@ cgroup v2 使用一个与 cgroup v1 不同的 API，因此如果有任何应用
 <!--
 ## Identify the cgroup version on Linux Nodes  {#check-cgroup-version}
 
-The cgroup version depends on on the Linux distribution being used and the
+The cgroup version depends on the Linux distribution being used and the
 default cgroup version configured on the OS. To check which cgroup version your
 distribution uses, run the `stat -fc %T /sys/fs/cgroup/` command on
 the node: