修剪对象以回收资源 | 构建应用程序 | OpenShift Container Platform 4.17

基本的修剪操作
修剪组
修剪部署资源
修剪构建
自动修剪镜像
手动修剪镜像
硬修剪注册表
修剪cron作业

随着时间的推移，在OpenShift Container Platform中创建的API对象可能会通过正常的用户操作（例如构建和部署应用程序时）积累在集群的etcd数据存储中。

集群管理员可以定期从不再需要的集群中修剪旧版本的對象。例如，通过修剪镜像，您可以删除不再使用但仍在占用磁盘空间的旧镜像和层。

基本的修剪操作

CLI 将修剪操作分组在一个公共父命令下

$ oc adm prune <object_type> <options>

这指定了

要对其执行操作的<object_type>，例如groups、builds、deployments或images。
支持用于修剪该对象类型的<options>。

修剪组

要从外部提供程序修剪组记录，管理员可以运行以下命令

$ oc adm prune groups \
    --sync-config=path/to/sync/config [<options>]

表1. `oc adm prune groups`标志
选项	描述
`--confirm`	指示应执行修剪，而不是执行试运行。
`--blacklist`	组黑名单文件的路径。
`--whitelist`	组白名单文件的路径。
`--sync-config`	同步配置文件的路径。

步骤

要查看prune命令将删除的组，请运行以下命令

$ oc adm prune groups --sync-config=ldap-sync-config.yaml

要执行修剪操作，请添加--confirm标志

$ oc adm prune groups --sync-config=ldap-sync-config.yaml --confirm

修剪部署资源

您可以修剪与部署相关的资源，这些资源由于年龄和状态而不再被系统需要。

以下命令修剪与DeploymentConfig对象相关的复制控制器

$ oc adm prune deployments [<options>]

要同时修剪与Deployment对象相关的副本集，请使用--replica-sets标志。此标志目前是技术预览功能。

选项描述

--confirm

指示应执行修剪，而不是执行试运行。

--keep-complete=<N>

根据DeploymentConfig对象，保留最后N个状态为Complete且副本数为零的复制控制器。默认为5。

--keep-failed=<N>

根据DeploymentConfig对象，保留最后N个状态为Failed且副本数为零的复制控制器。默认为1。

--keep-younger-than=<duration>

不要修剪任何相对于当前时间小于<duration>的复制控制器。有效的度量单位包括纳秒 (ns)、微秒 (us)、毫秒 (ms)、秒 (s)、分钟 (m) 和小时 (h)。默认为60m。

--orphans

修剪所有不再具有DeploymentConfig对象、状态为Complete或Failed且副本数为零的复制控制器。

--replica-sets=true|false

如果为true，则副本集将包含在修剪过程中。默认为false。

此标志是技术预览功能。

步骤

要查看修剪操作将删除的内容，请运行以下命令

$ oc adm prune deployments --orphans --keep-complete=5 --keep-failed=1 \
    --keep-younger-than=60m

要实际执行修剪操作，请添加--confirm标志

$ oc adm prune deployments --orphans --keep-complete=5 --keep-failed=1 \
    --keep-younger-than=60m --confirm

修剪构建

要修剪由于年龄和状态而不再被系统需要的构建，管理员可以运行以下命令

$ oc adm prune builds [<options>]

表 3. `oc adm prune builds` 参数
选项	描述
`--confirm`	指示应执行修剪，而不是执行试运行。
`--orphans`	修剪所有构建配置不再存在且状态为已完成、失败、错误或已取消的构建。
`--keep-complete=<N>`	对于每个构建配置，保留状态为已完成的最后 `N` 个构建。默认值为 `5`。
`--keep-failed=<N>`	对于每个构建配置，保留状态为失败、错误或已取消的最后 `N` 个构建。默认值为 `1`。
`--keep-younger-than=<duration>`	不修剪任何比当前时间早于 `<duration>` 的对象。默认值为 `60m`。

