kubernetes高级调度方式

调度方式:

  • 节点选择器: nodeSelector,nodeName
  • 节点亲和调度: nodeAffinity
  • pod亲和调度: podAffinity

♦ kubectl get nodes --show-labels  可以查看节点存在哪些标签

一、节点选择器

♦ nodeSelector选择的标签需要在node上存在,node才会被选中为pod创建的节点

下图中pod使用了nodeSelector选项过滤包含了gup=9527标签的node,然后pod就创建到了ks-node2上:

二、节点亲和调度

♦ pod.spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution   软亲和性,尽量找满足需求的

apiVersion: v1
kind: Pod
metadata:
  name: pod-node-preferaffinity
  #namespace: develop
  labels:
    app: ngx-demo
    rel: stable
spec:
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: nginx-node-preferaffinity
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - preference:
          matchExpressions:
          - key: gpu
            operator: In
            values:
            - "952"
        weight: 10

♦ pod.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution  硬亲和性,必须满足需求

[email protected]:/home/ubuntu/manifests/k8s/scheduler# cat nodeaffinity_require.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-node-requiredaffinity
  #namespace: develop
  labels:
    app: ngx-demo
    rel: stable
spec:
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: nginx-node-requiredaffinity
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: gpu
            operator: In
            values:
            - "952"

使用同样的matchExpressions来匹配label,required必须满足标签要求,否则会一直处于pending状态:

三、Pod亲和调度

♦ 使用podAffinity我们需要有一个标准来判断哪些节点属于亲和;使用topologyKey判定是否属于同一个位置

♦ pod亲和性与节点亲和性一样有prefered和required两种类型

♦ pod.spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution

[email protected]:/home/ubuntu/manifests/k8s/scheduler# cat pod_affinity_require.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-first
  #namespace: develop
  labels:
    app: ngx-demo
    rel: stable
spec:
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: nginx-1
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-podrequiredaffinity-second    # 该pod会根据第一个部署的pod标签找到亲和的机器来部署pod
  #namespace: develop
  labels:
    app: ngx-demo
    rel: stable
spec:
  containers:
  - image: tomcat
    imagePullPolicy: IfNotPresent
    name: tomcat-podrequiredaffinity
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:  # 这里匹配的是第一个pod的标签,所以key/values应该是想要pod部署的在一起的label
          - key: app
            operator: In
            values:
            - "ngx-demo"
        topologyKey: kubernetes.io/hostname      #使用的hostname来判断是否在同一位置,也可以使用其它自定义的标签

♦ pod.spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution

[email protected]:/home/ubuntu/manifests/k8s/scheduler# cat pod_affinity_prefer.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-first
  #namespace: develop
  labels:
    app: ngx-demo
    rel: stable
spec:
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: nginx-1
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-podrequiredaffinity-second
  #namespace: develop
  labels:
    app: ngx-demo
    rel: stable
spec:
  containers:
  - image: tomcat
    imagePullPolicy: IfNotPresent
    name: tomcat-podrequiredaffinity
  affinity:
    podAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - "ngx-demo"
          topologyKey: kubernetes.io/hostname      #可以使用自定义label
        weight: 60

♦ pod.spec.affinity.podAntiAffinity  反亲和性,创建的pod不会在一起,反亲和性也有prefered和required两种类型

apiVersion: v1
kind: Pod
metadata:
  name: pod-first
  #namespace: develop
  labels:
    app: ngx-demo
    rel: stable
spec:
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: nginx-1
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-podrequired_anti_affinity-second
  #namespace: develop
  labels:
    app: ngx-demo
    rel: stable
spec:
  containers:
  - image: tomcat
    imagePullPolicy: IfNotPresent
    name: tomcat-podrequired_anti_affinity
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - "ngx-demo"
        topologyKey: kubernetes.io/hostname 

四、污点调度

taint --- 污点就是定义在节点上的键值属性

