Pod和容器基本概念

容器的基本概念

容器的本质上其实就是一个视图被隔离(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。

猜你喜欢

转载自blog.csdn.net/qq_27180763/article/details/123798216