作者：李晓辉

微信联系：lxh_chat

联系邮箱: 939958092@qq.com

回顾Kubernetes 架构

Kubernetes就是一个平台，能把那些装在容器里的应用程序的部署、管理和扩展都搞定，省心省力。

它用的是一种声明式配置模型，就好比管理员写了个“任务清单”，上面写明了要在集群里执行的工作负载是啥样，然后Kubernetes就自动去保证实际运行的工作负载跟这个清单一模一样。举个例子，管理员定义了好几个工作负载，每个都标注了需要多少内存，Kubernetes就会在不同的节点上创建相应的容器，把内存需求都满足了。

资源嘛，就是集群管的那些能配置、能用的部件。这些资源属于一个声明式API的一部分，有很规范的结构和端点。因为结构和端点都很规整，所以大部分Kubernetes工具都能和任何Kubernetes API配合着用，哪怕那些工具不是核心部分的。像OpenShift Container Platform和OpenShift Virtualization，它们都扩展了API，还提供了额外的资源。

K8S基本架构

想知道Kubernetes 是怎么工作的吗？它用好多服务器（也叫节点）来保证它管理的应用程序既稳定又可以灵活扩展。这些节点可以是物理机，也可以是虚拟机，就像给应用搭了个结实又灵活的“架子”。

节点分两种，各有各的“活儿”。

控制平面节点（Control Plane Nodes）就像是整个集群的“大脑”，负责统筹安排部署的工作负载啥时候该运行。它们还得根据集群里发生的事儿和收到的请求，管理好集群配置的状态，确保一切按计划进行。
计算平面节点（Compute Plane Nodes）呢，就是干活儿的“小弟”，专门负责运行用户的工作负载，把用户的任务都给搞定。

虽然一台服务器可以同时当控制平面节点和计算平面节点，但一般情况下，大家都会把这两个角色分开，这样能让整个系统更稳定、更安全，也更好管理。就像把不同的任务交给不同的人去做，效率更高，出错的概率也小很多。

Kubernetes集群的规模可大可小，小的可能就只有一个节点，就像个小作坊，自己搞定一切。大的集群可以有高达5000个节点，那可就是个超大型的“工厂”了，能同时处理超多的任务，满足各种复杂的需求。

Kubernetes API与工作负载

提供了一个模型，让管理员可以定义要在集群上运行的任务，就像在纸上画出你想要的“任务蓝图”一样。

管理员定义任务的时候，都是用资源来描述的。不管是什么类型的资源，它们都用同一个API，就像大家都说同一种语言一样。这样一来，工具比如kubectl命令就能轻松管理各种类型的资源，哪怕是自定义的资源类型也不在话下。

而且，Kubernetes还能把资源当作文本文件导入和导出，超方便！管理员可以直接用文本格式来描述他们的任务，而不用操心具体的操作步骤。这种“我只要说出我想要什么，剩下的交给系统搞定”的方式，就叫声明式资源管理。

声明式资源管理能大大减轻管理员创建任务的负担，还能让维护变得更简单。而且，用文本文件描述资源还有一个超棒的好处，管理员可以用通用工具，比如版本控制系统，来跟踪资源的变更。这样一来，每次修改都能留下记录，出了问题也好追溯。

为了支持这种声明式资源管理，Kubernetes用了一种叫控制器的东西。控制器就像个“监督员”，时刻盯着集群的状态，一旦发现实际状态和目标状态不一样，就会自动采取措施，把集群调整到理想的状态。不过，因为这个过程需要一步步来，所以资源的变更通常不会立刻生效。但别担心，Kubernetes很聪明，能自动搞定复杂的变更。比如，如果你把一个应用的内存需求提高了，而当前节点满足不了，Kubernetes就会自动把应用迁移到有足够内存的节点上。而且，它还会等到迁移完全完成之后，才把流量切换到新的实例上，确保整个过程无缝衔接。

另外，Kubernetes还支持命名空间（namespaces），这可是个好东西！命名空间就像一个个“小隔间”，可以用来隔离不同的资源组。管理员可以创建命名空间，大部分资源都得在命名空间里创建。这不仅能让资源管理更有条理，还能为资源访问控制等功能打下基础。管理员可以给命名空间设置权限，决定哪些用户可以查看或修改里面的资源，这样一来，资源的安全性和管理的灵活性都得到了保障。

Kubernetes OperatorHub

OperatorHub是 Kubernetes Operators 的“大本营”，好多厉害的公司，像 Red Hat、AWS、Google Cloud 和微软，都参与了这个项目，一起搞了个大事情。
OperatorHub 就像是一个“应用商店”，不过里面全是给 Kubernetes 用的 Operators。你可以在这里找到各种各样的 Operators，它们能给你的 Kubernetes 集群增加超多新功能。比如，你想让你的集群能自动备份数据，或者轻松升级应用，这里肯定能找到合适的 Operator。

