1、Project 和 Namespace
在 Kubernetes 中使用命名空间（Namespace）的概念来分隔资源 。 在同一个命名空间中，某一个对象的名称在其分类中必须是唯一的，但是分布在不同命名空间中的对象则可以同名 。 OpenShift 中继承了 Kubernetes命名空间的概念，而且在其之上定义了 Project对象的概念 。每一个 Project会和一个 Namespace相关联，甚至可以简单地认为，Project就是Namespace。
常用命令：oc project (查看用户当前所在的project)、oc get projects (查看所有项目)、oc project <project-name> (切换到指定项目)
2、Pod
在 OpenShift 上运行的容器会被一种叫 Pod 的对象所“包裹”，用户不会直接看到 Docker 容器本身。从技术上来说， Pod其实也是一种特殊的容器。
常用命令：oc get pod (查看所有pod)、oc describe pod <pod-name> (查看该pod的详细信息)
oc logs <pod-name> (查看pod的log)、oc rsh <pod-name> (可以进入pod内部执行命令)
3、Service
获取一个新的IP地址。
为了克服容器变化引发的连接信息的变化， Kubernetes 提供了一种叫 Service (服务) 的组件。当部署某个应用时，我们会为该应用创建一个 Service对象。 Service对象会与该应用的一个或多个 Pod关联。 同时每个 Service会被分配到一个IP地址，这个IP地址是相对恒定的。通过访问这个 IP 地址及相应的端口（或者service域名），请求就会被转发到对应 Pod 的相应端口。
注意⚠️：Service提供了一个通往后端 Pod集群的稳定的人口，但是 Service的 IP地址只是集群内部的节点及容器可见(外部不可达)。 对于外部的应用或者用户来说，这个地址是不可达的。（Service域名的格式是 <SERV工CE NAME> . <PROJECT NAME> . svc.cluster.local）
测试==》通过oc rsh <pod-name>进入pod内部执行命令：curl <service-ip>:<service-port>，可以看到访问成功。
常用命令：oc get svc (查看当前项目下的所有service列表)
4、Router 和 Route
外部可达)。Route规则会被 Router 加载。 当用户通过指定域名访问应用时，域名会被解析并指向 Router所在的计算节点上 。 Router获取这个请求，然后根据 Route 规则定义转发给与这个域名对应的Service。然后Service会接着做一个load banlance，转发请求到后端所关联的 Pod 容器实例。
PS：其实 Router 组件就是一个运行在容器内的 Haproxy，是一个特殊定制的 Haproxy。
常用命令：oc get route (查看项目中所有的route)
5、Secure Route（开启HTTPS）
Secure Route其实是route的一种，只不过是开启了TLS termination。注：TLS（Transport Layer Security）传输层安全性协议，其前身是安全套接层（Secure Sockets Layer，缩写作SSL）是一种安全协议，目的是为互联网通信提供安全及数据完整性保障。
三种TLS termination type：
1⃣️Edge：TLS在router上被终结，然后非SSL网络包被转发给后端pod。因此需要在 router 上安装 TLS 证书。不安装的话，会使用 router 的默认证书。（即在Route上安装certificate证书，pod内部程序不安装证书，因此外部是https，内部是http）
2⃣️passthrough：加密网络包直接被发给 pod，router 上不做TLS 终结，因此不需要在 router 上配置证书或密钥。（即在Route上不安装证书，在pod内部安装证书，因此外部是http，内部是https）
3⃣️Re-encryption：是 edge 的一种变种。首先 router 上会使用一个证书做 TSL 终结，然后使用另外的证书再进行加密，然后发给后端 pod。因此，整个网络路径都是加密的。（内外部全部https）
注意⚠️：使用Secure Route，访问路径都是https。
6、Persistent Storage
容器默认是非持久化的，所有的修改在容器销毁时都会丢失。
OpenShift 除了支持 Docker 持久化卷的挂载方式外，还提供了一种持久化供给模型，即 Persistent Volume (持久化卷， PV)及 Persistent Volume Claim (持久化卷请求， PVC)模型 。
在 PV 和 PVC 模型中，集群管理员会创建大量不同大小和不同特性的 PV。 用户在部署应用时，显式声明对持久化的需求，创建 PVC。用户在 PVC 中定义所需存储的大小、访问方式(只读或可读可写;独占或共享) 。OpenShift 集群会自动寻找符合要求的 PV 与 PVC 自动对接 。
常用命令：oc get pv (查看所有持久化卷，需要admin权限)、oc get pvc（查看所有持久化卷请求）
7、Registry
OpenShift 提供了一个内部的 Docker 镜像仓库( Registry)，该镜像仓库用于存放用户通过内置的 Source to Image 镜像构建流程所产生的镜像 。每当 S2I 完成镜像构建，就会向内部的镜像仓库推送构建完成的镜像 。
Registry 组件默认以容器的方式提供，因此我们可以通过 oc get pod -n default 查看 Registry 容器的状态。同理，通过 oc get svc -n default 可以查看 Registry 容器对应的 Service 信息。
8、Source to Image （S2I）
一个典型的 S21 流程包含了以下几个步骤。
1⃣️ 用户输入源代码仓库的地址。
2⃣️ 用户选择 S2I 构建的基础镜像(又称为 Builder 镜像)。 Builder镜像中包含了操作系统、编程语言、框架等应用所需的软件及配置。 OpenShift 默认提供了多种编程语言的 Builder 镜像，如 Java、 PHP、 Ruby、 Python、 Perl等。 用户也可以根据自身需求定制自己的 Builder镜像，并发布到服务目录中供用户选用 。
3⃣️ 用户或系统触发 S2I 构建 。 OpenShift 将实例化 S2I 构建执行器 。
4⃣️ S2I 构建执行器将从用户指定的代码仓库下载源代码。
5⃣️ S2I 构建执行器实例化 Builder 镜像。 代码将会被注入 Builder 镜像中。
6⃣️ Builder 镜像将根据预定义的逻辑执行源代码的编译、构建并完成部署。
7⃣️ S2I构建执行器将完成操作的 Builder 镜像去生成新的 Docker 镜像。
8⃣️ S2I构建执行器将新的镜像推送到 OpenShift 内部的镜像仓库（Registry）。
9⃣️ S2I构建执行器更新该次构建相关的 Image Stream 信息。
注：S2I 构建完成后，根据用户定义的部署逻辑， OpenShift将把镜像实例化部署到集群中 。 除了接受源代码仓库地址作为输入外， S2I还接受 Dockerfile 以及二进制文件作为构建的输入。 用户甚至可以完全自定义构建逻辑来满足特殊的需求。
9、Image Stream
OpenShift 定义了 Image Stream 的概念来管理一组镜像的集合 。 在一个 Image Stream 中可以定义多个镜像名称和 Tag，然后再指向实际的 Docker镜像。通过 oc get / describe is 命令来查看 Image Stream 信息。
10、镜像构建：Build Config 与 Build
Build Config 用于指导应用构建过程，包括源码位置、构建策略、构建触发配置等。通过 oc get bc 可以查看所有的 build config 信息。如果想进一步获取某个 Build Config 的具体配置信息可使用 oc get bc <build-config-name> -o yaml 命令。
Build Config 只是静态的配置信息 。 OpenShift 根据这个静态的配置信息可以触发多次实际的构建实例，构建的实例称为 Build。 一个 Build Config 可以被多次触发， 生成多个Build。通过 oc get build 命令，可以查看生成的 build 列表。执行 oc logs build/<build-name> 命令，可以查看本次 build 的详细信息。如果想执行一次新的构建，可使用 oc new-build <svc-name> 命令。
11、镜像部署：Deployment Config 与 Deploy
Deployment Config 描述了镜像部署的参数和要求。通过 oc get dc 命令可以查看项目中的 Deployment Config 列表。执行 oc get dc <svc-name> -o yaml 命令，可以查看该 DeploymentConfig 的详细定义 。在 Deployment Config 中会定义 Trigger (触发器)，使部署在某些特定条件下自动触发，如 S2I 完成时。
每个 Deployment Config 可以被多次触发，每一次触发称为一个 Deploy。 每一次 Deploy 都会生成一个 Replication Controller 对象，用以监控容器的状态。 Replication Controller (复制控制器)是 Kubernetes 中的一个组件，其负责监控容器的实际数量。通过 oc get rc 可以查看 Replication Controller 列表。
Openshift 的更新部署策略有 Rolling 和 Recreate 两种。
1⃣️ Rolling（滚动更新）是指 Openshift 在部署时，会等一定数量的新版本容器实例启动完毕后，在终结一定数量的老版本容器实例，通过这种方式对容器集群中的实例进行逐一替换更新。这种方式可以保证应用在更新发布的过程中不会出现服务中断。
2⃣️ Recreate（重新创建）是指在更新时将所有老容器应用先停止，然后再启动一批新版本的容器实例。
12、Replication Controller
在 OpenShift 中，每一个部署的应用的容器实例数量在其 Deployment Config 中定义。实际部署时，OpenShift 为每次的部署实例化一个 Replication Controller，并将该数值传递给相关联的 Replication Controller。 Replication Controller是 Kubernetes 的一个组件，其负责维护容器实例的数量 。
可以通过 oc scale dc <service-name> --replicas=n 命令来将该 service 应用弹性伸缩为 n 个实例。
其他
oc login/logout 登录/登出OCP
如何触发部署：oc tag --source=docker <docker-registry>/<project-name>:<tag> <ocp-project-name>/<ocp-service-name>:<tag>
