容器的基本概念

容器的本质上其实就是一个视图被隔离（namespace机制，chroot机制），资源访问受限的进程（cgroups机制）。容器中PID=1的进程就是应用本身，那么就意味着在管理容器的时候，我们其实就是在管理容器本身。而在寻常的虚拟机中，我们在管理的是机器本身，那么容器化就是不可变基础设施的最佳体现，也是未来Paas架构模式的最佳体现方式之一。

如果说K8S本身就是OS，那么在OS中，一个程序实际上是由多个线程组成的。

我们这边以阿里云ECS服务器为例，我们可以看到Systemd进程是由多个线程来组成的。

也就是说，这么多进程同时协作，共享Systemd程序的资源，组成了systemd程序的工作状态，所以这就是进程组的一个概念。

进程组概念

容器的设计本身是一种“单进程“的模型，因为我们PID=1的这个进程的本身就是容器本身，那么容器就是进程本身，而其他的进程就是在这个容器中的低级进程，而PID=1的进程就是高级进程，通过进程共享资源空间，能够相互访问的特点，就形成了高级进程对低级进程的管理，所以说，服务应用进程本身是具有进程管理能力的。

而如果某程序有system的能力，那么直接把PID=1的进程改为systemed，不然这个进程没有更高级的权限是没有办法管理其他进程的。但是如果这个PID=1成立了，运行环境确实是Systemed级别的，那么我们管理容器是不是和VM模式下的管理是相同的，我们对systemed管理就类似于我们对虚拟机的管理而不是对应用本身的管理。

而如果我们在容器中运行一个systemed，用来管理我们的其他所有的进程，那么我们可能就没有办法直接管理我们的进程，而是需要通过sytemed来管理我们的进程，这个时候应用状态和容器处于一个割裂的情况，可能会出现我们的应用程序崩溃，但是容器运行情况良好的可能性，那么在这个情况下，我们没有办法来说出那句“应用就是容器，容器就是应用“，这和我们的云原生的理念是相违背的。

而POD其实就是一组进程，每一个POD都是一个进程，他们相互协作共同组成了一个systemd系统。
因此pod就是K8S的原子调度单位。而POD的底层就是由Docker来实现。

因为计算机资源的紧缺，同时我们需要实现k8S的水平扩展和弹性扩充的能力，我们需要让我们的pod成为原子调度单位，这样更好的让我们来进行某个特定进程（特定业务所对应的进程）进行故障恢复和处理，有这样我们能够解决资源冲突的问题，来针对每一个pod进行资源的分配，而k8S本身能够通过控制器来实现资源的分配，并通过调度器来解决这个问题。Apiserver的作用就是沟通这些组件共同为pod服务，而pod作为工作负载来实现系统的基本功能。

两个POD之间可能会发现文件交换，例如对同一个共享文件资源的读写，或者是通过socket进行网络通信、RPC远程程序调用等，这样的情况需要POD去申请api server和调度器沟通，来实现资源的访问。
而对于文件资源的功能，可以通过数据挂在的方式来解决，这样能较好地解决分布在不同地放的文件或者是数据资源的访问，避免每个应用都需要我们去配置独立的配置文件。
因为配置文件相同，而我们的容器就是应用，我们需要抽象他们的配置，因此，独立的数据挂载显得非常重要了。

Pod 要解决的问题（来源于CNCFx阿里云）

像 Pod 这样一个东西，本身是一个逻辑概念。那在机器上，它究竟是怎么实现的呢？这就是我们要解释的第二个问题。 既然说 Pod
要解决这个问题，核心就在于如何让一个 Pod 里的多个容器之间最高效的共享某些资源和数据。 因为容器之间原本是被 Linux
Namespace 和 cgroups 隔开的，所以现在实际要解决的是怎么去打破这个隔离，然后共享某些事情和某些信息。这就是 Pod
的设计要解决的核心问题所在。 所以说具体的解法分为两个部分：网络和存储。

1.共享网络

第一个问题是 Pod 里的多个容器怎么去共享网络？下面是个例子： 比如说现在有一个 Pod，其中包含了一个容器 A 和一个容器 B，它们两个就要共享 Network Namespace。在 Kubernetes 里的解法是这样的：它会在每个 Pod
里，额外起一个 Infra container 小容器来共享整个 Pod 的 Network Namespace。 Infra
container 是一个非常小的镜像，大概 100~200KB 左右，是一个汇编语言写的、永远处于“暂停”状态的容器。由于有了这样一个
Infra container 之后，其他所有容器都会通过 Join Namespace 的方式加入到 Infra container 的
Network Namespace 中。 所以说一个 Pod
里面的所有容器，它们看到的网络视图是完全一样的。即：它们看到的网络设备、IP地址、Mac地址等等，跟网络相关的信息，其实全是一份，这一份都来自于
Pod 第一次创建的这个 Infra container。这就是 Pod 解决网络共享的一个解法。 在 Pod 里面，一定有一个 IP
地址，是这个 Pod 的 Network Namespace 对应的地址，也是这个 Infra container 的 IP
地址。所以大家看到的都是一份，而其他所有网络资源，都是一个 Pod 一份，并且被 Pod 中的所有容器共享。这就是 Pod 的网络实现方式。
由于需要有一个相当于说中间的容器存在，所以整个 Pod 里面，必然是 Infra container 第一个启动。并且整个 Pod
的生命周期是等同于 Infra container 的生命周期的，与容器 A 和 B 是无关的。这也是为什么在 Kubernetes
里面，它是允许去单独更新 Pod 里的某一个镜像的，即：做这个操作，整个 Pod 不会重建，也不会重启，这是非常重要的一个设计。

2.共享存储

第二问题：Pod 怎么去共享存储？Pod 共享存储就相对比较简单。 比如说现在有两个容器，一个是 Nginx，另外一个是非常普通的容器，在 Nginx 里放一些文件，让我能通过 Nginx 访问到。所以它需要去 share 这个目录。我
share 文件或者是 share 目录在 Pod 里面是非常简单的，实际上就是把 volume 变成了 Pod
level。然后所有容器，就是所有同属于一个 Pod 的容器，他们共享所有的 volume。