步骤

要查看修剪操作将删除的内容，请运行以下命令

$ oc adm prune builds --orphans --keep-complete=5 --keep-failed=1 \
    --keep-younger-than=60m

要实际执行修剪操作，请添加--confirm标志

$ oc adm prune builds --orphans --keep-complete=5 --keep-failed=1 \
    --keep-younger-than=60m --confirm

开发人员可以通过修改其构建配置来启用自动构建修剪。

其他资源

执行高级构建 → 修剪构建

自动修剪镜像

由于过期、状态或超出限制而不再被系统需要的 OpenShift 镜像仓库中的镜像将被自动修剪。集群管理员可以配置或暂停修剪自定义资源。

先决条件

您可以使用具有集群管理员权限的帐户访问 OpenShift Container Platform 集群。
安装 oc CLI。

步骤

验证名为 imagepruners.imageregistry.operator.openshift.io/cluster 的对象是否包含以下 spec 和 status 字段

spec:
  schedule: 0 0 * * * (1)
  suspend: false (2)
  keepTagRevisions: 3 (3)
  keepYoungerThanDuration: 60m (4)
  keepYoungerThan: 3600000000000 (5)
  resources: {} (6)
  affinity: {} (7)
  nodeSelector: {} (8)
  tolerations: [] (9)
  successfulJobsHistoryLimit: 3 (10)
  failedJobsHistoryLimit: 3 (11)
status:
  observedGeneration: 2 (12)
  conditions: (13)
  - type: Available
    status: "True"
    lastTransitionTime: 2019-10-09T03:13:45
    reason: Ready
    message: "Periodic image pruner has been created."
  - type: Scheduled
    status: "True"
    lastTransitionTime: 2019-10-09T03:13:45
    reason: Scheduled
    message: "Image pruner job has been scheduled."
  - type: Failed
    staus: "False"
    lastTransitionTime: 2019-10-09T03:13:45
    reason: Succeeded
    message: "Most recent image pruning job succeeded."

1	`schedule`：`CronJob` 格式的调度。这是一个可选字段，默认为每天午夜。
2	`suspend`：如果设置为 `true`，则暂停运行修剪的 `CronJob`。这是一个可选字段，默认为 `false`。新集群上的初始值为 `false`。
3	`keepTagRevisions`：每个标签要保留的修订版数量。这是一个可选字段，默认为 `3`。初始值为 `3`。
4	`keepYoungerThanDuration`：保留比此持续时间更短的镜像。这是一个可选字段。如果未指定值，则使用 `keepYoungerThan` 或默认值 `60m`（60 分钟）。
5	`keepYoungerThan`：已弃用。与 `keepYoungerThanDuration` 相同，但持续时间以纳秒为单位的整数指定。这是一个可选字段。设置 `keepYoungerThanDuration` 时，将忽略此字段。
6	`resources`：标准 Pod 资源请求和限制。这是一个可选字段。
7	`affinity`：标准 Pod 亲和性。这是一个可选字段。
8	`nodeSelector`：标准 Pod 节点选择器。这是一个可选字段。
9	`tolerations`：标准 Pod 容忍度。这是一个可选字段。
10	`successfulJobsHistoryLimit`：要保留的最大成功作业数。必须 `>= 1` 以确保报告指标。这是一个可选字段，默认为 `3`。初始值为 `3`。
11	`failedJobsHistoryLimit`：要保留的最大失败作业数。必须 `>= 1` 以确保报告指标。这是一个可选字段，默认为 `3`。初始值为 `3`。
12	`observedGeneration`：操作员观察到的代。
13	`conditions`：具有以下类型的标准条件对象 `Available`：指示是否已创建修剪作业。原因可能是就绪或错误。 `Scheduled`：指示是否已安排下一个修剪作业。原因可能是已安排、已暂停或错误。 `Failed`：指示最近的修剪作业是否失败。

