为什么需要Pod？

Pod是K8S的调度单位。

回顾容器和K8S的关系

容器的本质？
- 一个视图被隔离，资源受限的进程
- 容器里PID=1的进程就是应用本身
  - 管理虚拟机=管理基础设施
  - 管理容器=直接管理应用
K8S？
- K8s是云时代的操作系统
- 容器镜像是K8S这个操作系统的软件安装包

真实操作系统的例子

一个Helloworld程序由多个进程组成
四个进程共享helloworld的资源，相互协作，完成helloworld的工作

两者对比

k8s=操作系统
容器=进程
pod=进程组

进程组

对于上面拥有4个进程的helloworld程序，怎么用容器跑起来？
方法一：在一个docker里面启动4个进程
- 问题：容器是单进程模型，PID=1的进程比如说是main进程，其他三个进程怎么管理？
- 解决方法：
  - 应用程序本身具有进程管理的能力，helloworld程序具备systemd的能力。
  - 或者，PID=1的进程改为systemd
    - 这样，管理容器=管理systemd！=直接管理应用本身。

Pod=进程组

来自Borg的思考

Borg部署的应用，往往存在着类似进程与进程组的关系，必须部署在同一台机器上，共享一些信息。

为什么Pod是原子调度单位？

举例：两个容器紧密合作
- App，业务容器，写日志
- Log，转发日志到ES
内存要求
- APP：1G
- Log：0.5G
可用内存
- Node_A : 1.25G
- Node_B : 2G
如果App被调度到了Node_A上，Log资源不足就调度不过来了
Task co-scheduling问题的解决方案
- Mesos：资源囤积（reource hoarding）
  - 所有设置了Afinity约束的任务都达到了，才开始统一调度
  - 问题：调度效率损失、死锁
- Google Omega：乐观调度处理冲突
  - 先不管冲突，在冲突发生时会有机制进行回滚来处理问题
  - 问题：负载
- K8S：Pod打包部署

再次理解Pod

亲密关系-调度解决
- 两个应用需要部署在同一个宿主机上
超亲密关系-pod解决
- 会直接发生文件交换
- 会使用localhost或socket文件进行本地通信
- 会频繁的RPC调用
- 会共享某些Linux namespace（一个容器加入另一个容器的network namespace，这样就可以看到对方的网络设备）

Pod的实现机制

Pod要解决的问题

如何让一个Pod里的容器之间最高效地共享某些资源和数据？
- 容器之间是被Linux Namespace和cgroups隔离开的

1 共享网络

容器A和B
- 通过Infra Container的方式共享同一个Network Namespace
  - 镜像：k8s.gcr.io/pause；汇编语言编写的，永远处于暂停状态，大小100-200KB
- 直接使用localhost通信
- 看到的网络设备和Infra容器看到的完全一样
- 一个Pod只有一个IP地址，也就是这个pod的Network Namespace对应的IP地址
  - 所有网络资源，都是一个Pod一份，被该Pod中的所有容器共享
- 整个Pod的生命周期和Infra容器一致，而与容器A和B无关

2 共享存储

设置一个Pod级别的Volumn
各个容器去挂载这个Volumn，然后就可以看到（/opt/tiger/...）

详解容器设计模式

举例：WAR包+Tomcat的容器化

方法一：把WAR包和Tomcat打包进一个镜像
- 无论是WAR更新和Tomcat更新都需要重新制作镜像
方法二：镜像里只打包Tomcat，用数据卷容宿主机上将WAR包挂载进Tomcat容器
- 需要分布式存储系统
更通用的做法？

InitContainer

InitContainer会比spec.containers定义的用户容器先执行，并且严格按照定义的顺序依次执行
/app是个Volumn
Tomcat容器同样挂载了该Volumn到自己的webapps目录下
当Tomcat容器启动是，它的webapp目录下就一定会有sample.war

容器设计模式：Sidecar

通过在Pod里定义专门容器，来执行主业务容器需要的辅助功能
比如：
- Init Container把war包复制到Volumn里面
- 需要SSH进去执行的脚本
- 日志收集
- Debug应用
- 应用监控
优势：
- 将辅助功能和祝业务容器解耦，实现独立发布和能力重用

Sidecar：应用与日志收集

业务容器将日志写在Volumn里
日志容器共享该Volumn从而将日志转发到远程存储当中
- Fluentd等

Sidecar：代理容器

