影响K8S Pod分配和调度策略的两大关键特性

标签: k8s pod 调度 | 发表时间:2020-01-22 10:44 | 作者:Rancher
出处:http://weekly.dockone.io

在Kubernetes中有一个最复杂的调度器可以处理pod的分配策略。基于在pod规范中所提及的资源需求,Kubernetes调度器会自动选择最合适的节点来运行pod。

但在许多实际场景下,我们必须干预调度过程才能在pod和一个节点或两个特定pod之间进行匹配。因此,Kubernetes中有一种十分强大的机制来管理及控制pod的分配逻辑。

那么,本文将探索影响Kubernetes中默认调度决定的关键特性。

节点亲和性/反亲和性

Kubernetes一向以来都是依赖label和selector来对资源进行分组。例如,某服务使用selector来过滤具有特定label的pod,这些label可以选择性地接收流量。Label和selector可以使用简单的基于等式的条件(=and!=)来评估规则。通过nodeSelector的特性(即强制将pod调度到特定节点上),可以将这一技术扩展到节点中。



此外,label和selector开始支持基于集合的query,它带来了基于in、notin和exist运算符的高级过滤技术。与基于等式的需求相结合,基于集合的需求提供了复杂的技术来过滤Kubernetes中的资源。

节点亲和性/反亲和性使用label和annotation的基于表达集的过滤技术来定义特定节点上的pod的分配逻辑。Annotation可以提供不会暴露到selector的其他元数据,这意味着用于annotation的键不会包含在query和过滤资源中。但是节点亲和性可以在表达式中使用annotation。反亲和性可以确保pod不会被强制调度到与规则匹配的节点上。

除了能够在query中使用复杂的逻辑之外,节点亲和性/反亲和性能够为分配逻辑强制施加硬性和软性规则。硬性规则将会执行严格的策略,可能会阻止将pod分配到不符合条件的节点上。而软性规则则会首先确认节点是否与特定的条件相匹配,如果它们不匹配,它将使用默认的调度模式来分配Pod。表达式 requiredDuringSchedulingIgnoredDuringExecutionpreferredDuringSchedulingIgnoredDuringExecution 将会分别执行硬性规则和软性规则。

以下是在硬性和软性规则下使用节点亲和性/反亲和性的示例:
affinity:  
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
  nodeSelectorTerms:
    - matchExpressions:
      - key: "failure-domain.beta.kubernetes.io/zone"
        operator: In
        values: ["asia-south1-a"]


以上规则将指示Kubernetes调度器尝试将Pod分配到在GKE集群的asia-south1-a区域中运行的节点上。如果没有可用的节点,则调度器将会直接应用标准的分配逻辑。
affinity:  
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
  nodeSelectorTerms:
    - matchExpressions:
      - key: "failure-domain.beta.kubernetes.io/zone"
        operator: NotIn


以上规则通过使用NotIn运算符来强制执行反亲和性。这是一个硬性规则,它能够确保没有pod被分配到运行在asia-south1-a空间中的GKE节点。

Pod亲和性/反亲和性

尽管节点亲和性/反亲和性能够处理pod和节点之间的匹配,但是有些场景下我们需要确保pod在一起运行或在相同的节点上不运行2个pod。Pod亲和性/反亲和性将帮助我们应用强制实施粒度分配逻辑。

与节点亲和性/反亲和性中的表达式类似,pod亲和性/反亲和性也能够通过 requiredDuringSchedulingIgnoredDuringExecutionpreferredDuringSchedulingIgnoredDuringExecution 强制实施硬性以及软性规则。还可以将节点亲和性与pod亲和性进行混合和匹配,以定义复杂的分配逻辑。

为了能够更好地理解概念,想象一下我们有一个web和缓存deployment,其中三个副本在一个3节点的集群中运行。为了确保在web和缓存pod之间低延迟,我们想要在用一个节点上运行它们。与此同时,我们不想在相同的节点上运行超过1个缓存pod。基于此情况,我们需要实施以下策略:每个节点仅运行1个且只有1个缓存Pod的web pod。

首先,我们将使用反亲和性规则来部署缓存,它将阻止超过1个pod运行在1个节点上:
affinity:  
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - redis
        topologyKey: "kubernetes.io/hostname"


topoloyKey使用附加到节点的默认label动态过滤节点的名称。请注意,我们使用podAntiAffinity表达式和in运算符来应用规则的方式。

假设在集群的某个节点上安排了3个pod缓存,那么现在我们想要在与缓存Pod相同的节点上部署web pod。我们将使用podAffinity来实施这一逻辑:
podAffinity:  
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - redis
        topologyKey: "kubernetes.io/hostname"


以上代码表明Kubernetes调度器要寻找有缓存Pod的节点并部署web pod。

除了节点和pod的亲和性/反亲和性之外,我们还能使用taints和tolerations来定义自定义分配逻辑。此外,我们还能写自定义调度程序,它可以从默认的调度程序中接管调度逻辑。

