DO280 OpenShift 管理完全指南 — 全部理论知识点系统梳理

欢迎来到 OpenShift 管理的世界！如果你正在准备红帽的 DO280 课程或 EX280 认证，或者你只是想系统地理解如何在生产环境中运维一个 Kubernetes 集群，那么你来对地方了。

这篇文章不是一份枯燥的命令清单，而是一份为你精心梳理的知识图谱。我们将深入探讨 OpenShift 的核心概念，从架构、权限、网络到存储和安全，为你构建一个坚实的理论基础。让我们一起揭开 OpenShift 的神秘面纱，成为一名真正的集群管理专家！

1. OpenShift 架构与核心概念

要管好 OpenShift，首先得理解它是什么，以及它与 Kubernetes 的关系。

控制平面 vs 数据平面

像所有现代分布式系统一样，OpenShift 集群也分为两个主要部分：

• 控制平面 (Control Plane): 这是集群的“大脑”。它负责做出所有决策，比如调度应用、管理集群状态、响应 API 请求等。控制平面由一组 master 节点组成，运行着 etcd (集群数据库)、API Server、Scheduler 和 Controller Manager 等关键组件。你的所有 oc 命令，首先都是与控制平面交互的。
• 数据平面 (Data Plane): 这是集群的“身体”或“劳动力”。它由所有的 worker 节点（也叫 compute 节点）组成，负责实际运行你的应用程序容器（Pods）。每个 worker 节点上都运行着 Kubelet（与控制平面通信）和 CRI-O（容器运行时）。

实际场景: 当你执行 oc run my-app --image=... 时，请求首先到达控制平面的 API Server，Scheduler 决定将这个 Pod 放在哪个 worker 节点上，然后该 worker 节点的 Kubelet 接收指令，通过 CRI-O 启动你的容器。你作为管理员，主要管理控制平面，而开发者则更关心他们的应用在数据平面上的运行情况。

Operator 框架（OLM）

Operator 是 OpenShift 的灵魂之一。它是一种封装、部署和管理 Kubernetes 应用的方法。简单来说，Operator = Controller + CRD (自定义资源定义)。

• CRD (Custom Resource Definition): 让你能像创建 Pod 或 Deployment 一样，创建自定义的资源类型，比如 Database、MonitoringStack 等。
• Controller: 一个持续运行的进程，它会“监视”你创建的自定义资源，并根据其定义执行相应的操作（比如创建一个数据库实例、配置监控告警等），就像一个自动化的人类运维专家。

Operator Lifecycle Manager (OLM): 这是 OpenShift 内置的 Operator 管理框架。它负责处理 Operator 的安装、升级和依赖管理，就像一个应用商店。你可以通过 OperatorHub 轻松地发现和安装各种成熟的 Operator。

实际场景: 你需要部署一个高可用的 PostgreSQL 集群。传统方式需要你手动配置 StatefulSet、Service、PV/PVC 等。使用 CrunchyData PostgreSQL Operator，你只需要创建一个简单的 YAML 文件，定义一个 PostgresCluster 类型的资源，Operator 就会自动为你完成所有复杂的配置和后续的备份、故障转移等运维工作。

apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: my-db
spec:
  instances:
    - name: instance1
      replicas: 2
  # ... 其他配置

项目（Project）vs 命名空间（Namespace）

在 Kubernetes 中，Namespace 是资源隔离的基本单位。OpenShift 在此基础上引入了 Project 的概念。

一个 Project 就是一个增强版的 Namespace。

结论: 在 OpenShift 环境中，始终使用 oc new-project 来创建工作空间。它为你提供了更丰富的用户管理和安全功能。

OpenShift vs Kubernetes 区别

OpenShift 是一个企业级的 Kubernetes 发行版。你可以把它理解为：OpenShift = Kubernetes Core + 企业级功能。

这些增强功能包括：

总结: Kubernetes 提供了强大的引擎，而 OpenShift 则提供了一辆功能完备、安全可靠的汽车。对于企业来说，OpenShift 降低了采用和运维 Kubernetes 的门槛。

2. 身份认证（Identity Providers）

