fix zh-doc

2026-07-17 01:39:06 +00:00 · 2019-10-08 09:49:55 +08:00
parent 281f932814
commit 40ed9e6a44
2 changed files with 42 additions and 41 deletions
--- a/examples/zh/chart.md
+++ b/examples/zh/chart.md
@@ -1,4 +1,4 @@
-# 使用 kustomize 定义 helm chart
+# 使用 kustomize 对 helm chart s进行修改

 [last mile]: https://testingclouds.wordpress.com/2018/07/20/844/
 [stable chart]: https://github.com/helm/charts/tree/master/stable
@@ -6,15 +6,15 @@
 [_minecraft_]: https://github.com/helm/charts/tree/master/stable/minecraft
 [插件]: ../../docs/plugins

-kustomize 并不会读取 [Helm charts] ，但可以使用[插件]来访问 [Helm charts] 。
+kustomize 并不会读取 [Helm charts] ，但可以使用 generator ß来访问 [Helm charts] 。

 使用 [last mile] 模式来结合 kustomize 和 helm ，使用一个 inflated chart 作为基础，然后使用 kustomize 在部署到集群的途中进行修改。

-以下示例中使用的插件编码仅适用于 [stable chart] 仓库中的 chart。该示例虽然使用 [_minecraft_] ，但可以应用于任何 chart。
+以下示例中使用的 generator 仅适用于 [stable chart] 仓库中的 chart。该示例虽然使用 [_minecraft_] ，但可以应用于任何 chart。

 假设 `helm` 已在你的 `$PATH` 中，建立一个工作空间：

-<!-- @makeWorkplace @helmtest -->
+<!-- @makeWorkplace @test -->
 ```bash
 DEMO_HOME=$(mktemp -d)
 mkdir -p $DEMO_HOME/base
@@ -28,7 +28,7 @@ mkdir -p $DEMO_HOME/prod

 这可能涉及许多 kustomizations（参见其他示例），但在本示例中，将 `dev-` 名称前缀添加到所有资源：

-<!-- @writeKustDev @helmtest -->
+<!-- @writeKustDev @test -->
 ```bash
 cat <<'EOF' >$DEMO_HOME/dev/kustomization.yaml
 namePrefix:  dev-
@@ -39,7 +39,7 @@ EOF

 同上，使用 `namePrefix: prod-` 定义生产 variant ：

-<!-- @writeKustProd @helmtest -->
+<!-- @writeKustProd @test -->
 ```bash
 cat <<'EOF' >$DEMO_HOME/prod/kustomization.yaml
 namePrefix:  prod-
@@ -52,7 +52,7 @@ EOF

 定义这个 base：

-<!-- @writeKustDev @helmtest -->
+<!-- @writeKustDev @test -->
 ```bash
 cat <<'EOF' >$DEMO_HOME/base/kustomization.yaml
 generators:
@@ -66,7 +66,7 @@ base 指向一个名为 `chartInflator.yaml` 的生成配置文件。

 创建配置文件 `chartInflator.yaml`，指定 chart 名称为 _minecraft_：

-<!-- @writeGeneratorConfig @helmtest -->
+<!-- @writeGeneratorConfig @test -->
 ```bash
 cat <<'EOF' >$DEMO_HOME/base/chartInflator.yaml
 apiVersion: someteam.example.com/v1
@@ -81,7 +81,7 @@ EOF

 将插件下载到 `DEMO_HOME` 并赋予其执行权限：

-<!-- @installPlugin @helmtest -->
+<!-- @installPlugin @test -->
 ```bash
 plugin=plugin/someteam.example.com/v1/chartinflator/ChartInflator
 curl -s --create-dirs -o \
@@ -99,7 +99,7 @@ chmod a+x $DEMO_HOME/kustomize/$plugin
 tree $DEMO_HOME
 ```

-将会得到类似的东西：
+将会得倒类似的目录及文件：

 > ```bash
 > /tmp/whatever
@@ -120,7 +120,7 @@ tree $DEMO_HOME

 运行 kustomize 定义一个 helper function 来传入正确的环境和常见标志：

-<!-- @defineKustomizeIt @helmtest -->
+<!-- @defineKustomizeIt @test -->
 ```
 function kustomizeIt {
  XDG_CONFIG_HOME=$DEMO_HOME \
@@ -131,7 +131,7 @@ function kustomizeIt {

 最终构建 `prod` variant。这里要注意的是，所有资源名称现在都具有 `prod-` 前缀：

-<!-- @doProd @helmtest -->
+<!-- @doProd @test -->
 ```bash
 clear
 kustomizeIt prod
