浅析Kubelet驱逐机制

Kubelet 出于对节点的保护，允许在节点资源不足的情况下，开启对节点上 Pod 进行驱逐的功能。最近对 Kubelet 的驱逐机制有所研究，发现其中有很多值得学习的地方，总结下来和大家分享。

成都网络公司-成都网站建设公司创新互联公司10年经验成就非凡，专业从事网站设计、成都网站设计，成都网页设计，成都网页制作，软文营销，广告投放平台等。10年来已成功提供全面的成都网站建设方案，打造行业特色的成都网站建设案例，建站热线：18980820575，我们期待您的来电！

Kubelet 的配置

Kubelet 的驱逐功能需要在配置中打开，并且配置驱逐的阈值。Kubelet 的配置中与驱逐相关的参数如下：

 
 
 
 
    
  
  
  
  
  1. type KubeletConfiguration struct { 
    2. 
  
  
  
  
  2.     ... 
    3. 
  
  
  
  
  3.   // Map of signal names to quantities that defines hard eviction thresholds. For example: {"memory.available": "300Mi"}. 
    4. 
  
  
  
  
  4.   EvictionHard map[string]string 
    5. 
  
  
  
  
  5.   // Map of signal names to quantities that defines soft eviction thresholds.  For example: {"memory.available": "300Mi"}. 
    6. 
  
  
  
  
  6.   EvictionSoft map[string]string 
    7. 
  
  
  
  
  7.   // Map of signal names to quantities that defines grace periods for each soft eviction signal. For example: {"memory.available": "30s"}. 
    8. 
  
  
  
  
  8.   EvictionSoftGracePeriod map[string]string 
    9. 
  
  
  
  
  9.   // Duration for which the kubelet has to wait before transitioning out of an eviction pressure condition. 
    10. 
  
  
  
  
  10.   EvictionPressureTransitionPeriod metav1.Duration 
    11. 
  
  
  
  
  11.   // Maximum allowed grace period (in seconds) to use when terminating pods in response to a soft eviction threshold being met. 
    12. 
  
  
  
  
  12.   EvictionMaxPodGracePeriod int32 
    13. 
  
  
  
  
  13.   // Map of signal names to quantities that defines minimum reclaims, which describe the minimum 
    14. 
  
  
  
  
  14.   // amount of a given resource the kubelet will reclaim when performing a pod eviction while 
    15. 
  
  
  
  
  15.   // that resource is under pressure. For example: {"imagefs.available": "2Gi"} 
    16. 
  
  
  
  
  16.   EvictionMinimumReclaim map[string]string 
    17. 
  
  
  
  
  17.   ... 
    18. 
  
  
  
  
  18. } 
    19.

其中，EvictionHard 表示硬驱逐，一旦达到阈值，就直接驱逐;EvictionSoft 表示软驱逐，即可以设置软驱逐周期，只有超过软驱逐周期后，才启动驱逐，周期用 EvictionSoftGracePeriod 设置;EvictionMinimumReclaim 表示设置最小可用的阈值，比如 imagefs。

可以设置的驱逐信号有：

  • memory.available：node.status.capacity[memory] - node.stats.memory.workingSet，节点可用内存
  • nodefs.available：node.stats.fs.available，Kubelet 使用的文件系统的可使用容量大小
  • nodefs.inodesFree：node.stats.fs.inodesFree，Kubelet 使用的文件系统的可使用 inodes 数量
  • imagefs.available：node.stats.runtime.imagefs.available，容器运行时用来存放镜像及容器可写层的文件系统的可使用容量
  • imagefs.inodesFree：node.stats.runtime.imagefs.inodesFree，容器运行时用来存放镜像及容器可写层的文件系统的可使用 inodes 容量
  • allocatableMemory.available：留给分配 Pod 用的可用内存
  • pid.available：node.stats.rlimit.maxpid - node.stats.rlimit.curproc，留给分配 Pod 用的可用 PID

Eviction Manager 工作原理

Eviction Manager的主要工作在 synchronize 函数里。有两个地方触发 synchronize 任务，一个是 monitor 任务，每 10s 触发一次;另一个是根据用户配置的驱逐信号，启动的 notifier 任务，用来监听内核事件。

notifier

notifier 由 eviction manager 中的 thresholdNotifier 启动，用户配置的每一个驱逐信号，都对应一个 thresholdNotifier，而 thresholdNotifier 和 notifier 通过 channel 通信，当 notifier 向 channel 中发送消息时，对应的 thresholdNotifier 便触发一次 synchronize 逻辑。

notifier 采用的是内核的 cgroups Memory thresholds，cgroups 允许用户态进程通过 eventfd 来设置当 memory.usage_in_bytes 达到某阈值时，内核给应用发送通知。具体做法是向 cgroup.event_control 写入 " "。

