Merge pull request #39824 from mickeyboxell/merged-main-dev-1.27

Merged main dev 1.27

Author: k8s-ci-robot

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

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

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._

content/en/blog/_posts/2022-12-12-kubernetes-release-artifact-signing.md

@@ -31,8 +31,8 @@ files side by side to the artifacts for verifying their integrity.
 
 [tarballs]: https://github.com/kubernetes/kubernetes/blob/release-1.26/CHANGELOG/CHANGELOG-1.26.md#downloads-for-v1260
 [binaries]: https://gcsweb.k8s.io/gcs/kubernetes-release/release/v1.26.0/bin
-[sboms]: https://storage.googleapis.com/kubernetes-release/release/v1.26.0/kubernetes-release.spdx
-[provenance]: https://storage.googleapis.com/kubernetes-release/release/v1.26.0/provenance.json
+[sboms]: https://dl.k8s.io/release/v1.26.0/kubernetes-release.spdx
+[provenance]: https://dl.k8s.io/kubernetes-release/release/v1.26.0/provenance.json
 [cosign]: https://github.com/sigstore/cosign
 
 To verify an artifact, for example `kubectl`, you can download the

content/en/blog/_posts/2023-03-01-introducing-kwok/index.md

@@ -0,0 +1,76 @@
+---
+layout: blog
+title: "Introducing KWOK: Kubernetes WithOut Kubelet"
+date: 2023-03-01
+slug: introducing-kwok
+canonicalUrl: https://kubernetes.dev/blog/2023/03/01/introducing-kwok/
+---
+
+**Author:** Shiming Zhang (DaoCloud), Wei Huang (Apple), Yibo Zhuang (Apple)
+
+<img style="float: right; display: inline-block; margin-left: 2em; max-width: 15em;" src="/blog/2023/03/01/introducing-kwok/kwok.svg" alt="KWOK logo" />
+
+Have you ever wondered how to set up a cluster of thousands of nodes just in seconds, how to simulate real nodes with a low resource footprint, and how to test your Kubernetes controller at scale without spending much on infrastructure?
+
+If you answered "yes" to any of these questions, then you might be interested in KWOK, a toolkit that enables you to create a cluster of thousands of nodes in seconds.
+
+## What is KWOK?
+
+KWOK stands for Kubernetes WithOut Kubelet. So far, it provides two tools:
+
+`kwok`
+: `kwok` is the cornerstone of this project, responsible for simulating the lifecycle of fake nodes, pods, and other Kubernetes API resources.
+
+`kwokctl`
+: `kwokctl` is a CLI tool designed to streamline the creation and management of clusters, with nodes simulated by `kwok`.
+
+## Why use KWOK?
+
+KWOK has several advantages:
+
+- **Speed**: You can create and delete clusters and nodes almost instantly, without waiting for boot or provisioning.
+- **Compatibility**: KWOK works with any tools or clients that are compliant with Kubernetes APIs, such as kubectl, helm, kui, etc.
+- **Portability**: KWOK has no specific hardware or software requirements. You can run it using pre-built images, once Docker or Nerdctl is installed. Alternatively, binaries are also available for all platforms and can be easily installed.
+- **Flexibility**: You can configure different node types, labels, taints, capacities, conditions, etc., and you can configure different pod behaviors, status, etc. to test different scenarios and edge cases.
+- **Performance**: You can simulate thousands of nodes on your laptop without significant consumption of CPU or memory resources.
+
+## What are the use cases?
+
+KWOK can be used for various purposes:
+
+- **Learning**: You can use KWOK to learn about Kubernetes concepts and features without worrying about resource waste or other consequences. 
+- **Development**: You can use KWOK to develop new features or tools for Kubernetes without accessing to a real cluster or requiring other components.
+- **Testing**:
+  - You can measure how well your application or controller scales with different numbers of nodes and(or) pods.
+  - You can generate high loads on your cluster by creating many pods or services with different resource requests or limits.
+  - You can simulate node failures or network partitions by changing node conditions or randomly deleting nodes.
+  - You can test how your controller interacts with other components or features of Kubernetes by enabling different feature gates or API versions.
+
+## What are the limitations?
+
+KWOK is not intended to replace others completely. It has some limitations that you should be aware of:
+
+- **Functionality**: KWOK is not a kubelet and may exhibit different behaviors in areas such as pod lifecycle management, volume mounting, and device plugins. Its primary function is to simulate updates of node and pod status.
+- **Accuracy**: It's important to note that KWOK doesn't accurately reflect the performance or behavior of real nodes under various workloads or environments. Instead, it approximates some behaviors using simple formulas.
+- **Security**: KWOK does not enforce any security policies or mechanisms on simulated nodes. It assumes that all requests from the kube-apiserver are authorized and valid.
+
+## Getting started
+
+If you are interested in trying out KWOK, please check its [documents] for more details.
+
+{{< figure src="/blog/2023/03/01/introducing-kwok/manage-clusters.svg" alt="Animation of a terminal showing kwokctl in use" caption="Using kwokctl to manage simulated clusters" >}}
+
+## Getting Involved
+
+If you're interested in participating in future discussions or development related to KWOK, there are several ways to get involved:
+
+- Slack: [#kwok] for general usage discussion, [#kwok-dev] for development discussion. (visit [slack.k8s.io] for a workspace invitation)
+- Open Issues/PRs/Discussions in [sigs.k8s.io/kwok]
+
+We welcome feedback and contributions from anyone who wants to join us in this exciting project.
+
+[documents]: https://kwok.sigs.k8s.io/
+[sigs.k8s.io/kwok]: https://sigs.k8s.io/kwok/
+[#kwok]: https://kubernetes.slack.com/messages/kwok/
+[#kwok-dev]: https://kubernetes.slack.com/messages/kwok-dev/
+[slack.k8s.io]: https://slack.k8s.io/

content/en/blog/_posts/2023-03-01-introducing-kwok/kwok.svg

@@ -17,8 +17,6 @@ components.
 The cloud-controller-manager is structured using a plugin
 mechanism that allows different cloud providers to integrate their platforms with Kubernetes.
 
-
-
 <!-- body -->
 
 ## Design
@@ -48,10 +46,10 @@ when new servers are created in your cloud infrastructure. The node controller o
 hosts running inside your tenancy with the cloud provider. The node controller performs the following functions:
 
 1. Update a Node object with the corresponding server's unique identifier obtained from the cloud provider API.
-2. Annotating and labelling the Node object with cloud-specific information, such as the region the node
+1. Annotating and labelling the Node object with cloud-specific information, such as the region the node
    is deployed into and the resources (CPU, memory, etc) that it has available.
-3. Obtain the node's hostname and network addresses.
-4. Verifying the node's health. In case a node becomes unresponsive, this controller checks with
+1. Obtain the node's hostname and network addresses.
+1. Verifying the node's health. In case a node becomes unresponsive, this controller checks with
    your cloud provider's API to see if the server has been deactivated / deleted / terminated.
    If the node has been deleted from the cloud, the controller deletes the Node object from your Kubernetes
    cluster.
@@ -88,13 +86,13 @@ to read and modify Node objects.
 
 `v1/Node`:
 
-- Get
-- List
-- Create
-- Update
-- Patch
-- Watch
-- Delete
+- get
+- list
+- create
+- update
+- patch
+- watch
+- delete
 
 ### Route controller {#authorization-route-controller}
 
@@ -103,37 +101,42 @@ routes appropriately. It requires Get access to Node objects.
 
 `v1/Node`:
 
-- Get
+- get
 
 ### Service controller {#authorization-service-controller}
 
-The service controller listens to Service object Create, Update and Delete events and then configures Endpoints for those Services appropriately (for EndpointSlices, the kube-controller-manager manages these on demand).
+The service controller watches for Service object **create**, **update** and **delete** events and then
+configures Endpoints for those Services appropriately (for EndpointSlices, the
+kube-controller-manager manages these on demand).
 
-To access Services, it requires List, and Watch access. To update Services, it requires Patch and Update access.
+To access Services, it requires **list**, and **watch** access. To update Services, it requires
+**patch** and **update** access.
 
-To set up Endpoints resources for the Services, it requires access to Create, List, Get, Watch, and Update.
+To set up Endpoints resources for the Services, it requires access to **create**, **list**,
+**get**, **watch**, and **update**.
 
 `v1/Service`:
 
-- List
-- Get
-- Watch
-- Patch
-- Update
+- list
+- get
+- watch
+- patch
+- update
 
 ### Others {#authorization-miscellaneous}
 
-The implementation of the core of the cloud controller manager requires access to create Event objects, and to ensure secure operation, it requires access to create ServiceAccounts.
+The implementation of the core of the cloud controller manager requires access to create Event
+objects, and to ensure secure operation, it requires access to create ServiceAccounts.
 
 `v1/Event`:
 
-- Create
-- Patch
-- Update
+- create
+- patch
+- update
 
 `v1/ServiceAccount`:
 
-- Create
+- create
 
 The {{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRole for the cloud
 controller manager looks like:
@@ -206,12 +209,21 @@ rules:
 [Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
 has instructions on running and managing the cloud controller manager.
 
-To upgrade a HA control plane to use the cloud controller manager, see [Migrate Replicated Control Plane To Use Cloud Controller Manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/).
+To upgrade a HA control plane to use the cloud controller manager, see
+[Migrate Replicated Control Plane To Use Cloud Controller Manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/).
 
 Want to know how to implement your own cloud controller manager, or extend an existing project?
 
-The cloud controller manager uses Go interfaces to allow implementations from any cloud to be plugged in. Specifically, it uses the `CloudProvider` interface defined in [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.21/cloud.go#L42-L69) from [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider).
+The cloud controller manager uses Go interfaces to allow implementations from any cloud to be plugged in.
+Specifically, it uses the `CloudProvider` interface defined in
+[`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.26/cloud.go#L43-L69) from
+[kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider).
+
+The implementation of the shared controllers highlighted in this document (Node, Route, and Service),
+and some scaffolding along with the shared cloudprovider interface, is part of the Kubernetes core.
+Implementations specific to cloud providers are outside the core of Kubernetes and implement the
+`CloudProvider` interface.
 
-The implementation of the shared controllers highlighted in this document (Node, Route, and Service), and some scaffolding along with the shared cloudprovider interface, is part of the Kubernetes core. Implementations specific to cloud providers are outside the core of Kubernetes and implement the `CloudProvider` interface.
+For more information about developing plugins, see
+[Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
 
-For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).