共计 2761 个字符，预计需要花费 7 分钟才能阅读完成。
云原生部署扭转了软件开发。依据云原生计算基金会 (CNCF)2021 年年度考察，96% 的组织正在应用或评估 Kubernetes。更确切地说，560 万开发者在应用 Kubernetes，比去年减少了 67%。
云原生架构使涣散耦合的服务具备弹性、可管理性和可察看性。当与自动化相结合时，云原生性能还能够以最小的中断实现频繁的、影响较大的更改。
只管越来越多的开发人员正在承受云原生部署，但该技术在电信业务支持系统（BSS）畛域依然绝对较新，而且云原生应用程序部署团队面临着一些挑战，尤其是在有状态应用程序方面，例如 BSS 中的应用程序。
上面，让咱们看看企业目前在运行云原生部署方面面临的次要挑战。
云原生挑战 #1：运行 Helm chart
传统上来说，BSS 空间部署和降级始终是一场劫难。因为全面降级通常须要 12 到 18 个月的工夫，搭建环境又须要几天或几周的工夫。然而如果采纳正确的办法，云原生应用程序部署无望通过无缝降级齐全颠覆这种模式，而这种降级不会中断服务，并且只须要通常所需工夫的一小部分。
然而，设置基于云的自动化部署以减速降级的一个重要局部是可能疾速启动运行测试甚至全面的生产环境。
Helm charts 是执行此操作的一种办法。借助 Helm，你只需按一下按钮就能够将系统启动并运行到所需的大小和规格。但为了使其发挥作用，企业的整个技术栈包含其数据平台须要无缝合作，这可能是一个挑战。
假如你可能应答这一挑战，则能够依据须要应用 Helm 启动开发和测试环境，并在实现后销毁它们。这对于共享硬件和通过仅在应用资源时付费来升高公共云老本十分有用。
云原生挑战 #2：CI/CD
应用 Helm 来治理部署和降级通常只能做到这个水平。为了确保继续服务，还必须治理多个异地冗余群集，并在各个群集之间编排任何更改。继续集成和继续交付（CI/CD）能够通过自动化部署减少显著的业务价值，从而加重团队设置手动配置的累赘。
CI/CD 工具可用于主动启动更改（如降级）的一系列步骤，以及在生产部署中执行的其余手动工作。与其让开发人员在凌晨 3 点通过 100 步流程来实现降级（并因筋疲力尽而犯错误），CI/CD 会为您解决这所有。
然而，为了实现 CI/CD 的承诺，开发团队须要确保他们的工具可能无缝合作。
云原生挑战 #3：主动扩大
当公司在公共云上部署应用程序时，他们会为所应用的资源付费（例如，每小时）。
通常，夜间的免费策略和收费量要远低于白天。更重要的是，流量模式会随着用户群的增长而季节性稳定。在这种状况下，通信服务提供商（CSP）不心愿从一开始就领取反映将来业务量最忙碌工夫和最低廉资源的价格。相同，他们心愿确保以具备老本效益的形式为他们应用的资源付费——不多也不少。
这就是主动扩大特地有用的中央。通过主动扩大，应用程序能够始终依据所需的流量需要调整容量，并且会随着需要的变动而动静地扩充和放大。
然而，对于有状态的应用程序，这是有问题的。尽管有状态应用程序能够通过增加新的 Pod 来扩大，但放大规模是有代价的；你必须要解决存储在要删除的 Pod 上的数据，这须要工夫和精力。依据所波及的内容，这项工作的老本可能比独自应用解决方案要高。
此外，Kubernetes 可能对你数据平台的弹性能力或散布在 Pod 中的分区无所不知，这意味着 Kubernetes 不能用于向上或向下扩大 Pod，因为须要扩大多个 Pod 能力保持数据冗余。因而，你可能须要在 Operator 中治理所有这些，这须要额定的工程设计工作。
云原生挑战 #4：服务网格
将单个应用程序（如用于策略和计费的应用程序）拆分为多个微服务会减少它们之间的接口。因为解决方案的每个局部都是依据本人的需要独立扩大的，因而在任何给定工夫都将运行多个微服务。
这就是基于云的服务网格特地有用的中央。简而言之，服务网格旨在帮忙简化和治理微服务之间的路由流量，因为每个微服务运行的 Pod 数量是动静的。服务网格还能够加密接口流量，从而使应用程序不用治理加密。在某些状况下，它还能够帮忙进行日志记录和事务跟踪。
跟踪只实用于基于 HTTP 的协定；它实用于 5G，但不适用于 4G 或之前的任何产品。可怜的是，微服务之间的接口不太可能基于 HTTP 的，因而网格将无奈帮忙进行跟踪。
然而，有些 RFP 要求对所有外部和内部接口应用基于 Istio 的服务网格。如果须要网格来管理系统外部接口，例如集群内和跨数据中心复制 (XDCR)，可能会导致性能问题，这就须要工程人员能力解决。
云原生挑战 #5：群集降级
因为 5G 服务级别协定（SLA）须要个位数毫秒的响应，开发人员没有工夫通过 XDCR 将流量路由到其余数据中心。因而，即便在降级期间，每个集群都应放弃服务状态。
群集降级应一一 Pod 进行。这意味着你必须治理混合版本的集群，直到每个 Pod 都降级。尽管这是一个常见问题，但对于有状态的应用程序，它须要产品在单个集群中解决并发的多个版本，这是一个须要解决的简单问题。
云原生挑战 #6：多站点 XDCR 降级
从软件版本升级到架构革新再到存储过程更改，所有事件都须要在 XDCR 设置中的每个集群放弃服务时执行。换言之，你不能敞开一个集群而只留下一个可用集群。
再一次，正确实现这一点须要大量的产品性能。
云原生挑战 #7：安全性
监管机构对部署在公共云上的应用程序的平安和加密越来越严格。因为政策和免费性能蕴含十分敏感的数据，监管机构越来越多地审查这些畛域以爱护消费者。
展望未来，当应用程序在公共云中运行时，很可能所有接口——甚至是运行时内存——都必须加密。例如，一些欧洲监管机构曾经要求对保留在公共云中的敏感数据的运行时内存进行加密。
随着平安要求的进步，产品将须要在整个应用程序堆栈中更无效地治理明码、用户、角色、拜访和加密证书。他们还须要确保在放弃预期性能的同时对所有流量进行加密。
云原生挑战 #8：操作和故障排除
将应用程序拆分为多个可动静扩大的微服务会使操作和故障排除变得更加艰难。当呈现问题时，服务失败申请的实例很有可能在有人试图查看产生的状况时不会运行。
例如，主动缩容会终止多个 Pod，而当有人解决问题时，导致问题的 pod 可能早已死亡。
Kubernetes 设计用于解决主动复原；Pod 是为了失败、终止和被代替而发明的。因而，团队将须要新的监控和追踪工具来帮忙理解状况。而这些工具也须要被治理。
云原生仍是将来
只管存在这些挑战，软件开发的将来依然是云原生。这是因为该办法带来了很多益处，包含更快的迭代、更低的老本、可扩展性、灵活性、自动化等等。
通过理解云原生部署中固有的挑战并踊跃致力解决这些问题，开发团队能够充分发挥云原生应用程序的后劲，让其用户和企业称心。
如果您心愿集成 VoltActiveData 到您的技术栈中，请与咱们分割！
Volt Active Data 中国网站 | sgao@voltactivedata.com
