[zh] Fix links in zh localization (2)
This commit is contained in:
@@ -288,7 +288,7 @@ on configuring Controller Manager authorization, see
|
||||
|
||||
- [控制器管理器组件](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/)
|
||||
必须运行在
|
||||
[安全的 API 端口](/zh/docs/reference/access-authn-authz/controlling-access/),
|
||||
[安全的 API 端口](/zh/docs/concepts/security/controlling-access/),
|
||||
并且一定不能具有超级用户权限。
|
||||
否则其请求会绕过身份认证和鉴权模块控制,从而导致所有 PodSecurityPolicy 对象
|
||||
都被启用,用户亦能创建特权容器。
|
||||
@@ -696,7 +696,7 @@ several security mechanisms.
|
||||
See [Pod Security Standards](/docs/concepts/security/pod-security-standards/#policy-instantiation) for more examples.
|
||||
-->
|
||||
更多的示例可参考
|
||||
[Pod 安全标准](/docs/concepts/security/pod-security-standards/#policy-instantiation)。
|
||||
[Pod 安全标准](/zh/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 安全标准](/docs/concepts/security/pod-security-standards/)
|
||||
- 参阅[Pod 安全标准](zh/docs/concepts/security/pod-security-standards/)
|
||||
了解策略建议。
|
||||
- 阅读 [Pod 安全策略参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)了解 API 细节。
|
||||
|
||||
|
||||
@@ -178,7 +178,8 @@ with prefix `requests.` is allowed for now.
|
||||
Take the GPU resource as an example, if the resource name is `nvidia.com/gpu`, and you want to
|
||||
limit the total number of GPUs requested in a namespace to 4, you can define a quota as follows:
|
||||
-->
|
||||
以 GPU 拓展资源为例,如果资源名称为 `nvidia.com/gpu`,并且要将命名空间中请求的 GPU 资源总数限制为 4,则可以如下定义配额:
|
||||
以 GPU 拓展资源为例,如果资源名称为 `nvidia.com/gpu`,并且要将命名空间中请求的 GPU
|
||||
资源总数限制为 4,则可以如下定义配额:
|
||||
|
||||
* `requests.nvidia.com/gpu: 4`
|
||||
|
||||
@@ -196,7 +197,8 @@ In addition, you can limit consumption of storage resources based on associated
|
||||
-->
|
||||
## 存储资源配额
|
||||
|
||||
用户可以对给定命名空间下的[存储资源](/docs/concepts/storage/persistent-volumes/)总量进行限制。
|
||||
用户可以对给定命名空间下的[存储资源](/zh/docs/concepts/storage/persistent-volumes/)
|
||||
总量进行限制。
|
||||
|
||||
此外,还可以根据相关的存储类(Storage Class)来限制存储资源的消耗。
|
||||
|
||||
@@ -219,7 +221,8 @@ In addition, you can limit consumption of storage resources based on associated
|
||||
For example, if an operator wants to quota storage with `gold` storage class separate from `bronze` storage class, the operator can
|
||||
define a quota as follows:
|
||||
-->
|
||||
例如,如果一个操作人员针对 `gold` 存储类型与 `bronze` 存储类型设置配额,操作人员可以定义如下配额:
|
||||
例如,如果一个操作人员针对 `gold` 存储类型与 `bronze` 存储类型设置配额,
|
||||
操作人员可以定义如下配额:
|
||||
|
||||
* `gold.storageclass.storage.k8s.io/requests.storage: 500Gi`
|
||||
* `bronze.storageclass.storage.k8s.io/requests.storage: 100Gi`
|
||||
@@ -279,7 +282,8 @@ The same syntax can be used for custom resources.
|
||||
For example, to create a quota on a `widgets` custom resource in the `example.com` API group, use `count/widgets.example.com`.
|
||||
-->
|
||||
相同语法也可用于自定义资源。
|
||||
例如,要对 `example.com` API 组中的自定义资源 `widgets` 设置配额,请使用 `count/widgets.example.com`。
|
||||
例如,要对 `example.com` API 组中的自定义资源 `widgets` 设置配额,请使用
|
||||
`count/widgets.example.com`。
|
||||
|
||||
<!--
|
||||
When using `count/*` resource quota, an object is charged against the quota if it exists in server storage.
|
||||
@@ -292,7 +296,8 @@ a poorly configured CronJob. CronJobs that create too many Jobs in a namespace c
|
||||
这些类型的配额有助于防止存储资源耗尽。例如,用户可能想根据服务器的存储能力来对服务器中
|
||||
Secret 的数量进行配额限制。
|
||||
集群中存在过多的 Secret 实际上会导致服务器和控制器无法启动。
|
||||
用户可以选择对 Job 进行配额管理,以防止配置不当的 CronJob 在某命名空间中创建太多 Job 而导致集群拒绝服务。
|
||||
用户可以选择对 Job 进行配额管理,以防止配置不当的 CronJob 在某命名空间中创建太多
|
||||
Job 而导致集群拒绝服务。
|
||||
|
||||
<!--
|
||||
It is possible to do generic object count quota on a limited set of resources.
|
||||
@@ -337,7 +342,8 @@ quota on a namespace to avoid the case where a user creates many small pods and
|
||||
exhausts the cluster's supply of Pod IPs.
|
||||
-->
|
||||
例如,`pods` 配额统计某个命名空间中所创建的、非终止状态的 `Pod` 个数并确保其不超过某上限值。
|
||||
用户可能希望在某命名空间中设置 `pods` 配额,以避免有用户创建很多小的 Pod,从而耗尽集群所能提供的 Pod IP 地址。
|
||||
用户可能希望在某命名空间中设置 `pods` 配额,以避免有用户创建很多小的 Pod,
|
||||
从而耗尽集群所能提供的 Pod IP 地址。
|
||||
|
||||
<!--
|
||||
## Quota Scopes
|
||||
@@ -460,7 +466,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 可以创建为特定的[优先级](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)。
|
||||
Pod 可以创建为特定的[优先级](/zh/docs/concepts/configuration/pod-priority-preemption/#pod-priority)。
|
||||
通过使用配额规约中的 `scopeSelector` 字段,用户可以根据 Pod 的优先级控制其系统资源消耗。
|
||||
|
||||
<!--
|
||||
@@ -891,7 +897,8 @@ will be able to consume these priority classes by default.
|
||||
To enforce this, kube-apiserver flag `-admission-control-config-file` should be
|
||||
used to pass path to the following configuration file:
|
||||
-->
|
||||
要实现此目的,应使用 kube-apiserver 标志 `--admission-control-config-file` 传递如下配置文件的路径:
|
||||
要实现此目的,应设置 kube-apiserver 的标志 `--admission-control-config-file`
|
||||
指向如下配置文件:
|
||||
|
||||
```yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
@@ -938,5 +945,5 @@ For example:
|
||||
- 查看[如何使用资源配额的详细示例](/zh/docs/tasks/administer-cluster/quota-api-object/)。
|
||||
- 阅读[优先级类配额支持的设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)。
|
||||
了解更多信息。
|
||||
- 参阅[LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)
|
||||
- 参阅 [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user