- 序言
- 云原生
- Kubernetes 架构
- Kubernetes 中的网络
- Pod 状态与生命周期管理
- 集群资源管理
- 控制器
- 服务发现
- 身份与权限控制
- 存储
- 集群扩展
- 资源调度
- 用户指南
- 资源对象配置
- 命令使用
- 集群安全性管理
- 访问 Kubernetes 集群
- 在 Kubernetes 中开发部署应用
- 最佳实践概览
- 在 CentOS 上部署 Kubernetes 集群
- 生产级的 Kubernetes 简化管理工具kubeadm
- 服务发现与负载均衡
- 运维管理
- 存储管理
- 集群与应用监控
- 分布式跟踪
- 服务编排管理
- 持续集成与发布
- 更新与升级
- 领域应用概览
- 微服务架构
- Service Mesh 服务网格
- 大数据
- Serverless架构
- 边缘计算
- 人工智能
- 开发指南
- CNCF
- 附录说明
文章来源于网络收集而来,版权归原创者所有,如有侵权请及时联系!
数据持久化问题
数据落盘问题的由来
这本质上是数据持久化问题,对于有些应用依赖持久化数据,比如应用自身产生的日志需要持久化存储的情况,需要保证容器里的数据不丢失,在Pod挂掉后,其他应用依然可以访问到这些数据,因此我们需要将数据持久化存储起来。
数据落盘问题解决方案
下面以一个应用的日志收集为例,该日志需要持久化收集到ElasticSearch集群中,如果不考虑数据丢失的情形,可以直接使用前面提到的应用日志收集一节中的方法,但考虑到Pod挂掉时logstash(或filebeat)并没有收集完该pod内日志的情形,我们想到了如下这种解决方案,示意图如下:
- 首先需要给数据落盘的应用划分node,即这些应用只调用到若干台主机上
- 给这若干台主机增加label
- 使用
deamonset
方式在这若干台主机上启动logstash的Pod(使用nodeSelector来限定在这几台主机上,我们在边缘节点启动的treafik
也是这种模式) - 将应用的数据通过volume挂载到宿主机上
- Logstash(或者filebeat)收集宿主机上的数据,数据持久化不会丢失
Side-effect
- 首先kubernetes本身就提供了数据持久化的解决方案statefulset,不过需要用到公有云的存储货其他分布式存储,这一点在我们的私有云环境里被否定了。
- 需要管理主机的label,增加运维复杂度,但是具体问题具体对待
- 必须保证应用启动顺序,需要先启动logstash
- 为主机打label使用nodeSelector的方式限制了资源调度的范围
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论