Kubernetes之Pod调度-低调大师

Kubernetes之Pod调度

2018-12-13 576

Kubernetes调度器根据特定的算法与策略将pod调度到工作节点上。在默认情况下，Kubernetes调度器可以满足绝大多数需求，例如调度pod到资源充足的节点上运行，或调度pod分散到不同节点使集群节点资源均衡等。但一些特殊的场景，默认调度算法策略并不能满足实际需求，例如使用者期望按需将某些pod调度到特定硬件节点(数据库服务部署到SSD硬盘机器、CPU/内存密集型服务部署到高配CPU/内存服务器），或就近部署交互频繁的pod（例如同一机器、同一机房、或同一网段等）。

Kubernetes中的调度策略主要分为全局调度与运行时调度2种。其中全局调度策略在调度器启动时配置，而运行时调度策略主要包括选择节点（nodeSelector），节点亲和性（nodeAffinity），pod亲和与反亲和性（podAffinity与podAntiAffinity）。Node Affinity、podAffinity/AntiAffinity以及后文即将介绍的污点(Taints）与容忍（tolerations）等特性，在Kuberntes1.6中均处于Beta阶段。

本文着重介绍运行时调度策略。

设置节点label

Label是Kubernetes核心概念之一，其以key/value的形式附加到各种对象上，如Pod、Service、Deployment、Node等，达到识别这些对象，管理关联关系等目的，如Node和Pod的关联。
获取当前集群中的全部节点:

kubectl get nodes

为指定节点设置label:

kubectl label nodes <node-name> <label-key>=<label-value>

确认节点label是否设置成功:

kubectl get nodes -l ‘label_key=label_value’

选择节点（nodeSelector）

nodeSelector是目前最为简单的一种pod运行时调度限制，目前在Kubernetes1.7.x及以下版本可用。Pod.spec.nodeSelector通过kubernetes的label-selector机制选择节点，由调度器调度策略匹配label，而后调度pod到目标节点，该匹配规则属于强制约束。后文要讲的nodeAffinity具备nodeSelector的全部功能，所以未来Kubernetes会将nodeSelector废除。

nodeSelector举例：

设置label

$ kubectl label nodes bjo-rpt-re-002.dev.fwmrm.net disktype=ssd
node "bjo-rpt-re-002.dev.fwmrm.net" labeled

查看满足非master节点且disktype类型为ssd的节点：

kubectl get nodes -l 'role!=master, disktype=ssd'
NAME STATUS AGE VERSION
bjo-rpt-re-002.dev.fwmrm.net Ready 39d v1.7.1

pod.yaml文件内容：

apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers: - name: nginx
image: nginx
imagePullPolicy: IfNotPresent
nodeSelector:
disktype: ssd

创建pod：

kubectl create -f pod.yaml

查看pod nginx被调度到预期节点运行：

$ kubectl get po nginx -o wide
NAME READY STATUS RESTARTS AGE IP NODE
nginx 1/1 Running 0 10s 10.244.3.13 bjo-rpt-re-002.dev.fwmrm.net

注：如果非默认namespace，需要指定具体namespace，例如:

kubectl -n kube-system get pods -o wide

内置节点label

Kubernetes自v1.4开始，节点有一些built-in label，罗列如下：

kubernetes.io/hostname
failure-domain.beta.kubernetes.io/zone
failure-domain.beta.kubernetes.io/region
beta.kubernetes.io/instance-type
beta.kubernetes.io/os
beta.kubernetes.io/arch

built-in label举例

yaml文件内容：

apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers: - name: nginx
image: nginx
imagePullPolicy: IfNotPresent
nodeSelector:
kubernetes.io/hostname: bjo-ep-svc-017.dev.fwmrm.net

创建pod，并检查结果符合预期，pod被调度在预先设置的节点 bjo-ep-svc-017.dev.fwmrm.net：

$ kubectl get po nginx -o wide
NAME READY STATUS RESTARTS AGE IP NODE
nginx 1/1 Running 0 3m 10.244.1.58 bjo-ep-svc-017.dev.fwmrm.net

亲和性（Affinity）与非亲和性（anti-affinity）

前面提及的nodeSelector，其仅以一种非常简单的方式、即label强制限制pod调度到指定节点。而亲和性（Affinity）与非亲和性（anti-affinity）则更加灵活的指定pod调度到预期节点上，相比nodeSelector，Affinity与anti-affinity优势体现在：

表述语法更加多样化，不再仅受限于强制约束与匹配。
调度规则不再是强制约束（hard），取而代之的是软限（soft）或偏好（preference）。
指定pod可以和哪些pod部署在同一个/不同拓扑结构下。

亲和性主要分为3种类型：node affinity与inter-pod affinity/anti-affinity，下文会进行详细说明。

节点亲和性（Node affinity）

Node affinity在Kubernetes 1.2做为alpha引入，其涵盖了nodeSelector功能，主要分为requiredDuringSchedulingIgnoredDuringExecution与preferredDuringSchedulingIgnoredDuringExecution 2种类型。前者可认为一种强制限制，如果 Node 的标签发生了变化导致其没有符合 Pod 的调度要求节点，那么pod调度就会失败。而后者可认为理解为软限或偏好，同样如果 Node 的标签发生了变化导致其不再符合 pod 的调度要求，pod 依然会调度运行。

Node affinity举例

设置节点label：

$ kubectl label nodes bjo-ep-dep-040.dev.fwmrm.net cpu=high
node "bjo-ep-dep-040.dev.fwmrm.net" labeled

$ kubectl label nodes bjo-ep-svc-017.dev.fwmrm.net cpu=mid
node "bjo-ep-svc-017.dev.fwmrm.net" labeled

$ kubectl label nodes bjo-rpt-re-002.dev.fwmrm.net cpu=low
node "bjo-rpt-re-002.dev.fwmrm.net" labeled

部署pod的预期是到非master节点（role!=master）、且CPU高配的机器上(cpu=high)。
查看满足条件节点：

$ kubectl get nodes -l 'cpu=high, role!=master'
NAME STATUS AGE VERSION
bjo-ep-dep-040.dev.fwmrm.net Ready 41d v1.7.1

pod.yaml文件内容如下：

apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
affinity:
nodeAffinity:
 requiredDuringSchedulingIgnoredDuringExecution:
 nodeSelectorTerms: - matchExpressions: - key: role
 operator: NotIn
 values: - master
 preferredDuringSchedulingIgnoredDuringExecution: - weight: 1
 preference:
 matchExpressions: - key: cpu
 operator: In
 values: - high
containers: - name: nginx
image: nginx
imagePullPolicy: IfNotPresent

检查结果符合预期，pod nginx成功部署到非master节点且CPU高配的机器上。

$ kubectl get po nginx -o wide
NAME READY STATUS RESTARTS AGE IP NODE
nginx 1/1 Running 0 32s 10.244.2.185 bjo-ep-dep-040.dev.fwmrm.net

pod亲和性（Inter-pod affinity）与反亲和性（anti-affinity）

inter-pod affinity与anti-affinity由Kubernetes 1.4引入，当前处于beta阶段，其中podAffinity用于调度pod可以和哪些pod部署在同一拓扑结构之下。而podAntiAffinity相反，其用于规定pod不可以和哪些pod部署在同一拓扑结构下。通过pod affinity与anti-affinity来解决pod和pod之间的关系。
与Node affinity类似，pod affinity与anti-affinity同样分为requiredDuringSchedulingIgnoredDuringExecution and preferredDuringSchedulingIgnoredDuringExecution等2种类型，前者被认为是强制约束，而后者后者可认为理解软限（soft）或偏好（preference）。

pod affinity与anti-affinity举例

本示例中假设部署场景为：期望is服务与oltp服务就近部署，而不希望与solr服务部署同一拓扑结构上。
yaml文件部分内容：

spec:
replicas: 1 template:
metadata:
 labels:
 app: is

spec:
 affinity:
 podAffinity:
 requiredDuringSchedulingIgnoredDuringExecution: - labelSelector:
 matchExpressions: - key: app
 operator: NotIn
 values: - solr
 topologyKey: kubernetes.io/hostname
 podAntiAffinity:
 preferredDuringSchedulingIgnoredDuringExecution: - weight: 1
 podAffinityTerm:
 labelSelector:
 matchExpressions: - key: app
 operator: In
 values: - oltp
 topologyKey: beta.kubernetes.io/os

查看部署结果，is服务与oltp部署到了同一台机器，而solr被部署在其他机器上。

$ kubectl get po -o wide
NAME READY STATUS RESTARTS AGE IP NODE
is-3059482752-5s14t 0/1 Running 1 1m 10.244.1.60 bjo-ep-svc-017.dev.fwmrm.net
oltp-282283610-kdvnp 1/1 Running 0 1m 10.244.1.53 bjo-ep-svc-017.dev.fwmrm.net
solr-908150957-rswlm 1/1 Running 0 1m 10.244.3.5 bjo-rpt-re-002.dev.fwmrm.net

亲和性/反亲和性调度策略比较

调度策略 匹配标签 操作符 拓扑域支持 调度目标
nodeAffinity 主机 In, NotIn, Exists, 否 pod到指定主机 DoesNotExist, Gt, Lt 
podAffinity Pod In, NotIn, Exists, 是 pod与指定pod同一拓扑域 DoesNotExist PodAntiAffinity Pod In, NotIn, Exists, 是 pod与指定pod非同一拓扑域 DoesNotExist

污点（Taints）与容忍（tolerations）

对于Node affinity，无论是强制约束（hard）或偏好（preference）方式，都是调度pod到预期节点上，而Taints恰好与之相反，如果一个节点标记为 Taints ，除非 Pod也被标识为可以耐受污点节点，否则该Taints节点不会被调度pod。Taints）与tolerations当前处于beta阶段，
Taints节点应用场景比如用户希望把Kubernetes Master节点保留给 Kubernetes 系统组件使用，或者把一组具有特殊资源预留给某些 pod。pod不会再被调度到taint标记过的节点。

taint标记节点举例如下：

$ kubectl taint nodes bjo-ep-dep-039.dev.fwmrm.net key=value:NoSchedule
node "bjo-ep-dep-039.dev.fwmrm.net" tainted

如果仍然希望某个pod调度到taint节点上，则必须在 Spec 中做出Toleration 定义，才能调度到该节点，举例如下：

tolerations: - key: "key" operator: "Equal"
value: "value"
effect: "NoSchedule"

effect 共有三个可选项，可按实际需求进行设置：

NoSchedule：pod不会被调度到标记为taints节点。
PreferNoSchedule：NoSchedule的“preference”或“soft”版本。
NoExecute：该选项意味着一旦Taint 生效，如该节点内正在运行的 Pod 没有对应 Tolerate 设置，会直接被逐出。

总结

使用者可根据实际需求，充分利用pod的相关高级调度策略，使Kubernetes更好的服务于我们的需求。

本文转自中文社区-Kubernetes之Pod调度

微信关注我们

原文链接：https://yq.aliyun.com/articles/679511

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

Kubernetes-基于RKE进行Kubernetes的安装部署

在进行Kubernetes的深入学习之前，首先要做的一件事情就是Kubernetes环境的安装部署。由于Kubernetes本身的复杂性，因此决定安装过程相当较为复杂，在安装过程中需要考虑诸多的因素。在本文中，将使用Kubernetes的轻量级工具——Rancher Kubernetes Engine（RKE）进行Kubernetes的安装部署。RKE是一个用Golang编写的Kubernetes安装程序，相对于其它的工具来说，更加简单易用和上手。 1、环境准备 1.1 操作系统 1）建议使用Ubuntu 16.04.3 LTS版本；如果使用CentOS 7，建议7.3以上版本；序号角色操作系统 IP 主机 1 RKE CentOS7 10.0.32.134 rancher-server 2 etcd CentOS7 10.0.32.175 rancher2-server 3 Master Node CentOS7 10.0.32.175 rachenr2-server 4 Worker Node CentOS7 10.0.32.177 rancher2-node01 5 Wor...

2018-12-14

493

1、MySQL简介 MySQL 是一个开源的关系型数据库管理系统，使用标准的sql语言，由瑞典 MySQL AB 公司开发，当前属于 Oracle 公司。能够支持大型的数据库，可以处理上千万条的数据记录。可以运行于在Windows、Linux等多种系统上；支持C、C++、Python、Java、Perl、PHP、Eiffel、Ruby和Tcl等编程语言。对于32位系统，MySQL的表文件最大可支持4GB，对于64位系统，MySQL支持最大的表文件为8TB。 2、MySQL的高可用方案本文的MySQL高可用方案为主从复制+读写分离，即由单一的master和多个slave所构成。其中，客户端通过master对数据库进行写操作，通过slave端进行读操作。master出现问题后，可以将应用切换到slave端。此方案是MySQL官方提供的一种高可用解决方案，节点间的数据同步采用MySQL Replication技术。 MySQL Replication从一个MySQL数据库服务器（master）的数据复制到一个或多个MySQL数据库服务器（slave）。在默认情况下，复制是异步的；sla...

2018-12-14

528

资源下载

更多资源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。