OpenShift 自己不存储密码。它通过一个内置的 OAuth Server 来处理用户认证，这个 Server 再去和你配置的身份提供者 (Identity Provider, IdP) 对接。

OAuth 流程

1. 用户访问 Web Console 或使用 oc login。
2. 请求被重定向到 OpenShift 内置的 OAuth Server。
3. OAuth Server 显示一个登录页面，列出所有已配置的身份提供者（如 HTPasswd, LDAP, GitHub）。
4. 用户选择一个 IdP 并输入凭据（例如，用户名和密码）。
5. OAuth Server 将凭据转发给选定的 IdP 进行验证。
6. IdP 验证成功后，返回一个身份信息给 OAuth Server。
7. OAuth Server 在 OpenShift 内部创建两个关键对象：User 和 Identity，并将它们关联起来。
8. 最后，OAuth Server 返回一个 access_token 给用户，用户凭借此 token 进行后续操作。

HTPasswd / LDAP / GitHub / OpenID Connect

你可以配置多种身份提供者来满足不同需求：

• HTPasswd: 最简单的 IdP，基于一个纯文本文件，存储用户名和 bcrypt 加密的密码。适合快速测试或小型环境。
• LDAP/AD: 企业中最常见的 IdP，可以和公司的 Active Directory 或其他 LDAP 服务器集成，实现单点登录。
• GitHub: 允许用户使用他们的 GitHub 账号登录。适合开源项目或开发团队。
• OpenID Connect (OIDC): 一个现代的开放认证标准，可以与 Keycloak、Auth0、Okta 等身份认证服务集成。

配置 IdP 的核心是修改一个名为 cluster 的 OAuth 类型的集群级资源。

示例：配置 HTPasswd

# 1. 创建 htpasswd 文件
htpasswd -c -B -b users.htpasswd felix mypassword

# 2. 将文件存为 Secret
oc create secret generic htpasswd-secret --from-file=htpasswd=users.htpasswd -n openshift-config

# 3. 编辑 OAuth 配置
oc edit oauth cluster

在 spec.identityProviders 中添加以下内容：

- name: my_htpasswd_provider
  mappingMethod: claim
  type: HTPasswd
  htpasswd:
    fileData:
      name: htpasswd-secret # 引用上面创建的 Secret

mappingMethod 策略

这个策略决定了当一个用户通过 IdP 登录时，OpenShift 如何处理 User 和 Identity 对象的映射关系。

用户管理（User / Identity 对象）

• User: 代表一个真实的用户。它只包含用户名、全名等基本信息。User 对象是持久的。
• Identity: 代表用户在某个特定 IdP 中的身份记录。它包含了 IdP 的名称和用户在该 IdP 中的唯一标识。

一个 User 可以关联多个 Identity。这意味着同一个用户 felix 可以通过 HTPasswd 登录，也可以通过 LDAP 登录，最终都会映射到 OpenShift 中的同一个 User 对象，从而拥有相同的权限。

# 查看所有用户
oc get users

# 查看所有身份记录
oc get identities

3. RBAC 权限管理

认证 (Authentication) 解决了 “你是谁” 的问题，而授权 (Authorization) 则解决 “你能做什么” 的问题。OpenShift 使用 Kubernetes 的 RBAC (Role-Based Access Control) 模型进行授权。

RBAC 的核心思想是：谁 (Subject) 对什么 (Resource) 能做什么 (Verb)。

• Subject: 用户 (User)、组 (Group) 或服务账号 (ServiceAccount)。
• Resource: pods, deployments, services, nodes 等。
• Verb: get, list, watch, create, update, patch, delete。

ClusterRole vs Role

• Role: 定义了一组权限，但它是有命名空间范围的。一个 Role 只能授予对所在命名空间内资源的访问权限。
• ClusterRole: 同样定义了一组权限，但它是集群范围的。一个 ClusterRole 可以授予对集群级资源（如 nodes）的访问权限，也可以授予对所有命名空间中的资源（如 pods）的访问权限。

ClusterRoleBinding vs RoleBinding

Role 和 ClusterRole 只定义了“权限能做什么”，但并没有把这些权限授予给任何人。Binding 对象就是用来连接 Subject 和 Role/ClusterRole 的桥梁。

• RoleBinding: 将一个 Role 或 ClusterRole 的权限授予一个 Subject，但作用范围仅限于该 RoleBinding 所在的命名空间。
• ClusterRoleBinding: 将一个 ClusterRole 的权限授予一个 Subject，作用范围是整个集群。

关键组合：

内置角色

OpenShift 提供了几个非常有用的内置 ClusterRole：

组（Group）管理

直接给每个用户分配权限很繁琐。更好的做法是创建 Group，将用户添加到组中，然后给组分配权限。

# 创建一个名为 developers 的组
oc adm groups new developers

# 添加用户到组
oc adm groups add-users developers user1 user2

# 给 developers 组授予 project-a 的 edit 权限
oc policy add-role-to-group edit developers -n project-a

oc adm policy 命令族

这是管理 RBAC 的瑞士军刀，比写 YAML 快得多。

# 授予用户 jobs 集群管理员权限
oc adm policy add-cluster-role-to-user cluster-admin jobs

# 授予用户 wozniak 在项目 titan 中的 view 权限
oc policy add-role-to-user view wozniak -n titan

# 从组中移除 self-provisioner 权限（禁止所有用户自建项目）
oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauth

self-provisioner 的特殊性（autoupdate=false）

默认情况下，self-provisioner 角色通过一个名为 self-provisioners 的 ClusterRoleBinding 绑定到了 system:authenticated:oauth 这个系统组（即所有认证通过的用户）。

如果你想禁止所有普通用户创建项目，只移除绑定是不够的，因为 OpenShift 的 Operator 会自动恢复它。你必须给这个绑定加上一个注解：

# 关键一步：防止 Operator 自动恢复权限
oc annotate clusterrolebinding self-provisioners 'rbac.authorization.kubernetes.io/autoupdate=false' --overwrite

oc auth can-i 验证

如何确定一个用户到底有没有某个权限？oc auth can-i 是你的调试利器。

# 检查当前用户是否可以在 my-project 中创建 deployment
oc auth can-i create deployment -n my-project

# 模拟成用户 'bob' 来检查权限
oc auth can-i list pods --all-namespaces --as=bob

4. 资源管理

在一个多租户环境中，必须对资源进行限制，防止某个项目或应用耗尽整个集群的资源。

ResourceQuota（项目配额）

ResourceQuota 用于限制一个项目（命名空间）内可以使用的资源总量。

你可以限制两类资源：

1. 计算资源: limits.cpu, limits.memory, requests.cpu, requests.memory
2. 对象数量: pods, replicationcontrollers, services, secrets 等

示例：创建一个配额

# 创建一个名为 project-quota 的配额
# 限制 CPU request 总量为 10 核，内存 request 总量为 20Gi，最多 20 个 Pod
oc create quota project-quota \
  --hard=requests.cpu=10,requests.memory=20Gi,pods=20 \
  -n my-project

考试典型命令（含 OpenShift 特有配额类型）：

# 考试中经常需要包含 replicationcontrollers（对应 DeploymentConfig）
oc create quota ex280-quota \
  --hard=cpu=2,memory=1Gi,pods=3,replicationcontrollers=3,services=6

⚠️ replicationcontrollers 是 OpenShift 特有的配额类型。如果不包含此项，DeploymentConfig 创建的 RC 可能超出配额导致失败。这是考试高频陷阱！

当项目中的资源使用量接近配额时，用户会收到警告。当超过配额时，新的资源创建请求将被拒绝。

LimitRange（容器限制）

ResourceQuota 管总量，而 LimitRange 管单个 Pod 或 Container 的资源范围。

LimitRange 有三大作用：

1. 强制限制: 为项目中的每个容器设置 CPU/Memory 的 request 和 limit 的最大值和最小值。
2. 注入默认值: 如果一个容器没有声明 request 或 limit，LimitRange 会自动为它注入默认值。这非常重要，因为没有 request 的 Pod 无法被 HPA 监控，也可能被调度到不合适的节点上。
3. 控制资源比例: 可以设置 limit-to-request 的比例，例如限制 limit 最多是 request 的 4 倍。

示例：创建一个 LimitRange

apiVersion: v1
kind: LimitRange
metadata:
  name: resource-limits
spec:
  limits:
  - type: Container
    max:
      cpu: "2"
      memory: 2Gi
    min:
      cpu: 100m
      memory: 100Mi
    default:
      cpu: 300m
      memory: 512Mi
    defaultRequest:
      cpu: 200m
      memory: 256Mi

扩缩容（oc scale / HPA）

• 手动扩缩容 (oc scale): 简单直接，用于快速响应可预见的负载变化。

  # 将 my-app 这个 deployment 扩展到 5 个副本
  oc scale deployment/my-app --replicas=5
  

• 自动扩缩容 (HPA - Horizontal Pod Autoscaler): HPA 是一个控制器，它会定期检查 Pod 的指标（通常是 CPU 或内存使用率），并根据设定的阈值自动增加或减少副本数量。

  使用 HPA 的前提条件：

  1. Metrics Server 必须在集群中运行（OpenShift 默认安装）。
  2. 被伸缩的 Pod 必须设置了资源 requests（例如 requests.cpu），否则 HPA 不知道使用率的基准是多少。

  # 为 my-app 创建一个 HPA
  # 目标 CPU 使用率为 80%，副本数在 3 到 10 之间
  oc autoscale deployment/my-app --cpu-percent=80 --min=3 --max=10
  

5. 应用管理

OpenShift 提供了多种部署和管理应用的方式。

Deployment vs DeploymentConfig

这是 OpenShift 的一个历史特点。

• Deployment: 这是 Kubernetes 原生的应用部署资源。它使用 ReplicaSet 来管理 Pod 的生命周期。Deployment 的更新逻辑是在客户端（kubectl/oc）或控制器层面处理的。
• DeploymentConfig: 这是 OpenShift 特有的资源。它引入了 ReplicationController 和触发器 (Triggers) 的概念。DeploymentConfig 的更新逻辑主要在服务端（OpenShift API Server）处理的。

核心区别 - 触发器: DeploymentConfig 的最大特点是镜像变更触发器 (ImageChangeTrigger)。当 ImageStream 中引用的镜像有新版本时，可以自动触发一次新的部署。而 Deployment 需要借助外部 CI/CD 工具（如 ArgoCD, Tekton）来实现类似的功能。

滚动更新与回滚

两种资源都支持滚动更新（Rolling Update），即逐个替换旧 Pod，而不是一次性销毁所有旧 Pod，从而保证服务不中断。

如果新版本有问题，可以快速回滚：

# 查看部署历史
oc rollout history dc/my-app

# 回滚到上一个版本
oc rollout undo dc/my-app

对于 Deployment，命令是类似的 (oc rollout history deployment/my-app)。

CronJob

CronJob 是 Kubernetes 原生资源，用于运行定时任务，类似于 Linux 的 crontab。

apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-backup
spec:
  schedule: "0 2 * * *" # 每天凌晨 2:00 执行
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup-container
            image: backup-tool
            args: ["--run"]
          restartPolicy: OnFailure

Operator 安装与管理

如前所述，通过 OperatorHub 可以轻松安装和管理复杂应用。在 Web Console 中，管理员可以浏览市场，选择 Operator，并决定其安装模式：

• All namespaces on the cluster (cluster-wide): Operator 在 openshift-operators 命名空间中安装，可以管理集群中所有命名空间里的自定义资源。
• A specific namespace: Operator 安装在指定的命名空间中，只能管理该命名空间里的自定义资源。

Helm 包管理

Helm 是 Kubernetes 的包管理器，它将一组相关的 K8s 资源打包成一个称为 Chart 的模板。你可以通过 helm CLI 来安装、升级和管理这些应用。

# 添加一个 Chart 仓库
helm repo add bitnami https://charts.bitnami.com/bitnami

# 从仓库安装一个 nginx chart
helm install my-nginx bitnami/nginx

# 查看已安装的应用
helm list

# 卸载应用
helm uninstall my-nginx

6. 网络

