🎹 个人简介：大家好，我是 金鱼哥，CSDN运维领域新星创作者，华为云·云享专家，阿里云社区·专家博主
📚个人资质：CCNA、HCNP、CSNA（网络分析师），软考初级、中级网络工程师、RHCSA、RHCE、RHCA、RHCI、ITIL😜
💬格言：努力不一定成功，但要想成功就必须努力🔥

🎈支持我：可点赞👍、可收藏⭐️、可留言📝

---

📜管理OpenShift

📑OpenShift项目及应用

除了Kubernetes的资源(如pods和services)之外，OpenShift还管理projects和users。一个projects对Kubernetes资源进行分组，以便用户可以使用访问权限。还可以为projects分配配额，从而限制了已定义的pod、volumes、services和其他资源。

OpenShift中没有application的概念，OpenShift client提供了一个new-app命令。此命令在projects中创建资源，但它们都不是应用程序资源。这个命令是为标准开发人员工作流配置带有公共资源

的proiect的快捷方式。OpenShift使用lables(标签)对集群中的资源进行分类。默认情况下，OpenShift使用app标签将相关资源分组到应用程序中。

---

📑使用Source-to-image构建映像

OpenShift允许开发人员使用标准源代码管理仓库(SCM)和集成开发环境(ide)来发布应用。

OpenShift中的source-to-lmage (S2I) 流程从SCM仓库中提取代码，自动判断所需的runtime，基于runtime启动一个pod，在pod中编译应用。

当编译成功时，将在runtime image中添加层并形成新的image，推送进入OpenShift internal registry仓库，接着基于这个image将创建新的pod，运行应用程序。

S2I可被视为已经内置到OpenShift中的完整的CI/CD管道。

CI/CD有不同的形式，根据具体场景表现不同。例如，可以使用外部CI工具(如Jenkins)启动构建并运行测试，然后将新构建的映像标记为成功或失败，将其推送到QA或生产。

---

📑管理OpenShift资源

OpenShift资源定义,如image、container、pod、service、builder、template等，都存储在Etcd中，可以由OpenShift CLI, web控制台或REST API进行管理。

OpenShift的资源可通过JSON或YAML文件查看，并且在类似Git或版本控制的SCM中共享。OpenShift甚至可以直接从外部SCM检索这些资源定义。

大多数OpenShift操作不需要实时响应，OpenShift命令和APIs通常创建或修改存储在Etcd中的资源描述。Etcd然后通知OpenShift控制器，OpenShift控制器会就更改警告这些资源。

这些控制器采取行动，以便使得资源的最终态反应达到更改效果。例如，如果创建了一个新的pod资源，Kubernetes将在node上调度并启动该pod，使用pod资源确定要使用哪个映像、要公开哪个端口，等等。或者一个模板被更改，从而指定应该有更多的pod来处理负载，OpenShift会安排额外的pod(副本)来满足更新后的模板定义。

---

**注意：**虽然Docker和Kubernetes是OpenShift的底层，但是必须主要使用OpenShift CLi和OpenShift APls来管理应用程序和基础设施。OpenShift增加了额外的安全和自动化功能，当直接使用Docker或Kubernetes命令和APls时，这些功能必须手动配置，或者根本不可用。因此强烈建议不要使用docker或Kubernetes的命令直接管理应用。

---

📜OpenShift网络

📑OpenShift网络概述

Docker网络相对简单，Docker创建一个虚拟内核桥接器（docker0网卡），并将每个容器网络接口连接到它。Docker本身没有提供允许一个主机上的pod连接到另一个主机上的pod的方法。Docker也没有提供向应用程序分配公共固定IP地址的方法，以便外部用户可以访问它。

但Kubernetes提供service和route资源来管理pods之间的网络，以及从外部到pods的路由流量。service在不同pods之间提供负载均衡用于接收网络请求，同时为service的所有客户机(通常是其他

pods)提供一个内部IP地址。container和pods不需要知道其他pods在哪里，它们只连接到service。route为service提供一个固定的惟一DNS名称，使其对OpenShift集群之外的客户端可见。

