Merge pull request #22 from whmzsu/whmzsu

 complete developer's guide

README.md

@@ -58,14 +58,23 @@
 - [Values](chart_best_practices/values-zh_cn.md)
 - [Templates](chart_best_practices/templates-zh_cn.md)
 - [Requirements](chart_best_practices/requirements-zh_cn.md)
-;- [Labels 和 Annotations](chart_best_practices/labels-zh_cn.md)
+- [Labels 和 Annotations](chart_best_practices/labels-zh_cn.md)
 - [Pods and PodTemplates](chart_best_practices/pods-zh_cn.md)
 - [资源定义定制](chart_best_practices/custom_resource_definitions-zh_cn.md)
 - [RBAC](chart_best_practices/rbac-zh_cn.md)
 
 ### 相关项目和文档
+- [相关项目和文档](related-zh_cn.md)
+
 ### Kubernetes Helm 架构
-### 开发指南
+- [Kubernetes Helm 架构](architecture-zh_cn.md)
+
+### 开发者指南
+- [开发者指南](developers-zh_cn.md)
+
 ### 项目历史
+- [项目历史](history-zh_cn.md)
+
 ### 术语表
+
 ### [何处寻找Charts](https://hub.kubeapps.com/)

SUMMARY.md

@@ -50,18 +50,23 @@
 - [Values](chart_best_practices/values-zh_cn.md)
 - [Templates](chart_best_practices/templates-zh_cn.md)
 - [Requirements](chart_best_practices/requirements-zh_cn.md)
-;- [Labels 和 Annotations](chart_best_practices/labels-zh_cn.md)
+- [Labels 和 Annotations](chart_best_practices/labels-zh_cn.md)
 - [Pods and PodTemplates](chart_best_practices/pods-zh_cn.md)
 - [资源定义定制](chart_best_practices/custom_resource_definitions-zh_cn.md)
 - [RBAC](chart_best_practices/rbac-zh_cn.md)
 
+### 相关项目和文档
+- [相关项目和文档](related-zh_cn.md)
 
+### Kubernetes Helm 架构
+- [Kubernetes Helm 架构](architecture-zh_cn.md)
 
+### 开发者指南
+- [开发者指南](developers-zh_cn.md)
 
-
-### 相关项目和文档
-### Kubernetes Helm 架构
-### 开发指南
 ### 项目历史
+- [项目历史](history-zh_cn.md)
+
 ### 术语表
+
 ### [何处寻找Charts](https://hub.kubeapps.com/)

architecture-zh_cn.md

@@ -0,0 +1,49 @@
+# Kubernetes Helm 架构
+
+本文档介绍了Helm高层次体系结构。
+
+## Helm的目的
+Helm是管理称为chart的 Kubernetes包的工具。Helm可以做到以下几点：
+
+- 从头开始创建新chart
+- 将chart打包成chart归档（tgz）文件
+- 与存储chart的chart存储库交互
+- 安装或卸载chart到现有的Kubernetes集群中
+- 管理用Helm安装的chart的release周期
+
+对于Helm，有三个重要的概念：
+
+- chart是创建Kubernetes应用程序实例所需的一系列信息。
+- 配置包含可以合并到打包chart以创建可发布对象的配置信息。
+- Release是一个的运行实例的chart，具有特定的组合配置。
+
+## 组件
+Helm有两个主要部分：
+
+Helm Client是最终用户的命令行客户端。客户端负责以下部分：
+
+- 本地chart开发
+- 管理存储库
+- 与Tiller服务交互
+- 发送要安装的chart
+- 查询有关发布的信息
+- 请求升级或卸载现有release
+
+**Tiller Server**是一个集群内服务，与Helm客户端进行交互，并与Kubernetes API服务进行交互。服务负责以下内容：
+
+- 监听来自Helm客户端的传入请求
+- 结合chart和配置来构建发布
+- 将chart安装到Kubernetes中，然后跟踪后续release
+- 通过与Kubernetes交互来升级和卸载chart
+
+简而言之，客户端负责管理chart，而服务端负责管理release。
+
+## 部署
+
+Helm客户端使用Go编程语言编写，并使用gRPC协议套件与Tiller服务进行交互。
+
+Tiller服务也用Go编写。它提供了一个与客户端连接的gRPC服务，它使用Kubernetes客户端库与Kubernetes进行通信。目前，该库使用REST + JSON。
+
+Tiller服务将信息存储在位于Kubernetes内的ConfigMaps中。它不需要自己的数据库。
+
+如有可能，配置文件用YAML编写。

chart_best_practices/labels-zh_cn.md

@@ -18,8 +18,8 @@ Helm hook总是注释。
 
 名称|状态|描述
 -----|------|----------
