接下来，我们就一起来看看“编排”这个 Kubernetes 项目最核心的功能吧。
实际上，你可能已经有所感悟：Pod 这个看似复杂的 API 对象，实际上就是对容器的进一步抽象和封装而已。

在本篇，我们就先从一种特殊的 Volume 开始，来帮助你更加深入地理解 Pod 对象各个重要字段的含义。

凡是调度、网络、存储、以及安全相关的属性，基本上是 Pod 级别的。 这些属性的共同特征是，它们描述的是“机器”这个整体，而不是里面运行的“程序”。

在前面的文章中，详细介绍了 Kubernetes 中部署一个应用的过程。在这些讲解中，提到了这样一个知识点：Pod，是 Kubernetes 项目中最小的 API 对象。如果换一个更专业的说法，我们可以这样描述：Pod，是 Kubernetes 项目的原子调度单位。
不过，我相信你在学习和使用 Kubernetes 项目的过程中，已经不止一次地想要问这样的一个问题：为什么我们会需要 Pod？

在 Kubernetes 项目初期，它的部署完全要依靠一堆由社区维护的脚本。除了将各个组件编译成二进制文件外，用户还要负责为这些文件编写对应的配置文件、配置自启动脚本，以及为 kube-apiserver 配置授权文件等等诸多运维工作。

在这篇文章中，我们来扮演一个应用开发者的角色，使用我们已经搭建好的 Kubernetes 集群发布第一个容器化应用。

部署 Kubernetes 的 Master 节点

在上篇文章中介绍了如何使用 kubeadm 一键部署 Master 节点。不过，既然要在本篇文章中部署一个“完整”的 Kubernetes 集群，那不妨提高一下难度：通过配置文件来开启一些新功能。

Kubernetes 项目依托着 Borg 项目的理论优势，在短短几个月内迅速站稳了脚跟，进而确定了一个如下图所示的全局架构：

这一次，我要用 Docker 部署一个用 Python 编写的 Web 应用。

了解了 Namespace 和 Cgroups 技术后，可以来思考一下：容器内的进程看到的文件系统又是什么样的呢？
很显然，这是有关于 Mount Namespace 的问题：容器里的应用进程，理应看到一份完全独立的文件系统。那么，真实情况是这样吗？