K8s作为容器编排系统的通用标准呢,K8s的出现促进了PaaS的飞速发展和企业中的落地。基于K8s红帽推出的企业级PaaS平台——OpenShift提供了开箱即用的PaaS功能。
一、OpenShift与K8s的关系
OpenShift与K8s之间的关系可以阐述为OpenShift因K8s而重生,K8s因OpenShift走向企业级PaaS平台。
容器运行时接口OCI标准提出以后,红帽考虑到K8s在企业中的应用,专门为K8s做了一个轻量级的容器运行时,决定重用了runC等基本组件来启动容器,并实现了一个最小的CRI称为CRI-O,CRI-O是CRI的一种标准实现。
红帽OpenShift最新的调用架构:
- K8s master
- Kubelet
- CRI-O
- runC
- Linux kernel
采用CRI-O运行时OpenShift对底层的调用链路更短、效率更高、稳定性更强。CRI-O的运行不依赖于守护进程,即使OpenShift节点上的CRI-O的Systemed进程终止,所有运行的Pod也不受影响。
详细的调用流程:
- K8s要启动一个Pod,所以调用CRI
- 配置K8s实例来使用cri-o,调用cri-o daemon
- cri-o使用/container/image和/container/storage库来拉取镜像并在磁盘上管理它们
- cri-o守护进程使用/container/image库来从一个registry中拉取一个容器镜像
- cri-o守护进程启动一个OCI兼容运行时runc来运行容器进程
- runc启动在容器镜像中使用文件containerd的容器,并通过告诉Linux Kernel来启动适当的namespace、cgroup中的进程
二、OpenShift发展简史
基于K8s 1.0的OpenShift 3.0,构建中三大强有力的支柱上:
- Linux:红帽RHEL作为OpenShift3基础,保证了基础架构的稳定性和可靠性。
- 容器:提供高效、不可变和标准化的应用程序打包,实现跨混合云环境的应用程序可移植性。
- K8s:提供强大的容器编排和管理功能,并成为过去十年中发展最快的开源项目之一。
企业通常对PaaS平台的安全性、可操作性、兼容性等有复杂的要求,K8s的原生功能很难满足这些需求。为此,在过去几年的时间里,红帽在K8s和其周边社区投入了大量的精力。
红帽收购CoreOS公司,在随后一年的时间里,红帽将CoreOS优秀的功能和组件迅速融合到OpenShift中。
三、OpenShift对K8s的增强
红帽的OpenShift补充了大量的企业级功能,并逐渐将这些功能贡献给上游的K8s社区,K8s与OpenShift共同成长。
1.稳定性的提升:
- OpenShift除了包含K8s,还包含很多其他企业级组件,如认证集成、日志监控等。
- K8s每年发布4个版本,OpneShift通常使用次新版本的K8s为最新版本产品的组件,这样保证客户企业级PaaS产品的稳定性。
2.OpenShift实现了一个集群承载多租户和多应用:
- 企业客户通常需要PaaS集群具备租户隔离能力,以支持多应用和多租户。
- 红帽推动力K8s RBAC和资源限制Quota的开发,以便多个租户可以共享一个K8s集群,并可以做资源限制。
- 红帽推动了基于K8s角色的访问控制(RBAC)的开发,以便可以为用户分配具有不同权限级别的角色。
- K8s直到1.6版本才正式提供RBAC功能。
3.OpenShift实现了应用程序的简单和安全部署:
- 红帽在OpenShift3.0中开发了DeploymentConfig,以提供参数化部署输入、执行滚动部署、启用回滚到先前部署状态,以及通过触发器驱动自动部署(buildConfig执行完毕触发DeploymentConfig)。
- 红帽OpenShift DeploymentConfig中许多功能最终将成为K8s Deployment功能集的一部分,目前OpenShift也完全支持K8s Deployment。
- K8s通过Pod安全策略来提升安全性。可以设置Pod以非root用户方式运行。Pod安全策略是K8s中较新的功能,这也是受OpenShift SCC(安全上下文约束)的启发。
4.OpenShift帮助K8s运行更多类型的应用负载:
- K8s本身适合无状态的应用运行。有状态应用在K8s上运行的最基本要求就是数据持久化。
- 红帽推动了动态存储配置的诞生,并推出了OpenShift Container Storage等创新解决方案。
- 红帽还参与了K8s容器存储接口(CSI)开源项目,以实现Pod与后端存储的松耦合。
5.OpenShift实现应用的快速访问:
- 在OpenShift3.0中,红帽开发了Router,以提供入口请求的自动负载均衡。Router是现在K8s Ingress控制器的前身,当然,OpenShift也支持K8s Ingress。
- K8s本身不包括SDN和虚拟网络隔离,而OpenShift包括集成了OVS的SDN,并实现虚拟网络隔离。
- 红帽还帮助推动了K8s容器网络接口开发,为K8s集群提供了丰富的第三方SDN插件生态系统。
- 目前,OpenShift的OVS支持Network Policy模式,其网络隔离性更强,而且默认使用Network Policy模式,极大提升了容器的网络安全。
6.OpenShift实现了容器镜像的便捷管理:
- 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对K8s生态的延伸
OpenShift对K8s生态的延伸主要体现在七个方面,接下来分别介绍这七个方面。
1.OpenShift实现了与CI/CD工具的完美集成:
- 目前OpenShift Pipeline默认使用Tekton。Tekton是一个功能强大且灵活的K8s原生开源框架,用于创建持续集成和交付CI/CD。通过抽象底层实现细节,用户可以跨多云平台和本地系统进行构建、测试和部署。
- Tekton将许多K8s自定义资源CR定义为构建块,这些自定义资源是K8s的扩展,允许用户使用Kubectl和其他K8s工具创建这些对象并与之交互。
- 虽然OpenShift默认使用Tekton实现Pipeline,但OpenShift会继续发布并支持与Jenkins的集成。OpenShift与Jenkins的集成,体现在以下几个方面:
- 统一认证:OpenShift和部署在OpenShift中的Jenkins实现了SSO。根据OpenShift用户在Project中的角色,可以自动映射与之匹配的Jenkins角色(view、edit或admin)
- OpenShift提供四个版本的Jenkins:默认已经提供了一键部署Jenkins的四个模版。
- 自动同步Secret:在同一个项目中,OpenShift的Secret与Jenkins凭证自动同步,以便Jenkins可以使用用户名/密码、SSH密钥或Secret文本,而不必在Jenkins中单独创建。
- Pipeline的集成:可以在Jenkins中定义Pipeline来调用OpenShift API,完成一些应用构建和发布等操作。
2.OpenShift实现开发运维一体化:
- 在监控方面,Prometheus成为默认的监控工具,提供了原生的Prometheus监控、警报和集成的Grafana仪表板。
- 在运维管理方面,OpenShift将CoreOS Tectonic控制台的功能完全融入OpenShift中,提供运维能力很强的Cluster Console。
- 操作系统CoreOS作为OpenShift的宿主机操作系统。
- 将Operator作为集群组件和容器应用的部署方式。
- Quay正在与OpenShift进行最后的集成。后面OpenShift的Docker Registry可以由Quay替代。
3.OpenShift实现有状态应用的全生命周期管理:
- CoreOS推出了在K8s上管理应用的新方式——Operator。Operator扩展了K8s API,可以配置和管理复杂的、有状态应用程序的实例。
- 在K8s上运行复杂的有状态应用程序(如数据库、中间件和其他服务)通常需要特定于该应用领域的知识。Operator允许将领域知识编程到代码中,以便使每个应用能够自我管理。主要利用K8s API和声明性管理功能来实现这一目标。
- Operator可以实现跨混合云的应用生命周期统一管理。
- OpenShift提供一个非常方便的容器应用商店:OperatorHub。OperatorHub提供了一个Web界面,用于发现和发布遵循Operator Framework标准的Operator。开源Operator和商业Operator都可以发布到OperatorHub。
4.OpenShift实现了对IaaS资源的管理:
- K8s虽然对运行在其上的容器化应用有较强的管理能力,但K8s缺乏对K8s下的基础设施进行管理的能力。
- 为了实现PaaS对基础架构的管理,OpenShift引入Machine API,通过配置MachineSet实现IaaS和PaaS统一管理。
- 当OpenShift集群性能不足的时候,自动将基础架构资源加入OpenShift集群中。
5.OpenShift实现集群实时更新:
- 按照K8s集群后,一个重大挑战是保持最新状态。
- OpenShift集群能够连接到红帽官网,这样客户可以收到有关新版本和关键更新自动通知,OpenShift集群仍然可以从本地镜像仓库下载和安装相同的更新。
- OpenShift的主机操作系统基于CoreOS,将提供平滑升级能力。
6.OpenShift通过Istio实现新一代微服务架构:
- 红帽为上游Istio社区作出贡献,并在OpenShift上发布企业级Istio。
- Istio通过Envoy为服务添加轻量级分布式代理来管理对服务的请求。
- 在OpenShift4.2上的Red Hat Istio已经正式发布。
7.OpenShift实现Serverless:
- Knative是一种支持K8s的Serverless架构。基于OpenShift实现开放的混合无服务器功能FaaS。