专栏首页Liusy01深入理解Pod(三)

深入理解Pod(三)

目录:

Pod的调度

Pod的扩容和缩容

Pod的滚动升级

Pod的调度

Pod只是容器的载体,通常需要通过RC、Deployment、DaemonSet、Job等对象来完成Pod的调度和自动控制功能。

1

RC、Deployment全自动调度

RC的主要功能之一就是自动部署一个容器应用的多份副本,以及持续监控副本的数量,在集群内始终维持用户指定的副本数量。

2

NodeSelector:定向调度

Master上的Schedule负责实现Pod的调度,但无法知道Pod会调度到哪个节点上。可以通过Node的标签(Label)和Pod的nodeSelector属性相匹配,达到将Pod调度到指定的Node上。

(1)首先通过kubectl label命令给目标Node打上标签

kubectl label nodes node-name key=value

例如这边给cnode-2和cnode-3添加标签

查看是否已打上标签可以使用如下命令

kubelct describe nodes node-name

(2)在Pod定义上添加nodeSelector的设置,

apiVersion: v1
kind: ReplicationController
metadata:
  name: nodeselectorrc
  labels:
    name: nodeselectorrc
spec:
  replicas: 1
  template:
    metadata:
      name: nodeselectorrc
      labels:
        name: nodeselectorrc
    spec:
      containers:
      - name: nodeselectorrc
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
      nodeSelector:
        name: cnode-2

【注】如果没有节点有这个标签,那么Pod会无法进行调度

3

NodeAffinity:亲和性调度

由于NodeSelector通过Node的label进行精确匹配,所以NodeAffinity增加了In,NotIn,Exists、DoesNotExist、Gt、Lt等操作符来选择Node,能够使调度更加灵活,同时在NodeAffinity中将增加一些信息来设置亲和性调度策略

(1)RequiredDuringSchedulingIgnoredDuringExecution:必须满足指定的规则才可以调度Pod到Node上

(2)PreferredDuringSchedulingIngoredDuringExecution:强调优选满足指定规则,调度器尝试将Pod调度到Node上,但不强求,多个优先级规则还可以设置权重,以定义执行的选后顺序。

需要在Pod的metadata.annotations中设置NodeAffinity的内容,例如

apiVersion: v1
kind: Pod
metadata:
  name: with-labels
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: name
            operator: NotIn
            values: ["cnode-1","cnode-2"]
  containers:
  - name: with-labels
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80

上述yaml脚本是说明只有Node的label中包含key=name,并且值并非是["cnode-1","cnode-2"]中的一个,才能成为Pod的调度目标,其中操作符还有In,Exists,DoesNotExist,Gt,Lt。

PreferredDuringSchedulingIngoredDuringExecution使用如下:

spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIngoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: name
            operator: In
            values: ["cnode-1","cnode-2"]

4

DaemonSet:特定场景调度

用于管理在集群中每个Node上仅运行一份Pod的副本实例

适合以下场景:

1、在每个Node上运行GlusterFS存储或者Ceph存储的daemon进程

2、每个Node上运行一个日志采集程序 ,例如fluentd或者logstach。

3、每个Node上运行一个健康程序,采集该Node的运行性能数据,例如Prometheus node Exporter

调度策略于RC类似,也可使用NodeSelector或者NodeAffinity来进行调度

例如:为每个Node上启动一个nginx

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: ds-nginx
  labels:
    name: ds-nginx
spec:
  selector:
    matchLabels:
      name: ds-nginx
  template:
    metadata:
      name: ds-nginx
      labels:
        name: ds-nginx
    spec:
      containers:
      - name: ds-nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

5

Job批处理调度

可通过Job资源对象定义并启动一个批处理任务,通常并行或串行启动多个计算进程去处理一批工作任务,处理完成后,整个批处理任务结束。

按照批处理任务实现方式的不同,可分为如下几种模式 :

1、Job Template Expansion模式:一个Job对象对应一个待处理的Work Item,有几个Work item就产生几个独立的Job,适合Work item少,每个Work item要处理的数据量比较大的场景

