Pod和容器设计模式

为什么需要 Pod

一些应用的实现是需要多个进程配合完成的,由于容器实际上是一个"单进程"模型,如果在容器里启动多个进程会存在进程管理的难题。在Kubernetes里面,实际上会被定义为一个拥有四个容器的Pod。

Pod相当于进程组

Kubernetes 是云时代的操作系统,Pod相当于进程组,容器就是一个个进程。Pod是Kubernetes分配资源的一个单位,因为里面的容器要共享某些资源,所以Pod也是Kubernetes的原子调度单位。

Pod是原子调度单位

为什么Pod必须是Kubernetes的原子调度单位,下面一个例子解释:

具有超亲密关系的容器的部署在ks8中会通过Pod去解决,对于超亲密关系的描述如下:

  • 两个进程之间会发生文件交换,前面提到的例子就是这样,一个写日志,一个读日志;
  • 两个进程之间需要通过localhost或者说是本地的Socket去进行通信,这种本地通信也是超亲密关系;
  • 这两个容器或者是微服务之间,需要发生非常频繁的 RPC 调用,出于性能的考虑,也希望它们是超亲密关系;
  • 两个容器或者是应用,它们需要共享某些 Linux Namespace。最简单常见的一个例子,就是我有一个容器需要加入另一个容器的Network Namespace。这样我就能看到另一个容器的网络设备,和它的网络信

息。

Pod 的实现机制

Pod要解决的问题:容器之间原本是被Linux Namespace和cgroups隔开的,所以现在实际要解决的是怎么去打破这个隔离,然后共享某些事情和某些信息。主要是解决网络和存储。

共享网络

在每个 Pod 里,额外起一个Infra container小容器来共享整个 Pod 的 Network Namespace。由于有了这样一个 Infra container 之后,其他所有容器都会通过 Join Network Namespace 的方式加入到Infra container的Network Namespace中。

Infra container是一个非常小的镜像,大概100~200KB 左右,是一个汇编语言写的、永远处于暂停状态的容器。

整个Pod的生命周期和Infra容器一致,与其他容器无关。

共享存储

Pod中的容器声明挂载同一个volume,通过这种方式实现存储共享。

容器设计模式

容器设计模式Sidecar:在Pod定义一些专门的容器,来执行主业务容器所需要的一些辅助工作。优势是将辅助功能同主业务容器解耦,实现独立发布和能力重用。一些常用的场景如下:

  • 使用Init Container在主业务容器启动前,将一些必要的文件或其他资源拷贝到共享的数据卷中,主业务容器启动后直接就可以从数据卷中读取和使用。
  • 应用日志收集,在Pod中启动一个Sidecar容器从共享的Volume中读取日志,然后存到远程存储里面。
  • 代理容器:单独写一个 Proxy容器,用来处理对接外部的服务集群,它对外暴露出来只有一个 IP 地址就可以了。所以接下来,业务容器主要访问Proxy,然后由 Proxy 去连接这些服务集群, 这里的关键在于 Pod 里面多个容器是通过 localhost 直接通信的。
  • 适配器容器:将业务容器暴露出来的接口转换为另一种格式。
相关推荐
WCL-JAVA1 小时前
Docker快速安装MongoDB并配置主从同步
mongodb·docker·容器
云上艺旅1 小时前
K8S学习之基础六十九:Rancher创建svc资源
学习·云原生·容器·kubernetes·rancher
下一秒_待续2 小时前
.Net8项目使用docker、docker-compose部署步骤
docker·容器·.net
GodGump4 小时前
dbgpt7.0 docker部署
运维·docker·容器
爱编程的王小美12 小时前
Docker基础详解
运维·docker·容器
白夜易寒12 小时前
Docker学习之容器虚拟化与虚拟机的区别(day11)
学习·docker·容器
草药味儿の岁月14 小时前
Docker镜像分层存储原理:UnionFS技术深度解析
运维·docker·容器
可观测性用观测云15 小时前
Kubernetes APIServer 可观测最佳实践
kubernetes
碣石潇湘无限路17 小时前
【云原生】Kubernetes CEL 速查表
容器·贪心算法·kubernetes
mingyuewu19 小时前
MAC安装docker 后提示com.docker.vmnetd”将对您的电脑造成伤害
macos·docker·容器