kubernetes · chrismetz09 · Feb 20, 2023 · Feb 20, 2023 · Feb 20, 2023 · Feb 20, 2023
diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES
@@ -44,6 +44,7 @@ aliases:
     - divya-mohan0209
     - kbhawkey
     - mehabhalodiya
+    - mengjiao-liu
     - natalisucks
     - nate-double-u
     - onlydole
@@ -143,6 +144,7 @@ aliases:
     - chenxuc
     - howieyuen
     # idealhack
+    - kinzhi
     - mengjiao-liu
     - my-git9
     # pigletfly
@@ -166,6 +168,7 @@ aliases:
     - edsoncelio
     - femrtnz
     - jcjesus
+    - mrerlison
     - rikatz
     - stormqueen1990
     - yagonobre

diff --git a/README-zh.md b/README-zh.md
@@ -60,14 +60,34 @@ cd website
 <!--
 The Kubernetes website uses the [Docsy Hugo theme](https://github.com/google/docsy#readme). Even if you plan to run the website in a container, we strongly recommend pulling in the submodule and other development dependencies by running the following:
 -->
-
 Kubernetes 网站使用的是 [Docsy Hugo 主题](https://github.com/google/docsy#readme)。
 即使你打算在容器中运行网站，我们也强烈建议你通过运行以下命令来引入子模块和其他开发依赖项：
 
-```bash
-# 引入 Docsy 子模块
+<!-- 
+### Windows
+```powershell
+# fetch submodule dependencies
 git submodule update --init --recursive --depth 1
-```
+``` 
+-->
+### Windows
+```powershell
+# 获取子模块依赖
+git submodule update --init --recursive --depth 1
+``` 
+
+<!-- 
+### Linux / other Unix
+```bash
+# fetch submodule dependencies
+make module-init
+``` 
+-->
+### Linux / 其它 Unix
+```bash
+# 获取子模块依赖
+make module-init
+``` 
 
 <!--
 ## Running the website using a container

diff --git a/assets/scss/_custom.scss b/assets/scss/_custom.scss
@@ -878,3 +878,17 @@ div.alert > em.javascript-required {
     color: #fff;
     background: #326de6;
 }
+
+// Adjust Bing search result page
+#bing-results-container {
+    padding: 1em;
+}
+#bing-pagination-container {
+    padding: 1em;
+    margin-bottom: 1em;
+
+    a.bing-page-anchor {
+        padding: 0.5em;
+        margin: 0.25em;
+    }
+}
diff --git a/content/de/docs/concepts/containers/images.md b/content/de/docs/concepts/containers/images.md
@@ -277,7 +277,7 @@ Pods können nur eigene Image Pull Secret in ihrem eigenen Namespace referenzier
 
 #### Referenzierung eines imagePullSecrets bei einem Pod
 
