translation | 伪架构师

针对资源紧缺处理方式的配置

Thu, 01 Jun 2017 19:25:48 +0800

如何在资源紧缺的情况下，保证 Node 的稳定性，是 Kubelet 需要面对的一个重要的问题。尤其对于内存和磁盘这种不可压缩的资源，紧缺就相当于不稳定。

驱逐策略

Kubelet 能够监控资源消耗，来防止计算资源被耗尽。一旦出现资源紧缺的迹象，Kubelet 就会主动终止一或多个 Pod 的运行，以回收紧俏资源。当一个 Pod 被终止时，其中的容器会全部停止，Pod 状态会被置为 Failed。

驱逐信号

下文中提到了一些信号，kubelet 能够利用这些信号作为决策依据来触发驱逐行为。描述列中的内容来自于 Kubelet summary API。

驱逐信号	描述
memory.available	memory.available := node.status.capacity[memory] - node.stats.memory.workingSet
nodefs.available	nodefs.available := node.stats.fs.available
nodefs.inodesFree	nodefs.inodesFree := node.stats.fs.inodesFree
imagefs.available	imagefs.available := node.stats.runtime.imagefs.available
imagefs.inodesFree	imagefs.inodesFree := node.stats.runtime.imagefs.inodesFree

上面的每个信号都支持整数值或者百分比。百分比的分母部分就是各个信号的总量。kubelet 支持两种文件系统分区。

nodefs：保存 kubelet 的卷和守护进程日志等。
imagefs：在容器运行时，用于保存镜像以及可写入层。

imagefs 是可选的。Kubelet 能够利用 cAdvisor 自动发现这些文件系统。Kubelet 不关注其他的文件系统。所有其他类型的配置，例如保存在独立文件系统的卷和日志，都不被支持。

因为磁盘压力已经被驱逐策略接管，因此未来将会停止对现有垃圾收集方式的支持。

驱逐阈（yù，音同“预”）值：

一旦超出阈值，就会触发 kubelet 进行资源回收的动作。阈值的定义方式如下：

<eviction-signal><operator><quantity>

上面的表格中列出了可用的 eviction-signal.
仅有一个 operator 可用：<
quantity 需要符合 Kubernetes 中的描述方式。

例如如果一个 Node 有 10Gi 内存，我们希望在可用内存不足 1Gi 时进行驱逐，就可以选取下面的一种方式来定义驱逐阈值：

memory.available<10%
memory.available<1Gi

驱逐软阈值

软阈值需要和一个宽限期参数协同工作。当系统资源消耗达到软阈值时，这一状况的持续时间超过了宽限期之前，Kubelet 不会触发任何动作。如果没有定义宽限期，Kubelet 会拒绝启动。

另外还可以定义一个 Pod 结束的宽限期。如果定义了这一宽限期，那么 Kubelet 会使用 pod.Spec.TerminationGracePeriodSeconds 和最大宽限期这两个值之间较小的那个（进行宽限），如果没有指定的话，kubelet 会不留宽限立即杀死 Pod。

软阈值的定义包括以下几个参数：

eviction-soft：描述一套驱逐阈值（例如 memory.available<1.5Gi ），如果满足这一条件的持续时间超过宽限期，就会触发对 Pod 的驱逐动作。
eviction-soft-grace-period：包含一套驱逐宽限期（例如 memory.available=1m30s），用于定义达到软阈值之后，持续时间超过多久才进行驱逐。
eviction-max-pod-grace-period：在因为达到软阈值之后，到驱逐一个 Pod 之前的最大宽限时间（单位是秒），

驱逐硬阈值

硬阈值没有宽限期，如果达到了硬阈值，kubelet 会立即杀掉 Pod 并进行资源回收。

硬阈值的定义：

eviction-hard：描述一系列的驱逐阈值（比如说 memory.available<1Gi），一旦达到这一阈值，就会触发对 Pod 的驱逐，缺省的硬阈值定义是：

–eviction-hard=memory.available<100Mi

驱逐监控频率

Housekeeping interval 参数定义一个时间间隔，Kubelet 每隔这一段就会对驱逐阈值进行评估。

housekeeping-interval：容器检查的时间间隔。

节点状况

Kubelet 会把驱逐信号跟节点状况对应起来。

如果触发了硬阈值，或者符合软阈值的时间持续了与其对应的宽限期，Kubelet 就会认为当前节点压力太大，下面的节点状态定义描述了这种对应关系。

