F5与容器化
简介
组织始终需要在拥抱技术变革以开拓新商机与保护业务免受新挑战和风险影响之间寻求平衡。本文将探讨容器化，以及F5产品采用这项技术对IT专业人员、架构师和业务决策者的影响。
过去20年来，虚拟化技术改变了服务器计算，使多个相互独立的操作系统能够在同一个硬件平台上运行。容器化（或操作系统虚拟化）是一种更现代的方法，可让多个应用在主机操作系统的单个实例上运行。每个应用实例共享该操作系统实例中安装的二进制文件和库。图1对这些方法进行了比较。
与虚拟机（VM）不同，容器可以共享同一操作系统，并在操作系统层而非虚拟机监控程序层实现虚拟化。
开发人员青睐容器并不意外，因为容器可以让应用开发和部署以及微服务启动变得快捷、轻松。容器化还能提高可移植性，使容器中的应用更易于部署到不同的操作系统、硬件平台和云服务。与直接在裸机操作系统或虚拟机上运行的应用相比，容器占用的资源更少。
通常，有关容器的讨论（及文档）大多侧重于编程或DevOps视角。作为IT专业人员、系统架构师或业务决策者，您在认可容器化所带来灵活性的同时，可能也会切实担忧这一变化将如何影响所在环境中应用和服务的运维、管理与监控。此外，您还希望确保容器化不会对网络和应用安全造成不利影响。
应对现代IT挑战
在竞争日益激烈的市场中，现代IT系统必须带来切实可见的业务效益。为满足这一要求，IT部门必须能够扩大应用资本，设计和构建相应架构，不仅容纳更多应用，还要让应用具备更强的功能、更出色的易用性，并且更易于集成。
IT主管面临的挑战是，部门必须在不增加人员编制的情况下提供更强大的功能。如今，生产力的提升不再依靠增聘人员，而是依靠技术进步和自动化，让规模不变的团队能够管理更多面向客户的应用。
容器部署的便捷性也带来了新的挑战。开发人员需要接受培训和指导，以确保在创建应用时兼顾扩展能力和安全性；IT专业人员可以帮助他们实现这些目标。为此，需要考虑Kubernetes和Docker等容器平台对生产环境的影响，并确保敏捷性需求不会因安全实践不当或未考虑生产负载而导致不良后果。
Kubernetes是一个用于管理容器化服务和工作负载的开源平台。Kubernetes最初是Google的容器调度和编排系统，后来由Google捐赠给云原生计算基金会（Cloud Native Computing Foundation），向所有人开放源代码。Docker提供类似的开源架构和分发方式，由一套相互关联的软件即服务（SaaS）和平台即服务（PaaS）组成。
计算价值实现时间
要实现切实的业务收益，缩短价值实现时间是关键因素。与轻松部署相比，性能和延迟等因素的重要性日益降低。因此，如果两个组件的功能几乎相同，但一个性能更高，另一个更易于集成，组织往往会选择更容易与当前环境集成的组件。随着环境复杂性增加，这一倾向可能会持续。
确定价值
在考虑实施容器化等技术时，需要采用某种方法来衡量这种新方法带来的价值。影响价值的因素通常包括适用性、能力、投入和成本。以下公式举例说明了如何根据这些因素确定相对价值。
公式中使用什么单位并不重要，重要的是对每个评估项使用相同的单位。
该等式表明，技术必须能够无缝集成，而熟悉度（即易于引入现有环境）可能比出色的功能或性能更重要。因此，在计算整体价值时，部署工作量会起到平衡作用。这可能导致功能较弱的产品因更易于引入而对客户更具吸引力。
这种影响可能体现在两款相互竞争的监控解决方案上。产品A的规格十分出色，日志记录和报告功能尤为突出。它采用军用级安全机制，并且易于管理。但遗憾的是，其专有命令行界面、对开放标准支持不足以及缺少集成功能，导致安装困难。此外，它的价格也高于市场上的大多数其他产品。
相比之下，产品B的功能远不及竞争对手，但仍能提供可接受的监控和安全水平。不过，在成本和安装便捷性方面，它的得分高于竞品。将各产品的评分汇总后得到下表，其中适用性、功能和安装工作量均按1至10分评分，1分最低，10分最高。
将这些数字代入上述公式，即可得出表格最后一行所列的价值评分。
可以看出，与同类优选产品相比，这款适用性和功能较弱的产品安装难度仅为其五分之一，价格仅为其一半，预计可带来约3倍的价值。许多组织已认识到这些因素，并在采用和部署新技术时，越来越多地将安装和集成的便捷性作为关键考量因素。基于容器的方法可显著减少部署工作量并控制成本，同时保持适用性和功能。
为什么容器越来越受欢迎？
随着应用日益成为业务价值的驱动力，容器化为以DevOps为核心的IT实施实践所面临的挑战提供了合理的解决方案。容器既能与其运行平台隔离，也能彼此隔离，同时无需承担运行虚拟机所带来的管理开销。开发人员可以轻松启动应用环境，其中包含所需的全部二进制文件和库，并内置必要的网络和管理功能。容器化还可简化应用测试和部署。
基于容器的环境可大幅增加单台服务器上运行的应用实例数量，因此比虚拟机具有更高的资源利用率。容器环境通过共享操作系统内核，无需承担主机和客户机操作系统的双重开销，从而更高效地利用处理器时间和内存空间。底层平台既可以是虚拟机，也可以是物理服务器，因此容器化还能提高架构灵活性。Red Hat Product Strategy1 指出，未来在容器中部署应用的Kubernetes客户中，近一半将直接在裸机上运行容器引擎。
容器化推动计算架构从基于硬件的计算向虚拟化和多云进一步演进，可实现高达100%的自动化、亚秒级服务创建，并将服务生命周期缩短至以秒计。Docker、OpenShift和Kubernetes等容器环境支持在现代IT架构中即时预配和取消预配服务及微服务。
更重要的是，在当今多平台、多云环境中，容器化带来了一项至关重要的优势：无需更改底层代码，即可将应用从本地环境迁移到云端、其他云服务提供商，再迁回本地环境。互操作性是架构决策的重要依据，而这种可移植性有助于IT部门实现应用服务部署的关键里程碑，并支持DevOps团队达成组织目标。IBM近期发布的一份报告2指出，使用容器部署应用还有助于企业提升应用质量、减少缺陷，并尽可能缩短应用停机时间及降低相关成本。
同一份报告还列出了特别适合容器化环境的应用，包括数据分析、Web服务和数据库。性能是其中的关键因素，但还需考虑其他相关因素，例如应用是否可能跨多个环境运行，以及是否使用微服务来支持多个DevOps团队并行工作。使用容器时，只需启动更多应用实例即可解决性能问题，前提是采用无状态架构设计，并能大规模提供应用服务。
容器面临的挑战
容器在部署方面并非毫无挑战，而且这项仍处于发展初期的技术尚未达到虚拟化技术的成熟度。以下部分将重点介绍容器带来的一些挑战。
- 密钥管理：容器之间的密钥管理可能会带来问题，尤其是因为容器的一项主要优势在于可移植性。密钥管理环境需要能够应对容器在本地主机之间迁移，以及迁移到云端后再迁回的情况。
- 网络：容器可以快速启动和停止，这对传统网络模型构成了挑战。因此，静态网络地址在此类环境中并不可行。动态主机配置协议（DHCP）等寻址机制虽然适用于物理主机和虚拟机，但容器工作负载可能在其IP地址完成注册、容器本身可被发现之前就已出现并消失。使用基于容器的软件定义网络（SDN）与物理网络硬件解耦至关重要，这样才能在本地环境与私有云和公有云环境之间迁移整个容器拓扑。大多数容器环境都会实施某种形式的容器网络接口（CNI）来实现此功能。
- 多种容器技术：贵组织的环境中可能已经实施了多种不同的容器技术。即便如此，员工也可能并未深入了解所有这些环境。因此，培训非常重要，同时还应给团队留出时间来熟悉这些不同的容器实施方案。管理多种容器技术也会增加成本。不过，随着可管理性不断改进，尤其是最新Kubernetes版本在这方面的提升，组织往往会逐步统一采用最易用且使用最广泛的环境。
- 默认配置风险：随着应用在容器中开发，容器配置错误的风险也随之上升。例如，使用默认配置部署容器。Palo Alto的Unit 42全球威胁情报3 近期发现了超过40,000台采用默认配置的独立容器设备。当然，并非所有这些实例都存在可被利用的漏洞，但这表明基本配置错误十分普遍，并使这些组织成为进一步攻击利用的目标。
均衡的容器化
如图2所示，容器化的一项关键设计标准是在性能、密度和可靠性这三个维度之间取得平衡。
F5的方法侧重于组件级而非系统级的容器化。这种方法具有多项优势，包括：
- 不为未使用的网络功能分配内存，从而减少每个容器的内存占用。
- 尽量减少对主机CNI的依赖，从而避免网络性能问题。
- 实施小型轻量级组件，将故障域缩小到订阅者或用户级别。
组件级容器化通过解耦、调度和编排实现这三方面的平衡。采用容器的F5产品将利用这些功能，充分发挥容器化的优势。
F5 Container Ingress Services
为支持组织采用容器技术，F5提供F5® Container Ingress Services，这是一款开源容器集成解决方案。Container Ingress Services提供自动化、编排和网络服务，包括路由、SSL卸载、HTTP路由和强大的安全防护。更重要的是，它将F5的一系列BIG-IP服务与Kubernetes和Red Hat OpenShift等原生容器环境集成。
从架构角度看，Container Ingress Services 与容器化应用之间的位置关系如下：它在应用入口处提供 Ingress 控制器服务，并通过 BIG-IP 实现可观测性和分析。
Container Ingress Services可解决本文前面指出的两个关键问题：可扩展性和安全性。通过启用安全服务，可以扩展应用以满足容器工作负载需求，并保护容器数据。通过集成BIG-IP平台，可以在编排环境中实现应用性能自助服务。Container Ingress Services还可使用Helm图表进行基于模板的部署和升级，从而降低开发人员使用默认设置部署Kubernetes容器的可能性。
此外，Container Ingress Services通过高级容器应用攻击防护和访问控制服务增强安全性。对于不熟悉配置的应用开发人员和DevOps专业人员，F5应用服务不仅提供开箱即用的策略和基于角色的访问控制（RBAC），还提供企业级支持，以及DevCentral客户社区和开源社区。
NGINX Kubernetes Ingress Controller
原生Kubernetes面临的挑战在于，如何在不增加复杂性的情况下开发和扩展现代容器应用。性能和可靠性可能受到限制，而作为Kubernetes容器统一入口的服务在实现方式上可能不一致，因此需要投入更多集成工作才能完成部署和配置。
应对这些挑战的解决方案是NGINX Kubernetes Ingress Controller。该控制器为Kubernetes应用提供交付服务，从而增强基础Kubernetes环境。通常，Kubernetes Pod只能与同一集群中的其他Pod通信。图4显示了Kubernetes Ingress Controller如何让外部网络访问Kubernetes Pod。此访问由Ingress资源规则管理，这些规则可控制通用资源标识符（URI）路径、后端服务名称及其他配置信息等要素。可用服务取决于使用的是NGINX还是NGINX Plus。
使用NGINX的企业可获得负载均衡、SSL或TLS加密终止、URI重写以及上游SSL或TLS加密等功能。NGINX Plus还提供其他功能，例如为有状态应用提供会话持久性，以及使用JSON Web Token（JWT）进行API身份验证。
Aspen Mesh
随着组织采用微服务来提升开发敏捷性和云原生可扩展性，在组织能力逐步跟上技术发展的过程中，需要经历一定的学习适应期。这些组织希望快速发挥微服务的优势，同时保持支撑客户体验的稳定性。
Aspen Mesh是开源Istio服务网格的全支持版本，可帮助企业大规模采用微服务和Kubernetes，并获得对微服务架构的可观测性、控制能力和安全性。Aspen Mesh增加了关键的企业级服务网格功能，包括便于直观呈现和了解服务状态及运行状况的用户界面、细粒度RBAC，以及可帮助容器化应用实现预期行为的策略和配置功能。
Aspen Mesh提供Kubernetes原生实现，可部署在Kubernetes集群中，并可在私有云、公有云或本地环境中运行。更重要的是，它可与基于F5的入口机制协同工作，并使用Container Ingress Services配置更深入的第7层功能。
从架构上看，Aspen Mesh采用边车代理模型，为容器化应用增强功能和安全性，如图5所示。
F5与容器采用
F5积极推动容器应用，帮助组织运行可靠、安全且高性能的容器化应用环境，并可针对从简单到大规模的行业特定工作负载扩展应用服务。容器技术将成为未来应用开发和部署环境的关键推动因素，例如无服务器实施、服务网格架构和移动边缘安全。F5通过自身的研发和容器商业化实施，推动并开发能够为业务创造价值的应用和服务。
与现有产品的虚拟化类似，我们采用容器技术的方式可能不会立即被管理员察觉，但对最终用户而言完全透明。客户将获得更高的性能、灵活性和安全性。随着我们无缝实施这些新应用和服务，您可以专注于确保具备所需的功能。
我们还在努力将优质的开源解决方案融入产品，扩展这些开源平台提供的服务，并增强容器环境的功能。我们的目标始终是打造更易于部署、能更快集成到现有网络中，并且更加可靠、安全的产品。
为实施容器采用战略，我们将重点采取以下方法：
- 扩展我们提供的非安全类应用服务。重点是提供更完善的工具，以提高容器环境的可观测性和可管理性，包括应用性能管理、日志记录与跟踪、增强型调试以及应用整体运行状况监控。
- 为容器添加非面向数据平面的安全服务。我们计划通过提供可缩小运行中容器攻击面的安全服务来实现创新。
- 支持在F5产品中托管第三方容器。通过此集成选项，客户开发或第三方提供的应用可在当前及未来F5产品的灵活容器运行时接口中运行。借助这种方式，F5可创建包含各种现成或定制开发的容器和应用的交钥匙解决方案，从而显著提升互操作性。
- 使用开源工具封装现有应用服务。借助此选项，F5可以在旧有环境与新建环境之间提供一致的服务策略。
- 实现容器应用扩展和安全服务自动化，在增加纳管应用数量的同时，控制为其分配的支持资源。
容器的未来
F5致力于推动容器成为众多未来应用服务技术的基础交付机制。这些技术将包括无服务器、服务网格和移动边缘，也可能包括目前仍在开发中或尚未构想出的其他方法。我们正在重新设计产品组合，将容器融入解决方案，同时不影响有效网络管理的关键要素。
与虚拟化类似，容器本身将能更好地感知运行容器引擎的底层硬件能力。每个容器中运行的应用将越来越无需关注多线程、内存速度、存储访问和网络连接等底层细节，从而进一步提高资源利用率。
我们并不认为容器会取代虚拟化，而是对虚拟化形成补充。因此，我们预计容器的生命周期至少会与虚拟化一样长，两者将继续共存。最后，我们预计还会出现更高层次的抽象，并与虚拟化和容器共存。
我们深知，安全始终是客户重点关注的问题。因此，F5继续利用在硬件和软件设备、防火墙及网络领域积累的经验，为旗下所有产品提供尽可能严密的安全防护。
总之，除现有的容器相关技术外，F5还计划继续将容器整合到F5产品系列中，为更新版及未来的应用提供更多集成选项、更高的可靠性、更出色的性能，并缩短部署时间。
要详细了解F5及其对应用容器的支持，请访问f5.com/solutions/bridge-f5-with-container-environments
脚注
1 裸机Kubernetes服务器的兴起，《Container Journal》，Mike Vizard，2019年
2 基于容器的应用开发现状，IBM Cloud报告，2018年
3 配置错误与暴露：容器服务，Palo Alto Networks，Nathaniel Quist，2019年
发布于2022年6月23日