容器。 它们不是一种时尚,也不是一个阶段。 与前身虚拟化相比,它们的采用速度实际上相当快。 在不到两年的时间里,我们已经看到人们对在容器中部署应用服务的兴趣,这通常表明已经投入生产的应用程序需要规模、安全性和速度来支持当今应用体验的高期望。
有趣的是,容器及其管理和编排框架正在日趋成熟。 虚拟化没有,但虚拟化再次先于云计算,它强制其他敏捷技术采用 API 和模板,从而将云计算的自动化和编排应用于虚拟基础设施。 如今,容器和虚拟化(可以说它们是兄弟技术)通常与编排框架一起部署,该框架用于协调其他应用程序和服务的流量(东西向流量)的配置、扩展甚至路由。
尽管在这些框架领域范围内,这些机制可以很好地提供本地化的规模和路由,但事实上这些应用程序和服务是更大视图的一部分;该视图包括一个更全面的需要与用户交互的“应用程序”(南北流量)。 Portworx 在 2016 年末进行的一项调查发现,计划进行容器化的第二受欢迎的工作负载是“Web 前端”,占受访者的 48%。
这几乎可以保证存在一个上游服务(或者如果你愿意,也可以是设备)在用户和由部署在容器环境中的服务组成的“应用程序”之间提供规模、安全性和速度。
这意味着容器编排框架和上游设备/服务之间应该进行协调。
输入F5 容器连接器。 当我们首次宣布容器连接器时,我们正在对 Mesos 支持进行最后的完善。 今天,我们也很高兴发布对Kubernetes的支持。
F5 容器连接器提供的是连接南北流量与东西流量之间最后一英里内部所需的集成。 在这里,上游(Kubernetes 所在位置)BIG-IP 将请求传递给适当的本地代理(例如,可能是我们自己的application服务代理,或者在 Kubernetes 的情况下是Kube-Proxy )或 pod 进行处理。
然后它等待响应,并执行其自己分配的任务,如数据清理(以防止数据泄露)、图像优化(以提高性能)并将其发送回用户。
关键组件是容器连接器,它驻留在 Kubernetes 集群中并像其他组件一样订阅事件。 当它看到适当的事件时,它会使用适当的详细信息动态配置或修改上游(BIG-IP)配置上的现有配置。 这可能是通过向集群/池添加新成员来实现扩大规模,也可能是缩小规模 — 再次将其取出。
最重要的方面是它是集成的并且自动发生,这意味着在南北入口/出口处一致地应用安全策略,而不会进一步使容器环境复杂化。 它还鼓励使用 SSL/TLS 来保护与用户的应用程序(和 API)流量,通过提供一个管理和维护证书的单点。 这也使得容器化环境免于额外的操作复杂性,这是引入容器及其相关应用程序架构时常见的抱怨。
F5 容器连接器提供的功能是在生产环境中自动配置和管理容器化应用所需的应用服务,而无需对开发和测试中已经存在的环境进行大规模改造(您已经测试过了,对吧?)。 它支持无摩擦部署的概念,并保留了当今对容器化应用至关重要的可移植性概念。
F5 致力于确保应用程序所需的交付和安全服务在各种环境中均可用,无论是容器还是虚拟机,也无论是在云中还是传统环境中。 但我们也致力于使这些服务的配置和管理尽可能简单且轻松,这意味着解决方案可以适应各种架构。
为了支持 DevOps 工具链,我们在https://hub.docker.com/r/f5networks/免费提供了容器连接器和我们的 kube-proxy 版本,您可以从我们的 git 存储库https://github.com/F5Networks/k8s-bigip-ctlr获取我们的 Kubernetes 控制器的开源版本