OpenShift on Power介绍

随着技术的不断演进，应用的部署方式从传统的一个操作系统之上部署多个应用的方式演化为基于 Hypervisor 通过虚拟化方式来部署应用。近些年，随着容器技术的不断成熟，很多应用又从虚拟化的部署方式逐渐转向到容器化部署。容器化技术可以理解为操作系统层面的轻量级虚拟化。

要运行容器，必须要通过容器镜像进行。可以在互联网上的公共容器镜像仓库中搜索已有的容器镜像。大家最熟悉的容器镜像仓库是 DockerHub:

浪潮商用机器的 K1 Power 服务器使用的是 IBM POWER 处理器，不同于 Intel 的 X86 处理器。在互联网上的公共容器镜像仓库中搜索镜像时，请注意带 ppc64le 标签的镜像才是支持 Power 服务器的版本：

要制作自己应用程序的容器镜像可以通过 Dockerfile 实现。通过 Dockerfile 制作镜像的过程，以及 Dockerfile 的示例如下面两幅图片所示：

如果系统中包含了大量的容器，完全通过手动的方式管理容器是一个极大的挑战，此时就需要容器编排系统。目前，开源的 Kubernetes （ K8S ）已经成为了容器编排系统的事实标准。很多厂商均基于 Kubernetes 发布了自己的商用容器云系统，其中 Redhat 的 OpenShift Container Platform 无疑是其中的佼佼者。 2018 年发布的 OpenShift 3.11 开始支持 Power 平台， 2019 年发布的 OpenShift 4.x 是 Power 服务器上的首选版本。

OpenShift 4 的技术堆栈如下图所示：底层操作系统采用的是 Red Hat Enterprise Linux CoreOS (RHCOS) ，容器运行时是 CRI-O ，基于 Kubernets 引入了 Operator 的功能来支持有状态的应用；最上层是 OpenShift 的特定服务，包含性能监控组件 Prometheus/Grafana 、 EFK 日志套件、 CI/CD 组件、服务网格 Istio 等。

OpenShift 基于 Kubernetes 开发，架构和 Kubernestes 类似，包含 master 结点和 worker 结点：

并原生支持高可用架构：

围绕整个容器云的生态， Redhat 进行了大量的工作，包含：
1) 收购 CoreOS ，并将其容器操作系统整合到 RHEL 中，形成新的容器操作系统 Red Hat Enterprise Linux CoreOS (RHCOS) 。
2) 开发与 Kubernetes CRI 兼容性更好的轻量级的容器运行时 CRI-O ，替代 docker 。
3) 考虑到 docker 需要 root 权限的不安全因素，开发新的容器管理工具： podman 、 buildah 和 skopeo 。

• CoreOS:
  单一目的仅用来运行容器的操作系统，基于 RHEL 开发，使用 rpm 进行包管理。 OpenShift 集群通过 Machine Config Operator 对 CoreOS 进行管理，管理员一般无需手动管理 CoreOS ， CoreOS 会随着 OpenShift 的更新而更新。 CoreOS 的版本和 OpenShift 的版本保持一致，例如 OpenShift V4.3.18 包含的 CoreOS 的版本也是 V4.3.18 。
• CRI-O ：
  CRI-O 是一个符合 OCI (Open Container Initiative) 标准的容器运行时实现，同时向上兼容 Kubernetes 的 CRI (Container Runtime Interface) 接口，是 docker 的轻量级替代者。 CRI-O 的版本与 OpenShift 使用的 Kubernetes 的版本保持一致，例如 OpenShift 4.1 基于 Kubernetes 1.13 开发，那么 OpenShift4.1 对应的 CRI-O 的版本也是 1.13 。
• podman ：
  podman 用于容器和容器镜像的管理，其命令格式及参数和 docker 基本一致，同时 podman 不需要 root 权限来运行容器。 podman 的示例如下：
• buildah ：
  buildah 用于构建容器镜像。 buildah 构建的容器镜像可以直接推送到镜像仓库中，供 podman 、 CRI-O 、 docker 等容器运行时使用。 buildah 的示例如下：
• skopeo:
  skopeo 用于容器镜像的拷贝，可以从主机到主机拷贝容器镜像，也可以从镜像仓库到镜像仓库拷贝容器镜像。 Skopeo 还可以直接从镜像仓库中查看镜像的详细信息。 skopeo 的示例如下：

OpenShift 在 Kubernetes 的基础上引入了一些新的概念，如 Image Stream 、 Source 2 Image 、 Template 。 OpenShift 4 同时大力引入了 Kubernetes 中的 Operator 用于有状态应用的维护。下面分别对 Image Stream 、 Source 2 Image 、 Template 和 Operator 进行介绍。

• Image Stream ：
  Image Stream 是一组镜像的集合，方便地将一组相关联的镜像进行整合管理和使用。可以在一个 Image Stream 中定义一些名称及标签（ tag ），并定义这些名字及标签指向的具体镜像。 Image Stream 里面保存的是容器镜像的元数据，而不是容器镜像本身，容器镜像仍然保存在外部或者内部的镜像仓库中。下图是一个名为 python 的 Image Stream 的示例：
  
• Source 2 Image （ S2I ）：
  OpenShift 的 S2I 是一个基于基础镜像，将应用的源代码打包到基础镜像进而生成包含程序源代码的新镜像的工具。 S2I 的运作流程如下：
  1) 指定基础镜像， Builder Image 即为基础镜像。
  2) 开发人员向版本管理系统提交新的源代码
  3) 源代码被注入的基础镜像中，生成新的镜像
  4) 新的镜像被推送到镜像仓库，以供后续使用
  
• Template ：
  Template 指的是一组可参数化并可在 OpenShift 上创建的对象集合，比如 services, routes, volumes, image stream, build configurations, deployment configuration 等。通过参数化的模板可以同时创建一个应用正常运行所需要的所有的必须的 OpenShift 资源。 OpenShift 平台默认包含了很多预定义的模板，如下图所示：
  
  通过填写必要的参数，就可以直接部署应用系统。

也可以到 github 上搜索针对 ppc64le 平台的模板：
https://github.com/openshift/library/tree/master/arch/ppc64le/official

• Operator ：
  Operator 是一种打包、部署、管理 Kubernetes 原生应用的一种方法。 Operator 本质上是一种用户自定义的控制器，类似于 Kubernetes 原生的控制器，如 Deployment 、 DaemonSet 等，用于控制管理有状态的应用。首先用户需要通过 Custom Resource Definition (CRD) 定义自己的资源类型，然后基于 CRD 定义自己的资源 Custom Resources (CR) ， Kubernetes 能够识别到 CRD 类型及 CR 资源。最后 Kubernetes 通过自定义控制器（ Operator ）管理控制 CR 。
  

可以通过 Operator SDK 构建自己应用的 Operator 。
Operator SDK 的网址如下：https://github.com/operator-framework/operator-sdk

OpenShift 的官网对 Operator SDK 的使用进行了介绍：https://docs.openshift.com/container-platform/4.6/operators/operator_sdk/osdk-getting-started.html
Operator 的三种构建方式如下图：

OpenShift 内置了很多应用厂商开发的 Operator ：

在 Redhat 的网址上也可以查找和下载 OpenShift 认证的 Operator ：
https://catalog.redhat.com/software/operators/search

https://operatorhub.io 网址上也可以下载很多应用对应的 Operator ：

最后展示一下 OpenShift 的 WEB 界面。
可以选择管理员视图和开发者视图：

开发者视图下显示应用的状态：

开发者视图下显示项目的信息：

管理员视图：

OpenShift 内置的 Operator ：