相关 [k8s pod 调度] 推荐:

影响K8S Pod分配和调度策略的两大关键特性

- - DockOne.io
在Kubernetes中有一个最复杂的调度器可以处理pod的分配策略. 基于在pod规范中所提及的资源需求,Kubernetes调度器会自动选择最合适的节点来运行pod. 但在许多实际场景下,我们必须干预调度过程才能在pod和一个节点或两个特定pod之间进行匹配. 因此,Kubernetes中有一种十分强大的机制来管理及控制pod的分配逻辑.

深入掌握K8S Pod - Yabea - 博客园

- -
K8S configmap介绍. Pod是k8s中最小的调度单元,包含了一个“根容器”和其它用户业务容器. 如果你使用过k8s的话,当然会了解pod的基本使用,但是为了更好的应用,你需要深入了解pod的配置、调度、升级和扩缩容等. pod包含一个或多个相对紧密耦合的容器,处于同一个pod中的容器共享同样的存储空间、IP地址和Port端口.

k8s外网如何访问业务应用之Service 池化pod

- - IT瘾-geek
一、废话:先讲述一个k8s重要概念,我觉得这个概念是整个k8s集群实现微服务的最核心的概念. Service定义了Pod的逻辑集合和访问该集合的策略,是真实服务的抽象. Service提供了一个统一的服务访问入口以及服务代理和发现机制,用户不需要了解后台Pod是如何运行. 只需要将一组跑同一服务的pod池化成一个service,k8s集群会自动给这个service分配整个集群唯一ip和端口号(这个端口号自己在yaml文件中定义),一个service定义了访问pod的方式,就像单个固定的IP地址和与其相对应的DNS名之间的关系.

在 k8s 中对指定 Pod 进行抓包

- -
Distributed Tracing时,遇到了一些问题,需要深入到底层去进行网络抓包分析报文. 但是应用时运行在 k8s 集群中的,与传统的在一台机器上跑一个进程直接通过 tcpdump 抓包方式略有不同. 最初对容器的理解不深刻认为一定要进入到这个容器抓包,而进入容器内并没有 tcpdump 等基础工具,相当于自己还是把容器当作虚拟机在看待.

k8s 部署 skywalking 并将 pod 应用接入链路追踪

- - SegmentFault 最新的文章
前面写了两篇文章介绍使用 docker 部署 spring boot 和 tomcat 项目,并将其接入skywalking,这篇文章主要介绍使用 k8s 部署 skywalking 并将 pod 应用接入链路追踪. 二、使用 helm 部署 skywalking. 在 k8s 中使用 helm 的前提是需要先安装 helm 客户端,关于 helm 的安装可以查看官方文档.

k8s资源需求和限制, 以及pod驱逐策略 - ainimore - 博客园

- -
requests:需求,最低保障, 保证被调度的节点上至少有的资源配额 limits:限制,硬限制, 容器可以分配到的最大资源配额. 如果Pod中所有Container的所有Resource的limit和request都相等且不为0,则这个Pod的QoS Class就是Guaranteed. 注意,如果一个容器只指明了limit,而未指明request,则表明request的值等于limit的值.

CentOS7 安装 K8S

- - 企业架构 - ITeye博客
前提:VirtualBox CentOS7. 物理机IP   192.168.18.8. 虚拟机1IP:192.168.18.100(VMaster master). 虚拟机2IP:192.168.18.101(VServer1 node1). 虚拟机3IP:192.168.18.102(VServer2 node2).

Kubernetes:玩转 Pod 滚动更新

- - IT瘾-dev
今天推荐一篇关于Kubernetes上服务滚动更新相关的配置选项的文章,文章列出了最常用的几个配置项,解释了他们是怎么影响调度器对服务进行滚动更新的,同时还带出了 Kubernetes项目中 Pod这个逻辑单元的 Ready状态是怎么确定的,并不是容器运行起来后 Pod就进入 Ready状态的.

解决Kubernetes Pod故障的5个简单的技巧

- - DockOne.io
——轻松地解决Kubernetes应用程序的故障并理解其机制. 在很多情况下,你可能会发现Kubernetes中的应用程序没有正确地部署,或者没有正常地工作. 今天这篇文章就提供了如何去快速解决这类故障以及一些技巧. 在阅读了这篇文章之后,你还将深入了解Kubernetes的内部机制,另外,我还将与大家分享一些关于自己操作K8S的一些非常有用的技巧.

监控 Pod 时,我们在监控什么

- - DockOne.io
应用 Kubernetes 化已经开始推进了一段时间,监控系统也提供了 Kubernetes Pod 相关的监控指标和警报规则. 由于 Kubernetes 和传统的物理机/虚拟机是完全不同的运行环境,因此监控系统提供的监控指标也存在一定的区别. 虽然我们已经尽量统一不同平台的差异,但是日常工作中仍会收到用户对 Kubernetes 监控指标的反馈.