5.8. 使用捆绑包镜像
您可以使用 Operator SDK 在 Operator Lifecycle Manager(OLM)中以捆绑格式(Bundle Format)打包、部署和升级 Operator。
5.8.1. 捆绑 Operator
Operator 捆绑包格式是 Operator SDK 和 Operator Lifecycle Manager(OLM)的默认打包方法。您可以使用 Operator SDK 来构建和推送 Operator 项目作为捆绑包镜像,使 Operator 可供 OLM 使用。
先决条件
- 在开发工作站上安装 operator SDK CLI
-
已安装 OpenShift CLI(
oc
))v4.8+ - 使用 Operator SDK 初始化 operator 项目
- 如果 Operator 是基于 Go 的,则必须更新您的项目以使用支持的镜像在 OpenShift Container Platform 上运行
流程
在 Operator 项目目录中运行以下
make
命令来构建和推送 Operator 镜像。在以下步骤中修改IMG
参数来引用您可访问的库。您可以获取在存储库站点(如 Quay.io)存储容器的帐户。构建镜像:
$ make docker-build IMG=<registry>/<user>/<operator_image_name>:<tag>
注意由 SDK 为 Operator 生成的 Dockerfile 需要为
go build
明确引用GOARCH=amd64
。这可以在非 AMD64 构架中使用GOARCH=$TARGETARCH
。Docker 自动将环境变量设置为-platform
指定的值。对于 Buildah,需要使用-build-arg
来实现这一目的。如需更多信息,请参阅多个架构。将镜像推送到存储库:
$ make docker-push IMG=<registry>/<user>/<operator_image_name>:<tag>
运行
make bundle
命令创建 Operator 捆绑包清单,该命令调用多个命令,其中包括 Operator SDKgenerate bundle
和bundle validate
子命令:$ make bundle IMG=<registry>/<user>/<operator_image_name>:<tag>
Operator 的捆绑包清单描述了如何显示、创建和管理应用程序。
make bundle
命令在 Operator 项目中创建以下文件和目录:-
包含
ClusterServiceVersion
对象的捆绑包清单目录,名为bundle/manifests
-
名为
bundle/metadata
的捆绑包元数据目录 -
config/crd
目录中的所有自定义资源定义(CRD) -
一个 Dockerfile
bundle.Dockerfile
然后,使用
operator-sdk bundle validate
自动验证这些文件,以确保磁盘上的捆绑包的格式是正确的。-
包含
运行以下命令来构建和推送捆绑包镜像。OLM 使用索引镜像来消耗 Operator 捆绑包,该镜像引用一个或多个捆绑包镜像。
构建捆绑包镜像。使用您要推送镜像的 registry、用户命名空间和镜像标签的详情,设置
BUNDLE_IMG
:$ make bundle-build BUNDLE_IMG=<registry>/<user>/<bundle_image_name>:<tag>
推送捆绑包镜像:
$ docker push <registry>/<user>/<bundle_image_name>:<tag>
5.8.2. 使用 Operator Lifecycle Manager 部署 Operator
Operator Lifecycle Manager(OLM)可帮助您在 Kubernetes 集群中安装、更新和管理 Operator 及其相关服务的生命周期。OLM 在 OpenShift Container Platform 上默认安装,并作为 Kubernetes 扩展运行,以便您可以在没有任何额外工具的情况下将 Web 控制台和 OpenShift CLI(oc
)用于所有 Operator 生命周期管理功能。
Operator Bundle Format 是 Operator SDK 和 OLM 的默认打包方法。您可以使用 Operator SDK 在 OLM 上快速运行捆绑包镜像,以确保它正确运行。
先决条件
- 在开发工作站上安装 operator SDK CLI
- 构建并推送到 registry 的 Operator 捆绑包镜像
-
OLM安装在一个基于 Kubernetes 的集群上(如果使用
apiextensions.k8s.io/v1
CRD,则为 v1.16.0 或更新版本,如 OpenShift Container Platform 4.8) -
使用具有
cluster-admin
权限的账户使用oc
登录到集群 - 如果 Operator 是基于 Go 的,则必须更新您的项目以使用支持的镜像在 OpenShift Container Platform 上运行
流程
输入以下命令在集群中运行 Operator:
$ operator-sdk run bundle \ [-n <namespace>] \1 <registry>/<user>/<bundle_image_name>:<tag>
- 1
- 默认情况下,命令会在
~/.kube/config
文件中当前活跃的项目中安装 Operator。您可以添加-n
标志来为安装设置不同的命名空间范围。
这个命令执行以下操作:
- 创建引用捆绑包镜像的索引镜像。索引镜像不透明且具有临时性,但准确反映了如何将捆绑包添加到生产中的目录中。
- 创建指向新索引镜像的目录源,以便 OperatorHub 能够发现 Operator。
-
通过创建一个
OperatorGroup
、Subscription
、InstallPlan
和所有其他必要的对象(包括 RBAC),将 Operator 部署到集群中。
5.8.3. 发布包含捆绑 Operator 的目录
要安装和管理 Operator,Operator Lifecycle Manager(OLM)要求 Operator 捆绑包列在索引镜像中,该镜像由集群中的目录引用。作为 Operator 作者,您可以使用 Operator SDK 为 Operator 及其所有依赖项创建一个包含捆绑包的索引。这可用于测试远程集群并发布到容器 registry。
Operator SDK 使用 opm
CLI 来简化索引镜像的创建。不要求具备 opm
命令相关经验。对于高级用例,可以直接使用 opm
命令,而不是 Operator SDK。
先决条件
- 在开发工作站上安装 operator SDK CLI
- 构建并推送到 registry 的 Operator 捆绑包镜像
-
OLM安装在一个基于 Kubernetes 的集群上(如果使用
apiextensions.k8s.io/v1
CRD,则为 v1.16.0 或更新版本,如 OpenShift Container Platform 4.8) -
使用具有
cluster-admin
权限的账户使用oc
登录到集群
流程
在 Operator 项目目录中运行以下
make
命令,以构建包含 Operator 捆绑包的索引镜像:$ make catalog-build CATALOG_IMG=<registry>/<user>/<index_image_name>:<tag>
其中
CATALOG_IMG
参数引用您有权访问的存储库。您可以获取在存储库站点(如 Quay.io)存储容器的帐户。将构建的索引镜像推送到存储库:
$ make catalog-push CATALOG_IMG=<registry>/<user>/<index_image_name>:<tag>
提示如果您要同时按顺序执行多个操作,您可以使用 Operator SDK
make
命令。例如,如果您还没有为 Operator 项目构建捆绑包镜像,您可以使用以下语法构建和推送捆绑包镜像和索引镜像:$ make bundle-build bundle-push catalog-build catalog-push \ BUNDLE_IMG=<bundle_image_pull_spec> \ CATALOG_IMG=<index_image_pull_spec>
另外,您可以将
Makefile
中的IMAGE_TAG_BASE
字段设置为现有的存储库:IMAGE_TAG_BASE=quay.io/example/my-operator
然后,您可以使用以下语法使用自动生成的名称构建和推送镜像,例如捆绑包镜像
quay.io/example/my-operator-bundle:v0.0.1
和quay.io/example/my-operator-catalog:v0.0.1
作为索引镜像:$ make bundle-build bundle-push catalog-build catalog-push
定义一个
CatalogSource
对象来引用您刚才生成的索引镜像,然后使用oc apply
命令或 Web 控制台创建对象:CatalogSource
YAML 示例apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: cs-memcached namespace: default spec: displayName: My Test publisher: Company sourceType: grpc image: quay.io/example/memcached-catalog:v0.0.1 1 updateStrategy: registryPoll: interval: 10m
- 1
- 将
image
设置为您之前与CATALOG_IMG
参数搭配使用的镜像拉取规格。
检查目录源:
$ oc get catalogsource
输出示例
NAME DISPLAY TYPE PUBLISHER AGE cs-memcached My Test grpc Company 4h31m
验证
使用您的目录安装 Operator:
定义
OperatorGroup
对象并使用oc apply
命令或 Web 控制台创建它:OperatorGroup
YAML 示例apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: my-test namespace: default spec: targetNamespaces: - default
定义
Subscription
对象并使用oc apply
命令或 Web 控制台创建它:Subscription
YAML 示例apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: catalogtest namespace: default spec: channel: "alpha" installPlanApproval: Manual name: catalog source: cs-memcached sourceNamespace: default startingCSV: memcached-operator.v0.0.1
验证已安装的 Operator 是否正在运行:
检查 Operator 组:
$ oc get og
输出示例
NAME AGE my-test 4h40m
检查集群服务版本(CSV):
$ oc get csv
输出示例
NAME DISPLAY VERSION REPLACES PHASE memcached-operator.v0.0.1 Test 0.0.1 Succeeded
检查 Operator 的 pod:
$ oc get pods
输出示例
NAME READY STATUS RESTARTS AGE 9098d908802769fbde8bd45255e69710a9f8420a8f3d814abe88b68f8ervdj6 0/1 Completed 0 4h33m catalog-controller-manager-7fd5b7b987-69s4n 2/2 Running 0 4h32m cs-memcached-7622r 1/1 Running 0 4h33m
其他资源
-
如需了解更多高级用例,请参阅管理自定义目录以了解有关
opm
CLI 直接使用的详情。
5.8.4. 在 Operator Lifecycle Manager 中测试 Operator 升级
您可以使用 Operator Lifecycle Manager(OLM)集成 Operator SDK 来快速测试 Operator 升级,而无需手动管理索引镜像和目录源。
run bundle-upgrade
子命令通过为以后的版本指定捆绑包镜像来自动触发已安装的 Operator 以升级到更新的版本。
先决条件
-
使用
run bundle
子命令或传统的 OLM 安装安装 OLM 的 operator - 代表已安装 Operator 的更新版本的捆绑包镜像
流程
如果 Operator 尚未安装 OLM,请使用
run bundle
子命令或传统的 OLM 安装安装较早的版本。注意如果通过传统方式使用 OLM 安装捆绑包的早期版本,则您要升级到的较新的捆绑包不能存在于目录源引用的索引镜像中。否则,运行
run bundle-upgrade
子命令将导致 registry pod 失败,因为较新的捆绑包已被提供软件包和集群服务版本的索引引用。例如,您可以通过指定更早的捆绑包镜像,为 Memcached Operator 使用以下
run bundle
子命令:$ operator-sdk run bundle <registry>/<user>/memcached-operator:v0.0.1
输出示例
INFO[0009] Successfully created registry pod: quay-io-demo-memcached-operator-v0-0-1 INFO[0009] Created CatalogSource: memcached-operator-catalog INFO[0010] OperatorGroup "operator-sdk-og" created INFO[0010] Created Subscription: memcached-operator-v0-0-1-sub INFO[0013] Approved InstallPlan install-bqggr for the Subscription: memcached-operator-v0-0-1-sub INFO[0013] Waiting for ClusterServiceVersion "my-project/memcached-operator.v0.0.1" to reach 'Succeeded' phase INFO[0013] Waiting for ClusterServiceVersion "my-project/memcached-operator.v0.0.1" to appear INFO[0019] Found ClusterServiceVersion "my-project/memcached-operator.v0.0.1" phase: Succeeded
通过为后续的 Operator 版本指定捆绑包镜像来升级已安装的 Operator:
$ operator-sdk run bundle-upgrade <registry>/<user>/memcached-operator:v0.0.2
输出示例
INFO[0002] Found existing subscription with name memcached-operator-v0-0-1-sub and namespace my-project INFO[0002] Found existing catalog source with name memcached-operator-catalog and namespace my-project INFO[0009] Successfully created registry pod: quay-io-demo-memcached-operator-v0-0-2 INFO[0009] Updated catalog source memcached-operator-catalog with address and annotations INFO[0010] Deleted previous registry pod with name "quay-io-demo-memcached-operator-v0-0-1" INFO[0041] Approved InstallPlan install-gvcjh for the Subscription: memcached-operator-v0-0-1-sub INFO[0042] Waiting for ClusterServiceVersion "my-project/memcached-operator.v0.0.2" to reach 'Succeeded' phase INFO[0042] Found ClusterServiceVersion "my-project/memcached-operator.v0.0.2" phase: InstallReady INFO[0043] Found ClusterServiceVersion "my-project/memcached-operator.v0.0.2" phase: Installing INFO[0044] Found ClusterServiceVersion "my-project/memcached-operator.v0.0.2" phase: Succeeded INFO[0044] Successfully upgraded to "memcached-operator.v0.0.2"
清理已安装的 Operator:
$ operator-sdk cleanup memcached-operator
5.8.5. 控制与 OpenShift Container Platform 版本的 Operator 兼容性
Kubernetes 定期弃用后续版本中删除的某些 API。如果您的 Operator 使用已弃用的 API,则在 OpenShift Container Platform 集群升级到已删除 API 的 Kubernetes 版本后,它可能无法正常工作。
作为 Operator 作者,强烈建议您查阅 Kubernetes 文档中的已弃用 API 迁移指南,并保持您的 Operator 项目最新状态以避免使用已弃用和删除的 API。理想情况下,您应该在更新的 OpenShift Container Platform 版本发行之前更新 Operator,从而避免 Operator 不兼容的问题。
当从 OpenShift Container Platform 版本中删除 API 时,在该集群版本上运行的仍使用删除的 API 的 Operator 将不再正常工作。作为 Operator 作者,您应该计划更新 Operator 项目,以适应 API 弃用和删除情况,以避免 Operator 用户中断。
您可以检查在 OpenShift Container Platform 4.8 及之后的版本上运行的 Operator 的事件警报,以查找当前是否对 API 有任何警告。以下警报在检测到正在使用的 API 会在下一发行版本中会被删除时发出一个警告:
APIRemovedInNextReleaseInUse
- 将在下一个 OpenShift Container Platform 发行版本中删除的 API。
APIRemovedInNextEUSReleaseInUse
- 将在下一个 OpenShift Container Platform 延长更新支持(EUS)发行版本中删除的 API。
如果集群管理员安装了 Operator,在升级到下一个 OpenShift Container Platform 版本前,必须确保安装与下一集群版本兼容的 Operator 版本。虽然建议您将 Operator 项目更新为不再使用已弃用或删除的 API,但如果您仍需要发布带有已删除 API 的 Operator 捆绑包,以便在早期版本的 OpenShift Container Platform 上继续使用,请确保正确配置了捆绑包。
以下流程可帮助管理员在不兼容的 OpenShift Container Platform 版本上安装 Operator 版本。这些步骤还可防止管理员升级到与当前在集群中安装的 Operator 版本不兼容的 OpenShift Container Platform 的更新版本。
当您知道当前版本的 Operator 因任何原因无法在特定的 OpenShift Container Platform 版本上正常工作时,此过程也很有用。通过定义应分发 Operator 的集群版本,可确保 Operator 不出现在允许范围内的集群版本目录中。
当集群管理员升级到不再支持 API 的未来 OpenShift Container Platform 版本时,使用已弃用 API 的 Operator 可能会对关键工作负载造成负面影响。如果您的 Operator 使用已弃用的 API,则应该尽快在 Operator 项目中配置以下设置。
先决条件
- 现有 Operator 项目
流程
如果您知道特定 Operator 捆绑包不受支持,且早于特定集群版本无法在 OpenShift Container Platform 上正常工作,请配置 Operator 兼容的最大 OpenShift Container Platform 版本。在 Operator 项目的集群服务版本 (CSV) 中,设置
olm.maxOpenShiftVersion
注解以防止管理员在将已安装的 Operator 升级到兼容版本前升级其集群:重要只有在 Operator 捆绑包版本稍后无法工作时,才必须使用
olm.maxOpenShiftVersion
注解。请注意,集群管理员无法使用安装的解决方案升级其集群。如果没有提供更新的版本和有效的升级路径,集群管理员可以卸载 Operator,并可升级集群版本。带有
olm.maxOpenShiftVersion
注解的 CSV 示例apiVersion: operators.coreos.com/v1alpha1 kind: ClusterServiceVersion metadata: annotations: "olm.properties": '[{"type": "olm.maxOpenShiftVersion", "value": "<cluster_version>"}]' 1
- 1
- 指定 Operator 兼容的最大 OpenShift Container Platform 集群版本。例如,当在集群中安装这个捆绑包时,将
value
设为4.8
可防止集群升级到 OpenShift Container Platform 4.8 之后的版本。
如果您的捆绑包旨在在红帽提供的 Operator 目录中发布,请通过设置以下属性为 Operator 配置兼容版本的 OpenShift Container Platform。此配置可确保您的 Operator 只包含在以兼容 OpenShift Container Platform 版本为目标的目录中:
注意仅当在红帽提供的目录中发布 Operator 时,才需要这个步骤。如果您的捆绑包只用于在自定义目录中分发,您可以跳过这一步。如需了解更多详细信息,请参阅"红帽提供的 Operator 目录"。
在项目的
bundle/metadata/annotations.yaml
文件中设置com.redhat.openshift.versions
注解:兼容版本的
bundle/metadata/annotations.yaml
文件示例com.redhat.openshift.versions: "v4.6-v4.8" 1
- 1
- 设置一个范围或一个版本。
为防止您的捆绑包被传输到不兼容的 OpenShift Container Platform 版本,请确保索引镜像使用 Operator 捆绑包镜像中的正确
com.redhat.openshift.versions
标签生成。例如,如果您的项目是使用 Operator SDK 生成的,请更新bundle.Dockerfile
文件:与兼容版本的
bundle.Dockerfile
示例LABEL com.redhat.openshift.versions="<versions>" 1
- 1
- 设置为范围或单个版本,如
v4.6-v4.8
。通过这个设置,您可以定义应分发 Operator 的集群版本,Operator 不会出现在范围之外的集群版本目录中。
现在,您可以捆绑 Operator 的新版本,并将更新的版本发布到目录以进行分发。
其他资源
- 认证的 Operator 构建指南中的管理OpenShift 版本
- 更新安装的 Operator
- 红帽提供的 Operator 目录
5.8.6. 其他资源
- 如需有关捆绑格式的更多详情,请参阅 Operator Framework 打包格式。
-
有关使用
opm
命令将捆绑包镜像添加到索引镜像的详情,请参阅管理自定义目录。 - 如需了解有关升级已安装的 Operator 的工作原理的详细信息,请参阅 Operator Lifecycle Manager 工作流。