kubernetes VS OpenShift浅析
Kubernetes vs OpenShift浅析
古语有云：“知彼知己,百战不殆。不知彼而知己，一胜一负。不知彼，不知己，每战必殆。” 这句话同样也适用于技术体系。无论我们在落地，还是在学习、实践某一项技术，对提供相同功能的体系框架的对比学习，可以使得我们能够快速、全面地去拥抱其生态。
容器技术催生了云原生思潮，云原生生态推动了容器技术发展。从2013 年 docker（container）技术诞生开始，各种各样的集群管理工具及编排系统开始应运而生，早期的Docker machine、Docker Compose集群管理工具，到Docker swarm 、 Kubernetes 、以Apache
Mesos等编排系统，每一次的产品的发展无不推动者技术的革新。
因涉及的面比较广，本文暂不赘述其历史发展，通过下图我们可以了解容器技术的发展历程，以及围绕容器技术而衍生出的生态栈，以“容器编排”为核心，所涉列的体系链路包含容器容器引擎、容器网络、容器存储、容器镜像以及容器运行时等，具体如下所示：
在容器编排生态方面，目前，Kubernetes和OpenShift是我们不能忽视的主要选择。当我们比较两者时，请谨记：它们是可互补。其实，从本质上来说，Kubernetes是OpenShift平台的重要组成部分。此外，由于其强大的功能和可扩展的配置，这两种技术都提供了以下可能性：
- 大规模应用开发
- 管理
- 部署方式
在本文中，我们将试图分析这两个流行的容器编排平台，并探讨它们的根本区别，具体，我们先从Kubernetes和OpenShift的架构拓扑开始。
Kubernetes
针对K8S，我们先看下其集群架构图，以便能够清晰地去了解这个生态，具体如下所示：
由上述架构图可知：Kubernetes 集群可视化分为两个部分：控制平面与计算设备（或称为节点）。每个节点都是其自己的 Linux® 环境，并且可以是物理机或虚拟机。每个节点都运行由若干容器组成的容器集。结合上述的架构图以及官方的描述，Kubernetes集群设计原理主要基于以下3个基本原则：安全性、可扩展性以及易用性。
现在，我们再看下其内部组件图，具体如下所示：
通过上述2副图，我们可以看出：整个K8S生态体系主要包括2大核心部分：控制面板和节点。其余组件都是围绕此部分进行相关活动开展。此处简要地对所涉及的组件进行分析：
控制平面
K8S生态集群的核心，用于控制集群的 Kubernetes 组件以及一些有关集群状态和配置的数据。这些核心 Kubernetes 组件负责处理重要的工作，以确保容器以足够的数量和所需的资源运行。
Kube-ApiServer
Kubernetes 控制平面的前端，此集群API用于处理内部和外部请求。API 服务器会确定请求是否有效，如果有效，则对其进行处理。可以通过 REST 调用、kubectl 命令行界面或其他命令行工具（例如 kubeadm）来访问 API。
Kube-Sscheduler
此调度程序主要管理及检测容器集的资源需求（例如 CPU 或内存）以及集群的运行状况。根据当前资源现状将容器集安排到适当的计算节点。
Kube-Controller-Manager
此控制器用于查询调度程序，并确保有正确数量的容器集在运行。如果有容器集停止运行，另一个控制器会发现并做出响应。控制器会将服务连接至容器集，以便让请求前往正确的端点。还有一些控制器用于创建帐户和 API 访问令牌。
Etcd
一种分布式键值存储数据库，此数据库基于分布式、容错性设计，用来配置集群数据及状态信息。
节点
通常，一个K8S集群中会设计为多个计算节点，容器集经过调度和编排后，就会在节点上分布与运行。
引擎
此容器运行时引擎，主要为容器运行提供相关环境支撑，例如，常见的Docker，当然，K8S不仅仅支持Docker，还支持其他符合开源容器运动（OCI）标准的运行时，例如 rkt 和 CRI-O。
容器集
容器集是 Kubernetes 对象模型中最小、最简单的单元，它代表了应用的单个实例。每个容器集都由一个容器（或一系列紧密耦合的容器）以及若干控制容器运行方式的选件组成。容器集可以连接至持久存储，以运行有状态应用。
Kube-Proxy
K8S 网络代理用于优化 Kubernetes 网络服务的网络代理。Kube-Proxy 负责处理集群内部或外部的网络通信——依托操作系统的数据包过滤层，或者自行转发流量。此网络代理通常存在于每个计算节点中。
Kubelet
每个计算节点中都包含一个 kubelet，这是一个与控制平面通信的微型应用。Kublet 可确保容器在容器集内运行。当控制平面需要在节点中执行某个操作时，Kubelet 就会执行该操作。
除上述核心组件外，K8S生态集群同时也包括其他部分，例如，持久存储、容器镜像仓库以及底层资源基础架构等等。 OpenShift
针对OpenShift，我们先看下其集群架构图，以便能够清晰地去了解这个生态，具体如下所示：
由上述架构图可知：从技术堆栈的角度分析，作为容器云，OpenShift自底而上包含了以下几个层次：基础架构层、容器引擎层、容器编排层、PaaS服务层、界面及工具层。
基础架构层为OpenShift平台的运行提供了基础的运行环境。OpenShift支持运行在物理机、虚拟机、基础架构云（如OpenStack、Amazon Web Service等）或混合云上。
OpenShift目前以Docker作为平台的容器引擎。Docker是当前主流的容器引擎，已经在社区及许多企业的环境中进行了检验。
Kubernetes是OpenShift的重要组件，OpenShift平台上的许多对象和概念都是衍生自Kubernetes，如Pod、Namespace、Replication Controller等。在OpenShift集群上仍然可以通过Kubernetes的原生命令来操作Kubernetes的原生对象。
OpenShift在PaaS服务层默认提供了丰富的开发语言、开发框架、数据库及中间件的支持。用户可以在OpenShift平台上快速部署和获取一个数据库、分布式缓存或者业务规则引擎的服务。
OpenShift提供了多种用户接入的渠道：Web控制台、命令行、IDE集成及RESTful编程接口。
现在，我们再看下其内部组件图，具体如下所示：
通过上述架构图以及组件图，我们可以看到，OpenShift在容器编排层使用了Kubernetes，所以OpenShift在架构上和Kubernetes十分接近，OpenShift与K8S在大部分还是重叠的，只不过是对原生的K8S体系架构进行了功能的丰富及优化，其内部的许多组件和概念是从Kubernetes衍生而来的，它基于红帽企业版Linux和Kubernetes引擎而构建。Openshift具有多种功能，可通过UI和CLI管理集群。
有关OpenShift编排系统的相关组件与K8S相差无几，故不一一解析，仅针对个别代表性的进行描述，具体如下：
Replication Controller
复制控制器负责监控当前容器实例的数量和用户部署指定的容器数量是否匹配。如果容器异常退出，复制控制器将会发现实际的容器实例数少于部署定义的数量，从而触发部署新的容器实例，已恢复原有的状态。
Pod
在OpenShift上运行的容器会被一种叫做Pod的对象所“包裹”，用户不会直接看到Docker容器本身。从技术上来说，Pod其实也是一种特殊的容器。执行oc get pod命令可以看到当前所在项目的Pod。
Project和Namespace
OpenShift中继承了Kubernetes命名空间的概念，而且在其之上定义了Project对象的概念。每一个Project会和一个Namespace相关联，甚至可以简单地认为，Project就是Namespace。所以在OpenShift中进行操作时，首先要确认当前执行的上行文是哪一个Project。
现在，我们针对Kubernetes与OpenShift两者之间的差异进行简要对比，具体如下：
1、UI
Kubernetes Web界面很复杂，要访问Kubernetes Web GUI，我们需要安装Kubernetes仪表板，并使用kube-proxy将本地计算机的端口地址转发到群集服务器。由于仪表板缺少登录页面，因此还必须创建支持授权和身份验证的承载令牌。
相反，OpenShift具有直观的Web控制台和一键式登录页面。该控制台为我们提供了一个简单的基于表单的界面，使我们可以轻松地修改，添加和删除资源。可视化集群角色，项目和服务器也更加容易。
2、平台支撑
作为一个开源框架，Kubernetes可以部署在任何的公有云平台以及Linux发行版，而OpenShift需要RHEL，Red Hat CoreOS或CentOS Linux等发行版。
3、其他方面（因人而异）
总之，Kubernetes和OpenShift都是大规模部署容器化应用程序的绝佳选择。尽管Kubernetes凭借其灵活的部署选项而在大多数组织中都很受欢迎，但OpenShift提供了专门的支持，并具有大量简化应用程序容器化的内置组件，使其在Agile和DevOps方法学中均很受欢迎。
因此，对于需要不断更新的高需求应用程序，毫无疑问，Kubernetes是首选。OpenShift提供了全方位的解决方案，非常适合需要持续不断的专业支持的公司。
