对比Kubernetes和OpenShift 2/2

6. A different approach to deployments

像前文Ingress/Router类似,OpenShift选择采用不同的方式管理部署。在Kubernetes中,有Deployment对象(您也可以在OpenShift中使用它们与所有其他Kubernetes对象一起使用)负责以滚动更新方式更新pod,并在控制器内部实现。 OpenShift有一个名为DeploymentConfig的类似对象,不是由控制器实现的,而是由基于专用pod控制整个过程的复杂逻辑实现的。它有一些缺点,但相对Kubernetes Deployment也有一个显著优势 - 你可以使用钩子(Hook)来准备你的环境以进行更新 - 例如通过更改数据库架构。这是一个很难用Deployment实现的功能(不,InitContainers不是一回事,因为它很难与许多运行的实例协调)。但是,在处理多个并发更新时,Kubernetes Deployment更好--DacementConfig根本不支持并发更新,而在Kubernetes中,您可以拥有许多并发更新,并且它将设法正确地扩展它们。

哪一个更好?

OpenShift DeploymentConfig有更多选项并支持ImageStream,所以我选择它来替代传统的Kubernetes Deployment。

7. Better management of container images

这是我在Kubernetes中非常想要的,也是我个人最喜欢的OpenShift功能。 用于管理容器镜像的ImageStreams。 你知道在传统容器注册表中更改镜像的标签(Tag)有多“简单”吗? 如果没有skopeo等外部工具,您需要下载整个镜像,在本地更改并将其推回Registry。 通过更改容器标记和更新Deployment对象定义来提升应用程序也不是一种愉快的方法。 这就是我喜欢ImageStreams的原因,以下是主要原因和特点:

  • 使用ImageStream,您可以上传一个容器镜像,然后在OpenShift内部管理它的虚拟标记(tag) - 在一个项目中,您将始终使用devel标记并仅在内部更改对它的引用,在prod上您将使用stable或prod标记并在内部管理它 在OpenShift中,不需要对注册表进行处理操作!
  • 当使用带有DeploymentConfig的ImageStream时,您可以设置一个触发器(触发器/Hook),当新镜像出现或标签更改其引用时自动开始部署操作 - 它非常适合开发环境,其中app会在构建新版本时自行部署(无需任何CICD操作!)
  • 使用触发器,您可以实现更多 - 当基础镜像发布新版本时,使用链式构建来创建我们的应用程序/工具的更新版本 
  • 您可以通过将镜像曝光为ImageStream来隐藏镜像本身 - 例如 jenkins指向一个原始的官方镜像,当你想要修改一些东西时,你构建自己的,将它推入你的注册表并仅需要更改ImageStream中的引用,而不是像传统的docker镜像那样部署配置

哪一个更好?

OpenShift中的ImageStreams更赞!

8. Integrated CI/CD with Jenkins

Red Hat在创建Kubernetes项目之前很久就创建了OpenShift,从一开始,它就是一个PaaS平台。 通过从他们的自定义解决方案(他们使用称为gears而不是容器的东西)切换到Kubernetes,更容易带来更多功能,其中最令人兴奋的是集成Jenkins。 有多种CI / CD软件解决方案,但Jenkins仍然是最大,使用最广泛,通用和成熟的解决方案。 它还经常与Kubernetes集群一起用于构建容器镜像,对它们执行持续集成任务,并将它们作为容器部署在具有Continuous Deployment管道的多个环境中。 由于它如此受欢迎,因此将其作为OpenShift的内置部分使得整个CI / CD不那么痛苦。 这是我在OpenShift上集成的Jenkins最喜欢的功能列表:

  • OAuth身份验证 - 使用您的OpenShift登录信息登录Jenkins,根据您在项目中的角色,您可以获得三个jenkins角色中的一个(查看,编辑或管理员)
  • 支持源代码到镜像整个生命周期,允许您创建自定义jenkins镜像 —— 一些带有插件列表,自定义配置和其他资源的文件,使您可以在基础镜像更改时轻松更新它(该部分也可以自动化!) 并使用Jekins完全“immutable”模式
  • 提供两个版本的模板 - 用于测试目的的临时版本和持久存储的持久存储,用于更严肃的工作,配置数据和作业历史记录与Jenkins本身分开保存,从而使其易于管理(例如升级,测试不同的插件集)
  • 从正在运行的命名空间同步涉密对象 - 不同的涉密对象与Jenkins凭证同步,以便您的作业中可以使用用户名/密码,ssh密钥或秘密文本,而无需在Jenkins中创建它们
  • 最后但并非也很重要 - 管道定义是一个单独的BuildConfig对象,是在Jenkins之外定义为一个简单的yaml文件中的OpenShift对象

哪一个更好?

再一次,OpenShift的一个附加功能使您可以轻松地使用CI / CD管道部署您的应用程序。

9. OpenShift projects are more than Kubernetes namespaces

这是一个微小的差异,在OpenShift中,projects只不过是具有附加功能的Kubernetes namespace。 除了支持描述和显示名称之类的琐碎事物(相信我 - 当你有几十个它们时它们会很有帮助),projects会添加一些默认对象。 目前,一些角色(精确的角色绑定对象)与project一起创建,但您可以修改默认project模板并使用它来设置其他对象。 一个很好的例子是关闭project以拒绝外部网络访问的网络策略——使得project默认情况下是隔离和安全的 - 如果您想通过明确创建其他策略来允许某种外部网络访问。 以类似的方式,您可以提供默认配额或限制范围对象,并根据您的组织规则预先配置新项目。

哪一个更好?

因为projects仅仅是添加了一些小特性的namespace,谈不上谁更好。

10. OpenShift is easier for beginners

作为最后一部分,我想强调用户体验方面的差异。 容器仍然是非常新的技术,并且其复杂的操作界面、访问接口使得它更难学习和掌握容器技术。 OpenShift版本的命令行和Web界面都要优于Kubernetes版本。

让我们从命令行操作界面开始吧。 在OpenShift上有一个oc命令,相当于Kubernetes的kubectl,但有以下不同之处:

  • oc支持登录到OpenShift集群 - 使用kubectl,您需要获取认证凭据并使用一些外部工具创建kubeconfig文件
  • oc允许你在项目/命名空间之间切换,而kubectl没有(你需要诸如kubens/kubectx之类的外部工具) - 如果你开始使用许多名称空间和集群,你会欣赏这个功能,相信我
  • oc允许您从源构建容器映像,然后使用单个命令将其部署到环境中! (oc new-app)它将为您创建所有必需的对象,然后您可以决定导出它们,更改并重新应用或存储在镜像库中的某个位置

另外,OpenShift的web console使用体验要明显优于Kubernetes dashboard。

总结:

有些人可能会认为我是一个完全的OpenShift粉丝,但实际上,我两个都爱。 毕竟,他们给予可以如此管理我们的容器化应用程序的能力,之前是只有像谷歌这样的独角兽公司才具备的。 因此,无论您选择哪种方式,您都将获得大量功能,让您的生活更轻松,您将进一步的爱上这种原生云世界(DevOps, CD, MicroService ...)。

原文链接: https://cloudowski.com/articles/10-differences-between-openshift-and-kubernetes/

Leave Comment