安裝FAQ
本節跟蹤安裝或開始使用Helm時遇到的一些經常遇到的問題。
歡迎你的幫助 來更好的提供此文檔。要添加，更正或刪除信息，提出問題issue或向我們發送PR請求。
我在網址 https://whmzsu.github.io/helm-doc-zh-cn/ 不斷更新，同時也會搬運到這裏，大家有興趣加入https://github.com/whmzsu/helm-doc-zh-cn/的可以給我提交意見和建議。
下載
我想知道更多關於我的下載選項。
問：我無法獲得最新Helm的GitHub發佈。他們在哪？
答：我們不再使用GitHub發佈版本。二進制文件現在存儲在 GCS公共存儲區中GCS public bucket。
問：爲什麼沒有Debian/Fedora/… Helm的原生的軟件包？
我們很樂意提供這些信息，或者指向可靠的提供商。如果你對幫助感興趣，我們很樂意。這就是Homebrew式的開始。
問：你爲什麼要提供一個curl …|bash腳本？
答：我們的repo庫（scripts/get）中有一個腳本可以作爲curl ..|bash腳本執行。這些傳輸全部受HTTPS保護，並且腳本會對其獲取的包進行一些審計。但是，腳本具有任何shell腳本的所有常見危險。
我們提供它是因爲它很有用，但我們建議用戶先仔細閱讀腳本。並且，我們真正喜歡的是Helm的的打包版本。
安裝
我正在嘗試安裝Helm/Tiller，但有些地方出了問題。
問：我如何將Helm客戶端文件放在~/.helm以外的地方？
設置$HELM_HOME環境變量，然後運行helm init：
export HELM_HOME=/some/path
helm init --client-only注意，如果你有現有的repo存儲庫，則需要通過helm repo add....重新添加它們。
問：我如何配置Helm，但不安裝Tiller？
答：默認情況下，helm init將確認本地$HELM_HOME配置，然後在羣集上安裝Tiller。要本地配置，但不安裝Tiller，請使用helm init --client-only。
問：如何在集羣上手動安裝Tiller？
答：Tiller是作爲Kubernetes deployment安裝的。可以通過運行helm init --dry-run --debug獲取manifest，然後通過kubectl手動安裝 。建議不要刪除或更改該deployment中的標籤labels，因爲它們有時支持腳本和工具需要用到。
問：爲什麼安裝Tiller期間報錯誤Error response from daemon: target is unknown？
答：有用戶報告無法在使用Docker 1.13.0的Kubernetes實例上安裝Tiller。造成這種情況的根本原因是Docker中的一個錯誤，它使得一個版本與早期版本的Docker推送到Docker註冊表的鏡像不兼容。
該問題在發佈後不久就已修復，並在Docker 1.13.1-RC1和更高版本中提供。
入門
我成功安裝了Helm/Tiller，但我使用時碰到問題。
問：使用Helm時，收到錯誤“客戶端傳輸中斷”
E1014 02:26:32.885226 16143 portforward.go:329] an error occurred forwarding 37008 -> 44134: error forwarding port 44134 to pod tiller-deploy-2117266891-e4lev_kube-system, uid : unable to do port forwarding: socat not found.
2016/10/14 02:26:32 transport: http2Client.notifyError got notified that the client transport was broken EOF.
Error: transport is closing答：這通常表明Kubernetes未設置爲允許端口轉發。
通常情況下，缺少的部分是socat。如果正在運行CoreOS，我們被告知它可能在安裝時配置錯誤。CoreOS團隊建議閱讀以下內容：
https://coreos.com/kubernetes/docs/latest/kubelet-wrapper.html
以下是一些解決的問題案例，可以幫助開始使用：
Q：使用Helm時,報錯誤”lookup XXXXX on 8.8.8.8:53: no such host”
Error: Error forwarding ports: error upgrading connection: dial tcp: lookup kube-4gb-lon1-02 on 8.8.8.8:53: no such host答：我們在Ubuntu和Kubeadm多節點羣集中有這個問題。問題原因是節點期望某些DNS記錄可以通過全局DNS獲得。在上游解決此問題之前，可以按照以下方式解決該問題。在每個控制平面節點上：
- 添加條目到
/etc/hosts，將主機名映射到其 public IP - 安裝
dnsmasq（例如apt install -y dnsmasq） - 刪除k8s api服務容器（kubelet會重新創建它）
- 然後
systemctl restart docker（或重新啓動節點）請/etc/resolv.conf更改 請參閱此問題以獲取更多信息：https://github.com/kubernetes/helm/issues/1455
問：在GKE（Google Container Engine）上，報錯”No SSH tunnels currently open”
Error: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-[redacted]"?錯誤消息的另一個形式是：
Unable to connect to the server: x509: certificate signed by unknown authority答：這個問題是你的本地Kubernetes配置文件必須具有正確的憑據。
在GKE上創建集羣時，它將提供憑證，包括SSL證書和證書頒發機構信息。這些需要存儲在一個Kubernetes配置文件中（默認：~/.kube/config，這樣kubectl和helm可以訪問它們）。
問：當我運行Helm命令時，出現有關隧道tunnel或代理proxy的錯誤
答：Helm使用Kubernetes代理服務連接到Tiller服務器。如果命令kubectl proxy不適用，Helm也不行。通常，錯誤與缺失的socat服務有關。
問：Tiller 崩潰
當我在Helm上運行命令時，Tiller崩潰時會出現如下錯誤：
Tiller is listening on :44134
Probes server is listening on :44135
Storage driver is ConfigMap
Cannot initialize Kubernetes connection: the server has asked for the client to provide credentials 2016-12-20 15:18:40.545739 I | storage.go:37: Getting release "bailing-chinchilla" (v1) from storage
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x8053d5]
goroutine 77 [running]:
panic(0x1abbfc0, 0xc42000a040)
/usr/local/go/src/runtime/panic.go:500 +0x1a1
k8s.io/helm/vendor/k8s.io/kubernetes/pkg/client/unversioned.(*ConfigMaps).Get(0xc4200c6200, 0xc420536100, 0x15, 0x1ca7431, 0x6, 0xc42016b6a0)
/home/ubuntu/.go_workspace/src/k8s.io/helm/vendor/k8s.io/kubernetes/pkg/client/unversioned/configmap.go:58 +0x75
k8s.io/helm/pkg/storage/driver.(*ConfigMaps).Get(0xc4201d6190, 0xc420536100, 0x15, 0xc420536100, 0x15, 0xc4205360c0)
/home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/storage/driver/cfgmaps.go:69 +0x62
k8s.io/helm/pkg/storage.(*Storage).Get(0xc4201d61a0, 0xc4205360c0, 0x12, 0xc400000001, 0x12, 0x0, 0xc420200070)
/home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/storage/storage.go:38 +0x160
k8s.io/helm/pkg/tiller.(*ReleaseServer).uniqName(0xc42002a000, 0x0, 0x0, 0xc42016b800, 0xd66a13, 0xc42055a040, 0xc420558050, 0xc420122001)
/home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/tiller/release_server.go:577 +0xd7
k8s.io/helm/pkg/tiller.(*ReleaseServer).prepareRelease(0xc42002a000, 0xc42027c1e0, 0xc42002a001, 0xc42016bad0, 0xc42016ba08)
/home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/tiller/release_server.go:630 +0x71
k8s.io/helm/pkg/tiller.(*ReleaseServer).InstallRelease(0xc42002a000, 0x7f284c434068, 0xc420250c00, 0xc42027c1e0, 0x0, 0x31a9, 0x31a9)
/home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/tiller/release_server.go:604 +0x78
k8s.io/helm/pkg/proto/hapi/services._ReleaseService_InstallRelease_Handler(0x1c51f80, 0xc42002a000, 0x7f284c434068, 0xc420250c00, 0xc42027c190, 0x0, 0x0, 0x0, 0x0, 0x0)
/home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/proto/hapi/services/tiller.pb.go:747 +0x27d
k8s.io/helm/vendor/google.golang.org/grpc.(*Server).processUnaryRPC(0xc4202f3ea0, 0x28610a0, 0xc420078000, 0xc420264690, 0xc420166150, 0x288cbe8, 0xc420250bd0, 0x0, 0x0)
/home/ubuntu/.go_workspace/src/k8s.io/helm/vendor/google.golang.org/grpc/server.go:608 +0xc50
k8s.io/helm/vendor/google.golang.org/grpc.(*Server).handleStream(0xc4202f3ea0, 0x28610a0, 0xc420078000, 0xc420264690, 0xc420250bd0)
/home/ubuntu/.go_workspace/src/k8s.io/helm/vendor/google.golang.org/grpc/server.go:766 +0x6b0
k8s.io/helm/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1(0xc420124710, 0xc4202f3ea0, 0x28610a0, 0xc420078000, 0xc420264690)
/home/ubuntu/.go_workspace/src/k8s.io/helm/vendor/google.golang.org/grpc/server.go:419 +0xab
created by k8s.io/helm/vendor/google.golang.org/grpc.(*Server).serveStreams.func1
/home/ubuntu/.go_workspace/src/k8s.io/helm/vendor/google.golang.org/grpc/server.go:420 +0xa3答：請檢查Kubernetes的安全設置。
Tiller中的崩潰幾乎總是由於未能與Kubernetes API服務器進行協商而導致的結果（此時，Tiller功能不正常，因此崩潰並退出）。
通常，這是認證失敗的結果，因爲運行Tiller的Pod沒有正確的令牌token。
要解決這個問題，你需要修改Kubernetes配置。確保–service-account-private-key-file從controller-manager和 –service-account-key-file從API服務器指向同一個X509 RSA密鑰。
升級
我的Helm原來工作正常，然後我升級了。現在它工作不正常。
問：升級後，我收到錯誤“Client version is incompatible”。怎麼問題？
Tiller和Helm必須協商一個通用版本，以確保他們可以安全地進行通信而不會違反API假設。該錯誤意味着版本差異太大而無法安全地繼續。通常，需要爲此手動升級Tiller。
安裝指南有安全Helm升級和Tiller的正式信息。
版本號的規則如下：
- 預發佈版本與其他一切不兼容。Alpha.1與…不相容Alpha.2。
- 修補程序版本兼容：1.2.3與1.2.4兼容
- 少量修訂不兼容：1.2.0與1.3.0不兼容，但我們可能在未來放寬這一限制。
- 主要版本不兼容：1.0.0與2.0.0不兼容。
卸載
我正在嘗試刪除某些東西。
問：當我刪除Tiller deployment時，爲何所有安裝的release信息還在集羣裏？
安裝release信息存儲在kube-system名稱空間內的ConfigMaps中。需要手動刪除它們以刪除記錄或使用helm delete –purge。
問：我想刪除我的本地Helm。它的所有文件在哪裏？
包括helm二進制文件，Helm存儲了一些文件在$HELM_HOME，默認位於~/.helm。
本文轉自kubernetes中文社區-Helm 用戶指南-系列（4）-安裝FAQ