更简单的理解Pod和容器

一、容器的理解

容器的本质实际上是一个进程，一个视图被隔离，资源受限制的进程。

容器里PID = 1的进程就是应用本身，管理虚拟机 = 管理基础设施，管理容器 = 管理应用本身。

那么Kubernetes呢？

Kubernetes就是云时代的操作系统，以此类推，容器镜像其实就是这个操作系统的软件安装包。

二、Pod的理解

1、进程组的概念

在Kubernetes里面，Pod实际上正式kubernetes项目为你抽象出来的一个可以类比为进程组的概念。

也就是Pod = “进程组”。Pod也是原子调度调度单位。那为什么需要Pod呢？我们来看下不停的容器之间需要解决的问题。

不同的容器之间需要解决的一些问题。

1、比如两个进程之间会发生文件交换，一个写日志，一个读日志；

2、两个进程之间需要通过localhost或者说是本地的Socket去进行通信；

3、这两个容器或者是微服务之间，需要发生非常频繁的RPC调用；

4、两个容器或者是应用，它们需要共享某些Linux Namespace。最简单常见的一个例子，就是我有一个容器需要加入另一个容器的Network Namespace。这样我就能看到另一个容器的网络设备，和它的网络信息。

以上的这些问题，他们都是在Kubernetes中通过Pod的概念去解决的。

2、Pod要解决的问题分为俩个部分：网络和存储。

共享网络

我们通过容器A, 容器B来看如何共享网络。

容器A和B：

• 通过infra Container的方式共享同一个Network Namespace
• 直接使用localhost进行通信
• 看到的网络设备跟Infra容器看到的完全一样
• 一Pod只有一个IP地址，也就是这个Pod的Network Namespace对应的IP地址
• 整个Pod的生命周期跟Infra容器一致，而与容器A和B无关

共享存储

Pod怎么去共享存储呢，Pod共享存储就相对比较简单。

比如说现在有两个容器，一个是Nginx, 另外一个是非常普通的容器，在Nginx里放一些文件，让我能通过Nginx访问到。所以它需要去share这个目录。share文件或者是share目录在Pod里面是非常简单的，实际上就是把volumn变成了Pod level。然后所有容器，就是所有同属于一个Pod容器，他们相公所有的volumn。

三、容器设计模式

所有“设计模式”的本质都是：解耦和重用。Kubernetes里面有一个非常经典的容器设计模式，叫做：”Sidecar”。比如，同步组合两个不同角色的容器，用init Container等这样的一种编排方式，就是属于容器设计模式的范畴。

具体的说通过在Pod重定义专门容器，来执行主业务容器需要的辅助工作，比如：

• 原来需要SSH进去执行的脚本
• 日志收集
• Debug应用
• 应用监控
• ..

这里的明显优势就是将辅助功能同主业务容器解耦，实现独立发布和能力重用。

常用的Sidebar模式的场景：

1、应用与日志收集

• 业务容器将日志写在Volume里；
• 日志容器共享该Volume从而将日志转发到远程存储当中, Fluentd等；

2、代理容器

代理容器对业务容器屏蔽代理的服务集群，简化业务代码的实现逻辑。

提示：

• 容器之间通过localhost直接通讯；
• 代理容器的代码可以备全公司通用；

所以代理容器除了做了解耦之外，并不会降低性能，最重要的是，像这样一个代理容器的代码又可以被全公司重用了。

3、适配器容器

适配器容器将业务容器暴露出来的接口转换为另一种格式。

举例：

业务容器暴露出来的监控接口是 /metircs

Monitoring Adapter将其转换为 /healthz以适配新的监控系统