01-Pod-1

• 0.1. 进程与进程组
  • 0.1.1. 成组调度问题
  • 0.1.2. 超亲密关系
• 0.2. Pod实现原理
• 0.3. 容器设计模式
  • 0.3.1. 示例一
  • 0.3.2. 示例二
• 0.4. 共享Network Namespace
• 0.5. 总结

Pod 是Kubernetes项目中最小的API对象，原子调度单位。

Docker的原理与本质：Namespace做隔离，Cgroups做限制，rootfs做文件系统。

容器的本质：进程。

• 容器，是未来云计算系统中的进程
• 容器镜像，是未来云计算系统里的“.exe”安装包
• kubernetes，就是这个云计算系统（操作系统）

0.1. 进程与进程组

安装psmics工具集，并使用pstree工具查看系统进程。

yum install -y psmisc

# 返回当前系统中正在运行的进程的树状结构
pstree -g
systemd(1)───rsyslogd(627) ─┬─{rs:main Q:Reg}(627)
                       └─{in:imklog}(627)
# 省略很多
...

在一个正在运行的操作系统中，进程是以进程组的方式“有原则的”组织在一起，在进程后的括号中的数组表示进程组ID（Process Group ID，PGID）。

rsyslogd程序是负责Linux系统里的日志处理，它的主程序是main，和它要用的内核日志模块imklog等，同属于627进程组，这些进程相互协作，共同完成rsyslog程序的职责。对于操作系统来说，这样的进程更容易管理。

例如，Linux系统只需要将信号（如SIGKILL）发送给进程组，那么该进程组中的所有进程都会收到这个信号而终止运行。

kubernetes项目所做的，就是将“进程组”的概念映射到了容器技术中，并使其成为云计算“操作系统”里面的“一等公民”。

在实际应用中，应用之间有着密切的协作关系，类似于“进程与进程组”的关系，这使得它们必须部署在同一台机器上，否则基于Socket的通信和文件交换，会出现问题。没有组的概念，这样的运维关系非常难以处理。

容器是单进程模型。

容器的“单进程模型”，并不是指容器里只能运行“一个”进程，而是指容器没有管理多个进程的能力。这是因为容器里PID=1的进程就是应用本身，其他的进程都是这个PID=1进程的子进程。

用户编写的应用，并不能够向正常操作系统里的init进程或者systemd那样拥有进程管理的功能。

举个例子：一个Java Web程序（PID=1），然后执行docker exec 进入该容器后，在后台启动一个Nginx进程（PID=3），当这个Nginx进程异常退出的时候如何知道？进程退出后的垃圾回收工作又该谁去做？

0.1.1. 成组调度问题

1. Mesos采用资源囤积机制：在所有亲和性任务到达后才开始统一进行调度。
2. Google Omega采用乐观调度机制：先不管冲突，通过精心设计的回滚机制在出现冲突后解决问题。

以上解决方案存在的问题：

1. 囤积机制容易带来不可避免的调度效率损失和死锁的可能性。
2. 客观调度的实现程度过于复杂。

在Kubernetes中以Pod为原子调度单位，调度器统一按照Pod而非容器的资源需求进行计算。

0.1.2. 超亲密关系

容器之间的紧密协作称为“超亲密关系”。这样的容器的典型特征包括但不限于：

1. 互相之间会发生直接的文件交换
2. 使用 localhost 或者Socket文件进行本地通信
3. 发生非常频繁的远程调用
4. 需要共享某些 Linux Namespace（比如，一个容器要加入另一个容器的 Network Namespace）
5. 。。。

容器的超亲密关系可以在调度层面实现，Pod在kubernetes项目中，最重要的是“容器设计模式”。

0.2. Pod实现原理

Pod是逻辑上的概念。即Kubernetes真正处理的其实是宿主机操作系统上Linux容器的Namespace和Cgroups，而不存在一个所谓的Pod隔离环境。

Pod是一组共享了某些资源的容器，Pod里的所有容器共享的是同一个Network Namespace，并且可以声明共享同一个Volume。

使用Docker原理能否实现Pod？A与B两个容器共享网络和Volume，如下命令：

docker run --net=B --volumes-from=B --name=A image-A ...

# 容器B必须比容器A先启动

这样的话，多个容器就不是对等关系，而是拓扑关系。

Pod的实现需要使用一个中间容器，这个容器叫作Infra容器。在这个Pod中，Infra容器永远都是第一个被创建的容器，而其他用户定义的容器，则通过Join Network Namespace的方式与Infra容器关联在一起。

