[zh] Sync changes from English site (4)
This commit is contained in:
Qiming Teng
parent
7a44e1a820
commit
2d8e136e6a
|
|
@ -97,7 +97,7 @@ API 通常用于托管的 Kubernetes 服务和受控的 Kubernetes 安装环境
|
|||
这些 API 是声明式的，与 Pod 这类其他 Kubernetes 资源遵从相同的约定，所以
|
||||
新的集群配置是可复用的，并且可以当作应用程序来管理。
|
||||
此外，对于稳定版本的 API 而言，它们与其他 Kubernetes API 一样，采纳的是
|
||||
一种[预定义的支持策略](/docs/reference/using-api/deprecation-policy/)。
|
||||
一种[预定义的支持策略](/zh/docs/reference/using-api/deprecation-policy/)。
|
||||
出于以上原因，在条件允许的情况下，基于 API 的方案应该优先于*配置文件*和*参数标志*。
|
||||
|
||||
<!--
|
||||
|
|
@ -195,12 +195,12 @@ This diagram shows the extension points in a Kubernetes system.
|
|||
|
||||
<!--
|
||||
1. Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies.
|
||||
2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](/docs/concepts/overview/extending#api-access-extensions) section.
|
||||
3. The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](/docs/concepts/overview/extending#user-defined-types) section. Custom Resources are often used with API Access Extensions.
|
||||
4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](/docs/concepts/overview/extending#scheduler-extensions) section.
|
||||
2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](#api-access-extensions) section.
|
||||
3. The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](#user-defined-types) section. Custom Resources are often used with API Access Extensions.
|
||||
4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](#scheduler-extensions) section.
|
||||
5. Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources.
|
||||
6. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](/docs/concepts/overview/extending#network-plugins) allow for different implementations of pod networking.
|
||||
7. The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](/docs/concepts/overview/extending#storage-plugins).
|
||||
6. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](#network-plugins) allow for different implementations of pod networking.
|
||||
7. The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](#storage-plugins).
|
||||
|
||||
If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions.
|
||||
-->
|
||||
|
|
@ -259,7 +259,7 @@ For more about Custom Resources, see the [Custom Resources concept guide](/docs/
|
|||
|
||||
不要使用自定义资源来充当应用、用户或者监控数据的数据存储。
|
||||
|
||||
关于自定义资源的更多信息，可参见[自定义资源概念指南](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
|
||||
关于自定义资源的更多信息，可参见[自定义资源概念指南](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
|
||||
|
||||
<!--
|
||||
### Combining New APIs with Automation
|
||||
|
|
@ -289,7 +289,7 @@ API 组中。你不可以替换或更改现有的 API 组。
|
|||
<!--
|
||||
### API Access Extensions
|
||||
|
||||
When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) for more on this flow.
|
||||
When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/) for more on this flow.
|
||||
|
||||
Each of these steps offers extension points.
|
||||
|
||||
|
|
@ -299,7 +299,7 @@ Kubernetes has several built-in authentication methods that it supports. It can
|
|||
|
||||
当请求到达 Kubernetes API 服务器时，首先要经过身份认证，之后是鉴权操作，
|
||||
再之后要经过若干类型的准入控制器的检查。
|
||||
参见[控制 Kubernetes API 访问](/zh/docs/reference/access-authn-authz/controlling-access/)
|
||||
参见[控制 Kubernetes API 访问](/zh/docs/concepts/security/controlling-access/)
|
||||
以了解此流程的细节。
|
||||
|
||||
这些步骤中都存在扩展点。
|
||||
|
|
@ -319,11 +319,11 @@ Kubernetes provides several built-in authentication methods, and an [Authenticat
|
|||
-->
|
||||
### 身份认证 {#authentication}
|
||||
|
||||
[身份认证](/docs/reference/access-authn-authz/authentication/)负责将所有请求中
|
||||
[身份认证](/zh/docs/reference/access-authn-authz/authentication/)负责将所有请求中
|
||||
的头部或证书映射到发出该请求的客户端的用户名。
|
||||
|
||||
Kubernetes 提供若干种内置的认证方法，以及
|
||||
[认证 Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
|
||||
[认证 Webhook](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
|
||||
方法以备内置方法无法满足你的要求。
|
||||
|
||||
<!--
|
||||
|
|
@ -443,7 +443,7 @@ the nodes chosen for a pod.
|
|||
* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
|
||||
* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
|
||||
-->
|
||||
* 进一步了解[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
* 进一步了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
* 了解[动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
* 进一步了解基础设施扩展
|
||||
* [网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
|
||||
|
|
|
|||
|
|
@ -28,16 +28,16 @@ methods for adding custom resources and how to choose between them.
|
|||
<!--
|
||||
## Custom resources
|
||||
|
||||
A *resource* is an endpoint in the [Kubernetes
|
||||
API](/docs/reference/using-api/api-overview/) that stores a collection of [API
|
||||
objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/) of
|
||||
A *resource* is an endpoint in the
|
||||
[Kubernetes API](/docs/concepts/overview/kubernetes-api/) that stores a collection of
|
||||
[API objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/) of
|
||||
a certain kind; for example, the built-in *pods* resource contains a
|
||||
collection of Pod objects.
|
||||
-->
|
||||
## 定制资源
|
||||
|
||||
*资源（Resource）* 是
|
||||
[Kubernetes API](/zh/docs/reference/using-api/api-overview/) 中的一个端点，
|
||||
[Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/) 中的一个端点，
|
||||
其中存储的是某个类别的
|
||||
[API 对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/)
|
||||
的一个集合。
|
||||
|
|
@ -177,16 +177,16 @@ Signs that your API might not be declarative include:
|
|||
命令式 API（Imperative API）与声明式有所不同。
|
||||
以下迹象表明你的 API 可能不是声明式的：
|
||||
|
||||
- 客户端发出“做这个操作”的指令，之后在该操作结束时获得同步响应。
|
||||
- 客户端发出“做这个操作”的指令，并获得一个操作 ID，之后需要检查一个 Operation（操作）
|
||||
对象来判断请求是否成功完成。
|
||||
- 你会将你的 API 类比为远程过程调用（Remote Procedure Call，RPCs）。
|
||||
- 直接存储大量数据；例如每个对象几 kB，或者存储上千个对象。
|
||||
- 需要较高的访问带宽（长期保持每秒数十个请求）。
|
||||
- 存储有应用来处理的最终用户数据（如图片、个人标识信息（PII）等）或者其他大规模数据。
|
||||
- 在对象上执行的常规操作并非 CRUD 风格。
|
||||
- API 不太容易用对象来建模。
|
||||
- 你决定使用操作 ID 或者操作对象来表现悬决的操作。
|
||||
- 客户端发出“做这个操作”的指令，之后在该操作结束时获得同步响应。
|
||||
- 客户端发出“做这个操作”的指令，并获得一个操作 ID，之后需要检查一个 Operation（操作）
|
||||
对象来判断请求是否成功完成。
|
||||
- 你会将你的 API 类比为远程过程调用（Remote Procedure Call，RPCs）。
|
||||
- 直接存储大量数据；例如每个对象几 kB，或者存储上千个对象。
|
||||
- 需要较高的访问带宽（长期保持每秒数十个请求）。
|
||||
- 存储有应用来处理的最终用户数据（如图片、个人标识信息（PII）等）或者其他大规模数据。
|
||||
- 在对象上执行的常规操作并非 CRUD 风格。
|
||||
- API 不太容易用对象来建模。
|
||||
- 你决定使用操作 ID 或者操作对象来表现悬决的操作。
|
||||
|
||||
<!--
|
||||
## Should I use a configMap or a custom resource?
|
||||
|
|
|
|||
|
|
@ -19,13 +19,19 @@ The targeted devices include GPUs, high-performance NICs, FPGAs, InfiniBand adap
|
|||
and other similar computing resources that may require vendor specific initialization
|
||||
and setup.
|
||||
-->
|
||||
Kubernetes 提供了一个[设备插件框架](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)，你可以用来将系统硬件资源发布到 {{< glossary_tooltip term_id="kubelet" >}}。
|
||||
Kubernetes 提供了一个
|
||||
[设备插件框架](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)，你可以用它来将系统硬件资源发布到 {{< glossary_tooltip term_id="kubelet" >}}。
|
||||
|
||||
供应商可以实现设备插件，由你手动部署或作为 {{< glossary_tooltip term_id="daemonset" >}} 来部署，而不必定制 Kubernetes 本身的代码。目标设备包括 GPU、高性能 NIC、FPGA、InfiniBand 适配器以及其他类似的、可能需要特定于供应商的初始化和设置的计算资源。
|
||||
供应商可以实现设备插件，由你手动部署或作为 {{< glossary_tooltip term_id="daemonset" >}}
|
||||
来部署，而不必定制 Kubernetes 本身的代码。目标设备包括 GPU、高性能 NIC、FPGA、
|
||||
InfiniBand 适配器以及其他类似的、可能需要特定于供应商的初始化和设置的计算资源。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 注册设备插件
|
||||
<!--
|
||||
## Device plugin registration
|
||||
-->
|
||||
## 注册设备插件 {#device-plugin-registration}
|
||||
|
||||
<!--
|
||||
The kubelet exports a `Registration` gRPC service:
|
||||
|
|
@ -45,7 +51,7 @@ During the registration, the device plugin needs to send:
|
|||
* The name of its Unix socket.
|
||||
* The Device Plugin API version against which it was built.
|
||||
* The `ResourceName` it wants to advertise. Here `ResourceName` needs to follow the
|
||||
[extended resource naming scheme](/docs/concepts/configuration/manage-resources-container/#extended-resources)
|
||||
[extended resource naming scheme](/docs/concepts/configuration/manage-resources-containers/#extended-resources)
|
||||
as `vendor-domain/resourcetype`.
|
||||
(For example, an NVIDIA GPU is advertised as `nvidia.com/gpu`.)
|
||||
|
||||
|
|
@ -54,7 +60,7 @@ list of devices it manages, and the kubelet is then in charge of advertising tho
|
|||
resources to the API server as part of the kubelet node status update.
|
||||
For example, after a device plugin registers `hardware-vendor.example/foo` with the kubelet
|
||||
and reports two healthy devices on a node, the node status is updated
|
||||
to advertise that the node has 2 “Foo” devices installed and available.
|
||||
to advertise that the node has 2 "Foo" devices installed and available.
|
||||
-->
|
||||
设备插件可以通过此 gRPC 服务在 kubelet 进行注册。在注册期间，设备插件需要发送下面几样内容：
|
||||
|
||||
|
|
@ -64,9 +70,12 @@ to advertise that the node has 2 “Foo” devices installed and available.
|
|||
[扩展资源命名方案](/zh/docs/concepts/configuration/manage-resources-containers/#extended-resources)，
|
||||
类似于 `vendor-domain/resourcetype`。（比如 NVIDIA GPU 就被公布为 `nvidia.com/gpu`。）
|
||||
|
||||
成功注册后，设备插件就向 kubelet 发送他所管理的设备列表，然后 kubelet 负责将这些资源发布到 API 服务器，作为 kubelet 节点状态更新的一部分。
|
||||
成功注册后，设备插件就向 kubelet 发送它所管理的设备列表，然后 kubelet
|
||||
负责将这些资源发布到 API 服务器，作为 kubelet 节点状态更新的一部分。
|
||||
|
||||
比如，设备插件在 kubelet 中注册了 `hardware-vendor.example/foo` 并报告了节点上的两个运行状况良好的设备后，节点状态将更新以通告该节点已安装2个 `Foo` 设备并且是可用的。
|
||||
比如，设备插件在 kubelet 中注册了 `hardware-vendor.example/foo` 并报告了
|
||||
节点上的两个运行状况良好的设备后，节点状态将更新以通告该节点已安装 2 个
|
||||
"Foo" 设备并且是可用的。
|
||||
|
||||
<!--
|
||||
Then, users can request devices in a
|
||||
|
|
@ -105,9 +114,9 @@ spec:
|
|||
hardware-vendor.example/foo: 2
|
||||
#
|
||||
# 这个 pod 需要两个 hardware-vendor.example/foo 设备
|
||||
# 而且只能够调度到满足需求的 node 上
|
||||
# 而且只能够调度到满足需求的节点上
|
||||
#
|
||||
# 如果该节点中有2个以上的设备可用，其余的可供其他 pod 使用
|
||||
# 如果该节点中有 2 个以上的设备可用，其余的可供其他 Pod 使用
|
||||
```
|
||||
|
||||
<!--
|
||||
|
|
@ -121,14 +130,16 @@ The general workflow of a device plugin includes the following steps:
|
|||
* The plugin starts a gRPC service, with a Unix socket under host path
|
||||
`/var/lib/kubelet/device-plugins/`, that implements the following interfaces:
|
||||
-->
|
||||
|
||||
## 设备插件的实现
|
||||
## 设备插件的实现 {#device-plugin-implementation}
|
||||
|
||||
设备插件的常规工作流程包括以下几个步骤：
|
||||
|
||||
* 初始化。在这个阶段，设备插件将执行供应商特定的初始化和设置，以确保设备处于就绪状态。
|
||||
* 插件使用主机路径 `/var/lib/kubelet/device-plugins/` 下的 Unix socket 启动一个 gRPC 服务，该服务实现以下接口：
|
||||
* 初始化。在这个阶段，设备插件将执行供应商特定的初始化和设置，
|
||||
以确保设备处于就绪状态。
|
||||
* 插件使用主机路径 `/var/lib/kubelet/device-plugins/` 下的 Unix 套接字启动
|
||||
一个 gRPC 服务，该服务实现以下接口：
|
||||
|
||||
<!--
|
||||
```gRPC
|
||||
service DevicePlugin {
|
||||
// ListAndWatch returns a stream of List of Devices
|
||||
|
|
@ -140,8 +151,58 @@ The general workflow of a device plugin includes the following steps:
|
|||
// Plugin can run device specific operations and instruct Kubelet
|
||||
// of the steps to make the Device available in the container
|
||||
rpc Allocate(AllocateRequest) returns (AllocateResponse) {}
|
||||
|
||||
// GetPreferredAllocation returns a preferred set of devices to allocate
|
||||
// from a list of available ones. The resulting preferred allocation is not
|
||||
// guaranteed to be the allocation ultimately performed by the
|
||||
// devicemanager. It is only designed to help the devicemanager make a more
|
||||
// informed allocation decision when possible.
|
||||
rpc GetPreferredAllocation(PreferredAllocationRequest) returns (PreferredAllocationResponse) {}
|
||||
|
||||
// PreStartContainer is called, if indicated by Device Plugin during registeration phase,
|
||||
// before each container start. Device plugin can run device specific operations
|
||||
// such as resetting the device before making devices available to the container.
|
||||
rpc PreStartContainer(PreStartContainerRequest) returns (PreStartContainerResponse) {}
|
||||
}
|
||||
```
|
||||
-->
|
||||
```gRPC
|
||||
service DevicePlugin {
|
||||
// ListAndWatch 返回 Device 列表构成的数据流。
|
||||
// 当 Device 状态发生变化或者 Device 消失时，ListAndWatch
|
||||
// 会返回新的列表。
|
||||
rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}
|
||||
|
||||
// Allocate 在容器创建期间调用，这样设备插件可以运行一些特定于设备的操作，
|
||||
// 并告诉 kubelet 如何令 Device 可在容器中访问的所需执行的具体步骤
|
||||
rpc Allocate(AllocateRequest) returns (AllocateResponse) {}
|
||||
|
||||
// GetPreferredAllocation 从一组可用的设备中返回一些优选的设备用来分配，
|
||||
// 所返回的优选分配结果不一定会是设备管理器的最终分配方案。
|
||||
// 此接口的设计仅是为了让设备管理器能够在可能的情况下做出更有意义的决定。
|
||||
rpc GetPreferredAllocation(PreferredAllocationRequest) returns (PreferredAllocationResponse) {}
|
||||
|
||||
// PreStartContainer 在设备插件注册阶段根据需要被调用，调用发生在容器启动之前。
|
||||
// 在将设备提供给容器使用之前，设备插件可以运行一些诸如重置设备之类的特定于
|
||||
// 具体设备的操作，
|
||||
rpc PreStartContainer(PreStartContainerRequest) returns (PreStartContainerResponse) {}
|
||||
}
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Plugins are not required to provide useful implementations for
|
||||
`GetPreferredAllocation()` or `PreStartContainer()`. Flags indicating which
|
||||
(if any) of these calls are available should be set in the `DevicePluginOptions`
|
||||
message sent back by a call to `GetDevicePluginOptions()`. The `kubelet` will
|
||||
always call `GetDevicePluginOptions()` to see which optional functions are
|
||||
available, before calling any of them directly.
|
||||
-->
|
||||
插件并非必须为 `GetPreferredAllocation()` 或 `PreStartContainer()` 提供有用
|
||||
的实现逻辑，调用 `GetDevicePluginOptions()` 时所返回的 `DevicePluginOptions`
|
||||
消息中应该设置这些调用是否可用。`kubelet` 在真正调用这些函数之前，总会调用
|
||||
`GetDevicePluginOptions()` 来查看是否存在这些可选的函数。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
* The plugin registers itself with the kubelet through the Unix socket at host
|
||||
|
|
@ -155,7 +216,8 @@ If the operations succeed, the device plugin returns an `AllocateResponse` that
|
|||
runtime configurations for accessing the allocated devices. The kubelet passes this information
|
||||
to the container runtime.
|
||||
-->
|
||||
* 插件通过 Unix socket 在主机路径 `/var/lib/kubelet/device-plugins/kubelet.sock` 处向 kubelet 注册自身。
|
||||
* 插件通过 Unix socket 在主机路径 `/var/lib/kubelet/device-plugins/kubelet.sock`
|
||||
处向 kubelet 注册自身。
|
||||
* 成功注册自身后，设备插件将以服务模式运行，在此期间，它将持续监控设备运行状况，
|
||||
并在设备状态发生任何变化时向 kubelet 报告。它还负责响应 `Allocate` gRPC 请求。
|
||||
在 `Allocate` 期间，设备插件可能还会做一些设备特定的准备；例如 GPU 清理或 QRNG 初始化。
|
||||
|
|
@ -174,8 +236,8 @@ of its Unix socket and re-register itself upon such an event.
|
|||
|
||||
设备插件应能监测到 kubelet 重启，并且向新的 kubelet 实例来重新注册自己。
|
||||
在当前实现中，当 kubelet 重启的时候，新的 kubelet 实例会删除 `/var/lib/kubelet/device-plugins`
|
||||
下所有已经存在的 Unix sockets。
|
||||
设备插件需要能够监控到它的 Unix socket 被删除，并且当发生此类事件时重新注册自己。
|
||||
下所有已经存在的 Unix 套接字。
|
||||
设备插件需要能够监控到它的 Unix 套接字被删除，并且当发生此类事件时重新注册自己。
|
||||
|
||||
<!--
|
||||
## Device plugin deployment
|
||||
|
|
@ -197,10 +259,11 @@ Pod onto Nodes, to restart the daemon Pod after failure, and to help automate up
|
|||
|
||||
你可以将你的设备插件作为节点操作系统的软件包来部署、作为 DaemonSet 来部署或者手动部署。
|
||||
|
||||
规范目录 `/var/lib/kubelet/device-plugins` 是需要特权访问的，所以设备插件必须要在被授权的安全的上下文中运行。
|
||||
规范目录 `/var/lib/kubelet/device-plugins` 是需要特权访问的，所以设备插件
|
||||
必须要在被授权的安全的上下文中运行。
|
||||
如果你将设备插件部署为 DaemonSet，`/var/lib/kubelet/device-plugins` 目录必须要在插件的
|
||||
[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
|
||||
中声明作为 {{< glossary_tooltip term_id="volume" >}} 被 mount 到插件中。
|
||||
中声明作为 {{< glossary_tooltip term_id="volume" >}} 被挂载到插件中。
|
||||
|
||||
如果你选择 DaemonSet 方法，你可以通过 Kubernetes 进行以下操作：
|
||||
将设备插件的 Pod 放置在节点上，在出现故障后重新启动守护进程 Pod，来进行自动升级。
|
||||
|
|
@ -296,11 +359,12 @@ gRPC 服务通过 `/var/lib/kubelet/pod-resources/kubelet.sock` 的 UNIX 套接
|
|||
|
||||
{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
|
||||
|
||||
The Topology Manager is a Kubelet component that allows resources to be co-ordintated in a Topology aligned manner. In order to do this, the Device Plugin API was extended to include a `TopologyInfo` struct.
|
||||
|
||||
The Topology Manager is a Kubelet component that allows resources to be co-ordinated in a Topology aligned manner. In order to do this, the Device Plugin API was extended to include a `TopologyInfo` struct.
|
||||
-->
|
||||
## 设备插件与拓扑管理器的集成
|
||||
|
||||
{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
拓扑管理器是 Kubelet 的一个组件，它允许以拓扑对齐方式来调度资源。
|
||||
为了做到这一点，设备插件 API 进行了扩展来包括一个 `TopologyInfo` 结构体。
|
||||
|
|
|
|||
|
|
@ -12,31 +12,28 @@ weight: 10
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state state="alpha" >}}
|
||||
<!--
|
||||
{{< caution >}}Alpha features can change rapidly. {{< /caution >}}
|
||||
-->
|
||||
{{< caution >}}Alpha 特性可能很快会变化。{{< /caution >}}
|
||||
|
||||
<!--
|
||||
Network plugins in Kubernetes come in a few flavors:
|
||||
|
||||
* CNI plugins: adhere to the appc/CNI specification, designed for interoperability.
|
||||
* CNI plugins: adhere to the [Container Network Interface](https://github.com/containernetworking/cni) (CNI) specification, designed for interoperability.
|
||||
* Kubernetes follows the [v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) release of the CNI specification.
|
||||
* Kubenet plugin: implements basic `cbr0` using the `bridge` and `host-local` CNI plugins
|
||||
-->
|
||||
Kubernetes中的网络插件有几种类型：
|
||||
|
||||
* CNI 插件： 遵守 appc/CNI 规约，为互操作性设计。
|
||||
* CNI 插件：遵守[容器网络接口（Container Network Interface，CNI）](https://github.com/containernetworking/cni)
|
||||
规范，其设计上偏重互操作性。
|
||||
* Kubernetes 遵从 CNI 规范的
|
||||
[v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md)
|
||||
版本。
|
||||
* Kubenet 插件：使用 `bridge` 和 `host-local` CNI 插件实现了基本的 `cbr0`。
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Installation
|
||||
|
||||
The kubelet has a single default network plugin, and a default network common to the entire cluster. It probes for plugins when it starts up, remembers what it finds, and executes the selected plugin at appropriate times in the pod lifecycle (this is only true for Docker, as rkt manages its own CNI plugins). There are two Kubelet command line parameters to keep in mind when using plugins:
|
||||
The kubelet has a single default network plugin, and a default network common to the entire cluster. It probes for plugins when it starts up, remembers what it finds, and executes the selected plugin at appropriate times in the pod lifecycle (this is only true for Docker, as CRI manages its own CNI plugins). There are two Kubelet command line parameters to keep in mind when using plugins:
|
||||
|
||||
* `cni-bin-dir`: Kubelet probes this directory for plugins on startup
|
||||
* `network-plugin`: The network plugin to use from `cni-bin-dir`. It must match the name reported by a plugin probed from the plugin directory. For CNI plugins, this is simply "cni".
|
||||
|
|
@ -44,11 +41,14 @@ The kubelet has a single default network plugin, and a default network common to
|
|||
## 安装
|
||||
|
||||
kubelet 有一个单独的默认网络插件，以及一个对整个集群通用的默认网络。
|
||||
它在启动时探测插件，记住找到的内容，并在 pod 生命周期的适当时间执行所选插件（这仅适用于 Docker，因为 rkt 管理自己的 CNI 插件）。
|
||||
在使用插件时，需要记住两个 Kubelet 命令行参数：
|
||||
它在启动时探测插件，记住找到的内容，并在 Pod 生命周期的适当时间执行
|
||||
所选插件（这仅适用于 Docker，因为 CRI 管理自己的 CNI 插件）。
|
||||
在使用插件时，需要记住两个 kubelet 命令行参数：
|
||||
|
||||
* `cni-bin-dir`： Kubelet 在启动时探测这个目录中的插件
|
||||
* `network-plugin`： 要使用的网络插件来自 `cni-bin-dir`。它必须与从插件目录探测到的插件报告的名称匹配。对于 CNI 插件，其值为 "cni"。
|
||||
* `cni-bin-dir`： kubelet 在启动时探测这个目录中的插件
|
||||
* `network-plugin`： 要使用的网络插件来自 `cni-bin-dir`。
|
||||
它必须与从插件目录探测到的插件报告的名称匹配。
|
||||
对于 CNI 插件，其值为 "cni"。
|
||||
|
||||
<!--
|
||||
## Network Plugin Requirements
|
||||
|
|
@ -59,12 +59,18 @@ By default if no kubelet network plugin is specified, the `noop` plugin is used,
|
|||
-->
|
||||
## 网络插件要求
|
||||
|
||||
除了提供[`NetworkPlugin` 接口](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go)来配置和清理 pod 网络之外，该插件还可能需要对 kube-proxy 的特定支持。
|
||||
除了提供
|
||||
[`NetworkPlugin` 接口](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go)
|
||||
来配置和清理 Pod 网络之外，该插件还可能需要对 kube-proxy 的特定支持。
|
||||
iptables 代理显然依赖于 iptables，插件可能需要确保 iptables 能够监控容器的网络通信。
|
||||
例如，如果插件将容器连接到 Linux 网桥，插件必须将 `net/bridge/bridge-nf-call-iptables` 系统参数设置为`1`，以确保 iptables 代理正常工作。
|
||||
如果插件不使用 Linux 网桥（而是类似于 Open vSwitch 或者其它一些机制），它应该确保为代理对容器通信执行正确的路由。
|
||||
例如，如果插件将容器连接到 Linux 网桥，插件必须将 `net/bridge/bridge-nf-call-iptables`
|
||||
系统参数设置为`1`，以确保 iptables 代理正常工作。
|
||||
如果插件不使用 Linux 网桥（而是类似于 Open vSwitch 或者其它一些机制），
|
||||
它应该确保为代理对容器通信执行正确的路由。
|
||||
|
||||
默认情况下，如果未指定 kubelet 网络插件，则使用 `noop` 插件，该插件设置 `net/bridge/bridge-nf-call-iptables=1`，以确保简单的配置（如带网桥的 Docker ）与 iptables 代理正常工作。
|
||||
默认情况下，如果未指定 kubelet 网络插件，则使用 `noop` 插件，
|
||||
该插件设置 `net/bridge/bridge-nf-call-iptables=1`，以确保简单的配置
|
||||
（如带网桥的 Docker ）与 iptables 代理正常工作。
|
||||
|
||||
<!--
|
||||
### CNI
|
||||
|
|
@ -77,13 +83,20 @@ In addition to the CNI plugin specified by the configuration file, Kubernetes re
|
|||
-->
|
||||
### CNI
|
||||
|
||||
通过给 Kubelet 传递 `--network-plugin=cni` 命令行选项来选择 CNI 插件。
|
||||
Kubelet 从 `--cni-conf-dir` （默认是 `/etc/cni/net.d`） 读取文件并使用该文件中的 CNI 配置来设置每个 pod 的网络。
|
||||
CNI 配置文件必须与 [CNI 规约](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration)匹配，并且配置引用的任何所需的 CNI 插件都必须存在于 `--cni-bin-dir`（默认是 `/opt/cni/bin`）。
|
||||
通过给 Kubelet 传递 `--network-plugin=cni` 命令行选项可以选择 CNI 插件。
|
||||
Kubelet 从 `--cni-conf-dir` （默认是 `/etc/cni/net.d`） 读取文件并使用
|
||||
该文件中的 CNI 配置来设置各个 Pod 的网络。
|
||||
CNI 配置文件必须与
|
||||
[CNI 规约](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration)
|
||||
匹配，并且配置所引用的所有所需的 CNI 插件都应存在于
|
||||
`--cni-bin-dir`（默认是 `/opt/cni/bin`）下。
|
||||
|
||||
如果这个目录中有多个 CNI 配置文件，kubelet 将会使用按文件名的字典顺序排列的第一个作为配置文件。
|
||||
如果这个目录中有多个 CNI 配置文件，kubelet 将会使用按文件名的字典顺序排列
|
||||
的第一个作为配置文件。
|
||||
|
||||
除了配置文件指定的 CNI 插件外，Kubernetes 还需要标准的 CNI [`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) 插件，最低版本是0.2.0。
|
||||
除了配置文件指定的 CNI 插件外，Kubernetes 还需要标准的 CNI
|
||||
[`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go)
|
||||
插件，最低版本是0.2.0。
|
||||
|
||||
<!--
|
||||
#### Support hostPort
|
||||
|
|
@ -96,8 +109,9 @@ For example:
|
|||
-->
|
||||
#### 支持 hostPort
|
||||
|
||||
CNI 网络插件支持 `hostPort`。 您可以使用官方 [portmap](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap)
|
||||
插件，它由 CNI 插件团队提供，或者使用您自己的带有 portMapping 功能的插件。
|
||||
CNI 网络插件支持 `hostPort`。 你可以使用官方
|
||||
[portmap](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap)
|
||||
插件，它由 CNI 插件团队提供，或者使用你自己的带有 portMapping 功能的插件。
|
||||
|
||||
如果你想要启动 `hostPort` 支持，则必须在 `cni-conf-dir` 指定 `portMappings capability`。
|
||||
例如：
|
||||
|
|
@ -147,11 +161,13 @@ If you want to enable traffic shaping support, you must add the `bandwidth` plug
|
|||
**实验功能**
|
||||
|
||||
CNI 网络插件还支持 pod 入口和出口流量整形。
|
||||
您可以使用 CNI 插件团队提供的 [bandwidth](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth) 插件，
|
||||
也可以使用您自己的具有带宽控制功能的插件。
|
||||
你可以使用 CNI 插件团队提供的
|
||||
[bandwidth](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth)
|
||||
插件，也可以使用你自己的具有带宽控制功能的插件。
|
||||
|
||||
如果您想要启用流量整形支持，你必须将 `bandwidth` 插件添加到 CNI 配置文件
|
||||
（默认是 `/etc/cni/net.d`）并保证该可执行文件包含在您的 CNI 的 bin 文件夹内 (默认为 `/opt/cni/bin`)。
|
||||
如果你想要启用流量整形支持，你必须将 `bandwidth` 插件添加到 CNI 配置文件
|
||||
（默认是 `/etc/cni/net.d`）并保证该可执行文件包含在你的 CNI 的 bin
|
||||
文件夹内 (默认为 `/opt/cni/bin`)。
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -185,8 +201,8 @@ CNI 网络插件还支持 pod 入口和出口流量整形。
|
|||
Now you can add the `kubernetes.io/ingress-bandwidth` and `kubernetes.io/egress-bandwidth` annotations to your pod.
|
||||
For example:
|
||||
-->
|
||||
现在，您可以将 `kubernetes.io/ingress-bandwidth` 和 `kubernetes.io/egress-bandwidth` 注解添加到 pod 中。
|
||||
例如：
|
||||
现在，你可以将 `kubernetes.io/ingress-bandwidth` 和 `kubernetes.io/egress-bandwidth`
|
||||
注解添加到 pod 中。例如：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
|
@ -210,7 +226,7 @@ The plugin requires a few things:
|
|||
* The standard CNI `bridge`, `lo` and `host-local` plugins are required, at minimum version 0.2.0. Kubenet will first search for them in `/opt/cni/bin`. Specify `cni-bin-dir` to supply additional search path. The first found match will take effect.
|
||||
* Kubelet must be run with the `--network-plugin=kubenet` argument to enable the plugin
|
||||
* Kubelet should also be run with the `--non-masquerade-cidr=<clusterCidr>` argument to ensure traffic to IPs outside this range will use IP masquerade.
|
||||
* The node must be assigned an IP subnet through either the `--pod-cidr` kubelet command-line option or the `--allocate-node-cidrs=true --cluster-cidr=<cidr>` controller-manager command-line options.
|
||||
* The node must be assigned an IP subnet through either the `--pod-cidr` kubelet command-line option or the `--allocate-node-cidrs=true -cluster-cidr=<cidr>` controller-manager command-line options.
|
||||
-->
|
||||
### kubenet
|
||||
|
||||
|
|
@ -218,16 +234,23 @@ Kubenet 是一个非常基本的、简单的网络插件，仅适用于 Linux。
|
|||
它本身并不实现更高级的功能，如跨节点网络或网络策略。
|
||||
它通常与云驱动一起使用，云驱动为节点间或单节点环境中的通信设置路由规则。
|
||||
|
||||
Kubenet 创建名为 `cbr0` 的网桥，并为每个 pod 创建了一个 veth 对，每个 pod 的主机端都连接到 `cbr0`。
|
||||
这个 veth 对的 pod 端会被分配一个 IP 地址，该 IP 地址隶属于节点所被分配的 IP 地址范围内。节点的 IP 地址范围则通过配置或控制器管理器来设置。
|
||||
Kubenet 创建名为 `cbr0` 的网桥，并为每个 pod 创建了一个 veth 对，
|
||||
每个 Pod 的主机端都连接到 `cbr0`。
|
||||
这个 veth 对的 Pod 端会被分配一个 IP 地址，该 IP 地址隶属于节点所被分配的 IP
|
||||
地址范围内。节点的 IP 地址范围则通过配置或控制器管理器来设置。
|
||||
`cbr0` 被分配一个 MTU，该 MTU 匹配主机上已启用的正常接口的最小 MTU。
|
||||
|
||||
使用此插件还需要一些其他条件：
|
||||
|
||||
* 需要标准的 CNI `bridge`、`lo` 以及 `host-local` 插件，最低版本是0.2.0。Kubenet 首先在 `/opt/cni/bin` 中搜索它们。 指定 `cni-bin-dir` 以提供其它的搜索路径。首次找到的匹配将生效。
|
||||
* 需要标准的 CNI `bridge`、`lo` 以及 `host-local` 插件，最低版本是0.2.0。
|
||||
kubenet 首先在 `/opt/cni/bin` 中搜索它们。 指定 `cni-bin-dir` 以提供
|
||||
其它搜索路径。首次找到的匹配将生效。
|
||||
* Kubelet 必须和 `--network-plugin=kubenet` 参数一起运行，才能启用该插件。
|
||||
* Kubelet 还应该和 `--non-masquerade-cidr=<clusterCidr>` 参数一起运行，以确保超出此范围的 IP 流量将使用 IP 伪装。
|
||||
* 节点必须被分配一个 IP 子网，通过kubelet 命令行的 `--pod-cidr` 选项或控制器管理器的命令行选项 `--allocate-node-cidrs=true --cluster-cidr=<cidr>` 来设置。
|
||||
* Kubelet 还应该和 `--non-masquerade-cidr=<clusterCidr>` 参数一起运行，
|
||||
以确保超出此范围的 IP 流量将使用 IP 伪装。
|
||||
* 节点必须被分配一个 IP 子网，通过kubelet 命令行的 `--pod-cidr` 选项或
|
||||
控制器管理器的命令行选项 `--allocate-node-cidrs=true --cluster-cidr=<cidr>`
|
||||
来设置。
|
||||
|
||||
<!--
|
||||
### Customizing the MTU (with kubenet)
|
||||
|
|
@ -249,11 +272,11 @@ This option is provided to the network-plugin; currently **only kubenet supports
|
|||
要获得最佳的网络性能，必须确保 MTU 的取值配置正确。
|
||||
网络插件通常会尝试推断出一个合理的 MTU，但有时候这个逻辑不会产生一个最优的 MTU。
|
||||
例如，如果 Docker 网桥或其他接口有一个小的 MTU, kubenet 当前将选择该 MTU。
|
||||
或者如果您正在使用 IPSEC 封装，则必须减少 MTU，并且这种计算超出了大多数网络插件的能力范围。
|
||||
或者如果你正在使用 IPSEC 封装，则必须减少 MTU，并且这种计算超出了大多数网络插件的能力范围。
|
||||
|
||||
如果需要，您可以使用 `network-plugin-mtu` kubelet 选项显式的指定 MTU。
|
||||
例如：在 AWS 上 `eth0` MTU 通常是 9001，因此您可以指定 `--network-plugin-mtu=9001`。
|
||||
如果您正在使用 IPSEC ，您可以减少它以允许封装开销，例如 `--network-plugin-mtu=8873`。
|
||||
如果需要，你可以使用 `network-plugin-mtu` kubelet 选项显式的指定 MTU。
|
||||
例如：在 AWS 上 `eth0` MTU 通常是 9001，因此你可以指定 `--network-plugin-mtu=9001`。
|
||||
如果你正在使用 IPSEC ，你可以减少它以允许封装开销，例如 `--network-plugin-mtu=8873`。
|
||||
|
||||
此选项会传递给网络插件； 当前 **仅 kubenet 支持 `network-plugin-mtu`**。
|
||||
|
||||
|
|
@ -264,14 +287,15 @@ This option is provided to the network-plugin; currently **only kubenet supports
|
|||
* `--network-plugin=kubenet` specifies that we use the `kubenet` network plugin with CNI `bridge` and `host-local` plugins placed in `/opt/cni/bin` or `cni-bin-dir`.
|
||||
* `--network-plugin-mtu=9001` specifies the MTU to use, currently only used by the `kubenet` network plugin.
|
||||
-->
|
||||
## 使用总结
|
||||
## 用法总结
|
||||
|
||||
* `--network-plugin=cni` 用来表明我们要使用 `cni` 网络插件，实际的 CNI 插件可执行文件位于 `--cni-bin-dir`（默认是 `/opt/cni/bin`）下， CNI 插件配置位于 `--cni-conf-dir`（默认是 `/etc/cni/net.d`）下。
|
||||
* `--network-plugin=kubenet` 用来表明我们要使用 `kubenet` 网络插件，CNI `bridge` 和 `host-local` 插件位于 `/opt/cni/bin` 或 `cni-bin-dir` 中。
|
||||
* `--network-plugin=cni` 用来表明我们要使用 `cni` 网络插件，实际的 CNI 插件
|
||||
可执行文件位于 `--cni-bin-dir`（默认是 `/opt/cni/bin`）下， CNI 插件配置位于
|
||||
`--cni-conf-dir`（默认是 `/etc/cni/net.d`）下。
|
||||
* `--network-plugin=kubenet` 用来表明我们要使用 `kubenet` 网络插件，CNI `bridge`
|
||||
和 `host-local` 插件位于 `/opt/cni/bin` 或 `cni-bin-dir` 中。
|
||||
* `--network-plugin-mtu=9001` 指定了我们使用的 MTU，当前仅被 `kubenet` 网络插件使用。
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@ content_type: concept
|
|||
weight: 10
|
||||
---
|
||||
<!--
|
||||
---
|
||||
title: Extending your Kubernetes Cluster
|
||||
reviewers:
|
||||
- erictune
|
||||
|
|
@ -13,7 +12,6 @@ reviewers:
|
|||
- chenopis
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -89,7 +87,7 @@ Flags and configuration files may not always be changeable in a hosted Kubernete
|
|||
它们是声明性的，并使用与其他 Kubernetes 资源（如 Pod ）相同的约定，所以新的集群配置可以重复使用，
|
||||
并以与应用程序相同的方式进行管理。
|
||||
而且，当它们变稳定后，也遵循和其他 Kubernetes API 一样的
|
||||
[支持政策](/docs/reference/using-api/deprecation-policy/)。
|
||||
[支持政策](/zh/docs/reference/using-api/deprecation-policy/)。
|
||||
出于这些原因，在合适的情况下它们优先于 *配置文件* 和 *标志* 被使用。
|
||||
|
||||
<!--
|
||||
|
|
@ -238,12 +236,13 @@ For more about Custom Resources, see the [Custom Resources concept guide](/docs/
|
|||
|
||||
### 用户自定义类型 {#user-defined-types}
|
||||
|
||||
如果你想定义新的控制器、应用程序配置对象或其他声明式 API，并使用 Kubernetes 工具（如 `kubectl`）管理它们，请考虑为 Kubernetes 添加一个自定义资源。
|
||||
如果你想定义新的控制器、应用程序配置对象或其他声明式 API，并使用 Kubernetes
|
||||
工具（如 `kubectl`）管理它们，请考虑为 Kubernetes 添加一个自定义资源。
|
||||
|
||||
不要使用自定义资源作为应用、用户或者监控数据的数据存储。
|
||||
|
||||
有关自定义资源的更多信息，请查看
|
||||
[自定义资源概念指南](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
|
||||
[自定义资源概念指南](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
|
||||
|
||||
<!--
|
||||
### Combining New APIs with Automation
|
||||
|
|
@ -272,7 +271,7 @@ Adding an API does not directly let you affect the behavior of existing APIs (e.
|
|||
<!--
|
||||
### API Access Extensions
|
||||
|
||||
When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) for more on this flow.
|
||||
When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/) for more on this flow.
|
||||
|
||||
Each of these steps offers extension points.
|
||||
|
||||
|
|
@ -282,13 +281,13 @@ Kubernetes has several built-in authentication methods that it supports. It can
|
|||
|
||||
当请求到达 Kubernetes API Server 时，它首先被要求进行用户认证，然后要进行授权检查，
|
||||
接着受到各种类型的准入控制的检查。有关此流程的更多信息，请参阅
|
||||
[Kubernetes API 访问控制](/zh/docs/reference/access-authn-authz/controlling-access/)。
|
||||
[Kubernetes API 访问控制](/zh/docs/concepts/security/controlling-access/)。
|
||||
|
||||
上述每个步骤都提供了扩展点。
|
||||
|
||||
Kubernetes 有几个它支持的内置认证方法。它还可以位于身份验证代理之后，并将 Authorziation 头部
|
||||
中的令牌发送给远程服务（webhook）进行验证。所有这些方法都在
|
||||
[身份验证文档](/docs/reference/access-authn-authz/authentication/)中介绍。
|
||||
[身份验证文档](/zh/docs/reference/access-authn-authz/authentication/)中介绍。
|
||||
|
||||
<!--
|
||||
### Authentication
|
||||
|
|
@ -299,11 +298,11 @@ Kubernetes provides several built-in authentication methods, and an [Authenticat
|
|||
-->
|
||||
### 身份认证 {#authentication}
|
||||
|
||||
[身份认证](/docs/reference/access-authn-authz/authentication/)
|
||||
[身份认证](/zh/docs/reference/access-authn-authz/authentication/)
|
||||
将所有请求中的头部字段或证书映射为发出请求的客户端的用户名。
|
||||
|
||||
Kubernetes 提供了几种内置的身份认证方法，如果这些方法不符合你的需求，可以使用
|
||||
[身份认证 Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 方法。
|
||||
[身份认证 Webhook](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 方法。
|
||||
|
||||
<!--
|
||||
### Authorization
|
||||
|
|
|
|||
|
|
@ -16,12 +16,13 @@ weight: 30
|
|||
Operators are software extensions to Kubernetes that make use of [custom
|
||||
resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
to manage applications and their components. Operators follow
|
||||
Kubernetes principles, notably the [control loop](/docs/concepts/#kubernetes-control-plane).
|
||||
Kubernetes principles, notably the [control loop](/docs/concepts/architecture/controller/).
|
||||
-->
|
||||
|
||||
Operator 是 Kubernetes 的扩展软件，它利用
|
||||
[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)管理应用及其组件。
|
||||
Operator 遵循 Kubernetes 的理念，特别是在[控制回路](/zh/docs/concepts/#kubernetes-control-plane)方面。
|
||||
Operator 遵循 Kubernetes 的理念，特别是在[控制回路](/zh/docs/concepts/architecture/controller/)
|
||||
方面。
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
|
@ -43,7 +44,8 @@ code to automate a task beyond what Kubernetes itself provides.
|
|||
Operator 模式旨在捕获（正在管理一个或一组服务的）运维人员的关键目标。
|
||||
负责特定应用和 service 的运维人员，在系统应该如何运行、如何部署以及出现问题时如何处理等方面有深入的了解。
|
||||
|
||||
在 Kubernetes 上运行工作负载的人们都喜欢通过自动化来处理重复的任务。Operator 模式会封装您编写的（Kubernetes 本身提供功能以外的）任务自动化代码。
|
||||
在 Kubernetes 上运行工作负载的人们都喜欢通过自动化来处理重复的任务。
|
||||
Operator 模式会封装你编写的（Kubernetes 本身提供功能以外的）任务自动化代码。
|
||||
|
||||
<!--
|
||||
## Operators in Kubernetes
|
||||
|
|
@ -57,14 +59,15 @@ Kubernetes' {{< glossary_tooltip text="controllers" term_id="controller" >}}
|
|||
concept lets you extend the cluster's behaviour without modifying the code
|
||||
of Kubernetes itself.
|
||||
Operators are clients of the Kubernetes API that act as controllers for
|
||||
a [Custom Resource](/docs/concepts/api-extension/custom-resources/).
|
||||
a [Custom Resource](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
|
||||
-->
|
||||
## Kubernetes 上的 Operator
|
||||
|
||||
Kubernetes 为自动化而生。无需任何修改，您即可以从 Kubernetes 核心中获得许多内置的自动化功能。
|
||||
您可以使用 Kubernetes 自动化部署和运行工作负载， *甚至* 可以自动化 Kubernetes 自身。
|
||||
Kubernetes 为自动化而生。无需任何修改，你即可以从 Kubernetes 核心中获得许多内置的自动化功能。
|
||||
你可以使用 Kubernetes 自动化部署和运行工作负载， *甚至* 可以自动化 Kubernetes 自身。
|
||||
|
||||
Kubernetes {{< glossary_tooltip text="控制器" term_id="controller" >}} 使您无需修改 Kubernetes 自身的代码，即可以扩展集群的行为。
|
||||
Kubernetes {{< glossary_tooltip text="控制器" term_id="controller" >}}
|
||||
使你无需修改 Kubernetes 自身的代码，即可以扩展集群的行为。
|
||||
Operator 是 Kubernetes API 的客户端，充当
|
||||
[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)的控制器。
|
||||
|
||||
|
|
@ -123,15 +126,21 @@ detail:
|
|||
|
||||
想要更详细的了解 Operator？这儿有一个详细的示例：
|
||||
|
||||
1. 有一个名为 SampleDB 的自定义资源，您可以将其配置到集群中。
|
||||
1. 有一个名为 SampleDB 的自定义资源，你可以将其配置到集群中。
|
||||
2. 一个包含 Operator 控制器部分的 Deployment，用来确保 Pod 处于运行状态。
|
||||
3. Operator 代码的容器镜像。
|
||||
4. 控制器代码，负责查询控制平面以找出已配置的 SampleDB 资源。
|
||||
5. Operator 的核心是告诉 API 服务器，如何使现实与代码里配置的资源匹配。
|
||||
* 如果添加新的 SampleDB，Operator 将设置 PersistentVolumeClaims 以提供持久化的数据库存储，设置 StatefulSet 以运行 SampleDB，并设置 Job 来处理初始配置。
|
||||
* 如果您删除它，Operator 将建立快照，然后确保 StatefulSet 和 Volume 已被删除。
|
||||
6. Operator 也可以管理常规数据库的备份。对于每个 SampleDB 资源，Operator 会确定何时创建（可以连接到数据库并进行备份的）Pod。这些 Pod 将依赖于 ConfigMap 和/或 具有数据库连接详细信息和凭据的 Secret。
|
||||
7. 由于 Operator 旨在为其管理的资源提供强大的自动化功能，因此它还需要一些额外的支持性代码。在这个示例中，代码将检查数据库是否正运行在旧版本上，如果是，则创建 Job 对象为您升级数据库。
|
||||
* 如果添加新的 SampleDB，Operator 将设置 PersistentVolumeClaims 以提供
|
||||
持久化的数据库存储，设置 StatefulSet 以运行 SampleDB，并设置 Job
|
||||
来处理初始配置。
|
||||
* 如果你删除它，Operator 将建立快照，然后确保 StatefulSet 和 Volume 已被删除。
|
||||
6. Operator 也可以管理常规数据库的备份。对于每个 SampleDB 资源，Operator
|
||||
会确定何时创建（可以连接到数据库并进行备份的）Pod。这些 Pod 将依赖于
|
||||
ConfigMap 和/或具有数据库连接详细信息和凭据的 Secret。
|
||||
7. 由于 Operator 旨在为其管理的资源提供强大的自动化功能，因此它还需要一些
|
||||
额外的支持性代码。在这个示例中，代码将检查数据库是否正运行在旧版本上，
|
||||
如果是，则创建 Job 对象为你升级数据库。
|
||||
|
||||
<!--
|
||||
## Deploying Operators
|
||||
|
|
@ -145,7 +154,10 @@ For example, you can run the controller in your cluster as a Deployment.
|
|||
-->
|
||||
## 部署 Operator
|
||||
|
||||
部署 Operator 最常见的方法是将自定义资源及其关联的控制器添加到您的集群中。跟运行容器化应用一样，Controller 通常会运行在 {{< glossary_tooltip text="控制平面" term_id="control-plane" >}} 之外。例如，您可以在集群中将控制器作为 Deployment 运行。
|
||||
部署 Operator 最常见的方法是将自定义资源及其关联的控制器添加到你的集群中。
|
||||
跟运行容器化应用一样，控制器通常会运行在
|
||||
{{< glossary_tooltip text="控制平面" term_id="control-plane" >}} 之外。
|
||||
例如，你可以在集群中将控制器作为 Deployment 运行。
|
||||
|
||||
<!--
|
||||
## Using an Operator {#using-operators}
|
||||
|
|
@ -160,10 +172,10 @@ kubectl get SampleDB # find configured databases
|
|||
kubectl edit SampleDB/example-database # manually change some settings
|
||||
```
|
||||
-->
|
||||
|
||||
## 使用 Operator {#using-operators}
|
||||
|
||||
部署 Operator 后，您可以对 Operator 所使用的资源执行添加、修改或删除操作。按照上面的示例，您将为 Operator 本身建立一个 Deployment，然后：
|
||||
部署 Operator 后，你可以对 Operator 所使用的资源执行添加、修改或删除操作。
|
||||
按照上面的示例，你将为 Operator 本身建立一个 Deployment，然后：
|
||||
|
||||
```shell
|
||||
kubectl get SampleDB # 查找所配置的数据库
|
||||
|
|
@ -176,8 +188,7 @@ kubectl edit SampleDB/example-database # 手动修改某些配置
|
|||
|
||||
## Writing your own Operator {#writing-operator}
|
||||
-->
|
||||
|
||||
可以了！Operator 会负责应用所作的更改并保持现有服务处于良好的状态
|
||||
可以了！Operator 会负责应用所作的更改并保持现有服务处于良好的状态。
|
||||
|
||||
## 编写你自己的 Operator {#writing-operator}
|
||||
|
||||
|
|
@ -191,9 +202,11 @@ You also implement an Operator (that is, a Controller) using any language / runt
|
|||
that can act as a [client for the Kubernetes API](/docs/reference/using-api/client-libraries/).
|
||||
-->
|
||||
|
||||
如果生态系统中没可以实现您目标的 Operator，您可以自己编写代码。在[接下来](#what-s-next)一节中，您会找到编写自己的云原生 Operator 需要的库和工具的链接。
|
||||
如果生态系统中没可以实现你目标的 Operator，你可以自己编写代码。在
|
||||
[接下来](#what-s-next)一节中，你会找到编写自己的云原生 Operator
|
||||
需要的库和工具的链接。
|
||||
|
||||
您还可以使用任何支持 [Kubernetes API 客户端](/zh/docs/reference/using-api/client-libraries/)
|
||||
你还可以使用任何支持 [Kubernetes API 客户端](/zh/docs/reference/using-api/client-libraries/)
|
||||
的语言或运行时来实现 Operator（即控制器）。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
|
@ -206,20 +219,20 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie
|
|||
* using [kubebuilder](https://book.kubebuilder.io/)
|
||||
* using [Metacontroller](https://metacontroller.app/) along with WebHooks that
|
||||
you implement yourself
|
||||
* using the [Operator Framework](https://github.com/operator-framework/getting-started)
|
||||
* using the [Operator Framework](https://operatorframework.io)
|
||||
* [Publish](https://operatorhub.io/) your operator for other people to use
|
||||
* Read [CoreOS' original article](https://coreos.com/blog/introducing-operators.html) that introduced the Operator pattern
|
||||
* Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators
|
||||
-->
|
||||
|
||||
* 详细了解[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
* 在 [OperatorHub.io](https://operatorhub.io/) 上找到现成的、适合您的 Operator
|
||||
* 借助已有的工具来编写您自己的 Operator，例如：
|
||||
* 在 [OperatorHub.io](https://operatorhub.io/) 上找到现成的、适合你的 Operator
|
||||
* 借助已有的工具来编写你自己的 Operator，例如：
|
||||
* [KUDO](https://kudo.dev/) (Kubernetes 通用声明式 Operator)
|
||||
* [kubebuilder](https://book.kubebuilder.io/)
|
||||
* [Metacontroller](https://metacontroller.app/)，可与 Webhook 结合使用，以实现自己的功能。
|
||||
* [Operator 框架](https://github.com/operator-framework/getting-started)
|
||||
* [发布](https://operatorhub.io/)您的 Operator，让别人也可以使用
|
||||
* [Operator Framework](https://operatorframework.io)
|
||||
* [发布](https://operatorhub.io/)你的 Operator，让别人也可以使用
|
||||
* 阅读 [CoreOS 原文](https://coreos.com/blog/introducing-operators.html)，其介绍了 Operator 介绍
|
||||
* 阅读这篇来自谷歌云的关于构建 Operator 最佳实践的
|
||||
[文章](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps)
|
||||
|
|
|
|||
|
|
@ -435,7 +435,7 @@ The following example describes how to map secret values into application enviro
|
|||
<!--
|
||||
* If you are familiar with {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}, [install Service Catalog using Helm](/docs/tasks/service-catalog/install-service-catalog-using-helm/) into your Kubernetes cluster. Alternatively, you can [install Service Catalog using the SC tool](/docs/tasks/service-catalog/install-service-catalog-using-sc/).
|
||||
* View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
|
||||
* Explore the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) project.
|
||||
* Explore the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) project.
|
||||
* View [svc-cat.io](https://svc-cat.io/docs/).
|
||||
-->
|
||||
* 如果你熟悉 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}，
|
||||
|
|
@ -443,7 +443,7 @@ The following example describes how to map secret values into application enviro
|
|||
到 Kubernetes 集群中。或者，你可以
|
||||
[使用 SC 工具安装服务目录](/zh/docs/tasks/service-catalog/install-service-catalog-using-sc/)。
|
||||
* 查看[服务代理示例](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers)
|
||||
* 浏览 [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 项目
|
||||
* 浏览 [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 项目
|
||||
* 查看 [svc-cat.io](https://svc-cat.io/docs/)
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue