[zh]Update concepts pages(part-1) for links with '/zh/' prefix, using new prefix '/zh-cn/'
This commit is contained in:
@@ -73,7 +73,7 @@ The name of a ConfigMap must be a valid
|
||||
-->
|
||||
## ConfigMap 对象
|
||||
|
||||
ConfigMap 是一个 API [对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/),
|
||||
ConfigMap 是一个 API [对象](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/),
|
||||
让你可以存储其他对象所需要使用的配置。
|
||||
和其他 Kubernetes 对象都有一个 `spec` 不同的是,ConfigMap 使用 `data` 和
|
||||
`binaryData` 字段。这些字段能够接收键-值对作为其取值。`data` 和 `binaryData`
|
||||
@@ -81,7 +81,7 @@ ConfigMap 是一个 API [对象](/zh/docs/concepts/overview/working-with-objects
|
||||
则被设计用来保存二进制数据作为 base64 编码的字串。
|
||||
|
||||
ConfigMap 的名字必须是一个合法的
|
||||
[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
|
||||
[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
|
||||
|
||||
<!--
|
||||
Each key under the `data` or the `binaryData` field must consist of
|
||||
@@ -367,7 +367,7 @@ the [KubeletConfiguration struct](/docs/reference/config-api/kubelet-config.v1be
|
||||
kubelet 组件会在每次周期性同步时检查所挂载的 ConfigMap 是否为最新。
|
||||
不过,kubelet 使用的是其本地的高速缓存来获得 ConfigMap 的当前值。
|
||||
高速缓存的类型可以通过
|
||||
[KubeletConfiguration 结构](/zh/docs/reference/config-api/kubelet-config.v1beta1/).
|
||||
[KubeletConfiguration 结构](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/).
|
||||
的 `ConfigMapAndSecretChangeDetectionStrategy` 字段来配置。
|
||||
|
||||
<!--
|
||||
@@ -395,7 +395,7 @@ ConfigMaps consumed as environment variables are not updated automatically and r
|
||||
A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes#using-subpath) volume mount will not receive ConfigMap updates.
|
||||
-->
|
||||
{{< note >}}
|
||||
使用 ConfigMap 作为 [subPath](/zh/docs/concepts/storage/volumes#using-subpath) 卷挂载的容器将不会收到 ConfigMap 的更新。
|
||||
使用 ConfigMap 作为 [subPath](/zh-cn/docs/concepts/storage/volumes#using-subpath) 卷挂载的容器将不会收到 ConfigMap 的更新。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
@@ -432,7 +432,7 @@ You can create an immutable ConfigMap by setting the `immutable` field to `true`
|
||||
For example:
|
||||
-->
|
||||
此功能特性由 `ImmutableEphemeralVolumes`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)来控制。
|
||||
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)来控制。
|
||||
你可以通过将 `immutable` 字段设置为 `true` 创建不可变更的 ConfigMap。
|
||||
例如:
|
||||
|
||||
@@ -465,7 +465,7 @@ to the deleted ConfigMap, it is recommended to recreate these pods.
|
||||
* Read [The Twelve-Factor App](https://12factor.net/) to understand the motivation for
|
||||
separating code from configuration.
|
||||
-->
|
||||
* 阅读 [Secret](/zh/docs/concepts/configuration/secret/)。
|
||||
* 阅读[配置 Pod 使用 ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)。
|
||||
* 阅读[修改 ConfigMap(或任何其他 Kubernetes 对象)](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)。
|
||||
* 阅读 [Secret](/zh-cn/docs/concepts/configuration/secret/)。
|
||||
* 阅读[配置 Pod 使用 ConfigMap](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/)。
|
||||
* 阅读[修改 ConfigMap(或任何其他 Kubernetes 对象)](/zh-cn/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)。
|
||||
* 阅读 [Twelve-Factor 应用](https://12factor.net/zh_cn/)来了解将代码和配置分开的动机。
|
||||
|
||||
@@ -145,8 +145,8 @@ through the Kubernetes API server.
|
||||
-->
|
||||
CPU 和内存统称为“计算资源”,或简称为“资源”。
|
||||
计算资源的数量是可测量的,可以被请求、被分配、被消耗。
|
||||
它们与 [API 资源](/zh/docs/concepts/overview/kubernetes-api/) 不同。
|
||||
API 资源(如 Pod 和 [Service](/zh/docs/concepts/services-networking/service/))是可通过
|
||||
它们与 [API 资源](/zh-cn/docs/concepts/overview/kubernetes-api/) 不同。
|
||||
API 资源(如 Pod 和 [Service](/zh-cn/docs/concepts/services-networking/service/))是可通过
|
||||
Kubernetes API 服务器读取和修改的对象。
|
||||
|
||||
<!--
|
||||
@@ -417,11 +417,11 @@ directly or from your monitoring tools.
|
||||
## 监控计算和内存资源用量
|
||||
|
||||
kubelet 会将 Pod 的资源使用情况作为 Pod
|
||||
[`status`](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status)
|
||||
[`status`](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status)
|
||||
的一部分来报告的。
|
||||
|
||||
如果为集群配置了可选的[监控工具](/zh/docs/tasks/debug/debug-cluster/resource-usage-monitoring/),
|
||||
则可以直接从[指标 API](/zh/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-api)
|
||||
如果为集群配置了可选的[监控工具](/zh-cn/docs/tasks/debug/debug-cluster/resource-usage-monitoring/),
|
||||
则可以直接从[指标 API](/zh-cn/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-api)
|
||||
或者监控工具获得 Pod 的资源使用情况。
|
||||
|
||||
<!--
|
||||
@@ -448,7 +448,7 @@ mount [`emptyDir`](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir
|
||||
|
||||
Pods 通常可以使用临时性本地存储来实现缓冲区、保存日志等功能。
|
||||
kubelet 可以为使用本地临时存储的 Pods 提供这种存储空间,允许后者使用
|
||||
[`emptyDir`](/zh/docs/concepts/storage/volumes/#emptydir) 类型的
|
||||
[`emptyDir`](/zh-cn/docs/concepts/storage/volumes/#emptydir) 类型的
|
||||
{{< glossary_tooltip term_id="volume" text="卷" >}}将其挂载到容器中。
|
||||
|
||||
<!--
|
||||
@@ -465,7 +465,7 @@ of ephemeral local storage a Pod can consume.
|
||||
-->
|
||||
|
||||
kubelet 也使用此类存储来保存
|
||||
[节点层面的容器日志](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level),
|
||||
[节点层面的容器日志](/zh-cn/docs/concepts/cluster-administration/logging/#logging-at-the-node-level),
|
||||
容器镜像文件、以及运行中容器的可写入层。
|
||||
|
||||
{{< caution >}}
|
||||
@@ -502,7 +502,7 @@ Kubernetes 有两种方式支持节点上配置本地临时性存储:
|
||||
(kubelet)来保存数据的。
|
||||
|
||||
kubelet 也会生成
|
||||
[节点层面的容器日志](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level),
|
||||
[节点层面的容器日志](/zh-cn/docs/concepts/cluster-administration/logging/#logging-at-the-node-level),
|
||||
并按临时性本地存储的方式对待之。
|
||||
|
||||
<!--
|
||||
@@ -553,7 +553,7 @@ as you like.
|
||||
无关的其他系统日志);这个文件系统还可以是根文件系统。
|
||||
|
||||
kubelet 也将
|
||||
[节点层面的容器日志](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)
|
||||
[节点层面的容器日志](/zh-cn/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)
|
||||
写入到第一个文件系统中,并按临时性本地存储的方式对待之。
|
||||
|
||||
同时你使用另一个由不同逻辑存储设备支持的文件系统。在这种配置下,你会告诉
|
||||
@@ -587,7 +587,7 @@ than as local ephemeral storage.
|
||||
kubelet 能够度量其本地存储的用量。实现度量机制的前提是:
|
||||
|
||||
- `LocalStorageCapacityIsolation`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
被启用(默认状态),并且
|
||||
- 你已经对节点进行了配置,使之使用所支持的本地临时性储存配置方式之一
|
||||
|
||||
@@ -688,7 +688,7 @@ The scheduler ensures that the sum of the resource requests of the scheduled con
|
||||
当你创建一个 Pod 时,Kubernetes 调度器会为 Pod 选择一个节点来运行之。
|
||||
每个节点都有一个本地临时性存储的上限,是其可提供给 Pods 使用的总量。
|
||||
欲了解更多信息,可参考
|
||||
[节点可分配资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
|
||||
[节点可分配资源](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
|
||||
节。
|
||||
|
||||
调度器会确保所调度的容器的资源请求总和不会超出节点的资源容量。
|
||||
@@ -873,8 +873,8 @@ If you want to use project quotas, you should:
|
||||
|
||||
如果你希望使用项目配额,你需要:
|
||||
|
||||
* 在 [kubelet 配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/)中使用 `featureGates` 字段 或者使用 `--feature-gates` 命令行参数
|
||||
启用 `LocalStorageCapacityIsolationFSQuotaMonitoring=true` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) 。
|
||||
* 在 [kubelet 配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/)中使用 `featureGates` 字段 或者使用 `--feature-gates` 命令行参数
|
||||
启用 `LocalStorageCapacityIsolationFSQuotaMonitoring=true` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 。
|
||||
|
||||
* 确保根文件系统(或者可选的运行时文件系统)启用了项目配额。所有 XFS
|
||||
文件系统都支持项目配额。
|
||||
@@ -933,7 +933,7 @@ for how to advertise device plugin managed resources on each node.
|
||||
##### 设备插件管理的资源 {#device-plugin-managed-resources}
|
||||
|
||||
有关如何颁布在各节点上由设备插件所管理的资源,请参阅
|
||||
[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)。
|
||||
[设备插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)。
|
||||
|
||||
<!--
|
||||
##### Other resources
|
||||
@@ -1011,7 +1011,7 @@ in [scheduler policy configuration](/docs/reference/config-api/kube-scheduler-co
|
||||
集群层面的扩展资源并不绑定到具体节点。
|
||||
它们通常由调度器扩展程序(Scheduler Extenders)管理,这些程序处理资源消耗和资源配额。
|
||||
|
||||
你可以在[调度器策略配置](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/)
|
||||
你可以在[调度器策略配置](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/)
|
||||
中指定由调度器扩展程序处理的扩展资源。
|
||||
|
||||
<!--
|
||||
@@ -1139,7 +1139,7 @@ to limit the number of PIDs that a given Pod can consume. See
|
||||
## PID 限制 {#pid-limiting}
|
||||
|
||||
进程 ID(PID)限制允许对 kubelet 进行配置,以限制给定 Pod 可以消耗的 PID 数量。
|
||||
有关信息,请参见 [PID 限制](/zh/docs/concepts/policy/pid-limiting/)。
|
||||
有关信息,请参见 [PID 限制](/zh-cn/docs/concepts/policy/pid-limiting/)。
|
||||
|
||||
<!--
|
||||
## Troubleshooting
|
||||
@@ -1264,7 +1264,7 @@ For more information on node allocatable resources in Kubernetes, see
|
||||
-->
|
||||
字段 `.status.allocatable` 描述节点上可以用于 Pod 的资源总量(例如:15 个虚拟
|
||||
CPU、7538 MiB 内存)。关于 Kubernetes 中节点可分配资源的信息,可参阅
|
||||
[为系统守护进程预留计算资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/)。
|
||||
[为系统守护进程预留计算资源](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/)。
|
||||
|
||||
<!--
|
||||
You can configure [resource quotas](/docs/concepts/policy/resource-quotas/)
|
||||
@@ -1279,7 +1279,7 @@ You should also consider what access you grant to that namespace:
|
||||
**full** write access to a namespace allows someone with that access to remove any
|
||||
resource, include a configured ResourceQuota.
|
||||
-->
|
||||
你可以配置[资源配额](/zh/docs/concepts/policy/resource-quotas/)功能特性以限制每个名字空间可以使用的资源总量。
|
||||
你可以配置[资源配额](/zh-cn/docs/concepts/policy/resource-quotas/)功能特性以限制每个名字空间可以使用的资源总量。
|
||||
当某名字空间中存在 ResourceQuota 时,Kubernetes 会在该名字空间中的对象强制实施配额。
|
||||
例如,如果你为不同的团队分配名字空间,你可以为这些名字空间添加 ResourceQuota。
|
||||
设置资源配额有助于防止一个团队占用太多资源,以至于这种占用会影响其他团队。
|
||||
@@ -1375,10 +1375,10 @@ memory limit (and possibly request) for that container.
|
||||
* Read about [project quotas](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS
|
||||
* Read more about the [kube-scheduler configuration reference (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
|
||||
-->
|
||||
* 获取[分配内存资源给容器和 Pod ](/zh/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验
|
||||
* 获取[分配 CPU 资源给容器和 Pod ](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验
|
||||
* 获取[分配内存资源给容器和 Pod ](/zh-cn/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验
|
||||
* 获取[分配 CPU 资源给容器和 Pod ](/zh-cn/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验
|
||||
* 阅读 API 参考中 [Container](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)
|
||||
和其[资源请求](/docs/reference/kubernetes-api/workload-resources/pod-v1/#resources)定义。
|
||||
* 阅读 XFS 中[配额](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)的文档
|
||||
* 进一步阅读 [kube-scheduler 配置参考 (v1beta3)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/)
|
||||
* 进一步阅读 [kube-scheduler 配置参考 (v1beta3)](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/)
|
||||
|
||||
|
||||
@@ -58,7 +58,7 @@ For step-by-step instructions on creating and specifying kubeconfig files, see
|
||||
[Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
|
||||
-->
|
||||
有关创建和指定 kubeconfig 文件的分步说明,请参阅
|
||||
[配置对多集群的访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。
|
||||
[配置对多集群的访问](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
@@ -193,7 +193,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files:
|
||||
[Setting the KUBECONFIG environment variable](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable).
|
||||
-->
|
||||
有关设置 `KUBECONFIG` 环境变量的示例,请参阅
|
||||
[设置 KUBECONFIG 环境变量](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。
|
||||
[设置 KUBECONFIG 环境变量](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。
|
||||
|
||||
<!--
|
||||
Otherwise, use the default kubeconfig file, `$HOME/.kube/config`, with no merging.
|
||||
@@ -319,5 +319,5 @@ contexts:
|
||||
* [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
|
||||
--->
|
||||
* [配置对多集群的访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
* [配置对多集群的访问](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
|
||||
|
||||
@@ -77,8 +77,8 @@ This is a living document. If you think of something that is not on this list bu
|
||||
- Don't use naked Pods (that is, Pods not bound to a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) or [Deployment](/docs/concepts/workloads/controllers/deployment/)) if you can avoid it. Naked Pods will not be rescheduled in the event of a node failure.
|
||||
-->
|
||||
- 如果可能,不要使用独立的 Pods(即,未绑定到
|
||||
[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) 或
|
||||
[Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 的 Pod)。
|
||||
[ReplicaSet](/zh-cn/docs/concepts/workloads/controllers/replicaset/) 或
|
||||
[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/) 的 Pod)。
|
||||
如果节点发生故障,将不会重新调度独立的 Pods。
|
||||
|
||||
<!--
|
||||
@@ -86,9 +86,9 @@ This is a living document. If you think of something that is not on this list bu
|
||||
-->
|
||||
|
||||
Deployment 既可以创建一个 ReplicaSet 来确保预期个数的 Pod 始终可用,也可以指定替换 Pod 的策略(例如
|
||||
[RollingUpdate](/zh/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment))。
|
||||
除了一些显式的 [`restartPolicy: Never`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
|
||||
场景外,Deployment 通常比直接创建 Pod 要好得多。[Job](/zh/docs/concepts/workloads/controllers/job/) 也可能是合适的选择。
|
||||
[RollingUpdate](/zh-cn/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment))。
|
||||
除了一些显式的 [`restartPolicy: Never`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
|
||||
场景外,Deployment 通常比直接创建 Pod 要好得多。[Job](/zh-cn/docs/concepts/workloads/controllers/job/) 也可能是合适的选择。
|
||||
|
||||
<!--
|
||||
## Services
|
||||
@@ -99,7 +99,7 @@ Deployment 既可以创建一个 ReplicaSet 来确保预期个数的 Pod 始终
|
||||
- Create a [Service](/docs/concepts/services-networking/service/) before its corresponding backend workloads (Deployments or ReplicaSets), and before any workloads that need to access it. When Kubernetes starts a container, it provides environment variables pointing to all the Services which were running when the container was started. For example, if a Service named `foo` exists, all containers will get the following variables in their initial environment:
|
||||
-->
|
||||
- 在创建相应的后端工作负载(Deployment 或 ReplicaSet),以及在需要访问它的任何工作负载之前创建
|
||||
[服务](/zh/docs/concepts/services-networking/service/)。
|
||||
[服务](/zh-cn/docs/concepts/services-networking/service/)。
|
||||
当 Kubernetes 启动容器时,它提供指向启动容器时正在运行的所有服务的环境变量。
|
||||
例如,如果存在名为 `foo` 的服务,则所有容器将在其初始环境中获得以下变量。
|
||||
|
||||
@@ -118,7 +118,7 @@ Deployment 既可以创建一个 ReplicaSet 来确保预期个数的 Pod 始终
|
||||
- An optional (though strongly recommended) [cluster add-on](/docs/concepts/cluster-administration/addons/) is a DNS server. The
|
||||
DNS server watches the Kubernetes API for new `Services` and creates a set of DNS records for each. If DNS has been enabled throughout the cluster then all `Pods` should be able to do name resolution of `Services` automatically.
|
||||
-->
|
||||
- 一个可选(尽管强烈推荐)的[集群插件](/zh/docs/concepts/cluster-administration/addons/)
|
||||
- 一个可选(尽管强烈推荐)的[集群插件](/zh-cn/docs/concepts/cluster-administration/addons/)
|
||||
是 DNS 服务器。DNS 服务器为新的 `Services` 监视 Kubernetes API,并为每个创建一组 DNS 记录。
|
||||
如果在整个集群中启用了 DNS,则所有 `Pods` 应该能够自动对 `Services` 进行名称解析。
|
||||
|
||||
@@ -135,14 +135,14 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of DN
|
||||
If you only need access to the port for debugging purposes, you can use the [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) or [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
|
||||
-->
|
||||
如果你只需要访问端口以进行调试,则可以使用
|
||||
[apiserver proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)或
|
||||
[`kubectl port-forward`](/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。
|
||||
[apiserver proxy](/zh-cn/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)或
|
||||
[`kubectl port-forward`](/zh-cn/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。
|
||||
|
||||
<!--
|
||||
If you explicitly need to expose a Pod's port on the node, consider using a [NodePort](/docs/concepts/services-networking/service/#type-nodeport) Service before resorting to `hostPort`.
|
||||
-->
|
||||
如果你明确需要在节点上公开 Pod 的端口,请在使用 `hostPort` 之前考虑使用
|
||||
[NodePort](/zh/docs/concepts/services-networking/service/#type-nodeport) 服务。
|
||||
[NodePort](/zh-cn/docs/concepts/services-networking/service/#type-nodeport) 服务。
|
||||
|
||||
<!--
|
||||
- Avoid using `hostNetwork`, for the same reasons as `hostPort`.
|
||||
@@ -154,7 +154,7 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of DN
|
||||
services) (which have a `ClusterIP` of `None`) for service discovery when you don't need `kube-proxy` load balancing.
|
||||
-->
|
||||
- 当你不需要 `kube-proxy` 负载均衡时,使用
|
||||
[无头服务](/zh/docs/concepts/services-networking/service/#headless-services)
|
||||
[无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services)
|
||||
(`ClusterIP` 被设置为 `None`)以便于服务发现。
|
||||
|
||||
<!--
|
||||
@@ -165,7 +165,7 @@ services) (which have a `ClusterIP` of `None`) for service discovery when you do
|
||||
<!--
|
||||
- Define and use [labels](/docs/concepts/overview/working-with-objects/labels/) that identify __semantic attributes__ of your application or Deployment, such as `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. You can use these labels to select the appropriate Pods for other resources; for example, a Service that selects all `tier: frontend` Pods, or all `phase: test` components of `app: myapp`. See the [guestbook](https://github.com/kubernetes/examples/tree/master/guestbook/) app for examples of this approach.
|
||||
-->
|
||||
- 定义并使用[标签](/zh/docs/concepts/overview/working-with-objects/labels/)来识别应用程序
|
||||
- 定义并使用[标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)来识别应用程序
|
||||
或 Deployment 的 __语义属性__,例如`{ app: myapp, tier: frontend, phase: test, deployment: v3 }`。
|
||||
你可以使用这些标签为其他资源选择合适的 Pod;
|
||||
例如,一个选择所有 `tier: frontend` Pod 的服务,或者 `app: myapp` 的所有 `phase: test` 组件。
|
||||
@@ -175,7 +175,7 @@ services) (which have a `ClusterIP` of `None`) for service discovery when you do
|
||||
A Service can be made to span multiple Deployments by omitting release-specific labels from its selector. [Deployments](/docs/concepts/workloads/controllers/deployment/) make it easy to update a running service without downtime.
|
||||
-->
|
||||
通过从选择器中省略特定发行版的标签,可以使服务跨越多个 Deployment。
|
||||
当你需要不停机的情况下更新正在运行的服务,可以使用[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)。
|
||||
当你需要不停机的情况下更新正在运行的服务,可以使用[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/)。
|
||||
|
||||
<!--
|
||||
A desired state of an object is described by a Deployment, and if changes to that spec are _applied_, the deployment controller changes the actual state to the desired state at a controlled rate.
|
||||
@@ -187,9 +187,9 @@ Deployment 描述了对象的期望状态,并且如果对该规范的更改被
|
||||
- Use the [Kubernetes common labels](/docs/concepts/overview/working-with-objects/common-labels/) for common use cases. These standardized labels enrich the metadata in a way that allows tools, including `kubectl` and [dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard), to work in an interoperable way.
|
||||
-->
|
||||
|
||||
- 对于常见场景,应使用 [Kubernetes 通用标签](/zh/docs/concepts/overview/working-with-objects/common-labels/)。
|
||||
- 对于常见场景,应使用 [Kubernetes 通用标签](/zh-cn/docs/concepts/overview/working-with-objects/common-labels/)。
|
||||
这些标准化的标签丰富了对象的元数据,使得包括 `kubectl` 和
|
||||
[仪表板(Dashboard)](/zh/docs/tasks/access-application-cluster/web-ui-dashboard)
|
||||
[仪表板(Dashboard)](/zh-cn/docs/tasks/access-application-cluster/web-ui-dashboard)
|
||||
这些工具能够以可互操作的方式工作。
|
||||
|
||||
<!--
|
||||
@@ -217,13 +217,13 @@ Deployment 描述了对象的期望状态,并且如果对该规范的更改被
|
||||
- Use label selectors for `get` and `delete` operations instead of specific object names. See the sections on [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) and [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
|
||||
-->
|
||||
- 使用标签选择器进行 `get` 和 `delete` 操作,而不是特定的对象名称。
|
||||
- 请参阅[标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)和
|
||||
[有效使用标签](/zh/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)部分。
|
||||
- 请参阅[标签选择器](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors)和
|
||||
[有效使用标签](/zh-cn/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)部分。
|
||||
|
||||
<!--
|
||||
- Use `kubectl run` and `kubectl expose` to quickly create single-container Deployments and Services. See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) for an example.
|
||||
-->
|
||||
- 使用`kubectl run`和`kubectl expose`来快速创建单容器部署和服务。
|
||||
有关示例,请参阅[使用服务访问集群中的应用程序](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/)。
|
||||
有关示例,请参阅[使用服务访问集群中的应用程序](/zh-cn/docs/tasks/access-application-cluster/service-access-application-cluster/)。
|
||||
|
||||
|
||||
|
||||
@@ -74,8 +74,8 @@ In order to safely use Secrets, take at least the following steps:
|
||||
|
||||
为了安全地使用 Secret,请至少执行以下步骤:
|
||||
|
||||
1. 为 Secret [启用静态加密](/zh/docs/tasks/administer-cluster/encrypt-data/);
|
||||
1. [启用或配置 RBAC 规则](/zh/docs/reference/access-authn-authz/authorization/)来限制读取和写入
|
||||
1. 为 Secret [启用静态加密](/zh-cn/docs/tasks/administer-cluster/encrypt-data/);
|
||||
1. [启用或配置 RBAC 规则](/zh-cn/docs/reference/access-authn-authz/authorization/)来限制读取和写入
|
||||
Secret 的数据(包括通过间接方式)。需要注意的是,被准许创建 Pod 的人也隐式地被授权获取
|
||||
Secret 内容。
|
||||
1. 在适当的情况下,还可以使用 RBAC 等机制来限制允许哪些主体创建新 Secret 或替换现有 Secret。
|
||||
@@ -139,7 +139,7 @@ Here are some of your options:
|
||||
token).
|
||||
-->
|
||||
- 如果你的云原生组件需要执行身份认证来访问你所知道的、在同一 Kubernetes 集群中运行的另一个应用,
|
||||
你可以使用 [ServiceAccount](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens)
|
||||
你可以使用 [ServiceAccount](/zh-cn/docs/reference/access-authn-authz/authentication/#service-account-tokens)
|
||||
及其令牌来标识你的客户端身份。
|
||||
- 你可以运行的第三方工具也有很多,这些工具可以运行在集群内或集群外,提供机密数据管理。
|
||||
例如,这一工具可能是 Pod 通过 HTTPS 访问的一个服务,该服务在客户端能够正确地通过身份认证
|
||||
@@ -153,9 +153,9 @@ Here are some of your options:
|
||||
trusted Pods onto nodes that provide a Trusted Platform Module, configured out-of-band.
|
||||
-->
|
||||
- 就身份认证而言,你可以为 X.509 证书实现一个定制的签名者,并使用
|
||||
[CertificateSigningRequest](/zh/docs/reference/access-authn-authz/certificate-signing-requests/)
|
||||
[CertificateSigningRequest](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/)
|
||||
来让该签名者为需要证书的 Pod 发放证书。
|
||||
- 你可以使用一个[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
|
||||
- 你可以使用一个[设备插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
|
||||
来将节点本地的加密硬件暴露给特定的 Pod。例如,你可以将可信任的 Pod
|
||||
调度到提供可信平台模块(Trusted Platform Module,TPM)的节点上。
|
||||
这类节点是另行配置的。
|
||||
@@ -191,9 +191,9 @@ There are several options to create a Secret:
|
||||
|
||||
### 创建 Secret {#creating-a-secret}
|
||||
|
||||
- [使用 `kubectl` 命令来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
|
||||
- [基于配置文件来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-config-file/)
|
||||
- [使用 kustomize 来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
- [使用 `kubectl` 命令来创建 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
|
||||
- [基于配置文件来创建 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-config-file/)
|
||||
- [使用 kustomize 来创建 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
|
||||
<!--
|
||||
#### Constraints on Secret names and data {#restriction-names-data}
|
||||
@@ -204,7 +204,7 @@ The name of a Secret object must be a valid
|
||||
#### 对 Secret 名称与数据的约束 {#restriction-names-data}
|
||||
|
||||
Secret 对象的名称必须是合法的
|
||||
[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
|
||||
[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
|
||||
|
||||
<!--
|
||||
You can specify the `data` and/or the `stringData` field when creating a
|
||||
@@ -242,7 +242,7 @@ number of Secrets (or other resources) in a namespace.
|
||||
|
||||
每个 Secret 的尺寸最多为 1MiB。施加这一限制是为了避免用户创建非常大的 Secret,
|
||||
进而导致 API 服务器和 kubelet 内存耗尽。不过创建很多小的 Secret 也可能耗尽内存。
|
||||
你可以使用[资源配额](/zh/docs/concepts/policy/resource-quotas/)来约束每个名字空间中
|
||||
你可以使用[资源配额](/zh-cn/docs/concepts/policy/resource-quotas/)来约束每个名字空间中
|
||||
Secret(或其他资源)的个数。
|
||||
|
||||
<!--
|
||||
@@ -438,7 +438,7 @@ Kubernetes v1.22 版本之前都会自动创建用来访问 Kubernetes API 的
|
||||
这一老的机制是基于创建可被挂载到 Pod 中的令牌 Secret 来实现的。
|
||||
在最近的版本中,包括 Kubernetes v{{< skew currentVersion >}} 中,API 凭据是直接通过
|
||||
[TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
|
||||
API 来获得的,这一凭据会使用[投射卷](/zh/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume)
|
||||
API 来获得的,这一凭据会使用[投射卷](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume)
|
||||
挂载到 Pod 中。使用这种方式获得的令牌有确定的生命期,并且在挂载它们的 Pod
|
||||
被删除时自动作废。
|
||||
|
||||
@@ -450,7 +450,7 @@ subresource to obtain a token to access the API is recommended instead.
|
||||
You can use the [`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-)
|
||||
command to obtain a token from the `TokenRequest` API.
|
||||
-->
|
||||
你仍然可以[手动创建](/zh/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token)
|
||||
你仍然可以[手动创建](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token)
|
||||
服务账号令牌。例如,当你需要一个永远都不过期的令牌时。
|
||||
不过,仍然建议使用 [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
|
||||
子资源来获得访问 API 服务器的令牌。
|
||||
@@ -648,7 +648,7 @@ A container using a Secret as a
|
||||
[subPath](/docs/concepts/storage/volumes#using-subpath) volume mount does not receive
|
||||
automated Secret updates.
|
||||
-->
|
||||
对于以 [subPath](/zh/docs/concepts/storage/volumes#using-subpath) 形式挂载 Secret 卷的容器而言,
|
||||
对于以 [subPath](/zh-cn/docs/concepts/storage/volumes#using-subpath) 形式挂载 Secret 卷的容器而言,
|
||||
它们无法收到自动的 Secret 更新。
|
||||
{{< /note >}}
|
||||
|
||||
@@ -660,7 +660,7 @@ the [kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/)
|
||||
-->
|
||||
Kubelet 组件会维护一个缓存,在其中保存节点上 Pod 卷中使用的 Secret 的当前主键和取值。
|
||||
你可以配置 kubelet 如何检测所缓存数值的变化。
|
||||
[kubelet 配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/)中的
|
||||
[kubelet 配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/)中的
|
||||
`configMapAndSecretChangeDetectionStrategy` 字段控制 kubelet 所采用的策略。
|
||||
默认的策略是 `Watch`。
|
||||
|
||||
@@ -886,7 +886,7 @@ documentation.
|
||||
-->
|
||||
##### 手动设定 imagePullSecret {#manually-specifying-an-imagepullsecret}
|
||||
|
||||
你可以通过阅读[容器镜像](/zh/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)
|
||||
你可以通过阅读[容器镜像](/zh-cn/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)
|
||||
文档了解如何设置 `imagePullSecrets`。
|
||||
|
||||
<!--
|
||||
@@ -904,7 +904,7 @@ See [Add ImagePullSecrets to a service account](/docs/tasks/configure-pod-contai
|
||||
你可以手动创建 `imagePullSecret`,并在一个 ServiceAccount 中引用它。
|
||||
对使用该 ServiceAccount 创建的所有 Pod,或者默认使用该 ServiceAccount 创建的 Pod
|
||||
而言,其 `imagePullSecrets` 字段都会设置为该服务账号。
|
||||
请阅读[向服务账号添加 ImagePullSecrets](/zh/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)
|
||||
请阅读[向服务账号添加 ImagePullSecrets](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)
|
||||
来详细了解这一过程。
|
||||
|
||||
<!--
|
||||
@@ -1549,7 +1549,7 @@ You can also check the `automountServiceAccountToken` field and the
|
||||
[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
|
||||
for information on referencing service account credentials from within Pods.
|
||||
-->
|
||||
参考 [ServiceAccount](/zh/docs/tasks/configure-pod-container/configure-service-account/)
|
||||
参考 [ServiceAccount](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/)
|
||||
文档了解服务账号的工作原理。你也可以查看
|
||||
[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
|
||||
资源中的 `automountServiceAccountToken` 和 `serviceAccountName` 字段文档,
|
||||
@@ -1814,7 +1814,7 @@ The following YAML contains an example config for a TLS Secret:
|
||||
|
||||
Kubernetes 提供一种内置的 `kubernetes.io/tls` Secret 类型,用来存放 TLS
|
||||
场合通常要使用的证书及其相关密钥。
|
||||
TLS Secret 的一种典型用法是为 [Ingress](/zh/docs/concepts/services-networking/ingress/)
|
||||
TLS Secret 的一种典型用法是为 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/)
|
||||
资源配置传输过程中的数据加密,不过也可以用于其他资源或者直接在负载中使用。
|
||||
当使用此类型的 Secret 时,Secret 配置中的 `data` (或 `stringData`)字段必须包含
|
||||
`tls.key` 和 `tls.crt` 主键,尽管 API 服务器实际上并不会对每个键的取值作进一步的合法性检查。
|
||||
@@ -2164,8 +2164,8 @@ on that node.
|
||||
[authorization policies](/docs/reference/access-authn-authz/authorization/) such as
|
||||
[RBAC](/docs/reference/access-authn-authz/rbac/).
|
||||
-->
|
||||
- 部署与 Secret API 交互的应用时,你应该使用 [RBAC](/zh/docs/reference/access-authn-authz/rbac/)
|
||||
这类[鉴权策略](/zh/docs/reference/access-authn-authz/authorization/)来限制访问。
|
||||
- 部署与 Secret API 交互的应用时,你应该使用 [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/)
|
||||
这类[鉴权策略](/zh-cn/docs/reference/access-authn-authz/authorization/)来限制访问。
|
||||
<!--
|
||||
- In the Kubernetes API, `watch` and `list` requests for Secrets within a namespace
|
||||
are extremely powerful capabilities. Avoid granting this access where feasible, since
|
||||
@@ -2203,8 +2203,8 @@ Pod 来访问 Secret 的内容。
|
||||
- 保留(使用 Kubernetes API)对集群中所有 Secret 对象执行 `watch` 或 `list` 操作的能力,
|
||||
这样只有特权级最高、系统级别的组件能够执行这类操作。
|
||||
- 在部署需要通过 Secret API 交互的应用时,你应该通过使用
|
||||
[RBAC](/zh/docs/reference/access-authn-authz/rbac/)
|
||||
这类[鉴权策略](/zh/docs/reference/access-authn-authz/authorization/)来限制访问。
|
||||
[RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/)
|
||||
这类[鉴权策略](/zh-cn/docs/reference/access-authn-authz/authorization/)来限制访问。
|
||||
<!--
|
||||
- In the API server, objects (including Secrets) are persisted into
|
||||
{{< glossary_tooltip term_id="etcd" >}}; therefore:
|
||||
@@ -2221,7 +2221,7 @@ Pod 来访问 Secret 的内容。
|
||||
因此:
|
||||
|
||||
- 只应准许集群管理员访问 etcd(包括只读访问);
|
||||
- 为 Secret 对象启用[静态加密](/zh/docs/tasks/administer-cluster/encrypt-data/),
|
||||
- 为 Secret 对象启用[静态加密](/zh-cn/docs/tasks/administer-cluster/encrypt-data/),
|
||||
这样这些 Secret 的数据就不会以明文的形式保存到
|
||||
{{< glossary_tooltip term_id="etcd" >}} 中;
|
||||
- 当 etcd 的持久化存储不再被使用时,请考虑彻底擦除存储介质;
|
||||
@@ -2235,8 +2235,8 @@ Pod 来访问 Secret 的内容。
|
||||
- Learn how to [manage Secrets using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
- Read the [API reference](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/) for `Secret`
|
||||
-->
|
||||
- 学习如何[使用 `kubectl` 管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
|
||||
- 学习如何[使用配置文件管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-config-file/)
|
||||
- 学习如何[使用 kustomize 管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
- 阅读 [API 参考](/zh/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)了解 `Secret`
|
||||
- 学习如何[使用 `kubectl` 管理 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
|
||||
- 学习如何[使用配置文件管理 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-config-file/)
|
||||
- 学习如何[使用 kustomize 管理 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
- 阅读 [API 参考](/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)了解 `Secret`
|
||||
|
||||
|
||||
@@ -104,7 +104,7 @@ On Windows these values are only used to calculate the node's
|
||||
|
||||
为了满足操作系统、容器运行时和 kubelet 等 Kubernetes 主机进程使用的内存和 CPU,
|
||||
你可以(且应该)用 `--kube-reserved` 和/或 `--system-reserved` kubelet 标志来预留内存和 CPU 资源。
|
||||
在 Windows 上,这些值仅用于计算节点的[可分配](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)资源。
|
||||
在 Windows 上,这些值仅用于计算节点的[可分配](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)资源。
|
||||
|
||||
<!--
|
||||
As you deploy workloads, set resource memory and CPU limits on containers.
|
||||
|
||||
Reference in New Issue
Block a user