OpenStack v.s. Kubernetes
2019-10-30 10:37 云物互联 阅读(855) 评论(0) 编辑 收藏 举报目录
What are the differences with OpenStack and Kubernetes？
| OpenStack | Kubernetes | |
|---|---|---|
| 虚拟化技术 | 计算机虚拟化 | 操作系统虚拟化 |
| 运算单元 | Virtual Machine | Container |
| 云存储服务 | 块存储、对象存储、文件存储 | 块存储 |
| 多租户隔离 | 多租户 | 单租户 |
| 安全隔离性 | 好 | 差 |
| 裸机管理 | 支持 | 不支持 |
| 微服务支撑 | 不支持 | 原生支持 |
| 弹性伸缩维度 | 主机 | Pod |
| 应用编排能力 | 弱 | 强 |
| 业务创新能力 | 低 | 高 |
| 平台运维难度 | 大 | 小 |
Why OpenStack & Kubernetes？
OpenStack 采用的是计算机虚拟化技术，即 VMM Hypervisor，能够提供完整而独立的虚拟机，每个虚拟机都拥有独立的内核，隔离好、安全高。而 Kubernetes 采用的是操作系统虚拟化技术，提供了极其轻量的应用程序运行环境，即 Container，拥有轻量、敏捷、可移植的优势。如果将虚拟化技术实现比作云计算的基因，那么 OpenStack 和 Kubernetes 天生就注定了会走向两个不同的世界，即 IaaS 和 PaaS。在此，笔者希望提醒一下，这个世界并非先有了 OpenStack 再有 IaaS，而是有了 IaaS 之后才有 OpenStack。Kubernetes 亦然。之所以提出这一点是因为，这恰恰说明了 OpenStack 也可以是 PaaS，Kubernetes 亦然。这是两个社区之间必然存在竞争关系的原罪。
值得一提的是，容器虽然拥有 Namespace 的概念，但是更多是限制资源的使用，容器间共享内核，并不是真正意义的多租户。所以在对安全性要求高的应用领域，例如：金融、电信行业，容器技术一直备受挑战。通常的做法是，可以考虑在 Hardware 和容器之间通过增加一层虚拟机来弥补，但 Container on VM 的模式必然存在性能的损耗。所以 OpenStack 基金会一直在大力推动 Kata Containers 的发展，愿望可以在减少虚拟化开销的同时，兼顾容器的性能和隔离性。随着 Kata 的成熟，为容器安全解决方案提供了新的思路。而笔者认为 Kata 更重要的意义在于，它或许，甚至已经成为了促进 OpenStack Foundation 和 CNCF 达成协作的桥梁。这对两个社区未来的发展方向至关重要，OpenStack Summit 向 Open Infrastructure Summit 的蜕变就是一个非常美好的转向。这势必会回避很多 OpenStack 和 Kubernetes 正面碰撞的竞争，更倾向于互补互足，持续发展各自领域的优势。对此，请恕笔者再多说一句闲话，聊技术可以，但请大家不要再讨论 OpenStack 和 Kubernetes 谁生谁死的问题了，实在过于业余。
回到正题，还需要强调的一点是，安全隔离这一问题的范畴可不仅限于计算资源，还要考虑到网络和账户运营的层面。对于后者，在大规模集群或庞大的企业组织结构应用场景中，Kubernetes 可以考虑使用 OpenStack Keystone 完备的权限系统来进行补充。每个 OpenStack Tenant 独立维护自身的 Kubernetes 集群。例如：R&D Tenant、Business Tenant。
而在网络层面，虽然 Kubernetes 提出了很多网络的概念，例如：CNI、Service、DNS、Ingress、Network Policy。但必须承认 Kubernetes 的网络并不贴近传统数据中心的网络基础设施，方案也缺乏灵活，以至于经常受到来自网络基础设施部门的挑战。在他们眼里，网络基础设施平台应该具有 Subnet、 Floating IP 以及在此之上有 DHCP、路由控制、安全组、QoS、负载均衡、域名解析、VPC 等基础网络功能，以至于在此之上构建多租户隔离、多类型网络共存、可伸展性 SDN 网络的愿望。虽然 Kubernetes 的 Calico 网络也可以解决多租户网络隔离的问题，但与数据中心网络发展规划的目标依旧存在距离。这或许就是技术需求和 “真用户核心需求” 的距离。当然，我相信未来随着容器的密度越来越大，必然会出现专门针对容器架构进行优化的网络方案，而不再单存依赖 Linux 网络堆栈的支撑。但就当下而言，Kubernetes 依托于 OpenStack Neutron + Kuryr 来整合两者的网络仍不失为一个好的选择，即解决了嵌套 Overlay 网络的问题，还能够实现容器和容器之间、容器和虚拟器之间的网络直通。
在存储需求的层面，OpenStack 除了提供云主机之外，还可以提供多种类型的云存储服务，例如：块存储、对象存储和文件存储。对此 Kubernetes 则有着完全不同的思考。对于 Kubernetes 而言重要的不是能提供何种存储服务，而是怎么简易的利用好存储资源，继而更好的支撑上层的应用编排。这一点与 Kubernetes 对网络的态度如出一辙，它始终围绕要上层业务思考，而非 IT 资源。单凭 Kubernetes 难以满足企业对云存储服务和网络服务需求的需求。
有失必有得，Kubernetes 自始至终给到笔者的感觉都是一个懂得取舍的智者。Kubernetes 的核心价值始终明确 —— 推动企业的业务创新。未来的业务都会运行在云上，而容器是走向 DevOps、Cloud Native 的标准工具，微服务架构是走向大流量时代的标准软件设计思路。容器改变了应用程序交付的方式，微服务架构改变了应用程序的开发形态。而 Kubernetes 的编排能力以及微服务框架能力，让容器和微服务架构能够落地到业务应用中，加速企业业务创新，快速适应云时代的发展与竞争。这一点是 Kubernetes 之于 OpenStack 而言难以企及的优势，由基因就已经决定了。
退一步回来说，Kubernetes 的优势还是要依托于高可靠的云基础设施的可用性之上。Kubernetes 面向应用层，变革的是业务架构，而 OpenStack 面向资源层，提供了抽象化和自动化的 IT 基础设施，改变的是资源供给模式，是上层平台的强力支撑。在使用容器且集群规模不大的场景中，直接用 Kubenetes 当然可以，但在大规模的集群场景中，不管应用是否只是单存的跑在容器中，都是 OpenStack & Kubernetes 更好。就更不用说当下百花齐放的 5G 时代了。AI、MEC、IoT 将会掀起新的时代潮流，领先的私有云不再仅是虚拟机、容器或裸机，而是我全都要，我又全都可以不要。支持、管理和协调这三种方法的能力是运营效率的关键。具备弹性、韧性（Toughness，AWS 内部一直在强调的关键字）的云计算平台，才是可以经受时代变革洪流的领先的云平台。
诚然，我相信 Kubernetes 就如 OpenStack 的发展历程一般，会度过许多成长过程中的难关和挑战。但同时也可以确定的是，Kubernetes 并不会轻率的、奋不顾身的去挑战 OpenStack 在私有云 IaaS 领域的标准地位，因为 Kubernetes 自身也面临着诸多对手，例如 Serverless、例如 Lambda。Kubernetes 要想全面俘获企业级市场的信任必将经历长期的博弈过程，虚拟机、容器、裸机三种资源提供平台将会长期共存。
当然了，假如你问我 Kubernetes 和 OpenStack 我更喜欢哪一个，那么 Kubernetes 的许多思想和设计理念我认为都是比较先进的，但我们也不能忘记他之所以先进的原因 —— 站在巨人的肩膀上。
上述属于个人观点，碍于能力，仅供参考。写于上海 OpenInfra Summit 之前，希望届时能与大家在现场继续交流。