而且，这个平台还特别贴心，不仅让你能找到现成的 Operators，还能帮你搞定自定义 Operators。要是你有独特的想法，想开发自己的 Operators，这里有一大堆工具和教程，能帮你快速上手。

这些 Operators 都是用 Operator Framework 做出来的，然后分享到 OperatorHub 上，让全世界的开发者都能用。这就好比开源社区的“宝藏库”，大家都能在里面找到自己需要的宝贝，还能把自己的作品分享给大家。

大家可以打开这个网址看看：https://operatorhub.io/

聊聊OpenShift

Kubernetes它是个超厉害的工具，能帮咱们搭建服务器集群，专门用来运行那些容器化的应用程序。不过呢，它并不打算把所有事情都包办，而是留了很多扩展点，让系统管理员可以根据自己的需求去完善它。

Red Hat OpenShift 就是基于 Kubernetes 的这些扩展点，搞出了一个特别完整的平台。它给生产平台加了好多厉害的功能，比如：

远程管理：能让咱们在千里之外也能掌控一切，超方便！
多租户功能：不同用户可以互不干扰地使用资源，大家各干各的，互不打扰。
安全性提升：不用担心被黑客盯上，安全得很！
监控和审计功能：能时刻掌握系统动态，出了问题也能快速定位。
应用生命周期管理：让应用程序从出生到消亡都能被妥善照顾，不用担心半路出岔子。
开发者自助界面：方便开发者们自己折腾，想怎么开发就怎么开发。

Red Hat OpenShift 这个产品家族里，集成了好多牛气的组件呢，具体有：

Red Hat Enterprise Linux CoreOS：一个超轻量级的操作系统，运行速度快，占用资源少。
CRI-O 容器运行时引擎：它的攻击面很小，安全性很高，不用担心被攻击。
Kubernetes 开源容器编排平台：这是核心，用来管理容器的运行和调度。
自助式的 Web 控制台：界面友好得很，操作起来超简单。
预装的应用服务：比如日志和监控框架，啥都有，直接用就行。
多种认证容器镜像：包括编程语言运行时、数据库和其他软件包，啥都不用自己装，直接拉取就行。

这一整套技术堆叠起来，让 Red Hat OpenShift 能为现代部署提供企业级的扩展性和可靠性，超级靠谱！

对了，Red Hat OpenShift 还有好几个版本呢，是根据不同业务需求和场景量身定制的：

公共云托管版本：比如亚马逊云服务提供的版本，啥都不用操心，交给他们就行。
自管版本：可以根据自己的需求灵活配置，自己掌控一切。

OpenShift Kubernetes Engine

Red Hat OpenShift Kubernetes Engine包含了 Kubernetes 平台的最新版本，而且还有 Red Hat 特别出名的额外安全加固和企业级稳定性。这个部署是在 Red Hat Enterprise Linux CoreOS（一个不可变的容器操作系统）上跑的，用 Red Hat OpenShift 虚拟化来管理虚拟机，还给管理员配了个控制台，方便日常操作和维护。

Red Hat OpenShift 容器平台（RHOCP）是在 OpenShift Kubernetes Engine 的基础上搞出来的，专门给企业用，增加了更多集群管理、安全、稳定和应用开发的便利性。这个版本的额外功能包括：

开发者控制台：方便开发者操作。
日志管理：能轻松搞定日志。
成本管理：帮你管好成本。
计量信息：能清楚地看到各种资源的使用情况。

这个版本还加入了：

Red Hat OpenShift Serverless（Knative）：让应用可以按需运行，省资源。
Red Hat OpenShift 服务网格（Istio）：管理微服务之间的通信。
Red Hat OpenShift 管道（Tekton）：帮开发者自动化构建和部署应用。
Red Hat OpenShift GitOps（Argo CD）：用 Git 来管理应用的部署。

Red Hat OpenShift 平台增强版（就是功能最全的那个）进一步扩展了这些功能，提供了最有价值、最强大的功能组合。这个版本包括：

Red Hat 高级集群管理（针对 Kubernetes）：能轻松管理多个集群。
Red Hat 高级集群安全（针对 Kubernetes）：让集群更安全。
Red Hat Quay 私有注册平台：用于安全地存储和管理容器镜像。

对于想要最完整、功能最全的容器体验的人来说，Red Hat OpenShift 平台增强版把所有必要的工具都打包在一起了，无论是开发还是管理容器化应用平台，都能搞定。

Red Hat Marketplace