代理容器对业务容器屏蔽被代理的服务集群（consul、服务发现？），简化业务代码的实现逻辑
提示：
- 容器之间通过localhost直接通信
- 代理容器的代码可以被全公司重用

Sidecar：适配器模式

适配器模式将业务暴露出来的接口转化为另一种格式
举例：
- 业务暴露出来的监控接口是/metrics
- 监控系统需要的接口是/healthz
- monitoring adapter将/metrics转化为/healthz以适配新的监控系统
提示：
- 容器之间通过localhost通信
- 代理容器的代码可以被全公司重用

总结

Pod是K8s项目里实现容器设计模式的核心机制
容器设计模式是K8s进行复杂应用编排的基础依赖
所有设计模式的本质都是：解耦和重用

Pod和容器设计模式相关推荐

从零开始入门 K8s| 详解 Pod 及容器设计模式
作者|张磊阿里云容器平台高级技术专家,CNCF 官方大使一.为什么需要 Pod 容器的基本概念我们知道 Pod 是 Kubernetes 项目里面一个非常重要的概念,也是非常重要的一个原子调度单 ...
云原生学习——理解pod和容器设计模式
本文整理自 CNCF 和阿里巴巴联合举办的云原生技术公开课的课时 4:理解 Pod 和容器设计模式.本次课程中,阿阿里巴巴高级技术专家.CNCF 官方大使张磊为大家介绍了为什么我们需要 Pod.Pod ...
为什么我们需要Pod？(容器设计模式sidecar)
Pod,是 Kubernetes 项目中最小的 API 对象容器的本质是进程,就是未来云计算系统中的进程:容器镜像就是这个系统里的".exe"安装包 Kubernetes 就是操 ...
理解 Pod 和容器设计模式
本节课程要点为什么需要 Pod: Pod 的实现机制: 详解容器设计模式. 为什么需要 Pod 容器的基本概念现在来看第一个问题:为什么需要 Pod?我们知道 Pod 是 Kubernetes 项 ...
Kubernetes（K8s）容器设计模式实践案例 – 分散收集模式
<Kubernetes与云原生应用>专栏是InfoQ向轻元科技首席架构师王昕约稿的系列文章.本专栏包含8篇内容,将会从介绍和分析Kubernetes系统以及云原生应用入手,逐步推出基于 ...
Kubernetes — 容器设计模式
目录文章目录目录 InitContainer Sidecar InitContainer 有了 InitContainer 之后就可以这样去描述:Pod 是一个自包含的,可以把这一个 Pod 在全 ...
对象容器设计模式_容器对象模式。一种新的测试模式。
对象容器设计模式如果您搜索什么是页面对象的描述,您会发现页面对象模式为我们提供了一种以可重用和可维护的方式对内容建模的常识方法. 还要指出:在Web应用程序的UI中,您的测试与某些区域交互. Pag ...
k8s pod内部容器_第三章 pod：运行于kubernetes中的容器
本章内容涵盖创建. 启动和停止 pod 使用标签组织 pod 和其他资源使用特定标签对所有 pod 执行操作使用命名空间将多个 pod 分到不重叠的组中调度 pod 到指定类型的工作节点上一 ...
深入kubernetes之Pod——一pod多容器
六.深入Pod--一pod多容器一pod多容器,可以说是kube精华所在,让多个同应用的单一容器可以整合到一个类虚拟机中,使其所有容器共用一个vm的资源,提高耦合度,神来之笔,从而方便副本的复制,提 ...
OpenShift 4 - 验证 Pod 内部容器使用 CA 和 ServiceAccount Token访问API服务
<OpenShift 4.x HOL教程汇总> 说明:本文已经在OpenShift 4.7环境中验证文章目录部署测试应用在容器内部访问API服务部署测试应用部署测试应用 $ oc ...

Pod和容器设计模式

为什么需要Pod？

回顾容器和K8S的关系

真实操作系统的例子

两者对比

进程组

Pod=进程组

来自Borg的思考

为什么Pod是原子调度单位？

再次理解Pod

Pod的实现机制

Pod要解决的问题

1 共享网络

2 共享存储

详解容器设计模式

举例：WAR包+Tomcat的容器化

InitContainer

容器设计模式：Sidecar

Sidecar：应用与日志收集

Sidecar：代理容器

Sidecar：适配器模式

总结

Pod和容器设计模式相关推荐

最新文章

热门文章