4.9. 管理自定义目录
集群管理员和 Operator 目录维护人员可以使用 OpenShift Container Platform 的 Operator Lifecycle Manager (OLM) 上的捆绑包格式创建和管理打包的自定义目录。
Kubernetes 定期弃用后续版本中删除的某些 API。因此,从使用删除 API 的 Kubernetes 版本的 OpenShift Container Platform 版本开始,Operator 无法使用删除 API 的 API。
如果您的集群使用自定义目录,请参阅控制 Operator 与 OpenShift Container Platform 版本的兼容性,以了解更多有关 Operator 作者如何更新其项目的详细信息,以帮助避免工作负载问题并防止不兼容的升级。
其他资源
4.9.1. 先决条件
-
已安装
opm
CLI。
4.9.2. 基于文件的目录
基于文件的目录是 Operator Lifecycle Manager (OLM) 中目录格式的最新迭代。它是基于纯文本(JSON 或 YAML)和早期 SQLite 数据库格式的声明式配置演变,并且完全向后兼容。
从 OpenShift Container Platform 4.11 开始,默认的红帽提供的 Operator 目录以基于文件的目录格式发布。通过以过时的 SQLite 数据库格式发布的 4.10,用于 OpenShift Container Platform 4.6 的默认红帽提供的 Operator 目录。
与 SQLite 数据库格式相关的 opm
子命令、标志和功能已被弃用,并将在以后的版本中删除。功能仍被支持,且必须用于使用已弃用的 SQLite 数据库格式的目录。
许多 opm
子命令和标志都用于 SQLite 数据库格式,如 opm index prune
,它们无法使用基于文件的目录格式。有关使用基于文件的目录的更多信息,请参阅 Operator Framework 打包格式 以及使用 oc-mirror 插件为断开连接的安装 mirror 镜像。
4.9.2.1. 创建基于文件的目录镜像
您可以使用 opm
CLI 创建一个目录镜像,它使用纯文本(基于文件的目录)格式(JSON 或 YAML),替换已弃用的 SQLite 数据库格式。
先决条件
-
已安装
opm
CLI。 -
您有
podman
版本 1.9.3+。 - 已构建捆绑包镜像并推送到支持 Docker v2-2 的 registry。
流程
初始化目录:
运行以下命令,为目录创建一个目录:
$ mkdir <catalog_dir>
运行
opm generate dockerfile
命令生成可构建目录镜像的 Dockerfile:$ opm generate dockerfile <catalog_dir> \ -i registry.redhat.io/openshift4/ose-operator-registry:v4.13 1
- 1
- 使用
-i
标志指定官方红帽基础镜像,否则 Dockerfile 使用默认的上游镜像。
Dockerfile 必须与您在上一步中创建的目录目录位于相同的父目录中:
目录结构示例
. 1 ├── <catalog_dir> 2 └── <catalog_dir>.Dockerfile 3
运行
opm init
命令,使用 Operator 的软件包定义填充目录:$ opm init <operator_name> \ 1 --default-channel=preview \ 2 --description=./README.md \ 3 --icon=./operator-icon.svg \ 4 --output yaml \ 5 > <catalog_dir>/index.yaml 6
此命令在指定的目录配置文件中生成
olm.package
声明性配置 blob。
运行
opm render
命令向目录添加捆绑包:$ opm render <registry>/<namespace>/<bundle_image_name>:<tag> \ 1 --output=yaml \ >> <catalog_dir>/index.yaml 2
注意频道必须至少包含一个捆绑包。
为捆绑包添加频道条目。例如,根据您的规格修改以下示例,并将其添加到
<catalog_dir>/index.yaml
文件中:频道条目示例
--- schema: olm.channel package: <operator_name> name: preview entries: - name: <operator_name>.v0.1.0 1
- 1
- 确定在
<operator_name>
之后、版本v
中包含句点 (.
)。否则,条目无法传递opm validate
命令。
验证基于文件的目录:
针对目录目录运行
opm validate
命令:$ opm validate <catalog_dir>
检查错误代码是否为
0
:$ echo $?
输出示例
0
运行
podman build
命令构建目录镜像:$ podman build . \ -f <catalog_dir>.Dockerfile \ -t <registry>/<namespace>/<catalog_image_name>:<tag>
将目录镜像推送到 registry:
如果需要,运行
podman login
命令与目标 registry 进行身份验证:$ podman login <registry>
运行
podman push
命令来推送目录镜像:$ podman push <registry>/<namespace>/<catalog_image_name>:<tag>
其他资源
4.9.2.2. 更新或过滤基于文件的目录镜像
您可以使用 opm
CLI 更新或过滤(也称为 prune)使用基于文件的目录格式的目录镜像。通过提取和修改现有目录镜像的内容,您可以从目录中更新、添加或删除一个或多个 Operator 软件包条目。然后,您可以将镜像重新构建为目录的更新版本。
或者,如果您已在镜像 registry 上已有目录镜像,您可以使用 oc-mirror CLI 插件在将其镜像到目标 registry 时自动从该目录镜像更新的源版本中修剪任何删除的镜像。
有关 oc-mirror 插件和此用例的更多信息,请参阅"更新您的镜像 registry 内容"部分,特别是"使用 oc-mirror 插件为断开连接的安装镜像镜像"部分。
先决条件
在您的工作站上有以下内容:
-
opm
CLI。 -
podman
版本 1.9.3+。 - 基于文件的目录镜像。
最近在与此目录相关的工作站上初始化的目录结构。
如果您没有初始化的 catalog 目录,请创建目录并生成 Dockerfile。如需更多信息,请参阅"创建基于文件的目录镜像"中的"初始化目录"步骤。
-
流程
以 YAML 格式将目录镜像的内容提取到 catalog 目录中的
index.yaml
文件中:$ opm render <registry>/<namespace>/<catalog_image_name>:<tag> \ -o yaml > <catalog_dir>/index.yaml
注意或者,您可以使用
-o json
标志以 JSON 格式输出。通过更新、添加或删除一个或多个 Operator 软件包条目,将生成的
index.yaml
文件的内容修改为您的规格。重要在目录中发布捆绑包后,假设您安装了其中一个用户。确保之前发布目录中的所有捆绑包都具有到当前或更新频道头的更新路径,以避免安装该版本的用户。
例如,如果要删除 Operator 软件包,以下示例列出了一组
olm.package
、olm.channel
和olm.bundle
blob,它们必须删除才能从目录中删除软件包:例 4.2. 删除条目示例
--- defaultChannel: release-2.7 icon: base64data: <base64_string> mediatype: image/svg+xml name: example-operator schema: olm.package --- entries: - name: example-operator.v2.7.0 skipRange: '>=2.6.0 <2.7.0' - name: example-operator.v2.7.1 replaces: example-operator.v2.7.0 skipRange: '>=2.6.0 <2.7.1' - name: example-operator.v2.7.2 replaces: example-operator.v2.7.1 skipRange: '>=2.6.0 <2.7.2' - name: example-operator.v2.7.3 replaces: example-operator.v2.7.2 skipRange: '>=2.6.0 <2.7.3' - name: example-operator.v2.7.4 replaces: example-operator.v2.7.3 skipRange: '>=2.6.0 <2.7.4' name: release-2.7 package: example-operator schema: olm.channel --- image: example.com/example-inc/example-operator-bundle@sha256:<digest> name: example-operator.v2.7.0 package: example-operator properties: - type: olm.gvk value: group: example-group.example.io kind: MyObject version: v1alpha1 - type: olm.gvk value: group: example-group.example.io kind: MyOtherObject version: v1beta1 - type: olm.package value: packageName: example-operator version: 2.7.0 - type: olm.bundle.object value: data: <base64_string> - type: olm.bundle.object value: data: <base64_string> relatedImages: - image: example.com/example-inc/example-related-image@sha256:<digest> name: example-related-image schema: olm.bundle ---
-
将更改保存到
index.yaml
文件。 验证目录:
$ opm validate <catalog_dir>
重建目录:
$ podman build . \ -f <catalog_dir>.Dockerfile \ -t <registry>/<namespace>/<catalog_image_name>:<tag>
将更新的目录镜像推送到 registry:
$ podman push <registry>/<namespace>/<catalog_image_name>:<tag>
验证
-
在 Web 控制台中,进入 Administration
Cluster Settings Configuration 页面中的 OperatorHub 配置资源。 添加目录源或更新现有目录源,以便将 pull spec 用于更新的目录镜像。
如需更多信息,请参阅本节的"添加资源"中的"在集群中添加目录源"。
-
在目录源处于 READY 状态后,进入 Operators
OperatorHub 页面,检查您所做的更改是否反映在 Operator 列表中。
4.9.3. 基于 SQLite 的目录
Operator 目录的 SQLite 数据库格式是一个弃用的功能。弃用的功能仍然包含在 OpenShift Container Platform 中,并将继续被支持。但是,这个功能会在以后的发行版本中被删除,且不建议在新的部署中使用。
有关 OpenShift Container Platform 中已弃用或删除的主要功能的最新列表,请参阅 OpenShift Container Platform 发行注记中已弃用和删除的功能部分。
4.9.3.1. 创建基于 SQLite 的索引镜像
您可以使用 opm
CLI 根据 SQLite 数据库格式创建索引镜像。
先决条件
-
已安装
opm
CLI。 -
您有
podman
版本 1.9.3+。 - 已构建捆绑包镜像并推送到支持 Docker v2-2 的 registry。
流程
启动一个新的索引:
$ opm index add \ --bundles <registry>/<namespace>/<bundle_image_name>:<tag> \1 --tag <registry>/<namespace>/<index_image_name>:<tag> \2 [--binary-image <registry_base_image>] 3
将索引镜像推送到 registry。
如果需要,与目标 registry 进行身份验证:
$ podman login <registry>
推送索引镜像:
$ podman push <registry>/<namespace>/<index_image_name>:<tag>
4.9.3.2. 更新基于 SQLite 的索引镜像
在将 OperatorHub 配置为使用引用自定义索引镜像的目录源后,集群管理员可通过将捆绑包镜像添加到索引镜像来保持其集群上的可用 Operator 最新状态。
您可以使用 opm index add
命令来更新存在的索引镜像。
先决条件
-
已安装
opm
CLI。 -
您有
podman
版本 1.9.3+。 - 构建并推送到 registry 的索引镜像。
- 引用索引镜像的现有目录源。
流程
通过添加捆绑包镜像来更新现有索引:
$ opm index add \ --bundles <registry>/<namespace>/<new_bundle_image>@sha256:<digest> \1 --from-index <registry>/<namespace>/<existing_index_image>:<existing_tag> \2 --tag <registry>/<namespace>/<existing_index_image>:<updated_tag> \3 --pull-tool podman 4
其中:
<registry>
-
指定 registry 的主机名,如
quay.io
或mirror.example.com
。 <namespace>
-
指定 registry 的命名空间,如
ocs-dev
或abc
。 <new_bundle_image>
-
指定要添加到 registry 的新捆绑包镜像,如
ocs-operator
。 <digest>
-
指定捆绑包镜像的 SHA 镜像 ID 或摘要,如
c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41
。 <existing_index_image>
-
指定之前推送的镜像,如
abc-redhat-operator-index
。 <existing_tag>
-
指定之前推送的镜像标签,如
4.13
。 <updated_tag>
-
指定要应用到更新的索引镜像的镜像标签,如
4.13.1
。
示例命令
$ opm index add \ --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \ --from-index mirror.example.com/abc/abc-redhat-operator-index:4.13 \ --tag mirror.example.com/abc/abc-redhat-operator-index:4.13.1 \ --pull-tool podman
推送更新的索引镜像:
$ podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>
Operator Lifecycle Manager(OLM)会在常规时间段内自动轮询目录源中引用的索引镜像,验证是否已成功添加新软件包:
$ oc get packagemanifests -n openshift-marketplace
4.9.3.3. 过滤基于 SQLite 的索引镜像
基于 Operator Bundle Format 的索引镜像是 Operator 目录的容器化快照。您可以过滤或 prune(修剪)除指定的软件包列表以外的所有索引,创建只包含您想要的 Operator 的源索引副本。
先决条件
-
您有
podman
版本 1.9.3+。 -
grpcurl
(第三方命令行工具) -
已安装
opm
CLI。 - 访问支持 Docker v2-2 的 registry
流程
通过目标 registry 进行身份验证:
$ podman login <target_registry>
确定您要包括在您的修剪索引中的软件包列表。
运行您要修剪容器中的源索引镜像。例如:
$ podman run -p50051:50051 \ -it registry.redhat.io/redhat/redhat-operator-index:v4.13
输出示例
Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.13... Getting image source signatures Copying blob ae8a0c23f5b1 done ... INFO[0000] serving registry database=/database/index.db port=50051
在一个单独的终端会话中,使用
grpcurl
命令获取由索引提供的软件包列表:$ grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out
检查
package.out
文件,确定要保留在此列表中的哪个软件包名称。例如:软件包列表片断示例
... { "name": "advanced-cluster-management" } ... { "name": "jaeger-product" } ... { { "name": "quay-operator" } ...
-
在您执行
podman run
命令的终端会话中,按 Ctrl 和 C 停止容器进程。
运行以下命令来修剪指定软件包以外的所有源索引:
$ opm index prune \ -f registry.redhat.io/redhat/redhat-operator-index:v4.13 \1 -p advanced-cluster-management,jaeger-product,quay-operator \2 [-i registry.redhat.io/openshift4/ose-operator-registry:v4.9] \3 -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.13 4
运行以下命令将新索引镜像推送到目标 registry:
$ podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.13
其中
<namespace>
是 registry 上的任何现有命名空间。
4.9.4. 目录源和 pod 安全准入
OpenShift Container Platform 4.11 中引入了 Pod 安全准入,以确保 pod 安全标准。使用基于 SQLite 的目录格式构建的目录源以及在 OpenShift Container Platform 4.11 无法运行受限 pod 安全强制前发布的 opm
CLI 工具的版本。
在 OpenShift Container Platform 4.13 中,命名空间默认没有限制 pod 安全强制,默认目录源安全模式被设置为 legacy
。
计划在以后的 OpenShift Container Platform 发行版本中包括所有命名空间的默认限制强制。当发生受限强制时,目录源 pod 规格的安全上下文必须与受限 pod 安全标准匹配。如果您的目录源镜像需要不同的 pod 安全标准,则必须明确设置命名空间的 pod 安全准入标签。
如果您不想以受限方式运行基于 SQLite 的目录源 pod,则不需要在 OpenShift Container Platform 4.13 中更新目录源。
但是,建议您采取措施来确保目录源在受限 pod 安全强制下运行。如果您不采取措施来确保目录源在受限 pod 安全强制下运行,您的目录源可能不会在以后的 OpenShift Container Platform 版本中运行。
作为目录作者,您可以通过完成以下任一操作来启用与受限 pod 安全强制的兼容性:
- 将您的目录迁移到基于文件的目录格式。
-
使用 OpenShift Container Platform 4.11 或更高版本发布的
opm
CLI 工具版本更新您的目录镜像。
SQLite 数据库目录格式已弃用,但仍然被红帽支持。在以后的发行版本中,不支持 SQLite 数据库格式,目录将需要迁移到基于文件的目录格式。从 OpenShift Container Platform 4.11 开始,默认的红帽提供的 Operator 目录以基于文件的目录格式发布。基于文件的目录与受限 pod 安全强制兼容。
如果您不想更新 SQLite 数据库目录镜像,或将目录迁移到基于文件的目录格式,您可以将目录配置为使用升级的权限运行。
其他资源
4.9.4.1. 将 SQLite 数据库目录迁移到基于文件的目录格式
您可以将已弃用的 SQLite 数据库格式目录更新为基于文件的目录格式。
先决条件
- SQLite 数据库目录源
-
您可以使用具有
cluster-admin
角色的用户访问集群。 -
工作站上 OpenShift Container Platform 4.13 发布的
opm
CLI 工具的最新版本
流程
运行以下命令,将 SQLite 数据库目录迁移到基于文件的目录:
$ opm migrate <registry_image> <fbc_directory>
运行以下命令,为您的基于文件的目录生成 Dockerfile:
$ opm generate dockerfile <fbc_directory> \ --binary-image \ registry.redhat.io/openshift4/ose-operator-registry:v4.13
后续步骤
- 生成的 Dockerfile 可以构建、标记并推送到 registry。
其他资源
4.9.4.2. 重建 SQLite 数据库目录镜像
您可以使用 OpenShift Container Platform 版本发布的 opm
CLI 工具的最新版本重建 SQLite 数据库目录镜像。
先决条件
- SQLite 数据库目录源
-
您可以使用具有
cluster-admin
角色的用户访问集群。 -
工作站上 OpenShift Container Platform 4.13 发布的
opm
CLI 工具的最新版本
流程
运行以下命令,使用
opm
CLI 工具的最新版本重建目录:$ opm index add --binary-image \ registry.redhat.io/openshift4/ose-operator-registry:v4.13 \ --from-index <your_registry_image> \ --bundles "" -t \<your_registry_image>
4.9.4.3. 配置目录以使用升级的权限运行
如果您不想更新 SQLite 数据库目录镜像,或将目录迁移到基于文件的目录格式,您可以执行以下操作以确保目录源在默认 pod 安全强制更改为受限时运行:
- 在目录源定义中手动将目录安全模式设置为 legacy。此操作可确保您的目录使用旧权限运行,即使默认目录安全模式更改为 restricted。
- 为基准或特权 pod 安全强制标记目录源命名空间。
SQLite 数据库目录格式已弃用,但仍然被红帽支持。在以后的发行版本中,不支持 SQLite 数据库格式,目录将需要迁移到基于文件的目录格式。基于文件的目录与受限 pod 安全强制兼容。
先决条件
- SQLite 数据库目录源
-
您可以使用具有
cluster-admin
角色的用户访问集群。 -
支持运行带有升级 pod 安全准入标准
baseline
或privileged
的 pod 的目标命名空间
流程
通过将
spec.grpcPodConfig.securityContextConfig
标签设置为legacy
来编辑CatalogSource
定义,如下例所示:CatalogSource
定义示例apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: my-catsrc namespace: my-ns spec: sourceType: grpc grpcPodConfig: securityContextConfig: legacy image: my-image:latest
提示在 OpenShift Container Platform 4.13 中,
spec.grpcPodConfig.securityContextConfig
字段默认设置为legacy
。在以后的发行版本中,计划默认设置将更改为restricted
。如果您的目录无法在受限强制下运行,建议您手动将此字段设置为legacy
。编辑
<namespace>.yaml
文件,将升级的 pod 安全准入标准添加到目录源命名空间中,如下例所示:<namespace>.yaml
文件示例apiVersion: v1 kind: Namespace metadata: ... labels: security.openshift.io/scc.podSecurityLabelSync: "false" 1 openshift.io/cluster-monitoring: "true" pod-security.kubernetes.io/enforce: baseline 2 name: "<namespace_name>"
4.9.5. 在集群中添加目录源
将目录源添加到 OpenShift Container Platform 集群可为用户发现和安装 Operator。集群管理员可以创建一个 CatalogSource
对象来引用索引镜像。OperatorHub 使用目录源来填充用户界面。
或者,您可以使用 Web 控制台管理目录源。在 Administration
先决条件
- 构建并推送索引镜像到 registry。
-
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
创建一个
CatalogSource
对象来引用索引镜像。根据您的规格修改以下内容,并将它保存为
catalogSource.yaml
文件:apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: my-operator-catalog namespace: openshift-marketplace 1 annotations: olm.catalogImageTemplate: 2 "<registry>/<namespace>/<index_image_name>:v{kube_major_version}.{kube_minor_version}.{kube_patch_version}" spec: sourceType: grpc grpcPodConfig: securityContextConfig: <security_mode> 3 image: <registry>/<namespace>/<index_image_name>:<tag> 4 displayName: My Operator Catalog publisher: <publisher_name> 5 updateStrategy: registryPoll: 6 interval: 30m
- 1
- 如果您希望目录源对所有命名空间中的用户全局可用,请指定
openshift-marketplace
命名空间。否则,您可以指定一个不同的命名空间来对目录进行作用域并只对该命名空间可用。 - 2
- 可选:将
olm.catalogImageTemplate
注解设置为索引镜像名称,并使用一个或多个 Kubernetes 集群版本变量,如为镜像标签构建模板时所示。 - 3
- 指定
legacy
或restricted
的值。如果没有设置该字段,则默认值为legacy
。在以后的 OpenShift Container Platform 发行版本中,计划默认值为restricted
。如果您的目录无法使用restricted
权限运行,建议您手动将此字段设置为legacy
。 - 4
- 指定索引镜像。如果您在镜像名称后指定了标签,如
:v4.13
,则目录源 Pod 会使用镜像 pull 策略Always
,这意味着 pod 始终在启动容器前拉取镜像。如果您指定了摘要,如@sha256:<id>
,则镜像拉取策略为IfNotPresent
,这意味着仅在节点上不存在的镜像时才拉取镜像。 - 5
- 指定发布目录的名称或机构名称。
- 6
- 目录源可以自动检查新版本以保持最新。
使用该文件创建
CatalogSource
对象:$ oc apply -f catalogSource.yaml
确定成功创建以下资源。
检查 pod:
$ oc get pods -n openshift-marketplace
输出示例
NAME READY STATUS RESTARTS AGE my-operator-catalog-6njx6 1/1 Running 0 28s marketplace-operator-d9f549946-96sgr 1/1 Running 0 26h
检查目录源:
$ oc get catalogsource -n openshift-marketplace
输出示例
NAME DISPLAY TYPE PUBLISHER AGE my-operator-catalog My Operator Catalog grpc 5s
检查软件包清单:
$ oc get packagemanifest -n openshift-marketplace
输出示例
NAME CATALOG AGE jaeger-product My Operator Catalog 93s
现在,您可以在 OpenShift Container Platform Web 控制台中通过 OperatorHub 安装 Operator。
4.9.6. 从私有 registry 访问 Operator 的镜像
如果与 Operator Lifecycle Manager(OLM)管理的 Operator 相关的某些镜像托管在需要经过身份验证的容器镜像 registry(也称为私有 registry)中时,在默认情况下,OLM 和 OperatorHub 将无法拉取镜像。要启用访问权限,可以创建一个包含 registry 验证凭证的 pull secret。通过引用一个或多个目录源的 pull secret,OLM 可以处理将 secret 放置到 Operator 和目录命名空间中以允许进行安装。
Operator 或其 Operands 所需的其他镜像可能会需要访问私有 registry。对于这种情况,OLM 不处理将 secret 放置到目标租户命名空间中,但身份验证凭证可以添加到全局范围集群 pull secret 中,或单独的命名空间服务帐户中,以启用所需的访问权限。
在决定由 OLM 管理的 Operator 是否有适当的拉取访问权限时,应该考虑以下类型的镜像:
- 索引镜像
-
CatalogSource
对象可以引用索引镜像,该镜像使用 Operator 捆绑包格式,并作为托管在镜像 registry 中的容器镜像的目录源打包。如果索引镜像托管在私有 registry 中,可以使用 secret 来启用拉取访问。 - 捆绑包镜像
- Operator 捆绑包镜像是元数据和清单,并被打包为容器镜像,代表 Operator 的一个特定版本。如果目录源中引用的任何捆绑包镜像托管在一个或多个私有 registry 中,可以使用一个 secret 来启用拉取(pull)访问。
- Operator 和 Operand 镜像
如果从目录源安装的 Operator 使用私有镜像,对于 Operator 镜像本身或它监视的 Operand 镜像之一,Operator 将无法安装,因为部署无法访问所需的 registry 身份验证。在目录源中引用 secret 不会使 OLM 将 secret 放置到安装 Operands 的目标租户命名空间中。
相反,身份验证详情被添加到
openshift-config
命名空间中的全局集群 pull secret 中,该 secret 提供对集群上所有命名空间的访问。另外,如果不允许访问整个集群,则可将 pull secret 添加到目标租户命名空间的default
服务帐户中。
先决条件
您至少有一个托管在私有 registry 中的以下之一:
- 一个索引镜像或目录镜像。
- 一个 Operator 捆绑包镜像。
- 一个 Operator 或 Operand 镜像。
-
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
为每个必需的私有 registry 创建 secret。
登录到私有 registry 以创建或更新 registry 凭证文件:
$ podman login <registry>:<port>
注意registry 凭证的文件路径可能会根据用于登录到 registry 的容器工具的不同而有所不同。对于
podman
CLI,默认位置为${XDG_RUNTIME_DIR}/containers/auth.json
。对于docker
CLI,默认位置为/root/.docker/config.json
。建议您为每个 secret 只包含一个 registry 的凭证,并在单独的 secret 中为多个 registry 管理凭证。后续步骤中的
CatalogSource
可包括多个 secret,OpenShift Container Platform 会将这些 secret 合并为一个单独的虚拟凭证文件,以便在镜像拉取过程中使用。默认情况下,registry 凭证文件可以在一个 registry 中存储多个 registry 或多个存储库的详细信息。确认您的文件的当前内容。例如:
为多个 registry 存储凭证的文件
{ "auths": { "registry.redhat.io": { "auth": "FrNHNydQXdzclNqdg==" }, "quay.io": { "auth": "fegdsRib21iMQ==" }, "https://quay.io/my-namespace/my-user/my-image": { "auth": "eWfjwsDdfsa221==" }, "https://quay.io/my-namespace/my-user": { "auth": "feFweDdscw34rR==" }, "https://quay.io/my-namespace": { "auth": "frwEews4fescyq==" } } }
由于此文件用于后续步骤中创建 secret,请确保为每个文件只存储一个 registry 的详情。这可使用以下方法之一完成:
-
使用
podman logout <registry>
命令为额外 registry 删除凭证,直到您只保留一个 registry。 编辑 registry 凭证文件,将 registry 详情分开以存储在多个文件中。例如:
为一个 registry 存储凭证的文件
{ "auths": { "registry.redhat.io": { "auth": "FrNHNydQXdzclNqdg==" } } }
为另一个 registry 存储凭证的文件
{ "auths": { "quay.io": { "auth": "Xd2lhdsbnRib21iMQ==" } } }
-
使用
在
openshift-marketplace
命名空间中创建 secret,其中包含私有 registry 的身份验证凭证:$ oc create secret generic <secret_name> \ -n openshift-marketplace \ --from-file=.dockerconfigjson=<path/to/registry/credentials> \ --type=kubernetes.io/dockerconfigjson
重复此步骤,为任何其他需要的私有 registry 创建额外的 secret,更新
--from-file
标志以指定另一个 registry 凭证文件路径。
创建或更新现有的
CatalogSource
对象以引用一个或多个 secret:apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: my-operator-catalog namespace: openshift-marketplace spec: sourceType: grpc secrets: 1 - "<secret_name_1>" - "<secret_name_2>" grpcPodConfig: securityContextConfig: <security_mode> 2 image: <registry>:<port>/<namespace>/<image>:<tag> displayName: My Operator Catalog publisher: <publisher_name> updateStrategy: registryPoll: interval: 30m
如果订阅的 Operator 引用的任何 Operator 或 Operand 镜像需要访问私有 registry,您可以提供对集群中的所有命名空间或单独的目标租户命名空间的访问。
要访问集群中的所有命名空间,请将身份验证详情添加到
openshift-config
命名空间中的全局集群 pull secret 中。警告集群资源必须调整为新的全局 pull secret,这样可暂时限制集群的可用性。
从全局 pull secret 中提取
.dockerconfigjson
文件:$ oc extract secret/pull-secret -n openshift-config --confirm
使用所需私有 registry 或 registry 的身份验证凭证更新
.dockerconfigjson
文件,并将它保存为新文件:$ cat .dockerconfigjson | \ jq --compact-output '.auths["<registry>:<port>/<namespace>/"] |= . + {"auth":"<token>"}' \1 > new_dockerconfigjson
- 1
- 将
<registry>:<port> /<namespace>
替换为私有 registry 的详情,将<token>
替换为您的身份验证凭证。
使用新文件更新全局 pull secret:
$ oc set data secret/pull-secret -n openshift-config \ --from-file=.dockerconfigjson=new_dockerconfigjson
要更新单个命名空间,请向 Operator 的服务帐户添加一个 pull secret,以便在目标租户命名空间中访问该 Operator。
在租户命名空间中为
openshift-marketplace
重新创建 secret:$ oc create secret generic <secret_name> \ -n <tenant_namespace> \ --from-file=.dockerconfigjson=<path/to/registry/credentials> \ --type=kubernetes.io/dockerconfigjson
通过搜索租户命名空间来验证 Operator 的服务帐户名称:
$ oc get sa -n <tenant_namespace> 1
- 1
- 如果 Operator 安装在单独的命名空间中,请搜索该命名空间。如果 Operator 已为所有命名空间安装,请搜索
openshift-operators
命名空间。
输出示例
NAME SECRETS AGE builder 2 6m1s default 2 6m1s deployer 2 6m1s etcd-operator 2 5m18s 1
- 1
- 已安装的 etcd Operator 的服务帐户。
将 secret 链接到 Operator 的服务帐户:
$ oc secrets link <operator_sa> \ -n <tenant_namespace> \ <secret_name> \ --for=pull
其他资源
- 如需了解更多与 secret 相关的信息,包括用于 registry 凭证的 secret 类型的信息,请参阅什么是 secret?。
- 如需了解有关更改此 secret 的影响的更多详细信息,请参阅更新全局集群 pull secret。
- 如需了解更多有关将 pull secret 链接到每个命名空间的服务帐户的详情,请参阅允许 Pod 引用其他安全 registry 中的镜像。
4.9.7. 禁用默认的 OperatorHub 目录源
在 OpenShift Container Platform 安装过程中,默认为 OperatorHub 配置由红帽和社区项目提供的源内容的 operator 目录。作为集群管理员,您可以禁用默认目录集。
流程
通过在
OperatorHub
对象中添加disableAllDefaultSources: true 来
禁用默认目录的源:$ oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
或者,您可以使用 Web 控制台管理目录源。在 Administration
4.9.8. 删除自定义目录
作为集群管理员,您可以删除之前添加到集群中的自定义 Operator 目录,方法是删除相关的目录源。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。
流程
-
在 Web 控制台的 Administrator 视角中,导航到 Administration
Cluster Settings。 - 点 Configuration 选项卡,然后点 OperatorHub。
- 点 Sources 选项卡。
- 选择您要删除的目录的 Options 菜单 ,然后点 Delete CatalogSource。