【探索 Kubernetes|作业管理篇 系列 11】控制器的核心功能

这篇具有很好参考价值的文章主要介绍了【探索 Kubernetes|作业管理篇 系列 11】控制器的核心功能。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

前言

大家好,我是秋意零。

上一篇结束了 Pod 对象的内容。

今天要探讨的内容是 “控制器”,它是 Kubernetes 编排最核心的功能。理解了 “控制器”,你就能理解 Deployment、StatefulSet、DaemontSet、Job、CroJob 控制器对象。

最近搞了一个扣扣群,旨在技术交流、博客互助,希望各位大佬多多支持!

获取方式:

  • 1.在我主页推广区域,如图:

【探索 Kubernetes|作业管理篇 系列 11】控制器的核心功能

  • 2.文章底部推广区域,如图:

【探索 Kubernetes|作业管理篇 系列 11】控制器的核心功能

👿 简介

  • 🏠 个人主页: 秋意零
  • 🧑 个人介绍:在校期间参与众多云计算相关比赛,如:🌟 “省赛”、“国赛”,并斩获多项奖项荣誉证书
  • 🎉 目前状况:24 届毕业生,拿到一家私有云(IAAS)公司 offer,暑假开始实习
  • 🔥 账号:各个平台, 秋意零 账号创作者、 云社区 创建者
  • 💕欢迎大家:欢迎大家一起学习云计算,走向年薪 30 万

【探索 Kubernetes|作业管理篇 系列 11】控制器的核心功能

系列文章目录


【云原生|探索 Kubernetes-1】容器的本质是进程
【云原生|探索 Kubernetes-2】容器 Linux Cgroups 限制
【云原生|探索 Kubernetes 系列 3】深入理解容器进程的文件系统
【云原生|探索 Kubernetes 系列 4】现代云原生时代的引擎
【云原生|探索 Kubernetes 系列 5】简化 Kubernetes 的部署,深入解析其工作流程



更多点击专栏查看:深入探索 Kubernetes

正文开始

  • 快速上船,马上开始掌舵了(Kubernetes),距离开船还有 3s,2s,1s…

【探索 Kubernetes|作业管理篇 系列 11】控制器的核心功能

一、控制器模型

在 Kubernetes中,控制器模式是一种用于管理和维护资源对象的模式。控制器模式基于 Kubernetes 的声明式配置和自动化管理原则,通过监视资源对象的状态和变化,以及根据期望状态进行调谐和调整,实现对应用程序的自动化部署、扩展、修复和管理。

Pod 这个看似复杂的 API 对象,实际上就是对容器的进一步抽象和封装而已。

更形象说明就是,“容器镜像” 虽然好用,但是容器这样一个 “沙盒” 的概念,对应用描述关联性来说,还是太简单了。好比,码头的集装箱好用,但是它四面都是光秃秃的,吊车怎么把它这个集装箱吊起来摆放好呢?(这个摆放过程可以看作编排)

因为,一个容器通常是一个应用 APP,但是现实中基本上不存在一个 APP 就能提供所有服务,必然要使用一些辅助程序,如:Redis、RabbitMQ、MySQL等等中间件;所以,对比到 “一个容器” ,它是不能满足现实中的情况的,因为需要辅助程序,这种情况下 Kubernetes 使用了 Pod。

Pod 对象,其实就是容器的升级版。它对容器进行了组合,添加了更多的属性和字段。这就好比给集装箱四面安装了吊环,使得 Kubernetes 这架 “吊车”,可以更轻松地操作它

而 Kubernetes 操作这些 “集装箱“ 的逻辑,都是控制器(Controller)负责完成。

现在,我们看一个 Deployment 控制器的栗子:

  • Deployment 通过 spec.selector.matchLabels 携带了 app=myapp 标签与 Pod 绑定,这样 Deployment 就能控制于它具有相同标签的 Pod 了;通过 spec.replicas 指定 Pod 期望个数,Deployment 控制器会将 Pod 一直保持在 3 个,少了会创建,多了会删除。
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
  labels:
    app: myapp
spec:
  replicas: 3  # 指定副本数量
  selector:
    matchLabels:
      app: myapp  # 选择标签为`app: myapp`的Pod进行管理
  template:
    metadata:
      labels:
        app: myapp  # Pod的标签
    spec:
      containers:
        - name: myapp-web
          image: nginx  # 指定应用程序的镜像
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80  # 应用程序监听的端口号

验证

[root@master01 yaml]# kubectl apply -f deploy-web.yaml
deployment.apps/myapp-deployment created
[root@master01 yaml]# kubectl get -f deploy-web.yaml
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
myapp-deployment   3/3     3            3           6s
[root@master01 yaml]#
[root@master01 yaml]# kubectl get pod |grep deploy
myapp-deployment-764dfc58c9-dbfrm   1/1     Running            0                 16s
myapp-deployment-764dfc58c9-jwghb   1/1     Running            0                 16s
myapp-deployment-764dfc58c9-z2n7t   1/1     Running            0                 16s

