自年前一周到现在，我基本都在实践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会更简单些，不会涉及到太多东西。
自年前一周到现在，我基本都在实践openshift， 下面说下我的总结，
现在社区开源的paas平台，目前只有Cloud Foundry和openshift origin两个，前者是vmware开源的，后者是RedHat开源的。
因为openshift的技术栈和我们比较贴近，技术栈：
所以我们选择了openshift。
首先，openshift到现在发展了3代产品，第一，二代是自研的，但自2014年 k8s一经推出，redhat就从对外宣称要推出基于k8s的第三代产品,
下面的链接详细的介绍了红帽为什么要选择基于kubernetes推出互不兼容的第三代产品
https://blog.openshift.com/red-hat-chose-kubernetes-openshift/，
总结起来就3点理由：
目前红帽是除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会更简单些，不会涉及到太多东西。