Merge branch 'master' into patch-3
This commit is contained in:
@@ -939,10 +939,10 @@ For background information on design details for API priority and fairness, see
|
||||
[enhancement proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md).
|
||||
You can make suggestions and feature requests via
|
||||
[SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery)
|
||||
or the feature's [slack channel](http://kubernetes.slack.com/messages/api-priority-and-fairness).
|
||||
or the feature's [slack channel](https://kubernetes.slack.com/messages/api-priority-and-fairness).
|
||||
-->
|
||||
有关API优先级和公平性的设计细节的背景信息,
|
||||
请参阅[增强建议](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md)。
|
||||
你可以通过 [SIG APIMachinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery)
|
||||
或特性的 [Slack 频道](http://kubernetes.slack.com/messages/api-priority-and-fairness)
|
||||
你可以通过 [SIG APIMachinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery/)
|
||||
或特性的 [Slack 频道](https://kubernetes.slack.com/messages/api-priority-and-fairness/)
|
||||
提出建议和特性请求。
|
||||
|
||||
@@ -204,7 +204,7 @@ kubelet 在驱动程序上保持打开状态。这意味着为了执行基础结
|
||||
现在,收集加速器指标的责任属于供应商,而不是 kubelet。供应商必须提供一个收集指标的容器,
|
||||
并将其公开给指标服务(例如 Prometheus)。
|
||||
|
||||
[`DisableAcceleratorUsageMetrics` 特性门控](/zh/docs/references/command-line-tools-reference/feature-gates/)
|
||||
[`DisableAcceleratorUsageMetrics` 特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
禁止由 kubelet 收集的指标。
|
||||
关于[何时会在默认情况下启用此功能也有一定规划](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)。
|
||||
|
||||
|
||||
@@ -90,6 +90,6 @@ to disable the timeout restriction. This deprecated feature gate will be removed
|
||||
了解如何在自己的环境中启用聚合器。
|
||||
* 接下来,了解[安装扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/),
|
||||
开始使用聚合层。
|
||||
* 也可以学习怎样[使用自定义资源定义扩展 Kubernetes API](zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
|
||||
* 也可以学习怎样[使用自定义资源定义扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
|
||||
* 阅读 [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io) 的规范
|
||||
|
||||
|
||||
@@ -97,7 +97,7 @@ Extensions are software components that extend and deeply integrate with Kuberne
|
||||
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 need to
|
||||
instance of Kubernetes. As a result, most Kubernetes users will not need to
|
||||
install extensions and fewer will need to author new ones.
|
||||
-->
|
||||
## 扩展程序 {#extension}
|
||||
@@ -105,7 +105,7 @@ install extensions and fewer will need to author new ones.
|
||||
扩展程序是指对 Kubernetes 进行扩展和深度集成的软件组件。它们适合用于支持新的类型和新型硬件。
|
||||
|
||||
大多数集群管理员会使用托管的或统一分发的 Kubernetes 实例。
|
||||
因此,大多数 Kubernetes 用户需要安装扩展程序,而且还有少部分用户甚至需要编写新的扩展程序。
|
||||
因此,大多数 Kubernetes 用户不需要安装扩展程序,而且还有少部分用户甚至需要编写新的扩展程序。
|
||||
|
||||
<!--
|
||||
## Extension Patterns
|
||||
@@ -145,21 +145,20 @@ failure.
|
||||
<!--
|
||||
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](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md)
|
||||
and [Network
|
||||
Plugins](/docs/concepts/cluster-administration/network-plugins/))
|
||||
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 卷插件](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md)和
|
||||
[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)和
|
||||
`kubectl` 所使用。
|
||||
[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 extensions points interact with the
|
||||
Below is a diagram showing how the extension points interact with the
|
||||
Kubernetes control plane.
|
||||
-->
|
||||
下图显示了扩展点如何与 Kubernetes 控制平面进行交互。
|
||||
@@ -184,13 +183,14 @@ This diagram shows the extension points in a Kubernetes system.
|
||||
<!-- 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/overview/extending#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).
|
||||
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 进行交互。
|
||||
@@ -209,9 +209,9 @@ This diagram shows the extension points in a Kubernetes system.
|
||||
5. Kubernetes 的大部分行为都是由称为控制器(Controllers)的程序实现的,这些程序是 API 服务器的客户端。
|
||||
控制器通常与自定义资源一起使用。
|
||||
6. `kubelet` 在主机上运行,并帮助 Pod 看起来就像在集群网络上拥有自己的 IP 的虚拟服务器。
|
||||
[网络插件](/zh/docs/concepts/extend-kubernetes/#network-plugins/)让你可以实现不同的 pod 网络。
|
||||
[网络插件](/zh/docs/concepts/extend-kubernetes/#network-plugins)让你可以实现不同的 pod 网络。
|
||||
7. `kubelet` 也负责为容器挂载和卸载卷。新的存储类型可以通过
|
||||
[存储插件](/zh/docs/concepts/extend-kubernetes/#storage-plugins/)支持。
|
||||
[存储插件](/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.
|
||||
@@ -230,7 +230,7 @@ Consider adding a Custom Resource to Kubernetes if you want to define new contro
|
||||
|
||||
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/api-extension/custom-resources/).
|
||||
For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
|
||||
-->
|
||||
## API 扩展 {#api-extensions}
|
||||
|
||||
@@ -343,24 +343,23 @@ After a request is authorized, if it is a write operation, it also goes through
|
||||
|
||||
### Storage Plugins
|
||||
|
||||
[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md
|
||||
) allow users to mount volume types without built-in support by having the
|
||||
[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](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md
|
||||
)
|
||||
[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/cluster-administration/device-plugins/).
|
||||
builtin ones like cpu and memory) via a
|
||||
[Device Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/).
|
||||
-->
|
||||
### 设备插件 {#device-plugins}
|
||||
|
||||
@@ -371,7 +370,8 @@ Plugin](/docs/concepts/cluster-administration/device-plugins/).
|
||||
<!--
|
||||
### Network Plugins
|
||||
|
||||
Different networking fabrics can be supported via node-level [Network Plugins](/docs/admin/network-plugins/).
|
||||
Different networking fabrics can be supported via node-level
|
||||
[Network Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/).
|
||||
-->
|
||||
### 网络插件 {#network-plugins}
|
||||
|
||||
@@ -408,17 +408,21 @@ the nodes chosen for a pod.
|
||||
[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/api-extension/custom-resources/)
|
||||
## {{% 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/cluster-administration/network-plugins/)
|
||||
* [Device Plugins](/docs/concepts/cluster-administration/device-plugins/)
|
||||
* [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/)
|
||||
* 详细了解基础设施扩展
|
||||
|
||||
@@ -1230,7 +1230,7 @@ By default, all safe sysctls are allowed.
|
||||
|
||||
- Refer to [Pod Security Policy Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) for the api details.
|
||||
-->
|
||||
- 参阅[Pod 安全标准](zh/docs/concepts/security/pod-security-standards/)
|
||||
- 参阅[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)
|
||||
了解策略建议。
|
||||
- 阅读 [Pod 安全策略参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)了解 API 细节。
|
||||
|
||||
|
||||
@@ -316,7 +316,7 @@ The rest of this section will assume you have a Service with a long lived IP
|
||||
所以可以通过标准做法,使在集群中的任何 Pod 都能与该 Service 通信(例如:`gethostbyname()`)。
|
||||
如果 CoreDNS 没有在运行,你可以参照
|
||||
[CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes) 或者
|
||||
[安装 CoreDNS](/docs/tasks/administer-cluster/coredns/#installing-coredns) 来启用它。
|
||||
[安装 CoreDNS](/zh/docs/tasks/administer-cluster/coredns/#installing-coredns) 来启用它。
|
||||
让我们运行另一个 curl 应用来进行测试:
|
||||
|
||||
```shell
|
||||
|
||||
@@ -63,28 +63,29 @@ Kubernetes 作为一个项目,目前支持和维护
|
||||
* [Citrix Ingress 控制器](https://github.com/citrix/citrix-k8s-ingress-controller#readme)
|
||||
可以用来与 Citrix Application Delivery Controller 一起使用。
|
||||
* [Contour](https://projectcontour.io/) 是一个基于 [Envoy](https://www.envoyproxy.io/) 的 Ingress 控制器。
|
||||
* [EnRoute](https://getenroute.io/) 是一个基于 [Envoy](https://www.envoyproxy.io) API 网关能够执行 Ingress 控制器。
|
||||
* [EnRoute](https://getenroute.io/) 是一个基于 [Envoy](https://www.envoyproxy.io) API 网关,
|
||||
可以作为 Ingress 控制器来执行。
|
||||
<!--
|
||||
* F5 BIG-IP [Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)
|
||||
lets you use an Ingress to configure F5 BIG-IP virtual servers.
|
||||
* [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io),
|
||||
which offers API gateway functionality.
|
||||
* [HAProxy Ingress](https://haproxy-ingress.github.io/) is an ingress controller for
|
||||
[HAProxy](http://www.haproxy.org/#desc).
|
||||
[HAProxy](https://www.haproxy.org/#desc).
|
||||
* The [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress#readme)
|
||||
is also an ingress controller for [HAProxy](http://www.haproxy.org/#desc).
|
||||
is also an ingress controller for [HAProxy](https://www.haproxy.org/#desc).
|
||||
* [Istio Ingress](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)
|
||||
is an [Istio](https://istio.io/) based ingress controller.
|
||||
-->
|
||||
* F5 BIG-IP 的
|
||||
[用于 Kubernetes 的容器 Ingress 服务](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)
|
||||
[用于 Kubernetes 的容器 Ingress 服务](https://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)
|
||||
让你能够使用 Ingress 来配置 F5 BIG-IP 虚拟服务器。
|
||||
* [Gloo](https://gloo.solo.io) 是一个开源的、基于 [Envoy](https://www.envoyproxy.io) 的
|
||||
Ingress 控制器,能够提供 API 网关功能,
|
||||
* [HAProxy Ingress](https://haproxy-ingress.github.io/) 针对 [HAProxy](http://www.haproxy.org/#desc)
|
||||
* [HAProxy Ingress](https://haproxy-ingress.github.io/) 针对 [HAProxy](https://www.haproxy.org/#desc)
|
||||
的 Ingress 控制器。
|
||||
* [用于 Kubernetes 的 HAProxy Ingress 控制器](https://github.com/haproxytech/kubernetes-ingress#readme)
|
||||
也是一个针对 [HAProxy](http://www.haproxy.org/#desc) 的 Ingress 控制器。
|
||||
也是一个针对 [HAProxy](https://www.haproxy.org/#desc) 的 Ingress 控制器。
|
||||
* [Istio Ingress](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)
|
||||
是一个基于 [Istio](https://istio.io/) 的 Ingress 控制器。
|
||||
<!--
|
||||
@@ -96,7 +97,7 @@ Kubernetes 作为一个项目,目前支持和维护
|
||||
* The [Traefik Kubernetes Ingress provider](https://doc.traefik.io/traefik/providers/kubernetes-ingress/) is an
|
||||
ingress controller for the [Traefik](https://traefik.io/traefik/) proxy.
|
||||
* [Voyager](https://appscode.com/products/voyager) is an ingress controller for
|
||||
[HAProxy](http://www.haproxy.org/#desc).
|
||||
[HAProxy](https://www.haproxy.org/#desc).
|
||||
-->
|
||||
* [用于 Kubernetes 的 Kong Ingress 控制器](https://github.com/Kong/kubernetes-ingress-controller#readme)
|
||||
是一个用来驱动 [Kong Gateway](https://konghq.com/kong/) 的 Ingress 控制器。
|
||||
@@ -108,7 +109,7 @@ Kubernetes 作为一个项目,目前支持和维护
|
||||
设计用来作为构造你自己的定制代理的库。
|
||||
* [Traefik Kubernetes Ingress 提供程序](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)
|
||||
是一个用于 [Traefik](https://traefik.io/traefik/) 代理的 Ingress 控制器。
|
||||
* [Voyager](https://appscode.com/products/voyager) 是一个针对 [HAProxy](http://www.haproxy.org/#desc)
|
||||
* [Voyager](https://appscode.com/products/voyager) 是一个针对 [HAProxy](https://www.haproxy.org/#desc)
|
||||
的 Ingress 控制器。
|
||||
|
||||
<!--
|
||||
|
||||
@@ -348,7 +348,7 @@ each Service port. The value of this field is mirrored by the corresponding
|
||||
Endpoints and EndpointSlice objects.
|
||||
|
||||
This field follows standard Kubernetes label syntax. Values should either be
|
||||
[IANA standard service names](http://www.iana.org/assignments/service-names) or
|
||||
[IANA standard service names](https://www.iana.org/assignments/service-names) or
|
||||
domain prefixed names such as `mycompany.com/my-custom-protocol`.
|
||||
-->
|
||||
### 应用程序协议 {#application-protocol}
|
||||
@@ -358,8 +358,8 @@ domain prefixed names such as `mycompany.com/my-custom-protocol`.
|
||||
此字段的取值会被映射到对应的 Endpoints 和 EndpointSlices 对象。
|
||||
|
||||
该字段遵循标准的 Kubernetes 标签语法。
|
||||
其值可以是 [IANA 标准服务名称](http://www.iana.org/assignments/service-names)或以域名前缀的名称,
|
||||
如 `mycompany.com/my-custom-protocol`。
|
||||
其值可以是 [IANA 标准服务名称](https://www.iana.org/assignments/service-names)
|
||||
或以域名为前缀的名称,如 `mycompany.com/my-custom-protocol`。
|
||||
<!--
|
||||
## Virtual IPs and service proxies
|
||||
|
||||
|
||||
@@ -691,7 +691,7 @@ vSphere 存储类有两种制备器
|
||||
[弃用](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi)。
|
||||
更多关于 CSI 制备器的详情,请参阅
|
||||
[Kubernetes vSphere CSI 驱动](https://vsphere-csi-driver.sigs.k8s.io/)
|
||||
和 [vSphereVolume CSI 迁移](/docs/concepts/storage/volumes/#csi-migration-5)。
|
||||
和 [vSphereVolume CSI 迁移](/zh/docs/concepts/storage/volumes/#csi-migration-5)。
|
||||
|
||||
<!--
|
||||
#### CSI Provisioner {#vsphere-provisioner-csi}
|
||||
@@ -1356,4 +1356,4 @@ scheduling constraints when choosing an appropriate PersistentVolume for a
|
||||
PersistentVolumeClaim.
|
||||
-->
|
||||
延迟卷绑定使得调度器在为 PersistentVolumeClaim 选择一个合适的
|
||||
PersistentVolume 时能考虑到所有 Pod 的调度限制。
|
||||
PersistentVolume 时能考虑到所有 Pod 的调度限制。
|
||||
|
||||
@@ -33,7 +33,8 @@ due to a node hardware failure or a node reboot).
|
||||
|
||||
You can also use a Job to run multiple Pods in parallel.
|
||||
-->
|
||||
Job 会创建一个或者多个 Pods,并会持续重试直到指定数量的 Pods 成功终止。
|
||||
|
||||
Job 会创建一个或者多个 Pods,并将继续重试 Pods 的执行,直到指定数量的 Pods 成功终止。
|
||||
随着 Pods 成功结束,Job 跟踪记录成功完成的 Pods 个数。
|
||||
当数量达到指定的成功个数阈值时,任务(即 Job)结束。
|
||||
删除 Job 的操作会清除所创建的全部 Pods。
|
||||
|
||||
@@ -320,6 +320,71 @@ To make such deployment secure, communication between etcd instances is authoriz
|
||||
为了允许 etcd 组建集群,需开放 etcd 实例之间通信所需的端口(用于集群内部通信)。
|
||||
为了使这种部署安全,etcd 实例之间的通信使用 SSL 进行鉴权。
|
||||
|
||||
<!--
|
||||
### API server identity
|
||||
-->
|
||||
### API 服务器标识
|
||||
|
||||
{{< feature-state state="alpha" for_k8s_version="v1.20" >}}
|
||||
|
||||
<!--
|
||||
The API Server Identity feature is controlled by a
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
and is not enabled by default. You can activate API Server Identity by enabling
|
||||
the feature gate named `APIServerIdentity` when you start the
|
||||
{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}:
|
||||
-->
|
||||
使用 API 服务器标识功能需要启用[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/),
|
||||
该功能默认不启用。
|
||||
你可以在启动 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}} 的时候启用特性门控 `APIServerIdentity` 来激活 API 服务器标识:
|
||||
|
||||
<!--
|
||||
```shell
|
||||
kube-apiserver \
|
||||
--feature-gates=APIServerIdentity=true \
|
||||
# …and other flags as usual
|
||||
```
|
||||
-->
|
||||
```shell
|
||||
kube-apiserver \
|
||||
--feature-gates=APIServerIdentity=true \
|
||||
# …其他标记照常
|
||||
```
|
||||
|
||||
<!--
|
||||
During bootstrap, each kube-apiserver assigns a unique ID to itself. The ID is
|
||||
in the format of `kube-apiserver-{UUID}`. Each kube-apiserver creates a
|
||||
[Lease](/docs/reference/generated/kubernetes-api/{{< param "version" >}}//#lease-v1-coordination-k8s-io)
|
||||
in the _kube-system_ {{< glossary_tooltip text="namespaces" term_id="namespace">}}.
|
||||
-->
|
||||
在启动引导过程中,每个 kube-apiserver 会给自己分配一个唯一 ID。
|
||||
该 ID 的格式是 `kube-apiserver-{UUID}`。
|
||||
每个 kube-apiserver 会在 _kube-system_ {{< glossary_tooltip text="名字空间" term_id="namespace">}} 里创建一个 [`Lease` 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}//#lease-v1-coordination-k8s-io)。
|
||||
<!--
|
||||
The Lease name is the unique ID for the kube-apiserver. The Lease contains a
|
||||
label `k8s.io/component=kube-apiserver`. Each kube-apiserver refreshes its
|
||||
Lease every `IdentityLeaseRenewIntervalSeconds` (defaults to 10s). Each
|
||||
kube-apiserver also checks all the kube-apiserver identity Leases every
|
||||
`IdentityLeaseDurationSeconds` (defaults to 3600s), and deletes Leases that
|
||||
hasn't got refreshed for more than `IdentityLeaseDurationSeconds`.
|
||||
`IdentityLeaseRenewIntervalSeconds` and `IdentityLeaseDurationSeconds` can be
|
||||
configured by kube-apiserver flags `identity-lease-renew-interval-seconds`
|
||||
and `identity-lease-duration-seconds`.
|
||||
-->
|
||||
`Lease` 对象的名字是 kube-apiserver 的唯一 ID。
|
||||
`Lease` 对象包含一个标签 `k8s.io/component=kube-apiserver`。
|
||||
每个 kube-apiserver 每过 `IdentityLeaseRenewIntervalSeconds`(默认是 10 秒)就会刷新它的 `Lease` 对象。
|
||||
每个 kube-apiserver 每过 `IdentityLeaseDurationSeconds`(默认是 3600 秒)也会检查所有 kube-apiserver 的标识 `Lease` 对象,
|
||||
并且会删除超过 `IdentityLeaseDurationSeconds` 时间还没被刷新的 `Lease` 对象。
|
||||
可以在 kube-apiserver 的 `identity-lease-renew-interval-seconds`
|
||||
和 `identity-lease-duration-seconds` 标记里配置 `IdentityLeaseRenewIntervalSeconds` 和 `IdentityLeaseDurationSeconds`。
|
||||
|
||||
<!--
|
||||
Enabling this feature is a prerequisite for using features that involve HA API
|
||||
server coordination (for example, the `StorageVersionAPI` feature gate).
|
||||
-->
|
||||
启用该功能是使用 HA API 服务器协调相关功能(例如,`StorageVersionAPI` 特性门控)的前提条件。
|
||||
|
||||
<!--
|
||||
## Additional reading
|
||||
|
||||
|
||||
@@ -108,7 +108,7 @@ Once you have a Linux-based Kubernetes control-plane node you are ready to choos
|
||||
"Network": "10.244.0.0/16",
|
||||
"Backend": {
|
||||
"Type": "vxlan",
|
||||
"VNI" : 4096,
|
||||
"VNI": 4096,
|
||||
"Port": 4789
|
||||
}
|
||||
}
|
||||
@@ -136,7 +136,7 @@ Once you have a Linux-based Kubernetes control-plane node you are ready to choos
|
||||
"Network": "10.244.0.0/16",
|
||||
"Backend": {
|
||||
"Type": "vxlan",
|
||||
"VNI" : 4096,
|
||||
"VNI": 4096,
|
||||
"Port": 4789
|
||||
}
|
||||
}
|
||||
|
||||
@@ -252,7 +252,7 @@ data:
|
||||
删除你刚才创建的 Secret:
|
||||
|
||||
```shell
|
||||
kubectl delete secret db-user-pass
|
||||
kubectl delete secret mysecret
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
@@ -85,7 +85,7 @@ of deploying Redis scalably and redundantly.
|
||||
<!--
|
||||
You could also download the following files directly:
|
||||
-->
|
||||
你可以直接下载如下文件:
|
||||
你也可以直接下载如下文件:
|
||||
|
||||
- [`redis-pod.yaml`](/examples/application/job/redis/redis-pod.yaml)
|
||||
- [`redis-service.yaml`](/examples/application/job/redis/redis-service.yaml)
|
||||
@@ -121,7 +121,7 @@ Now hit enter, start the redis CLI, and create a list with some work items in it
|
||||
-->
|
||||
现在按回车键,启动 redis 命令行界面,然后创建一个存在若干个工作项的列表。
|
||||
|
||||
```
|
||||
```shell
|
||||
# redis-cli -h redis
|
||||
redis:6379> rpush job2 "apple"
|
||||
(integer) 1
|
||||
@@ -214,7 +214,7 @@ your username and push to the Hub with the below commands. Replace
|
||||
### Push 镜像
|
||||
|
||||
对于 [Docker Hub](https://hub.docker.com/),请先用你的用户名给镜像打上标签,
|
||||
然后使用下面的命令 push 你的镜像到仓库。请将 `<username>` 替换为你自己的用户名。
|
||||
然后使用下面的命令 push 你的镜像到仓库。请将 `<username>` 替换为你自己的 Hub 用户名。
|
||||
|
||||
```shell
|
||||
docker tag job-wq-2 <username>/job-wq-2
|
||||
@@ -270,7 +270,7 @@ too.
|
||||
-->
|
||||
在这个例子中,每个 pod 处理了队列中的多个项目,直到队列中没有项目时便退出。
|
||||
因为是由工作程序自行检测工作队列是否为空,并且 Job 控制器不知道工作队列的存在,
|
||||
所以依赖于工作程序在完成工作时发出信号。
|
||||
这依赖于工作程序在完成工作时发出信号。
|
||||
工作程序以成功退出的形式发出信号表示工作队列已经为空。
|
||||
所以,只要有任意一个工作程序成功退出,控制器就知道工作已经完成了,所有的 Pod 将很快会退出。
|
||||
因此,我们将 Job 的完成计数(Completion Count)设置为 1 。
|
||||
@@ -360,11 +360,10 @@ want to consider one of the other [job patterns](/docs/concepts/jobs/run-to-comp
|
||||
|
||||
<!--
|
||||
If you have a continuous stream of background processing work to run, then
|
||||
consider running your background workers with a `replicationController` instead,
|
||||
consider running your background workers with a `ReplicaSet` instead,
|
||||
and consider running a background processing library such as
|
||||
[https://github.com/resque/resque](https://github.com/resque/resque).
|
||||
-->
|
||||
如果你有连续的后台处理业务,那么可以考虑使用 `replicationController` 来运行你的后台业务,
|
||||
如果你有持续的后台处理业务,那么可以考虑使用 `ReplicaSet` 来运行你的后台业务,
|
||||
和运行一个类似 [https://github.com/resque/resque](https://github.com/resque/resque)
|
||||
的后台处理库。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user