Kubernetes 的使用时机

已完成

是否使用容器业务流程平台(如 Kubernetes)取决于业务和开发要求。 我们来回顾无人机跟踪解决方案的整个体系结构。

该解决方案构建为微服务,该微服务被设计为松散耦合的协作服务。 若要简化解决方案的设计和维护工作,你需要单独部署这些服务。 下面是解决方案的当前配置。

Diagram of the high-level architecture that describes the drone tracking solution.

  • Web 前端:显示与跟踪的无人机相关的地图和信息。
  • 缓存服务:存储网站上显示的频繁被请求的信息。
  • RESTful API:由跟踪的无人机用于发送自身的状态数据(例如 GPS 位置和电池电量水平)。
  • 队列:保存由 RESTful API 收集的未处理数据。
  • 数据处理服务:从队列中提取和处理数据。
  • NoSQL 数据库:存储从网站和数据处理服务中捕获的已处理的跟踪数据和用户信息。

公司中的不同团队分别开发和拥有这些服务。 每个团队都使用容器生成和部署自己的服务。 利用这一新的策略,开发团队可以满足新式软件开发对自动化、测试以及整体稳定性和质量的要求。

开发人员的要求变化为公司带来了流程和业务上的优势。 例如,更好地利用托管计算资源、缩短推出新功能的时间并扩大了客户范围。

但是,容器管理方面的挑战需要公司调查容器业务流程解决方案。 你的团队发现,将跟踪应用程序缩减为少量部署相对比较简单,但缩减和管理多个实例却很困难。

还有其他几个方面需要考虑。 例如,处理失败的容器、内存分配、网络配置和管理应用机密。

正如先前所了解的,Kubernetes 作为编排平台为这些挑战全部提供支持。

Kubernetes 适用于存在以下情况的公司:

  • 开发微服务形式的应用。
  • 开发云原生应用程序形式的应用。
  • 使用容器部署微服务。
  • 大规模更新容器。
  • 需要集中式容器网络和存储管理。

Kubernetes 不适用的情况

并非所有应用程序都需要在 Kubernetes 中运行。 因此,Kubernetes 可能不适合你的公司。

例如,在单体应用的容器化和部署方面的付出可能大于在 Kubernetes 中运行应用的收获。 单体体系结构无法轻松地使用单个组件缩放或更新这样的功能。

Kubernetes 可能会在软件开发、部署、管理和流程简化方面带来许多业务优势。 然而,Kubernetes 学习起来并不简单。 Kubernetes 的模块化设计引入了可能影响公司各个团队的新概念。

开发和设计应用时,开发团队必须接受新式设计概念。 这些概念包括使用微服务和将这些服务容器化。 公司中的团队还需要尝试使用容器和业务流程环境,从而充分利用所有可用的选项。

如果你的公司未准备好接受这样的变化,则 Kubernetes 可能并不适合你的公司。