例如:定义一个Job模板,job.yaml.txt

apiVersion: batch/v1
kind: Job
metadata:
  name: process-item-$ITEM
  labels:
    jobgroup: jobexample
spec:
  template:
    metadata:
      name: jobexample
      labels:
        jobgroup: jobexample
    spec:
      containers:
      - name: c
        image: busybox
        imagePullPolicy: IfNotPresent
        command: ["sh","-c","echo $Item && sleep 5"]
      restartPolicy: Never
#使用如下命令生成yaml文件
for i in a b c; do cat job.yaml.txt | sed "s/\$ITEM/${i}/" > ./job-$i.yaml; done

#查看运行情况
kubectl get jobs -l jobgroup=jobexample

2、Queue with Pod Per Work Item模式:采用一个任务队列存放Work Item,一个Job作为消费者去完成这些Work item,此模式下,Job会启动N个Pod,每个Pod对应一个WorkItem

3、Queue with Variable Pod Count模式:采用一个任务队列存放Work Item,一个Job作为消费者去完成这些Work item,Job启动的Pod数量是可变的

4、Single Job with Static Work Assignment模式:一个Job产生多个Pod,采用程序静态方式分配任务项

考虑到批处理的并行问题,k8s将job分为以下三种类型:

1、Non-parallel Jobs

一个Job只启动一个Pod,除非Pod异常,才会 重启该Pod,一旦 Pod正常结束,Job将结束。

2、Parallel Jobs with a fixed completion count

并行job会 启动多个Pod,需要设定Pod的参数.spec.completions为一个正数,当正常 结束的Pod数量达到此数时,Job结束,同时此参数用于控制并行度,即同时启动几个Job来处理Work item

3、Parallel Jobs with a work queue

任务队列的并行job需要一个独立的队列,work item都在一个队列中存放,不能设置job的 .spec.completions参数,此时job有以下一些特性

(1)每个Pod能独立判断和决定是否还有任务项需要储里

(2)如果某个Pod能正常结束,则Job不会在启动新的Pod

(3)如果一个Pod成功结束,则此时应该不存在其他Pod还在干活 的情况,应该都处于即将结束 、退出的状态 。

(4)如果 所有Pod都结束了,且至少有一个Pod成功结束,则整个Job才算成功 结束。

6

Cronjob:定时任务

能根据设定的定时表达式定时调度Pod

(1)Cron Job的定时表达式(与Linux的基本相同)

Minutes Hours DayOfMonth Month DayOfWeek Year

其中每个域都可出现的字符如下。

◎ Minutes:可出现【,-*/】这4个字符,有效范围为0~59的整数。

◎ Hours:可出现【,-*/】这4个字符,有效范围为0~23的整 数。

◎ DayofMonth:可出现【,-*/?LWC】这8个字符,有效范围为0~31的整数。

◎ Month:可出现【,-*/】这4个字符,有效范围为1~12的整数或JAN~DEC。

◎ DayofWeek:可出现【,-*/?LC#】这8个字符,有效范围为1~7的整数或SUN~SAT。1表示星期天,2表示星期一,以此类推

◎ *:表示匹配该域的任意值,假如在Minutes域使用,则表示每分钟都会触发事件。

◎ /:表示从起始时间开始触发,然后每隔固定时间触发一次,例如在Minutes域设置为5/20,则意味着第1次触发在第5min时,接下来每20min触发一次

◎ -:指定一个整数范围。譬如,1-4 意味着整数 1、2、3、4。 ◎ ,:隔开的一系列值指定一个列表。譬如3, 4, 6, 8 标明这四个指定的整数。

比如需要每分钟执行一次:

*/1 * * * * 

(2)创建Cron Job

使用yaml文件

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            command: ["/bin/bash","-c","date;echo Hello"]
          restartPolicy: OnFailure

7

PodAffinity:Pod亲和与互斥调度策略

