1、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 不会重建，也不会重启。）

2、容器设计模式

案例

• 需求：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，将辅助功能和业务容器解耦；解耦之后则可复用
  • 设计模式的本质：解耦和重用

RPC
remote procedure call：远程过程调用，一个节点请求另一个节点提供的服务