Red Hat 给大家搞了个 Red Hat Marketplace，里面有个认证的企业级Operator（就是一些能自动帮你搞定事儿的工具）目录，专门用来安装在 Red Hat OpenShift 集群上。你可以像逛商店一样，从这个精选的合集里看看、试试，然后挑出适合你集群需求的Operator。当你开始在 Red Hat OpenShift 集群上加新功能，或者和其他业务系统（比如存储）集成的时候，Red Hat Marketplace 里的Operator就能帮你搞定这些资源的管理。

在刚开始用容器的时候，像 Red Hat OpenShift 虚拟化这样的Operator能给集群提供各种功能，帮企业从虚拟机平滑过渡到容器。

随着容器的使用越来越多，很多企业虽然在探索容器技术，但还得继续管理和开发现有的或者新的虚拟机部署。在安装了 Red Hat OpenShift 虚拟化Operator的 Red Hat OpenShift 集群上，虚拟化应用和容器化应用都能在一个平台上搞定，这可太方便了，能大大助力你的容器之旅。

Red Hat OpenShift Web 控制台概览

Red Hat OpenShift 的 Web 控制台提供了一个图形用户界面，用来管理集群的各种任务。这个控制台用 Kubernetes API 和 OpenShift 扩展 API 来提供一个超棒的图形体验。控制台里的菜单、任务和功能，其实用命令行界面（CLI）也能搞定，不过 Web 控制台操作起来更简单，能让复杂的集群管理任务变得轻松很多。

CLI 工具

CLI 工具（就是命令行界面工具）给开发者提供了超多有用的命令，能帮他们搞定 Red Hat OpenShift 集群和应用的管理。每个命令都会被翻译成一个 API 调用，然后把结果直接显示在命令行里。

如果你对 Kubernetes 已经很熟悉了，可以用 kubectl 工具来管理 Red Hat OpenShift 集群。不过，我们用的是 oc 命令行工具，因为它能用上更多 Red Hat OpenShift 的独家功能。

常见的 oc 命令

下面就是一些最常用的 oc 命令啦：

oc login：登录到集群，就像你进门要先刷卡一样。
oc get：查看集群里的资源，比如 Pod、Service 等等，就像你去超市查货架上的商品。
oc describe：能详细地查看某个资源的信息，比如某个 Pod 的状态、配置等等，就像你仔细研究一个产品的说明书。
oc create：创建新的资源，比如新建一个 Deployment，就像你搭建一个新的乐高模型。
oc delete：删除不需要的资源，比如删掉一个不再需要的 Pod，就像你清理掉不需要的杂物。
oc apply：应用一个配置文件，更新集群里的资源，就像你给房间重新装修一下。
oc rollout：用来管理应用的部署版本，比如回滚到之前的版本，就像你后悔了，想回到之前的状态。
oc expose：把集群里的服务暴露出去，让外面能访问，就像你开了个窗口，让外面的人能看到里面的东西。
oc explain：这个命令超有用，能帮你解释 Kubernetes 资源的字段和配置，就像你有个随身的小助手，随时帮你解答疑惑。

Red Hat OpenShift 关键概念

当你在 Red Hat OpenShift 的 Web 控制台里逛来逛去的时候，知道一些入门的 OpenShift、Kubernetes 和容器术语，会帮你省不少事儿。下面这些基本概念能帮你更好地在 OpenShift Web 控制台里摸清门路。

项目（Projects）：这是 Kubernetes 的命名空间，但多了一些额外的注解，能让应用在多租户环境中划清界限。简单说，就是给不同的应用划分了各自的地盘，互不干扰。
操作符（Operators）：这是打包好的 Kubernetes 应用，能给集群增加新功能。就好比给你的工具箱里又添了一些新工具，让集群能干更多事儿。
Pod（Pods）：这是 Kubernetes 管理的容器化应用里最小的单位。一个 Pod 里可以有一个或多个容器，它们就像一个团队，一起完成任务。
部署（Deployments）：这是用来管理运行中应用的单位，能让你更细致地控制应用的运行状态。就好比你有一个遥控器，能随时调整应用的运行情况。
路由（Routes）：这是网络配置，能让集群外的资源访问你的应用和服务。就像在你的应用和外界之间搭了一座桥，让别人能找到你。
持久卷（Persistent Volume，PV）：这是存储资源，可以由动态供应器或者管理员来分配，用来定义对物理存储的访问。简单说，就是给你的应用准备了一个可以长期使用的存储空间。
持久卷声明（Persistent Volume Claims，PVC）：这是存储配置，能把 PV 绑定到一个命名空间里，这样 Pod 就能用它了。就好比你给 Pod 分配了一个专属的存储柜，它随时都能用。