[zh]Update tasks pages(part-5) for links with '/zh/' prefix, using new prefix '/zh-cn/'
howieyuen
parent
e0d6f94bf6
commit
e06459c0c5
|
|
@ -320,7 +320,7 @@ Please refer to [Network Policies](/docs/concepts/services-networking/network-po
|
|||
如果你部署了任何可能影响到 `hostnames-*` Pod 的传入流量的网络策略入站规则，
|
||||
则需要对其进行检查。
|
||||
|
||||
详细信息，请参阅[网络策略](/zh/docs/concepts/services-networking/network-policies/)。
|
||||
详细信息，请参阅[网络策略](/zh-cn/docs/concepts/services-networking/network-policies/)。
|
||||
|
||||
<!--
|
||||
## Does the Service work by DNS name?
|
||||
|
|
@ -648,7 +648,7 @@ every Service and saves the results into a corresponding Endpoints object.
|
|||
"AGE" 列表明这些 Pod 已经启动一个小时了，这意味着它们运行良好，而未崩溃。
|
||||
|
||||
"RESTARTS" 列表明 Pod 没有经常崩溃或重启。经常性崩溃可能导致间歇性连接问题。
|
||||
如果重启次数过大，通过[调试 Pod](/zh/docs/tasks/debug/debug-application/debug-pods)
|
||||
如果重启次数过大，通过[调试 Pod](/zh-cn/docs/tasks/debug/debug-application/debug-pods)
|
||||
了解相关技术。
|
||||
|
||||
在 Kubernetes 系统中有一个控制回路，它评估每个 Service 的选择算符，并将结果保存到 Endpoints 对象中。
|
||||
|
|
@ -1002,7 +1002,7 @@ back to themselves if they try to access their own Service VIP. The
|
|||
如果网络没有为“发夹模式（Hairpin）”流量生成正确配置，
|
||||
通常当 `kube-proxy` 以 `iptables` 模式运行，并且 Pod 与桥接网络连接时，就会发生这种情况。
|
||||
`kubelet` 提供了 `hairpin-mode`
|
||||
[标志](/zh/docs/reference/command-line-tools-reference/kubelet/)。
|
||||
[标志](/zh-cn/docs/reference/command-line-tools-reference/kubelet/)。
|
||||
如果 Service 的末端尝试访问自己的 Service VIP，则该端点可以把流量负载均衡回来到它们自身。
|
||||
`hairpin-mode` 标志必须被设置为 `hairpin-veth` 或者 `promiscuous-bridge`。
|
||||
|
||||
|
|
@ -1114,4 +1114,4 @@ Contact us on
|
|||
<!--
|
||||
Visit [troubleshooting document](/docs/tasks/debug/) for more information.
|
||||
-->
|
||||
访问[故障排查文档](/zh/docs/tasks/debug/) 获取更多信息。
|
||||
访问[故障排查文档](/zh-cn/docs/tasks/debug/) 获取更多信息。
|
||||
|
|
|
|||
|
|
@ -57,9 +57,9 @@ You can debug individual Pods in a StatefulSet using the
|
|||
[Debugging Pods](/docs/tasks/debug/debug-application/debug-pods/) guide.
|
||||
-->
|
||||
如果你发现列出的任何 Pod 长时间处于 `Unknown` 或 `Terminating` 状态，请参阅
|
||||
[删除 StatefulSet Pod](/zh/docs/tasks/run-application/delete-stateful-set/)
|
||||
[删除 StatefulSet Pod](/zh-cn/docs/tasks/run-application/delete-stateful-set/)
|
||||
了解如何处理它们的说明。
|
||||
你可以参考[调试 Pod](/zh/docs/tasks/debug/debug-application/debug-pods/)
|
||||
你可以参考[调试 Pod](/zh-cn/docs/tasks/debug/debug-application/debug-pods/)
|
||||
来调试 StatefulSet 中的各个 Pod。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
|
@ -67,5 +67,5 @@ You can debug individual Pods in a StatefulSet using the
|
|||
<!--
|
||||
Learn more about [debugging an init-container](/docs/tasks/debug/debug-application/debug-init-containers/).
|
||||
-->
|
||||
* 进一步了解如何[调试 Init 容器](/zh/docs/tasks/debug/debug-application/debug-init-containers/)。
|
||||
* 进一步了解如何[调试 Init 容器](/zh-cn/docs/tasks/debug/debug-application/debug-init-containers/)。
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ the general
|
|||
终止消息为容器提供了一种方法，可以将有关致命事件的信息写入某个位置，
|
||||
在该位置可以通过仪表板和监控软件等工具轻松检索和显示致命事件。
|
||||
在大多数情况下，你放入终止消息中的信息也应该写入
|
||||
[常规 Kubernetes 日志](/zh/docs/concepts/cluster-administration/logging/)。
|
||||
[常规 Kubernetes 日志](/zh-cn/docs/concepts/cluster-administration/logging/)。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
|
@ -169,6 +169,6 @@ is empty and the container exited with an error. The log output is limited to
|
|||
|
||||
* 参考 [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
|
||||
资源的 `terminationMessagePath` 字段。
|
||||
* 了解[接收日志](/zh/docs/concepts/cluster-administration/logging/)。
|
||||
* 了解[接收日志](/zh-cn/docs/concepts/cluster-administration/logging/)。
|
||||
* 了解 [Go 模版](https://golang.org/pkg/text/template/)。
|
||||
|
||||
|
|
|
|||
|
|
@ -22,8 +22,8 @@ the [application troubleshooting guide](/docs/tasks/debug/debug-application/) fo
|
|||
You may also visit the [troubleshooting overview document](/docs/tasks/debug/) for more information.
|
||||
-->
|
||||
本篇文档是介绍集群故障排查的；我们假设对于你碰到的问题，你已经排除了是由应用程序造成的。
|
||||
对于应用的调试，请参阅[应用故障排查指南](/zh/docs/tasks/debug/debug-application/)。
|
||||
你也可以访问[故障排查](/zh/docs/tasks/debug/)来获取更多的信息。
|
||||
对于应用的调试，请参阅[应用故障排查指南](/zh-cn/docs/tasks/debug/debug-application/)。
|
||||
你也可以访问[故障排查](/zh-cn/docs/tasks/debug/)来获取更多的信息。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -408,7 +408,7 @@ This is an incomplete list of things that could go wrong, and how to adjust your
|
|||
- 措施: 对于运行 API 服务器和 etcd 的 VM，使用 IaaS 提供的可靠的存储（例如 GCE PD 或者 AWS EBS 卷）
|
||||
- 缓解：API 服务器后端存储的丢失
|
||||
|
||||
- 措施：使用[高可用性](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/)的配置
|
||||
- 措施：使用[高可用性](/zh-cn/docs/setup/production-environment/tools/kubeadm/high-availability/)的配置
|
||||
- 缓解：主控节点 VM 关机或者主控节点组件（调度器、API 服务器、控制器管理器）崩馈
|
||||
- 将容许一个或多个节点或组件同时出现故障
|
||||
- 缓解：API 服务器后端存储（例如 etcd 的数据目录）丢失
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ and the backends persist the records. The current backend implementations
|
|||
include logs files and webhooks.
|
||||
-->
|
||||
审计记录最初产生于
|
||||
[kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)
|
||||
[kube-apiserver](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/)
|
||||
内部。每个请求在不同执行阶段都会生成审计事件；这些审计事件会根据特定策略
|
||||
被预处理并写入后端。策略确定要记录的内容和用来存储记录的后端。
|
||||
当前的后端支持日志文件和 webhook。
|
||||
|
|
@ -90,7 +90,7 @@ is different from the
|
|||
API object.
|
||||
-->
|
||||
{{< note >}}
|
||||
[审计事件配置](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)
|
||||
[审计事件配置](/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)
|
||||
的配置与 [Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)
|
||||
API 对象不同。
|
||||
{{< /note >}}
|
||||
|
|
@ -117,7 +117,7 @@ _audit level_ of the event. The defined audit levels are:
|
|||
|
||||
审计政策定义了关于应记录哪些事件以及应包含哪些数据的规则。
|
||||
审计策略对象结构定义在
|
||||
[`audit.k8s.io` API 组](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)
|
||||
[`audit.k8s.io` API 组](/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)
|
||||
处理事件时，将按顺序与规则列表进行比较。第一个匹配规则设置事件的
|
||||
**审计级别（Audit Level）**。已定义的审计级别有：
|
||||
|
||||
|
|
@ -179,7 +179,7 @@ for details about the fields defined.
|
|||
[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)
|
||||
脚本，该脚本能够生成审计策略文件。你可以直接在脚本中看到审计策略的绝大部份内容。
|
||||
|
||||
你也可以参考 [`Policy` 配置参考](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)
|
||||
你也可以参考 [`Policy` 配置参考](/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)
|
||||
以获取有关已定义字段的详细信息。
|
||||
|
||||
<!--
|
||||
|
|
@ -203,7 +203,7 @@ In all cases, audit events follow a structure defined by the Kubernetes API in t
|
|||
- Webhook 后端，将事件发送到外部 HTTP API
|
||||
|
||||
在这所有情况下，审计事件均遵循 Kubernetes API 在
|
||||
[`audit.k8s.io` API 组](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)
|
||||
[`audit.k8s.io` API 组](/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)
|
||||
中定义的结构。
|
||||
|
||||
<!--
|
||||
|
|
@ -325,7 +325,7 @@ The webhook config file uses the kubeconfig format to specify the remote address
|
|||
the service and credentials used to connect to it.
|
||||
-->
|
||||
- `--audit-webhook-config-file` 设置 Webhook 配置文件的路径。Webhook 配置文件实际上是一个
|
||||
[kubeconfig 文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)。
|
||||
[kubeconfig 文件](/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig/)。
|
||||
- `--audit-webhook-initial-backoff` 指定在第一次失败后重发请求等待的时间。随后的请求将以指数退避重试。
|
||||
|
||||
Webhook 配置文件使用 kubeconfig 格式指定服务的远程地址和用于连接它的凭据。
|
||||
|
|
@ -449,4 +449,4 @@ By default truncate is disabled in both `webhook` and `log`, a cluster administr
|
|||
<!--
|
||||
* Learn about [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations).
|
||||
-->
|
||||
* 了解 [Mutating webhook 审计注解](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations)。
|
||||
* 了解 [Mutating webhook 审计注解](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations)。
|
||||
|
|
@ -560,4 +560,4 @@ CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT
|
|||
* [Map `docker` CLI commands to `crictl`](/docs/reference/tools/map-crictl-dockercli/).
|
||||
-->
|
||||
* [进一步了解 `crictl`](https://github.com/kubernetes-sigs/cri-tools)
|
||||
* [将 `docker` CLI 命令映射到 `crictl`](/zh/docs/reference/tools/map-crictl-dockercli/)
|
||||
* [将 `docker` CLI 命令映射到 `crictl`](/zh-cn/docs/reference/tools/map-crictl-dockercli/)
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Kubernetes applications usually consist of multiple, separate services, each run
|
|||
|
||||
Kubernetes 应用程序通常由多个独立的服务组成，每个服务都在自己的容器中运行。
|
||||
在远端的 Kubernetes 集群上开发和调试这些服务可能很麻烦，
|
||||
需要[在运行的容器上打开 Shell](/zh/docs/tasks/debug/debug-application/get-shell-running-container/)，
|
||||
需要[在运行的容器上打开 Shell](/zh-cn/docs/tasks/debug/debug-application/get-shell-running-container/)，
|
||||
以运行调试工具。
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ To learn how to install and use Node Problem Detector, see
|
|||
*节点问题检测器（Node Problem Detector）* 是一个守护程序，用于监视和报告节点的健康状况。
|
||||
你可以将节点问题探测器以 `DaemonSet` 或独立守护程序运行。
|
||||
节点问题检测器从各种守护进程收集节点问题，并以
|
||||
[NodeCondition](/zh/docs/concepts/architecture/nodes/#condition) 和
|
||||
[NodeCondition](/zh-cn/docs/concepts/architecture/nodes/#condition) 和
|
||||
[Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)
|
||||
的形式报告给 API 服务器。
|
||||
|
||||
|
|
@ -140,7 +140,7 @@ is embedded when building the Docker image of Node Problem Detector.
|
|||
However, you can use a [`ConfigMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
to overwrite the configuration:
|
||||
-->
|
||||
不过，你可以像下面这样使用 [`ConfigMap`](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
不过，你可以像下面这样使用 [`ConfigMap`](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
将其覆盖：
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ command.
|
|||
包括 CPU 和内存的指标。如果将 Metrics API 部署到集群中，
|
||||
那么 Kubernetes API 的客户端就可以查询这些信息，并且可以使用 Kubernetes 的访问控制机制来管理权限。
|
||||
|
||||
[HorizontalPodAutoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA) 和
|
||||
[HorizontalPodAutoscaler](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA) 和
|
||||
[VerticalPodAutoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) (VPA)
|
||||
使用 metrics API 中的数据调整工作负载副本和资源，以满足客户需求。
|
||||
|
||||
|
|
@ -52,7 +52,7 @@ that uses the _Custom Metrics API_.
|
|||
-->
|
||||
Metrics API 及其启用的指标管道仅提供最少的 CPU 和内存指标，以启用使用 HPA 和/或 VPA 的自动扩展。
|
||||
如果你想提供更完整的指标集，你可以通过部署使用 _Custom Metrics API_ 的第二个
|
||||
[指标管道](/zh/docs/tasks/debug/debug-cluster/resource-usage-monitoring/#full-metrics-pipeline)来作为简单的 Metrics API 的补充。
|
||||
[指标管道](/zh-cn/docs/tasks/debug/debug-cluster/resource-usage-monitoring/#full-metrics-pipeline)来作为简单的 Metrics API 的补充。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
|
|
@ -110,7 +110,7 @@ The architecture components, from right to left in the figure, consist of the fo
|
|||
图中从右到左的架构组件包括以下内容：
|
||||
|
||||
* [cAdvisor](https://github.com/google/cadvisor): 用于收集、聚合和公开 Kubelet 中包含的容器指标的守护程序。
|
||||
* [kubelet](/zh/docs/concepts/overview/components/#kubelet): 用于管理容器资源的节点代理。
|
||||
* [kubelet](/zh-cn/docs/concepts/overview/components/#kubelet): 用于管理容器资源的节点代理。
|
||||
可以使用 `/metrics/resource` 和 `/stats` kubelet API 端点访问资源指标。
|
||||
* [Summary API](#summary-api-source): kubelet 提供的 API，用于发现和检索可通过 `/stats` 端点获得的每个节点的汇总统计信息。
|
||||
* [metrics-server](#metrics-server): 集群插件组件，用于收集和聚合从每个 kubelet 中提取的资源指标。
|
||||
|
|
@ -244,8 +244,8 @@ the [metrics-server repository](https://github.com/kubernetes-sigs/metrics-serve
|
|||
-->
|
||||
|
||||
Metrics API 在 [k8s.io/metrics](https://github.com/kubernetes/metrics) 代码库中定义。
|
||||
你必须启用 [API 聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/)并为
|
||||
`metrics.k8s.io` API 注册一个 [APIService](/zh/docs/reference/kubernetes-api/cluster-resources/api-service-v1/)。
|
||||
你必须启用 [API 聚合层](/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/)并为
|
||||
`metrics.k8s.io` API 注册一个 [APIService](/zh-cn/docs/reference/kubernetes-api/cluster-resources/api-service-v1/)。
|
||||
|
||||
要了解有关 Metrics API 的更多信息，
|
||||
请参阅资源 [Resource Metrics API Design](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/resource-metrics-api.md)、
|
||||
|
|
@ -286,7 +286,7 @@ CPU 报告为以 cpu 为单位测量的平均核心使用率。在 Kubernetes
|
|||
用于计算 CPU 的时间窗口显示在 Metrics API 的窗口字段下。
|
||||
|
||||
要了解更多关于 Kubernetes 如何分配和测量 CPU 资源的信息，请参阅
|
||||
[CPU 的含义](/zh/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu)。
|
||||
[CPU 的含义](/zh-cn/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu)。
|
||||
|
||||
<!--
|
||||
### Memory
|
||||
|
|
@ -315,7 +315,7 @@ Kubernetes 模型中，容器工作集是由容器运行时计算的与相关容
|
|||
工作集指标通常还包括一些缓存（文件支持）内存，因为主机操作系统不能总是回收页面。
|
||||
|
||||
要了解有关 Kubernetes 如何分配和测量内存资源的更多信息，
|
||||
请参阅[内存的含义](/zh/docs/concepts/configuration/manage-resources-containers/#meaning-of-memory)。
|
||||
请参阅[内存的含义](/zh-cn/docs/concepts/configuration/manage-resources-containers/#meaning-of-memory)。
|
||||
|
||||
<!--
|
||||
## Metrics Server
|
||||
|
|
@ -350,7 +350,7 @@ to collect metrics from each node. Depending on the metrics-server version it us
|
|||
* Metrics resource endpoint `/metrics/resource` in version v0.6.0+ or
|
||||
* Summary API endpoint `/stats/summary` in older versions
|
||||
-->
|
||||
metrics-server 调用 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) API
|
||||
metrics-server 调用 [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) API
|
||||
从每个节点收集指标。根据它使用的度量服务器版本：
|
||||
|
||||
* 版本 v0.6.0+ 中，使用指标资源端点 `/metrics/resource`
|
||||
|
|
@ -377,7 +377,7 @@ You can also check out the following:
|
|||
* [metrics-server FAQ](https://github.com/kubernetes-sigs/metrics-server/blob/master/FAQ.md)
|
||||
* [metrics-server known issues](https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md)
|
||||
* [metrics-server releases](https://github.com/kubernetes-sigs/metrics-server/releases)
|
||||
* [Horizontal Pod Autoscaling](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)
|
||||
* [Horizontal Pod Autoscaling](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/)
|
||||
|
||||
<!--
|
||||
### Summary API Source
|
||||
|
|
@ -389,7 +389,7 @@ for consumers to read.
|
|||
|
||||
### Summary API 来源 {#summary-api-source}
|
||||
|
||||
[Kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 在节点、卷、Pod 和容器级别收集统计信息，
|
||||
[Kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 在节点、卷、Pod 和容器级别收集统计信息，
|
||||
并在 [Summary API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go)
|
||||
中提供它们的统计信息供消费者阅读。
|
||||
|
||||
|
|
|
|||
|
|
@ -24,8 +24,8 @@ where bottlenecks can be removed to improve overall performance.
|
|||
-->
|
||||
要扩展应用程序并提供可靠的服务，你需要了解应用程序在部署时的行为。
|
||||
你可以通过检测容器检查 Kubernetes 集群中的应用程序性能，
|
||||
[Pods](/zh/docs/concepts/workloads/pods),
|
||||
[服务](/zh/docs/concepts/services-networking/service/)
|
||||
[Pods](/zh-cn/docs/concepts/workloads/pods),
|
||||
[服务](/zh-cn/docs/concepts/services-networking/service/)
|
||||
和整个集群的特征。
|
||||
Kubernetes 在每个级别上提供有关应用程序资源使用情况的详细信息。
|
||||
此信息使你可以评估应用程序的性能，以及在何处可以消除瓶颈以提高整体性能。
|
||||
|
|
@ -55,7 +55,7 @@ These metrics are collected by the lightweight, short-term, in-memory
|
|||
## 资源度量管道 {#resource-metrics-pipeline}
|
||||
|
||||
资源指标管道提供了一组与集群组件，例如
|
||||
[Horizontal Pod Autoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)
|
||||
[Horizontal Pod Autoscaler](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/)
|
||||
控制器以及 `kubectl top` 实用程序相关的有限度量。
|
||||
这些指标是由轻量级的、短期、内存存储的
|
||||
[metrics-server](https://github.com/kubernetes-sigs/metrics-server) 收集的，
|
||||
|
|
@ -76,7 +76,7 @@ This API is served at `/metrics/resource/v1beta1` on the kubelet's authenticated
|
|||
read-only ports.
|
||||
-->
|
||||
度量服务器发现集群中的所有节点，并且查询每个节点的
|
||||
[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/)
|
||||
[kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/)
|
||||
以获取 CPU 和内存使用情况。
|
||||
Kubelet 充当 Kubernetes 主节点与节点之间的桥梁，管理机器上运行的 Pod 和容器。
|
||||
kubelet 将每个 Pod 转换为其组成的容器，并在容器运行时通过容器运行时接口
|
||||
|
|
|
|||
|
|
@ -101,7 +101,7 @@ content_type: concept
|
|||
[cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf)
|
||||
的配置。你可以随时编辑这个静态文件。更新配置将应用于新的 Kubernetes 资源。
|
||||
|
||||
Kubernetes 的网络需求之一 (查看 [Kubernetes 模型](/zh/docs/concepts/cluster-administration/networking/))
|
||||
Kubernetes 的网络需求之一 (查看 [Kubernetes 模型](/zh-cn/docs/concepts/cluster-administration/networking/))
|
||||
是集群通信不需要内部的 NAT。
|
||||
为了遵守这一要求， 对于你不希望发生的出站 NAT 通信，这里有一个
|
||||
[ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20) 。
|
||||
|
|
@ -138,7 +138,7 @@ content_type: concept
|
|||
|
||||
4. 容器的 vnic 和 HNS endpoints 正在被删除
|
||||
|
||||
当 `hostname-override` 参数没有传递给 [kube-proxy](/zh/docs/reference/command-line-tools-reference/kube-proxy/)
|
||||
当 `hostname-override` 参数没有传递给 [kube-proxy](/zh-cn/docs/reference/command-line-tools-reference/kube-proxy/)
|
||||
时可能引发这一问题。想要解决这个问题，用户需要将主机名传递给 kube-proxy，如下所示：
|
||||
|
||||
```powershell
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ content_type: task
|
|||
This guide demonstrates how to install and write extensions for [kubectl](/docs/reference/kubectl/kubectl/). By thinking of core `kubectl` commands as essential building blocks for interacting with a Kubernetes cluster, a cluster administrator can think
|
||||
of plugins as a means of utilizing these building blocks to create more complex behavior. Plugins extend `kubectl` with new sub-commands, allowing for new and custom features not included in the main distribution of `kubectl`.
|
||||
-->
|
||||
本指南演示了如何为 [kubectl](/zh/docs/reference/kubectl/kubectl/) 安装和编写扩展。
|
||||
本指南演示了如何为 [kubectl](/zh-cn/docs/reference/kubectl/kubectl/) 安装和编写扩展。
|
||||
通过将核心 `kubectl` 命令看作与 Kubernetes 集群交互的基本构建块，
|
||||
集群管理员可以将插件视为一种利用这些构建块创建更复杂行为的方法。
|
||||
插件用新的子命令扩展了 `kubectl`，允许新的和自定义的特性不包括在 `kubectl` 的主要发行版中。
|
||||
|
|
@ -510,7 +510,7 @@ an example usage of the tools provided in the CLI Runtime repo.
|
|||
[cli-runtime](https://github.com/kubernetes/cli-runtime) 工具库。
|
||||
|
||||
这些库提供了一些辅助函数，用来解析和更新用户的
|
||||
[kubeconfig](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
[kubeconfig](/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
文件，向 API 服务器发起 REST 风格的请求，或者将参数绑定到某配置上，
|
||||
抑或将其打印输出。
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ weight: 10
|
|||
<!--
|
||||
Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs.
|
||||
-->
|
||||
配置[聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
|
||||
配置[聚合层](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
|
||||
可以允许 Kubernetes apiserver 使用其它 API 扩展，这些 API 不是核心
|
||||
Kubernetes API 的一部分。
|
||||
|
||||
|
|
@ -232,9 +232,9 @@ Kubernetes apiserver 中注册。
|
|||
Kubernetes apiserver 使用它的标准认证和授权配置来对用户认证，以及对特定路径的鉴权。
|
||||
|
||||
有关对 Kubernetes 集群认证的概述，请参见
|
||||
[对集群认证](/zh/docs/reference/access-authn-authz/authentication/)。
|
||||
[对集群认证](/zh-cn/docs/reference/access-authn-authz/authentication/)。
|
||||
有关对Kubernetes集群资源的访问鉴权的概述，请参见
|
||||
[鉴权概述](/zh/docs/reference/access-authn-authz/authorization/)。
|
||||
[鉴权概述](/zh-cn/docs/reference/access-authn-authz/authorization/)。
|
||||
|
||||
到目前为止，所有内容都是标准的 Kubernetes API 请求，认证与鉴权。
|
||||
|
||||
|
|
@ -407,7 +407,7 @@ In order for the extension apiserver to be authorized itself to submit the `Subj
|
|||
|
||||
扩展 apiserver 现在可以验证从标头检索的`user/group`是否有权执行给定请求。
|
||||
通过向 Kubernetes apiserver 发送标准
|
||||
[SubjectAccessReview](/zh/docs/reference/access-authn-authz/authorization/) 请求来实现。
|
||||
[SubjectAccessReview](/zh-cn/docs/reference/access-authn-authz/authorization/) 请求来实现。
|
||||
|
||||
为了使扩展 apiserver 本身被鉴权可以向 Kubernetes apiserver 提交 SubjectAccessReview 请求，
|
||||
它需要正确的权限。
|
||||
|
|
@ -466,7 +466,7 @@ Each of these functions independently and can conflict with each other, if not u
|
|||
则 Kubernetes apiserver 会检查请求的证书。
|
||||
如果它是由 `--client-ca-file` 引用的文件中的 CA 证书之一签名的，
|
||||
并且用户是公用名`CN=`的值，而组是组织`O=` 的取值，则该请求被视为合法请求。
|
||||
请参阅[关于 TLS 身份验证的文档](/zh/docs/reference/access-authn-authz/authentication/#x509-client-certs)。
|
||||
请参阅[关于 TLS 身份验证的文档](/zh-cn/docs/reference/access-authn-authz/authentication/#x509-client-certs)。
|
||||
|
||||
* `--requestheader-client-ca-file`：当请求到达 Kubernetes apiserver 时，
|
||||
如果启用此选项，则 Kubernetes apiserver 会检查请求的证书。
|
||||
|
|
@ -545,7 +545,7 @@ The name of an APIService object must be a valid
|
|||
[path segment name](/docs/concepts/overview/working-with-objects/names#path-segment-names).
|
||||
-->
|
||||
APIService 对象的名称必须是合法的
|
||||
[路径片段名称](/zh/docs/concepts/overview/working-with-objects/names#path-segment-names)。
|
||||
[路径片段名称](/zh-cn/docs/concepts/overview/working-with-objects/names#path-segment-names)。
|
||||
|
||||
<!--
|
||||
#### Contacting the extension apiserver
|
||||
|
|
@ -598,6 +598,6 @@ spec:
|
|||
* Learn how to [Extend the Kubernetes API Using Custom Resource Definitions](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/).
|
||||
-->
|
||||
|
||||
* 使用聚合层[安装扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)。
|
||||
* 有关高级概述，请参阅[使用聚合层扩展 Kubernetes API](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)。
|
||||
* 了解如何[使用自定义资源扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
|
||||
* 使用聚合层[安装扩展 API 服务器](/zh-cn/docs/tasks/extend-kubernetes/setup-extension-api-server/)。
|
||||
* 有关高级概述，请参阅[使用聚合层扩展 Kubernetes API](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)。
|
||||
* 了解如何[使用自定义资源扩展 Kubernetes API](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ scheduler and instruct Kubernetes what scheduler to use for each of your pods. L
|
|||
learn how to run multiple schedulers in Kubernetes with an example.
|
||||
-->
|
||||
Kubernetes 自带了一个默认调度器，其详细描述请查阅
|
||||
[这里](/zh/docs/reference/command-line-tools-reference/kube-scheduler/)。
|
||||
[这里](/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/)。
|
||||
如果默认调度器不适合你的需求，你可以实现自己的调度器。
|
||||
而且，你甚至可以和默认调度器一起同时运行多个调度器，并告诉 Kubernetes 为每个
|
||||
Pod 使用哪个调度器。
|
||||
|
|
@ -108,8 +108,8 @@ config. Save it as `my-scheduler.yaml`:
|
|||
|
||||
现在将调度器放在容器镜像中，为它创建一个 Pod 配置，并在 Kubernetes 集群中
|
||||
运行它。但是与其在集群中直接创建一个 Pod，不如使用
|
||||
[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)。
|
||||
Deployment 管理一个 [ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/)，
|
||||
[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/)。
|
||||
Deployment 管理一个 [ReplicaSet](/zh-cn/docs/concepts/workloads/controllers/replicaset/)，
|
||||
ReplicaSet 再管理 Pod，从而使调度器能够免受一些故障的影响。
|
||||
以下是 Deployment 配置，将其保存为 `my-scheduler.yaml`：
|
||||
|
||||
|
|
@ -120,7 +120,7 @@ In the above manifest, you use a [KubeSchedulerConfiguration](/docs/reference/sc
|
|||
to customize the behavior of your scheduler implementation. This configuration has been passed to
|
||||
the `kube-scheduler` during initialization with the `--config` option. The `my-scheduler-config` ConfigMap stores the configuration file. The Pod of the`my-scheduler` Deployment mounts the `my-scheduler-config` ConfigMap as a volume.
|
||||
-->
|
||||
在以上的清单中，你使用 [KubeSchedulerConfiguration](/zh/docs/reference/scheduling/config/)
|
||||
在以上的清单中，你使用 [KubeSchedulerConfiguration](/zh-cn/docs/reference/scheduling/config/)
|
||||
来自定义调度器实现的行为。当使用 `--config` 选项进行初始化时，该配置被传递到 `kube-scheduler`。
|
||||
`my-scheduler-config` ConfigMap 存储配置数据。
|
||||
`my-scheduler` Deployment 的 Pod 将 `my-scheduler-config` ConfigMap 挂载为一个卷。
|
||||
|
|
@ -369,6 +369,6 @@ You can also use a [custom scheduler configuration](/docs/reference/scheduling/c
|
|||
or a custom container image for the cluster's main scheduler by modifying its static pod manifest
|
||||
on the relevant control plane nodes.
|
||||
-->
|
||||
你也可以使用[自定义调度器配置](/zh/docs/reference/scheduling/config/#multiple-profiles)
|
||||
你也可以使用[自定义调度器配置](/zh-cn/docs/reference/scheduling/config/#multiple-profiles)
|
||||
或自定义容器镜像，用于集群的主调度器，方法是在相关控制平面节点上修改其静态 pod 清单。
|
||||
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ API 升级时需要在不同 API 表示形式之间进行转换。
|
|||
<!--
|
||||
You should have a initial understanding of [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
|
||||
-->
|
||||
你应该对[定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
你应该对[定制资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
有一些初步了解。
|
||||
|
||||
{{< version-check >}}
|
||||
|
|
@ -524,7 +524,7 @@ Webhook conversion is available as beta since 1.15, and as alpha since Kubernete
|
|||
Webhook 转换在 Kubernetes 1.13 版本引入，在 Kubernetes 1.15 中成为 Beta 功能。
|
||||
要使用此功能，应启用 `CustomResourceWebhookConversion` 特性。
|
||||
在大多数集群上，这类 Beta 特性应该是自动启用的。
|
||||
请参阅[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
请参阅[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
文档以获得更多信息。
|
||||
{{< /note >}}
|
||||
|
||||
|
|
@ -599,7 +599,7 @@ how to [authenticate API servers](/docs/reference/access-authn-authz/extensible-
|
|||
默认为 `NoClientCert`。
|
||||
这意味着 webhook 服务器没有验证客户端（也就是 API 服务器）的身份。
|
||||
如果你需要双向 TLS 或者其他方式来验证客户端，请参阅如何
|
||||
[验证 API 服务](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#authenticate-apiservers)。
|
||||
[验证 API 服务](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#authenticate-apiservers)。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
|
|
@ -626,7 +626,7 @@ The assumption for next sections is that the conversion webhook server is deploy
|
|||
### 部署转换 Webhook 服务
|
||||
|
||||
用于部署转换 webhook 的文档与
|
||||
[准入 Webhook 服务示例](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#deploy_the_admission_webhook_service)相同。
|
||||
[准入 Webhook 服务示例](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#deploy_the_admission_webhook_service)相同。
|
||||
这里的假设是转换 Webhook 服务器被部署为 `default` 名字空间中名为
|
||||
`example-conversion-webhook-server` 的服务，并在路径 `/crdconvert`
|
||||
上处理请求。
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ into the Kubernetes API by creating a
|
|||
本页展示如何使用
|
||||
[CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1-apiextensions-k8s-io)
|
||||
将
|
||||
[定制资源（Custom Resource）](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
[定制资源（Custom Resource）](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
安装到 Kubernetes API 上。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
|
@ -831,7 +831,7 @@ CustomResourceDefinition and migrating your objects from one version to another.
|
|||
|
||||
关于如何为你的 CustomResourceDefinition 提供多个版本的支持，以及如何将你的对象
|
||||
从一个版本迁移到另一个版本， 详细信息可参阅
|
||||
[定制资源定义的版本](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/)。
|
||||
[定制资源定义的版本](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/)。
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
|
|
@ -912,7 +912,7 @@ can add additional validation using
|
|||
定制资源是通过
|
||||
[OpenAPI v3 模式定义](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#schemaObject)
|
||||
来执行合法性检查的，当启用[验证规则特性](#validation-rules)时，通过 `x-kubernetes-validations` 验证，
|
||||
你可以通过使用[准入控制 Webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook)
|
||||
你可以通过使用[准入控制 Webhook](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook)
|
||||
来添加额外的合法性检查逻辑。
|
||||
|
||||
<!--
|
||||
|
|
@ -971,7 +971,7 @@ enabled, which is the case automatically for many clusters for beta features).
|
|||
就 `apiextensions.k8s.io/v1` 组的 CustomResourceDefinitions，这一条件是满足的。
|
||||
设置默认值的功能特性从 1.17 开始正式发布。该特性在 1.16 版本中处于
|
||||
Beta 状态，要求 `CustomResourceDefaulting`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
被启用。对于大多数集群而言，Beta 状态的特性门控默认都是自动启用的。
|
||||
|
||||
<!--
|
||||
|
|
@ -1138,7 +1138,7 @@ This feature is only available if the schema is a
|
|||
[structural schema](#specifying-a-structural-schema).
|
||||
-->
|
||||
验证规则从 1.23 开始处于 Alpha 状态，
|
||||
当 `CustomResourceValidationExpressions` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)被启用时，
|
||||
当 `CustomResourceValidationExpressions` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)被启用时，
|
||||
验证定制资源。这个功能只有在模式是[结构化的模式](#specifying-a-structural-schema)时才可用。
|
||||
|
||||
<!--
|
||||
|
|
@ -1608,7 +1608,7 @@ types](https://swagger.io/specification/#data-types), [Kubernetes Structural Sch
|
|||
-->
|
||||
参考：[CEL 类型](https://github.com/google/cel-spec/blob/v0.6.0/doc/langdef.md#values)，
|
||||
[OpenAPI 类型](https://swagger.io/specification/#data-types)，
|
||||
[Kubernetes 结构化模式](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema)。
|
||||
[Kubernetes 结构化模式](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema)。
|
||||
|
||||
<!--
|
||||
#### Validation functions {#available-validation-functions}
|
||||
|
|
@ -2090,10 +2090,10 @@ The [kubectl](/docs/reference/kubectl/) command-line tool consumes the published
|
|||
CustomResourceDefinition 的[结构化的](#specifying-a-structural-schema)、
|
||||
[启用了剪裁的](#preserving-unknown-fields) [OpenAPI v3 合法性检查模式](#validation)
|
||||
会在 Kubernetes API 服务器上作为
|
||||
[OpenAPI v2 规约](/zh/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions)
|
||||
[OpenAPI v2 规约](/zh-cn/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions)
|
||||
的一部分发布出来。
|
||||
|
||||
[kubectl](/zh/docs/reference/kubectl/) 命令行工具会基于所发布的模式定义来执行客户端的合法性检查（`kubectl create` 和 `kubectl apply`），为定制资源的模式定义提供解释（`kubectl explain`）。
|
||||
[kubectl](/zh-cn/docs/reference/kubectl/) 命令行工具会基于所发布的模式定义来执行客户端的合法性检查（`kubectl create` 和 `kubectl apply`），为定制资源的模式定义提供解释（`kubectl explain`）。
|
||||
所发布的模式还可被用于其他目的，例如生成客户端或者生成文档。
|
||||
|
||||
<!--
|
||||
|
|
@ -2106,7 +2106,7 @@ valid OpenAPI schemas that it doesn't understand. The conversion won't modify th
|
|||
and therefore won't affect [validation](#validation) in the API server.
|
||||
-->
|
||||
OpenAPI v3 合法性检查模式定义会被转换为 OpenAPI v2 模式定义，并出现在
|
||||
[OpenAPI v2 规范](/zh/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions)
|
||||
[OpenAPI v2 规范](/zh-cn/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions)
|
||||
的 `definitions` 和 `paths` 字段中。
|
||||
|
||||
在转换过程中会发生以下修改，目的是保持与 1.13 版本以前的 kubectl 工具兼容。
|
||||
|
|
@ -2567,7 +2567,7 @@ kubectl get crontabs my-new-cron-object -o jsonpath='{.spec.replicas}'
|
|||
You can use a [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) to protect custom
|
||||
resources that have the scale subresource enabled.
|
||||
-->
|
||||
你可以使用 [PodDisruptionBudget](/zh/docs/tasks/run-application/configure-pdb/)
|
||||
你可以使用 [PodDisruptionBudget](/zh-cn/docs/tasks/run-application/configure-pdb/)
|
||||
来保护启用了 scale 子资源的定制资源。
|
||||
|
||||
<!--
|
||||
|
|
@ -2694,7 +2694,7 @@ crontabs/my-new-cron-object 3s
|
|||
* Serve [multiple versions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/) of a
|
||||
CustomResourceDefinition.
|
||||
-->
|
||||
* 阅读了解[定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
* 阅读了解[定制资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
* 参阅 [CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1-apiextensions-k8s-io)
|
||||
* 参阅支持 CustomResourceDefinition 的[多个版本](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/)
|
||||
* 参阅支持 CustomResourceDefinition 的[多个版本](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/)
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ Setting up an extension API server to work the aggregation layer allows the Kube
|
|||
<!--
|
||||
* You must [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) and enable the apiserver flags.
|
||||
-->
|
||||
* 你必须[配置聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
|
||||
* 你必须[配置聚合层](/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
|
||||
并且启用 API 服务器的相关参数。
|
||||
|
||||
<!-- steps -->
|
||||
|
|
@ -110,7 +110,7 @@ Alternatively, you can use an existing 3rd party solution, such as [apiserver-bu
|
|||
* For a high level overview, see [Extending the Kubernetes API with the aggregation layer](/docs/concepts/api-extension/apiserver-aggregation).
|
||||
* Learn how to [Extend the Kubernetes API Using Custom Resource Definitions](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/).
|
||||
-->
|
||||
* 如果你还未配置，请[配置聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
|
||||
* 如果你还未配置，请[配置聚合层](/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
|
||||
并启用 apiserver 的相关参数。
|
||||
* 高级概述，请参阅[使用聚合层扩展 Kubernetes API](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation)。
|
||||
* 了解如何[使用 Custom Resource Definition 扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
|
||||
* 高级概述，请参阅[使用聚合层扩展 Kubernetes API](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation)。
|
||||
* 了解如何[使用 Custom Resource Definition 扩展 Kubernetes API](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ your API Server egress configuration file.
|
|||
-->
|
||||
你需要配置 API 服务器来使用 Konnectivity 服务，并将网络流量定向到集群节点：
|
||||
|
||||
确保[服务账号令牌卷投射](/zh/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)
|
||||
确保[服务账号令牌卷投射](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)
|
||||
特性被启用。该特性自 Kubernetes v1.20 起默认已被启用。
|
||||
|
||||
1. 创建一个出站流量配置文件，比如 `admin/konnectivity/egress-selector-configuration.yaml`。
|
||||
|
|
|
|||
|
|
@ -131,8 +131,8 @@ and
|
|||
[Secrets](/docs/concepts/configuration/secret/).
|
||||
-->
|
||||
这意味着你可以将那些用来设置环境变量的方法应用于设置命令的参数，其中包括了
|
||||
[ConfigMaps](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) 与
|
||||
[Secrets](/zh/docs/concepts/configuration/secret/)。
|
||||
[ConfigMaps](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/) 与
|
||||
[Secrets](/zh-cn/docs/concepts/configuration/secret/)。
|
||||
|
||||
<!--
|
||||
The environment variable appears in parentheses, `"$(VAR)"`. This is
|
||||
|
|
@ -168,7 +168,7 @@ args: ["-c", "while true; do echo hello; sleep 10;done"]
|
|||
* Learn more about [running commands in a container](/docs/tasks/debug/debug-application/get-shell-running-container/).
|
||||
* See [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core).
|
||||
-->
|
||||
* 进一步了解[配置 Pod 和容器](/zh/docs/tasks/)
|
||||
* 进一步了解[在容器中运行命令](/zh/docs/tasks/debug/debug-application/get-shell-running-container/)
|
||||
* 进一步了解[配置 Pod 和容器](/zh-cn/docs/tasks/)
|
||||
* 进一步了解[在容器中运行命令](/zh-cn/docs/tasks/debug/debug-application/get-shell-running-container/)
|
||||
* 参阅 [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
|
||||
API 资源
|
||||
|
|
|
|||
|
|
@ -173,7 +173,7 @@ Upon creation, the command `echo Warm greetings to The Most Honorable Kubernetes
|
|||
* See [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core).
|
||||
-->
|
||||
|
||||
* 进一步了解[环境变量](/zh/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)
|
||||
* 进一步了解[通过环境变量来使用 Secret](/zh/docs/concepts/configuration/secret/#using-secrets-as-environment-variables)
|
||||
* 进一步了解[环境变量](/zh-cn/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)
|
||||
* 进一步了解[通过环境变量来使用 Secret](/zh-cn/docs/concepts/configuration/secret/#using-secrets-as-environment-variables)
|
||||
* 关于 [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core) 资源的信息。
|
||||
|
||||
|
|
|
|||
|
|
@ -110,6 +110,6 @@ is defined or not. This can be seen from the `ESCAPED_REFERENCE` case above.
|
|||
* Learn more about [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/).
|
||||
* See [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core).
|
||||
-->
|
||||
* 进一步了解[环境变量](/zh/docs/tasks/inject-data-application/environment-variable-expose-pod-information/).
|
||||
* 进一步了解[环境变量](/zh-cn/docs/tasks/inject-data-application/environment-variable-expose-pod-information/).
|
||||
* 参阅 [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core).
|
||||
|
||||
|
|
|
|||
|
|
@ -375,7 +375,7 @@ This functionality is available in Kubernetes v1.6 and later.
|
|||
* Learn more about [Secrets](/docs/concepts/configuration/secret/).
|
||||
* Learn about [Volumes](/docs/concepts/storage/volumes/).
|
||||
-->
|
||||
* 进一步了解 [Secret](/zh/docs/concepts/configuration/secret/)。
|
||||
* 了解 [Volumes](/zh/docs/concepts/storage/volumes/)。
|
||||
* 进一步了解 [Secret](/zh-cn/docs/concepts/configuration/secret/)。
|
||||
* 了解 [Volumes](/zh-cn/docs/concepts/storage/volumes/)。
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ Together, these two ways of exposing Pod and Container fields are called the
|
|||
|
||||
有两种方式可以将 Pod 和 Container 字段呈现给运行中的容器：
|
||||
|
||||
* [环境变量](/zh/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#the-downward-api)
|
||||
* [环境变量](/zh-cn/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#the-downward-api)
|
||||
* 卷文件
|
||||
|
||||
这两种呈现 Pod 和 Container 字段的方式都称为 "Downward API"。
|
||||
|
|
@ -213,7 +213,7 @@ receive Downward API updates.
|
|||
-->
|
||||
{{< note >}}
|
||||
如果容器以
|
||||
[subPath](/zh/docs/concepts/storage/volumes/#using-subpath)卷挂载方式来使用
|
||||
[subPath](/zh-cn/docs/concepts/storage/volumes/#using-subpath)卷挂载方式来使用
|
||||
Downward API，则该容器无法收到更新事件。
|
||||
{{< /note >}}
|
||||
|
||||
|
|
@ -259,7 +259,7 @@ default value of `1` which means cores for cpu and bytes for memory.
|
|||
Create the Pod:
|
||||
-->
|
||||
在这个配置文件中，你可以看到 Pod 有一个
|
||||
[`downwardAPI` 卷](/zh/docs/concepts/storage/volumes/#downwardapi)，
|
||||
[`downwardAPI` 卷](/zh-cn/docs/concepts/storage/volumes/#downwardapi)，
|
||||
并且挂载到容器的 `/etc/podinfo` 目录。
|
||||
|
||||
查看 `downwardAPI` 下面的 `items` 数组。每个数组元素都是一个
|
||||
|
|
@ -353,9 +353,9 @@ variables and `downwardAPI` volumes:
|
|||
* 容器的内存约束值
|
||||
* 容器的内存请求值
|
||||
* 容器的巨页限制值（前提是启用了 `DownwardAPIHugePages`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)）
|
||||
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)）
|
||||
* 容器的巨页请求值（前提是启用了 `DownwardAPIHugePages`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)）
|
||||
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)）
|
||||
* 容器的临时存储约束值
|
||||
* 容器的临时存储请求值
|
||||
|
||||
|
|
@ -411,7 +411,7 @@ basis. For more information, see
|
|||
## 投射键名到指定路径并且指定文件权限 {#project-keys-to-specific-paths-and-file-permissions}
|
||||
|
||||
你可以将键名投射到指定路径并且指定每个文件的访问权限。
|
||||
更多信息，请参阅 [Secret](/zh/docs/concepts/configuration/secret/)。
|
||||
更多信息，请参阅 [Secret](/zh-cn/docs/concepts/configuration/secret/)。
|
||||
|
||||
<!--
|
||||
## Motivation for the Downward API
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ Together, these two ways of exposing Pod and Container fields are called the
|
|||
有两种方式可以将 Pod 和 Container 字段呈现给运行中的容器：
|
||||
|
||||
* 环境变量
|
||||
* [卷文件](/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)
|
||||
* [卷文件](/zh-cn/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)
|
||||
|
||||
这两种呈现 Pod 和 Container 字段的方式统称为 *Downward API*。
|
||||
|
||||
|
|
@ -245,7 +245,7 @@ The output shows the values of selected environment variables:
|
|||
* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core)
|
||||
-->
|
||||
|
||||
* [给容器定义环境变量](/zh/docs/tasks/inject-data-application/define-environment-variable-container/)
|
||||
* [给容器定义环境变量](/zh-cn/docs/tasks/inject-data-application/define-environment-variable-container/)
|
||||
* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
|
||||
* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
|
||||
* [EnvVar](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ Cron jobs can also schedule individual tasks for a specific time, such as if you
|
|||
|
||||
在Kubernetes v1.21 版本中，CronJob 被提升为通用版本。如果你使用的是旧版本的 Kubernetes，请参考你正在使用的 Kubernetes 版本的文档，这样你就能看到准确的信息。旧的 Kubernetes 版本不支持`batch/v1` CronJob API。
|
||||
|
||||
你可以利用 [CronJobs](/zh/docs/concepts/workloads/controllers/cron-jobs) 执行基于时间调度的任务。这些自动化任务和 Linux 或者 Unix 系统的 [Cron](https://en.wikipedia.org/wiki/Cron) 任务类似。
|
||||
你可以利用 [CronJobs](/zh-cn/docs/concepts/workloads/controllers/cron-jobs) 执行基于时间调度的任务。这些自动化任务和 Linux 或者 Unix 系统的 [Cron](https://en.wikipedia.org/wiki/Cron) 任务类似。
|
||||
|
||||
CronJobs 在创建周期性以及重复性的任务时很有帮助，例如执行备份操作或者发送邮件。CronJobs 也可以在特定时间调度单个任务，例如你想调度低活跃周期的任务。
|
||||
|
||||
|
|
@ -45,7 +45,7 @@ CronJobs 有一些限制和特点。
|
|||
例如，在特定状况下，同一个 CronJob 可以创建多个任务。
|
||||
因此，任务应该是幂等的。
|
||||
|
||||
查看更多限制，请参考 [CronJobs](/zh/docs/concepts/workloads/controllers/cron-jobs)。
|
||||
查看更多限制，请参考 [CronJobs](/zh-cn/docs/concepts/workloads/controllers/cron-jobs)。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
|
@ -194,7 +194,7 @@ Deleting the cron job removes all the jobs and pods it created and stops it from
|
|||
You can read more about removing jobs in [garbage collection](/docs/concepts/workloads/controllers/garbage-collection/).
|
||||
-->
|
||||
删除 CronJob 会清除它创建的所有任务和 Pod，并阻止它创建额外的任务。你可以查阅
|
||||
[垃圾收集](/zh/docs/concepts/workloads/controllers/garbage-collection/)。
|
||||
[垃圾收集](/zh-cn/docs/concepts/workloads/controllers/garbage-collection/)。
|
||||
|
||||
<!--
|
||||
## Writing a Cron Job Spec
|
||||
|
|
@ -209,8 +209,8 @@ A cron job config also needs a [`.spec` section](https://git.k8s.io/community/co
|
|||
|
||||
像 Kubernetes 的其他配置一样，CronJob 需要 `apiVersion`、`kind`、和 `metadata` 域。
|
||||
配置文件的一般信息，请参考
|
||||
[部署应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/) 和
|
||||
[使用 kubectl 管理资源](/zh/docs/concepts/overview/working-with-objects/object-management/).
|
||||
[部署应用](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/) 和
|
||||
[使用 kubectl 管理资源](/zh-cn/docs/concepts/overview/working-with-objects/object-management/).
|
||||
|
||||
CronJob 配置也需要包括
|
||||
[`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
|
||||
|
|
@ -272,10 +272,10 @@ For information about writing a job `.spec`, see
|
|||
### 任务模版
|
||||
|
||||
`.spec.jobTemplate`是任务的模版，它是必须的。它和
|
||||
[Job](/zh/docs/concepts/workloads/controllers/job/)的语法完全一样，
|
||||
[Job](/zh-cn/docs/concepts/workloads/controllers/job/)的语法完全一样，
|
||||
除了它是嵌套的没有 `apiVersion` 和 `kind`。
|
||||
编写任务的 `.spec` ，请参考
|
||||
[编写 Job 的Spec](/zh/docs/concepts/workloads/controllers/job/#writing-a-job-spec)。
|
||||
[编写 Job 的Spec](/zh-cn/docs/concepts/workloads/controllers/job/#writing-a-job-spec)。
|
||||
|
||||
<!--
|
||||
### Starting Deadline
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workload
|
|||
-->
|
||||
|
||||
要熟悉 Job 基本用法（非并行的），请参考
|
||||
[Job](/zh/docs/concepts/workloads/controllers/job/)。
|
||||
[Job](/zh-cn/docs/concepts/workloads/controllers/job/)。
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
|
@ -448,7 +448,7 @@ want to consider one of the other [job patterns](/docs/concepts/jobs/run-to-comp
|
|||
本文所讲述的处理方法的好处是你不需要修改你的 "worker" 程序使其知道工作队列的存在。
|
||||
|
||||
本文所描述的方法需要你运行一个消息队列服务。如果不方便运行消息队列服务，你也许会考虑另外一种
|
||||
[任务模式](/zh/docs/concepts/workloads/controllers/job/#job-patterns)。
|
||||
[任务模式](/zh-cn/docs/concepts/workloads/controllers/job/#job-patterns)。
|
||||
|
||||
<!--
|
||||
This approach creates a pod for every work item. If your work items only take a few seconds,
|
||||
|
|
@ -464,13 +464,13 @@ communicate with the work queue using a client library.
|
|||
|
||||
本文所述的方法为每个工作项创建了一个 Pod。
|
||||
如果你的工作项仅需数秒钟，为每个工作项创建 Pod会增加很多的常规消耗。
|
||||
可以考虑另外的方案请参考[示例](/zh/docs/tasks/job/fine-parallel-processing-work-queue/)，
|
||||
可以考虑另外的方案请参考[示例](/zh-cn/docs/tasks/job/fine-parallel-processing-work-queue/)，
|
||||
这种方案可以实现每个 Pod 执行多个工作项。
|
||||
|
||||
示例中，我们使用 `amqp-consume` 从消息队列读取消息并执行我们真正的程序。
|
||||
这样的好处是你不需要修改你的程序使其知道队列的存在。
|
||||
要了解怎样使用客户端库和工作队列通信，请参考
|
||||
[不同的示例](/zh/docs/tasks/job/fine-parallel-processing-work-queue/)。
|
||||
[不同的示例](/zh-cn/docs/tasks/job/fine-parallel-processing-work-queue/)。
|
||||
|
||||
<!--
|
||||
## Caveats
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ Here is an overview of the steps in this example:
|
|||
Be familiar with the basic,
|
||||
non-parallel, use of [Job](/docs/concepts/workloads/controllers/job/).
|
||||
-->
|
||||
熟悉基本的、非并行的 [Job](/zh/docs/concepts/workloads/controllers/job/)。
|
||||
熟悉基本的、非并行的 [Job](/zh-cn/docs/concepts/workloads/controllers/job/)。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
|
@ -226,7 +226,7 @@ You need to push to a public repository or [configure your cluster to be able to
|
|||
your private repository](/docs/concepts/containers/images/).
|
||||
-->
|
||||
你需要将镜像 push 到一个公共仓库或者
|
||||
[配置集群访问你的私有仓库](/zh/docs/concepts/containers/images/)。
|
||||
[配置集群访问你的私有仓库](/zh-cn/docs/concepts/containers/images/)。
|
||||
|
||||
<!--
|
||||
If you are using [Google Container
|
||||
|
|
@ -356,7 +356,7 @@ If running a queue service or modifying your containers to use a work queue is i
|
|||
want to consider one of the other [job patterns](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns).
|
||||
-->
|
||||
如果你不方便运行一个队列服务或者修改你的容器用于运行一个工作队列，你可以考虑其它的
|
||||
[Job 模式](/zh/docs/concepts/workloads/controllers/job/#job-patterns)。
|
||||
[Job 模式](/zh-cn/docs/concepts/workloads/controllers/job/#job-patterns)。
|
||||
|
||||
<!--
|
||||
If you have a continuous stream of background processing work to run, then
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ expose the index in the `JOB_COMPLETION_INDEX` environment variable.
|
|||
Pod 索引在{{<glossary_tooltip text="注解" term_id="annotation" >}}
|
||||
`batch.kubernetes.io/job-completion-index` 中呈现，具体表示为一个十进制值字符串。
|
||||
为了让容器化的任务进程获得此索引，你可以使用
|
||||
[downward API](/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)
|
||||
[downward API](/zh-cn/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)
|
||||
机制发布注解的值。为方便起见，
|
||||
控制平面自动设置 downward API 以在 `JOB_COMPLETION_INDEX` 环境变量中公开索引。
|
||||
|
||||
|
|
@ -64,7 +64,7 @@ Here is an overview of the steps in this example:
|
|||
You should already be familiar with the basic,
|
||||
non-parallel, use of [Job](/docs/concepts/workloads/controllers/job/).
|
||||
-->
|
||||
你应该已经熟悉 [Job](/zh/docs/concepts/workloads/controllers/job/) 的基本的、非并行的用法。
|
||||
你应该已经熟悉 [Job](/zh-cn/docs/concepts/workloads/controllers/job/) 的基本的、非并行的用法。
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
|
@ -149,13 +149,13 @@ to publish the index to containers. You can also choose to load a list of values
|
|||
from a [ConfigMap as an environment variable or file](/docs/tasks/configure-pod-container/configure-pod-configmap/).
|
||||
-->
|
||||
在上面的示例中，你使用 Job 控制器为所有容器设置的内置 `JOB_COMPLETION_INDEX` 环境变量。
|
||||
[Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)
|
||||
[Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/)
|
||||
将索引映射到一个静态值，并将其写入一个文件，该文件通过
|
||||
[emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir)
|
||||
[emptyDir 卷](/zh-cn/docs/concepts/storage/volumes/#emptydir)
|
||||
与运行 worker 的容器共享。或者，你可以
|
||||
[通过 Downward API 定义自己的环境变量](/zh/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)
|
||||
[通过 Downward API 定义自己的环境变量](/zh-cn/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)
|
||||
将索引发布到容器。你还可以选择从
|
||||
[包含 ConfigMap 的环境变量或文件](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
[包含 ConfigMap 的环境变量或文件](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
加载值列表。
|
||||
|
||||
<!--
|
||||
|
|
@ -164,7 +164,7 @@ value as a volume file](/docs/tasks/inject-data-application/downward-api-volume-
|
|||
like shown in the following example:
|
||||
-->
|
||||
或者也可以直接
|
||||
[使用 Downward API 将注解值作为卷文件传递](/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#store-pod-fields)，
|
||||
[使用 Downward API 将注解值作为卷文件传递](/zh-cn/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#store-pod-fields)，
|
||||
如下例所示：
|
||||
|
||||
{{< codenew language="yaml" file="application/job/indexed-job-vol.yaml" >}}
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ this pattern fits more realistic use cases.
|
|||
You should be familiar with the basic,
|
||||
non-parallel, use of [Job](/docs/concepts/workloads/controllers/job/).
|
||||
-->
|
||||
你应先熟悉基本的、非并行的 [Job](/zh/docs/concepts/workloads/controllers/job/)
|
||||
你应先熟悉基本的、非并行的 [Job](/zh-cn/docs/concepts/workloads/controllers/job/)
|
||||
的用法。
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
|
@ -258,7 +258,7 @@ to contain only certain characters.
|
|||
|
||||
在[第一个例子](#create-jobs-based-on-a-template)中，模板的每个示例都有一个参数
|
||||
而该参数也用在 Job 名称中。不过，对象
|
||||
[名称](/zh/docs/concepts/overview/working-with-objects/names/#names)
|
||||
[名称](/zh-cn/docs/concepts/overview/working-with-objects/names/#names)
|
||||
被限制只能使用某些字符。
|
||||
|
||||
<!--
|
||||
|
|
@ -453,7 +453,7 @@ that you can use if you wish.
|
|||
-->
|
||||
{{< note >}}
|
||||
标签键 `jobgroup` 没什么特殊的，也不是保留字。 你可以选择你自己的标签方案。
|
||||
如果愿意，有一些[建议的标签](/zh/docs/concepts/overview/working-with-objects/common-labels/#labels)
|
||||
如果愿意，有一些[建议的标签](/zh-cn/docs/concepts/overview/working-with-objects/common-labels/#labels)
|
||||
可供使用。
|
||||
{{< /note >}}
|
||||
|
||||
|
|
@ -490,8 +490,8 @@ objects.
|
|||
You could also consider writing your own [controller](/docs/concepts/architecture/controller/)
|
||||
to manage Job objects automatically.
|
||||
-->
|
||||
还有一些其他[作业模式](/zh/docs/concepts/workloads/controllers/job/#job-patterns)
|
||||
还有一些其他[作业模式](/zh-cn/docs/concepts/workloads/controllers/job/#job-patterns)
|
||||
可供选择，这些模式都能用来处理大量任务而又不会创建过多的 Job 对象。
|
||||
|
||||
你也可以考虑编写自己的[控制器](/zh/docs/concepts/architecture/controller/)
|
||||
你也可以考虑编写自己的[控制器](/zh-cn/docs/concepts/architecture/controller/)
|
||||
来自动管理 Job 对象。
|
||||
|
|
|
|||
|
|
@ -230,6 +230,6 @@ Some example values of `matchImages` patterns are:
|
|||
[kubelet configuration API (v1alpha1) reference](/docs/reference/config-api/kubelet-config.v1alpha1/).
|
||||
* Read the [kubelet credential provider API reference (v1alpha1)](/docs/reference/config-api/kubelet-credentialprovider.v1alpha1/).
|
||||
-->
|
||||
* 阅读 [kubelet 配置 API (v1alpha1) 参考](/zh/docs/reference/config-api/kubelet-config.v1alpha1/)中有关 `CredentialProviderConfig` 的详细信息。
|
||||
* 阅读 [kubelet 配置 API (v1alpha1) 参考](/zh-cn/docs/reference/config-api/kubelet-config.v1alpha1/)中有关 `CredentialProviderConfig` 的详细信息。
|
||||
* 阅读 [kubelet 凭据提供程序 API 参考 (v1alpha1)](/docs/reference/config-api/kubelet-credentialprovider.v1alpha1/)。
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue