【云原生kubernetes】k8s中控制器使用详解

阿里云国内75折 回扣 微信号：monov8
阿里云国际，腾讯云国际，低至75折。AWS 93折 免费开户实名账号 代冲值 优惠多多 微信号：monov8 飞机：@monov6

一、什么是控制器

  • 控制器是管理pod的中间层只需要告诉Pod控制器想要创建多少个什么样的Pod它会创建出满足条件的Pod
  • 控制器相当于一个状态机用来控制Pod的具体状态和行为
  • controller会自动创建相应的pod资源并在当pod发生故障的时候按照策略进行重新编排
  • 通过它来实现对pod的管理比如启动pod、停止pod、扩展pod的数量等等  

通俗来说就是控制器就是pod的幕后老板

二、k8s中常用的控制器

k8s发展到今天产生了很多种控制器以下列举常用的几类控制器

ReplicaSet

ReplicaSet 主要具备下面的特点

  • 一种副本控制器简称rs主要是控制由其管理的pod使pod副本的数量始终维持在预设的个数
  • 并支持pod数量扩缩容镜像版本升级
  • 官方建议不要直接使用ReplicaSet用Deployments更好并提供很多其它有用的特性

Deployment

通过控制ReplicaSet来控制Pod并支持滚动升级、回退版本适合无状态的服务部署

主要特点如下

  • 当某个应用有新版本发布时Deployment会同时操作两个版本的ReplicaSet
  • 内置多种滚动升级策略会按照既定策略降低老版本的Pod数量同时也创建新版本的Pod
  • Deployment控制器不直接管理Pod对象而是 Deployment 管理ReplicaSet, 再由ReplicaSet管理Pod对象

DaemonSet

在K8S集群部署中由于节点数量不定那么如果我们需要对每个节点中都运行一个守护进程、日志收集进程等情况时在k8s中如何实现呢这个时候就是DaemonSet应用场景了

其主要特点如下

  • 这类Pod 运行在K8S 集群里的每一个节点Node上确保所有节点上有且仅有一个pod
  • 有新的节点加入 K8S集群后该 Pod 会自动地在新节点上被创建出来
  • 而当旧节点被删除后它上面的 Pod也相应地会被回收掉
  • 应用场景监控告警Agent、日志组件、监控组件等

StatefulSet

像RS、Deployment、DaemonSet都是面向无状态的服务所管理的Pod的IP、名字启停顺序都是随机 StatefulSet就是有状态的集合管理所有有状态的服务

其特点如下

  • StatefulSet 中的 Pod 具有黏性的、独一无二的身份标识重新调度后PodName和HostName不变
  • Pod重新调度后还是能访问到相同的持久化数据基于PVC实现
  • 分配给每个 Pod 的唯一顺序索引Pod 的名称的形式为 <statefulset name>-<ordinal index>

应用场景比如MySQL、MongoDB集群

Horizontal Pod Autoscaler

  • 可以基于 CPU 利用率或其他指标实现Pod水平自动扩缩
  • 被伸缩的pod需要是通过deployment或者replica set管理
  • HPA不能应用于不可伸缩的对象如DaemonSets
  • 由资源来决定控制器行为控制器周期性调整目标pod的副本数量让目标pod的实际cpu使用率符合用户指定的数值

Job

  • 普通任务容器控制器只会执行一次,只要完成任务就立即退出不需要重启或重建
  • 容器中的进程在正常运行结束后不会对其进行重启,而是将pod对象置于completed状态
  • 若容器中的进程因错误而终止,则需要依据配置确定是否需要重启
  • 应用场景批处理程序完成后容器就退出等

Cronjob

顾名思义Linux 中有 cron 程序定时执行任务K8s的 CronJob 提供了类似的功能可以定时执行 Job

  • 创建的Pod负责周期性任务控制
  • 应用场景执行周期性的重复任务如备份数据、发送邮件、数据报表、报告生成等

三、k8s控制器之ReplicaSet

上文系统介绍了k8s中常用的几类控制器接下来以ReplicaSet这种控制器为例进行详细的说明

早期k8s没那么多控制器使用Replication Controller 来部署、升级Pod简称RC 也被称为下一代Replication Controller

1、关于ReplicaSet特性

  • 一种副本控制器简称rs主要是控制由其管理的pod使pod副本的数量始终维持在预设的个数
  • 并支持pod数量扩缩容镜像版本升级
  • 官方建议不要直接使用ReplicaSet用Deployments更好并提供很多其它有用的特性

2、ReplicaSet控制器配置模板样例

