k8s中的控制器的使用

server/2025/3/13 5:45:43/

一 什么是控制器

控制器也是管理pod的一种手段

  • 自主式pod：pod退出或意外关闭后不会被重新创建

  • 控制器管理的 Pod：在控制器的生命周期里，始终要维持 Pod 的副本数目

Pod控制器是管理pod的中间层，使用Pod控制器之后，只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod资源在运行中出现故障，它会基于指定策略重新编排Pod

当建立控制器后，会把期望值写入etcd，k8s中的apiserver检索etcd中我们保存的期望状态，并对比pod的当前状态，如果出现差异代码自驱动立即恢复

二 控制器常用类型

控制器名称控制器用途
Replication Controller比较原始的pod控制器，已经被废弃，由ReplicaSet替代
ReplicaSetReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行
Deployment一个 Deployment 为 Pod 和 ReplicaSet 提供声明式的更新能力
DaemonSetDaemonSet 确保全指定节点上运行一个 Pod 的副本
StatefulSetStatefulSet 是用来管理有状态应用的工作负载 API 对象。
Job执行批处理任务，仅执行一次任务，保证任务的一个或多个Pod成功结束
CronJobCron Job 创建基于时间调度的 Jobs。
HPA全称Horizontal Pod Autoscaler根据资源利用率自动调整service中Pod数量，实现Pod水平自动缩放

 

三 replicaset控制器

3.1 replicaset功能

  • ReplicaSet 是下一代的 Replication Controller，官方推荐使用ReplicaSet

  • ReplicaSet和Replication Controller的唯一区别是选择器的支持，ReplicaSet支持新的基于集合的选择器需求

  • ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行

  • 虽然 ReplicaSets 可以独立使用，但今天它主要被Deployments 用作协调 Pod 创建、删除和更新的机制

3.2 replicaset参数说明

参数名称字段类型参数说明
specObject详细定义对象，固定值就写Spec
spec.replicasinteger指定维护pod数量
spec.selectorObjectSelector是对pod的标签查询，与pod数量匹配
spec.selector.matchLabelsstring指定Selector查询标签的名称和值，以key：value方式指定
spec.templateObject指定对pod的描述信息，比如lab标签，运行容器的信息等
spec.template.metadataObject指定pod属性
spec.template.metadata.labelsstring指定pod标签
spec.template.specObject详细定义对象
spec.template.spec.containerslistSpec对象的容器列表定义
spec.template.spec.containers.namestring指定容器名称
spec.template.spec.containers.imagestring指定容器镜像

3.3 replicaset 示例

#replicaset是通过标签匹配pod

修改标签后

#恢复标签后

#replicaset自动控制副本数量，pod可以自愈

 replicaset无法更新版本所以需要用到deployment控制器

四 deployment 控制器

4.1 deployment控制器的功能

  • 为了更好的解决服务编排的问题，kubernetes在V1.2版本开始，引入了Deployment控制器。

  • Deployment控制器并不直接管理pod，而是通过管理ReplicaSet来间接管理Pod

  • Deployment管理ReplicaSet，ReplicaSet管理Pod

  • Deployment 为 Pod 和 ReplicaSet 提供了一个申明式的定义方法

  • 在Deployment中ReplicaSet相当于一个版本

典型的应用场景：

  • 用来创建Pod和ReplicaSet

  • 滚动更新和回滚

  • 扩容和缩容

  • 暂停与恢复

 

4.2 deployment控制器示例

版本迭代

#pod运行容器版本为v1

更新的过程是重新建立一个版本的RS，新版本的RS会把pod 重建，然后把老版本的RS回收

测试：

版本回滚

滚动更新策略

暂停及恢复

在实际生产环境中我们做的变更可能不止一处，当修改了一处后，如果执行变更就直接触发了

我们期望的触发时当我们把所有修改都搞定后一次触发暂停，避免触发不必要的线上更新

暂停滚动更新

做资源限制

#调整副本数，不受影响

[root@master pod]# kubectl describe pods deployment-5f4d6b95df-7fzmb 
Name:             deployment-5f4d6b95df-7fzmb
Namespace:        default
Priority:         0
Service Account:  default
Node:             k8snode1/192.168.10.10
Start Time:       Wed, 12 Mar 2025 16:09:18 +0800
Labels:           app=myapp
                  pod-template-hash=5f4d6b95df
