F5 和容器化

企业时刻面临着一个难题：拥抱技术变革以开辟新的商业机会还是保护企业免受新的挑战和风险影响？在本文中，我们将研究容器化以及 F5 产品采用该技术对 IT 专业人士、架构师和业务决策者的影响。

在过去的 20 年里，虚拟化改变了服务器计算方式，使多个独立的操作系统可在一个硬件平台上运行。如今，有一种更现代的方法，即容器化（或操作系统虚拟化），它使多个应用可在一个主机操作系统的单一实例上运行。此外，每个应用实例共享安装在单个操作系统实例中的二进制文件和库。图 1 对这些方法进行了比较。

与虚拟机 (VM) 不同，容器可共享操作系统，在操作系统层面而非管理程序层面进行虚拟化。

开发人员喜欢容器，这不足为奇，因为容器可使开发和部署应用以及启用微服务变得快速而简单。容器化还能实现更大的可移植性，因为容器中的应用更易于部署到不同的操作系统、硬件平台和云服务。与直接在裸机托管操作系统或虚拟机上运行的应用相比，容器占用的资源更少。

一般来说，大多数关于容器的讨论（和资料）都集中在编程或 DevOps 的角度。作为一名 IT 专业人士、系统架构师或业务决策者，您可能很欣赏容器化带来的灵活性，但也可能确实担心这种变化会对您所处环境中的应用和服务的管理和监控产生影响。您还希望确保容器化不会对网络和应用的安全性造成不利影响。

在竞争日益激烈的市场中，现代 IT 系统必须提供可实现的商业效益。为满足这一要求，IT 部门必须增加他们的应用资本，以设计和建造适用于更多应用的架构，而且这些应用要有更强大的功能和更高的可用性并且更易于集成。

IT 总监面临的挑战是其部门必须在不增加人员的情况下提供更强大的功能。如今生产力的提高不是来自于雇佣更多人，而是来自于技术和自动化的发展，这些技术和自动化能够增加客户可用的应用数量，并且由同样规模的团队管理。

容器部署的简易性带来了进一步挑战。开发人员需要接受教育和指导，以确保他们在创建应用时同时考虑规模和安全性，而 IT 专业人士可帮助他们实现这些产出。在这里，您需要考虑 Kubernetes 和 Docker 等容器平台对生产的影响以及如何避免敏捷性需求导致安全实践差或未考虑生产负载等不良后果。

提供可实现的商业效益的关键因素是最小化价值实现时间。当涉及到插入建议性时，性能和延迟等因素的地位越来越低。因此，如果有两个拥有几乎相同的功能的组件，其中一个性能更高，而另一个更易于集成，企业会倾向于选择更容易与当前环境集成的组件。随着环境愈加复杂，这种偏见可能会持续。

当您想使用容器化等技术时，您需要一种方法来衡量这种新技术带来的价值。影响价值的因素通常包括适用性、功能、投入的精力以及成本。下列等式展示了如何根据这些因素分配相对价值。

在等式中使用的单位并不重要，但要确保将要评估的每个项目单位相同。

这个等式强调了技术必须为全方位集成，熟悉程度（即插入的简易性）可能比一流的功能或性能更重要。因此，当涉及到总价值计算时，投入部署的精力具有平衡效应，这可能导致功能较弱的产品由于易于插入而对客户更具吸引力。

相关例子可以是两个相互竞争的监控解决方案。产品 A 规格很高，有一流的记录和报告，安全性达到军事级别，并且可管理度高。然而，因其专有的命令行界面、对开放标准的支持不足以及缺乏集成功能，产品 A 难以安装。此外，它也比市场上大多数其他产品更昂贵。

相比之下，产品 B 虽然功能远不及其竞品，但仍提供可接受的监控和安全水平。此外，在成本和安装简易性方面，产品 B 比其竞品更有优势。每个产品的分数列表如下，适用性、功能和投入安装的精力方面的评分从 1 到 10，最低为 1，最高为 10。

将这些数字放入上述等式，就会产生表格最下面一行列出的价值。

您可以看到，与其最好的竞品相比，适用性较低、功能较弱的产品 B 投入安装的精力为其五分之一，价格便宜一半，但能带来的价值多两倍。许多企业了解这些需要考虑的因素，并且在采用和部署新技术时，越来越多地将安装和集成的简易性作为一个关键因素。容器化可显著减少投入部署的精力和控制成本，同时还可以保持适用性和功能。

随着应用逐渐在提高商业价值，容器化为以 DevOps 为中心的 IT 实施做法所面临的挑战提供了一个合理的解决方案。容器可与它们所运行的平台以及其他容器隔离，而不产生运行虚拟机的管理费用。开发人员可轻松建立包含所有所需二进制文件和库的应用环境并内置所需的网络和管理设施。容器化也可简化应用测试和部署。