镜像仓库操作员管理修剪程序的行为与在镜像仓库操作员的 ClusterOperator 对象上指定的 managementState 正交。如果镜像仓库操作员未处于 Managed 状态，则仍然可以通过修剪自定义资源配置和管理镜像修剪程序。

但是，镜像仓库操作员的 managementState 会改变已部署的镜像修剪程序作业的行为

Managed：镜像修剪程序的 --prune-registry 参数设置为 true。
Removed：镜像修剪程序的 --prune-registry 参数设置为 false，这意味着它只修剪 etcd 中的镜像元数据。

手动修剪镜像

修剪自定义资源为 OpenShift 镜像仓库中的镜像启用自动镜像修剪。但是，管理员可以手动修剪系统不再需要的镜像（由于过期、状态或超出限制）。有两种方法可以手动修剪镜像

在集群上运行作为 Job 或 CronJob 的镜像修剪。
运行 oc adm prune images 命令。

先决条件

要修剪镜像，您必须首先以具有访问令牌的用户身份登录到 CLI。用户还必须具有 system:image-pruner 集群角色或更高角色（例如，cluster-admin）。
公开镜像仓库。

步骤

要手动修剪系统不再需要的镜像（由于过期、状态或超出限制），请使用以下方法之一

通过为 pruner 服务帐户创建 YAML 文件，在集群上运行作为 Job 或 CronJob 的镜像修剪，例如

$ oc create -f <filename>.yaml

示例输出

kind: List
apiVersion: v1
items:
- apiVersion: v1
  kind: ServiceAccount
  metadata:
    name: pruner
    namespace: openshift-image-registry
- apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
    name: openshift-image-registry-pruner
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: system:image-pruner
  subjects:
  - kind: ServiceAccount
    name: pruner
    namespace: openshift-image-registry
- apiVersion: batch/v1
  kind: CronJob
  metadata:
    name: image-pruner
    namespace: openshift-image-registry
  spec:
    schedule: "0 0 * * *"
    concurrencyPolicy: Forbid
    successfulJobsHistoryLimit: 1
    failedJobsHistoryLimit: 3
    jobTemplate:
      spec:
        template:
          spec:
            restartPolicy: OnFailure
            containers:
            - image: "quay.io/openshift/origin-cli:4.1"
              resources:
                requests:
                  cpu: 1
                  memory: 1Gi
              terminationMessagePolicy: FallbackToLogsOnError
              command:
              - oc
              args:
              - adm
              - prune
              - images
              - --certificate-authority=/var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt
              - --keep-tag-revisions=5
              - --keep-younger-than=96h
              - --confirm=true
              name: image-pruner
            serviceAccountName: pruner

运行 oc adm prune images [<options>] 命令

$ oc adm prune images [<options>]

除非使用 --prune-registry=false，否则修剪镜像会从集成注册表中删除数据。

使用 --namespace 参数修剪镜像不会删除镜像，只会删除镜像流。镜像是非命名空间资源。因此，将修剪限制在特定命名空间会使计算其当前使用情况成为不可能。

默认情况下，集成注册表会缓存 Blob 的元数据，以减少对存储的请求次数并提高请求处理速度。修剪不会更新集成注册表缓存。修剪后仍然包含已修剪层的镜像将损坏，因为缓存中具有元数据的已修剪层不会被推送。因此，您必须在修剪后重新部署注册表以清除缓存

$ oc rollout restart deployment/image-registry -n openshift-image-registry

如果集成注册表使用 Redis 缓存，则必须手动清理数据库。

如果修剪后重新部署注册表不可行，则必须永久禁用缓存。

oc adm prune images 操作需要您的注册表的路由。默认情况下不会创建注册表路由。

**修剪镜像 CLI 配置选项** 表描述了您可以与 oc adm prune images <options> 命令一起使用的选项。

