[zh] Clean PodPreset related pages/examples
This commit is contained in:
parent
2f344c874e
commit
b9265d377e
|
@ -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
|
||||
|
|
|
@ -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" >}}
|
||||
|
|
|
@ -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.
|
||||
-->
|
||||
对于更早期版本,没有验证和变更的概念,并且准入控制器按照指定的确切顺序运行。
|
||||
|
|
|
@ -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 与环境特定的配置解耦。
|
|
@ -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
|
||||
```
|
||||
|
|
@ -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{}},
|
||||
|
|
|
@ -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: {}
|
|
@ -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: {}
|
|
@ -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"
|
||||
|
|
@ -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: {}
|
|
@ -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: {}
|
||||
|
|
@ -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: {}
|
||||
|
|
@ -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: {}
|
|
@ -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
|
||||
|
|
@ -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: {}
|
|
@ -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: {}
|
|
@ -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: {}
|
||||
|
|
@ -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
|
Loading…
Reference in New Issue