whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Switch language name 'zh' to 'zh-cn'

Browse Source 
This is the first step to rename 'zh' to 'zh-cn'. There are several reasons why we rename the language name.

- The upstream docsy theme changed the language name, leading to many warnings during site build;
  The side-effect is that the i18n strings are no longer working.
- We believe renaming the language is the right thing to do, because this move can make room for other variants of Chinese language, such as 'zh-tw', 'zh-sg' etc.

There would be several follow-ups to this PR, such as fixing the intra-site links, adding redirects etc.

We will lock up changes to zh/zh-cn pages for the moment, until this one gets in.

This PR is based on commit cdad0a7342.
This commit is contained in:
Qiming Teng
2022-06-10 20:25:27 +08:00
parent 3d345b1816
commit c52818c03d
1347 changed files with 8 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh-cn/docs/concepts/architecture/_index.md
+6
View File
@@ -0,0 +1,6 @@
---
title: "Kubernetes 架构"
weight: 30
description: >
Kubernetes 背后的架构概念。
---
content/zh-cn/docs/concepts/architecture/cloud-controller.md
+348
View File
@@ -0,0 +1,348 @@
---
title: 云控制器管理器
content_type: concept
weight: 40
---
<!--
title: Cloud Controller Manager
content_type: concept
weight: 40
-->
<!-- overview -->
{{< feature-state state="beta" for_k8s_version="v1.11" >}}
<!--
Cloud infrastructure technologies let you run Kubernetes on public, private, and hybrid clouds.
Kubernetes believes in automated, API-driven infrastructure without tight coupling between
components.
-->
使用云基础设施技术，你可以在公有云、私有云或者混合云环境中运行 Kubernetes。
Kubernetes 的信条是基于自动化的、API 驱动的基础设施，同时避免组件间紧密耦合。
{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="组件 cloud-controller-manager 是指云控制器管理器，">}}
<!--
The cloud-controller-manager is structured using a plugin
mechanism that allows different cloud providers to integrate their platforms with Kubernetes.
-->
`cloud-controller-manager` 组件是基于一种插件机制来构造的，
这种机制使得不同的云厂商都能将其平台与 Kubernetes 集成。
<!-- body -->
<!--
## Design
![Kubernetes components](/images/docs/components-of-kubernetes.svg)
The cloud controller manager runs in the control plane as a replicated set of processes
(usually, these are containers in Pods). Each cloud-controller-manager implements
multiple {{< glossary_tooltip text="controllers" term_id="controller" >}} in a single
process.
-->
## 设计 {#design}
![Kubernetes 组件](/images/docs/components-of-kubernetes.svg)
云控制器管理器以一组多副本的进程集合的形式运行在控制面中，通常表现为 Pod
中的容器。每个 `cloud-controller-manager` 在同一进程中实现多个
{{< glossary_tooltip text="控制器" term_id="controller" >}}。
<!--
You can also run the cloud controller manager as a Kubernetes
{{< glossary_tooltip text="addon" term_id="addons" >}} rather than as part
of the control plane.
-->
{{< note >}}
你也可以用 Kubernetes {{< glossary_tooltip text="插件" term_id="addons" >}}
的形式而不是控制面中的一部分来运行云控制器管理器。
{{< /note >}}
<!--
## Cloud controller manager functions {#functions-of-the-ccm}
The controllers inside the cloud controller manager include:
-->
## 云控制器管理器的功能 {#functions-of-the-ccm}
云控制器管理器中的控制器包括：
<!--
### Node controller
The node controller is responsible for updating {{< glossary_tooltip text="Node" term_id="node" >}} objects
when new servers are created in your cloud infrastructure. The node controller obtains information about the
hosts running inside your tenancy with the cloud provider. The node controller performs the following functions:
-->
### 节点控制器 {#node-controller}
节点控制器负责在云基础设施中创建了新服务器时为之 更新
{{< glossary_tooltip text="节点（Node）" term_id="node" >}}对象。
节点控制器从云提供商获取当前租户中主机的信息。节点控制器执行以下功能：
<!--
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
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
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.
-->
1. 使用从云平台 API 获取的对应服务器的唯一标识符更新 Node 对象；
2. 利用特定云平台的信息为 Node 对象添加注解和标签，例如节点所在的
区域（Region）和所具有的资源（CPU、内存等等）；
3. 获取节点的网络地址和主机名；
4. 检查节点的健康状况。如果节点无响应，控制器通过云平台 API 查看该节点是否
已从云中禁用、删除或终止。如果节点已从云中删除，则控制器从 Kubernetes 集群
中删除 Node 对象。
<!--
Some cloud provider implementations split this into a node controller and a separate node
lifecycle controller.
-->
某些云驱动实现中，这些任务被划分到一个节点控制器和一个节点生命周期控制器中。
<!--
### Route controller
The route controller is responsible for configuring routes in the cloud
appropriately so that containers on different nodes in your Kubernetes
cluster can communicate with each other.
Depending on the cloud provider, the route controller might also allocate blocks
of IP addresses for the Pod network.
-->
### 路由控制器 {#route-controller}
Route 控制器负责适当地配置云平台中的路由，以便 Kubernetes 集群中不同节点上的
容器之间可以相互通信。
取决于云驱动本身，路由控制器可能也会为 Pod 网络分配 IP 地址块。
<!--
### Service controller
{{< glossary_tooltip text="Services" term_id="service" >}} integrate with cloud
infrastructure components such as managed load balancers, IP addresses, network
packet filtering, and target health checking. The service controller interacts with your
cloud provider's APIs to set up load balancers and other infrastructure components
when you declare a Service resource that requires them.
-->
### 服务控制器 {#service-controller}
{{< glossary_tooltip text="服务（Service）" term_id="service" >}}与受控的负载均衡器、
IP 地址、网络包过滤、目标健康检查等云基础设施组件集成。
服务控制器与云驱动的 API 交互，以配置负载均衡器和其他基础设施组件。
你所创建的 Service 资源会需要这些组件服务。
<!--
## Authorization
This section breaks down the access that the cloud controller manager requires
on various API objects, in order to perform its operations.
-->
## 鉴权 {#authorization}
本节分别讲述云控制器管理器为了完成自身工作而产生的对各类 API 对象的访问需求。
<!--
### Node controller {#authorization-node-controller}
The Node controller only works with Node objects. It requires full access
to read and modify Node objects.
-->
### 节点控制器 {#authorization-node-controller}
节点控制器只操作 Node 对象。它需要读取和修改 Node 对象的完全访问权限。
`v1/Node`:
- Get
- List
- Create
- Update
- Patch
- Watch
- Delete
<!--
### Route controller {#authorization-route-controller}
The route controller listens to Node object creation and configures
routes appropriately. It requires Get access to Node objects.
-->
### 路由控制器 {#authorization-route-controller}
路由控制器会监听 Node 对象的创建事件，并据此配置路由设施。
它需要读取 Node 对象的 Get 权限。
`v1/Node`:
- 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.
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.
-->
### 服务控制器 {#authorization-service-controller}
服务控制器监测 Service 对象的 Create、Update 和 Delete 事件，并配置
对应服务的 Endpoints 对象。
为了访问 Service 对象，它需要 List、Watch 访问权限；为了更新 Service 对象
它需要 Patch 和 Update 访问权限。
为了能够配置 Service 对应的 Endpoints 资源，它需要 Create、List、Get、Watch
和 Update 等访问权限。
`v1/Service`:
- 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.
`v1/Event`:
- Create
- Patch
- Update
`v1/ServiceAccount`:
- Create
The {{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRole for the cloud
controller manager looks like:
-->
### 其他 {#authorization-miscellaneous}
云控制器管理器的实现中，其核心部分需要创建 Event 对象的访问权限以及
创建 ServiceAccount 资源以保证操作安全性的权限。
`v1/Event`:
- Create
- Patch
- Update
`v1/ServiceAccount`:
- Create
用于云控制器管理器 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}
的 ClusterRole 如下例所示：
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cloud-controller-manager
rules:
- apiGroups:
- ""
resources:
- events
verbs:
- create
- patch
- update
- apiGroups:
- ""
resources:
- nodes
verbs:
- '*'
- apiGroups:
- ""
resources:
- nodes/status
verbs:
- patch
- apiGroups:
- ""
resources:
- services
verbs:
- list
- patch
- update
- watch
- apiGroups:
- ""
resources:
- serviceaccounts
verbs:
- create
- apiGroups:
- ""
resources:
- persistentvolumes
verbs:
- get
- list
- update
- watch
- apiGroups:
- ""
resources:
- endpoints
verbs:
- create
- get
- list
- watch
- update
```
## {{% heading "whatsnext" %}}
<!--
[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/).
Want to know how to implement your own cloud controller manager, or extend an existing project?
-->
[云控制器管理器的管理](/zh/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
给出了运行和管理云控制器管理器的指南。
要升级 HA 控制平面以使用云控制器管理器，请参见 [将复制的控制平面迁移以使用云控制器管理器](/zh/docs/tasks/administer-cluster/controller-manager-leader-migration/)
想要了解如何实现自己的云控制器管理器，或者对现有项目进行扩展么？
<!--
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).
-->
云控制器管理器使用 Go 语言的接口，从而使得针对各种云平台的具体实现都可以接入。
其中使用了在 [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)
项目中 [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.21/cloud.go#L42-L69)
文件所定义的 `CloudProvider` 接口。
<!--
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/).
-->
本文中列举的共享控制器（节点控制器、路由控制器和服务控制器等）的实现以及
其他一些生成具有 CloudProvider 接口的框架的代码，都是 Kubernetes 的核心代码。
特定于云驱动的实现虽不是 Kubernetes 核心成分，仍要实现 `CloudProvider` 接口。
关于如何开发插件的详细信息，可参考
[开发云控制器管理器](/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager/)
文档。
content/zh-cn/docs/concepts/architecture/control-plane-node-communication.md
+172
View File
@@ -0,0 +1,172 @@
---
title: 控制面到节点通信
content_type: concept
weight: 20
---
<!--
title: Control Plane-Node Communication
content_type: concept
weight: 20
aliases:
- master-node-communication
-->
<!-- overview -->
<!--
This document catalogs the communication paths between the control plane (apiserver) and the Kubernetes cluster. 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).
-->
本文列举控制面节点（确切说是 API 服务器）和 Kubernetes 集群之间的通信路径。
目的是为了让用户能够自定义他们的安装，以实现对网络配置的加固，使得集群能够在不可信的网络上
（或者在一个云服务商完全公开的 IP 上）运行。
<!-- body -->
<!--
## Node to Control Plane
Kubernetes has a "hub-and-spoke" API pattern. All API usage from nodes (or the pods they run) terminates at the apiserver. None of the other control plane components are designed to expose remote services. The apiserver is configured to listen for remote connections on a secure HTTPS port (typically 443) with one or more forms of client [authentication](/docs/reference/access-authn-authz/authentication/) enabled.
One or more forms of [authorization](/docs/reference/access-authn-authz/authorization/) should be enabled, especially if [anonymous requests](/docs/reference/access-authn-authz/authentication/#anonymous-requests) or [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) are allowed.
-->
## 节点到控制面
Kubernetes 采用的是中心辐射型（Hub-and-Spoke）API 模式。
所有从集群（或所运行的 Pods）发出的 API 调用都终止于 API 服务器。
其它控制面组件都没有被设计为可暴露远程服务。
API 服务器被配置为在一个安全的 HTTPS 端口（通常为 443）上监听远程连接请求，
并启用一种或多种形式的客户端[身份认证](/zh/docs/reference/access-authn-authz/authentication/)机制。
一种或多种客户端[鉴权机制](/zh/docs/reference/access-authn-authz/authorization/)应该被启用，
特别是在允许使用[匿名请求](/zh/docs/reference/access-authn-authz/authentication/#anonymous-requests)
或[服务账号令牌](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。
<!--
Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver 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.
-->
应该使用集群的公共根证书开通节点，这样它们就能够基于有效的客户端凭据安全地连接 API 服务器。
一种好的方法是以客户端证书的形式将客户端凭据提供给 kubelet。
请查看 [kubelet TLS 启动引导](/zh/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
以了解如何自动提供 kubelet 客户端证书。
<!--
Pods that wish to connect to the apiserver 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 apiserver.
The control plane components also communicate with the cluster apiserver over the secure port.
-->
想要连接到 API 服务器的 Pod 可以使用服务账号安全地进行连接。
当 Pod 被实例化时，Kubernetes 自动把公共根证书和一个有效的持有者令牌注入到 Pod 里。
`kubernetes` 服务（位于 `default` 名字空间中）配置了一个虚拟 IP 地址，用于（通过 kube-proxy）转发
请求到 API 服务器的 HTTPS 末端。
控制面组件也通过安全端口与集群的 API 服务器通信。
<!--
As a result, the default operating mode for connections from the nodes and pods running on the nodes to the control plane is secured by default and can run over untrusted and/or public networks.
-->
这样，从集群节点和节点上运行的 Pod 到控制面的连接的缺省操作模式即是安全的，
能够在不可信的网络或公网上运行。
<!--
## Control Plane to node
There are two primary communication paths from the control plane (apiserver) to the nodes. The first is from the apiserver to the kubelet process which runs on each node in the cluster. The second is from the apiserver to any node, pod, or service through the apiserver's proxy functionality.
-->
## 控制面到节点
从控制面（API 服务器）到节点有两种主要的通信路径。
第一种是从 API 服务器到集群中每个节点上运行的 kubelet 进程。
第二种是从 API 服务器通过它的代理功能连接到任何节点、Pod 或者服务。
<!--
### apiserver to kubelet
The connections from the apiserver to the kubelet are used for:
* Fetching logs for pods.
* Attaching (through kubectl) to running pods.
* Providing the kubelet's port-forwarding functionality.
These connections terminate at the kubelet's HTTPS endpoint. By default, the apiserver does not verify the kubelet's serving certificate, which makes the connection subject to man-in-the-middle attacks and **unsafe** to run over untrusted and/or public networks.
-->
### API 服务器到 kubelet
从 API 服务器到 kubelet 的连接用于：
* 获取 Pod 日志
* 挂接（通过 kubectl）到运行中的 Pod
* 提供 kubelet 的端口转发功能。
这些连接终止于 kubelet 的 HTTPS 末端。
默认情况下，API 服务器不检查 kubelet 的服务证书。这使得此类连接容易受到中间人攻击，
在非受信网络或公开网络上运行也是 **不安全的**。
<!--
To verify this connection, use the `--kubelet-certificate-authority` flag to provide the apiserver with a root certificate bundle to use to verify the kubelet's serving certificate.
If that is not possible, use [SSH tunneling](#ssh-tunnels) between the apiserver and kubelet if required to avoid connecting over an
untrusted or public network.
Finally, [Kubelet authentication and/or authorization](/docs/reference/access-authn-authz/kubelet-authn-authz/) should be enabled to secure the kubelet API.
-->
为了对这个连接进行认证，使用 `--kubelet-certificate-authority` 标志给 API
服务器提供一个根证书包，用于 kubelet 的服务证书。
如果无法实现这点，又要求避免在非受信网络或公共网络上进行连接，可在 API 服务器和
kubelet 之间使用 [SSH 隧道](#ssh-tunnels)。
最后，应该启用
[kubelet 用户认证和/或鉴权](/zh/docs/reference/access-authn-authz/kubelet-authn-authz/)
来保护 kubelet API。
<!--
### apiserver to nodes, pods, and services
The connections from the apiserver to a node, pod, or service default to plain HTTP connections and are therefore neither authenticated nor encrypted. They can be run over a secure HTTPS connection by prefixing `https:` to the node, pod, or service name in the API URL, but they will not validate the certificate provided by the HTTPS endpoint nor provide client credentials. So while the connection will be encrypted, it will not provide any guarantees of integrity. These connections **are not currently safe** to run over untrusted or public networks.
-->
### API 服务器到节点、Pod 和服务
从 API 服务器到节点、Pod 或服务的连接默认为纯 HTTP 方式，因此既没有认证，也没有加密。
这些连接可通过给 API URL 中的节点、Pod 或服务名称添加前缀 `https:` 来运行在安全的 HTTPS 连接上。
不过这些连接既不会验证 HTTPS 末端提供的证书，也不会提供客户端证书。
因此，虽然连接是加密的，仍无法提供任何完整性保证。
这些连接 **目前还不能安全地** 在非受信网络或公共网络上运行。
<!--
### SSH tunnels
Kubernetes supports SSH tunnels to protect the control plane to nodes communication paths. In this configuration, the apiserver 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.
This tunnel ensures that the traffic is not exposed outside of the network in which the nodes are running.
SSH tunnels are currently deprecated, so you shouldn't opt to use them unless you know what you are doing. The Konnectivity service is a replacement for this communication channel.
-->
### SSH 隧道 {#ssh-tunnels}
Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。在这种配置下，API
服务器建立一个到集群中各节点的 SSH 隧道（连接到在 22 端口监听的 SSH 服务）
并通过这个隧道传输所有到 kubelet、节点、Pod 或服务的请求。
这一隧道保证通信不会被暴露到集群节点所运行的网络之外。
SSH 隧道目前已被废弃。除非你了解个中细节，否则不应使用。
Konnectivity 服务是对此通信通道的替代品。
<!--
### Konnectivity service
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
As a replacement to the SSH tunnels, the Konnectivity service provides TCP level proxy for the control plane to cluster communication. The Konnectivity service consists of two parts: the Konnectivity server in the control plane network and the Konnectivity agents in the nodes network. The Konnectivity agents initiate connections to the Konnectivity server and maintain the network connections.
After enabling the Konnectivity service, all control plane to nodes traffic goes through these connections.
Follow the [Konnectivity service task](/docs/tasks/extend-kubernetes/setup-konnectivity/) to set up the Konnectivity service in your cluster.
-->
### Konnectivity 服务
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
作为 SSH 隧道的替代方案，Konnectivity 服务提供 TCP 层的代理，以便支持从控制面到集群的通信。
Konnectivity 服务包含两个部分：Konnectivity 服务器和 Konnectivity 代理，分别运行在
控制面网络和节点网络中。Konnectivity 代理建立并维持到 Konnectivity 服务器的网络连接。
启用 Konnectivity 服务之后，所有控制面到节点的通信都通过这些连接传输。
请浏览 [Konnectivity 服务任务](/zh/docs/tasks/extend-kubernetes/setup-konnectivity/)
在你的集群中配置 Konnectivity 服务。
content/zh-cn/docs/concepts/architecture/controller.md
+288
View File
@@ -0,0 +1,288 @@
---
title: 控制器
content_type: concept
weight: 30
---
<!-- overview -->
<!--
In robotics and automation, a _control loop_ is
a non-terminating loop that regulates the state of a system.
Here is one example of a control loop: a thermostat in a room.
When you set the temperature, that's telling the thermostat
about your *desired state*. The actual room temperature is the
*current state*. The thermostat acts to bring the current state
closer to the desired state, by turning equipment on or off.
-->
在机器人技术和自动化领域，控制回路（Control Loop）是一个非终止回路，用于调节系统状态。
这是一个控制环的例子：房间里的温度自动调节器。
当你设置了温度，告诉了温度自动调节器你的*期望状态（Desired State）*。
房间的实际温度是*当前状态（Current State）*。
通过对设备的开关控制，温度自动调节器让其当前状态接近期望状态。
{{< glossary_definition term_id="controller" length="short">}}
<!-- body -->
<!--
## Controller pattern
A controller tracks at least one Kubernetes resource type.
These [objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
have a spec field that represents the desired state. The
controller(s) for that resource are responsible for making the current
state come closer to that desired state.
The controller might carry the action out itself; more commonly, in Kubernetes,
a controller will send messages to the
{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} that have
useful side effects. You'll see examples of this below.
{{< comment >}}
Some built-in controllers, such as the namespace controller, act on objects
that do not have a spec. For simplicity, this page omits explaining that
detail.
{{< /comment >}}
-->
## 控制器模式 {#controller-pattern}
一个控制器至少追踪一种类型的 Kubernetes 资源。这些
[对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/)
有一个代表期望状态的 `spec` 字段。
该资源的控制器负责确保其当前状态接近期望状态。
控制器可能会自行执行操作；在 Kubernetes 中更常见的是一个控制器会发送信息给
{{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}，这会有副作用。
具体可参看后文的例子。
{{< comment >}}
一些内置的控制器，比如名字空间控制器，针对没有指定 `spec` 的对象。
为了简单起见，本文没有详细介绍这些细节。
{{< /comment >}}
<!--
### Control via API server
The {{< glossary_tooltip term_id="job" >}} controller is an example of a
Kubernetes built-in controller. Built-in controllers manage state by
interacting with the cluster API server.
Job is a Kubernetes resource that runs a
{{< glossary_tooltip term_id="pod" >}}, or perhaps several Pods, to carry out
a task and then stop.
(Once [scheduled](/docs/concepts/scheduling/), Pod objects become part of the
desired state for a kubelet).
When the Job controller sees a new task it makes sure that, somewhere
in your cluster, the kubelets on a set of Nodes are running the right
number of Pods to get the work done.
The Job controller does not run any Pods or containers
itself. Instead, the Job controller tells the API server to create or remove
Pods.
Other components in the
{{< glossary_tooltip text="control plane" term_id="control-plane" >}}
act on the new information (there are new Pods to schedule and run),
and eventually the work is done.
-->
### 通过 API 服务器来控制 {#control-via-API-server}
{{< glossary_tooltip text="Job" term_id="job" >}} 控制器是一个 Kubernetes 内置控制器的例子。
内置控制器通过和集群 API 服务器交互来管理状态。
Job 是一种 Kubernetes 资源，它运行一个或者多个 {{< glossary_tooltip term_id="pod" >}}，
来执行一个任务然后停止。
（一旦[被调度了](/zh/docs/concepts/scheduling-eviction/)，对 `kubelet` 来说 Pod
对象就会变成了期望状态的一部分）。
在集群中，当 Job 控制器拿到新任务时，它会保证一组 Node 节点上的 `kubelet`
可以运行正确数量的 Pod 来完成工作。
Job 控制器不会自己运行任何的 Pod 或者容器。Job 控制器是通知 API 服务器来创建或者移除 Pod。
{{< glossary_tooltip text="控制面" term_id="control-plane" >}}中的其它组件
根据新的消息作出反应（调度并运行新 Pod）并且最终完成工作。
<!--
After you create a new Job, the desired state is for that Job to be completed.
The Job controller makes the current state for that Job be nearer to your
desired state: creating Pods that do the work you wanted for that Job, so that
the Job is closer to completion.
Controllers also update the objects that configure them.
For example: once the work is done for a Job, the Job controller
updates that Job object to mark it `Finished`.
(This is a bit like how some thermostats turn a light off to
indicate that your room is now at the temperature you set).
-->
创建新 Job 后，所期望的状态就是完成这个 Job。Job 控制器会让 Job 的当前状态不断接近期望状态：创建为 Job 要完成工作所需要的 Pod，使 Job 的状态接近完成。
控制器也会更新配置对象。例如：一旦 Job 的工作完成了，Job 控制器会更新 Job 对象的状态为 `Finished`。
（这有点像温度自动调节器关闭了一个灯，以此来告诉你房间的温度现在到你设定的值了）。
<!--
### Direct control
By contrast with Job, some controllers need to make changes to
things outside of your cluster.
For example, if you use a control loop to make sure there
are enough {{< glossary_tooltip text="Nodes" term_id="node" >}}
in your cluster, then that controller needs something outside the
current cluster to set up new Nodes when needed.
Controllers that interact with external state find their desired state from
the API server, then communicate directly with an external system to bring
the current state closer in line.
(There actually is a [controller](https://github.com/kubernetes/autoscaler/)
that horizontally scales the nodes in your cluster.)
-->
### 直接控制 {#direct-control}
相比 Job 控制器，有些控制器需要对集群外的一些东西进行修改。
例如，如果你使用一个控制回路来保证集群中有足够的
{{< glossary_tooltip text="节点" term_id="node" >}}，那么控制器就需要当前集群外的
一些服务在需要时创建新节点。
和外部状态交互的控制器从 API 服务器获取到它想要的状态，然后直接和外部系统进行通信
并使当前状态更接近期望状态。
（实际上有一个[控制器](https://github.com/kubernetes/autoscaler/)
可以水平地扩展集群中的节点。）
<!--
The important point here is that the controller makes some change to bring about
your desired state, and then reports current state back to your cluster's API server.
Other control loops can observe that reported data and take their own actions.
-->
这里，很重要的一点是，控制器做出了一些变更以使得事物更接近你的期望状态，
之后将当前状态报告给集群的 API 服务器。
其他控制回路可以观测到所汇报的数据的这种变化并采取其各自的行动。
<!--
In the thermostat example, if the room is very cold then a different controller
might also turn on a frost protection heater. With Kubernetes clusters, the control
plane indirectly works with IP address management tools, storage services,
cloud provider APIs, and other services by
[extending Kubernetes](/docs/concepts/extend-kubernetes/) to implement that.
-->
在温度计的例子中，如果房间很冷，那么某个控制器可能还会启动一个防冻加热器。
就 Kubernetes 集群而言，控制面间接地与 IP 地址管理工具、存储服务、云驱动
APIs 以及其他服务协作，通过[扩展 Kubernetes](/zh/docs/concepts/extend-kubernetes/)
来实现这点。
<!--
## Desired versus current state {#desired-vs-current}
Kubernetes takes a cloud-native view of systems, and is able to handle
constant change.
Your cluster could be changing at any point as work happens and
control loops automatically fix failures. This means that,
potentially, your cluster never reaches a stable state.
As long as the controllers for your cluster are running and able to make
useful changes, it doesn't matter if the overall state is stable or not.
-->
## 期望状态与当前状态 {#desired-vs-current}
Kubernetes 采用了系统的云原生视图，并且可以处理持续的变化。
在任务执行时，集群随时都可能被修改，并且控制回路会自动修复故障。
这意味着很可能集群永远不会达到稳定状态。
只要集群中的控制器在运行并且进行有效的修改，整体状态的稳定与否是无关紧要的。
<!--
## Design
As a tenet of its design, Kubernetes uses lots of controllers that each manage
a particular aspect of cluster state. Most commonly, a particular control loop
(controller) uses one kind of resource as its desired state, and has a different
kind of resource that it manages to make that desired state happen.
It's useful to have simple controllers rather than one, monolithic set of control
loops that are interlinked. Controllers can fail, so Kubernetes is designed to
allow for that.
-->
## 设计 {#design}
作为设计原则之一，Kubernetes 使用了很多控制器，每个控制器管理集群状态的一个特定方面。
最常见的一个特定的控制器使用一种类型的资源作为它的期望状态，
控制器管理控制另外一种类型的资源向它的期望状态演化。
使用简单的控制器而不是一组相互连接的单体控制回路是很有用的。
控制器会失败，所以 Kubernetes 的设计正是考虑到了这一点。
<!--
There can be several controllers that create or update the same kind of object.
Behind the scenes, Kubernetes controllers make sure that they only pay attention
to the resources linked to their controlling resource.
For example, you can have Deployments and Jobs; these both create Pods.
The Job controller does not delete the Pods that your Deployment created,
because there is information ({{< glossary_tooltip term_id="label" text="labels" >}})
the controllers can use to tell those Pods apart.
-->
{{< note >}}
可以有多个控制器来创建或者更新相同类型的对象。
在后台，Kubernetes 控制器确保它们只关心与其控制资源相关联的资源。
例如，你可以创建 Deployment 和 Job；它们都可以创建 Pod。
Job 控制器不会删除 Deployment 所创建的 Pod，因为有信息
（{{< glossary_tooltip term_id="label" text="标签" >}}）让控制器可以区分这些 Pod。
{{< /note >}}
<!--
## Ways of running controllers {#running-controllers}
Kubernetes comes with a set of built-in controllers that run inside
the {{< glossary_tooltip term_id="kube-controller-manager" >}}. These
built-in controllers provide important core behaviors.
The Deployment controller and Job controller are examples of controllers that
come as part of Kubernetes itself (“built-in” controllers).
Kubernetes lets you run a resilient control plane, so that if any of the built-in
controllers were to fail, another part of the control plane will take over the work.
You can find controllers that run outside the control plane, to extend Kubernetes.
Or, if you want, you can write a new controller yourself.
You can run your own controller as a set of Pods,
or externally to Kubernetes. What fits best will depend on what that particular
controller does.
-->
## 运行控制器的方式 {#running-controllers}
Kubernetes 内置一组控制器，运行在 {{< glossary_tooltip term_id="kube-controller-manager" >}} 内。
这些内置的控制器提供了重要的核心功能。
Deployment 控制器和 Job 控制器是 Kubernetes 内置控制器的典型例子。
Kubernetes 允许你运行一个稳定的控制平面，这样即使某些内置控制器失败了，
控制平面的其他部分会接替它们的工作。
你会遇到某些控制器运行在控制面之外，用以扩展 Kubernetes。
或者，如果你愿意，你也可以自己编写新控制器。
你可以以一组 Pod 来运行你的控制器，或者运行在 Kubernetes 之外。
最合适的方案取决于控制器所要执行的功能是什么。
## {{% heading "whatsnext" %}}
<!--
* Read about the [Kubernetes control plane](/docs/concepts/overview/components/#control-plane-components)
* Discover some of the basic [Kubernetes objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
* Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/)
* If you want to write your own controller, see [Extension Patterns](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Extending Kubernetes.
-->
* 阅读 [Kubernetes 控制平面组件](/zh/docs/concepts/overview/components/#control-plane-components)
* 了解 [Kubernetes 对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/)
的一些基本知识
* 进一步学习 [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/)
* 如果你想编写自己的控制器，请看 Kubernetes 的
[扩展模式](/zh/docs/concepts/extend-kubernetes/#extension-patterns)。
content/zh-cn/docs/concepts/architecture/cri.md
+88
View File
@@ -0,0 +1,88 @@
---
title: 容器运行时接口（CRI）
content_type: concept
weight: 50
---
<!--
title: Container Runtime Interface (CRI)
content_type: concept
weight: 50
-->
<!-- overview -->
<!--
The CRI is a plugin interface which enables the kubelet to use a wide variety of
container runtimes, without having a need to recompile the cluster components.
You need a working
{{<glossary_tooltip text="container runtime" term_id="container-runtime">}} on
each Node in your cluster, so that the
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} can launch
{{< glossary_tooltip text="Pods" term_id="pod" >}} and their containers.
-->
CRI 是一个插件接口，它使 kubelet 能够使用各种容器运行时，无需重新编译集群组件。
你需要在集群中的每个节点上都有一个可以正常工作的
{{<glossary_tooltip text="容器运行时" term_id="container-runtime">}}，
这样
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} 能启动
{{< glossary_tooltip text="Pod" term_id="pod" >}} 及其容器。
{{< glossary_definition prepend="容器运行时接口（CRI）是" term_id="container-runtime-interface" length="all" >}}
<!-- body -->
<!-- ## The API {#api} -->
## API {#api}
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
<!--
The kubelet acts as a client when connecting to the container runtime via gRPC.
The runtime and image service endpoints have to be available in the container
runtime, which can be configured separately within the kubelet by using the
`--image-service-endpoint` and `--container-runtime-endpoint` [command line
flags](/docs/reference/command-line-tools-reference/kubelet)
-->
当通过 gRPC 连接到容器运行时时，kubelet 充当客户端。
运行时和镜像服务端点必须在容器运行时中可用，可以使用
[命令行标志](/zh/docs/reference/command-line-tools-reference/kubelet)的
`--image-service-endpoint` 和 `--container-runtime-endpoint`
在 kubelet 中单独配置。
<!--
For Kubernetes v{{< skew currentVersion >}}, the kubelet prefers to use CRI `v1`.
If a container runtime does not support `v1` of the CRI, then the kubelet tries to
negotiate any older supported version.
The v{{< skew currentVersion >}} kubelet can also negotiate CRI `v1alpha2`, but
this version is considered as deprecated.
If the kubelet cannot negotiate a supported CRI version, the kubelet gives up
and doesn't register as a node.
-->
对 Kubernetes v{{< skew currentVersion >}}，kubelet 偏向于使用 CRI `v1` 版本。
如果容器运行时不支持 CRI 的 `v1` 版本，那么 kubelet 会尝试协商任何旧的其他支持版本。
如果 kubelet 无法协商支持的 CRI 版本，则 kubelet 放弃并且不会注册为节点。
<!--
## Upgrading
When upgrading Kubernetes, then the kubelet tries to automatically select the
latest CRI version on restart of the component. If that fails, then the fallback
will take place as mentioned above. If a gRPC re-dial was required because the
container runtime has been upgraded, then the container runtime must also
support the initially selected version or the redial is expected to fail. This
requires a restart of the kubelet.
-->
## 升级 {#upgrading}
升级 Kubernetes 时，kubelet 会尝试在组件重启时自动选择最新的 CRI 版本。
如果失败，则将如上所述进行回退。如果由于容器运行时已升级而需要 gRPC 重拨，
则容器运行时还必须支持最初选择的版本，否则重拨预计会失败。
这需要重新启动 kubelet。
## {{% heading "whatsnext" %}}
<!--
- Learn more about the CRI [protocol definition](https://github.com/kubernetes/cri-api/blob/c75ef5b/pkg/apis/runtime/v1/api.proto)
-->
- 了解更多有关 CRI [协议定义](https://github.com/kubernetes/cri-api/blob/c75ef5b/pkg/apis/runtime/v1/api.proto)
content/zh-cn/docs/concepts/architecture/garbage-collection.md
+361
View File
@@ -0,0 +1,361 @@
---
title: 垃圾收集
content_type: concept
weight: 50
---
<!--
title: Garbage Collection
content_type: concept
weight: 50
-->
<!-- overview -->
<!--
{{<glossary_definition term_id="garbage-collection" length="short">}} This
allows the clean up of resources like the following:
-->
{{<glossary_definition term_id="garbage-collection" length="short">}}
垃圾收集允许系统清理如下资源：
<!--
* [Failed pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)
* [Completed Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/)
* [Objects without owner references](#owners-dependents)
* [Unused containers and container images](#containers-images)
* [Dynamically provisioned PersistentVolumes with a StorageClass reclaim policy of Delete](/docs/concepts/storage/persistent-volumes/#delete)
* [Stale or expired CertificateSigningRequests (CSRs)](/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
* {{<glossary_tooltip text="Nodes" term_id="node">}} deleted in the following scenarios:
* On a cloud when the cluster uses a [cloud controller manager](/docs/concepts/architecture/cloud-controller/)
* On-premises when the cluster uses an addon similar to a cloud controller
manager
* [Node Lease objects](/docs/concepts/architecture/nodes/#heartbeats)
-->
* [失败的 Pod](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)
* [已完成的 Job](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)
* [不再存在属主引用的对象](#owners-dependents)
* [未使用的容器和容器镜像](#containers-images)
* [动态制备的、StorageClass 回收策略为 Delete 的 PV 卷](/zh/docs/concepts/storage/persistent-volumes/#delete)
* [阻滞或者过期的 CertificateSigningRequest (CSRs)](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
* 在以下情形中删除了的{{<glossary_tooltip text="节点" term_id="node">}}对象：
* 当集群使用[云控制器管理器](/zh/docs/concepts/architecture/cloud-controller/)运行于云端时；
* 当集群使用类似于云控制器管理器的插件运行在本地环境中时。
* [节点租约对象](/zh/docs/concepts/architecture/nodes/#heartbeats)
<!--
## Owners and dependents {#owners-dependents}
Many objects in Kubernetes link to each other through [*owner references*](/docs/concepts/overview/working-with-objects/owners-dependents/).
Owner references tell the control plane which objects are dependent on others.
Kubernetes uses owner references to give the control plane, and other API
clients, the opportunity to clean up related resources before deleting an
object. In most cases, Kubernetes manages owner references automatically.
-->
## 属主与依赖 {#owners-dependents}
Kubernetes 中很多对象通过[*属主引用*](/zh/docs/concepts/overview/working-with-objects/owners-dependents/)
链接到彼此。属主引用（Owner Reference）可以告诉控制面哪些对象依赖于其他对象。
Kubernetes 使用属主引用来为控制面以及其他 API 客户端在删除某对象时提供一个
清理关联资源的机会。在大多数场合，Kubernetes 都是自动管理属主引用的。
<!--
Ownership is different from the [labels and selectors](/docs/concepts/overview/working-with-objects/labels/)
mechanism that some resources also use. For example, consider a
{{<glossary_tooltip text="Service" term_id="service">}} that creates
`EndpointSlice` objects. The Service uses *labels* to allow the control plane to
determine which `EndpointSlice` objects are used for that Service. In addition
to the labels, each `EndpointSlice` that is managed on behalf of a Service has
an owner reference. Owner references help different parts of Kubernetes avoid
interfering with objects they don’t control.
-->
属主关系与某些资源所使用的的[标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)
不同。例如，考虑一个创建 `EndpointSlice` 对象的 {{<glossary_tooltip text="Service" term_id="service">}}
对象。Service 对象使用*标签*来允许控制面确定哪些 `EndpointSlice` 对象被该
Service 使用。除了标签，每个被 Service 托管的 `EndpointSlice` 对象还有一个属主引用属性。
属主引用可以帮助 Kubernetes 中的不同组件避免干预并非由它们控制的对象。
{{< note >}}
<!--
Cross-namespace owner references are disallowed by design.
Namespaced dependents can specify cluster-scoped or namespaced owners.
A namespaced owner **must** exist in the same namespace as the dependent.
If it does not, the owner reference is treated as absent, and the dependent
is subject to deletion once all owners are verified absent.
-->
根据设计，系统不允许出现跨名字空间的属主引用。名字空间作用域的依赖对象可以指定集群作用域或者名字空间作用域的属主。
名字空间作用域的属主**必须**存在于依赖对象所在的同一名字空间。
如果属主位于不同名字空间，则属主引用被视为不存在，而当检查发现所有属主都已不存在时，
依赖对象会被删除。
<!--
Cluster-scoped dependents can only specify cluster-scoped owners.
In v1.20+, if a cluster-scoped dependent specifies a namespaced kind as an owner,
it is treated as having an unresolvable owner reference, and is not able to be garbage collected.
-->
集群作用域的依赖对象只能指定集群作用域的属主。
在 1.20 及更高版本中，如果一个集群作用域的依赖对象指定了某个名字空间作用域的类别作为其属主，
则该对象被视为拥有一个无法解析的属主引用，因而无法被垃圾收集处理。
<!--
In v1.20+, if the garbage collector detects an invalid cross-namespace `ownerReference`,
or a cluster-scoped dependent with an `ownerReference` referencing a namespaced kind, a warning Event
with a reason of `OwnerRefInvalidNamespace` and an `involvedObject` of the invalid dependent is reported.
You can check for that kind of Event by running
`kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`.
-->
在 1.20 及更高版本中，如果垃圾收集器检测到非法的跨名字空间 `ownerReference`，
或者某集群作用域的依赖对象的 `ownerReference` 引用某名字空间作用域的类别，
系统会生成一个警告事件，其原因为 `OwnerRefInvalidNamespace`，`involvedObject`
设置为非法的依赖对象。你可以通过运行
`kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`
来检查是否存在这类事件。
{{< /note >}}
<!--
## Cascading deletion {#cascading-deletion}
Kubernetes checks for and deletes objects that no longer have owner
references, like the pods left behind when you delete a ReplicaSet. When you
delete an object, you can control whether Kubernetes deletes the object's
dependents automatically, in a process called *cascading deletion*. There are
two types of cascading deletion, as follows:
* Foreground cascading deletion
* Background cascading deletion
-->
## 级联删除 {#cascading-deletion}
Kubernetes 会检查并删除那些不再拥有属主引用的对象，例如在你删除了 ReplicaSet
之后留下来的 Pod。当你删除某个对象时，你可以控制 Kubernetes 是否要通过一个称作
级联删除（Cascading Deletion）的过程自动删除该对象的依赖对象。
级联删除有两种类型，分别如下：
* 前台级联删除
* 后台级联删除
<!--
You can also control how and when garbage collection deletes resources that have
owner references using Kubernetes {{<glossary_tooltip text="finalizers" term_id="finalizer">}}.
-->
你也可以使用 Kubernetes {{<glossary_tooltip text="Finalizers" term_id="finalizer">}}
来控制垃圾收集机制如何以及何时删除包含属主引用的资源。
<!--
### Foreground cascading deletion {#foreground-deletion}
In foreground cascading deletion, the owner object you're deleting first enters
a *deletion in progress* state. In this state, the following happens to the
owner object:
-->
### 前台级联删除 {#foreground-deletion}
在前台级联删除中，正在被你删除的对象首先进入 *deletion in progress* 状态。
在这种状态下，针对属主对象会发生以下事情：
<!--
* The Kubernetes API server sets the object's `metadata.deletionTimestamp`
field to the time the object was marked for deletion.
* The Kubernetes API server also sets the `metadata.finalizers` field to
`foregroundDeletion`.
* The object remains visible through the Kubernetes API until the deletion
process is complete.
-->
* Kubernetes API 服务器将对象的 `metadata.deletionTimestamp`
字段设置为对象被标记为要删除的时间点。
* Kubernetes API 服务器也会将 `metadata.finalizers` 字段设置为 `foregroundDeletion`。
* 在删除过程完成之前，通过 Kubernetes API 仍然可以看到该对象。
<!--
After the owner object enters the deletion in progress state, the controller
deletes the dependents. After deleting all the dependent objects, the controller
deletes the owner object. At this point, the object is no longer visible in the
Kubernetes API.
During foreground cascading deletion, the only dependents that block owner
deletion are those that have the `ownerReference.blockOwnerDeletion=true` field.
See [Use foreground cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion)
to learn more.
-->
当属主对象进入删除过程中状态后，控制器删除其依赖对象。控制器在删除完所有依赖对象之后，
删除属主对象。这时，通过 Kubernetes API 就无法再看到该对象。
在前台级联删除过程中，唯一的可能阻止属主对象被删除的依赖对象是那些带有
`ownerReference.blockOwnerDeletion=true` 字段的对象。
参阅[使用前台级联删除](/zh/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion)
以了解进一步的细节。
<!--
### Background cascading deletion {#background-deletion}
In background cascading deletion, the Kubernetes API server deletes the owner
object immediately and the controller cleans up the dependent objects in
the background. By default, Kubernetes uses background cascading deletion unless
you manually use foreground deletion or choose to orphan the dependent objects.
See [Use background cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion)
to learn more.
-->
### 后台级联删除 {#background-deletion}
在后台级联删除过程中，Kubernetes 服务器立即删除属主对象，控制器在后台清理所有依赖对象。
默认情况下，Kubernetes 使用后台级联删除方案，除非你手动设置了要使用前台删除，
或者选择遗弃依赖对象。
参阅[使用后台级联删除](/zh/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion)
以了解进一步的细节。
<!--
### Orphaned dependents
When Kubernetes deletes an owner object, the dependents left behind are called
*orphan* objects. By default, Kubernetes deletes dependent objects. To learn how
to override this behaviour, see [Delete owner objects and orphan dependents](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy).
-->
### 被遗弃的依赖对象 {#orphaned-dependents}
当 Kubernetes 删除某个属主对象时，被留下来的依赖对象被称作被遗弃的（Orphaned）对象。
默认情况下，Kubernetes 会删除依赖对象。要了解如何重载这种默认行为，可参阅
[删除属主对象和遗弃依赖对象](/zh/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy)。
<!--
## Garbage collection of unused containers and images {#containers-images}
The {{<glossary_tooltip text="kubelet" term_id="kubelet">}} performs garbage
collection on unused images every five minutes and on unused containers every
minute. You should avoid using external garbage collection tools, as these can
break the kubelet behavior and remove containers that should exist.
-->
## 未使用容器和镜像的垃圾收集 {#containers-images}
{{<glossary_tooltip text="kubelet" term_id="kubelet">}} 会每五分钟对未使用的镜像执行一次垃圾收集，
每分钟对未使用的容器执行一次垃圾收集。
你应该避免使用外部的垃圾收集工具，因为外部工具可能会破坏 kubelet
的行为，移除应该保留的容器。
<!--
To configure options for unused container and image garbage collection, tune the
kubelet using a [configuration file](/docs/tasks/administer-cluster/kubelet-config-file/)
and change the parameters related to garbage collection using the
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
resource type.
-->
要配置对未使用容器和镜像的垃圾收集选项，可以使用一个
[配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/)，基于
[`KubeletConfiguration`](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
资源类型来调整与垃圾搜集相关的 kubelet 行为。
<!--
### Container image lifecycle
Kubernetes manages the lifecycle of all images through its *image manager*,
which is part of the kubelet, with the cooperation of
{{< glossary_tooltip text="cadvisor" term_id="cadvisor" >}}. The kubelet
considers the following disk usage limits when making garbage collection
decisions:
-->
### 容器镜像生命期 {#container-image-lifecycle}
Kubernetes 通过其镜像管理器（Image Manager）来管理所有镜像的生命周期，
该管理器是 kubelet 的一部分，工作时与
{{< glossary_tooltip text="cadvisor" term_id="cadvisor" >}} 协同。
kubelet 在作出垃圾收集决定时会考虑如下磁盘用量约束：
* `HighThresholdPercent`
* `LowThresholdPercent`
<!--
Disk usage above the configured `HighThresholdPercent` value triggers garbage
collection, which deletes images in order based on the last time they were used,
starting with the oldest first. The kubelet deletes images
until disk usage reaches the `LowThresholdPercent` value.
-->
磁盘用量超出所配置的 `HighThresholdPercent` 值时会触发垃圾收集，
垃圾收集器会基于镜像上次被使用的时间来按顺序删除它们，首先删除的是最老的镜像。
kubelet 会持续删除镜像，直到磁盘用量到达 `LowThresholdPercent` 值为止。
<!--
### Container garbage collection {#container-image-garbage-collection}
The kubelet garbage collects unused containers based on the following variables,
which you can define:
-->
### 容器垃圾收集 {#container-image-garbage-collection}
kubelet 会基于如下变量对所有未使用的容器执行垃圾收集操作，这些变量都是你可以定义的：
<!--
* `MinAge`: the minimum age at which the kubelet can garbage collect a
container. Disable by setting to `0`.
* `MaxPerPodContainer`: the maximum number of dead containers each Pod pair
can have. Disable by setting to less than `0`.
* `MaxContainers`: the maximum number of dead containers the cluster can have.
Disable by setting to less than `0`.
-->
* `MinAge`：kubelet 可以垃圾回收某个容器时该容器的最小年龄。设置为 `0`
表示禁止使用此规则。
* `MaxPerPodContainer`：每个 Pod 可以包含的已死亡的容器个数上限。设置为小于 `0`
的值表示禁止使用此规则。
* `MaxContainers`：集群中可以存在的已死亡的容器个数上限。设置为小于 `0`
的值意味着禁止应用此规则。
<!--
In addition to these variables, the kubelet garbage collects unidentified and
deleted containers, typically starting with the oldest first.
`MaxPerPodContainer` and `MaxContainer` may potentially conflict with each other
in situations where retaining the maximum number of containers per Pod
(`MaxPerPodContainer`) would go outside the allowable total of global dead
containers (`MaxContainers`). In this situation, the kubelet adjusts
`MaxPerPodContainer` to address the conflict. A worst-case scenario would be to
downgrade `MaxPerPodContainer` to `1` and evict the oldest containers.
Additionally, containers owned by pods that have been deleted are removed once
they are older than `MinAge`.
-->
除以上变量之外，kubelet 还会垃圾收集除无标识的以及已删除的容器，通常从最老的容器开始。
当保持每个 Pod 的最大数量的容器（`MaxPerPodContainer`）会使得全局的已死亡容器个数超出上限
（`MaxContainers`）时，`MaxPerPodContainer` 和 `MaxContainers` 之间可能会出现冲突。
在这种情况下，kubelet 会调整 `MaxPerPodContainer` 来解决这一冲突。
最坏的情形是将 `MaxPerPodContainer` 降格为 `1`，并驱逐最老的容器。
此外，当隶属于某已被删除的 Pod 的容器的年龄超过 `MinAge` 时，它们也会被删除。
{{<note>}}
<!--
The kubelet only garbage collects the containers it manages.
-->
kubelet 仅会回收由它所管理的容器。
{{</note>}}
<!--
## Configuring garbage collection {#configuring-gc}
You can tune garbage collection of resources by configuring options specific to
the controllers managing those resources. The following pages show you how to
configure garbage collection:
* [Configuring cascading deletion of Kubernetes objects](/docs/tasks/administer-cluster/use-cascading-deletion/)
* [Configuring cleanup of finished Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/)
-->
## 配置垃圾收集 {#configuring-gc}
你可以通过配置特定于管理资源的控制器来调整资源的垃圾收集行为。
下面的页面为你展示如何配置垃圾收集：
* [配置 Kubernetes 对象的级联删除](/zh/docs/tasks/administer-cluster/use-cascading-deletion/)
* [配置已完成 Job 的清理](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)
<!-- * [Configuring unused container and image garbage collection](/docs/tasks/administer-cluster/reconfigure-kubelet/) -->
## {{% heading "whatsnext" %}}
<!--
* Learn more about [ownership of Kubernetes objects](/docs/concepts/overview/working-with-objects/owners-dependents/).
* Learn more about Kubernetes [finalizers](/docs/concepts/overview/working-with-objects/finalizers/).
* Learn about the [TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) (beta) that cleans up finished Jobs.
-->
* 进一步了解 [Kubernetes 对象的属主关系](/zh/docs/concepts/overview/working-with-objects/owners-dependents/)。
* 进一步了解 Kubernetes [finalizers](/zh/docs/concepts/overview/working-with-objects/finalizers/)。
* 进一步了解 [TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/) (beta)，
该控制器负责清理已完成的 Job。
content/zh-cn/docs/concepts/architecture/nodes.md
+1183
View File
File diff suppressed because it is too large Load Diff