Annotations:      <none>
Status:           Running
IP:               10.244.1.14
IPs:
  IP:           10.244.1.14
Controlled By:  ReplicaSet/deployment-5f4d6b95df
Containers:
  myapp:
    Container ID:   docker://f414b15cd85f4d034d57b88c4d9aefd6f1699794b1852ff1113dd3af4ba5e00e
    Image:          reg.timinglee.org/library/myapp:v1
    Image ID:       docker-pullable://reg.timinglee.org/library/myapp@sha256:9eeca44ba2d410e54fccc54cbe9c021802aa8b9836a0bcf3d3229354e4c8870e
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Wed, 12 Mar 2025 16:09:18 +0800
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-n2sdf (ro)
Conditions:
  Type                        Status
  PodReadyToStartContainers   True 
  Initialized                 True 
  Ready                       True 
  ContainersReady             True 
  PodScheduled                True 
Volumes:
  kube-api-access-n2sdf:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  21m   default-scheduler  Successfully assigned default/deployment-5f4d6b95df-7fzmb to k8snode1
  Normal  Pulled     21m   kubelet            Container image "reg.timinglee.org/library/myapp:v1" already present on machine
  Normal  Created    21m   kubelet            Created container myapp
  Normal  Started    21m   kubelet            Started container myap

#但是更新镜像和修改资源并没有触发更新

#恢复后开始触发更新

五 daemonset控制器

5.1 daemonset功能

DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时， 也会为他们新增一个 Pod ，当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod

DaemonSet 的典型用法：

  • 在每个节点上运行集群存储 DaemonSet，例如 glusterd、ceph。

  • 在每个节点上运行日志收集 DaemonSet，例如 fluentd、logstash。

  • 在每个节点上运行监控 DaemonSet，例如 Prometheus Node Exporter、zabbix agent等

  • 一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使用

  • 一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet，但具有不同的标志， 并且对不同硬件类型具有不同的内存、CPU 要求

5.2 daemonset 示例

六 job 控制器

6.1 job控制器功能

Job，主要用于负责批量处理(一次要处理指定数量任务)短暂的一次性(每个任务仅运行一次就结束)任务

Job特点如下：

  • 当Job创建的pod执行成功结束时，Job将记录成功结束的pod数量

  • 当成功结束的pod达到指定的数量时，Job将完成执行

6.2 job 控制器示例：

 

  • 如果指定为OnFailure，则job会在pod出现故障时重启容器

    而不是创建pod，failed次数不变

  • 如果指定为Never，则job会在pod出现故障时创建新的pod

    并且故障pod不会消失，也不会重启，failed次数加1

  • 如果指定为Always的话，就意味着一直重启，意味着job任务会重复去执行了

七 cronjob 控制器

7.1 cronjob 控制器功能

  • Cron Job 创建基于时间调度的 Jobs。

  • CronJob控制器以Job控制器资源为其管控对象，并借助它管理pod资源对象，

  • CronJob可以以类似于Linux操作系统的周期性任务作业计划的方式控制其运行时间点及重复运行的方式。

  • CronJob可以在特定的时间点(反复的)去运行job任务

7.2 cronjob 控制器 示例

区别

CronJob 控制器和 Job 控制器都用于处理批处理任务，但它们在功能、使用场景、执行方式等方面存在明显区别，下面为你详细介绍：

1. 功能定位

  • Job 控制器
    • Job 控制器的主要功能是创建一个或多个 Pod 来执行特定的任务，直到达到指定的成功完成次数。一旦任务完成（所有 Pod 成功执行并退出），Job 就会被标记为完成状态。它专注于确保任务在集群中可靠地执行一次或多次。
  • CronJob 控制器
    • CronJob 控制器是基于 Job 控制器构建的，它增加了按时间调度的功能。CronJob 可以按照指定的时间间隔（如每分钟、每小时、每天等）定期创建 Job，从而实现任务的周期性执行。

