[zh] sync admission-controllers.md
Michael
parent
2bad323592
commit
1de3ced68c
|
|
@ -4,7 +4,6 @@ linkTitle: 准入控制器
|
|||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!--
|
||||
reviewers:
|
||||
- lavalamp
|
||||
|
|
@ -342,7 +341,8 @@ This admission controller ignores any `PersistentVolumeClaim` updates; it acts o
|
|||
See [persistent volume](/docs/concepts/storage/persistent-volumes/) documentation about persistent volume claims and
|
||||
storage classes and how to mark a storage class as default.
|
||||
-->
|
||||
关于持久卷申领和存储类，以及如何将存储类标记为默认，请参见[持久卷](/zh-cn/docs/concepts/storage/persistent-volumes/)页面。
|
||||
关于持久卷申领和存储类，以及如何将存储类标记为默认，
|
||||
请参见[持久卷](/zh-cn/docs/concepts/storage/persistent-volumes/)页面。
|
||||
|
||||
### DefaultTolerationSeconds {#defaulttolerationseconds}
|
||||
|
||||
|
|
@ -505,6 +505,20 @@ This file may be json or yaml and has the following format:
|
|||
ImagePolicyWebhook 使用配置文件来为后端行为设置选项。该文件可以是 JSON 或 YAML，
|
||||
并具有以下格式:
|
||||
|
||||
<!--
|
||||
```yaml
|
||||
imagePolicy:
|
||||
kubeConfigFile: /path/to/kubeconfig/for/backend
|
||||
# time in s to cache approval
|
||||
allowTTL: 50
|
||||
# time in s to cache denial
|
||||
denyTTL: 50
|
||||
# time in ms to wait between retries
|
||||
retryBackoff: 500
|
||||
# determines behavior if the webhook backend fails
|
||||
defaultAllow: true
|
||||
```
|
||||
-->
|
||||
```yaml
|
||||
imagePolicy:
|
||||
kubeConfigFile: /path/to/kubeconfig/for/backend
|
||||
|
|
@ -635,15 +649,14 @@ group (`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`).
|
|||
-->
|
||||
注意，Webhook API 对象与其他 Kubernetes API 对象一样受制于相同的版本控制兼容性规则。
|
||||
实现者应该知道对 alpha 对象兼容性是相对宽松的，并检查请求的 "apiVersion" 字段，
|
||||
以确保正确的反序列化。
|
||||
此外，API 服务器必须启用 `imagepolicy.k8s.io/v1alpha1` API 扩展组
|
||||
以确保正确的反序列化。此外，API 服务器必须启用 `imagepolicy.k8s.io/v1alpha1` API 扩展组
|
||||
（`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`）。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
An example request body:
|
||||
-->
|
||||
请求载荷示例：
|
||||
请求体示例：
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -808,7 +821,7 @@ group/version via the `--runtime-config` flag, both are on by default.
|
|||
<!--
|
||||
#### Use caution when authoring and installing mutating webhooks
|
||||
-->
|
||||
#### 谨慎编写和安装变更 webhook {#use-caution-when-authoring-and-installing-mutating-webhooks}
|
||||
#### 谨慎编写和安装变更 Webhook {#use-caution-when-authoring-and-installing-mutating-webhooks}
|
||||
|
||||
<!--
|
||||
* Users may be confused when the objects they try to create are different from
|
||||
|
|
@ -860,8 +873,7 @@ This admission controller also prevents deletion of three system reserved namesp
|
|||
`kube-system`, `kube-public`.
|
||||
-->
|
||||
该准入控制器禁止在一个正在被终止的 `Namespace` 中创建新对象，并确保针对不存在的
|
||||
`Namespace` 的请求被拒绝。
|
||||
该准入控制器还会禁止删除三个系统保留的名字空间，即 `default`、
|
||||
`Namespace` 的请求被拒绝。该准入控制器还会禁止删除三个系统保留的名字空间，即 `default`、
|
||||
`kube-system` 和 `kube-public`。
|
||||
|
||||
<!--
|
||||
|
|
@ -1006,8 +1018,7 @@ This admission controller is disabled by default.
|
|||
此准入控制器会自动将由云提供商（如 Azure 或 GCP）定义的区（region）或区域（zone）
|
||||
标签附加到 PersistentVolume 上。这有助于确保 Pod 和 PersistentVolume 位于相同的区或区域。
|
||||
如果准入控制器不支持为 PersistentVolumes 自动添加标签，那你可能需要手动添加标签，
|
||||
以防止 Pod 挂载其他区域的卷。
|
||||
PersistentVolumeLabel **已被弃用**，
|
||||
以防止 Pod 挂载其他区域的卷。PersistentVolumeLabel **已被弃用**，
|
||||
为持久卷添加标签的操作已由{{< glossary_tooltip text="云管理控制器" term_id="cloud-controller-manager" >}}接管。
|
||||
|
||||
此准入控制器默认被禁用。
|
||||
|
|
@ -1129,7 +1140,7 @@ admitted, determines if it should be admitted based on the requested security co
|
|||
for the namespace that the Pod would be in.
|
||||
-->
|
||||
PodSecurity 准入控制器在新 Pod 被准入之前对其进行检查，
|
||||
根据请求的安全上下文和 Pod 所在命名空间允许的
|
||||
根据请求的安全上下文和 Pod 所在名字空间允许的
|
||||
[Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards/)的限制来确定新 Pod
|
||||
是否应该被准入。
|
||||
|
||||
|
|
@ -1253,21 +1264,34 @@ for more information.
|
|||
|
||||
### SecurityContextDeny {#securitycontextdeny}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.0" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.27" state="deprecated" >}}
|
||||
|
||||
{{< caution >}}
|
||||
<!--
|
||||
This admission controller plugin is **outdated** and **incomplete**, it may be
|
||||
unusable or not do what you would expect. It was originally designed to prevent
|
||||
the use of some, but not all, security-sensitive fields. Indeed, fields like
|
||||
`privileged`, were not filtered at creation and the plugin was not updated with
|
||||
the most recent fields, and new APIs like the `ephemeralContainers` field for a
|
||||
Pod.
|
||||
The Kubernetes project recommends that you **do not use** the
|
||||
`SecurityContextDeny` admission controller.
|
||||
|
||||
The `SecurityContextDeny` admission controller plugin is deprecated and disabled
|
||||
by default. It will be removed in a future version. If you choose to enable the
|
||||
`SecurityContextDeny` admission controller plugin, you must enable the
|
||||
`SecurityContextDeny` feature gate as well.
|
||||
-->
|
||||
这个准入控制器插件是**过时的**且**不完整的**，它可能无法使用或无法达到你的预期。
|
||||
它最初旨在防止使用某些（但不是全部）安全敏感字段。
|
||||
事实上，像 `privileged` 这样的字段在创建时并没有被过滤，
|
||||
而且该插件没有根据最新的字段和新的 API（例如 Pod 的 `ephemeralContainers` 字段）来更新。
|
||||
Kubernetes 项目建议你**不要使用** `SecurityContextDeny` 准入控制器。
|
||||
|
||||
`SecurityContextDeny` 准入控制器插件已被弃用，并且默认处于禁用状态。
|
||||
此插件将在后续的版本中被移除。如果你选择启用 `SecurityContextDeny` 准入控制器插件，
|
||||
也必须同时启用 `SecurityContextDeny` 特性门控。
|
||||
|
||||
<!--
|
||||
The `SecurityContextDeny` admission plugin is deprecated because it is outdated
|
||||
and incomplete; it may be unusable or not do what you would expect. As
|
||||
implemented, this plugin is unable to restrict all security-sensitive attributes
|
||||
of the Pod API. For example, the `privileged` and `ephemeralContainers` fields
|
||||
were never restricted by this plugin.
|
||||
-->
|
||||
`SecurityContextDeny` 准入插件已被弃用，因为它已经过时且不完整；
|
||||
它可能无法使用或无法达到你的预期。该插件实现之时，就无法限制 Pod API 的所有与安全相关的属性。
|
||||
例如，`privileged` 和 `ephemeralContainers` 字段就从未受过此插件的限制。
|
||||
|
||||
<!--
|
||||
The [Pod Security Admission](/docs/concepts/security/pod-security-admission/)
|
||||
|
|
@ -1333,8 +1357,8 @@ Refer to the
|
|||
for more detailed information.
|
||||
-->
|
||||
`StorageObjectInUseProtection` 插件将 `kubernetes.io/pvc-protection` 或
|
||||
`kubernetes.io/pv-protection` finalizers 添加到新创建的持久卷申领（PVC）
|
||||
或持久卷（PV）中。如果用户尝试删除 PVC/PV，除非 PVC/PV 的保护控制器移除终结器（finalizers），
|
||||
`kubernetes.io/pv-protection` 终结器（finalizers）添加到新创建的持久卷申领（PVC）
|
||||
或持久卷（PV）中。如果用户尝试删除 PVC/PV，除非 PVC/PV 的保护控制器移除终结器，
|
||||
否则 PVC/PV 不会被删除。有关更多详细信息，
|
||||
请参考[保护使用中的存储对象](/zh-cn/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection)。
|
||||
|
||||
|
|
@ -1406,4 +1430,3 @@ You can enable additional admission controllers beyond the default set using the
|
|||
（请查看[这里](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/#options)）。
|
||||
因此，你无需显式指定它们。
|
||||
你可以使用 `--enable-admission-plugins` 标志（ **顺序不重要** ）来启用默认设置以外的其他准入控制器。
|
||||
|
||||
|
|
|
|||
|
|
@ -13,17 +13,17 @@ weight: 140
|
|||
<!--
|
||||
This page shows how to configure liveness, readiness and startup probes for containers.
|
||||
|
||||
The [kubelet](/docs/reference/command-line-tools-reference/kubelet/) uses liveness probes to know when to
|
||||
restart a container. For example, liveness probes could catch a deadlock,
|
||||
where an application is running, but unable to make progress. Restarting a
|
||||
container in such a state can help to make the application more available
|
||||
despite bugs.
|
||||
The [kubelet](/docs/reference/command-line-tools-reference/kubelet/) uses
|
||||
liveness probes to know when to restart a container. For example, liveness
|
||||
probes could catch a deadlock, where an application is running, but unable to
|
||||
make progress. Restarting a container in such a state can help to make the
|
||||
application more available despite bugs.
|
||||
-->
|
||||
这篇文章介绍如何给容器配置存活（Liveness）、就绪（Readiness）和启动（Startup）探针。
|
||||
|
||||
[kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/)
|
||||
使用存活探针来确定什么时候要重启容器。
|
||||
例如，存活探针可以探测到应用死锁（应用程序在运行，但是无法继续执行后面的步骤）情况。
|
||||
例如，存活探针可以探测到应用死锁（应用在运行，但是无法继续执行后面的步骤）情况。
|
||||
重启这种状态下的容器有助于提高应用的可用性，即使其中存在缺陷。
|
||||
|
||||
<!--
|
||||
|
|
@ -41,7 +41,7 @@ One use of this signal is to control which Pods are used as backends for Service
|
|||
When a Pod is not ready, it is removed from Service load balancers.
|
||||
|
||||
The kubelet uses startup probes to know when a container application has started.
|
||||
If such a probe is configured, it disables liveness and readiness checks until
|
||||
If such a probe is configured, liveness and readiness probes do not start until
|
||||
it succeeds, making sure those probes don't interfere with the application startup.
|
||||
This can be used to adopt liveness checks on slow starting containers, avoiding them
|
||||
getting killed by the kubelet before they are up and running.
|
||||
|
|
@ -52,8 +52,7 @@ kubelet 使用就绪探针可以知道容器何时准备好接受请求流量，
|
|||
若 Pod 尚未就绪，会被从 Service 的负载均衡器中剔除。
|
||||
|
||||
kubelet 使用启动探针来了解应用容器何时启动。
|
||||
如果配置了这类探针，你就可以控制容器在启动成功后再进行存活性和就绪态检查，
|
||||
确保这些存活、就绪探针不会影响应用的启动。
|
||||
如果配置了这类探针，存活探针和就绪探针成功之前不会重启，确保这些探针不会影响应用的启动。
|
||||
启动探针可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。
|
||||
|
||||
{{< caution >}}
|
||||
|
|
@ -74,9 +73,9 @@ scalable; and increased workload on remaining pods due to some failed pods.
|
|||
Understand the difference between readiness and liveness probes and when to apply them for your app.
|
||||
-->
|
||||
错误的存活探针可能会导致级联故障。
|
||||
这会导致在高负载下容器重启；例如由于应用程序无法扩展，导致客户端请求失败；以及由于某些
|
||||
这会导致在高负载下容器重启；例如由于应用无法扩展，导致客户端请求失败；以及由于某些
|
||||
Pod 失败而导致剩余 Pod 的工作负载增加。了解就绪探针和存活探针之间的区别，
|
||||
以及何时为应用程序配置使用它们非常重要。
|
||||
以及何时为应用配置使用它们非常重要。
|
||||
{{< /note >}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
|
@ -389,7 +388,7 @@ kubelet 可以配置为使用该协议来执行应用存活性检查。
|
|||
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
才能配置依赖于 gRPC 的检查机制。
|
||||
|
||||
这个例子展示了如何配置 Kubernetes 以将其用于应用程序的存活性检查。
|
||||
这个例子展示了如何配置 Kubernetes 以将其用于应用的存活性检查。
|
||||
类似地，你可以配置就绪探针和启动探针。
|
||||
|
||||
下面是一个示例清单：
|
||||
|
|
@ -557,7 +556,7 @@ provide a fast response to container deadlocks.
|
|||
If the startup probe never succeeds, the container is killed after 300s and
|
||||
subject to the pod's `restartPolicy`.
|
||||
-->
|
||||
幸亏有启动探测，应用程序将会有最多 5 分钟（30 * 10 = 300s）的时间来完成其启动过程。
|
||||
幸亏有启动探测，应用将会有最多 5 分钟（30 * 10 = 300s）的时间来完成其启动过程。
|
||||
一旦启动探测成功一次，存活探测任务就会接管对容器的探测，对容器死锁作出快速响应。
|
||||
如果启动探测一直没有成功，容器会在 300 秒后被杀死，并且根据 `restartPolicy`
|
||||
来执行进一步处置。
|
||||
|
|
@ -646,7 +645,9 @@ liveness and readiness checks:
|
|||
|
||||
<!--
|
||||
* `initialDelaySeconds`: Number of seconds after the container has started before startup,
|
||||
liveness or readiness probes are initiated. Defaults to 0 seconds. Minimum value is 0.
|
||||
liveness or readiness probes are initiated. If a startup probe is defined, liveness and
|
||||
readiness probe delays do not begin until the startup probe has succeeded.
|
||||
Defaults to 0 seconds. Minimum value is 0.
|
||||
* `periodSeconds`: How often (in seconds) to perform the probe. Default to 10 seconds.
|
||||
The minimum value is 1.
|
||||
* `timeoutSeconds`: Number of seconds after which the probe times out.
|
||||
|
|
@ -655,7 +656,8 @@ liveness and readiness checks:
|
|||
after having failed. Defaults to 1. Must be 1 for liveness and startup Probes.
|
||||
Minimum value is 1.
|
||||
-->
|
||||
* `initialDelaySeconds`：容器启动后要等待多少秒后才启动启动、存活和就绪探针，
|
||||
* `initialDelaySeconds`：容器启动后要等待多少秒后才启动启动、存活和就绪探针。
|
||||
如果定义了启动探针，则存活探针和就绪探针的延迟将在启动探针已成功之后才开始计算。
|
||||
默认是 0 秒，最小值是 0。
|
||||
* `periodSeconds`：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。
|
||||
* `timeoutSeconds`：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。
|
||||
|
|
|
|||
Loading…
Reference in New Issue