导语：K8S作为目前容器编排工具的主流平台，其基本逻辑概念在学习时有些理解上的困难，笔者通过与一个电子商城应用的通用概念进行类比，希望可以快速地介绍清楚Namespace、pod、container、servicer、volume等基础概念，希望对大家有所帮助。
我们以一个电子商城应用举例，然后再对应到k8s的对象上，首先对齐一下语言：
- 一个电子商城为一个应用；
- 一个电子商城有展示页、产品、购物车、用户、支付等应用模块；
- 每个应用模块都是多副本部署以保障可靠性及扩展性，且可以独立访问，每个副本是一组关系紧密的进程，如产品模块有主进程、日志进程等。
那么一个应用的结构如下图所示：
应用结构那么我们的k8s在应用编排时是如何对应的呢？
- 一个Namespace通常对应一个应用
- 一个Deployment对应一个应用模块（集群版），定义了应用模块提供服务的最终态。
- 一个Pod对应一个应用模块的单机版（一个副本），含一个或多个Container（一般不重复），也可以理解为关系亲密的进程组，pod中的container共享数据栈和网络栈。
- 一个Container对应应用模块单机版的一个进程。
- 一个Service对应一个应用模块的访问入口。
- 一个Volume对应一个应用模块的存储卷，不同容器可以将数据持久化到卷上的不同目录。
对应上面应用结构的形式，k8s基础对象关系如下图：
这些pod会被k8s做为最基础的调度单元，分配运行在不同的node上（物理机或者虚拟机上）。
通过k8s基础概念比对应用的概念可以帮助大家更快地理解。
最后有一个初学k8s时遇到的问题：k8s为什么把pod作为调度的原子单元，而不是container？
答案如下：
因为通常一个模块的进程间存在“超亲密”关系，这些进程的特征为需要共享内存、存储及使用localhost高效通讯，这类“进程组”需“打包”为一个整体进行调度，可以简单地理解为需要部署在一个node上（ 举例如下图1）。
图1（Pod中的进程运行在一个node上）如果以container为粒度调度，进程/container可能被调度到不同node，从而无法共享数据及网络资源，导致模块失效（如下图2）。
图2：没有pod概念，container被调度到不同node总之：以pod（即进程组）为最小单位进行调度，既可以满足“超亲密”进程的资源共享需求，又提供了不亚于单container调度的灵活性（即一个pod由一个container构成）。
参考材料：
k8s核心对象：https://www.bilibili.com/video/BV1Nd4y1S7qa/?spm_id_from=333.788.top_right_bar_window_custom_collection.content.click&vd_source=d9f43531a9b37c3d4e6b06ae3d1de823
kubernetes-阿里云与CNCF联合推出的云原生技术公开课：https://www.bilibili.com/video/BV1r7411r7h7?p=4&vd_source=d9f43531a9b37c3d4e6b06ae3d1de823
