设置和配置 Registry

使用此页面为 Alauda Container Platform Registry 配置存储、Registry 请求行为、服务账户拉取凭证、镜像限制和计划的镜像清理。

前提条件

Registry 已安装，并且 Config/cluster 已存在。
你有权限更新 configs.imageregistry.operator.alauda.io、imagepruners.imageregistry.operator.alauda.io、LimitRange、ResourceQuota 及相关 Kubernetes 资源。
对于持久化存储，请在配置 Config/cluster 之前准备好存储后端和所需凭证。

配置开发存储

警告：emptyDir 将镜像数据存储在临时 Pod 存储中。Registry Pod 从其节点中移除时，数据会被删除；此存储类型不能与多个 Registry 副本一起使用。仅在可以丢弃所有推送镜像数据的开发或测试环境中使用。请勿将 emptyDir 用于生产环境或任何必须保留镜像的环境。

修补 Config/cluster。null 字段会从当前配置中移除互斥的存储后端：

kubectl patch configs.imageregistry.operator.alauda.io cluster \
  --type=merge \
  -p '{
    "spec": {
      "managementState": "Managed",
      "replicas": 1,
      "storage": {
        "emptyDir": {},
        "pvc": null,
        "s3": null,
        "swift": null,
        "gcs": null,
        "ibmcos": null,
        "azure": null
      },
      "resources": {
        "requests": {
          "cpu": "500m",
          "memory": "500Mi"
        },
        "limits": {
          "cpu": "500m",
          "memory": "500Mi"
        }
      }
    }
  }'

验证配置并检查发布状态：

kubectl get configs.imageregistry.operator.alauda.io cluster -o yaml
kubectl -n image-registry-system rollout status deployment/image-registry --timeout=300s

预期结果：

Config/cluster 报告 Available=True、Progressing=False 和 Degraded=False。
image-registry Deployment 成功发布。

配置 PVC 存储

生产环境请使用持久化后端。此示例使用 ReadWriteOnce、一个 Registry 副本，以及 Operator 针对 RWO 存储所需的 Recreate 发布策略。创建名为 image-registry-pvc.yaml 的文件：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: image-registry
  namespace: image-registry-system
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi
  storageClassName: <storage-class-name>

占位符	描述
`<storage-class-name>`	为 Registry PVC 提供资源的 StorageClass。运行 `kubectl get storageclass` 以列出可用值。对于多副本 Registry 部署，请选择支持所需访问模式的存储。

应用 PVC：

kubectl apply -f image-registry-pvc.yaml

修补 Config/cluster 以使用 PVC。使用合并修补，以免删除其他 Config/cluster.spec 字段（例如路由或拉取密钥设置）。null 字段会从当前配置中移除互斥的存储后端：

kubectl patch configs.imageregistry.operator.alauda.io cluster \
  --type=merge \
  -p '{
    "spec": {
      "managementState": "Managed",
      "replicas": 1,
      "rolloutStrategy": "Recreate",
      "storage": {
        "managementState": "Unmanaged",
        "emptyDir": null,
        "pvc": {
          "claim": "image-registry"
        },
        "s3": null,
        "swift": null,
        "gcs": null,
        "ibmcos": null,
        "azure": null
      },
      "resources": {
        "requests": {
          "cpu": "500m",
          "memory": "500Mi"
        },
        "limits": {
          "cpu": "500m",
          "memory": "500Mi"
        }
      }
    }
  }'

验证 PVC、配置和发布状态：

kubectl -n image-registry-system get pvc image-registry
kubectl get configs.imageregistry.operator.alauda.io cluster -o yaml
kubectl -n image-registry-system rollout status deployment/image-registry --timeout=300s

预期结果：

image-registry PVC 的状态为 Bound。
Config/cluster 报告 Available=True、Progressing=False 和 Degraded=False。
image-registry Deployment 成功发布。

配置 S3 兼容存储凭证

在配置 Config/cluster 之前，创建用户管理的存储 Secret。Operator 会将此 Secret 合并到 Registry 私有配置中：

kubectl -n image-registry-system create secret generic image-registry-private-configuration-user \
  --from-literal=REGISTRY_STORAGE_S3_ACCESSKEY=<access-key-id> \
  --from-literal=REGISTRY_STORAGE_S3_SECRETKEY=<secret-access-key> \
  --dry-run=client -o yaml | kubectl apply -f -