Kubernetes service和route资源需要外部（功能）插件支持。service需要软件定义的网络(SDN)，它将在不同主机上的pod之间提供通信，route需要转发或重定向来自外部客户端的包到服务内部IP。OpenShift提供了一个基于Open vSwitch的SDN，路由由分布式HAProxy farm提供。

---

📜OpenShift持久性存储

📑永久存储

pod可以在一个节点上停止，并随时在另一个节点上重新启动。同时pod的默认存储是临时存储，通过对于类似数据库需要永久保存数据的应用不适合。

Kubernetes为管理容器的外部持久存储提供了一个框架。Kubernetes提供了PersistentVolume资源，它可以在本地或网络中定义存储。pod资源可以使用PersistentVolumeClaim资源来访问对应的持久存储卷。

Kubernetes还指定了一个PersistentVolume资源是否可以在pod之间共享，或者每个pod是否需要具有独占访问权的自己PersistentVolume。当pod移动到另一个节点时，它将保持与相同的PersistentVolumeClaim和PersistentVolumne资源的关联。这意味着pod的持久存储数据跟随它，而不管它将在哪个节点上运行。

OpenShift向Kubernetes提供了多种VolumeProvider，如NFS、iSCSI、FC、Gluster或OpenStack Cinder。

OpenShift还通过StorageClass资源为应用程序提供动态存储。使用动态存储，可以选择不同类型的后端存储。后面存储根据应用程序的需要划分为不同的“tiers”。例如，可以定义一个名为“fast”的存储类和另一个名为“slow”的存储类，前者使用更高速的后端存储，后者提供普通的存储。当请求存储时，最终用户可以指定一个Persistentvolumeclaim，并使用一个注释指定他们所需的StorageClass。

---

📜OpenShift高可用

📑OpenShift高可用概述

OpenShift平台集群的高可用性(HA)有两个不同的方面：OpenShift基础设施本身的HA(即主机)；以及在OpenShift集群中运行的应用程序的HA。

默认情况下，OpenShift为master提供了完全支持的本机HA机制。

对于应用程序或“pods”，如果pod因任何原因丢失，Kubernetes将调度另一个副本，将其连接到服务层和持久存储。如果整个节点丢失，Kubernetes会为它所有的pod安排替换节点，最终所有的应用程序都会重新可用。pod中的应用程序负责它们自己的状态，因此它们需要自己维护应用程序状态(如HTTP会话复制或数据库复制)。

---

📜Image Streams

📑Image Streams

要在OpenShift中创建一个新的应用程序，除了应用程序源代码之外，还需要一个base image(S2I builder image)。如果源代码或image任何一个更新，就会生成一个新的image，并且基于此新image创建新的pod，同时替换旧的pod。

即当应用程序代码发生更改时，容器镜像需要更新，但如果构建器镜像发生更改，则部署的pod也需

要更新。

Image Streams包括由tag标识的大量的image。应用程序是针对Image Streams构建的。Image Streams可用于在创建新image时自动执行操作。构建和部署可以监视Image Streams，以便在添加新image时接收通知，并分别执行构建或部署。

OpenShift默认情况下提供了几个Image Streams，包括许多流行的runtime和frameworks。Image Streams tag是指向Image Streams中的image的别名。通常缩写为istag。它包含一个image历史记录，表示为tag曾经指向的所有images的堆栈。每当使用特定的istag标记一个新的或现有的image时，它都会被放在历史堆栈的第一个位置(标记为latest)。之前tag再次指向旧的image。同时允许简单的回滚，使标签再次指向旧的image。

---

摘自网上资料（摘自陈沙克老师的博客）

感谢陈沙克（可自行百度一下，大神级人物，九州云副总裁）老师的文章分享让我们能够学习得更多。

📜虚拟化和容器–开源发展相似历程（2017-10-25）