通常在实际业务中控制器的设置也是通过在yaml中通过一些标签元素进行设置如下

apiVersion: apps/v1 # 版本号
kind: ReplicaSet  #资源文件 
metadata: # 元对象信息
  name: test-rs #rs控制器名称
  namespace: default #名称空间
spec: #具体详情
  replicas: 2 #副本数量
  selector: # 选择器指定rs控制器管理哪些pod资源
    matchLabels: # 标签匹配规则
      app: test-nginx-pod #标签key是app,值是xdclass-nginx-pod
      
  template: # pod模板当数量不满足的时候根据下面编码创建pod副本
    metadata: # 元对象信息
      labels: # pod资源标签
        app: test-nginx-pod
    spec: #具体详情
      containers: # 容器数组列表
      - name: test-nginx  #容器名称
        image: nginx:1.23.0  # 镜像和版本

在当前目录下创建一个yaml拷贝上面的内容然后执行 apply命令创建pod

kubectl apply -f rep-nginx.yaml

执行完成后可以看到上面创建了2个副本的pod 

3、使用ReplicaSet命令行进行缩容

如果在业务的低峰期不需要开启那么多pod的时候就可以考虑缩减pod的个数使用ReplicaSet的操作命令很容易达到这个目的

kubectl scale rs test-rs --replicas=1 -n default

参数说明

  • test-rs 上面的rs名称
  • -n default pod所在的namespace名称

执行完成后可以看到 pod只剩1个了

4、删除rs创建的pod

可以直接删除rs也可以通过yaml删除

kubectl delete -f rep-nginx.yaml

执行之后可以看到下面的效果pod就被删掉了

四、k8s控制器之Deployment

Deployment 也是一种控制器在之前的文章中也在反复的使用它创建pod其特点如下

  • 通过控制ReplicaSet来控制Pod并支持滚动升级、回退版本适合无状态的服务部署
  • 当某个应用有新版本发佈时Deployment会同时操作两个版本的ReplicaSet
  • 内置多种滚动升级策略会按照既定策略降低老版本的Pod数量同时也创建新版本的Pod
  • Deployment控制器不直接管理Pod对象而是 Deployment 管理ReplicaSet, 再由ReplicaSet管理Pod对象

总的来说Deployment、ReplicaSet、Pod三者之间是一种阶梯控制的关系

1、Deployment 控制器配置模板样例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-deploy
  namespace: default
spec:
  replicas: 2
  selector: 
    matchLabels:
      app: test-nginx-pod
  template:
    metadata:
      labels:
        app: test-nginx-pod
    spec:
      containers:
      - name: test-nginx
        image: nginx:1.23.0

在当前目录下创建一个yaml拷贝上面的内容然后执行 apply命令创建pod

kubectl apply -f pod-nginx.yaml

执行完成后可以看到上面创建了2个副本的pod 

2、查看集群中的Deployment详细信息

kubectl get deploy -o wide -n default

结果参数说明

  • NAME 列出了集群中 Deployment 的名称
  • READY 显示应用程序的可用的“副本”数,格式是“就绪个数/期望个数”
  • UP-TO-DATE 显示为了达到期望状态已经更新的副本数
  • AVAILABLE 显示可用的副本数
  • AGE 应用程序运行的时间

3、删除Deployment 的pod

通过apply创建的pod直接使用 delete -f 删除即可

kubectl delete -f pod-nginx.yaml

五、基于Deployment 使用rollout 实现滚动升级

滚动升级在日常的生产变更过程中可以说是非常常见的业务了简单来说滚动升级的目的就是为了保证在升级过程中不停服减少因升级带来服务不可用造成的用户不好的产品体验

通常传统的滚动升级一般是针对无状态的应用服务而且是集群部署的那种升级的时候先通过一定的手段控制集群中的部分节点服务先升级然后再逐步完成全部节点的升级

一般这个过程可以通过脚本控制或者可视化操作界面手工来完成在k8s中Deployment这种控制器提供了一种很好的控制机制基于rollout就可以完成服务的滚动升级

1、Deployment控制器核心介绍

  • 适合部署无状态的应用服务
  • 用来管理pod和replicaset
  • 上线部署、副本控制、滚动更新、回滚等功能

