update with upstream

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/`。
 

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 版本

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。
 

chart_best_practices/templates-zh_cn.md

@@ -19,17 +19,17 @@ templates 目目录的结构应如下所示：
 正确：
 
 ```yaml
-{{- define "nginx.fullname" }}
+{{- define "nginx.fullname"}}
 {{/* ... */}}
-{{ end -}}
+{{end -}}
 ```
 
 不正确：
 
 ```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` 时可见，而在 `{{- /* */ -}}` 部分中指定的注释不是。

chart_template_guide/accessing_files-zh_cn.md

@@ -142,15 +142,15 @@ kind: ConfigMap
 metadata:
   name: conf
 data:
-{{(.Files.Glob "foo/*").AsConfig | indent 2 }}
+  {{- (.Files.Glob "foo/*").AsConfig | nindent 2 }}
 ---
 apiVersion: v1
 kind: Secret
 metadata:
   name: very-secret
 type: Opaque
 data:
-{{(.Files.Glob "bar/*").AsSecrets | indent 2 }}
+  {{(.Files.Glob "bar/*").AsSecrets | nindent 2 }}
 ```
 
 ## 编码

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` 文件中，输出应该如下所示:

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,17 +127,17 @@ 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`：
 
 ```yaml
 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,15 +184,15 @@ data:
 
 
 ```yaml
-{{- define "labels" }}from: mychart{{ end }}
+{{- define "labels"}}from: mychart{{ end }}
 ```
 
 回想一下模板上的标签是如何全局共享的。因此，`labels` chart 可以包含在其他 chart 中。
 
 尽管 chart 开发人员可以选择 `include` 和 `template`, 使用 `include` 的一个优点是，include 可以动态地引用模板：
 
 ```yaml
-{{ include $mytemplate }}
+{{include $mytemplate}}
 ```
 
 以上例子不会引用 $mytemplate。`template` 相反，将只接受一个字符串。

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。

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 的更多信息。
 
 ### 快捷群集内安装
 

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。
 

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 配置为在相同的命名空间中管理资源。