其实回顾一下虚拟化和容器的发展历程，很大程度是惊人相似。我这里其实肯定不是很严谨的描述。仅仅是大概介绍一下过程。

---

📑虚拟化

技术

商业的虚拟化技术其实也不少。开源的的也是一样。著名的就是Xen和KVM两家。

1. Xen

2. KVM

Xen是2003年发布。KVM进入linux内核，真正第一个操作系统支持，当时据说是：ubuntu 8.04，也就是2008年，当时的KVM，还是一个玩具。

2010年，红帽发布RHEL 6.0，KVM算是正式进入主流。当时全球虚拟化，公有云，基本都是Xen的天下。

经过了5年的PK，现在已经是KVM独大。目前AWS，阿里云，已经全面转向KVM。

Xen的没落，很多原因，其中一个，就是intel搞了一套cpu虚拟化的东西，帮助kvm胜出。

KVM的想法其实应该是2006年，为了对抗Xen，intel，红帽，IBM，联手搞出一个KVM，放到内核里。

---

抽象层

那么多虚拟化引擎，那么肯定有人想到要做一个统一管理工具，这样可以管理多个。这样Libvirt就出现了。

Libvirt最擅长管理KVM，不过其实别的都是可以管理。

管理引擎

虚拟化的技术，其实需要有管理工具，那么他的管理工具有哪些呢

• OpenStack
• CloudStack
• Eucalptus
• OpenNebula

---

其实还要很多，这些管理工具，当时是能管理Xen和Kvm，也有专门针对某个虚拟化的管理工具

1. Xen Server，专门管理Xen

2. Ovirt，专门管理KVM

这些工具，从2008年，一直pk到2014年，终于分出的高低。最后是OpenStack+KVM胜出。

管理引擎，也是通过抽象层，Libvirt去管理KVM的。

---

产品化

其实就是针对管理引擎的产品化。你需要把管理引擎包装出来，加上很多辅助的工具，让用户用的很爽。

1. 红帽TrippleO

2. Mirantis的Fuel

3. Kolla

其实Ubuntu和Suse，都有他们的产品。

Mirantis的Fuel和Suse的Crowbar，大概是2014年出现，到现在也经历了3年多。从我的角度，最终就是Kolla彻底胜出，毫无悬念啊。

---

OpenStack的创业公司，目前还能有口饭吃，其实是要谢谢红帽。红帽因为在OpenStack上的策略有所失误，导致没能在OpenStack一统天下。要记住啊，

1. 当年kolla项目可是TrippleO的一个子项目，

2. Kolla项目的创始人，也是红帽的工程师，

3. ansible，Ceph都是红帽自家产品啊，

4. Cobbler，也是Ansible公司的人在维护。

5. libvirt，qemu，kvm都是红帽的

---

📑容器

技术

容器的技术，起源很早，我最早接触是OpenVZ，这个让国内很多卖虚拟机挣钱的软件。对于开源，流行的容器来说

1. LXC

2. Docker

3. LXD

4. RTK

5. Clean container

LXC，国内互联网2010年就开始使用。不过目前最流行的是Docker，

Docker从2013年发布到现在，其实发展速度很快，很多厂商都来不及响应，这个东西就成为主流。这个时候，intel又想重施故技，搞一个和cpu有关的容器技术，所谓的Clean Container。

不过这次由于Docker发展过于迅速，intel这次搞容器，完全是自己玩，不像当年和红帽勾搭在一起。所以很难在市场立足。

---

抽象层

和虚拟化其实一样道理，底层那么多容器技术，如何方便管理呢。

CRI Interface, Container RunTime Interface，就出现了，做了一层抽象后，各个厂商就可以和平共处。

---

管理引擎

对于容器来说，也叫编排引擎，这个大家就比较熟悉3大编排引擎

1. K8S

2. Swarm

3. Messos

K8S是从2014年7月份推出，到2017年7月份，基本上是完胜。厂商纷纷投降。K8s+Docker和虚拟化也是一样，目前K8s，是通过CRI，去管理Docker。

---

产品化

用户要用起来，要把k8s，或者messos用起来，那么还是需要做很多工作。业界最著名的产品就是

1. OpenShift

2. Racher

国内的很多容器公司，k8s公司，其实都是在做类似的工作，在K8s上增加自己定制，形成自己的产品。包括现在CloudFountry，都号称要支持K8s。背后的故事也很多，Racher当时号称要管理3个引擎，k8s，swarm和messos，最新的2.0的版本，就只管理K8s。

还是红帽厉害，2014年K8s发布，马上转方向，全面发力K8s，包装自己的OpenShift产品。当红帽已经做出势头的时候，那是无人能敌的。这种K8s的产品化，基本也是毫无悬念，OpenShift胜出。

---

📜OpenShift介绍（2017-10-19）

现在开始搞PaaS平台，那么OpenShift就必须研究一下，这里写篇文章，把我过去一个月的理解，整理一下。

以前都是搞OpenStack，IaaS层面，发现对PaaS层面，了解不多。不过幸好当时搞Kolla，把OpenStack容器化，对我现在理解PaaS，还是有很大的帮助。

---

📑容器和Docker

其实这个对我来说，还是比较熟悉，可以说的清楚。市场上的容器，基本都是Docker，有很多其他容器厂商，不过目前看来还是很难和Docker来PK。

那么对于软件行业来说，我自己是深刻体会Docker带来的变化。是一个革命性的应用。Docker从2013年发布，到现在已经五年，已经进入比较稳定的阶段。

---

📑编排和kubernetes

编排，这个词，对于不是开发人员来说，还是不好理解。其实就是当你的应用放到容器里的时候，容器的启动顺序是有要求的。那么这个时候就需要用编排。

对容器的编排，其实很多工具可以实现。对于OpenStack容器化项目kolla来说。ansible目前是编排工具，其实也挺好。这主要一个原因就是在规模不大，容量数量不多，环境不复杂的情况下，ansible编排，是可以满足需求的。

对编排一个需求，就是一个服务如果挂掉，编排工具可以自动启动，压力大的时候，会横向扩容。不过在OpenStack的场景下，无状态的服务，从来都不是瓶颈，nova api，服务我用了OpenStack那么久，没遇到过挂掉的。

对于有状态的服务，其实编排工具是无法实现所谓的横向扩容。例如数据库和消息队列。

编排工具，目前最大的玩家，就是k8s。基本所有厂商都用它。

那么k8s和paas是什么关系。经常在会议上，很多讲座，就把k8s当成PaaS来介绍。

K8S是一个容器编排工具，要实现PaaS的功能，其实还需要在上面做很多工作，监控，日志，CI，CD等。那么这些工具，你可以自己组合，结合自己的公司的需求，搞出一套PaaS平台。

---

📑PaaS和OpenShift

真正意义上的PaaS，其实就是业界两家：

• vmware 的CloudFoundry
• 红帽的OpenShift

2015年的时候，这两家的PaaS，都是ruby开发，思路基本都是一样，江湖传闻，两位项目创始人酒吧喝完酒，各自搞了一个项目。不过在市场上，CloudFoundry声音是比较大的。远超过红帽。

2015年的时候，华为，IBM，HP的所谓PaaS平台，都是基于CloudFoundry来修改的。

K8s，2014年7月份发布第一个版本，2015年七月份，发布1.0的产品，那么这个时候红帽看到的机会，也是在这个时候，业界的风向发生的改变，红帽，华为，IBM，把底层都改成K8S。

2015年，红帽推出基于k8s的OpenShift。

Openshift 3.0的产品，就全面转向K8S。可以这样理解，以前的代码全部扔掉，重新来过一次。很神奇的事情，2016年，红帽就宣布OpenShift挣大钱。同时也加大投入。

---

OpenShift对红帽有多么重要呢？已经成为的第二大收入来源。第一大肯定是操作系统。

