k8s 上如何对数据库进行灾备？

事实上目前主流的容器技术都是围绕着无状态应用来设计的，因为早期的容器设计没有考虑到磁盘，主要是cpu和IO资源。一旦涉及到业务状态或者数据存储都是采用外置存储的方式来解决，比如ceph等。而数据库这种应用更是典型的有状态应用，不仅涉及到数据落盘写入的问题，采用外置存储方案或者集中式存储往往还会遇到性能问题等。但并不是不能解决，某些场景下甚至能解决的更好。

一种新的针对容器存储的解决思路是云原生存储，也就是直接把主机操作系统中LVM的功能向上移动到kubernetes这样的云原生操作系统中来实现，kubernetes识别的不再是主机操作系统中文件系统或者卷，而是存储设备。LVM所负责的存储设备到逻辑存储卷的功能，直接由kubernetes环境中一组deamonset容器来实现。这样kubernetes中pv直接和硬件层的存储设备对接，并且可以设定多副本和一致性规则。在这样的架构下，容器化的数据库灾备能力甚至超过传统架构下的数据库产品，因为容器的恢复重建远比虚拟机要迅速。一个容器中数据库实例，通过云原生存储的多副本和强一致性保证，就可以得到传统架构中一主一备甚至一主两备的防护。维护成本则大为降低，不再需要维护多个数据库实例的工作了。集中保证kubernetes容器云的应用和存储即可。

k8s本身不负责上面运行服务的灾备。需要逐层思考这个问题。
架构上可以提一个思路，k8s下层的容器调度（scheduling framework）和存储调度（CSI和PVC storageclass）都是插件式的，可按需进行定制和扩展。
但高可用本身，见过很多方案通过应用层进行，如sidecar BIN log复制等等

不太建议数据库上容器，目前还没有成熟的方案，尤其对并发及性能有要求的场景。

不太建议数据库上容器，

这个问题还是回归到有状态的服务要不要上K8S，目前阿里云之类的数据存储类服务还是依赖虚拟机，数据库上K8S 的还是比较少，其实重点还是回归到存储，本地存储、共享存储等 不同的场景保障不同的可用性。