文章目录
一、概述
云原生技术范畴:
理论基础
- 不可变基础设施:容器镜像
- 云应用编排理论:容器设计模式
二、容器技术
2.1 什么是容器
- 传统系统中,进程相互可见、相互通信,共享同一套文件系统
- 容器则是通过namespace进行了资源隔离、cgroup限制了资源使用,并独立拥有一套自己文件系统的进程集合(容器本质为一个init进程及其子进程)
- 容器如果需要持久化,则需要绑定本地的数据卷Volume
2.2 容器引擎架构
容器引擎目前最流行的为moby,其可以帮助我们管理容器镜像、volume等
- moby基于containerd,containerd是容器运行时管理引擎
- containerd-shim是管理容器生命周期的组件,也是一个守护进程,用于适配不同的容器运行时(例如runC、kata),以插件的形式管理容器运行时
Tips:
- docker相比cloud foundary等paas平台的优势,是方便了部署,将整个文件系统打包部署(容器镜像),使得不用更改任何配置,项目就可以在别的机器上运行。
- 容器本身没有价值,容器编排才有价值
- 对一个应用来说,操作系统才是它运行所需要的最完整的“依赖库”
- 一个进程,可以选择加入到某个进程已有的namespace中,从而达到“进入”这个进程所在容器的目的,也就是docker exec的实现原理
三、K8s
核心功能:
- 服务发现与负载均衡
- 容器自动装箱
- 存储编排
- 自动容器恢复
- 自动发布与回滚
- 配置与密文管理
- 批量执行
- 水平伸缩
k8s架构
Master节点:
- controller:控制器,管理集群状态
- api server:处理API操作,k8s中所有组件均与api server交互
- scheduler:调度器
- etcd:存储元数据信息
Node节点:
- Pod:业务负载以Pod形式运行
- Kublet:与api server交互,管理pod
- Kube-proxy:组建k8s集群网络
- Network Plugin:网络管理
- Storage Plugin:存储管理
- Container Runtime:容器运行时
k8s运行过程
四、容器设计模式
Sidecar
通过在Pod中定义一些专门的容器,来执行主业务容器需要的辅助工作,比如日志收集、应用监控等等。
Sidecar还可以实现代理和适配器功能。
优点是将辅助功能同主业务容器解耦,实现独立发布和能力重用。
控制器模式
让各个组件独立自主运行,同时不断让系统向所期望的状态趋近,status–>spec。
流程:
- Reflector:与Api Server交互,获取资源数据,封装资源数据以及对应的事件放入Delta队列中
- Delta Queue:存储资源数据本身以及资源对象处理事件,保证同一个资源对象只有一条记录
- Informer:不断从Queue中取数据,执行对应的Event回调函数,同时将资源数据交给Indexer
- Indexer:将数据存入缓存中,key为namespace
五、应用编排
我们可以直接管理所有Pod吗?
如果我们直接管理,以下问题不好解决:
- 如何保证集群内可用Pod的数量?
- 如何为所有Pod更新镜像版本?
- 更新过程中,如何保证服务可用?
- 更新过程中,发现问题如何快速回滚?
引入了Deployment,其基于控制器模式,核心是Deployment controller。
我们可以直接通过Pod运行任务吗?
如果直接通过Pod运行任务,存在以下问题:
- 如何保证Pod内进程正确的结束?
- 如果进程执行失败,如何重试?
- 如何管理多个任务且任务之间有相互依赖关系?
- 如何并行运行任务并管理他们的队列大小?
引入Job、cronJob
我们可以让集群节点都运行相同的一个Pod吗
需要考虑以下问题:
- 如何保证每个节点都运行一个pod
- 如果新节点加入集群,如果感知并部署pod
- 如果有节点退出,如何删除对应的pod
- 如果pod状态异常,如何监控并恢复pod状态
引入DaemonSet,守护进程控制器
Pod数据共享
Volumes
- 本地存储:emptyDir/hostpath
- 网络存储:
- Projected Volume:
- PVC和PV:Persistent Volume & Persistent VolumeClaim