事实上目前主流的容器技术都是围绕着无状态应用来设计的,因为早期的容器设计没有考虑到磁盘,主要是cpu和IO资源。一旦涉及到业务状态或者数据存储都是采用外置存储的方式来解决,比如ceph等。而数据库这种应用更是典型的有状态应用,不仅涉及到数据落盘写入的问题,采用外置存储方案或者集中式存储往往还会遇到性能问题等。但并不是不能解决,某些场景下甚至能解决的更好。
一种新的针对容器存储的解决思路是云原生存储,也就是直接把主机操作系统中LVM的功能向上移动到kubernetes这样的云原生操作系统中来实现,kubernetes识别的不再是主机操作系统中文件系统或者卷,而是存储设备。LVM所负责的存储设备到逻辑存储卷的功能,直接由kubernetes环境中一组deamonset容器来实现。这样kubernetes中pv直接和硬件层的存储设备对接,并且可以设定多副本和一致性规则。在这样的架构下,容器化的数据库灾备能力甚至超过传统架构下的数据库产品,因为容器的恢复重建远比虚拟机要迅速。一个容器中数据库实例,通过云原生存储的多副本和强一致性保证,就可以得到传统架构中一主一备甚至一主两备的防护。维护成本则大为降低,不再需要维护多个数据库实例的工作了。集中保证kubernetes容器云的应用和存储即可。
收起k8s本身不负责上面运行服务的灾备。需要逐层思考这个问题。
架构上可以提一个思路,k8s下层的容器调度(scheduling framework)和存储调度(CSI和PVC storageclass)都是插件式的,可按需进行定制和扩展。
但高可用本身,见过很多方案通过应用层进行,如sidecar BIN log复制等等