merged master into dev-1.18 to keep in sync
This commit is contained in:
vineeth
@@ -0,0 +1,222 @@
|
||||
---
|
||||
title: Kubernetes 控制面板的指标
|
||||
content_template: templates/concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
System component metrics can give a better look into what is happening inside them. Metrics are particularly useful for building dashboards and alerts.
|
||||
|
||||
Metrics in Kubernetes control plane are emitted in [prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/) and are human readable.
|
||||
-->
|
||||
|
||||
系统组件的指标可以让我们更好的看清系统内部究竟发生了什么，尤其对于构建仪表盘和告警都非常有用。
|
||||
|
||||
Kubernetes 控制面板中的指标是以 [prometheus](https://prometheus.io/docs/instrumenting/exposition_formats/) 格式发出的，而且是易于阅读的。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## Metrics in Kubernetes
|
||||
In most cases metrics are available on `/metrics` endpoint of the HTTP server. For components that doesn't expose endpoint by default it can be enabled using `--bind-address` flag.
|
||||
-->
|
||||
|
||||
## Kubernetes 的指标
|
||||
|
||||
在大多数情况下，指标在 HTTP 服务器的 `/metrics` 端点使用，对于默认情况下不暴露端点的组件，可以使用 `--bind-address` 参数启用。
|
||||
|
||||
<!--
|
||||
Examples of those components:
|
||||
-->
|
||||
|
||||
举例下面这些组件：
|
||||
|
||||
* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}
|
||||
* {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}
|
||||
* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
|
||||
* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}}
|
||||
* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}
|
||||
|
||||
<!--
|
||||
In a production environment you may want to configure [Prometheus Server](https://prometheus.io/) or some other metrics scraper
|
||||
to periodically gather these metrics and make them available in some kind of time series database.
|
||||
|
||||
Note that {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} also exposes metrics in `/metrics/cadvisor`, `/metrics/resource` and `/metrics/probes` endpoints. Those metrics do not have same lifecycle.
|
||||
|
||||
If your cluster uses {{< glossary_tooltip term_id="rbac" text="RBAC" >}}, reading metrics requires authorization via a user, group or ServiceAccount with a ClusterRole that allows accessing `/metrics`.
|
||||
For example:
|
||||
-->
|
||||
|
||||
在生产环境中，你可能需要配置 [Prometheus Server](https://prometheus.io/) 或其他指标收集器来定期收集这些指标，并使它们在某种时间序列数据库中可用。
|
||||
|
||||
请注意 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} 同样在 `/metrics/cadvisor`、`/metrics/resource` 和 `/metrics/probes` 等端点提供性能指标。这些指标的生命周期并不相同。
|
||||
|
||||
如果你的集群还使用了 {{< glossary_tooltip term_id="rbac" text="RBAC" >}} ，那读取指标数据的时候，还需要通过具有 ClusterRole 的用户、组或者 ServiceAccount 来进行授权，才有权限访问 `/metrics` 。
|
||||
|
||||
举例：
|
||||
|
||||
```
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: prometheus
|
||||
rules:
|
||||
- nonResourceURLs:
|
||||
- "/metrics"
|
||||
verbs:
|
||||
- get
|
||||
```
|
||||
|
||||
<!--
|
||||
## Metric lifecycle
|
||||
Alpha metric → Stable metric → Deprecated metric → Hidden metric → Deletion
|
||||
|
||||
Alpha metrics have no stability guarantees; as such they can be modified or deleted at any time.
|
||||
|
||||
Stable metrics can be guaranteed to not change; Specifically, stability means:
|
||||
-->
|
||||
|
||||
## 指标的生命周期
|
||||
|
||||
内测版指标 → 稳定版指标 → 弃用指标 → 隐藏指标 → 删除
|
||||
|
||||
内测版指标没有任何稳定性保证，因此可能随时被修改或删除。
|
||||
|
||||
稳定版指标可以保证不会改变，具体的说，稳定就意味着：
|
||||
|
||||
<!--
|
||||
* the metric itself will not be deleted (or renamed)
|
||||
* the type of metric will not be modified
|
||||
-->
|
||||
|
||||
* 这个指标自身不会被删除或者重命名。
|
||||
* 这个指标类型不会被更改
|
||||
|
||||
<!--
|
||||
Deprecated metric signal that the metric will eventually be deleted; to find which version, you need to check annotation, which includes from which kubernetes version that metric will be considered deprecated.
|
||||
|
||||
Before deprecation:
|
||||
-->
|
||||
|
||||
弃用指标表明这个指标最终将会被删除，要想查找是哪个版本，你需要检查其注释，注释中包括该指标从哪个 kubernetes 版本被弃用。
|
||||
|
||||
指标弃用前：
|
||||
|
||||
```
|
||||
# HELP some_counter this counts things
|
||||
# TYPE some_counter counter
|
||||
some_counter 0
|
||||
```
|
||||
|
||||
<!--
|
||||
After deprecation:
|
||||
-->
|
||||
|
||||
指标弃用后：
|
||||
|
||||
```
|
||||
# HELP some_counter (Deprecated since 1.15.0) this counts things
|
||||
# TYPE some_counter counter
|
||||
some_counter 0
|
||||
```
|
||||
|
||||
<!--
|
||||
Once a metric is hidden then by default the metrics is not published for scraping. To use a hidden metric, you need to override the configuration for the relevant cluster component.
|
||||
|
||||
Once a metric is deleted, the metric is not published. You cannot change this using an override.
|
||||
-->
|
||||
|
||||
一个指标一旦被隐藏，默认这个指标是不会发布来被抓取的。如果你想要使用这个隐藏指标，你需要覆盖相关集群组件的配置。
|
||||
|
||||
一个指标一旦被删除，那这个指标就不会被发布，您也不可以通过覆盖配置来进行更改。
|
||||
|
||||
<!--
|
||||
## Show Hidden Metrics
|
||||
|
||||
As described above, admins can enable hidden metrics through a command-line flag on a specific binary. This intends to be used as an escape hatch for admins if they missed the migration of the metrics deprecated in the last release.
|
||||
|
||||
The flag `show-hidden-metrics-for-version` takes a version for which you want to show metrics deprecated in that release. The version is expressed as x.y, where x is the major version, y is the minor version. The patch version is not needed even though a metrics can be deprecated in a patch release, the reason for that is the metrics deprecation policy runs against the minor release.
|
||||
|
||||
The flag can only take the previous minor version as it's value. All metrics hidden in previous will be emitted if admins set the previous version to `show-hidden-metrics-for-version`. The too old version is not allowed because this violates the metrics deprecated policy.
|
||||
|
||||
Take metric `A` as an example, here assumed that `A` is deprecated in 1.n. According to metrics deprecated policy, we can reach the following conclusion:
|
||||
-->
|
||||
|
||||
## 显示隐藏指标
|
||||
|
||||
综上所述，管理员可以通过在运行可执行文件时添加一些特定的参数来开启一些隐藏的指标。当管理员错过了之前版本的的一些已弃用的指标时，这个可被视作是一个后门。
|
||||
|
||||
`show-hidden-metrics-for-version` 参数可以指定一个版本，用来显示这个版本中被隐藏的指标。这个版本号形式是x.y，x 是主要版本号，y 是次要版本号。补丁版本并不是必须的，尽管在一些补丁版本中也会有一些指标会被弃用，因为指标弃用策略主要是针对次要版本。
|
||||
|
||||
这个参数只能使用上一版本作为其值，如果管理员将上一版本设置为 `show-hidden-metrics-for-version` 的值，那么就会显示上一版本所有被隐藏的指标，太老的版本是不允许的，因为这不符合指标弃用策略。
|
||||
|
||||
以指标 `A` 为例，这里假设 `A` 指标在 1.n 版本中被弃用，根据指标弃用策略，我们可以得出以下结论：
|
||||
|
||||
<!--
|
||||
* In release `1.n`, the metric is deprecated, and it can be emitted by default.
|
||||
* In release `1.n+1`, the metric is hidden by default and it can be emitted by command line `show-hidden-metrics-for-version=1.n`.
|
||||
* In release `1.n+2`, the metric should be removed from the codebase. No escape hatch anymore.
|
||||
|
||||
If you're upgrading from release `1.12` to `1.13`, but still depend on a metric `A` deprecated in `1.12`, you should set hidden metrics via command line: `--show-hidden-metrics=1.12` and remember to remove this metric dependency before upgrading to `1.14`
|
||||
-->
|
||||
|
||||
* 在 `1.n` 版本中，这个指标被弃用，并且默认情况下，这个指标还是可以发出.
|
||||
* 在 `1.n+1` 版本中，这个指标默认被隐藏，你可以通过设置参数 `show-hidden-metrics-for-version=1.n` 来使它可以被发出.
|
||||
* 在 `1.n+2` 版本中，这个指标就被从代码库中删除，也不会再有后门了.
|
||||
|
||||
如果你想要从 `1.12` 版本升级到 `1.13` ，但仍然需要依赖指标 `A` ，你可以通过命令行设置隐藏指标 `--show-hidden-metrics=1.12` ，但是在升级到 `1.14`时就必须要删除这个指标的依赖，因为这个版本中这个指标已经被删除了。
|
||||
|
||||
<!--
|
||||
## Component metrics
|
||||
|
||||
### kube-controller-manager metrics
|
||||
|
||||
Controller manager metrics provide important insight into the performance and health of the controller manager.
|
||||
These metrics include common Go language runtime metrics such as go_routine count and controller specific metrics such as
|
||||
etcd request latencies or Cloudprovider (AWS, GCE, OpenStack) API latencies that can be used
|
||||
to gauge the health of a cluster.
|
||||
|
||||
Starting from Kubernetes 1.7, detailed Cloudprovider metrics are available for storage operations for GCE, AWS, Vsphere and OpenStack.
|
||||
These metrics can be used to monitor health of persistent volume operations.
|
||||
|
||||
For example, for GCE these metrics are called:
|
||||
-->
|
||||
|
||||
## 组件指标
|
||||
|
||||
### kube-controller-manager 指标
|
||||
|
||||
控制器管理器指标提供了有关控制器管理器性能和运行状况的重要见解。这些指标包括常见的一些 Go 语言运行时的重要指标（比如 go_routine 的数量）和一些控制器的特定指标（比如 etcd 的请求时延），还有一些云供应商（比如 AWS、GCE、OpenStack）的 API 请求延迟，用来评估集群的整体运行状况。
|
||||
|
||||
从 Kubernetes 1.7 开始，详细的云供应商指标便可用于 GCE、 AWS、Vsphere 和 OpenStack 的存储操作，这些指标可用于监控持久卷运行时的健康状况。
|
||||
|
||||
举例，GCE 的这些指标是这些：
|
||||
|
||||
```
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
<!--
|
||||
* Read about the [Prometheus text format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) for metrics
|
||||
* See the list of [stable Kubernetes metrics](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)
|
||||
* Read about the [Kubernetes deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior )
|
||||
-->
|
||||
|
||||
* 了解有关 [Prometheus 指标相关的文本格式](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)
|
||||
* 查看 [Kubernetes 稳定版指标](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)列表
|
||||
* 了解有关 [Kubernetes 指标弃用策略](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior )
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -36,7 +36,7 @@ systems.
|
||||
## 介绍
|
||||
|
||||
`StorageClass` 为管理员提供了描述存储 `"类"` 的方法。
|
||||
不同的`类型`可能会映射到不同的服务质量等级或备份策略，或是由群集管理员制定的任意策略。
|
||||
不同的`类型`可能会映射到不同的服务质量等级或备份策略，或是由集群管理员制定的任意策略。
|
||||
Kubernetes 本身并不清楚各种`类`代表的什么。这个`类`的概念在其他存储系统中有时被称为"配置文件"。
|
||||
|
||||
<!--
|
||||
@@ -66,8 +66,8 @@ request any particular class to bind to: see the
|
||||
[`PersistentVolumeClaim` section](/docs/concepts/storage/persistent-volumes/#class-1)
|
||||
for details.
|
||||
-->
|
||||
管理员可以为没有申请绑定到特定 `StorageClass` 的 PVC 指定一个默认的`类` ：
|
||||
更多详情请参阅 [`PersistentVolumeClaim` 章节](#persistentvolumeclaims)。
|
||||
管理员可以为没有申请绑定到特定 `StorageClass` 的 PVC 指定一个默认的存储`类` ：
|
||||
更多详情请参阅 [`PersistentVolumeClaim` 章节](/docs/concepts/storage/persistent-volumes/#class-1)。
|
||||
|
||||
```yaml
|
||||
apiVersion: storage.k8s.io/v1
|
||||
@@ -92,13 +92,13 @@ for provisioning PVs. This field must be specified.
|
||||
-->
|
||||
### 存储分配器
|
||||
|
||||
`StorageClass` 有一个分配器，用来决定使用哪个`卷插件`分配`持久化卷申领`。该字段必须指定。
|
||||
`StorageClass` 有一个分配器，用来决定使用哪个`卷插件`分配`PV`。该字段必须指定。
|
||||
|
||||
<!--
|
||||
| Volume Plugin | Internal Provisioner| Config Example |
|
||||
-->
|
||||
|
||||
| 卷插件 | 提供厂商 | 配置例子 |
|
||||
| 卷插件 | 内置分配器 | 配置例子 |
|
||||
| :--- | :---: | :---: |
|
||||
| AWSElasticBlockStore | ✓ | [AWS EBS](#aws-ebs) |
|
||||
| AzureFile | ✓ | [Azure File](#azure-file) |
|
||||
|
||||
@@ -24,18 +24,7 @@ weight: 30
|
||||
This document describes the concept of cloning existing CSI Volumes in Kubernetes. Familiarity with [Volumes](/docs/concepts/storage/volumes) is suggested.
|
||||
-->
|
||||
|
||||
本文档描述 Kubernetes 中克隆现有 CSI 卷的概念。建议先熟悉[卷](/docs/concepts/storage/volumes)。
|
||||
|
||||
<!--
|
||||
This feature requires VolumePVCDataSource feature gate to be enabled:
|
||||
-->
|
||||
|
||||
此功能需要启动 VolumePVCDataSource 功能门：
|
||||
|
||||
```
|
||||
--feature-gates=VolumePVCDataSource=true
|
||||
```
|
||||
|
||||
本文档介绍 Kubernetes 中克隆现有 CSI 卷的概念。阅读前建议先熟悉[卷](/docs/concepts/storage/volumes)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -52,13 +41,13 @@ This feature requires VolumePVCDataSource feature gate to be enabled:
|
||||
The {{< glossary_tooltip text="CSI" term_id="csi" >}} Volume Cloning feature adds support for specifying existing {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}s in the `dataSource` field to indicate a user would like to clone a {{< glossary_tooltip term_id="volume" >}}.
|
||||
-->
|
||||
|
||||
{{< glossary_tooltip text="CSI" term_id="csi" >}} 卷克隆功能增加了在 `dataSource` 字段指定现有的 {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}s，来表示用户想要克隆的 {{< glossary_tooltip term_id="volume" >}}。
|
||||
{{< glossary_tooltip text="CSI" term_id="csi" >}} 卷克隆功能增加了通过在 `dataSource` 字段中指定存在的 {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}s，来表示用户想要克隆的 {{< glossary_tooltip term_id="volume" >}}。
|
||||
|
||||
<!--
|
||||
A Clone is defined as a duplicate of an existing Kubernetes Volume that can be consumed as any standard Volume would be. The only difference is that upon provisioning, rather than creating a "new" empty Volume, the back end device creates an exact duplicate of the specified Volume.
|
||||
-->
|
||||
|
||||
克隆定义为已有 Kubernetes 卷的副本，可以像任何标准卷一样被使用。唯一的区别就是配置后，后端设备将创建指定卷的精确副本，而不是创建一个“新的”空卷。
|
||||
克隆，意思是为已有的 Kubernetes 卷创建副本，它可以像任何其它标准卷一样被使用。唯一的区别就是配置后，后端设备将创建指定完全相同的副本，而不是创建一个“新的”空卷。
|
||||
|
||||
<!--
|
||||
The implementation of cloning, from the perspective of the Kubernetes API simply adds the ability to specify an existing unbound PVC as a dataSource during new pvc creation.
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: 代理
|
||||
id: proxy
|
||||
date: 2019-09-10
|
||||
short_description: >
|
||||
充当客户端和服务器之间的中介的应用程序
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- networking
|
||||
---
|
||||
<!--
|
||||
---
|
||||
title: Proxy
|
||||
id: proxy
|
||||
date: 2019-09-10
|
||||
short_description: >
|
||||
An application acting as an intermediary beween clients and servers
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- networking
|
||||
---
|
||||
-->
|
||||
<!--
|
||||
In computing, a proxy is a server that acts as an intermediary for a remote
|
||||
service.
|
||||
-->
|
||||
在计算机领域，代理指的是充当远程服务中介的服务器。
|
||||
|
||||
|
||||
<!--more-->
|
||||
|
||||
<!--
|
||||
A client interacts with the proxy; the proxy copies the client's data to the
|
||||
actual server; the actual server replies to the proxy; the proxy sends the
|
||||
actual server's reply to the client.
|
||||
-->
|
||||
客户端与代理进行交互；代理将客户端的数据复制到实际服务器；实际服务器回复代理；代理将实际服务器的回复发送给客户端。
|
||||
|
||||
<!--
|
||||
[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) is a
|
||||
network proxy that runs on each node in your cluster, implementing part of
|
||||
the Kubernetes {{< glossary_tooltip term_id="service">}} concept.
|
||||
-->
|
||||
[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) 是集群中每个节点上运行的网络代理，实现了部分 Kubernetes {{< glossary_tooltip term_id="service">}} 概念。
|
||||
|
||||
<!--
|
||||
You can run kube-proxy as a plain userland proxy service. If your operating
|
||||
system supports it, you can instead run kube-proxy in a hybrid mode that
|
||||
achieves the same overall effect using less system resources.
|
||||
-->
|
||||
你可以将 kube-proxy 作为普通的用户态代理服务运行。
|
||||
如果你的操作系统支持，则可以在混合模式下运行 kube-proxy；该模式使用较少的系统资源即可达到相同的总体效果。
|
||||
|
||||
@@ -0,0 +1,285 @@
|
||||
---
|
||||
title: PKI 证书和要求
|
||||
reviewers:
|
||||
- sig-cluster-lifecycle
|
||||
content_template: templates/concept
|
||||
weight: 40
|
||||
---
|
||||
<!--
|
||||
---
|
||||
title: PKI certificates and requirements
|
||||
reviewers:
|
||||
- sig-cluster-lifecycle
|
||||
content_template: templates/concept
|
||||
weight: 40
|
||||
---
|
||||
-->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
Kubernetes requires PKI certificates for authentication over TLS.
|
||||
If you install Kubernetes with [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), the certificates that your cluster requires are automatically generated.
|
||||
You can also generate your own certificates -- for example, to keep your private keys more secure by not storing them on the API server.
|
||||
This page explains the certificates that your cluster requires.
|
||||
-->
|
||||
Kubernetes 需要 PKI 证书才能进行基于 TLS 的身份验证。如果您是使用 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) 安装的 Kubernetes，则会自动生成集群所需的证书。您还可以生成自己的证书。例如，不将私钥存储在 API 服务器上，可以让私钥更加安全。此页面说明了集群必需的证书。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## How certificates are used by your cluster
|
||||
|
||||
Kubernetes requires PKI for the following operations:
|
||||
-->
|
||||
## 集群是如何使用证书的
|
||||
|
||||
Kubernetes 需要 PKI 才能执行以下操作：
|
||||
|
||||
<!--
|
||||
* Client certificates for the kubelet to authenticate to the API server
|
||||
* Server certificate for the API server endpoint
|
||||
* Client certificates for administrators of the cluster to authenticate to the API server
|
||||
* Client certificates for the API server to talk to the kubelets
|
||||
* Client certificate for the API server to talk to etcd
|
||||
* Client certificate/kubeconfig for the controller manager to talk to the API server
|
||||
* Client certificate/kubeconfig for the scheduler to talk to the API server.
|
||||
* Client and server certificates for the [front-proxy][proxy]
|
||||
-->
|
||||
* Kubelet 的客户端证书，用于 API 服务器身份验证
|
||||
* API 服务器端点的证书
|
||||
* 集群管理员的客户端证书，用于 API 服务器身份认证
|
||||
* API 服务器的客户端证书，用于和 Kubelet 的会话
|
||||
* API 服务器的客户端证书，用于和 etcd 的会话
|
||||
* 控制器管理器的客户端证书/kubeconfig，用于和 API server 的会话
|
||||
* 调度器的客户端证书/kubeconfig，用于和 API server 的会话
|
||||
* [前端代理][proxy] 的客户端及服务端证书
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
`front-proxy` certificates are required only if you run kube-proxy to support [an extension API server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/).
|
||||
-->
|
||||
只有当您运行 kube-proxy 并要支持[扩展 API 服务器](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)时，才需要 `front-proxy` 证书
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
etcd also implements mutual TLS to authenticate clients and peers.
|
||||
-->
|
||||
etcd 还实现了双向 TLS 来对客户端和对其他对等节点进行身份验证。
|
||||
|
||||
<!--
|
||||
## Where certificates are stored
|
||||
|
||||
If you install Kubernetes with kubeadm, certificates are stored in `/etc/kubernetes/pki`. All paths in this documentation are relative to that directory.
|
||||
-->
|
||||
## 证书存放的位置
|
||||
|
||||
如果你是通过 kubeadm 安装的 Kubernetes，所有证书都存放在 `/etc/kuberntes/pki` 目录下。本文所有相关的路径都是基于该路径的相对路径。
|
||||
|
||||
<!--
|
||||
## Configure certificates manually
|
||||
|
||||
If you don't want kubeadm to generate the required certificates, you can create them in either of the following ways.
|
||||
-->
|
||||
## 手动配置证书
|
||||
|
||||
如果你不想通过 kubeadm 生成这些必需的证书，你可以通过下面两种方式之一来手动创建他们。
|
||||
|
||||
<!--
|
||||
### Single root CA
|
||||
|
||||
You can create a single root CA, controlled by an administrator. This root CA can then create multiple intermediate CAs, and delegate all further creation to Kubernetes itself.
|
||||
-->
|
||||
### 单根 CA
|
||||
|
||||
你可以创建一个单根 CA，由管理员控制器它。该根 CA 可以创建多个中间 CA，并将所有进一步的创建委托给 Kubernetes。
|
||||
|
||||
<!--
|
||||
Required CAs:
|
||||
|
||||
| 路径 | 默认 CN | 描述 |
|
||||
|------------------------|---------------------------|----------------------------------|
|
||||
| ca.crt,key | kubernetes-ca | Kubernetes general CA |
|
||||
| etcd/ca.crt,key | etcd-ca | For all etcd-related functions |
|
||||
| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | For the [front-end proxy][proxy] |
|
||||
|
||||
On top of the above CAs, it is also necessary to get a public/private key pair for service account management, `sa.key` and `sa.pub`.
|
||||
-->
|
||||
需要这些 CA：
|
||||
|
||||
| 路径 | 默认 CN | 描述 |
|
||||
|------------------------|---------------------------|----------------------------------|
|
||||
| ca.crt,key | kubernetes-ca | Kubernetes 通用 CA |
|
||||
| etcd/ca.crt,key | etcd-ca | 与 etcd 相关的所有功能 |
|
||||
| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | 用于 [前端代理][proxy] |
|
||||
|
||||
上面的 CA 之外，还需要获取用于服务账户管理的密钥对，也就是 `sa.key` 和 `sa.pub`。
|
||||
|
||||
<!--
|
||||
### All certificates
|
||||
|
||||
If you don't wish to copy the CA private keys to your cluster, you can generate all certificates yourself.
|
||||
|
||||
Required certificates:
|
||||
-->
|
||||
### 所有的证书
|
||||
|
||||
如果你不想将 CA 的私钥拷贝至你的集群中，你也可以自己生成全部的证书。
|
||||
|
||||
需要这些证书：
|
||||
|
||||
| 默认 CN | 父级 CA | O (位于 Subject 中) | 类型 | 主机 (SAN) |
|
||||
|-------------------------------|---------------------------|----------------|----------------------------------------|---------------------------------------------|
|
||||
| kube-etcd | etcd-ca | | server, client | `localhost`, `127.0.0.1` |
|
||||
| kube-etcd-peer | etcd-ca | | server, client | `<hostname>`, `<Host_IP>`, `localhost`, `127.0.0.1` |
|
||||
| kube-etcd-healthcheck-client | etcd-ca | | client | |
|
||||
| kube-apiserver-etcd-client | etcd-ca | system:masters | client | |
|
||||
| kube-apiserver | kubernetes-ca | | server | `<hostname>`, `<Host_IP>`, `<advertise_IP>`, `[1]` |
|
||||
| kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | |
|
||||
| front-proxy-client | kubernetes-front-proxy-ca | | client | |
|
||||
|
||||
<!--
|
||||
[1]: any other IP or DNS name you contact your cluster on (as used by [kubeadm][kubeadm] the load balancer stable IP and/or DNS name, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`,
|
||||
`kubernetes.default.svc.cluster`, `kubernetes.default.svc.cluster.local`)
|
||||
|
||||
where `kind` maps to one or more of the [x509 key usage][usage] types:
|
||||
-->
|
||||
[1]: 用来连接到集群的不同 IP 或 DNS 名（就像 [kubeadm][kubeadm] 为负载均衡所使用的固定 IP 或 DNS 名，`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`）
|
||||
|
||||
其中，`kind` 对应一种或多种类型的 [x509 密钥用途][usage]：
|
||||
|
||||
<!--
|
||||
| kind | Key usage |
|
||||
|--------|---------------------------------------------------------------------------------|
|
||||
| server | digital signature, key encipherment, server auth |
|
||||
| client | digital signature, key encipherment, client auth |
|
||||
-->
|
||||
| kind | 密钥用途 |
|
||||
|--------|---------------------------------------------------------------------------------|
|
||||
| server | 数字签名、密钥加密、服务端认证 |
|
||||
| client | 数字签名、密钥加密、客户端认证 |
|
||||
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Hosts/SAN listed above are the recommended ones for getting a working cluster; if required by a specific setup, it is possible to add additional SANs on all the server certificates.
|
||||
-->
|
||||
上面列出的 Hosts/SAN 是推荐的配置方式；如果需要特殊安装，则可以在所有服务器证书上添加其他 SAN。
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
For kubeadm users only:
|
||||
|
||||
* The scenario where you are copying to your cluster CA certificates without private keys is referred as external CA in the kubeadm documentation.
|
||||
* If you are comparing the above list with a kubeadm generated PKI, please be aware that `kube-etcd`, `kube-etcd-peer` and `kube-etcd-healthcheck-client` certificates
|
||||
are not generated in case of external etcd.
|
||||
-->
|
||||
对于 kubeadm 用户：
|
||||
|
||||
* 不使用私钥，将证书复制到集群 CA 的方案，在 kubeadm 文档中将这种方案称为外部 CA。
|
||||
* 如果将以上列表与 kubeadm 生成的 PKI 进行比较，你会注意到，如果使用外部 etcd，则不会生成 `kube-etcd`、`kube-etcd-peer` 和 `kube-etcd-healthcheck-client` 证书。
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Certificate paths
|
||||
|
||||
Certificates should be placed in a recommended path (as used by [kubeadm][kubeadm]). Paths should be specified using the given argument regardless of location.
|
||||
-->
|
||||
### 证书路径
|
||||
|
||||
证书应放置在建议的路径中（以便 [kubeadm][kubeadm]使用）。无论使用什么位置，都应使用给定的参数指定路径。
|
||||
|
||||
| 默认 CN | 建议的密钥路径 | 建议的证书路径 | 命令 | 密钥参数 | 证书参数 |
|
||||
|------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------|
|
||||
| etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | | --etcd-cafile |
|
||||
| kube-apiserver-etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile |
|
||||
| kubernetes-ca | ca.key | ca.crt | kube-apiserver | | --client-ca-file |
|
||||
| kubernetes-ca | ca.key | ca.crt | kube-controller-manager | --cluster-signing-key-file | --client-ca-file, --root-ca-file, --cluster-signing-cert-file |
|
||||
| kube-apiserver | apiserver.key | apiserver.crt | kube-apiserver | --tls-private-key-file | --tls-cert-file |
|
||||
| kube-apiserver-kubelet-client| apiserver-kubelet-client.key | apiserver-kubelet-client.crt| kube-apiserver | --kubelet-client-key | --kubelet-client-certificate |
|
||||
| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | | --requestheader-client-ca-file |
|
||||
| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-controller-manager | | --requestheader-client-ca-file |
|
||||
| front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-key-file | --proxy-client-cert-file |
|
||||
| etcd-ca | etcd/ca.key | etcd/ca.crt | etcd | | --trusted-ca-file, --peer-trusted-ca-file |
|
||||
| kube-etcd | etcd/server.key | etcd/server.crt | etcd | --key-file | --cert-file |
|
||||
| kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | --peer-key-file | --peer-cert-file |
|
||||
| etcd-ca | | etcd/ca.crt | etcdctl | | --cacert |
|
||||
| kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl | --key | --cert |
|
||||
|
||||
<!--
|
||||
Same considerations apply for the service account key pair:
|
||||
-->
|
||||
注意事项同样适用于服务帐户密钥对：
|
||||
|
||||
| 私钥路径 | 公钥路径 | 命令 | 参数 |
|
||||
|------------------------------|-----------------------------|-------------------------|--------------------------------------|
|
||||
| sa.key | | kube-controller-manager | service-account-private |
|
||||
| | sa.pub | kube-apiserver | service-account-key |
|
||||
|
||||
<!--
|
||||
## Configure certificates for user accounts
|
||||
|
||||
You must manually configure these administrator account and service accounts:
|
||||
-->
|
||||
## 为用户帐户配置证书
|
||||
|
||||
您必须手动配置以下管理员帐户和服务帐户：
|
||||
|
||||
| 文件名 | 凭据名称 | 默认 CN | O (位于 Subject 中) |
|
||||
|-------------------------|----------------------------|--------------------------------|----------------|
|
||||
| admin.conf | default-admin | kubernetes-admin | system:masters |
|
||||
| kubelet.conf | default-auth | system:node:`<nodeName>` (see note) | system:nodes |
|
||||
| controller-manager.conf | default-controller-manager | system:kube-controller-manager | |
|
||||
| scheduler.conf | default-scheduler | system:kube-scheduler | |
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The value of `<nodeName>` for `kubelet.conf` **must** match precisely the value of the node name provided by the kubelet as it registers with the apiserver. For further details, read the [Node Authorization](/docs/reference/access-authn-authz/node/).
|
||||
-->
|
||||
`kubelet.conf` 中 `<nodeName>` 的值 **必须** 与 kubelet 向 apiserver 注册时提供的节点名称的值完全匹配。有关更多详细信息，请阅读[节点授权](/docs/reference/access-authn-authz/node/)。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
1. For each config, generate an x509 cert/key pair with the given CN and O.
|
||||
|
||||
1. Run `kubectl` as follows for each config:
|
||||
-->
|
||||
1. 对于每个配置，请都使用给定的 CN 和 O 生成 x509 证书/密钥偶对。
|
||||
|
||||
1. 为每个配置运行下面的 `kubectl` 命令：
|
||||
|
||||
```shell
|
||||
KUBECONFIG=<filename> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <path-to-kubernetes-ca> --embed-certs
|
||||
KUBECONFIG=<filename> kubectl config set-credentials <credential-name> --client-key <path-to-key>.pem --client-certificate <path-to-cert>.pem --embed-certs
|
||||
KUBECONFIG=<filename> kubectl config set-context default-system --cluster default-cluster --user <credential-name>
|
||||
KUBECONFIG=<filename> kubectl config use-context default-system
|
||||
```
|
||||
|
||||
<!--
|
||||
These files are used as follows:
|
||||
|
||||
| filename | command | comment |
|
||||
|-------------------------|-------------------------|-----------------------------------------------------------------------|
|
||||
| admin.conf | kubectl | Configures administrator user for the cluster |
|
||||
| kubelet.conf | kubelet | One required for each node in the cluster. |
|
||||
| controller-manager.conf | kube-controller-manager | Must be added to manifest in `manifests/kube-controller-manager.yaml` |
|
||||
| scheduler.conf | kube-scheduler | Must be added to manifest in `manifests/kube-scheduler.yaml` |
|
||||
-->
|
||||
这些文件用途如下：
|
||||
|
||||
| 文件名 | 命令 | 说明 |
|
||||
|-------------------------|-------------------------|-----------------------------------------------------------------------|
|
||||
| admin.conf | kubectl | 配置集群的管理员 |
|
||||
| kubelet.conf | kubelet | 集群中的每个节点都需要一份 |
|
||||
| controller-manager.conf | kube-controller-manager | 必需添加到 `manifests/kube-controller-manager.yaml` 清单中 |
|
||||
| scheduler.conf | kube-scheduler | 必需添加到 `manifests/kube-scheduler.yaml` 清单中 |
|
||||
|
||||
[usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage
|
||||
[kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/
|
||||
[proxy]: /docs/tasks/access-kubernetes-api/configure-aggregation-layer/
|
||||
|
||||
{{% /capture %}}
|
||||
+28
-28
@@ -196,7 +196,7 @@ kubeadm 包含生成下述证书所需的所有必要的密码学工具；在这
|
||||
如果您还没有 CA，则在 `$HOST0`（您为 kubeadm 生成配置文件的位置）上运行此命令。
|
||||
|
||||
```
|
||||
kubeadm alpha phase certs etcd-ca
|
||||
kubeadm init alpha phase certs etcd-ca
|
||||
```
|
||||
|
||||
<!--
|
||||
@@ -214,25 +214,25 @@ kubeadm 包含生成下述证书所需的所有必要的密码学工具；在这
|
||||
|
||||
<!--
|
||||
```sh
|
||||
kubeadm alpha phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
kubeadm alpha phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
kubeadm alpha phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
kubeadm alpha phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
cp -R /etc/kubernetes/pki /tmp/${HOST2}/
|
||||
# cleanup non-reusable certificates
|
||||
find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
|
||||
|
||||
kubeadm alpha phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
kubeadm alpha phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
kubeadm alpha phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
kubeadm alpha phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
cp -R /etc/kubernetes/pki /tmp/${HOST1}/
|
||||
find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
|
||||
|
||||
kubeadm alpha phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
kubeadm alpha phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
kubeadm alpha phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
kubeadm alpha phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
# No need to move the certs because they are for HOST0
|
||||
|
||||
# clean up certs that should not be copied off this host
|
||||
@@ -241,25 +241,25 @@ kubeadm 包含生成下述证书所需的所有必要的密码学工具；在这
|
||||
```
|
||||
-->
|
||||
```sh
|
||||
kubeadm alpha phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
kubeadm alpha phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
kubeadm alpha phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
kubeadm alpha phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
cp -R /etc/kubernetes/pki /tmp/${HOST2}/
|
||||
# 清理不可重复使用的证书
|
||||
find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
|
||||
|
||||
kubeadm alpha phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
kubeadm alpha phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
kubeadm alpha phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
kubeadm alpha phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
cp -R /etc/kubernetes/pki /tmp/${HOST1}/
|
||||
find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
|
||||
|
||||
kubeadm alpha phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
kubeadm alpha phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
kubeadm alpha phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
kubeadm alpha phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
# 不需要移动 certs 因为它们是给 HOST0 使用的
|
||||
|
||||
# 清理不应从此主机复制的证书
|
||||
@@ -370,9 +370,9 @@ kubeadm 包含生成下述证书所需的所有必要的密码学工具；在这
|
||||
既然证书和配置已经就绪，是时候去创建清单了。在每台主机上运行 `kubeadm` 命令来生成 etcd 使用的静态清单。
|
||||
|
||||
```sh
|
||||
root@HOST0 $ kubeadm alpha phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
root@HOST1 $ kubeadm alpha phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml
|
||||
root@HOST2 $ kubeadm alpha phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml
|
||||
root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
root@HOST1 $ kubeadm init phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml
|
||||
root@HOST2 $ kubeadm init phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
|
||||
@@ -0,0 +1,539 @@
|
||||
---
|
||||
title: 为容器和 Pod 分配内存资源
|
||||
content_template: templates/task
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Assign Memory Resources to Containers and Pods
|
||||
content_template: templates/task
|
||||
weight: 10
|
||||
---
|
||||
-->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
This page shows how to assign a memory *request* and a memory *limit* to a
|
||||
Container. A Container is guaranteed to have as much memory as it requests,
|
||||
but is not allowed to use more memory than its limit.
|
||||
-->
|
||||
此页面显示如何将内存 *请求* （request）和内存 *限制* （limit）分配给一个容器。我们保障容器拥有它请求数量的内存，但不允许使用超过限制数量的内存。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
<!--
|
||||
Each node in your cluster must have at least 300 MiB of memory.
|
||||
-->
|
||||
您集群中的每个节点必须拥有至少 300 MiB 的内存。
|
||||
|
||||
<!--
|
||||
A few of the steps on this page require you to run the
|
||||
[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
|
||||
service in your cluster. If you have the metrics-server
|
||||
running, you can skip those steps.
|
||||
-->
|
||||
该页面上的一些步骤要求您在集群中运行 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 服务。如果您已经有在运行中的 metrics-server，则可以跳过这些步骤。
|
||||
|
||||
<!--
|
||||
If you are running Minikube, run the following command to enable the
|
||||
metrics-server:
|
||||
-->
|
||||
如果您运行的是 Minikube，可以运行下面的命令启用 metrics-server：
|
||||
|
||||
```shell
|
||||
minikube addons enable metrics-server
|
||||
```
|
||||
|
||||
<!--
|
||||
To see whether the metrics-server is running, or another provider of the resource metrics
|
||||
API (`metrics.k8s.io`), run the following command:
|
||||
-->
|
||||
要查看 metrics-server 或资源指标 API (`metrics.k8s.io`) 是否已经运行，请运行以下命令：
|
||||
|
||||
```shell
|
||||
kubectl get apiservices
|
||||
```
|
||||
|
||||
<!--
|
||||
If the resource metrics API is available, the output includes a
|
||||
reference to `metrics.k8s.io`.
|
||||
-->
|
||||
如果资源指标 API 可用，则输出结果将包含对 `metrics.k8s.io` 的引用信息。
|
||||
|
||||
```shell
|
||||
NAME
|
||||
v1beta1.metrics.k8s.io
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!--
|
||||
## Create a namespace
|
||||
|
||||
Create a namespace so that the resources you create in this exercise are
|
||||
isolated from the rest of your cluster.
|
||||
-->
|
||||
## 创建命名空间
|
||||
|
||||
创建一个命名空间，以便将本练习中创建的资源与集群的其余部分隔离。
|
||||
|
||||
```shell
|
||||
kubectl create namespace mem-example
|
||||
```
|
||||
|
||||
<!--
|
||||
## Specify a memory request and a memory limit
|
||||
|
||||
To specify a memory request for a Container, include the `resources:requests` field
|
||||
in the Container's resource manifest. To specify a memory limit, include `resources:limits`.
|
||||
|
||||
In this exercise, you create a Pod that has one Container. The Container has a memory
|
||||
request of 100 MiB and a memory limit of 200 MiB. Here's the configuration file
|
||||
for the Pod:
|
||||
-->
|
||||
## 指定内存请求和限制
|
||||
|
||||
要为容器指定内存请求，请在容器资源清单中包含 `resources：requests` 字段。
|
||||
同理，要指定内存限制，请包含 `resources：limits`。
|
||||
|
||||
在本练习中，您将创建一个拥有一个容器的 Pod。
|
||||
容器将会请求 100 MiB 内存，并且内存会被限制在 200 MiB 以内。
|
||||
这是 Pod 的配置文件：
|
||||
|
||||
{{< codenew file="pods/resource/memory-request-limit.yaml" >}}
|
||||
|
||||
<!--
|
||||
The `args` section in the configuration file provides arguments for the Container when it starts.
|
||||
The `"--vm-bytes", "150M"` arguments tell the Container to attempt to allocate 150 MiB of memory.
|
||||
|
||||
Create the Pod:
|
||||
-->
|
||||
配置文件的 `args` 部分提供了容器启动时的参数。
|
||||
`"--vm-bytes", "150M"` 参数告知容器尝试分配 150 MiB 内存。
|
||||
|
||||
开始创建 Pod：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit.yaml --namespace=mem-example
|
||||
```
|
||||
|
||||
<!--
|
||||
Verify that the Pod Container is running:
|
||||
-->
|
||||
验证 Pod 中的容器是否已运行：
|
||||
|
||||
```shell
|
||||
kubectl get pod memory-demo --namespace=mem-example
|
||||
```
|
||||
|
||||
<!--
|
||||
View detailed information about the Pod:
|
||||
-->
|
||||
查看 Pod 相关的详细信息：
|
||||
|
||||
```shell
|
||||
kubectl get pod memory-demo --output=yaml --namespace=mem-example
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows that the one Container in the Pod has a memory request of 100 MiB
|
||||
and a memory limit of 200 MiB.
|
||||
-->
|
||||
输出结果显示：该 Pod 中容器的内存请求为 100 MiB，内存限制为 200 MiB。
|
||||
|
||||
```yaml
|
||||
...
|
||||
resources:
|
||||
limits:
|
||||
memory: 200Mi
|
||||
requests:
|
||||
memory: 100Mi
|
||||
...
|
||||
```
|
||||
|
||||
<!--
|
||||
Run `kubectl top` to fetch the metrics for the pod:
|
||||
-->
|
||||
运行 `kubectl top` 命令，获取该 Pod 的指标数据：
|
||||
|
||||
```shell
|
||||
kubectl top pod memory-demo --namespace=mem-example
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows that the Pod is using about 162,900,000 bytes of memory, which
|
||||
is about 150 MiB. This is greater than the Pod's 100 MiB request, but within the
|
||||
Pod's 200 MiB limit.
|
||||
-->
|
||||
输出结果显示：Pod 正在使用的内存大约为 162,900,000 字节，约为 150 MiB。
|
||||
这大于 Pod 请求的 100 MiB，但在 Pod 限制的 200 MiB之内。
|
||||
|
||||
```
|
||||
NAME CPU(cores) MEMORY(bytes)
|
||||
memory-demo <something> 162856960
|
||||
```
|
||||
|
||||
<!--
|
||||
Delete your Pod:
|
||||
-->
|
||||
删除 Pod：
|
||||
|
||||
```shell
|
||||
kubectl delete pod memory-demo --namespace=mem-example
|
||||
```
|
||||
|
||||
<!--
|
||||
## Exceed a Container's memory limit
|
||||
|
||||
A Container can exceed its memory request if the Node has memory available. But a Container
|
||||
is not allowed to use more than its memory limit. If a Container allocates more memory than
|
||||
its limit, the Container becomes a candidate for termination. If the Container continues to
|
||||
consume memory beyond its limit, the Container is terminated. If a terminated Container can be
|
||||
restarted, the kubelet restarts it, as with any other type of runtime failure.
|
||||
-->
|
||||
## 超过容器限制的内存
|
||||
|
||||
当节点拥有足够的可用内存时，容器可以使用其请求的内存。但是，容器不允许使用超过其限制的内存。
|
||||
如果容器分配的内存超过其限制，该容器会成为被终止的候选容器。如果容器继续消耗超出其限制的内存，则终止容器。
|
||||
如果终止的容器可以被重启，则 kubelet 会重新启动它，就像其他任何类型的运行时失败一样。
|
||||
|
||||
<!--
|
||||
In this exercise, you create a Pod that attempts to allocate more memory than its limit.
|
||||
Here is the configuration file for a Pod that has one Container with a
|
||||
memory request of 50 MiB and a memory limit of 100 MiB:
|
||||
-->
|
||||
在本练习中，您将创建一个 Pod，尝试分配超出其限制的内存。
|
||||
这是一个 Pod 的配置文件，其拥有一个容器，该容器的内存请求为 50 MiB，内存限制为 100 MiB：
|
||||
|
||||
{{< codenew file="pods/resource/memory-request-limit-2.yaml" >}}
|
||||
|
||||
<!--
|
||||
In the `args` section of the configuration file, you can see that the Container
|
||||
will attempt to allocate 250 MiB of memory, which is well above the 100 MiB limit.
|
||||
|
||||
Create the Pod:
|
||||
-->
|
||||
在配置文件的 `args` 部分中，您可以看到容器会尝试分配 250 MiB 内存，这远高于 100 MiB 的限制。
|
||||
|
||||
创建 Pod：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-2.yaml --namespace=mem-example
|
||||
```
|
||||
|
||||
<!--
|
||||
View detailed information about the Pod:
|
||||
-->
|
||||
查看 Pod 相关的详细信息：
|
||||
|
||||
```shell
|
||||
kubectl get pod memory-demo-2 --namespace=mem-example
|
||||
```
|
||||
<!--
|
||||
At this point, the Container might be running or killed. Repeat the preceding command until the Container is killed:
|
||||
-->
|
||||
此时，容器可能正在运行或被杀死。重复前面的命令，直到容器被杀掉：
|
||||
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
memory-demo-2 0/1 OOMKilled 1 24s
|
||||
```
|
||||
|
||||
<!--
|
||||
Get a more detailed view of the Container status:
|
||||
-->
|
||||
获取容器更详细的状态信息：
|
||||
|
||||
```shell
|
||||
kubectl get pod memory-demo-2 --output=yaml --namespace=mem-example
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows that the Container was killed because it is out of memory (OOM):
|
||||
-->
|
||||
输出结果显示：由于内存溢出（OOM），容器已被杀掉：
|
||||
|
||||
```shell
|
||||
lastState:
|
||||
terminated:
|
||||
containerID: docker://65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f
|
||||
exitCode: 137
|
||||
finishedAt: 2017-06-20T20:52:19Z
|
||||
reason: OOMKilled
|
||||
startedAt: null
|
||||
```
|
||||
|
||||
<!--
|
||||
The Container in this exercise can be restarted, so the kubelet restarts it. Repeat
|
||||
this command several times to see that the Container is repeatedly killed and restarted:
|
||||
-->
|
||||
本练习中的容器可以被重启，所以 kubelet 会重启它。多次运行下面的命令，可以看到容器在反复的被杀死和重启：
|
||||
|
||||
```shell
|
||||
kubectl get pod memory-demo-2 --namespace=mem-example
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows that the Container is killed, restarted, killed again, restarted again, and so on:
|
||||
-->
|
||||
输出结果显示：容器被杀掉、重启、再杀掉、再重启……：
|
||||
|
||||
```
|
||||
kubectl get pod memory-demo-2 --namespace=mem-example
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
memory-demo-2 0/1 OOMKilled 1 37s
|
||||
```
|
||||
```
|
||||
|
||||
kubectl get pod memory-demo-2 --namespace=mem-example
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
memory-demo-2 1/1 Running 2 40s
|
||||
```
|
||||
|
||||
<!--
|
||||
View detailed information about the Pod history:
|
||||
-->
|
||||
查看关于该 Pod 历史的详细信息：
|
||||
|
||||
```
|
||||
kubectl describe pod memory-demo-2 --namespace=mem-example
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows that the Container starts and fails repeatedly:
|
||||
-->
|
||||
输出结果显示：该容器反复的在启动和失败：
|
||||
|
||||
```
|
||||
... Normal Created Created container with id 66a3a20aa7980e61be4922780bf9d24d1a1d8b7395c09861225b0eba1b1f8511
|
||||
... Warning BackOff Back-off restarting failed container
|
||||
```
|
||||
|
||||
<!--
|
||||
View detailed information about your cluster's Nodes:
|
||||
-->
|
||||
查看关于集群节点的详细信息：
|
||||
|
||||
```
|
||||
kubectl describe nodes
|
||||
```
|
||||
|
||||
<!--
|
||||
The output includes a record of the Container being killed because of an out-of-memory condition:
|
||||
-->
|
||||
输出结果包含了一条练习中的容器由于内存溢出而被杀掉的记录：
|
||||
|
||||
```
|
||||
Warning OOMKilling Memory cgroup out of memory: Kill process 4481 (stress) score 1994 or sacrifice child
|
||||
```
|
||||
|
||||
<!--
|
||||
Delete your Pod:
|
||||
-->
|
||||
删除 Pod:
|
||||
|
||||
```shell
|
||||
kubectl delete pod memory-demo-2 --namespace=mem-example
|
||||
```
|
||||
|
||||
<!--
|
||||
## Specify a memory request that is too big for your Nodes
|
||||
|
||||
Memory requests and limits are associated with Containers, but it is useful to think
|
||||
of a Pod as having a memory request and limit. The memory request for the Pod is the
|
||||
sum of the memory requests for all the Containers in the Pod. Likewise, the memory
|
||||
limit for the Pod is the sum of the limits of all the Containers in the Pod.
|
||||
-->
|
||||
## 超过整个节点容量的内存
|
||||
|
||||
内存请求和限制是与容器关联的，但将 Pod 视为具有内存请求和限制，也是很有用的。
|
||||
Pod 的内存请求是 Pod 中所有容器的内存请求之和。
|
||||
同理，Pod 的内存限制是 Pod 中所有容器的内存限制之和。
|
||||
|
||||
<!--
|
||||
Pod scheduling is based on requests. A Pod is scheduled to run on a Node only if the Node
|
||||
has enough available memory to satisfy the Pod's memory request.
|
||||
|
||||
In this exercise, you create a Pod that has a memory request so big that it exceeds the
|
||||
capacity of any Node in your cluster. Here is the configuration file for a Pod that has one
|
||||
Container with a request for 1000 GiB of memory, which likely exceeds the capacity
|
||||
of any Node in your cluster.
|
||||
-->
|
||||
Pod 的调度基于请求。只有当节点拥有足够满足 Pod 内存请求的内存时，才会将 Pod 调度至节点上运行。
|
||||
|
||||
在本练习中，你将创建一个 Pod，其内存请求超过了您集群中的任意一个节点所拥有的内存。
|
||||
这是该 Pod 的配置文件，其拥有一个请求 1000 GiB 内存的容器，这应该超过了您集群中任何节点的容量。
|
||||
|
||||
{{< codenew file="pods/resource/memory-request-limit-3.yaml" >}}
|
||||
|
||||
<!--
|
||||
Create the Pod:
|
||||
-->
|
||||
创建 Pod：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-3.yaml --namespace=mem-example
|
||||
```
|
||||
|
||||
<!--
|
||||
View the Pod status:
|
||||
-->
|
||||
查看 Pod 状态：
|
||||
|
||||
```shell
|
||||
kubectl get pod memory-demo-3 --namespace=mem-example
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows that the Pod status is PENDING. That is, the Pod is not scheduled to run on any Node, and it will remain in the PENDING state indefinitely:
|
||||
-->
|
||||
输出结果显示：Pod 处于 PENDING 状态。这意味着，该 Pod 没有被调度至任何节点上运行，并且它会无限期的保持该状态：
|
||||
|
||||
```
|
||||
kubectl get pod memory-demo-3 --namespace=mem-example
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
memory-demo-3 0/1 Pending 0 25s
|
||||
```
|
||||
|
||||
<!--
|
||||
View detailed information about the Pod, including events:
|
||||
-->
|
||||
查看关于 Pod 的详细信息，包括事件：
|
||||
|
||||
|
||||
```shell
|
||||
kubectl describe pod memory-demo-3 --namespace=mem-example
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows that the Container cannot be scheduled because of insufficient memory on the Nodes:
|
||||
-->
|
||||
输出结果显示：由于节点内存不足，该容器无法被调度：
|
||||
|
||||
```shell
|
||||
Events:
|
||||
... Reason Message
|
||||
------ -------
|
||||
... FailedScheduling No nodes are available that match all of the following predicates:: Insufficient memory (3).
|
||||
```
|
||||
|
||||
<!--
|
||||
## Memory units
|
||||
|
||||
The memory resource is measured in bytes. You can express memory as a plain integer or a
|
||||
fixed-point integer with one of these suffixes: E, P, T, G, M, K, Ei, Pi, Ti, Gi, Mi, Ki.
|
||||
For example, the following represent approximately the same value:
|
||||
-->
|
||||
## 内存单位
|
||||
|
||||
内存资源的基本单位是字节（byte）。您可以使用这些后缀之一，将内存表示为纯整数或定点整数：E、P、T、G、M、K、Ei、Pi、Ti、Gi、Mi、Ki。例如，下面是一些近似相同的值：
|
||||
|
||||
```shell
|
||||
128974848, 129e6, 129M , 123Mi
|
||||
```
|
||||
|
||||
<!--
|
||||
Delete your Pod:
|
||||
-->
|
||||
删除 Pod：
|
||||
|
||||
```shell
|
||||
kubectl delete pod memory-demo-3 --namespace=mem-example
|
||||
```
|
||||
|
||||
<!--
|
||||
## If you do not specify a memory limit
|
||||
|
||||
If you do not specify a memory limit for a Container, one of the following situations applies:
|
||||
-->
|
||||
## 如果你没有指定内存限制
|
||||
|
||||
如果你没有为一个容器指定内存限制，则自动遵循以下情况之一：
|
||||
|
||||
<!--
|
||||
* The Container has no upper bound on the amount of memory it uses. The Container
|
||||
could use all of the memory available on the Node where it is running which in turn could invoke the OOM Killer. Further, in case of an OOM Kill, a container with no resource limits will have a greater chance of being killed.
|
||||
|
||||
* The Container is running in a namespace that has a default memory limit, and the
|
||||
Container is automatically assigned the default limit. Cluster administrators can use a
|
||||
[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
|
||||
to specify a default value for the memory limit.
|
||||
-->
|
||||
* 容器可无限制地使用内存。容器可以使用其所在节点所有的可用内存，进而可能导致该节点调用 OOM Killer。
|
||||
此外，如果发生 OOM Kill，没有资源限制的容器将被杀掉的可行性更大。
|
||||
|
||||
* 运行的容器所在命名空间有默认的内存限制，那么该容器会被自动分配默认限制。
|
||||
集群管理员可用使用 [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
|
||||
来指定默认的内存限制。
|
||||
|
||||
<!--
|
||||
## Motivation for memory requests and limits
|
||||
|
||||
By configuring memory requests and limits for the Containers that run in your
|
||||
cluster, you can make efficient use of the memory resources available on your cluster's
|
||||
Nodes. By keeping a Pod's memory request low, you give the Pod a good chance of being
|
||||
scheduled. By having a memory limit that is greater than the memory request, you accomplish two things:
|
||||
-->
|
||||
## 内存请求和限制的目的
|
||||
|
||||
通过为集群中运行的容器配置内存请求和限制，您可以有效利用集群节点上可用的内存资源。通过将 Pod 的内存请求保持在较低水平，您可以更好地安排 Pod 调度。通过让内存限制大于内存请求，您可以完成两件事：
|
||||
|
||||
<!--
|
||||
* The Pod can have bursts of activity where it makes use of memory that happens to be available.
|
||||
* The amount of memory a Pod can use during a burst is limited to some reasonable amount.
|
||||
-->
|
||||
* Pod 可以进行一些突发活动，从而更好的利用可用内存。
|
||||
* Pod 在突发活动期间，可使用的内存被限制为合理的数量。
|
||||
|
||||
<!--
|
||||
## Clean up
|
||||
|
||||
Delete your namespace. This deletes all the Pods that you created for this task:
|
||||
-->
|
||||
## 清理
|
||||
|
||||
删除命名空间。下面的命令会删除你根据这个任务创建的所有 Pod：
|
||||
|
||||
```shell
|
||||
kubectl delete namespace mem-example
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
### 应用开发者扩展阅读
|
||||
|
||||
* [为容器和 Pod 分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
* [配置 Pod 的服务质量](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
### 集群管理员扩展阅读
|
||||
|
||||
* [为命名空间配置默认的内存请求和限制](/docs/tasks/administer-cluster/memory-default-namespace/)
|
||||
|
||||
* [为命名空间配置默认的 CPU 请求和限制](/docs/tasks/administer-cluster/cpu-default-namespace/)
|
||||
|
||||
* [配置命名空间的最小和最大内存约束](/docs/tasks/administer-cluster/memory-constraint-namespace/)
|
||||
|
||||
* [配置命名空间的最小和最大 CPU 约束](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
|
||||
|
||||
* [为命名空间配置内存和 CPU 配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
|
||||
|
||||
* [配置命名空间下 Pod 总数](/docs/tasks/administer-cluster/quota-pod-namespace/)
|
||||
|
||||
* [配置 API 对象配额](/docs/tasks/administer-cluster/quota-api-object/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -74,9 +74,16 @@ For example: -->
|
||||
|
||||
例如：
|
||||
|
||||
# Create the local directory
|
||||
<!-- # Create the local directory
|
||||
mkdir -p configure-pod-container/configmap/
|
||||
|
||||
# Download the sample files into `configure-pod-container/configmap/` directory
|
||||
wget https://kubernetes.io/examples/configmap/game.properties -O configure-pod-container/configmap/game.properties
|
||||
wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-container/configmap/ui.properties
|
||||
|
||||
# Create the configmap
|
||||
kubectl create configmap game-config --from-file=configure-pod-container/configmap/ -->
|
||||
|
||||
```shell
|
||||
# 创建本地目录
|
||||
mkdir -p configure-pod-container/configmap/
|
||||
@@ -242,7 +249,7 @@ allowed="true" -->
|
||||
# env 文件中的每一行必须为 VAR = VAL 格式。
|
||||
# 以＃开头的行(即注释)将被忽略。
|
||||
# 空行将被忽略。
|
||||
# 引号没有特殊处理(即它们将成为 ConfigMap 值的一部分)。
|
||||
# 引号没有特殊处理(即它们将成为 ConfigMap 值的一部分)。
|
||||
|
||||
# 将样本文件下载到 `configure-pod-container/configmap/` 目录
|
||||
wget https://kubernetes.io/examples/configmap/game-env-file.properties -O configure-pod-container/configmap/game-env-file.properties
|
||||
@@ -527,6 +534,7 @@ configmap/game-config-5-m67dt67794 created
|
||||
<!-- To generate a ConfigMap from literals `special.type=charm` and `special.how=very`,
|
||||
you can specify the ConfigMap generator in `kusotmization.yaml` as -->
|
||||
要从文字 `special.type=charm` 和 `special.how=very` 生成 ConfigMap，可以在 `kusotmization.yaml` 中将 ConfigMap 生成器指定。
|
||||
|
||||
<!-- ```shell
|
||||
# Create a kustomization.yaml file with ConfigMapGenerator
|
||||
cat <<EOF >./kustomization.yaml
|
||||
@@ -537,6 +545,7 @@ configMapGenerator:
|
||||
- special.type=charm
|
||||
EOF
|
||||
``` -->
|
||||
|
||||
```shell
|
||||
# 使用 ConfigMapGenerator 创建 kustomization.yaml 文件
|
||||
cat <<EOF >./kustomization.yaml
|
||||
|
||||
+2
-2
@@ -31,7 +31,7 @@ content_template: templates/task
|
||||
|
||||
在这个练习中，你将创建一个包含一个容器的pod。这是该pod的配置文件：
|
||||
|
||||
{{< codenew file="pods/inject/dapi-volume-resources.yaml" >}}
|
||||
{{< codenew file="pods/inject/dapi-volume.yaml" >}}
|
||||
|
||||
在配置文件中，你可以看到Pod有一个`downwardAPI`类型的Volume，并且挂载到容器中的`/etc`。
|
||||
|
||||
@@ -148,7 +148,7 @@ drwxrwxrwt 3 root root 120 Dec 5 07:00 ..
|
||||
|
||||
前面的练习中，你将Pod字段保存到DownwardAPIVolumeFile中。接下来这个练习，你将存储容器字段。这里是包含一个容器的pod的配置文件：
|
||||
|
||||
{{< codenew file="pods/inject/dapi-volume.yaml" >}}
|
||||
{{< codenew file="pods/inject/dapi-volume-resources.yaml" >}}
|
||||
|
||||
在这个配置文件中，你可以看到Pod有一个`downwardAPI`类型的Volume,并且挂载到容器的`/etc`目录。
|
||||
|
||||
|
||||
@@ -249,11 +249,11 @@ Example label:
|
||||
```yaml
|
||||
selector:
|
||||
matchLabels:
|
||||
controller-selector: "extensions/v1beta1/deployment/nginx"
|
||||
controller-selector: "apps/v1/deployment/nginx"
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
controller-selector: "extensions/v1beta1/deployment/nginx"
|
||||
controller-selector: "apps/v1/deployment/nginx"
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
Reference in New Issue
Block a user