在前面的文章中，我们讨论了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）。举个例子，如果

在前面的文章中，我们已经对Pod对象进行了深入地讨论。接下来，我们一起来看Kubernetes项目最核心的功能，编排。 一、从一个例子说起 在前面讨论Pod对象时，我们做出了一个这样的总结：“容器，是进程；Pod，是操作系统”。由于容器描述应用时过于简单，因此kubernetes将容器进一步抽象、封装成了Pod。在kubernetes的世界中，通常不会直接操作Pod对象，而是由控制器完成。比如，下

在前面的文章中，我们已经深入讨论了Pod的API对象，以及Pod和Container的关系。接下来，我们先从一种特殊的Volume开始，更加深入地理解Pod对象各个重要字段的含义。 一、Projected Volume 在 Kubernetes 中，有几种特殊的 Volume，它们存在的意义不是为了存放容器里的数据，也不是用来进行容器和宿主机之间的数据交换。这些特殊 Volume 的作用，是为容器

在前面的文章中，我们详细讨论了Pod的实现原理和容器设计模式。接下来，我们来看看有关Pod对象的更多细节。 一、Pod VS 虚拟机 在 Kubernetes 项目中，最小的编排单位是Pod。将这个设计落实到 API 对象上后，容器（Container）就成了 Pod 属性里的一个普通的字段。此时，一个很自然的问题就是： 到底哪些字段属于 Pod 对象，而又有哪些字段属于 Container ？

接触过kubernetes的同学，对Pod这个概念一定不陌生。它是Kubernetes项目中最小的API对象。用更专业的术语来描述：Pod，是Kubernetes项目的原子调度单位。但我们是否思考过：我们为什么需要Pod？接下来，我们就来讨论一下这个问题。 一、从进程组说起 首先，我们登录到一台 Linux 机器里，执行一条如下所示的命令： 1$ pstree -gt 这条命令的作用，是展示当前系

在前面的文章中，我们围绕“Namespace做隔离、Cgroups做限制、Rootfs做文件系统”对Linux容器的核心实现原理展开了详细的讨论。接下来，我们通过一个实际案例对前面的内容做一次深入的总结和扩展。 一、从一个Python应用说起 在开始实践之前，我们需要准备一台 Linux 机器，并安装 Docker。这个流程可以参考Docker官网，就不在此赘述了。 这一次，我们用 Docker

todo 一、理解Mount Namespace 如下，是一个小程序，它的作用是在创建子进程时开启指定的Namespace。 12345678910111213141516171819202122232425262728293031#define _GNU_SOURCE#include <sys/mount.h> #include <sys/types.h>#include

在我们真的了解容器吗这文章中，我们讨论了Linux容器中用来实现“隔离”的技术手段：Namespace。接下来，我们一起来了解一下容器的限制机制。 一、再谈隔离 我们知道，Namespace技术实际上修改了进程能够看到的计算机“视图”，即它的“视线”被操作系统做了限制，只能“看到”某些指定的内容。但对于宿主机来说，这些被“隔离”的进程跟其他进程并没有太大区别。 此外，我们需要知道的是，Docker