#Operator

#概览

基于 OLM (Operator Lifecycle Manager) 框架，OperatorHub 提供了用于管理 Operators 安装、升级和生命周期的统一界面。
管理员可以使用 OperatorHub 安装和管理 Operators，从而为 Kubernetes 应用实现完整的生命周期自动化，包括创建、更新和删除。

OLM 主要由以下组件和 CRD 组成：

• OLM (olm-operator)：管理 Operators 的完整生命周期，包括安装、升级和版本冲突检测。
• Catalog Operator：管理 Operator catalog，并生成相应的 InstallPlan。
• CatalogSource：一种命名空间级别的 CRD，用于管理 Operator catalog 来源并提供 Operator 元数据（例如版本信息、受管 CRD）。平台提供 3 个默认的 CatalogSource：system、platform 和 custom。system 中的 Operators 不会显示在 OperatorHub 中。
• ClusterServiceVersion (CSV)：一种命名空间级别的 CRD，用于描述 Operator 的特定版本，包括它所需的资源、CRD 和权限。
• Subscription：一种命名空间级别的 CRD，用于描述所订阅的 Operator、其来源、获取通道和升级策略。
• InstallPlan：一种命名空间级别的 CRD，用于描述需要执行的实际安装操作（例如创建 Deployments、CRD 和 RBAC）。只有在 InstallPlan 获得批准后，Operator 才会被安装或升级。

#Operator 来源

为了明确 OperatorHub 中不同 Operators 的生命周期策略，平台提供 5 种来源类型：

1. 由 提供和维护，包括完整的生命周期管理、安全更新、技术支持和 SLA 承诺。

2. Curated 从开源社区中精选，保持与社区版本一致，不修改代码，也不重新编译。 提供指导和安全更新，但不保证 SLA 或生命周期管理。

3. Community 由开源社区提供，定期更新以确保可安装性，但不保证功能完整性；不提供 SLA 或 支持。

4. Marketplace 由经过 认证的第三方厂商提供和维护。 提供平台集成支持，而核心维护由厂商负责。

5. Custom 由用户自行开发并上传，以满足自定义使用场景需求。

#安装前准备

在安装 Operator 之前，需要了解以下关键参数：

#安装模式

OLM 提供三种安装模式：

• Single Namespace
• Multi Namespace
• Cluster

推荐使用 Cluster 模式（AllNamespaces）。 平台最终将升级到 OLM v1，而 OLM v1 仅支持 AllNamespaces 安装模式。因此，应强烈避免使用 SingleNamespace 和 MultiNamespace。

#更新通道

如果某个 Operator 提供多个更新通道，可以选择订阅其中一个通道，例如 stable。

#批准策略

可选项：Automatic 或 Manual。

• Automatic：当所选通道中发布新版本时，OLM 会自动升级 Operator。
• Manual：当有新版本可用时，OLM 会创建一个升级请求，必须由集群管理员手动批准后才会执行升级。

注意：来自 的 Operators 仅支持 Manual 模式；否则安装将失败。

#安装位置

建议为每个 Operator 创建一个单独的命名空间。

如果多个 Operators 共享同一个命名空间，它们的 Subscriptions 可能会被解析到同一个 InstallPlan 中：

• 如果该命名空间中的某个 InstallPlan 需要 Manual 批准且仍处于 pending 状态，它可能会阻塞同一 InstallPlan 中其他 Subscriptions 的自动升级。

#通过 Web Console 安装

1. 登录 Web Console，并切换到 Administrator 视图。

2. 导航到 Marketplace > OperatorHub。

3. 如果状态为 Absent：

   • 从 Customer Portal 下载 Operator package，或联系支持团队。
   • 使用 violet 将 package 上传到目标集群（参见 CLI）。
   • 在 Marketplace > Upload Packages 页面，切换到 Operator 选项卡并确认上传。

4. 如果状态为 Ready，单击 Install，然后按照 Operator 的用户指南操作。

#通过 YAML 安装

以下示例演示了来自 （仅支持 Manual）和非 来源（支持 Manual 或 Automatic）的 Operator 安装方式。

