Kubernetes亲和性学习笔记

kubernetes,亲和性,学习,笔记 · 浏览次数 : 337

小编点评

**欣宸的 Kubernetes 调度过程** **步骤:** 1. **预选(Predicates)** - 确定节点亲和性。 2. **优选(Priorities)** - 考虑节点亲和性和pod亲和性。 3. **选择(Select)** - 选择满足优先级的所有节点。 4. **亲和性排序(Affinity Sort)** - 对节点亲和性和pod亲和性进行排序。 5. **执行调度** - 根据亲和性排序的顺序,调度节点和pod。 **亲和性** * **节点亲和性:**用于指定节点上可匹配的pod的节点类型。 * **pod亲和性:**用于指定pod在任何节点上可匹配的节点类型。 **优先级** * **NodeAffinityPriority:**使用节点亲和性来分配节点。 * **SelectorSpreadPriority:**使用pod亲和性来分配节点。 **反亲和** * **pod Anti-Affinity:**使用反亲和性来指定节点上不可匹配的节点。 **其他** * **topologyKey:**用于指定节点上可匹配的pod的标签或属性。 * **matchExpressions:**用于指定如何匹配节点亲和性。

正文

欢迎访问我的GitHub

这里分类和汇总了欣宸的全部原创(含配套源码):https://github.com/zq2599/blog_demos

本篇概览

  • 本文是欣宸在学习Kubernetes调度器的过程中,对亲和性相关知识点的整理和总结,这是一篇笔记性质的博客

kubernetes默认调度器的调度过程:

  • 调度过程如下:
  1. 预选(Predicates)
  2. 优选(Priorities)
  3. 选定(Select)

亲和性一览

  • 这里将亲和性先分类,便于理解
graph LR A(亲和性)-->B1(节点亲和性); A-->B2(Pod亲和性); B1-->C1(硬亲和性-required); B1-->C2(软亲和性-preferred); B2-->C3(硬亲和性-required); B2-->C4(软亲和性-preferred); B2-->C5(反亲和性);

节点亲和性和pod亲和性的区别

  • 举个例子,假设给小明分配班级(小明是pod,班级是节点)
  1. 节点亲和性:直接告诉小明,你去一年级

  2. pod亲和性:从小朋友中找出和小明同年的,找到了小张,发现小张是一年级的,于是让小明去一年级

节点亲和性:硬亲和性

  • requiredDuringSchedulinglgnoredDuringExecution:用于定义节点硬亲和性

  • nodeSelectorTerm:节点选择器,可以有多个,之间的关系是逻辑或,即一个nodeSelectorTerm满足即可

  • matchExpressions:匹配规则定义,多个之间的关系是逻辑与,即同一个nodeSelectorTerm下所有matchExpressions定义的规则都匹配,才算匹配成功

  • 示例:

apiVersion: v1
kind: Pod
metadata:
  name: with-required-nodeaffinity
spec:
  affinity:
    nodeAffinity: 
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - {key: zone, operator: In, values: ["foo"]}
  containers:
  - name: nginx
    image: nginx
  • 功能与nodeSelector类似,用的是匹配表达式,可以被理解为新一代节点选择器
  • 不满足硬亲和性条件时,pod为Pending状态
  • 在预选阶段,节点硬亲和性被用于预选策略MatchNodeSelector

节点亲和性:软亲和性

  • 特点:条件不满足时也能被调度

  • 示例:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deploy-with-node-affinity
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 60
            preference:
              matchExpressions:
              - {key: zone, operator: In, values: ["foo"]}
          - weight: 30
            preference:
              matchExpressions:
              - {key: ssd, operator: Exists, values: []}
      containers:
      - name: nginx
        image: nginx
  • 集群中的节点,由于标签不同,导致的优先级结果如下:

image-20220228154031823

  • 在优选阶段,节点软亲和性被用于优选函数NodeAffinityPriority

  • 注意:NodeAffinityPriority并非决定性因素,因为优选阶段还会调用其他优选函数,例如SelectorSpreadPriority(将pod分散到不同节点以分散节点故障导致的风险)

  • pod副本数增加时,分布的比率会参考节点亲和性的权重

Pod亲和性(podAffinity)

  • 如果需求是:新增的pod要和已经存在pod(假设是A)在同一node上,此时用节点亲和性是无法完成的,因为A可能和节点没啥关系(可能是随机调度的),此时只能用pod亲和性来实现

  • pod亲和性:一个pod与已经存在的某个pod的亲和关系,需要通过举例来说明

  1. 创建一个deployment,这个pod有标签app=tomcat
kubectl run tomcat -l app=tomcat --image tomcat:alpine
  1. 创建pod,需求是和前面的pod在一起,使用pod亲和性来实现:
apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity-1
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - {key: app, operator: In, values: ["tomcat"]}
        topologyKey: kubernetes.io/hostname
  containers:
  - name: nginx
    image: nginx
  1. 调度逻辑:
