就Kubernetes和OpenShift专访Brian Gracely
近期，德克萨斯州奥斯汀 Kubecon 大会落下帷幕，有 4000 多名工程师参加了会议，Kubernetes 区位于左边、前面和中心的位置。
InfoQ 有幸采访了 Red Hat Openshift 的产品策略主管 Brian Gracely，请他谈了谈，Kubernetes 如何帮助规划产品方向的，以及它与开发人员和架构师有怎样的关联。
Brian Gracely：在 2015 年之前，OpenShift 看起来和大多数其他 PaaS 平台一个（Apprenda、 dotCloud、Cloud Foundry、Heroku 等等），自己构建、非标准化的容器编配。Red Hat 基于经验了解到，在没有广泛的社区支持下，同时创新和维持技术是非常难的。所以当谷歌在 2014 年就 Kubernetes 项目找到 Red Hat 时，我们对能够为这样的项目和社区出力感到非常兴奋。自 2013 年以来，我们已经深度参与进了 docker 项目，所以这是抛离 OpenShift v1 和 v2 中的本土容器技术，变为 OpenShift v3.0 中完全支持 docker 和 Kubernetes 的逻辑上的下一步。Red Hat OpenShift 是支持这些标准的第一个企业级平台，Red Hat 已经成为所有这些项目的第二大贡献者。从那时起，我们就已经深入参与进了 Kubernetes 领导 / 指导小组，以及 Kubernetes 12 名主席或联合主席的特别兴趣小组。我们也是 OCI 项目的最大贡献者，该项目正在标准化容器格式和运行时。
Gracely：Red Hat 为 OpenShift 平台所做的每一件事都始于 Kubernetes 项目，所以整体协同作用是 100%。OpenShift 是 Kubernetes 认证的。从 Kubernetes 中的上流工作开始，我们把工作与其他技术做广泛的集成，包括 SDN 联网、存储、监控、容器注册、Linux 中的容器需求（比如安全性、硬件支持）、持续集成 / 持续交付集成，等等。它就成了 OpenShift Origin 项目。OpenShift Origin 与 Linux 下的 Fedora 项目类似。OpenShift Origin 的商业版既可作为软件（OpenShift 容器 平台, OCP），也可以作为托管服务（OpenShift Dedicated 或 OpenShift Online）。
Gracely：OpenShift 是一个模块化的、可组装的平台。它附带了默认的能力，也允许客户或技术合作伙伴替换为其他选择（比如，SDN 网络、存储、监控等等）。有 300 多个 OpenShift 合作伙伴提供了 100 多个经过测试的集成。鉴于 OpenShift 在历史上就被作为了一个平台，许多特性经常会先在它身上得以实现，然后才是 Kubernetes 或其他开源项目。例如，基于角色的访问控制（RBAC ）就是先在 OpenShift 实现的，然后才迁移到了 Kubernetes 上。OpenShift 在 Helm 项目之前就有了应用程序模版。在某些情况下，OpenShift 实现将被迁移到 Kubernetes 上（比如 RBAC），还有一些情况是它将增加新的功能（比如 Helm 或 Prometheus）作为 OpenShift 的选项。此外，Red Hat 积极参与了新项目的演进和集成，比如 Istio 或 OpenWhisk 之类的无服务器项目，以及像性能敏感应用之类的新领域。
Gracely：大概至少一半的 OpenShift 客户已经现代化了已有的应用，或者提升并转变应用到 OpenShift 了。比如说：巴克莱银行、德国银行、迪斯尼 / 皮克斯、国际海事卫星组织、科凯国际、美国联合健康集团、天空电视、威瑞森、泰勒斯电信，还有很多很多。分析公司 IDC 确认，这些迁移的投资回报率能为企业带来巨大的价值。
容器和 Kubernetes 提供了许多有价值的概念，适用于任何应用。容器可以提供一种统一的应用打包方式，让其在开发、测试、质保、准生产和生产环境中运行。它们带来了不变性，可简化运维团队处理安全更新的方式。它们还能让你在云环境间进行移植。Kubernetes 和 OpenShift 之类的平台可以跨任意云环境提供统一的、自动化的、可伸缩的环境（比如，多个云环境）。
Gracely：只能支持无状态应用的限制是早期 PaaS 系统客户最不满意的事情了，特别是企业公司。为什么你的应用不能在 Heroku 或 Cloud Foundry 平台上运行，12 要素应用收集了 12 个此中观点。当 OpenShift 迁移到标准容器和 Kubernetes 时，它就不存在这样的 12 个要素了，所以平台能够更加灵活。Red Hat 工程师为 Kubernetes 的存储工作做了大量的贡献，截止 v3.0，我们已经支持了许多类型的持久存储。在后续版本中，不仅会增加多个存储相关的类，还会增强存储容量的动态供给。除了 Kubernetes 存储方面的工作之外，Red Hat 还积极参与了 StatefulSets 的工作。
最容器最大的一个误解是，它们只能用于短生命周期应用中无状态应用。
Gracely：首先，我们看到 OpenShift 生态系统成了 Kubernetes 生态系统。其核心技术使生态系统可以非常地灵活，社区已经在 API 和接口上做了标准化，这为统一集成的新思想成为了可能。它还使我们可以在任何云平台上部署 OpenShift，比如 AWS、 Azure、 GCP、 OpenStack、 VMware、 RHV，以及 bare meta。对于技术合作伙伴、ISV 和向我们提供集成请求的客户，我们有 OpenShift Commons 社区和 OpenShift Primed 项目。Red Hat 已经宣布了与 AWS 和 Azure 的主要合作关系，将他们的技术扩展到 OpenShift(例如服务代理、Windows 容器、MS SQL)，我们在 AWS 和 GCP(以及接下来的 Azure) 上托管了 OpenShift，大家都清楚的是，我们从 Kubernetes 的早期就开始与谷歌工程团队非常密切地合作了。OpenShift 也被用作后端平台技术，为全球的云服务提供商提供动力。OpenShift 在商业上可用于多种消费模式：
OpenShift 容器平台 — 作为软件平台来使用，可以跨任何云部署 (AWS、Azure、GCP、OpenStack、VMware、RHV 和 bare metal)。
OpenShift Dedicated — 作为托管服务 (由 Red Hat 运维) 来使用，提供了一个“私有”云环境。OpenShift Dedicated 可以部署在 AWS 或 GCP 的任何区域（region）中 (Azure 将于 2018 年推出)。
OpenShift Online - 作为适合开发人员的按需环境来用，由 Red Hat 管理。OpenShift Online 同时提供入门级 (免费) 和专业级 (付费)。
关于路线图和下一步做什么，我们不仅在 KubeCon 之前在奥斯丁的 OpenShift Commons 做了随访，还在 Red Hat 峰会上召开了一个公开会议。路线图中优先级较高的事项分为以下领域：
持续集成来自 Kubernetes 社区和 CNCF 基金会项目的更新。
继续扩展可以在 OpenShift 平台上运行的应用程序的宽度 (12 个因素，有状态的，机器学习 / AI，数据库，服务器，高性能计算等等)。最近发布的 RHOAR (Red Hat OpenShift 应用运行时）有助于带来这种扩展。
继续使多个云体验成为可能，简化与公共云服务的集成（比如服务代理）。
继续为平台交付健壮性、多层次安全性，并继续简化在高速变化的软件背景下交付安全环境的方式。
继续交付健壮的开发人员的体验，包括 UI（CLI, GUI, API）和 CI/CD 集成。OpenShift.io 将是这样的一个选择，它将为开发人员提供更简单、更综合的体验。
从北京到上海，从硅谷到西雅图，那些互联网巨头企业具有实战经验的架构师和技术专家是怎样看各种新技术，又是怎样高效地根据不同的情况应用这些新技术的？QCon 北京 2018 现 8 折报名中，看最佳理论和实践结合的体验，有任何问题欢迎咨询购票经理 Hanna，电话：15110019061，微信：qcon-0410。
「细说云计算」是 InfoQ 旗下关注云计算技术的垂直社群，投稿请发邮件到 editors@cn.infoq.com，注明“细说云计算投稿”即可。
相关内容
微信扫码咨询专知VIP会员