notifier 的初始化代码如下(为了方便阅读，删除了部分不相干代码)，主要是找到 memory.usage_in_bytes 的文件描述符 watchfd，cgroup.event_control 的文件描述符 controlfd，完成 cgroup memory thrsholds 的注册。

 
 
 
 
    
  
  
  
  
  1. func NewCgroupNotifier(path, attribute string, threshold int64) (CgroupNotifier, error) { 
    2. 
  
  
  
  
  2.   var watchfd, eventfd, epfd, controlfd int 
    3. 
  
  
  
  
  3.  
    4. 
  
  
  
  
  4.   watchfd, err = unix.Open(fmt.Sprintf("%s/%s", path, attribute), unix.O_RDONLY|unix.O_CLOEXEC, 0) 
    5. 
  
  
  
  
  5.   defer unix.Close(watchfd) 
    6. 
  
  
  
  
  6.    
    7. 
  
  
  
  
  7.   controlfd, err = unix.Open(fmt.Sprintf("%s/cgroup.event_control", path), unix.O_WRONLY|unix.O_CLOEXEC, 0) 
    8. 
  
  
  
  
  8.   defer unix.Close(controlfd) 
    9. 
  
  
  
  
  9.    
    10. 
  
  
  
  
  10.   eventfd, err = unix.Eventfd(0, unix.EFD_CLOEXEC) 
    11. 
  
  
  
  
  11.   defer func() { 
    12. 
  
  
  
  
  12.     // Close eventfd if we get an error later in initialization 
    13. 
  
  
  
  
  13.     if err != nil { 
    14. 
  
  
  
  
  14.       unix.Close(eventfd) 
    15. 
  
  
  
  
  15.     } 
    16. 
  
  
  
  
  16.   }() 
    17. 
  
  
  
  
  17.    
    18. 
  
  
  
  
  18.   epfd, err = unix.EpollCreate1(unix.EPOLL_CLOEXEC) 
    19. 
  
  
  
  
  19.   defer func() { 
    20. 
  
  
  
  
  20.     // Close epfd if we get an error later in initialization 
    21. 
  
  
  
  
  21.     if err != nil { 
    22. 
  
  
  
  
  22.       unix.Close(epfd) 
    23. 
  
  
  
  
  23.     } 
    24. 
  
  
  
  
  24.   }() 
    25. 
  
  
  
  
  25.    
    26. 
  
  
  
  
  26.   config := fmt.Sprintf("%d %d %d", eventfd, watchfd, threshold) 
    27. 
  
  
  
  
  27.   _, err = unix.Write(controlfd, []byte(config)) 
    28. 
  
  
  
  
  28.  
    29. 
  
  
  
  
  29.   return &linuxCgroupNotifier{ 
    30. 
  
  
  
  
  30.     eventfd: eventfd, 
    31. 
  
  
  
  
  31.     epfd:    epfd, 
    32. 
  
  
  
  
  32.     stop:    make(chan struct{}), 
    33. 
  
  
  
  
  33.   }, nil 
    34. 
  
  
  
  
  34. } 
    35.

notifier 在启动时还会通过 epoll 来监听上述的 eventfd，当监听到内核发送的事件时，说明使用的内存已超过阈值，便向 channel 中发送信号。

 
 
 
 
    
  
  
  
  
  1. func (n *linuxCgroupNotifier) Start(eventCh chan<- struct{}) { 
    2. 
  
  
  
  
  2.   err := unix.EpollCtl(n.epfd, unix.EPOLL_CTL_ADD, n.eventfd, &unix.EpollEvent{ 
    3. 
  
  
  
  
  3.     Fd:     int32(n.eventfd), 
    4. 
  
  
  
  
  4.     Events: unix.EPOLLIN, 
    5. 
  
  
  
  
  5.   }) 
    6. 
  
  
  
  
  6.  
    7. 
  
  
  
  
  7.   for { 
    8. 
  
  
  
  
  8.     select { 
    9. 
  
  
  
  
  9.     case <-n.stop: 
    10. 
  
  
  
  
  10.       return 
    11. 
  
  
  
  
  11.     default: 
    12. 
  
  
  
  
  12.     } 
    13. 
  
  
  
  
  13.     event, err := wait(n.epfd, n.eventfd, notifierRefreshInterval) 
    14. 
  
  
  
  
  14.     if err != nil { 
    15. 
  
  
  
  
  15.       klog.InfoS("Eviction manager: error while waiting for memcg events", "err", err) 
    16. 
  
  
  
  
  16.       return 
    17. 
  
  
  
  
  17.     } else if !event { 
    18. 
  
  
  
  
  18.       // Timeout on wait.  This is expected if the threshold was not crossed 
    19. 
  
  
  
  
  19.       continue 
    20. 
  
  
  
  
  20.     } 
    21. 
  
  
  
  
  21.     // Consume the event from the eventfd 
    22. 
  
  
  
  
  22.     buf := make([]byte, eventSize) 
    23. 
  
  
  
  
  23.     _, err = unix.Read(n.eventfd, buf) 
    24. 
  
  
  
  
  24.     if err != nil { 
    25. 
  
  
  
  
  25.       klog.InfoS("Eviction manager: error reading memcg events", "err", err) 
    26. 
  
  
  
  
  26.       return 
    27. 
  
  
  
  
  27.     } 
    28. 
  
  
  
  
  28.     eventCh <- struct{}{} 
    29. 
  
  
  
  
  29.   } 
    30. 
  
  
  
  
  30. } 
    31.

synchronize 逻辑每次执行都会判断 10s 内 notifier 是否有更新，并重新启动 notifier。cgroup memory threshold 的计算方式为内存总量减去用户设置的驱逐阈值。

synchronize

Eviction Manager 的主逻辑 synchronize 细节比较多，这里就不贴源码了，梳理下来主要是以下几个事项：

  1. 针对每个信号构建排序函数;
  2. 更新 threshold 并重新启动 notifier;
  3. 获取当前节点的资源使用情况(cgroup 的信息)和所有活跃的 pod;
  4. 针对每个信号，分别确定当前节点的资源使用情况是否达到驱逐的阈值，如果都没有，则退出当前循环;
  5. 将所有的信号进行优先级排序，优先级为：跟内存有关的信号先进行驱逐;
  6. 向 apiserver 发送 驱逐事件;
  7. 将所有活跃的 pod 进行优先级排序;
  8. 按照排序后的顺序对 pod 进行驱逐。

计算驱逐顺序

对 pod 的驱逐顺序主要取决于三个因素：

  • pod 的资源使用情况是否超过其 requests;
  • pod 的 priority 值;
  • pod 的内存使用情况;

三个因素的判断顺序也是根据注册进 orderedBy 的顺序。这里 orderedBy 函数的多级排序也是 Kubernetes 里一个值得学习(抄作业)的一个实现，感兴趣的读者可以自行查阅源码。

 
 
 
 
    
  
  
  
  
  1. // rankMemoryPressure orders the input pods for eviction in response to memory pressure. 
    2. 
  
  
  
  
  2. // It ranks by whether or not the pod's usage exceeds its requests, then by priority, and 
    3. 
  
  
  
  
  3. // finally by memory usage above requests. 
    4. 
  
  
  
  
  4. func rankMemoryPressure(pods []*v1.Pod, stats statsFunc) { 
    5. 
  
  
  
  
  5.   orderedBy(exceedMemoryRequests(stats), priority, memory(stats)).Sort(pods) 
    6. 
  
  
  
  
  6. } 
    7.

驱逐 Pod

接下来就是驱逐 Pod 的实现。Eviction Manager 驱逐 Pod 就是干净利落的 kill，里面具体的实现这里不展开分析，值得注意的是在驱逐之前有一个判断，如果 IsCriticalPod 返回为 true 则不驱逐。

 
 
 
 
    
  
  
  
  
  1. func (m *managerImpl) evictPod(pod *v1.Pod, gracePeriodOverride int64, evictMsg string, annotations map[string]string) bool { 
    2. 
  
  
  
  
  2.   // If the pod is marked as critical and static, and support for critical pod annotations is enabled, 
    3. 
  
  
  
  
  3.   // do not evict such pods. Static pods are not re-admitted after evictions. 
    4. 
  
  
  
  
  4.   // https://github.com/kubernetes/kubernetes/issues/40573 has more details. 
    5. 
  
  
  
  
  5.   if kubelettypes.IsCriticalPod(pod) { 
    6. 
  
  
  
  
  6.     klog.ErrorS(nil, "Eviction manager: cannot evict a critical pod", "pod", klog.KObj(pod)) 
    7. 
  
  
  
  
  7.     return false 
    8. 
  
  
  
  
  8.   } 
    9. 
  
  
  
  
  9.   // record that we are evicting the pod 
    10. 
  
  
  
  
  10.   m.recorder.AnnotatedEventf(pod, annotations, v1.EventTypeWarning, Reason, evictMsg) 
    11. 
  
  
  
  
  11.   // this is a blocking call and should only return when the pod and its containers are killed. 
    12. 
  
  
  
  
  12.   klog.V(3).InfoS("Evicting pod", "pod", klog.KObj(pod), "podUID", pod.UID, "message", evictMsg) 
    13. 
  
  
  
  
  13.   err := m.killPodFunc(pod, true, &gracePeriodOverride, func(status *v1.PodStatus) { 
    14. 
  
  
  
  
  14.     status.Phase = v1.PodFailed 
    15. 
  
  
  
  
  15.     status.Reason = Reason 
    16. 
  
  
  
  
  16.     status.Message = evictMsg 
    17. 
  
  
  
  
  17.   }) 
    18. 
  
  
  
  
  18.   if err != nil { 
    19. 
  
  
  
  
  19.     klog.ErrorS(err, "Eviction manager: pod failed to evict", "pod", klog.KObj(pod)) 
    20. 
  
  
  
  
  20.   } else { 
    21. 
  
  
  
  
  21.     klog.InfoS("Eviction manager: pod is evicted successfully", "pod", klog.KObj(pod)) 
    22. 
  
  
  
  
  22.   } 
    23. 
  
  
  
  
  23.   return true 
    24. 
  
  
  
  
  24. } 
    25.

