让我们重新认识OpenShift系列1

OpenShift Container Platform，简称OCP（后面的文章就不再重复全称了）。OCP3中最经典的是OCP 3.11版本。我们和ISV、BP的很多验证方案都主要基于OCP3.11。包括去年发布的：《OpenShift在企业中的实践》。本书再版的时候，将会融入届时最新或者次新版本的OCP内容。

OCP3.11 Maintenance Support结束日期是2022年6月。所以现有生产上使用OCP3.11的同学也不用担心。

OCP4与OCP3比，融入了CoreOS的元素。架构上有一些变化。目前OCP 4最新的版本是4.3，对应K8S的1.16。这也是K8S的次新版本（最新是1.17）。目前OCP4.3的可管理性还不错。

架构图如下所示：

Kubernetes的声明式架构

OpenShift的架构基于Kubernetes的声明性。大多数系统管理员习惯于命令式体系结构，在该体系结构中，您执行间接更改系统状态的操作，例如在给定服务器上启动和停止容器。在声明性体系结构中，您可以更改系统状态，并且系统会更新自身以符合新状态。例如，使用Kubernetes，您定义了一个pod资源，该资源指定某个容器应在特定条件下运行。然后Kubernetes找到可以在这些特定条件下运行该容器的服务器（节点）。

声明式体系结构允许自我优化和自我修复的系统比命令性体系结构更易于管理。

Kubernetes将集群的状态（包括已部署的应用程序的集合）定义为存储在etcd数据库中的资源的集合。Kubernetes还运行控制器来监视这些资源，并将其与集群的当前状态进行比较。这些控制器采取任何必要的动作来使集群状态与资源状态保持一致，例如，通过找到具有足够CPU容量的节点来从新的pod资源中启动新的容器，来执行这些操作。

Kubernetes提供了REST API来管理这些资源。 OpenShift用户使用命令行界面或Web控制台执行的所有操作都是通过调用此REST API来执行的。

OpenShift控制平面

Kubernetes集群由一组运行kubelet系统服务的节点和一个容器引擎组成。OpenShift4仅运行CRI-O容器引擎。（不再使用Docker）

OpenShift中一些节点是运行REST API、etcd数据库和平台控制器的主节点（Master）。OpenShift对其主节点进行配置，以使它们只运行控制类的pod，不运行业务类的pod。OpenShift将其非主节点称为worker节点。

根据node设置，kubelet agent启动不同的静态pod（static pod）。静态容器是不需要连接到API服务器即可启动的容器。kubelet agent 管理静态pod的生命周期。静态Pod可以提供很多服务，如 scheduler、node services, software-defined networking (SDN)。OpenShift提供了为这些静态Pod创建Pod operator，以便像常规Pod一样对其进行监视。下图表示，在Master节点上主要有三类pod：蓝框标注的是静态pod，红框是一般的pod，白框的是systemd。

查看Master节点上的static pod

查看系统服务crio

查看系统服务kubelet

OpenShift扩展

Kubernetes的许多功能都取决于外部组件，例如ingress controllers, storage plug-ins, network plug-ins, authentication plug-ins.。与Linux发行版相似，有很多方法可以通过选择和选择不同的组件来构建Kubernetes发行版。也就是所谓的、各式各样的DYI的容器云。Kubernetes的许多功能还取决于扩展API，例如访问控制和网络隔离。

OpenShift是Kubernetes发行版，提供了许多已经由operators配置并管理的组件。OpenShift还向Kubernetes添加了一系列扩展API和自定义资源。如S2I，并路由资源以管理对集群的外部访问。

红帽将所有扩展作为开源项目进行开发，并与更大的Kubernetes社区合作，不仅使它们成为Kubernetes的这些正式组件，而且使Kubernetes平台得以发展，从而使维护和自定义更加容易。

在OpenShift 3中，这些扩展有时是上游Kubernetes的补丁（或分支）。使用OpenShift 4 Operator，这些扩展是标准的Kubernetes扩展，可以添加到任何Kubernetes发行版中。

OpenShift Default Storage Class

与许多专注于云原生无状态应用程序的容器平台不同，OpenShift还支持不遵循标准的十二要素应用程序方法的有状态应用程序。

OpenShift通过提供一组全面的存储功能并支持Operator来支持有状态应用程序。 OpenShift附带了集成的storage plug-ins和storage classes ，这些存储插件和存储类依赖于基础云或虚拟化平台来提供动态配置的存储。

例如，如果您在Amazon Web Services（AWS）上安装OpenShift，则OpenShift群集已预先配置了默认存储类，该默认存储类使用AWS EBS服务自动按需配置存储卷。用户可以部署需要持久存储的应用程序（例如数据库），OpenShift会自动创建一个EBS卷来托管应用程序数据。

OpenShift集群管理员以后可以定义使用不同EBS服务层的其他存储类。例如，您可能有一个存储类用于高性能存储，可维持较高的每秒输入输出操作（IOPS）速率，而另一个存储类则用于低性能，低成本存储。然后，群集管理员可以只允许某些应用程序使用高性能存储类，并可以将数据归档应用程序配置为使用低性能存储类。

Kubernetes Operators

Kubernetes Operators是调用Kubernetes API来管理Kubernetes资源的应用程序。对于任何Kubernetes应用程序，您都可以通过定义Kubernetes资源来部署Operator。由于与普通应用程序不同，Operators要直接访问Kubernetes资源，因此他们通常需要 custom security 设置。

Operators通常会定义用于存储其设置和配置的自定义资源（CR）。OpenShift Operators通过编辑其自定义资源来管理Operators。定制资源的语法由定制资源定义（CRD）定义。

介绍Operator框架

您可以使用首选的编程语言来开发operator。从技术上讲，您不需要专用的SDK即可开发operator。您所需要的就是能够调用REST API并使用包含对Kubernetes API的访问凭据的机密的能力。

Operator Framework是用于构建，测试和打包operator的开源工具包。通过提供以下组件，Operator Framework使这些任务比直接编码为低级Kubernetes API更容易。

Operator软件开发套件（Operator SDK）

提供了一组Golang库和源代码示例，这些示例在operator应用程序中实现了通用模式。它还提供了一个容器镜像和playbook示例，使您可以使用Ansible开发operator。

Operator生命周期管理器（OLM）

提供一个应用程序，该应用程序管理通过operator catalog，资源利用，更新和删除。OLM本身是预装OpenShift Operator。

Operator框架还定义了一组用于实现Operator和CRD的推荐实践，以及将Operator清单打包为容器映像的标准方式，该标准方法允许使用Operator目录分发operator。Operator目录的最常见形式是映像注册表服务器。

遵循Operator Framework标准的operator容器映像包含部署operator应用程序所需的所有资源定义。这样，OLM可以自动安装Operator。如果没有按照Operator框架标准来构建和打包operator，则OLM将无法安装或管理该Operator。

介绍OperatorHub

OperatorHub提供了一个Web界面，用于发现和发布遵循Operator Framework标准的Operator。开源operator和商业Operator都可以发布到Operator中心。可以将operator容器图像托管在不同的图像注册表中，例如Quay.io。

介绍OpenShift Cluster Operators

Cluster Operators是常规Operators，只是它们不受OLM管理。它们由 OpenShift Cluster Version Operator（有时称为第一级Operator）管理。所有集群operator也称为第二级Operator。

OpenShift Cluster Operators提供OpenShift扩展API和基础架构服务，例如：

OAuth服务器，用于验证对主API和扩展API的访问。
核心DNS服务器，用于管理群集内的服务发现。
Web控制台，允许对集群进行图形化管理。
内部映像注册表，允许开发人员使用S2I或其他机制在群集内托管容器映像。
监视堆栈，它生成有关集群运行状况的指标和警报。

一些集群operator管理节点或控制平面设置。例如，使用上游Kubernetes，您可以编辑节点配置文件以添加存储和网络插件，并且这些插件可能需要其他配置文件。 OpenShift支持operator管理所有节点中的配置文件，并重新加载受这些文件更改影响的节点服务。

探索 OpenShift Cluster Operators

通常，Operator及其托管应用程序共享同一项目。对于 Cluster Operators，它们在openshift- *项目中。

每个集群operator都定义一个typeClusterOperator的自定义资源。群集operator管理群集本身，包括API服务器，Web控制台或网络堆栈。每个 Cluster Operators定义一组自定义资源，以进一步控制其组件。ClusterOperatorAPI资源公开信息，例如更新的运行状况或组件的版本。

Operators的名字很明显，例如，consolecluster operator提供了Web控制台，ingresscluster operator启用了入口和路由。以下列出了一些集群operator。

network
ingress
storage
authentication
console
monitoring
image-registry
autoscale
openshift-apiserver
openshift-dns
openshift-controller-manager
dns
cloud-credential

更多相关文章

随机推荐