根据在节点上正在运行的 Pod的标签而不是节点的标签进行判断和调度,要求对节点和Pod两个条 件进行匹配。这种规则可以描述为:如果在具有标签X的Node上运行了一个或者多个符合条件Y的Pod,那么Pod应该(如果是互斥的情况,那么就变成拒绝)运行在这个Node上。

这里X指的是一个集群中的节点、机架、区域等概念,通过 Kubernetes内置节点标签中的key来进行声明。这个key的名字为 topologyKey,意为表达节点所属的topology范围。

◎ kubernetes.io/hostname

◎ failure-domain.beta.kubernetes.io/zone

◎ failure-domain.beta.kubernetes.io/region

与节点不同的是,Pod是属于某个命名空间的,所以条件Y表达的 是一个或者全部命名空间中的一个Label Selector。

和节点亲和相同,Pod亲和与互斥的条件设置也是requiredDuringSchedulingIgnoredDuringExecution和 preferredDuringSchedulingIgnoredDuringExecution。

Pod的亲和性被定义于PodSpec的affinity字段下的podAffinity子字段中。Pod间的互斥性则被定义于同一层次的podAntiAffinity子字段中。

例如:

参照目标Pod

apiVerison: v1
kind: Pod
metadata:
  name: pod-flag
  labels:
    security: s1
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx

(1)Pod亲和性调度

apiVersion: v1
kind: Pod
metadata:
  name: pod-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values: ["s1"]
        topologyKey: kubernetes.io/hostname
  containers:
  - name: nginx
    image: nginx

创建之后会发现两个Pod在同一个节点上

(2)Pod互斥性调度

apiVersion: v1
kind: Pod
metadata:
  name: pod-antiaffinity
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values: ["s1"]
        topologyKey: kubernetes.io/hostname
  containers:
  - name: nginx
    image: nginx

创建之后会发现这个Pod跟参照Pod不在同一个节点上

8

Pod Priority Preemption:Pod优先级调度

在中大型集群中,为了尽可能提高集群的资源利用率,会采用优先级方案,即不同类型的负载对应不同的优先级,同时允许集群中的所有负载所需的资源总量超过集群可提供的资源,在这种情况下,当发生资源不足的情况时,系统可以选择释放一些不重要的负载(优先级最低的),保障最重要的负载能够获取足够的资源稳定运行。

如果发生了需要抢占的调度,高优先级Pod就可能抢占节点N,并将其低优先级Pod驱逐出节点N。

(1)首先创建PriorityClasses

apiVersion: v1
kind: scheduling.k8s.io/v1beta1
metadata:
  name: high-priority
value: 10000
globalDefault: false

(2)然后在Pod中引用Pod优先级

apiVersion: v1
kind: Pod
metadata:
  name: nginx-priority
spec:
  containers:
  - name: nginx
    image: nginx
  priorityClassName: high-priority

Pod的扩容和缩容

1

通过kubectl scale

通过kubectl scale进行扩容和缩容,其实就是修改控制器的副本数字段

kubectl scale rc rc-name --replicas=副本数量

比如我将nodeselectorrc扩容为3

缩容也是一样,将副本数量改小就行

2

Horizontal Pod AutoScale(HPA)

实现基于cpu使用率进行自动Pod扩缩容,HPA控制器基于Master的kube-controller-manager服务启动参数

--horizontal-pod-authscaler-sync-period

定义的时长(默认为30s),周期性的监测目标pod的cpu使用率,并在满足条件时对RC或Deployment中的Pod副本数量进行调整,以符合用户定义的平均Pod CPU使用率

创建HPA时可以使用kubectl autoscale命令进行快速创建或者使用yaml配置文件进行创建,在创建HPA前,需要已经存在一个RC或者Deployment对象,并且必须定义resources.requests.cpu的资源请求值,如果不设置该值,则heapster将无法采集Pod的cpu使用率

【注】此方式需要安装heapster进行采集资源的cpu使用率

命令行方式:

kubectl autoscale rc rc-name --min=1 --max=10 --cpu-percent=50

yaml方式:

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-name
spec:
  scaleTargetRef:
    apiVersion: v1
    kind: ReplicationController
    name: rc-name
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50

