7.2. 组件和架构

在 Operator Lifecycle Manager（OLM）1.0 中，集群管理员在 Operator 的自定义资源(CR)中以声明性方式设置 Operator 的目标版本。

如果在 Operator 的 CR 中指定频道，OLM 1.0 会从指定频道安装最新版本。当向指定的频道发布更新时，OLM 1.0 会自动更新至该频道的最新发行版本。

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: quay-example
spec:
  packageName: quay-operator
  channel: stable-3.8 1

如果在 CR 中指定 Operator 的目标版本，OLM 1.0 将安装指定的版本。当在 Operator 的 CR 中指定目标版本时，OLM 1.0 在向目录发布更新时不会更改目标版本。

如果要更新集群中安装的 Operator 版本，您必须手动更新 Operator 的 CR。指定 Operator 的目标版本将 Operator 的版本固定到指定的发行版本。

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: quay-example
spec:
  packageName: quay-operator
  version: 3.8.12 1

如果要更改 Operator 的安装版本，请将 Operator 的 CR 编辑为所需的目标版本。

您可以运行以下命令来检查 Operator 的目录内容，包括可用版本和频道：

$ oc get package <catalog_name>-<package_name> -o yaml

创建或更新 CR 后，运行以下命令来创建或修改 Operator：

$ oc apply -f <extension_name>.yaml

在 API 服务器接受 Bundle 对象后，捆绑包被视为 RukPak 系统的其余部分的不可变工件。这个行为强制捆绑包代表集群中要 source 的一些唯一静态内容。用户可以放心，特定捆绑包指向特定的清单集合，在没有创建新捆绑包的情况下无法更新。对于由嵌入式 BundleTemplate 对象创建的单机捆绑包和动态捆绑包，此属性为 true。

捆绑包的不可变性由核心 RukPak webhook 强制执行。此 webhook 监视 Bundle 对象事件，并对捆绑包的任何更新，检查现有捆绑包的 spec 字段是否与建议的捆绑包中的 spec 字段相同。如果它们不相等，则 Webhook 将拒绝更新。在捆绑包的生命周期中，其他 Bundle 对象字段（如 metadata 或 status）会更新，它只是被视为不可变的 spec 字段。

应用 Bundle 对象，然后尝试更新其 spec 会失败。例如，以下示例会创建一个捆绑包：

$ oc apply -f -<<EOF
apiVersion: core.rukpak.io/v1alpha1
kind: Bundle
metadata:
  name: combo-tag-ref
spec:
  source:
    type: git
    git:
      ref:
        tag: v0.0.2
      repository: https://github.com/operator-framework/combo
  provisionerClassName: core-rukpak-io-plain
EOF

bundle.core.rukpak.io/combo-tag-ref created

然后，修补捆绑包以指向较新的标签会返回错误：

$ oc patch bundle combo-tag-ref --type='merge' -p '{"spec":{"source":{"git":{"ref":{"tag":"v0.0.3"}}}}}'

Error from server (bundle.spec is immutable): admission webhook "vbundles.core.rukpak.io" denied the request: bundle.spec is immutable

核心 RukPak 准入 Webhook 会拒绝补丁，因为捆绑包的 spec 是不可变的。推荐的修改捆绑包内容的方法是通过创建一个新的 Bundle 对象而不是原位更新。

进一步的不可变注意事项

虽然 Bundle 对象的 spec 字段不可变，但 BundleDeployment 对象仍有可能变为较新的捆绑包内容版本，而无需更改底层 spec 字段。这个非预期的行为可能会在以下情况中出现：

如果发生这种情况，步骤 2 中的新内容会因为第 3 步而解包。捆绑包部署会检测更改，并探测到新版本的内容。

这与 pod 的行为类似，其中一个 pod 的容器镜像使用标签，标签将移到不同的摘要中，然后在将来将现有 pod 重新调度到其他节点上。此时，节点会将新镜像拉取到新摘要中，并在没有用户明确要求的情况下运行不同的镜像。

为了确定底层 Bundle spec 内容没有改变，请在创建捆绑包时使用基于摘要的镜像或 Git 提交引用。

RukPak 中的普通捆绑包是给定目录中静态、任意的 Kubernetes YAML 清单的集合。

当前实施的普通捆绑包格式是 plain+v0 格式。捆绑包格式的名称 (plain+v0) 组合了捆绑包类型 (plain) 和当前模式版本 (v0)。

例如，下面显示了 plain+v0 捆绑包中的文件树。它必须具有一个 manifests/ 目录，其中包含部署应用程序所需的 Kubernetes 资源。

$ tree manifests

manifests
├── namespace.yaml
├── service_account.yaml
├── cluster_role.yaml
├── cluster_role_binding.yaml
└── deployment.yaml

静态清单必须位于 manifests/ 目录中，其中至少包含一个资源，以便捆绑包是置备程序可以解包的有效 plain+v0 捆绑包。manifests/ 目录还必须是扁平的；所有清单都必须位于顶层，且无子目录。

registry 捆绑包或 registry+v1 捆绑包包含一组以旧 Operator Lifecycle Manager (OLM) 捆绑包格式组织的静态 Kubernetes YAML 清单。

用户想要安装具有以下依赖关系的软件包 A 和 B：

此外，用户希望将 A 的版本固定到 v0.1.0。

传递给 OLM 1.0 的软件包和限制

用户想要安装具有以下依赖关系的软件包 A 和 B：

此外，用户希望将 A 的版本固定到 v0.1.0。

传递给 OLM 1.0 的软件包和限制

Operator Lifecycle Manager (OLM) 1.0 默认不包括红帽提供的 Operator 目录。如果要在集群中添加红帽提供的目录，请为目录创建一个自定义资源 (CR)，并将其应用到集群。以下自定义资源 (CR) 示例演示了如何为 OLM 1.0 创建目录资源。

apiVersion: catalogd.operatorframework.io/v1alpha1
kind: Catalog
metadata:
  name: redhat-operators
spec:
  source:
    type: image
    image:
      ref: registry.redhat.io/redhat/redhat-operator-index:v4.14

apiVersion: catalogd.operatorframework.io/v1alpha1
kind: Catalog
metadata:
  name: certified-operators
spec:
  source:
    type: image
    image:
      ref: registry.redhat.io/redhat/certified-operator-index:v4.14

apiVersion: catalogd.operatorframework.io/v1alpha1
kind: Catalog
metadata:
  name: community-operators
spec:
  source:
    type: image
    image:
      ref: registry.redhat.io/redhat/community-operator-index:v4.14

以下命令在集群中添加目录：

$ oc apply -f <catalog_name>.yaml 1