@@ -68,7 +68,7 @@ There are additional rules about where you can place the separator
68
68
characters (`_`, `-`, and `.`) inside an image tag.
69
69
If you don't specify a tag, Kubernetes assumes you mean the tag `latest`.
70
70
-->
71
- 镜像标签可以包含小写字母、大写字符 、数字、下划线(` _ ` )、句点(` . ` )和连字符(` - ` )。
71
+ 镜像标签可以包含小写字母、大写字母 、数字、下划线(` _ ` )、句点(` . ` )和连字符(` - ` )。
72
72
关于在镜像标签中何处可以使用分隔字符(` _ ` 、` - ` 和 ` . ` )还有一些额外的规则。
73
73
如果你不指定标签,Kubernetes 认为你想使用标签 ` latest ` 。
74
74
@@ -517,6 +517,116 @@ registry keys are added to the `.docker/config.json`.
517
517
518
518
在 ` .docker/config.json ` 中配置了私有仓库密钥后,所有 Pod 都将能读取私有仓库中的镜像。
519
519
520
+ <!--
521
+ ### Interpretation of config.json {#config-json}
522
+ -->
523
+ ### config.json 说明 {#config-json}
524
+
525
+ <!--
526
+ The interpretation of `config.json` varies between the original Docker
527
+ implementation and the Kubernetes interpretation. In Docker, the `auths` keys
528
+ can only specify root URLs, whereas Kubernetes allows glob URLs as well as
529
+ prefix-matched paths. This means that a `config.json` like this is valid:
530
+ -->
531
+ 对于 ` config.json ` 的解释在原始 Docker 实现和 Kubernetes 的解释之间有所不同。
532
+ 在 Docker 中,` auths ` 键只能指定根 URL ,而 Kubernetes 允许 glob URLs 以及
533
+ 前缀匹配的路径。这意味着,像这样的 ` config.json ` 是有效的:
534
+ ``` json
535
+ {
536
+ "auths" : {
537
+ "*my-registry.io/images" : {
538
+ "auth" : " …"
539
+ }
540
+ }
541
+ }
542
+ ```
543
+
544
+ <!--
545
+ The root URL (`*my-registry.io`) is matched by using the following syntax:
546
+
547
+ ```
548
+ pattern:
549
+ { term }
550
+
551
+ term:
552
+ '*' matches any sequence of non-Separator characters
553
+ '?' matches any single non-Separator character
554
+ '[' [ '^' ] { character-range } ']'
555
+ character class (must be non-empty)
556
+ c matches character c (c != '*', '?', '\\', '[')
557
+ '\\' c matches character c
558
+
559
+ character-range:
560
+ c matches character c (c != '\\', '-', ']')
561
+ '\\' c matches character c
562
+ lo '-' hi matches character c for lo <= c <= hi
563
+ ```
564
+ -->
565
+ 使用以下语法匹配根 URL (` *my-registry.io ` ):
566
+ ```
567
+ pattern:
568
+ { term }
569
+
570
+ term:
571
+ '*' 匹配任何无分隔符字符序列
572
+ '?' 匹配任意单个非分隔符
573
+ '[' [ '^' ] 字符范围
574
+ 字符集(必须非空)
575
+ c 匹配字符 c (c 不为 '*','?','\\','[')
576
+ '\\' c 匹配字符 c
577
+
578
+ 字符范围:
579
+ c 匹配字符 c (c 不为 '\\','?','-',']')
580
+ '\\' c 匹配字符 c
581
+ lo '-' hi 匹配字符范围在 lo 到 hi 之间字符
582
+ ```
583
+
584
+ <!--
585
+ Image pull operations would now pass the credentials to the CRI container
586
+ runtime for every valid pattern. For example the following container image names
587
+ would match successfully:
588
+
589
+ - `my-registry.io/images`
590
+ - `my-registry.io/images/my-image`
591
+ - `my-registry.io/images/another-image`
592
+ - `sub.my-registry.io/images/my-image`
593
+ - `a.sub.my-registry.io/images/my-image`
594
+ -->
595
+ 现在镜像拉取操作会将每种有效模式的凭据都传递给 CRI 容器运行时。例如下面的容器镜像名称会匹配成功:
596
+
597
+ - ` my-registry.io/images `
598
+ - ` my-registry.io/images/my-image `
599
+ - ` my-registry.io/images/another-image `
600
+ - ` sub.my-registry.io/images/my-image `
601
+ - ` a.sub.my-registry.io/images/my-image `
602
+
603
+ <!--
604
+ The kubelet performs image pulls sequentially for every found credential. This
605
+ means, that multiple entries in `config.json` are possible, too:
606
+ -->
607
+ kubelet 为每个找到的凭证的镜像按顺序拉取。 这意味着在 ` config.json ` 中可能有多项:
608
+
609
+ ``` json
610
+ {
611
+ "auths" : {
612
+ "my-registry.io/images" : {
613
+ "auth" : " …"
614
+ },
615
+ "my-registry.io/images/subpath" : {
616
+ "auth" : " …"
617
+ }
618
+ }
619
+ }
620
+ ```
621
+
622
+ <!--
623
+ If now a container specifies an image `my-registry.io/images/subpath/my-image`
624
+ to be pulled, then the kubelet will try to download them from both
625
+ authentication sources if one of them fails.
626
+ -->
627
+ 如果一个容器指定了要拉取的镜像 ` my-registry.io/images/subpath/my-image ` ,
628
+ 并且其中一个失败,kubelet 将尝试从另一个身份验证源下载镜像。
629
+
520
630
<!--
521
631
### Pre-pulled images
522
632
-->
0 commit comments