taintToleration --- 容忍度是定义在pod上的键值属性,是一个列表

  • 标签   可定义在所有资源
  • 注解   可定义在所有资源
  • 污点   只能定义在节点上

taint的effect定义对pod的排斥效果:

  • NoSchedule:仅影响调度过程,对现存的pod不影响
  • NoExecute: 既影响调度,也影响现存pod;不满足容忍的pod对象将被驱逐
  • PreferNoSchedule:尽量不调度,实在没地方运行也可以

♦  如果一个节点上定义了污点,一个pod能否调上来,我们先去检查能够匹配的容忍度和污点;剩余不能被容忍的污点就去检查污点的effect,

  如果是PreferNoSchedule,还是能调度;

  如果是NoSchedule,还没调度的就不能被调度,已经调度完的没影响;

  如果是NoExecute,完全不能被调度,如果此前有运行的pod,后来改了污点,pod将被驱逐

♦  kubectl taint --help  打污点标签

  kubectl taint node k8s-node2 node-type=prod:NoSchedule  给k8s-node2打上prod环境标签,effect为NoSchedule

  kubectl taint node k8s-node2 node-type-   移除所有key为node-type的污点

  kubectl taint node k8s-node2 node-type:NoSchedule-  移除所有key为node-type中effect为NoSchedule的污点

示例:我们首先使用反亲和性特点使得nginx和tomcat的pod不能在同一个node上被创建,然后再tomcat中设置容忍度满足k8s-master节点的污点(默认情况下,master节点是不能被创建普通pod的)

[email protected]:/home/ubuntu/manifests/k8s/scheduler# cat pod_toleration_master_taint.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-first
  #namespace: develop
  labels:
    app: ngx-demo
    rel: stable
spec:
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: nginx-1
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-toleration-master-taint-second
  #namespace: develop
  labels:
    app: ngx-demo
    rel: stable
spec:
  containers:
  - image: tomcat
    imagePullPolicy: IfNotPresent
    name: tomcat-toleration-master-taint
  tolerations:  # 设置容忍度 可以容忍master节点NoSchedule
  - effect: NoSchedule  # 如果effect为空,则表示容忍所有的
    key: node-role.kubernetes.io/master    operator: Exists
  affinity:
    podAntiAffinity:  #反亲和性使得tomat的pod不能和nginx在同一个pod上
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - "ngx-demo"
        topologyKey: kubernetes.io/hostname 

最终结果使得tomcat的pod可以被调度到master节点:

原文地址:https://www.cnblogs.com/alamisu/p/11318470.html

时间: 2024-10-09 10:41:14

kubernetes高级调度方式的相关文章

Kubernetes 学习21 kubernetes高级调度方式

一.概述 1.上集讲了Scheduler在实现调度时分三步实现调度过程.首先是预选,即从所有节点中选择基本符合选择条件的节点.而后在基本符合条件的节点中使用优选函数计算他们各自的得分并加以比较.并从最高得分的节点中随机选择出一个运行pod的节点,这就是我们的控制平面中scheduler所实现负责的主要功用.同时如果在某些调度场景中我们期望能够通过自己的预设去影响他的一些调度方式,比如就是把我们的pod运行在某些特定的节点之上的时候可以通过自己的预设操作去影响他的预选和优选过程从而使得调度操作能符

kubernetes高级调度简单说明

Node label使用说明 1.查看node label kubectl get nodes --show-labels=true 2.创建label kubectl label node $(node_name) $key=$value 3.更新label kubectl label --overwrite node $(node_name) $key=$value 4.删除 kubectl label node $(node_name) $key- Node调度几种模式 首先看一下,我测试

kubernetes高级之动态准入控制

系列目录 动态准入控制器文档介绍了如何使用标准的,插件式的准入控制器.但是,但是由于以下原因,插件式的准入控制器在一些场景下并不灵活: 它们需要编译到kube-apiserver里 它们仅在apiserver启动的时候可以配置 准入钩子(Admission Webhooks 从1.9版本开始)解决了这些问题,它允许准入控制器独立于核心代码编译并且可以在运行时配置. 什么是准入钩子 准入钩子是一种http回调,它接收准入请求然后做一些处理.你可以定义两种类型的准入钩子:验证钩子和变换钩子.对于验证

