Registry

Red Hat OpenShift Service on AWS 4

Red Hat OpenShift Service on AWS 可以从源代码构建镜像,部署并管理其生命周期。

Red Hat OpenShift Documentation Team

摘要

Red Hat OpensShift Service on AWS 提供了一个内部集成的容器镜像 registry,可在 Red Hat OpenShift Service on AWS 环境中部署,以在本地管理镜像。

第 1 章 OpenShift 镜像 registry 概述

Red Hat OpenShift Service on AWS 可以从源代码构建镜像,部署并管理其生命周期。它提供内部集成的容器镜像 registry,它可以部署到 Red Hat OpenShift Service on AWS 环境中,以在本地管理镜像。此概述包含 Red Hat OpenShift Service on AWS 常用的 registry 的参考信息和链接,专注于 OpenShift 镜像 registry。

1.1. OpenShift 镜像 registry 常用术语表

该术语表定义了 registry 内容中使用的常用术语。

container
包括软件及其所有依赖项的轻量级和可执行镜像。由于容器虚拟化操作系统,因此您可以在数据中心、公有云或私有云或本地主机中运行容器。
Image Registry Operator
Image Registry Operator 在 openshift-image-registry 命名空间中运行,并管理该位置中的 registry 实例。
镜像仓库
镜像仓库是相关容器镜像和标识它们的标签(tag)的集合。
镜像 registry
镜像 registry 是一个 registry,其中包含 Red Hat OpenShift Service on AWS 镜像的镜像。
namespace
命名空间隔离单个集群中的一组资源。
pod
pod 是 Kubernetes 中的最小逻辑单元。pod 由一个或多个容器组成,可在 worker 节点上运行。
私有 registry
registry 是实现容器镜像 registry API 的服务器。私有 registry 是需要身份验证的 registry,允许用户访问其内容。
公共 registry
registry 是实现容器镜像 registry API 的服务器。公共 registry 是以公开方式提供其内容的 registry。
Quay.io
由红帽提供和维护的公共 Red Hat Quay Container Registry 实例,为 Red Hat OpenShift Service on AWS 集群提供大多数容器镜像和 Operator。
OpenShift 镜像 registry
OpenShift 镜像 registry 是 Red Hat OpenShift Service on AWS 提供的 registry,用于管理镜像。
registry 身份验证
要将镜像推送 (push) 到私有镜像仓库,registry 需要根据凭据验证其用户。
route
公开服务,以允许从 Red Hat OpenShift Service on AWS 实例以外的用户和应用程序对 pod 进行网络访问。
缩减(scale down)
减少副本数。
扩展(scale up)
增加副本数量。
service
服务在一组 pod 上公开正在运行的应用程序。

1.2. 集成的 OpenShift 镜像 registry

Red Hat OpenShift Service on AWS 提供了一个内置的容器镜像 registry,它作为一个标准的工作负载在集群中运行。这个 registry 由一个 infrastructure Operator 配置并管理。它为用户提供了一种现成的解决方案,供用户管理在已有集群基础架构上运行的,用于处理实际工作负载的镜像。这个registry可以象集群中的其他负载一样进行扩展,且不需要置备特殊的基础架构。此外,它已被集成到集群用户身份验证和授权系统中。这意味着,通过定义镜像资源上的用户权限就可以控制对镜像的创建和访问权限。

该 registry 通常作为集群中构建的镜像的发布目标,以及在集群中运行的工作负载的镜像源。当一个新镜像被推送到registry时,集群会收到新镜像的通知,其他组件就可以对更新的镜像做出反应。

镜像数据会存储在两个位置。实际镜像数据存储在可配置的存储位置,例如云存储或一个文件系统卷中。镜像的元数据被保存为标准的API资源(镜像(image)及镜像流(imagestream)),它们可以通过标准的集群 API 进行访问。

1.3. 第三方 registry

Red Hat OpenShift Service on AWS 可以使用第三方 registry 中的镜像创建容器,但这些 registry 可能不会提供与集成的 OpenShift 镜像 registry 相同的镜像通知支持。在这种情况下,Red Hat OpenShift Service on AWS 会在创建镜像流时从远程 registry 获取标签。要刷新获取的标签,请运行 oc import-image <stream>。当检测到新的镜像时,以前的构建和部署将会被重新创建。

1.3.1. 身份验证

