Merge pull request #27666 from tengqm/zh-rm-old-files

[zh] Remove outdated files
pull/28093/head
Kubernetes Prow Robot 2021-05-09 01:52:47 -07:00 committed by GitHub
commit 8bec0c8954
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
13 changed files with 0 additions and 2510 deletions

View File

@ -1,434 +0,0 @@
---
title: 扩展 Kubernetes 集群
content_type: concept
weight: 10
---
<!--
title: Extending your Kubernetes Cluster
reviewers:
- erictune
- lavalamp
- cheftako
- chenopis
content_type: concept
weight: 10
-->
<!-- overview -->
<!--
Kubernetes is highly configurable and extensible. As a result,
there is rarely a need to fork or submit patches to the Kubernetes
project code.
This guide describes the options for customizing a Kubernetes cluster. It is
aimed at {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}}
who want to understand how to adapt their
Kubernetes cluster to the needs of their work environment. Developers who are prospective
{{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}}
or Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}}
will also find it useful as an introduction to what extension points and
patterns exist, and their trade-offs and limitations.
-->
Kubernetes 是高度可配置和可扩展的。因此,极少需要分发或提交补丁代码给 Kubernetes 项目。
本文档介绍自定义 Kubernetes 集群的选项。本文档的目标读者包括希望了解如何使
Kubernetes 集群满足其业务环境需求的
{{< glossary_tooltip text="集群运维人员" term_id="cluster-operator" >}}、
Kubernetes 项目的{{< glossary_tooltip text="贡献者" term_id="contributor" >}}。
或潜在的{{< glossary_tooltip text="平台开发人员" term_id="platform-developer" >}}
也可以从本文找到有用的信息,如对已存在扩展点和模式的介绍,以及它们的权衡和限制。
<!-- body -->
<!--
## Overview
Customization approaches can be broadly divided into *configuration*, which only involves changing flags, local configuration files, or API resources; and *extensions*, which involve running additional programs or services. This document is primarily about extensions.
-->
## 概述
定制方法可以大致分为 *配置Configuration**扩展Extension*
*配置* 只涉及更改标志参数、本地配置文件或 API 资源;
*扩展* 涉及运行额外的程序或服务。本文档主要内容是关于扩展。
<!--
## Configuration
*Configuration files* and *flags* are documented in the Reference section of the online documentation, under each binary:
* [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/).
-->
## 配置 {#configuration}
关于 *配置文件**标志* 的说明文档位于在线文档的"参考"部分,按照可执行文件组织:
* [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/)
* [kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)
* [kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/)
* [kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/).
<!--
Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options.
-->
在托管的 Kubernetes 服务或受控安装的 Kubernetes 版本中,标志和配置文件可能并不总是可以更改的。而且当它们可以进行更改时,它们通常只能由集群管理员进行更改。此外,标志和配置文件在未来的 Kubernetes 版本中可能会发生变化,并且更改设置后它们可能需要重新启动进程。出于这些原因,只有在没有其他选择的情况下才使用它们。
<!--
*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/using-api/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable.
-->
*内置策略 API* ,例如 [ResourceQuota](/zh/docs/concepts/policy/resource-quotas/)、
[PodSecurityPolicy](/zh/docs/concepts/policy/pod-security-policy/)、
[NetworkPolicy](/zh/docs/concepts/services-networking/network-policies/)
和基于角色的权限控制 ([RBAC](/zh/docs/reference/access-authn-authz/rbac/))
是内置的 Kubernetes API。API 通常与托管的 Kubernetes 服务和受控的 Kubernetes 安装一起使用。
它们是声明性的,并使用与其他 Kubernetes 资源(如 Pod )相同的约定,所以新的集群配置可以重复使用,
并以与应用程序相同的方式进行管理。
而且,当它们变稳定后,也遵循和其他 Kubernetes API 一样的
[支持政策](/zh/docs/reference/using-api/deprecation-policy/)。
出于这些原因,在合适的情况下它们优先于 *配置文件**标志* 被使用。
<!--
## Extensions
Extensions are software components that extend and deeply integrate with Kubernetes.
They adapt it to support new types and new kinds of hardware.
Most cluster administrators will use a hosted or distribution
instance of Kubernetes. As a result, most Kubernetes users will not need to
install extensions and fewer will need to author new ones.
-->
## 扩展程序 {#extension}
扩展程序是指对 Kubernetes 进行扩展和深度集成的软件组件。它们适合用于支持新的类型和新型硬件。
大多数集群管理员会使用托管的或统一分发的 Kubernetes 实例。
因此,大多数 Kubernetes 用户不需要安装扩展程序,而且还有少部分用户甚至需要编写新的扩展程序。
<!--
## Extension Patterns
-->
## 扩展模式 {#extension-patterns}
<!--
Kubernetes is designed to be automated by writing client programs. Any
program that reads and/or writes to the Kubernetes API can provide useful
automation. *Automation* can run on the cluster or off it. By following
the guidance in this doc you can write highly available and robust automation.
Automation generally works with any Kubernetes cluster, including hosted
clusters and managed installations.
-->
Kubernetes 的设计是通过编写客户端程序来实现自动化的。
任何读和(或)写 Kubernetes API 的程序都可以提供有用的自动化工作。
*自动化* 程序可以运行在集群之中或之外。按照本文档的指导,你可以编写出高可用的和健壮的自动化程序。
自动化程序通常适用于任何 Kubernetes 集群,包括托管集群和受管理安装的集群。
<!--
There is a specific pattern for writing client programs that work well with
Kubernetes called the *Controller* pattern. Controllers typically read an
object's `.spec`, possibly do things, and then update the object's `.status`.
A controller is a client of Kubernetes. When Kubernetes is the client and
calls out to a remote service, it is called a *Webhook*. The remote service
is called a *Webhook Backend*. Like Controllers, Webhooks do add a point of
failure.
-->
*控制器Controller* 模式是编写适合 Kubernetes 的客户端程序的一种特定模式。
控制器通常读取一个对象的 `.spec` 字段,可能做出一些处理,然后更新对象的 `.status` 字段。
一个控制器是 Kubernetes 的一个客户端。
当 Kubernetes 作为客户端调用远程服务时,它被称为 *Webhook*
远程服务称为 *Webhook* 后端。 和控制器类似Webhooks 增加了一个失败点。
<!--
In the webhook model, Kubernetes makes a network request to a remote service.
In the *Binary Plugin* model, Kubernetes executes a binary (program).
Binary plugins are used by the kubelet (e.g.
[Flex Volume Plugins](/docs/concepts/storage/volumes/#flexvolume)
and [Network Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))
and by kubectl.
-->
在 webhook 模型里Kubernetes 向远程服务发送一个网络请求。
*可执行文件插件* 模型里Kubernetes 执行一个可执行文件(程序)。
可执行文件插件被 kubelet
[Flex 卷插件](/zh/docs/concepts/storage/volumes/#flexvolume)
和[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
`kubectl` 所使用。
<!--
Below is a diagram showing how the extension points interact with the
Kubernetes control plane.
-->
下图显示了扩展点如何与 Kubernetes 控制平面进行交互。
<img src="https://docs.google.com/drawings/d/e/2PACX-1vQBRWyXLVUlQPlp7BvxvV9S1mxyXSM6rAc_cbLANvKlu6kCCf-kGTporTMIeG5GZtUdxXz1xowN7RmL/pub?w=960&h=720">
<!-- image source drawing https://docs.google.com/drawings/d/1muJ7Oxuj_7Gtv7HV9-2zJbOnkQJnjxq-v1ym_kZfB-4/edit?ts=5a01e054 -->
<!--
## Extension Points
This diagram shows the extension points in a Kubernetes system.
<img src="https://docs.google.com/drawings/d/e/2PACX-1vSH5ZWUO2jH9f34YHenhnCd14baEb4vT-pzfxeFC7NzdNqRDgdz4DDAVqArtH4onOGqh0bhwMX0zGBb/pub?w=425&h=809">
-->
## 扩展点 {#extension-points}
下图显示了 Kubernetes 系统的扩展点。
<img src="https://docs.google.com/drawings/d/e/2PACX-1vSH5ZWUO2jH9f34YHenhnCd14baEb4vT-pzfxeFC7NzdNqRDgdz4DDAVqArtH4onOGqh0bhwMX0zGBb/pub?w=425&h=809">
<!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
<!--
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/extend-kubernetes/#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/extend-kubernetes/#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/extend-kubernetes/#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/extend-kubernetes/#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/extend-kubernetes/#storage-plugins).
-->
1. 用户通常使用 `kubectl` 与 Kubernetes API 进行交互。
[kubectl 插件](/zh/docs/tasks/extend-kubectl/kubectl-plugins/)扩展了 kubectl 可执行文件。
它们只影响个人用户的本地环境,因此不能执行站点范围的策略。
2. API 服务器处理所有请求。API 服务器中的几种类型的扩展点允许对请求进行身份认证或根据其内容对其进行阻止、
编辑内容以及处理删除操作。这些内容在
[API 访问扩展](/zh/docs/concepts/extend-kubernetes/#api-access-extensions)小节中描述。
3. API 服务器提供各种 *资源Resource**内置的资源种类Resource Kinds* ,如 `pods`
由 Kubernetes 项目定义,不能更改。你还可以添加你自己定义的资源或其他项目已定义的资源,
称为 *自定义资源Custom Resource*,如[自定义资源](/zh/docs/concepts/extend-kubernetes/#user-defined-types)
部分所述。自定义资源通常与 API 访问扩展一起使用。
4. Kubernetes 调度器决定将 Pod 放置到哪个节点。有几种方法可以扩展调度器。
这些内容在[调度器扩展](/zh/docs/concepts/extend-kubernetes/#scheduler-extensions)
小节中描述。
5. Kubernetes 的大部分行为都是由称为控制器Controllers的程序实现的这些程序是 API 服务器的客户端。
控制器通常与自定义资源一起使用。
6. `kubelet` 在主机上运行,并帮助 Pod 看起来就像在集群网络上拥有自己的 IP 的虚拟服务器。
[网络插件](/zh/docs/concepts/extend-kubernetes/#network-plugins)让你可以实现不同的 pod 网络。
7. `kubelet` 也负责为容器挂载和卸载卷。新的存储类型可以通过
[存储插件](/zh/docs/concepts/extend-kubernetes/#storage-plugins)支持。
<!--
If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions.
-->
如果你不确定从哪里开始扩展,下面流程图可以提供一些帮助。请注意,某些解决方案可能涉及多种类型的扩展。
<img src="https://docs.google.com/drawings/d/e/2PACX-1vRWXNNIVWFDqzDY0CsKZJY3AR8sDeFDXItdc5awYxVH8s0OLherMlEPVUpxPIB1CSUu7GPk7B2fEnzM/pub?w=1440&h=1080">
<!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
<!--
## API Extensions
### User-Defined Types
Consider adding a Custom Resource to Kubernetes if you want to define new controllers, application configuration objects or other declarative APIs, and to manage them using Kubernetes tools, such as `kubectl`.
Do not use a Custom Resource as data storage for application, user, or monitoring data.
For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
-->
## API 扩展 {#api-extensions}
### 用户自定义类型 {#user-defined-types}
如果你想定义新的控制器、应用程序配置对象或其他声明式 API并使用 Kubernetes
工具(如 `kubectl`)管理它们,请考虑为 Kubernetes 添加一个自定义资源。
不要使用自定义资源作为应用、用户或者监控数据的数据存储。
有关自定义资源的更多信息,请查看
[自定义资源概念指南](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
<!--
### Combining New APIs with Automation
The combination of a custom resource API and a control loop is called the [Operator pattern](/docs/concepts/extend-kubernetes/operator/). The Operator pattern is used to manage specific, usually stateful, applications. These custom APIs and control loops can also be used to control other resources, such as storage or policies.
-->
### 将新的 API 与自动化相结合
自定义资源 API 和控制循环的组合称为
[操作者Operator模式](/zh/docs/concepts/extend-kubernetes/operator/)。
操作者模式用于管理特定的,通常是有状态的应用程序。
这些自定义 API 和控制循环还可用于控制其他资源,例如存储或策略。
<!--
### Changing Built-in Resources
When you extend the Kubernetes API by adding custom resources, the added resources always fall into a new API Groups. You cannot replace or change existing API groups.
Adding an API does not directly let you affect the behavior of existing APIs (e.g. Pods), but API Access Extensions do.
-->
### 改变内置资源
当你通过添加自定义资源来扩展 Kubernetes API 时,添加的资源始终属于新的 API 组。
你不能替换或更改已有的 API 组。
添加 API 不会直接影响现有 API例如 Pod )的行为,但是 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/concepts/security/controlling-access/) for more on this flow.
Each of these steps offers extension points.
Kubernetes has several built-in authentication methods that it supports. It can also sit behind an authenticating proxy, and it can send a token from an Authorization header to a remote service for verification (a webhook). All of these methods are covered in the [Authentication documentation](/docs/reference/access-authn-authz/authentication/).
-->
### API 访问扩展 {#api-access-extensions}
当请求到达 Kubernetes API Server 时,它首先被要求进行用户认证,然后要进行授权检查,
接着受到各种类型的准入控制的检查。有关此流程的更多信息,请参阅
[Kubernetes API 访问控制](/zh/docs/concepts/security/controlling-access/)。
上述每个步骤都提供了扩展点。
Kubernetes 有几个它支持的内置认证方法。它还可以位于身份验证代理之后,并将 Authorziation 头部
中的令牌发送给远程服务webhook进行验证。所有这些方法都在
[身份验证文档](/zh/docs/reference/access-authn-authz/authentication/)中介绍。
<!--
### Authentication
[Authentication](/docs/reference/access-authn-authz/authentication/) maps headers or certificates in all requests to a username for the client making the request.
Kubernetes provides several built-in authentication methods, and an [Authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) method if those don't meet your needs.
-->
### 身份认证 {#authentication}
[身份认证](/zh/docs/reference/access-authn-authz/authentication/)
将所有请求中的头部字段或证书映射为发出请求的客户端的用户名。
Kubernetes 提供了几种内置的身份认证方法,如果这些方法不符合你的需求,可以使用
[身份认证 Webhook](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 方法。
<!--
### Authorization
[Authorization](/docs/reference/access-authn-authz/webhook/) determines whether specific users can read, write, and do other operations on API resources. It just works at the level of whole resources -- it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, and [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision.
-->
### 鉴权 {#authorization}
[鉴权组件](/zh/docs/reference/access-authn-authz/authorization/)决定特定用户是否可以对
API 资源执行读取、写入以及其他操作。它只是在整个资源的层面上工作 --
它不基于任意的对象字段进行区分。如果内置授权选项不能满足你的需求,
[鉴权 Webhook](/zh/docs/reference/access-authn-authz/webhook/)
允许调用用户提供的代码来作出授权决定。
<!--
### Dynamic Admission Control
After a request is authorized, if it is a write operation, it also goes through [Admission Control](/docs/reference/access-authn-authz/admission-controllers/) steps. In addition to the built-in steps, there are several extensions:
* The [Image Policy webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) restricts what images can be run in containers.
* To make arbitrary admission control decisions, a general [Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) can be used. Admission Webhooks can reject creations or updates.
-->
### 动态准入控制
在请求被授权之后,如果是写入操作,它还将进入
[准入控制](/zh/docs/reference/access-authn-authz/admission-controllers/)
步骤。除了内置的步骤之外,还有几个扩展:
* [镜像策略 Webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)
限制哪些镜像可以在容器中运行。
* 为了进行灵活的准入控制决策,可以使用通用的
[准入 Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。
准入 Webhooks 可以拒绝创建或更新操作。
<!--
## Infrastructure Extensions
### Storage Plugins
[Flex Volumes](/docs/concepts/storage/volumes/#flexvolume)
allow users to mount volume types without built-in support by having the
Kubelet call a Binary Plugin to mount the volume.
-->
## 基础设施扩展
### 存储插件
[Flex Volumes](/zh/docs/concepts/storage/volumes/#flexvolume)
允许用户挂载无内置插件支持的卷类型,它通过 Kubelet 调用一个可执行文件插件来挂载卷。
<!--
### Device Plugins
Device plugins allow a node to discover new Node resources (in addition to the
builtin ones like cpu and memory) via a
[Device Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/).
-->
### 设备插件 {#device-plugins}
设备插件允许节点通过
[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/).
发现新的节点资源(除了内置的 CPU 和内存之外)。
<!--
### Network Plugins
Different networking fabrics can be supported via node-level
[Network Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/).
-->
### 网络插件 {#network-plugins}
不同的网络结构可以通过节点级的
[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
得到支持。
<!--
### Scheduler Extensions
The scheduler is a special type of controller that watches pods, and assigns
pods to nodes. The default scheduler can be replaced entirely, while
continuing to use other Kubernetes components, or
[multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)
can run at the same time.
This is a significant undertaking, and almost all Kubernetes users find they
do not need to modify the scheduler.
The scheduler also supports a
[webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)
that permits a webhook backend (scheduler extension) to filter and prioritize
the nodes chosen for a pod.
-->
### 调度器扩展 {#scheduler-extensions}
调度器是一种特殊类型的控制器,用于监视 pod 并将其分配到节点。
默认的调度器可以完全被替换,而继续使用其他 Kubernetes 组件,或者可以同时运行
[多个调度器](/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)。
这是一个不太轻松的任务,几乎所有的 Kubernetes 用户都会意识到他们并不需要修改调度器。
调度器也支持
[Webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)
它允许使用一个 Webhook 后端(调度器扩展程序)为 Pod 筛选节点和确定节点的优先级。
<!--
## {{% heading "whatsnext" %}}
* Learn more about [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
* Learn about [Dynamic admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/)
* Learn more about Infrastructure extensions
* [Network Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
* [Device Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
-->
## {{% heading "whatsnext" %}}
* 详细了解[自定义资源](/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/)
* [设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
* 了解 [kubectl 插件](/zh/docs/tasks/extend-kubectl/kubectl-plugins/)
* 了解[操作者模式](/zh/docs/concepts/extend-kubernetes/operator/)

View File

@ -1,6 +0,0 @@
---
title: v1.20
weight: 50
---
[Kubernetes API v1.20](/docs/reference/generated/kubernetes-api/v1.20/)

View File

@ -1,69 +0,0 @@
<!--
### Synopsis
-->
### 概要
<!--
This command is not meant to be run on its own. See list of available subcommands.
-->
此命令并非设计用来单独运行。请参阅可用子命令列表。
<!--
### Options
-->
### 选项
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
help for kubelet
-->
kubelet 操作的帮助命令
</td>
</tr>
</tbody>
</table>
<!--
### Options inherited from parent commands
-->
### 从父命令继承的选项
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--rootfs string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
[EXPERIMENTAL] The path to the 'real' host root filesystem.
-->
[实验] 指向 '真实' 宿主机的根目录。
</td>
</tr>
</tbody>
</table>

View File

@ -1,67 +0,0 @@
<!--
### Synopsis
-->
### 概要
<!--
This command is not meant to be run on its own. See list of available subcommands.
-->
此命令并非设计用来单独运行。请参阅可用子命令列表。
<!--
### Options
-->
### 选项
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!-- help for config -->
config 操作的帮助命令
</td>
</tr>
</tbody>
</table>
<!--
### Options inherited from parent commands
-->
### 从父命令继承的选项
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--rootfs string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
[EXPERIMENTAL] The path to the 'real' host root filesystem.
-->
[实验] 指向宿主机上的 '实际' 根文件系统的路径。
</td>
</tr>
</tbody>
</table>

View File

@ -1,134 +0,0 @@
<!--
### Synopsis
-->
### 概要
<!--
Enable or update dynamic kubelet configuration for a Node, against the kubelet-config-1.X ConfigMap in the cluster, where X is the minor version of the desired kubelet version.
-->
针对集群中的 kubelet-config-1.X ConfigMap 启用或更新节点的动态 kubelet 配置,其中 X 是所需 kubelet 版本的次要版本。
<!--
WARNING: This feature is still experimental, and disabled by default. Enable only if you know what you are doing, as it may have surprising side-effects at this stage.
-->
警告:此功能仍处于试验阶段,默认情况下处于禁用状态。仅当知道自己在做什么时才启用它,因为在此阶段它可能会产生令人惊讶的副作用。
<!--
Alpha Disclaimer: this command is currently alpha.
-->
Alpha 免责声明:此命令当前为 Alpha 功能。
```
kubeadm alpha kubelet config enable-dynamic [flags]
```
<!--
### Examples # Enable dynamic kubelet configuration for a Node.
-->
### 示例
```
# 为节点启用动态 kubelet 配置。
kubeadm alpha phase kubelet enable-dynamic-config --node-name node-1 --kubelet-version 1.16.0
WARNING: This feature is still experimental, and disabled by default. Enable only if you know what you are doing, as it
may have surprising side-effects at this stage.
```
<!--
### Options
-->
### 选项
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
help for enable-dynamic
-->
enable-dynamic 操作的帮助命令
</td>
</tr>
<tr>
<td colspan="2">
<!--
--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"
-->
--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: "/etc/kubernetes/admin.conf"
</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.
-->
与集群通信时使用的 kubeconfig 文件。如果未设置该标志,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
</td>
</tr>
<tr>
<td colspan="2">--kubelet-version string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
The desired version for the kubelet
-->
kubelet 所需版本
</td>
</tr>
<tr>
<td colspan="2">--node-name string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
Name of the node that should enable the dynamic kubelet configuration
-->
应该启用动态 kubelet 配置节点的名称
</td>
</tr>
</tbody>
</table>
<!--
### Options inherited from parent commands
-->
### 从父命令继承的选项
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--rootfs string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
[EXPERIMENTAL] The path to the 'real' host root filesystem.
-->
[实验] 指向 '真实' 宿主机的根目录。
</td>
</tr>
</tbody>
</table>

View File

@ -1,68 +0,0 @@
<!--
### Synopsis
-->
### 概要
<!--
This command is not meant to be run on its own. See list of available subcommands.
-->
此命令并非设计用来单独运行。请参阅可用子命令列表。
<!--
### Options
-->
### 选项
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
help for selfhosting
-->
selfhosting 操作的帮助命令
</td>
</tr>
</tbody>
</table>
<!--
### Options inherited from parent commands
-->
### 从父命令继承的选项
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--rootfs string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
[EXPERIMENTAL] The path to the 'real' host root filesystem.
-->
[实验] 指向 '真实' 宿主机的根目录。
</td>
</tr>
</tbody>
</table>

View File

@ -1,171 +0,0 @@
<!--
### Synopsis
-->
### 概要
<!--
Convert static Pod files for control plane components into self-hosted DaemonSets configured via the Kubernetes API.
-->
将用于控制平面组件的静态 Pod 文件转换为通过 Kubernetes API 配置的自托管 DaemonSet。
<!--
See the documentation for self-hosting limitations.
-->
有关自托管的限制,请参阅相关文档。
<!--
Alpha Disclaimer: this command is currently alpha.
-->
Alpha 免责声明:此命令当前为 alpha 功能。
```
kubeadm alpha selfhosting pivot [flags]
```
<!--
### Examples
-->
### 示例
<!--
# Convert a static Pod-hosted control plane into a self-hosted one.
-->
```
# 将静态 Pod 托管的控制平面转换为自托管的控制平面。
kubeadm alpha phase self-hosting convert-from-staticpods
```
<!--
### Options
-->
### 选项
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">
<!--
--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"
-->
--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值:"/etc/kubernetes/pki"
</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
The path where certificates are stored
-->
证书存储的路径
</td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
Path to a kubeadm configuration file.
-->
kubeadm 配置文件的路径。
</td>
</tr>
<tr>
<td colspan="2">-f, --force</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
Pivot the cluster without prompting for confirmation
-->
在不提示确认的情况下转换集群
</td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
help for pivot
-->
pivot 操作的帮助命令
</td>
</tr>
<tr>
<td colspan="2">
<!--
--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"
-->
--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值:"/etc/kubernetes/admin.conf"
</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.
-->
与集群通信时使用的 kubeconfig 文件。如果未设置该参数,则可以在一组标准位置中搜索现有的 kubeconfig 文件。
</td>
</tr>
<tr>
<td colspan="2">-s, --store-certs-in-secrets</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
Enable storing certs in secrets
-->
启用 secret 存储证书
</td>
</tr>
</tbody>
</table>
<!--
### Options inherited from parent commands
-->
### 从父命令继承的选项
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--rootfs string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
[EXPERIMENTAL] The path to the 'real' host root filesystem.
-->
[实验] 到 '真实' 主机根文件系统的路径。
</td>
</tr>
</tbody>
</table>

View File

@ -1,91 +0,0 @@
<!--
### Synopsis
-->
### 概要
<!--
Using this command, you can view the ConfigMap in the cluster where the configuration for kubeadm is located.
The configuration is located in the "kube-system" namespace in the "kubeadm-config" ConfigMap.
-->
使用此命令,可以查看 kubeadm 配置的集群中的 ConfigMap。
该配置位于 "kube-system" 命名空间中的名为 "kubeadm-config" 的 ConfigMap 中。
```
kubeadm config view [flags]
```
<!--
### Options
-->
### 选项
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
help for view
-->
view 操作的帮助命令
</td>
</tr>
</tbody>
</table>
<!--
### Options inherited from parent commands
-->
### 继承于父命令的选项
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">
<!--
--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/admin.conf"
-->
--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值:"/etc/kubernetes/admin.conf"
</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!--
The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.
-->
用于和集群通信的 KubeConfig 文件。如果未设置,那么 kubeadm 将会搜索一个已经存在于标准路径的 KubeConfig 文件。
</td>
</tr>
<tr>
<td colspan="2">--rootfs string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">
<!-- [EXPERIMENTAL] The path to the 'real' host root filesystem. -->
[实验] 到 '真实' 主机根文件系统的路径。
</td>
</tr>
</tbody>
</table>

View File

@ -45,9 +45,6 @@ has to be used.
<!-- body -->
## kubeadm config upload from-file {#cmd-config-from-file}
## kubeadm config view {#cmd-config-view}
{{< include "generated/kubeadm_config_view.md" >}}
## kubeadm config print init-defaults {#cmd-config-print-init-defaults}
{{< include "generated/kubeadm_config_print_init-defaults.md" >}}

View File

@ -1,107 +0,0 @@
---
reviewers:
- janetkuo
title: 工具
content_type: concept
---
<!--
reviewers:
- janetkuo
title: Tools
content_type: concept
-->
<!--
Kubernetes contains several built-in tools to help you work with the Kubernetes system.
-->
<!-- overview -->
Kubernetes 包含一些内置工具,可以帮助用户更好的使用 Kubernetes 系统。
<!-- body -->
## Kubectl
<!--
[`kubectl`](/docs/tasks/tools/install-kubectl/) is the command line tool for Kubernetes. It controls the Kubernetes cluster manager.
-->
[`kubectl`](/zh/docs/tasks/tools/install-kubectl/) 是 Kubernetes 命令行工具,
可以用来操控 Kubernetes 集群。
## Kubeadm
<!--
[`kubeadm`](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) is the command line tool for easily provisioning a secure Kubernetes cluster on top of physical or cloud servers or virtual machines (currently in alpha).
-->
[`kubeadm`](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) 是一个命令行工具,
可以用来在物理机、云服务器或虚拟机(目前处于 alpha 阶段)
上轻松部署一个安全可靠的 Kubernetes 集群。
## Minikube
<!--
[`minikube`](https://minikube.sigs.k8s.io/docs/) is a tool that makes it
easy to run a single-node Kubernetes cluster locally on your workstation for
development and testing purposes.
-->
[`minikube`](https://minikube.sigs.k8s.io/docs/) 是一个可以方便用户
在其工作站点本地部署一个单节点 Kubernetes 集群的工具,用于开发和测试。
## Dashboard
<!--
[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/), the web-based user interface of Kubernetes, allows you to deploy containerized applications
to a Kubernetes cluster, troubleshoot them, and manage the cluster and its resources itself.
-->
[`Dashboard`](/zh/docs/tasks/access-application-cluster/web-ui-dashboard/)
是 Kubernetes 基于 Web 的用户管理界面,允许用户部署容器化应用到 Kubernetes
集群,进行故障排查以及管理集群和集群资源。
## Helm
<!--
[`Kubernetes Helm`](https://github.com/kubernetes/helm) is a tool for managing packages of pre-configured
Kubernetes resources, aka Kubernetes charts.
-->
[`Kubernetes Helm`](https://github.com/kubernetes/helm) 是一个管理
预先配置完毕的 Kubernetes 资源包的工具,这里的资源在 Helm 中也被称作
Kubernetes charts。
<!--
Use Helm to:
* Find and use popular software packaged as Kubernetes charts
* Share your own applications as Kubernetes charts
* Create reproducible builds of your Kubernetes applications
* Intelligently manage your Kubernetes manifest files
* Manage releases of Helm packages
-->
使用 Helm
* 查找并使用已经打包为 Kubernetes charts 的流行软件
* 分享您自己的应用作为 Kubernetes charts
* 为 Kubernetes 应用创建可重复执行的构建
* 为您的 Kubernetes 清单文件提供更智能化的管理
* 管理 Helm 软件包的发布
## Kompose
<!--
[`Kompose`](https://github.com/kubernetes/kompose) is a tool to help Docker Compose users move to Kubernetes.
-->
[`Kompose`](https://github.com/kubernetes/kompose) 一个转换工具,
用来帮助 Docker Compose 用户迁移至 Kubernetes。
<!--
Use Kompose to:
* Translate a Docker Compose file into Kubernetes objects
* Go from local Docker development to managing your application via Kubernetes
* Convert v1 or v2 Docker Compose `yaml` files or [Distributed Application Bundles](https://docs.docker.com/compose/bundles/)
-->
使用 Kompose:
* 将一个 Docker Compose 文件解释成 Kubernetes 对象
* 将本地 Docker 开发 转变成通过 Kubernetes 来管理
* 转换 v1 或 v2 Docker Compose `yaml` 文件 或
[已发布的应用程序包](https://docs.docker.com/compose/bundles/)

View File

@ -1,129 +0,0 @@
---
title: 配置您的 kubernetes 集群以自托管控制平台
content_type: concept
weight: 100
---
<!--
title: Configuring your kubernetes cluster to self-host the control plane
content_type: concept
weight: 100
-->
<!-- overview -->
<!--
### Self-hosting the Kubernetes control plane {#self-hosting}
-->
### 自托管 Kubernetes 控制平台 {#self-hosting}
<!--
kubeadm allows you to experimentally create a _self-hosted_ Kubernetes control
plane. This means that key components such as the API server, controller
manager, and scheduler run as [DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
configured via the Kubernetes API instead of [static pods](/docs/tasks/administer-cluster/static-pod/)
configured in the kubelet via static files.
-->
kubeadm 允许您实验性地创建 _self-hosted_ Kubernetes 控制平面。
这意味着 API 服务器,控制管理器和调度程序之类的关键组件将通过配置 Kubernetes API 以
[DaemonSet Pods](/zh/docs/concepts/workloads/controllers/daemonset/) 的身份运行,
而不是通过静态文件在 kubelet 中配置[静态 Pods](/zh/docs/tasks/configure-pod-container/static-pod/)。
<!--
To create a self-hosted cluster see the
[kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command.
-->
要创建自托管集群,请参见
[kubeadm alpha selfhosting pivot](/zh/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting)
命令。
<!-- body -->
<!--
#### Caveats
-->
#### 警告
<!--
This feature pivots your cluster into an unsupported state, rendering kubeadm unable
to manage you cluster any longer. This includes `kubeadm upgrade`.
-->
{{< caution >}}
此功能将您的集群设置为不受支持的状态,从而使 kubeadm 无法再管理您的集群。
这包括 `kubeadm 升级`
{{< /caution >}}
<!--
1. Self-hosting in 1.8 and later has some important limitations. In particular, a
self-hosted cluster _cannot recover from a reboot of the control-plane node_
without manual intervention.
-->
1. 1.8及更高版本中的自托管功能有一些重要限制。
特别是自托管集群在没有人工干预的情况下_无法从控制平面节点的重新启动中恢复_ 。
<!--
1. By default, self-hosted control plane Pods rely on credentials loaded from
[`hostPath`](/docs/concepts/storage/volumes/#hostpath)
volumes. Except for initial creation, these credentials are not managed by
kubeadm.
-->
2. 默认情况下,自托管的控制平面 Pod 依赖于从
[`hostPath`](/zh/docs/concepts/storage/volumes/#hostpath) 卷加载的凭据。
除初始创建外,这些凭据不由 kubeadm 管理。
<!--
1. The self-hosted portion of the control plane does not include etcd,
which still runs as a static Pod.
-->
3. 控制平面的自托管部分不包括 etcd后者仍作为静态 Pod 运行。
<!--
#### Process
The self-hosting bootstrap process is documented in the [kubeadm design
document](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting).
-->
#### 过程
自托管引导过程描述于 [kubeadm 设计文档](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting) 中。
<!--
In summary, `kubeadm alpha selfhosting` works as follows:
-->
总体而言,`kubeadm alpha 自托管` 的工作原理如下:
<!--
1. Waits for this bootstrap static control plane to be running and
healthy. This is identical to the `kubeadm init` process without self-hosting.
-->
1. 等待此引导静态控制平面运行且良好。
这与没有自我托管的 `kubeadm init` 过程相同。
<!--
1. Uses the static control plane Pod manifests to construct a set of
DaemonSet manifests that will run the self-hosted control plane.
It also modifies these manifests where necessary, for example adding new volumes
for secrets.
-->
2. 使用静态控制平面 Pod 清单来构造一组 DaemonSet 清单,这些清单将运行自托管的控制平面。
它还会在必要时修改这些清单,例如添加新的 secrets 卷。
<!--
1. Creates DaemonSets in the `kube-system` namespace and waits for the
resulting Pods to be running.
-->
3. 在 `kube-system` 名称空间中创建 DaemonSets ,并等待生成的 Pod 运行。
<!--
1. Once self-hosted Pods are operational, their associated static Pods are deleted
and kubeadm moves on to install the next component. This triggers kubelet to
stop those static Pods.
-->
4. 自托管 Pod 运行后,将删除其关联的静态 Pod然后 kubeadm 继续安装下一个组件。
这将触发 kubelet 停止那些静态 Pod 。
<!--
1. When the original static control plane stops, the new self-hosted control
plane is able to bind to listening ports and become active.
-->
5. 当原始静态控制平面停止时,新的自托管控制平面能够绑定到侦听端口并变为活动状态。

View File

@ -1,161 +0,0 @@
---
reviewers:
title: 启用 EndpointSlices
content_type: task
---
<!--
reviewers:
- bowei
- freehan
title: Enabling EndpointSlices
content_type: task
-->
<!-- overview -->
<!--
This page provides an overview of enabling EndpointSlices in Kubernetes.
-->
本页提供启用 Kubernetes EndpointSlice 的总览。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
<!--
## Introduction
EndpointSlices provide a scalable and extensible alternative to Endpoints in
Kubernetes. They build on top of the base of functionality provided by Endpoints
and extend that in a scalable way. When Services have a large number (>100) of
network endpoints, they will be split into multiple smaller EndpointSlice
resources instead of a single large Endpoints resource.
-->
## 介绍
EndpointSlice (端点切片)为 Kubernetes Endpoints 提供了可伸缩和可扩展的替代方案。
它们建立在 Endpoints 提供的功能基础之上,并以可伸缩的方式进行扩展。
当 Service 具有大量(>100网络端点时它们将被分成多个较小的 EndpointSlice 资源,
而不是单个大型 Endpoints 资源。
<!--
## Enabling EndpointSlices
-->
## 启用 EndpointSlice
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
{{< note >}}
<!--
The EndpointSlice resource was designed to address shortcomings in a earlier
resource: Endpoints. Some Kubernetes components and third-party applications
continue to use and rely on Endpoints. Whilst that remains the case,
EndpointSlices should be seen as an addition to Endpoints in a cluster, not as
an outright replacement.
-->
EndpointSlice 资源旨在解决较早资源Endpoints 中的缺点。一些 Kubernetes 组件和第三方应用程序
继续使用并依赖 Endpoints。既然情况如此应该将 EndpointSlices 视为集群中 Endpoints 的补充,而不是
彻底替代。
{{< /note >}}
<!--
EndpointSlice functionality in Kubernetes is made up of several different
components, most are enabled by default:
-->
Kubernetes 中的 EndpointSlice 功能包含若干不同组件。它们中的大部分都是
默认被启用的:
<!--
* _The EndpointSlice API_: EndpointSlices are part of the
`discovery.k8s.io/v1beta1` API. This is beta and enabled by default since
Kubernetes 1.17. All components listed below are dependent on this API being
enabled.
* _The EndpointSlice Controller_: This {{< glossary_tooltip text="controller"
term_id="controller" >}} maintains EndpointSlices for Services and the Pods
they reference. This is controlled by the `EndpointSlice` feature gate. It has
been enabled by default since Kubernetes 1.18.
-->
* _EndpointSlice API_EndpointSlice 隶属于 `discovery.k8s.io/v1beta1` API。
此 API 处于 Beta 阶段,从 Kubernetes 1.17 开始默认被启用。
下面列举的所有组件都依赖于此 API 被启用。
* _EndpointSlice 控制器_:此 {{< glossary_tooltip text="控制器" term_id="controller" >}}
为 Service 维护 EndpointSlice 及其引用的 Pods。
此控制器通过 `EndpointSlice` 特性门控控制。自从 Kubernetes 1.18 起,
该特性门控默认被启用。
<!--
* _The EndpointSliceMirroring Controller_: This {{< glossary_tooltip
text="controller" term_id="controller" >}} mirrors custom Endpoints to
EndpointSlices. This is controlled by the `EndpointSlice` feature gate. It has
been enabled by default since Kubernetes 1.19.
* _Kube-Proxy_: When {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy">}}
is configured to use EndpointSlices, it can support higher numbers of Service
endpoints. This is controlled by the `EndpointSliceProxying` feature gate on
Linux and `WindowsEndpointSliceProxying` on Windows. It has been enabled by
default on Linux since Kubernetes 1.19. It is not enabled by default for
Windows nodes. To configure kube-proxy to use EndpointSlices on Windows, you
can enable the `WindowsEndpointSliceProxying` [feature
gate](/docs/reference/command-line-tools-reference/feature-gates/) on
kube-proxy.
-->
* _EndpointSliceMirroring 控制器_:此 {{< glossary_tooltip text="控制器" term_id="controller" >}}
将自定义的 Endpoints 映射为 EndpointSlice。
控制器受 `EndpointSlice` 特性门控控制。该特性门控自 1.19 开始被默认启用。
* _kube-proxy_:当 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy">}}
被配置为使用 EndpointSlice 时,它会支持更大数量的 Service 端点。
此功能在 Linux 上受 `EndpointSliceProxying` 特性门控控制;在 Windows 上受
`WindowsEndpointSliceProxying` 特性门控控制。
在 Linux 上,从 Kubernetes 1.19 版本起自动启用。目前尚未在 Windows 节点
上默认启用。
要在 Windows 节点上配置 kube-proxy 使用 EndpointSlice你需要为 kube-proxy 启用
`WindowsEndpointSliceProxying`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
<!--
## API fields
Some fields in the EndpointSlice API are feature-gated.
- The `EndpointSliceNodeName` feature gate controls access to the `nodeName`
field. This is an alpha feature that is disabled by default.
- The `EndpointSliceTerminating` feature gate controls access to the `serving`
and `terminating` condition fields. This is an alpha feature that is disabled
by default.
-->
## API 字段
EndpointSlice API 中的某些字段有对应的特性门控控制。
- `EndpointSliceNodeName` 特性门控控制对 `nodeName` 字段的访问。这是默认情况下禁用的 Alpha 功能。
- `EndpointSliceTerminating` 特性门控控制对 `serving``terminating` 状况字段的访问。这是默认情况下禁用的 Alpha 功能。
<!--
## Using Endpoint Slices
With EndpointSlices fully enabled in your cluster, you should see corresponding
EndpointSlice resources for each Endpoints resource. In addition to supporting
existing Endpoints functionality, EndpointSlices will allow for greater
scalability and extensibility of network endpoints in your cluster.
-->
## 使用 EndpointSlice
在集群中完全启用 EndpointSlice 的情况下,你应该看到对应于每个
Endpoints 资源的 EndpointSlice 资源。除了支持现有的 Endpoints 功能外,
EndpointSlices 将允许集群中网络端点更好的可伸缩性和可扩展性。
<!--
## {{% heading "whatsnext" %}}
* Read about [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
-->
## {{% heading "whatsnext" %}}
* 参阅 [EndpointSlices](/zh/docs/concepts/services-networking/endpoint-slices/)
* 参阅[将应用程序与服务连接](/zh/docs/concepts/services-networking/connect-applications-service/)

File diff suppressed because it is too large Load Diff