From cec04c46a24d5b133967f08a95f32ee786f6d98a Mon Sep 17 00:00:00 2001
From: "Wuhongming (Mingo)" <w00297372@china.huawei.com>
Date: Fri, 23 Nov 2018 17:31:04 +0800
Subject: [PATCH 1/3] update with upstream

---
 ._cover.jpg                                   | Bin 0 -> 233 bytes
 chart/chart_repository-zh_cn.md               |   6 +-
 chart/chart_repository_faq-zh_cn.md           |   2 +-
 chart/chart_tests-zh_cn.md                    |  20 ++--
 chart/charts-zh_cn.md                         |  18 +--
 chart/charts_hooks-zh_cn.md                   |  16 +--
 chart/charts_tips_and_tricks-zh_cn.md         |  60 ++++++++--
 chart/provenance-zh_cn.md                     |  18 +--
 chart_best_practices/README-zh_cn.md          |   2 +-
 chart_best_practices/conventions-zh_cn.md     |  11 +-
 chart_best_practices/labels-zh_cn.md          |  16 ++-
 chart_best_practices/pods-zh_cn.md            |  10 +-
 chart_best_practices/values-zh_cn.md          |  11 +-
 chart_template_guide/accessing_files-zh_cn.md |  40 +++----
 .../control_structures-zh_cn.md               | 105 ++++++++--------
 chart_template_guide/variables-zh_cn.md       |  52 ++++----
 chart_template_guide/wrapping_up-zh_cn.md     |   8 +-
 developers-zh_cn.md                           |   8 +-
 quickstart/install-zh_cn.md                   |  24 ++--
 quickstart/install_faq-zh_cn.md               |   4 +-
 quickstart/kubernetes_distros-zh_cn.md        |   2 +-
 quickstart/quickstart-zh_cn.md                | 113 ++++++++++++++++--
 quickstart/rbac-zh_cn.md                      |  24 ++--
 quickstart/securing_installation-zh_cn.md     |   9 +-
 quickstart/tiller_ssl-zh_cn.md                |  15 ++-
 quickstart/using_helm-zh_cn.md                |  35 +++++-
 related-zh_cn.md                              |  84 +++++++------
 27 files changed, 458 insertions(+), 255 deletions(-)
 create mode 100644 ._cover.jpg