2. 使用场景

  • Job 控制器
    • 一次性任务：适用于只需要执行一次的任务，例如数据迁移、批量数据处理、备份任务等。比如，将旧数据库中的数据迁移到新数据库，这种任务通常只需要执行一次，使用 Job 可以确保任务成功完成。
    • 多次执行但无时间规律：当需要执行多次相同的任务，但这些任务之间没有特定的时间间隔要求时，可以使用 Job 并设置 spec.completions 来指定任务需要成功完成的次数。
  • CronJob 控制器
    • 周期性任务：适合需要定期执行的任务，如每天凌晨进行数据备份、每小时收集系统监控数据、每分钟清理临时文件等。通过 CronJob 可以方便地按照预定的时间计划执行这些任务。

 


http://www.ppmy.cn/server/174565.html

相关文章

【01】HTTP基本原理

【01】HTTP基本原理

目录 一、URI和URL 二、超文本 三、http和https 3.1 HTTP&#xff08;超文本传输协议&#xff09; 3.2 HTTPS&#xff08;超文本传输安全协议&#xff09; 四、HTTP请求过程 五、请求 5.1. 请求方法 5.2. 请求的网址 5.3 请求头 5.4 请求体 六、响应 1. 响应状态码…
阅读更多...
【MySQL】基本操作 —— DDL

【MySQL】基本操作 —— DDL

目录 DDLDDL 常用操作对数据库的常用操作查看所有数据库创建数据库切换、显示当前数据库删除数据库修改数据库编码 对表的常用操作创建表数据类型数值类型日期和时间类型字符串类型 查看当前数据库所有表查看指定表的创建语句查看指定表结构删除表 对表结构的常用操作给表添加字…
阅读更多...
Mesh网络

Mesh网络

Mesh网络&#xff08;Mesh Network&#xff09;是一种网络拓扑结构&#xff0c;所有节点互相连接&#xff0c;协同工作&#xff0c;动态分配数据和路由任务。它不同于传统的星型或树型结构&#xff0c;具有去中心化、高可靠性和灵活扩展的特点。 Mesh网络的特点 去中心化&#…
阅读更多...
基于SpringBoot的“体育购物商城”的设计与实现（源码+数据库+文档+PPT)

基于SpringBoot的“体育购物商城”的设计与实现（源码+数据库+文档+PPT)

基于SpringBoot的“体育购物商城”的设计与实现&#xff08;源码数据库文档PPT) 开发语言&#xff1a;Java 数据库&#xff1a;MySQL 技术&#xff1a;SpringBoot 工具&#xff1a;IDEA/Ecilpse、Navicat、Maven 系统展示 系统总体模块设计 前台用户登录界面 系统首页界面…
阅读更多...
植物学（botany）这个单词怎么记？牛吃草，草是一种植物

植物学（botany）这个单词怎么记？牛吃草，草是一种植物

植物学&#xff08;botany&#xff09;这个单词怎么记&#xff1f; botany n.植物学 botany 这个单词&#xff0c;词源上来自 botanic 一词&#xff1a; botanic a.植物学的 SYN: botanical(a.植物学的) 因此&#xff0c;英语词根botan-&#xff0c;意为“植物”。比如&…
阅读更多...
【医学半监督分割】不确定性感知一致性学习

【医学半监督分割】不确定性感知一致性学习

Uncertainty-aware consistency learning for semi-supervised medical image segmentation 半监督医学影像分割面临两个挑战性问题&#xff1a;&#xff08;1&#xff09;对潜在结构的探索不足&#xff0c;导致难以全面捕捉医学影像中的复杂特征和结构&#xff1b;&#xff08…
阅读更多...
DeepSeek助力CFD仿真学习：剖析与实用指南

DeepSeek助力CFD仿真学习：剖析与实用指南

在CFD&#xff08;计算流体动力学&#xff09;的学习征程中&#xff0c;学习者面临着诸多挑战&#xff0c;从复杂的基础概念、深奥的数学理论&#xff0c;到编写UDF代码、阅读海量文献以及调试仿真等。此时&#xff0c;一款得力的智能助手显得尤为重要。国产AI模型DeepSeek在这…
阅读更多...
Python从入门到精通1：FastAPI

Python从入门到精通1：FastAPI

引言 在现代 Web 开发中&#xff0c;API 是前后端分离架构的核心。FastAPI 凭借其高性能、简洁的语法和自动文档生成功能&#xff0c;成为 Python 开发者的首选框架。本文将从零开始&#xff0c;详细讲解 FastAPI 的核心概念、安装配置、路由设计、请求处理以及实际应用案例&a…
阅读更多...
最新文章

Copyright @ 2022~2023