Kubernetes Prow Robot
GitHub
commit
273034a5ba
|
|
@ -265,7 +265,7 @@ The implementation of the four shared controllers highlighted above, and some sc
|
|||
For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
|
||||
-->
|
||||
|
||||
有关开发插件的更多信息，请参阅[开发云控制器管理器](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)。
|
||||
有关开发插件的更多信息，请参阅[开发云控制器管理器](/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager/)。
|
||||
|
||||
<!--
|
||||
## Authorization
|
||||
|
|
@ -494,7 +494,7 @@ Complete instructions for configuring and running the CCM are provided
|
|||
[here](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager).
|
||||
-->
|
||||
|
||||
[这里](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了有关配置和运行 CCM 的完整说明。
|
||||
[这里](/zh/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了有关配置和运行 CCM 的完整说明。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -32,10 +32,10 @@ One or more forms of [authorization](/docs/reference/access-authn-authz/authoriz
|
|||
Kubernetes 采用的是中心辐射型（Hub-and-Spoke）API 模式。
|
||||
所有从集群（或所运行的 Pods）发出的 API 调用都终止于 apiserver（其它控制面组件都没有被设计为可暴露远程服务）。
|
||||
apiserver 被配置为在一个安全的 HTTPS 端口（443）上监听远程连接请求，
|
||||
并启用一种或多种形式的客户端[身份认证](/zh/docs/reference/access-authn-authz/authentication/)机制。
|
||||
并启用一种或多种形式的客户端[身份认证](/docs/reference/access-authn-authz/authentication/)机制。
|
||||
一种或多种客户端[鉴权机制](/zh/docs/reference/access-authn-authz/authorization/)应该被启用，
|
||||
特别是在允许使用[匿名请求](/zh/docs/reference/access-authn-autha/authentication/#anonymous-requests)
|
||||
或[服务账号令牌](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。
|
||||
特别是在允许使用[匿名请求](/docs/reference/access-authn-authz/authentication/#anonymous-requests)
|
||||
或[服务账号令牌](/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。
|
||||
|
||||
<!--
|
||||
Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. For example, on a default GKE deployment, the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates.
|
||||
|
|
@ -168,5 +168,5 @@ Konnectivity 服务包含两个部分：Konnectivity 服务器和 Konnectivity
|
|||
控制面网络和节点网络中。Konnectivity 代理建立并维持到 Konnectivity 服务器的网络连接。
|
||||
启用 Konnectivity 服务之后，所有控制面到节点的通信都通过这些连接传输。
|
||||
|
||||
请浏览 [Konnectivity 服务任务](/zh/docs/tasks/extend-kubernetes/setup-konnectivity/)
|
||||
请浏览 [Konnectivity 服务任务](/docs/tasks/extend-kubernetes/setup-konnectivity/)
|
||||
在你的集群中配置 Konnectivity 服务。
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ Before choosing a guide, here are some considerations:
|
|||
* [证书](/zh/docs/concepts/cluster-administration/certificates/)节描述了使用不同的工具链生成证书的步骤。
|
||||
* [Kubernetes 容器环境](/zh/docs/concepts/containers/container-environment/)描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。
|
||||
* [控制到 Kubernetes API 的访问](/zh/docs/reference/access-authn-authz/controlling-access/)描述了如何为用户和 service accounts 建立权限许可。
|
||||
* [认证](/zh/docs/reference/access-authn-authz/authentication/)节阐述了 Kubernetes 中的身份认证功能，包括许多认证选项。
|
||||
* [认证](/docs/reference/access-authn-authz/authentication/)节阐述了 Kubernetes 中的身份认证功能，包括许多认证选项。
|
||||
* [鉴权](/zh/docs/reference/access-authn-authz/authorization/)从认证中分离出来，用于控制如何处理 HTTP 请求。
|
||||
* [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。
|
||||
* [在 Kubernetes 集群中使用 Sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。
|
||||
|
|
|
|||
|
|
@ -274,7 +274,7 @@ Using a node-level logging agent is the most common and encouraged approach for
|
|||
Kubernetes doesn't specify a logging agent, but two optional logging agents are packaged with the Kubernetes release: [Stackdriver Logging](/docs/user-guide/logging/stackdriver) for use with Google Cloud Platform, and [Elasticsearch](/docs/user-guide/logging/elasticsearch). You can find more information and instructions in the dedicated documents. Both use [fluentd](http://www.fluentd.org/) with custom configuration as an agent on the node.
|
||||
-->
|
||||
Kubernetes 并不指定日志代理，但是有两个可选的日志代理与 Kubernetes 发行版一起发布。
|
||||
[Stackdriver 日志](/zh/docs/tasks/debug-application-cluster/logging-stackdriver/)
|
||||
[Stackdriver 日志](/docs/tasks/debug-application-cluster/logging-stackdriver/)
|
||||
适用于 Google Cloud Platform，和
|
||||
[Elasticsearch](/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/)。
|
||||
你可以在专门的文档中找到更多的信息和说明。
|
||||
|
|
@ -447,7 +447,7 @@ which uses fluentd as a logging agent. Here are two configuration files that
|
|||
you can use to implement this approach. The first file contains
|
||||
a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to configure fluentd.
|
||||
-->
|
||||
例如，你可以使用 [Stackdriver](/zh/docs/tasks/debug-application-cluster/logging-stackdriver/)，
|
||||
例如，你可以使用 [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/)，
|
||||
它使用 fluentd 作为日志记录代理。
|
||||
以下是两个可用于实现此方法的配置文件。
|
||||
第一个文件包含配置 fluentd 的
|
||||
|
|
|
|||
|
|
@ -219,6 +219,6 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
|
|||
|
||||
* 了解有关 [Prometheus 指标相关的文本格式](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)
|
||||
* 查看 [Kubernetes 稳定版指标](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)列表
|
||||
* 了解有关 [Kubernetes 指标弃用策略](/zh/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior )
|
||||
* 了解有关 [Kubernetes 指标弃用策略](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior )
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -473,7 +473,7 @@ you can create the Secret on the API server with `kubectl apply`.
|
|||
-->
|
||||
#### 从生成器创建 Secret
|
||||
|
||||
Kubectl 从 1.14 版本开始支持[使用 Kustomize 管理对象](/zh/docs/tasks/manage-kubernetes-objects/kustomization/)。
|
||||
Kubectl 从 1.14 版本开始支持[使用 Kustomize 管理对象](/docs/tasks/manage-kubernetes-objects/kustomization/)。
|
||||
Kustomize 提供资源生成器创建 Secret 和 ConfigMaps。
|
||||
Kustomize 生成器要在当前目录内的 `kustomization.yaml` 中指定。
|
||||
生成 Secret 之后，使用 `kubectl apply` 在 API 服务器上创建对象。
|
||||
|
|
|
|||
|
|
@ -97,7 +97,7 @@ API 通常用于托管的 Kubernetes 服务和受控的 Kubernetes 安装环境
|
|||
这些 API 是声明式的，与 Pod 这类其他 Kubernetes 资源遵从相同的约定，所以
|
||||
新的集群配置是可复用的，并且可以当作应用程序来管理。
|
||||
此外，对于稳定版本的 API 而言，它们与其他 Kubernetes API 一样，采纳的是
|
||||
一种[预定义的支持策略](/zh/docs/reference/using-api/deprecation-policy/)。
|
||||
一种[预定义的支持策略](/docs/reference/using-api/deprecation-policy/)。
|
||||
出于以上原因，在条件允许的情况下，基于 API 的方案应该优先于*配置文件*和*参数标志*。
|
||||
|
||||
<!--
|
||||
|
|
@ -259,7 +259,7 @@ For more about Custom Resources, see the [Custom Resources concept guide](/docs/
|
|||
|
||||
不要使用自定义资源来充当应用、用户或者监控数据的数据存储。
|
||||
|
||||
关于自定义资源的更多信息，可参见[自定义资源概念指南](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
|
||||
关于自定义资源的更多信息，可参见[自定义资源概念指南](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
|
||||
|
||||
<!--
|
||||
### Combining New APIs with Automation
|
||||
|
|
@ -307,7 +307,7 @@ Kubernetes has several built-in authentication methods that it supports. It can
|
|||
Kubernetes 提供若干内置的身份认证方法。
|
||||
它也可以运行在某中身份认证代理的后面，并且可以将来自鉴权头部的令牌发送到
|
||||
某个远程服务（Webhook）来执行验证操作。
|
||||
所有这些方法都在[身份认证文档](/zh/docs/reference/access-authn-authz/authentication/)
|
||||
所有这些方法都在[身份认证文档](/docs/reference/access-authn-authz/authentication/)
|
||||
中详细论述。
|
||||
|
||||
<!--
|
||||
|
|
@ -319,11 +319,11 @@ Kubernetes provides several built-in authentication methods, and an [Authenticat
|
|||
-->
|
||||
### 身份认证 {#authentication}
|
||||
|
||||
[身份认证](/zh/docs/reference/access-authn-authz/authentication/)负责将所有请求中
|
||||
[身份认证](/docs/reference/access-authn-authz/authentication/)负责将所有请求中
|
||||
的头部或证书映射到发出该请求的客户端的用户名。
|
||||
|
||||
Kubernetes 提供若干种内置的认证方法，以及
|
||||
[认证 Webhook](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
|
||||
[认证 Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
|
||||
方法以备内置方法无法满足你的要求。
|
||||
|
||||
<!--
|
||||
|
|
@ -443,7 +443,7 @@ the nodes chosen for a pod.
|
|||
* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
|
||||
* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
|
||||
-->
|
||||
* 进一步了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
* 进一步了解[自定义资源](/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/)
|
||||
|
|
|
|||
|
|
@ -91,6 +91,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](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
|
||||
* 阅读 [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io) 的规范
|
||||
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ to advertise that the node has 2 “Foo” devices installed and available.
|
|||
* 设备插件的 Unix 套接字。
|
||||
* 设备插件的 API 版本。
|
||||
* `ResourceName` 是需要公布的。这里 `ResourceName` 需要遵循
|
||||
[扩展资源命名方案](/zh/docs/concepts/configuration/manage-resources-container/#extended-resources)，
|
||||
[扩展资源命名方案](/zh/docs/concepts/configuration/manage-resources-containers/#extended-resources)，
|
||||
类似于 `vendor-domain/resourcetype`。（比如 NVIDIA GPU 就被公布为 `nvidia.com/gpu`。）
|
||||
|
||||
成功注册后，设备插件就向 kubelet 发送他所管理的设备列表，然后 kubelet 负责将这些资源发布到 API 服务器，作为 kubelet 节点状态更新的一部分。
|
||||
|
|
@ -378,8 +378,8 @@ Here are some examples of device plugin implementations:
|
|||
* Learn about the [Topology Manager] (/docs/tasks/adminster-cluster/topology-manager/)
|
||||
-->
|
||||
* 查看[调度 GPU 资源](/zh/docs/tasks/manage-gpus/scheduling-gpus/) 来学习使用设备插件
|
||||
* 查看在上如何[公布节点上的扩展资源](/docs/tasks/administer-cluster/extended-resource-node/)
|
||||
* 查看在上如何[公布节点上的扩展资源](/zh/docs/tasks/administer-cluster/extended-resource-node/)
|
||||
* 阅读如何在 Kubernetes 中使用 [TLS Ingress 的硬件加速](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/)
|
||||
* 学习[拓扑管理器](/zh/docs/tasks/adminster-cluster/topology-manager/)
|
||||
* 学习[拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/)
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ Flags and configuration files may not always be changeable in a hosted Kubernete
|
|||
它们是声明性的，并使用与其他 Kubernetes 资源（如 Pod ）相同的约定，所以新的集群配置可以重复使用，
|
||||
并以与应用程序相同的方式进行管理。
|
||||
而且，当它们变稳定后，也遵循和其他 Kubernetes API 一样的
|
||||
[支持政策](/zh/docs/reference/using-api/deprecation-policy/)。
|
||||
[支持政策](/docs/reference/using-api/deprecation-policy/)。
|
||||
出于这些原因，在合适的情况下它们优先于 *配置文件* 和 *标志* 被使用。
|
||||
|
||||
<!--
|
||||
|
|
@ -243,7 +243,7 @@ For more about Custom Resources, see the [Custom Resources concept guide](/docs/
|
|||
不要使用自定义资源作为应用、用户或者监控数据的数据存储。
|
||||
|
||||
有关自定义资源的更多信息，请查看
|
||||
[自定义资源概念指南](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
|
||||
[自定义资源概念指南](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
|
||||
|
||||
<!--
|
||||
### Combining New APIs with Automation
|
||||
|
|
@ -288,7 +288,7 @@ Kubernetes has several built-in authentication methods that it supports. It can
|
|||
|
||||
Kubernetes 有几个它支持的内置认证方法。它还可以位于身份验证代理之后，并将 Authorziation 头部
|
||||
中的令牌发送给远程服务（webhook）进行验证。所有这些方法都在
|
||||
[身份验证文档](/zh/docs/reference/access-authn-authz/authentication/)中介绍。
|
||||
[身份验证文档](/docs/reference/access-authn-authz/authentication/)中介绍。
|
||||
|
||||
<!--
|
||||
### Authentication
|
||||
|
|
@ -299,11 +299,11 @@ Kubernetes provides several built-in authentication methods, and an [Authenticat
|
|||
-->
|
||||
### 身份认证 {#authentication}
|
||||
|
||||
[身份认证](/zh/docs/reference/access-authn-authz/authentication/)
|
||||
[身份认证](/docs/reference/access-authn-authz/authentication/)
|
||||
将所有请求中的头部字段或证书映射为发出请求的客户端的用户名。
|
||||
|
||||
Kubernetes 提供了几种内置的身份认证方法，如果这些方法不符合你的需求，可以使用
|
||||
[身份认证 Webhook](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 方法。
|
||||
[身份认证 Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 方法。
|
||||
|
||||
<!--
|
||||
### Authorization
|
||||
|
|
@ -420,7 +420,7 @@ the nodes chosen for a pod.
|
|||
* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
|
||||
* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
|
||||
-->
|
||||
* 详细了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
* 详细了解[自定义资源](/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/)
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Kubernetes principles, notably the [control loop](/docs/concepts/#kubernetes-con
|
|||
-->
|
||||
|
||||
Operator 是 Kubernetes 的扩展软件，它利用
|
||||
[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)管理应用及其组件。
|
||||
[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)管理应用及其组件。
|
||||
Operator 遵循 Kubernetes 的理念，特别是在[控制回路](/zh/docs/concepts/#kubernetes-control-plane)方面。
|
||||
|
||||
|
||||
|
|
@ -66,7 +66,7 @@ Kubernetes 为自动化而生。无需任何修改，您即可以从 Kubernetes
|
|||
|
||||
Kubernetes {{< glossary_tooltip text="控制器" term_id="controller" >}} 使您无需修改 Kubernetes 自身的代码，即可以扩展集群的行为。
|
||||
Operator 是 Kubernetes API 的客户端，充当
|
||||
[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)的控制器。
|
||||
[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)的控制器。
|
||||
|
||||
<!--
|
||||
## An example Operator {#example}
|
||||
|
|
@ -212,7 +212,7 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie
|
|||
* 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
|
||||
-->
|
||||
|
||||
* 详细了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
* 详细了解[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
* 在 [OperatorHub.io](https://operatorhub.io/) 上找到现成的、适合您的 Operator
|
||||
* 借助已有的工具来编写您自己的 Operator，例如：
|
||||
* [KUDO](https://kudo.dev/) (Kubernetes 通用声明式 Operator)
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ Kubernetes 项目的目标是 _不要_ 引发现有客户端的兼容性问题
|
|||
|
||||
一般而言，新的 API 资源和新的资源字段可以被频繁地添加进来。
|
||||
删除资源或者字段则要遵从
|
||||
[API 废弃策略](/zh/docs/reference/using-api/deprecation-policy/)。
|
||||
[API 废弃策略](/docs/reference/using-api/deprecation-policy/)。
|
||||
|
||||
关于什么是兼容性的变更，如何变更 API 等详细信息，可参考
|
||||
[API 变更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)。
|
||||
|
|
@ -281,9 +281,9 @@ There are two paths to extending the API with [custom resources](/docs/concepts/
|
|||
to make it seamless for clients.
|
||||
-->
|
||||
有两种途径来扩展 Kubernetes API 以支持
|
||||
[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)：
|
||||
[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)：
|
||||
|
||||
1. 使用 [CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)，
|
||||
1. 使用 [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)，
|
||||
你可以用声明式方式来定义 API 如何提供你所选择的资源 API。
|
||||
|
||||
1. 你也可以选择[实现自己的扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)
|
||||
|
|
|
|||
|
|
@ -325,7 +325,7 @@ Disadvantages compared to imperative object configuration:
|
|||
- [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
-->
|
||||
- [使用命令式命令管理 Kubernetes 对象](/docs/tasks/manage-kubernetes-objects/imperative-command/)
|
||||
- [使用对象配置管理 Kubernetes 对象（命令式）](/docs/tasks/manage-kubernetes-objects/imperative-config/)
|
||||
- [使用对象配置管理 Kubernetes 对象（命令式）](/zh/docs/tasks/manage-kubernetes-objects/imperative-config/)
|
||||
- [使用对象配置管理 Kubernetes 对象（声明式）](/docs/tasks/manage-kubernetes-objects/declarative-config/)
|
||||
- [使用 Kustomize（声明式）管理 Kubernetes 对象](/docs/tasks/manage-kubernetes-objects/kustomization/)
|
||||
- [Kubectl 命令参考](/docs/reference/generated/kubectl/kubectl-commands/)
|
||||
|
|
|
|||
|
|
@ -696,7 +696,7 @@ several security mechanisms.
|
|||
See [Pod Security Standards](/docs/concepts/security/pod-security-standards/#policy-instantiation) for more examples.
|
||||
-->
|
||||
更多的示例可参考
|
||||
[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/#policy-instantiation)。
|
||||
[Pod 安全标准](/docs/concepts/security/pod-security-standards/#policy-instantiation)。
|
||||
|
||||
<!--
|
||||
## Policy Reference
|
||||
|
|
@ -1219,7 +1219,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 安全标准](/docs/concepts/security/pod-security-standards/)
|
||||
了解策略建议。
|
||||
- 阅读 [Pod 安全策略参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)了解 API 细节。
|
||||
|
||||
|
|
|
|||
|
|
@ -190,7 +190,7 @@ In addition, you can limit consumption of storage resources based on associated
|
|||
-->
|
||||
## 存储资源配额
|
||||
|
||||
用户可以对给定命名空间下的[存储资源](/zh/docs/concepts/storage/persistent-volumes/)总量进行限制。
|
||||
用户可以对给定命名空间下的[存储资源](/docs/concepts/storage/persistent-volumes/)总量进行限制。
|
||||
|
||||
此外，还可以根据相关的存储类（Storage Class）来限制存储资源的消耗。
|
||||
|
||||
|
|
@ -205,9 +205,9 @@ In addition, you can limit consumption of storage resources based on associated
|
|||
| 资源名称 | 描述 |
|
||||
| --------------------- | ----------------------------------------------------------- |
|
||||
| `requests.storage` | 所有 PVC，存储资源的需求总量不能超过该值。 |
|
||||
| `persistentvolumeclaims` | 在该命名空间中所允许的 [PVC](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 总量。 |
|
||||
| `persistentvolumeclaims` | 在该命名空间中所允许的 [PVC](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 总量。 |
|
||||
| `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | 在所有与 storage-class-name 相关的持久卷声明中，存储请求的总和不能超过该值。 |
|
||||
| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` | 在与 storage-class-name 相关的所有持久卷声明中，命名空间中可以存在的[持久卷申领](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)总数。 |
|
||||
| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` | 在与 storage-class-name 相关的所有持久卷声明中，命名空间中可以存在的[持久卷申领](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)总数。 |
|
||||
|
||||
<!--
|
||||
For example, if an operator wants to quota storage with `gold` storage class separate from `bronze` storage class, the operator can
|
||||
|
|
@ -307,7 +307,7 @@ The following types are supported:
|
|||
| 资源名称 | 描述 |
|
||||
| ------------------------------- | ------------------------------------------------- |
|
||||
| `configmaps` | 在该命名空间中允许存在的 ConfigMap 总数上限。 |
|
||||
| `persistentvolumeclaims` | 在该命名空间中允许存在的 [PVC](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 的总数上限。 |
|
||||
| `persistentvolumeclaims` | 在该命名空间中允许存在的 [PVC](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 的总数上限。 |
|
||||
| `pods` | 在该命名空间中允许存在的非终止状态的 pod 总数上限。Pod 终止状态等价于 Pod 的 `.status.phase in (Failed, Succeeded)` = true |
|
||||
| `replicationcontrollers` | 在该命名空间中允许存在的 RC 总数上限。 |
|
||||
| `resourcequotas` | 在该命名空间中允许存在的资源配额总数上限。 |
|
||||
|
|
@ -387,7 +387,7 @@ Pods can be created at a specific [priority](/docs/concepts/configuration/pod-pr
|
|||
You can control a pod's consumption of system resources based on a pod's priority, by using the `scopeSelector`
|
||||
field in the quota spec.
|
||||
-->
|
||||
Pod 可以创建为特定的[优先级](/zh/docs/concepts/configuration/pod-priority-preemption/#pod-priority)。
|
||||
Pod 可以创建为特定的[优先级](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)。
|
||||
通过使用配额规约中的 `scopeSelector` 字段，用户可以根据 Pod 的优先级控制其系统资源消耗。
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -520,6 +520,6 @@ arbitrary tolerations to DaemonSets.
|
|||
* Read about [pod priority](/docs/concepts/configuration/pod-priority-preemption/)
|
||||
-->
|
||||
* 阅读[资源耗尽的处理](/zh/docs/tasks/administer-cluster/out-of-resource/)，以及如何配置其行为
|
||||
* 阅读 [Pod 优先级](/zh/docs/concepts/configuration/pod-priority-preemption/)
|
||||
* 阅读 [Pod 优先级](/docs/concepts/configuration/pod-priority-preemption/)
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ automatically provisions storage when it is requested by users.
|
|||
-->
|
||||
动态卷供应允许按需创建存储卷。
|
||||
如果没有动态供应，集群管理员必须手动地联系他们的云或存储提供商来创建新的存储卷，
|
||||
然后在 Kubernetes 集群创建 [`PersistentVolume` 对象](/zh/docs/concepts/storage/persistent-volumes/)来表示这些卷。
|
||||
然后在 Kubernetes 集群创建 [`PersistentVolume` 对象](/docs/concepts/storage/persistent-volumes/)来表示这些卷。
|
||||
动态供应功能消除了集群管理员预先配置存储的需要。 相反，它在用户请求时自动供应存储。
|
||||
|
||||
<!-- body -->
|
||||
|
|
@ -199,7 +199,7 @@ Zones in a Region. Single-Zone storage backends should be provisioned in the Zon
|
|||
Pods are scheduled. This can be accomplished by setting the [Volume Binding
|
||||
Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode).
|
||||
-->
|
||||
在[多区域](/zh/docs/setup/best-practices/multiple-zones/)集群中，Pod 可以被分散到多个区域。
|
||||
在[多区域](/docs/setup/best-practices/multiple-zones/)集群中，Pod 可以被分散到多个区域。
|
||||
单区域存储后端应该被供应到 Pod 被调度到的区域。
|
||||
这可以通过设置[卷绑定模式](/zh/docs/concepts/storage/storage-classes/#volume-binding-mode)来实现。
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ with [volumes](/docs/concepts/storage/volumes/) and
|
|||
[persistent volumes](/docs/concepts/storage/persistent-volumes) is suggested.
|
||||
-->
|
||||
本文描述了 Kubernetes 中 StorageClass 的概念。建议先熟悉 [卷](/zh/docs/concepts/storage/volumes/) 和
|
||||
[持久卷](/zh/docs/concepts/storage/persistent-volumes) 的概念。
|
||||
[持久卷](/docs/concepts/storage/persistent-volumes) 的概念。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -67,7 +67,7 @@ for details.
|
|||
-->
|
||||
管理员可以为没有申请绑定到特定 StorageClass 的 PVC 指定一个默认的存储类 ：
|
||||
更多详情请参阅
|
||||
[PersistentVolumeClaim 章节](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
|
||||
[PersistentVolumeClaim 章节](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
|
||||
|
||||
```yaml
|
||||
apiVersion: storage.k8s.io/v1
|
||||
|
|
@ -240,7 +240,7 @@ the class or PV, so mount of the PV will simply fail if one is invalid.
|
|||
The `volumeBindingMode` field controls when [volume binding and dynamic
|
||||
provisioning](/docs/concepts/storage/persistent-volumes/#provisioning) should occur.
|
||||
-->
|
||||
`volumeBindingMode` 字段控制了[卷绑定和动态分配](/zh/docs/concepts/storage/persistent-volumes/#provisioning)
|
||||
`volumeBindingMode` 字段控制了[卷绑定和动态分配](/docs/concepts/storage/persistent-volumes/#provisioning)
|
||||
应该发生在什么时候。
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ weight: 20
|
|||
In Kubernetes, a _VolumeSnapshot_ represents a snapshot of a volume on a storage system. This document assumes that you are already familiar with Kubernetes [persistent volumes](/docs/concepts/storage/persistent-volumes/).
|
||||
-->
|
||||
在 Kubernetes 中，卷快照是一个存储系统上卷的快照，本文假设你已经熟悉了 Kubernetes
|
||||
的 [持久卷](/zh/docs/concepts/storage/persistent-volumes/)。
|
||||
的 [持久卷](/docs/concepts/storage/persistent-volumes/)。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -260,5 +260,5 @@ the *dataSource* field in the `PersistentVolumeClaim` object.
|
|||
For more details, see
|
||||
[Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
|
||||
-->
|
||||
更多详细信息，请参阅 [卷快照和从快照还原卷](/zh/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)。
|
||||
更多详细信息，请参阅 [卷快照和从快照还原卷](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)。
|
||||
|
||||
|
|
|
|||
|
|
@ -916,7 +916,7 @@ Watch out when using this type of volume, because:
|
|||
* 具有相同配置（例如从 podTemplate 创建）的多个 Pod 会由于节点上文件的不同而在不同节点上有不同的行为。
|
||||
* 当 Kubernetes 按照计划添加资源感知的调度时，这类调度机制将无法考虑由 `hostPath` 使用的资源。
|
||||
* 基础主机上创建的文件或目录只能由 root 用户写入。您需要在
|
||||
[特权容器](/zh/docs/tasks/configure-pod-container/security-context/)
|
||||
[特权容器](/docs/tasks/configure-pod-container/security-context/)
|
||||
中以 root 身份运行进程，或者修改主机上的文件权限以便容器能够写入 `hostPath` 卷。
|
||||
|
||||
<!--
|
||||
|
|
@ -1190,7 +1190,7 @@ A `persistentVolumeClaim` volume is used to mount a
|
|||
way for users to "claim" durable storage (such as a GCE PersistentDisk or an
|
||||
iSCSI volume) without knowing the details of the particular cloud environment.
|
||||
-->
|
||||
`persistentVolumeClaim` 卷用来将[持久卷](/zh/docs/concepts/storage/persistent-volumes/)（PersistentVolume）挂载到 Pod 中。
|
||||
`persistentVolumeClaim` 卷用来将[持久卷](/docs/concepts/storage/persistent-volumes/)（PersistentVolume）挂载到 Pod 中。
|
||||
持久卷是用户在不知道特定云环境细节的情况下"申领"持久存储（例如 GCE PersistentDisk 或者 iSCSI 卷）的一种方法。
|
||||
|
||||
<!--
|
||||
|
|
@ -1198,7 +1198,7 @@ See the [PersistentVolumes example](/docs/concepts/storage/persistent-volumes/)
|
|||
details.
|
||||
-->
|
||||
|
||||
更多详情请参考[持久卷示例](/zh/docs/concepts/storage/persistent-volumes/)
|
||||
更多详情请参考[持久卷示例](/docs/concepts/storage/persistent-volumes/)
|
||||
|
||||
### projected {#projected}
|
||||
|
||||
|
|
@ -1887,7 +1887,7 @@ specification, and to select the type of media to use, for clusters that have
|
|||
several media types.
|
||||
-->
|
||||
将来，我们希望 `emptyDir` 卷和 `hostPath` 卷能够使用
|
||||
[resource](/zh/docs/concepts/configuration/manage-compute-resources-containers/)
|
||||
[resource](/zh/docs/concepts/configuration/manage-resources-containers/)
|
||||
规约来请求一定量的空间，
|
||||
并且能够为具有多种介质类型的集群选择要使用的介质类型。
|
||||
|
||||
|
|
@ -2115,7 +2115,7 @@ CSI块卷支持功能已启用，但默认情况下启用。必须为此功能
|
|||
Learn how to
|
||||
[setup your PV/PVC with raw block volume support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support).
|
||||
-->
|
||||
学习怎样[安装您的带有块卷支持的 PV/PVC](/zh/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)。
|
||||
学习怎样[安装您的带有块卷支持的 PV/PVC](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)。
|
||||
|
||||
<!--
|
||||
#### CSI ephemeral volumes
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ A _Cron Job_ creates [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-com
|
|||
One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically
|
||||
on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format.
|
||||
-->
|
||||
_Cron Job_ 创建基于时间调度的 [Jobs](/zh/docs/concepts/workloads/controllers/jobs-run-to-completion/)。
|
||||
_Cron Job_ 创建基于时间调度的 [Jobs](/zh/docs/concepts/workloads/controllers/job/)。
|
||||
|
||||
一个 CronJob 对象就像 _crontab_ (cron table) 文件中的一行。
|
||||
它用 [Cron](https://en.wikipedia.org/wiki/Cron) 格式进行编写，
|
||||
|
|
|
|||
|
|
@ -199,7 +199,7 @@ If you do not specify either, then the DaemonSet controller will create Pods on
|
|||
-->
|
||||
### 仅在某些节点上运行 Pod
|
||||
|
||||
如果指定了 `.spec.template.spec.nodeSelector`，DaemonSet Controller 将在能够与 [Node Selector](/docs/concepts/configuration/assign-pod-node/) 匹配的节点上创建 Pod。类似这种情况，可以指定 `.spec.template.spec.affinity`，然后 DaemonSet Controller 将在能够与 [node Affinity](/docs/concepts/configuration/assign-pod-node/) 匹配的节点上创建 Pod。
|
||||
如果指定了 `.spec.template.spec.nodeSelector`，DaemonSet Controller 将在能够与 [Node Selector](/zh/docs/concepts/scheduling-eviction/assign-pod-node/) 匹配的节点上创建 Pod。类似这种情况，可以指定 `.spec.template.spec.affinity`，然后 DaemonSet Controller 将在能够与 [node Affinity](/zh/docs/concepts/scheduling-eviction/assign-pod-node/) 匹配的节点上创建 Pod。
|
||||
如果根本就没有指定，则 DaemonSet Controller 将在所有节点上创建 Pod。
|
||||
|
||||
<!--
|
||||
|
|
@ -232,7 +232,7 @@ DaemonSet 确保所有符合条件的节点都运行该 Pod 的一个副本。
|
|||
|
||||
* Pod 行为的不一致性：正常 Pod 在被创建后等待调度时处于 `Pending` 状态，
|
||||
DaemonSet Pods 创建后不会处于 `Pending` 状态下。这使用户感到困惑。
|
||||
* [Pod 抢占](/zh/docs/concepts/configuration/pod-priority-preemption/)
|
||||
* [Pod 抢占](/docs/concepts/configuration/pod-priority-preemption/)
|
||||
由默认调度器处理。启用抢占后，DaemonSet 控制器将在不考虑 Pod 优先级和抢占
|
||||
的情况下制定调度决策。
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ A _Deployment_ controller provides declarative updates for [Pods](/docs/concepts
|
|||
[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/).
|
||||
|
||||
-->
|
||||
一个 _Deployment_ 控制器为 [Pods](/docs/concepts/workloads/pods/pod/)和 [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/)提供描述性的更新方式。
|
||||
一个 _Deployment_ 控制器为 [Pods](/zh/docs/concepts/workloads/pods/)和 [ReplicaSets](/zh/docs/concepts/workloads/controllers/replicaset/)提供描述性的更新方式。
|
||||
|
||||
<!--
|
||||
|
||||
|
|
@ -1030,7 +1030,7 @@ deployment.apps/nginx-deployment scaled
|
|||
in your cluster, you can setup an autoscaler for your Deployment and choose the minimum and maximum number of
|
||||
Pods you want to run based on the CPU utilization of your existing Pods.
|
||||
-->
|
||||
假设启用[水平自动缩放 Pod](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)在集群中，可以为 Deployment 设置自动缩放器，并选择最小和最大
|
||||
假设启用[水平自动缩放 Pod](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)在集群中，可以为 Deployment 设置自动缩放器，并选择最小和最大
|
||||
要基于现有 Pods 的 CPU 利用率运行的 Pods。
|
||||
|
||||
```shell
|
||||
|
|
@ -1726,7 +1726,7 @@ thus that Deployment will not be able to roll back.
|
|||
can create multiple Deployments, one for each release, following the canary pattern described in
|
||||
[managing resources](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments).
|
||||
-->
|
||||
如果要使用 Deployment 向用户或服务器子集展开版本，则可以创建多个 Deployments ，每个版本一个，遵循[资源管理](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)。
|
||||
如果要使用 Deployment 向用户或服务器子集展开版本，则可以创建多个 Deployments ，每个版本一个，遵循[资源管理](/zh/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)。
|
||||
|
||||
<!--
|
||||
## Writing a Deployment Spec
|
||||
|
|
@ -1738,7 +1738,7 @@ can create multiple Deployments, one for each release, following the canary patt
|
|||
For general information about working with config files, see [deploying applications](/docs/tutorials/stateless-application/run-stateless-application-deployment/),
|
||||
configuring containers, and [using kubectl to manage resources](/docs/concepts/overview/working-with-objects/object-management/) documents.
|
||||
-->
|
||||
同其他 Kubernetes 配置， Deployment 需要 `apiVersion`， `kind`， 和 `metadata` 字段。有关配置文件的其他信息，参考 [应用 Deployment ](/docs/tutorials/stateless-application/run-stateless-application-deployment/)，配置容器，和 [使用 kubectl 管理资源](/docs/concepts/overview/working-with-objects/object-management/) 相关文档。
|
||||
同其他 Kubernetes 配置， Deployment 需要 `apiVersion`， `kind`， 和 `metadata` 字段。有关配置文件的其他信息，参考 [应用 Deployment ](/zh/docs/tasks/run-application/run-stateless-application-deployment/)，配置容器，和 [使用 kubectl 管理资源](/zh/docs/concepts/overview/working-with-objects/object-management/) 相关文档。
|
||||
|
||||
<!--
|
||||
A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
|
||||
|
|
@ -1759,7 +1759,7 @@ configuring containers, and [using kubectl to manage resources](/docs/concepts/o
|
|||
The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an
|
||||
`apiVersion` or `kind`.
|
||||
-->
|
||||
`.spec.template` 是一个 [Pod 示例](/docs/concepts/workloads/pods/pod-overview/#pod-templates)。它和 [Pod](/docs/concepts/workloads/pods/pod/)的约束完全相同，除了它是嵌套的，而且没有 `apiVersion` 或 `kind`。
|
||||
`.spec.template` 是一个 [Pod 示例](/zh/docs/concepts/workloads/pods/#pod-templates)。它和 [Pod](/zh/docs/concepts/workloads/pods)的约束完全相同，除了它是嵌套的，而且没有 `apiVersion` 或 `kind`。
|
||||
|
||||
<!--
|
||||
In addition to required fields for a Pod, a Pod template in a Deployment must specify appropriate
|
||||
|
|
@ -1768,10 +1768,10 @@ labels and an appropriate restart policy. For labels, make sure not to overlap w
|
|||
除了 Pod 的必填字段外， Deployment 中的 Pod 模板必须指定适当的标签和适当的重新启动策略。对于标签，请确保不要与其他控制器重叠。请参考[选择器](#selector))。
|
||||
|
||||
<!--
|
||||
Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Always` is
|
||||
Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/#restart-policy) equal to `Always` is
|
||||
allowed, which is the default if not specified.
|
||||
-->
|
||||
只有 [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always` 被允许，这是在没有指定时的默认设置。
|
||||
只有 [`.spec.template.spec.restartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always` 被允许，这是在没有指定时的默认设置。
|
||||
|
||||
<!--
|
||||
### Replicas
|
||||
|
|
@ -1792,7 +1792,7 @@ allowed, which is the default if not specified.
|
|||
`.spec.selector` is an required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/)
|
||||
for the Pods targeted by this Deployment.
|
||||
-->
|
||||
`.spec.selector` 是指定本次 Deployment Pods [标签选择器](/docs/concepts/overview/working-with-objects/labels/)的必要字段。
|
||||
`.spec.selector` 是指定本次 Deployment Pods [标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/)的必要字段。
|
||||
|
||||
<!--
|
||||
`.spec.selector` must match `.spec.template.metadata.labels`, or it will be rejected by the API.
|
||||
|
|
@ -1857,7 +1857,7 @@ the default value.
|
|||
fashion when `.spec.strategy.type==RollingUpdate`. You can specify `maxUnavailable` and `maxSurge` to control
|
||||
the rolling update process.
|
||||
-->
|
||||
Deployment 会在 `.spec.strategy.type==RollingUpdate`时，采取 [滚动更新](/docs/tasks/run-application/rolling-update-replication-controller/)的方式更新Pods。可以指定 `maxUnavailable` 和 `maxSurge` 来控制滚动更新操作。
|
||||
Deployment 会在 `.spec.strategy.type==RollingUpdate`时，采取滚动更新的方式更新Pods。可以指定 `maxUnavailable` 和 `maxSurge` 来控制滚动更新操作。
|
||||
|
||||
<!--
|
||||
##### Max Unavailable
|
||||
|
|
@ -1932,7 +1932,7 @@ created Pod should be ready without any of its containers crashing, for it to be
|
|||
This defaults to 0 (the Pod will be considered available as soon as it is ready). To learn more about when
|
||||
a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
|
||||
-->
|
||||
`.spec.minReadySeconds` 是一个可选字段，用于指定新创建的 Pod 在没有任意容器崩溃情况下的最小就绪时间，以便将其视为可用。默认值为 0（Pod 在准备就绪后立即将被视为可用）。了解有关何时Pod 被视为已准备就绪，参考[容器探针](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
|
||||
`.spec.minReadySeconds` 是一个可选字段，用于指定新创建的 Pod 在没有任意容器崩溃情况下的最小就绪时间，以便将其视为可用。默认值为 0（Pod 在准备就绪后立即将被视为可用）。了解有关何时Pod 被视为已准备就绪，参考[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
|
||||
|
||||
<!--
|
||||
### Rollback To
|
||||
|
|
|
|||
|
|
@ -812,7 +812,7 @@ for pods with `RestartPolicy` equal to `OnFailure` or `Never`.
|
|||
-->
|
||||
### 副本控制器 {#replication-controller}
|
||||
|
||||
Job 与[副本控制器](/docs/user-guide/replication-controller)是彼此互补的。
|
||||
Job 与[副本控制器](/zh/docs/concepts/workloads/controllers/replicationcontroller/)是彼此互补的。
|
||||
副本控制器管理的是那些不希望被终止的 Pod （例如，Web 服务器），
|
||||
Job 管理的是那些希望被终止的 Pod（例如，批处理作业）。
|
||||
|
||||
|
|
|
|||
|
|
@ -81,9 +81,9 @@ their ReplicaSets.
|
|||
-->
|
||||
## 怎样使用 ReplicaSet {#how-to-use-a-replicaset}
|
||||
|
||||
大多数支持 Replication Controllers 的[`kubectl`](/docs/user-guide/kubectl/)命令也支持 ReplicaSets。但[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是个例外。如果您想要滚动更新功能请考虑使用 Deployment。[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是必需的，而 Deployment 是声明性的，因此我们建议通过 [`rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)命令使用 Deployment。
|
||||
大多数支持 Replication Controllers 的[`kubectl`](/zh/docs/reference/kubectl/kubectl/)命令也支持 ReplicaSets。但[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是个例外。如果您想要滚动更新功能请考虑使用 Deployment。[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是必需的，而 Deployment 是声明性的，因此我们建议通过 [`rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)命令使用 Deployment。
|
||||
|
||||
虽然 ReplicaSets 可以独立使用，但今天它主要被[Deployments](/docs/concepts/workloads/controllers/deployment/) 用作协调 Pod 创建、删除和更新的机制。
|
||||
虽然 ReplicaSets 可以独立使用，但今天它主要被[Deployments](/zh/docs/concepts/workloads/controllers/deployment/) 用作协调 Pod 创建、删除和更新的机制。
|
||||
当您使用 Deployment 时，您不必担心还要管理它们创建的 ReplicaSet。Deployment 会拥有并管理它们的 ReplicaSet。
|
||||
|
||||
<!--
|
||||
|
|
@ -171,7 +171,7 @@ A ReplicaSet also needs a [`.spec` section](https://git.k8s.io/community/contrib
|
|||
|
||||
## 编写 ReplicaSet Spec
|
||||
|
||||
与所有其他 Kubernetes API 对象一样，ReplicaSet 也需要 `apiVersion`、`kind`、和 `metadata` 字段。有关使用清单的一般信息，请参见 [使用 kubectl 管理对象](/docs/concepts/overview/object-management-kubectl/overview/)。
|
||||
与所有其他 Kubernetes API 对象一样，ReplicaSet 也需要 `apiVersion`、`kind`、和 `metadata` 字段。有关使用清单的一般信息，请参见 [使用 kubectl 管理对象](/zh/docs/concepts/overview/working-with-objects/object-management/)。
|
||||
|
||||
ReplicaSet 也需要 [`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) 部分。
|
||||
|
||||
|
|
@ -195,15 +195,15 @@ for example the [Kubelet](/docs/admin/kubelet/) or Docker.
|
|||
|
||||
### Pod 模版
|
||||
|
||||
`.spec.template` 是 `.spec` 唯一需要的字段。`.spec.template` 是 [Pod 模版](/docs/concepts/workloads/pods/pod-overview/#pod-templates)。它和 [Pod](/docs/concepts/workloads/pods/pod/) 的语法几乎完全一样，除了它是嵌套的并没有 `apiVersion` 和 `kind`。
|
||||
`.spec.template` 是 `.spec` 唯一需要的字段。`.spec.template` 是 [Pod 模版](/zh/docs/concepts/workloads/pods/#pod-templates)。它和 [Pod](/zh/docs/concepts/workloads/pods/) 的语法几乎完全一样，除了它是嵌套的并没有 `apiVersion` 和 `kind`。
|
||||
|
||||
除了所需的 Pod 字段之外，ReplicaSet 中的 Pod 模板必须指定适当的标签和适当的重启策略。
|
||||
|
||||
对于标签，请确保不要与其他控制器重叠。更多信息请参考 [Pod 选择器](#pod-selector)。
|
||||
|
||||
对于 [重启策略](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)，`.spec.template.spec.restartPolicy` 唯一允许的取值是 `Always`，这也是默认值.
|
||||
对于 [重启策略](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)，`.spec.template.spec.restartPolicy` 唯一允许的取值是 `Always`，这也是默认值.
|
||||
|
||||
对于本地容器重新启动，ReplicaSet 委托给了节点上的代理去执行，例如[Kubelet](/docs/admin/kubelet/) 或 Docker 去执行。
|
||||
对于本地容器重新启动，ReplicaSet 委托给了节点上的代理去执行，例如[Kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 或 Docker 去执行。
|
||||
|
||||
<!--
|
||||
### Pod Selector
|
||||
|
|
@ -221,7 +221,7 @@ In Kubernetes 1.9 the API version `apps/v1` on the ReplicaSet kind is the curren
|
|||
|
||||
### Pod 选择器
|
||||
|
||||
`.spec.selector` 字段是[标签选择器](/docs/concepts/overview/working-with-objects/labels/)。ReplicaSet 管理所有标签匹配与标签选择器的 Pod。它不区分自己创建或删除的 Pod 和其他人或进程创建或删除的pod。这允许在不影响运行中的 Pod 的情况下替换副本集。
|
||||
`.spec.selector` 字段是[标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/)。ReplicaSet 管理所有标签匹配与标签选择器的 Pod。它不区分自己创建或删除的 Pod 和其他人或进程创建或删除的pod。这允许在不影响运行中的 Pod 的情况下替换副本集。
|
||||
|
||||
`.spec.template.metadata.labels` 必须匹配 `.spec.selector`，否则它将被 API 拒绝。
|
||||
|
||||
|
|
@ -279,7 +279,7 @@ When using the REST API or the `client-go` library, you must set `propagationPol
|
|||
### 删除 ReplicaSet 和它的 Pod
|
||||
|
||||
要删除 ReplicaSet 和它的所有 Pod，使用[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 命令。
|
||||
默认情况下，[垃圾收集器](/docs/concepts/workloads/controllers/garbage-collection/) 自动删除所有依赖的 Pod。
|
||||
默认情况下，[垃圾收集器](/zh/docs/concepts/workloads/controllers/garbage-collection/) 自动删除所有依赖的 Pod。
|
||||
|
||||
当使用 REST API 或 `client-go` 库时，您必须在删除选项中将 `propagationPolicy` 设置为 `Background` 或 `Foreground`。例如：
|
||||
|
||||
|
|
@ -405,9 +405,9 @@ application using a Deployment, please read [Run a Stateless Application Using a
|
|||
|
||||
### Deployment （推荐）
|
||||
|
||||
[`Deployment`](/docs/concepts/workloads/controllers/deployment/) 是一个高级 API 对象，它以 `kubectl rolling-update` 的方式更新其底层副本集及其Pod。
|
||||
[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 是一个高级 API 对象，它以 `kubectl rolling-update` 的方式更新其底层副本集及其Pod。
|
||||
如果您需要滚动更新功能，建议使用 Deployment，因为 Deployment 与 `kubectl rolling-update` 不同的是：它是声明式的、服务器端的、并且具有其他特性。
|
||||
有关使用 Deployment 来运行无状态应用的更多信息，请参阅 [使用 Deployment 运行无状态应用](/docs/tasks/run-application/run-stateless-application-deployment/)。
|
||||
有关使用 Deployment 来运行无状态应用的更多信息，请参阅 [使用 Deployment 运行无状态应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)。
|
||||
|
||||
<!--
|
||||
### Bare Pods
|
||||
|
|
@ -431,7 +431,7 @@ Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead o
|
|||
|
||||
### Job
|
||||
|
||||
使用[`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) 代替ReplicaSet，可以用于那些期望自行终止的 Pod。
|
||||
使用[`Job`](/zh/docs/concepts/workloads/controllers/job/) 代替ReplicaSet，可以用于那些期望自行终止的 Pod。
|
||||
|
||||
<!--
|
||||
### DaemonSet
|
||||
|
|
@ -444,7 +444,7 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown.
|
|||
|
||||
### DaemonSet
|
||||
|
||||
对于管理那些提供主机级别功能（如主机监控和主机日志）的容器，就要用[`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) 而不用 ReplicaSet。
|
||||
对于管理那些提供主机级别功能（如主机监控和主机日志）的容器，就要用[`DaemonSet`](/zh/docs/concepts/workloads/controllers/daemonset/) 而不用 ReplicaSet。
|
||||
这些 Pod 的寿命与主机寿命有关：这些 Pod 需要先于主机上的其他 Pod 运行，并且在机器准备重新启动/关闭时安全地终止。
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -211,7 +211,7 @@ for example the [Kubelet](/docs/admin/kubelet/) or Docker.
|
|||
只允许 [`.spec.template.spec.restartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always`，如果没有指定，这是默认值。
|
||||
|
||||
对于本地容器重启，ReplicationController 委托给节点上的代理，
|
||||
例如 [Kubelet](/docs/reference/command-line-toolls-reference/kubelet/) 或 Docker。
|
||||
例如 [Kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 或 Docker。
|
||||
|
||||
<!--
|
||||
### Labels on the ReplicationController
|
||||
|
|
@ -546,7 +546,7 @@ Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead o
|
|||
### Job
|
||||
|
||||
对于预期会自行终止的 Pod (即批处理任务)，使用
|
||||
[`Job`](/docs/concepts/workloads/controllers/job/) 而不是 ReplicationController。
|
||||
[`Job`](/zh/docs/concepts/workloads/controllers/job/) 而不是 ReplicationController。
|
||||
|
||||
<!--
|
||||
### DaemonSet
|
||||
|
|
|
|||
|
|
@ -140,7 +140,7 @@ spec:
|
|||
* 名为 `nginx` 的 Headless Service 用来控制网络域名。
|
||||
* 名为 `web` 的 StatefulSet 有一个 Spec，它表明将在独立的 3 个 Pod 副本中启动 nginx 容器。
|
||||
* `volumeClaimTemplates` 将通过 PersistentVolumes 驱动提供的
|
||||
[PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
|
||||
[PersistentVolumes](/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
|
||||
|
||||
<!--
|
||||
## Pod Selector
|
||||
|
|
@ -232,7 +232,7 @@ This must be done manually.
|
|||
-->
|
||||
### 稳定的存储 {#stable-storage}
|
||||
|
||||
Kubernetes 为每个 VolumeClaimTemplate 创建一个 [PersistentVolume](/zh/docs/concepts/storage/persistent-volumes/)。
|
||||
Kubernetes 为每个 VolumeClaimTemplate 创建一个 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)。
|
||||
在上面的 nginx 示例中，每个 Pod 将会得到基于 StorageClass `my-storage-class` 提供的
|
||||
1 Gib 的 PersistentVolume。如果没有声明 StorageClass，就会使用默认的 StorageClass。
|
||||
当一个 Pod 被调度（重新调度）到节点上时，它的 `volumeMounts` 会挂载与其
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ up finished Jobs (either `Complete` or `Failed`) automatically by specifying the
|
|||
|
||||
TTL 控制器现在只支持 Job。集群操作员可以通过指定 Job 的 `.spec.ttlSecondsAfterFinished`
|
||||
字段来自动清理已结束的作业（`Complete` 或 `Failed`），如
|
||||
[示例](/zh/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
|
||||
[示例](/zh/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
|
||||
所示。
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -286,7 +286,7 @@ PodTemplates are specifications for creating Pods, and are included in workload
|
|||
|
||||
Pod 模板是包含在工作负载对象中的规范，用来创建 Pod。这类负载资源包括
|
||||
[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)、
|
||||
[Job](/zh/docs/concepts/workloads/containers/job/) 和
|
||||
[Job](/zh/docs/concepts/workloads/controllers/job/) 和
|
||||
[DaemonSets](/zh/docs/concepts/workloads/controllers/daemonset/)等。
|
||||
|
||||
<!--
|
||||
|
|
@ -431,7 +431,7 @@ Processes within a privileged container get almost the same privileges that are
|
|||
## 容器的特权模式 {#rivileged-mode-for-containers}
|
||||
|
||||
Pod 中的任何容器都可以使用容器规约中的
|
||||
[安全性上下文](/zh/docs/tasks/configure-pod-container/security-context/)中的
|
||||
[安全性上下文](/docs/tasks/configure-pod-container/security-context/)中的
|
||||
`privileged` 参数启用特权模式。
|
||||
这对于想要使用使用操作系统管理权能（Capabilities，如操纵网络堆栈和访问设备）
|
||||
的容器很有用。
|
||||
|
|
@ -516,7 +516,7 @@ To understand the context for why Kubernetes wraps a common Pod API in other res
|
|||
或 {{< glossary_tooltip text="Deployment" term_id="deployment" >}}）
|
||||
封装通用的 Pod API，相关的背景信息可以在前人的研究中找到。具体包括：
|
||||
|
||||
* [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
|
||||
* [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
|
||||
* [Borg](https://research.google.com/pubs/pub43438.html)
|
||||
* [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
|
||||
* [Omega](https://research.google/pubs/pub41684/)
|
||||
|
|
|
|||
|
|
@ -147,7 +147,7 @@ or across zones (if using a
|
|||
和[有状态](/zh/docs/tasks/run-application/run-replicated-stateful-application/)应用程序的信息。）
|
||||
- 为了在运行复制应用程序时获得更高的可用性，请跨机架（使用
|
||||
[反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)）或跨区域
|
||||
（如果使用[多区域集群](/zh/docs/setup/best-practices/multiple-zones/)）扩展应用程序。
|
||||
（如果使用[多区域集群](/docs/setup/best-practices/multiple-zones/)）扩展应用程序。
|
||||
|
||||
<!--
|
||||
The frequency of voluntary disruptions varies. On a basic Kubernetes cluster, there are
|
||||
|
|
@ -204,7 +204,7 @@ instead of directly deleting pods or deployments. Examples are the `kubectl dra
|
|||
and the Kubernetes-on-GCE cluster upgrade script (`cluster/gce/upgrade.sh`).
|
||||
-->
|
||||
集群管理员和托管提供商应该使用遵循 Pod Disruption Budgets 的接口
|
||||
（通过调用[Eviction API](/zh/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)），
|
||||
（通过调用[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)），
|
||||
而不是直接删除 Pod 或 Deployment。
|
||||
|
||||
<!--
|
||||
|
|
@ -267,7 +267,7 @@ hornoring the
|
|||
`terminationGracePeriodSeconds` setting in its [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).)
|
||||
-->
|
||||
当使用驱逐 API 驱逐 Pod 时，Pod 会被体面地
|
||||
[终止](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)，期间会
|
||||
[终止](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)，期间会
|
||||
参考 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
|
||||
中的 `terminationGracePeriodSeconds` 配置值。
|
||||
|
||||
|
|
@ -497,7 +497,7 @@ the nodes in your cluster, such as a node or system software upgrade, here are s
|
|||
including steps to maintain its availability during the rollout.
|
||||
-->
|
||||
* 参考[配置 Pod 干扰预算](/zh/docs/tasks/run-application/configure-pdb/)中的方法来保护你的应用。
|
||||
* 进一步了解[排空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)的信息。
|
||||
* 进一步了解[排空节点](/docs/tasks/administer-cluster/safely-drain-node/)的信息。
|
||||
* 了解[更新 Deployment](/zh/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)
|
||||
的过程，包括如何在其进程中维持应用的可用性
|
||||
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ feature could change significantly in the future or be removed entirely.
|
|||
{{< warning >}}
|
||||
临时容器处于早期的 alpha 阶段，不适用于生产环境集群。
|
||||
应该预料到临时容器在某些情况下不起作用，例如在定位容器的命名空间时。
|
||||
根据 [Kubernetes 弃用政策](/zh/docs/reference/using-api/deprecation-policy/)，
|
||||
根据 [Kubernetes 弃用政策](/docs/reference/using-api/deprecation-policy/)，
|
||||
此 alpha 功能将来可能发生重大变化或被完全删除。
|
||||
{{< /warning >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -1017,7 +1017,7 @@ for more information.
|
|||
-->
|
||||
|
||||
该准入控制器根据与 PodPreset 中条件的匹配情况，将指定字段注入一个 pod。
|
||||
另请参见 [PodPreset 概念](/docs/concepts/workloads/pods/podpreset/)和[使用 PodPreset 将信息注入 Pod](/docs/tasks/inject-data-application/podpreset) 获取详情。
|
||||
另请参见 [PodPreset 概念](/zh/docs/concepts/workloads/pods/podpreset/)和[使用 PodPreset 将信息注入 Pod](/zh/docs/tasks/inject-data-application/podpreset) 获取详情。
|
||||
|
||||
### PodSecurityPolicy {#podsecuritypolicy}
|
||||
|
||||
|
|
|
|||
|
|
@ -576,7 +576,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
|||
- `EnableAggregatedDiscoveryTimeout` （ *已弃用* ）：对聚集的发现调用启用五秒钟超时设置。
|
||||
- `EnableEquivalenceClassCache`：调度 Pod 时，使 scheduler 缓存节点的等效项。
|
||||
- `EphemeralContainers`：启用添加 {{< glossary_tooltip text="临时容器" term_id="ephemeral-container" >}} 到正在运行的 Pod 的特性。
|
||||
- `EvenPodsSpread`：使 Pod 能够在拓扑域之间平衡调度。请参阅 [Pod 拓扑扩展约束](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。
|
||||
- `EvenPodsSpread`：使 Pod 能够在拓扑域之间平衡调度。请参阅 [Pod 拓扑扩展约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。
|
||||
- `ExpandInUsePersistentVolumes`：启用扩展使用中的 PVC。请查阅 [调整使用中的 PersistentVolumeClaim 的大小](/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim)。
|
||||
- `ExpandPersistentVolumes`：启用持久卷的扩展。请查阅[扩展永久卷声明](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)。
|
||||
- `ExperimentalCriticalPodAnnotation`：启用将特定 Pod 注解为 *critical* 的方式，用于[确保其调度](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)。从 v1.13 开始，Pod 优先级和抢占功能已弃用此特性。
|
||||
|
|
@ -650,7 +650,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
|||
- `PersistentLocalVolumes`：在 Pod 中启用 “本地” 卷类型的使用。如果请求 “本地” 卷，则必须指定 Pod 亲和力。
|
||||
- `PodOverhead`：启用 [PodOverhead](/docs/concepts/configuration/pod-overhead/) 特性以解决 Pod 开销。
|
||||
- `PodPriority`：根据[优先级](/docs/concepts/configuration/pod-priority-preemption/)启用 Pod 的调度和抢占。
|
||||
- `PodReadinessGates`：启用 `PodReadinessGate` 字段的设置以扩展 Pod 准备状态评估。有关更多详细信息，请参见 [Pod readiness 特性门控](/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)。
|
||||
- `PodReadinessGates`：启用 `PodReadinessGate` 字段的设置以扩展 Pod 准备状态评估。有关更多详细信息，请参见 [Pod readiness 特性门控](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)。
|
||||
|
||||
<!--
|
||||
- `PodShareProcessNamespace`: Enable the setting of `shareProcessNamespace` in a Pod for sharing
|
||||
|
|
@ -710,7 +710,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
|||
- `ServiceLoadBalancerFinalizer`：为服务负载均衡启用终结器保护。
|
||||
- `ServiceNodeExclusion`：启用从云提供商创建的负载均衡中排除节点。如果节点标记有 `alpha.service-controller.kubernetes.io/exclude-balancer` 键或 `node.kubernetes.io/exclude-from-external-load-balancers`，则可以排除节点。
|
||||
- `ServiceTopology`: 启用服务拓扑可以让一个服务基于集群的节点拓扑进行流量路由。有关更多详细信息，请参见[Service 拓扑](https://kubernetes.io/zh/docs/concepts/services-networking/service-topology/)
|
||||
- `StartupProbe`：在 kubelet 中启用 [startup](/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe) 探针。
|
||||
- `StartupProbe`：在 kubelet 中启用 [startup](/zh/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe) 探针。
|
||||
- `StorageObjectInUseProtection`：如果仍在使用 PersistentVolume 或 PersistentVolumeClaim 对象，则将其推迟。
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -37,4 +37,4 @@ tags:
|
|||
<!--
|
||||
A [Pod Disruption Budget](/docs/concepts/workloads/pods/disruptions/) allows an application owner to create an object for a replicated application, that ensures a certain number or percentage of Pods with an assigned label will not be voluntarily evicted at any point in time. PDBs cannot prevent an involuntary disruption, but will count against the budget.
|
||||
-->
|
||||
[Pod Disruption Budget](/docs/concepts/workloads/pods/disruptions/) 使应用所有者能够为多实例应用创建一个对象，来确保一定数量的具有指定标签的 Pod 在任何时候都不会被主动驱逐。 PDB 无法防止非主动的中断，但是会计入预算（budget）。
|
||||
[Pod Disruption Budget](/zh/docs/concepts/workloads/pods/disruptions/) 使应用所有者能够为多实例应用创建一个对象，来确保一定数量的具有指定标签的 Pod 在任何时候都不会被主动驱逐。 PDB 无法防止非主动的中断，但是会计入预算（budget）。
|
||||
|
|
@ -39,4 +39,4 @@ short_description: >
|
|||
<!--
|
||||
The [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/) is a high level summary of where a Pod is in its lifecyle. A Pod’s `status` field is a [PodStatus](/docs/reference/generated/kubernetes-api/v1.13/#podstatus-v1-core) object, which has a `phase` field that displays one of the following phases: Running, Pending, Succeeded, Failed, Unknown, Completed, or CrashLoopBackOff.
|
||||
-->
|
||||
[Pod 生命周期](/docs/concepts/workloads/pods/pod-lifecycle/) 是关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。Pod 的`status` 字段是 [PodStatus](/docs/reference/generated/kubernetes-api/v1.13/#podstatus-v1-core) 对象, 该对象的 `phase` 字段包含了下面的状态: Running、Pending、Succeeded、Failed、Unknown、Completed 或 CrashLoopBackOff。
|
||||
[Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/) 是关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。Pod 的`status` 字段是 [PodStatus](/docs/reference/generated/kubernetes-api/v1.13/#podstatus-v1-core) 对象, 该对象的 `phase` 字段包含了下面的状态: Running、Pending、Succeeded、Failed、Unknown、Completed 或 CrashLoopBackOff。
|
||||
|
|
|
|||
Loading…
Reference in New Issue