K8S中五种控制器的介绍以及使用

目录
  • k8s的控制器类型
  • pod与控制器之间的关系
  • Deployment(无状态化应用)
  • 状态与无状态化对特点
  • Deployment的更新
  • Deployment的回滚
  • CronJob控制器
  • 总结

k8s的控制器类型

Kubernetes中内建了很多controller(控制器),这些相当于一个状态机,用来控制Pod的具体状态和行为

Deployment:适合无状态的服务部署

StatefullSet:适合有状态的服务部署

DaemonSet:一次部署,所有的node节点都会部署,例如一些典型的应用场景:

运行集群存储 daemon,例如在每个Node上运行 glusterd、ceph

在每个Node上运行日志收集 daemon,例如 fluentd、 logstash

在每个Node上运行监控 daemon,例如 Prometheus Node Exporter

Job:一次性的执行任务

Cronjob:周期性的执行任务

总体来说,K8S有五种控制器,分别对应处理无状态应用、有状态应用、守护型应用和批处理应用

pod与控制器之间的关系

controllers:在集群上管理和运行容器的对象通过label-selector相关联

Pod通过控制器实现应用的运维,如伸缩,升级等

Deployment(无状态化应用)

应用场景:web服务

Deployment中文意思为部署、调度,通过Deployment我们能操作RS(ReplicaSet),你可以简单的理解为它是一种通过yml文件的声明,在Deployment 文件里可以定义Pod数量、更新方式、使用的镜像,资源限制等。无状态应用都用Deployment来创建

通过Deployment对象,你可以轻松的做到以下事情:

  • 创建ReplicaSet和Pod
  • 滚动升级(不停止旧服务的状态下升级)和回滚应用(将应用回滚到之前的版本)
  • 平滑地扩容和缩容
  • 暂停和继续Deployment
Deployment创建
[root@master shuai]# vim nginx-delpoy.yaml

apiVersion: apps/v1
kind: Deployment   '定义是Deployment'
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3  '副本数量为3'
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80

'创建资源'
[root@master shuai]# kubectl apply -f nginx-delpoy.yaml
deployment.apps/nginx-deployment created

//Replicaset 是控制版本,副本数,回滚就是通过此来实现
'//查看所有资源'
[root@master shuai]# kubectl get all
NAME                                  READY   STATUS    RESTARTS   AGE
pod/nginx-deployment-d55b94fd-cndf2   1/1     Running   0          3m31s
pod/nginx-deployment-d55b94fd-ghlwk   1/1     Running   0          3m31s
pod/nginx-deployment-d55b94fd-tm4sw   1/1     Running   0          3m31s
pod/pod-example                       1/1     Running   0          10h

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.0.0.1     <none>        443/TCP   3d6h

NAME                               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-deployment   3         3         3            3           3m31s

NAME                                        DESIRED   CURRENT   READY   AGE
replicaset.apps/nginx-deployment-d55b94fd   3         3         3       3m31s

查看控制器信息
kubectl deit deployment/nginx-deployment
.....省略信息.....
strategy:
    rollingUpdate:         '版本更新为滚动更新机制'
      maxSurge: 25%        '最大更新副本数是25%,最多扩容125%' '为了保持副本数量,增加的百分比同时要销毁多少'
      maxUnavailable: 25%  '最大删除副本是25%,最多缩容到75%'
    type: RollingUpdate
...省略信息....

'执行kubectl describe deploy nginx-deployment 也可以查看'

....省略信息....
RollingUpdateStrategy:  25% max unavailable, 25% max surge

查看历史版本

[root@master shuai]# kubectl rollout history deploy/nginx-deployment
deployment.extensions/nginx-deployment
REVISION  CHANGE-CAUSE
1         <none>   '//这边只有一个,证明还没有滚动更新'

状态与无状态化对特点

无状态服务的特点:

1)deployment 认为所有的pod都是一样的

2)不用考虑顺序的要求

3)不用考虑在哪个node节点上运行