节点状况	驱逐信号	描述
MemoryPressure	memory.available	节点的可用内存达到了驱逐阈值
DiskPressure	nodefs.available, nodefs.inodesFree, imagefs.available, imagefs.inodesFree	节点的 root 文件系统或者镜像文件系统的可用空间达到了驱逐阈值

Kubelet 会持续报告节点状态的更新过程，这一频率由参数 –node-status-update-frequency 指定，缺省情况下取值为 10s。

节点状况的波动

如果一个节点的状况在软阈值的上下波动，但是又不会超过他的宽限期，将会导致该节点的状态持续的在是否之间徘徊，最终会影响降低调度的决策过程。

要防止这种状况，下面的标志可以用来通知 Kubelet，在脱离压力状态之前，必须等待。

eviction-pressure-transition-period 定义了在跳出压力状态之前要等待的时间。

Kubelet 在把压力状态设置为 False 之前，会确认在周期之内，该节点没有达到逐出阈值。

回收节点级别的资源

如果达到了驱逐阈值，并且超出了宽限期，那么 Kubelet 会开始回收超出限量的资源，直到驱逐信号量回到阈值以内。

Kubelet 在驱逐用户 Pod 之前，会尝试回收节点级别的资源。如果服务器为容器定义了独立的 imagefs，他的回收过程会有所不同。

有 Imagefs

如果 nodefs 文件系统到达了驱逐阈值，kubelet 会按照下面的顺序来清理空间。

删除死掉的 Pod/容器

如果 imagefs 文件系统到达了驱逐阈值，kubelet 会按照下面的顺序来清理空间。

删掉所有无用镜像

没有 Imagefs

如果 nodefs 文件系统到达了驱逐阈值，kubelet 会按照下面的顺序来清理空间。

删除死掉的 Pod/容器
删掉所有无用镜像

驱逐用户 Pod

如果 Kubelet 无法获取到足够的资源，就会开始驱逐 Pod。

Kubelet 会按照下面的标准对 Pod 的驱逐行为进行评判：

根据服务质量
根据 Pod 调度请求的被耗尽资源的消耗量

接下来，Pod 按照下面的顺序进行驱逐：

BestEffort：消耗最多紧缺资源的 Pod 最先失败。
Burstable：相对请求（request）最多紧缺资源的 Pod 最先被驱逐，如果没有 Pod 超出他们的请求，策略会瞄准紧缺资源消耗量最大的 Pod。
Guaranteed：相对请求（request）最多紧缺资源的 Pod 最先被驱逐，如果没有 Pod 超出他们的请求，策略会瞄准紧缺资源消耗量最大的 Pod。

Guaranteed Pod 绝不会因为其他 Pod 的资源消费被驱逐。如果系统进程（例如 kubelet、docker、journald 等）消耗了超出 system-reserved 或者 kube-reserved 的资源，而且这一节点上只运行了 Guaranteed Pod，那么为了保证节点的稳定性并降低异常消费对其他 Guaranteed Pod 的影响，必须选择一个 Guaranteed Pod 进行驱逐。

本地磁盘是一个 BestEffort 资源。如有必要，kubelet 会在 DiskPressure 的情况下，kubelet 会按照 QoS 进行评估。如果 Kubelet 判定缺乏 inode 资源，就会通过驱逐最低 QoS 的 Pod 的方式来回收 inodes。如果 kubelet 判定缺乏磁盘空间，就会通过在相同 QoS 的 Pods 中，选择消耗最多磁盘空间的 Pod 进行驱逐。

有 Imagefs

如果 nodefs 触发了驱逐，Kubelet 会用 nodefs 的使用对 Pod 进行排序 - Pod 中所有容器的本地卷和日志。

如果 imagefs 触发了驱逐，Kubelet 会根据 Pod 中所有容器的消耗的可写入层进行排序。

没有 Imagefs

如果 nodefs 触发了驱逐，Kubelet 会对各个 Pod 的所有容器的总体磁盘消耗进行排序 —— 本地卷 + 日志 + 写入层。

在某些场景下，驱逐 Pod 可能只回收了很少的资源。这就导致了 kubelet 反复触发驱逐阈值。另外回收资源例如磁盘资源，是需要消耗时间的。

要缓和这种状况，Kubelet 能够对每种资源定义 minimum-reclaim。kubelet 一旦发现了资源压力，就会试着回收至少 minimum-reclaim 的资源，使得资源消耗量回到期望范围。

例如下面的配置：