占位符	描述
`<access-key-id>`	S3 兼容存储帐户的访问密钥 ID。请从存储管理员处获取。
`<secret-access-key>`	S3 兼容存储帐户的秘密访问密钥。仅将其存储在 Kubernetes Secret 中。

在不打印其内容的情况下验证 Secret：

kubectl -n image-registry-system get secret image-registry-private-configuration-user \
  -o jsonpath='{.type}{"\n"}'
kubectl -n image-registry-system get secret image-registry-private-configuration-user \
  -o jsonpath='{.data}' | wc -c

预期结果：

Secret 存在于 image-registry-system 中。
第二条命令返回非零字节数。请勿打印或解码 Secret 数据。

当客户端无法直接访问对象存储端点，且所有内容都必须通过 Registry 提供时，使用 disableRedirect: true。

如果 S3 端点使用私有 CA，请创建包含所需键的引用 ConfigMap：

kubectl -n image-registry-system create configmap <trusted-ca-configmap> \
  --from-file=ca-bundle.crt=/path/to/ca-bundle.crt \
  --dry-run=client -o yaml | kubectl apply -f -

在不显示证书的情况下验证 ConfigMap 键：

kubectl -n image-registry-system get configmap <trusted-ca-configmap> \
  -o jsonpath='{.data.ca-bundle\.crt}' | wc -c

预期结果：

对于 ca-bundle.crt，命令返回非零字节数。

修补 Config/cluster。null 字段会从当前配置中移除互斥的存储后端：

kubectl patch configs.imageregistry.operator.alauda.io cluster \
  --type=merge \
  -p '{
    "spec": {
      "managementState": "Managed",
      "replicas": 2,
      "storage": {
        "managementState": "Unmanaged",
        "emptyDir": null,
        "pvc": null,
        "swift": null,
        "gcs": null,
        "ibmcos": null,
        "azure": null,
        "s3": {
          "bucket": "<bucket-name>",
          "region": "<region>",
          "regionEndpoint": "https://<s3-endpoint>",
          "trustedCA": {
            "name": "<trusted-ca-configmap>"
          }
        }
      },
      "disableRedirect": true
    }
  }'

占位符	描述
`<bucket-name>`	用于存储 Registry Blob 的现有对象存储桶或等效容器。
`<region>`	存储后端所需的地域值。请使用提供商的值，或 S3 兼容服务所需的值。
`<s3-endpoint>`	Registry Pod 可访问的 S3 兼容端点主机和可选端口，不包含 `https://`，也不包含存储桶名称。示例提供了 `https://` 方案。
`<trusted-ca-configmap>`	`image-registry-system` 中包含对象存储端点 CA 证书的 ConfigMap。当端点使用 Registry Pod 信任的公共 CA 时，省略 `trustedCA`。

当前 operator 支持以下存储字段：emptyDir、pvc、s3、swift、gcs、
ibmcos 和 azure。请勿配置其他存储字段。

注意：Config CRD 还公开了一个 storage.oss 字段，该字段继承自上游 image registry operator。此 operator 未实现该字段。将 storage.oss 设置为任何值都会被视为“未配置存储后端”：Operator 会报告原因为 StorageNotConfigured 的 Degraded=True，并且 Registry 数据平面不会进行调谐。仅使用上面列出的七个受支持字段。

验证配置和发布状态：

kubectl get configs.imageregistry.operator.alauda.io cluster -o yaml
kubectl -n image-registry-system rollout status deployment/image-registry --timeout=300s
kubectl -n image-registry-system logs deployment/image-registry -c registry --tail=80

预期结果：

Config/cluster 报告 Available=True、Progressing=False 和 Degraded=False。
Registry 日志中不显示存储身份验证、存储桶、端点或证书错误。

配置云存储后端

当相应的平台集成和凭证可用时，Operator 可以使用 Swift、GCS、IBM COS 或 Azure 存储。在 Config/cluster.spec.storage 中仅配置一个存储字段；使用上文所示的相同合并补丁模式，并将其他受支持的存储字段设置为 null。

后端	主要的 `Config/cluster.spec.storage` 字段	所需的用户管理 Secret 数据
Swift	`swift.authURL`、`swift.authVersion`、`swift.container`、`swift.domain`、`swift.domainID`、`swift.tenant`、`swift.tenantID` 和 `swift.regionName`	`REGISTRY_STORAGE_SWIFT_USERNAME` 和 `REGISTRY_STORAGE_SWIFT_PASSWORD`，或应用凭证密钥 `REGISTRY_STORAGE_SWIFT_APPLICATIONCREDENTIALID`、`REGISTRY_STORAGE_SWIFT_APPLICATIONCREDENTIALNAME` 和 `REGISTRY_STORAGE_SWIFT_APPLICATIONCREDENTIALSECRET`，或 `REGISTRY_STORAGE_SWIFT_TOKENID`。
GCS	`gcs.bucket`、`gcs.region`、`gcs.projectID` 和可选的 `gcs.keyID`	包含服务账户密钥文件的 `REGISTRY_STORAGE_GCS_KEYFILE`。
IBM COS	`ibmcos.bucket`、`ibmcos.location`、`ibmcos.resourceGroupName`、`ibmcos.resourceKeyCRN` 和 `ibmcos.serviceInstanceCRN`	`REGISTRY_STORAGE_IBMCOS_IAMAPIKEY`。
Azure	`azure.accountName`、`azure.container`、`azure.cloudName` 和可选的 `azure.networkAccess`	`REGISTRY_STORAGE_AZURE_ACCOUNTKEY`。

Provider 集成可以填充地域、项目、账户或端点信息等平台特定值。请与存储管理员确认所需的 Provider 资源和凭证。配置后端后，按照上述存储流程所示，验证 Config/cluster 条件和 Registry 发布状态。排查问题时请勿打印 Secret 数据。

配置请求处理

使用 Config/cluster.spec.readOnly 拒绝镜像推送和删除。使用 requests 设置限制并发读取和写入、排队请求数以及队列等待时间：

kubectl patch configs.imageregistry.operator.alauda.io cluster \
  --type=merge \
  -p '{
    "spec": {
      "readOnly": false,
      "requests": {
        "read": {
          "maxRunning": 100,
          "maxInQueue": 500,
          "maxWaitInQueue": "30s"
        },
        "write": {
          "maxRunning": 50,
          "maxInQueue": 200,
          "maxWaitInQueue": "30s"
        }
      }
    }
  }'

当集群代理设置不足时，proxy.http、proxy.https 和 proxy.noProxy 字段用于配置 Registry 出站连接。logLevel 接受 Normal、Debug、Trace 或 TraceAll。Config/cluster.spec 还支持资源请求和限制、节点选择、容忍度、亲和性以及拓扑分布。

验证请求处理设置和发布状态：

kubectl get configs.imageregistry.operator.alauda.io cluster -o yaml
kubectl -n image-registry-system rollout status deployment/image-registry --timeout=300s

预期结果：

Config/cluster.spec.readOnly 和 Config/cluster.spec.requests 包含请求的值。
Registry Deployment 成功完成发布。

配置托管服务账户拉取 Secret

Operator 包含一个托管的 imagePullSecret 控制器。当 Config/cluster 由其管理时，该控制器可以为内部 Registry 创建、注入、刷新和删除服务账户拉取 Secret。

使用其他主机或忽略的命名空间修补 Config/cluster。此补丁中的数组字段会替换当前数组，因此请包含所有必须保留配置的主机和命名空间：

kubectl patch configs.imageregistry.operator.alauda.io cluster \
  --type=merge \
  -p '{
    "spec": {
      "managementState": "Managed",
      "imagePullSecret": {
        "managementState": "Managed",
        "additionalRegistryHosts": [
          "registry.example.com"
        ],
        "ignoredNamespaces": [
          "kube-public"
        ],
        "ignoreSystemNamespaces": true
      }
    }
  }'

验证配置：

kubectl get configs.imageregistry.operator.alauda.io cluster -o yaml

预期结果：

Config/cluster.spec.imagePullSecret 包含配置的管理状态、其他主机和忽略的命名空间设置。

控制器会异步协调拉取凭证。在控制器有足够时间完成协调后，验证托管的 RoleBinding 和一个 ServiceAccount：

kubectl -n <workload-namespace> get rolebinding image-registry-system-image-pullers -o yaml
kubectl -n <workload-namespace> get serviceaccount default \
  -o jsonpath='{.imagePullSecrets[*].name}{"\n"}'
kubectl -n <workload-namespace> get secret \
  -l imageregistry.operator.alauda.io/managed-pull-secret=true -o name

预期结果：

RoleBinding 将 system:image-puller ClusterRole 授予命名空间中的服务账户。
异步协调后，ServiceAccount 至少列出一个托管的拉取 Secret。
至少存在一个带有 managed-pull-secret 标签的 Secret。使用 kubectl get secret 仅检查元数据；不要打印或解码凭证数据。

占位符	描述
`<workload-namespace>`	应注入托管 ServiceAccount 拉取凭证的命名空间。它不得列在 `ignoredNamespaces` 中，并且必须满足 `ignoreSystemNamespaces`。

配置镜像限制

在 Registry 中，镜像大小和标签数量限制通过 Kubernetes LimitRange 和 ResourceQuota 对象表示。

创建名为 team-a-image-quota.yaml 的文件以配置命名空间级别的配额：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: image-registry-quota
  namespace: team-a
spec:
  hard:
    alauda.io/imagestreams: "20"
    alauda.io/images: "200"
    alauda.io/image-tags: "200"

应用配额：

kubectl apply -f team-a-image-quota.yaml

创建名为 team-a-image-limits.yaml 的文件以配置每个镜像和每个 ImageStream 的限制：

apiVersion: v1
kind: LimitRange
metadata:
  name: image-registry-limits
  namespace: team-a
spec:
  limits:
    - type: alauda.io/Image
      max:
        storage: 1Gi
    - type: alauda.io/ImageStream
      max:
        alauda.io/images: "100"
        alauda.io/image-tags: "100"

应用限制：

kubectl apply -f team-a-image-limits.yaml

验证配额和限制：

kubectl -n team-a get resourcequota image-registry-quota -o yaml
kubectl -n team-a get limitrange image-registry-limits -o yaml

预期结果：

ResourceQuota 包含配置的 Image API 限制。
LimitRange 包含配置的 alauda.io/Image 和 alauda.io/ImageStream 限制。

配置计划的镜像清理

创建或更新单实例 ImagePruner/cluster 以配置计划的镜像清理。在启用计划前确认保留策略，因为清理会移除未使用的镜像元数据。

创建名为 image-pruner.yaml 的文件：

apiVersion: imageregistry.operator.alauda.io/v1
kind: ImagePruner
metadata:
  name: cluster
spec:
  schedule: "0 0 * * *"
  suspend: false
  keepTagRevisions: 3
  keepYoungerThanDuration: 60m
  resources:
    requests:
      cpu: 500m
      memory: 500Mi
    limits:
      cpu: 500m
      memory: 500Mi

应用配置：

kubectl apply -f image-pruner.yaml

验证清理器资源和渲染后的 CronJob：

kubectl get imagepruners.imageregistry.operator.alauda.io cluster -o yaml
kubectl -n image-registry-system get cronjob image-pruner

预期结果：

ImagePruner/cluster 包含配置的计划和保留策略。
Operator 在 image-registry-system 中渲染 image-pruner CronJob。

生成的 CronJob 运行 ac adm prune images --confirm。当 Registry 管理状态为 Managed 时，Operator 会添加 --prune-registry=true，因此计划的作业也会在镜像元数据清理后执行 Registry 垃圾回收。对于手动运行的清理，仅当需要回收 blob 时添加 --prune-registry；否则，应将垃圾回收作为单独的经审核操作执行。

有关手动清理和 Registry 垃圾回收命令，请参阅管理访问权限和清理。

操作存储

对于由 PVC 支持的 Registry 存储：

kubectl -n image-registry-system get pvc
kubectl -n image-registry-system describe pvc image-registry
kubectl get pv

常见操作：

如果 PVC 处于 pending 状态，请检查 StorageClass、访问模式、容量、配额和事件。
如果 Registry Pod 无法挂载存储，请检查 PV 绑定、节点挂载和后端存储可用性。
如果镜像元数据存在但 blob 数据缺失，请确认 Registry 是否使用了 emptyDir，或存储后端是否已更改。
在确认数据保留决策之前，不要删除 PVC、PV 或对象存储数据。

#设置和配置 Registry

#目录

#前提条件

#配置开发存储

#配置 PVC 存储

#配置 S3 兼容存储凭证

#配置云存储后端

#配置请求处理

#配置托管服务账户拉取 Secret

#配置镜像限制

#配置计划的镜像清理

#操作存储

设置和配置 Registry

目录

前提条件

配置开发存储

配置 PVC 存储

配置 S3 兼容存储凭证

配置云存储后端

配置请求处理

配置托管服务账户拉取 Secret

配置镜像限制

配置计划的镜像清理

操作存储