广告

Postgres在Kubernetes的5年

  • 浏览(102)
  • 评论(0)
  • 译者:k8s

Kubernetes设立Postgres operator的想法是在2016年社区成员的一次讨论中产生的。那时是Kubernet成立初期,关于在容器中运行数据库的想法存在争议。

如今,有一系列工具和技术可用于在Kubernetes集群(包括Crunchy Data等公司的operator)中运行稳定、高可用和高性能的Postgres工作负载。

在整个行业中,我们看到越来越多的人成功地将operator架构模式用于不同的工作负载集。笔者客户的体验,以及与更大社区交互的体验,让笔者对Kubernetes中的Postgres世界有了一个细致入微的了解。今天,笔者分享这些经验教训,并对五年来的经验教训进行深入分析。

基础设施就是代码

从一开始,operator背后的概念是,它们将在功能上自动化你的Kubernetes应用程序。这意味着,基础设施即代码是在Kubernetes中实现的。这一直是DevOps的梦想——一个自我修复、版本控制、自我安排和声明性定义的平台。

随着Kubernetes的发展和API的成熟,在Kubernete中提供一个完全声明的Postgres operator成为一个越来越容易实现的目标。我们还开始从用户和客户那里听到,他们希望看到项目采用更具声明性的方法。

幸运的是,这也是我们一直在思考的问题。这成为了Crunchy Postgres for Kubernetes第五大版本的关键驱动因素。虽然我们在设计这个版本的Postgres Operator时考虑了几个理想情况,但我们的主要目标是使Crunchy Postgres for Kubernetes完全声明性。这不是一件小事;本质上,这是一次彻底的重建。从最新的现代Kubernetes功能开始,我们为Kubernete开发了一个新版本的Crunchy Postgres,用户可以简单地描述他们追求的最终结果,剩下的就由Crunchy Postgress来完成。

从存储开始

数据库不同于无状态应用程序,它们需要持久存储。Kubernetes提供了强大的自动化功能和许多有趣的功能,但我们知道我们需要一种方法来提供一致和有状态的存储,因为存储是数据库功能的基石之一。

存储需求最终导致我们将Kubernetes技术与operator相结合。

如今,在Kubernetes上运行的数据库可以使用一系列存储类型,如HostPath、网络文件系统(NFS)和动态存储。Crunchy Postgres for Kubernetes与存储无关:它适用于任何受支持的Kubernete存储系统。你必须同时为Hostpath和NFS配置永久卷,尽管确实存在自动存储配置器。动态存储类允许用户请求持久卷声明,并为你创建持久卷。有许多动态存储类的提供程序可供选择。你需要配置适用于环境的内容,并调整物理卷、持久卷(PV)的大小。

Postgres operator

早期,Kubernetes的operator模式是未知领域。运行容器中的数据库等有状态进程是一个非常新的概念。operator模式展示了简化Kubernetes数据库操作和管理的潜力。从我们团队听到CoreOS的推介的那一刻起,我们就看到了承诺。

在早期,对于operator模式的适当使用以及该模式是否具有持久力,存在着相当多的争论。早期,许多人就Helm图表和operator之间的权衡提出了问题。实际上,它们是不同的,你可能两个都需要。

构建一个高可用、自我修复的Postgres集群很困难。你必须考虑备份、跨数据库的负载均衡、指标、数据库主机更改、存储和正确调整所有这些服务的大小。你必须确保这些服务一直在运行,还需要考虑如何处理版本升级、安全修补程序等。

Crunchy Postgres for Kubernetes是最早的针对Kubernet的Postgress operator之一,其体验体现在易于设置和高度弹性的架构上。让人们能够创建内置高可用性和自我修复的Postgres集群,是Crunchy Data的Postgrees for Kubernetes团队的主要目标。

学习API

自早期以来,Kubernetes和它的API发展迅速。底层API通常会在不同版本之间进行更改,以增强新功能或整合功能。Crunchy Postgres for Kubernetes与Kubernetes API一起发展,你可以在Postgres Operator的第五个主要版本中看到这些年的工作达到了顶峰。

通过使用operator的API功能,团队可以感受到Kubernetes的真正力量。这些API能够执行许多任务,如部署、添加用户、从失败的健康检查中恢复、运行备份、从备份中恢复等。使用这些API时,团队开始升级。CI/CD功能在团队中的可重复性大大提高,部署staging是一个自动化而不是手动的过程,因此每个数据库都统一运行,而不是作为边缘案例。

为了实现此功能,必须将operator的使用集成到许多其他系统中。例如,我们的客户具有API级别的集成,包括票证系统、部署系统、分析团队、营销团队、运维团队和代码库。因此,至关重要的是,Crunchy Postgres for Kubernetes拥有稳定的API,并得到一个考虑兼容性的团队的支持。使用流体API部署operator可能很快成为所有集成点的负担。

展望未来

笔者认为,我们最初支持operator模式来管理状态服务,如Kubernetes中的Postgres,是一个不错的选择。随着Kubernetes的成熟,operator模式和API的发展加强了这种方法,Postgres operator已经与社区一起成熟。相信未来Operator模式会进一步成熟并实现。

 

原文链接:

https://thenewstack.io/5-years-of-postgres-on-kubernetes/

  • 分享到:
  • icon
  • icon
  • icon
  • icon
箭头