文档教程云原生【免费下载链接】follow-me-install-kubernetes-cluster和我一步步部署 kubernetes 集群项目地址https://gitcode.com/gh_mirrors/fo/follow-me-install-kubernetes-cluster点击查看免费下载本文是「和我一步步部署 kubernetes 集群」系列的第九章讲解使用 docker 官方registry:2镜像部署一套生产级私有镜像仓库的完整步骤采用TLS 证书加密传输、HTTP Basic 认证、ceph RGWSwift 协议作为后端存储三层加固方案。读完本文你将掌握 ceph RGW 账号体系user/subuser/key的创建、registry 证书与认证文件生成、config.yml参数精解、镜像 push/查询/digest 获取/删除等全部运维操作以及两种典型故障416、503的根因与修复方法。本文档对应仓库源码09.Registry.md项目整体的组件版本与配置策略可参考 00.组件版本和配置策略.md其中明确将「Registry 镜像库docker-registry、harbor」列为集群插件之一。部署背景与整体架构本方案的核心目标是在无法访问公网镜像仓库或出于安全、合规、内网隔离需求时自建一套仅内网可访问的私有 docker registry。它具备三方面安全能力传输加密TLSregistry 的 HTTP 服务使用 x509 证书提供 HTTPS 访问docker 客户端通过/etc/docker/certs.d/host:port目录信任该证书访问认证HTTP Basic Auth使用 htpasswd 生成的 bcrypt 口令文件配合docker login进行账号密码认证数据持久化ceph RGW镜像数据不落在 registry 容器本地磁盘而是通过Swift 协议写入 ceph RGWRADOS Gateway对象存储实现分布式、可扩展的存储后端。示例环境使用两台机器IP 规划如下实际部署请替换为你的环境地址角色IP说明ceph rgw 节点172.27.132.66提供对象存储服务rgw 默认监听 7480 端口docker registry 节点172.27.132.67运行registry:2容器对外暴露 8000 端口前置条件已按 02.创建CA根证书和秘钥.md 创建集群共享的 CA 根证书与ca-config.jsonregistry 证书将复用这套 CA 签名因此本文假设 CA 文件位于/etc/kubernetes/cert/目录下已安装 docker可参考附件 F.部署docker.md其中docker-daemon.json里配置的insecure-registries与registry-mirrors是自建仓库场景下的常见配套项已部署 ceph 集群与 rgw 节点。如果你更倾向使用功能更完整的 Harbor含 Web 管理界面、镜像复制、漏洞扫描等可参考本仓库附件 D.部署Harbor-Registry.md本文后续内容全部围绕 docker 官方 registry v2 镜像展开。第一步部署 ceph RGW 节点在 ceph 管理节点上执行ceph-deploy rgw create命令即可在指定节点上创建 RGWRADOS Gateway守护进程$ ceph-deploy rgw create 172.27.132.66 # rgw 默认监听7480端口 $命令执行完成后rgw 默认监听7480 端口并提供 REST 接口兼容 Swift 与 S3 协议。本方案中 registry 将通过 Swift 协议访问该端口上的auth/v1认证端点详见下文config.yml中的RGW_AUTH_URL配置。第二步创建测试账号 demo使用radosgw-admin命令创建一个名为demo的测试用户作为访问 rgw 存储的账号载体$ radosgw-admin user create --uiddemo --display-nameceph rgw demo user $参数说明--uid用户唯一标识user id--display-name用户显示名称。第三步创建 demo 账号的 swift 子账号这里有一个关键限制需要明确当前版本的 docker registry 只支持使用 Swift 协议访问 ceph rgw 存储暂时不支持 S3 协议。因此需要为demo用户创建一个 Swift 类型的子账号subuser$ radosgw-admin subuser create --uid demo --subuserdemo:swift --accessfull --secretsecretkey --key-typeswift $参数说明--subuserdemo:swift子账号 ID命名规则为uid:subuser名此处即demo用户的swift子账号--accessfull授予子账号 full 访问权限也可以按需设置为read、write、read-write等--key-typeswift指定密钥类型为 Swiftregistry 访问 rgw 时使用--secretsecretkey先指定一个临时 secret下一步会重新生成真正的密钥。第四步创建 demo:swift 子账号的 secret key执行以下命令为子账号生成真正的 Swift 密钥$ radosgw-admin key create --subuserdemo:swift --key-typeswift --gen-secret { user_id: demo, display_name: ceph rgw demo user, email: , suspended: 0, max_buckets: 1000, auid: 0, subusers: [ { id: demo:swift, permissions: full-control } ], keys: [ { user: demo, access_key: 5Y1B1SIJ2YHKEHO5U36B, secret_key: nrIvtPqUj7pUlccLYPuR3ntVzIa50DToIpe7xFjT } ], swift_keys: [ { user: demo:swift, secret_key: ttQcU1O17DFQ4I9xzKqwgUe7WIYYX99zhcIfU9vb } ], caps: [], op_mask: read, write, delete, default_placement: , placement_tags: [], bucket_quota: { enabled: false, max_size_kb: -1, max_objects: -1 }, user_quota: { enabled: false, max_size_kb: -1, max_objects: -1 }, temp_url_keys: [] }返回的 JSON 是demo用户的完整信息重点关注以下字段subusers显示demo:swift子账号权限为full-controlkeysS3 类型的访问密钥对access_key/secret_keyswift_keysSwift 类型的密钥列表其中ttQcU1O17DFQ4I9xzKqwgUe7WIYYX99zhcIfU9vb就是子账号demo:swift的 secret key后续config.yml中的RGW_SECRET_KEY将直接使用它op_mask操作掩码read, write, deletebucket_quota/user_quota配额均为enabled: false即不限容量与对象数。第五步创建 docker registry5.1 创建 registry 使用的 x509 证书首先创建工作目录并编写证书签名请求CSR文件$ mkdir -p registry/{auth,certs} $ cat registry-csr.json EOF { CN: registry, hosts: [ 127.0.0.1, 172.27.132.67 ], key: { algo: rsa, size: 2048 }, names: [ { C: CN, ST: BeiJing, L: BeiJing, O: k8s, OU: opsnull } ] } EOF $ cfssl gencert -ca/etc/kubernetes/cert/ca.pem \ -ca-key/etc/kubernetes/cert/ca-key.pem \ -config/etc/kubernetes/cert/ca-config.json \ -profilekubernetes registry-csr.json | cfssljson -bare registry $ cp registry.pem registry-key.pem registry/certs $要点说明复用集群 CA这里直接复用 02.创建CA根证书和秘钥.md 中创建的ca.pem、ca-key.pem与ca-config.json无需重新创建根证书hosts字段必须指定 registry 的NodeIP示例为172.27.132.67同时保留127.0.0.1便于本机访问如果后续打算用域名访问 registry还需将域名加入该列表-profilekubernetes对应ca-config.json中定义的 profile其 usages 包含signing、key encipherment、server auth、client auth因此生成的 registry 证书同时具备服务端与客户端认证能力可与集群内其他组件相互认证生成的registry.pem与registry-key.pem拷贝到registry/certs目录供容器挂载。5.2 创建 HTTP Basic 认证文件使用registry:2镜像内置的 htpasswd 工具生成认证口令文件用户名foo密码foo123$ docker run --entrypoint htpasswd registry:2 -Bbn foo foo123 registry/auth/htpasswd $ cat registry/auth/htpasswd foo:$2y$05$iZaM45Jxlcg0DJKXZMggLOibAsHLGybyU.CgU9AHqWcVDyBjiScN.要点说明--entrypoint htpasswd覆盖镜像默认入口直接执行 htpasswd-B使用bcrypt算法加密密码这是 registry 的 htpasswd 认证器明确要求的算法-bn表示批量模式不交互输入生成的htpasswd文件中冒号前为用户名冒号后为 bcrypt 哈希串示例中以$2y$05$开头明文密码不会出现在文件中该文件将挂载到容器内的/auth/htpasswd供config.yml的auth.htpasswd.path引用。5.3 配置 registry 参数config.yml首先导出后端存储的连接参数为环境变量便于在配置文件中引用export RGW_AUTH_URLhttp://172.27.132.66:7480/auth/v1 export RGW_USERdemo:swift export RGW_SECRET_KEYttQcU1O17DFQ4I9xzKqwgUe7WIYYX99zhcIfU9vb cat config.yml EOF # https://docs.docker.com/registry/configuration/#list-of-configuration-options version: 0.1 log: level: info fromatter: text fields: service: registry storage: cache: blobdescriptor: inmemory delete: enabled: true swift: authurl: ${RGW_AUTH_URL} username: ${RGW_USER} password: ${RGW_SECRET_KEY} container: registry auth: htpasswd: realm: basic-realm path: /auth/htpasswd http: addr: 0.0.0.0:8000 headers: X-Content-Type-Options: [nosniff] tls: certificate: /certs/registry.pem key: /certs/registry-key.pem health: storagedriver: enabled: true interval: 10s threshold: 3 EOF [k8szhangjun-k8s-01 cert]$ cp config.yml registry [k8szhangjun-k8s-01 cert]$ scp -r registry 172.27.132.67:/opt/k8s配置文件各段落的含义逐项说明配置项作用version: 0.1registry 配置文件版本号registry v2 使用 0.1log.level: info日志级别排查问题时可以临时改为debuglog.fields.service日志中附加的 service 标识字段storage.cache.blobdescriptor: inmemoryblob 描述符使用内存缓存提高元数据访问性能storage.delete.enabled: true开启镜像删除能力这是后续 DELETE API 生效的前提storage.swift.authurlSwift 认证端点即 rgw 的http://rgw-ip:7480/auth/v1storage.swift.usernameSwift 用户即demo:swift子账号storage.swift.passwordSwift 密钥即第四步生成的ttQc...storage.swift.container对象容器名示例为registry镜像数据将存放在该容器中auth.htpasswd.realmBasic 认证的 realm 提示信息auth.htpasswd.path认证口令文件在容器内的路径对应挂载的/auth目录http.addr监听地址与端口0.0.0.0:8000http.headers附加 HTTP 响应头X-Content-Type-Options: nosniff用于防 MIME 嗅探http.tls.certificate / keyTLS 证书与私钥在容器内的路径对应挂载的/certs目录health.storagedriver存储驱动健康检查interval: 10s、threshold: 3表示每 10 秒检查一次连续 3 次失败则标记不健康补充说明storage.swift指定后端使用Swift 接口协议的存储这里配置的正是 ceph rgw 存储参数auth.htpasswd指定了 HTTP Basic 认证的口令文件路径http.tls指定了 registry HTTP 服务器的证书和私钥文件路径示例配置中的fromatter: text为原文档笔误官方配置键为formatter: text参考 Docker Registry 官方配置文档使用时建议写为formatter若你的后端不是 ceph rgw例如本地磁盘、S3、OSS 等可以跳过「部署 ceph RGW 节点」到「创建 secret key」这几节直接从本步「创建 docker registry」开始将storage段替换为对应驱动即可。最后把配置目录分发到 registry 节点$ scp -r registry 172.27.132.67:/opt/k8s5.4 启动 registry 容器登录 registry 节点IP 为 172.27.132.67并启动容器ssh k8s172.27.132.67 $ docker run -d -p 8000:8000 --privileged \ -v /opt/k8s/registry/auth/:/auth \ -v /opt/k8s/registry/certs:/certs \ -v /opt/k8s/registry/config.yml:/etc/docker/registry/config.yml \ --name registry registry:2参数说明-p 8000:8000将容器内0.0.0.0:8000映射到宿主机 8000 端口--privileged必须携带缺少该参数会导致 docker 客户端 login 时返回 503详见文末「常见问题」-v挂载三个数据卷认证目录对应/auth、证书目录对应/certs、配置文件覆盖镜像默认的/etc/docker/registry/config.ymlregistry:2为 docker 官方 registry v2 镜像标签。第六步向 registry push image6.1 配置 docker 客户端信任 CA 证书将签署 registry 证书的 CA 证书拷贝到/etc/docker/certs.d/host:port目录下让 docker 客户端在访问172.27.132.67:8000时能够验证服务器证书链[k8szhangjun-k8s-01 cert]$ sudo mkdir -p /etc/docker/certs.d/172.27.132.67:8000 [k8szhangjun-k8s-01 cert]$ sudo cp /etc/kubernetes/cert/ca.pem /etc/docker/certs.d/172.27.132.67:8000/ca.crt注意目录名中的端口号与 registry 对外端口必须完全一致172.27.132.67:8000docker 会按该规则精确匹配主机。6.2 登录私有 registry$ docker login 172.27.132.67:8000 Username: foo Password: Login Succeeded登录成功后认证信息被写入~/.docker/config.json文件$ cat ~/.docker/config.json { auths: { 172.27.132.67:8000: { auth: Zm9vOmZvbzEyMw } } }其中auth字段是用户名:密码的 Base64 编码Zm9vOmZvbzEyMw解码后即为foo:foo123后续docker pull/docker push会自动携带该凭据。6.3 打 tag 并 push 镜像将本地已有镜像打上私有 registry 的 tag$ docker tag prom/node-exporter:v0.16.0 172.27.132.67:8000/prom/node-exporter:v0.16.0 $ docker images |grep pause prom/node-exporter:v0.16.0 latest f9d5de079539 2 years ago 239.8 kB 172.27.132.67:8000/prom/node-exporter:v0.16.0 latest f9d5de079539 2 years ago 239.8 kB执行 push$ docker push 172.27.132.67:8000/prom/node-exporter:v0.16.0 The push refers to a repository [172.27.132.67:8000/prom/node-exporter:v0.16.0] 5f70bf18a086: Pushed e16a89738269: Pushed latest: digest: sha256:9a6b437e896acad3f5a2a8084625fdd4177b2e7124ee943af642259f2f283359 size: 916输出中的digest: sha256:...是这次 push 操作最终写入的manifest digest可用于后续精确删除与校验。6.4 在 ceph 侧验证数据落盘在 ceph 管理节点上查看 pool 列表确认 rgw 相关的 pool 已创建$ rados lspools rbd cephfs_data cephfs_metadata .rgw.root k8s default.rgw.control default.rgw.meta default.rgw.log default.rgw.buckets.index default.rgw.buckets.data在对象数据 pooldefault.rgw.buckets.data中检索刚才 push 的镜像文件$ rados --pool default.rgw.buckets.data ls|grep node-exporter 1f3f02c4-fe58-4626-992b-c6c0fe4c8acf.34107.1_files/docker/registry/v2/repositories/prom/node-exporter/_layers/sha256/cdb7590af5f064887f3d6008d46be65e929c74250d747813d85199e04fc70463/link 1f3f02c4-fe58-4626-992b-c6c0fe4c8acf.34107.1_files/docker/registry/v2/repositories/prom/node-exporter/_manifests/revisions/sha256/55302581333c43d540db0e144cf9e7735423117a733cdec27716d87254221086/link 1f3f02c4-fe58-4626-992b-c6c0fe4c8acf.34107.1_files/docker/registry/v2/repositories/prom/node-exporter/_manifests/tags/v0.16.0/current/link 1f3f02c4-fe58-4626-992b-c6c0fe4c8acf.34107.1_files/docker/registry/v2/repositories/prom/node-exporter/_manifests/tags/v0.16.0/index/sha256/55302581333c43d540db0e144cf9e7735423117a733cdec27716d87254221086/link 1f3f02c4-fe58-4626-992b-c6c0fe4c8acf.34107.1_files/docker/registry/v2/repositories/prom/node-exporter/_layers/sha256/224a21997e8ca8514d42eb2ed98b19a7ee2537bce0b3a26b8dff510ab637f15c/link 1f3f02c4-fe58-4626-992b-c6c0fe4c8acf.34107.1_files/docker/registry/v2/repositories/prom/node-exporter/_layers/sha256/528dda9cf23d0fad80347749d6d06229b9a19903e49b7177d5f4f58736538d4e/link 1f3f02c4-fe58-4626-992b-c6c0fe4c8acf.34107.1_files/docker/registry/v2/repositories/prom/node-exporter/_layers/sha256/188af75e2de0203eac7c6e982feff45f9c340eaac4c7a0f59129712524fa2984/link可以看到 ceph 对象路径完整复刻了 registry v2 的存储布局_layers/存放镜像层每个 layer 以 digest 命名并指向 blob、_manifests/revisions/存放 manifest 历史修订、_manifests/tags/tag/current与index/存放 tag 指向。这验证了镜像确实通过 Swift 协议落盘到 ceph 分布式存储中。第七步私有 registry 的运维操作registry v2 暴露了标准的 HTTP API/v2/...以下操作全部通过curl完成。由于启用了 TLS 与 Basic 认证每次请求都需要携带--user foo:foo123认证凭据与--cacert /etc/docker/certs.d/172.27.132.67:8000/ca.crt信任链注意在 shell 中对:8000的冒号进行转义。7.1 查询私有 registry 中的镜像列表$ curl --user foo:foo123 --cacert /etc/docker/certs.d/172.27.132.67\:8000/ca.crt https://172.27.132.67:8000/v2/_catalog {repositories:[prom/node-exporter]}对应 APIGET /v2/_catalog返回 JSON 为仓库名数组repositories。7.2 查询某个镜像的 tags 列表$ curl --user foo:foo123 --cacert /etc/docker/certs.d/172.27.132.67\:8000/ca.crt https://172.27.132.67:8000/v2/prom/node-exporter/tags/list {name:prom/node-exporter,tags:[v0.16.0]}对应 APIGET /v2/repoName/tags/list返回该仓库下的所有 tag。7.3 获取 image 或 layer 的 digest向v2/repoName/manifests/tagName发送 GET 请求从响应头部Docker-Content-Digest获取image digest从响应 body 的fsLayers.blobSum中获取layer digests对应新版 manifest v2 结构中的layers[].digest。注意必须携带请求头Accept: application/vnd.docker.distribution.manifest.v2json否则 registry 可能返回 schemaVersion 1 的旧格式fsLayers字段即 v1 格式产物$ curl -v -H Accept: application/vnd.docker.distribution.manifest.v2json --user foo:foo123 --cacert /etc/docker/certs.d/172.27.132.67\:8000/ca.crt https://172.27.132.67:8000/v2/prom/node-exporter/manifests/v0.16.0 * About to connect() to 172.27.132.67 port 8000 (#0) * Trying 172.27.132.67... * Connected to 172.27.132.67 (172.27.132.67) port 8000 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/docker/certs.d/172.27.132.67:8000/ca.crt CApath: none * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * Server certificate: * subject: CNregistry,OU4Paradigm,Ok8s,LBeiJing,STBeiJing,CCN * start date: Jul 05 12:52:00 2018 GMT * expire date: Jul 02 12:52:00 2028 GMT * common name: registry * issuer: CNkubernetes,OU4Paradigm,Ok8s,LBeiJing,STBeiJing,CCN * Server auth using Basic with user foo GET /v2/prom/node-exporter/manifests/v0.16.0 HTTP/1.1 Authorization: Basic Zm9vOmZvbzEyMw User-Agent: curl/7.29.0 Host: 172.27.132.67:8000 Accept: application/vnd.docker.distribution.manifest.v2json HTTP/1.1 200 OK Content-Length: 949 Content-Type: application/vnd.docker.distribution.manifest.v2json Docker-Content-Digest: sha256:55302581333c43d540db0e144cf9e7735423117a733cdec27716d87254221086 Docker-Distribution-Api-Version: registry/2.0 Etag: sha256:55302581333c43d540db0e144cf9e7735423117a733cdec27716d87254221086 X-Content-Type-Options: nosniff Date: Fri, 06 Jul 2018 06:18:41 GMT { schemaVersion: 2, mediaType: application/vnd.docker.distribution.manifest.v2json, config: { mediaType: application/vnd.docker.container.image.v1json, size: 3511, digest: sha256:188af75e2de0203eac7c6e982feff45f9c340eaac4c7a0f59129712524fa2984 }, layers: [ { mediaType: application/vnd.docker.image.rootfs.diff.tar.gzip, size: 2392417, digest: sha256:224a21997e8ca8514d42eb2ed98b19a7ee2537bce0b3a26b8dff510ab637f15c }, { mediaType: application/vnd.docker.image.rootfs.diff.tar.gzip, size: 560703, digest: sha256:cdb7590af5f064887f3d6008d46be65e929c74250d747813d85199e04fc70463 }, { mediaType: application/vnd.docker.image.rootfs.diff.tar.gzip, size: 5332460, digest: sha256:528dda9cf23d0fad80347749d6d06229b9a19903e49b7177d5f4f58736538d4e } ] }从-v输出中可以看到服务端证书链subject: CNregistry、issuer: CNkubernetes证明 registry 证书由集群 CA02.创建CA根证书和秘钥.md 中CNkubernetes-ca签发的签署请求头Authorization: Basic Zm9vOmZvbzEyMw即foo:foo123与Accept头都正确携带响应头Docker-Content-Digest: sha256:55302581333c43d540db0e144cf9e7735423117a733cdec27716d87254221086即image digest响应体为 schemaVersion 2 的 manifestconfig字段指向镜像配置 blobdigestsha256:188af7...layers数组列出每个镜像层的 mediaType、size 与 digest这些 digest 即layer digestsv1 格式中对应fsLayers.blobSum。7.4 删除 imagemanifest向/v2/name/manifests/reference发送 DELETE 请求其中reference为上一步响应头返回的Docker-Content-Digest字段内容$ curl -X DELETE --user foo:foo123 --cacert /etc/docker/certs.d/172.27.132.67\:8000/ca.crt https://172.27.132.67:8000/v2/prom/node-exporter/manifests/sha256:68effe31a4ae8312e47f54bec52d1fc925908009ce7e6f734e1b54a4169081c5 $删除 manifest 后该 digest 对应的 tag 即不可再拉取。7.5 删除 layerblob向/v2/name/blobs/digest发送 DELETE 请求其中digest为上一步返回的fsLayers.blobSumv2 格式为layers[].digest字段内容$ curl -X DELETE --user foo:foo123 --cacert /etc/docker/certs.d/172.27.132.67\:8000/ca.crt https://172.27.132.67:8000/v2/prom/node-exporter/blobs/sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4 $ curl -X DELETE --cacert /etc/docker/certs.d/172.27.132.67\:8000/ca.crt https://172.27.132.67:8000/v2/prom/node-exporter/blobs/sha256:04176c8b224aa0eb9942af765f66dae866f436e75acef028fe44b8a98e045515 $说明DELETE 操作依赖于 5.3 节中storage.delete.enabled: true的配置blob镜像层被删除后registry 的垃圾回收garbage collection进程会最终清理掉存储中未被任何 manifest 引用的层数据因此删除通常不是即时的。常见问题排查login 失败 416现象执行 ceph 官方文档中的s3test.py程序时botoS3 客户端报错[k8szhangjun-k8s-01 cert]$ python s3test.py Traceback (most recent call last): File s3test.py, line 12, in module bucket conn.create_bucket(my-new-bucket) File /usr/lib/python2.7/site-packages/boto/s3/connection.py, line 625, in create_bucket response.status, response.reason, body) boto.exception.S3ResponseError: S3ResponseError: 416 Requested Range Not Satisfiable根因radosgw-admin在内部 pool 创建失败时没有抛出正确的错误导致上层暴露的是极具迷惑性的 416 错误。解决办法在管理节点上修改ceph.conf将默认的pg_num和pgp_num调低例如设为 8或者将mon_max_pg_per_osd调高避免 pg 数量超过每个 OSD 的上限而导致 pool 创建失败推送配置到各节点并重启相关 ceph 服务ceph-deploy config push zhangjun-k8s-01 zhangjun-k8s-02 zhangjun-k8s-03 systemctl restart ceph-mdszhangjun-k8s-03.service systemctl restart ceph-osd0 systemctl restart ceph-monzhangjun-k8s-01.service systemctl restart ceph-mgrzhangjun-k8s-01.servicelogin 失败 503现象docker 客户端登录私有 registry 时报 503[rootzhangjun-k8s-01 ~]# docker login 172.27.132.67:8000 Username: foo Password: Error response from daemon: login attempt to https://172.27.132.67:8000/v2/ failed with status: 503 Service Unavailable原因启动 registry 容器的docker run命令缺少--privileged参数。补上该参数重新创建容器即可参见 5.4 节。小结至此一套「TLS 加密 HTTP Basic 认证 ceph RGWSwift存储」的私有 docker registry 已完整落地。你已掌握从 rgw 账号体系搭建、证书与认证文件生成、config.yml参数精解到镜像推送与 registry v2 HTTP API 的增删查运维全链路以及 416/503 两类高频故障的修复方法。如果希望在集群内进一步打通镜像分发可将这套 registry 与集群部署文档中的其他章节配合使用例如 F.部署docker.md 中daemon.json的insecure-registries字段可指向自建仓库08-1.部署集群插件.md 中的 coredns、dashboard、kube-prometheus、EFK 等插件镜像也都可以预先推送到私有仓库实现离线部署若需要 Web 管理界面、镜像复制等企业级能力可进一步参考 D.部署Harbor-Registry.md 部署 Harbor。赞分享文档教程云原生【免费下载链接】follow-me-install-kubernetes-cluster和我一步步部署 kubernetes 集群项目地址https://gitcode.com/gh_mirrors/fo/follow-me-install-kubernetes-cluster点击查看免费下载相关推荐基于Docker Compose部署Portus私有镜像仓库的实践指南基于Docker Compose部署Portus私有镜像仓库的实践指南 前言 Portus作为开源Docker镜像仓库管理系统提供了完善的镜像管理功能。本文将Ceph RGW S3 Python 编程指南基于 boto / boto3 的对象存储操作实战Ceph RGW S3 Python 编程指南基于 boto / boto3 的对象存储操作实战 本篇指南以 Ceph 对象网关RGW的 Python S存储分布式文件系统对象存储后端高可用Apache Pulsar 基于 KeyStore 的 TLS 加密与认证配置实战指南Apache Pulsar 基于 KeyStore 的 TLS 加密与认证配置实战指南 导读 Apache Pulsar 原生支持客户端与服务端之间的 TLS消息队列后端流处理上一篇如何在10分钟内用AI语音克隆技术创造专业级音色下一篇VutronMusic三平台统一音乐播放体验的完整解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考