这个Pod里有两个用户容器A和B，还有一个Infra容器。在Kubernetes项目中，Infra容器占用极少资源，使用一个非常特殊的镜像（k8s.gcr.io/pause）。这个镜像是一个用汇编语言编写的，永远处于“暂停”状态的容器，解压后的大小也只有100~20KB左右。

对于Pod里的容器A和B：

• 它们可以直接使用localhost通信
• 它们看到的网络设备与Infra容器看到的完全一样
• 一个Pod只有一个IP地址，是这个Pod的Network Namespace对应的IP地址
• 其他的所有网络资源，都是一个Pod一份，并且被该Pod中的所有容器共享
• Pod的生命周期只跟Infra容器一致，与容器A和B无关

对于同一个 Pod里面的所有用户容器来说，它们的进出流量，可以认为都是通过Infra容器完成的。

如果要为 Kubernetes 开发一个网络插件，应该重点考虑的是如何配置这个 Pod 的 Network Namespace，而不是每一个用户容器如何使用网络配置，这是没有意义的。

• 这意味着，如果网络插件需要在容器里安装某些包或者配置才能完成的话，是不可取的，在Infra 容器镜像的 rootfs里几乎什么都没有，没有你随意发挥的空间。
• 这意味着，网络插件完全不必关心用户容器启动与否，而只需要关注如何配置 Pod，也就是 Infra 容器的Network Namespace 即可。

有了这个设计之后，共享Volume就简单多了：Kubernetes 项目只要把所有Volume 的定义都设计在 Pod 层级即可。这样，一个 Volume对应的宿主机目录对于Pod来说就只有一个，Pod 里的容器只要声明挂载这个 Volume，就一定可以共享这个Volume对应的宿主机目录。比如下面这个例子：

apiVersion: v1
kind: Pod
metadata:
  name: two-containers
spec:
  restartPolicy: Never
  volumes:
  - name: shared-data
    hostPath:
      path: /data
  containers:
  - name: nginx-container
    image: nginx
    volumeMounts:
    - name: shared-data
      mountPath: /usr/share/nginx/html
  - name: debian-container
    image: debian
    volumeMounts:
    - name: shared-data
      mountPath: /pod-data
    command: ["/bin/sh"]
    args: ["-c", "echo Hello from the debian container > /pod-data/index.html"]

在这个例子中，debian-container 和 nginx-container 都声明挂载了 shared-data 这个Volume。而 shared-data 是 hostPath 类型。所以，它对应在宿主机上的目录就是：/data。而这个目录，其实就被同时绑定挂载进了上述两个容器当中。

0.3. 容器设计模式

Pod 这种“超亲密关系”容器的设计思想，实际上就是希望，当用户想在一个容器里跑多个功能并不相关的应用时，应该优先考虑它们是不是更应该被描述成一个 Pod 里的多个容器。

为了能够掌握这种思考方式，应该尽量尝试使用它来描述一些用单个容器难以解决的问题。

0.3.1. 示例一

第一个最典型的例子是：WAR 包与 Web 服务器。我们现在有一个 Java Web 应用的 WAR 包，它需要被放在 Tomcat 的 webapps 目录下运行起来。

假如，你现在只能用 Docker 来做这件事情，那该如何处理这个组合关系呢？

1. 一种方法是，把 WAR 包直接放在 Tomcat 镜像的 webapps 目录下，做成一个新的镜像运行起来。可是，这时候，如果你要更新WAR包的内容，或者要升级Tomcat镜像，就要重新制作一个新的发布镜像，非常麻烦。
2. 另一种方法是，你压根儿不管 WAR 包，永远只发布一个 Tomcat 容器。不过，这个容器的webapps 目录，就必须声明一个 hostPath 类型的 Volume，从而把宿主机上的 WAR 包挂载进Tomcat 容器当中运行起来。不过，这样你就必须要解决一个问题，即：如何让每一台宿主机，都预先准备好这个存储有 WAR 包的目录呢？这样来看，你只能独立维护一套分布式存储系统了。

实际上，有了 Pod 之后，这样的问题就很容易解决了。我们可以把 WAR 包和 Tomcat 分别做成镜像，然后把它们作为一个 Pod 里的两个容器“组合”在一起。这个 Pod 的配置文件如下所示：

apiVersion: v1
kind: Pod
metadata:
  name: javaweb-2
