在 Kubernetes 集群中部署现代应用的通用模式

2022年05月11日 阅读数:4
这篇文章主要向大家介绍在 Kubernetes 集群中部署现代应用的通用模式,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

原文做者:Rob Whiteley of F5
原文连接:​​NGINX Sprint 2.0:清晰的愿景、新出炉的代码、全新的开源承诺 - NGINX​
转载来源:NGINX 官方网站nginx


摘要

咱们正在经历现代应用交付领域的第二次浪潮,而Kubernetes 和容器化则是此次浪潮的主要推进力量。安全

随着第二次浪潮的推动,咱们在 NGINX 用户和已在Kubernetes 集群中成功部署现代应用的客户中看到了一种通用模式。咱们将这种模式称为 ClusterOut,它共分为三个阶段:微信

第一阶段:构建坚实的Kubernetes基础网络

第二阶段:安全地管理集群内外的 API并发

第三阶段:提升集群弹性负载均衡

本文将详细介绍Cluster Out这一优先级框架,从而帮助您更有效地采用Kubernetes 和现代应用。框架


感知可控,随需而变

F5 的愿景是打造感知可控、随需而变的应用。什么是“感知可控、随需而变” 的应用?咱们将应用想象成一个生物体,它们可以自主扩展、缩小、自我修复和防护,帮助减小对持续人工干预的需求。机器学习

我强调“自主”一词是有缘由的。随着新一代数字服务的诞生,底层应用必须摆脱人工操做的速度限制。它们必须足够智能才能根据上下文和条件适应环境。它们必须本身作出改变,就像生物体同样。分布式

咱们正在探索如何让机器学习支持自适应智能。但罗马不是一日建成的,咱们还要付出不少努力。如下是咱们对感知可控、随需而变的应用发展道路的设想,以及经过技术发布和产品路线图来实现愿景的思路。微服务


现代应用交付领域的三次浪潮

咱们认为现代应用交付领域将经历三次浪潮。第一次浪潮主要是实现大规模并发和扩展。NGINX 便问世于此次浪潮中,为 Web 级应用的兴起而生。

第二次浪潮(也就是咱们正在经历的浪潮)是应用解耦为微服务并经过 API 进行链接,以加深分布式程度和提升弹性。Kubernetes 和容器化是此次浪潮的主要推进力量,最初随着云计算的增加而崭露头角。

这波浪潮还极大地推进了自动化技术的发展,第一代感知可控、随需而变的应用应运而生。自适应行为既能够像自动扩展同样简单,也能够像策略引擎同样复杂,其中策略引擎经过观察 API 和应用的执行方式进行自我纠正。

第二次浪潮为第三次波浪潮奠基了基础。第三次浪潮将赋予应用更高级的智能性和机器学习能力,让它们可以感知环境,并真正实现无人工干预的自适应。


Cluster Out——​K8s 应用部署的通用模式

随着第二次浪潮的推动,咱们在 NGINX 用户和已在 Kubernetes 集群中成功部署现代应用的客户中看到了一种通用模式。咱们将这种模式称为 Cluster Out,它共分为三个阶段,以下图所示。

第一阶段:构建坚实的 Kubernetes 基础

许多企业仍在紧锣密鼓地部署 Kubernetes 和容器。其实,一个好的生产级 Kubernetes 平台,须要进行深思熟虑的定制和调整。尽管 Kubernetes 是一款强大的多用例通用平台,但开箱即用的特性仍是致使它缺少部署、管理和保护生产应用所需的应用交付和应用安全功能。

最重要的是,若是 Kubernetes 生产环境不稳定,开发人员就不肯意在这里部署代码。为了加强开发人员的信心,您必须为 Kubernetes 生产环境添加七层网络、可观察性和安全性。您能够经过 Ingress 控制器、WAF 和服务网格并结合其余云原生项目(例如 Prometheus)来解决这一挑战。

第二阶段 安全地管理集群内外的 API

只要您拥有优秀的生产级 Kubernetes 环境,开发人员就愿意在这里部署更多代码。这就是咱们常说的“栽下梧桐树,引得凤凰来”。您会发现,微服务和应用的数量正在快速增加,它们与集群内的其余服务、集群外的客户端和应用进行通讯所用的 API 数量也是如此。内部(服务到服务)API 调用次数一般是外部(应用到客户端)调用的 10 倍或更多倍。

随着应用环境的扩张,一系列让 Kubernetes 平台没法应对的新挑战不断涌现,包括要求更复杂的 API 身份验证、受权、路由/整形和生命周期管理等。复杂的环境可能有成百上千个 API,所以拥有可帮助您对 API 进行保护、管理、版本控制和弃用的工具相当重要。在 Cluster Out 的这个阶段,您须要 API 网关、API 管理和 API 安全工具等技术,它们可以随着开发人员作出的调整持续扩展服务,并进一步加强应用功能。

第三阶段 提升集群弹性

实施 Cluster Out 模式的第三个阶段是考虑如何将 Kubernetes 环境与其余环境链接起来,不管这些环境是其余集群仍是虚拟机或裸机上的应用部署。毕竟,咱们如今设计的是分布式、松散耦合和富有弹性的云原生应用。

现代应用必须至少可以跨多个 Kubernetes 集群进行通讯,从而实现更高级别的弹性并实施更智能的策略(例如成本控制策略)。而从普遍意义上来讲,现代应用不多是孤岛。它们更有可能被融合到一个由外部服务、存储桶和合做伙伴 API(可能位于其余环境)组成的网络中。即便在内部,复杂的应用也可能须要与不一样集群、可用区或数据中心的其余内部应用进行通讯。

在这个阶段,开箱即用的 Kubernetes 仍然未能解决其所面临的挑战。您须要将 Kubernetes 边界(即 Ingress Controller)自动链接到外部技术,例如四层负载均衡器、应用交付控制器和 DNS 服务,从而路由流量和处理故障转移。


总结

实际上,Cluster Out 模式只是咱们从 Kubernetes 早期采用者身上看到的一个成功秘诀。做为一个优先级框架,Cluster Out 是在企业环境中大规模运行容器的逻辑和方法,可以帮助您更有效地采用 Kubernetes 和现代应用。这种方法的强大之处在于,它为平台团队提供了一种系统方法,支持 Kubernetes 在生产环境中的使用。


更多资源

想要更及时全面地获取 NGINX 相关的技术干货、互动问答、系列课程、活动资源?

请前往 NGINX 开源社区: