2.4. 升级 QuayEcosystem
从以前的 Operator 版本支持升级，这些 Operator 使用 QuayEcosystem API 进行一组有限的配置。为确保迁移不会意外发生，需要将一个特殊标签应用到 QuayEcosystem 以便它被迁移。将创建一个新的 QuayRegistry 以供 Operator 管理，但旧的 QuayEcosystem 将保留，直到手动删除为止，以确保您可以在任何错误时回滚并仍然访问 Quay。要将现有的 QuayEcosystem 迁移到新的 QuayRegistry，请使用以下流程：
流程
将
"quay-operator/migrate": "true"添加到QuayEcosystem的metadata.labels中。$ oc edit quayecosystem <quayecosystemname>
metadata: labels: quay-operator/migrate: "true"-
等待使用与
QuayEcosystem相同的metadata.name创建QuayRegistry。QuayEcosystem将标记为标签"quay-operator/migration-complete": "true"。 -
在设置了新
QuayRegistry的status.registryEndpoint后，访问 Red Hat Quay 并确认所有数据和设置都已成功迁移。 -
如果一切正常工作，您可以删除
QuayEcosystem和 Kubernetes 垃圾回收清理所有旧资源。
2.4.1. 恢复 QuayEcosystem 升级
如果在从 QuayEcosystem 升级到 QuayRegistry 的过程中出现错误，请按照以下步骤恢复为使用 QuayEcosystem ：
流程
使用 UI 或
kubectl删除QuayRegistry：$ kubectl delete -n <namespace> quayregistry <quayecosystem-name>
-
如果使用
Route提供外部访问，将Route更改为指回原始的Service（使用 UI 或kubectl）。
如果您的 QuayEcosystem 管理 PostgreSQL 数据库，升级过程会将您的数据迁移到由升级 Operator 管理的新 PostgreSQL 数据库。您的旧数据库不会被更改或删除，但 Red Hat Quay 在迁移完成后不再使用它。如果数据迁移过程中出现问题，升级过程将退出，建议您继续将数据库作为非受管组件。
2.4.2. 支持的升级的 QuayEcosystem 配置
如果迁移 QuayEcosystem 组件失败或不受支持，Red Hat Quay Operator 会在日志中报告错误，并在 status.conditions 中报告错误。所有非受管组件都应成功迁移，因为不需要采用 Kubernetes 资源，并且 Red Hat Quay 的 config.yaml 文件中已提供了所有必要的值。
数据库
不支持临时数据库（必须设置volumeSize 字段）。
Redis
不需要特别要求。
外部访问
自动迁移只支持 passthrough Route 访问。其他方法所需的手动迁移。
-
没有自定义主机名的
LoadBalancer：当QuayEcosystem使用标签"quay-operator/migration-complete": "true"标记后，在删除QuayEcosystem前需要从现存的Service中删除metadata.ownerReferences字段，这可以防止 Kubernetes 对Service进行垃圾回收并并删除负载均衡器。一个新的Service将被创建，带有metadata.name格式<QuayEcosystem-name>-quay-app。编辑现有Service的spec.selector，使其与新Service的spec.selector匹配，以便进入旧负载均衡器端点的流量现在会被定向到新的 pod。旧的Service将会被您管理; Quay Operator 将不再管理它。 -
带有自定义主机名的
LoadBalancer/NodePort/Ingress：将创建一个类型为LoadBalancer的新的Service，带有metadata.name格式<QuayEcosystem-name>-quay-app。将您的 DNS 设置更改为指向由新Service提供的status.loadBalancer端点。
Clair
不需要特别要求。
对象存储
QuayEcosystem 没有受管对象存储组件，因此对象存储始终标记为非受管。不支持本地存储。
仓库镜像
不需要特别要求。