4)可以随意扩容和缩容

有状态服务的特点:

1)实例之间有差别,每个实例都有自己的独特性,元数据不同,例如etcd,zookeeper

2)实例之间不对等的关系,以及依靠外部存储的应用。

Deployment的更新

如果想要让 nginx pod 使用 nginx:1.9.1 的镜像来代替原来的 nginx的镜像,运行以下命令
[root@master ~]# kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
deployment.apps/nginx-deployment image updated

或者我们可以使用 edit 命令来编辑 Deployment,将image从nginx改写成 nginx:1.9.1
kubectl edit deployment/nginx-deployment

查看更新进度
[root@master ~]# kubectl rollout status deployment/nginx-deployment
Waiting for deployment "nginx-deployment" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "nginx-deployment" rollout to finish: 1 old replicas are pending termination...
deployment "nginx-deployment" successfully rolled out

Deployment更新时会创建一个新的ReplicaSet,然后将新的ReplicaSet中的Pod慢慢扩容到指定的副本数,将旧的ReplicaSet慢慢缩容到0。因此,更新时总能够确保旧的服务不会停止,这就是滚动更新。

Deployment的回滚

当我们像上文一样更新了Deployment之后,我们发现nginx:1.9.1的镜像不是很稳定,因此想要修改回nginx:1.7.9的版本,此时我们不需要手动更改Deployment文件,而是利用Deployment的回滚功能。

使用rollout history命令查看Deployment的版本(revision):

[root@master ~]# kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment
REVISION  CHANGE-CAUSE
1         kubectl create --filename=deploy.yml --record=true
2         kubectl create --filename=deploy.yml --record=true

因为我们创建 Deployment 的时候使用了 —recored 参数可以记录命令,我们可以很方便的查看每次 revison 的变化。

查看单个 revision 的详细信息:

[root@master ~]# kubectl rollout history deployment/nginx-deployment --revision=2
deployment.apps/nginx-deployment with revision #2
Pod Template:
  Labels:       app=nginx
        pod-template-hash=658d7f4b4b
  Annotations:  kubernetes.io/change-cause: kubectl create --filename=deploy.yml --record=true
  Containers:
   nginx:
    Image:      nginx:1.9.1
    Port:       80/TCP
    Host Port:  0/TCP
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>

可以使用rollout undo命令回滚到前一个revision
[root@master ~]# kubectl rollout undo deployment/nginx-deployment
deployment.apps/nginx-deployment rolled back

[root@master ~]# kubectl describe deployment/nginx-deployment
Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Fri, 24 Dec 2021 22:24:10 +0800
Labels:                 <none>
Annotations:            deployment.kubernetes.io/revision: 3
                        kubernetes.io/change-cause: kubectl create --filename=deploy.yml --record=true
Selector:               app=nginx
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>

也可以使用–to-revision参数指定某个历史版本:

[root@master ~]#  kubectl rollout undo deployment/nginx-deployment --to-revision=2
deployment.apps/nginx-deployment rolled back

[root@master ~]# kubectl describe deployment/nginx-deployment
Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Fri, 24 Dec 2021 22:24:10 +0800
Labels:                 <none>
Annotations:            deployment.kubernetes.io/revision: 4
                        kubernetes.io/change-cause: kubectl create --filename=deploy.yml --record=true
Selector:               app=nginx
Replicas:               3 desired | 3 updated | 4 total | 3 available | 1 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:1.9.1
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>

你可以通过设置 .spec.revisonHistoryLimit 项来指定 deployment 最多保留多少 revison 历史记录。默认的会保留所有的 revision;如果将该项设置为 0,Deployment 就不允许回退了。

只有 Deployment 的 rollout 被触发才会创建一个 revision!注意!当且仅当 Deployment 的 Pod template被更改,例如更新 template 中的 label 和容器镜像时,才会触发一个rollout,从而为Deployment创建出一个新的 revision。