Red Hat OpenShift Service on AWS 可以使用用户提供的凭证与 registry 通信,以访问私有镜像存储库。这允许 Red Hat OpenShift Service on AWS 将镜像推送到私有存储库中或从私有仓库推送和拉取镜像。

1.3.1.1. 使用 Podman 进行 registry 身份验证

有些容器镜像 registry 需要访问授权。Podman 是一个开源工具,用于管理容器和容器镜像,并与镜像 registry 交互。您可以使用 Podman 来验证凭证、拉取 registry 镜像,并将本地镜像存储在本地文件系统中。以下是使用 Podman 验证 registry 的通用示例:

流程

  1. 使用红帽生态系统目录从红帽仓库搜索特定容器镜像并选择所需的镜像。
  2. Get this image 来查找您的容器镜像的命令。
  3. 运行以下命令,并输入您的用户名和密码进行验证:

    $ podman login registry.redhat.io
     Username:<your_registry_account_username>
     Password:<your_registry_account_password>
  4. 运行以下命令下载镜像并将其保存在本地:

    $ podman pull registry.redhat.io/<repository_name>

1.4. Red Hat Quay registries

Red Hat Quay 为您提供了一个企业级的容器镜像 registry。它可以作为一个托管的服务,也可以在您自己的数据中心或环境中安装它。Red Hat Quay 中的高级功能包括跨区域复制、镜像扫描及镜像回滚(roll back)功能。

请通过 Quay.io 网站设置您自己的托管 Quay registry 帐户。之后,请按照Quay教程中的内容登录到Quay registry并开始管理镜像。

您可以像任何远程容器镜像 registry 一样,从 Red Hat OpenShift Service on AWS 访问 Red Hat Quay registry。

1.5. 启用了身份验证的红帽 registry

红帽生态系统目录的容器镜像部分提供的所有容器镜像都托管在镜像 registry 上(registry.redhat.io)。

registry ( registry.redhat.io )需要进行身份验证才能访问 Red Hat OpenShift Service on AWS 上的镜像及内容。当迁移到新registry后,现有的registry仍将在一段时间内可用。

注意

Red Hat OpenShift Service on AWS 从 registry.redhat.io 拉取镜像,因此您必须配置集群以使用它。

新registry使用标准的OAuth机制进行身份验证:

  • 身份验证令牌。令牌(token)是服务帐户,由管理员生成。系统可以使用它们与容器镜像registry进行身份验证。服务帐户不受用户帐户更改的影响,因此使用令牌进行身份验证是一个可靠且具有弹性的方法。这是生产环境集群中唯一受支持的身份验证选项。
  • Web用户名和密码。这是用于登录到诸如access.redhat.com之类的资源的标准凭据集。虽然可以将这个验证方法与 Red Hat OpenShift Service on AWS 搭配使用,但生产环境部署中不支持这个验证方法。将此验证方法限制为 Red Hat OpenShift Service on AWS 以外的独立项目。

您可以在 podman login 中使用您的凭证(用户名和密码,或身份验证令牌)来访问新 registry 中的内容。

所有镜像流都指向使用安装 pull secret 进行身份验证的新 registry。

您必须将凭证放在以下任一位置:

  • OpenShift 命名空间。您的凭证必须存在于 openshift 命名空间中,以便 openshift 命名空间中的镜像流可以被导入。
  • 您的主机。您的凭据必须存在于主机上,因为在抓取(pull)镜像时,Kubernetes会使用主机中的凭据。

其他资源

第 2 章 Red Hat OpenShift Service on AWS 中的 Image Registry Operator

2.1. Red Hat OpenShift Service on AWS 上的 Image Registry

Image Registry Operator 安装一个单独的 OpenShift 镜像 registry 实例,并对 registry 的所有配置进行管理(包括设置 registry 存储)。

当部署了control plane后,Operator 将会根据集群中的配置创建一个默认的 configs.imageregistry.operator.openshift.io 资源实例。

如果没有足够的信息来定义完整的configs.imageregistry.operator.openshift.io资源,则将定义不完整的资源,Operator 将更新资源状态以提供缺失的内容。

Image Registry Operator在openshift-image-registry命名空间中运行,并管理该位置中的 registry 实例。registry的所有配置和工作负载资源都位于该命名空间中。

重要

Image Registry Operator 管理修剪器的行为与在 Image Registry Operator 的 ClusterOperator 对象上指定的 managementState 关联。如果 Image Registry Operator 没有处于 Managed 状态,则镜像修剪器仍然可以被 Pruning 自定义资源配置和管理。