graph TD A[1. 用matchExpressions的规则app=tomcat搜索] -->B(2. 找到tomcat的pod,也就确定了该pod的节点,假设是A节点) B --> C(3. topologyKey是kubernetes.io/hostname,所以去找A节点kubernetes.io/hostname标签的值,假设是xxx) C --> D(4. 将新的pod调度到kubernetes.io/hostname=xxx的节点)
  1. 表面上看,最终只是根据hostname去调度的,但如果topologyKey的值是多个节点所拥有的,就更有通用性了,如下图,topologyKey等于filure-domain.beta.kubernetes.io/zone:

image-20220228163933279

  • 硬亲和:requiredDuringSchedulingIgnoredDuringExecution
  • 软亲和:preferredDuringSchedulingIgnoredDuringExecution

Pod反亲和(podAntiAffinity)

  • 与亲和性相反,将当前pod调度到满足匹配条件之外的节点上
  • 适用场景:
  1. 分散同一类应用
  2. 将不同安全级别的pod调度至不同节点
  • 示例如下,匹配表达式和自身标签一致,作用是分散同一类应用,让相同pod不要调度到同一个节点:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-with-pod-anti-affinity
spec:
  replicas: 4
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      name: myapp
      labels:
        app: myapp
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - {key: app, operator: In, values: ["myapp"]}
            topologyKey: kubernetes.io/hostname
      containers:
      - name: nginx
        image: nginx
  • 如果集群中只有三个节点,那么执行上述yaml的结果就是最多创建三个pod,另一个始终处于pending状态

参考

欢迎关注博客园:程序员欣宸

学习路上,你不孤单,欣宸原创一路相伴...

与Kubernetes亲和性学习笔记相似的内容:

Kubernetes亲和性学习笔记

学习kubernetes亲和性的关键知识点

[转帖]k8s 污点和容忍

文章目录 污点和容忍污点(Taints)查看污点:设置污点删除污点 容忍 (toleratints)Pod 设置容忍设置容忍时间容忍示例 节点自污染,pod 应对节点故障 污点和容忍 在 Kubernetes 中,节点亲和性 NodeAffinity 是 Pod 上定义的一种属性,能够使 Pod 按

[转帖]Kubernetes-15:一文详解Pod、Node调度规则(亲和性、污点、容忍、固定节点)

https://www.cnblogs.com/v-fan/p/13609124.html Kubernetes Pod调度说明 简介 Scheduler 是 Kubernetes 的调度器,主要任务是把定义的Pod分配到集群的节点上,听起来非常简单,但要考虑需要方面的问题: 公平:如何保证每个节点

Kubernetes Pod调度:从基础到高级实战技巧

本文深入探讨了Kubernetes中的Pod调度机制,包括基础概念、高级调度技术和实际案例分析。文章详细介绍了Pod调度策略、Taints和Tolerations、节点亲和性,以及如何在高流量情况下优化Pod调度和资源管理。 关注【TechLeadCloud】,分享互联网架构、云服务技术的全维度知识

改造 Kubernetes 自定义调度器

原文出处:改造 Kubernetes 自定义调度器 | Jayden's Blog (jaydenchang.top) Overview Kubernetes 默认调度器在调度 Pod 时并不关心特殊资源例如磁盘、GPU 等,因此突发奇想来改造调度器,在翻阅官方调度器框架[1]、调度器配置[2]和参

Kubernetes 数据存储:从理论到实践的全面指南

本文深入解析 Kubernetes (K8S) 数据存储机制,探讨其架构、管理策略及最佳实践。文章详细介绍了 K8S 数据存储的基础、架构组成、存储卷管理技巧,并通过具体案例阐述如何高效、安全地管理数据存储,同时展望了未来技术趋势。 关注【TechLeadCloud】,分享互联网架构、云服务技术的全

Kubernetes 审计(Auditing)

Kubernetes 审计(Auditing),Kubernetes 审计简介,审计策略简介,引入审计,启用审计,记录审计阶段为:ResponseStarted,审计级别为Metadata,apiVersion为group: "" 的日志,只记录audit命名空间里的日志,只记录audit命名空间的...

Kubernetes容器生命周期 —— 钩子函数详解(postStart、preStop)

1、概述 容器生命周期钩子(Container Lifecycle Hooks)监听容器生命周期的特定事件,并在事件发生时执行已注册的回调函数。 钩子函数能够感知自身生命周期中的事件,并在相应的时刻到来时运行用户指定的程序代码。 kubernetes在主容器的启动之后和停止之前提供了两个钩子函数:

详解Kubernetes Pod优雅退出

1、概述 Pod优雅关闭是指在Kubernetes中,当Pod因为某种原因(如版本更新、资源不足、故障等)需要被终止时,Kubernetes不会立即强制关闭Pod,而是首先尝试以一种“优雅”的方式关闭Pod。这个过程允许Pod中的容器有足够的时间来响应终止信号(默认为SIGTERM),并在终止前完成

在kubernetes里使用seccomp限制容器的系统调用

在kubernetes里使用seccomp限制容器的系统调用,Secure Computing Mode,系统调用,使用seccomp限制docker容器系统调用,strace -fqc,SCMP_ACT_ALLOW,SCMP_ACT_LOG,SCMP_ACT_ERRNO,配置seccomp允许po...