云原生应用程序和数据必须要确保安全

更敏捷、更多数据……更多问题?

为了采取必要的措施，开发人员正在研究如何利用云原生方法。但是，这不仅仅是将现有应用程序迁移到云平台上并添加更多基础设施那样简单。它需要围绕软件容器构建的新架构和采用的业务流程工具如何在从构建到生产的自动化应用程序中发挥作用，如何在容器之间有效地使用API​​，然后如何通过应用程序基础设施的动态更改来处理数据。

Kubernetes现在是基于这种方法来编排容器和管理应用程序的一种首选方法。 Kubernetes可以处理设置应用程序工作负载，确保其继续运行，并应对规模挑战。但是，尽管Kubernetes可以编排应用程序，但它不能解决数据管理问题。应用程序创建的所有信息仍然需要管理。

传统上，要想成功地使用像Apache Cassandra这样的数据库，用户必须从操作系统开始理解整个软件堆栈。他们还必须确保其一致性并遵循严格的操作和部署手册。这种方法不仅需要深入了解数据库的工作原理，还需要随着时间的推移进行一些人工干预以处理扩展。

使数据与应用程序一样易于编排

与Kubernetes一起管理云原生应用程序数据需要一些计划。一种方法是使每个服务的数据库实例位于Kubernetes集群之外。这使企业的数据基础设施脱离了控制平台，并为那些现在必须管理两个环境的用户创建了额外的工作。而这种情况并不理想。

更好的方法是从物理角度将数据与应用程序组件一起分布，但需要在同一控制平台内。这确保了每个应用程序服务都可以有效地读写数据，企业可以将这些数据和应用程序作为一个整体进行管理。更重要的是，这种方法应该能够像任何软件容器映像一样在多个云服务或云平台上进行扩展。

为了与诸如Apache Cassandra之类的数据库一起运行Kubernetes，企业将需要在Kubernetes集群中使用Cassandra Operator。这使Cassandra节点可以作为服务在现有Kubernetes集群内部运行。运营商在Kubernetes和更复杂的流程(例如Cassandra)之间提供了接口，以允许对其进行一起管理。启动和停止Cassandra集群，对其进行扩展和处理故障都通过Kubernetes Operator以Cassandra理解的方式进行处理。

更好地参与Kubernetes环境意味着需要深入了解集群状态。实际上，这意味着以前属于数据库内部的某些操作(例如自动重试或建立Gossip链接以跟踪内部集群状态)被提升到API层。然后，Kubernetes可以基于整个集群的健康状况做出决策，以便可以采取任何行动，例如如果需要更多节点，则可以启动这些元素以自动弥补。通过可用指标可以观察到所有这些情况。

（编辑：淮南站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!