云原生基础

一、概述

云原生技术范畴：

理论基础

• 不可变基础设施：容器镜像
• 云应用编排理论：容器设计模式

二、容器技术

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