再看看 IsCriticalPod 的代码：

 
 
 
 
    
  
  
  
  
  1. func IsCriticalPod(pod *v1.Pod) bool { 
    2. 
  
  
  
  
  2.   if IsStaticPod(pod) { 
    3. 
  
  
  
  
  3.     return true 
    4. 
  
  
  
  
  4.   } 
    5. 
  
  
  
  
  5.   if IsMirrorPod(pod) { 
    6. 
  
  
  
  
  6.     return true 
    7. 
  
  
  
  
  7.   } 
    8. 
  
  
  
  
  8.   if pod.Spec.Priority != nil && IsCriticalPodBasedOnPriority(*pod.Spec.Priority) { 
    9. 
  
  
  
  
  9.     return true 
    10. 
  
  
  
  
  10.   } 
    11. 
  
  
  
  
  11.   return false 
    12. 
  
  
  
  
  12. } 
    13. 
  
  
  
  
  13.  
    14. 
  
  
  
  
  14. // IsMirrorPod returns true if the passed Pod is a Mirror Pod. 
    15. 
  
  
  
  
  15. func IsMirrorPod(pod *v1.Pod) bool { 
    16. 
  
  
  
  
  16.   _, ok := pod.Annotations[ConfigMirrorAnnotationKey] 
    17. 
  
  
  
  
  17.   return ok 
    18. 
  
  
  
  
  18. } 
    19. 
  
  
  
  
  19.  
    20. 
  
  
  
  
  20. // IsStaticPod returns true if the pod is a static pod. 
    21. 
  
  
  
  
  21. func IsStaticPod(pod *v1.Pod) bool { 
    22. 
  
  
  
  
  22.   source, err := GetPodSource(pod) 
    23. 
  
  
  
  
  23.   return err == nil && source != ApiserverSource 
    24. 
  
  
  
  
  24. } 
    25. 
  
  
  
  
  25.  
    26. 
  
  
  
  
  26. func IsCriticalPodBasedOnPriority(priority int32) bool { 
    27. 
  
  
  
  
  27.   return priority >= scheduling.SystemCriticalPriority 
    28. 
  
  
  
  
  28. } 
    29.

从代码看，如果 Pod 是 Static、Mirror、Critical Pod 都不驱逐。其中 Static 和 Mirror 都是从 Pod 的 annotation 中判断;而 Critical 则是通过 Pod 的 Priority 值判断的，如果 Priority 为 system-cluster-critical/system-node-critical 都属于 Critical Pod。

不过这里值得注意的是，官方文档里提及 Critical Pod 是说，如果非 Static Pod 被标记为 Critical，并不完全保证不会被驱逐：https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods 。因此，很有可能是社区并没有想清楚这种情况是否要驱逐，并不排除后面会改变这段逻辑，不过也有可能是文档没有及时更新??。

总结

本文主要分析了 Kubelet 的 Eviction Manager，包括其对 Linux CGroup 事件的监听、判断 Pod 驱逐的优先级等。了解了这些之后，我们就可以根据自身应用的重要性来设置优先级，甚至设置成 Critical Pod。

当前名称：浅析Kubelet驱逐机制
文章路径：http://www.shufengxianlan.com/qtweb/news43/57943.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

python知识

同城分类信息

seo优化排名　　 　成都400电话申请　　 　成都集团网站建设　　 　盐亭网站设计　　 　成都网站推广　　 　证企宝企业　　 　小程序开发公司　　 　Android开发　　 　网站推广公司　　 　成都商城网站建设公司　　 　四川成都做网站　　 　玄科环保　　 　木包装箱　　 　简阳电信机房　　 　做网站价格　　 　眉山网站建设　　 　四川國際商會　　 　成都网站建设公司　　 　成都网络营销　　 　达州服务器托管