但是,Image Registry Operator 的 managementState 会更改部署的镜像修剪器任务的行为:

  • Managed: 镜像修剪器的 --prune-registry 标志被设置为 true
  • Removed: 镜像修剪器的 --prune-registry 标志被设置为 false,这意味着它只在 etcd 中修剪镜像元数据。
  • Unmanaged: 镜像修剪器的 --prune-registry 标志设置为 false

2.2. Image Registry Operator 在可用区间分布

Image Registry Operator 的默认配置现在将镜像 registry pod 分散到拓扑区中,以防止在完全区失败时造成延迟恢复时间,因为所有 pod 都会受到影响。

当使用与区相关的拓扑约束部署时,Image Registry Operator 会默认使用以下内容:

使用与区相关的拓扑约束部署的 Image Registry Operator

  topologySpreadConstraints:
  - labelSelector:
      matchLabels:
        docker-registry: default
    maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: DoNotSchedule
  - labelSelector:
      matchLabels:
        docker-registry: default
    maxSkew: 1
    topologyKey: node-role.kubernetes.io/worker
    whenUnsatisfiable: DoNotSchedule
  - labelSelector:
      matchLabels:
        docker-registry: default
    maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule

集群管理员可以通过配置 configs.imageregistry.operator.openshift.io/cluster spec 文件来覆盖默认的 topologySpreadConstraints。在这种情况下,只有您提供的约束会被应用。

2.3. Image Registry Operator 配置参数

configs.imageregistry.operator.openshift.io资源提供以下配置参数。

参数描述

managementState

Managed: Operator 在资源被更新时对 registry 进行相应更新。

Unmanaged: Operator 忽略配置资源的改变。

Removed: Operator 删除 registry 实例,并清除所有由 Operator 置备的存储。

logLevel

设置 registry 实例的 logLevel。默认为 Normal

支持 logLevel 的以下值:

  • Normal
  • Debug
  • Trace
  • TraceAll

httpSecret

安全上载时 registry 所需的值,默认生成。

operatorLogLevel

operatorLogLevel 配置参数为 Operator 本身提供基于意图的日志记录,以及管理 Operator 本身必须解释的粗粒度日志记录选项的简单方法。此配置参数默认为 Normal。它没有提供精细的控制。

支持 operatorLogLevel 的以下值:

  • Normal
  • Debug
  • Trace
  • TraceAll

proxy

定义在调用 master API 和上游 registry 时要使用的代理。

storage

Storagetype :用于配置 registry 存储的详细信息,例如S3 bucket坐标。通常会被默认配置。

readOnly

registry 实例是否应该拒绝推送新镜像或删除现有镜像的尝试。

requests

API Request Limit 详情。控制在把请求放入队列前,registry 实例可以并行处理的请求数量。

defaultRoute

确定是否使用默认主机名定义外部路由。如果启用,该路由将会对加密进行重新加密。默认值为 false

Routes

要创建的其他路由。您需要提供路由的主机名和证书。

rolloutStrategy

为镜像 registry 部署定义 rollout 策略。默认为 RollingUpdate

replicas

registry 的副本数量。

disableRedirect

控制是否通过 registry 路由所有数据,而不是重定向到后端。默认值为 false

spec.storage.managementState

在 AWS 上的集群安装或升级时,Image Registry Operator 会将 spec.storage.managementState 参数设置为 Managed

  • Managed: 确定 Image Registry Operator 管理底层存储。如果 Image Registry Operator 的 managementState 被设置为 Removed,则存储将被删除。

    • 如果 managementState 设为 Managed,Image Registry Operator 会尝试对底层存储单元应用一些默认配置。例如,如果设置为 Managed,Operator 会尝试在 S3 存储桶上启用加密,然后提供给 registry。如果您不希望默认设置应用到您提供的存储中,请确保将 managementState 设置为 Unmanaged
  • Unmanaged:确定 Image Registry Operator 忽略存储设置。如果 Image Registry Operator 的 managementState 设置为 Removed,则存储不会被删除。如果您提供了底层存储单元配置,如存储桶或容器名称,并且 spec.storage.managementState 尚未设置为任何值,则 Image Registry Operator 会将其配置为 Unmanaged

2.4. 使用 CRD 启用 Image Registry 默认路由

在 Red Hat OpenShift Service on AWS 中,Registry Operator 控制 OpenShift 镜像 registry 功能。这个 Operator 由 configs.imageregistry.operator.openshift.io CRD(Custom Resource Definition)定义。

如果您需要自动启用Image Registry默认路由,请对 Image Registry Operator CRD 进行 patch 处理。

流程

  • 对 Image Registry Operator CRD 进行 patch 处理:

    $ oc patch configs.imageregistry.operator.openshift.io/cluster --type merge -p '{"spec":{"defaultRoute":true}}'

2.5. 为镜像 registry 访问配置额外的信任存储

Image.config.openshift.io/cluster 自定资源可包含对配置映射的引用,该配置映射包含要在镜像 registry 访问期间被信任的额外证书颁发机构。

先决条件

  • 证书颁发机构(CA)必须经过 PEM 编码。

流程

您可以在openshift-config命名空间中创建配置映射,并在 image.config.openshift.io 子定义资源中的 AdditionalTrustedCA 中使用其名称,以提供与外部 registry 联系时可以被信任的额外CA。

对于每个要信任的额外 registry CA,配置映射键是带有要信任此 CA 的端口的 registry 的主机名,而 PEM 证书内容是要信任的每个额外 registry CA。

镜像 registry CA 配置映射示例

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-registry-ca
data:
  registry.example.com: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  registry-with-port.example.com..5000: | 1
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

1
如果 registry 带有端口,如 registry-with-port.example.com:5000: 需要被 .. 替换。

您可以按照以下过程配置其他CA。

  1. 配置其他CA:

    $ oc create configmap registry-config --from-file=<external_registry_address>=ca.crt -n openshift-config
    $ oc edit image.config.openshift.io cluster
    spec:
      additionalTrustedCA:
        name: registry-config

2.6. 为 Image Registry Operator 配置一个存储凭证

除了configs.imageregistry.operator.openshift.io及 ConfigMap 资源外,还可以通过openshift-image-registry命名空间中的独立的 secret 资源为 Operator 提供存储凭证配置。

image-registry-private-configuration-user secret 提供了存储访问和管理所需的凭证。如果找到默认凭据,它将覆盖 Operator 使用的默认凭据。

流程

  • 创建一个包含所需密钥的 Red Hat OpenShift Service on AWS secret。

    $ oc create secret generic image-registry-private-configuration-user --from-literal=KEY1=value1 --from-literal=KEY2=value2 --namespace openshift-image-registry

第 3 章 访问registry

使用以下部分介绍的内容来访问registry,包括查看日志和指标,以及保护和公开registry。

您可以使用podman命令直接访问registry。您可以使用podman pushpodman pull等操作直接从集成的registry中进行镜像的 pull 和 push 操作。要做到这一点,您必须使用 podman login 命令登录到registry。您可以执行的操作取决于您的用户权限,如以下各节所述。

3.1. 先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 您必须已经配置了一个身份供应商(IDP)。
  • 为了抓取镜像,例如使用podman pull命令,用户必须具有registry-viewer角色。要添加此角色,请运行以下命令:

    $ oc policy add-role-to-user registry-viewer <user_name>
  • 在编写或推送镜像时,例如使用 podman push 命令时:

    • 用户必须具有 registry-editor 角色。要添加此角色,请运行以下命令:

      $ oc policy add-role-to-user registry-editor <user_name>
    • 集群必须有一个可以推送镜像的现有项目。

3.2. 直接从集群访问 registry

您可以从集群内部访问registry。

流程

通过使用内部路由从集群访问registry:

  1. 通过获取节点的名称来访问节点:

    $ oc get nodes
    $ oc debug nodes/<node_name>
  2. 要在节点上启用对 ocpodman 等工具的访问,请将您的根目录改为 /host

    sh-4.2# chroot /host
  3. 使用您的访问令牌登录到容器镜像registry:

    sh-4.2# oc login -u kubeadmin -p <password_from_install_log> https://api-int.<cluster_name>.<base_domain>:6443
    sh-4.2# podman login -u kubeadmin -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000

    您应该看到一条确认登录的消息,例如:

    Login Succeeded!
    注意

    用户名可以是任何值,令牌包含了所有必要的信息。如果用户名包含冒号,则会导致登录失败。

    因为 Image Registry Operator 创建了路由,所以它将与 default-route-openshift-image-registry.<cluster_name> 类似。

  4. 针对您的registry执行podman pullpodman push操作:

    重要

    您可以抓取任意镜像,但是如果已添加了system:registry角色,则只能将镜像推送到您自己的registry中。

    在以下示例中,使用:

    组件

    <registry_ip>

    172.30.124.220

    <port>

    5000

    <project>

    openshift

    <image>

    image

    <tag>

    忽略 (默认为 latest)

    1. 抓取任意镜像:

      sh-4.2# podman pull <name.io>/<image>
    2. 使用 <registry_ip>:<port>/<project>/<image> 格式标记(tag)新镜像。项目名称必须出现在 Red Hat OpenShift Service on AWS 的这个 pull 规格中,以便正确放置并稍后访问 registry 中的镜像:

      sh-4.2# podman tag <name.io>/<image> image-registry.openshift-image-registry.svc:5000/openshift/<image>
      注意

      您必须具有指定项目的system:image-builder角色,该角色允许用户写或推送镜像。否则,下一步中的podman push将失败。为了进行测试,您可以创建一个新项目来推送镜像。

    3. 将新标记的镜像推送到 registry:

      sh-4.2# podman push image-registry.openshift-image-registry.svc:5000/openshift/<image>

