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

Merge pull request #22994 from tengqm/zh-links-concepts-5

Browse Source 
[zh] Fix links in concepts section (5)
This commit is contained in:
Kubernetes Prow Robot
2020-08-09 19:22:19 -07:00
committed by GitHub
parent a8d831318c b4189b5800
commit da1eec647d
9 changed files with 485 additions and 370 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/concepts/architecture/control-plane-node-communication.md
+10 -19
View File
@@ -5,9 +5,6 @@ weight: 20
---
<!--
reviewers:
- dchen1107
- liggitt
title: Control Plane-Node Communication
content_type: concept
weight: 20
@@ -20,8 +17,7 @@ aliases:
<!--
This document catalogs the communication paths between the control plane (really the 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).
-->
本文对控制面节点（确切说是 apiserver）和 Kubernetes 集群之间的通信路径进行了分类。
本文列举控制面节点（确切说是 API 服务器）和 Kubernetes 集群之间的通信路径。
目的是为了让用户能够自定义他们的安装，以实现对网络配置的加固，使得集群能够在不可信的网络上
（或者在一个云服务商完全公开的 IP 上）运行。
@@ -31,24 +27,22 @@ This document catalogs the communication paths between the control plane (really
Kubernetes has a "hub-and-spoke" API pattern. All API usage from nodes (or the pods they run) terminate 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 调用都终止于 apiserver（其它控制面组件都没有被设计为可暴露远程服务）。
apiserver 被配置为在一个安全的 HTTPS 端口（443）上监听远程连接请求，
并启用一种或多种形式的客户端[身份认证](/docs/reference/access-authn-authz/authentication/)机制。
一种或多种客户端[鉴权机制](/docs/reference/access-authn-authz/authorization/)应该被启用，
特别是在允许使用[匿名请求](/docs/reference/access-authn-autha/authentication/#anonymous-requests)
或[服务账号令牌](/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。
并启用一种或多种形式的客户端[身份认证](/zh/docs/reference/access-authn-authz/authentication/)机制。
一种或多种客户端[鉴权机制](/zh/docs/reference/access-authn-authz/authorization/)应该被启用，
特别是在允许使用[匿名请求](/zh/docs/reference/access-authn-autha/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. For example, on a default GKE deployment, the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates.
-->
应该使用集群的公共根证书开通节点，这样它们就能够基于有效的客户端凭据安全地连接 apiserver。
例如：在一个默认的 GCE 部署中，客户端凭据以客户端证书的形式提供给 kubelet。
请查看 [kubelet TLS 启动引导](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
请查看 [kubelet TLS 启动引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
以了解如何自动提供 kubelet 客户端证书。
<!--
@@ -57,7 +51,6 @@ The `kubernetes` service (in all namespaces) is configured with a virtual IP add
The control plane components also communicate with the cluster apiserver over the secure port.
-->
想要连接到 apiserver 的 Pod 可以使用服务账号安全地进行连接。
当 Pod 被实例化时，Kubernetes 自动把公共根证书和一个有效的持有者令牌注入到 Pod 里。
`kubernetes` 服务（位于所有名字空间中）配置了一个虚拟 IP 地址，用于（通过 kube-proxy）转发
@@ -68,7 +61,6 @@ The control plane components also communicate with the cluster apiserver over th
<!--
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 到控制面的连接的缺省操作模式即是安全的，能够在不可信的网络或公网上运行。
<!--
@@ -76,7 +68,6 @@ As a result, the default operating mode for connections from the nodes and pods
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.
-->
## 控制面到节点
从控制面（apiserver）到节点有两种主要的通信路径。
@@ -94,8 +85,7 @@ The connections from the apiserver to the kubelet are used for:
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.
-->
### apiserver 到 kubelet
### API 服务器到 kubelet
从 apiserver 到 kubelet 的连接用于：
@@ -122,7 +112,8 @@ Finally, [Kubelet authentication and/or authorization](/docs/admin/kubelet-authe
如果无法实现这点，又要求避免在非受信网络或公共网络上进行连接，可在 apiserver 和
kubelet 之间使用 [SSH 隧道](#ssh-tunnels)。
最后，应该启用 [Kubelet 用户认证和/或鉴权](/docs/admin/kubelet-authentication-authorization/)来保护 kubelet API。
最后，应该启用 [Kubelet 用户认证和/或鉴权](/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
来保护 kubelet API。
<!--
### apiserver to nodes, pods, and services
@@ -177,5 +168,5 @@ Konnectivity 服务包含两个部分：Konnectivity 服务器和 Konnectivity
控制面网络和节点网络中。Konnectivity 代理建立并维持到 Konnectivity 服务器的网络连接。
启用 Konnectivity 服务之后，所有控制面到节点的通信都通过这些连接传输。
请浏览 [Konnectivity 服务任务](/docs/tasks/extend-kubernetes/setup-konnectivity/)
请浏览 [Konnectivity 服务任务](/zh/docs/tasks/extend-kubernetes/setup-konnectivity/)
在你的集群中配置 Konnectivity 服务。
content/zh/docs/concepts/architecture/controller.md
+61 -53
View File
@@ -16,18 +16,16 @@ 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
@@ -51,12 +49,18 @@ detail.
-->
## 控制器模式 {#controller-pattern}
一个控制器至少追踪一种类型的 Kubernetes 资源。这些[对象](/docs/concepts/overview/working-with-objects/kubernetes-objects/)有一个代表期望状态的指定字段。控制器负责确保其追踪的资源对象的当前状态接近期望状态。
一个控制器至少追踪一种类型的 Kubernetes 资源。这些
[对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/)
有一个代表期望状态的 `spec` 字段。
该资源的控制器负责确保其当前状态接近期望状态。
控制器可能会自行执行操作；在 Kubernetes 中更常见的是一个控制器会发送信息给 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}，这会有副作用。看下面这个例子。
控制器可能会自行执行操作；在 Kubernetes 中更常见的是一个控制器会发送信息给
{{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}，这会有副作用。
具体可参看后文的例子。
{{< comment >}}
一些内置的控制器，比如命名空间控制器，针对没有指定命名空间的对象。为了简单起见，这篇文章没有详细介绍这些细节。
一些内置的控制器，比如名字空间控制器，针对没有指定 `spec` 的对象。
为了简单起见，本文没有详细介绍这些细节。
{{< /comment >}}
<!--
@@ -87,15 +91,19 @@ and eventually the work is done.
### 通过 API 服务器来控制 {#control-via-API-server}
{{< glossary_tooltip term_id="job" >}} 控制器是一个 Kubernetes 内置控制器的例子。内置控制器通过和集群 API 服务器交互来管理状态。
{{< glossary_tooltip text="Job" term_id="job" >}} 控制器是一个 Kubernetes 内置控制器的例子。
内置控制器通过和集群 API 服务器交互来管理状态。
Job 是一种 Kubernetes 资源，它运行一个 {{< glossary_tooltip term_id="pod" >}}，或者可能是多个 Pod，来执行一个任务然后停止。
Job 是一种 Kubernetes 资源，它运行一个或者多个 {{< glossary_tooltip term_id="pod" >}}，
来执行一个任务然后停止。
（一旦[被调度了](/zh/docs/concepts/scheduling-eviction/)，对 `kubelet` 来说 Pod
对象就会变成了期望状态的一部分）。
（一旦[被调度了](/docs/concepts/scheduling/)），对 kubelet 来说 Pod 对象就会变成了期望状态的一部分。
在集群中，当 Job 控制器拿到新任务时，它会保证一组 Node 节点上的 kubelet 可以运行正确数量的 Pod 来完成工作。
在集群中，当 Job 控制器拿到新任务时，它会保证一组 Node 节点上的 `kubelet`
可以运行正确数量的 Pod 来完成工作。
Job 控制器不会自己运行任何的 Pod 或者容器。Job 控制器是通知 API 服务器来创建或者移除 Pod。
{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}中的其它组件根据新的消息而反应（调度新的 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.
@@ -110,7 +118,6 @@ 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`。
@@ -145,7 +152,8 @@ nodes in your cluster. See
和外部状态交互的控制器从 API 服务器获取到它想要的状态，然后直接和外部系统进行通信并使当前状态更接近期望状态。
（实际上有一个控制器可以水平地扩展集群中的节点。请看[集群自动扩缩容](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)）。
（实际上有一个控制器可以水平地扩展集群中的节点。请参阅
[集群自动扩缩容](/zh/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)）。
<!--
## Desired versus current state {#desired-vs-current}
@@ -160,12 +168,11 @@ 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 or is not stable.
-->
## 期望状态与当前状态 {#desired-vs-current}
Kubernetes 采用了系统的云原生视图，并且可以处理持续的变化。
在任务执行时，集群随时都可能被修改，并且控制环会自动的修复故障。这意味着很可能集群永远不会达到稳定状态。
在任务执行时，集群随时都可能被修改，并且控制回路会自动修复故障。这意味着很可能集群永远不会达到稳定状态。
只要集群中控制器的在运行并且进行有效的修改，整体状态的稳定与否是无关紧要的。
@@ -181,12 +188,17 @@ It's useful to have simple controllers rather than one, monolithic set of contro
loops that are interlinked. Controllers can fail, so Kubernetes is designed to
allow for that.
For example: a controller for Jobs tracks Job objects (to discover
new work) and Pod object (to run the Jobs, and then to see when the work is
finished). In this case something else creates the Jobs, whereas the Job
controller creates Pods.
-->
## 设计 {#design}
{{< note >}}
作为设计原则之一，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.
@@ -195,21 +207,14 @@ 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 >}}
-->
## 设计 {#design}
作为设计的一个原则，Kubernetes 使用了很多控制器，每个控制器管理集群状态的一个特定方面。最常见的一个特定的控制器使用一种类型的资源作为它的期望状态，控制器管理控制另外一种类型的资源向它的期望状态发展。
使用简单的控制器而不是一组相互连接的单体控制环是很有用的。控制器会失败，所以 Kubernetes 的设计是考虑到了这一点。
例如：为 Job 追踪 Job 对象（发现新工作）和 Pod 对象（运行 Job，并且等工作完成）的控制器。在本例中，其它东西创建作业，而作业控制器创建 Pod。
{{< note >}}
可以有多个控制器来创建或者更新相同类型的对象。在这之后，Kubernetes 控制器确保他们只关心和它们控制资源相关联的资源。
可以有多个控制器来创建或者更新相同类型的对象。
在后台，Kubernetes 控制器确保它们只关心与其控制资源相关联的资源。
例如，你可以有 Deployments 和 Jobs；它们都可以创建 Pod。Job 控制器不删除 Deployment 创建的 Pod，因为有信息({{< glossary_tooltip term_id="label" text="标签" >}})让控制器可以区分这些 Pod。
例如，你可以创建 Deployment 和 Job；它们都可以创建 Pod。
Job 控制器不会删除 Deployment 所创建的 Pod，因为有信息
（{{< glossary_tooltip term_id="label" text="标签" >}}）让控制器可以区分这些 Pod。
{{< /note >}}
<!--
@@ -229,27 +234,30 @@ 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/#kubernetes-control-plane)
* Discover some of the basic [Kubernetes objects](/docs/concepts/#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.
-->
## 运行控制器的方式 {#running-controllers}
Kubernetes 自带有一组内置的控制器，运行在 {{< glossary_tooltip term_id="kube-controller-manager" >}} 内。这些内置的控制器提供了重要的核心功能。
Deployment 控制器和 Job 控制器是 Kubernetes 内置控制器的典型例子。Kubernetes 运行一个弹性的控制平面，所以如果任意内置控制器失败了，控制平面的另外一部分会接替它的工作。
你会发现控制平面外面运行的控制器，扩展了 Kubernetes 的能力。或者，如果你愿意，你也可以写一个新控制器。你可以以一组 Pod 来运行你的控制器，或者运行在 Kubernetes 外面。什么是最合适的控制器，这将取决于特定控制器的功能。
## {{% heading "whatsnext" %}}
* 请阅读 [Kubernetes 控制平面](/docs/concepts/#kubernetes-control-plane)
* 了解一些基本的 [Kubernetes 对象](/docs/concepts/#kubernetes-objects)
* 学习更多的 [Kubernetes API](/docs/concepts/overview/kubernetes-api/)
* 如果你想写自己的控制器，请看 Kubernetes 的[扩展模式](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)。
* 阅读 [Kubernetes 控制面](/zh/docs/concepts/#kubernetes-control-plane)
* 了解 [Kubernetes 对象](/zh/docs/concepts/#kubernetes-objects) 的一些基本知识
* 进一步学习 [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/)
* 如果你想编写自己的控制器，请看 Kubernetes 的[扩展模式](/zh/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)。