VCN专题 | NSX高级负载均衡助推企业应用的容器化转型

Posted 2021-04-02 VMware中国

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了VCN专题 | NSX高级负载均衡助推企业应用的容器化转型相关的知识，希望对你有一定的参考价值。

现代化应用的平台Kubernetes/Openshift/Tanzu 为基于容器的工作负载提供了的自动化部署平台，将这个平台上的应用发布给最终用户时，通常需要容器外部的负载均衡产品/解决方案，或者在平台上建立Ingress服务。应用迁移到容器平台后，基于硬件设备的“网络-安全-负载均衡”解决方案变得过时了：传统的负载均衡器不支持南-北向Ingress服务，基于硬件设备的部署无法适应容器灵活部署、扩展和迁移的特点。

VMware NSX Advanced Load Balancer（本文中简称为NSX-ALB）是一个成熟的、经过大规模部署验证的负载均衡解决方案，完全可以为容器应用平台提供“Load Balancer”类型的服务，NSX-ALB中的Kubernetes Services则增加了针对容器Ingress服务功能的支持。NSX-ALB通过分布式架构的融合服务平台，将适用于Kubernetes/Openshift/Tanzu的各种应用服务整合在一起，将容器Ingress等应用层服务无缝扩展到Kubernetes环境中的云原生应用程序。

NSX-ALB融合Kubernetes的服务

NSX-ALB在提供Kubernetes Ingress Services时，可与多个Kubernetes集群进行集成，每个集群都运行自己的AKO实例。AKO是一个Kubernetes Operator，作为一个Pod运行在Kubernetes集群中的Master节点上，可与Kubernetes主数据库通信、同步所需的Kubernetes对象，并调用NSX-ALB Controller API来部署和配置Ingress服务。多个群集在转发平面上借助VRF Context彼此区分并隔离。

图：AKO服务架构

Multi-Kubernetes Operator：要跨多区域和多可用区部署扩展应用程序，则需要AMKO——它促进了多集群应用程序的部署，跨多个集群扩展了应用程序Ingress控制器。AMKO调用NSX-ALB Controller API，在作为“领导者”的集群上创建GSLB服务，所有“追随者”集群与“领导者”集群同步。这有助于多集群应用程序部署，将部署在多个集群上的同一应用程序映射到单个GSLB服务，从而跨多区域和多可用区部署扩展应用程序Ingress。

图：AMKO服务架构

以上介绍的AKO和AMKO部署方式，均需通过NSX-ALB完成集中配置和管理功能。控制器是NSX-ALB架构的中央管理组件，为基础架构编排、集中管理和分析仪表板提供所有控制平面功能。同一个控制器集群，既能为传统应用配置和管理负载均衡，也能为Kubnetes环境配置和管理负载均衡和Ingress服务。只要连接性和延迟满足要求，它可以部署在任何地方。

控制器根据需要自动部署并管理Serivce Engine（服务引擎），它提供数据平面中的所有服务：负载均衡、Ingress Controller、GSLB、DNS和WAF。服务引擎的灵活部署和“一站式”服务，避免了应用流量在多个功能网元之间被频繁调度、迂回往复，系统逻辑架构简洁清晰。NSX-ALB控制器可以从服务引擎实时监视多个应用程序并进行基于网络的遥测，并自动将虚拟服务迁移到轻载的服务引擎，或在多个服务引擎之间扩展虚拟服务以增加容量，允许多个活动的服务引擎同时分担单个虚拟服务的工作负载。

容器环境中的应用服务

将Kubernetes集群中部署好的容器通过负载均衡或者Ingress方式发布出去，只是基于容器的应用平台上最基本的需求。作为企业/组织的IT架构设计师，还必须考虑到应用被正式发布到互联网时，将要使用到的域名解析服务、WEB应用防火墙、DDoS防御、双活/多活等等一系列功能该如何设计和实现。很多用户在进行新应用转型，虽然将应用的承载和部署迁移到了以容器为基础的云平台上，但却继续使用着既有的技术方案为云平台提供外围服务。

应用平台与所需服务之间未能携手演进，主要是因为，“外围服务”包含的多种功能往往由各种彼此离散的产品来提供。企业/组织的IT部门在过去十余年间，花费了大量时间和精力，管理来自不同供应商的多个独立组件，熟悉并掌握复杂的操作步骤和流程，终于把它们整合成为了适合本企业/组织特点的应用服务体系。这个体系却无法满足容器应用的要求，大大降低了现代化应用平台在敏捷性和自动化方面的优势，好比是装备有最新一代强劲动力发动机的赛车仍在使用十余年前生产的底盘、悬挂和轮胎。