-Nun können Sie Pods erstellen, die dieses Secret referenzieren, indem Sie einen Aschnitt `imagePullSecrets` zu ihrer Pod - Definition hinzufügen.
+Nun können Sie Pods erstellen, die dieses Secret referenzieren, indem Sie einen Abschnitt `imagePullSecrets` zu ihrer Pod - Definition hinzufügen.
 
 ```shell
 cat <<EOF > pod.yaml

diff --git a/content/en/_index.html b/content/en/_index.html
@@ -30,7 +30,9 @@
 {{% blocks/feature image="suitcase" %}}
 #### Run K8s Anywhere
 
-Kubernetes is open source giving you the freedom to take advantage of on-premises, hybrid, or public cloud infrastructure, letting you effortlessly move workloads to where it matters to you.
+Kubernetes is open source giving you the freedom to take advantage of on-premises, hybrid, or public cloud infrastructure, letting you effortlessly move workloads to where it matters to you. 
+
+To download Kubernetes, visit the [download](/releases/download/) section.
 
 {{% /blocks/feature %}}
 

diff --git a/...ent/en/blog/_posts/2016-10-00-Dynamic-Provisioning-And-Storage-In-Kubernetes.md b/...ent/en/blog/_posts/2016-10-00-Dynamic-Provisioning-And-Storage-In-Kubernetes.md
@@ -143,7 +143,7 @@ When a default StorageClass exists and a user creates a PersistentVolumeClaim wi
 
 
 
-Kubernetes 1.4 maintains backwards compatibility with the alpha version of the dynamic provisioning feature to allow for a smoother transition to the beta version. The alpha behavior is triggered by the existance of the alpha dynamic provisioning annotation (volume. **alpha**.kubernetes.io/storage-class). Keep in mind that if the beta annotation (volume. **beta**.kubernetes.io/storage-class) is present, it takes precedence, and triggers the beta behavior.
+Kubernetes 1.4 maintains backwards compatibility with the alpha version of the dynamic provisioning feature to allow for a smoother transition to the beta version. The alpha behavior is triggered by the existence of the alpha dynamic provisioning annotation (volume. **alpha**.kubernetes.io/storage-class). Keep in mind that if the beta annotation (volume. **beta**.kubernetes.io/storage-class) is present, it takes precedence, and triggers the beta behavior.
 
 
 

diff --git a/content/en/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md b/content/en/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md
@@ -192,7 +192,7 @@ To modify/add your own DAGs, you can use `kubectl cp` to upload local files into
 
 # Get Involved
 
-This feature is just the beginning of multiple major efforts to improves Apache Airflow integration into Kubernetes. The Kubernetes Operator has been merged into the [1.10 release branch of Airflow](https://github.com/apache/incubator-airflow/tree/v1-10-test) (the executor in experimental mode), along with a fully k8s native scheduler called the Kubernetes Executor (article to come). These features are still in a stage where early adopters/contributers can have a huge influence on the future of these features.
+This feature is just the beginning of multiple major efforts to improves Apache Airflow integration into Kubernetes. The Kubernetes Operator has been merged into the [1.10 release branch of Airflow](https://github.com/apache/incubator-airflow/tree/v1-10-test) (the executor in experimental mode), along with a fully k8s native scheduler called the Kubernetes Executor (article to come). These features are still in a stage where early adopters/contributors can have a huge influence on the future of these features.
 
 For those interested in joining these efforts, I'd recommend checkint out these steps:
 

diff --git a/content/en/blog/_posts/2018-10-02-network-bootable-farm-with-ltsp.md b/content/en/blog/_posts/2018-10-02-network-bootable-farm-with-ltsp.md
@@ -460,7 +460,7 @@ Now you can configure your DHCP. Basically you should set the `next-server` and
 I use ISC-DHCP server, and here is an example `dhcpd.conf`:
 
 ```
