阿里云《云原生》公开课笔记第四章理解Pod和容器设计模式

本文链接：https://blog.csdn.net/Alexia23/article/details/105840419

课程文字：https://edu.aliyun.com/lesson_1651_16895?spm=5176.10731542.0.0.708e20bee0BSyt#_16895

Pod的重要性

容器的基本概念

单进程模型：Linux 容器的“单进程”模型，指的是容器的生命周期等同于 PID=1 的进程（容器应用进程）的生命周期，而不是说容器里不能创建多进程。由于容器是一个“单进程”模型，所以如果在容器里启动多个进程，只有一个可以作为 PID=1 的进程。
容器里面 PID=1 的进程就是应用本身。
- 管理虚拟机，等同于，管理基础设施
- 管理容器，等同于，直接管理应用本身
进程组：每个进程组有一个领头进程。进程组是一个或多个进程的集合，通常它们与一组作业相关联，可以接受来自同一终端的各种信号。
systemd：systemd（system daemon）是一个专用于 Linux 操作系统的系统与服务管理器。当作为启动进程(PID=1)运行时，它将作为初始化系统运行，也就是启动并维护各种用户空间的服务。

pod等同于进程组

多个容器的组合就叫做 Pod

pod的设计原因

解决pod内容器组的 Task co-scheduling问题
- Mesos: 资源囤积，实现成组调度
- Omega：乐观调度（先调度，出现问题回滚）
- K8s：pod为原子调度单位，不存在这样的问题
pod里面的容器属于超亲密关系
- 亲密关系
  - 两个 Pod，它们需要运行在同一台宿主机上
- 超亲密关系
  - 两个进程之间会发生文件交换，比如：一个写日志，一个读日志；
  - 两个进程之间需要通过 localhost 或者说是本地的 Socket 去进行通信；
  - 这两个容器或者是微服务之间，需要发生非常频繁的RPC 调用，出于性能的考虑，也希望它们是超亲密关系；
  - 两个容器或者是应用，它们需要共享某些 Linux Namespace。常见例子：有一个容器需要加入另一个容器的 Network Namespace，加入之后能看到另一个容器的网络设备和网络信息。

Pod的实现原理

共享网络

Infra container：一个非常小的镜像，大概 100~200KB 左右，是一个汇编语言写的、永远处于“暂停”状态的容器。由于有了这样一个 Infra container 之后，其他所有容器都会通过 Join Namespace 的方式加入到 Infra container 的 Network Namespace 中。
一个 Pod 里面的所有容器，它们看到的网络视图是完全一样的。即：它们看到的网络设备、IP地址、Mac地址等等，跟网络相关的信息，其实全是一份，这一份都来自于 Pod 第一次创建的这个 Infra container。
整个 Pod 里面，Infra container 第一个启动。并且整个 Pod 的生命周期是等同于 Infra container 的生命周期的，与容器 A 和 B 是无关的。（结果：允许去单独更新 Pod 里的某一个镜像的，即：做这个操作，整个 Pod 不会重建，也不会重启。）

共享存储

在pod的每一个容器里直接声明：挂载了shared-data的volume

容器设计模式

案例

需求：java写的war包+tomcat
- 方案1：war和tomcat打包到一个镜像里，更新war和tomcat大批需要重做镜像
- 方案2：war通过数据卷挂载到tomcat里面。（分布式存储系统：容器第一次运行在宿主机A，第二次运次在宿主机B，这两个地方都要能访问到war）
- 方案3：利用init container，把 WAR 包从镜像里拷贝到一个 Volume 里面，然后启动容器去挂载Volume

Sidecar

概念：在 Pod 里面，可以定义一些专门的容器，来执行主业务容器所需要的一些辅助工作
应用
- 原本需要在容器里面执行 SSH 需要干的一些事情，可以写脚本、一些前置的条件，其实都可以通过像 Init Container 或者另外像 Sidecar 的方式去解决；
- 当然还有一个典型例子是日志收集（fluentd），日志收集本身是一个进程，是一个小容器，那么就可以把它打包进 Pod 里面去做这个收集工作；（业务容器将日志写在一个 Volume 里面，而由于 Volume 在 Pod 里面是被共享的，所以日志容器 —— 即 Sidecar 容器一定可以通过共享该 Volume，直接把日志文件读出来，然后存到远程存储）
- Debug 应用，实际上现在 Debug 整个应用都可以在应用 Pod 里面再次定义一个额外的小的 Container，它可以去 exec 应用 pod 的 namespace；
- 查看其他容器的工作状态，实现应用监控。不再需要去 SSH 登陆到容器里去看，只要把监控组件装到额外的小容器里面就可以了，然后把它作为一个 Sidecar 启动起来，跟主业务容器进行协作，所以同样业务监控也都可以通过 Sidecar 方式来去做。
- 代理容器：单独写一个这么小的 Proxy，用来处理对接外部的服务集群，它对外暴露出来只有一个 IP 地址就可以了。所以接下来，业务容器主要访问 Proxy（localhost通信，性能损耗忽略），然后由 Proxy 去连接这些服务集群。
- 适配器容器：将业务容器暴露出来的接口转换成另一种格式。举例：业务容器暴露出来的监控接口是 /metrics，访问这个这个容器的 metrics 的这个 URL 就可以获取信息。可是后来这个监控系统升级了，它访问的 URL 是 /health，只认得暴露出 health 健康检查的 URL，才能去做监控，metrics 不认识。如果不改代码，可以额外写一个 Adapter，用来把所有对 health 的这个请求转发给 metrics 就可以了，所以这个 Adapter 对外暴露的是 health 监控的 URL。
优势：通过sidecar，将辅助功能和业务容器解耦；解耦之后则可复用
- 设计模式的本质：解耦和重用