在前面的文章中，我们通过手动方式创建出了所需要的PV。接下来，我们来看一种自动创建PV的方式。 1.1、Static Provisioning & Dynamic Provisioning 在一个大规模的Kubernetes集群中，集群用户可能会创建出成千上万个PVC，这时，集群管理员就需要不停地创建出满足一定条件的PV，否则新Pod就会因为PVC无法绑定PV而运行失败。显然，在实际操作中

我们要知道的是，所谓的容器Volume，其实就是将宿主机上的一个目录，跟容器中的一个目录绑定挂载在一起。而所谓的“持久化Volume”，指的就是宿主机上的目录具备“持久性”。即，这个目录里的内容，即不会因为容器的删除而被清理掉，也不会跟当前的宿主机绑定。这样，当容器被重启或者在其它节点上重建，它仍然能通过挂载这个Volume，访问到这些内容。 那么，在Kubernetes中又是如何准备持久化目录的

一个优秀的云计算项目自然少不了存储资源的管理。在kubernetes中，为了简化用户使用持久化存储的门槛，引入了一组叫作 Persistent Volume（PV）和Persistent Volume Claim（PVC）的 API 对象。 1.1、PV对象 PV对象用于描述集群中的存储资源。它主要定义了存储服务的访问信息（或实现细节），比如一个NFS服务的共享信息。通常情况下，PV对象是由集群

在 Kubernetes 中，管理“有状态应用”是一个比较复杂的过程，尤其是编写 Pod 模板的时候，总有一种“在 YAML 文件里编程序”的感觉，让人很不舒服。而在 Kubernetes 生态中，还有一个相对更加灵活和编程友好的管理“有状态应用”的解决方案，它就是：Operator。接下来，我们就以 Etcd Operator 为例，讨论一下 Operator 的工作原理和编写方法。 一、Ope

在前面的文章中，我们已经讨论Deployment、StatefulSet以及DaemonSet这三个编排对象。接下来，我们讨论另一种重要的对象：Job 一、在线业务 vs 离线业务 Deployment、StatefulSet，以及 DaemonSet 这三个编排对象，它们主要编排的都是“在线业务”，即：Long Running Task（长作业）。比如，我在前面举例时常用的 Nginx、Tomc

在前面的文章中，我们讨论了StatefulSet的工作原理。接下来，我们再看看容器化守护进程的意义，即：DaemonSet。 一、从滚动更新StatefulSet说起 StatefulSet 其实就是对现有典型运维业务的容器化抽象。也就是说，我们一定有方法在不使用 Kubernetes、甚至不使用容器的情况下，自己 DIY 一个类似的方案出来。但是，一旦涉及到升级、版本管理等更工程化的能力，Kub

在前面的文章中，我们主要讨论了StatefulSet是如何处理拓扑状态和存储状态的，以及StatefulSet的工作原理。接下来，我们通过一个实际例子，熟悉一下部署一个StatefulSet的完整流程。 一、部署MySQL主从集群的三座大山 相比于 Etcd、Cassandra 等“原生”就考虑了分布式需求的项目，MySQL 以及很多其他的数据库项目，在分布式集群的搭建上并不友好，甚至有点“原始”

在前面的文章中，我们讨论了StatefulSet如何保证应用实例的拓扑状态。接下来，我们重点讨论StatefulSet如何保证应用的存储状态。 一、从PVC和PV说起 StatefulSet 对存储状态的管理，主要依赖于一个叫作 Persistent Volume Claim 的功能。 1.1、没有PVC和PV之前 我们知道，在一个 Pod 里声明 Volume，只要在 Pod 里加上 spec.

在前面的文章中，我们讨论了Deployment控制器的工作原理，但Deployment控制器并不足以覆盖所有的应用编排问题。接下来，我们重点讨论Kubernetes提供的另一种重要的编排能力：StatefulSet。 一、从有状态应用说起 Deployment 对应用做了一个简单化假设：一个应用的所有 Pod，是完全一样的。所以，它们互相之间没有顺序，也无所谓运行在哪台宿主机上。需要的时候，Dep

在前面讨论控制器模式的文章中，我们提到了Deployment这个控制器，接下来，我们重点讨论一下这个控制器的工作原理。 一、从ReplicaSet说起 Deployment 看似简单，但实际上，它实现了 Kubernetes 项目中两个非常重要的功能：Pod 的“水平扩展 / 收缩”（horizontal scaling out/in）和“滚动更新”（rolling update）。举个例子，如果