From 2d8e136e6ae9958c7412aed00702ce29fb8db3f7 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Fri, 13 Nov 2020 11:03:25 +0800 Subject: [PATCH] [zh] Sync changes from English site (4) --- .../docs/concepts/extend-kubernetes/_index.md | 24 ++-- .../api-extension/custom-resources.md | 28 ++--- .../compute-storage-net/device-plugins.md | 104 ++++++++++++--- .../compute-storage-net/network-plugins.md | 118 +++++++++++------- .../extend-kubernetes/extend-cluster.md | 19 ++- .../concepts/extend-kubernetes/operator.md | 61 +++++---- .../extend-kubernetes/service-catalog.md | 4 +- 7 files changed, 229 insertions(+), 129 deletions(-) diff --git a/content/zh/docs/concepts/extend-kubernetes/_index.md b/content/zh/docs/concepts/extend-kubernetes/_index.md index ab475eee2d..9721e674cd 100644 --- a/content/zh/docs/concepts/extend-kubernetes/_index.md +++ b/content/zh/docs/concepts/extend-kubernetes/_index.md @@ -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 的方案应该优先于*配置文件*和*参数标志*。 @@ -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/)。 ### 身份认证 {#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) 方法以备内置方法无法满足你的要求。 -* 进一步了解[自定义资源](/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/) diff --git a/content/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index 3010597fee..a893ef8765 100644 --- a/content/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -28,16 +28,16 @@ methods for adding custom resources and how to choose between them. ## 定制资源 *资源（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 或者操作对象来表现悬决的操作。 -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 适配器以及其他类似的、可能需要特定于供应商的初始化和设置的计算资源。 -## 注册设备插件 + +## 注册设备插件 {#device-plugin-registration} 设备插件可以通过此 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" 设备并且是可用的。 - -## 设备插件的实现 +## 设备插件的实现 {#device-plugin-implementation} 设备插件的常规工作流程包括以下几个步骤： -* 初始化。在这个阶段，设备插件将执行供应商特定的初始化和设置，以确保设备处于就绪状态。 -* 插件使用主机路径 `/var/lib/kubelet/device-plugins/` 下的 Unix socket 启动一个 gRPC 服务，该服务实现以下接口： +* 初始化。在这个阶段，设备插件将执行供应商特定的初始化和设置， + 以确保设备处于就绪状态。 +* 插件使用主机路径 `/var/lib/kubelet/device-plugins/` 下的 Unix 套接字启动 + 一个 gRPC 服务，该服务实现以下接口： + + ```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 >}} + + 插件并非必须为 `GetPreferredAllocation()` 或 `PreStartContainer()` 提供有用 + 的实现逻辑，调用 `GetDevicePluginOptions()` 时所返回的 `DevicePluginOptions` + 消息中应该设置这些调用是否可用。`kubelet` 在真正调用这些函数之前，总会调用 + `GetDevicePluginOptions()` 来查看是否存在这些可选的函数。 + {{< /note >}} -* 插件通过 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 套接字被删除，并且当发生此类事件时重新注册自己。 ## 设备插件与拓扑管理器的集成 -{{< feature-state for_k8s_version="v1.17" state="alpha" >}} +{{< feature-state for_k8s_version="v1.18" state="beta" >}} 拓扑管理器是 Kubelet 的一个组件，它允许以拓扑对齐方式来调度资源。 为了做到这一点，设备插件 API 进行了扩展来包括一个 `TopologyInfo` 结构体。 diff --git a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md index 7ad8153077..dd19252f01 100644 --- a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md +++ b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md @@ -12,31 +12,28 @@ weight: 10 -{{< feature-state state="alpha" >}} - -{{< caution >}}Alpha 特性可能很快会变化。{{< /caution >}} - 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`。 - - ## 网络插件要求 -除了提供[`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 -通过给 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。 #### 支持 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=` 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=` 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=` 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=` 参数一起运行，以确保超出此范围的 IP 流量将使用 IP 伪装。 -* 节点必须被分配一个 IP 子网，通过kubelet 命令行的 `--pod-cidr` 选项或控制器管理器的命令行选项 `--allocate-node-cidrs=true --cluster-cidr=` 来设置。 +* Kubelet 还应该和 `--non-masquerade-cidr=` 参数一起运行， + 以确保超出此范围的 IP 流量将使用 IP 伪装。 +* 节点必须被分配一个 IP 子网，通过kubelet 命令行的 `--pod-cidr` 选项或 + 控制器管理器的命令行选项 `--allocate-node-cidrs=true --cluster-cidr=` + 来设置。 -## 使用总结 +## 用法总结 -* `--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" %}} diff --git a/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md b/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md index cb1ace4a9c..68b52333db 100644 --- a/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md @@ -4,7 +4,6 @@ content_type: concept weight: 10 --- @@ -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/)。 出于这些原因，在合适的情况下它们优先于 *配置文件* 和 *标志* 被使用。 ### 身份认证 {#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) 方法。 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/) +方面。 @@ -43,7 +44,8 @@ code to automate a task beyond what Kubernetes itself provides. Operator 模式旨在捕获（正在管理一个或一组服务的）运维人员的关键目标。 负责特定应用和 service 的运维人员，在系统应该如何运行、如何部署以及出现问题时如何处理等方面有深入的了解。 -在 Kubernetes 上运行工作负载的人们都喜欢通过自动化来处理重复的任务。Operator 模式会封装您编写的（Kubernetes 本身提供功能以外的）任务自动化代码。 +在 Kubernetes 上运行工作负载的人们都喜欢通过自动化来处理重复的任务。 +Operator 模式会封装你编写的（Kubernetes 本身提供功能以外的）任务自动化代码。 ## 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 对象为你升级数据库。 ## 部署 Operator -部署 Operator 最常见的方法是将自定义资源及其关联的控制器添加到您的集群中。跟运行容器化应用一样，Controller 通常会运行在 {{< glossary_tooltip text="控制平面" term_id="control-plane" >}} 之外。例如，您可以在集群中将控制器作为 Deployment 运行。 +部署 Operator 最常见的方法是将自定义资源及其关联的控制器添加到你的集群中。 +跟运行容器化应用一样，控制器通常会运行在 +{{< glossary_tooltip text="控制平面" term_id="control-plane" >}} 之外。 +例如，你可以在集群中将控制器作为 Deployment 运行。 - ## 使用 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) diff --git a/content/zh/docs/concepts/extend-kubernetes/service-catalog.md b/content/zh/docs/concepts/extend-kubernetes/service-catalog.md index 29b12f6bea..aa38076e44 100644 --- a/content/zh/docs/concepts/extend-kubernetes/service-catalog.md +++ b/content/zh/docs/concepts/extend-kubernetes/service-catalog.md @@ -435,7 +435,7 @@ The following example describes how to map secret values into application enviro * 如果你熟悉 {{< 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/)