那么新版的OpenShift和以前的OpenShift有啥区别呢？

---

其实以前的PaaS平台一个通病，就是要把应用放到PaaS上，你是必须对代码进行修改才行。例如大家可能以前也去红帽的OpenShift官网测试过一个wordpress的实验，这个wordpress，是要经过代码修改的。一旦进行了update更新，就肯定会挂掉。

现在的OpenShift，不需要你做任何的代码修改，就可以放上去PaaS平台，所以肯定也是能update。

CloudFoundry，刚刚也对外宣布，底层也要支持K8s，不过已经晚了。红帽的势头已经起来。你就完全没有机会了。

我和朋友开玩笑说：红帽的OpenStack势头没做起来，导致OpenStack厂商还能有口饭吃。红帽的PaaS平台，K8s已经势头起来了，别的厂商，其实已经空间不大了。

---

📑OpenShift版本

红帽的一贯风格，都是开源版本，商业版本，命名也不一样。从上面图其实就可以看出来，也让用户感觉很混乱。

到了OpenShift 3.6的版本，集成的K8s 1.6的版本，版本就清晰很多

1. 开源版本：OpenShift Origin 3.6

2. 商业版本：OpenShift 3.6

我的理解，代码都是一样，就是一个商业支持的区别。

---

从红帽的发布OpenShift版本可以看出，基本是一年4个版本，紧跟K8S。目前K8S最新版本是1.8。落后2个版本。

k8s 1.5的版本是2016年12月23日，红帽的OpenShift 3.5，是2017年4月份发布

K8s 1.6的版本是2017年3月22日发布的，红帽的OpenShift 3.6是2017年7月底。红帽需要4个月时间发布一个版本。

https://www.kubernetes.org.cn/1353.html

2017年12月13日 k8s v1.9.0正式版本发布！

Kubernetes 1.1的版本是，2015年11月9日发布。

---

📑OpenShift介绍

很多人说红帽的OpenShift就是一个K8S，其实这是一个不算太正确的理解。OpenShift，目前的版本，可以理解成一个真正意义上的PaaS。

红帽在K8S上封装了一层，你基本上已经用不上K8S的命令。上面提供红帽的UI，集成了日志，监控，镜像仓库等功能。也集成的CI，CD。

比如你希望在K8s跑一个mysql的群集，Redis的群集，那么这些都是需要厂商做很多工作才能实现，红帽提供全套的服务。

---

📑OpenShift对手

很多厂商基于K8S做出自己的PaaS平台，例如IBM的Bluemix。但是真正能产品化的，也就

OpenShift和Racher。

目前市场上OpenShift肯定是领先的。红帽的开源优势发挥出来。

---

📑PaaS和IaaS关系

大家可以受那张图的影响，认为PaaS必须跑在IaaS上。那么其实两者可以没任何关系，也是可以密切联系。

红帽的OpenShift，基本支持所有的平台，物理机器的部署，OpenStack里部署，和虚拟机里部署。

目前OpenShift的部署，是通过Ansible来实现，非常方便。

IaaS平台上，很多组件可以是PaaS通过软件提供，也可以是IaaS提供，例如负载均衡，DNS服务，Nas服务，如果Iaas平台提供这些服务，那么跑PaaS平台，OpenShift，就更加方便可靠。

对于实际的PaaS应用来说，微服务用到有状态的服务，例如数据库，mysql，redis。目前业界都是推荐直接使用IaaS平台的，目前在PaaS层跑有状态的应用，业界的测试还是不够的。

---

📜OpenShift图解（2017-11-9）

📑部署架构图

---

📑What isOpenShift

---

📑Roadmap

---

📑流程

1. developer provides git repo

2. Developer chooses image from grgistry

3. layer is applied to image

4. layer is added back to registry

5. image is scheduled and deployed

6. Developer can declare webhooks

7. updated image is added back to the registry

8. New Images is depoyed as rooling update

---

📑Compare

📑Architecture

---

