k8s之Pod对象多种调度方式

💝💝💝欢迎来到我的博客，很高兴能够在这里和您见面！希望您在这里可以感受到一份轻松愉快的氛围，不仅可以获得有趣的内容和知识，也可以畅所欲言、分享您的想法和见解。

推荐:Linux运维老纪的首页,持续学习,不断总结,共同进步,活到老学到老
导航剑指大厂系列:全面总结 运维核心技术:系统基础、数据库、网路技术、系统安全、自动化运维、容器技术、监控工具、脚本编程、云服务等。
常用运维工具系列:常用的运维开发工具, zabbix、nagios、docker、k8s、puppet、ansible等
数据库系列:详细总结了常用数据库 mysql、Redis、MongoDB、oracle 技术点,以及工作中遇到的 mysql 问题等
懒人运维系列:总结好用的命令,解放双手不香吗?能用一个命令完成绝不用两个操作
数据结构与算法系列:总结数据结构和算法,不同类型针对性训练,提升编程思维,剑指大厂
非常期待和您一起在这个小小的网络世界里共同探索、学习和成长。💝💝💝 ✨✨ 欢迎订阅本专栏 ✨✨

k8s之Pod对象多种调度方式

1.Kubernetes控制器架构与事件通知机制

• Kubernetes基于list-watch机制的控制器架构，实现组件间交 互的解耦。

• 其他组件监控自己负责的资源，当这些资源发生变化时，kube-apiserver会通知这些组件，这个过程类似于发布与订阅

2.创建Pod的流程

• 用户提交创建Pod的请求，可以通过API Server的REST API ，也可用Kubectl命令行工具，支持Json和Yaml两种格式；

• API Server 处理用户请求，存储Pod数据到Etcd；

• Schedule通过和 API Server的watch机制，查看到新的pod，尝试为Pod绑定Node；

• 过滤主机：调度器用一组规则过滤掉不符合要求的主机（比如Pod指定了所需要的资源，那么就要过滤掉资源不够的主机）；

• 主机打分：对第一步筛选出的符合要求的主机进行打分，在主机打分阶段，调度器会考虑一些整体优化策略

  • 比如：把一个Replication Controller的副本分布到不同的主机上，使用最低负载的主机等；

• 选择主机：选择打分最高的主机，进行binding操作，结果存储到Etcd中；

• kubelet根据调度结果执行Pod创建操作：

  • 绑定成功后，会启动container, docker run

  • scheduler会调用API Server的API在etcd中创建一个bound pod对象，描述在一个工作节点上绑定运行的所有pod信息。

  • 运行在每个工作节点上的kubelet也会定期与etcd同步bound pod信息

  • 一旦发现应该在该工作节点上运行的bound pod对象没有更新，则调用Docker API创建并启动pod内的容器。

3.影响Pod调度的主要属性

资源限制

Node Selectors & Node Affinity

nodeSelector 匹配节点标签

用于将Pod调度到匹配Label的Node上，如果没有匹配的标签会调度失败。

作用：

• 约束Pod到特定的节点运行

• 完全匹配节点标签

应用场景：

• 专用节点：根据业务线将Node分组管理

• 配备特殊硬件：部分Node配有SSD硬盘、GPU

第一步：给k8s-node1中打标签 disktype=ssd

[root@k8s-node2 ~]# kubectl label node k8s-node1 disktype=ssd       # 将k8s-node1打一个标签为ssdnode/k8s-node1 labeled[root@k8s-node2 ~]# kubectl get node --show-labels              # 可以查看到k8s-node1节点上就有了这个标签

第二步: 添加nodeSelector字段到Pod配置中

[root@k8s-master ~]# vim pod-nodeselector.yaml  apiVersion: v1kind: Podmetadata:  name: pod-nodeselectorspec:  nodeSelector:    disktype: "ssd"  containers:  - name: web    image: nginx

第三步：验证当前节点是否按照预期部署

[root@k8s-master ~]# kubectl apply -f pod-nodeselector.yaml [root@k8s-master ~]# kubectl get pods -o wideNAME            READY   STATUS  RESTARTS   AGE    IP        NODE    NOMINATED NODE   READINESS GATESpod-nodeselector    1/1   Running    0     117s   10.244.36.74  k8s-node1   <none>         <none>

4.nodeAffinitty 匹配节点亲和性

nodeAffinity：节点亲和性，与nodeSelector作用一样，但相比更灵活，

满足更多条件，诸如：

• 匹配有更多的逻辑组合，不只是字符串的完全相等

• 调度分为软策略和硬策略，而不是硬性要求

• 硬（required）：必须满足

• 软（preferred）：尝试满足，但不保证

• 操作符：In、NotIn、Exists、DoesNotExist、Gt、

• LtTaint(污点) & Tolerations(污点容忍)

Taints：避免Pod调度到特定Node上

Tolerations：允许Pod调度到持有Taints的Node上

5.应用场景：

• 专用节点：根据业务线将Node分组管理，希望在默认情况下不调度该节点，只有配置了污点容忍才允许分配

• 配备特殊硬件：部分Node配有SSD硬盘、GPU，希望在默认情况下不调度该节点，只有配置了污点容忍才允许分配

• 基于Taint的驱逐

6.nodeName

nodeName：指定节点名称，用于将Pod调度到指定的Node上，不经过调度器

7.Pod Ant-Affinity（pod亲和性）

概念：   Pod Anti-Affinity是一种亲和性规则，用于避免Pod被调度到彼此太近的节点上。这有助于避免单点故障，提高应用的可用性。

配置：在Pod的spec中设置affinity.podAntiAffinity字段：

apiVersion: v1kind: Podmetadata:  name: with-anti-affinityspec:  affinity:    podAntiAffinity:      requiredDuringSchedulingIgnoredDuringExecution:      - labelSelector:          matchExpressions:          - key: app            operator: In            values:            - my-app        topologyKey: kubernetes.io/hostname  containers:  - name: my-container    image: my-image

8.Pod Topology Spread Constraints（pod拓扑分布约束）

概念：Pod拓扑分布约束确保Pod在集群的不同区域中均匀分布，如不同的节点、机架、区域等。

配置：在Pod的spec中设置topologySpreadConstraints字段：

apiVersion: v1kind: Podmetadata:  name: my-podspec:  topologySpreadConstraints:  - maxSkew: 1    topologyKey: kubernetes.io/hostname    whenUnsatisfiable: DoNotSchedule    labelSelector:      matchLabels:        app: my-app  containers:  - name: my-container    image: my-image

在上述配置中：

• maxSkew定义了Pod在不同拓扑域之间的最大偏差。

• topologyKey指定了用于确定Pod分布的节点标签。

• whenUnsatisfiable定义了如果分布约束无法满足时的行为。