使用Kubernetes和Apache Cassandra的云原生应用和数据

将你的应用程序转移到云中运行对开发者来说是很有吸引力的。谁不喜欢能够轻松扩展并由别人来担心硬件的想法？然而，利用云原生方法来设计你的应用程序，不仅仅是将它们迁移到云平台，或使用云服务。

这在实践中意味着什么？它涉及到理解容器和协调工具在自动化你的应用程序中所发挥的作用，如何有效地使用API，以及数据等其他元素是如何被你的应用程序基础设施的动态变化所影响。更具体地说，它意味着在向分布式数据转移的同时，使用云中几乎无限的计算和存储来运行你的应用程序。Apache Cassandra是为云数据而建立的，现在正成为开发者对云原生应用的选择。

我们是如何走到今天的？

让我们来看看我们是如何走到今天的。在过去的二十年里，分布式计算有几个大趋势。可靠的规模网络是2000年的重点领域，它使多个地点和服务连接在一起，使它们能够以互联网要求的速度和数量运作。随后在2010年代，计算和存储被转移到云端，利用分布式网络的力量，按需弹性地将应用基础设施连接起来。这对应用本身很有效，但它并没有改变我们一直以来的数据管理方式。

管理像Cassandra这样的分布式数据库可能很复杂。为了管理多个服务器上的事务，需要对布鲁尔定理中提出的权衡有一定的了解，该定理涵盖了一致性、可用性和分区容忍度（CAP）：数据库如何管理跨节点的数据；该数据的可用性；以及在不同地点分别会发生什么。更重要的是，当非理想条件出现时，数据库如何反应。在一个有多个部分的系统中，不可避免地会发生故障。

你的数据库不仅要管理故障情况，它还必须在保持数据一致性、可用性和跨多个地点的分区容忍度的同时做到这一点。这正是Cassandra所要做的，并且已经在这些艰难的条件下证明了自己。扎根于分布式基础，使Cassandra从一开始就有能力做混合云、多云或地理分布式环境。随着应用程序被建立起来以抵御故障和可扩展性问题，Cassandra一直是开发人员的首选数据库。

下一步是什么？

今天，我们有更多的开发人员使用微服务设计，将应用程序分解成更小、更容易管理的单元。每个单元都实现了一个特定的目的，可以使用容器独立扩展。为了管理这些容器实例，容器编排工具Kubernetes已经成为事实上的选择。

Kubernetes可以根据需要处理创建新的容器实例，这可以帮助扩展应用程序的可用计算能力。同样，Kubernetes动态地跟踪运行中的容器的健康状况–如果一个容器发生故障，Kubernetes会处理重新启动它，并可以在其他硬件上安排其容器替换。你可以快速构建微服务驱动的应用程序，并确保它们在任何Kubernetes平台上按设计运行。对于一个应用程序来说，连续运行并避免停机，甚至在事情发生时，都是强大的属性。

为了让Kubernetes与Apache Cassandra一起运行，你需要在Kubernetes集群中使用Cassandra运营商。这允许Cassandra节点作为一项服务在现有的Kubernetes集群之上运行。操作员在Kubernetes和更复杂的进程（如Cassandra）之间提供了一个接口，使它们能够被一起管理。启动Cassandra集群、扩展它和处理故障都是通过Kubernetes运营商以Cassandra理解的方式来处理的。

由于Cassandra节点被认为是有状态的服务，你将需要为你的Kubernetes集群提供额外的部分。Cassandra所需的存储需求可以通过使用PersistentVolumes和StatefulSets来满足，以保证数据卷在任何重启事件之间都连接到相同的运行节点。Cassandra节点的容器是以外部卷的理念构建的，是集群部署成功的关键因素。如果配置得当，一个YAML文件就可以在各种环境中以一致的方式部署应用层和数据层。