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 的通用示例:
流程
- 使用红帽生态系统目录从红帽仓库搜索特定容器镜像并选择所需的镜像。
- 点 Get this image 来查找您的容器镜像的命令。
运行以下命令,并输入您的用户名和密码进行验证:
$ podman login registry.redhat.io Username:<your_registry_account_username> Password:<your_registry_account_password>
运行以下命令下载镜像并将其保存在本地:
$ 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资源提供以下配置参数。
| 参数 | 描述 |
|---|---|
|
|
|
|
|
设置 registry 实例的
支持
|
|
| 安全上载时 registry 所需的值,默认生成。 |
|
|
支持
|
|
| 定义在调用 master API 和上游 registry 时要使用的代理。 |
|
|
|
|
| registry 实例是否应该拒绝推送新镜像或删除现有镜像的尝试。 |
|
| API Request Limit 详情。控制在把请求放入队列前,registry 实例可以并行处理的请求数量。 |
|
|
确定是否使用默认主机名定义外部路由。如果启用,该路由将会对加密进行重新加密。默认值为 |
|
| 要创建的其他路由。您需要提供路由的主机名和证书。 |
|
|
为镜像 registry 部署定义 rollout 策略。默认为 |
|
| registry 的副本数量。 |
|
|
控制是否通过 registry 路由所有数据,而不是重定向到后端。默认值为 |
|
|
在 AWS 上的集群安装或升级时,Image Registry Operator 会将
|
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。
配置其他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 push或podman 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:
通过获取节点的名称来访问节点:
$ oc get nodes
$ oc debug nodes/<node_name>
要在节点上启用对
oc和podman等工具的访问,请将您的根目录改为/host:sh-4.2# chroot /host
使用您的访问令牌登录到容器镜像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>类似。针对您的registry执行
podman pull和podman push操作:重要您可以抓取任意镜像,但是如果已添加了system:registry角色,则只能将镜像推送到您自己的registry中。
在以下示例中,使用:
组件 值 <registry_ip>
172.30.124.220<port>
5000<project>
openshift<image>
image<tag>
忽略 (默认为
latest)抓取任意镜像:
sh-4.2# podman pull <name.io>/<image>
使用
<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将失败。为了进行测试,您可以创建一个新项目来推送镜像。将新标记的镜像推送到 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角色的用户访问集群。
流程
列出
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中的日志信息。
流程
使用带有 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路径获得。
流程
您可以使用集群角色运行指标查询来访问指标。
集群角色
如果还没有一个访问指标的集群角色,创建一个集群角色:
$ 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
将此角色添加到用户,运行以下命令:
$ oc adm policy add-cluster-role-to-user prometheus-scraper <username>
指标数据查询
获取用户令牌。
openshift: $ oc whoami -t
在节点或 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:
将
defaultRoute设为true:$ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge获取默认 registry 路由:
$ HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')获取 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使用以下命令启用集群的默认证书来信任路由:
$ sudo update-ca-trust enable
使用默认路由通过 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:
将
DefaultRoute设置为True:$ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge使用
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:
使用路由的 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配置。
在 Registry Operator 中:
spec: routes: - name: public-routes hostname: myregistry.mycorp.organization secretName: public-route-tls ...注意如果为registry的路由提供了一个自定义的 TLS 配置,则仅需设置
secretName。
故障排除