表 4. 修剪镜像 CLI 配置选项
选项	描述
`--all`	包含未推送到注册表但已通过拉取镜像镜像的镜像。默认情况下启用此选项。要将修剪限制为已推送到集成注册表的镜像，请传递 `--all=false`。
`--certificate-authority`	与 OpenShift Container Platform 托管的注册表通信时要使用的证书颁发机构文件的路径。默认为当前用户配置文件中的证书颁发机构数据。如果提供，则会启动安全连接。
`--confirm`	指示应进行修剪，而不是执行测试运行。这需要一个到集成容器镜像注册表的有效路由。如果此命令在集群网络外部运行，则必须使用 `--registry-url` 提供路由。
`--force-insecure`	使用此选项需谨慎。允许与通过 HTTP 托管或具有无效 HTTPS 证书的容器注册表建立不安全连接。
`--keep-tag-revisions=<N>`	对于每个镜像流，最多保留每个标签的 `N` 个镜像修订版（默认值为 `3`）。
`--keep-younger-than=<duration>`	不要修剪任何比当前时间年轻 `<duration>` 的镜像。或者，不要修剪任何被比当前时间年轻 `<duration>` 的其他对象引用的镜像（默认值为 `60m`）。
`--prune-over-size-limit`	修剪每个超过同一项目中定义的最小限制的镜像。此标志不能与 `--keep-tag-revisions` 或 `--keep-younger-than` 组合使用。
`--registry-url`	联系注册表时使用的地址。该命令尝试使用从托管镜像和镜像流确定的集群内部 URL。如果失败（无法解析或访问注册表），则需要使用此标志提供可行的替代路由。注册表主机名可以以 `https://` 或 `http://` 为前缀，强制使用特定的连接协议。
`--prune-registry`	结合其他选项规定的条件，此选项控制是否修剪与 OpenShift Container Platform 镜像 API 对象对应的注册表中的数据。默认情况下，镜像修剪会同时处理镜像 API 对象和注册表中的对应数据。当您只关心删除 etcd 内容、减少镜像对象数量但不关心清理注册表存储，或者您打算在注册表的适当维护窗口期间通过硬修剪注册表单独进行清理时，此选项非常有用。

镜像修剪条件

您可以对手动修剪的镜像应用条件。

要删除由 OpenShift Container Platform 管理的任何镜像，或带有注释 openshift.io/image.managed 的镜像
- 至少创建了 --keep-younger-than 分钟前，并且当前未被任何
  - 少于 --keep-younger-than 分钟前创建的 Pod
  - 少于 --keep-younger-than 分钟前创建的镜像流
  - 正在运行的 Pod
  - 挂起的 Pod
  - 副本控制器
  - 部署
  - 部署配置
  - 副本集
  - 构建配置
  - 构建
  - 作业
  - 定时作业
  - 有状态集
  - stream.status.tags[].items 中最新的 --keep-tag-revisions 个项目
- 超过同一项目中定义的最小限制，并且当前未被任何
  - 正在运行的 Pod
  - 挂起的 Pod
  - 副本控制器
  - 部署
  - 部署配置
  - 副本集
  - 构建配置
  - 构建
  - 作业
  - 定时作业
  - 有状态集
不支持从外部注册表修剪。
修剪镜像时，所有对该镜像的引用都将从所有在 status.tags 中引用该镜像的镜像流中删除。
不再被任何镜像引用的镜像层将被删除。

--prune-over-size-limit 标志不能与 --keep-tag-revisions 标志或 --keep-younger-than 标志组合使用。这样做会返回此操作不允许的信息。

通过使用 --prune-registry=false 将删除 OpenShift Container Platform 镜像 API 对象和注册表中的镜像数据分开，然后硬修剪注册表，可以缩小时间窗口，并且与尝试通过一个命令修剪两者相比更安全。但是，时间窗口并没有完全消除。

例如，您仍然可以创建一个引用镜像的 Pod，因为修剪会识别要修剪的镜像。您仍然应该跟踪在修剪操作期间创建的可能引用镜像的 API 对象，以便您可以减轻对已删除内容的任何引用。