@@ -144,22 +144,23 @@ kustomizeIt prod
 diff <(kustomizeIt dev) <(kustomizeIt prod) | more
 ```

-在 base上 运行 kustomize 查看未修改但已 inflated 的 chart。这里的每次调用都是重新下载并 re-inflating chart。
+在 base上 运行 kustomize 查看未修改但已展开的 chart。
+这里的每次调用都是重新下载并重新展开 chart。

-<!-- @showBase @helmtest -->
+<!-- @showBase @test -->
 ```bash
 kustomizeIt base
 ```

 ## 使用本地 chart

-上面的示例由于未在配置中指定本地 chart 的主目录，则使用 kustomize 构建将 chart 的新副本 fetche 到临时目录。
+上面的示例由于未在配置中指定本地 chart 的主目录，所以kustomize会取得远程chart的副本并存在临时目录中。

-要禁止 fetche ，请明确指定 chart home ，并确保图表已存在。
+要禁止 fetch，请明确指定 `charHome` ，并确保chart 已经被保存在该目录下

 要进行演示，并且不会干扰您现有的 helm 环境，请执行以下操作：

-<!-- @helmInit @helmtest -->
+<!-- @helmInit @test -->
 ```bash
 helmHome=$DEMO_HOME/dothelm
 chartHome=$DEMO_HOME/base/charts
@@ -175,14 +176,14 @@ doHelm init --client-only >& /dev/null

 现在下载 chart ； 可以再次使用的 [_minecraft_] （也可以使用其他的 chart ）：

-<!-- @fetchChart @helmtest -->
+<!-- @fetchChart @test -->
 ```bash
 doHelm fetch --untar \
    --untardir $chartHome \
    stable/minecraft
 ```

-使用 tree 查看更多信息；helm 配置数据和完成的 chart 副本：
+使用 tree 查看更多信息；helm 配置数据和完整的 chart 副本：

 <!-- @tree -->
 ```bash
@@ -191,14 +192,14 @@ tree $DEMO_HOME

 将 `chartHome` 字段添加到生成器的配置文件中，以便可以查找本地 chart：

-<!-- @modifyGenConfig @helmtest -->
+<!-- @modifyGenConfig @test -->
 ```bash
 echo "chartHome: $chartHome" >>$DEMO_HOME/base/chartInflator.yaml
 ```

 更改 values 文件，用来展示本地 chart 的更改：

-<!-- @valueChange @helmtest -->
+<!-- @valueChange @test -->
 ```
 sed -i 's/CHANGEME!/SOMETHINGELSE/' $chartHome/minecraft/values.yaml
 sed -i 's/LoadBalancer/NodePort/' $chartHome/minecraft/values.yaml
@@ -206,9 +207,9 @@ sed -i 's/LoadBalancer/NodePort/' $chartHome/minecraft/values.yaml

 最后进行构建：

-<!-- @finalProd @helmtest -->
+<!-- @finalProd @test -->
 ```bash
 kustomizeIt prod
 ```

-观察从变化 `LoadBalancer` 到 `NodePort`，并更改编码的密码。
+观察结果中 `LoadBalancer` 变为 `NodePort`，并且加密的密码也有所不同。
--- a/examples/zh/secretGeneratorPlugin.md
+++ b/examples/zh/secretGeneratorPlugin.md
@@ -15,11 +15,11 @@

 Kubernetes 的 [ConfigMaps] 和 [Secrets] 都是key:value map，但 [Secrets] 的内容更为敏感，比如：密码或者 ssh 秘钥。

-Kubernetes 开发者以各种方式工作，Secrets 保存的信息相比 ConfigMaps、Deployments 等的配置信息需要更谨慎的隐藏。
+Kubernetes 开发者以各种方式工作，Secrets 保存的信息相比 ConfigMaps,Deployments 等的配置信息需要更谨慎的隐藏。

 ## 创建一个工作空间

-<!-- @establishBase @testAgainstLatestRelease -->
+<!-- @establishBase @test -->
 ```bash
 DEMO_HOME=$(mktemp -d)
 ```
@@ -36,7 +36,7 @@ kustomize 可以通过三种不同的方式生成来自本地文件的 Secret

 创建一个包含一些短密码的 env 文件：

-<!-- @makeEnvFile @testAgainstLatestRelease -->
+<!-- @makeEnvFile @test -->
 ```bash
 cat <<'EOF' >$DEMO_HOME/foo.env
 ROUTER_PASSWORD=admin
@@ -46,7 +46,7 @@ EOF

 创建一个长密码的文本文件：

-<!-- @makeLongSecretFile @testAgainstLatestRelease -->
+<!-- @makeLongSecretFile @test -->
 ```bash
 cat <<'EOF' >$DEMO_HOME/longsecret.txt
 Lorem ipsum dolor sit amet,
@@ -56,9 +56,9 @@ ut labore et dolore magna aliqua.
 EOF
 ```

-并创建一个参考上面的 kustomization.yaml 文件，并且另外定义一些文字 KV 对：
+创建一个kustomization.yaml 文件, 其中包含引用上面文件的 secretGenerator, 并且另外定义一些文字 KV 对：

-<!-- @makeKustomization1 @testAgainstLatestRelease -->
+<!-- @makeKustomization1 @test -->
 ```bash
 cat <<'EOF' >$DEMO_HOME/kustomization.yaml
 secretGenerator:
@@ -75,7 +75,7 @@ EOF

 生成 Secret ：

-<!-- @build1 @testAgainstLatestRelease -->
+<!-- @build1 @test -->
 ```bash
 result=$(kustomize build $DEMO_HOME)
 echo "$result"
@@ -103,23 +103,23 @@ test 1 == $(echo "$result" | grep -c "FRUIT: YXBwbGU=")

 使用 base64 解码器确认这些值的原始版本。

-这三种方法共同的问题是声明的 secrets 必须保存磁盘上。
+这三种方法共同的问题是创建 Secret 所使用的敏感数据必须保存磁盘上。

-这会增加额外的安全问题：对本地存储的 secrets 文件的查看、安装和删除权限的控制等。
+这会增加额外的安全问题：对本地存储的敏感文件的查看、安装和删除权限的控制等。

 ## 来自任何地方的 Secret

-一般的替代方案是在[插件](../docs/plugins)中生成 secrets 。
+一般的替代方案是在[generator](../../docs/plugins)中生成 secrets 。

 然后，这些值可以通过经过身份验证和授权的 RPC 进入密码保险库服务。

-[sgp]: ../plugin/someteam.example.com/v1/secretsfromdatabase
+[sgp]: ../../plugin/someteam.example.com/v1/secretsfromdatabase

-这里有一个[secret 生成插件][sgp]，它假装从数据库中拉取 map 中的值。
+这里有一个[secret 生成器][sgp]，它模拟从数据库中拉取 map 中的值。

 下载

-<!-- @copyPlugin @testAgainstLatestRelease -->
+<!-- @copyPlugin @test -->
 ```bash
 repo=https://raw.githubusercontent.com/kubernetes-sigs/kustomize
 pPath=plugin/someteam.example.com/v1/secretsfromdatabase
@@ -131,7 +131,7 @@ curl -s -o $dir/SecretsFromDatabase.go \
  ${repo}/master/$pPath/SecretsFromDatabase.go
 ```

-进行构建
+运行 kustomize build 生成结果

 <!-- @compilePlugin @xtest -->
 ```bash
@@ -142,7 +142,7 @@ go build -buildmode plugin \

 创建一个配置文件：

-<!-- @makeConfiguration @testAgainstLatestRelease -->
+<!-- @makeConfiguration @test -->
 ```bash
 cat <<'EOF' >$DEMO_HOME/secretFromDb.yaml
 apiVersion: someteam.example.com/v1
@@ -157,9 +157,9 @@ keys:
 EOF
 ```

-创建一个引用此插件的新 kustomization.yaml 文件：
+创建一个引用此生成器的新 kustomization.yaml 文件：

-<!-- @makeKustomization2 @testAgainstLatestRelease -->
+<!-- @makeKustomization2 @test -->
 ```bash
 cat <<'EOF' >$DEMO_HOME/kustomization.yaml
 generators:
@@ -167,7 +167,7 @@ generators:
 EOF
 ```

-最终生成 secret ，设置 `XDG_CONFIG_HOME` 以便可以在 `$DEMO_HOME` 中找到该插件：
+最终生成 secret ，设置 `XDG_CONFIG_HOME` 以便可以在 `$DEMO_HOME` 中找到该生成器：

 <!-- @build2 @xtest -->
 ```bash