面临容器平台的强烈需求，大量原生于容器环境的新技术和新产品（大部分可通过开源社区获得）应运而生，但它们普遍存在功能单一、彼此孤立的问题。重新整合这些离散的技术和产品所需的时间仍将以“年”为单位，因为：多种产品功能之间存在差异，上下游接口不匹配可能会限制其灵活性和跨环境的可移植性，需要深度掌握不同产品的脚本知识，才有可能实现部分自动化（如果有的话），从而导致功能、自动化和规模化三者之间的冲突与妥协。因此，转向新应用平台的企业/组织，迫切需要适应容器环境的、完整的全栈应用服务解决方案，来为企业应用的转型提速。

如果说，VMware Tanzu是“最新发动机”的代表，而适用于Kubernetes的NSX-ALB，就是可以与之相匹配的最新一代应用服务解决方案。NSX-ALB具备在多种环境和多个“云”中一致地交付这些应用层服务的能力，这是业界唯一具备完整的L2-L7网络和安全堆栈的解决方案：

流量管理-本地负载均衡：本地负载均衡器或应用程序交付控制器（ADC）需要提供应用程序网络服务，例如负载均衡、运行状况监视，TLS/SSL卸载、会话持久性、基于内容/ URL的交换和内容修改。
安全防护：内置解决方案为安全和网络团队，通过全栈的安全能力（包括防DDoS，速率限制，SSL/TLS卸载和加密，以及ACL），可减少对定制化策略的依赖，并在任何环境中自动按需扩展。启用基于微服务的网络安全策略，来控制应用程序访问、进行DDoS保护/缓解，以及对Web应用程序防护（WAF）。NSX-ALB具有智能Web应用程序防火墙（iWAF）和分布式应用程序安全结构，涵盖OWASP CRS保护、对合规性法规（如PCI DSS，HIPAA和GDPR）的支持，可靠的安全模型和基于特征的检测。iWAF通过接受列表引擎来分析未经验证的流量，主动安全模型可在了解到应用程序和攻击模式后验证已知的良好行为，最后特征引擎处理与特定交易匹配的安全规则——所有这些都是实时的。经过优化的安全管道可最大程度地提高效率，大幅减少误报，并阻止“零日”攻击。

图：NSX-ALB为云原生应用提供全面的网络和安全服务

集成的架构和一致的操作体验

为了减轻企业/组织管理员的压力，还应提供集成的统一管理架构，帮助运维人员通过图形界面（或者API接口），清晰地获取每项应用及其外围服务的运行状况，并快捷、集中、自动化地完成系统的配置变更。在这方面，NSX-ALB的集中控制器符合“软件定义”的特点，在集中管理控制器上完成所有这些管理任务，而数据平面只负责流量转发、探测和安全策略的执行。以下是NSX-ALB“转-控分离”架构带来的优势：

控制操作简化：集中的策略和完整的生命周期自动化消除了手动任务，为管理员提供了集中控制、“自服务式”的应用程序交付自动化，和操作一致性。
丰富的可观察性：具有应用程序分析能力的实时遥测功能，通过闭环分析和深度机器学习，可提供涵盖了网络、最终用户、安全性和实时应用程序性能监控在内的、全面的、端到端的观察分析能力。应用健康评分ALB将分析信息汇总为健康状况评分，以提供整个应用程序的全貌。应用程序健康状况得分由服务器响应时间、资源使用情况、异常流量和安全状况确定。

图：NSX-ALB图形界面提供容器服务及健康评分的可视化展现

具有弹性的云原生自动化：在执行应用程序交付任务时，NSX-ALB的数据平面执行单元——服务引擎——的资源会出现不同的消耗情况，CPU、内存或吞吐量都存在达到容量阈值的可能。NSX-ALB可以学习应用程序访问模式，并可以基于学习到的流量模式和应用程序使用情况，执行智能的、可预测的自动扩展，以使服务引擎在需求引起的资源耗尽或中断之前，一直保持很高的可用性。这种自动扩展，可以在私有云和公有云上完成。公有云包括VMware，OpenStack，AWS，Azure和Google Cloud Platform。

综上所述，为了同时向传统的和云原生的应用程序提供全面容器服务，除了既有面向传统服务器的L4-7负载均衡功能外，NSX-ALB增加了 Kubernetes服务功能，针对南-北向（Ingress控制器）流量管理进行了增强，与NSX-ALB已有的GSLB、DNS/IPAM管理和完善的安全防护功能（WAF、DDoS防御）整合为一体。采用NSX-ALB作为应用负载管理解决方案，企业/组织的IT管理员不再需要为传统和云原生应用部署并维护不同的服务平台，将最大程度地降低应用迁移周期。无论用户的应用体系中有多少比例是基于K8S/容器方式部署的云原生应用，无论K8S集群在本地、私有云或公共云环境中运行，NSX-ALB都能够提供一致性的功能和使用体验。

云原生应用环境中的NSX-ALB功能一览