rollout命令的更多用法:

  • history(查看历史版本)
  • pause(暂停Deployment)
  • resume(恢复暂停的Deployment)
  • status(查看资源状态)
  • undo(回滚版本)

Job Controller负责根据Job Spec创建Pod,并持续监控Pod的状态,直至其成功结束。如果失败,则根据restartPolicy(只支持OnFailure和Never,不支持Always)决定是否创建新的Pod再次重试任务。

Job负责批量处理短暂的一次性任务 (short lived one-off tasks),即仅执行一次的任务,它保证批处理任务的一个或多个Pod成功结束。

Kubernetes支持以下几种Job:

  • 非并行Job:通常创建一个Pod直至其成功结束
  • 固定结束次数的Job:设置.spec.completions,创建多个Pod,直到.spec.completions个Pod成功结束
  • 带有工作队列的并行Job:设置.spec.Parallelism但不设置.spec.completions,当所有Pod结束并且至少一个成功时,Job就认为是成功
  • 根据.spec.completions和.spec.Parallelism的设置,可以将Job划分为以下几种pattern
JOB类型 使用实例 行为 completions parallelism
一次性Job 数据库迁移 创建一个Pod直至其成功结束 1 1
固定结束次数的Job 处理工作队列的Pod 依次创建一个Pod运行直至completions个成功结束 2+ 1
固定结束次数的并行Job 多个Pod同时处理工作队列 依次创建多个Pod运行直至completions个成功结束 2+ 2+
并行Job 多个Pod同时处理工作队列 创建一个或多个Pod直至有一个成功结束 1 2+
.job的使用
[root@master ~]# vi job.yml
---
apiVersion: batch/v1
kind: Job
metadata:
  name: myjob
spec:
  template:
    spec:
      containers:
      - name: myjob
        image: busybox
        command: ["echo",  "hello k8s job"]
      restartPolicy: Never

[root@master ~]# kubectl apply -f job.yml
job.batch/myjob created
[root@master ~]# kubectl get pods
NAME          READY   STATUS      RESTARTS   AGE
myjob-gq27p   0/1     Completed   0          37s

#查看这个 pod的任务
[root@master ~]# kubectl get job
NAME    COMPLETIONS   DURATION   AGE
myjob   1/1           19s        5m11s

#查看这个 pod的日志
[root@master ~]# kubectl logs myjob-gq27p
hello k8s job

CronJob控制器

CronJob 可以用来执行基于时间计划的定时任务,类似于Linux/Unix系统中的 crontable (opens new window)。

CronJob 执行周期性的重复任务时非常有用,例如备份数据、发送邮件等。CronJob 也可以用来指定将来某个时间点执行单个任务,例如将某项任务定时到系统负载比较低的时候执行。

一个 CronJob 对象就像 crontab (cron table) 文件中的一行。 它用Cron格式进行编写, 并周期性地在给定的调度时间执行 Job。

注意:

  • 所有 CronJob 的 schedule: 时间都是基于kube-controller-manager. 的时区。
  • 如果你的控制平面在 Pod 或是裸容器中运行了 kube-controller-manager, 那么为该容器所设置的时区将会决定 Cron Job 的控制器所使用的时区。
  • 为 CronJob 资源创建清单时,请确保所提供的名称是一个合法的DNS 子域名. 名称不能超过 52 个字符。 这是因为 CronJob 控制器将自动在提供的 Job 名称后附加 11 个字符,并且存在一个限制, 即 Job 名称的最大长度不能超过 63 个字符。
  • CronJob 用于执行周期性的动作,例如备份、报告生成等。 这些任务中的每一个都应该配置为周期性重复的(例如:每天/每周/每月一次); 你可以定义任务开始执行的时间间隔。

下面的 CronJob 示例清单会在每分钟打印出当前时间和问候消息:

[root@master kubenetres]# vi cronjob.yml
---
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello nihao
          restartPolicy: OnFailure

创建pod查看
[root@master ~]# kubectl apply -f cronjob.yml
Warning: batch/v1beta1 CronJob is deprecated in v1.21+, unavailable in v1.25+; use batch/v1 CronJob
cronjob.batch/hello created