#手动

harbor-ce-operator 来自 ，且仅支持 Manual 批准。
在 Manual 模式下，即使发布了新版本，Operator 也不会自动升级。你必须先手动 Approve，然后 OLM 才会执行升级。

#1. 检查可用版本

(
  echo -e "CHANNEL\tNAME\tVERSION"
  kubectl get packagemanifest harbor-ce-operator -o json | jq -r '
    .status.channels[] |
    .name as $channel |
    .entries[] |
    [$channel, .name, .version] | @tsv
  '
) | column -t -s $'\t'

示例输出：

CHANNEL   NAME                         VERSION
harbor-2  harbor-ce-operator.v2.12.11  2.12.11
harbor-2  harbor-ce-operator.v2.12.10  2.12.10
stable    harbor-ce-operator.v2.12.11  2.12.11
stable    harbor-ce-operator.v2.12.10  2.12.10

字段说明：

• CHANNEL：Operator 通道名称
• NAME：CSV 资源名称
• VERSION：Operator 版本

#2. 确认 catalogSource

kubectl get packagemanifests harbor-ce-operator -ojsonpath='{.status.catalogSource}'

示例输出：

platform

这表示 harbor-ce-operator 来自 platform catalogSource。

#3. 创建命名空间

kubectl create namespace harbor-ce-operator

#4. 创建 Subscription

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  annotations:
    cpaas.io/target-namespaces: ""
  name: harbor-ce-operator-subs
  namespace: harbor-ce-operator
spec:
  channel: stable
  installPlanApproval: Manual
  name: harbor-ce-operator
  source: platform
  sourceNamespace: cpaas-system
  startingCSV: harbor-ce-operator.v2.12.11

字段说明：

• annotation cpaas.io/target-namespaces：建议设置为空；为空表示集群范围安装。
• .metadata.name：Subscription 名称（符合 DNS 规范，最长 253 个字符）。
• .metadata.namespace：Operator 将要安装到的命名空间。
• .spec.channel：订阅的 Operator 通道。
• .spec.installPlanApproval：批准策略（Manual 或 Automatic）。这里 Manual 表示安装/升级需要手动批准。
• .spec.source：Operator catalogSource。
• .spec.sourceNamespace：必须设置为 cpaas-system，因为平台提供的所有 catalogSource 都位于该命名空间中。
• .spec.startingCSV：指定 Manual 批准时要安装的版本；如果为空，则默认使用该通道中的最新版本。Automatic 模式下不需要此字段。

#5. 检查 Subscription 状态

kubectl -n harbor-ce-operator get subscriptions harbor-ce-operator-subs -o yaml

关键信息输出：

• .status.state：UpgradePending 表示 Operator 正在等待安装或升级。
• Condition InstallPlanPending = True：等待手动批准。
• .status.currentCSV：当前订阅的最新 CSV。
• .status.installPlanRef：关联的 InstallPlan；必须先批准后才能继续安装。

#6. 批准 InstallPlan

kubectl -n harbor-ce-operator get installplan \
  "$(kubectl -n harbor-ce-operator get subscriptions harbor-ce-operator-subs -o jsonpath='{.status.installPlanRef.name}')"

示例输出：

NAME            CSV                           APPROVAL   APPROVED
install-27t29   harbor-ce-operator.v2.12.11   Manual     false

手动批准：

PLAN="$(kubectl -n harbor-ce-operator get subscription harbor-ce-operator-subs -o jsonpath='{.status.installPlanRef.name}')"
kubectl -n harbor-ce-operator patch installplan "$PLAN" --type=json -p='[{"op": "replace", "path": "/spec/approved", "value": true}]'

等待 CSV 创建；Phase 变为 Succeeded：

kubectl -n harbor-ce-operator get csv

示例输出：

NAME                          DISPLAY                  VERSION   REPLACES                      PHASE
harbor-ce-operator.v2.12.11   Alauda Build of Harbor   2.12.11   harbor-ce-operator.v2.12.10   Succeeded

字段说明：

• NAME：已安装的 CSV 名称
• DISPLAY：Operator 显示名称
• VERSION：Operator 版本
• REPLACES：升级时被替换的 CSV
• PHASE：安装状态（Succeeded 表示成功）

#自动

clickhouse-operator 来自非 来源，其批准策略可以设置为 Automatic。
在 Automatic 模式下，当发布新版本时，Operator 会自动升级，无需手动批准。

#1. 检查可用版本

(
  echo -e "CHANNEL\tNAME\tVERSION"
  kubectl get packagemanifest clickhouse-operator -o json | jq -r '
    .status.channels[] |
    .name as $channel |
    .entries[] |
    [$channel, .name, .version] | @tsv
  '
) | column -t -s $'\t'

示例输出：

CHANNEL   NAME                           VERSION
stable    clickhouse-operator.v0.18.2    0.18.2

#2. 确认 catalogSource

kubectl get packagemanifests clickhouse-operator -ojsonpath='{.status.catalogSource}'

示例输出：

platform

这表示 clickhouse-operator 来自 platform catalogSource。

#3. 创建命名空间

kubectl create namespace clickhouse-operator

#4. 创建 Subscription

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  annotations:
    cpaas.io/target-namespaces: ""
  name: clickhouse-operator-subs
  namespace: clickhouse-operator
spec:
  channel: stable
  installPlanApproval: Automatic
  name: clickhouse-operator
  source: platform
  sourceNamespace: cpaas-system

字段说明与 Manual 中相同。

#5. 检查 Subscription 状态

kubectl -n clickhouse-operator get subscriptions clickhouse-operator-subs -oyaml

#6. 验证 CSV

kubectl -n clickhouse-operator get csv

示例输出：

NAME                           DISPLAY                VERSION   PHASE
clickhouse-operator.v0.18.2    ClickHouse Operator    0.18.2    Succeeded

安装成功。

#高级 Subscription 配置

以下配置适用于批准策略为 Manual 或 Automatic 的 Subscriptions。

#配置 Operator Pod 调度

要控制 Operator Pod 运行的位置，可在 Subscription.spec.config 中配置调度设置。
该配置仅影响 OLM 管理的 Operator deployment。
它不控制 Operator 安装后创建的实例或自定义资源的调度。
要控制这些工作负载，请参考对应 Operator 的文档。

建议：当你希望 Operator 运行在 infra 节点或其他专用节点上时，使用此配置。

前提条件：目标节点必须已具备所需标签。如果目标节点带有 taint，请配置相应的 toleration。

可用字段：

• .spec.config.nodeSelector：可选。选择 Operator Pod 可以运行的节点。
• .spec.config.tolerations：可选。当 taint 匹配时，允许 Operator Pod 运行在带 taint 的节点上。

Subscription 示例片段：

spec:
  config:
    nodeSelector:
      node-role.kubernetes.io/infra: ""
    tolerations:
      - key: node-role.kubernetes.io/infra
        operator: Equal
        value: reserved
        effect: NoSchedule

如果 Operator 已经安装，可以 patch 现有的 Subscription：

kubectl patch subscription <subscription-name> -n <operator-namespace> --type='merge' -p '
{
  "spec": {
    "config": {
      "nodeSelector": {
        "node-role.kubernetes.io/infra": ""
      },
      "tolerations": [
        {
          "effect": "NoSchedule",
          "key": "node-role.kubernetes.io/infra",
          "operator": "Equal",
          "value": "reserved"
        }
      ]
    }
  }
}'

#升级流程

升级流程从上传新版本 Operator 开始。

上传完成后，请等待大约 10–15 分钟，以便平台同步新版本信息。

同步完成后，升级将按照 Subscription 中配置的策略执行：

• 如果 Operator 的 Approval Strategy 设置为 Automatic，则 Operator 会自动升级。

• 如果策略设置为 Manual，则必须手动批准升级请求。你可以选择以下升级方式之一：

  • Batch Upgrade：在 Platform Management > Cluster Management > Cluster > Features 页面执行升级。
  • Individual Upgrade：在 OperatorHub 中手动批准升级请求。

注意：只有 提供的 Operators 支持批量升级。