F5 与容器化

组织不断在拥抱技术变革以开拓新的商业机会与保护业务免受新的挑战和风险之间挣扎。 在本文中，我们将研究容器化以及 F5 产品中采用该技术如何影响 IT 专业人员、架构师和业务决策者。

在过去的 20 年里，虚拟化改变了服务器计算，使得多个独立的操作系统能够在一个硬件平台上运行。 一种更现代的方法是容器化（或操作系统虚拟化），它允许多个应用程序在主机操作系统的单个实例上运行。 然后，每个应用程序实例共享安装到单个操作系统实例中的二进制文件和库。 图 1 比较了这些方法。

与虚拟机 (VM) 不同，容器可以共享相同的操作系统，在操作系统级别而不是虚拟机管理程序级别进行虚拟化。

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

一般来说，关于容器的大部分讨论（和文档）都集中在编程或 DevOps 的角度。 作为 IT 专业人员、系统架构师或业务决策者，虽然您欣赏容器化可以带来的灵活性，但您可能真正担心这种变化将如何影响您环境中的应用程序和服务的管理、管理和监控。 您还希望确保容器化不会对网络和应用程序安全产生不利影响。

在竞争日益激烈的市场中，现代 IT 系统必须提供可实现的商业利益。 为了满足这一要求，IT 部门必须增加其应用资本，设计和创建的架构不仅要具有更多的应用程序，还要具有更强大功能、增强可用性和更易于集成的应用程序。

IT 主管面临的挑战是他们的部门必须在不增加员工数量的情况下提供更强大的功能。 现在，生产率的提高不是来自于雇佣更多的人，而是来自于技术和自动化的进步，这使得在同样规模的团队的管理下，可以增加可供客户使用的应用程序数量。

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

实现可实现的商业利益的一个关键因素是尽量缩短价值实现时间。 相对于插入的简易性，性能和延迟等因素越来越被置于次要地位。 因此，如果您有两个组件，它们具有几乎相同的功能，但一个具有更高的性能而另一个更易于集成，那么组织倾向于选择更容易与当前环境集成的组件。 随着环境复杂性的增加，这种偏见可能会持续下去。

当寻求实施诸如容器化之类的技术时，您需要某种方法来衡量这种新方法带来的价值。 影响价值的因素通常包括适用性、能力、努力和成本。 下面的等式给出了如何根据这些因素分配相对值的一个例子。

您在等式中使用的单位无关紧要；重要的是，它们对于您评估的每个项目都是相同的。

这个等式强调了技术必须无缝集成，并且熟悉度（即易于插入）比一流的功能或性能更重要。 因此，在总体价值计算方面，部署工作具有平衡效应，这可能导致功能较差的产品由于易于插入而对客户更具吸引力。

这种影响的一个例子可能是两个相互竞争的监控解决方案。 产品 A 具有出色的规格，并具有一流的日志记录和报告功能。 它采用了军用级安全性并且易于管理。 不幸的是，其专有的命令行界面、对开放标准的支持不佳以及缺乏集成功能导致安装困难。 它也比市场上大多数其他产品更贵。

相比之下，产品 B 的功能远不及其竞争对手，尽管仍提供可接受的监控和安全水平。 然而，在成本和安装简易性方面，它比竞争产品更胜一筹。 将每种产品的分数汇总到下表中，其中适用性、能力和安装工作量得分从 1 到 10，1 为最低分，10 为最高分。

将这些数字代入上面的公式中，就会得出表格底行列出的价值分数。

您可以看到，与同类最佳产品相比，这款产品虽然不太合适，但功能却不那么强大，安装起来却容易五倍，价格只有其一半，但价值却预计是其三倍。 许多组织了解这些考虑因素，并在采用和部署新技术时越来越多地将安装和集成的简易性作为关键因素。 基于容器的方法可以显著减少部署工作量和控制成本，同时还能保持适用性和能力。

随着应用程序日益推动商业价值，容器化为以 DevOps 为中心的 IT 实施实践的挑战提供了合理的解决方案。 容器与其运行的平台以及彼此之间提供了隔离，而无需运行虚拟机的管理开销。 开发人员可以轻松启动包含他们需要的所有二进制文件和库的应用程序环境，并内置所需的网络和管理设施。 容器化还简化了应用的测试和部署。

基于容器的环境通过大规模扩展可在服务器上运行的应用实例数量，提供了比虚拟计算机更高的资源利用率。 容器环境无需承担主机和客户操作系统的开销，通过共享操作系统内核，可以更有效地利用处理器时间和内存空间。 容器化还提供了更多的架构灵活性，因为底层平台可以是虚拟机或物理服务器。 红帽产品战略¹这表明未来将应用部署到容器中的 Kubernetes 客户中，将有近一半的人直接在裸机上运行容器引擎。