-heritage|	REC	|这应该始终设置为`{{ .Release.Service }}`。它用于查找Tiller管理的所有东西。
-release| REC |这应该是`{{ .Release.Name }}`。
-chart| REC| 这应该是chart名称和版本：`{{ .Chart.Name }}-{{ .Chart.Version \| replace "+" "_" }}`。
-app| REC| 这应该是应用程序名称，代表了整个应用程序。通常`{{ template "name" . }}` 用于此。这被许多Kubernetes manifests所使用，而不是Helm特有的。
+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`。

developers-zh_cn.md

@@ -0,0 +1,191 @@
+# 开发者指南
+
+本指南解释了如何设置环境来开发Helm和Tiller。
+
+## 前提条件
+- Go的最新版本
+- 最新版本的Glide
+- Kubernetes集群和kubectl（可选）
+- gRPC工具链
+- Git
+
+## 构建Helm/tiller
+
+我们使用Make来构建我们的程序。最简单的入门方法是：
+
+```bash
+$ make bootstrap build
+```
+
+
+
+注意：如果不从路径`$GOPATH/src/k8s.io/helm`运行，命令将会失败。目录k8s.io不应该是符号链接，否则build找不到相关的包。
+
+这将构建Helm和Tiller。`make bootstrap`将尝试安装某些工具，如果它们不存在的话。
+
+要运行所有测试（无需运行测试`vendor/`），请运行 make test。
+
+要在本地运行Helm和Tiller，可以运行`bin/helm`或`bin/tiller`。
+
+- 已知Helm和Tiller可在macOS和大多数Linux，包括Alpine上运行。
+- Tiller必须能够访问Kubernetes群集。它通过检查使用kubectl的Kube配置文件来了解群集信息。
+
+### 手册页
+
+手册页和Markdown文档已经在`docs/`预先建好。可以使用重新生成文档make docs。
+
+要将Helm手册页公开给`man`客户端，您可以将这些文件放入`$MANPATH`：
+
+```
+$ export MANPATH=$GOPATH/src/k8s.io/helm/docs/man:$MANPATH
+$ man helm
+```
+
+## gRPC和Protobuf
+
+Helm和Tiller使用gRPC进行通信。要开始使用gRPC，需要如下准备
+
+- 安装protoc编译protobuf文件。发布在[这里](https://github.com/google/protobuf/releases)
+- 运行Helm的 `make bootstrap`来生成p`rotoc-gen-go`插件并将其放入`bin/`。
+
+请注意，需要使用protobuf 3.2.0（`protoc --version`）的版本。protoc-gen-go版本与Kubernetes使用GRPC的版本绑定。所以这个插件是在本地维护的。
+
+虽然gRPC和ProtoBuf规范缩进时没有规定，但我们要求缩进样式与Go格式规范相匹配。也就是说，协议缓冲区应该使用基于标签的缩进，并且rpc声明应该遵循Go函数声明的风格。
+
+### Helm API（HAPI）
+
+我们使用gRPC作为API层。请参阅`pkg/proto/hapi`生成的Go代码以及`_proto`协议缓冲区定义。
+
+要从protobuf源重新生成Go文件，使用`make protoc`。
+
+## Docker镜像
+
+要构建Docker镜像，请使用`make docker-build`。
+
+预构建的镜像已经在官方Kubernetes Helm GCR registry中提供。
+
+## 运行本地群集
+
+对于开发，我们强烈建议使用 [Kubernetes Minikube](https://github.com/kubernetes/minikube)这个面向开发人员的发行版。安装完成后，可以使用 helm init安装到群集中。请注意，用于开发的Tiller版本可能无法在Google Cloud Container Registry中使用。如果遇到镜像Pull错误，可以覆盖Tiller的版本。例：
+
+```bash
+helm init --tiller-image=gcr.io/kubernetes-helm/tiller:2.7.2
+```
+
+或使用最新版本：
+
+```bash
+helm init --canary-image
+```
+
+为了在Tiller上进行开发，在本地运行Tiller有时更方便，而不是将其打包到镜像中并在群集中运行。你可以通过告诉Helm客户端使用一个本地实例来做到这一点。
+
+```bash
+$ make build
+$ bin/tiller
+```
+
+要配置Helm客户端，请使用`--host`标志或导出`HELM_HOST`环境变量：
+
+```bash
+$ export HELM_HOST=localhost:44134
+$ helm install foo
+```
+
+（请注意，直接运行Tiller时不需要使用`helm init`）
+
+Tiller应该在>= 1.3 Kubernetes群集上运行。
+
+## 贡献指南
+
+我们欢迎捐款。这个项目已经制定了一些指导方针，以确保（a）代码质量仍然很高，（b）项目保持一致，（c）贡献遵循开源法律要求。我们的目的不是为了给贡献者带来负担，而是为了构建优雅和高质量的开源代码，让我们的用户受益。
+
+确保你已经阅读并理解了贡献指南：
+
+https://github.com/kubernetes/helm/blob/master/CONTRIBUTING.md
+
+### 代码的结构
+
+Helm项目的代码组织如下：
+
+- 单独的程序位于`cmd/`。`cmd/`里面的代码 不是为库的重复使用而设计的。
+- 共享库存储在`pkg/`。
+- 原始ProtoBuf文件存储在`_proto/hapi`（hapi表示Helm应用程序编程接口）。
+- 从proto定义生成的Go文件存储在`pkg/proto`。
+- `scripts/`目录包含许多实用程序脚本。其中大部分由CI/CD管道使用。
+- `rootfs/`文件夹用于Docker特定的文件。
+- `docs/`文件夹用于文档和示例。
+
+Go依赖关系由Glide管理 并存储在`vendor/`目录中。
+
+### Git约定
+
+我们将Git用于版本控制系统。Master分支是当前发展候选目录。发布版本有标记。
+
+我们通过GitHub Pull Requests（PR）接受对代码的更改。执行此操作的一个工作流程如下所示：
+
+1. 转到`$GOPATH/src/k8s.io`目录，`git clone` `github.com/kubernetes/helm`存储库。
+2. 将该存储库fork到你自己的GitHub帐户
+3. 将你的存储库添加为远程服务器 `$GOPATH/src/k8s.io/helm`
+4. 创建一个新的工作分支（`git checkout -b feat/my-feature`）并在该分支上完成工作。
+5. 当准备好让我们review时，将你的分支推送到GitHub，然后给我们提交一个新的PR请求。
+
+对于Git提交消息，我们遵循语义提交消息[Semantic Commit Messages](http://karma-runner.github.io/0.13/dev/git-commit-msg.html)：
+
+```
+fix(helm): add --foo flag to 'helm install'
+
+When 'helm install --foo bar' is run, this will print "foo" in the
+output regardless of the outcome of the installation.
+
+Closes #1234
+```
+
+常见提交类型：
+
+- fix: 修复一个bug或错误
+- feat: 添加一项新功能
+- docs: 更改文档
+- test: 改进测试
+- ref: 重构现有的代码
+
+常见范围：
+
+- helm：Helm CLI
+- tiller：Tiller服务器
+- proto：Protobuf定义
+- pkg/lint：lint包。对于任何软件包遵循类似的约定
+- `*`：两个或更多范围
+
+
+更多内容：
+
+- DEIS准则[Deis Guidelines](https://github.com/deis/workflow/blob/master/src/contributing/submitting-a-pull-request.md)是这一部分的灵感启发。
+- Karma Runner [定义](http://karma-runner.github.io/0.13/dev/git-commit-msg.html)了语义提交消息的主意。
+
+### Go 语言约定
+
+我们非常密切地遵循Go编码风格标准。通常，运行 `go fmt`会让你的代码更加漂亮。
+
+我们通常也遵循由`go lint`和 `gometalinter`推荐的约定。运行`make test-style`以测试样式一致性。
+
+更多阅读：
+
+- Effective Go [introduces formatting](https://golang.org/doc/effective_go.html#formatting)。
+- Go Wiki有一个关于格式化的非常好的文章[formatting](https://github.com/golang/go/wiki/CodeReviewComments).。
+
+### Protobuf约定
+
+由于项目主要是Go代码，因此我们尽可能将Protobuf文件格式化为Go。目前Protobuf没有真正的格式规则或准则，但随着它们的出现，我们可能会选择遵循这些规则或准则。
+
+标准：
+
+- Tab缩进，而不是空格。
+- 间距规则遵循Go约定（线条末端的花括号，运算符周围的空格）。
+
+约定：
+
+- 文件应该用`option go_package = "...";`来指定它们的包
+- 注释应该转化为良好的Go代码注释（因为`protoc `会拷贝注释到目标源代码文件中）。
+- RPC功能在它们的请求/响应消息的同一文件中定义。
+- 不推荐使用的RPC，消息和字段在注释中不推荐使用（// UpdateFoo DEPRECATED updates a foo.）。

history-zh_cn.md

@@ -0,0 +1,19 @@
+## 项目的历史
+Kubernetes Helm是[Helm
+Classic](https://github.com/helm/helm)和GCS Deployment Manager的Kubernetes移植的合并结果。该项目由Google和Deis联合创建，尽管它现在是CNCF的一部分。许多公司现在定期为Helm做出贡献。
+
+与Helm Classic的区别：
+
+- Helm现在有一个客户端（`helm`）和一个服务端（`tiller`）。服务端在Kubernetes内部运行，并管理资源。
+- Helm的chart格式更好：
+  - 依赖关系是不可变的，并存储在chart的`charts/` 目录中。
+  - chart使用[SemVer 2](http://semver.org/spec/v2.0.0.html)版本标准化
+  - chart可以从目录或chart归档文件中加载
+  - Helm支持Go模板，无需运行`generate` 或`template`命令。
+  - Helm可以轻松配置release - 并与团队的其他成员共享配置。
+- Helm chart存储库现在使用普通的HTTP（S）而不是Git / GitHub。不再有任何GitHub依赖。
+  - chart存储库服务是一个简单的HTTP服务器
+  - chart由版本引用
+  - `helm serve`命令将运行本地chart服务器，也可以轻松使用对象存储（S3，GCS）或常规Web服务器。
+  - 而且仍然可以从本地目录加载chart。
+- Helm工作空间不存在了。现在可以在想要工作的文件系统上的任何地方工作。