diff --git a/._cover.jpg b/._cover.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..b4385de0b4e2008bb3b0d6a813209c1083daacbe
GIT binary patch
literal 233
zcmZQz6=P>$Vqox1Ojhs@R)|o50+1L3ClDI}@pd2v@m~Tl5x_AdBnYYuq~ib(YeM-j
z3S`;=AQoU?kV?+a)k`cW$Vt`9Nh~fYEly2INi0cK4hV)Sz5t{p85l$n>IzE}ixTrn
tGV@Xy*0cFVgVZfq7NrQH3-t{QER3v8lT1<#%*>Ll1Bz11GE>W~831cPCGY?M

literal 0
HcmV?d00001

diff --git a/chart/chart_repository-zh_cn.md b/chart/chart_repository-zh_cn.md
index c0e6dcf..826827b 100644
--- a/chart/chart_repository-zh_cn.md
+++ b/chart/chart_repository-zh_cn.md
@@ -13,7 +13,7 @@
 
 chart 库是带有一个 index.yaml 文件和任意个打包 cahrt 的 HTTP 服务器。当准备好分享 chart 时，首选方法是将其上传到 chart 库。
 
-** 注意：** 对于 Helm 2.0.0，chart 库没有任何内部认证。 在 GitHub 中有一个跟踪进度的问题 [issue tracking progress](https://github.com/kubernetes/helm/issues/1038)。
+** 注意：** 对于 Helm 2.0.0，chart 库没有任何内部认证。 在 GitHub 中有一个跟踪进度的问题 [issue tracking progress](https://github.com/helm/issues/1038)。
 
 由于 chart 库可以是任何可以提供 YAML 和 tar 文件并可以回答 GET 请求的 HTTP 服务器，因此当托管自己的 chart 库时，很多选择。例如，可以使用 Google 云端存储（GCS）存储桶，Amazon S3 存储桶，Github Pages，甚至可以创建自己的 Web 服务器。
 
@@ -52,7 +52,7 @@ entries:
       home: https://k8s.io/helm
       name: alpine
       sources:
-      - https://github.com/kubernetes/helm
+      - https://github.com/helm
       urls:
       - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz
       version: 0.2.0
@@ -62,7 +62,7 @@ entries:
       home: https://k8s.io/helm
       name: alpine
       sources:
-      - https://github.com/kubernetes/helm
+      - https://github.com/helm
       urls:
       - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz
       version: 0.1.0
diff --git a/chart/chart_repository_faq-zh_cn.md b/chart/chart_repository_faq-zh_cn.md
index a0d3a4b..fe8c440 100644
--- a/chart/chart_repository_faq-zh_cn.md
+++ b/chart/chart_repository_faq-zh_cn.md
@@ -2,7 +2,7 @@
 
 本节跟踪使用 chart 库时的一些常遇到的问题。
 
-我们很欢迎你的帮助来改进这个文档。要添加，更正或删除信息，提出问题或向我们发送 PR。
+我们很欢迎你的帮助来改进这个文档。要添加，更正或删除信息，提出问题[file an issue](https://github.com/helm/helm/issues)或向我们发送 PR。
 
 ## Fetching
 
diff --git a/chart/chart_tests-zh_cn.md b/chart/chart_tests-zh_cn.md
index 1885d88..a4abdea 100644
--- a/chart/chart_tests-zh_cn.md
+++ b/chart/chart_tests-zh_cn.md
@@ -22,10 +22,10 @@
 
 ## 示例测试
 
-下面是一个示例 mariadb chart 中 helm 测试 pod 定义的示例：
+下面是一个示例 WordPress chart 中 helm 测试 pod 定义的示例。这个测试验证了 mariadb 的连接和登录：
 
 ```
-mariadb/
+wordpress/
   Chart.yaml
   README.md
   values.yaml
@@ -40,26 +40,26 @@ mariadb/
 apiVersion: v1
 kind: Pod
 metadata:
-  name: "{{ .Release.Name }}-credentials-test"
+  name: "{{.Release.Name}}-credentials-test"
   annotations:
     "helm.sh/hook": test-success
 spec:
   containers:
-  - name: {{ .Release.Name }}-credentials-test
-    image: {{ .Values.image }}
+  - name: {{.Release.Name}}-credentials-test
+    image: {{.Values.image}}
     env:
       - name: MARIADB_HOST
-        value: {{ template "mariadb.fullname" . }}
+        value: {{template "mariadb.fullname" .}}
       - name: MARIADB_PORT
         value: "3306"
       - name: WORDPRESS_DATABASE_NAME
-        value: {{ default "" .Values.mariadb.mariadbDatabase | quote }}
+        value: {{default "" .Values.mariadb.mariadbDatabase | quote}}
       - name: WORDPRESS_DATABASE_USER
-        value: {{ default "" .Values.mariadb.mariadbUser | quote }}
+        value: {{default "" .Values.mariadb.mariadbUser | quote}}
       - name: WORDPRESS_DATABASE_PASSWORD
         valueFrom:
           secretKeyRef:
-            name: {{ template "mariadb.fullname" . }}
+            name: {{template "mariadb.fullname" .}}
             key: mariadb-password
     command: ["sh", "-c", "mysql --host=$MARIADB_HOST --port=$MARIADB_PORT --user=$WORDPRESS_DATABASE_USER --password=$WORDPRESS_DATABASE_PASSWORD"]
   restartPolicy: Never
@@ -67,7 +67,7 @@ spec:
 
 ## 在 release 上运行测试套件的步骤
 
-1. `$ helm install mariadb`
+1. `$ helm install wordpress`
 ```
 NAME:   quirky-walrus
 LAST DEPLOYED: Mon Feb 13 13:50:43 2017
diff --git a/chart/charts-zh_cn.md b/chart/charts-zh_cn.md
index a45b609..f9e846a 100644
--- a/chart/charts-zh_cn.md
+++ b/chart/charts-zh_cn.md
@@ -67,7 +67,7 @@ nginx-1.2.3.tgz
 
 更复杂的 SemVer 2 命名也是支持的，例如 version: 1.2.3-alpha.1+ef365。但非 SemVer 命名是明确禁止的。
 
-** 注意 **：虽然 Helm Classic 和 Deployment Manager 在 chart 方面都非常适合 GitHub，但 Kubernetes Helm 并不依赖或需要 GitHub 甚至 Git。因此，它不使用 Git SHA 进行版本控制。
+** 注意 ** ：虽然 Helm Classic 和 Deployment Manager 在 chart 方面都非常适合 GitHub，但 Kubernetes Helm 并不依赖或需要 GitHub 甚至 Git。因此，它不使用 Git SHA 进行版本控制。
 
 许多 Helm 工具都使用 `Chart.yaml` 的 v`ersion` 字段，其中包括 CLI 和 Tiller 服务。在生成包时，helm package 命令将使用它在 Chart.yaml 中的版本名作为包名。系统假定 chart 包名称中的版本号与 `Chart.yaml` 中的版本号相匹配。不符合这个情况会导致错误。
 
@@ -387,7 +387,7 @@ wordpress:
 
 因此，单个 release 是使用 charts 及其依赖关系创建的所有对象。
 
-Kubernetes 类型的安装顺序由 kind_sorter.go 中的枚举 InstallOrder 给出（[the Helm source file](https://github.com/kubernetes/helm/blob/master/pkg/tiller/kind_sorter.go#L26))）。
+Kubernetes 类型的安装顺序由 kind_sorter.go 中的枚举 InstallOrder 给出（[the Helm source file](https://github.com/helm/blob/master/pkg/tiller/kind_sorter.go#L26))）。
 
 ## 模板 Templates 和值 Values
 
@@ -413,15 +413,15 @@ metadata:
   name: deis-database
   namespace: deis
   labels:
-    heritage: deis
+    app.kubernetes.io/managed-by: deis
 spec:
   replicas: 1
   selector:
-    app: deis-database
+    app.kubernetes.io/name: deis-database
   template:
     metadata:
       labels:
-        app: deis-database
+        app.kubernetes.io/name: deis-database
     spec:
       serviceAccount: deis-database
       containers:
@@ -514,15 +514,15 @@ metadata:
   name: deis-database
   namespace: deis
   labels:
-    heritage: deis
+    app.kubernetes.io/managed-by: deis
 spec:
   replicas: 1
   selector:
-    app: deis-database
+    app.kubernetes.io/name: deis-database
   template:
     metadata:
       labels:
-        app: deis-database
+        app.kubernetes.io/name: deis-database
     spec:
       serviceAccount: deis-database
       containers:
@@ -655,5 +655,5 @@ repo 库的主要特征是存在一个名为的特殊文件 `index.yaml`，它
 
 -   `Chart.yaml` 将被生成器覆盖。
 -   用户将期望修改这样的 chart 内容，因此文档应该指出用户如何做到这一点。
--   所有匹配项 <CHARTNAME> 将被替换为指定的 chart 名称，以便起始 chart 可用作模板。
+-   所有 templates 目录下的匹配项 `<CHARTNAME>` 将被替换为指定的 chart 名称，以便起始 chart 可用作模板。另外, `values.yaml` 的 `<CHARTNAME>` 也会被替换.
 -   目前添加chart的唯一方法是手动将其复制到`$HELM_HOME/starters`。在chart的文档中，你需要解释该过程。
diff --git a/chart/charts_hooks-zh_cn.md b/chart/charts_hooks-zh_cn.md
index 46dc306..a9077e0 100644
--- a/chart/charts_hooks-zh_cn.md
+++ b/chart/charts_hooks-zh_cn.md
@@ -67,9 +67,9 @@ kind: Job
 metadata:
   name: "{{.Release.Name}}"
   labels:
-    heritage: {{.Release.Service | quote }}
-    release: {{.Release.Name | quote }}
-    chart: "{{.Chart.Name}}-{{.Chart.Version}}"
+    app.kubernetes.io/managed-by: {{.Release.Service | quote}}
+    app.kubernetes.io/instance: {{.Release.Name | quote}}
+    helm.sh/chart: "{{.Chart.Name}}-{{.Chart.Version}}"
   annotations:
     # This is what defines this resource as a hook. Without this line, the
     # job is considered part of the release.
@@ -81,15 +81,15 @@ spec:
     metadata:
       name: "{{.Release.Name}}"
       labels:
-        heritage: {{.Release.Service | quote }}
-        release: {{.Release.Name | quote }}
-        chart: "{{.Chart.Name}}-{{.Chart.Version}}"
+      app.kubernetes.io/managed-by: {{.Release.Service | quote}}
+      app.kubernetes.io/instance: {{.Release.Name | quote}}
+      helm.sh/chart: "{{.Chart.Name}}-{{.Chart.Version}}"
     spec:
       restartPolicy: Never
       containers:
       - name: post-install-job
         image: "alpine:3.3"
-        command: ["/bin/sleep","{{default "10" .Values.sleepyTime}}"]
+        command: ["/bin/sleep","{{default"10".Values.sleepyTime}}"]
 
 ```
 
@@ -119,7 +119,7 @@ spec:
     "helm.sh/hook-weight": "5"
 ```
 
-hook 权重可以是正数或负数，但必须表示为字符串。当 Tiller 开始执行一个特定类型的 hook 的执行周期时，它会按升序对这些 hook 进行排序。
+hook 权重可以是正数或负数，但必须表示为字符串。当 Tiller 开始执行一个特定类型的 hook (例： `pre-install` hooks  `post-install` hooks, 等等) 执行周期时，它会按升序对这些 hook 进行排序。
 
 还可以定义确定何时删除相应的 hook 资源的策略。hook 删除策略使用以下注释来定义：
 
diff --git a/chart/charts_tips_and_tricks-zh_cn.md b/chart/charts_tips_and_tricks-zh_cn.md
index fbb76d9..465bd74 100644
--- a/chart/charts_tips_and_tricks-zh_cn.md
+++ b/chart/charts_tips_and_tricks-zh_cn.md
@@ -5,7 +5,7 @@
 
 Helm 使用 Go 模板 [Go templates](https://godoc.org/text/template) 来模板化你的资源文件。虽然 Go 提供了几个内置函数，但我们添加了许多其他函数。
 
-首先，我们在 Sprig 库 [Sprig library](https://godoc.org/github.com/Masterminds/sprig) 中添加了几乎所有的功能 。出于安全原因，我们删除了两个：`env` 和 `expandenv`（这会让 chart 作者访问 Tiller 的环境）。
+首先，我们在 Sprig 库 [Sprig library](https://godoc.org/github.com/Masterminds/sprig) 中添加了几乎所有的函数 。出于安全原因，我们删除了两个：`env` 和 `expandenv`（这会让 chart 作者访问 Tiller 的环境）。
 
 我们还添加了两个特殊的模板函数：`include` 和 `required`。`include` 函数允许引入另一个模板，然后将结果传递给其他模板函数。
 
@@ -20,7 +20,7 @@ value: {{include "mytpl" . | lower | quote}}
 下面的 `required` 函数示例声明了. Values.who 的条目是必需的，并且在缺少该条目时将显示错误消息：
 
 ```yaml
-value: {{required "A valid .Values.who entry required!" .Values.who }}
+value: {{required "A valid .Values.who entry required!" .Values.who}}
 ```
 
 ## 引用字符串，不要引用整数
@@ -28,13 +28,13 @@ value: {{required "A valid .Values.who entry required!" .Values.who }}
 当使用字符串数据时，引用字符串比把它们留为空白字符更安全：
 
 ```
-name: {{.Values.MyName | quote }}
+name: {{.Values.MyName | quote}}
 ```
 
 但是，使用整数时 _不要引用值_。在很多情况下，这可能会导致 Kubernetes 内部的解析错误。
 
 ```
-port: {{ .Values.Port }}
+port: {{.Values.Port}}
 ```
 
 这种做法不适用于预期为字符串的 env 变量值，即使它们表示为整数：
@@ -54,7 +54,7 @@ Go 提供了一种使用内置 `template` 指令将一个模板包含在另一
 为了能够包含模板，然后对该模板的输出执行操作，Helm 有一个特殊的 `include` 函数：
 
 ```
-{{ include "toYaml" $value | indent 2 }}
+{{include "toYaml" $value | indent 2}}
 ```
 
 上面包含一个名为的模板 toYaml，传递它 $value 的值，然后将该模板的输出传递给该 indent 函数。
@@ -70,11 +70,49 @@ Go 提供了一种设置模板选项以控制 map 使用 map 中不存在的键
 例如：
 
 ```
-{{ required "A valid foo is required!" .Values.foo }}
+{{required "A valid foo is required!" .Values.foo}}
 ```
 
 上面将在定义. Values.foo 时渲染模板，但在未定义. Values.foo 时无法渲染并报错退出。
+## 使用'tpl' 函数
 
+`tpl` 函数允许开发人员将字符串计算为模板内的模板。
+这对于将模板字符串作为值传递给 chart 或渲染外部配置文件很有用。
+
+语法: `{{tpl TEMPLATE_STRING VALUES}}`
+
+样例:
+
+```yaml
+# values
+template: "{{.Values.name}}"
+name: "Tom"
+
+# template
+{{tpl .Values.template .}}
+
+# output
+Tom
+```
+
+渲染一个外部配置文件:
+
+```yaml
+# external configuration file conf/app.conf
+firstName={{.Values.firstName}}
+lastName={{.Values.lastName}}
+
+# values
+firstName: Peter
+lastName: Parker
+
+# template
+{{tpl (.Files.Get "conf/app.conf") . }}
+
+# output
+firstName=Peter
+lastName=Parker
+```
 ## 创建镜像拉取的 Secrets
 
 镜像拉的 secrets 实质上是注册，用户名和密码的组合。在正在部署的应用程序中可能需要它们，但要创建它们需要多次运行 base64。我们可以编写一个帮助程序模板来组合 Docker 配置文件，以用作 Secret 的有效载体。这里是一个例子：
@@ -90,9 +128,9 @@ imageCredentials:
 
 然后我们定义我们的帮助模板如下：
 ```
-{{- define "imagePullSecret" }}
+{{- define "imagePullSecret"}}
 {{- printf "{\"auths\": {\"%s\": {\"auth\": \"%s\"}}}" .Values.imageCredentials.registry (printf "%s:%s" .Values.imageCredentials.username .Values.imageCredentials.password | b64enc) | b64enc }}
-{{- end }}
+{{- end}}
 ```
 最后，我们在更大的模板中使用助手模板来创建 Secret manifest：
 
@@ -103,7 +141,7 @@ metadata:
   name: myregistrykey
 type: kubernetes.io/dockerconfigjson
 data:
-  .dockerconfigjson: {{ template "imagePullSecret" . }}
+  .dockerconfigjson: {{template "imagePullSecret" .}}
 ```
 
 ## ConfigMaps 或 Secrets 更改时自动 Roll Deployments
@@ -118,7 +156,7 @@ spec:
   template:
     metadata:
       annotations:
-        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
+        checksum/config: {{include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
 [...]
 ```
 
@@ -144,7 +182,7 @@ metadata:
 
 有时候你想在 chart 中创建一些可重用的部分，无论它们是块还是模板部分。通常，将这些文件保存在自己的文件中会更整洁。
 
-在 `templates/` 目录中，任何以下划线 “_” 开头的文件都不会输出 Kubernetesmanifest 文件。另按照惯例，辅助模板和 partials 被放置在一个 _helpers.tpl 文件中。
+在 `templates/` 目录中，任何以下划线 "-" 开头的文件都不会输出 Kubernetesmanifest 文件。另按照惯例，辅助模板和 partials 被放置在一个 `_helpers.tpl` 文件中。
 
 ## 具有许多依赖关系的复杂 chart
 
diff --git a/chart/provenance-zh_cn.md b/chart/provenance-zh_cn.md
index 50aca66..e9385ee 100644
--- a/chart/provenance-zh_cn.md
+++ b/chart/provenance-zh_cn.md
@@ -16,10 +16,12 @@ Helm 拥有可帮助 chart 用户验证 chart 包完整性和出处的工具。
 
 - 二进制（非 ASCII）格式的有效 PGP 密钥对
 - helm 命令行工具
-- GnuPG 命令行工具（可选）
+- GnuPG >=2.1 命令行工具（可选）
 - Keybase 命令行工具（可选）
 -
-** 注意：** 如果 PGP 私钥有密码，支持 `--sign` 选项的任何命令系统将提示输入密码以查看。
+** 注意：** 如果 PGP 私钥有密码，支持 `--sign` 选项的任何命令系统将提示输入密码。可以设置 HELM_KEY_PASSPHRASE 环境变量避免每次输入.
+
+** 注意：** GnuPG 的密钥文件格式在 2.1 版中已更改。在该版本之前，没有必要从 GnuPG 中导出密钥，可以将 Helm 指向你的 `* .gpg` 文件。使用 2.1 时，引入了新的 `.kbx` 格式，Helm 不支持这种格式。
 
 创建 chart：
 
@@ -34,9 +36,9 @@ Creating mychart
 $ helm package --sign --key 'helm signing key' --keyring path/to/keyring.secret mychart
 ```
 
-** 提示：** 对于 GnuPG 用户，密钥环已存在 `~/.gnupg/secring.gpg`。可以使用 gpg --list-secret-keys 列出拥有的密钥。
+** 提示：** 对于 GnuPG 用户，密钥环已存在 `~/.gnupg/secring.kbx`。可以使用 gpg --list-secret-keys 列出拥有的密钥。
 
-** 警告：** GnuPG v2 在默认位置在 `〜/ .gnupg / pubring.kbx`，使用新格式'kbx'存储密钥 keyring。请使用以下命令将钥匙 keyring 转换为传统的 gpg 格式：
+** 警告：** GnuPG v2.1 在默认位置在 `〜/ .gnupg / pubring.kbx`，使用新格式'kbx'存储密钥 keyring。请使用以下命令将钥匙 keyring 转换为传统的 gpg 格式：
 
 ```
 $ gpg --export-secret-keys >~/.gnupg/secring.gpg
@@ -80,10 +82,10 @@ $ helm install --verify mychart-0.1.0.tgz
 第一步是将 keybase 密钥导入到本地 GnuPG 密钥 keyring 中：
 
 ```
-$ keybase pgp export -s | gpg --import
+$ keybase pgp export -s > secring.gpg
 ```
 
-这会将 Keybase 密钥转换为 OpenPGP 格式，然后将其本地导入到 `~/.gnupg/secring.gpg` 文件中。
+这会将 Keybase 密钥转换为 OpenPGP 格式，然后将其本地导入到 secring.gpg 文件中。
 
 可以通过运行 `gpg --list-secret-keys` 进行仔细检查。
 
@@ -95,7 +97,9 @@ uid                  technosophos (keybase.io/technosophos) <technosophos@keybas
 ssb   2048R/D125E546 2016-07-25
 ```
 
-注意，密钥有一个标识符字符串：
+提示: 如果你想添加一个 Keybase key 到已存在的 keyring, 你需要执行 `keybase pgp export -s | gpg --import && gpg --export-secret-keys --outfile secring.gpg`
+
+你的密钥有一个标识符字符串：
 
 ```
 technosophos (keybase.io/technosophos) <technosophos@keybase.io>
diff --git a/chart_best_practices/README-zh_cn.md b/chart_best_practices/README-zh_cn.md
index 2ed6a9a..a530984 100644
--- a/chart_best_practices/README-zh_cn.md
+++ b/chart_best_practices/README-zh_cn.md
@@ -13,4 +13,4 @@
 - Kubernetes 资源：
   - [Pod 及其规格](pods-zh_cn.md)：查看使用 pod 规格的最佳做法。
   - [基于角色的访问控制](rbac-zh_cn.md)：有关创建和使用服务帐户，角色和角色绑定的指导。
- ;- [第三方资源]：第三方资源（TPR）有其自己的相关最佳实践。
+  - [自定义资源](custom_resource_definitions-zh_cn.md)：自定义资源（CRDs）有其自己的相关最佳实践。
diff --git a/chart_best_practices/conventions-zh_cn.md b/chart_best_practices/conventions-zh_cn.md
index 275417c..3356637 100644
--- a/chart_best_practices/conventions-zh_cn.md
+++ b/chart_best_practices/conventions-zh_cn.md
@@ -4,19 +4,22 @@
 
 ## Chart 名称
 
-Chart 名称应该是小写字母和数字组成，可以用破折号（-）分隔：
+Chart 名称应该是小写字母和数字组成，字母开头：
 
 举例：
+可以使用破折号 `-`, 但在 Helm templates 中使用需要一些小技巧 (查看 [issue #2192](https://github.com/helm/helm/issues/2192) 获取更多信息).
++
+这里有一些好例子 [Helm Community Charts](https://github.com/helm/charts):
 
 ```
 drupal
-nginx-lego
-aws-cluster-autoscaler
+cert-manager
+oauth2-proxy
 ```
 
 Chart 名称中不能使用大写字母和下划线。Chart 名称不应使用点。
 
-包含 chart 的目录必须与 chart 具有相同的名称。因此，chart `nginx-lego` 必须在名为 `nginx-lego/` 的目录中创建。这不仅仅是一种风格的细节，而是 Helm Chart 格式的要求。
+包含 chart 的目录必须与 chart 具有相同的名称。因此，chart `cert-manager` 必须在名为 `cert-manager/` 的目录中创建。这不仅仅是一种风格的细节，而是 Helm Chart 格式的要求。
 
 ## 版本号
 
diff --git a/chart_best_practices/labels-zh_cn.md b/chart_best_practices/labels-zh_cn.md
index affd8f4..ef1ffd3 100644
--- a/chart_best_practices/labels-zh_cn.md
+++ b/chart_best_practices/labels-zh_cn.md
@@ -7,7 +7,7 @@
 - Kubernetes 使用它来识别此资源
 - 为了查询系统目的，向操作员暴露是非常有用的。
 
-例如，我们建议使用 `chart: NAME-VERSION` 标签作为标签，以便操作员可以方便地查找要使用的特定 chart 的所有实例。
+例如，我们建议使用 `helm.sh/chart: NAME-VERSION` 标签作为标签，以便操作员可以方便地查找要使用的特定 chart 的所有实例。
 
 如果元数据项不用于查询，则应将其设置为注释。
 
@@ -18,8 +18,12 @@ Helm hook 总是注释。
 
 名称 | 状态 | 描述
 -----|------|----------
-heritage|	REC	| 这应该始终设置为 {% raw %}{{ .Release.Service }}{% endraw %}。它用于查找 Tiller 管理的所有东西。
-release| REC | 这应该是 {% raw %}{{ .Release.Name }}{% endraw %}。
-chart| REC| 这应该是 chart 名称和版本：{% raw %}{{ .Chart.Name }}-{{ .Chart.Version }}{% endraw %}。
-app| REC| 这应该是应用程序名称，代表了整个应用程序。通常 {% raw %}{{ template "name" . }}{% endraw %} 用于此。这被许多 Kubernetes manifests 所使用，而不是 Helm 特有的。
-component| OPT|	这是标记片段,在应用程序中可能发挥的不同角色的常用标签。例如，`component: frontend`。
+`app.kubernetes.io/name` | REC | This should be the app name, reflecting the entire app. Usually \{\{template "name" .\}\} is used for this. This is used by many Kubernetes manifests, and is not Helm-specific.
+`helm.sh/chart` | REC | This should be the chart name and version: \{\{.Chart.Name\}\}-\{\{ .Chart.Version \\| replace "+" "_" \}\}.
+`app.kubernetes.io/managed-by` | REC | This should always be set to \{\{.Release.Service\}\}. It is for finding all things managed by Tiller.
+`app.kubernetes.io/instance` | REC | This should be the \{\{.Release.Name\}\}. It aid in differentiating between different instances of the same application.
+`app.kubernetes.io/version` | OPT | The version of the app and can be set to \{\{.Chart.AppVersion\}\}.
+`app.kubernetes.io/component` | OPT | This is a common label for marking the different roles that pieces may play in an application. For example, `app.kubernetes.io/component: frontend`.
+`app.kubernetes.io/part-of` | OPT | When multiple charts or pieces of software are used together to make one application. For example, application software and a database to produce a website. This can be set to the top level application being supported.
+
+获取更多关于 `app.kubernetes.io`前缀的 Kubernetes labels 的信息 [Kubernetes documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/)
diff --git a/chart_best_practices/pods-zh_cn.md b/chart_best_practices/pods-zh_cn.md
index 133ccf4..55cee57 100644
--- a/chart_best_practices/pods-zh_cn.md
+++ b/chart_best_practices/pods-zh_cn.md
@@ -17,13 +17,13 @@
 镜像可以在 `values.yaml` 文件中定义，可以很容易地换为镜像地址。
 
 ```
-image: {{ .Values.redisImage | quote }}
+image: {{.Values.redisImage | quote}}
 ```
 
 镜像和标签可以在 `values.yaml` 中定义为两个单独的字段：
 
 ```
-image: "{{ .Values.redisImage }}:{{ .Values.redisTag }}"
+image: "{{.Values.redisImage}}:{{ .Values.redisTag }}"
 ```
 
 ## ImagePullPolicy
@@ -31,7 +31,7 @@ image: "{{ .Values.redisImage }}:{{ .Values.redisTag }}"
 `helm create` 设置 `imagePullPolicy` 为 `IfNotPresent`, 在 `deployment.yaml` 中：
 
 ```yaml
-imagePullPolicy: {{ .Values.image.pullPolicy }}
+imagePullPolicy: {{.Values.image.pullPolicy}}
 ```
 
 和 values.yaml 中：
@@ -49,11 +49,11 @@ pullPolicy: IfNotPresent
 ```yaml
 selector:
   matchLabels:
-      app: MyName
+      app.kubernetes.io/name: MyName
 template:
   metadata:
     labels:
-      app: MyName
+      app.kubernetes.io/name: MyName
 ```
 
 这是一个很好的做法，因为它可以使 set 和 pod 之间保持关系。
diff --git a/chart_best_practices/values-zh_cn.md b/chart_best_practices/values-zh_cn.md
index 92128bb..4329629 100644
--- a/chart_best_practices/values-zh_cn.md
+++ b/chart_best_practices/values-zh_cn.md
@@ -44,15 +44,15 @@ serverPort: 80
 为了获得最佳安全性，必须在每个级别检查嵌套值：
 
 ```
-{{ if .Values.server }}
-  {{ default "none" .Values.server.name }}
-{{ end }}
+{{if .Values.server}}
+  {{default "none" .Values.server.name}}
+{{end}}
 ```
 
 对于每一层嵌套，都必须进行存在检查。但对于展平配置，可以跳过这些检查，使模板更易于阅读和使用。
 
 ```
-{{ default "none" .Values.serverName }}
+{{default "none" .Values.serverName}}
 ```
 
 当有大量相关变量时，且至少有一个是非可选的，可以使用嵌套值来提高可读性。
@@ -69,11 +69,12 @@ YAML 的类型强制规则有时是违反直觉的。例如， `foo: false` 与
 
 ## 考虑用户如何使用你的 values
 
-有三种潜在的 values 来源：
+有几种潜在的 values 来源：
 
 - chart 的 `values.yaml` 文件
 - 由 `helm install -f` 或 `helm upgrade -f` 提供的 value 文件
 - 传递给 `--set` 或的 `--set-string` 标志 `helm install` 或 `helm upgrade` 命令
+- 通过 `--set-file`  将 文件内容传递给 `helm install` or `helm upgrade`
 
 在设计 value 的结构时，请记住 chart 的用户可能希望通过 `-f` 标志或 `--set ` 选项覆盖它们。
 
diff --git a/chart_template_guide/accessing_files-zh_cn.md b/chart_template_guide/accessing_files-zh_cn.md
index c25809c..c461dfb 100644
--- a/chart_template_guide/accessing_files-zh_cn.md
+++ b/chart_template_guide/accessing_files-zh_cn.md
@@ -49,13 +49,13 @@ message = Goodbye from config 3
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: {{ .Release.Name }}-configmap
+  name: {{.Release.Name}}-configmap
 data:
-  {{- $files := .Files }}
-  {{- range tuple "config1.toml" "config2.toml" "config3.toml" }}
-  {{ . }}: |-
-    {{ $files.Get . }}
-  {{- end }}
+  {{- $files := .Files}}
+  {{- range tuple "config1.toml" "config2.toml" "config3.toml"}}
+  {{.}}: |-
+    {{$files.Get .}}
+  {{- end}}
 ```
 
 这个配置映射使用了前几节讨论的几种技术。例如，我们创建一个 `$files` 变量来保存 `.Files` 对象的引用。我们还使用该 `tuple` 函数来创建我们循环访问的文件列表。然后我们打印每个文件名（`{{.}}: |-`），然后打印文件的内容 `{{ $files.Get . }}`。
@@ -111,19 +111,19 @@ bar/:
 Globs 有多个方法可选择：
 
 ```yaml
-{{ $root := . }}
-{{ range $path, $bytes := .Files.Glob "**.yaml" }}
-{{ $path }}: |-
-{{ $root.Files.Get $path }}
-{{ end }}
+{{$root := .}}
+{{range $path, $bytes := .Files.Glob "**.yaml"}}
+{{$path}}: |-
+{{$root.Files.Get $path}}
+{{end}}
 ```
 
 或
 
 ```yaml
-{{ range $path, $bytes := .Files.Glob "foo/*" }}
-{{ $path.base }}: '{{ $root.Files.Get $path | b64enc }}'
-{{ end }}
+{{range $path, $bytes := .Files.Glob "foo/*"}}
+{{$path.base}}: '{{ $root.Files.Get $path | b64enc }}'
+{{end}}
 ```
 
 ## ConfigMap 和 Secrets 工具函数
@@ -142,7 +142,7 @@ kind: ConfigMap
 metadata:
   name: conf
 data:
-{{ (.Files.Glob "foo/*").AsConfig | indent 2 }}
+{{(.Files.Glob "foo/*").AsConfig | indent 2 }}
 ---
 apiVersion: v1
 kind: Secret
@@ -150,7 +150,7 @@ metadata:
   name: very-secret
 type: Opaque
 data:
-{{ (.Files.Glob "bar/*").AsSecrets | indent 2 }}
+{{(.Files.Glob "bar/*").AsSecrets | indent 2 }}
 ```
 
 ## 编码
@@ -162,11 +162,11 @@ data:
 apiVersion: v1
 kind: Secret
 metadata:
-  name: {{ .Release.Name }}-secret
+  name: {{.Release.Name}}-secret
 type: Opaque
 data:
   token: |-
-    {{ .Files.Get "config1.toml" | b64enc }}
+    {{.Files.Get "config1.toml" | b64enc}}
 ```
 
 以上例子将采用 `config1.toml` 文件，我们之前使用的相同文件并对其进行编码：
@@ -189,8 +189,8 @@ data:
 
 ```yaml
 data:
-  some-file.txt: {{ range .Files.Lines "foo/bar.txt" }}
-    {{ . }}{{ end }}
+  some-file.txt: {{range .Files.Lines "foo/bar.txt"}}
+    {{.}}{{ end }}
 ```
 
 目前，无法将 `helm install` 期间将外部文件传递给 chart。因此，如果要求用户提供数据，则必须使用 `helm install -f` 或进行加载 `helm install --set`。
diff --git a/chart_template_guide/control_structures-zh_cn.md b/chart_template_guide/control_structures-zh_cn.md
index 2e0d3d8..dd772d6 100644
--- a/chart_template_guide/control_structures-zh_cn.md
+++ b/chart_template_guide/control_structures-zh_cn.md
@@ -20,13 +20,13 @@
 条件的基本结构如下所示：
 
 ```
-{{ if PIPELINE }}
+{{if PIPELINE}}
   # Do something
-{{ else if OTHER PIPELINE }}
+{{else if OTHER PIPELINE}}
   # Do something else
-{{ else }}
+{{else}}
   # Default case
-{{ end }}
+{{end}}
 ```
 
 注意，我们现在讨论的是管道而不是值。其原因是要明确控制结构可以执行整个管道，而不仅仅是评估一个值。
@@ -39,7 +39,7 @@
 - 一个 `nil`（空或 null）
 - 一个空的集合（`map`，`slice`，`tuple`，`dict`，`array`）
 
-在所有其他条件下，条件为真。
+在其他情况下, 条件值为 _true_ 此管道被执行。
 
 我们为 ConfigMap 添加一个简单的条件。如果饮料被设置为咖啡，我们将添加另一个设置：
 
@@ -47,16 +47,15 @@
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: {{ .Release.Name }}-configmap
+  name: {{.Release.Name}}-configmap
 data:
   myvalue: "Hello World"
-  drink: {{ .Values.favorite.drink | default "tea" | quote }}
-  food: {{ .Values.favorite.food | upper | quote }}
-  {{ if eq .Values.favorite.drink "coffee" }}mug: true{{ end }}
-```
-
-由于我们在最后一个例子中注释了 drink: coffee，因此输出结果不应包含 `mug: true` 标志。但是，如果我们将该行添加回到我们的 values.yaml 文件中，则输出应如下所示：
+  drink: {{.Values.favorite.drink | default "tea" | quote}}
+  food: {{.Values.favorite.food | upper | quote}}
+  {{if (.Values.favorite.drink) and eq .Values.favorite.drink "coffee" }}mug: true{{ end }}
 
+```
+注意 `.Values.favorite.drink` 必须已定义，否则在将它与 “coffee” 进行比较时会抛出错误。由于我们在上一个例子中注释掉了 `drink：coffee`，因此输出不应该包含 `mug：true` 标志。但是如果我们将该行添加回 `values.yaml` 文件中，输出应该如下所示:
 
 ```yaml
 # Source: mychart/templates/configmap.yaml
@@ -79,11 +78,11 @@ data:
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: {{ .Release.Name }}-configmap
+  name: {{.Release.Name}}-configmap
 data:
   myvalue: "Hello World"
-  drink: {{ .Values.favorite.drink | default "tea" | quote }}
-  food: {{ .Values.favorite.food | upper | quote }}
+  drink: {{.Values.favorite.drink | default "tea" | quote}}
+  food: {{.Values.favorite.food | upper | quote}}
   {{if eq .Values.favorite.drink "coffee"}}
     mug: true
   {{end}}
@@ -119,11 +118,11 @@ mug 不正确地缩进。让我们简单地缩进那行，然后重新运行：
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: {{ .Release.Name }}-configmap
+  name: {{.Release.Name}}-configmap
 data:
   myvalue: "Hello World"
-  drink: {{ .Values.favorite.drink | default "tea" | quote }}
-  food: {{ .Values.favorite.food | upper | quote }}
+  drink: {{.Values.favorite.drink | default "tea" | quote}}
+  food: {{.Values.favorite.food | upper | quote}}
   {{if eq .Values.favorite.drink "coffee"}}
   mug: true
   {{end}}
@@ -160,11 +159,11 @@ YAML 中的缩进空格是严格的的，因此管理空格变得非常重要。
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: {{ .Release.Name }}-configmap
+  name: {{.Release.Name}}-configmap
 data:
   myvalue: "Hello World"
-  drink: {{ .Values.favorite.drink | default "tea" | quote }}
-  food: {{ .Values.favorite.food | upper | quote }}
+  drink: {{.Values.favorite.drink | default "tea" | quote}}
+  food: {{.Values.favorite.food | upper | quote}}
   {{- if eq .Values.favorite.drink "coffee"}}
   mug: true
   {{- end}}
@@ -177,11 +176,11 @@ data:
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: {{ .Release.Name }}-configmap
+  name: {{.Release.Name}}-configmap
 data:
   myvalue: "Hello World"
-  drink: {{ .Values.favorite.drink | default "tea" | quote }}
-  food: {{ .Values.favorite.food | upper | quote }}*
+  drink: {{.Values.favorite.drink | default "tea" | quote}}
+  food: {{.Values.favorite.food | upper | quote}}*
 **{{- if eq .Values.favorite.drink "coffee"}}
   mug: true*
 **{{- end}}
@@ -207,7 +206,7 @@ data:
 
 
 ```yaml
-  food: {{ .Values.favorite.food | upper | quote }}
+  food: {{.Values.favorite.food | upper | quote}}
   {{- if eq .Values.favorite.drink "coffee" -}}
   mug: true
   {{- end -}}
@@ -227,9 +226,9 @@ data:
 其语法 with 类似于一个简单的 if 语句：
 
 ```
-{{ with PIPELINE }}
+{{with PIPELINE}}
   # restricted scope
-{{ end }}
+{{end}}
 ```
 范围可以改变。with 可以允许将当前范围（`.`）设置为特定的对象。例如，我们一直在使用的 `.Values.favorites`。让我们重写我们的 ConfigMap 来改变 `.` 范围来指向 `.Values.favorites`：
 
@@ -237,13 +236,13 @@ data:
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: {{ .Release.Name }}-configmap
+  name: {{.Release.Name}}-configmap
 data:
   myvalue: "Hello World"
-  {{- with .Values.favorite }}
-  drink: {{ .drink | default "tea" | quote }}
-  food: {{ .food | upper | quote }}
-  {{- end }}
+  {{- with .Values.favorite}}
+  drink: {{.drink | default "tea" | quote}}
+  food: {{.food | upper | quote}}
+  {{- end}}
 ```
 
 
@@ -252,21 +251,21 @@ data:
 但是请注意！在受限范围内，此时将无法从父范围访问其他对象。例如，下面会报错：
 
 ```yaml
-  {{- with .Values.favorite }}
-  drink: {{ .drink | default "tea" | quote }}
-  food: {{ .food | upper | quote }}
-  release: {{ .Release.Name }}
-  {{- end }}
+  {{- with .Values.favorite}}
+  drink: {{.drink | default "tea" | quote}}
+  food: {{.food | upper | quote}}
+  release: {{.Release.Name}}
+  {{- end}}
 ```
 
 它会产生一个错误，因为 Release.Name 它不在 `.` 限制范围内。但是，如果我们交换最后两行，所有将按预期工作，因为范围在 {{end}} 之后被重置。
 
 ```yaml
-  {{- with .Values.favorite }}
-  drink: {{ .drink | default "tea" | quote }}
-  food: {{ .food | upper | quote }}
-  {{- end }}
-  release: {{ .Release.Name }}
+  {{- with .Values.favorite}}
+  drink: {{.drink | default "tea" | quote}}
+  food: {{.food | upper | quote}}
+  {{- end}}
+  release: {{.Release.Name}}
 ```
 
 看下 `range`，我们看看模板变量，它提供了一个解决上述范围问题的方法。
@@ -294,17 +293,17 @@ pizzaToppings:
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: {{ .Release.Name }}-configmap
+  name: {{.Release.Name}}-configmap
 data:
   myvalue: "Hello World"
-  {{- with .Values.favorite }}
-  drink: {{ .drink | default "tea" | quote }}
-  food: {{ .food | upper | quote }}
-  {{- end }}
+  {{- with .Values.favorite}}
+  drink: {{.drink | default "tea" | quote}}
+  food: {{.food | upper | quote}}
+  {{- end}}
   toppings: |-
-    {{- range .Values.pizzaToppings }}
-    - {{ . | title | quote }}
-    {{- end }}
+    {{- range .Values.pizzaToppings}}
+    - {{. | title | quote}}
+    {{- end}}
 
 ```
 让我们仔细看看 `toppings`:list。该 range 函数将遍历 pizzaToppings 列表。但现在发生了一些有趣的事. 就像 `with`sets 的范围 `.`，`range` 操作子也是一样。每次通过循环时，`.` 都设置为当前比萨饼顶部。也就是第一次 `.` 设定 mushrooms。第二个迭代它设置为 `cheese`，依此类推。
@@ -336,9 +335,9 @@ data:
 
 ```yaml
   sizes: |-
-    {{- range tuple "small" "medium" "large" }}
-    - {{ . }}
-    {{- end }}
+    {{- range tuple "small" "medium" "large"}}
+    - {{.}}
+    {{- end}}
 ```
 
 ```yaml
diff --git a/chart_template_guide/variables-zh_cn.md b/chart_template_guide/variables-zh_cn.md
index d456ec3..61fbbe2 100644
--- a/chart_template_guide/variables-zh_cn.md
+++ b/chart_template_guide/variables-zh_cn.md
@@ -5,11 +5,11 @@
 
 
 ```yaml
-  {{- with .Values.favorite }}
-  drink: {{ .drink | default "tea" | quote }}
-  food: {{ .food | upper | quote }}
-  release: {{ .Release.Name }}
-  {{- end }}
+  {{- with .Values.favorite}}
+  drink: {{.drink | default "tea" | quote}}
+  food: {{.food | upper | quote}}
+  release: {{.Release.Name}}
+  {{- end}}
 ```
 
 `Release.Name` 不在该 `with` 块中限制的范围内。解决范围问题的一种方法是将对象分配给可以在不考虑当前范围的情况下访问的变量。
@@ -20,15 +20,15 @@
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: {{ .Release.Name }}-configmap
+  name: {{.Release.Name}}-configmap
 data:
   myvalue: "Hello World"
   {{- $relname := .Release.Name -}}
-  {{- with .Values.favorite }}
-  drink: {{ .drink | default "tea" | quote }}
-  food: {{ .food | upper | quote }}
-  release: {{ $relname }}
-  {{- end }}
+  {{- with .Values.favorite}}
+  drink: {{.drink | default "tea" | quote}}
+  food: {{.food | upper | quote}}
+  release: {{$relname}}
+  {{- end}}
 ```
 
 注意，在我们开始 `with` 块之前，我们赋值 `$relname := `.Release.Name。现在在 `with` 块内部，`$relname` 变量仍然指向发布名称。
@@ -53,9 +53,9 @@ data:
 
 ```yaml
   toppings: |-
-    {{- range $index, $topping := .Values.pizzaToppings }}
-      {{ $index }}: {{ $topping }}
-    {{- end }}
+    {{- range $index, $topping := .Values.pizzaToppings}}
+      {{$index}}: {{ $topping }}
+    {{- end}}
 
 ```
 
@@ -75,11 +75,11 @@ data:
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: {{ .Release.Name }}-configmap
+  name: {{.Release.Name}}-configmap
 data:
   myvalue: "Hello World"
-  {{- range $key, $val := .Values.favorite }}
-  {{ $key }}: {{ $val | quote }}
+  {{- range $key, $val := .Values.favorite}}
+  {{$key}}: {{ $val | quote }}
   {{- end}}
 ```
 
@@ -104,25 +104,25 @@ data:
 举例说明：
 
 ```yaml
-{{- range .Values.tlsSecrets }}
+{{- range .Values.tlsSecrets}}
 apiVersion: v1
 kind: Secret
 metadata:
-  name: {{ .name }}
+  name: {{.name}}
   labels:
     # Many helm templates would use `.` below, but that will not work,
     # however `$` will work here
-    app: {{ template "fullname" $ }}
+    app.kubernetes.io/name: {{template "fullname" $}}
     # I cannot reference .Chart.Name, but I can do $.Chart.Name
-    chart: "{{ $.Chart.Name }}-{{ $.Chart.Version }}"
-    release: "{{ $.Release.Name }}"
-    heritage: "{{ $.Release.Service }}"
+    helm.sh/chart: "{{$.Chart.Name}}-{{ $.Chart.Version }}"
+    app.kubernetes.io/instance: "{{$.Release.Name}}"
+    app.kubernetes.io/managed-by: "{{$.Release.Service}}"
 type: kubernetes.io/tls
 data:
-  tls.crt: {{ .certificate }}
-  tls.key: {{ .key }}
+  tls.crt: {{.certificate}}
+  tls.key: {{.key}}
 ---
-{{- end }}
+{{- end}}
 ```
 
 到目前为止，我们只查看了一个文件中声明的一个模板。但是Helm模板语言的强大功能之一是它能够声明多个模板并将它们一起使用。我们将在下一节中讨论。
diff --git a/chart_template_guide/wrapping_up-zh_cn.md b/chart_template_guide/wrapping_up-zh_cn.md
index 2510606..d4cd166 100644
--- a/chart_template_guide/wrapping_up-zh_cn.md
+++ b/chart_template_guide/wrapping_up-zh_cn.md
@@ -12,8 +12,10 @@
 - 在 Go 模板 [Go template docs](https://godoc.org/text/template) 文档详细解释模板语法。
 - Schelm 工具 [Schelm tool](https://github.com/databus23/schelm) 是用于调试 chart 一个很好的帮手工具。
 
-有时候，问几个问题, 并从经验丰富的开发人员那里获得答案会更容易。最好的地方是在 Kubernetes `#Helm`Slack 频道：
+有时候，问几个问题, 并从经验丰富的开发人员那里获得答案会更容易。最好的地方是在 [Kubernetes Slack](https://kubernetes.slack.com) Helm 频道：
 
-- [Kubernetes Slack](https://slack.k8s.io/): `#helm`
+- [#helm-users](https://kubernetes.slack.com/messages/helm-users)
+- [#helm-dev](https://kubernetes.slack.com/messages/helm-dev)
+- [#charts](https://kubernetes.slack.com/messages/charts)
 
-最后，如果在本文中发现错误或遗漏，想要推荐一些新内容或希望参与，请访问Helm项目[The Helm Project](https://github.com/kubernetes/helm)。
+最后，如果在本文中发现错误或遗漏，想要推荐一些新内容或希望参与，请访问Helm项目[The Helm Project](https://github.com/helm)。
diff --git a/developers-zh_cn.md b/developers-zh_cn.md
index 231a333..3dd9f3c 100644
--- a/developers-zh_cn.md
+++ b/developers-zh_cn.md
@@ -23,7 +23,7 @@ $ make bootstrap build
 
 这将构建 Helm 和 Tiller。`make bootstrap` 将尝试安装某些工具，如果它们不存在的话。
 
-要运行所有测试（无需运行测试 `vendor/`），请运行 make test。
+要运行所有测试（无需运行测试 `vendor/`），请运行 `make test`。在容器环境运行所有测试，请运行 `make docker-test`
 
 要在本地运行 Helm 和 Tiller，可以运行 `bin/helm` 或 `bin/tiller`。
 
@@ -102,7 +102,7 @@ Tiller 应该在 >= 1.3 Kubernetes 群集上运行。
 
 确保你已经阅读并理解了贡献指南：
 
-https://github.com/kubernetes/helm/blob/master/CONTRIBUTING.md
+https://github.com/helm/blob/master/CONTRIBUTING.md
 
 ### 代码的结构
 
@@ -124,7 +124,7 @@ Go 依赖关系由 Glide 管理 并存储在 `vendor/` 目录中。
 
 我们通过 GitHub Pull Requests（PR）接受对代码的更改。执行此操作的一个工作流程如下所示：
 
-1. 转到 `$GOPATH/src/k8s.io` 目录，`git clone` `github.com/kubernetes/helm` 存储库。
+1. 转到 `$GOPATH/src/k8s.io` 目录，`git clone` `github.com/helm` 存储库。
 2. 将该存储库 fork 到你自己的 GitHub 帐户
 3. 将你的存储库添加为远程服务器 `$GOPATH/src/k8s.io/helm`
 4. 创建一个新的工作分支（`git checkout -b feat/my-feature`）并在该分支上完成工作。
@@ -169,6 +169,8 @@ Closes #1234
 
 我们通常也遵循由 `go lint` 和 `gometalinter` 推荐的约定。运行 `make test-style` 以测试样式一致性。
 
+如果你不想将 `gometalinter` 中的所有 linters 安装到你的全局 Go 环境中，你可以运行 `make docker-test-style`，它将运行相同的测试，但是在 docker 容器中是隔离的。
+
 更多阅读：
 
 - Effective Go [introduces formatting](https://golang.org/doc/effective_go.html#formatting)。
diff --git a/quickstart/install-zh_cn.md b/quickstart/install-zh_cn.md
index b287459..84a67df 100644
--- a/quickstart/install-zh_cn.md
+++ b/quickstart/install-zh_cn.md
@@ -2,7 +2,7 @@
 
 Helm 有两个部分：Helm 客户端（helm）和 Helm 服务端（Tiller）。本指南介绍如何安装客户端，然后继续演示两种安装服务端的方法。
 
-** 重要提示 **：如果你负责的群集是在受控的环境，尤其是在共享资源时，强烈建议使用安全配置安装 Tiller。有关指导，请参阅 [安全 Helm 安装](securing_installation-zh_cn.md)。
+** 重要提示 ** ：如果你负责的群集是在受控的环境，尤其是在共享资源时，强烈建议使用安全配置安装 Tiller。有关指导，请参阅 [安全 Helm 安装](securing_installation-zh_cn.md)。
 
 ## 安装 Helm 客户端
 
@@ -10,14 +10,22 @@ Helm 客户端可以从源代码安装，也可以从预构建的二进制版本
 
 ### 从二进制版本
 
-每一个版本 [release](https://github.com/kubernetes/helm/releases)Helm 提供多种操作系统的二进制版本。这些二进制版本可以手动下载和安装。
+每一个版本 [release](https://github.com/helm/releases)Helm 提供多种操作系统的二进制版本。这些二进制版本可以手动下载和安装。
 
-1. 下载你 [想要的版本](https://github.com/kubernetes/helm/releases)
+1. 下载你 [想要的版本](https://github.com/helm/releases)
 2. 解压缩（`tar -zxvf helm-v2.0.0-linux-amd64.tgz`）
 3. `helm` 在解压后的目录中找到二进制文件，并将其移动到所需的位置（`mv linux-amd64/helm /usr/local/bin/helm`）
 
 到这里，你应该可以运行客户端了：`helm help`。
 
+### 通过 Snap (Linux)
+
+Snap package 维护站点 [Snapcrafters](https://github.com/snapcrafters/helm).
+
+```
+$ sudo snap install helm
+```
+
 ### 通过 homebrew（macOS）
 
 Kubernetes 社区的成员为 Homebrew 贡献了 Helm。这个通常是最新的。
@@ -42,13 +50,13 @@ Helm 现在有一个安装 shell 脚本，将自动获取最新版本的 Helm 
 可以获取该脚本，然后在本地执行它。这种方法也有文档指导，以便可以在运行之前仔细阅读并理解它在做什么。
 
 ```
-$ curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > get_helm.sh
+$ curl https://raw.githubusercontent.com/helm/master/scripts/get > get_helm.sh
 $ chmod 700 get_helm.sh
 $ ./get_helm.sh
 ```
 
 ```
-curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get | bash
+curl https://raw.githubusercontent.com/helm/master/scripts/get | bash
 ```
 也可以做到这一点。
 
@@ -72,7 +80,7 @@ curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get | bash
 $ cd $GOPATH
 $ mkdir -p src/k8s.io
 $ cd src/k8s.io
-$ git clone https://github.com/kubernetes/helm.git
+$ git clone https://github.com/helm.git
 $ cd helm
 $ make bootstrap build
 ```
@@ -97,8 +105,10 @@ Helm 的服务器端部分 Tiller 通常运行在 Kubernetes 集群内部。但
 - `--tiller-image` 安装特定的镜像（版本）
 - `--kube-context` 使用安装到特定群集
 - `--tiller-namespace` 用一个特定的命名空间 (namespace) 安装
+- `--service-account` 使用 Service Account 安装  [RBAC enabled clusters](securing_installation-zh_cn.md#rbac))
+- `--automount-service-account false` 不适用 service account 安装
 
-一旦安装了 Tiller，运行 helm version 会显示客户端和服务器版本。（如果它仅显示客户端版本， helm 则无法连接到服务器, 使用 `kubectl` 查看是否有任何 tiller Pod 正在运行。）
+一旦安装了 Tiller，运行 `helm version` 会显示客户端和服务器版本。（如果它仅显示客户端版本， helm 则无法连接到服务器, 使用 `kubectl` 查看是否有任何 tiller Pod 正在运行。）
 
 除非设置 `--tiller-namespace` 或 `TILLER_NAMESPACE` 参数，否则 Helm 将在命名空间 `kube-system` 中查找 Tiller 。
 
diff --git a/quickstart/install_faq-zh_cn.md b/quickstart/install_faq-zh_cn.md
index 310eab3..ab8df08 100644
--- a/quickstart/install_faq-zh_cn.md
+++ b/quickstart/install_faq-zh_cn.md
@@ -2,7 +2,7 @@
 
 本节跟踪安装或开始使用 Helm 时遇到的一些经常遇到的问题。
 
-** 欢迎你的帮助 ** 来更好的提供此文档。要添加，更正或删除信息，提出问题 [issue](https://github.com/kubernetes/helm/issues) 或向我们发送 PR 请求。
+** 欢迎你的帮助 ** 来更好的提供此文档。要添加，更正或删除信息，提出问题 [issue](https://github.com/helm/helm/issues) 或向我们发送 PR 请求。
 
 ## 下载
 
@@ -163,7 +163,7 @@ Tiller 中的崩溃几乎总是由于未能与 Kubernetes API 服务器进行协
 
 Tiller 和 Helm 必须协商一个通用版本，以确保他们可以安全地进行通信而不会违反 API 假设。该错误意味着版本差异太大而无法安全地继续。通常，需要为此手动升级 Tiller。
 
-该安装指南 [Installation Guide](install.md) 大约有安全 Helm 升级和 Tiller 权威信息。
+该安装指南 [Installation Guide](install-zh_cn.md) 有关于安全 Helm 升级和 Tiller 的详细信息。
 
 版本号的规则如下：
 
diff --git a/quickstart/kubernetes_distros-zh_cn.md b/quickstart/kubernetes_distros-zh_cn.md
index c53dfac..a205792 100644
--- a/quickstart/kubernetes_distros-zh_cn.md
+++ b/quickstart/kubernetes_distros-zh_cn.md
@@ -10,7 +10,7 @@ Helm 已经过测试并且已知可以与 minikube 一起使用。它不需要
 通过配置 Hyperkube scripts/local-cluster.sh 已知可以工作。对于原始的 Hyperkube，可能需要进行一些手动配置。
 
 ## GKE
-已知 Google 的 GKE 托管 Kubernetes 平台与 Helm 一起工作，并且不需要额外的配置。
+已知 Google 的 GKE 托管 Kubernetes 平台 默认启用 RBAC. 因此需要为 tiller 创建一个服务帐户（service account），并在初始化 helm 服务端时使用 --service-account 参数。查看 [Tiller 和 RBAC](rbac-zh_cn.md) 获取更详细的信息.
 
 ## Ubuntu 与'kubeadm'
 kubeadm 构建的 Kubernetes 已知可用于以下 Linux 发行版：
diff --git a/quickstart/quickstart-zh_cn.md b/quickstart/quickstart-zh_cn.md
index 62acba3..325f111 100644
--- a/quickstart/quickstart-zh_cn.md
+++ b/quickstart/quickstart-zh_cn.md
@@ -12,7 +12,7 @@
 - 必须已安装 Kubernetes。对于 Helm 的最新版本，我们推荐最新的 Kubernetes 稳定版本，在大多数情况下它是次新版本。
 - 应该有一个本地配置好的 `kubectl`。
 
-** 注意：**1.6 之前的 Kubernetes 版本对于基于角色的访问控制（RBAC），要么有限制，或者不支持。
+** 注意：** 1.6 之前的 Kubernetes 版本对于基于角色的访问控制（RBAC），要么有限制，或者不支持。
 
 Helm 将通过 Kubernetes 配置文件（通常是 `$HOME/.kube/config`）来确定在哪里安装 Tiller 。这个配置文件也是 kubectl 使用的文件。
 
@@ -32,7 +32,7 @@ my-cluster
 如果群集启用了基于角色的访问控制（RBAC），在继续之前配置 [服务帐户 (service account) 和规则](rbac-zh_cn.md)。
 
 ## 安装 Helm
-下载 Helm 客户端的二进制版本。可以使用类似工具如 `homebrew`，或查看 [官方发布页面](https://github.com/kubernetes/helm/releases)。
+下载 Helm 客户端的二进制版本。可以使用类似工具如 `homebrew`，或查看 [官方发布页面](https://github.com/helm/helm/releases)。
 
 有关更多详细信息或其他选项，请参阅 [安装指南](install-zh_cn.md)。
 
@@ -57,8 +57,67 @@ $ helm init
 $ helm repo update               ＃确保我们获得最新的 chart 清单
 $ helm install stable/mysql
 Released smile-penguin
+NAME:   wintering-rodent
+LAST DEPLOYED: Thu Oct 18 14:21:18 2018
+NAMESPACE: default
+STATUS: DEPLOYED
+
+RESOURCES:
+==> v1/Secret
+NAME                    AGE
+wintering-rodent-mysql  0s
+
+==> v1/ConfigMap
+wintering-rodent-mysql-test  0s
+
+==> v1/PersistentVolumeClaim
+wintering-rodent-mysql  0s
+
+==> v1/Service
+wintering-rodent-mysql  0s
+
+==> v1beta1/Deployment
+wintering-rodent-mysql  0s
+
+==> v1/Pod(related)
+
+NAME                                    READY  STATUS   RESTARTS  AGE
+wintering-rodent-mysql-6986fd6fb-988x7  0/1    Pending  0         0s
+
+
+NOTES:
+MySQL can be accessed via port 3306 on the following DNS name from within your cluster:
+wintering-rodent-mysql.default.svc.cluster.local
+
+To get your root password run:
+
+    MYSQL_ROOT_PASSWORD=$(kubectl get secret --namespace default wintering-rodent-mysql -o jsonpath="{.data.mysql-root-password}" | base64 --decode; echo)
+
+To connect to your database:
+
+1. Run an Ubuntu pod that you can use as a client:
+
+    kubectl run -i --tty ubuntu --image=ubuntu:16.04 --restart=Never -- bash -il
+
+2. Install the mysql client:
+
+    $ apt-get update && apt-get install mysql-client -y
+
+3. Connect using the mysql cli, then provide your password:
+    $ mysql -h wintering-rodent-mysql -p
+
+To connect to your database directly from outside the K8s cluster:
+    MYSQL_HOST=127.0.0.1
+    MYSQL_PORT=3306
+
+    # Execute the following command to route the connection:
+    kubectl port-forward svc/wintering-rodent-mysql 3306
+
+    mysql -h ${MYSQL_HOST} -P${MYSQL_PORT} -u root -p${MYSQL_ROOT_PASSWORD}
+
+
 ```
-在上面的例子中，stable/mysql 已经安装，安装版本的 release 的名字是 smiling-penguin。通过运行 `helm inspect stable/mysql` 可以简单了解这个 MySQL chart 的功能。
+在上面的例子中，stable/mysql 已经安装，安装版本的 release 的名字是 `wintering-rodent`。通过运行 `helm inspect stable/mysql` 可以简单了解这个 MySQL chart 的功能。
 
 无论何时安装 chart，都会创建一个新 release 版本。所以一个 chart 可以多次安装到同一个群集中。而且每个都可以独立管理和升级。
 
@@ -70,8 +129,8 @@ Released smile-penguin
 
 ```bash
 $ helm ls
-NAME             VERSION   UPDATED                   STATUS    CHART
-smiling-penguin  1         Wed Sep 28 12:59:46 2016  DEPLOYED  mysql-0.1.0
++NAME            	REVISION	UPDATED                 	STATUS  	CHART       	APP VERSION	NAMESPACE
++wintering-rodent	1       	Thu Oct 18 15:06:58 2018	DEPLOYED	mysql-0.10.1	5.7.14     	default
 ```
 
 ## 卸载安装的 release
@@ -79,16 +138,48 @@ smiling-penguin  1         Wed Sep 28 12:59:46 2016  DEPLOYED  mysql-0.1.0
 要卸载安装的 release，请使用以下 `helm delete` 命令：
 
 ```bash
-$ helm delete smiling-penguin
-Removed smiling-penguin
+$ helm delete wintering-rodent
+release "wintering-rodent" deleted
 ```
 
-smiling-penguin release 将从 Kubernetes 卸载，但仍然可以查询有关该 release 的信息：
+`wintering-rodent` release 将从 Kubernetes 卸载，但仍然可以查询有关该 release 的信息：
 
 ```bash
-$ helm status smiling-penguin
-Status: DELETED
-...
+$ helm status wintering-rodent
+LAST DEPLOYED: Thu Oct 18 14:21:18 2018
+NAMESPACE: default
+STATUS: DELETED
+
+NOTES:
+MySQL can be accessed via port 3306 on the following DNS name from within your cluster:
+wintering-rodent-mysql.default.svc.cluster.local
+
+To get your root password run:
+
+    MYSQL_ROOT_PASSWORD=$(kubectl get secret --namespace default wintering-rodent-mysql -o jsonpath="{.data.mysql-root-password}" | base64 --decode; echo)
+
+To connect to your database:
+
+1. Run an Ubuntu pod that you can use as a client:
+
+    kubectl run -i --tty ubuntu --image=ubuntu:16.04 --restart=Never -- bash -il
+
+2. Install the mysql client:
+
+    $ apt-get update && apt-get install mysql-client -y
+
+3. Connect using the mysql cli, then provide your password:
+    $ mysql -h wintering-rodent-mysql -p
+
+To connect to your database directly from outside the K8s cluster:
+    MYSQL_HOST=127.0.0.1
+    MYSQL_PORT=3306
+
+    # Execute the following command to route the connection:
+    kubectl port-forward svc/wintering-rodent-mysql 3306
+
+    mysql -h ${MYSQL_HOST} -P${MYSQL_PORT} -u root -p${MYSQL_ROOT_PASSWORD}
+
 ```
 
 由于 Helm 在删除它们之后也会跟踪该 release，因此可以审核群集的历史记录，甚至可以取消删除动作（使用 `helm rollback`）。
diff --git a/quickstart/rbac-zh_cn.md b/quickstart/rbac-zh_cn.md
index 664b4c4..0db2070 100644
--- a/quickstart/rbac-zh_cn.md
+++ b/quickstart/rbac-zh_cn.md
@@ -31,7 +31,7 @@ metadata:
   name: tiller
   namespace: kube-system
 ---
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v11
 kind: ClusterRoleBinding
 metadata:
   name: tiller
@@ -69,12 +69,12 @@ serviceaccount "tiller" created
 
 ```yaml
 kind: Role
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v11
 metadata:
   name: tiller-manager
   namespace: tiller-world
 rules:
-- apiGroups: ["", "extensions", "apps"]
+- apiGroups: ["","extensions","apps"]
   resources: ["*"]
   verbs: ["*"]
 ```
@@ -88,7 +88,7 @@ role "tiller-manager" created
 
 ```yaml
 kind: RoleBinding
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v11
 metadata:
   name: tiller-binding
   namespace: tiller-world
@@ -145,12 +145,12 @@ serviceaccount "tiller" created
 
 ```yaml
 kind: Role
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v11
 metadata:
   name: tiller-manager
   namespace: myorg-users
 rules:
-- apiGroups: ["", "extensions", "apps"]
+- apiGroups: ["","extensions","apps"]
   resources: ["*"]
   verbs: ["*"]
 ```
@@ -164,7 +164,7 @@ role "tiller-manager" created
 
 ```yaml
 kind: RoleBinding
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v11
 metadata:
   name: tiller-binding
   namespace: myorg-users
@@ -186,12 +186,12 @@ rolebinding "tiller-binding" created
 
 ```yaml
 kind: Role
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v11
 metadata:
   namespace: myorg-system
   name: tiller-manager
 rules:
-- apiGroups: ["", "extensions", "apps"]
+- apiGroups: ["","extensions","apps"]
   resources: ["configmaps"]
   verbs: ["*"]
 ```
@@ -205,7 +205,7 @@ role "tiller-manager" created
 
 ```yaml
 kind: RoleBinding
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v11
 metadata:
   name: tiller-binding
   namespace: myorg-system
@@ -241,7 +241,7 @@ metadata:
   name: helm
   namespace: helm-world
 ---
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v11
 kind: Role
 metadata:
   name: tiller-user
@@ -260,7 +260,7 @@ rules:
   verbs:
   - list
 ---
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v11
 kind: RoleBinding
 metadata:
   name: tiller-user-binding
diff --git a/quickstart/securing_installation-zh_cn.md b/quickstart/securing_installation-zh_cn.md
index 21f9b3d..62913b4 100644
--- a/quickstart/securing_installation-zh_cn.md
+++ b/quickstart/securing_installation-zh_cn.md
@@ -30,7 +30,7 @@ helm init 将 Tiller 安装到 kube-system 名称空间中的集群中，而不
 4. Helm harts
 
 ### RBAC
-Kubernetes 的最新版本采用基于角色的访问控制（或 RBAC）系统（与现代操作系统一样），以帮助缓解证书被滥用或存在错误时可能造成的损害。即使在身份被劫持的情况下，这个身份在受控空间也只有这么多的权限。这有效地增加了一层安全性，以限制使用该身份进行攻击的范围。
+Kubernetes 的最新版本采用基于角色的访问控制（[RBAC] (https://en.wikipedia.org/wiki/Role-based_access_control) ）系统（与现代操作系统一样），以帮助缓解证书被滥用或存在错误时可能造成的损害。即使在身份被劫持的情况下，这个身份在受控空间也只有这么多的权限。这有效地增加了一层安全性，以限制使用该身份进行攻击的范围。
 
 Helm 和 Tiller 在安装，删除和修改逻辑应用程序时，可以包含许多服务交互。因此，它的使用通常涉及整个集群的操作，在多租户集群中意味着 Tiller 安装必须非常小心才能访问整个集群，以防止不正确的安全活动。
 
@@ -50,14 +50,14 @@ Helm 和 Tiller 在安装，删除和修改逻辑应用程序时，可以包含
 
 有关正确配置并使用 TLS 的 Tiller 和 Helm 的正确步骤的更多信息，请参阅 Helm 和 Tiller 使用 SSL[Using SSL between Helm and Tiller](tiller_ssl.md)。
 
-当 Helm 客户端从群集外部连接时，Helm 客户端和 API 服务器之间的安全性由 Kubernetes 本身管理。你可能需要确保这个链接是安全的。请注意，如果使用上面建议的 TLS 配置，则 Kubernetes API 服务器也无法访问客户端和 Tiller 之间的未加密消息。
+当 Helm 客户端从群集外部连接时，Helm 客户端和 API 服务器之间的安全性由 Kubernetes 本身管理。你可能需要确保这个链接是安全的。请注意，如果使用上面建议的 TLS 配置，则 Kubernetes API 服务器也无法访问客户端和 Tiller 之间的加密消息。
 
 ### Tiller Release 信息
 由于历史原因，Tiller 将其 release 信息存储在 ConfigMaps 中。我们建议将默认设置更改为 Secrets。
 
 Secrets 是 Kubernetes 用于保存被认为是敏感的配置数据的可接受的方法。尽管 secrets 本身并不提供很多保护，但 Kubernetes 集群管理软件经常将它们与其他对象区别开来。因此，我们建议使用 secrets 来存储 release 信息。
 
-启用此功能目前需要在 Tiller 部署时设置参数 `--storage=secret`。这需要直接修改 deployment 或使用 `helm init --override=...`，因为当前没有 helm init 参数可供执行此操作。有关更多信息，请参阅 [Using --override](install.md#using---override)。
+启用此功能目前需要在 Tiller 部署时设置参数 `--storage=secret`。这需要直接修改 deployment 或使用 `helm init --override 'spec.template.spec.containers[0].command'='{/tiller,--storage=secret}'`，因为当前没有 helm init 参数可供执行此操作。
 
 ### 关于 chart
 由于 Helm 的相对生命周期，Helm chart 生态系统的发展并没有考虑到整个集群的控制，这在开发人员来说，是完全合理的。但是，chart 是一种不仅可以安装可能已经验证或可能未验证的容器的包，它也可以安装到多个 namespace 中。
@@ -82,6 +82,7 @@ Secrets 是 Kubernetes 用于保存被认为是敏感的配置数据的可接受
 
 ```bash
 $ helm init \
+--override 'spec.template.spec.containers[0].command'='{/tiller,--storage=secret}' \
 --tiller-tls \
 --tiller-tls-verify \
 --tiller-tls-cert=cert.pem \
@@ -90,4 +91,4 @@ $ helm init \
 --service-account=accountname
 ```
 
-此命令将通过gRPC进行强身份验证，并应用RBAC策略的服务帐户安装启动Tiller。
+此命令将通过gRPC进行强身份验证，release信息存储在Kubernetes Secret，并使用RBAC策略的服务帐户安装启动Tiller。
diff --git a/quickstart/tiller_ssl-zh_cn.md b/quickstart/tiller_ssl-zh_cn.md
index 8c54582..ad8a203 100644
--- a/quickstart/tiller_ssl-zh_cn.md
+++ b/quickstart/tiller_ssl-zh_cn.md
@@ -238,7 +238,20 @@ $ cp helm.key.pem $(helm home)/key.pem
 
 * 如果我使用 `--tls-verify` 客户端，报错 `Error: x509: certificate is valid for tiller-server, not localhost`*
 
-如果打算 --tls-verify 在客户端上使用，则需要确保 Helm 连接的主机名与证书上的主机名匹配。在某些情况下，这很尴尬，因为 Helm 将通过本地主机连接，或者 FQDN 不可用于公共解析。
+如果打算 --tls-verify 在客户端上使用，则需要确保 Helm 连接的主机名与证书上的主机名匹配。在某些情况下，这很尴尬，因为 Helm 将通过本地主机 localhost 连接，或者 FQDN 不可用于公共解析。
+
+* 如果我在客户端使用 `--tls-verify` , 返回报错信息 `Error: x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANs`*
+
+
+默认情况下，Helm 客户端通过隧道（即 kube 代理）127.0.0.1 连接到 Tiller。 在 TLS 握手期间，通常提供主机名（例如 example.com），对证书进行检查，包括附带的信息。 但是，由于通过隧道，目标是 IP 地址。因此，要验证证书，必须在 Tiller 证书中将 IP 地址 127.0.0.1 列为 IP 附带备用名称（IP SAN： IP subject alternative name）。
+
+例如，要在生成 Tiller 证书时将 127.0.0.1 列为 IP SAN：
+
+```bash
+$ echo subjectAltName=IP:127.0.0.1 > extfile.cnf
+$ openssl x509 -req -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -in tiller.csr.pem -out tiller.cert.pem -days 365 -extfile extfile.cnf
+```
+
 
 * 如果我在客户端使用 `--tls-verify`，报错 `Error: x509: certificate has expired or is not yet valid`*
 
diff --git a/quickstart/using_helm-zh_cn.md b/quickstart/using_helm-zh_cn.md
index c6d0e0f..f3bfcc5 100644
--- a/quickstart/using_helm-zh_cn.md
+++ b/quickstart/using_helm-zh_cn.md
@@ -66,10 +66,10 @@ keywords:
 ```
 $ helm install stable/mariadb
 Fetched stable/mariadb-0.3.0 to /Users/mattbutcher/Code/Go/src/k8s.io/helm/mariadb-0.3.0.tgz
-happy-panda
-Last Deployed: Wed Sep 28 12:32:28 2016
-Namespace: default
-Status: DEPLOYED
+NAME: happy-panda
+LAST DEPLOYED: Wed Sep 28 12:32:28 2016
+NAMESPACE: default
+STATUS: DEPLOYED
 
 Resources:
 ==> extensions/Deployment
@@ -183,7 +183,7 @@ $ helm install -f config.yaml stable/mariadb
 在安装过程中有两种方式传递自定义配置数据：
 
 - --values（或 - f）：指定一个 overrides 的 YAML 文件。可以指定多次，最右边的文件将优先使用
-- --set：在命令行上指定 overrides。
+- --set  (也包括 `--set-string` 和 `--set-file`): ：在命令行上指定 overrides。
 
 如果两者都使用，则将 `--set` 值合并到 `--values` 更高的优先级中。指定的 override `--set` 将保存在 configmap 中。`--set` 可以通过使用特定的版本查看已经存在的值 `helm get values <release-name>`,`--set` 设置的值可以通过运行 helm upgrade 带有 --reset-values 参数重置。
 
@@ -233,7 +233,7 @@ servers:
     host: example
 ```
 
-有时候你需要在 `--set` 行中使用特殊字符。可以使用反斜杠来转义字符; --set name="value1\,value2" 会变成：
+有时候你需要在 `--set` 行中使用特殊字符。可以使用反斜杠来转义字符; `--set name="value1\,value2"` 会变成：
 
 ```yaml
 name: "value1,value2"
@@ -248,6 +248,29 @@ nodeSelector:
 
 使用深层嵌套的数据结构可能很难用 `--set` 表达。鼓励 chart 设计师在设计 values.yaml 文件格式时考虑 `--set` 使用情况。
 
+Helm 会使用 `--set` 将指定的某些值转换为整数。例如，`--set foo = true`Helm 会将 `true` 强制转换为 int64 值。如果你想要一个字符串，请使用 `--set` 的变体名为 `--set-string`。 `--set-string foo = true` 会设置字符串值为 `"true"`。
+
+`--set-file key = filepath` 是 `--set` 的另一种变体。 它读取文件并将其内容用作值。 它的一个示例用例是将多行文本注入值而不处理 YAML 中的缩进。 假设您要创建一个 [brigade](https://github.com/Azure/brigade) 项目，其中包含包含 5 行 JavaScript 代码的特定值，您可以编写一个 `values.yaml`，如：
+
+```yaml
+defaultScript: |
+  const {events, Job} = require("brigadier")
+  function run(e, project) {
+    console.log("hello default script")
+  }
+  events.on("run", run)
+```
+
+嵌入在 YAML 中，这使你更难以使用支持编写代码的 IDE 功能和测试框架等。 因此，你可以使用 `-set-file defaultScript = brigade.js` 替代，`brigade.js` 包含：
+
+```javascript
+const {events, Job} = require("brigadier")
+function run(e, project) {
+  console.log("hello default script")
+}
+events.on("run", run)
+```
+
 ### 更多的安装方法
 helm install 命令可以从多个来源安装：
 
diff --git a/related-zh_cn.md b/related-zh_cn.md
index b9c6f7e..95e26f5 100644
--- a/related-zh_cn.md
+++ b/related-zh_cn.md
@@ -3,45 +3,56 @@ Helm 社区已经制作了许多关于 Helm 的额外工具，插件和文档。
 或 [pull request](https://github.com/kubernetes/helm/pulls)。
 
 ## 文章，博客，操作方法和额外文档
-- [Using Helm to Deploy to Kubernetes](https://daemonza.github.io/2017/02/20/using-helm-to-deploy-to-kubernetes/)
-- [Honestbee's Helm Chart Conventions](https://gist.github.com/so0k/f927a4b60003cedd101a0911757c605a)
+- [Awesome Helm](https://github.com/cdwv/awesome-helm) - List of awesome Helm resources
+- [CI/CD with Kubernetes, Helm & Wercker](http://www.slideshare.net/Diacode/cicd-with-kubernetes-helm-wercker-madscalability)
+- [Creating a Helm Plugin in 3 Steps](http://technosophos.com/2017/03/21/creating-a-helm-plugin.html)
+- [Awesome Helm](https://github.com/cdwv/awesome-helm) - List of awesome Helm resources
 - [Deploying Kubernetes Applications with Helm](http://cloudacademy.com/blog/deploying-kubernetes-applications-with-helm/)
-- [Releasing backward-incompatible changes: Kubernetes, Jenkins, Prometheus Operator, Helm and Traefik](https://medium.com/@enxebre/releasing-backward-incompatible-changes-kubernetes-jenkins-plugin-prometheus-operator-helm-self-6263ca61a1b1#.e0c7elxhq)
-- [CI/CD with Kubernetes, Helm & Wercker ](http://www.slideshare.net/Diacode/cicd-with-kubernetes-helm-wercker-madscalability)
-- [The missing CI/CD Kubernetes component: Helm package manager](https://hackernoon.com/the-missing-ci-cd-kubernetes-component-helm-package-manager-1fe002aac680#.691sk2zhu)
-- [The Workflow "Umbrella" Helm Chart](https://deis.com/blog/2017/workflow-chart-assembly)
 - [GitLab, Consumer Driven Contracts, Helm and Kubernetes](https://medium.com/@enxebre/gitlab-consumer-driven-contracts-helm-and-kubernetes-b7235a60a1cb#.xwp1y4tgi)
+- [Honestbee's Helm Chart Conventions](https://gist.github.com/so0k/f927a4b60003cedd101a0911757c605a)
+- [Releasing backward-incompatible changes: Kubernetes, Jenkins, Prometheus Operator, Helm and Traefik](https://medium.com/@enxebre/releasing-backward-incompatible-changes-kubernetes-jenkins-plugin-prometheus-operator-helm-self-6263ca61a1b1#.e0c7elxhq)
+- [The Missing CI/CD Kubernetes Component: Helm package manager](https://hackernoon.com/the-missing-ci-cd-kubernetes-component-helm-package-manager-1fe002aac680#.691sk2zhu)
+- [Using Helm to Deploy to Kubernetes](https://daemonza.github.io/2017/02/20/using-helm-to-deploy-to-kubernetes/)
 - [Writing a Helm Chart](https://www.influxdata.com/packaged-kubernetes-deployments-writing-helm-chart/)
-- [Creating a Helm Plugin in 3 Steps](http://technosophos.com/2017/03/21/creating-a-helm-plugin.html)
+- [A basic walk through Kubernetes Helm](https://github.com/muffin87/helm-tutorial)
+- [Tillerless Helm v2](https://rimusz.net/tillerless-helm/)
 
 ## 视频, 音频, and Podcast
 
 - [CI/CD with Jenkins, Kubernetes, and Helm](https://www.youtube.com/watch?v=NVoln4HdZOY): AKA "The Infamous Croc Hunter Video".
-- [KubeCon2016: Delivering Kubernetes-Native Applications by Michelle Noorali](https://www.youtube.com/watch?v=zBc1goRfk3k&index=49&list=PLj6h78yzYM2PqgIGU1Qmi8nY7dqn9PCr4)
 - [Helm with Michelle Noorali and Matthew Butcher](https://gcppodcast.com/post/episode-50-helm-with-michelle-noorali-and-matthew-butcher/): The official Google CloudPlatform Podcast interviews Michelle and Matt about Helm.
+- [KubeCon2016: Delivering Kubernetes-Native Applications by Michelle Noorali](https://www.youtube.com/watch?v=zBc1goRfk3k&index=49&list=PLj6h78yzYM2PqgIGU1Qmi8nY7dqn9PCr4)
 
 
 ## Helm 插件
 
-- [helm-tiller](https://github.com/adamreese/helm-tiller) - Additional commands to work with Tiller
-- [Technosophos's Helm Plugins](https://github.com/technosophos/helm-plugins) - Plugins for GitHub, Keybase, and GPG
-- [helm-template](https://github.com/technosophos/helm-template) - Debug/render templates client-side
-- [Helm Value Store](https://github.com/skuid/helm-value-store) - Plugin for working with Helm deployment values
-- [Helm Diff](https://github.com/databus23/helm-diff) - Preview `helm upgrade` as a coloured diff
-- [helm-env](https://github.com/adamreese/helm-env) - Plugin to show current environment
-- [helm-last](https://github.com/adamreese/helm-last) - Plugin to show the latest release
-- [helm-nuke](https://github.com/adamreese/helm-nuke) - Plugin to destroy all releases
-- [helm-local](https://github.com/adamreese/helm-local) - Plugin to run Tiller as a local daemon
 - [App Registry](https://github.com/app-registry/helm-plugin) - Plugin to manage charts via the [App Registry specification](https://github.com/app-registry/spec)
-- [helm-secrets](https://github.com/futuresimple/helm-secrets) - Plugin to manage and store secrets safely
+- [helm-backup](https://github.com/maorfr/helm-backup) - Plugin which performs backup/restore of releases in a namespace to/from a file
+- [Helm Diff](https://github.com/databus23/helm-diff) - Preview `helm upgrade` as a coloured diff
+- [Helm Value Store](https://github.com/skuid/helm-value-store) - Plugin for working with Helm deployment values
+- [Technosophos's Helm Plugins](https://github.com/technosophos/helm-plugins) - Plugins for GitHub, Keybase, and GPG
+- [helm-convert](https://github.com/ContainerSolutions/helm-convert) - Plugin to convert charts into Kustomize compatible packages
+- [helm-cos](https://github.com/imroc/helm-cos) - Plugin to manage repositories on Tencent Cloud Object Storage
 - [helm-edit](https://github.com/mstrzele/helm-edit) - Plugin for editing release's values
+- [helm-env](https://github.com/adamreese/helm-env) - Plugin to show current environment
 - [helm-gcs](https://github.com/nouney/helm-gcs) - Plugin to manage repositories on Google Cloud Storage
 - [helm-github](https://github.com/sagansystems/helm-github) - Plugin to install Helm Charts from Github repositories
-- [helm-monitor](https://github.com/ContainerSolutions/helm-monitor) - Plugin to monitor a release and rollback based on Prometheus/ElasticSearch query
-- [helm-k8comp](https://github.com/cststack/k8comp) - Plugin to create Helm Charts from hiera using k8comp
 - [helm-hashtag](https://github.com/balboah/helm-hashtag) - Plugin for tracking docker tag hash digests as values
+- [helm-inject](https://github.com/maorfr/helm-inject) - Plugin for injecting additional configurations during release upgrade
+- [helm-k8comp](https://github.com/cststack/k8comp) - Plugin to create Helm Charts from hiera using k8comp
+- [helm-last](https://github.com/adamreese/helm-last) - Plugin to show the latest release
+- [helm-local](https://github.com/adamreese/helm-local) - Plugin to run Tiller as a local daemon
+- [helm-logs](https://github.com/maorfr/helm-logs) - Plugin to view changed releases over time
+- [helm-monitor](https://github.com/ContainerSolutions/helm-monitor) - Plugin to monitor a release and rollback based on Prometheus/ElasticSearch query
+- [helm-nuke](https://github.com/adamreese/helm-nuke) - Plugin to destroy all releases
+- [helm-plugin-utils](https://github.com/maorfr/helm-plugin-utils) - Utility functions to be used within Helm plugins
+- [helm-restore](https://github.com/maorfr/helm-restore) - Plugin to restore a deployed release to its original state
+- [helm-secrets](https://github.com/futuresimple/helm-secrets) - Plugin to manage and store secrets safely
+- [helm-stop](https://github.com/IBM/helm-stop) - Plugin for stopping a release pods
+- [helm-template](https://github.com/technosophos/helm-template) - Debug/render templates client-side
+- [helm-tiller](https://github.com/adamreese/helm-tiller) - Additional commands to work with Tiller
 - [helm-unittest](https://github.com/lrills/helm-unittest) - Plugin for unit testing chart locally with YAML
-
+- [Tillerless Helm v2](https://github.com/rimusz/helm-tiller) - Helm plugin for using Tiller locally and in CI/CD pipelines
 We also encourage GitHub authors to use the [helm-plugin](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories)
 tag on their plugin repositories.
 
@@ -51,33 +62,34 @@ tag on their plugin repositories.
 分布在 Helm 或 Tiller 之上的工具。
 
 - [AppsCode Swift](https://github.com/appscode/swift) - Ajax friendly Helm Tiller Proxy using [grpc-gateway](https://github.com/grpc-ecosystem/grpc-gateway)
-- [Quay App Registry](https://coreos.com/blog/quay-application-registry-for-kubernetes.html) - Open Kubernetes application registry, including a Helm access client
-- [Chartify](https://github.com/appscode/chartify) - Generate Helm charts from existing Kubernetes resources.
-- [VIM-Kubernetes](https://github.com/andrewstuart/vim-kubernetes) - VIM plugin for Kubernetes and Helm
-- [Landscaper](https://github.com/Eneco/landscaper/) - "Landscaper takes a set of Helm Chart references with values (a desired state), and realizes this in a Kubernetes cluster."
-- [Rudder](https://github.com/AcalephStorage/rudder) - RESTful (JSON) proxy for Tiller's API
-- [Helmfile](https://github.com/roboll/helmfile) - Helmfile is a declarative spec for deploying helm charts
+- [Armada](https://github.com/att-comdev/armada) - Manage prefixed releases throughout various Kubernetes namespaces, and removes completed jobs for complex deployments. Used by the [Openstack-Helm](https://github.com/openstack/openstack-helm) team.
 - [Autohelm](https://github.com/reactiveops/autohelm) - Autohelm is _another_ simple declarative spec for deploying helm charts. Written in python and supports git urls as a source for helm charts.
-- [Helmsman](https://github.com/Praqma/helmsman) - Helmsman is a helm-charts-as-code tool which enables installing/upgrading/protecting/moving/deleting releases from version controlled desired state files (described in a simple TOML format).
-- [Schelm](https://github.com/databus23/schelm) - Render a Helm manifest to a directory
-- [Drone.io Helm Plugin](http://plugins.drone.io/ipedrazas/drone-helm/) - Run Helm inside of the Drone CI/CD system
+- [ChartMuseum](https://github.com/chartmuseum/chartmuseum) - Helm Chart Repository with support for Amazon S3 and Google Cloud Storage
+- [Chartify](https://github.com/appscode/chartify) - Generate Helm charts from existing Kubernetes resources.
+- [Codefresh](https://codefresh.io) - Kubernetes native CI/CD and management platform with UI dashboards for managing Helm charts and releases
 - [Cog](https://github.com/ohaiwalt/cog-helm) - Helm chart to deploy Cog on Kubernetes
-- [Monocular](https://github.com/helm/monocular) - Web UI for Helm Chart repositories
+- [Drone.io Helm Plugin](http://plugins.drone.io/ipedrazas/drone-helm/) - Run Helm inside of the Drone CI/CD system
 - [Helm Chart Publisher](https://github.com/luizbafilho/helm-chart-publisher) - HTTP API for publishing Helm Charts in an easy way
-- [Armada](https://github.com/att-comdev/armada) - Manage prefixed releases throughout various Kubernetes namespaces, and removes completed jobs for complex deployments. Used by the [Openstack-Helm](https://github.com/openstack/openstack-helm) team.
-- [ChartMuseum](https://github.com/chartmuseum/chartmuseum) - Helm Chart Repository with support for Amazon S3 and Google Cloud Storage
 - [Helm.NET](https://github.com/qmfrederik/helm) - A .NET client for Tiller's API
-- [Codefresh](https://codefresh.io) - Kubernetes native CI/CD and management platform with UI dashboards for managing Helm charts and releases
+- [Helmfile](https://github.com/roboll/helmfile) - Helmfile is a declarative spec for deploying helm charts
+- [Helmsman](https://github.com/Praqma/helmsman) - Helmsman is a helm-charts-as-code tool which enables installing/upgrading/protecting/moving/deleting releases from version controlled desired state files (described in a simple TOML format).
+- [Landscaper](https://github.com/Eneco/landscaper/) - "Landscaper takes a set of Helm Chart references with values (a desired state), and realizes this in a Kubernetes cluster."
+- [Monocular](https://github.com/helm/monocular) - Web UI for Helm Chart repositories
+- [Orca](https://github.com/maorfr/orca) - Advanced CI\CD tool for Kubernetes and Helm made simple.
+- [Quay App Registry](https://coreos.com/blog/quay-application-registry-for-kubernetes.html) - Open Kubernetes application registry, including a Helm access client
+- [Rudder](https://github.com/AcalephStorage/rudder) - RESTful (JSON) proxy for Tiller's API
+- [Schelm](https://github.com/databus23/schelm) - Render a Helm manifest to a directory
+- [VIM-Kubernetes](https://github.com/andrewstuart/vim-kubernetes) - VIM plugin for Kubernetes and Helm
 
 ## 集成 Helm
 
 包含 Helm 支持的平台，发行版和服务。
 
-- [Kubernetic](https://kubernetic.com/) - Kubernetes Desktop Client
 - [Cabin](http://www.skippbox.com/cabin/) - Mobile App for Managing Kubernetes
-- [Qstack](https://qstack.com)
 - [Fabric8](https://fabric8.io) - Integrated development platform for Kubernetes
 - [Jenkins X](http://jenkins-x.io/) - open source automated CI/CD for Kubernetes which uses Helm for [promoting](http://jenkins-x.io/about/features/#promotion) applications through [environments via GitOps](http://jenkins-x.io/about/features/#environments)
+- [Kubernetic](https://kubernetic.com/) - Kubernetes Desktop Client
+- [Qstack](https://qstack.com)
 
 ## 杂项
 

From 629e9ea0c6e88727def6ea28c9330963071367fd Mon Sep 17 00:00:00 2001
From: unknown <whmzsu@gmail.com>
Date: Sat, 24 Nov 2018 00:15:34 +0800
Subject: [PATCH 2/3] update with upstream

---
 ._cover.jpg                          | Bin 233 -> 0 bytes
 chart_best_practices/labels-zh_cn.md |   2 +-
 quickstart/install-zh_cn.md          |   5 +++++
 3 files changed, 6 insertions(+), 1 deletion(-)
 delete mode 100644 ._cover.jpg

diff --git a/._cover.jpg b/._cover.jpg
deleted file mode 100644
index b4385de0b4e2008bb3b0d6a813209c1083daacbe..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 233
zcmZQz6=P>$Vqox1Ojhs@R)|o50+1L3ClDI}@pd2v@m~Tl5x_AdBnYYuq~ib(YeM-j
z3S`;=AQoU?kV?+a)k`cW$Vt`9Nh~fYEly2INi0cK4hV)Sz5t{p85l$n>IzE}ixTrn
tGV@Xy*0cFVgVZfq7NrQH3-t{QER3v8lT1<#%*>Ll1Bz11GE>W~831cPCGY?M

diff --git a/chart_best_practices/labels-zh_cn.md b/chart_best_practices/labels-zh_cn.md
index ef1ffd3..c25b986 100644
--- a/chart_best_practices/labels-zh_cn.md
+++ b/chart_best_practices/labels-zh_cn.md
@@ -19,7 +19,7 @@ Helm hook 总是注释。
 名称 | 状态 | 描述
 -----|------|----------
 `app.kubernetes.io/name` | REC | This should be the app name, reflecting the entire app. Usually \{\{template "name" .\}\} is used for this. This is used by many Kubernetes manifests, and is not Helm-specific.
-`helm.sh/chart` | REC | This should be the chart name and version: \{\{.Chart.Name\}\}-\{\{ .Chart.Version \\| replace "+" "_" \}\}.
+`helm.sh/chart` | REC | This should be the chart name and version: \{\{.Chart.Name\}\}-\{\{ .Chart.Version \| replace "+" "_" \}\}.
 `app.kubernetes.io/managed-by` | REC | This should always be set to \{\{.Release.Service\}\}. It is for finding all things managed by Tiller.
 `app.kubernetes.io/instance` | REC | This should be the \{\{.Release.Name\}\}. It aid in differentiating between different instances of the same application.
 `app.kubernetes.io/version` | OPT | The version of the app and can be set to \{\{.Chart.AppVersion\}\}.
diff --git a/quickstart/install-zh_cn.md b/quickstart/install-zh_cn.md
index 84a67df..77de70d 100644
--- a/quickstart/install-zh_cn.md
+++ b/quickstart/install-zh_cn.md
@@ -93,6 +93,11 @@ $ make bootstrap build
 
 Helm 的服务器端部分 Tiller 通常运行在 Kubernetes 集群内部。但是对于开发，它也可以在本地运行，并配置为与远程 Kubernetes 群集通信。
 
+### Special Note for RBAC Users
+
+Most cloud providers enable a feature called Role-Based Access Control - RBAC for short. If your cloud provider enables this feature, you will need to create a service account for Tiller with the right roles and permissions to access resources.
+Check the [Kubernetes Distribution Guide](kubernetes_distros-zh_cn.md) to see if there's any further points of interest on using Helm with your cloud provider. Also check out the guide on [Tiller and Role-Based Access Control](rbac-zh_cn.md) for more information on how to run Tiller in an RBAC-enabled Kubernetes cluster.
+
 ### 快捷群集内安装
 
 安装 `tiller` 到群集中最简单的方法就是运行 `helm init`。这将验证 `helm` 本地环境设置是否正确（并在必要时进行设置）。然后它会连接到 `kubectl` 默认连接的任何集群（`kubectl config view`）。一旦连接，它将安装 `tiller` 到 `kube-system` 命名空间中。

From 20899c54c5aed7dbe3a16e6e76fb1893cd85e5d8 Mon Sep 17 00:00:00 2001
From: unknown <whmzsu@gmail.com>
Date: Sat, 24 Nov 2018 10:26:01 +0800
Subject: [PATCH 3/3] update with upstream

---
 chart/chart_repository-zh_cn.md               |  6 +-
 chart/charts-zh_cn.md                         |  2 +-
 chart/charts_tips_and_tricks-zh_cn.md         | 14 ++---
 chart_best_practices/templates-zh_cn.md       | 59 +++++++++++++++----
 chart_template_guide/accessing_files-zh_cn.md |  4 +-
 .../control_structures-zh_cn.md               |  2 +-
 .../subcharts_and_globals-zh_cn.md            | 20 +++----
 chart_template_guide/wrapping_up-zh_cn.md     |  2 +-
 quickstart/install-zh_cn.md                   |  6 +-
 quickstart/securing_installation-zh_cn.md     | 18 +++++-
 quickstart/using_helm-zh_cn.md                |  6 +-
 11 files changed, 93 insertions(+), 46 deletions(-)

diff --git a/chart/chart_repository-zh_cn.md b/chart/chart_repository-zh_cn.md
index 826827b..0798a1c 100644
--- a/chart/chart_repository-zh_cn.md
+++ b/chart/chart_repository-zh_cn.md
@@ -2,7 +2,7 @@
 
 本节介绍如何创建和使用 Helm chart repo。在高层次上，chart 库是可以存储和共享打包 chart 的位置。
 
-官方 chart 库由 [Kubernetes Charts](https://github.com/kubernetes/charts) 维护 ，我们欢迎参与贡献。Helm 还可以轻松创建和运行自己的 chart 库。本指南讲解了如何做到这一点。
+官方 chart 库由 [Helm Charts](https://github.com/helm/charts) 维护 ，我们欢迎参与贡献。Helm 还可以轻松创建和运行自己的 chart 库。本指南讲解了如何做到这一点。
 
 ## 前提条件
 
@@ -73,7 +73,7 @@ entries:
       home: https://k8s.io/helm
       name: nginx
       sources:
-      - https://github.com/kubernetes/charts
+      - https://github.com/helm/charts
       urls:
       - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz
       version: 1.1.0
@@ -116,7 +116,7 @@ Now serving you on 127.0.0.1:8879
 
 恭喜，现在你有一个空的 GCS bucket 准备好给 chart 提供服务！
 
-可以使用 Google Cloud Storage 命令行工具或使用 GCS Web UI 上传 chart 库。这是官方 Kubernetes Charts 存储库托管其 chart 的技术，因此如果遇到困难，可能需要查看该项目 [peek at that project](https://github.com/kubernetes/charts) 。
+可以使用 Google Cloud Storage 命令行工具或使用 GCS Web UI 上传 chart 库。这是官方 Kubernetes Charts 存储库托管其 chart 的技术，因此如果遇到困难，可能需要查看该项目 [peek at that project](https://github.com/helm/charts) 。
 
 ** 注意：** 可以通过此处的 HTTPS 地址方便的访问公开的 GCS 存储桶 `https://bucket-name.storage.googleapis.com/`。
 
diff --git a/chart/charts-zh_cn.md b/chart/charts-zh_cn.md
index f9e846a..81aa74c 100644
--- a/chart/charts-zh_cn.md
+++ b/chart/charts-zh_cn.md
@@ -77,7 +77,7 @@ nginx-1.2.3.tgz
 
 ### 弃用 charts
 
-在管理 chart tepo 库中的 chart 时，有时需要弃用 chart。`Chart.yaml` 的 d`eprecated` 字段可用于将 chart 标记为已弃用。如果存储库中最新版本的 chart 标记为已弃用，则整个 chart 被视为已弃用。chart 名称稍后可以通过发布未标记为已弃用的较新版本来重新使用。废弃 chart 的工作流程根据 [kubernetes/charts](https://github.com/kubernetes/charts) 项目的工作流程如下：
+在管理 chart tepo 库中的 chart 时，有时需要弃用 chart。`Chart.yaml` 的 d`eprecated` 字段可用于将 chart 标记为已弃用。如果存储库中最新版本的 chart 标记为已弃用，则整个 chart 被视为已弃用。chart 名称稍后可以通过发布未标记为已弃用的较新版本来重新使用。废弃 chart 的工作流程根据 [helm/charts](https://github.com/helm/charts) 项目的工作流程如下：
 
 -   更新 chart 的 `Chart.yaml` 以将 chart 标记为启用，并且更新版本
 -   在 chart Repository 中发布新的 chart 版本
diff --git a/chart/charts_tips_and_tricks-zh_cn.md b/chart/charts_tips_and_tricks-zh_cn.md
index 465bd74..c42fa1f 100644
--- a/chart/charts_tips_and_tricks-zh_cn.md
+++ b/chart/charts_tips_and_tricks-zh_cn.md
@@ -27,19 +27,19 @@ value: {{required "A valid .Values.who entry required!" .Values.who}}
 
 当使用字符串数据时，引用字符串比把它们留为空白字符更安全：
 
-```
+```yaml
 name: {{.Values.MyName | quote}}
 ```
 
 但是，使用整数时 _不要引用值_。在很多情况下，这可能会导致 Kubernetes 内部的解析错误。
 
-```
+```yaml
 port: {{.Values.Port}}
 ```
 
 这种做法不适用于预期为字符串的 env 变量值，即使它们表示为整数：
 
-```
+```yaml
 env:
   -name: HOST
     value: "http://host"
@@ -54,7 +54,7 @@ Go 提供了一种使用内置 `template` 指令将一个模板包含在另一
 为了能够包含模板，然后对该模板的输出执行操作，Helm 有一个特殊的 `include` 函数：
 
 ```
-{{include "toYaml" $value | indent 2}}
+{{- include "toYaml" $value | nindent 2}}
 ```
 
 上面包含一个名为的模板 toYaml，传递它 $value 的值，然后将该模板的输出传递给该 indent 函数。
@@ -119,7 +119,7 @@ lastName=Parker
 
 首先，假设凭证在 `values.yaml` 文件中定义如下：
 
-```
+```yaml
 imageCredentials:
   registry: quay.io
   username: someone
@@ -134,7 +134,7 @@ imageCredentials:
 ```
 最后，我们在更大的模板中使用助手模板来创建 Secret manifest：
 
-```
+```yaml
 apiVersion: v1
 kind: Secret
 metadata:
@@ -186,7 +186,7 @@ metadata:
 
 ## 具有许多依赖关系的复杂 chart
 
-官方 chart repo 存储库 [official charts repository](https://github.com/kubernetes/charts) 中的许多 chart 是用于创建更高级应用程序的 “构建块”。chart 可能用于创建大规模应用程序的实例。在这种情况下，一张伞形 chart 可能有多个子 chart，每个子 chart 都是整体的一部分。
+官方 chart repo 存储库 [official charts repository](https://github.com/helm/charts) 中的许多 chart 是用于创建更高级应用程序的 “构建块”。chart 可能用于创建大规模应用程序的实例。在这种情况下，一张伞形 chart 可能有多个子 chart，每个子 chart 都是整体的一部分。
 
 当前最佳做法是：从各个子 chart 组成复杂应用程序，创建公开全局配置的顶层伞形 chart，然后使用 charts / 子目录嵌入每个组件 chart。
 
diff --git a/chart_best_practices/templates-zh_cn.md b/chart_best_practices/templates-zh_cn.md
index 226d3eb..3e40f18 100644
--- a/chart_best_practices/templates-zh_cn.md
+++ b/chart_best_practices/templates-zh_cn.md
@@ -19,9 +19,9 @@ templates 目目录的结构应如下所示：
 正确：
 
 ```yaml
-{{- define "nginx.fullname" }}
+{{- define "nginx.fullname"}}
 {{/* ... */}}
-{{ end -}}
+{{end -}}
 ```
 
 不正确：
@@ -29,7 +29,7 @@ templates 目目录的结构应如下所示：
 ```yaml
 {{- define "fullname" -}}
 {{/* ... */}}
-{{ end -}}
+{{end -}}
 ```
 
 强烈建议通过 `helm create` 命令创建新 chart，因为根据此最佳做法自动定义模板名称。
@@ -43,8 +43,8 @@ templates 目目录的结构应如下所示：
 正确：
 
 ```
-{{ .foo }}
-{{ print "foo" }}
+{{.foo}}
+{{print "foo"}}
 {{- print "bar" -}}
 ```
 
@@ -60,16 +60,16 @@ templates 目目录的结构应如下所示：
 
 ```
 foo:
-  {{- range .Values.items }}
-  {{ . }}
-  {{ end -}}
+  {{- range .Values.items}}
+  {{.}}
+  {{end -}}
 ```
 
 块（如控制结构）可以缩进以指示模板代码的流向。
 
 ```
-{{ if $foo -}}
-  {{- with .Bar }}Hello{{ end -}}
+{{if $foo -}}
+  {{- with .Bar}}Hello{{ end -}}
 {{- end -}}
 ```
 
@@ -125,6 +125,39 @@ metadata:
     second: second
 
 ```
+## Resource Naming in Templates
+
+将 `name:` 硬编码到资源中通常被认为是不好的做法。名称对于 release 应该是唯一的。因此，我们可能希望通过插入 release 名称来生成 name 字段，例如：
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: {{.Release.Name}}-myservice
+```
+
+Or if there is only one resource of this kind then we could use .Release.Name or the template fullname function defined in \_helpers.tpl (which uses release name):
+
+或者，如果只有一个此类资源，那么可以使用 .Release.Name 或 \_helpers.tpl（使用 release 名称）中定义的模板 fullname 函数：
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: {{template "fullname" .}}
+```
+尽快如此，可能还存在不会来自固定名称的命名冲突的情况。在这些情况下，固定名称可能使应用程序更容易找到诸如服务之类的资源。如果需要固定名称，那么一种可能的管理方法是通过使用 values.yaml 中的 service.name 值来显式设置名称（如果提供的话）:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  {{- if .Values.service.name}}
+    name: {{.Values.service.name}}
+  {{- else}}
+    name: {{template "fullname" .}}
+  {{- end}}
+```
 
 ## 注释（YAML 注释与模板注释）
 YAML 和头盔模板都有注释标记。
@@ -151,8 +184,8 @@ type: frobnitz
 {{- /*
 mychart.shortname provides a 6 char truncated version of the release name.
 */ -}}
-{{ define "mychart.shortname" -}}
-{{ .Release.Name | trunc 6 }}
+{{define "mychart.shortname" -}}
+{{.Release.Name | trunc 6}}
 {{- end -}}
 
 ```
@@ -161,7 +194,7 @@ mychart.shortname provides a 6 char truncated version of the release name.
 
 ```
 # This may cause problems if the value is more than 100Gi
-memory: {{ .Values.maxMem | quote }}
+memory: {{.Values.maxMem | quote}}
 ```
 
 上面的注释在用户运行 `helm install --debug` 时可见，而在 `{{- /* */ -}}` 部分中指定的注释不是。
diff --git a/chart_template_guide/accessing_files-zh_cn.md b/chart_template_guide/accessing_files-zh_cn.md
index c461dfb..c8ed4b1 100644
--- a/chart_template_guide/accessing_files-zh_cn.md
+++ b/chart_template_guide/accessing_files-zh_cn.md
@@ -142,7 +142,7 @@ kind: ConfigMap
 metadata:
   name: conf
 data:
-{{(.Files.Glob "foo/*").AsConfig | indent 2 }}
+  {{- (.Files.Glob "foo/*").AsConfig | nindent 2 }}
 ---
 apiVersion: v1
 kind: Secret
@@ -150,7 +150,7 @@ metadata:
   name: very-secret
 type: Opaque
 data:
-{{(.Files.Glob "bar/*").AsSecrets | indent 2 }}
+  {{(.Files.Glob "bar/*").AsSecrets | nindent 2 }}
 ```
 
 ## 编码
diff --git a/chart_template_guide/control_structures-zh_cn.md b/chart_template_guide/control_structures-zh_cn.md
index dd772d6..d4acd78 100644
--- a/chart_template_guide/control_structures-zh_cn.md
+++ b/chart_template_guide/control_structures-zh_cn.md
@@ -52,7 +52,7 @@ data:
   myvalue: "Hello World"
   drink: {{.Values.favorite.drink | default "tea" | quote}}
   food: {{.Values.favorite.food | upper | quote}}
-  {{if (.Values.favorite.drink) and eq .Values.favorite.drink "coffee" }}mug: true{{ end }}
+  {{if and (.Values.favorite.drink) (eq .Values.favorite.drink "coffee") }}mug: true{{ end }}
 
 ```
 注意 `.Values.favorite.drink` 必须已定义，否则在将它与 “coffee” 进行比较时会抛出错误。由于我们在上一个例子中注释掉了 `drink：coffee`，因此输出不应该包含 `mug：true` 标志。但是如果我们将该行添加回 `values.yaml` 文件中，输出应该如下所示:
diff --git a/chart_template_guide/subcharts_and_globals-zh_cn.md b/chart_template_guide/subcharts_and_globals-zh_cn.md
index be6e1bf..5ecae78 100644
--- a/chart_template_guide/subcharts_and_globals-zh_cn.md
+++ b/chart_template_guide/subcharts_and_globals-zh_cn.md
@@ -41,9 +41,9 @@ dessert: cake
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: {{ .Release.Name }}-cfgmap2
+  name: {{.Release.Name}}-cfgmap2
 data:
-  dessert: {{ .Values.dessert }}
+  dessert: {{.Values.dessert}}
 ```
 
 由于每个子 chart 都是独立的 chart，因此我们可以给 mysubchart 自行测试：
@@ -127,7 +127,7 @@ global:
   salad: caesar
 ```
 
-因为这样全局值的使用方法，`mychart/templates/configmap.yaml` 和 `mysubchart/templates/configmap.yaml` 都能够访问该值 `{{.Values.global.salad}}`。
+因为这样全局值的使用方法，`mychart/templates/configmap.yaml` 和 `mychart/charts/mysubchart/templates/configmap.yaml` 都能够访问该值 `{{.Values.global.salad}}`。
 
 `mychart/templates/configmap.yaml`：
 
@@ -135,9 +135,9 @@ global:
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: {{ .Release.Name }}-configmap
+  name: {{.Release.Name}}-configmap
 data:
-  salad: {{ .Values.global.salad }}
+  salad: {{.Values.global.salad}}
 ```
 
 `mysubchart/templates/configmap.yaml`：
@@ -146,10 +146,10 @@ data:
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: {{ .Release.Name }}-cfgmap2
+  name: {{.Release.Name}}-cfgmap2
 data:
-  dessert: {{ .Values.dessert }}
-  salad: {{ .Values.global.salad }}
+  dessert: {{.Values.dessert}}
+  salad: {{.Values.global.salad}}
 ```
 
 现在，如果我们运行 dry run，我们会在两个输出中看到相同的值：
@@ -184,7 +184,7 @@ data:
 
 
 ```yaml
-{{- define "labels" }}from: mychart{{ end }}
+{{- define "labels"}}from: mychart{{ end }}
 ```
 
 回想一下模板上的标签是如何全局共享的。因此，`labels` chart 可以包含在其他 chart 中。
@@ -192,7 +192,7 @@ data:
 尽管 chart 开发人员可以选择 `include` 和 `template`, 使用 `include` 的一个优点是，include 可以动态地引用模板：
 
 ```yaml
-{{ include $mytemplate }}
+{{include $mytemplate}}
 ```
 
 以上例子不会引用 $mytemplate。`template` 相反，将只接受一个字符串。
diff --git a/chart_template_guide/wrapping_up-zh_cn.md b/chart_template_guide/wrapping_up-zh_cn.md
index d4cd166..49f04f0 100644
--- a/chart_template_guide/wrapping_up-zh_cn.md
+++ b/chart_template_guide/wrapping_up-zh_cn.md
@@ -3,7 +3,7 @@
 
 但是当谈到 chart 的实际日常开发时，本指南还没有涉及很多事情。以下是一些有用的指向其他文档的指南，这些指南将帮助您创建新 chart：
 
-- Kubernetes chart 项目 [Kubernetes Charts project](https://github.com/kubernetes/charts) 是 chart 不可缺少的来源。该项目也是 chart 开发中最佳实践的标准。
+- Kubernetes chart 项目 [Helm Charts project](https://github.com/helm/charts) 是 chart 不可缺少的来源。该项目也是 chart 开发中最佳实践的标准。
 - Kubernetes 用户指南 [User's Guide](http://kubernetes.io/docs/user-guide/) 提供了可以使用的各种资源类型的详细示例，从 ConfigMaps 和 Secrets 到 DaemonSetkubernetes 和 Deployments。
 - Helm chart 指南 [Charts Guide](../chart/charts-zh_cn.md) 介绍了使用 chart 的工作流程。
 - Helm Chart Hooks 指南 [Chart Hooks Guide](../chart/charts_hooks-zh_cn.md) 解释了如何创建生命周期 hook。
diff --git a/quickstart/install-zh_cn.md b/quickstart/install-zh_cn.md
index 77de70d..d613aa9 100644
--- a/quickstart/install-zh_cn.md
+++ b/quickstart/install-zh_cn.md
@@ -23,7 +23,7 @@ Helm 客户端可以从源代码安装，也可以从预构建的二进制版本
 Snap package 维护站点 [Snapcrafters](https://github.com/snapcrafters/helm).
 
 ```
-$ sudo snap install helm
+$ sudo snap install helm --classic
 ```
 
 ### 通过 homebrew（macOS）
@@ -95,8 +95,8 @@ Helm 的服务器端部分 Tiller 通常运行在 Kubernetes 集群内部。但
 
 ### Special Note for RBAC Users
 
-Most cloud providers enable a feature called Role-Based Access Control - RBAC for short. If your cloud provider enables this feature, you will need to create a service account for Tiller with the right roles and permissions to access resources.
-Check the [Kubernetes Distribution Guide](kubernetes_distros-zh_cn.md) to see if there's any further points of interest on using Helm with your cloud provider. Also check out the guide on [Tiller and Role-Based Access Control](rbac-zh_cn.md) for more information on how to run Tiller in an RBAC-enabled Kubernetes cluster.
+大多数云提供商都支持名为基于角色的访问控制（简称 RBAC）的特性。如果您的云提供商启用了该特性，您将需要为 Tiller 创建一个具有访问资源的正确角色和权限的服务帐户 (service account)。
+查看 [Kubernetes Distribution Guide](kubernetes_distros-zh_cn.md) 在云提供商中使用 Helm 是否还有其他兴趣点. 也可以查看 [Tiller and Role-Based Access Control](rbac-zh_cn.md) 来获取关于如何在 RBAC 的 K8S 集群中使用 Tiller 的更多信息。
 
 ### 快捷群集内安装
 
diff --git a/quickstart/securing_installation-zh_cn.md b/quickstart/securing_installation-zh_cn.md
index 62913b4..c77e212 100644
--- a/quickstart/securing_installation-zh_cn.md
+++ b/quickstart/securing_installation-zh_cn.md
@@ -46,12 +46,26 @@ Helm 和 Tiller 在安装，删除和修改逻辑应用程序时，可以包含
 ### Tiller gRPC 端点和 TLS
 在默认安装中，Tiller 提供的 gRPC 端点在集群内部（不在集群外部）可用，不需要应用认证配置。如果不应用身份验证，集群中的任何进程都可以使用 gRPC 端点在集群内执行操作。在本地或安全的专用群集中，这可以实现快速使用并且是合适的。（当在集群外部运行时，Helm 通过 Kubernetes API 服务器进行身份验证，以达到 Tiller，利用现有的 Kubernetes 身份验证支持。）
 
-共享和生产群集 - 大多数情况下 - 应至少使用 Helm 2.7.2，并为每个 Tiller gRPC 端点配置 TLS，以确保群集内 gRPC 端点的使用仅适用于该端点的正确身份验证标识。这样做可以在任意数量的 namespace 中部署任意数量的 Tiller 实例，任何 gRPC 端点未经授权不可使用。使用 Helm `init` --tiller-tls-verify 选择安装启用 TLS 的 Tiller, 并验证远程证书，所有其他 Helm 命令都应该使用该 --tls 选项。
+The following two sub-sections describe options of how to setup Tiller so there isn't an unauthenticated endpoint (i.e. gRPC) in your cluster.
 
-有关正确配置并使用 TLS 的 Tiller 和 Helm 的正确步骤的更多信息，请参阅 Helm 和 Tiller 使用 SSL[Using SSL between Helm and Tiller](tiller_ssl.md)。
+#### Enabling TLS
+
+(Note that out of the two options, this is the recommended one for Helm 2.)
+共享和生产群集 - 大多数情况下 - 应至少使用 Helm 2.7.2，并为每个 Tiller gRPC 端点配置 TLS，以确保群集内 gRPC 端点的使用仅适用于该端点的正确身份验证标识。这样做可以在任意数量的 namespace 中部署任意数量的 Tiller 实例，任何 gRPC 端点未经授权不可使用。使用 Helm `init` 和 `--tiller-tls-verify` 选择安装启用 TLS 的 Tiller, 并验证远程证书，所有其他 Helm 命令都应该使用该 `--tls` 选项。
+
+有关正确配置并使用 TLS 的 Tiller 和 Helm 的正确步骤的更多信息，请参阅下面的章节 [Best Practices](#Helm 和 Tiller 安全最佳实践) 以及 Helm 和 Tiller 使用 SSL[在 Helm 和 Tiller 之间使用 SSL](tiller_ssl-zh_cn.md)。
 
 当 Helm 客户端从群集外部连接时，Helm 客户端和 API 服务器之间的安全性由 Kubernetes 本身管理。你可能需要确保这个链接是安全的。请注意，如果使用上面建议的 TLS 配置，则 Kubernetes API 服务器也无法访问客户端和 Tiller 之间的加密消息。
 
+#### Running Tiller Locally
+
+与上面的章节 [Enabling TLS](#Enabling TLS) 相反, 本节不涉及在集群中运行分蘖服务器 pod（就其价值而言，它符合当前情况 [helm v3 proposal](https://github.com/helm/community/blob/master/helm-v3/000-helm-v3.md)), 因此没有 gRPC 端点（因此不需要创建和管理 TLS 证书来保护每个 gRPC 端点）。
+
+步骤:
+ * 获取最新安装包 [GitHub release page](https://github.com/helm/helm/releases), 解压缩，并将 `helm` and `tiller` 放到你的路径 `$PATH`.
+ * "服务端": 运行 `tiller --storage=secret`. (`tiller` 默认监听 ":44134" 通过 `--listen` 参数.)
+ * "客户端": 在另一个终端 (同一台运行 `tiller` 的机器上): 运行 `export HELM_HOST=:44134`, 然后运行 `helm`.
+
 ### Tiller Release 信息
 由于历史原因，Tiller 将其 release 信息存储在 ConfigMaps 中。我们建议将默认设置更改为 Secrets。
 
diff --git a/quickstart/using_helm-zh_cn.md b/quickstart/using_helm-zh_cn.md
index f3bfcc5..ac7c6ea 100644
--- a/quickstart/using_helm-zh_cn.md
+++ b/quickstart/using_helm-zh_cn.md
@@ -382,7 +382,7 @@ $ helm repo add dev https://example.com/dev-charts
 由于 chart repo 经常更改，因此可以随时通过运行 `helm repo updat` 确保 Helm 客户端处于最新状态。
 
 ## 创建你自己的 charts
-该 chart 开发指南 [Chart Development Guide](charts.md) 介绍了如何开发自己的 charts。也可以通过使用以下 helm create 命令快速入门：
+该 chart 开发指南 [Chart Development Guide](../chart/charts-zh_cn.md) 介绍了如何开发自己的 charts。也可以通过使用以下 helm create 命令快速入门：
 
 ```bash
 $ helm create deis-workflow
@@ -409,13 +409,13 @@ $ helm install ./deis-workflow-0.1.0.tgz
 
 可以将已归档的 chart 加载到 chart repo 中。请参阅 chart repo 服务器的文档以了解如何上传。
 
-注意：stable repo 在 Kubernetes Charts GitHub 存储库上进行管理。该项目接受 chart 源代码，并且（在审计后）自动打包。
+注意：stable repo 在 Helm Charts GitHub 存储库 [Helm Charts GitHub repository](https://github.com/helm/charts) 上进行管理。该项目接受 chart 源代码，并且（在审计后）自动打包。
 
 ## Tiller，Namespaces 和 RBAC
 在某些情况下，可能希望将 Tiller 的范围或将多个 Tillers 部署到单个群集。以下是在这些情况下操作的一些最佳做法。
 
 1. Tiller 可以安装到任何 namespace。默认情况下，它安装在 kube-system 中。可以运行多个 Tillers，只要它们各自在自己的 namespace 中运行。
-2. 限制 Tiller 只能安装到特定的 namespace 和 / 或资源类型由 Kubernetes RBAC 角色和角色绑定控制。可以通过在配置 Helm 时通过 `helm init --service-account <NAME>` 向 Tiller 添加服务帐户。你可以在这里 [here](rbac.md). 找到更多的信息。
+2. 限制 Tiller 只能安装到特定的 namespace 和 / 或资源类型由 Kubernetes RBAC 角色和角色绑定控制。可以通过在配置 Helm 时通过 `helm init --service-account <NAME>` 向 Tiller 添加服务帐户。你可以在这里 [here](rbac-zh_cn.md). 找到更多的信息。
 3. Release 名称在每个 Tiller 实例中是唯一的。
 4. chart 应该只包含存在于单个命名空间中的资源。
 5. 不建议将多个 Tillers 配置为在相同的命名空间中管理资源。