凡是调度、网络、存储、以及安全相关的属性，基本上是 Pod 级别的。 这些属性的共同特征是，它们描述的是“机器”这个整体，而不是里面运行的“程序”。
在前面的文章中，详细介绍了 Kubernetes 中部署一个应用的过程。在这些讲解中，提到了这样一个知识点：Pod，是 Kubernetes 项目中最小的 API 对象。如果换一个更专业的说法，我们可以这样描述：Pod，是 Kubernetes 项目的原子调度单位。
不过，我相信你在学习和使用 Kubernetes 项目的过程中，已经不止一次地想要问这样的一个问题：为什么我们会需要 Pod？
在 Kubernetes 项目初期，它的部署完全要依靠一堆由社区维护的脚本。除了将各个组件编译成二进制文件外，用户还要负责为这些文件编写对应的配置文件、配置自启动脚本，以及为 kube-apiserver 配置授权文件等等诸多运维工作。
在这篇文章中，我们来扮演一个应用开发者的角色，使用我们已经搭建好的 Kubernetes 集群发布第一个容器化应用。
在上篇文章中介绍了如何使用 kubeadm 一键部署 Master 节点。不过，既然要在本篇文章中部署一个“完整”的 Kubernetes 集群，那不妨提高一下难度：通过配置文件来开启一些新功能。
Kubernetes 项目依托着 Borg 项目的理论优势，在短短几个月内迅速站稳了脚跟，进而确定了一个如下图所示的全局架构：
这一次，我要用 Docker 部署一个用 Python 编写的 Web 应用。
了解了 Namespace 和 Cgroups 技术后，可以来思考一下：容器内的进程看到的文件系统又是什么样的呢？
很显然，这是有关于 Mount Namespace 的问题：容器里的应用进程，理应看到一份完全独立的文件系统。那么，真实情况是这样吗？
“敏捷”和“高性能”是容器相较于虚拟机最大的优势，也是它能够在 PaaS 这种更细粒度的资源管理平台上大行其道的重要原因。
不过，有利就有弊，基于 Linux Namespace 的隔离机制相比于虚拟化技术也有很多不足之处，其中最主要的问题就是：隔离得不彻底。
容器技术的核心功能，就是通过约束和修改进程的动态表现，从而为其创造出一个“边界”。