持续分享，个人的运维经验，包含：云计算、Linux、Windows、容器、K8s、CICD、Python、运维开发、公有云等；以及个人经历相关内容，包含：实习、面试经验等。

大家好，我是秋意零。在上一篇中，我们讲解了 DaemonSet 控制器，相信你以及理解了其的工作过程，分为三部。一是，获取所有 Node 节点中的 Pod；二是，判断是否有符合 DaemonSet 管理的 Pod；三是，通过“亲和性”和“容忍”来精确控制并保证 Pod 在目标节点运行。今天的内容是 Job 与 CronJob 离线业务控制器。👿 简介🏠个人主页秋意零🔥账号：全平台同名，秋意零账号创作者、云社区创建者🧑个人介绍：在校期间参与众多云计算相关比赛，如：🌟“省赛”、“国赛”

大家好，我是秋意零。在上一篇中，我们讲解了 StatefulSet 的存储状态；我们发现，它的存储状态，就是利用了 PV 与 PVC 的设计。StatefulSet 自动为我们创建 PVC 并且以--命名，从而始终与 Pod 编号名一致的绑定。需要注意的是：StatefulSet 的“滚动更新”是从最后一个 Pod 开始的，为了不破坏拓扑状态。如：主从数据库，主的 Pod 编号是 0，后面是从，如果先更新主数据库 0 编号，那么后面的从数据库就会出现问题。

大家好，我是秋意零。在上一篇中，我们讲解了 StatefulSet 的拓扑状态；我们发现，它的拓扑状态，就是顺序启动/删除、Pod 名称+编号命名、将 Pod 名称设为 Hostname 名称、通过 Service 无头服务的 DNS 记录访问。今天，就来看看 StatefulSet 的存储状态。最近搞了一个扣扣群，旨在技术交流、博客互助，希望各位大佬多多支持！获取方式：1.在我主页推广区域，如图：2.文章底部推广区域，如图：👿 简介🏠个人主页秋意零🧑个人介绍。

大家好，我是秋意零。在上一篇中，我们讲解了 Deployment 这种无状态的控制器；而如果要部署有状态的应用，那么 Deployment 显然是达不到我们的需求的。今天讲解的是 StatefulSet 有状态控制器。最近搞了一个扣扣群，旨在技术交流、博客互助，希望各位大佬多多支持！获取方式：1.在我主页推广区域，如图：👿 简介🏠个人主页秋意零🧑个人介绍：在校期间参与众多云计算相关比赛，如：🌟“省赛”、“国赛”，并斩获多项奖项荣誉证书🎉目前状况。

Deployment 实现了非常重要的功能：Pod 的水平扩展、水平收缩、滚动更新。今天讲解了，Deploymen 最基本的编排控制器的实现原理和使用方法。分别说明了，水平扩展/收缩、滚动更新、回滚的机制实现。

今天，说明了 ”控制器模式“ 的方法。如：Deployment 它的控制循环是如何工作的，这个部分我们介绍了一个 Go 语言的伪代码。接着，简单介绍了，Kubernetes 是如何来区分谁是谁的控制对象的，答案是：使用 ownerReference 用于保存拥有者 API 对象（Owner）的信息来分辨的。最后：技术交流、博客互助，点击下方或主页推广加入哦！！

主要讲解了，Pod 的健康检查的基本概率，以及 Exec、HTTP、TCP 三种使用方式；接着讲解了 Pod 的恢复机制，我们知道了，实际上 Pod 的恢复机制就是 Pod 的三种重启策略。至此 Pod 的内容也基本介绍完了，目前剩下就绪检查的概率，这个后续会说明。下一章将是控制器部分的内容。最后：技术交流、博客互助，点击下方或主页推广加入哦！！

今天，介绍了 Pod 的 Volume 的 Projected 服务对象。你还应该认真体会一下 Kubernetes “一切皆对象” 的设计思想：比如，应用是 Pod 对象，应用的配置是 ConfigMap 对象，应用要访问的密码则是 Secret 对象。最后：技术交流、博客互助，点击下方或主页推广加入哦！！

今天介绍了，Pod 的基本概念。重点说明了，Pod 的 API 对象属性字段，那些是属于 Pod 级别，那些是属于容器级别的。所以你应该了解了，能够区分大部分 Pod 的 API 对象属性字段的级别是什么。之后介绍了，Pod 的一些常用字段的用法。

前一篇，我们介绍了如何从 0 到 1 搭建 Kubernetes 集群。现在我们可以正式了解，Kubernetes 核心特征了。今天我们来探究 Pod，为什么需要 Pod？

今天介绍了，使用 kubeadm 部署 Kubernetes 集群，可以发现其实并不复杂。重点简述了 kubeadm 初始化集群部分。Rook 是很有前途的项目，合理的使用了很多，如： Operator、CRD 等重要的扩展特性。大家可以先去了解一下这个项目。最后，今天我们从 0 到 1 搭建 kubernetes 集群就算是介绍完了。如有不对的地方，欢迎各位大佬指正。

这里，我们分享了 kubeadm 部署 kubernetes 的使用方式。我们从为何出现 kubeadm，解决了什么问题开始了我们这篇文章的开头。然后我们了解到 kubeadm 部署 Master 组件方式时采用容器化部署，而为什么 kubelet 组件没有采用容器化部署的原因。最后，我们聊了聊 kubeadm 的 init 工作过程和 join 工作过程。init 工作过程大致上就是：检查环境、生成证书，配置访问 apiserver 的配置文件、以 Pod 部署方式部署 Master 组件。

首先我们简单的回顾了一下前面章节的知识，理解静态视图和动态视图，了解开发和运维在容器中所承担的角色。接着我们介绍了 Kubernetes 它和 borg 系统和论文之间的关系，这里也说明了 Kubernetes 诞生的基础，阐述了 Kubernetes 是为解决什么问题而诞生的。然后我们重点介绍了 Kubernetes 的全局架构图，从 Master 控制节点和 Node 计算节点展开。最后我们说明了设计思想所站在的高度和其他项目有什么不同，同时阐述了 Kubernetes 之间的对象服务关系，分清

这里，介绍了 Linux 容器进程文件系统的实现方式，而这种机制，正是我们经常提到的容器镜像，也叫作：rootfs。它只是一个操作系统的所有文件和目录，并不包含内核，所以对比虚拟机的镜像要小的多。通过结合使用 Mount Namespace 和 rootfs，容器就能够为进程构建出一个完善的文件系统隔离环境。这需要依赖 chroot 和 pivot_root 切换进程根目录的能力。在 rootfs 根文件系统的基础上，Docker 使用了一个 overlay2 联合文件挂载。

大家好，我是秋意零。上一章提到，容器本质是一个进程，通过 Linux 系统 NameSpace 技术实现资源隔离（障眼法），通过它修改了进程看待整个操作系统“视角”，只能看到某些指定的内容。

相信大家学容器时都看过这个虚拟机和容器的对比图。左边是虚拟机的工作原理，其中Hypervisor 软件是虚拟机最重要的部分它可以实现模拟出各种硬件，比如：CPU、内存、磁盘等，在Hypervisor 软件层之上创建 Guest OS 也就是客户机操作系统，Guest OS 和 Hypervisor 模拟出来的硬件交互，这样用户应用程序就可以运行在这个虚拟机中，用户自然看到的就是这个新的操作系统的文件系统结构，这也是虚拟机也能起到将不同应用程序相互隔离的原因。