--eviction-hard=memory.available<500Mi,nodefs.available<1Gi,imagefs.available<100Gi
--eviction-minimum-reclaim="memory.available=0Mi,nodefs.available=500Mi,imagefs.available=2Gi"`

如果 memory.available 被触发，Kubelet 会启动回收，让 memory.available 至少有 500Mi。
如果是 nodefs.available，Kubelet 就要想法子让 nodefs.available 回到至少 1.5Gi。
而对于 imagefs.available， kubelet 就要回收到最少 102Gi。

缺省情况下，所有资源的 eviction-minimum-reclaim 为 0。

调度器

在节点资源紧缺的情况下，节点会报告这一状况。调度器以此为信号，不再继续向此节点部署新的 Pod。

节点状况	调度行为
`MemoryPressure`	不再分配新的 `BestEffort Pod` 到这个节点
`DiskPressure`	不再向这一节点分配 Pod

节点的 OOM 行为

如果节点在 Kubelet 能够回收内存之前，遭遇到了系统的 OOM (内存不足)，节点就依赖 oom_killer 进行响应了。

kubelet 根据 Pod 的 QoS 为每个容器设置了一个 oom_score_adj 值。

QoS	`oom_score_adj`
Guaranteed	-998
BestEffort	1000
Burstable	`min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)`

如果 kubelet 无法在系统 OOM 之前回收足够的内存，oom_killer 就会根据根据内存使用比率来计算 oom_score，得出结果和 oom_score_adj 相加，最后得分最高的 Pod 会被首先驱逐。

这一行为的思路是，QoS 最低，相对于调度的 Reqeust 来说又消耗最多内存的 Pod 会被首先清除，来保障内存的回收。

跟 Pod 驱逐不同，如果一个 Pod 的容器被 OOM 杀掉，他是可能被 kubelet 根据 RestartPolicy 重启的。

最佳时间

可调度的资源和驱逐策略

我们想象如下的场景：

节点内存容量：10Gi
保留 10% 的内存容量给系统服务（内核，kubelet 等）。
在 95% 内存使用率的时候驱逐 Pod，来降低系统 OOM 的发生率。

所以我们用这样的参数启动 Kubelet：

--eviction-hard=memory.available<500Mi
--system-reserved=memory=1.5Gi

这个配置中隐含了一个设定就是，系统保留涵盖了驱逐标准。

要达到这一容量，可能是有的 Pod 使用了超出其请求的数量，或者系统占用了超过 500Mi。

这样的配置保证了调度器不会向即将发生内存压力的节点分配 Pod，避免触发驱逐。

DaemonSet

因为 DaemonSet 中的 Pod 会立即重建到同一个节点，所以 Kubelet 不应驱逐 DaemonSet 中的 Pod。

但是目前 Kubelet 无法分辨一个 Pod 是否由 DaemonSet 创建。如果/当 Kubelet 能够识别这一点，那么就可以先从驱逐候选列表中过滤掉 DaemonSet 的 Pod。

一般来说，强烈建议 DaemonSet 不要创建 BestEffort Pod，而是使用 Guaranteed Pod，来避免进入驱逐候选列表。

弃用的现存回收磁盘的选项

为了保证节点的稳定性，Kubelet 已经尝试来释放磁盘空间了。

因为基于磁盘的驱逐方式已经成熟，下列的 Kubelet 参数会被标记为弃用。

现有参数	新参数
–image-gc-high-threshold	–eviction-hard or eviction-soft
–image-gc-low-threshold	–eviction-minimum-reclaim
–maximum-dead-containers	弃用
–maximum-dead-containers-per-container	弃用
–minimum-container-ttl-duration	弃用
–low-diskspace-threshold-mb	–eviction-hard or eviction-soft
–outofdisk-transition-frequency	–eviction-pressure-transition-period

已知问题

Kubelet 无法及时观测到内存压力

Kubelet 目前从 cAdvisor 定时获取内存使用状况统计。如果内存使用在这个时间段内发生了快速增长，Kubelet 就无法观察到 MemoryPressure，可能会触发 OOMKiller。我们正在尝试将这一过程集成到 memcg 通知 API 中，来降低这一延迟，而不是让内核首先发现这一情况。

如果用户不是希望获得终极使用率，而是作为一个过量使用的衡量方式，对付这一个问题的较为可靠的方式就是设置驱逐阈值为 75% 容量。这样就提高了避开 OOM 的能力，提高了驱逐的标准，有助于集群状态的平衡。

Kubelet 可能驱逐超出需要的更多 Pod

这也是因为状态搜集的时间差导致的。未来会加入功能，让根容器的统计频率和其他容器分别开来（https://github.com/google/cadvisor/issues/1247）。

Kubelet 如何在 inode 耗尽的时候评价 Pod 的驱逐

目前不可能知道一个容器消耗了多少 inode。如果 Kubelet 觉察到了 inode 耗尽，他会利用 QoS 对 Pod 进行驱逐评估。在 cadvisor 中有一个 issue，来跟踪容器的 inode 消耗，这样我们就能利用 inode 进行评估了。例如如果我们知道一个容器创建了大量的 0 字节文件，就会优先驱逐这一 Pod

Minikube：轻松运行本地 Kuberntes 集群

Thu, 14 Jul 2016 15:49:24 +0800

原文：Minikube: easily run Kubernetes locally

Kubernetes 已经是目前最佳的应用容器化工具之一。在投入实际使用之后的一年来，Kubernetes（社区）需要一个本地开发平台。

在过去的几个月中，Kubernetes 社区中的很多成员在为 Github 的 Minikube 仓库奋战。我们要建立一个可以一键运行的版本，这个版本要易用和准确兼顾，并且能够兼容 Mac、 Linux 以及 Windows 的工作站和笔记本电脑。

感谢社区成员的贡献，我们自豪的宣告 Minikube 的诞生，并与 Kubernetes 1.3 一起发布，新的命令能够更好的跟本地集群通信，并且加入了试验性的对 xhyve（OS X）以及 KVM（Linux）的支持。

使用 Minikube

Minitube 是一个独立的 Go 应用，所以只要下载运行就可以了：

Minikube 目前要求安装 VirtualBox

# 这是针对 Mac， 如果是 Linux 的话，用 minikube-linux-amd64 代替 minikube-darwin-amd64 即可

curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/

要启动 Kubernetes 集群，要使用minikube start命令：

$ minikube start
Starting local Kubernetes cluster...
Kubernetes is available at https://192.168.99.100:443
Kubectl is now configured to use the cluster

这样，就在你的电脑上启动了一个单节点的 Kubernetes 集群。Minikube 会给你配置 kubectl，所以你现在就可以运行容器了。

Minikube 创建了一个 Host-Only 的网络界面来和 Node 通信。要和其中的 Pod 或者 Service 通信，就需要跟这个地址进行交互。可以使用 minikube ip 命令：

Minikube 还自带了 Kubernetes Dashboard。要浏览这个界面，可以使用内置的 minikube dashboard命令。

一般来说，Minikube 支持 Kubernetes 集群的所有内容。你可以使用 kubectl exec 来在 pod 内获取一个 bash shell。还可以使用 kubectl port-forward 以及 kubectl proxy 命令来把通信从本地转发到一个 pod 或者 API server。

Minikube 是运行在本地而不是云供应商，因此特定的 LoadBalancer 以及 PersistentVolume 也就无法使用了；当然，还是可以使用 NodePort 以及 HostPath 作为替代方案。

架构

Minikube 构建于 Docker 的 libmachine，利用他的驱动模型来创建、管理本地运行的虚拟机，并与其交互。

慷慨的 RedSpread向 Minikube 贡献了他们的 localkube 代码，得到这一帮助，我们有了在虚拟机中创建单进程 Kubernetes 集群的能力。Localkube 把 etcd、DNS、Kubelet 以及所有的 Kubernetes Master 组件都集成到了一个单独的 Go Lib 中并使用不同的 goroutine 执行。

后续发展

Minikube 现在已经颇具可玩性了，为了改善 Kubernetes 开发体验，我们会持续对 Minikube 进行增强。如果你有任何设想，请移步 issue tracker 畅所欲言。

我们希望尽快把下面列表中的内容加入 Minikube：

为 OSX 以及 Windows 提供本地的 Native hypervisor 支持。
- 我们计划去掉对 Virtualbox 的依赖，转向 OSX 和 Windows 的本地 Hypervisor。
增强对 Kubernetes 特性的支持
- 希望能够进一步缩小功能差异，以便于引入 Ingress 之类的内容。
可配置的 Kubernetes 版本
- 目前 Minikube 只支持 Kubernetes 1.3。我们计划提供用户可控的 Kubernetes 版本支持，这样就能够让开发与生产环境更加贴近。

社区

我们乐于听取 Minikube 的反馈，可以用下面的方式参与社区：

在 GitHub 中提出 Issue 或者提出功能要求。
加入 Slack 的 #minikube 频道

请给 Minikube 一个机会，并让我们能够获知 Minikube 的运行情况。