企业时刻面临着一个难题:拥抱技术变革以开辟新的商业机会还是保护企业免受新的挑战和风险影响?在本文中,我们将研究容器化以及 F5 产品采用该技术对 IT 专业人士、架构师和业务决策者的影响。
在过去的 20 年里,虚拟化改变了服务器计算方式,使多个独立的操作系统可在一个硬件平台上运行。如今,有一种更现代的方法,即容器化(或操作系统虚拟化),它使多个应用可在一个主机操作系统的单一实例上运行。此外,每个应用实例共享安装在单个操作系统实例中的二进制文件和库。图 1 对这些方法进行了比较。
图 1 — 虚拟机与容器的比较
与虚拟机 (VM) 不同,容器可共享操作系统,在操作系统层面而非管理程序层面进行虚拟化。
开发人员喜欢容器,这不足为奇,因为容器可使开发和部署应用以及启用微服务变得快速而简单。容器化还能实现更大的可移植性,因为容器中的应用更易于部署到不同的操作系统、硬件平台和云服务。与直接在裸机托管操作系统或虚拟机上运行的应用相比,容器占用的资源更少。
一般来说,大多数关于容器的讨论(和资料)都集中在编程或 DevOps 的角度。作为一名 IT 专业人士、系统架构师或业务决策者,您可能很欣赏容器化带来的灵活性,但也可能确实担心这种变化会对您所处环境中的应用和服务的管理和监控产生影响。您还希望确保容器化不会对网络和应用的安全性造成不利影响。
在竞争日益激烈的市场中,现代 IT 系统必须提供可实现的商业效益。为满足这一要求,IT 部门必须增加他们的应用资本,以设计和建造适用于更多应用的架构,而且这些应用要有更强大的功能和更高的可用性并且更易于集成。
IT 总监面临的挑战是其部门必须在不增加人员的情况下提供更强大的功能。如今生产力的提高不是来自于雇佣更多人,而是来自于技术和自动化的发展,这些技术和自动化能够增加客户可用的应用数量,并且由同样规模的团队管理。
容器部署的简易性带来了进一步挑战。开发人员需要接受教育和指导,以确保他们在创建应用时同时考虑规模和安全性,而 IT 专业人士可帮助他们实现这些产出。在这里,您需要考虑 Kubernetes 和 Docker 等容器平台对生产的影响以及如何避免敏捷性需求导致安全实践差或未考虑生产负载等不良后果。
Kubernetes 是一个用于管理容器化服务和工作负载的开源平台。Kubernetes 最初是谷歌的容器调度和编排系统,该公司随后将其捐赠给云原生计算基金会,使源代码对所有人开放。而 Docker 提供了一种类似的开源架构和分布,由一套耦合的软件即服务 (SaaS) 和平台即服务 (PaaS) 组成。
提供可实现的商业效益的关键因素是最小化价值实现时间。当涉及到插入建议性时,性能和延迟等因素的地位越来越低。因此,如果有两个拥有几乎相同的功能的组件,其中一个性能更高,而另一个更易于集成,企业会倾向于选择更容易与当前环境集成的组件。随着环境愈加复杂,这种偏见可能会持续。
当您想使用容器化等技术时,您需要一种方法来衡量这种新技术带来的价值。影响价值的因素通常包括适用性、功能、投入的精力以及成本。下列等式展示了如何根据这些因素分配相对价值。
在等式中使用的单位并不重要,但要确保将要评估的每个项目单位相同。
这个等式强调了技术必须为全方位集成,熟悉程度(即插入的简易性)可能比一流的功能或性能更重要。因此,当涉及到总价值计算时,投入部署的精力具有平衡效应,这可能导致功能较弱的产品由于易于插入而对客户更具吸引力。
相关例子可以是两个相互竞争的监控解决方案。产品 A 规格很高,有一流的记录和报告,安全性达到军事级别,并且可管理度高。然而,因其专有的命令行界面、对开放标准的支持不足以及缺乏集成功能,产品 A 难以安装。此外,它也比市场上大多数其他产品更昂贵。
相比之下,产品 B 虽然功能远不及其竞品,但仍提供可接受的监控和安全水平。此外,在成本和安装简易性方面,产品 B 比其竞品更有优势。每个产品的分数列表如下,适用性、功能和投入安装的精力方面的评分从 1 到 10,最低为 1,最高为 10。
产品 A |
产品 B |
|
适用性 |
10 |
4 |
功能 |
10 |
2 |
投入安装的精力 |
10 |
2 |
成本 |
1,000 美元 |
500 美元 |
价值 |
20 |
60 |
将这些数字放入上述等式,就会产生表格最下面一行列出的价值。
您可以看到,与其最好的竞品相比,适用性较低、功能较弱的产品 B 投入安装的精力为其五分之一,价格便宜一半,但能带来的价值多两倍。许多企业了解这些需要考虑的因素,并且在采用和部署新技术时,越来越多地将安装和集成的简易性作为一个关键因素。容器化可显著减少投入部署的精力和控制成本,同时还可以保持适用性和功能。
随着应用逐渐在提高商业价值,容器化为以 DevOps 为中心的 IT 实施做法所面临的挑战提供了一个合理的解决方案。容器可与它们所运行的平台以及其他容器隔离,而不产生运行虚拟机的管理费用。开发人员可轻松建立包含所有所需二进制文件和库的应用环境并内置所需的网络和管理设施。容器化也可简化应用测试和部署。
通过大量增加可在服务器上运行的应用实例数量,容器环境可提供比虚拟机更高的资源利用率。由于没有主机和客户操作系统费用,容器环境通过共享操作系统内核更有效地利用了处理器时间和内存空间。容器化还提供了更高的架构灵活性,因为底层平台可以是虚拟机或物理服务器。Red Hat 产品策略1指出,未来近一半的 Kubernetes 客户在将应用部署到容器中时,会直接在裸机上运行容器引擎。
容器化会带来更多方面的进步,包括基于硬件的计算、虚拟化和多云,进而实现完全自动化、亚秒级的服务创建时间以及可用秒衡量的服务寿命。有了 Docker、OpenShift 和 Kubernetes 等容器环境,我们可在现代 IT 架构中对服务和微服务进行即时预配和移除。
重要的是,容器化提供了一个在如今的多平台和多云世界中至关重要的优势:容器化能将应用从本地移植到云端,再移植到另一个云供应商,然后再次移植回本地,并且都不需要改变底层代码。随着互操作性成为支撑架构决策的关键因素,这种移植性不但使 IT 部门能实现应用服务部署的重大突破,还可支持 DevOps 团队实现企业目标。IBM 最近的一份报告2强调,若使用容器进行应用部署,企业能提高应用质量、减少缺陷以及最小化应用停机时间和相关成本。
同一报告还列出了特别适合容器环境的应用,其中包括数据分析、Web 服务以及数据库。这里的关键因素是性能,但还有其他需要考虑的相关因素,包括应用是否可能在多个环境中运行以及它们是否使用微服务以支持多个 DevOps 团队同时工作。有了容器,您可以仅通过启动更多应用实例解决性能问题,但前提是您使用了无状态的架构设计并大规模提供应用服务。
容器并非完全没有部署方面的挑战,而且这项较新的技术还未达到虚拟化的成熟程度。下文强调了容器带来的一些挑战。
图 2 — 实现平衡的容器化
容器化的一个重要设计标准是性能、密度和可靠性这三个向量之间的平衡,如图 2 所示。
F5 的解决之道是专注于组件层面而非系统层面的容器化。这种方法带来了一些优势,其中包括:
组件层面的容器化使我们能够通过分解、调度和编排实现这种三方平衡。此外,启用容器的 F5 产品将使用这些功能最大化容器化的优势。
为支持企业采用基于容器的技术,F5 提供 F5® Container Ingress Services,这是一个开源的容器集成。Container Ingress Services 提供自动化、编排和网络服务,如路由、SSL 卸载、HTTP 路由和强大的安全性。重要的是,它集成了我们的一系列 BIG-IP 服务与原生容器环境(如 Kubernetes 和 Red Hat OpenShift)。
从架构上看,Container Ingress Services 在您的容器化应用中占据以下位置,增加了前门入口控制器服务,并通过 BIG-IP 实现可见性和分析。
图 3 — F5 Container Ingress Services
Container Ingress Services 解决了上文提到的两个关键问题 — 可扩展性和安全性。您可以扩展应用以满足容器工作负载,并通过启用安全服务保护容器数据。通过 BIG-IP 平台集成,您可以在编排环境中实现自助服务应用性能。通过使用 Helm 图表进行基于模板的部署和升级,使用 Container Ingress Services 还可以减少开发人员用默认设置启用 Kubernetes 容器的可能性。
此外,Container Ingress Services 通过先进的容器应用攻击保护和访问控制服务保障安全。对于不熟悉配置的应用开发人员和 DevOps 专业人士,F5 应用服务提供开箱即用的策略和基于角色的访问控制 (RBAC),并提供企业级支持,此外还有 DevCentral 客户和开源社区。
原生 Kubernetes 带来的挑战是开发和扩展现代容器应用而不增加复杂性。这可能会限制性能和可靠性,而且为 Kubernetes 容器提供前门的服务可能实施不一致,因此需要做出更多集成努力以进行部署和配置。
这些挑战的解决方案是 NGINX Kubernetes Ingress Controller,它通过为 Kubernetes 应用提供交付服务,增强了基本的 Kubernetes 环境。通常情况下,Kubernetes Pod 只能与同一集群中的其他 Pod 通信。图 4 表明 Kubernetes 入口控制器从外部网络向 Kubernetes Pod 提供访问路径,并由入口资源规则管理,这些规则控制通用资源标识符 (URI) 路径、后端服务名称和其他配置信息等。可用服务有什么取决于您是使用 NGINX 还是 NGINX Plus。
图 4 — 面向 Kubernetes 的 NGINX Ingress Controller
使用 NGINX 的企业获得的功能包括负载均衡、SSL 或 TLS 加密终端、URI 重写和上游 SSL 或 TLS 加密。NGINX Plus 则带来更多功能,如有状态应用的会话持久性和 JSON Web Token(JWT)API 认证。
随着企业采用微服务以增强开发人员的应变能力和云原生的可扩展性,这些企业正处于学习曲线中,同时企业能力也在为了该技术提升。这些企业希望尽快获益于微服务,同时保持支撑其客户体验的稳定性。
Aspen Mesh 是 Istio 开源服务网格得到充分支持的版本,帮助企业大规模采用微服务和 Kubernetes,并获得微服务架构的可观察性、控制力和安全性。Aspen Mesh 增加了关键的服务网格企业功能,其中包括易于查看和了解以下内容的用户界面:服务状态和健康状况、精细化的 RBAC 以及更易于在容器化应用中驱动所需行为的策略和配置功能。
Aspen Mesh 实现了 Kubernetes 原生,它被部署在您的 Kubernetes 集群中,可以在您的私有云、公有云或本地运行。重要的是,通过使用 Container Ingress Services 预配更深入的第 7 层功能,它可以与基于 F5 的入口机制合作。
从架构上看,Aspen Mesh 可利用一个 Sidecar 代理模型为容器化的应用增加更强功能和更高安全性,如图 5 所示。
图 5 — Aspen Mesh 架构
F5 处于容器应用的最前沿,使企业能运行可靠、安全和高性能的容器化应用环境,这些环境可在简单和大规模的特定行业工作负载中扩展应用服务。容器技术将成为未来应用开发和部署环境的关键推动因素,如无服务器实施、服务网格架构和移动边缘安全。F5 公司利用自身对容器的研发和商业实现推动和开发应用和服务,从而为您的企业带来变化。
与现有产品的虚拟化一样,我们采用容器技术的方式对管理员来说可能不是很明显,但对终端用户来说将为完全透明。作为客户,您将看到性能、灵活性和安全性的提高。当我们全方位启用这些新的应用和服务时,您可以专注于确保获得所需功能。
我们也正致力于在产品中采用最好的开源解决方案,以扩展这些开源平台提供的服务和增强容器环境的功能。我们的一贯目标是创造出更可靠、更安全、更易于部署以及更快集成到您现有网络的产品。
为执行我们的容器采用策略,我们正专注于以下方法:
F5 致力于将容器打造成许多未来应用服务技术的基础交付机制。这些技术将包括无服务器、服务网格和移动边缘,还可能包括目前正在开发或尚未设想到的其他方法。我们正在重新设计我们的产品范围,以将容器纳入我们的解决方案,同时不影响有效网络管理的重要方面。
与虚拟化一样,容器本身将变得更加了解其引擎所处硬件的底层功能。对于在容器中运行的应用来说,多线程、内存速度、存储访问和网络将越来越透明,因此可进一步提高资源利用率。
我们认为容器不是虚拟化的替代品,而是对虚拟化的补充。因此,我们希望容器的寿命至少与虚拟化的寿命相当,并且两者将继续共存。最后,我们希望会出现更高抽象级别,这种抽象级别将与虚拟化和容器并存。
我们知道,客户始终关心安全性。因此,F5 将继续利用其在硬件和软件设备、防火墙和网络方面的经验为其所有产品提供最大的安全保障。
总之,除了我们现有的容器相关技术外,F5 计划继续将容器纳入 F5 产品范围,为您提供更多集成选项、更高可靠性、更好性能,并减少更新后的应用和未来应用的部署时间。
有关 F5 和对应用的容器支持的更多信息,请访问 f5.com/solutions/bridge-f5-with-container-environments
1 Bare-Metal Kubernetes 服务器的兴起,Container Journal,Mike Vizard,2019 年
2 基于容器的应用开发现状,IBM 云报告,2018 年
3 错误配置与暴露:容器服务,Palo Alto Networks,Nathaniel Quist,2019 年