Merge branch 'main' of github.com:kubernetes/website into k8s-gcr-io-banner-1

Author: upodroid

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/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/docs/concepts/architecture/cgroups.md

@@ -103,6 +103,8 @@ updated to newer versions that support cgroup v2. For example:
 * If you run [cAdvisor](https://github.com/google/cadvisor) as a stand-alone
  DaemonSet for monitoring pods and containers, update it to v0.43.0 or later.
 * If you use JDK, prefer to use JDK 11.0.16 and later or JDK 15 and later, which [fully support cgroup v2](https://bugs.openjdk.org/browse/JDK-8230305).
+* If you are using the [uber-go/automaxprocs](https://github.com/uber-go/automaxprocs) package, make sure
+  the version you use is v1.5.1 or higher.
 
 ## Identify the cgroup version on Linux Nodes  {#check-cgroup-version}
 

content/en/docs/concepts/architecture/cloud-controller.md

@@ -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/).

content/en/docs/concepts/architecture/control-plane-node-communication.md

@@ -11,7 +11,8 @@ aliases:
 
 <!-- overview -->
 
-This document catalogs the communication paths between the API server and the Kubernetes cluster.
+This document catalogs the communication paths between the {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}}
+and the Kubernetes {{< glossary_tooltip text="cluster" term_id="cluster" length="all" >}}.
 The intent is to allow users to customize their installation to harden the network configuration
 such that the cluster can be run on an untrusted network (or on fully public IPs on a cloud
 provider).
@@ -30,28 +31,28 @@ enabled, especially if [anonymous requests](/docs/reference/access-authn-authz/a
 or [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens)
 are allowed.
 
-Nodes should be provisioned with the public root certificate for the cluster such that they can
+Nodes should be provisioned with the public root {{< glossary_tooltip text="certificate" term_id="certificate" >}} for the cluster such that they can
 connect securely to the API server along with valid client credentials. A good approach is that the
 client credentials provided to the kubelet are in the form of a client certificate. See
 [kubelet TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
 for automated provisioning of kubelet client certificates.
 
-Pods that wish to connect to the API server can do so securely by leveraging a service account so
+{{< glossary_tooltip text="Pods" term_id="pod" >}} that wish to connect to the API server can do so securely by leveraging a service account so
 that Kubernetes will automatically inject the public root certificate and a valid bearer token
 into the pod when it is instantiated.
 The `kubernetes` service (in `default` namespace) is configured with a virtual IP address that is
-redirected (via `kube-proxy`) to the HTTPS endpoint on the API server.
+redirected (via `{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}`) to the HTTPS endpoint on the API server.
 
 The control plane components also communicate with the API server over the secure port.
 
-As a result, the default operating mode for connections from the nodes and pods running on the
+As a result, the default operating mode for connections from the nodes and pod running on the
 nodes to the control plane is secured by default and can run over untrusted and/or public
 networks.
 
 ## Control plane to node
 
 There are two primary communication paths from the control plane (the API server) to the nodes.
-The first is from the API server to the kubelet process which runs on each node in the cluster.
+The first is from the API server to the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} process which runs on each node in the cluster.
 The second is from the API server to any node, pod, or service through the API server's _proxy_
 functionality.
 
@@ -89,7 +90,7 @@ connections **are not currently safe** to run over untrusted or public networks.
 
 ### SSH tunnels
 
-Kubernetes supports SSH tunnels to protect the control plane to nodes communication paths. In this
+Kubernetes supports [SSH tunnels](https://www.ssh.com/academy/ssh/tunneling) to protect the control plane to nodes communication paths. In this
 configuration, the API server initiates an SSH tunnel to each node in the cluster (connecting to
 the SSH server listening on port 22) and passes all traffic destined for a kubelet, node, pod, or
 service through the tunnel.
@@ -117,3 +118,12 @@ connections.
 Follow the [Konnectivity service task](/docs/tasks/extend-kubernetes/setup-konnectivity/) to set
 up the Konnectivity service in your cluster.
 
+## {{% heading "whatsnext" %}}
+
+* Read about the [Kubernetes control plane components](/docs/concepts/overview/components/#control-plane-components)
+* Learn more about [Hubs and Spoke model](https://book.kubebuilder.io/multiversion-tutorial/conversion-concepts.html#hubs-spokes-and-other-wheel-metaphors)
+* Learn how to [Secure a Cluster](/docs/tasks/administer-cluster/securing-a-cluster/) 
+* Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/)
+* [Set up Konnectivity service](/docs/tasks/extend-kubernetes/setup-konnectivity/)
+* [Use Port Forwarding to Access Applications in a Cluster](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
+* Learn how to [Fetch logs for Pods](/docs/tasks/debug/debug-application/debug-running-pod/#examine-pod-logs), [use kubectl port-forward](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/#forward-a-local-port-to-a-port-on-the-pod)

content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md

@@ -63,9 +63,10 @@ The name of a PriorityClass object must be a valid
 and it cannot be prefixed with `system-`.
 
 A PriorityClass object can have any 32-bit integer value smaller than or equal
-to 1 billion. Larger numbers are reserved for critical system Pods that should
-not normally be preempted or evicted. A cluster admin should create one
-PriorityClass object for each such mapping that they want.
+to 1 billion. This means that the range of values for a PriorityClass object is
+from -2147483648 to 1000000000 inclusive. Larger numbers are reserved for 
+built-in PriorityClasses that represent critical system Pods. A cluster
+admin should create one PriorityClass object for each such mapping that they want.
 
 PriorityClass also has two optional fields: `globalDefault` and `description`.
 The `globalDefault` field indicates that the value of this PriorityClass should