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 直接通信的。
  • 适配器容器:将业务容器暴露出来的接口转换为另一种格式。
相关推荐
草药味儿の岁月4 分钟前
Docker镜像分层存储原理:UnionFS技术深度解析
运维·docker·容器
可观测性用观测云1 小时前
Kubernetes APIServer 可观测最佳实践
kubernetes
碣石潇湘无限路3 小时前
【云原生】Kubernetes CEL 速查表
容器·贪心算法·kubernetes
mingyuewu5 小时前
MAC安装docker 后提示com.docker.vmnetd”将对您的电脑造成伤害
macos·docker·容器
企鹅侠客7 小时前
Prometheus operator怎么添加targets和告警规则
运维·云原生·kubernetes·prometheus·pod
专注代码七年8 小时前
Docker运维篇
运维·docker·容器
一杯敬朝阳 一杯敬月光9 小时前
WIN11 企业版 部署Dify+Docker
运维·docker·容器
Leo Han9 小时前
k8s常用命令(持续更新中)
docker·容器·kubernetes
KubeSphere 云原生9 小时前
云原生周刊:Kubernetes v1.33 要来了
云原生·容器·kubernetes
dessler10 小时前
Kubernetes(k8s)-日志(logs)和exec内部逻辑
linux·运维·kubernetes