【探索 Kubernetes|作业管理篇 系列 11】控制器的核心功能

二、控制循环

上述的控制操作,是 kube-controller-manager 组件负责的,而所有的控制器都在 kubernetes/pkg/controller 中,如图:

【探索 Kubernetes|作业管理篇 系列 11】控制器的核心功能

源码的 kubernetes/pkg/controller 目录下,保存的都是控制器。它们都遵循 Kubernetes 项目中的一个通用编排模式,即:控制循环(control loop)

Go 语言伪代码表示控制循环:

  • 获取对象的两种状态的值,从而对两种状态的值做比较,等于什么都不做,不等于就让 Pod 保持到期望状态的个数。
for {
  实际状态个数 := 获取集群中对象X的实际状态(Actual State)
  期望状态个数 := 获取集群中对象X的期望状态(Desired State)
  if 实际状态个数 == 期望状态个数{
    什么都不做
  } else {
    执行编排动作,将实际状态调整为期望状态
  }
}

1.实际状态:

  • 实际状态个数,就是 Kubernetes 集群中,真实运行的受 Deployment 控制器管理的 Pod 的个数。这个值可以通过 kubelet 通过心跳汇报的容器状态和节点状态,或者监控系统中保存的应用监控数据,来获取。

2.期望状态:

  • 期望状态,来自于用户提交的 YAML 文件中的 spec.replicas 字段的值。

现在,我们还是以 Deployment 为例,看看控制器实现过程:

  • 1.Deployment 控制器从 Etcd 中获取所有携带 “app: myapp” 标签的 Pod,统计它们的数量,这就是实际状态个数。
  • 2.获取 Deployment 对象的 spec.replicas 字段的值,这就是期望状态个数。
  • 3.Deployment 控制器将这两个状态的值做比较,根据是否相等来判断实际状态个数是否达到期望状态的个数,如果没有就判断是增加 Pod 还是删减 Pod。

可以看到,一个 Kubernetes 对象的主要编排逻辑,实际上是在第三步的 “对比” 阶段完成的。

这个操作,通常被叫作调谐(Reconcile)。这个调谐的过程,则被称作“Reconcile Loop”(调谐循环)或者“Sync Loop”(同步循环)。它们其实指的都是同一个东西:控制循环。

被这个循环控制的部分,是 Deployment 中的 spec.template 字段,template 字段这个在 Deployment 中是 PodTemplate(Pod 模板)。如下图所示,类似 Deployment 这样的一个控制器,实际上都是由上半部分的控制器定义(包括期望状态),加上下半部分的被控制对象的模板组成的。

下图中,Deployment (nginx-deployment)是直接控制 Pod(nginx)的吗?其实不是 Deployment 直接控制 ReplicaSet,ReplicaSet 再次控制 Pod 对象。

【探索 Kubernetes|作业管理篇 系列 11】控制器的核心功能
通过这种被谁是谁的控制对象的概念,其实是通过 API 对象的 Metadata 里,都有一个字段叫作 ownerReference, 用于保存拥有者 API 对象(Owner)的信息来分辨的。

  • 图中,我们查看了,通过 Deployment 控制器所创建的 Pod 的信息,可以看到框出的部分 ownerReference 的 API 对象是 ReplicaSet。

【探索 Kubernetes|作业管理篇 系列 11】控制器的核心功能

  • 我们再来验证查看 RplicaSet 的 ownerReference 是不是 Deployment,如图:

【探索 Kubernetes|作业管理篇 系列 11】控制器的核心功能

总结

今天,说明了 ”控制器模式“ 的方法。

如:Deployment 它的控制循环是如何工作的,这个部分我们介绍了一个 Go 语言的伪代码。

接着,简单介绍了,Kubernetes 是如何来区分谁是谁的控制对象的,答案是:使用 ownerReference 用于保存拥有者 API 对象(Owner)的信息来分辨的。

最后:技术交流、博客互助,点击下方或主页推广加入哦!!

【探索 Kubernetes|作业管理篇 系列 11】控制器的核心功能文章来源地址https://www.toymoban.com/news/detail-500279.html

