技术博客
Moderator Moderator , Moderator Moderator Moderator
技术博客
Kubernetes:现代内核
Dec 10, 2019

 

1Blog1.jpg

 

在 2019 年度 KubeCon + CloudNativeCon 大会筹备期间,我们会发布一系列博客,介绍我们预期在本次大会上会引发热议的主题。在 第一篇文章中,我们回顾了从整体应用到基于微服务应用的发展历程,并以 Kubernetes 作为编排器为例,概述了微服务带来的速度优势和规模优势。

 

Kubernetes 似乎采用了新的软件定义方式,一种类似软件定义网络 (SDN) 的灵丹妙药,在瞻博网络化身为著名的 JKitty——没错,就是 Rainbow Butterfly Unicorn Kitty 动画中的那个 Kitty。但是,您知道他们如何描述蝴蝶效应吗?当 Kubernetes Kitty 拍打翅膀时......风暴即将来临。Kubernetes 确实很棒,但不是那么容易实现。随着 Kubernetes 向微服务架构转变,面临的挑战可能与解决的难题一样多。

 

将应用细分为微服务意味着,安全性和网络连接都至关重要,因为网络决定了微服务相互之间如何通信,从而集成为更大的应用。您可能搞错了,这可是一场真正的大风暴。

 

在本周的 KubeCon 上,瞻博网络展示了我们以工程技术扬名的解决方案:大规模网络和安全性。

 

幸运的是,这些巧合恰到好处地简化了 Kubernetes 带来的挑战。让我们仔细探究一番。

 

微服务和 Kubernetes:机遇与挑战并存

对于一个架构出色的基于微服务的应用,
只要有一个编排平台能确保有足够的正确服务实例处于活动状态以使应用可以满足需求,丢失单个容器或服务器节点便不是什么大问题。  毕竟,基于微服务应用的设计初衷就是让您能够按需添加和移除单个服务实例。

 

这种横向扩展的容错编排是 Kubernetes 借助许多其他基于约束的调度功能实现的。因此,Kubernetes 通常被称为云端操作系统内核。从许多方面来看,它都是适用于基于微服务的分布式应用群集的强大过程调度程序。但是,内核并不是决定应用能否发挥功用的全部。

 

在解决我们行业中的各种棘手问题时,真正的瞻博网络风格是精研至简 — 从容应对存储、安全、网络和监控方面的挑战。我们从客户和自身经验中得知,如果您要管理自己的 Kubernetes 部署,那么必须妥善解决这些挑战方可成功管理这个新的 IT 平台。

 

解决问题的一种办法是外包。Kubernetes 即服务就是这样的一种至简方法,但它同样面临着如何在成本与多云可移植性及统一性之间权衡的挑战。因此,对于大多数企业而言,Kubernetes 群集运维势必无法避免瞻博网络随时准备提供帮助。

 

不要限制挑战,要勇于挑战极限

 

Kubernetes 运营商经常通过限制群集规模来应对挑战。

 

较小的群集规模可限制安全性和可靠性的爆发范围;同时,与大型共享群集相比,这种对监控、存储和网络的小规模需求更容易得到满足。在某些情况下,每个应用团队会部署各自的群集。还有一些情况下,每个开发生命周期阶段(开发、测试、部署和生产)都有各自的 Kubernetes 群集。除了所有变体之外,许多 Kubernetes 运营商还会部署一些小型群集;例如,部署 10 20 个节点,每个节点中各有几个应用。但是,Kubernetes 可以扩展至远超这种小型群集几个数量级的规模。

 

许多小型群集的结果有一个专门的名字:Kube 蔓延。

 

尽管使用小型群集设计可能有一些好处,但是这种方法很快产生了新的挑战 — 它并不是抑制了复杂性,而只是转移了复杂性。管理多个群集的运维挑战还意味着,在运行、升级和修补群集时增加了更多 Kubernetes 版本。更不用说,需要更多的工程师来完成所有这些工作,或者增添了更多构建自已的自动化流程的任务。

 

此外,还有一个明显的缺点是,由于每个服务器或虚拟机节点只能属于一个 Kubernetes 群集,因此丧失了大型共享群集所能提供的效率。随着大量应用、团队、批次和高峰使用的出现,规模的资源效率和经济性便显而易见了。

 

如果一个小型群集仅运行几个应用,这些应用的多样性便不足以稳定地充分利用整个资源池,因此经常会存在浪费的情况。运营商可以尝试设法令群集节点本身的数量像容器化应用一样具有弹性,但是这很难根据每个小型群集内部应用的独特需求自动执行和构建编排。鉴于每个 Kubernetes 群集需要至少三个服务器节点才能实现高可用性,所以在维护的众多群集之间这同样会导致重复浪费。

 

大量群集为开发人员带来了新的挑战。虽然存在诸如微服务跟踪之类的云原生工具可以使开发人员受益,但这些工具和其他中间件服务通常设计为在群集内(而非跨群集)使用。在跨群集联合时,像服务网格这类新工具可能会增加复杂性。

 

应用跨边缘云和多云,云原生基础架构也须如此

 

Kubernetes 擅长管理由服务器以及其上运行的容器组成的单个群集。但是,某些应用会在多个群集中运行,跨越了多个故障域或可用性区域 (AZ)。这不是同一数据中心可用性区域中的多个小型群集,而是跨多个数据中心,可以提高可用性并改善全局覆盖范围和用户延迟。

 

解决每个群集的安全性、网络、监控和存储只是第一步,强大的解决方案应该能够应对跨可用性区域、地区、边缘云和多云联合多个群集的挑战。在本次 KubeCon 上,瞻博网络再次展示了自己在该领域的市场领先地位。

 

在当前局势下,安全性和网络变得更加复杂,因为它们在全局应用架构中发挥着更为重要的作用。网络必须将微服务以及多云链接在一起。深度防御必须保护一个群集,而为了在从上到下实施的同时也实现端到端的统一策略实施,还需做到广度防御。

 

您不能总是抛弃老旧的软硬件设施

 

在企业实践中,云原生应用使用的服务范围非常广泛,从“该数位仍在大型机上运行此数位可以适当地称为微服务,种类繁多。那么,如果应用构建时所使用的服务类型各不相同,而且每种服务跨多个不同类型的基础架构运行并可能来自世界各地的多个提供商,这种情况下,组织该如何为应用提供安全、高性能和可扩展的软件定义基础架构呢?

 

同样,解决 Kubernetes 面临的安全性、网络、监控和存储挑战固然很好,但是又该如何管理虚拟机和裸机上的一些老旧软件和设备呢?随 Kubernetes 出现的许多新奇工具都因 Kubernetes 的需求变化而寿终正寝,但应用则不然。运维也不会出现这种情况,但运维团队因为需要学习和部署其他工具而加重了负担,并没有感受到预期的负但减轻。当今的技术和工具必须解决新的云原生问题,但解决当今最困难问题的最佳办法是:至简运维。只有跨越新与旧的界限,并保持顺应未来的发展能力,才有可能实现此目标。

 

带来至简运维的解决方案

 

至此,不难想象接下来会发生什么。瞻博网络已在过去很长一段时间里成功构建了许多高性能、可扩展的系统。

 

请继续关注我们的下一篇博客,其中将探讨瞻博网络如何为 Kubernetes 用户带来至简运维以及更多。同时,还可以访问 juniper.net/cloud-native 了解有关瞻博网络云原生解决方案的更多信息。 

0 Kudos