点赞
评论
收藏
分享
举报
在Kubernetes集群中部署现代应用的通用模式
发表于2021-09-15 10:00

浏览 745


摘要

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

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

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

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

        第三阶段:调高集群弹性


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




感知可控,随需而变


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

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

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


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


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

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

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

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


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


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


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 在生产环境中的使用。  




已修改于2023-03-07 02:21
本作品系原创
创作不易,留下一份鼓励
NGINX官方账号

暂无个人介绍

关注



写下您的评论
发表评论
全部评论(0)

按点赞数排序

按时间排序

关于作者
NGINX官方账号
这家伙很懒还未留下介绍~
228
文章
21
问答
198
粉丝
相关文章
通过nginxplus 实现动态黑白名单前言:随着现代应用架构的发展和演进,特别是容器云的盛行,越来越多的用户将7层流量的控制从前端网络的应用交付设备转向到了在每个应用,微服务前的软负载SLB上。典型的SLB,如nginx,部署位置可以在网络边界,在服务器的前端,在容器云中,以反代,微网关,sidecar的形式存在。因为业务在不断的变化,特别是随着devops文化的流行,业务变化的频率和业务对基础架构的诉求也在不断上升。因此,我们也在nginx上交付了越来越多的应用服务,其中就包括了大家熟悉的黑白名单功能。从现代的安全架构上来看,内网是不安全的,这件事情也得到了共识,从而出现了零信任架构,出现了无界的安全,出现了双模安全,基于每个应用的定制化精细化安全策略的诉求也就出现。那么如何基于每个应用或微服务,进行频率的控制是保证应用的稳定性,健壮性,可用性的关键。限流是一个很好的方法,但是静态的限流很容易被绕过,应用层的ddos攻击往往会压着访问频率,那么如果能够准确定位出每个客户端,每个session的请求频率,自动的把超出阈值的客户端加黑封禁一段时间,比如说3分钟,这样就可以
点赞 0
浏览 1.5k
本指南介绍了在Ubuntu16.04服务器上设置可用于生产环境的ASP.NETCore环境。这些说明可能适用于较新版本的Ubuntu,但尚未针对较新版本进行过测试。有关ASP.NETCore支持的其他Linux发行版的信息,请参见Linux上.NETCore的先决条件。笔记对于Ubuntu14.04,supervisord建议将其作为监视Kestrel进程的解决方案。systemd在Ubuntu14.04上不可用。有关Ubuntu14.04的说明,请参见本主题的先前版本。指南:将现有的ASP.NETCore应用程序放置在反向代理服务器后面。设置反向代理服务器以将请求转发到KestrelWeb服务器。确保Web应用程序在启动时作为守护程序运行。配置流程管理工具以帮助重新启动Web应用程序。先决条件使用具有sudo特权的标准用户帐户访问Ubuntu16.04服务器。服务器上安装了最新的非预览版.NET运行时。现有的ASP.NETCore应用程序。升级共享框架后,在将来的任何时候,重新启动服务器托管的ASP.NETCore应用程序。通过应用发布和复制配置应用程序以进行
点赞 2
浏览 754
如题所示,背景是工业互联网中,机器发送的数据包特别大,频率也很高,一个接收端来接收处理数据时负载较大,想着使用Nginx做负载均衡,但是传统的负载均衡都是对请求数或者连接数特别多的情况下的负载均衡,对于这种只有一个连接,但是数据包大小特别大、频率很高的情况下,使用nginx应该怎么做呢?还请诸位前辈不吝赐教,感谢!
点赞 0
浏览 968