到了这里,关于【探索 Kubernetes|作业管理篇 系列 11】控制器的核心功能的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【探索 Kubernetes|作业管理篇 系列 10】Pod 健康检查和恢复机制

    大家好,我是秋意零。 上一篇中介绍了,Pod 的服务对象,从而对 Pod 有了更深的理解; 今天的主题是 Pod 健康检查和恢复机制,我们将结束 Pod 的内容。 最近搞了一个扣扣群,旨在技术交流、博客互助,希望各位大佬多多支持!在我主页推广区域,如图: 文章底部推广区域

    2024年02月09日
    浏览(40)
  • 【探索 Kubernetes|作业管理篇 系列 16】离线业务 Job、CronJob

    大家好,我是秋意零。 在上一篇中,我们讲解了 DaemonSet 控制器,相信你以及理解了其的工作过程,分为三部。一是,获取所有 Node 节点中的 Pod;二是,判断是否有符合 DaemonSet 管理的 Pod;三是,通过“亲和性”和“容忍”来精确控制并保证 Pod 在目标节点运行。 今天的内容

    2024年02月12日
    浏览(40)
  • 【探索 Kubernetes|作业管理篇 系列 7】探究 Pod 有什么用,为什么需要它

    大家好,我是秋意零。 前一篇,我们介绍了如何从 0 到 1 搭建 Kubernetes 集群。现在我们可以正式了解,Kubernetes 核心特征了。 今天我们来探究 Pod,为什么需要 Pod? 👿 简介 🏠 个人主页 : 秋意零 🧑 个人介绍 :在校期间参与众多云计算相关比赛,如:🌟 “省赛”、“国

    2024年02月09日
    浏览(51)
  • 【探索 Kubernetes|作业管理篇 系列 8】探究 Pod 的 API 对象属性级别与重要字段用法

    大家好,我是秋意零。 本专栏上一篇中,我们介绍了 Pod 的核心思想以及 Pod 的工作原理。今天我们还是探讨 Pod ,聊一聊 Pod 的基本概念。 👿 简介 🏠 个人主页 : 秋意零 🧑 个人介绍 :在校期间参与众多云计算相关比赛,如:🌟 “省赛”、“国赛” ,并斩获多项奖项荣

    2024年02月08日
    浏览(48)
  • Linux之进程管理篇(2)

    1.1 ps命令 格式: ps  [选项] 作用: 显示进程的状态。没有选项的时候显示当前用户在当前终端启动的进程。 选项: * 高亮的为常用选项 a 显示所有进程 u 指定用户的所有进程 x 显示当前用户在所有终端下的进程信息 c 显示进程的真实名称k|--sort 属性 对属性排序,属性前加

    2024年01月24日
    浏览(40)
  • 【汤4操作系统】深入掌握操作系统-文件管理篇

    数据项记录文件 数据项分为: 基本数据项:描述对象的某些属性,例如学生的年龄,姓名学号等 组合数据项:由若干个基本数据项组合而成 记录:一组相关数据项的集合,用于描述一个对象在某方面的属性 文件:文件是指由创建者所定义的、 具有文件名的一组 相关元素的

    2024年02月09日
    浏览(42)
  • 【探索 Kubernetes|作业管理 Deployment 篇 系列 12】水平扩展 / 收缩、滚动 / 回滚更新

    大家好,我是秋意零。 在上一篇中,我们介绍了控制器的基本设计思想:控制器模式。通过这个 “控制器模式” 我们来看看 Deployment 是如何依靠它来实现的。 最近搞了一个扣扣群,旨在技术交流、博客互助,希望各位大佬多多支持! 获取方式: 1.在我主页推广区域,如图

    2024年02月11日
    浏览(34)
  • U3D客户端框架(资源管理篇)之自动化打Assetbundle包管理器

    AssetBundle是将资源使用Unity提供的一种用于存储资源的压缩格式打包后的集合,它可以存储任何一种Unity可以识别的资源,如模型,纹理图,音频,场景等资源。也可以加载开发者自定义的二进制文件。他们的文件类型是.assetbundle/.unity3d,他们先前被设计好,很容易就下载到我们

    2024年02月09日
    浏览(36)
  • 【管理篇 / 升级】❀ 13. FortiOS 7.4固件升级新规则 ❀ FortiGate 防火墙

    【简介】飞塔防火墙的固件升级一直是所有厂家中最好的。只要有注册官方帐号,有注册设备,并且只要有一台设备在服务期内,即可下载所有型号的所有版本的固件。即使其它设备服务期已过,也可以通过固件文件手动升级,避免防火墙受到漏洞攻击。但是从7.4版本开始,

    2024年01月17日
    浏览(57)
  • 【管理篇 / 恢复】❀ 08. 文件权限对macOS下用命令刷新固件的影响 ❀ FortiGate 防火墙

    【简介】虽然上篇文章中成功的在macOS下刷新了固件,但是很多小伙伴在实际操作中碰到了无法成功的状况,我们来看看最常见的一种。  在/private/tftpboot目录拷贝另一个版本的固件文件,具体拷贝过程不再详述。  打开终端,输入命令  sudo launchctl load -F /System/Library/LaunchDa

    2024年02月02日
    浏览(36)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包