[zh] Clean PodPreset related pages/examples

This commit is contained in:
Qiming Teng 2021-01-18 10:22:45 +08:00
parent 2f344c874e
commit b9265d377e
18 changed files with 85 additions and 893 deletions

View File

@ -45,6 +45,26 @@ Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象
这样的信息可能会被放在 Pod 规约中或者镜像中。
用户可以创建 Secret同时系统也创建了一些 Secret。
{{< caution >}}
<!--
Kubernetes Secrets are, by default, stored as unencrypted base64-encoded
strings. By default they can be retrieved - as plain text - by anyone with API
access, or anyone with access to Kubernetes' underlying data store, etcd. In
order to safely use Secrets, we recommend you (at a minimum):
1. [Enable Encryption at Rest](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) for Secrets.
2. [Enable RBAC rules that restrict reading and writing the Secret](https://kubernetes.io/docs/reference/access-authn-authz/authorization/). Be aware that secrets can be obtained implicitly by anyone with the permission to create a Pod.
-->
Kubernetes Secret 默认情况下存储为 base64-编码的、非加密的字符串。
默认情况下,能够访问 API 的任何人,或者能够访问 Kubernetes 下层数据存储etcd
的任何人都可以以明文形式读取这些数据。
为了能够安全地使用 Secret我们建议你至少
1. 为 Secret [启用静态加密](/zh/docs/tasks/administer-cluster/encrypt-data/)
2. [启用 RBAC 规则来限制对 Secret 的读写操作](/zh/docs/reference/access-authn-authz/authorization/)。
要注意,任何被允许创建 Pod 的人都默认地具有读取 Secret 的权限。
{{< /caution >}}
<!-- body -->
<!--
@ -1243,7 +1263,7 @@ these pods.
The `imagePullSecrets` field is a list of references to secrets in the same namespace.
You can use an `imagePullSecrets` to pass a secret that contains a Docker (or other) image registry
password to the kubelet. The kubelet uses this information to pull a private image on behalf of your Pod.
See the [PodSpec API](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#podspec-v1-core) for more information about the `imagePullSecrets` field.
See the [PodSpec API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) for more information about the `imagePullSecrets` field.
#### Manually specifying an imagePullSecret
@ -1254,7 +1274,8 @@ You can learn how to specify `ImagePullSecrets` from the [container images docum
`imagePullSecrets` 字段中包含一个列表,列举对同一名字空间中的 Secret 的引用。
你可以使用 `imagePullSecrets` 将包含 Docker或其他镜像仓库密码的 Secret 传递给
kubelet。kubelet 使用此信息来替你的 Pod 拉取私有镜像。
关于 `imagePullSecrets` 字段的更多信息,请参考 [PodSpec API](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#podspec-v1-core) 文档。
关于 `imagePullSecrets` 字段的更多信息,请参考
[PodSpec API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 文档。
#### 手动指定 imagePullSecret
@ -1284,15 +1305,12 @@ Pod 将会将其的 imagePullSecret 字段设置为服务帐户的 imagePullSecr
Manually created secrets (e.g. one containing a token for accessing a github account)
can be automatically attached to pods based on their service account.
See [Injecting Information into Pods Using a PodPreset](/docs/tasks/inject-data-application/podpreset/) for a detailed explanation of that process.
-->
#### 自动挂载手动创建的 Secret
手动创建的 Secret例如包含用于访问 GitHub 帐户令牌的 Secret可以
根据其服务帐户自动附加到 Pod。
请参阅[使用 PodPreset 向 Pod 中注入信息](/zh/docs/tasks/inject-data-application/podpreset/)
以获取该过程的详细说明。
<!--
## Details

View File

@ -1,5 +1,5 @@
---
title: "Pods"
title: Pods
content_type: concept
weight: 10
no_list: true
@ -26,7 +26,7 @@ _Pods_ are the smallest deployable units of computing that you can create and ma
A _Pod_ (as in a pod of whales or pea pod) is a group of one or more
{{< glossary_tooltip text="containers" term_id="container" >}}
with shared storage/network resources, and a specification
with shared storage and network resources, and a specification
for how to run the containers. A Pod's contents are always co-located and
co-scheduled, and run in a shared context. A Pod models an
application-specific "logical host": it contains one or more application
@ -350,6 +350,62 @@ changing existing code.
这种抽象和关注点分离简化了整个系统的语义,并且使得用户可以在不改变现有代码的
前提下就能扩展集群的行为。
<!--
## Pod update and replacement
As mentioned in the previous section, when the Pod template for a workload
resource is changed, the controller creates new Pods based on the updated
template instead of updating or patching the existing Pods.
-->
## Pod 更新与替换 {#pod-update-and-replacement}
正如前面章节所述,当某工作负载的 Pod 模板被改变时,控制器会基于更新的模板
创建新的 Pod 对象而不是对现有 Pod 执行更新或者修补操作。
<!--
Kubernetes doesn't prevent you from managing Pods directly. It is possible to
update some fields of a running Pod, in place. However, Pod update operations
like
[`patch`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#patch-pod-v1-core), and
[`replace`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replace-pod-v1-core)
have some limitations:
-->
Kubernetes 并不禁止你直接管理 Pod。对运行中的 Pod 的某些字段执行就地更新操作
还是可能的。不过,类似
[`patch`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#patch-pod-v1-core) 和
[`replace`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replace-pod-v1-core)
这类更新操作有一些限制:
<!--
- Most of the metadata about a Pod is immutable. For example, you cannot
change the `namespace`, `name`, `uid`, or `creationTimestamp` fields;
the `generation` field is unique. It only accepts updates that increment the
field's current value.
- If the `metadata.deletionTimestamp` is set, no new entry can be added to the
`metadata.finalizers` list.
- Pod updates may not change fields other than `spec.containers[*].image`,
`spec.initContainers[*].image`, `spec.activeDeadlineSeconds` or
`spec.tolerations`. For `spec.tolerations`, you can only add new entries.
- When updating the `spec.activeDeadlineSeconds` field, two types of updates
are allowed:
1. setting the unassigned field to a positive number;
1. updating the field from a positive number to a smaller, non-negative
number.
-->
- Pod 的绝大多数元数据都是不可变的。例如,你不可以改变其 `namespace`、`name`、
`uid` 或者 `creationTimestamp` 字段;`generation` 字段是比较特别的,如果更新
该字段,只能增加字段取值而不能减少。
- 如果 `metadata.deletionTimestamp` 已经被设置,则不可以向 `metadata.finalizers`
列表中添加新的条目。
- Pod 更新不可以改变除 `spec.containers[*].image`、`spec.initContainers[*].image`、
`spec.activeDeadlineSeconds``spec.tolerations` 之外的字段。
对于 `spec.tolerations`,你只被允许添加新的条目到其中。
- 在更新`spec.activeDeadlineSeconds` 字段时,以下两种更新操作是被允许的:
1. 如果该字段尚未设置,可以将其设置为一个正数;
1. 如果该字段已经设置为一个正数,可以将其设置为一个更小的、非负的整数。
<!--
## Resource sharing and communication
@ -486,7 +542,6 @@ but cannot be controlled from there.
<!--
* Learn about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/).
* Learn about [PodPresets](/docs/concepts/workloads/pods/podpreset/).
* Learn about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to
configure different Pods with different container runtime configurations.
* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
@ -497,7 +552,6 @@ but cannot be controlled from there.
* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container.
--
* 了解 [Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/)
* 了解 [PodPresets](/zh/docs/concepts/workloads/pods/podpreset/)
* 了解 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/),以及如何使用它
来配置不同的 Pod 使用不同的容器运行时配置
* 了解 [Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
@ -510,7 +564,7 @@ but cannot be controlled from there.
中解释了在同一 Pod 中包含多个容器时的几种常见布局。
<!--
To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}, you can read about the prior art, including:
To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}), you can read about the prior art, including:
-->
要了解为什么 Kubernetes 会在其他资源
(如 {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}

View File

@ -1117,19 +1117,6 @@ For more information about persistent volume claims, see [PersistentVolumeClaims
关于持久化卷申领的更多信息,请参见
[PersistentVolumeClaims](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
### PodPreset {#podpreset}
<!--
This admission controller injects a pod with the fields specified in a matching PodPreset.
See also [PodPreset concept](/docs/concepts/workloads/pods/podpreset/) and
[Inject Information into Pods Using a PodPreset](/docs/tasks/inject-data-application/podpreset)
for more information.
-->
该准入控制器根据与 PodPreset 中条件的匹配情况,将指定字段注入一个 Pod。
另请参见 [PodPreset 概念](/zh/docs/concepts/workloads/pods/podpreset/)和
[使用 PodPreset 将信息注入 Pod](/zh/docs/tasks/inject-data-application/podpreset)
了解更多信息。
### PodSecurityPolicy {#podsecuritypolicy}
<!--
@ -1350,12 +1337,12 @@ versions 1.9 and later).
<!--
## Is there a recommended set of admission controllers to use?
Yes. For Kubernetes version 1.10 and later, the recommended admission controllers are enabled by default (shown [here](/docs/reference/command-line-tools-reference/kube-apiserver/#options)), so you do not need to explicitly specify them. You can enable additional admission controllers beyond the default set using the `--enable-admission-plugins` flag (**order doesn't matter**).
Yes. The recommended admission controllers are enabled by default (shown [here](/docs/reference/command-line-tools-reference/kube-apiserver/#options)), so you do not need to explicitly specify them. You can enable additional admission controllers beyond the default set using the `--enable-admission-plugins` flag (**order doesn't matter**).
-->
## 有推荐的准入控制器吗?
有。对于 Kubernetes 1.10 以上的版本,推荐使用的准入控制器默认情况下都处于启用状态
(查看[这里](/zh/docs/reference/command-line-tools-reference/kube-apiserver/#options))。
有。推荐使用的准入控制器默认情况下都处于启用状态
查看[这里](/zh/docs/reference/command-line-tools-reference/kube-apiserver/#options))。
因此,你无需显式指定它们。
你可以使用 `--enable-admission-plugins` 标志( **顺序不重要** )来启用默认设置以外的其他准入控制器。
@ -1366,31 +1353,3 @@ Yes. For Kubernetes version 1.10 and later, the recommended admission controller
`--admission-control` 在 1.10 中已废弃,由 `--enable-admission-plugins` 取代。
{{< /note >}}
<!--
For Kubernetes 1.9 and earlier, we recommend running the following set of admission controllers using the `--admission-control` flag (**order matters**).
-->
对于 Kubernetes 1.9 及更早版本,我们建议使用 `--admission-control` 标志
**顺序很重要**)运行下面的一组准入控制器。
* v1.9
```shell
--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota
```
<!--
* It's worth reiterating that in 1.9, these happen in a mutating phase
and a validating phase, and that for example `ResourceQuota` runs in the validating
phase, and therefore is the last admission controller to run.
`MutatingAdmissionWebhook` appears before it in this list, because it runs
in the mutating phase.
-->
* 需要重申的是,在 1.9 中,它们都发生在变更阶段和验证阶段,例如 `ResourceQuota`
在验证阶段运行,因此是最后一个运行的准入控制器。
`MutatingAdmissionWebhook` 出现在此列表的前面,因为它在变更阶段运行。
<!--
For earlier versions, there was no concept of validating versus mutating and the
admission controllers ran in the exact order specified.
-->
对于更早期版本,没有验证和变更的概念,并且准入控制器按照指定的确切顺序运行。

View File

@ -1,40 +0,0 @@
---
title: PodPreset
id: podpreset
date: 2018-04-12
full_link:
short_description: >
PodPreset 是一种 API 对象,在创建 Pod 时将诸如 Secret、卷挂载和环境变量之类的信息注入到该 Pod 中。
aka:
tags:
- operation
---
<!--
---
title: PodPreset
id: podpreset
date: 2018-04-12
full_link:
short_description: >
An API object that injects information such as secrets, volume mounts, and environment variables into pods at creation time.
aka:
tags:
- operation
---
-->
<!--
An API object that injects information such as secrets, volume mounts, and environment variables into pods at creation time.
-->
PodPreset 是一种 API 对象,在创建 Pod 时将诸如 Secret、卷挂载和环境变量之类的信息注入到该 Pod 中。
<!--more-->
<!--
This object chooses the pods to inject information into using standard selectors. This allows the podspec definitions to be nonspecific, decoupling the podspec from environment specific configuration.
-->
此 API 对象使用标准选择器选择 Pod 并向其中注入信息。这允许 podspec 定义是非特定的,从而将 podspec 与环境特定的配置解耦。

View File

@ -1,512 +0,0 @@
---
title: 使用 PodPreset 将信息注入 Pod
min-kubernetes-server-version: v1.6
content_type: task
weight: 60
---
<!--
reviewers:
- jessfraz
title: Inject Information into Pods Using a PodPreset
min-kubernetes-server-version: v1.6
content_type: task
weight: 60
-->
{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
<!--
This page shows how to use PodPreset objects to inject information like {{< glossary_tooltip text="Secrets" term_id="secret" >}}, volume mounts, and {{< glossary_tooltip text="environment variables" term_id="container-env-variables" >}} into Pods at creation time.
-->
本页展示如何在创建 Pod 时 使用 PodPreset 对象将类似
{{< glossary_tooltip text="Secret" term_id="secret" >}}、卷挂载和
{{< glossary_tooltip text="环境变量" term_id="container-env-variables" >}}
这类信息注入到 Pod 中。
## {{% heading "prerequisites" %}}
<!--
You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one using [Minikube](https://minikube.sigs.k8s.io/docs/).
Make sure that you have [enabled PodPreset](/docs/concepts/workloads/pods/podpreset/#enable-pod-preset) in your cluster.
-->
你需要一个运行的 Kubernetes 集群以及配置好与集群通信的 kubectl 命令行工具。
如果你还没有集群,可以使用 [Minikube](https://minikube.sigs.k8s.io/docs/)
安装一个。
确保你已经在集群中[启用了 PodPreset](/zh/docs/concepts/workloads/pods/podpreset/#enable-pod-preset)。
<!--
## Use Pod presets to inject environment variables and volumes
In this step, you create a preset that has a volume mount and one environment variable.
Here is the manifest for the PodPreset:
-->
## 使用 PodPreset 来注入环境变量和卷
在这一步中,你要创建一个 PodPreset 对象,其中包含卷挂载和一个环境变量。
下面是 PodPreset 的清单:
{{< codenew file="podpreset/preset.yaml" >}}
<!--
The name of a PodPreset object must be a valid
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
-->
PodPreset 对象的名称必须是一个合法的
[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
<!--
In the manifest, you can see that the preset has an environment variable definition called `DB_PORT`
and a volume mount definition called `cache-volume` which is mounted under `/cache`. The {{< glossary_tooltip text="selector" term_id="selector" >}} specifies that
the preset will act upon any Pod that is labeled `role:frontend`.
Create the PodPreset:
-->
在清单中,你可以看到 PodPreset 有一个名为 `DB_PORT` 的环境变量定义,
和一个名为 `cache-volume` 的卷挂载定义,该卷挂载于 `/cache` 下。
{{< glossary_tooltip text="选择算符" term_id="selector" >}} 设定此 PodPreset
将应用于所有匹配 `role:frontend` 标签的 Pods。
创建 PodPreset
```shell
kubectl apply -f https://k8s.io/examples/podpreset/preset.yaml
```
<!--
Verify that the PodPreset has been created:
-->
检查所创建的 PodPreset
```shell
kubectl get podpreset
```
```
NAME AGE
allow-database 1m
```
<!--
This manifest defines a Pod labelled `role: frontend` (matching the PodPreset's selector):
-->
下面的清单定义了一个带有标签 `role: frontend` 的 Pod与 PodPreset
的选择算符匹配):
{{< codenew file="podpreset/pod.yaml" >}}
<!--
Create the Pod:
-->
创建 Pod
```shell
kubectl create -f https://k8s.io/examples/podpreset/pod.yaml
```
<!--
Verify that the Pod is running:
-->
验证 Pod 出于运行状态:
```shell
kubectl get pods
```
```
NAME READY STATUS RESTARTS AGE
website 1/1 Running 0 4m
```
<!--
View the Pod spec altered by the admission controller in order to see the effects of the preset
having been applied:
-->
查看被准入控制器更改过的 Pod 规约,以了解 PodPreset 在 Pod 上执行过的操作:
```shell
kubectl get pod website -o yaml
```
{{< codenew file="podpreset/merged.yaml" >}}
<!--
The `DB_PORT` environment variable, the `volumeMount` and the `podpreset.admission.kubernetes.io` annotation
of the Pod verify that the preset has been applied.
-->
Pod 的环境变量 `DB_PORT``volumeMount` 和 `podpreset.admission.kubernetes.io` 注解
表明 PodPreset 确实起了作用。
<!--
## Pod spec with ConfigMap example
This is an example to show how a Pod spec is modified by a Pod preset
that references a ConfigMap containing environment variables.
-->
### 带有 ConfigMap 的 Pod Spec 示例
这里的示例展示了如何通过 PodPreset 修改 Pod 规约PodPreset 中定义了 `ConfigMap`
作为环境变量取值来源。
<!--
Here is the manifest containing the definition of the ConfigMap:
-->
包含 ConfigMap 定义的清单:
{{< codenew file="podpreset/configmap.yaml" >}}
<!--
Create the ConfigMap:
-->
创建 ConfigMap
```shell
kubectl create -f https://k8s.io/examples/podpreset/configmap.yaml
```
<!--
Here is a PodPreset manifest referencing that ConfigMap:
-->
引用该 ConfigMap 的 PodPreset 的清单:
{{< codenew file="podpreset/allow-db.yaml" >}}
<!--
Create the preset that references the ConfigMap:
-->
创建 PodPreset
```shell
kubectl create -f https://k8s.io/examples/podpreset/allow-db.yaml
```
<!--
The following manifest defines a Pod matching the PodPreset for this example:
-->
下面的清单包含与 PodPreset 匹配的 Pod
{{< codenew file="podpreset/pod.yaml" >}}
<!--
Create the Pod:
-->
创建 Pod
```shell
kubectl create -f https://k8s.io/examples/podpreset/pod.yaml
```
<!--
View the Pod spec altered by the admission controller in order to see the effects of the preset
having been applied:
-->
查看 Pod 规约被准入控制器修改后的结果,了解 PodPreset 应用之后的效果:
```shell
kubectl get pod website -o yaml
```
{{< codenew file="podpreset/allow-db-merged.yaml" >}}
<!--
The `DB_PORT` environment variable and the `podpreset.admission.kubernetes.io` annotation of the Pod
verify that the preset has been applied.
-->
Pod 的环境变量 `DB_PORT``podpreset.admission.kubernetes.io` 注解
表明 PodPreset 确实起了作用。
<!--
## ReplicaSet with Pod spec example
This is an example to show that only Pod specs are modified by Pod presets. Other workload types
like ReplicaSets or Deployments are unaffected.
Here is the manifest for the PodPreset for this example:
-->
### 带有 Pod Spec 的 ReplicaSet 示例
以下示例展示了(通过 ReplicaSet 创建 Pod 后)只有 Pod 规约会被 PodPreset 所修改,
其他资源类型(如 ReplicaSet、Deployment不受影响。
下面是本例所用 PodPreset 的清单:
{{< codenew file="podpreset/preset.yaml" >}}
<!--
Create the preset:
-->
创建 Preset
```shell
kubectl apply -f https://k8s.io/examples/podpreset/preset.yaml
```
<!--
This manifest defines a ReplicaSet that manages three application Pods:
-->
此清单定义了一个管理三个应用 Pod 的 ReplicaSet
{{< codenew file="podpreset/replicaset.yaml" >}}
<!--
Create the ReplicaSet:
-->
创建 ReplicaSet
```shell
kubectl create -f https://k8s.io/examples/podpreset/replicaset.yaml
```
<!--
Verify that the Pods created by the ReplicaSet are running:
-->
验证 ReplicaSet 所创建的 Pod 处于运行状态:
```shell
kubectl get pods
```
<!--
The output shows that the Pods are running:
-->
输出显示 Pod 正在运行:
```
NAME READY STATUS RESTARTS AGE
frontend-2l94q 1/1 Running 0 2m18s
frontend-6vdgn 1/1 Running 0 2m18s
frontend-jzt4p 1/1 Running 0 2m18s
```
<!--
View the `spec` of the ReplicaSet:
-->
查看 ReplicaSet 的 `spec` 内容:
```shell
kubectl get replicasets frontend -o yaml
```
<!--
The ReplicaSet object's `spec` was not changed, nor does the ReplicaSet contain a
`podpreset.admission.kubernetes.io` annotation. This is because a PodPreset only
applies to Pod objects.
To see the effects of the preset having been applied, you need to look at individual Pods.
-->
{{< note >}}
ReplicaSet 对象的 `spec` 未被改变ReplicaSet 也没有被添加
`podpreset.admission.kubernetes.io` 注解。这是因为PodPreset 只针对
Pod 对象起作用。
要查看 PodPreset 的应用效果,你需要逐个地查看 Pod。
{{< /note >}}
<!--
The command to view the specs of the affected Pods is:
-->
查看被影响的 Pod 的规约的命令是:
```shell
kubectl get pod --selector=role=frontend -o yaml
```
{{< codenew file="podpreset/replicaset-merged.yaml" >}}
<!--
Again the `podpreset.admission.kubernetes.io` annotation of the Pods
verifies that the preset has been applied.
-->
再一次Pod 的 `podpreset.admission.kubernetes.io` 注解表明 PodPreset
已经被应用过。
<!--
## Multiple Pod presets example
This is an example to show how a Pod spec is modified by multiple Pod presets.
Here is the manifest for the first PodPreset:
-->
### 多 PodPreset 示例
这里的示例展示了如何通过多个 PodPreset 对象修改 Pod 规约。
第一个 PodPreset 的清单如下:
{{< codenew file="podpreset/preset.yaml" >}}
<!--
Create the first PodPreset for this example:
-->
为此例创建第一个 PodPreset
```shell
kubectl apply -f https://k8s.io/examples/podpreset/preset.yaml
```
<!--
Here is the manifest for the second PodPreset:
-->
下面是第二个 PodPreset 的清单:
{{< codenew file="podpreset/proxy.yaml" >}}
<!--
Create the second preset:
-->
创建第二个 PodPreset
```shell
kubectl apply -f https://k8s.io/examples/podpreset/proxy.yaml
```
<!--
Here's a manifest containing the definition of an applicable Pod (matched by two PodPresets):
-->
下面是包含可被修改的 Pod 定义的清单(此 Pod 同时被两个 PodPreset 匹配到):
{{< codenew file="podpreset/pod.yaml" >}}
<!--
Create the Pod:
-->
创建 Pod
```shell
kubectl create -f https://k8s.io/examples/podpreset/pod.yaml
```
<!--
View the Pod spec altered by the admission controller in order to see the effects of both presets
having been applied:
-->
查看被准入控制器更改后的 Pod 规约,以了解被两个 PodPreset 一同修改
后的效果:
```shell
kubectl get pod website -o yaml
```
{{< codenew file="podpreset/multi-merged.yaml" >}}
<!--
The `DB_PORT` environment variable, the `proxy-volume` VolumeMount and the two `podpreset.admission.kubernetes.io`
annotations of the Pod verify that both presets have been applied.
-->
Pod 定义中的 `DB_PORT` 环境变量、`proxy-volume` 卷挂载以及
两个 `podpreset.admission.kubernetes.io` 可以证明两个 Preset 都被应用了。
<!--
## Conflict example
This is an example to show how a Pod spec is not modified by a Pod preset when there is a conflict.
The conflict in this example consists of a `VolumeMount` in the PodPreset conflicting with a Pod that defines the same `mountPath`.
Here is the manifest for the PodPreset:
-->
### 冲突示例
这里的示例展示了 PodPreset 与原 Pod 存在冲突时Pod 规约不会被修改。
本例中的冲突是指 PodPreset 中的 `volumeMount` 与 Pod 中定义的卷挂载在
`mountPath` 上有冲突。
下面是 PodPreset 的清单:
{{< codenew file="podpreset/conflict-preset.yaml" >}}
<!--
Note the `mountPath` value of `/cache`.
Create the preset:
-->
注意 `mountPath` 的取值是 `/cache`
创建 PodPreset
```shell
kubectl apply -f https://k8s.io/examples/podpreset/conflict-preset.yaml
```
<!--
Here is the manifest for the Pod:
-->
下面是 Pod 的清单:
{{< codenew file="podpreset/conflict-pod.yaml" >}}
<!--
Note the volumeMount element with the same path as in the PodPreset.
Create the Pod:
-->
注意清单中 `volumeMount` 元素的取值与 PodPreset 中的路径值相同。
创建 Pod
```shell
kubectl create -f https://k8s.io/examples/podpreset/conflict-pod.yaml
```
<!--
View the Pod spec:
-->
查看 Pod 规约:
```shell
kubectl get pod website -o yaml
```
{{< codenew file="podpreset/conflict-pod.yaml" >}}
<!--
You can see there is no preset annotation (`podpreset.admission.kubernetes.io`). Seeing no annotation tells you that no preset has not been applied to the Pod.
However, the
[PodPreset admission controller](/docs/reference/access-authn-authz/admission-controllers/#podpreset)
logs a warning containing details of the conflict.
You can view the warning using `kubectl`:
-->
这里你可以看到 Pod 上并没有 PodPreset 的注解 podpreset.admission.kubernetes.io`。
这意味着没有 PodPreset 被应用到 Pod 之上。
不过 [PodPreset 准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#podpreset)
还是为所发生的冲突留下了一条警告性质的日志。
你可以通过 `kubectl` 来查看此警告信息:
```shell
kubectl -n kube-system logs -l=component=kube-apiserver
```
<!--
The output should look similar to:
-->
输出类似于:
```
W1214 13:00:12.987884 1 admission.go:147] conflict occurred while applying podpresets: allow-database on pod: err: merging volume mounts for allow-database has a conflict on mount path /cache:
v1.VolumeMount{Name:"other-volume", ReadOnly:false, MountPath:"/cache", SubPath:"", MountPropagation:(*v1.MountPropagationMode)(nil), SubPathExpr:""}
does not match
core.VolumeMount{Name:"cache-volume", ReadOnly:false, MountPath:"/cache", SubPath:"", MountPropagation:(*core.MountPropagationMode)(nil), SubPathExpr:""}
in container
```
注意这里关于卷挂载路径冲突的消息。
<!--
## Deleting a PodPreset
Once you don't need a PodPreset anymore, you can delete it with `kubectl`:
-->
## 删除 Pod Preset
一旦用户不再需要 PodPreset可以使用 `kubectl` 将其删除:
```shell
kubectl delete podpreset allow-database
```
<!--
The output shows that the PodPreset was deleted:
-->
输出显示 PodPreset 已经被删除:
```
podpreset "allow-database" deleted
```

View File

@ -56,9 +56,6 @@ import (
"k8s.io/kubernetes/pkg/apis/rbac"
rbac_validation "k8s.io/kubernetes/pkg/apis/rbac/validation"
"k8s.io/kubernetes/pkg/apis/settings"
settings_validation "k8s.io/kubernetes/pkg/apis/settings/validation"
"k8s.io/kubernetes/pkg/apis/storage"
storage_validation "k8s.io/kubernetes/pkg/apis/storage/validation"
@ -297,11 +294,6 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) {
case *rbac.ClusterRoleBinding:
// clusterolebinding does not accept namespace
errors = rbac_validation.ValidateClusterRoleBinding(t)
case *settings.PodPreset:
if t.Namespace == "" {
t.Namespace = api.NamespaceDefault
}
errors = settings_validation.ValidatePodPreset(t)
case *storage.StorageClass:
// storageclass does not accept namespace
errors = storage_validation.ValidateStorageClass(t)
@ -519,20 +511,6 @@ func TestExampleObjectSchemas(t *testing.T) {
"node-problem-detector-configmap": {&apps.DaemonSet{}},
"termination": {&api.Pod{}},
},
"podpreset": {
"allow-db": {&settings.PodPreset{}},
"allow-db-merged": {&api.Pod{}},
"configmap": {&api.ConfigMap{}},
"conflict-pod": {&api.Pod{}},
"conflict-preset": {&settings.PodPreset{}},
"merged": {&api.Pod{}},
"multi-merged": {&api.Pod{}},
"pod": {&api.Pod{}},
"preset": {&settings.PodPreset{}},
"proxy": {&settings.PodPreset{}},
"replicaset-merged": {&api.Pod{}},
"replicaset": {&apps.ReplicaSet{}},
},
"pods": {
"commands": {&api.Pod{}},
"init-containers": {&api.Pod{}},

View File

@ -1,31 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: website
labels:
app: website
role: frontend
annotations:
podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version"
spec:
containers:
- name: website
image: nginx
volumeMounts:
- mountPath: /cache
name: cache-volume
ports:
- containerPort: 80
env:
- name: DB_PORT
value: "6379"
- name: duplicate_key
value: FROM_ENV
- name: expansion
value: $(REPLACE_ME)
envFrom:
- configMapRef:
name: etcd-env-config
volumes:
- name: cache-volume
emptyDir: {}

View File

@ -1,24 +0,0 @@
apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: allow-database
spec:
selector:
matchLabels:
role: frontend
env:
- name: DB_PORT
value: "6379"
- name: duplicate_key
value: FROM_ENV
- name: expansion
value: $(REPLACE_ME)
envFrom:
- configMapRef:
name: etcd-env-config
volumeMounts:
- mountPath: /cache
name: cache-volume
volumes:
- name: cache-volume
emptyDir: {}

View File

@ -1,14 +0,0 @@
apiVersion: v1
kind: ConfigMap
metadata:
name: etcd-env-config
data:
number_of_members: "1"
initial_cluster_state: new
initial_cluster_token: DUMMY_ETCD_INITIAL_CLUSTER_TOKEN
discovery_token: DUMMY_ETCD_DISCOVERY_TOKEN
discovery_url: http://etcd_discovery:2379
etcdctl_peers: http://etcd:2379
duplicate_key: FROM_CONFIG_MAP
REPLACE_ME: "a value"

View File

@ -1,19 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: website
labels:
app: website
role: frontend
spec:
containers:
- name: website
image: nginx
volumeMounts:
- mountPath: /cache
name: cache-volume
ports:
- containerPort: 80
volumes:
- name: cache-volume
emptyDir: {}

View File

@ -1,18 +0,0 @@
apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: allow-database
spec:
selector:
matchLabels:
role: frontend
env:
- name: DB_PORT
value: "6379"
volumeMounts:
- mountPath: /cache
name: other-volume
volumes:
- name: other-volume
emptyDir: {}

View File

@ -1,25 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: website
labels:
app: website
role: frontend
annotations:
podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version"
spec:
containers:
- name: website
image: nginx
volumeMounts:
- mountPath: /cache
name: cache-volume
ports:
- containerPort: 80
env:
- name: DB_PORT
value: "6379"
volumes:
- name: cache-volume
emptyDir: {}

View File

@ -1,29 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: website
labels:
app: website
role: frontend
annotations:
podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version"
podpreset.admission.kubernetes.io/podpreset-proxy: "resource version"
spec:
containers:
- name: website
image: nginx
volumeMounts:
- mountPath: /cache
name: cache-volume
- mountPath: /etc/proxy/configs
name: proxy-volume
ports:
- containerPort: 80
env:
- name: DB_PORT
value: "6379"
volumes:
- name: cache-volume
emptyDir: {}
- name: proxy-volume
emptyDir: {}

View File

@ -1,14 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: website
labels:
app: website
role: frontend
spec:
containers:
- name: website
image: nginx
ports:
- containerPort: 80

View File

@ -1,17 +0,0 @@
apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: allow-database
spec:
selector:
matchLabels:
role: frontend
env:
- name: DB_PORT
value: "6379"
volumeMounts:
- mountPath: /cache
name: cache-volume
volumes:
- name: cache-volume
emptyDir: {}

View File

@ -1,14 +0,0 @@
apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: proxy
spec:
selector:
matchLabels:
role: frontend
volumeMounts:
- mountPath: /etc/proxy/configs
name: proxy-volume
volumes:
- name: proxy-volume
emptyDir: {}

View File

@ -1,31 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: frontend
labels:
app: guestbook
role: frontend
annotations:
podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version"
spec:
containers:
- name: php-redis
image: gcr.io/google_samples/gb-frontend:v3
resources:
requests:
cpu: 100m
memory: 100Mi
volumeMounts:
- mountPath: /cache
name: cache-volume
env:
- name: GET_HOSTS_FROM
value: dns
- name: DB_PORT
value: "6379"
ports:
- containerPort: 80
volumes:
- name: cache-volume
emptyDir: {}

View File

@ -1,29 +0,0 @@
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend
spec:
replicas: 3
selector:
matchLabels:
role: frontend
matchExpressions:
- {key: role, operator: In, values: [frontend]}
template:
metadata:
labels:
app: guestbook
role: frontend
spec:
containers:
- name: php-redis
image: gcr.io/google_samples/gb-frontend:v3
resources:
requests:
cpu: 100m
memory: 100Mi
env:
- name: GET_HOSTS_FROM
value: dns
ports:
- containerPort: 80