容器网络是 OpenShift 中最复杂也最重要的部分之一。

Service 类型

Service 是一个抽象层，它为一组功能相同的 Pod 提供一个稳定的网络入口。无论后端 Pod 如何创建和销毁，Service 的 IP 地址和端口保持不变。

Route（OpenShift 特有）

Ingress 是 K8s 的标准七层路由，但实现依赖于 Ingress Controller。OpenShift 的 Route 是一个功能更强大、开箱即用的替代品。它由 OpenShift Ingress Controller (基于 HAProxy) 负责实现。

Route 负责将外部的 HTTP/HTTPS 请求转发到集群内部的 Service。

# 为 my-service 创建一个 Route，并自动分配一个主机名
oc expose service/my-service

# 为 my-service 创建一个 Route，并指定主机名
oc expose service/my-service --hostname=app.example.com

TLS 终止模式

Route 的一个强大功能是处理 TLS/SSL 加密。考试中经常需要创建带证书的 HTTPS Route。

newcert 脚本（考试专用）

EX280 考试环境中预装了 newcert 脚本，用于自动生成由集群 CA 签名的 TLS 证书。学习环境可用 openssl 自签证书替代。

# 考试环境：使用 newcert 生成证书
newcert
# 输入 Subject: /C=US/ST=NV/L=Hiko/O=CIA/OU=USAF/CN=classified.apps.ocp4.example.com
# 自动生成 .key 和 .crt 文件

# 创建 edge Route（指定证书）
oc create route edge --service oxcart \\
  --hostname classified.apps.ocp4.example.com \\
  --key classified.apps.ocp4.example.com.key \\
  --cert classified.apps.ocp4.example.com.crt

⚠️ 考试提示：newcert 是考试环境特有工具，不需要记忆 openssl 命令。但要记住 oc create route edge 的 --key 和 --cert 参数。

NetworkPolicy 网络策略

默认情况下，一个 OpenShift 项目中的所有 Pod 都可以相互通信。NetworkPolicy 是一种 Kubernetes 资源，允许你定义 Pod 之间以及 Pod 与其他网络端点之间的流量规则，实现微服务级的防火墙。

典型策略:

1. 默认拒绝所有 Ingress 流量:

   kind: NetworkPolicy
   spec:
     podSelector: {} # 选择项目中的所有 Pod
     policyTypes:
     - Ingress
   

2. 允许特定标签的 Pod 访问:

   # 允许带有 'role: frontend' 标签的 Pod 访问带有 'role: backend' 标签的 Pod 的 8080 端口
   kind: NetworkPolicy
   spec:
     podSelector:
       matchLabels:
         role: backend
     ingress:
     - from:
       - podSelector:
           matchLabels:
             role: frontend
       ports:
       - protocol: TCP
         port: 8080
   

7. 存储

容器是临时的，但数据是持久的。OpenShift 继承了 Kubernetes 的存储体系。

PV / PVC / StorageClass

• PersistentVolume (PV): 由管理员创建，代表了一块真实的物理存储（如 NFS 共享、iSCSI 卷、云硬盘）。它是一个集群资源，就像 Node 一样。PV 抽象了存储的实现细节。
• PersistentVolumeClaim (PVC): 由用户（开发者）创建，代表了对存储的“请求”。PVC 就像是向集群申请一块特定大小和访问模式的存储空间。它是一个命名空间资源。
• StorageClass: 允许动态供给 (Dynamic Provisioning) PV。当用户创建一个 PVC 时，如果 PVC 指定了一个 StorageClass，那么该 StorageClass 关联的 provisioner 会自动地为你创建一个匹配的 PV。

动态供给 vs 静态供给

• 静态供给:

  1. 管理员手动创建若干个 PV。
  2. 开发者创建 PVC。
  3. 系统将一个符合 PVC 要求的空闲 PV 绑定到该 PVC 上。
  • 优点: 控制力强，适用于已有存储。
  • 缺点: 需要管理员预先准备好存储，不够灵活。