Kubernetes高级进阶之多维度弹性伸缩

**基于Kubernetes的多维度的弹性伸缩** 目录:2.1 传统弹性伸缩的困境2.2 kubernetes 弹性伸缩布局2.3 Node 自动扩容/缩容2.4 pod自动扩容/缩容 (HPA)2.5 基于CPU指标缩放2.6 基于prometheus自定义指标缩放 2.1 传统伸缩的困境从传统意义上,弹性伸缩主要解决的问题是容量规划与实际负载的矛盾蓝色水位线表示集群资源容量随着负载的增加不断扩容,红色曲线表示集群资源实际负载变化.弹性伸缩就是要解决当实际负载增加,而集群资源容量没来得及反应

Kubernetes高级进阶之pod的自动扩容/缩容

目录:实践1:基于autoscaling cpu指标的扩容与缩容实践2:基于prometheus自定义指标QPS的扩容与缩容 Pod自动扩容/缩容(HPA) Horizontal Pod Autoscaler(HPA,Pod水平自动伸缩),根据资源利用率或者自定义指标自动调整replication controller, deployment 或 replica set,实现部署的自动扩展和缩减,让部署的规模接近于实际服务的负载.HPA不适于无法缩放的对象,例如DaemonSet. HPA主要是

使用Istio治理微服务入门

近两年微服务架构流行,主流互联网厂商内部都已经微服务化,初创企业虽然技术积淀不行,但也通过各种开源工具拥抱微服务.再加上容器技术赋能,Kubernetes又添了一把火,微服务架构已然成为当前软件架构设计的首选.但微服务化易弄,服务治理难搞! 一.微服务的"痛点" 微服务化没有统一标准,多数是进行业务领域垂直切分,业务按一定的粒度划分职责,并形成清晰.职责单一的服务接口,这样每一块规划为一个微服务.微服务之间的通信方案相对成熟,开源领域选择较多的有RPC或RESTful API方案,比如

Serverless 与容器决战在即?有了弹性伸缩就不一样了

作者 | 阿里云容器技术专家 莫源?本文整理自莫源于 8 月 31 日?K8s & cloudnative meetup 深圳场的演讲内容.关注"阿里巴巴云原生"公众号,回复关键词 "资料" ,即可获得 2019 全年 meetup 活动 PPT 合集及 K8s 最全知识图谱. 导读:Serverless 和 Autoscaling 是近些年来广大开发者非常关心的内容.有人说 Serverless 是容器 2.0,终有一天容器会和 Serverless 进行

深入解析 Kubebuilder:让编写 CRD 变得更简单

作者 | 刘洋(炎寻) 阿里云高级开发工程师 导读:自定义资源 CRD(Custom Resource Definition)可以扩展 Kubernetes API,掌握 CRD 是成为 Kubernetes 高级玩家的必备技能,本文将介绍 CRD 和 Controller 的概念,并对 CRD 编写框架 Kubebuilder 进行深入分析,让您真正理解并能快速开发 CRD. 概览 控制器模式与声明式 API 在正式介绍 Kubebuidler 之前,我们需要先了解下 K8s 底层实现大量使用

kubernter相关内容

1. Kubernetes 第一章:互联网架构的演变 随着1946年世界上第一台电子计算机的问世网络就随之出现了,只不过当初只是为了解决多个终端之间的连接,这就是局域网的雏形.后来,随着美国国防部高级研究计划局(ARPA)的无线.卫星网的分组交换技术的研究问世,一不小心搞出了TCP/IP,由此出现了我们所熟知的Internet互联网. 早期的电脑体积大,价格昂贵,一般只用在科学研究领域,后来随着集成电路,半导体的发展,电脑逐渐出现在我们的日常生活中.由此,我们对互联网的依赖越来越多,到现在已经成