3.3. 检查 registry pod 的状态

作为集群管理员,您可以列出在 openshift-image-registry 项目中运行的镜像 registry pod,并检查其状态。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 列出 openshift-image-registry 项目中的 pod 并查看其状态:

    $ oc get pods -n openshift-image-registry

    输出示例

    NAME READY STATUS RESTARTS AGE
    cluster-image-registry-operator-764bd7f846-qqtpb 1/1 Running 0 78m
    image-registry-79fb4469f6-llrln 1/1 Running 0 77m
    node-ca-hjksc 1/1 Running 0 73m
    node-ca-tftj6 1/1 Running 0 77m
    node-ca-wb6ht 1/1 Running 0 77m
    node-ca-zvt9q 1/1 Running 0 74m

3.4. 查看registry日志

使用oc logs命令可以查看registry中的日志信息。

流程

  1. 使用带有 deployments 的oc logs命令查看容器镜像 registry 的日志:

    $ oc logs deployments/image-registry -n openshift-image-registry

    输出示例

    2015-05-01T19:48:36.300593110Z time="2015-05-01T19:48:36Z" level=info msg="version=v2.0.0+unknown"
    2015-05-01T19:48:36.303294724Z time="2015-05-01T19:48:36Z" level=info msg="redis not configured" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002
    2015-05-01T19:48:36.303422845Z time="2015-05-01T19:48:36Z" level=info msg="using inmemory layerinfo cache" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002
    2015-05-01T19:48:36.303433991Z time="2015-05-01T19:48:36Z" level=info msg="Using OpenShift Auth handler"
    2015-05-01T19:48:36.303439084Z time="2015-05-01T19:48:36Z" level=info msg="listening on :5000" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002

3.5. 访问registry的指标数据(metrics)

OpenShift Container Registry 为 Prometheus metrics 提供了一个端点。Prometheus是一个独立的开源系统监视和警报工具包。

metrics 可以通过registry端点的/extensions/v2/metrics路径获得。

流程

您可以使用集群角色运行指标查询来访问指标。

集群角色

  1. 如果还没有一个访问指标的集群角色,创建一个集群角色:

    $ cat <<EOF | oc create -f -
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: prometheus-scraper
    rules:
    - apiGroups:
      - image.openshift.io
      resources:
      - registry/metrics
      verbs:
      - get
    EOF
  2. 将此角色添加到用户,运行以下命令:

    $ oc adm policy add-cluster-role-to-user prometheus-scraper <username>