• 动态供给:

  1. 管理员创建一个或多个 StorageClass，定义好存储类型（如 gp2 on AWS, nfs-client）。
  2. 开发者创建一个 PVC，并在 PVC 中指定 storageClassName。
  3. StorageClass 对应的存储插件会自动创建一个 PV 并与 PVC 绑定。
  • 优点: 按需创建，自动化，是云原生环境下的主流方式。
  • 缺点: 需要底层存储支持动态创建。

NFS 配置

在许多本地数据中心环境中，NFS 是提供持久化存储的常用方式。要使用 NFS，通常需要：

1. 在集群外部搭建一个 NFS Server，并配置好共享目录。
2. 在 OpenShift 集群中，可以采用静态供给（手动为每个 NFS 共享目录创建一个 PV），或者使用 nfs-client-provisioner (或类似的 Operator) 来实现动态供给。

静态供给 NFS PV 示例:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv-01
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteMany # NFS 支持多个 Pod 同时读写
  storageClassName: "nfs"
  nfs:
    path: /exports/data01 # NFS 服务器上的路径
    server: nfs-server.example.com # NFS 服务器地址

8. 安全

OpenShift 在 Kubernetes 的基础上提供了更强大的安全功能。

Secret 和 ConfigMap

• ConfigMap: 用于存储非敏感的配置数据，如配置文件、命令行参数等。数据以明文形式存储。
• Secret: 用于存储敏感数据，如密码、TLS 证书、API Token 等。数据以 Base64 编码的形式存储在 etcd 中（注意：Base64 只是编码，不是加密！）。在 etcd 层面可以配置加密，提高安全性。

两者都可以通过环境变量或卷挂载的方式注入到 Pod 中。

创建 Secret 示例:

# 从字面量创建
oc create secret generic db-password --from-literal=password='S3cr3tP@ssw0rd!'

# 从文件创建（用于 TLS 证书）
oc create secret tls my-tls-secret --cert=path/to/cert.pem --key=path/to/key.pem

ServiceAccount

ServiceAccount 为在 Pod 中运行的进程提供了一个身份。当 Pod 需要与 API Server 交互时（例如，查询其他 Pod 的信息），它会使用关联的 ServiceAccount 的 token 进行认证。

每个命名空间都有一个默认的 default ServiceAccount。最佳实践是为每个应用创建专用的 ServiceAccount，并只授予它完成任务所需的最小权限（Least Privilege）。

SCC（Security Context Constraints）

SCC 是 OpenShift 独有的、比 K8s PodSecurityPolicy (PSP) / PodSecurityAdmission (PSA) 更强大和灵活的安全机制。

SCC 定义了一组 Pod 在运行时可以拥有的权限，例如：

• 是否可以以 root 用户运行 (runAsUser)
• 是否可以使用 host network (allowHostNetwork)
• 可以挂载哪些类型的卷 (volumes)
• 是否可以运行特权容器 (privileged)

OpenShift 内置了几种 SCC，按权限从高到低排列：

SCC 通过 RBAC 机制授予给 User、Group 或 ServiceAccount。当一个 Pod 被创建时，系统会检查创建者（通常是 ServiceAccount）拥有的 SCC，并应用权限最宽松的那个。

示例：授予 ServiceAccount anyuid 权限

# 允许 my-app-sa 这个 ServiceAccount 以任意用户身份运行容器
oc adm policy add-scc-to-user anyuid -z my-app-sa -n my-project

SecurityContext

SecurityContext 是在 Pod 或 Container 级别定义的属性，用于更精细地控制安全行为。例如，你可以指定一个容器必须以哪个用户ID (runAsUser) 运行，或者添加/删除哪些 Linux 能力 (capabilities)。SecurityContext 的设置必须符合其关联的 SCC 的规定，否则 Pod 会创建失败。

9. 故障排查

排查是管理员的日常。掌握一套系统的方法至关重要。

Pod 状态诊断

oc get pods 输出中的 STATUS 字段是第一个线索。

核心排查命令

