下载掌阅APP，畅读海量书库
立即打开
从最新Kubernetes社区代码贡献的排名可以看出红帽在Kubernetes社区具有重大的影响力，并发挥着举足轻重的作用，如图2-3所示（ https://www.stackalytics.com/cncf?project_type=kubernetes ）。
早期的Kubernetes功能尚弱，红帽的OpenShift补充了大量的企业级功能，并逐渐将这些功能贡献给上游Kubernetes社区，此时，Kubernetes和OpenShift共同成长。随着纳入CoreOS优秀基因的OpenShift的发布，OpenShift的功能特性和健壮性大胜往昔，并进一步推动Kubernetes社区的发展。所以说，OpenShift和Kubernetes是相互推动、相互促进的。接下来，我们具体看一下OpenShift对Kubernetes的一些关键性增强。
图2-3 Kubernetes社区各公司代码提交量分析
Kubernetes是一个开源项目，面向容器调度；OpenShift是企业级软件，面向企业PaaS平台。OpenShift除了包含Kubernetes，还包含很多其他企业级组件，如认证集成、日志监控等。
OpenShift提供企业版和社区版，红帽订阅客户可以使用企业版并获得OpenShift企业级支持。Kubernetes有很多发行版，但由于它是一个社区开源项目，如果遇到技术问题，主要依靠社区或外部专家来解决。
Kubernetes每年发布4个版本，OpenShift通常使用次新版本的Kubernetes为最新版本产品的组件，这样保证客户企业级PaaS产品的稳定性。
企业客户通常需要PaaS集群具备租户隔离能力，以支持多应用和多租户。多租户是Kubernetes社区中一个备受争议的话题，也是当时Kubernetes早期版本所欠缺的。
为解决这个问题，红帽在许多关键领域投入了大量资源。红帽推动了Kubernetes RBAC和资源限制Quota的开发，以便多个租户可以共享一个Kubernetes集群，并可以做资源限制。红帽推动了基于Kubernetes角色的访问控制（RBAC）的开发，以便可以为用户分配具有不同权限级别的角色。2015年发布的OpenShift 3.0（基于Kubernetes 1.0）就已经提供了RBAC的功能；而Kubernetes直到1.6版本才正式提供RBAC功能。当年没有RBAC、Quota这些功能的Kubernetes是无法满足企业客户的需求的。
Kubernetes为应用程序提供了诸如Pod、Service和Controller等功能组件，但在Kubernetes 1.0中部署应用程序并实现应用程序版本管理并不是一件简单的事情。红帽在OpenShift 3.0（基于Kubernetes 1.0）中开发了DeploymentConfig，以提供参数化部署输入、执行滚动部署、启用回滚到先前部署状态，以及通过触发器驱动自动部署（BuildConfig执行完毕触发DeploymentConfig）。红帽OpenShift DeploymentConfig中许多功能最终将成为Kubernetes Deployments功能集的一部分，目前OpenShift也完全支持Kubernetes Deployments。
企业客户需要更多安全工具来处理正在部署的应用程序。容器生态系统在容器镜像扫描、签名等解决方案方面已经走过了漫长的道路。但是，开发人员仍在寻找和部署缺乏任何来源且可能不太安全的镜像。Kubernetes通过Pod安全策略来提升安全性。例如我们可以设置Pod以非root用户方式运行。Pod安全策略是Kubernetes中的较新的功能，这也是受OpenShift SCC（安全上下文约束）的启发。
为了真正实现容器镜像的安全，红帽致力于消除单一厂商控制的容器镜像格式和运行时（即Docker）。红帽为Kubernetes开发了CRI-O，这是一个轻量级、稳定且更安全的容器运行时，基于OCI规范并通过Kubernetes CRI集成。目前已经在OpenShift中正式发布。
Kubernetes本身适合无状态的应用运行。但如果企业中大量有状态的应用都无法运行在Kubernetes上的话，Kubernetes的使用场景终将有限。有状态应用在Kubernetes上运行的最基本要求就是数据持久化。为此，红帽创建了OpenShift存储Scrum团队来专注此领域，并为上游的Kubernetes存储卷插件做出贡献，为这些有状态服务启用不同的存储后端。随后，红帽推动了动态存储配置的诞生，并推出了OpenShift Container Storage等创新解决方案。红帽还参与了Kubernetes容器存储接口（CSI）开源项目，以实现Pod与后端存储的松耦合。
Kubernetes 1.0中没有Ingress的概念，因此将入站流量路由到Kubernetes Pod和Service是一项非常复杂、需要手工配置的任务。在OpenShift 3.0中，红帽开发了Router，以提供入口请求的自动负载平衡。Router是现在Kubernetes Ingress控制器的前身，当然，OpenShift也支持Kubernetes Ingress。
Kubernetes本身不包括SDN和虚拟网络隔离，而OpenShift包括集成了OVS的SDN，并实现虚拟网络隔离。此外，红帽还帮助推动了Kubernetes容器网络接口开发，为Kubernetes集群提供了丰富的第三方SDN插件生态系统。目前，OpenShift的OVS支持Network Policy模式，其网络隔离性更强，而且默认使用Network Policy模式，极大提升了容器的网络安全。
OpenShift使用ImageStreams管理容器镜像。一个ImageStream是一类应用镜像的集合，而ImageStreams Tag则指向实际的镜像。
对于一个已经有的镜像，如Docker.io上的Docker Image，如果想在OpenShift中使用Image，则可以通过将Image导入ImageStream中来使用。需要注意的是，我们在将Image导入ImageStream的时候，可以加上--scheduled=true参数，它的作用是当创建好ImageStream以后，ImageStream会定期检查镜像库的更新，然后保持指向最新的Image。
在DeploymentConfig中使用ImageStream时，我们可以设置一个Trigger，当新镜像出现或镜像的Tag发生变化，Trigger会触发自动化部署。这个功能可以帮助我们在没有CI/CD配置的前提下实现新镜像的自动部署。
通过使用ImageStream，我们实现了容器镜像构建、部署与镜像仓库的松耦合。
在介绍OpenShift对Kubernetes的增强以后，接下来介绍OpenShift对Kubernetes生态的延伸。