8.深入k8s：資源控制Qos和eviction及其原始碼分析
阿新 • • 發佈：2020-08-30
> 轉載請宣告出處哦~，本篇文章釋出於luozhiyun的部落格：https://www.luozhiyun.com，原始碼版本是[1.19](https://github.com/kubernetes/kubernetes/tree/release-1.19)
又是一個週末，可以愉快的坐下來靜靜的品味一段原始碼，這一篇涉及到資源的回收，工作量是很大的，篇幅會比較長，我們可以看到k8s在資源不夠時會怎麼做的，k8s在回收資源的時候有哪些考慮，我們的pod為什麼會無端端的被幹掉等等。
## limit&request
在k8s中，CPU和記憶體的資源主要是通過這limit&request來進行限制的，在yaml檔案中的定義如下：
```
spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory
```
在排程的時候，kube-scheduler 只會按照 requests 的值進行計算，而真正限制資源使用的是limit。
下面我引用一個官方的例子：
```yaml
apiVersion: v1
kind: Pod
metadata:
name: cpu-demo
namespace: cpu-example
spec:
containers:
- name: cpu-demo-ctr
image: vish/stress
resources:
limits:
cpu: "1"
requests:
cpu: "0.5"
args:
- -cpus
- "2"
```
在這個例子中，args引數給的是cpus等於2，表示這個container可以使用2個cpu進行壓測。但是我們的limits是1，以及requests是0.5。
當我們建立好這個pod之後，然後使用kubectl top去檢視資源使用情況的時候會發現cpu使用並不會超過1：
```
NAME CPU(cores) MEMORY(bytes)
cpu-demo 974m
```
這說明這個pod的cpu資源被限制在了1個cpu，即使container想使用，也是沒有辦法的。
在容器沒有指定 request 的時候，request 的值和 limit 預設相等。
## QoS 模型與Eviction
下面說一下由不同的 requests 和 limits 的設定方式引出的不同的 QoS 級別。
kubernetes 中有三種 Qos，分別為：
1. `Guaranteed`：Pod中所有Container的所有Resource的`limit`和`request`都相等且不為0；
2. `Burstable`：pod不滿足Guaranteed條件，但是其中至少有一個container設定了requests或limits ；
3. `BestEffort`：pod的 requests 與 limits 均沒有設定；
當宿主機資源緊張的時候，kubelet 對 Pod 進行 Eviction（即資源回收）時會按照Qos的順序進行回收，回收順序是：BestEffort>Burstable>Guaranteed
Eviction有兩種模式，分為 Soft 和 Hard。Soft Eviction 允許你為 Eviction 過程設定grace period，然後等待一個使用者配置的grace period之後，再執行Eviction，而Hard則立即執行。
那麼什麼時候會發生Eviction呢？我們可以為Eviction 設定threshold，比如設定設定記憶體的 eviction hard threshold 為 100M，那麼當這臺機器的記憶體可用資源不足 100M 時，kubelet 就會根據這臺機器上面所有 pod 的 QoS 級別以及他們的記憶體使用情況，進行一個綜合排名，把排名最靠前的 pod 進行遷移，從而釋放出足夠的記憶體資源。
thresholds定義方式為`[eviction-signal][operator][quantity]`
**eviction-signal**
eviction-signal按照官方文件的說法分為如下幾種：
| Eviction Signal | Description |
| ------------------ | ------------------------------------------------------------ |
| 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 |
nodefs和imagefs表示兩種檔案系統分割槽：
nodefs：檔案系統，kubelet 將其用於卷和守護程式日誌等。
imagefs：檔案系統，容器執行時用於儲存映象和容器可寫層。
**operator**
就是所需的關係運算符，如"<"。
**quantity**
是閾值的大小，可以容量大小，如：1Gi；也可以用百分比來表示：10%。
如果kubelet在節點經歷系統 OOM 之前無法回收記憶體，那麼oom_killer將基於它在節點上 使用的記憶體百分比算出一個oom_score，然後結束得分最高的容器。
## Qos原始碼分析
qos的程式碼位於pkg\apis\core\v1\helper\qos\包下面：
**qos#GetPodQOS**
```go
//pkg\apis\core\v1\helper\qos\qos.go
func GetPodQOS(pod *v1.Pod) v1.PodQOSClass {
requests := v1.ResourceList{}
limits := v1.ResourceList{}
zeroQuantity := resource.MustParse("0")
isGuaranteed := true
allContainers := []v1.Container{}
//追加所有的初始化容器
allContainers = append(allContainers, pod.Spec.Containers...)
allContainers = append(allContainers, pod.Spec.InitContainers...)
//遍歷container
for _, container := range allContainers {
// process requests
//遍歷request 裡面的cpu、memory 獲取其中的值
for name, quantity := range container.Resources.Requests {
if !isSupportedQoSComputeResource(name) {
continue
}
if quantity.Cmp(zeroQuantity) == 1 {
delta := quantity.DeepCopy()
if _, exists := requests[name]; !exists {
requests[name] = delta
} else {
delta.Add(requests[name])
requests[name] = delta
}
}
}
// process limits
qosLimitsFound := sets.NewString()
//遍歷 limit 裡面的cpu、memory 獲取其中的值
for name, quantity := range container.Resources.Limits {
if !isSupportedQoSComputeResource(name) {
continue
}
if quantity.Cmp(zeroQuantity) == 1 {
qosLimitsFound.Insert(string(name))
delta := quantity.DeepCopy()
if _, exists := limits[name]; !exists {
limits[name] = delta
} else {
delta.Add(limits[name])
limits[name] = delta
}
}
}
//如果limits 沒有同時設定cpu 、Memory，那麼就不是Guaranteed
if !qosLimitsFound.HasAll(string(v1.ResourceMemory), string(v1.ResourceCPU)) {
isGuaranteed = false
}
}
//如果requests 和 limits都沒有設定，那麼為BestEffort
if len(requests) == 0 && len(limits) == 0 {
return v1.PodQOSBestEffort
}
// Check is requests match limits for all resources.
if isGuaranteed {
for name, req := range requests {
if lim, exists := limits[name]; !exists || lim.Cmp(req) != 0 {
isGuaranteed = false
break
}
}
}
// 都設定了limits 和 requests，則是Guaranteed
if isGuaranteed &&
len(requests) == len(limits) {
return v1.PodQOSGuaranteed
}
return v1.PodQOSBurstable
}
```
上面有註釋我就不過多介紹，非常的簡單。
下面這裡是QOS OOM打分機制，通過給不同的pod打分來判斷，哪些pod可以被優先kill掉，分數越高的越容易被kill。
**policy**
```go
//\pkg\kubelet\qos\policy.go
// 分值越高越容易被kill
const (
// KubeletOOMScoreAdj is the OOM score adjustment for Kubelet
KubeletOOMScoreAdj int = -999
// KubeProxyOOMScoreAdj is the OOM score adjustment for kube-proxy
KubeProxyOOMScoreAdj int = -999
guaranteedOOMScoreAdj int = -998
besteffortOOMScoreAdj int = 1000
)
```
**policy#GetContainerOOMScoreAdjust**
```go
//\pkg\kubelet\qos\policy.go
func GetContainerOOMScoreAdjust(pod *v1.Pod, container *v1.Container, memoryCapacity int64) int {
//靜態Pod、映象Pod和高優先順序Pod，直接可以是guaranteedOOMScoreAdj
if types.IsCriticalPod(pod) {
// Critical pods should be the last to get killed.
return guaranteedOOMScoreAdj
}
//獲取pod的qos等級，這裡只處理Guaranteed與BestEffort
switch v1qos.GetPodQOS(pod) {
case v1.PodQOSGuaranteed:
// Guaranteed containers should be the last to get killed.
return guaranteedOOMScoreAdj
case v1.PodQOSBestEffort:
return besteffortOOMScoreAdj
}
memoryRequest := container.Resources.Requests.Memory().Value()
//如果我們佔用的記憶體越少，則打分就越高
oomScoreAdjust := 1000 - (1000*memoryRequest)/memoryCapacity
//這裡是為了保證burstable能有個更高的 OOM score
if int(oomScoreAdjust) < (1000 + guaranteedOOMScoreAdj) {
return (1000 + guaranteedOOMScoreAdj)
}
if int(oomScoreAdjust) == besteffortOOMScoreAdj {
return int(oomScoreAdjust - 1)
}
return int(oomScoreAdjust)
}
```
這個方法裡面給不同的pod進行打分，靜態Pod、映象Pod和高優先順序Pod，QOS直接被設定成為guaranteed；
然後呼叫qos的GetPodQOS方法獲取一個pod的評分，但是如果一個pod是burstable，那麼需要根據其直接使用的記憶體來進行評分，佔用的記憶體越少，則打分就越高，如果分數小於1000 + guaranteedOOMScoreAdj，也就是2分，那麼被直接設定成2分，避免分數過低。
## Eviction Manager原始碼分析
kubelet在例項化一個kubelet物件的時候，呼叫`eviction.NewManager`新建了一個evictionManager物件。然後kubelet再Run方法開始工作的時候，建立一個goroutine，每5s執行一次updateRuntimeUp。
在updateRuntimeUp中，待確認runtime啟動成功後，會呼叫initializeRuntimeDependentModules完成runtime依賴模組的初始化工作。
然後在initializeRuntimeDependentModules中會呼叫evictionManager的start方法進行啟動。
程式碼如下，具體的kubelet流程我們留到以後慢慢分析：
```go
func NewMainKubelet(...){
...
evictionManager, evictionAdmitHandler := eviction.NewManager(klet.resourceAnalyzer, evictionConfig, killPodNow(klet.podWorkers, kubeDeps.Recorder), klet.podManager.GetMirrorPodByPod, klet.imageManager, klet.containerGC, kubeDeps.Recorder, nodeRef, klet.clock, etcHostsPathFunc)
klet.evictionManager = evictionManager
...
}
func (kl *Kubelet) Run(updates <-chan kubetypes.PodUpdate) {
...
go wait.Until(kl.updateRuntimeUp, 5*time.Second, wait.NeverStop)
...
}
func (kl *Kubelet) updateRuntimeUp() {
...
kl.oneTimeInitializer.Do(kl.initializeRuntimeDependentModules)
...
}
func (kl *Kubelet) initializeRuntimeDependentModules() {
...
kl.evictionManager.Start(kl.StatsProvider, kl.GetActivePods, kl.podResourcesAreReclaimed, evictionMonitoringPeriod)
...
}
```
下面我們來到\pkg\kubelet\eviction\eviction_manager.go去看一下Start方法怎麼實現eviction的。
**managerImp#Start**
```go
// 開啟一個控制迴圈去監視和響應資源過低的情況
func (m *managerImpl) Start(diskInfoProvider DiskInfoProvider, podFunc ActivePodsFunc, podCleanedUpFunc PodCleanedUpFunc, monitoringInterval time.Duration) {
thresholdHandler := func(message string) {
klog.Infof(message)
m.synchronize(diskInfoProvider, podFunc)
}
//是否要利用kernel memcg notification
if m.config.KernelMemcgNotification {
for _, threshold := range m.config.Thresholds {
if threshold.Signal == evictionapi.SignalMemoryAvailable || threshold.Signal == evictionapi.SignalAllocatableMemoryAvailable {
notifier, err := NewMemoryThresholdNotifier(threshold, m.config.PodCgroupRoot, &CgroupNotifierFactory{}, thresholdHandler)
if err != nil {
klog.Warningf("eviction manager: failed to create memory threshold notifier: %v", err)
} else {
go notifier.Start()
m.thresholdNotifiers = append(m.thresholdNotifiers, notifier)
}
}
}
}
// start the eviction manager monitoring
// 啟動一個goroutine，for迴圈裡每隔monitoringInterval（10s）執行一次synchronize
go func() {
for {
//synchronize是主要的eviction控制迴圈，返回被kill的pod，或返回nill
if evictedPods := m.synchronize(diskInfoProvider, podFunc); evictedPods != nil {
klog.Infof("eviction manager: pods %s evicted, waiting for pod to be cleaned up", format.Pods(evictedPods))
m.waitForPodsCleanup(podCleanedUpFunc, evictedPods)
} else {
time.Sleep(monitoringInterval)
}
}
}()
}
```
下面的synchronize方法會很長，需要點耐心：
**managerImpl#synchronize**
1. 根據上面介紹的不同的eviction signal會有不同的排序方法，以及設定節點資源回收方法
```go
func (m *managerImpl) synchronize(diskInfoProvider DiskInfoProvider, podFunc ActivePodsFunc) []*v1.Pod {
...
if m.dedicatedImageFs == nil {
hasImageFs, ok := diskInfoProvider.HasDedicatedImageFs()
if ok != nil {
return nil
}
m.dedicatedImageFs = &hasImageFs
//註冊各個eviction signal所對應的資源排序方法
m.signalToRankFunc = buildSignalToRankFunc(hasImageFs)
// 註冊節點資源回收方法，例如imagefs.avaliable對應的是刪除無用容器和無用映象
m.signalToNodeReclaimFuncs = buildSignalToNodeReclaimFuncs(m.imageGC, m.containerGC, hasImageFs)
}
...
}
```
看一下buildSignalToRankFunc方法的實現：
```go
func buildSignalToRankFunc(withImageFs bool) map[evictionapi.Signal]rankFunc {
signalToRankFunc := map[evictionapi.Signal]rankFunc{
evictionapi.SignalMemoryAvailable: rankMemoryPressure,
evictionapi.SignalAllocatableMemoryAvailable: rankMemoryPressure,
evictionapi.SignalPIDAvailable: rankPIDPressure,
}
if withImageFs {
signalToRankFunc[evictionapi.SignalNodeFsAvailable] = rankDiskPressureFunc([]fsStatsType{fsStatsLogs, fsStatsLocalVolumeSource}, v1.ResourceEphemeralStorage)
signalToRankFunc[evictionapi.SignalNodeFsInodesFree] = rankDiskPressureFunc([]fsStatsType{fsStatsLogs, fsStatsLocalVolumeSource}, resourceInodes)
signalToRankFunc[evictionapi.SignalImageFsAvailable] = rankDiskPressureFunc([]fsStatsType{fsStatsRoot}, v1.ResourceEphemeralStorage)
signalToRankFunc[evictionapi.SignalImageFsInodesFree] = rankDiskPressureFunc([]fsStatsType{fsStatsRoot}, resourceInodes)
} else {
signalToRankFunc[evictionapi.SignalNodeFsAvailable] = rankDiskPressureFunc([]fsStatsType{fsStatsRoot, fsStatsLogs, fsStatsLocalVolumeSource}, v1.ResourceEphemeralStorage)
signalToRankFunc[evictionapi.SignalNodeFsInodesFree] = rankDiskPressureFunc([]fsStatsType{fsStatsRoot, fsStatsLogs, fsStatsLocalVolumeSource}, resourceInodes)
signalToRankFunc[evictionapi.SignalImageFsAvailable] = rankDiskPressureFunc([]fsStatsType{fsStatsRoot, fsStatsLogs, fsStatsLocalVolumeSource}, v1.ResourceEphemeralStorage)
signalToRankFunc[evictionapi.SignalImageFsInodesFree] = rankDiskPressureFunc([]fsStatsType{fsStatsRoot, fsStatsLogs, fsStatsLocalVolumeSource}, resourceInodes)
}
return signalToRankFunc
}
```
這個方法裡面會將各個eviction signal的排序方法放入到一個map中返回，如MemoryAvailable、NodeFsAvailable、ImageFsAvailable等。
2. 獲取所有的活躍的pod，以及整體的stat資訊
```go
func (m *managerImpl) synchronize(diskInfoProvider DiskInfoProvider, podFunc ActivePodsFunc) []*v1.Pod {
...
//獲取當前active的pods
activePods := podFunc()
updateStats := true
//獲取節點的整體概況，即nodeStsts和podStats
summary, err := m.summaryProvider.Get(updateStats)
if err != nil {
klog.Errorf("eviction manager: failed to get summary stats: %v", err)
return nil
}
//如果Notifiers有超過10s沒有重新整理，那麼更新Notifiers
if m.clock.Since(m.thresholdsLastUpdated) >