通过大量增加可在服务器上运行的应用实例数量，容器环境可提供比虚拟机更高的资源利用率。由于没有主机和客户操作系统费用，容器环境通过共享操作系统内核更有效地利用了处理器时间和内存空间。容器化还提供了更高的架构灵活性，因为底层平台可以是虚拟机或物理服务器。Red Hat 产品策略¹指出，未来近一半的 Kubernetes 客户在将应用部署到容器中时，会直接在裸机上运行容器引擎。

容器化会带来更多方面的进步，包括基于硬件的计算、虚拟化和多云，进而实现完全自动化、亚秒级的服务创建时间以及可用秒衡量的服务寿命。有了 Docker、OpenShift 和 Kubernetes 等容器环境，我们可在现代 IT 架构中对服务和微服务进行即时预配和移除。

重要的是，容器化提供了一个在如今的多平台和多云世界中至关重要的优势：容器化能将应用从本地移植到云端，再移植到另一个云供应商，然后再次移植回本地，并且都不需要改变底层代码。随着互操作性成为支撑架构决策的关键因素，这种移植性不但使 IT 部门能实现应用服务部署的重大突破，还可支持 DevOps 团队实现企业目标。IBM 最近的一份报告²强调，若使用容器进行应用部署，企业能提高应用质量、减少缺陷以及最小化应用停机时间和相关成本。

同一报告还列出了特别适合容器环境的应用，其中包括数据分析、Web 服务以及数据库。这里的关键因素是性能，但还有其他需要考虑的相关因素，包括应用是否可能在多个环境中运行以及它们是否使用微服务以支持多个 DevOps 团队同时工作。有了容器，您可以仅通过启动更多应用实例解决性能问题，但前提是您使用了无状态的架构设计并大规模提供应用服务。

容器并非完全没有部署方面的挑战，而且这项较新的技术还未达到虚拟化的成熟程度。下文强调了容器带来的一些挑战。

1. 密钥管理 — 容器之间的密钥管理可能会有问题，特别是因为容器的一个主要优势是可移植性。您的密钥管理环境需要能够应对容器在本地主机之间的移动以及往返云端。
2. 网络 — 由于容器可快速启动和关闭，容器给传统网络模型带来了挑战，导致静态网络地址在这样的环境中不可行。尽管动态主机配置协议 (DHCP) 等寻址机制在物理主机和虚拟机上运行良好，但在容器的 IP 地址注意到它以及容器本身能够被发现之前，容器工作负载就可能出现和消失。因此，使用基于容器的软件定义网络 (SDN) 实现与物理网络硬件的分离非常重要，这样您就可以将整个容器拓扑结构从本地迁移到私有和公有云环境。大多数容器环境使用某种形式的容器网络接口 (CNI) 来执行这一功能。
3. 多种容器技术 — 您的企业可能已经在您所处环境实施了几种不同的容器技术。尽管如此，您的员工很可能对所有此类环境缺乏深入的技术理解。培训很重要，它能给您的团队时间以了解这些容器的实施过程。此外，对多种容器技术的管理费用较高。然而，改善可管理性（尤其是最新版 Kubernetes 的可管理性）往往会令企业选择最简单、最常用的环境以进行标准化。
4. 默认配置风险 — 在容器中开发应用的同时，错误配置容器的风险也随之上升。比如说以其默认配置部署容器。Palo Alto³ 的 Unit 42 全球威胁情报部门最近发现，超过 40,000 个独特的容器设备具有默认配置设置。当然，不是所有这些实例都容易被利用，但该报告强调，基本的错误配置做法普遍存在，而且此类企业成为更易受到攻击的目标。

容器化的一个重要设计标准是性能、密度和可靠性这三个向量之间的平衡，如图 2 所示。

F5 的解决之道是专注于组件层面而非系统层面的容器化。这种方法带来了一些优势，其中包括：

• 不把内存分配给未使用的网络功能，减少每个容器的内存占用。
• 最小化对主机 CNI 的依赖，从而避免网络性能问题。
• 启用小型、轻量级的组件，将故障域降低到订阅者/用户级别。

组件层面的容器化使我们能够通过分解、调度和编排实现这种三方平衡。此外，启用容器的 F5 产品将使用这些功能最大化容器化的优势。

为支持企业采用基于容器的技术，F5 提供 F5® Container Ingress Services，这是一个开源的容器集成。Container Ingress Services 提供自动化、编排和网络服务，如路由、SSL 卸载、HTTP 路由和强大的安全性。重要的是，它集成了我们的一系列 BIG-IP 服务与原生容器环境（如 Kubernetes 和 Red Hat OpenShift）。

从架构上看，Container Ingress Services 在您的容器化应用中占据以下位置，增加了前门入口控制器服务，并通过 BIG-IP 实现可见性和分析。

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。

使用 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 所示。