k8smeetup-shirdrn-pr-2017-8-15 (#5376)
* Chinese translation: 7.24-9.3, by shirdrn. * Translate and review again, and fix any translation problems for these 14 docs. * Delete network-policies.md temporarily, and then re-submit it for this PR.
This commit is contained in:
Dean Shi
@@ -0,0 +1,259 @@
|
||||
---
|
||||
assignees:
|
||||
- derekwaynecarr
|
||||
- janetkuo
|
||||
title: 设置 Pod CPU 和内存限制
|
||||
redirect_from:
|
||||
- "/docs/admin/limitrange/"
|
||||
- "/docs/admin/limitrange/index.html"
|
||||
- "/docs/tasks/configure-pod-container/limit-range/"
|
||||
- "/docs/tasks/configure-pod-container/limit-range.html"
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
|
||||
|
||||
默认情况下，Pod 运行没有限制 CPU 和内存。
|
||||
这意味着系统中的任何 Pod 将能够像执行该 Pod 所在的节点一样，使用足够多 CPU 和内存。
|
||||
|
||||
|
||||
|
||||
这个例子演示了如何限制 Kubernetes [Namespace](/docs/tasks/administer-cluster/namespaces-walkthrough/)，以此来控制每个 Pod 的最小/最大资源限额。
|
||||
另外，这个例子演示了当终端用户没有为 Pod 设置资源限额时，如何使用默认的资源限额。
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture prerequisites %}
|
||||
|
||||
* {% include task-tutorial-prereqs.md %}
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture steps %}
|
||||
|
||||
|
||||
|
||||
## 创建 Namespace
|
||||
|
||||
这个例子将使用一个自定义的 Namespace 来演示相关的概念。
|
||||
|
||||
让我们创建一个名称为 limit-example 的 Namespace：
|
||||
|
||||
```shell
|
||||
$ kubectl create namespace limit-example
|
||||
namespace "limit-example" created
|
||||
```
|
||||
|
||||
|
||||
|
||||
注意到 `kubectl` 命令将打印出被创建或修改的资源的类型和名称，也会在后面的命令中使用到：
|
||||
|
||||
```shell
|
||||
$ kubectl get namespaces
|
||||
NAME STATUS AGE
|
||||
default Active 51s
|
||||
limit-example Active 45s
|
||||
```
|
||||
|
||||
|
||||
|
||||
## 对 Namespace 应用限制
|
||||
|
||||
在我们的 Namespace 中创建一个简单的限制：
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/limits.yaml --namespace=limit-example
|
||||
limitrange "mylimits" created
|
||||
```
|
||||
|
||||
|
||||
|
||||
让我们描述一下在该 Namespace 中被强加的限制：
|
||||
|
||||
```shell
|
||||
$ kubectl describe limits mylimits --namespace=limit-example
|
||||
Name: mylimits
|
||||
Namespace: limit-example
|
||||
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
|
||||
---- -------- --- --- --------------- ------------- -----------------------
|
||||
Pod cpu 200m 2 - - -
|
||||
Pod memory 6Mi 1Gi - - -
|
||||
Container cpu 100m 2 200m 300m -
|
||||
Container memory 3Mi 1Gi 100Mi 200Mi -
|
||||
```
|
||||
|
||||
|
||||
|
||||
在这个场景下，指定了如下限制：
|
||||
|
||||
1. 如果一个资源被指定了最大约束（在该例子中为 2 CPU 和 1Gi 内存），则必须为跨所有容器的该资源指定限制（limits）。
|
||||
当尝试创建该 Pod 时，指定限额失败将导致一个验证错误。
|
||||
注意，一个默认的限额通过在 `limits.yaml` 文件中的 *default* 来设置（300m CPU 和 200Mi 内存）。
|
||||
2. 如果一个资源被指定了最小约束（在该例子中为 100m CPU 和 3Mi 内存），则必须跨所有容器的该资源指定请求（requests）。
|
||||
当尝试创建该 Pod 时，指定的请求失败将导致一个验证错误。
|
||||
注意，一个默认的请求的值通过在 `limits.yaml` 文件中的 *defaultRequest* 来设置（200m CPU 和 100Mi 内存）。
|
||||
3. 对任意 Pod，所有容器内存 requests 值之和必须 >= 6Mi，所有容器内存 limits 值之和必须 <= 1Gi；
|
||||
所有容器 CPU requests 值之和必须 >= 200m，所有容器 CPU limits 值之和必须 <= 2。
|
||||
|
||||
|
||||
|
||||
## 创建时强制设置限制
|
||||
|
||||
当集群中的 Pod 创建和更新时，在一个 Namespace 中列出的限额是强制设置的。
|
||||
如果将该限额修改成一个不同的值范围，它不会影响先前在该 Namespace 中创建的 Pod。
|
||||
|
||||
|
||||
|
||||
如果资源（CPU 或内存）被设置限额，用户将在创建时得到一个错误，并指出了错误的原因。
|
||||
|
||||
首先让我们启动一个 [Deployment](/docs/concepts/workloads/controllers/deployment/)，它创建一个单容器 Pod，演示了如何将默认值应用到每个 Pod 上：
|
||||
|
||||
```shell
|
||||
$ kubectl run nginx --image=nginx --replicas=1 --namespace=limit-example
|
||||
deployment "nginx" created
|
||||
```
|
||||
|
||||
|
||||
注意，在 >= v1.2 版本的 Kubernetes 集群中，`kubectl run` 创建了名称为 “nginx” 的 Deployment。如果在老版本的集群上运行，相反它会创建 ReplicationController。
|
||||
如果想要获取老版本的行为，使用 `--generator=run/v1` 选项来创建 ReplicationController。查看 [`kubectl run`](/docs/user-guide/kubectl/v1.6/#run) 获取更多详细信息。
|
||||
Deployment 管理单容器 Pod 的 1 个副本。让我们看一下它是如何管理 Pod 的。首先，查找到 Pod 的名称：
|
||||
|
||||
```shell
|
||||
$ kubectl get pods --namespace=limit-example
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-2040093540-s8vzu 1/1 Running 0 11s
|
||||
```
|
||||
|
||||
|
||||
|
||||
以 yaml 输出格式来打印这个 Pod，然后 `grep` 其中的 `resources` 字段。注意，您自己的 Pod 的名称将不同于上面输出的：
|
||||
|
||||
```shell
|
||||
$ kubectl get pods nginx-2040093540-s8vzu --namespace=limit-example -o yaml | grep resources -C 8
|
||||
resourceVersion: "57"
|
||||
selfLink: /api/v1/namespaces/limit-example/pods/nginx-2040093540-ivimu
|
||||
uid: 67b20741-f53b-11e5-b066-64510658e388
|
||||
spec:
|
||||
containers:
|
||||
- image: nginx
|
||||
imagePullPolicy: Always
|
||||
name: nginx
|
||||
resources:
|
||||
limits:
|
||||
cpu: 300m
|
||||
memory: 200Mi
|
||||
requests:
|
||||
cpu: 200m
|
||||
memory: 100Mi
|
||||
terminationMessagePath: /dev/termination-log
|
||||
volumeMounts:
|
||||
```
|
||||
|
||||
|
||||
|
||||
注意，我们的 Nginx 容器已经使用了 Namespace 的默认 CPU 和内存资源的 *limits* 和 *requests*。
|
||||
|
||||
让我们创建一个 Pod，它具有一个请求 3 CPU 核心的容器，这超过了被允许的限额：
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/invalid-pod.yaml --namespace=limit-example
|
||||
Error from server: error when creating "http://k8s.io/docs/tasks/configure-pod-container/invalid-pod.yaml": Pod "invalid-pod" is forbidden: [Maximum cpu usage per Pod is 2, but limit is 3., Maximum cpu usage per Container is 2, but limit is 3.]
|
||||
```
|
||||
|
||||
|
||||
|
||||
让我们创建一个 Pod，使它在允许的最大限额范围之内：
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/valid-pod.yaml --namespace=limit-example
|
||||
pod "valid-pod" created
|
||||
```
|
||||
|
||||
|
||||
|
||||
现在查看该 Pod 的 resources 字段：
|
||||
|
||||
```shell
|
||||
$ kubectl get pods valid-pod --namespace=limit-example -o yaml | grep -C 6 resources
|
||||
uid: 3b1bfd7a-f53c-11e5-b066-64510658e388
|
||||
spec:
|
||||
containers:
|
||||
- image: gcr.io/google_containers/serve_hostname
|
||||
imagePullPolicy: Always
|
||||
name: kubernetes-serve-hostname
|
||||
resources:
|
||||
limits:
|
||||
cpu: "1"
|
||||
memory: 512Mi
|
||||
requests:
|
||||
cpu: "1"
|
||||
memory: 512Mi
|
||||
```
|
||||
|
||||
|
||||
|
||||
注意到这个 Pod 显式地指定了资源 *limits* 和 *requests*，所以它不会使用该 Namespace 的默认值。
|
||||
|
||||
注意：在物理节点上默认安装的 Kubernetes 集群中，CPU 资源的 *limits* 是被强制使用的，该 Kubernetes 集群运行容器，除非管理员在部署 kublet 时使用了如下标志：
|
||||
|
||||
```shell
|
||||
$ kubelet --help
|
||||
Usage of kubelet
|
||||
....
|
||||
--cpu-cfs-quota[=true]: Enable CPU CFS quota enforcement for containers that specify CPU limits
|
||||
$ kubelet --cpu-cfs-quota=false ...
|
||||
```
|
||||
|
||||
|
||||
|
||||
## 清理
|
||||
|
||||
基于使用的该示例来清理资源，可以通过如下命令删除名称为 limit-example 的 Namespace：
|
||||
|
||||
```shell
|
||||
$ kubectl delete namespace limit-example
|
||||
namespace "limit-example" deleted
|
||||
$ kubectl get namespaces
|
||||
NAME STATUS AGE
|
||||
default Active 12m
|
||||
```
|
||||
{% endcapture %}
|
||||
|
||||
{% capture discussion %}
|
||||
|
||||
|
||||
## 设置资限额制的动机
|
||||
|
||||
可能由于对资源使用的各种原因，用户希望对单个 Pod 的资源总量进行强制限制。
|
||||
|
||||
例如：
|
||||
|
||||
|
||||
|
||||
1. 集群中每个节点有 2GB 内存。集群操作员不想接受内存需求大于 2GB 的 Pod，因为集群中没有节点能支持这个要求。
|
||||
为了避免 Pod 永远无法被调度到集群中的节点上，操作员会选择去拒绝超过 2GB 内存作为许可控制的 Pod。
|
||||
2. 一个集群被一个组织内部的 2 个团体共享，分别作为生产和开发工作负载来运行。
|
||||
生产工作负载可能消耗多达 8GB 内存，而开发工作负载可能消耗 512MB 内存。
|
||||
集群操作员为每个工作负载创建了一个单独的 Namespace，为每个 Namespace 设置了限额。
|
||||
3. 用户会可能创建一个资源消耗低于机器容量的 Pod。剩余的空间可能太小但很有用，然而对于整个集群来说浪费的代价是足够大的。
|
||||
结果集群操作员会希望设置限额：为了统一调度和限制浪费，Pod 必须至少消耗它们平均节点大小 20% 的内存和 CPU。
|
||||
|
||||
|
||||
|
||||
## 总结
|
||||
|
||||
想要限制单个容器或 Pod 消耗资源总量的集群操作员，能够为每个 Kubernetes Namespace 定义可允许的范围。
|
||||
在没有任何明确指派的情况下，Kubernetes 系统能够使用默认的资源 *limits* 和 *requests*，如果需要的话，限制一个节点上的 Pod 的资源总量。
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
|
||||
* 查看 [LimitRange 设计文档](https://git.k8s.io/community/contributors/design-proposals/admission_control_limit_range.md) 获取更多信息。
|
||||
* 查看 [资源](/docs/concepts/configuration/manage-compute-resources-container/) 获取关于 Kubernetes 资源模型的详细描述。
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/task.md %}
|
||||
@@ -0,0 +1,161 @@
|
||||
---
|
||||
approvers:
|
||||
- bowei
|
||||
- zihongz
|
||||
title: 在 Kubernetes 中配置私有 DNS 和上游域名服务器
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
本页展示了如何添加自定义私有 DNS 域（存根域）和上游域名服务器。
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture prerequisites %}
|
||||
* {% include task-tutorial-prereqs.md %}
|
||||
|
||||
|
||||
|
||||
* Kubernetes 1.6 及其以上版本。
|
||||
* 集群必须配置使用 `kube-dns` 插件。
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture steps %}
|
||||
|
||||
|
||||
|
||||
## 配置存根域和上游 DNS 服务器
|
||||
|
||||
通过为 kube-dns （`kube-system:kube-dns`）提供 ConfigMap，集群管理员能够指定自定义存根域和上游域名服务器。
|
||||
|
||||
例如，下面的 ConfigMap 建立了一个 DNS 配置，它具有一个单独的存根域和两个上游域名服务器：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: kube-dns
|
||||
namespace: kube-system
|
||||
data:
|
||||
stubDomains: |
|
||||
{“acme.local”: [“1.2.3.4”]}
|
||||
upstreamNameservers: |
|
||||
[“8.8.8.8”, “8.8.4.4”]
|
||||
```
|
||||
|
||||
|
||||
|
||||
按如上说明，具有 “.acme.local” 后缀的 DNS 请求被转发到 DNS 1.2.3.4。Google 公共 DNS服务器 为上游查询提供服务。
|
||||
下表描述了具有特定域名的查询如何映射到它们的目标 DNS 服务器：
|
||||
|
||||
|
||||
| 域名 | 响应查询的服务器 |
|
||||
| ----------- | -------------------------- |
|
||||
| kubernetes.default.svc.cluster.local| kube-dns |
|
||||
| foo.acme.local| 自定义 DNS (1.2.3.4) |
|
||||
| widget.com | 上游 DNS (8.8.8.8, 8.8.4.4，其中之一) |
|
||||
|
||||
|
||||
查看 [ConfigMap 选项](#configmap-options) 获取更多关于配置选项格式的详细信息。
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture discussion %}
|
||||
|
||||
|
||||
|
||||
## 理解 Kubernetes 中名字解析
|
||||
|
||||
可以为每个 Pod 设置 DNS 策略。
|
||||
当前 Kubernetes 支持两种 Pod 特定的 DNS 策略：“Default” 和 “ClusterFirst”。
|
||||
可以通过 `dnsPolicy` 标志来指定这些策略。
|
||||
*注意：“Default” 不是默认的 DNS 策略。如果没有显式地指定 `dnsPolicy`，将会使用 “ClusterFirst”。*
|
||||
|
||||
|
||||
|
||||
### "Default" DNS 策略
|
||||
|
||||
如果 `dnsPolicy` 被设置为 “Default”，则名字解析配置会继承自 Pod 运行所在的节点。
|
||||
自定义上游域名服务器和存根域不能够与这个策略一起使用。
|
||||
|
||||
|
||||
|
||||
### "ClusterFirst" DNS 策略
|
||||
|
||||
如果 `dnsPolicy` 被设置为 "ClusterFirst"，处理名字解析有所不同，*依赖于是否配置了存根域和上游 DNS 服务器*。
|
||||
|
||||
**未进行自定义配置**：没有匹配上配置的集群域名后缀的任何请求，例如 “www.kubernetes.io”，将会被转发到继承自节点的上游域名服务器。
|
||||
|
||||
**进行自定义配置**：如果配置了存根域和上游 DNS 服务器（类似于 [前面示例](#configuring-stub-domain-and-upstream-dns-servers) 配置的内容），DNS 查询将基于下面的流程对请求进行路由：
|
||||
|
||||
|
||||
|
||||
1. 查询首先被发送到 kube-dns 中的 DNS 缓存层。
|
||||
|
||||
1. 从缓存层，检查请求的后缀，并根据下面的情况转发到对应的 DNS 上：
|
||||
|
||||
* *具有集群后缀的名字*（例如 ".cluster.local"）：请求被发送到 kube-dns。
|
||||
|
||||
* *具有存根域后缀的名字*（例如 ".acme.local"）：请求被发送到配置的自定义 DNS 解析器（例如：监听在 1.2.3.4）。
|
||||
|
||||
* *未能匹配上后缀的名字*（例如 "widget.com"）：请求被转发到上游 DNS（例如：Google 公共 DNS 服务器，8.8.8.8 和 8.8.4.4）。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## ConfigMap 选项
|
||||
|
||||
kube-dns `kube-system:kube-dns` 对应的 ConfigMap 选项如下所示：
|
||||
|
||||
| 字段 | 格式 | 描述 |
|
||||
| ----- | ------ | ----------- |
|
||||
| `stubDomains`（可选）| 使用 DNS 后缀作为键（例如 “acme.local”）的 JSON map，以及由 DNS IP 的 JSON 数组组成的值。 | 目标域名服务器可能是一个 Kubernetes Service。例如，可以运行自己的 dnsmasq 副本，将 DNS 名字暴露到 ClusterDNS namespace 中。|
|
||||
| `upstreamNameservers`（可选）| DNS IP 的 JSON 数组。 | 注意：如果指定，则指定的值会替换掉被默认从节点的 `/etc/resolv.conf` 中获取到的域名服务器。限制：最多可以指定三个上游域名服务器。|
|
||||
|
||||
|
||||
|
||||
## 附加示例
|
||||
|
||||
### 示例：存根域
|
||||
|
||||
在这个例子中，用户有一个 Consul DNS 服务发现系统，他们希望能够与 kube-dns 集成起来。
|
||||
Consul 域名服务器地址为 10.150.0.1，所有的 Consul 名字具有后缀 “.consul.local”。
|
||||
要配置 Kubernetes，集群管理员只需要简单地创建一个 ConfigMap 对象，如下所示：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: kube-dns
|
||||
namespace: kube-system
|
||||
data:
|
||||
stubDomains: |
|
||||
{“consul.local”: [“10.150.0.1”]}
|
||||
```
|
||||
|
||||
|
||||
注意，集群管理员不希望覆盖节点的上游域名服务器，所以他们不会指定可选的 `upstreamNameservers` 字段。
|
||||
|
||||
|
||||
|
||||
### 示例：上游域名服务器
|
||||
|
||||
在这个示例中，集群管理员不希望显式地强制所有非集群 DNS 查询进入到他们自己的域名服务器 172.16.0.1。
|
||||
而且这很容易实现：他们只需要创建一个 ConfigMap，`upstreamNameservers` 字段指定期望的域名服务器即可：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: kube-dns
|
||||
namespace: kube-system
|
||||
data:
|
||||
upstreamNameservers: |
|
||||
[“172.16.0.1”]
|
||||
```
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/task.md %}
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
approvers:
|
||||
- davidopp
|
||||
- filipg
|
||||
- piosz
|
||||
title: 关键插件 Pod 的调度保证
|
||||
---
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
|
||||
|
||||
## 概览
|
||||
|
||||
除了 Kubernetes 核心组件，像运行在 master 机器上的 api-server、scheduler、controller-manager，由于各种原因，还有很多插件必须运行在一个普通的集群节点上（而不是 Kubernetes master）。
|
||||
这些插件中的一些对于一个功能完备的集群来说是非常关键的，例如 Heapster、DNS 以及 UI。
|
||||
如果一个关键的插件被移除（或者手动，或是类似升级这样具有副作用的其它操作），或者变成挂起状态（例如，当集群利用率过高，以及或者其它被调度到该空间中的挂起 Pod 被清理关键插件 Pod 给移除，或者由于其它原因导致节点上可用资源的总量发生变化），集群可能会停止正常工作。
|
||||
|
||||
|
||||
|
||||
## 二次调度器：关键插件的调度保证
|
||||
|
||||
二次调度器确保关键的插件总是能被调度（假定普通的 Pod 不存在时，集群具有足够的资源去运行关键插件 Pod）。
|
||||
如果调度器确定没有节点有足够资源去运行关键插件 Pod，假使有 Pod 已经运行在集群中（通过将关键插件 Pod 的条件 PodScheduled 设置为 false，原因设置为 Unschedulable 来指示），这时二次调度器通过清理一些 Pod 尽量去释放空间，然后调度器将调度该插件 Pod。
|
||||
|
||||
|
||||
|
||||
为了避免这种情况，当另一个 Pod 被调度到该空间，为了该关键插件，被选择的节点导致临时变成 "CriticalAddonsOnly" 的 taint（查看 [更多详情](https://git.k8s.io/community/contributors/design-proposals/taint-toleration-dedicated.md)）。
|
||||
每个关键插件不得不容忍它，然而其它一些 Pod 不可能容忍该 taint。一旦该插件被成功调度，该 taint 会被移除。
|
||||
|
||||
*警告：* 当前对选中哪个节点，以及为了调度该关键 Pod 杀掉哪个 Pod 并没有任何保证，所以如果启用了二次调度器，任何 Pod 都可能被偶然的杀掉以达到目的。
|
||||
|
||||
|
||||
|
||||
## 配置
|
||||
|
||||
二次调度器应该被 [作为 static Pod 默认启用](https://git.k8s.io/kubernetes/cluster/saltbase/salt/rescheduler/rescheduler.manifest)。
|
||||
它没有任何面向用户的配置（组件配置），或者 API，可以通过如下方式来禁用：
|
||||
|
||||
|
||||
|
||||
* 在集群安装过程中通过设置 `ENABLE_RESCHEDULER` 标志为 `false`
|
||||
* 在运行中的集群中从 master 节点删除它的 manifest（默认路径 `/etc/kubernetes/manifests/rescheduler.manifest`）
|
||||
|
||||
|
||||
|
||||
### 标记关键插件
|
||||
|
||||
想变成关键插件，必须运行在 `kube-system` Namespace 中（是基于标志可配置的），并且：
|
||||
* 将 `scheduler.alpha.kubernetes.io/critical-pod` annotation 设置为空字符串，并且
|
||||
* 将 PodSpec 的 `tolerations` 字段设置为 `[{"key":"CriticalAddonsOnly", "operator":"Exists"}]`
|
||||
|
||||
第一个表示是一个关键 Pod。第二个是二次调度器算法必需的。
|
||||
|
||||
Reference in New Issue
Block a user