不使用 --prune-registry 选项或使用 --prune-registry=true 重新进行修剪不会导致为先前通过 --prune-registry=false 修剪的镜像修剪镜像注册表中的关联存储。任何使用 --prune-registry=false 修剪的镜像只能通过硬修剪注册表才能从注册表存储中删除。

运行镜像修剪操作

步骤

查看修剪操作将删除什么
1. 保留最多三个标签修订版，并保留少于 60 分钟的资源（镜像、镜像流和 Pod）
  $ oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m
2. 修剪每个超过定义限制的镜像
  $ oc adm prune images --prune-over-size-limit

使用上一步中的选项执行修剪操作

$ oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m --confirm

$ oc adm prune images --prune-over-size-limit --confirm

使用安全或不安全连接

安全连接是首选和推荐的方法。它通过 HTTPS 协议进行，并强制进行证书验证。prune 命令始终尝试在可能的情况下使用它。如果不可能，在某些情况下它可能会回退到不安全的连接，这是危险的。在这种情况下，证书验证将被跳过或使用纯 HTTP 协议。

除非指定 --certificate-authority，否则在以下情况下允许回退到不安全连接

prune 命令使用 --force-insecure 选项运行。
提供的 registry-url 以 http:// 方案为前缀。
提供的 registry-url 是本地链接地址或 localhost。
当前用户的配置允许不安全连接。这可能是由于用户使用 --insecure-skip-tls-verify 登录或在提示时选择不安全连接造成的。

如果注册表由与 OpenShift Container Platform 使用的证书颁发机构不同的证书颁发机构保护，则必须使用 --certificate-authority 标志指定它。否则，prune 命令将失败并显示错误。

镜像修剪问题

镜像未被修剪

如果您的镜像不断累积，而 prune 命令仅删除您预期的一小部分，请确保您了解必须应用于将镜像视为修剪候选对象的镜像修剪条件。

确保您要删除的镜像在每个标签历史记录中的位置高于您选择的标签修订版阈值。例如，考虑一个名为 sha256:abz 的旧版和过时的镜像。通过在镜像已标记的命名空间中运行以下命令，该镜像在一个名为 myapp 的镜像流中被标记了三次

$ oc get is -n <namespace> -o go-template='{{range $isi, $is := .items}}{{range $ti, $tag := $is.status.tags}}'\
'{{range $ii, $item := $tag.items}}{{if eq $item.image "sha256:<hash>"}}{{$is.metadata.name}}:{{$tag.tag}} at position {{$ii}} out of {{len $tag.items}}\n'\
'{{end}}{{end}}{{end}}{{end}}'

示例输出

myapp:v2 at position 4 out of 5
myapp:v2.1 at position 2 out of 2
myapp:v2.1-may-2016 at position 0 out of 1

当使用默认选项时，镜像永远不会被修剪，因为它在 myapp:v2.1-may-2016 标签的历史记录中位于位置 0。为了使镜像被考虑进行修剪，管理员必须：

使用 oc adm prune images 命令指定 --keep-tag-revisions=0。

此操作将删除所有命名空间中所有带有底层镜像的标签，除非它们比较新或者被比指定阈值新的对象引用。
删除所有位置低于修订版阈值的 istags，这意味着 myapp:v2.1 和 myapp:v2.1-may-2016。
在历史记录中进一步移动镜像，方法是运行新的构建并推送到相同的 istag，或者标记其他镜像。这对于旧的发布标签并不总是理想的。

应避免在标签中包含特定镜像构建的日期或时间，除非必须无限期保留该镜像。此类标签往往在其历史记录中只有一个镜像，这会阻止它们被修剪。

对不安全注册表使用安全连接

如果您在 oc adm prune images 命令的输出中看到类似以下的消息，则您的注册表不安全，并且 oc adm prune images 客户端尝试使用安全连接

error: error communicating with registry: Get https://172.30.30.30:5000/healthz: http: server gave HTTP response to HTTPS client

建议的解决方案是保护注册表。否则，您可以强制客户端使用不安全连接，方法是将 --force-insecure 附加到命令；但是，不建议这样做。

对安全注册表使用不安全连接

如果在oc adm prune images命令的输出中看到以下错误之一，则表示您的注册表使用的是由证书颁发机构签名的证书，而该证书颁发机构与oc adm prune images客户端用于连接验证的证书颁发机构不同。

error: error communicating with registry: Get http://172.30.30.30:5000/healthz: malformed HTTP response "\x15\x03\x01\x00\x02\x02"
error: error communicating with registry: [Get https://172.30.30.30:5000/healthz: x509: certificate signed by unknown authority, Get http://172.30.30.30:5000/healthz: malformed HTTP response "\x15\x03\x01\x00\x02\x02"]

默认情况下，使用存储在用户配置文件中的证书颁发机构数据；与主API的通信也是如此。

使用--certificate-authority选项为容器镜像注册表服务器提供正确的证书颁发机构。

使用错误的证书颁发机构

以下错误表示用于签署安全容器镜像注册表证书的证书颁发机构与客户端使用的颁发机构不同。

error: error communicating with registry: Get https://172.30.30.30:5000/: x509: certificate signed by unknown authority

确保使用标志--certificate-authority提供正确的证书颁发机构。

作为变通方法，可以添加--force-insecure标志。但是，不推荐这样做。

其他资源

访问注册表
公开注册表
有关如何在OpenShift Container Platform中创建注册表路由的信息，请参阅OpenShift Container Platform中的镜像注册表操作符。

彻底清理注册表

OpenShift Container Registry可能会累积未被OpenShift Container Platform集群的etcd引用的blob。因此，基本的清理镜像过程无法对它们进行操作。这些被称为孤立blob。

孤立blob可能来自以下场景：

使用oc delete image <sha256:image-id>命令手动删除镜像，这只会从etcd中删除镜像，而不会从注册表的存储中删除。
守护程序故障启动的注册表推送，导致某些blob被上传，但镜像清单（作为最后一个组件上传）未上传。所有唯一的镜像blob都将成为孤立blob。
由于配额限制，OpenShift Container Platform拒绝镜像。
标准镜像清理程序删除镜像清单，但在删除相关blob之前被中断。
注册表清理程序中的错误，无法删除预期的blob，导致引用它们的镜像对象被删除，并且blob成为孤立blob。

彻底清理注册表是与基本镜像清理不同的单独过程，允许集群管理员删除孤立blob。如果您在OpenShift Container Registry中存储空间不足，并且认为存在孤立blob，则应执行彻底清理。

这应该是一个不频繁的操作，只有当您有证据表明已创建大量新的孤立blob时才需要执行。否则，您可以定期执行标准镜像清理，例如每天一次（取决于创建的镜像数量）。

步骤

要彻底清理注册表中的孤立blob：

登录。

以kubeadmin或具有访问openshift-image-registry命名空间权限的其他特权用户身份使用CLI登录集群。
运行基本镜像清理.

基本镜像清理会删除不再需要的额外镜像。彻底清理本身不会删除镜像。它只删除存储在注册表存储中的blob。因此，您应该在彻底清理之前运行此命令。
将注册表切换到只读模式。

如果注册表未运行在只读模式下，则在清理的同时发生的任何推送操作都会：
- 失败并导致新的孤立blob，或者
- 成功，尽管无法提取镜像（因为一些引用的blob已被删除）。
在将注册表切换回读写模式之前，推送将不会成功。因此，必须仔细安排彻底清理。

将注册表切换到只读模式：
1. 在configs.imageregistry.operator.openshift.io/cluster中，将spec.readOnly设置为true。
  $ oc patch configs.imageregistry.operator.openshift.io/cluster -p '{"spec":{"readOnly":true}}' --type=merge

添加system:image-pruner角色。

用于运行注册表实例的服务帐户需要额外的权限才能列出某些资源。

获取服务帐户名称

$ service_account=$(oc get -n openshift-image-registry \
    -o jsonpath='{.spec.template.spec.serviceAccountName}' deploy/image-registry)

将system:image-pruner集群角色添加到服务帐户

$ oc adm policy add-cluster-role-to-user \
    system:image-pruner -z \
    ${service_account} -n openshift-image-registry

可选：以试运行模式运行清理程序。

要查看将删除多少个blob，请以试运行模式运行彻底清理程序。实际上不会进行任何更改。以下示例引用了一个名为image-registry-3-vhndw的镜像注册表pod。

$ oc -n openshift-image-registry exec pod/image-registry-3-vhndw -- /bin/sh -c '/usr/bin/dockerregistry -prune=check'

或者，要获取清理候选对象的精确路径，请提高日志级别。

$ oc -n openshift-image-registry exec pod/image-registry-3-vhndw -- /bin/sh -c 'REGISTRY_LOG_LEVEL=info /usr/bin/dockerregistry -prune=check'

示例输出

time="2017-06-22T11:50:25.066156047Z" level=info msg="start prune (dry-run mode)" distribution_version="v2.4.1+unknown" kubernetes_version=v1.6.1+$Format:%h$ openshift_version=unknown
time="2017-06-22T11:50:25.092257421Z" level=info msg="Would delete blob: sha256:00043a2a5e384f6b59ab17e2c3d3a3d0a7de01b2cabeb606243e468acc663fa5" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6
time="2017-06-22T11:50:25.092395621Z" level=info msg="Would delete blob: sha256:0022d49612807cb348cabc562c072ef34d756adfe0100a61952cbcb87ee6578a" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6
time="2017-06-22T11:50:25.092492183Z" level=info msg="Would delete blob: sha256:0029dd4228961086707e53b881e25eba0564fa80033fbbb2e27847a28d16a37c" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6
time="2017-06-22T11:50:26.673946639Z" level=info msg="Would delete blob: sha256:ff7664dfc213d6cc60fd5c5f5bb00a7bf4a687e18e1df12d349a1d07b2cf7663" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6
time="2017-06-22T11:50:26.674024531Z" level=info msg="Would delete blob: sha256:ff7a933178ccd931f4b5f40f9f19a65be5eeeec207e4fad2a5bafd28afbef57e" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6
time="2017-06-22T11:50:26.674675469Z" level=info msg="Would delete blob: sha256:ff9b8956794b426cc80bb49a604a0b24a1553aae96b930c6919a6675db3d5e06" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6
...
Would delete 13374 blobs
Would free up 2.835 GiB of disk space
Use -prune=delete to actually delete the data

运行彻底清理。

在正在运行的image-registry pod实例中执行以下命令以运行彻底清理。以下示例引用了一个名为image-registry-3-vhndw的镜像注册表pod。
```
$ oc -n openshift-image-registry exec pod/image-registry-3-vhndw -- /bin/sh -c '/usr/bin/dockerregistry -prune=delete'
```
示例输出
```
Deleted 13374 blobs
Freed up 2.835 GiB of disk space
```
将注册表切换回读写模式。

清理完成后，可以将注册表切换回读写模式。在configs.imageregistry.operator.openshift.io/cluster中，将spec.readOnly设置为false。
```
$ oc patch configs.imageregistry.operator.openshift.io/cluster -p '{"spec":{"readOnly":false}}' --type=merge
```

清理cron作业

Cron作业可以执行成功作业的清理，但可能无法正确处理失败的作业。因此，集群管理员应手动定期清理作业。他们还应将对cron作业的访问权限限制为一小部分受信任的用户，并设置适当的配额以防止cron作业创建过多的作业和pod。

其他资源