#等一分钟查看
[root@master ~]# kubectl get pods
NAME                   READY   STATUS      RESTARTS   AGE
hello-27339330-kkfxv   0/1     Completed   0          2s

#查看日志
[root@master ~]# kubectl logs hello-27339330-kkfxv
Fri Dec 24 15:30:00 UTC 2021
Hello nihao

总结

到此这篇关于K8S中五种控制器及使用的文章就介绍到这了,更多相关K8S控制器使用内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • Docker学习笔记之k8s部署方法

    本文记录了如何在ubuntu 14.04裸机上部署k8s集群,参考自官方文档. 拓扑结构 1master + 2minion k8s-master 192.168.0.201 master k8s-node1 192.168.0.202 minion k8s-node2 192.168.0.203 minion 准备工作系统 安装Ubuntu 14.04 LTS 64bit server版本系统,配置好hostname和ip. 在更新国内的软件源的时候,由于GFW的原因,经常会出现md5校验错误

  • Kubernetes(k8s)基础介绍

    之前我一直想学习Kubernetes,因为它听起来很有意思(如果你是希腊人,你会觉得这个名字很有问题),但我从来没有机会,因为我没有任何东西需要运行在集群中.而最近,我的工作中开始逐步涉及Kubernetes相关的事情,所以这次我抓住机会,开始查资料,但后来我发现目前所有的资料(包括官方教程)都过于冗长,结构也不合理,这让我一开始有点沮丧. 经过几天的研究,我开始逐步理解Kubernetes的核心理念,并且把他部署到了生产环境中.因为我的简历现在说自己是个"Kubernetes专家",

  • 云原生技术kubernetes(K8S)简介

    目录 01 kubernetes是什么? 02 kubernetes和Compost+Swarm之间的区别 03 一点总结 今天我们看看kubernetes技术的介绍,最近在极客时间上看张磊老师的深入kubernetes技术,讲的非常好,有兴趣的同学可以去收听一下,对于理解kubernetes技术非常有帮助,这里我会按照自己的进度,分享一下学习的笔记. 今天站的角度比较高,概念性质的东西会多一点. 01 kubernetes是什么? 曾经我认为这个问题很好回答,直到不断的去理解kubernete

  • K8S中五种控制器的介绍以及使用

    目录 k8s的控制器类型 pod与控制器之间的关系 Deployment(无状态化应用) 状态与无状态化对特点 Deployment的更新 Deployment的回滚 CronJob控制器 总结 k8s的控制器类型 Kubernetes中内建了很多controller(控制器),这些相当于一个状态机,用来控制Pod的具体状态和行为 Deployment:适合无状态的服务部署 StatefullSet:适合有状态的服务部署 DaemonSet:一次部署,所有的node节点都会部署,例如一些典型的应

  • go语言中五种字符串的拼接方式(小结)

    目录 +拼接方式 sprintf函数 Join函数 buffer.Builderbuffer.WriteString函数 buffer.Builder函数 ps:直接使用运算符 主要结论 +拼接方式 这种方式是我在写golang经常用的方式,go语言用+拼接,php使用.拼接,不过由于golang中的字符串是不可变的类型,因此用 + 连接会产生一个新的字符串对效率有影响. func main() { s1 := "hello" s2 := "word" s3 :=

  • Python中五种列表拷贝的方法

    目录 1. 赋值操作 2. 使用copy操作 3. 使用list()构造函数 4. 使用索引 5. 列表生成式 6 总结 1. 赋值操作 最容易想到的就是我们可以使用赋值操作来直接复制列表, 代码如下: copied_list=original_list 此时,original_list 和copyed_list 都将指向同一个列表对象. 举例如下: original_list=[1,2,3] #Copying list using assignment operation copied_lis

  • Python中五种实现字符串反转的方法

    目录 前言 方法1 方法2 方法3 方法4 方法5 前言 一道题目是实现一个反转字符串的函数,具体如下: 编写一个函数,其作用是将输入的字符串反转过来.输入字符串以字符数组 char[] 的形式给出. 不要给另外的数组分配额外的空间,你必须原地修改输入数组.使用 O(1) 的额外空间解决这一问题. 我们可以假设数组中的所有字符都是 ASCII 码表中的可打印字符. 示例 1: 输入:["h","e","l","l","

  • Redis中五种数据类型简单操作

    Redis中五种数据类型简单操作 提出问题 Redis五种数据类型的简单增删改查命令??? 解决问题 假设你已经安装Redis服务器: 假设你已经打开Redis cli命令行工具: 假设你对Redis有所了解: Redis简单增删改查例子 例一:字符串的增删改查 #增加一个key为ay_key的值 127.0.0.1:6379> set ay_key "ay" OK #查询ay_key的值 127.0.0.1:6379> get ay_key "ay"

  • Mysql中Binlog3种格式的介绍与分析

    一.Mysql Binlog格式介绍      Mysql binlog日志有三种格式,分别为Statement,MiXED,以及ROW! 1.Statement:每一条会修改数据的sql都会记录在binlog中. 优点:不需要记录每一行的变化,减少了binlog日志量,节约了IO,提高性能.(相比row能节约多少性能与日志量,这个取决于应用的SQL情况,正常同一条记录修改或者插入row格式所产生的日志量还小于Statement产生的日志量,但是考虑到如果带条件的update操作,以及整表删除,

  • python中的五种异常处理机制介绍

    从几年前开始学习编程直到现在,一直对程序中的异常处理怀有恐惧和排斥心理.之所以这样,是因为不了解.这次攻python,首先把自己最畏惧和最不熟悉的几块内容列出来,里面就有「异常处理」这一项. <Dive into Python>并没有专门介绍异常处理,只是例子中用到的时候略微说明了一下.今天下载<Learn Python>,直接进异常处理这块.这一部分有四章,第一章讲解异常处理的一般使用方法,后面的章节深入地讨论其机制.我目前只看了第一章,先学会用,以后有必要的时候再扩展阅读. p

  • Java中五种不同方法的创建对象

    前言 作为Java开发者,我们每天都会创建大量的对象,但是,我们总是使用管理依赖系统(如Spring框架)来创建这些对象.其实还有其他方法可以创建对象,在接下来的文章中我会进行详细介绍. 1.使用new关键字 这是最常见的创建对象的方法,并且也非常简单.通过使用这种方法我们可以调用任何我们需要调用的构造函数. Employee emp1 = new Employee(); 0: new #19 // class org/programming/mitra/exercises/Employee 3

  • Java中四种引用类型详细介绍

    Java 四种引用类型 对象的强.软.弱和虚引用 在JDK 1.2以前的版本中,若一个对象不被任何变量引用,那么程序就无法再使用这个对象.也就是说,只有对象处于可触及(reachable)状态,程序才能使用它.从JDK 1.2版本开始,把对象的引用分为4种级别,从而使程序能更加灵活地控制对象的生命周期.这4种级别由高到低依次为:强引用.软引用.弱引用和虚引用. ⑴强引用(StrongReference) 强引用是使用最普遍的引用.如果一个对象具有强引用,那垃圾回收器绝不会回收它.当内存空间不足,

  • Java中三种简单注解介绍和代码实例

    简单Java注解 JDK5提供的简单注解类型只有3个. 这三个都是用来预防错误或者进行提醒的,分别是: 1.Override 2.Deprecated 3.Suppresswarnings 需要注意,JDK5(另一个说法,Tiger)实际上并没有许多内置注解;相反,它允许核心Java支持注解特性的能力. JSR-175中严格规定它用来定义元数据功能. 需要由程序员编写自定义的注解类型,其他JSR标准也编写了一系列标准注解类型. 下面将用实例来深入讲解这三个简单注解. Override 注解 Ov

随机推荐