spec:
  initContainers:
  - image: geektime/sample:v2
    name: war
    command: ["cp", "/sample.war", "/app"]
    volumeMounts:
    - mountPath: /app
      name: app-volume
  containers:
  - image: geektime/tomcat:7.0
    name: tomcat
    command: ["sh","-c","/root/apache-tomcat-7.0.42-v2/bin/start.sh"]
    volumeMounts:
    - mountPath: /root/apache-tomcat-7.0.42-v2/webapps
      name: app-volume
    ports:
    - containerPort: 8080
      hostPort: 8001
  volumes:
  - name: app-volume
    emptyDir: {}

在这个 Pod 中，我们定义了两个容器：

• 第一个容器使用的镜像是 geektime/sample:v2，这个镜像里只有一个 WAR 包（sample.war）放在根目录下
• 第二个容器则使用的是一个标准的 Tomcat镜像

WAR 包容器的类型不再是一个普通容器，而是一个 Init Container 类型的容器。

在 Pod 中，所有 Init Container 定义的容器，都会比 spec.containers 定义的用户容器先启动。并且，Init Container 容器会按顺序逐一启动，而直到它们都启动并且退出了，用户容器才会启动。

1. 这个 Init Container 类型的 WAR 包容器启动后，执行了一句 "cp /sample.war /app"，把应用的 WAR 包拷贝到 /app 目录下，然后退出
2. 而后这个 /app 目录，就挂载了一个名叫 app-volume 的 Volume
3. 接下来就很关键了。Tomcat 容器，同样声明了挂载 app-volume 到自己的 webapps 目录下。所以，等 Tomcat 容器启动时，它的 webapps 目录下就一定会存在 sample.war 文件：这个文件正是 WAR 包容器启动时拷贝到这个 Volume 里面的，而这个 Volume 是被这两个容器共享的

像这样，用一种“组合”方式，解决了 WAR 包与 Tomcat 容器之间耦合关系的问题。实际上，这个所谓的“组合”操作，正是容器设计模式里最常用的一种模式，它的名字叫：sidecar。

sidecar 指的就是可以在一个 Pod 中，启动一个辅助容器，来完成一些独立于主进程（主容器）之外的工作。

比如，这个应用Pod中，Tomcat容器是要使用的主容器，而WAR包容器的存在，只是为了给它提供一个 WAR包而已。所以，用InitContainer 的方式优先运行 WAR包容器，扮演了一个 sidecar 的角色。

0.3.2. 示例二

第二个例子：容器的日志收集。

比如，现在有一个应用，需要不断地把日志文件输出到容器的 /var/log 目录中。

1. 把一个 Pod 里的 Volume 挂载到应用容器的 /var/log 目录上
2. 在这个 Pod 里同时运行一个 sidecar 容器，它也声明挂载同一个 Volume 到自己的 /var/log 目录上
3. sidecar容器就只需要做一件事儿，不断地从自己的/var/log目录里读取日志文件，转发到 MongoDB 或者 Elasticsearch 中存储起来
4. 一个最基本的日志收集工作就完成了。

这个例子中的 sidecar 的主要工作也是使用共享的 Volume 来完成对文件的操作。

0.4. 共享Network Namespace

Pod中所有容器都共享同一个 Network Namespace。这就使得很多与 Pod 网络相关的配置和管理，也都可以交给 sidecar 完成，而完全无须干涉用户容器。

最典型的例子莫过于Istio这个微服务治理项目了。Istio项目使用sidecar容器完成微服务治理。

0.5. 总结

• 容器设计模式：启动一个辅助容器，来完成一些独立于主进程（主容器）之外的工作
• 共享Network Namespace：与Pod网络相关的配置和管理，交给sidecar完成

容器技术的本质是“进程”，一个运行在虚拟机里的应用，是被管理在Systemd或者supervisord执行的一组进程，而不是一个进程。

Pod实际上在扮演传统基础设施里的虚拟机的角色，而容器，则是这个虚拟机里运行的用户程序。

当需要把一个运行在虚拟机里的应用迁移到 Docker 容器中时，一定要仔细分析到底有哪些进程（组件）运行在这个虚拟机里。

然后，就可以把整个虚拟机想象成为一个Pod，把这些进程分别做成容器镜像，把有顺序关系的容器，定义为 Init Container。这才是更加合理的、松耦合的容器编排诀窍，也是从传统应用架构，到“微服务架构”最自然的过渡方式。

如果强行把整个应用塞到一个容器里，甚至不惜使用Docker in Docker 这种在生产环境中后患无穷的解决方案，恐怕最后往往得不偿失。