-shared-network ltsp-netowrk {
+shared-network ltsp-network {
     subnet 10.9.0.0 netmask 255.255.0.0 {
         authoritative;
         default-lease-time -1;

diff --git a/content/en/blog/_posts/2018-12-11-Kubernetes-Federation-Evolution.md b/content/en/blog/_posts/2018-12-11-Kubernetes-Federation-Evolution.md
@@ -8,7 +8,7 @@ date: 2018-12-12
 
 Kubernetes provides great primitives for deploying applications to a cluster: it can be as simple as `kubectl create -f app.yaml`. Deploy apps across multiple clusters has never been that simple. How should app workloads be distributed? Should the app resources be replicated into all clusters, replicated into selected clusters, or partitioned into clusters? How is  access to the clusters managed? What happens if some of the resources that a user wants to distribute pre-exist, in some or all of the clusters, in some form?
 
-In SIG Multicluster, our journey has revealed that there are multiple possible models to solve these problems and there probably is no single best-fit, all-scenario solution. [Federation](/docs/concepts/cluster-administration/federation/), however, is the single biggest Kubernetes open source sub-project, and has seen the maximum interest and contribution from the community in this problem space. The project initially reused the Kubernetes API to do away with any added usage complexity for an existing Kubernetes user. This approach was not viable, because of the problems summarised below:
+In SIG Multicluster, our journey has revealed that there are multiple possible models to solve these problems and there probably is no single best-fit, all-scenario solution. [Kubernetes Cluster Federation (KubeFed for short)](https://github.com/kubernetes-sigs/kubefed), however, is the single biggest Kubernetes open source sub-project, and has seen the maximum interest and contribution from the community in this problem space. The project initially reused the Kubernetes API to do away with any added usage complexity for an existing Kubernetes user. This approach was not viable, because of the problems summarised below:
 
 * Difficulties in re-implementing the Kubernetes API at the cluster level, as federation-specific extensions were stored in annotations.
 * Limited flexibility in federated types, placement and reconciliation, due to 1:1 emulation of the Kubernetes API.

diff --git a/content/en/blog/_posts/2019-04-04-local-persistent-volumes-ga.md b/content/en/blog/_posts/2019-04-04-local-persistent-volumes-ga.md
@@ -129,7 +129,7 @@ spec:
     spec:
       containers:
       - name: test-container
-        image: k8s.gcr.io/busybox
+        image: registry.k8s.io/busybox # updated after publication (previously used k8s.gcr.io/busybox)
         command:
         - "/bin/sh"
         args:

diff --git a/content/en/blog/_posts/2020-05-06-third-party-dual-sourced-content.md b/content/en/blog/_posts/2020-05-06-third-party-dual-sourced-content.md
@@ -27,7 +27,7 @@ Our goal is for Kubernetes docs to be a trustworthy guide to Kubernetes features
 
 ### Re-homing content
 
-Some content will be removed that readers may find helpful. To make sure readers have continous access to information, we're giving stakeholders until the [1.19 release deadline for docs](https://github.com/kubernetes/sig-release/tree/master/releases/release-1.19), **July 9th, 2020** to re-home any content slated for removal.
+Some content will be removed that readers may find helpful. To make sure readers have continuous access to information, we're giving stakeholders until the [1.19 release deadline for docs](https://github.com/kubernetes/sig-release/tree/master/releases/release-1.19), **July 9th, 2020** to re-home any content slated for removal.
 
 Over the next few months you'll see less third party content in the docs as contributors open PRs to remove content.
 

diff --git a/content/en/blog/_posts/2020-05-21-wsl2-dockerdesktop-k8s.md b/content/en/blog/_posts/2020-05-21-wsl2-dockerdesktop-k8s.md
@@ -520,7 +520,7 @@ And the real strength of WSL2 integration, the port `8443` once open on WSL2 dis
 
 Working on the command line is always good and very insightful. However, when dealing with Kubernetes we might want, at some point, to have a visual overview.
 
-For that, Minikube embeded the [Kubernetes Dashboard](https://github.com/kubernetes/dashboard). Thanks to it, running and accessing the Dashboard is very simple:
+For that, Minikube embedded the [Kubernetes Dashboard](https://github.com/kubernetes/dashboard). Thanks to it, running and accessing the Dashboard is very simple:
 
 ```bash
 # Enable the Dashboard service

diff --git a/...og/_posts/2020-05-27-An-Introduction-to-the-K8s-Infrastructure-Working-Group.md b/...og/_posts/2020-05-27-An-Introduction-to-the-K8s-Infrastructure-Working-Group.md
@@ -55,7 +55,7 @@ The team has made progress in the last few months that is well worth celebrating
 
 - The K8s-Infrastructure Working Group released an automated billing report that they start every meeting off by reviewing as a group. 
 - DNS for k8s.io and kubernetes.io are also fully [community-owned](https://groups.google.com/g/kubernetes-dev/c/LZTYJorGh7c/m/u-ydk-yNEgAJ), with community members able to [file issues](https://github.com/kubernetes/k8s.io/issues/new?assignees=&labels=wg%2Fk8s-infra&template=dns-request.md&title=DNS+REQUEST%3A+%3Cyour-dns-record%3E) to manage records.
-- The container registry [k8s.gcr.io](https://github.com/kubernetes/k8s.io/tree/main/k8s.gcr.io) is also fully community-owned and available for all Kubernetes subprojects to use. 
+- The container registry [registry.k8s.io](https://github.com/kubernetes/k8s.io/tree/main/registry.k8s.io) is also fully community-owned and available for all Kubernetes subprojects to use. 
 _Note:_ The container registry has changed to registry.k8s.io. Updated on August 25, 2022.
 - The Kubernetes [publishing-bot](https://github.com/kubernetes/publishing-bot) responsible for keeping k8s.io/kubernetes/staging repositories published to their own top-level repos (For example: [kubernetes/api](https://github.com/kubernetes/api)) runs on a community-owned cluster.
 - The gcsweb.k8s.io service used to provide anonymous access to GCS buckets for kubernetes artifacts runs on a community-owned cluster.

diff --git a/content/en/blog/_posts/2020-07-27-kubernetes-1-17-release-interview.md b/content/en/blog/_posts/2020-07-27-kubernetes-1-17-release-interview.md
@@ -198,7 +198,7 @@ GUINEVERE SAENGER: I would want Jorge to be really on top of making sure that ev
 
 Greater communication of timelines and just giving people more time and space to be able to get in their changes, or at least, seemingly give them more time and space by sending early warnings, is going to be helpful. Of course, he's going to have a slightly longer release, too, than I did. This might be related to a unique Q4 challenge. Overall, I would encourage him to take more breaks, to rely more on his release shadows, and split out the work in a fashion that allows everyone to have a turn and everyone to have a break as well.
 
-**ADAM GLICK: What would your advice be to someone who is hearing your experience and is inspired to get involved with the Kubernetes release or contributer process?**
+**ADAM GLICK: What would your advice be to someone who is hearing your experience and is inspired to get involved with the Kubernetes release or contributor process?**
 
 GUINEVERE SAENGER: Those are two separate questions. So let me tackle the Kubernetes release question first. Kubernetes [SIG Release](https://github.com/kubernetes/sig-release/#readme) has, in my opinion, a really excellent onboarding program for new members. We have what is called the [Release Team Shadow Program](https://github.com/kubernetes/sig-release/blob/master/release-team/shadows.md). We also have the Release Engineering Shadow Program, or the Release Management Shadow Program. Those are two separate subprojects within SIG Release. And each subproject has a team of roles, and each role can have two to four shadows that are basically people who are part of that role team, and they are learning that role as they are doing it.
 

diff --git a/content/en/blog/_posts/2021-12-07-kubernetes-release-1.23.md b/content/en/blog/_posts/2021-12-07-kubernetes-release-1.23.md
@@ -81,7 +81,7 @@ If the `ServerSideFieldValidation` feature gate is enabled starting 1.23, users
 
 With the feature gate enabled, we also introduce the `fieldValidation` query parameter so that users can specify the desired behavior of the server on a per request basis. Valid values for the `fieldValidation` query parameter are:
 
-- Ignore (default when feature gate is disabled, same as pre-1.23 behavior of dropping/ignoring unkonwn fields)
+- Ignore (default when feature gate is disabled, same as pre-1.23 behavior of dropping/ignoring unknown fields)
 - Warn (default when feature gate is enabled).
 - Strict (this will fail the request with an Invalid Request error)
 

diff --git a/content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md b/content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md
@@ -5,6 +5,7 @@ linkTitle: "Dockershim Removal FAQ"
 date: 2022-02-17
 slug: dockershim-faq
 aliases: [ '/dockershim' ]
+evergreen: true
 ---
 
 **This supersedes the original

diff --git a/content/en/blog/_posts/2022-03-15-meet-our-contributors-APAC-AU-NZ-region-02.md b/content/en/blog/_posts/2022-03-15-meet-our-contributors-APAC-AU-NZ-region-02.md
@@ -32,7 +32,7 @@ Caleb is also a co-organizer of the [CloudNative NZ](https://www.meetup.com/clou
 
 ## [Dylan Graham](https://github.com/DylanGraham)
 
-Dylan Graham is a cloud engineer from Adeliade, Australia. He has been contributing to the upstream Kubernetes project since 2018.
+Dylan Graham is a cloud engineer from Adelaide, Australia. He has been contributing to the upstream Kubernetes project since 2018.
 
 He stated that being a part of such a large-scale project was initially overwhelming, but that the community's friendliness and openness assisted him in getting through it.
 

diff --git a/content/en/blog/_posts/2022-05-13-grpc-probes-in-beta.md b/content/en/blog/_posts/2022-05-13-grpc-probes-in-beta.md
@@ -115,7 +115,8 @@ metadata:
 spec:
   containers:
   - name: agnhost
-    image: k8s.gcr.io/e2e-test-images/agnhost:2.35
+    # image changed since publication (previously used registry "k8s.gcr.io")
+    image: registry.k8s.io/e2e-test-images/agnhost:2.35
     command: ["/agnhost", "grpc-health-checking"]
     ports:
     - containerPort: 5000

diff --git a/content/en/blog/_posts/2022-05-27-maxunavailable-for-statefulset.md b/content/en/blog/_posts/2022-05-27-maxunavailable-for-statefulset.md
@@ -18,7 +18,7 @@ case where you're using the `OrderedReady` Pod management policy for a StatefulS
 Here are some examples:
 
 -  I am using a StatefulSet to orchestrate a multi-instance, cache based application where the size of the cache is large. The cache 
-   starts cold and requires some siginificant amount of time before the container can start. There could be more initial startup tasks
+   starts cold and requires some significant amount of time before the container can start. There could be more initial startup tasks
    that are required. A RollingUpdate on this StatefulSet would take a lot of time before the application is fully updated. If the 
    StatefulSet supported updating more than one pod at a time, it would result in a much faster update.
 
@@ -50,7 +50,8 @@ spec:
         app: nginx
     spec:
       containers:
-      - image: k8s.gcr.io/nginx-slim:0.8
+      # image changed since publication (previously used registry "k8s.gcr.io")
+      - image: registry.k8s.io/nginx-slim:0.8
         imagePullPolicy: IfNotPresent
         name: nginx
   updateStrategy:
@@ -66,7 +67,7 @@ If you enable the new feature and you don't specify a value for `maxUnavailable`
 I'll run through a scenario based on that example manifest to demonstrate how this feature works. I will deploy a StatefulSet that
 has 5 replicas, with `maxUnavailable` set to 2 and `partition` set to 0.
 
-I can trigger a rolling update by changing the image to `k8s.gcr.io/nginx-slim:0.9`. Once I initiate the rolling update, I can 
+I can trigger a rolling update by changing the image to `registry.k8s.io/nginx-slim:0.9`. Once I initiate the rolling update, I can 
 watch the pods update 2 at a time as the current value of maxUnavailable is 2. The below output shows a span of time and is not 
 complete.  The maxUnavailable can be an absolute number (for example, 2) or a percentage of desired Pods (for example, 10%). The 
 absolute number is calculated from percentage by rounding up to the nearest integer.  

diff --git a/content/en/blog/_posts/2022-07-13-gateway-api-in-beta.md b/content/en/blog/_posts/2022-07-13-gateway-api-in-beta.md
@@ -145,7 +145,7 @@ workstream within the Gateway API subproject focused on Gateway API for Mesh
 Management and Administration.
 
 This group will deliver [enhancement
-proposals](https://gateway-api.sigs.k8s.io/v1beta1/contributing/gep/) consisting
+proposals](https://gateway-api.sigs.k8s.io/geps/overview/) consisting
 of resources, additions, and modifications to the Gateway API specification for
 mesh and mesh-adjacent use-cases.
 

diff --git a/content/en/blog/_posts/2022-08-31-cgroupv2-ga.md b/content/en/blog/_posts/2022-08-31-cgroupv2-ga.md
@@ -89,7 +89,7 @@ To use cgroup v2 with Kubernetes, you must meet the following requirements:
 * The kubelet and the container runtime are configured to use the [systemd cgroup driver](/docs/setup/production-environment/container-runtimes#systemd-cgroup-driver)
 
 The kubelet and container runtime use a [cgroup driver](/docs/setup/production-environment/container-runtimes#cgroup-drivers)
-to set cgroup paramaters. When using cgroup v2, it's strongly recommended that both
+to set cgroup parameters. When using cgroup v2, it's strongly recommended that both
 the kubelet and your container runtime use the
 [systemd cgroup driver](/docs/setup/production-environment/container-runtimes#systemd-cgroup-driver),
 so that there's a single cgroup manager on the system. To configure the kubelet

diff --git a/content/en/blog/_posts/2022-09-29-immutability-with-cel.md b/content/en/blog/_posts/2022-09-29-immutability-with-cel.md
@@ -438,7 +438,7 @@ kubectl apply -f crds/stable.example.com_appendonlylists.yaml
 customresourcedefinition.apiextensions.k8s.io/appendonlylists.stable.example.com created
 ```
 
-Creating an inital list with one element inside should succeed without problem:
+Creating an initial list with one element inside should succeed without problem:
 ```shell
 kubectl apply -f - <<EOF
 ---

diff --git a/content/en/blog/_posts/2022-11-28-registry-k8s-io-change.md b/content/en/blog/_posts/2022-11-28-registry-k8s-io-change.md
@@ -11,7 +11,7 @@ Starting with Kubernetes 1.25, our container image registry has changed from k8s
 
 ## TL;DR: What you need to know about this change
 
-* Container images for Kubernetes releases from 1.25 onward are no longer published to k8s.gcr.io, only to registry.k8s.io.
+* Container images for Kubernetes releases from <del>1.25</del> 1.27 onward are not published to k8s.gcr.io, only to registry.k8s.io.
 * In the upcoming December patch releases, the new registry domain default will be backported to all branches still in support (1.22, 1.23, 1.24).
 * If you run in a restricted environment and apply strict domain/IP address access policies limited to k8s.gcr.io, the __image pulls will not function__ after the migration to this new registry. For these users, the recommended method is to mirror the release images to a private registry.
 
@@ -68,8 +68,15 @@ The image used by kubelet for the pod sandbox (`pause`) can be overridden by set
 kubelet --pod-infra-container-image=k8s.gcr.io/pause:3.5
 ```
 
+## Legacy container registry freeze {#registry-freeze}
+
+[k8s.gcr.io Image Registry Will Be Frozen From the 3rd of April 2023](/blog/2023/02/06/k8s-gcr-io-freeze-announcement/) announces the freeze of the
+legacy k8s.gcr.io image registry. Read that article for more details.
+
 ## Acknowledgments
 
 __Change is hard__, and evolving our image-serving platform is needed to ensure a sustainable future for the project. We strive to make things better for everyone using Kubernetes. Many contributors from all corners of our community have been working long and hard to ensure we are making the best decisions possible, executing plans, and doing our best to communicate those plans. 
 
 Thanks to Aaron Crickenberger, Arnaud Meukam, Benjamin Elder, Caleb Woodbine, Davanum Srinivas, Mahamed Ali, and Tim Hockin from SIG K8s Infra, Brian McQueen, and Sergey Kanzhelev from SIG Node, Lubomir Ivanov from SIG Cluster Lifecycle, Adolfo García Veytia, Jeremy Rickard, Sascha Grunert, and Stephen Augustus from SIG Release, Bob Killen and Kaslin Fields from SIG Contribex, Tim Allclair from the Security Response Committee. Also a big thank you to our friends acting as liaisons with our cloud provider partners: Jay Pipes from Amazon and Jon Johnson Jr. from Google.
+
+_This article was updated on the 28th of February 2023._
Original file line number	Diff line number	Diff line change
Expand Up		@@ -143,7 +143,7 @@ When a default StorageClass exists and a user creates a PersistentVolumeClaim wi



		Kubernetes 1.4 maintains backwards compatibility with the alpha version of the dynamic provisioning feature to allow for a smoother transition to the beta version. The alpha behavior is triggered by the existance of the alpha dynamic provisioning annotation (volume. alpha.kubernetes.io/storage-class). Keep in mind that if the beta annotation (volume. beta.kubernetes.io/storage-class) is present, it takes precedence, and triggers the beta behavior.
		Kubernetes 1.4 maintains backwards compatibility with the alpha version of the dynamic provisioning feature to allow for a smoother transition to the beta version. The alpha behavior is triggered by the existence of the alpha dynamic provisioning annotation (volume. alpha.kubernetes.io/storage-class). Keep in mind that if the beta annotation (volume. beta.kubernetes.io/storage-class) is present, it takes precedence, and triggers the beta behavior.



Expand Down