@@ -26,8 +26,7 @@ before referring to it in a
26
26
This page provides an outline of the container image concept.
27
27
-->
28
28
容器镜像(Image)所承载的是封装了应用程序及其所有软件依赖的二进制数据。
29
- 容器镜像是可执行的软件包,可以单独运行;该软件包对所处的运行时环境具有
30
- 良定(Well Defined)的假定。
29
+ 容器镜像是可执行的软件包,可以单独运行;该软件包对所处的运行时环境具有良定(Well Defined)的假定。
31
30
32
31
你通常会创建应用的容器镜像并将其推送到某仓库(Registry),然后在
33
32
{{< glossary_tooltip text="Pod" term_id="pod" >}} 中引用它。
@@ -85,8 +84,8 @@ image if it already exists.
85
84
86
85
当你最初创建一个 {{< glossary_tooltip text="Deployment" term_id="deployment" >}}、
87
86
{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}、Pod
88
- 或者其他包含 Pod 模板的对象时,如果没有显式设定的话,Pod 中所有容器的默认镜像
89
- 拉取策略是 ` IfNotPresent ` 。这一策略会使得
87
+ 或者其他包含 Pod 模板的对象时,如果没有显式设定的话,
88
+ Pod 中所有容器的默认镜像拉取策略是 ` IfNotPresent ` 。这一策略会使得
90
89
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}
91
90
在镜像已经存在的情况下直接略过拉取镜像的操作。
92
91
@@ -101,7 +100,8 @@ these values have:
101
100
-->
102
101
### 镜像拉取策略 {#image-pull-policy}
103
102
104
- 容器的 ` imagePullPolicy ` 和镜像的标签会影响 [ kubelet] ( /zh-cn/docs/reference/command-line-tools-reference/kubelet/ ) 尝试拉取(下载)指定的镜像。
103
+ 容器的 ` imagePullPolicy ` 和镜像的标签会影响
104
+ [ kubelet] ( /zh-cn/docs/reference/command-line-tools-reference/kubelet/ ) 尝试拉取(下载)指定的镜像。
105
105
106
106
以下列表包含了 ` imagePullPolicy ` 可以设置的值,以及这些值的效果:
107
107
@@ -221,8 +221,8 @@ the pull policy of any object after its initial creation.
221
221
-->
222
222
容器的 ` imagePullPolicy ` 的值总是在对象初次 _ 创建_ 时设置的,如果后来镜像的标签发生变化,则不会更新。
223
223
224
- 例如,如果你用一个 _ 非 _ ` :latest ` 的镜像标签创建一个 Deployment,
225
- 并在随后更新该 Deployment 的镜像标签为 ` :latest ` ,则 ` imagePullPolicy ` 字段 _ 不会 _ 变成 ` Always ` 。
224
+ 例如,如果你用一个 ** 非 ** ` :latest ` 的镜像标签创建一个 Deployment,
225
+ 并在随后更新该 Deployment 的镜像标签为 ` :latest ` ,则 ` imagePullPolicy ` 字段 ** 不会 ** 变成 ` Always ` 。
226
226
你必须手动更改已经创建的资源的拉取策略。
227
227
{{< /note >}}
228
228
@@ -273,7 +273,7 @@ which is 300 seconds (5 minutes).
273
273
-->
274
274
` ImagePullBackOff ` 状态意味着容器无法启动,
275
275
因为 Kubernetes 无法拉取容器镜像(原因包括无效的镜像名称,或从私有仓库拉取而没有 ` imagePullSecret ` )。
276
- ` BackOff ` 部分表示 Kubernetes 将继续尝试拉取镜像,并增加回退延迟。
276
+ ` BackOff ` 部分表示 Kubernetes 将继续尝试拉取镜像,并增加回退延迟。
277
277
278
278
Kubernetes 会增加每次尝试之间的延迟,直到达到编译限制,即 300 秒(5 分钟)。
279
279
@@ -286,10 +286,10 @@ Kubernetes itself typically names container images with a suffix `-$(ARCH)`. For
286
286
-->
287
287
## 带镜像索引的多架构镜像 {#multi-architecture-images-with-image-indexes}
288
288
289
- 除了提供二进制的镜像之外,容器仓库也可以提供
290
- [ 容器镜像索引] ( https://github.com/opencontainers/image-spec/blob/master/image-index.md ) 。
291
- 镜像索引可以根据特定于体系结构版本的容器指向镜像的多个
292
- [ 镜像清单 ] ( https://github.com/opencontainers/image-spec/blob/master/manifest.md ) 。
289
+ 除了提供二进制的镜像之外,
290
+ 容器仓库也可以提供 [ 容器镜像索引] ( https://github.com/opencontainers/image-spec/blob/master/image-index.md ) 。
291
+ 镜像索引可以指向镜像的多个 [ 镜像清单 ] ( https://github.com/opencontainers/image-spec/blob/master/manifest.md ) ,
292
+ 提供特定于体系结构版本的容器 。
293
293
这背后的理念是让你可以为镜像命名(例如:` pause ` 、` example/mycontainer ` 、` kube-apiserver ` )
294
294
的同时,允许不同的系统基于它们所使用的机器体系结构取回正确的二进制镜像。
295
295
@@ -316,7 +316,7 @@ Credentials can be provided in several ways:
316
316
- requires node configuration by cluster administrator
317
317
- Pre-pulled Images
318
318
- all pods can use any images cached on a node
319
- - requires root access to all nodes to setup
319
+ - requires root access to all nodes to set up
320
320
- Specifying ImagePullSecrets on a Pod
321
321
- only pods which provide own keys can access the private registry
322
322
- Vendor-specific or local extensions
@@ -333,8 +333,7 @@ Credentials can be provided in several ways:
333
333
- 在 Pod 中设置 ImagePullSecrets
334
334
- 只有提供自己密钥的 Pod 才能访问私有仓库
335
335
- 特定于厂商的扩展或者本地扩展
336
- - 如果你在使用定制的节点配置,你(或者云平台提供商)可以实现让节点
337
- 向容器仓库认证的机制
336
+ - 如果你在使用定制的节点配置,你(或者云平台提供商)可以实现让节点向容器仓库认证的机制
338
337
339
338
<!--
340
339
These options are explained in more detail below.
@@ -365,8 +364,8 @@ For an example of configuring a private container image registry, see the
365
364
[Pull an Image from a Private Registry](/docs/tasks/configure-pod-container/pull-image-private-registry)
366
365
task. That example uses a private registry in Docker Hub.
367
366
-->
368
- 有关配置私有容器镜像仓库的示例,请参阅任务
369
- [ 从私有镜像库中拉取镜像] ( /zh-cn/docs/tasks/configure-pod-container/pull-image-private-registry ) 。
367
+ 有关配置私有容器镜像仓库的示例,
368
+ 请参阅任务 [ 从私有镜像库中拉取镜像] ( /zh-cn/docs/tasks/configure-pod-container/pull-image-private-registry ) 。
370
369
该示例使用 Docker Hub 中的私有注册表。
371
370
372
371
<!--
@@ -381,8 +380,8 @@ can only specify root URLs, whereas Kubernetes allows glob URLs as well as
381
380
prefix-matched paths. This means that a `config.json` like this is valid:
382
381
-->
383
382
对于 ` config.json ` 的解释在原始 Docker 实现和 Kubernetes 的解释之间有所不同。
384
- 在 Docker 中,` auths ` 键只能指定根 URL ,而 Kubernetes 允许 glob URLs 以及
385
- 前缀匹配的路径。 这意味着,像这样的 ` config.json ` 是有效的:
383
+ 在 Docker 中,` auths ` 键只能指定根 URL,而 Kubernetes 允许 glob URLs 以及前缀匹配的路径。
384
+ 这意味着,像这样的 ` config.json ` 是有效的:
386
385
``` json
387
386
{
388
387
"auths" : {
@@ -456,7 +455,7 @@ would match successfully:
456
455
The kubelet performs image pulls sequentially for every found credential. This
457
456
means, that multiple entries in `config.json` are possible, too:
458
457
-->
459
- kubelet 为每个找到的凭证的镜像按顺序拉取。 这意味着在 ` config.json ` 中可能有多项:
458
+ kubelet 为每个找到的凭证的镜像按顺序拉取。这意味着在 ` config.json ` 中可能有多项:
460
459
461
460
``` json
462
461
{
@@ -532,8 +531,12 @@ in private registries.
532
531
533
532
<!--
534
533
Kubernetes supports specifying container image registry keys on a Pod.
534
+ `imagePullSecrets` must all be in the same namespace as the Pod. The referenced
535
+ Secrets must be of type `kubernetes.io/dockercfg` or `kubernetes.io/dockerconfigjson`.
535
536
-->
536
537
Kubernetes 支持在 Pod 中设置容器镜像仓库的密钥。
538
+ ` imagePullSecrets ` 必须全部与 Pod 位于同一个名字空间中。
539
+ 引用的 Secret 必须是 ` kubernetes.io/dockercfg ` 或 ` kubernetes.io/dockerconfigjson ` 类型。
537
540
538
541
<!--
539
542
#### Creating a Secret with a Docker config
@@ -576,21 +579,22 @@ Pods can only reference image pull secrets in their own namespace,
576
579
so this process needs to be done one time per namespace.
577
580
-->
578
581
{{< note >}}
579
- Pod 只能引用位于自身所在名字空间中的 Secret,因此需要针对每个名字空间
580
- 重复执行上述过程。
582
+ Pod 只能引用位于自身所在名字空间中的 Secret,因此需要针对每个名字空间重复执行上述过程。
581
583
{{< /note >}}
582
584
583
585
<!--
584
586
#### Referring to an imagePullSecrets on a Pod
585
587
586
588
Now, you can create pods which reference that secret by adding an `imagePullSecrets`
587
- section to a Pod definition.
589
+ section to a Pod definition. Each item in the `imagePullSecrets` array can only
590
+ reference a Secret in the same namespace.
588
591
589
592
For example:
590
593
-->
591
594
#### 在 Pod 中引用 ImagePullSecrets
592
595
593
596
现在,在创建 Pod 时,可以在 Pod 定义中增加 ` imagePullSecrets ` 部分来引用该 Secret。
597
+ ` imagePullSecrets ` 数组中的每一项只能引用同一名字空间中的 Secret。
594
598
595
599
例如:
596
600
@@ -626,12 +630,11 @@ Check [Add ImagePullSecrets to a Service Account](/docs/tasks/configure-pod-cont
626
630
You can use this in conjunction with a per-node `.docker/config.json`. The credentials
627
631
will be merged.
628
632
-->
629
- 你需要对使用私有仓库的每个 Pod 执行以上操作。
630
- 不过,设置该字段的过程也可以通过为
631
- [ 服务账号] ( /zh-cn/docs/tasks/configure-pod-container/configure-service-account/ )
632
- 资源设置 ` imagePullSecrets ` 来自动完成。
633
- 有关详细指令可参见
634
- [ 将 ImagePullSecrets 添加到服务账号] ( /zh-cn/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account ) 。
633
+ 你需要对使用私有仓库的每个 Pod 执行以上操作。不过,
634
+ 设置该字段的过程也可以通过为[ 服务账号] ( /zh-cn/docs/tasks/configure-pod-container/configure-service-account/ ) 资源设置
635
+ ` imagePullSecrets ` 来自动完成。
636
+ 有关详细指令,
637
+ 可参见[ 将 ImagePullSecrets 添加到服务账号] ( /zh-cn/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account ) 。
635
638
636
639
你也可以将此方法与节点级别的 ` .docker/config.json ` 配置结合使用。
637
640
来自不同来源的凭据会被合并。
@@ -670,7 +673,7 @@ common use cases and suggested solutions.
670
673
- Or, on a cluster where changing the node configuration is inconvenient, use `imagePullSecrets`.
671
674
-->
672
675
2 . 集群运行一些专有镜像,这些镜像需要对公司外部隐藏,对所有集群用户可见
673
- - 使用托管的私有 [ Docker 仓库] ( https://docs.docker.com/registry/ ) 。
676
+ - 使用托管的私有 [ Docker 仓库] ( https://docs.docker.com/registry/ )
674
677
- 可以托管在 [ Docker Hub] ( https://hub.docker.com/account/signup/ ) 或者其他地方
675
678
- 按照上面的描述,在每个节点上手动配置 ` .docker/config.json ` 文件
676
679
- 或者,在防火墙内运行一个组织内部的私有仓库,并开放读取权限
@@ -698,7 +701,7 @@ common use cases and suggested solutions.
698
701
4 . 集群是多租户的并且每个租户需要自己的私有仓库
699
702
- 确保 [ AlwaysPullImages 准入控制器] ( /zh-cn/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages ) 。否则,所有租户的所有的 Pod 都可以使用所有镜像。
700
703
- 为私有仓库启用鉴权
701
- - 为每个租户生成访问仓库的凭据,放置在 Secret 中,并将 Secrert 发布到各租户的命名空间下 。
704
+ - 为每个租户生成访问仓库的凭据,放置在 Secret 中,并将 Secret 发布到各租户的名字空间下 。
702
705
- 租户将 Secret 添加到每个名字空间中的 imagePullSecrets
703
706
704
707
<!--
@@ -714,6 +717,8 @@ Kubelet will merge any `imagePullSecrets` into a single virtual `.docker/config.
714
717
<!--
715
718
* Read the [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md).
716
719
* Learn about [container image garbage collection](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection).
720
+ * Learn more about [pulling an Image from a Private Registry](/docs/tasks/configure-pod-container/pull-image-private-registry).
717
721
-->
718
722
* 阅读 [ OCI Image Manifest 规范] ( https://github.com/opencontainers/image-spec/blob/master/manifest.md ) 。
719
723
* 了解[ 容器镜像垃圾收集] ( /zh-cn/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection ) 。
724
+ * 了解[ 从私有仓库拉取镜像] ( /zh-cn/docs/tasks/configure-pod-container/pull-image-private-registry ) 。
0 commit comments