容器需要持久化存储
根本不存在无状态化的架构
- There is no such thing as a stateless architecture
- Jonas Boner
Lightbend 创始人兼 CTO ,Akka 作者
应用程序需要数据, IT 方案被创造出来是为了解决商业业务数据的问题
容器问世之时, 它最初的目的是应对无状态化服务随着容器技术的成熟, 越来越多的人希望容器化应用可以直接关联数据不论是传统的还是新型应用, 都需要存储, 如文件块对象存储的形式, 通过文档关系型数据库或者流媒体等等
虚拟化技术的 hypervisor 虚拟机器监视器在硬件模拟层上有很多要求, 而比起虚拟化技术, 容器将应用的可移植性大大提升应用程序的可移植性, 依赖于容器编排系统的互操作性但是, 需要看到的是即使是现代化的云原生应用, 存储也是不可缺少的关键模块, 因为有了持久化存储, 应用程序就可以基于此开发出很多功能
容器编排系统和运行时通过特定请求来接通存储服务, 如 Creat / Remove, Inspect / List, Attach / Detach, Mount / Unmount 等目前看来, 业界都是在通过容器编排系统解决存储问题, 能否实现此点也成为了工业界的分水岭
通过 API 方式链接外部存储服务有两种方式: 第一种是 in-tree 驱动, 由在容器编排系统内部的原生化代码实现; 第二种 out-tree 驱动, 由插件实现前者受制于容器编排系统的发布周期, 而后者可能无法提供容器编排系统配套的加强功能
Kubernetes 的存储机制
Docker 率先尝试通过 out-tree 模式解决了如何与外部存储协同的问题, 在 1.7 Experimental 版本中创建了 Docker Volume Driver 接口
而 Kubernetes 则提供 in-tree 和 out-tree 两种模式
In-tree 是 Kubernetes 标准版的一部分, 已经写入 Kubernetes 代码中通过基于 Kubernetes 内置 interface 的 API 命令如 Mount / Unmount, Creat / Delete 等进行存储平台的操作 Kuberentes 会在
pod 创建时进行所有相关的必要操作, 并且找到相关驱动执行特定 API 背后的所需动作用户可以充分发挥 Kubernetes 中动态配置和存储类等新特性唯一的缺点就是, 如果存储平台需要 bug 修复或者功能添加的话, 需要等待 Kubernetes 的发布周期一般而言, Kubernetes 的发布周期在 3-6 个月, 这意味着 bug 修复或者持续更新并不能随心所欲
Out-tree 是通过 Flexvolume 接口实现的, Flexvolume 可以使得用户在 Kubernetes 内自己编写驱动或添加自有数据卷的支持第三方驱动通过数据卷插件路径安装在每个 Kubelet 和 master 节点这使得存储驱动可以与 Kubernetes 内核代码独立开来, bug 修复和功能更新都不需要等待 Kubernetes 的日程计划 Flexvolume 接口设定认为数据卷的创建和删除都是发生在其外部, 因此只有 Attach / Detach 和 Mount / Unmount 操作可行, 并且也不是在数据卷的全部生命周期可行
阿里云 Kubernetes 的存储支持
阿里云容器服务全球首批通过 Kubernetes 一致性认证, 用户可以通过 in-tree 形式挂载存储
而对于 out-tree, 阿里云容器服务支持 Kubernetes Pod 自动绑定阿里云云盘 NASOSS 存储服务目前对于静态存储卷和动态存储卷的支持情况如下:
操作指南:
使用阿里云云盘
使用阿里云 NAS
使用阿里云 OSS
在使用容器过程中, 你可能会在日志数据备份配置信息等场景中需要用到存储, 不如按照上述办法尝试下吧? 对了, 你也可以使用日志服务来应对日志的问题哦!
全面提升, 阿里云 Docker / Kubernetes(K8S) 日志解决方案与选型对比
参考文章
Container Storage Architectures: How Does Kubernetes, Docker, and Mesos Compare?
来源: https://yq.aliyun.com/articles/495754