上述两种方式都是在cpu使用率达到50%的时候进行扩缩容,最小副本数为1,最大副本数为10

Pod的滚动升级

滚动升级通过kubectl rolling-update命令完成,该命令创建了一个RC,然后自动控制旧的RC中的Pod副本的数量逐渐减少至0,同时新的RC中的Pod副本的数量从0逐步增加至目标值,最终实现了Pod的升级。新旧的RC需要在同一个Namespace下。

1

使用yaml进行升级

比如有一个nginx的v1版本:nginx-v1.yaml

apiVersion: v1
kind: ReplicationController
metadata:
  name: roll-v1
  labels:
    name: roll-v1
    version: v1
spec:
  replicas: 3
  selector:
    name: roll-v1
    version: v1
  template:
    metadata:
      name: roll-v1
      labels:
        name: roll-v1
        version: v1
    spec:
      containers:
      - name: roll-v1
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

创建之后如下:

需要将其升级为v2版本:nginx-v2.yaml

apiVersion: v1
kind: ReplicationController
metadata:
  name: roll-v2
  labels:
    name: roll-v2
    version: v2
spec:
  replicas: 3
  selector:
    name: roll-v2
    version: v2
  template:
    metadata:
      name: roll-v2
      labels:
        name: roll-v2
        version: v2
    spec:
      containers:
      - name: roll-v2
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080

使用如下命令进行升级:

kubectl rolling-update roll-v1 -f nginx-v2.yaml

执行之后会逐步替换掉v1版本的pod

需要注意的是:

1、RC的名字不能与旧的RC相同

2、在selector中至少有一个Label与旧的不同,以表示其是新的RC。(其实是必须所有label不一样)

2

使用命令方式直接升级

也可以使用命令行直接替换掉容器的镜像

kubectl rolling-update rc-name --image=image-name:version

3

回滚

当滚动更新出现问题时,可以进行回滚

kubectl rolling-update rc-name --image=image-name:version --rollback

本文分享自微信公众号 - Liusy01(Liusy_01)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-10-11

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 深入理解Pod(二)

    将应用所需的配置信息与程序进行分离,可以使应用程序更好的被复用,通过不同的配置实现更灵活的功能。如果将应用打包成镜像,再用环境变量或者外挂文件的方式挂载配置,在...

    Liusy
  • k8s重器之Service

    Service是k8s的核心,通过创建Service,可以为一组具有相同功能的容器应用提供一个统一的入口地址,并将请求进行负载分发到各个容器应用上。

    Liusy
  • 使用k8s部署springboot+redis简单应用

    本文将使用k8s部署一个springboot+redis应用,由于是示例,所以功能比较简单,只有设置值和获取值两个api。

    Liusy
  • PASCAL VOC统计各类目标数量

    于小勇
  • Job 资源对象

    服务类的Pod容器:RC、RS、DS、Deployment.(Pod内运行的服务,要持续运行) 工作类的Pod容器:Job--->执行一次,或者批量执行处理程序...

    小手冰凉
  • Springmvc响应Ajax请求(@ResponseBody)

    爱撒谎的男孩
  • kubernetes中常用对象pod的相关介绍

    pod是一组紧密关联的容器组合,他们共享PID,IPC,NETWORK,UTS namespace,一个Pod里可以运行多个容器,一个Pod里的多个容器共享网络...

    极客运维圈
  • 深入k8s:Pod对象中重要概念及用法

    Pod,实际上是在扮演传统基础设施里“虚拟机”的角色;而容器,则是这个虚拟机里运行的用户程序。

    luozhiyun
  • 《Monkey Java》课程5.0之this的使用方法

    GitOPEN
  • SPA(单页面应用)的基本实现原理

    我们应该都使用过网易云音乐或者是别的一些逼格比较高的网页,他们比较厉害的一点是页面看起来只有一个,不管你点击什么地方,永远不会刷新页面,都是感觉是在一个页面上完...

    何处锦绣不灰堆

扫码关注云+社区

领取腾讯云代金券