2、使用Deployment控制器滚动升级 (金丝雀发布 or 灰度发布

  • 对各个实例批次进行单独更新,而非同一时刻对所有实例进行全部更新达到不中断服务的更新升级方式
  • Deployment控制器 给旧版本(old_rs)副本数减少至0、给新版本(new_rs)副本数量增至期望值(replicas)

3、Deployment 更新策略

对应于yaml中的核心配置参数

spec:
  strategy:  # 策略 RollingUpdate Recreate 
    type: RollingUpdate

策略1Recreate

删除全部旧的pod然后创建新的pod

策略2RollingUpdate

滚动升级更新删除部分更新部分在整个更新过程中存在两个版本的pod

经验来讲RollingUpdate实际应用场景更多RollingUpdate根据业务需求的不同又有下面两个重要的参数可供选择

  • maxUnavailable

1、升级过程中不可用Pod的最大数量默认为25%
2、在滚动更新时我们可以忍受多少个 Pod 无法提供服务
3、值越小越能保证服务稳定,更新越平滑

  • maxSurge

1、升级过程中可以超过期望的Pod的最大数量默认为25%
2、在滚动更新时可以有多少个额外的 Pod
3、值调的越大副本更新速度越快

4、yaml 模板配置样例

在当前目录下创建一个deploy-rollout.yaml的文件内容如下

apiVersion: apps/v1
kind: Deployment
metadata:
  name: congge-deploy
  namespace: default
spec:
  replicas: 5
  revisionHistoryLimit: 5  #保留历史版本5个
  strategy: 
    type: RollingUpdate
  selector: 
    matchLabels:
      app: congge-nginx-pod
  template:
    metadata:
      labels:
        app: congge-nginx-pod
    spec:
      containers:
      - name: congge-nginx
        image: nginx:1.23.0

在当前的目录下执行命令

kubectl apply -f deploy-rollout.yaml

执行后可以看到一个5副本的pod就创建出来 

5、查看控制器参数

使用下面的命令可以查看上面控制器的详细描述信息

kubectl describe deploy congge-deploy -n default

关于图中展示的信息中的几点补充说明

  • MaxUnavailable为0在新 Pod 启动并就绪之前不要关闭任何旧Pod

  • MaxSurge 为100%, 立即启动所有新 Pod也就是有足够的资源希望尽快完成更新默认两个值都是 25%

  •  如果更新一个 100 Pod 的 Deployment会立刻创建 25 个新 Old同时会关闭 25 个旧 Pod

  • 每次有 Pod 启动就绪就可以关闭旧 Pod

6、实现滚动升级

在上面部署的nginx的版本为1.23.0现在来实现一个需求将现有的版本降至1.15.8直接使用下面的命令

kubectl set image deployment/congge-deploy congge-nginx=nginx:1.15.8 -n default

注意命令里面的参数主要涉及到deploy的名称和一个container的名称与上面的yaml中保持一致即可

当前的状态

执行之后的状态从状态上来看有一个短暂的切换状态并不是一下子就把所有现有的容器停止掉而是一个很明显的中间状态也就是滚动升级的过程

 稍等一会儿再看这时候5个pod对应的nginx就全部完成了版本的降级

补充参数说明

可以在上面的命令行后面追加 --record 以保存正在更改资源的 kubectl 命令方便查看history版本列表修改命令

kubectl set image deployment/congge-deploy congge-nginx=nginx:1.15.8 -n default --record=true

升级过程中如果涉及到的pod非常多也可以动态查看升级过程中存在的不同版本的pod

kubectl get pods -n dev -w

7、发布回滚

如果在升级之后发现问题需要进行回退就可以用上回退相关的操作命令了

kubectl rollout 版本升级回滚相关参数介绍

  • history 升级回滚历史记录 
  • undo 默认回滚上一版本 使用--to-revision回滚到指定版本
  • pause 暂停版本升级发布
  • resume 继续恢复刚暂停的版本升级
  • status 升级状态

查看历史版本列表

kubectl rollout history deployment/congge-deploy -n default

这里会展示出版本回退的相关历史记录信息 

查看具体某一个历史版本信息

kubectl rollout history deployment/congge-deploy -n default --revision=3

回滚到上一版本

kubectl rollout undo deployment/congge-deploy -n default

查看升级情况

kubectl rollout status deployment/congge-deploy -n default

回滚到指定版本

如果历史版本比较多的情况下也可以根据实际需要回滚到某个指定的版本

kubectl rollout undo deployment/congge-deploy -n default --to-revision=3

删除deployment

kubectl delete -f deploy-nginx-pod.yaml

六、K8S控制器之DaemonSet控制器

在K8S集群部署中由于节点数量不定那么如果我们需要对每个节点中都运行一个守护进程、日志收集进程等情况时在k8s中如何实现呢这个时候就是DaemonSet应用场景了

DaemonSet特点

  • 这类Pod 运行在K8S 集群里的每一个节点Node上确保所有节点上有且仅有一个pod 
  • 有新的节点加入 K8S集群后该 Pod 会自动地在新节点上被创建出来
  • 而当旧节点被删除后它上面的 Pod也相应地会被回收掉
  • 应用场景监控告警Agent、日志组件、监控组件等

daemonset 配置样例模板

在当前目录下创建一个daemonset-nginx.yaml的文件配置如下

apiVersion: apps/v1
kind: DaemonSet   
metadata:
  name: congge-ds
  namespace: default
spec:
  selector: 
    matchLabels:
      app: congge-nginx-pod
  template:
    metadata:
      labels:
        app: congge-nginx-pod
    spec:
      containers:
      - name: congge-nginx
        image: nginx:1.23.0
        imagePullPolicy: IfNotPresent

内容和上面的差不多主要把kind那里调整下即可执行apply命令创建pod创建成功后使用命令查看

kubectl get pod,deploy,ds,rs -o wide -n default

可以看到通过这种方式创建的pod在其他节点上也会开启一个pod类似于JVM中的守护进程

七、K8S控制器之job控制器

job控制器是一种普通任务容器控制器只会执行一次,只要完成任务就立即退出不需要重启或重建

job控制器特点

  • 容器中的进程在正常运行结束后不会对其进行重启而是将pod对象置于completed状态
  • 若容器中的进程因错误而终止则需要依据配置确定是否需要重启
  • 启动pod在运行完毕任务后就会变成Completed状态job的状态会更新为complete这个job任务已经执行完成pod不在系统中继续运行

应用场景批处理程序完成后容器就退出等

daemonset 核心配置参数说明

apiVersion: batch/v1
kind: Job
metadata:
  name: test-job
  namespace: default
spec:
  parallelism: 2 #job并发运行Pods的数量默认 1
  completions: 3 #job需要成功运行Pods的次数,默认 1
  backoffLimit: 5 #job失败后进行重试的次数默认是6
  activeDeadlineSeconds: 100 #job运行超时时间当job超过timeout时间则job的状态也会更新为failed
  template:
    spec:
      restartPolicy: Never #job重启策略OnFailure或Never 
      containers:
      - name: demo
        image: busybox:1.35.0 
				# 容器的启动命令列表,在pod中的容器初始化完毕后运行命令
				command: ["echo","hello k8s job"]

BusyBox  参数补充说明

  • 是一个集成了三百多个最常用Linux命令和工具的软件
  • 包含了简单的工具例如ls、cat和echo等等还包含了一些更复杂的工具例grep、find、telnet

daemonset 配置样例模板

在当前目录下创建一个job-test.yaml的文件配置内容如下

apiVersion: batch/v1
kind: Job
metadata:
  name: test-job
spec:
  parallelism: 2
  completions: 3
  backoffLimit: 5
  activeDeadlineSeconds: 100
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: demo
        image: busybox:1.35.0 
        command: ["echo","hello k8s job"]

使用apply命令执行创建pod

查看创建的job

kubectl get job -n default -o wide

 查看pod容器中的输出日志

在yaml中容器那一栏里面输出了一段内容可以查看下容器的日志看看是否输出了选择其中一个job执行下面的命令进行查看发现内容成功输出了

kubectl logs test-job-bl9n7

阿里云国内75折 回扣 微信号：monov8
阿里云国际，腾讯云国际，低至75折。AWS 93折 免费开户实名账号 代冲值 优惠多多 微信号：monov8 飞机：@monov6
标签: k8s
返回列表

上一篇：KMS加密K8S Secret技术方案研究

下一篇：随机梯度下降算法 入门介绍（最通俗易懂）

“【云原生kubernetes】k8s中控制器使用详解” 的相关文章

Kubernetes 常用命令1年前 (2023-02-02)
二十八、Kubernetes中job详解1年前 (2023-02-02)
k8s的dashboard部署1年前 (2023-02-02)
译文 | Kubernetes 1.26：PodDisruptionBudget 守护不健康 Pod 时所用的驱逐策略1年前 (2023-02-02)
云原生 | Kubernetes - Webhook 模式1年前 (2023-02-02)
三十四、Kubernetes1.25中Ingress介绍、安装1年前 (2023-02-02)
RockyLinux8.5安装k8s1年前 (2023-02-02)
k8s之部署有状态应用1年前 (2023-02-02)
根据官方文档详细说明 Kubernetes 网络流量走向，包含详细的图文说明和介绍1年前 (2023-02-04)
2-k8s基本单元-Pod1年前 (2023-02-08)

阿里云国际版