Skip to content

Commit 4b435b4

Browse files
authored
Merge pull request #35284 from windsonsea/secretyhf
[zh-cn] updated /concepts/configuration/secret.md
2 parents 93168d8 + 1099fb7 commit 4b435b4

File tree

1 file changed

+19
-20
lines changed
  • content/zh-cn/docs/concepts/configuration

1 file changed

+19
-20
lines changed

content/zh-cn/docs/concepts/configuration/secret.md

Lines changed: 19 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@ content_type: concept
44
feature:
55
title: Secret 和配置管理
66
description: >
7-
部署和更新 Secrets 和应用程序的配置而不必重新构建容器镜像,且
7+
部署和更新 Secret 和应用程序的配置而不必重新构建容器镜像,且
88
不必将软件堆栈配置中的秘密信息暴露出来。
99
weight: 30
1010
---
@@ -295,7 +295,7 @@ You can package many keys and values into one Secret, or use many Secrets, which
295295
-->
296296
这一示例清单定义了一个 Secret,其 `data` 字段中包含两个主键:`username` 和 `password`。
297297
清单中的字段值是 Base64 字符串,不过,当你在 Pod 中使用 Secret 时,kubelet 为 Pod
298-
及其中的容器提供的是解码后的数据
298+
及其中的容器提供的是**解码**后的数据
299299

300300
你可以在一个 Secret 中打包多个主键和数值,也可以选择使用多个 Secret,
301301
完全取决于哪种方式最方便。
@@ -437,7 +437,7 @@ invalidated when the Pod they are mounted into is deleted.
437437
Kubernetes v1.22 版本之前都会自动创建用来访问 Kubernetes API 的凭证。
438438
这一老的机制是基于创建可被挂载到 Pod 中的令牌 Secret 来实现的。
439439
在最近的版本中,包括 Kubernetes v{{< skew currentVersion >}} 中,API 凭据是直接通过
440-
[TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
440+
[TokenRequest](/zh-cn/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
441441
API 来获得的,这一凭据会使用[投射卷](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume)
442442
挂载到 Pod 中。使用这种方式获得的令牌有确定的生命期,并且在挂载它们的 Pod
443443
被删除时自动作废。
@@ -452,7 +452,7 @@ command to obtain a token from the `TokenRequest` API.
452452
-->
453453
你仍然可以[手动创建](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token)
454454
服务账号令牌。例如,当你需要一个永远都不过期的令牌时。
455-
不过,仍然建议使用 [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
455+
不过,仍然建议使用 [TokenRequest](/zh-cn/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
456456
子资源来获得访问 API 服务器的令牌。
457457
你可以使用 [`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-)
458458
命令调用 `TokenRequest` API 获得令牌。
@@ -845,7 +845,7 @@ level.
845845
### 容器镜像拉取 Secret {#using-imagepullsecrets}
846846

847847
如果你尝试从私有仓库拉取容器镜像,你需要一种方式让每个节点上的 kubelet
848-
能够完成与镜像库的身份认证。你可以配置 *镜像拉取 Secret* 来实现这点。
848+
能够完成与镜像库的身份认证。你可以配置 **镜像拉取 Secret** 来实现这点。
849849
Secret 是在 Pod 层面来配置的。
850850

851851
<!--
@@ -859,7 +859,7 @@ for more information about the `imagePullSecrets` field.
859859
Pod 的 `imagePullSecrets` 字段是一个对 Pod 所在的名字空间中的 Secret
860860
的引用列表。你可以使用 `imagePullSecrets` 来将镜像仓库访问凭据传递给 kubelet。
861861
kubelet 使用这个信息来替你的 Pod 拉取私有镜像。
862-
参阅 [Pod API 参考](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)
862+
参阅 [Pod API 参考](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)
863863
中的 `PodSpec` 进一步了解 `imagePullSecrets` 字段。
864864

865865
<!--
@@ -875,7 +875,7 @@ See the [PodSpec API](/docs/reference/generated/kubernetes-api/{{< param "versio
875875
`imagePullSecrets` 字段是一个列表,包含对同一名字空间中 Secret 的引用。
876876
你可以使用 `imagePullSecrets` 将包含 Docker(或其他)镜像仓库密码的 Secret
877877
传递给 kubelet。kubelet 使用此信息来替 Pod 拉取私有镜像。
878-
参阅 [PodSpec API ](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)
878+
参阅 [PodSpec API ](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)
879879
进一步了解 `imagePullSecrets` 字段。
880880

881881
<!--
@@ -1113,7 +1113,7 @@ secret "test-db-secret" created
11131113
Special characters such as `$`, `\`, `*`, `=`, and `!` will be interpreted by your [shell](https://en.wikipedia.org/wiki/Shell_(computing)) and require escaping.
11141114
-->
11151115
特殊字符(例如 `$``\``*``=``!`)会被你的
1116-
[Shell](https://en.wikipedia.org/wiki/Shell_(computing))解释,因此需要转义。
1116+
[Shell](https://zh.wikipedia.org/wiki/Shell_(computing)) 解释,因此需要转义。
11171117

11181118
<!--
11191119
In most shells, the easiest way to escape the password is to surround it with single quotes (`'`).
@@ -1355,7 +1355,7 @@ Kubernetes imposes on them.
13551355
-->
13561356
## Secret 的类型 {#secret-types}
13571357

1358-
创建 Secret 时,你可以使用 [Secret](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)
1358+
创建 Secret 时,你可以使用 [Secret](/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)
13591359
资源的 `type` 字段,或者与其等价的 `kubectl` 命令行参数(如果有的话)为其设置类型。
13601360
Secret 类型有助于对 Secret 数据进行编程处理。
13611361

@@ -1420,8 +1420,8 @@ command creates an empty Secret of type `Opaque`.
14201420
### Opaque Secret
14211421

14221422
当 Secret 配置文件中未作显式设定时,默认的 Secret 类型是 `Opaque`。
1423-
当你使用 `kubectl` 来创建一个 Secret 时,你会使用 `generic` 子命令来标明
1424-
要创建的是一个 `Opaque` 类型 Secret。
1423+
当你使用 `kubectl` 来创建一个 Secret 时,你会使用 `generic`
1424+
子命令来标明要创建的是一个 `Opaque` 类型 Secret。
14251425
例如,下面的命令会创建一个空的 `Opaque` 类型 Secret 对象:
14261426

14271427
```shell
@@ -1626,11 +1626,10 @@ server doesn't validate if the JSON actually is a Docker config file.
16261626
When you do not have a Docker config file, or you want to use `kubectl`
16271627
to create a Secret for accessing a container registry, you can do:
16281628
-->
1629-
当你使用清单文件来创建这两类 Secret 时,API 服务器会检查 `data` 字段中是否
1630-
存在所期望的主键,并且验证其中所提供的键值是否是合法的 JSON 数据。
1629+
当你使用清单文件来创建这两类 Secret 时,API 服务器会检查 `data` 字段中是否存在所期望的主键,
1630+
并且验证其中所提供的键值是否是合法的 JSON 数据。
16311631
不过,API 服务器不会检查 JSON 数据本身是否是一个合法的 Docker 配置文件内容。
16321632

1633-
16341633
当你没有 Docker 配置文件,或者你想使用 `kubectl` 创建一个 Secret
16351634
来访问容器倉庫时,你可以这样做:
16361635

@@ -1750,8 +1749,8 @@ key authentication:
17501749
-->
17511750
### SSH 身份认证 Secret {#ssh-authentication-secrets}
17521751

1753-
Kubernetes 所提供的内置类型 `kubernetes.io/ssh-auth` 用来存放 SSH 身份认证中
1754-
所需要的凭据。使用这种 Secret 类型时,你就必须在其 `data` (或 `stringData`)
1752+
Kubernetes 所提供的内置类型 `kubernetes.io/ssh-auth` 用来存放 SSH 身份认证中所需要的凭据。
1753+
使用这种 Secret 类型时,你就必须在其 `data` (或 `stringData`)
17551754
字段中提供一个 `ssh-privatekey` 键值对,作为要使用的 SSH 凭据。
17561755

17571756
下面的清单是一个 SSH 公钥/私钥身份认证的 Secret 示例:
@@ -1900,8 +1899,8 @@ well-known ConfigMaps.
19001899
-->
19011900
### 启动引导令牌 Secret {#bootstrap-token-secrets}
19021901

1903-
通过将 Secret 的 `type` 设置为 `bootstrap.kubernetes.io/token` 可以创建
1904-
启动引导令牌类型的 Secret。这种类型的 Secret 被设计用来支持节点的启动引导过程。
1902+
通过将 Secret 的 `type` 设置为 `bootstrap.kubernetes.io/token`
1903+
可以创建启动引导令牌类型的 Secret。这种类型的 Secret 被设计用来支持节点的启动引导过程。
19051904
其中包含用来为周知的 ConfigMap 签名的令牌。
19061905

19071906
<!--
@@ -1913,8 +1912,8 @@ As a Kubernetes manifest, a bootstrap token Secret might look like the
19131912
following:
19141913
-->
19151914
启动引导令牌 Secret 通常创建于 `kube-system` 名字空间内,并以
1916-
`bootstrap-token-<令牌 ID>` 的形式命名;其中 `<令牌 ID>` 是一个由 6 个字符组成
1917-
的字符串,用作令牌的标识。
1915+
`bootstrap-token-<令牌 ID>` 的形式命名;
1916+
其中 `<令牌 ID>` 是一个由 6 个字符组成的字符串,用作令牌的标识。
19181917

19191918
以 Kubernetes 清单文件的形式,某启动引导令牌 Secret 可能看起来像下面这样:
19201919

0 commit comments

Comments
 (0)