容器化实现了从基于硬件的计算到虚拟化再到多云的下一步发展，实现了高达 100% 的自动化、亚秒级的服务创建时间和以秒为单位的服务生命周期。 Docker、OpenShift 和 Kubernetes 等容器环境支持在现代 IT 架构中即时配置和取消配置服务和微服务。

重要的是，容器化提供了在当今的多平台和多云世界中至关重要的关键优势 - 能够将应用程序从本地移植到云，再移植到另一个云供应商，然后再移植回本地，而所有这些都无需更改底层代码。 由于互操作性是支撑架构决策的关键因素，这种可移植性使 IT 部门能够实现应用服务部署的关键里程碑，并支持 DevOps 团队实现组织目标。 IBM 最近的一份报告²强调了使用容器进行应用程序部署如何使公司能够提高应用程序质量，减少缺陷并最大限度地减少应用停机时间和相关成本。

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

容器并非完全没有部署挑战，并且这项尚属年轻的技术尚未达到虚拟化的成熟水平。 以下部分重点介绍容器带来的一些挑战。

1. 密钥管理——容器之间的密钥管理可能存在问题，特别是因为容器的主要优点是可移植性。 您的密钥管理环境需要能够应对本地主机之间以及云和云端之间容器的移动。
2. 网络——由于容器的启动和关闭速度很快，因此对传统的网络模型提出了挑战。 因此，静态网络地址在这样的环境中将无法工作。 尽管动态主机配置协议 (DHCP) 等寻址机制可以很好地与物理主机和虚拟机配合使用，但容器工作负载可能会在容器的 IP 地址可以注册并且容器本身可以被发现之前出现和消失。 通过使用基于容器的软件定义网络 (SDN) 与物理网络硬件分离至关重要，这样您才能将整个容器拓扑从本地迁移到私有云和公共云环境。 大多数容器环境都实现某种形式的容器网络接口（CNI）来执行此功能。
3. 多种容器技术——您的组织可能已经在您的环境中实施了几种不同的容器技术。 即使有了这些实现，您的员工可能仍然缺乏对所有这些环境的深入技术理解。 培训很重要，让您的团队有时间熟悉这些不同的容器实现也很重要。 这些多种容器技术的管理也更加昂贵。 然而，可管理性的改进，特别是最新的 Kubernetes 版本，往往会导致组织在最简单和最常用的环境上进行标准化。
4. 默认配置风险——由于应用程序是在容器中开发的，因此容器配置错误的风险会增加。 一个例子是按照默认配置部署容器。 帕洛阿尔托的 Unit 42 全球威胁情报³最近发现了超过 40,000 个具有默认配置设置的独特容器设备。 当然，并非所有这些情况都容易受到利用，但它突显出基本的错误配置做法十分普遍，并使这些组织成为进一步利用的目标。

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

F5 的方法是专注于组件级而不是系统级的容器化。 这种方法有几个优点，包括：

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

组件级容器化使我们能够通过分解、调度和编排实现三方平衡。 实施容器的 F5 产品将使用这些功能来最大限度地发挥容器化的优势。

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

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

容器入口服务解决了本文前面确定的两个关键问题——可扩展性和安全性。 您可以通过启用安全服务来扩展应用程序以满足容器工作负载并保护容器数据。 通过 BIG-IP 平台集成，您可以在编排环境中实现自助服务应用程序性能。 使用容器入口服务还可以通过使用 Helm 图表进行基于模板的部署和升级来降低开发人员使用默认设置实现 Kubernetes 容器的可能性。

此外，Container Ingress Services 还通过先进的容器应用攻击保护和访问控制服务实现安全性。 对于不熟悉配置的应用开发人员和 DevOps 专业人员，除了 DevCentral 客户和开源社区外，F5应用服务还提供具有企业级支持的开箱即用策略和基于角色的访问控制 (RBAC)。

与原生 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是开源Istio服务网格的完全支持版本，可帮助企业大规模采用微服务和 Kubernetes，并获得微服务架构的可观察性、控制力和安全性。 Aspen Mesh 增加了关键的服务网格企业功能，包括一个用户界面，可轻松可视化和了解服务的状态和健康状况、细粒度的 RBAC 以及策略和配置功能，可更轻松地在容器化应用中驱动所需的行为。

Aspen Mesh 提供了 Kubernetes 原生实现，部署在您的 Kubernetes 集群中，可以在您的私有云或公共云或本地运行。 重要的是，它可以与基于 F5 的入口机制协同工作，使用容器入口服务来提供更深层次的第 7 层功能。

从架构上看，Aspen Mesh 利用 sidecar 代理模型为容器化应用添加功能和安全性级别，如图 5 所示。