Skip to content

Commit 2c6a411

Browse files
authored
[zh] typo Update images.md (#30545)
* Update images.md typo * sync en docs * [zh] translate images.md [zh] translate interpretation of config.json images.md * [zh] modify the wording in images.md * [zh] remove origin english in images.md * [zh] del extra # in images.md * [zh] del origin english in images.md
1 parent 1c8a929 commit 2c6a411

File tree

1 file changed

+111
-1
lines changed

1 file changed

+111
-1
lines changed

content/zh/docs/concepts/containers/images.md

Lines changed: 111 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -68,7 +68,7 @@ There are additional rules about where you can place the separator
6868
characters (`_`, `-`, and `.`) inside an image tag.
6969
If you don't specify a tag, Kubernetes assumes you mean the tag `latest`.
7070
-->
71-
镜像标签可以包含小写字母、大写字符、数字、下划线(`_`)、句点(`.`)和连字符(`-`)。
71+
镜像标签可以包含小写字母、大写字母、数字、下划线(`_`)、句点(`.`)和连字符(`-`)。
7272
关于在镜像标签中何处可以使用分隔字符(`_``-``.`)还有一些额外的规则。
7373
如果你不指定标签,Kubernetes 认为你想使用标签 `latest`
7474

@@ -517,6 +517,116 @@ registry keys are added to the `.docker/config.json`.
517517

518518
`.docker/config.json` 中配置了私有仓库密钥后,所有 Pod 都将能读取私有仓库中的镜像。
519519

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+
520630
<!--
521631
### Pre-pulled images
522632
-->

0 commit comments

Comments
 (0)