Merge pull request #34519 from howieyuen/task-pages-4
[zh]Update tasks pages(part-4) for links with '/zh/' prefix, using new prefix '/zh-cn/'
This commit is contained in:
Kubernetes Prow Robot
GitHub
commit
60390ff3c0
|
|
@ -134,5 +134,5 @@ a `disktype=ssd` label.
|
|||
Learn more about
|
||||
[labels and selectors](/docs/concepts/overview/working-with-objects/labels/).
|
||||
-->
|
||||
进一步了解[标签和选择器](/zh/docs/concepts/overview/working-with-objects/labels/)
|
||||
进一步了解[标签和选择器](/zh-cn/docs/concepts/overview/working-with-objects/labels/)
|
||||
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ unless the Pod's grace period expires. For more details, see
|
|||
-->
|
||||
Kubernetes 在容器结束前立即发送 preStop 事件。除非 Pod 宽限期限超时，Kubernetes 的容器管理逻辑
|
||||
会一直阻塞等待 preStop 处理函数执行完毕。更多的相关细节，可以参阅
|
||||
[Pods 的结束](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。
|
||||
[Pods 的结束](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。
|
||||
|
||||
<!--
|
||||
Kubernetes only sends the preStop event when a Pod is *terminated*.
|
||||
|
|
@ -146,8 +146,8 @@ preStop 的事件处理逻辑不会被触发。这个限制在
|
|||
* Learn more about [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
|
||||
* Learn more about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/).
|
||||
-->
|
||||
* 进一步了解[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/)。
|
||||
* 进一步了解[Pod 的生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/)。
|
||||
* 进一步了解[容器生命周期回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks/)。
|
||||
* 进一步了解[Pod 的生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/)。
|
||||
|
||||
<!--
|
||||
### Reference
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ Next, install the CRD with `kubectl apply -f gmsa-crd.yaml`
|
|||
### 安装 GMSACredentialSpec CRD
|
||||
|
||||
你需要在集群上配置一个用于 GMSA 凭据规约资源的
|
||||
[CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)(CRD)，
|
||||
[CustomResourceDefinition](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)(CRD)，
|
||||
以便定义类型为 `GMSACredentialSpec` 的自定义资源。
|
||||
首先下载 GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml)
|
||||
并将其保存为 `gmsa-crd.yaml`。接下来执行 `kubectl apply -f gmsa-crd.yaml`
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ despite bugs.
|
|||
-->
|
||||
这篇文章介绍如何给容器配置活跃（Liveness）、就绪（Readiness）和启动（Startup）探测器。
|
||||
|
||||
[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/)
|
||||
[kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/)
|
||||
使用存活探测器来确定什么时候要重启容器。
|
||||
例如，存活探测器可以探测到应用死锁（应用程序在运行，但是无法继续执行后面的步骤）情况。
|
||||
重启这种状态下的容器有助于提高应用的可用性，即使其中存在缺陷。
|
||||
|
|
@ -354,7 +354,7 @@ Here is an example manifest:
|
|||
如果你的应用实现了 [gRPC 健康检查协议](https://github.com/grpc/grpc/blob/master/doc/health-checking.md)，
|
||||
kubelet 可以配置为使用该协议来执行应用活跃性检查。
|
||||
你必须启用 `GRPCContainerProbe`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
才能配置依赖于 gRPC 的检查机制。
|
||||
|
||||
下面是一个示例清单：
|
||||
|
|
@ -638,7 +638,7 @@ eventual removal of that feature gate.
|
|||
这一缺陷在 Kubernetes v1.20 版本中得到修复。你可能一直依赖于之前错误的探测行为，
|
||||
甚至都没有觉察到这一问题的存在，因为默认的超时值是 1 秒钟。
|
||||
作为集群管理员，你可以在所有的 kubelet 上禁用 `ExecProbeTimeout`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
（将其设置为 `false`），从而恢复之前版本中的运行行为。之后当集群中所有的
|
||||
exec 探针都设置了 `timeoutSeconds` 参数后，移除此标志重载。
|
||||
如果你有 Pod 受到此默认 1 秒钟超时值的影响，你应该更新这些 Pod 对应的探针的超时值，
|
||||
|
|
@ -860,7 +860,7 @@ It will be rejected by the API server.
|
|||
* Learn more about
|
||||
[Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
|
||||
-->
|
||||
* 进一步了解[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
|
||||
* 进一步了解[容器探针](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
|
||||
|
||||
<!--
|
||||
You can also read the API references for:
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ do not already have a single-node cluster, you can create one by using
|
|||
如果还没有单节点集群，可以使用
|
||||
[Minikube](https://minikube.sigs.k8s.io/docs/) 创建一个。
|
||||
.
|
||||
* 熟悉[持久卷](/zh/docs/concepts/storage/persistent-volumes/)中的材料。
|
||||
* 熟悉[持久卷](/zh-cn/docs/concepts/storage/persistent-volumes/)中的材料。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
|
@ -464,7 +464,7 @@ PersistentVolume are not present on the Pod resource itself.
|
|||
* Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
|
||||
* Read the [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md).
|
||||
-->
|
||||
* 进一步了解 [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/)
|
||||
* 进一步了解 [PersistentVolumes](/zh-cn/docs/concepts/storage/persistent-volumes/)
|
||||
* 阅读[持久存储设计文档](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md)
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ The name of a ConfigMap object must be a valid
|
|||
其中，`<映射名称>` 是为 ConfigMap 指定的名称，`<数据源>` 是要从中提取数据的目录、
|
||||
文件或者字面值。
|
||||
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).
|
||||
|
||||
<!--
|
||||
When you are creating a ConfigMap based on a file, the key in the \<data-source> defaults to the basename of the file, and the value defaults to the file content.
|
||||
|
|
@ -1053,7 +1053,7 @@ basis. The [Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files
|
|||
### 映射键到指定路径并设置文件访问权限 {#project-keys-to-specific-paths-and-file-permissions}
|
||||
|
||||
你可以将指定键名投射到特定目录，也可以逐个文件地设定访问权限。
|
||||
[Secret 用户指南](/zh/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod)
|
||||
[Secret 用户指南](/zh-cn/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod)
|
||||
中为这一语法提供了解释。
|
||||
|
||||
<!--
|
||||
|
|
@ -1098,7 +1098,7 @@ kubelet 同步周期（默认 1 分钟） + ConfigMap 在 kubelet 中缓存的 T
|
|||
A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates.
|
||||
-->
|
||||
{{< note >}}
|
||||
使用 ConfigMap 作为 [subPath](/zh/docs/concepts/storage/volumes/#using-subpath)
|
||||
使用 ConfigMap 作为 [subPath](/zh-cn/docs/concepts/storage/volumes/#using-subpath)
|
||||
的数据卷将不会收到 ConfigMap 更新。
|
||||
{{< /note >}}
|
||||
|
||||
|
|
@ -1113,7 +1113,7 @@ The ConfigMap API resource stores configuration data as key-value pairs. The dat
|
|||
|
||||
ConfigMap API 资源将配置数据存储为键值对。
|
||||
数据可以在 Pod 中使用，也可以用来提供系统组件（如控制器）的配置。
|
||||
ConfigMap 与 [Secret](/zh/docs/concepts/configuration/secret/) 类似，
|
||||
ConfigMap 与 [Secret](/zh-cn/docs/concepts/configuration/secret/) 类似，
|
||||
但是提供的是一种处理不含敏感信息的字符串的方法。
|
||||
用户和系统组件都可以在 ConfigMap 中存储配置数据。
|
||||
|
||||
|
|
@ -1123,7 +1123,7 @@ ConfigMaps should reference properties files, not replace them. Think of the Con
|
|||
{{< note >}}
|
||||
ConfigMap 应该引用属性文件，而不是替换它们。可以将 ConfigMap 理解为类似于 Linux
|
||||
`/etc` 目录及其内容的东西。例如，如果你基于 ConfigMap 创建
|
||||
[Kubernetes 卷](/zh/docs/concepts/storage/volumes/)，则 ConfigMap
|
||||
[Kubernetes 卷](/zh-cn/docs/concepts/storage/volumes/)，则 ConfigMap
|
||||
中的每个数据项都由该数据卷中的某个独立的文件表示。
|
||||
{{< /note >}}
|
||||
|
||||
|
|
@ -1220,6 +1220,6 @@ data:
|
|||
<!--
|
||||
* Follow a real world example of [Configuring Redis using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/).
|
||||
-->
|
||||
* 浏览[使用 ConfigMap 配置 Redis](/zh/docs/tutorials/configuration/configure-redis-using-configmap/)
|
||||
* 浏览[使用 ConfigMap 配置 Redis](/zh-cn/docs/tutorials/configuration/configure-redis-using-configmap/)
|
||||
真实示例。
|
||||
|
||||
|
|
|
|||
|
|
@ -138,8 +138,8 @@ The output shows that nginx is serving the web page that was written by the init
|
|||
* Learn more about [Debugging Init Containers](/docs/tasks/debug/debug-application/debug-init-containers/)
|
||||
-->
|
||||
|
||||
* 进一步了解[同一 Pod 中的容器间的通信](/zh/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/)。
|
||||
* 进一步了解 [Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)。
|
||||
* 进一步了解[卷](/zh/docs/concepts/storage/volumes/)。
|
||||
* 进一步了解 [Init 容器排错](/zh/docs/tasks/debug/debug-application/debug-init-containers/)。
|
||||
* 进一步了解[同一 Pod 中的容器间的通信](/zh-cn/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/)。
|
||||
* 进一步了解 [Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/)。
|
||||
* 进一步了解[卷](/zh-cn/docs/concepts/storage/volumes/)。
|
||||
* 进一步了解 [Init 容器排错](/zh-cn/docs/tasks/debug/debug-application/debug-init-containers/)。
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ several existing volume sources into the same directory. Currently, `secret`, `c
|
|||
and `serviceAccountToken` volumes can be projected.
|
||||
-->
|
||||
|
||||
本文介绍怎样通过[`projected`](/zh/docs/concepts/storage/volumes/#projected) 卷将现有的多个卷资源挂载到相同的目录。
|
||||
本文介绍怎样通过[`projected`](/zh-cn/docs/concepts/storage/volumes/#projected) 卷将现有的多个卷资源挂载到相同的目录。
|
||||
当前，`secret`、`configMap`、`downwardAPI` 和 `serviceAccountToken` 卷可以被投射。
|
||||
|
||||
<!--
|
||||
|
|
@ -47,7 +47,7 @@ Here is the configuration file for the Pod:
|
|||
## 为 Pod 配置 projected 卷
|
||||
|
||||
本练习中，你将从本地文件来创建包含有用户名和密码的 Secret。然后创建运行一个容器的 Pod，
|
||||
该 Pod 使用[`projected`](/zh/docs/concepts/storage/volumes/#projected) 卷将 Secret 挂载到相同的路径下。
|
||||
该 Pod 使用[`projected`](/zh-cn/docs/concepts/storage/volumes/#projected) 卷将 Secret 挂载到相同的路径下。
|
||||
|
||||
下面是 Pod 的配置文件：
|
||||
|
||||
|
|
@ -126,6 +126,6 @@ kubectl delete secret user pass
|
|||
* Read the [all-in-one volume](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md) design document.
|
||||
-->
|
||||
|
||||
* 进一步了解[`projected`](/zh/docs/concepts/storage/volumes/#projected) 卷。
|
||||
* 进一步了解[`projected`](/zh-cn/docs/concepts/storage/volumes/#projected) 卷。
|
||||
* 阅读[一体卷](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md)设计文档。
|
||||
|
||||
|
|
|
|||
|
|
@ -222,6 +222,6 @@ For more information about these limtations, check [here](https://support.micros
|
|||
* [Managing Workload Identity with Group Managed Service Accounts (GMSA)](/docs/concepts/windows/user-guide/#managing-workload-identity-with-group-managed-service-accounts)
|
||||
* [Configure GMSA for Windows pods and containers](/docs/tasks/configure-pod-container/configure-gmsa/)
|
||||
-->
|
||||
* [Kubernetes 中调度 Windows 容器的指南](/zh/docs/concepts/windows/user-guide/)
|
||||
* [使用组托管服务帐户（GMSA）管理工作负载身份](/zh/docs/concepts/windows/user-guide/#managing-workload-identity-with-group-managed-service-accounts)
|
||||
* [Windows 下 pod 和容器的 GMSA 配置](/zh/docs/tasks/configure-pod-container/configure-gmsa/)
|
||||
* [Kubernetes 中调度 Windows 容器的指南](/zh-cn/docs/concepts/windows/user-guide/)
|
||||
* [使用组托管服务帐户（GMSA）管理工作负载身份](/zh-cn/docs/concepts/windows/user-guide/#managing-workload-identity-with-group-managed-service-accounts)
|
||||
* [Windows 下 pod 和容器的 GMSA 配置](/zh-cn/docs/tasks/configure-pod-container/configure-gmsa/)
|
||||
|
|
|
|||
|
|
@ -73,9 +73,9 @@ In version 1.6+, you can opt out of automounting API credentials for a service a
|
|||
`automountServiceAccountToken: false` on the service account:
|
||||
-->
|
||||
你可以使用自动挂载给 Pod 的服务账户凭据访问 API，
|
||||
[访问集群](/zh/docs/tasks/access-application-cluster/access-cluster/)页面中有相关描述。
|
||||
[访问集群](/zh-cn/docs/tasks/access-application-cluster/access-cluster/)页面中有相关描述。
|
||||
服务账户的 API 许可取决于你所使用的
|
||||
[鉴权插件和策略](/zh/docs/reference/access-authn-authz/authorization/#authorization-modules)。
|
||||
[鉴权插件和策略](/zh-cn/docs/reference/access-authn-authz/authorization/#authorization-modules)。
|
||||
|
||||
在 1.6 以上版本中，你可以通过在服务账户上设置 `automountServiceAccountToken: false`
|
||||
来实现不给服务账号自动挂载 API 凭据：
|
||||
|
|
@ -155,7 +155,7 @@ The name of a ServiceAccount object must be a valid
|
|||
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
-->
|
||||
ServiceAccount 对象的名字必须是一个有效的
|
||||
[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).
|
||||
|
||||
<!--
|
||||
If you get a complete dump of the service account object, like this:
|
||||
|
|
@ -195,7 +195,7 @@ field of a pod to the name of the service account you wish to use.
|
|||
那么你就能看到系统已经自动创建了一个令牌并且被服务账户所引用。
|
||||
|
||||
你可以使用授权插件来
|
||||
[设置服务账户的访问许可](/zh/docs/reference/access-authn-authz/rbac/#service-account-permissions)。
|
||||
[设置服务账户的访问许可](/zh-cn/docs/reference/access-authn-authz/rbac/#service-account-permissions)。
|
||||
|
||||
要使用非默认的服务账户，将 Pod 的 `spec.serviceAccountName` 字段设置为你想用的服务账户名称。
|
||||
|
||||
|
|
@ -289,7 +289,7 @@ The content of `token` is elided here.
|
|||
|
||||
### 创建 ImagePullSecret
|
||||
|
||||
- 创建一个 ImagePullSecret，如同[为 Pod 设置 ImagePullSecret](/zh/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)所述。
|
||||
- 创建一个 ImagePullSecret，如同[为 Pod 设置 ImagePullSecret](/zh-cn/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)所述。
|
||||
|
||||
```shell
|
||||
kubectl create secret docker-registry myregistrykey --docker-server=DUMMY_SERVER \
|
||||
|
|
@ -494,7 +494,7 @@ This behavior is configured on a PodSpec using a ProjectedVolume type called
|
|||
pod with a token with an audience of "vault" and a validity duration of two
|
||||
hours, you would configure the following in your PodSpec:
|
||||
-->
|
||||
使用名为 [ServiceAccountToken](/zh/docs/concepts/storage/volumes/#projected) 的
|
||||
使用名为 [ServiceAccountToken](/zh-cn/docs/concepts/storage/volumes/#projected) 的
|
||||
ProjectedVolume 类型在 PodSpec 上配置此功能。
|
||||
要向 Pod 提供具有 "vault" 用户以及两个小时有效期的令牌，可以在 PodSpec 中配置以下内容：
|
||||
|
||||
|
|
@ -640,7 +640,7 @@ See also:
|
|||
-->
|
||||
另请参见：
|
||||
|
||||
- [服务账号的集群管理员指南](/zh/docs/reference/access-authn-authz/service-accounts-admin/)
|
||||
- [服务账号的集群管理员指南](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/)
|
||||
- [服务账号签署密钥检索 KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/1393-oidc-discovery)
|
||||
- [OIDC 发现规范](https://openid.net/specs/openid-connect-discovery-1_0.html)
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ applications, such as key-value stores (such as Redis) and databases.
|
|||
此页面展示了如何配置 Pod 以使用卷进行存储。
|
||||
|
||||
只要容器存在，容器的文件系统就会存在，因此当一个容器终止并重新启动，对该容器的文件系统改动将丢失。
|
||||
对于独立于容器的持久化存储，你可以使用[卷](/zh/docs/concepts/storage/volumes/)。
|
||||
对于独立于容器的持久化存储，你可以使用[卷](/zh-cn/docs/concepts/storage/volumes/)。
|
||||
这对于有状态应用程序尤为重要，例如键值存储（如 Redis）和数据库。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
|
@ -44,7 +44,7 @@ restarts. Here is the configuration file for the Pod:
|
|||
## 为 Pod 配置卷 {#configure-a-volume-for-a-pod}
|
||||
|
||||
在本练习中，你将创建一个运行 Pod，该 Pod 仅运行一个容器并拥有一个类型为
|
||||
[emptyDir](/zh/docs/concepts/storage/volumes/#emptydir) 的卷，
|
||||
[emptyDir](/zh-cn/docs/concepts/storage/volumes/#emptydir) 的卷，
|
||||
在整个 Pod 生命周期中一直存在，即使 Pod 中的容器被终止和重启。以下是 Pod 的配置：
|
||||
|
||||
{{< codenew file="pods/storage/redis.yaml" >}}
|
||||
|
|
@ -193,5 +193,5 @@ details such as mounting and unmounting the devices on the nodes. See
|
|||
* 参阅 [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)。
|
||||
* 除了 `emptyDir` 提供的本地磁盘存储外，Kubernetes 还支持许多不同的网络附加存储解决方案，
|
||||
包括 GCE 上的 PD 和 EC2 上的 EBS，它们是关键数据的首选，并将处理节点上的一些细节，
|
||||
例如安装和卸载设备。了解更多详情请参阅[卷](/zh/docs/concepts/storage/volumes/)。
|
||||
例如安装和卸载设备。了解更多详情请参阅[卷](/zh-cn/docs/concepts/storage/volumes/)。
|
||||
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ latest version of containerd (v1.6+) to run HostProcess containers.
|
|||
在 Kubernetes v{{< skew currentVersion >}} 中，HostProcess 容器功能特性默认是启用的。
|
||||
kubelet 会直接与 containerd 通信，通过 CRI 将主机进程标志传递过去。
|
||||
你可以使用 containerd 的最新版本（v1.6+）来运行 HostProcess 容器。
|
||||
参阅[如何安装 containerd](/zh/docs/setup/production-environment/container-runtimes/#containerd)。
|
||||
参阅[如何安装 containerd](/zh-cn/docs/setup/production-environment/container-runtimes/#containerd)。
|
||||
|
||||
<!--
|
||||
To *disable* HostProcess containers you need to pass the following feature gate flag to the
|
||||
|
|
@ -117,7 +117,7 @@ To *disable* HostProcess containers you need to pass the following feature gate
|
|||
See [Features Gates](/docs/reference/command-line-tools-reference/feature-gates/#overview)
|
||||
documentation for more details.
|
||||
-->
|
||||
进一步的细节可参阅[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/#overview)文档。
|
||||
进一步的细节可参阅[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#overview)文档。
|
||||
|
||||
<!--
|
||||
## Limitations
|
||||
|
|
@ -177,7 +177,7 @@ the configurations which need to be set to enable the creation of a HostProcess
|
|||
-->
|
||||
启用 Windows HostProcess Pod 需要在 Pod 安全配置中设置合适的选项。
|
||||
在 [Pod
|
||||
安全标准](/zh/docs/concepts/security/pod-security-standards)中所定义的策略中，
|
||||
安全标准](/zh-cn/docs/concepts/security/pod-security-standards)中所定义的策略中，
|
||||
HostProcess Pod 默认是不被 basline 和 restricted 策略支持的。因此建议
|
||||
HostProcess 运行在与 privileged 模式相看齐的策略下。
|
||||
|
||||
|
|
@ -193,11 +193,11 @@ HostProcess 运行在与 privileged 模式相看齐的策略下。
|
|||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td style="white-space: nowrap"><a href="/zh/docs/concepts/security/pod-security-standards"><tt>securityContext.windowsOptions.hostProcess</tt></a></td>
|
||||
<td style="white-space: nowrap"><a href="/zh-cn/docs/concepts/security/pod-security-standards"><tt>securityContext.windowsOptions.hostProcess</tt></a></td>
|
||||
<td>
|
||||
<p><!--Windows pods offer the ability to run <a href="/docs/tasks/configure-pod-container/create-hostprocess-pod">
|
||||
HostProcess containers</a> which enables privileged access to the Windows node.-->
|
||||
Windows Pods 提供运行<a href="/zh/docs/tasks/configure-pod-container/create-hostprocess-pod">
|
||||
Windows Pods 提供运行<a href="/zh-cn/docs/tasks/configure-pod-container/create-hostprocess-pod">
|
||||
HostProcess 容器</a>的能力，这类容器能够具有对 Windows 节点的特权访问权限。</p>
|
||||
<p><strong><!--Allowed Values-->可选值</strong></p>
|
||||
<ul>
|
||||
|
|
@ -206,7 +206,7 @@ HostProcess 运行在与 privileged 模式相看齐的策略下。
|
|||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="white-space: nowrap"><a href="/zh/docs/concepts/security/pod-security-standards"><tt>hostNetwork</tt></a></td>
|
||||
<td style="white-space: nowrap"><a href="/zh-cn/docs/concepts/security/pod-security-standards"><tt>hostNetwork</tt></a></td>
|
||||
<td>
|
||||
<p><!--Will be in host network by default initially. Support
|
||||
to set network to a different compartment may be desirable in
|
||||
|
|
@ -220,7 +220,7 @@ HostProcess 运行在与 privileged 模式相看齐的策略下。
|
|||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="white-space: nowrap"><a href="/zh/docs/tasks/configure-pod-container/configure-runasusername/"><tt>securityContext.windowsOptions.runAsUsername</tt></a></td>
|
||||
<td style="white-space: nowrap"><a href="/zh-cn/docs/tasks/configure-pod-container/configure-runasusername/"><tt>securityContext.windowsOptions.runAsUsername</tt></a></td>
|
||||
<td>
|
||||
<p><!--Specification of which user the HostProcess container should run as is required for the pod spec.-->
|
||||
关于 HostProcess 容器所要使用的用户的规约，需要设置在 Pod 的规约中。
|
||||
|
|
@ -234,7 +234,7 @@ HostProcess 运行在与 privileged 模式相看齐的策略下。
|
|||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="white-space: nowrap"><a href="/zh/docs/concepts/security/pod-security-standards"><tt>runAsNonRoot</tt></a></td>
|
||||
<td style="white-space: nowrap"><a href="/zh-cn/docs/concepts/security/pod-security-standards"><tt>runAsNonRoot</tt></a></td>
|
||||
<td>
|
||||
<p><!--Because HostProcess containers have privileged access to the host, the <tt>runAsNonRoot</tt> field cannot be set to true.-->
|
||||
因为 HostProcess 容器有访问主机的特权，<tt>runAsNonRoot</tt> 字段不可以设置为 true。
|
||||
|
|
|
|||
|
|
@ -18,9 +18,9 @@ As of v1.22, Kubernetes provides a built-in [admission controller](/docs/referen
|
|||
to enforce the [Pod Security Standards](/docs/concepts/security/pod-security-standards).
|
||||
You can configure this admission controller to set cluster-wide defaults and [exemptions](/docs/concepts/security/pod-security-admission/#exemptions).
|
||||
-->
|
||||
在 v1.22 版本中，Kubernetes 提供一种内置的[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#podsecurity)
|
||||
用来强制实施 [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards)。
|
||||
你可以配置此准入控制器来设置集群范围的默认值和[豁免选项](/zh/docs/concepts/security/pod-security-admission/#exemptions)。
|
||||
在 v1.22 版本中，Kubernetes 提供一种内置的[准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#podsecurity)
|
||||
用来强制实施 [Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards)。
|
||||
你可以配置此准入控制器来设置集群范围的默认值和[豁免选项](/zh-cn/docs/concepts/security/pod-security-admission/#exemptions)。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
|
@ -29,7 +29,7 @@ You can configure this admission controller to set cluster-wide defaults and [ex
|
|||
<!--
|
||||
- Ensure the `PodSecurity` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) is enabled.
|
||||
-->
|
||||
- 确保 `PodSecurity` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features)已被启用。
|
||||
- 确保 `PodSecurity` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features)已被启用。
|
||||
|
||||
<!--
|
||||
## Configure the Admission Controller
|
||||
|
|
|
|||
|
|
@ -18,10 +18,10 @@ Namespaces can be labeled to enforce the [Pod Security Standards](/docs/concepts
|
|||
and [restricted](/docs/concepts/security/pod-security-standards/#restricted) broadly cover the security spectrum
|
||||
and are implemented by the [Pod Security](/docs/concepts/security/pod-security-admission/)
|
||||
-->
|
||||
[特权（privileged）](/zh/docs/concepts/security/pod-security-standards/#privileged)、
|
||||
[基线（baseline）](/zh/docs/concepts/security/pod-security-standards/#baseline)和
|
||||
[受限（restricted）](/zh/docs/concepts/security/pod-security-standards/#restricted)
|
||||
这三种策略涵盖了广泛安全范围，并由 [Pod 安全](/zh/docs/concepts/security/pod-security-admission/)
|
||||
[特权（privileged）](/zh-cn/docs/concepts/security/pod-security-standards/#privileged)、
|
||||
[基线（baseline）](/zh-cn/docs/concepts/security/pod-security-standards/#baseline)和
|
||||
[受限（restricted）](/zh-cn/docs/concepts/security/pod-security-standards/#restricted)
|
||||
这三种策略涵盖了广泛安全范围，并由 [Pod 安全](/zh-cn/docs/concepts/security/pod-security-admission/)
|
||||
{{< glossary_tooltip text="准入控制器" term_id="admission-controller" >}}实现。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
|
@ -31,7 +31,7 @@ and are implemented by the [Pod Security](/docs/concepts/security/pod-security-a
|
|||
<!--
|
||||
- Ensure the `PodSecurity` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) is enabled.
|
||||
-->
|
||||
- 确保 `PodSecurity` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features)已被启用。
|
||||
- 确保 `PodSecurity` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features)已被启用。
|
||||
|
||||
<!--
|
||||
## Requiring the `baseline` Pod Security Standard with namespace labels
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ Before you do this exercise, do the exercise in
|
|||
That will configure one of your Nodes to advertise a dongle resource.
|
||||
-->
|
||||
在你开始此练习前，请先练习
|
||||
[为节点广播扩展资源](/zh/docs/tasks/administer-cluster/extended-resource-node/)。
|
||||
[为节点广播扩展资源](/zh-cn/docs/tasks/administer-cluster/extended-resource-node/)。
|
||||
在那个练习中将配置你的一个节点来广播 dongle 资源。
|
||||
|
||||
<!-- steps -->
|
||||
|
|
@ -195,8 +195,8 @@ kubectl delete pod extended-resource-demo-2
|
|||
-->
|
||||
## 应用开发者参考
|
||||
|
||||
* [为容器和 Pod 分配内存资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)
|
||||
* [为容器和 Pod 分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
* [为容器和 Pod 分配内存资源](/zh-cn/docs/tasks/configure-pod-container/assign-memory-resource/)
|
||||
* [为容器和 Pod 分配 CPU 资源](/zh-cn/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
<!--
|
||||
### For cluster administrators
|
||||
|
|
@ -205,5 +205,5 @@ kubectl delete pod extended-resource-demo-2
|
|||
-->
|
||||
### 集群管理员参考
|
||||
|
||||
* [为节点广播扩展资源](/zh/docs/tasks/administer-cluster/extended-resource-node/)
|
||||
* [为节点广播扩展资源](/zh-cn/docs/tasks/administer-cluster/extended-resource-node/)
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ admission controller. This can be done effectively using a combination of dry-ru
|
|||
This page assumes you are already familiar with the basic [Pod Security Admission](/docs/concepts/security/pod-security-admission/)
|
||||
concepts.
|
||||
-->
|
||||
本页面假定你已经熟悉 [Pod 安全性准入](/zh/docs/concepts/security/pod-security-admission/)的基本概念。
|
||||
本页面假定你已经熟悉 [Pod 安全性准入](/zh-cn/docs/concepts/security/pod-security-admission/)的基本概念。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -104,7 +104,7 @@ Pod 安全性准入被设计用来直接满足最常见的安全性需求，并
|
|||
- **设置默认的安全性约束** - Pod 安全性准入是一个非变更性质的准入控制器，
|
||||
这就意味着它不会在对 Pod 进行合法性检查之前更改其配置。如果你之前依赖于 PSP 的这方面能力，
|
||||
你或者需要更改你的负载以满足 Pod 安全性约束，或者需要使用一个
|
||||
[变更性质的准入 Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
[变更性质的准入 Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
来执行相应的变更。进一步的细节可参见后文的[简化和标准化 PodSecurityPolicy](#simplify-psps)。
|
||||
<!--
|
||||
- **Fine-grained control over policy definition** - Pod Security Admission only supports
|
||||
|
|
@ -114,9 +114,9 @@ Pod 安全性准入被设计用来直接满足最常见的安全性需求，并
|
|||
to enforce those policies.
|
||||
-->
|
||||
- **对策略定义的细粒度控制** - Pod 安全性准入仅支持
|
||||
[三种标准级别](/zh/docs/concepts/security/pod-security-standards/)。
|
||||
[三种标准级别](/zh-cn/docs/concepts/security/pod-security-standards/)。
|
||||
如果你需要对特定的约束施加更多的控制，你就需要使用一个
|
||||
[验证性质的准入 Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
[验证性质的准入 Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
以实施这列策略。
|
||||
<!--
|
||||
- **Sub-namespace policy granularity** - PodSecurityPolicy lets you bind different policies to
|
||||
|
|
@ -131,9 +131,9 @@ Pod 安全性准入被设计用来直接满足最常见的安全性需求，并
|
|||
即使这些服务账户或用户隶属于同一个名字空间。这一方法有很多缺陷，不建议使用。
|
||||
不过如果你的确需要这种功能，你就需要使用第三方的 Webhook。
|
||||
唯一的例外是当你只需要完全针对某用户或者
|
||||
[RuntimeClasses](/zh/docs/concepts/containers/runtime-class/) 赋予豁免规则时，
|
||||
[RuntimeClasses](/zh-cn/docs/concepts/containers/runtime-class/) 赋予豁免规则时，
|
||||
Pod 安全性准入的确也为豁免规则暴露一些
|
||||
[静态配置](/zh/docs/concepts/security/pod-security-admission/#exemptions)。
|
||||
[静态配置](/zh-cn/docs/concepts/security/pod-security-admission/#exemptions)。
|
||||
|
||||
<!--
|
||||
Even if Pod Security Admission does not meet all of your needs it was designed to be _complementary_
|
||||
|
|
@ -159,13 +159,13 @@ but if you must you will need to use an
|
|||
[admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
to place additional restrictions on setting Pod Security labels on Namespace objects.
|
||||
-->
|
||||
Pod 安全性准入是通过[名字空间上的标签](/zh/docs/concepts/security/pod-security-admission/#pod-security-admission-labels-for-namespaces)
|
||||
Pod 安全性准入是通过[名字空间上的标签](/zh-cn/docs/concepts/security/pod-security-admission/#pod-security-admission-labels-for-namespaces)
|
||||
来控制的。这也就是说，任何能够更新（或通过 patch 部分更新或创建）
|
||||
名字空间的人都可以更改该名字空间的 Pod 安全性级别，而这可能会被利用来绕过约束性更强的策略。
|
||||
在继续执行迁移操作之前，请确保只有被信任的、有特权的用户具有这类名字空间访问权限。
|
||||
不建议将这类强大的访问权限授予不应获得权限提升的用户，不过如果你必须这样做，
|
||||
你需要使用一个
|
||||
[准入 Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
[准入 Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
来针对为 Namespace 对象设置 Pod 安全性级别设置额外的约束。
|
||||
|
||||
<!--
|
||||
|
|
@ -211,7 +211,7 @@ validating policy. These fields (also listed in the
|
|||
reference) are:
|
||||
-->
|
||||
你可以先去掉那些纯粹变更性质的字段，留下验证策略中的其他内容。
|
||||
这些字段（也列举于[将 PodSecurityPolicy 映射到 Pod 安全性标准](/zh/docs/reference/access-authn-authz/psp-to-pod-security-standards/)参考中）
|
||||
这些字段（也列举于[将 PodSecurityPolicy 映射到 Pod 安全性标准](/zh-cn/docs/reference/access-authn-authz/psp-to-pod-security-standards/)参考中）
|
||||
包括：
|
||||
|
||||
<!--
|
||||
|
|
@ -253,7 +253,7 @@ which is outside the scope of this guide.
|
|||
-->
|
||||
PodSecurityPolicy 中有一些字段未被 Pod 安全性准入机制覆盖。如果你必须使用这些选项，
|
||||
你需要在 Pod 安全性准入之外部署
|
||||
[准入 Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
[准入 Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
以补充这一能力，而这类操作不在本指南范围。
|
||||
|
||||
<!--
|
||||
|
|
@ -263,7 +263,7 @@ These fields (also listed in the
|
|||
reference with "no opinion") are:
|
||||
-->
|
||||
首先，你可以去掉 Pod 安全性标准所未覆盖的那些验证性字段。这些字段（也列举于
|
||||
[将 PodSecurityPolicy 映射到 Pod 安全性标准](/zh/docs/reference/access-authn-authz/psp-to-pod-security-standards/)参考中，标记为“无意见”）有：
|
||||
[将 PodSecurityPolicy 映射到 Pod 安全性标准](/zh-cn/docs/reference/access-authn-authz/psp-to-pod-security-standards/)参考中，标记为“无意见”）有：
|
||||
|
||||
- `.spec.allowedHostPaths`
|
||||
- `.spec.allowedFlexVolumes`
|
||||
|
|
@ -355,7 +355,7 @@ For each updated PodSecurityPolicy:
|
|||
The fields to review are:
|
||||
-->
|
||||
2. 比较运行中的 Pod 与原来的 Pod 规约，确定 PodSecurityPolicy 是否更改过这些 Pod。
|
||||
对于通过[工作负载资源](/zh/docs/concepts/workloads/controllers/)所创建的 Pod，
|
||||
对于通过[工作负载资源](/zh-cn/docs/concepts/workloads/controllers/)所创建的 Pod，
|
||||
你可以比较 Pod 和控制器资源中的 PodTemplate。如果发现任何变更，则原来的 Pod
|
||||
或者 PodTemplate 需要被更新以加上所希望的配置。要审查的字段包括：
|
||||
|
||||
|
|
@ -425,7 +425,7 @@ familiarizing yourself with the 3 different levels.
|
|||
|
||||
There are several ways to choose a Pod Security level for your namespace:
|
||||
-->
|
||||
首先请回顾 [Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards/)内容，
|
||||
首先请回顾 [Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards/)内容，
|
||||
并了解三个安全级别。
|
||||
|
||||
为你的名字空间选择 Pod 安全性级别有几种方法：
|
||||
|
|
@ -447,7 +447,7 @@ There are several ways to choose a Pod Security level for your namespace:
|
|||
namespace with this command:
|
||||
-->
|
||||
2. **根据现有的 PodSecurityPolicy 来确定** - 基于
|
||||
[将 PodSecurityPolicy 映射到 Pod 安全性标准](/zh/docs/reference/access-authn-authz/psp-to-pod-security-standards/)
|
||||
[将 PodSecurityPolicy 映射到 Pod 安全性标准](/zh-cn/docs/reference/access-authn-authz/psp-to-pod-security-standards/)
|
||||
参考资料，你可以将各个 PSP 映射到某个 Pod 安全性标准级别。如果你的 PSP 不是基于
|
||||
Pod 安全性标准的，你可能或者需要选择一个至少与该 PSP 一样宽松的级别，
|
||||
或者选择一个至少与其一样严格的级别。使用下面的命令你可以查看被 Pod 使用的 PSP 有哪些：
|
||||
|
|
@ -613,7 +613,7 @@ for more information.
|
|||
-->
|
||||
你也可以静态配置 Pod 安全性准入控制器，为尚未打标签的名字空间设置默认的
|
||||
enforce、audit 与/或 warn 级别。详细信息可参阅
|
||||
[配置准入控制器](/zh/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller)
|
||||
[配置准入控制器](/zh-cn/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller)
|
||||
页面。
|
||||
|
||||
<!--
|
||||
|
|
@ -628,7 +628,7 @@ configuration of the API server:
|
|||
-->
|
||||
最后，你已为禁用 PodSecurityPolicy 做好准备。要禁用 PodSecurityPolicy，
|
||||
你需要更改 API 服务器上的准入配置：
|
||||
[我如何关闭某个准入控制器？](/zh/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-off-an-admission-controller)
|
||||
[我如何关闭某个准入控制器？](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-off-an-admission-controller)
|
||||
|
||||
<!--
|
||||
To verify that the PodSecurityPolicy admission controller is no longer enabled, you can manually run
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ View the `config.json` file:
|
|||
或 Docker ID 的密码）。
|
||||
|
||||
登录过程会创建或更新保存有授权令牌的 `config.json` 文件。
|
||||
查看 [Kubernetes 中如何解析这个文件](/zh/docs/concepts/containers/images#config-json)。
|
||||
查看 [Kubernetes 中如何解析这个文件](/zh-cn/docs/concepts/containers/images#config-json)。
|
||||
|
||||
查看 `config.json` 文件：
|
||||
|
||||
|
|
@ -348,9 +348,9 @@ kubectl get pod private-reg
|
|||
* See the `imagePullSecrets` field within the [container definitions](/docs/reference/kubernetes-api/workload-resources/pod-v1/#containers) of a Pod
|
||||
-->
|
||||
|
||||
* 进一步了解 [Secrets](/zh/docs/concepts/configuration/secret/)
|
||||
* 进一步了解 [Secrets](/zh-cn/docs/concepts/configuration/secret/)
|
||||
* 或阅读 {{< api-reference page="config-and-storage-resources/secret-v1" >}} 的 API 参考
|
||||
* 进一步了解 [使用私有仓库](/zh/docs/concepts/containers/images/#using-a-private-registry)
|
||||
* 进一步了解 [为服务账户添加拉取镜像凭证](/zh/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)
|
||||
* 进一步了解 [使用私有仓库](/zh-cn/docs/concepts/containers/images/#using-a-private-registry)
|
||||
* 进一步了解 [为服务账户添加拉取镜像凭证](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)
|
||||
* 查看 [kubectl 创建 docker-registry 凭证](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-)
|
||||
* 查看 Pod [容器定义](/docs/reference/kubernetes-api/workload-resources/pod-v1/#containers)中的 `imagePullSecrets` 字段。
|
||||
|
|
|
|||
|
|
@ -378,9 +378,9 @@ kubectl delete namespace qos-example
|
|||
-->
|
||||
### 应用开发者参考
|
||||
|
||||
* [为 Pod 和容器分配内存资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)
|
||||
* [为 Pod 和容器分配内存资源](/zh-cn/docs/tasks/configure-pod-container/assign-memory-resource/)
|
||||
|
||||
* [为 Pod 和容器分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
* [为 Pod 和容器分配 CPU 资源](/zh-cn/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
<!--
|
||||
### For cluster administrators
|
||||
|
|
@ -404,20 +404,20 @@ kubectl delete namespace qos-example
|
|||
|
||||
### 集群管理员参考
|
||||
|
||||
* [为命名空间配置默认的内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
|
||||
* [为命名空间配置默认的 CPU 请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace)
|
||||
* [为命名空间配置默认的内存请求和限制](/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
|
||||
* [为命名空间配置默认的 CPU 请求和限制](/zh-cn/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace)
|
||||
|
||||
* [为命名空间配置最小和最大内存限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
|
||||
* [为命名空间配置最小和最大内存限制](/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
|
||||
|
||||
* [为命名空间配置最小和最大 CPU 限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
|
||||
* [为命名空间配置最小和最大 CPU 限制](/zh-cn/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
|
||||
|
||||
* [为命名空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
|
||||
* [为命名空间配置内存和 CPU 配额](/zh-cn/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
|
||||
|
||||
* [为命名空间配置 Pod 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
|
||||
* [为命名空间配置 Pod 配额](/zh-cn/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
|
||||
|
||||
* [为 API 对象配置配额](/zh/docs/tasks/administer-cluster/quota-api-object/)
|
||||
* [为 API 对象配置配额](/zh-cn/docs/tasks/administer-cluster/quota-api-object/)
|
||||
|
||||
* [控制节点上的拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)
|
||||
* [控制节点上的拓扑管理策略](/zh-cn/docs/tasks/administer-cluster/topology-manager/)
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -54,8 +54,8 @@ a Pod or Container. Security context settings include, but are not limited to:
|
|||
|
||||
* readOnlyRootFilesystem: Mounts the container's root filesystem as read-only.
|
||||
-->
|
||||
* [AppArmor](/zh/docs/tutorials/security/apparmor/)：使用程序配置来限制个别程序的权能。
|
||||
* [Seccomp](/zh/docs/tutorials/security/seccomp/)：过滤进程的系统调用。
|
||||
* [AppArmor](/zh-cn/docs/tutorials/security/apparmor/)：使用程序配置来限制个别程序的权能。
|
||||
* [Seccomp](/zh-cn/docs/tutorials/security/seccomp/)：过滤进程的系统调用。
|
||||
* `allowPrivilegeEscalation`：控制进程是否可以获得超出其父进程的特权。
|
||||
此布尔值直接控制是否为容器进程设置
|
||||
[`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt)标志。
|
||||
|
|
@ -306,9 +306,9 @@ This field has no effect on ephemeral volume types such as
|
|||
and [`emptydir`](/docs/concepts/storage/volumes/#emptydir).
|
||||
-->
|
||||
{{< note >}}
|
||||
此字段对于 [`secret`](/zh/docs/concepts/storage/volumes/#secret)、
|
||||
[`configMap`](/zh/docs/concepts/storage/volumes/#configmap)
|
||||
和 [`emptydir`](/zh/docs/concepts/storage/volumes/#emptydir)
|
||||
此字段对于 [`secret`](/zh-cn/docs/concepts/storage/volumes/#secret)、
|
||||
[`configMap`](/zh-cn/docs/concepts/storage/volumes/#configmap)
|
||||
和 [`emptydir`](/zh-cn/docs/concepts/storage/volumes/#emptydir)
|
||||
这类临时性存储无效。
|
||||
{{< /note >}}
|
||||
|
||||
|
|
@ -784,7 +784,7 @@ kubectl delete pod security-context-demo-4
|
|||
* [使用最新的安全性增强来调优 Docker（英文）](https://github.com/containerd/containerd/blob/main/docs/cri/config.md)
|
||||
* [安全上下文的设计文档（英文）](https://github.com/kubernetes/design-proposals-archive/blob/main/auth/security_context.md)
|
||||
* [属主管理的设计文档（英文）](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/volume-ownership-management.md)
|
||||
* [Pod 安全策略](/zh/docs/concepts/security/pod-security-policy/)
|
||||
* [Pod 安全策略](/zh-cn/docs/concepts/security/pod-security-policy/)
|
||||
* [AllowPrivilegeEscalation 的设计文档（英文）](https://github.com/kubernetes/design-proposals-archive/blob/main/auth/no-new-privs.md)
|
||||
* 关于在 Linux 系统中的安全机制的更多信息，可参阅
|
||||
[Linux 内核安全性能力概述](https://www.linux.com/learn/overview-linux-kernel-security-features)。
|
||||
|
|
|
|||
|
|
@ -84,8 +84,8 @@ You can configure a static Pod with either a [file system hosted configuration f
|
|||
-->
|
||||
## 创建静态 Pod {#static-pod-creation}
|
||||
|
||||
可以通过[文件系统上的配置文件](/zh/docs/tasks/configure-pod-container/static-pod/#configuration-files)
|
||||
或者 [web 网络上的配置文件](/zh/docs/tasks/configure-pod-container/static-pod/#pods-created-via-http)
|
||||
可以通过[文件系统上的配置文件](/zh-cn/docs/tasks/configure-pod-container/static-pod/#configuration-files)
|
||||
或者 [web 网络上的配置文件](/zh-cn/docs/tasks/configure-pod-container/static-pod/#pods-created-via-http)
|
||||
来配置静态 Pod。
|
||||
|
||||
<!--
|
||||
|
|
@ -101,7 +101,7 @@ For example, this is how to start a simple web server as a static Pod:
|
|||
### 文件系统上的静态 Pod 声明文件 {#configuration-files}
|
||||
|
||||
声明文件是标准的 Pod 定义文件，以 JSON 或者 YAML 格式存储在指定目录。路径设置在
|
||||
[Kubelet 配置文件](/zh/docs/reference/config-api/kubelet-config.v1beta1/)
|
||||
[Kubelet 配置文件](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/)
|
||||
的 `staticPodPath: <目录>` 字段，kubelet 会定期的扫描这个文件夹下的 YAML/JSON
|
||||
文件来创建/删除静态 Pod。
|
||||
注意 kubelet 扫描目录的时候会忽略以点开头的文件。
|
||||
|
|
@ -179,7 +179,7 @@ For example, this is how to start a simple web server as a static Pod:
|
|||
```
|
||||
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
|
||||
```
|
||||
或者在 [Kubelet 配置文件](/zh/docs/reference/config-api/kubelet-config.v1beta1/)
|
||||
或者在 [Kubelet 配置文件](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/)
|
||||
中添加 `staticPodPath: <目录>`字段。
|
||||
|
||||
<!--
|
||||
|
|
@ -329,7 +329,7 @@ Make sure the kubelet has permission to create the mirror Pod in the API server.
|
|||
-->
|
||||
{{< note >}}
|
||||
要确保 kubelet 在 API 服务上有创建镜像 Pod 的权限。如果没有，创建请求会被 API 服务拒绝。
|
||||
可以看 [Pod 安全性准入](/zh/docs/concepts/security/pod-security-admission/)和 [Pod 安全策略](/zh/docs/concepts/security/pod-security-policy/)。
|
||||
可以看 [Pod 安全性准入](/zh-cn/docs/concepts/security/pod-security-admission/)和 [Pod 安全策略](/zh-cn/docs/concepts/security/pod-security-policy/)。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -449,11 +449,11 @@ The default `kompose` transformation will generate Kubernetes [Deployments](/doc
|
|||
## 其他转换方式 {#alternative-conversions}
|
||||
|
||||
默认的 `kompose` 转换会生成 yaml 格式的 Kubernetes
|
||||
[Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 和
|
||||
[Service](/zh/docs/concepts/services-networking/service/) 对象。
|
||||
[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/) 和
|
||||
[Service](/zh-cn/docs/concepts/services-networking/service/) 对象。
|
||||
你可以选择通过 `-j` 参数生成 json 格式的对象。
|
||||
你也可以替换生成 [Replication Controllers](/zh/docs/concepts/workloads/controllers/replicationcontroller/) 对象、
|
||||
[Daemon Sets](/zh/docs/concepts/workloads/controllers/daemonset/) 或
|
||||
你也可以替换生成 [Replication Controllers](/zh-cn/docs/concepts/workloads/controllers/replicationcontroller/) 对象、
|
||||
[Daemon Sets](/zh-cn/docs/concepts/workloads/controllers/daemonset/) 或
|
||||
[Helm](https://github.com/helm/helm) charts。
|
||||
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -30,9 +30,9 @@ two sections:
|
|||
* [Debugging your cluster](/docs/tasks/debug/debug-cluster/) - Useful
|
||||
for cluster administrators and people whose Kubernetes cluster is unhappy.
|
||||
-->
|
||||
* [应用排错](/zh/docs/tasks/debug/debug-application/) -
|
||||
* [应用排错](/zh-cn/docs/tasks/debug/debug-application/) -
|
||||
针对部署代码到 Kubernetes 并想知道代码为什么不能正常运行的用户。
|
||||
* [集群排错](/zh/docs/tasks/debug/debug-cluster/) -
|
||||
* [集群排错](/zh-cn/docs/tasks/debug/debug-cluster/) -
|
||||
针对集群管理员以及 Kubernetes 集群表现异常的用户。
|
||||
|
||||
<!--
|
||||
|
|
@ -69,13 +69,13 @@ and command-line interfaces (CLIs), such as [`kubectl`](/docs/reference/kubectl/
|
|||
### 问题 {#questions}
|
||||
|
||||
本网站上的文档针对回答各类问题进行了结构化组织和分类。
|
||||
[概念](/zh/docs/concepts/)部分解释 Kubernetes 体系结构以及每个组件的工作方式，
|
||||
[安装](/zh/docs/setup/)部分提供了安装的实用说明。
|
||||
[任务](/zh/docs/tasks/)部分展示了如何完成常用任务，
|
||||
[教程](/zh/docs/tutorials/)部分则提供对现实世界、特定行业或端到端开发场景的更全面的演练。
|
||||
[参考](/zh/docs/reference/)部分提供了详细的
|
||||
[概念](/zh-cn/docs/concepts/)部分解释 Kubernetes 体系结构以及每个组件的工作方式，
|
||||
[安装](/zh-cn/docs/setup/)部分提供了安装的实用说明。
|
||||
[任务](/zh-cn/docs/tasks/)部分展示了如何完成常用任务，
|
||||
[教程](/zh-cn/docs/tutorials/)部分则提供对现实世界、特定行业或端到端开发场景的更全面的演练。
|
||||
[参考](/zh-cn/docs/reference/)部分提供了详细的
|
||||
[Kubernetes API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 文档
|
||||
和命令行 (CLI) 接口的文档，例如[`kubectl`](/zh/docs/reference/kubectl/)。
|
||||
和命令行 (CLI) 接口的文档，例如[`kubectl`](/zh-cn/docs/reference/kubectl/)。
|
||||
|
||||
<!--
|
||||
## Help! My question isn't covered! I need help now!
|
||||
|
|
|
|||
|
|
@ -40,8 +40,8 @@ Init Containers. The example command lines below refer to the Pod as
|
|||
* You should have [Configured an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/).
|
||||
-->
|
||||
|
||||
* 你应该熟悉 [Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)的基础知识。
|
||||
* 你应该已经[配置好一个 Init 容器](/zh/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/)。
|
||||
* 你应该熟悉 [Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/)的基础知识。
|
||||
* 你应该已经[配置好一个 Init 容器](/zh-cn/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/)。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ This is *not* a guide for people who want to debug their cluster. For that you
|
|||
|
||||
本指南帮助用户调试那些部署到 Kubernetes 上后没有正常运行的应用。
|
||||
本指南 **并非** 指导用户如何调试集群。
|
||||
如果想调试集群的话，请参阅[这里](/zh/docs/tasks/debug/debug-cluster)。
|
||||
如果想调试集群的话，请参阅[这里](/zh-cn/docs/tasks/debug/debug-cluster)。
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
|
@ -94,7 +94,7 @@ scheduled. In most cases, `hostPort` is unnecessary, try using a Service object
|
|||
-->
|
||||
* **资源不足**:
|
||||
你可能耗尽了集群上所有的 CPU 或内存。此时，你需要删除 Pod、调整资源请求或者为集群添加节点。
|
||||
更多信息请参阅[计算资源文档](/zh/docs/concepts/configuration/manage-resources-containers/)
|
||||
更多信息请参阅[计算资源文档](/zh-cn/docs/concepts/configuration/manage-resources-containers/)
|
||||
|
||||
* **使用了 `hostPort`**:
|
||||
如果绑定 Pod 到 `hostPort`，那么能够运行该 Pod 的节点就有限了。
|
||||
|
|
@ -132,7 +132,7 @@ Once your pod has been scheduled, the methods described in [Debug Running Pods](
|
|||
#### Pod 处于 Crashing 或别的不健康状态
|
||||
|
||||
一旦 Pod 被调度，就可以采用
|
||||
[调试运行中的 Pod](/zh/docs/tasks/debug/debug-application/debug-running-pod/)
|
||||
[调试运行中的 Pod](/zh-cn/docs/tasks/debug/debug-application/debug-running-pod/)
|
||||
中的方法来进一步调试。
|
||||
|
||||
<!--
|
||||
|
|
@ -284,7 +284,7 @@ Please see [debugging service](/docs/tasks/debug/debug-applications/debug-servic
|
|||
-->
|
||||
#### 网络流量未被转发
|
||||
|
||||
请参阅[调试 Service](/zh/docs/tasks/debug/debug-applications/debug-service/) 了解更多信息。
|
||||
请参阅[调试 Service](/zh-cn/docs/tasks/debug/debug-applications/debug-service/) 了解更多信息。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
|
@ -298,8 +298,8 @@ does not seem to be misbehaving.
|
|||
You may also visit [troubleshooting document](/docs/tasks/debug/) for more information.
|
||||
-->
|
||||
如果上述方法都不能解决你的问题，
|
||||
请按照[调试 Service 文档](/zh/docs/tasks/debug/debug-applications/debug-service/)中的介绍，
|
||||
请按照[调试 Service 文档](/zh-cn/docs/tasks/debug/debug-applications/debug-service/)中的介绍，
|
||||
确保你的 `Service` 处于 Running 态，有 `Endpoints` 被创建，`Pod` 真的在提供服务；
|
||||
DNS 服务已配置并正常工作，iptables 规则也以安装并且 `kube-proxy` 也没有异常行为。
|
||||
|
||||
你也可以访问[故障排查文档](/zh/docs/tasks/debug/)来获取更多信息。
|
||||
你也可以访问[故障排查文档](/zh-cn/docs/tasks/debug/)来获取更多信息。
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ This page explains how to debug Pods running (or crashing) on a Node.
|
|||
need that access to run the standard debug steps that use `kubectl`.
|
||||
-->
|
||||
* 你的 {{< glossary_tooltip text="Pod" term_id="pod" >}} 应该已经被调度并正在运行中，
|
||||
如果你的 Pod 还没有运行，请参阅[调试 Pod](/zh/docs/tasks/debug/debug-application/)。
|
||||
如果你的 Pod 还没有运行，请参阅[调试 Pod](/zh-cn/docs/tasks/debug/debug-application/)。
|
||||
|
||||
* 对于一些高级调试步骤，你应该知道 Pod 具体运行在哪个节点上，并具有在该节点上运行命令的 shell 访问权限。
|
||||
你不需要任何访问权限就可以使用 `kubectl` 去运行一些标准调试步骤。
|
||||
|
|
@ -513,7 +513,7 @@ kubectl exec cassandra -- cat /var/log/cassandra/system.log
|
|||
kubectl exec -it cassandra -- sh
|
||||
```
|
||||
|
||||
若要了解更多内容，可查看[获取正在运行容器的 Shell](/zh/docs/tasks/debug/debug-application/get-shell-running-container/)。
|
||||
若要了解更多内容，可查看[获取正在运行容器的 Shell](/zh-cn/docs/tasks/debug/debug-application/get-shell-running-container/)。
|
||||
|
||||
<!--
|
||||
## Debugging with an ephemeral debug container {#ephemeral-container}
|
||||
|
|
@ -612,7 +612,7 @@ You can view the state of the newly created ephemeral container using `kubectl d
|
|||
-->
|
||||
此命令添加一个新的 busybox 容器并将其挂接到该容器。`--target` 参数指定另一个容器的进程命名空间。
|
||||
这是必需的，因为 `kubectl run` 不能在它创建的pod中启用
|
||||
[共享进程命名空间](/zh/docs/tasks/configure-pod-container/share-process-namespace/)。
|
||||
[共享进程命名空间](/zh-cn/docs/tasks/configure-pod-container/share-process-namespace/)。
|
||||
|
||||
{{< note >}}
|
||||
{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}必须支持 `--target` 参数。
|
||||
|
|
@ -728,7 +728,7 @@ root@myapp-debug:/#
|
|||
你可以通过指定 `--attach=false` 来防止这种情况。
|
||||
如果你的会话断开连接，你可以使用 `kubectl attach` 重新连接。
|
||||
* `--share-processes` 允许在此 Pod 中的其他容器中查看该容器的进程。
|
||||
参阅[在 Pod 中的容器之间共享进程命名空间](/zh/docs/tasks/configure-pod-container/share-process-namespace/)
|
||||
参阅[在 Pod 中的容器之间共享进程命名空间](/zh-cn/docs/tasks/configure-pod-container/share-process-namespace/)
|
||||
获取更多信息。
|
||||
{{< /note >}}
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue