From 4547691f97d14ceb6908b7ce761f76391ad102d2 Mon Sep 17 00:00:00 2001 From: Michael Date: Sun, 29 Oct 2023 11:46:36 +0800 Subject: [PATCH] [zh] Sync /containers/images.md --- .../zh-cn/docs/concepts/containers/images.md | 101 ++++++++---------- 1 file changed, 43 insertions(+), 58 deletions(-) diff --git a/content/zh-cn/docs/concepts/containers/images.md b/content/zh-cn/docs/concepts/containers/images.md index e9dea1061e..ac3b849b5b 100644 --- a/content/zh-cn/docs/concepts/containers/images.md +++ b/content/zh-cn/docs/concepts/containers/images.md @@ -516,63 +516,40 @@ See [Configure a kubelet image credential provider](/docs/tasks/administer-clust The interpretation of `config.json` varies between the original Docker implementation and the Kubernetes interpretation. In Docker, the `auths` keys can only specify root URLs, whereas Kubernetes allows glob URLs as well as -prefix-matched paths. This means that a `config.json` like this is valid: +prefix-matched paths. The only limitation is that glob patterns (`*`) have to +include the dot (`.`) for each subdomain. The amount of matched subdomains has +to be equal to the amount of glob patterns (`*.`), for example: --> 对于 `config.json` 的解释在原始 Docker 实现和 Kubernetes 的解释之间有所不同。 -在 Docker 中，`auths` 键只能指定根 URL，而 Kubernetes 允许 glob URLs 以及前缀匹配的路径。 +在 Docker 中，`auths` 键只能指定根 URL，而 Kubernetes 允许 glob URL 以及前缀匹配的路径。 +唯一的限制是 glob 模式（`*`）必须为每个子域名包括点（`.`）。 +匹配的子域名数量必须等于 glob 模式（`*.`）的数量，例如： + + +- `*.kubernetes.io` **不**会匹配 `kubernetes.io`，但会匹配 `abc.kubernetes.io` +- `*.*.kubernetes.io` **不**会匹配 `abc.kubernetes.io`，但会匹配 `abc.def.kubernetes.io` +- `prefix.*.io` 将匹配 `prefix.kubernetes.io` +- `*-good.kubernetes.io` 将匹配 `prefix-good.kubernetes.io` + + 这意味着，像这样的 `config.json` 是有效的： ```json { "auths": { - "*my-registry.io/images": { - "auth": "…" - } + "my-registry.io/images": { "auth": "…" }, + "*.my-registry.io/images": { "auth": "…" } } } ``` - -使用以下语法匹配根 URL （`*my-registry.io`）： - -``` -pattern: - { term } - -term: - '*' 匹配任何无分隔符字符序列 - '?' 匹配任意单个非分隔符 - '[' [ '^' ] 字符范围 - 字符集（必须非空） - c 匹配字符 c （c 不为 '*', '?', '\\', '['） - '\\' c 匹配字符 c - -字符范围: - c 匹配字符 c （c 不为 '\\', '?', '-', ']'） - '\\' c 匹配字符 c - lo '-' hi 匹配字符范围在 lo 到 hi 之间字符 -``` - +但这些不会匹配成功： + - `a.sub.my-registry.io/images/my-image` +- `a.b.sub.my-registry.io/images/my-image` -kubelet 为每个找到的凭据的镜像按顺序拉取。这意味着在 `config.json` 中可能有多项： +kubelet 为每个找到的凭据的镜像按顺序拉取。这意味着对于不同的路径在 `config.json` 中也可能有多项： ```json { @@ -697,7 +681,7 @@ kubectl create secret docker-registry \ @@ -774,8 +758,7 @@ will be merged. --> 你需要对使用私有仓库的每个 Pod 执行以上操作。不过， 设置该字段的过程也可以通过为[服务账号](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/)资源设置 -`imagePullSecrets` 来自动完成。 -有关详细指令， +`imagePullSecrets` 来自动完成。有关详细指令， 可参见[将 ImagePullSecrets 添加到服务账号](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)。 你也可以将此方法与节点级别的 `.docker/config.json` 配置结合使用。 @@ -830,8 +813,9 @@ common use cases and suggested solutions. - Move sensitive data into a "Secret" resource, instead of packaging it in an image. --> 3. 集群使用专有镜像，且有些镜像需要更严格的访问控制 - - 确保 [AlwaysPullImages 准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)被启用。否则，所有 Pod 都可以使用所有镜像。 - - 确保将敏感数据存储在 Secret 资源中，而不是将其打包在镜像里 + - 确保 [AlwaysPullImages 准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)被启用。 + 否则，所有 Pod 都可以使用所有镜像。 + - 确保将敏感数据存储在 Secret 资源中，而不是将其打包在镜像里。 4. 集群是多租户的并且每个租户需要自己的私有仓库 - - 确保 [AlwaysPullImages 准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)。否则，所有租户的所有的 Pod 都可以使用所有镜像。 - - 为私有仓库启用鉴权 + - 确保 [AlwaysPullImages 准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)。 + 否则，所有租户的所有的 Pod 都可以使用所有镜像。 + - 为私有仓库启用鉴权。 - 为每个租户生成访问仓库的凭据，放置在 Secret 中，并将 Secret 发布到各租户的名字空间下。 - - 租户将 Secret 添加到每个名字空间中的 imagePullSecrets + - 租户将 Secret 添加到每个名字空间中的 imagePullSecrets。 -## 旧版的内置 kubelet 凭据提供程序 +## 旧版的内置 kubelet 凭据提供程序 {#legacy-built-in-kubelet-credentials-provider} 在旧版本的 Kubernetes 中，kubelet 与云提供商凭据直接集成。 这使它能够动态获取镜像仓库的凭据。 @@ -869,7 +854,7 @@ There were three built-in implementations of the kubelet credential provider int ACR (Azure Container Registry), ECR (Elastic Container Registry), and GCR (Google Container Registry). --> kubelet 凭据提供程序集成存在三个内置实现： -ACR（Azure 容器仓库）、ECR（Elastic 容器仓库）和 GCR（Google 容器仓库） +ACR（Azure 容器仓库）、ECR（Elastic 容器仓库）和 GCR（Google 容器仓库）。