1. oc get events --sort-by='.lastTimestamp': 按时间顺序列出当前项目的所有事件。这是排查问题的黄金命令，通常能直接告诉你哪里出错了。
2. oc describe <resource_type> <resource_name>: 提供一个资源的详细信息，包括它的配置、状态和相关的 Events。对于诊断 Pending 和 ImagePullBackOff 的 Pod 至关重要。
3. oc logs <pod_name>: 查看容器的标准输出日志。--previous 标志可以查看上一个被杀死的容器的日志，对 CrashLoopBackOff 特别有用。

must-gather 工具

当遇到复杂的集群级别问题时，红帽支持可能会要求你提供 must-gather 的输出。这个命令会收集集群中大量的诊断信息（日志、资源定义、配置等）并打包成一个文件。

# 运行 must-gather，会在当前目录生成一个包含所有信息的目录
oc adm must-gather

10. 运维

日常运维工作。

项目模板（Project Template）

为了保证所有新创建的项目都有一套标准的基础配置（如 ResourceQuota, LimitRange, RoleBinding），你可以创建一个项目模板。

这是一个 OpenShift 特有的功能。管理员可以创建一个 Template 类型的资源，并将其配置为所有新项目的蓝图。

流程:

1. 使用 oc adm create-bootstrap-project-template 命令导出默认模板：

   oc adm create-bootstrap-project-template -o yaml > project-template.yaml
   

2. 编辑 project-template.yaml，添加你需要的资源（如 ResourceQuota, LimitRange, NetworkPolicy 等）。
3. 将模板创建到 openshift-config 命名空间：

   oc create -f project-template.yaml -n openshift-config
   

4. 编辑集群项目配置，引用模板：

   oc edit project.config.openshift.io/cluster
   # 设置 spec.projectRequestTemplate.name: <template-name>
   

之后，每当有用户执行 oc new-project，OpenShift 就会使用这个模板来初始化项目。

⚠️ 考试重点：oc adm create-bootstrap-project-template 是考试专用命令，生成包含默认 RoleBinding 的模板，再往里面添加 Quota/LimitRange。

集群升级概念

OpenShift 升级由 Cluster Version Operator (CVO) 负责。CVO 会监视 OpenShift 的上游镜像仓库，当有新版本发布时，管理员可以通过 Web Console 或 oc adm upgrade 命令启动升级流程。

升级是滚动进行的：

1. 首先升级控制平面节点（masters）。
2. 然后逐个升级数据平面节点（workers）。

CVO 会确保在升级过程中集群的核心服务保持可用。管理员可以指定一个更新频道（如 stable, fast, candidate）来控制接收更新的速度和稳定性。

备份与恢复基础

备份 OpenShift 集群主要涉及两个方面：

1. etcd 备份: 这是最关键的，因为 etcd 存储了整个集群的状态。OpenShift 提供了内置的脚本来执行 etcd 的快照和恢复。
2. 应用数据备份: 这指的是 PV 中的持久化数据。备份策略取决于底层存储技术（如 NFS、Ceph、云存储），需要使用相应的工具（如 Velero、存储厂商的快照功能）来完成。

监控与日志

• 监控: OpenShift 内置了一套基于 Prometheus、Alertmanager 和 Grafana 的完整监控栈。
  • Prometheus: 负责抓取和存储集群及应用的时间序列指标数据。
  • Alertmanager: 负责处理 Prometheus 发出的告警，进行去重、分组，并通过 Email, Slack 等方式通知管理员。
  • Grafana: 提供丰富的仪表盘来可视化监控数据。
• 日志: OpenShift 集群日志由 Cluster Logging Operator 负责，它通常部署一套 EFK/Loki 栈。
  • Fluentd (Vector): 在每个节点上作为代理运行，负责收集容器日志。
  • Elasticsearch / Loki: 负责存储和索引日志。
  • Kibana: 提供一个 UI 来搜索和分析日志。

管理员可以通过 Web Console 轻松访问这些监控和日志系统。

结语

我们已经系统地走过了 DO280 涉及的所有核心理论知识点。从宏观的架构到微观的安全配置，从日常的应用管理到复杂的故障排查，你现在应该对 OpenShift 有了一个全面而深入的理解。

理论是实践的基石。现在，打开你的终端，启动你的集群，把这些知识运用到实际操作中去吧！祝你在 OpenShift 的旅程中一切顺利！