Kubernetes 存储解决方案:从单例到有状态集的深入探索
1. 外部服务的局限性:健康检查
Kubernetes 中的外部服务存在一个显著限制,即它们不执行任何健康检查。用户需要确保提供给 Kubernetes 的端点或 DNS 名称对应用程序而言具有足够的可靠性。
2. 运行可靠的单例
在 Kubernetes 中运行存储解决方案时,像 ReplicaSet 这样的原语期望每个容器都是相同且可替换的,但对于大多数存储解决方案来说并非如此。一种解决方法是使用 Kubernetes 原语,但不尝试复制存储,而是简单地运行一个运行数据库或其他存储解决方案的单个 Pod。这样,由于没有复制操作,在 Kubernetes 中运行复制存储的挑战就不会出现。
乍一看,这似乎与构建可靠分布式系统的原则相悖,但总体而言,它与在单个虚拟或物理机器上运行数据库或存储基础设施的可靠性相当,而许多人目前就是这样构建他们的系统的。实际上,如果系统结构设计得当,唯一牺牲的可能是升级或机器故障时的潜在停机时间。对于大规模或关键任务系统来说,这可能无法接受,但对于许多小规模应用程序而言,这种有限的停机时间是降低复杂性的合理权衡。
3. 运行 MySQL 单例
要在 Kubernetes 中运行可靠的 MySQL 数据库单例实例并将其暴露给集群中的其他应用程序,需要创建三个基本对象:
- 持久卷 :用于独立管理磁盘存储的生命周期,与运行中的 MySQL 应用程序的生命周期分离。
- MySQL Pod :运行 MySQL 应用程序。
-
超级会员免费看
订阅专栏 解锁全文
62

被折叠的 条评论
为什么被折叠?