📜OpenStack和Kubernetes相似的地方（2018-9-10）

我也算是折腾了一年的OpenShift，OpenShift，就是Kubernetes的一个发行版，我的感觉，其实他们相似的地方还是很多，对我的改变并没有想象那么大。

下面总结一下他们的相同的地方

---

📑看不到对手

无论是OpenStack还是kubernetes，都是在重围中杀出来，一骑绝尘，根本看不到对手。

OpenStack干掉CloudStack，Eucalyptus，OpenNebula。

Kubernetes，干掉swam ，messos

都是压倒性的优势胜出。

区别就在于，OpenStack胜出以后，就迷失了方向，往自己不擅长的边缘计算，最终只能是一条不归路。

K8s胜出后，社区的想法还是很多，还保持1年4个版本的迭代。

一个是python最大的开源项目，一个是Go语言最大的开源项目。

---

📑基金会管理

OpenStack专门成立基金会管理，不过基金会不涉及技术方向，技术方向有专门的TC，技术委员会管理，当big tent，大帐篷策略后，TC的用途也就不大，而且TC混日子的人也多了。

OpenStack官方目前有60多个项目，其实大部分都是僵尸项目，停留在实验室阶段，根本就没生产使用案例。真的能用的项目，应该不超过15个。

k8s，其实也归属CNCF基金会。吸取OpenStack基金会的教训。对项目是加入，孵化，毕业，有了严格的流程。这个可以很好避免。

OpenStack技术设计的时候，很纠结规模优先还是功能优先。公有云为主，还是私有云为主。这个也导致一直无法明确。

我的理解，K8s的功能，逐步的玩企业级发展。无论是用k8s支持有状态的应用，还是让k8s管理vm，方向都非常明确。

---

📑架构

看完OpenStack的架构演变过程，再看k8s，感觉相似的地方很多的。

• Nova==CRI-O
• cinder=CSI
• Neutron=CNI

计算，存储，网络，都搞一个，无论是OpenStack，还是k8s，基本都是一样的玩法，让厂商都能参与进来。

---

目前k8s上没有统一的身份认证，就没有keystone，k8s上，没提供镜像仓库，就没有glance。

事实上也是有一堆的应用，对于OpenStack组件

• keystone+ldap=keycloak+ldap
• glance=Quay or harbor

---

📑部署

大家都感觉OpenStack很复杂，如果和k8s比起来，其实算是简单的。k8s的部署，单单是一个双向的证书，都能让你折腾一个半天。

但是用户一般感觉k8s比较简单，一个原因，就是k8s自己做的部署管理工具比较成熟。目前红帽的OpenShift，已经采用全容器化的部署方案部署OpenShift，并且容器的管理，也是在Openshift上，真的比较完善。升级的问题，也就变得很简单。

OpenStack目前部署方案的方向也是容器化部署，不过还无法实现用k8s来管理，只能通过ansible来管理。

对我来说，

• kolla-ansible 部署OpenStack
• openshift-ansible 部署OpenShift

都是通过ansible来实现。

---

💡总结

RHCA认证需要经历5门的学习与考试，还是需要花不少时间去学习与备考的，好好加油，可以噶🤪。

以上就是【金鱼哥】对 第一章 介绍红帽OPENSHIFT容器平台–管理OpenShift与课外补充 的简述和讲解。希望能对看到此文章的小伙伴有所帮助。

💾红帽认证专栏系列：
RHCSA专栏：戏说 RHCSA 认证
RHCE专栏：戏说 RHCE 认证
此文章收录在RHCA专栏：RHCA 回忆录

如果这篇【文章】有帮助到你，希望可以给【金鱼哥】点个赞👍，创作不易，相比官方的陈述，我更喜欢用【通俗易懂】的文笔去讲解每一个知识点。

如果有对【运维技术】感兴趣，也欢迎关注❤️❤️❤️ 【金鱼哥】❤️❤️❤️，我将会给你带来巨大的【收获与惊喜】💕💕！