自年前一周到现在,我基本都在实践openshift, 下面说下我的总结,
现在社区开源的paas平台,目前只有Cloud Foundry和openshift origin两个,前者是vmware开源的,后者是RedHat开源的。
因为openshift的技术栈和我们比较贴近,技术栈:
- docker ->提供进程级别的打包隔离应用的能力
- kuberntees->提供面向集群编排容器的能力
所以我们选择了openshift。
首先,openshift到现在发展了3代产品,第一,二代是自研的,但自2014年 k8s一经推出,redhat就从对外宣称要推出基于k8s的第三代产品,
下面的链接详细的介绍了红帽为什么要选择基于kubernetes推出互不兼容的第三代产品
https://blog.openshift.com/red-hat-chose-kubernetes-openshift/,
总结起来就3点理由:
- google根据内部borg系统开源的,自带了容器面向集群编排的生产特性设计。
- 红帽早期就和google一起合作贡献过内核Cgroups(docker底层依赖)的技术
- k8s是真正的社区引导的,目前不由任何一家公司主导,是CNCF(云原生基金会)管理的
目前红帽是除google外对kubernetes的贡献排名第一。
现在kubernetes已经release到1.5, 今年3月份1.6也会release出来了。k8s自14年发展到现在,能力已不仅仅限于容器编排那么简单了。
但现在kubernetes里的很多概念确实也是从openshift引入进去的,就我知道的有api group,RBAC模型等 ,下面从方方面面对比下k8s和openshift。
运行环境:都支持x86架构
虽然openshift是基于kubernetes,但后者还额外支持arm,ppc,s390等,
当然k8s的这个优势我们是不care的
用户和权限:两者都具备
都有接口和众多认证系统对接,比如ldap,keystone,Oauth2等
授权的话,现在都是RBAC这一套,引入rolebinding和clusterbinding的概念,是openshift贡献给上游的,但目前k8s默认是没有开启的,1.6里就会默认开启了。
易用性上openshift大大的胜出,已经在cli和web console上部分集成了。
理论上,K8s在不做二次开发的情况下,也可以实现openshift的功能,(尚未实践)
项目管理:两者都具备
openshift里有个project的概念,就是基于k8s的namespace加了些注解,
目前两者都可以实现:
基于namespace级别的policy(允许用户能做什么不能做什么)
基于namespace级别的资源配额限制
从易用性上,openshift胜出,其已经集成到cli上了,而k8s目前必须要通过kubect create -f policy.yaml的方式完成
CI&CD: openshift自身集成,k8s要通过第三方实现
目前openshift支持dockerfile,source, jenkins pipeline等方式完成自动编译,自动部署的话,支持人工干预上线(是jenkins pipeline的功能)
openshift还引入了dc的概念,比k8s里的deloyment强大些。
k8s的话,目前第三方案实现有deis,fabric8等
易用性和完成度上,openshift胜出
监控和日志:两者都具备
Kubernetes自身只有heapster项目,可以监控容器基本资源使用和基本的集群状态,应用级监控和告警有第三方prometheus支持,该项目已被列入CNCF(云原生基金会)项目;
目前openshift已集成红帽自家的开源监控方案Hawkular,已集成到web console,该方案支持应用级监控和告警,默认没集成,需要开发调试。
日志方面目前两者都采用efk方案,但openshift已和用户权限结合,用户只能看到自己应用的日志
完成度上openshift胜出
共享存储: 两者都具备
各种接口对接,都具备,目前两者兼容范围很广,包括nfs,ceph RBD, iSCSI等
共享存储业界大都选择ceph,其就是redhat旗下的开源产品。
两者不相上下;
网络SDN:两者都具备
网络部分,k8s社区现在很多支持,主要分为overlay(flannel)和SDN(ovs)两部分
目前openshift的sdn部分是基于ovs+openflow实现的,可以针对project(namespace)实现vxlan级别的隔离,可控制流向和带宽限制等等,当然K8s的networkpolicy也是兼容的;
从集成度上看,openshift胜出,从可选择范围上看,k8s大大的胜出;
生产部署:两者都具备
部署,主要考虑生产级别和调式开发环境搭建,目前两者都有方案支撑;
虽然openshift号称是on top of kuberntes, 但适用于k8s的安装方案,并不适用于前者,openshfit已经耦合进kubernetes了。
调式开发环境,两者都有,一个是minikube和另一个minishift,我自己实践这点,openshift更方便些。
生产环境的话,openshift给出基于ansible的方案,k8s目前有各种方案支撑,比如基于bootkube的自举方式完成部署,基于kops的云上部署方式,我自己也写过基于kubeadm的离线部署的方案
单考虑生产部署的话,k8s胜出;
web console:两者都具备
k8s目前只有dashboard使用,其基本是面向管理员的,基于用户权限管理部分尚在开发中
openshift有自己的web console,集成了监控,ci&cd,用户,存储管理等。
完成度和易用性好,openshift胜出
应用商店(模板):两者都具备
k8s社区采用helm方案,openshfit一开始也是采用这个,后来为了和自有的console界面结合,自搞了一套template,
目前helm是可以兼容openshfit 自有template的。
两者不好评判高低
社区发展: k8s胜出
两者都有自己的社区,但从规模和活跃度上,k8s都远远高于openshift。
openshfit基本会慢于k8s社区1个大版本,比如有状态服务stateful和异地机房federation,现在openshift还不支持,但也在有计划的引入中。
总结:各有利弊。
基于k8s做,方案可选择性更大,各方面都有多种选择,但围绕多租户的方方面面都需要我们统一打通,
比如基于租户的CI&CD,用户只能看到自己的监控告警数据,租户可以自由管理分配给它的空间等等;
基于openshift的话,其提供了完整的caas平台能力,并已开放所有API,可以定制自己的功能,虽号称模块可扩展,但社区活跃度不高,除了默认集成的,其他可选择性不大,如果真要替换某模块的话,只能自己趟坑了。
比如边界路由,openshift默认采用haproxy,如果我们要采用nginx的话,就得自己针对nginx开发适配好openshift原有的API,不然整体完成度就会大打折扣。
所以选择openshift的话,基本就是围绕红帽给出的方案来转。
根据自己的需求来选择,如果你像做个paas平台,那openshfit拿来就用,如果是只是运维部门来做个部署管理,那k8s会更简单些,不会涉及到太多东西。