指标数据查询

  1. 获取用户令牌。

    openshift:
    $ oc whoami -t
  2. 在节点或 pod 中运行指标查询,例如:

    $ curl --insecure -s -u <user>:<secret> \ 1
        https://image-registry.openshift-image-registry.svc:5000/extensions/v2/metrics | grep imageregistry | head -n 20

    输出示例

    # HELP imageregistry_build_info A metric with a constant '1' value labeled by major, minor, git commit & git version from which the image registry was built.
    # TYPE imageregistry_build_info gauge
    imageregistry_build_info{gitCommit="9f72191",gitVersion="v3.11.0+9f72191-135-dirty",major="3",minor="11+"} 1
    # HELP imageregistry_digest_cache_requests_total Total number of requests without scope to the digest cache.
    # TYPE imageregistry_digest_cache_requests_total counter
    imageregistry_digest_cache_requests_total{type="Hit"} 5
    imageregistry_digest_cache_requests_total{type="Miss"} 24
    # HELP imageregistry_digest_cache_scoped_requests_total Total number of scoped requests to the digest cache.
    # TYPE imageregistry_digest_cache_scoped_requests_total counter
    imageregistry_digest_cache_scoped_requests_total{type="Hit"} 33
    imageregistry_digest_cache_scoped_requests_total{type="Miss"} 44
    # HELP imageregistry_http_in_flight_requests A gauge of requests currently being served by the registry.
    # TYPE imageregistry_http_in_flight_requests gauge
    imageregistry_http_in_flight_requests 1
    # HELP imageregistry_http_request_duration_seconds A histogram of latencies for requests to the registry.
    # TYPE imageregistry_http_request_duration_seconds summary
    imageregistry_http_request_duration_seconds{method="get",quantile="0.5"} 0.01296087
    imageregistry_http_request_duration_seconds{method="get",quantile="0.9"} 0.014847248
    imageregistry_http_request_duration_seconds{method="get",quantile="0.99"} 0.015981195
    imageregistry_http_request_duration_seconds_sum{method="get"} 12.260727916000022

    1
    <user> 对象可以是任意的,但 <secret> 标签必须使用用户令牌。

第 4 章 开放registry

默认情况下,OpenShift 镜像 registry 在集群安装期间是加密的,它需要使用TLS进行访问。与以前的 Red Hat OpenShift Service on AWS 版本不同,安装时 registry 不会在集群外公开。

4.1. 手动公开默认 registry

通过使用路由可以开放从外部访问 OpenShift 镜像 registry 的通道,用户不再需要从集群内部登录到默认的 OpenShift Container Platform registry。通过外部访问,您可以使用路由地址从集群外部登录 registry,并使用路由主机标记并推送到现有项目。

先决条件

  • 以下的先决条件会被自动执行:

    • 部署 Registry Operator。
    • 部署 Ingress Operator。
  • 您可以使用具有 cluster-admin 角色的用户访问集群。

流程

您可以使用 configs.imageregistry.operator.openshift.io 资源中的 defaultRoute 参数来公开路由。

使用 defaultRoute 公开 registry:

  1. defaultRoute 设为 true

    $ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge
  2. 获取默认 registry 路由:

    $ HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')
  3. 获取 Ingress Operator 的证书:

    $ oc get secret -n openshift-ingress  router-certs-default -o go-template='{{index .data "tls.crt"}}' | base64 -d | sudo tee /etc/pki/ca-trust/source/anchors/${HOST}.crt  > /dev/null
  4. 使用以下命令启用集群的默认证书来信任路由:

    $ sudo update-ca-trust enable
  5. 使用默认路由通过 podman 登录:

    $ sudo podman login -u kubeadmin -p $(oc whoami -t) $HOST

4.2. 手动公开受保护的registry

通过使用路由可以开放从外部访问 OpenShift 镜像 registry 的通道,用户不再需要从集群内部登录到 OpenShift 镜像 registry。这样,您可以使用路由地址从集群外部登录 registry,并使用路由主机标记并推送到现有项目。

先决条件

  • 以下的先决条件会被自动执行:

    • 部署 Registry Operator。
    • 部署 Ingress Operator。
  • 您可以使用具有 cluster-admin 角色的用户访问集群。

流程

您可以使用configs.imageregistry.operator.openshift.io资源中的DefaultRoute参数或使用自定义路由来公开路由。

使用DefaultRoute公开registry:

  1. DefaultRoute设置为True

    $ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge
  2. 使用 podman 登录:

    $ HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')
    $ podman login -u kubeadmin -p $(oc whoami -t) --tls-verify=false $HOST 1
    1
    如果集群的默认路由证书不受信任,则需要--tls-verify=false 。您可以将一个自定义的可信证书设置为 Ingress Operator 的默认证书。

使用自定义路由公开registry:

  1. 使用路由的 TLS 密钥创建一个 secret:

    $ oc create secret tls public-route-tls \
        -n openshift-image-registry \
        --cert=</path/to/tls.crt> \
        --key=</path/to/tls.key>

    此步骤是可选的。如果不创建一个secret,则路由将使用Ingress Operator的默认TLS配置。

  2. 在 Registry Operator 中:

    spec:
      routes:
        - name: public-routes
          hostname: myregistry.mycorp.organization
          secretName: public-route-tls
    ...
    注意

    如果为registry的路由提供了一个自定义的 TLS 配置,则仅需设置secretName

法律通告

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.