helm を使っているときに、複数クラスタで使いたきときどうするか？についてちょっと試して見た。結論としては、kubectl 側でコンテキストを切り替えれば、自動で切り替わる。
この経緯で得た Tips をメモがわりとして、ブログにしておく。
Tiller のインストール
既存のクラスターがあり、そこに新規で tiller をインストールする場合どうするかというと、単にコンテキストを切り替えてインストールすれば良い。私は今、sacluster と sasbrk という二つのクラスタを持っている。現在使っているのが sacluster でsasbrk を追加したい場合は次の通り。ただし、コンテキストのが実施できるような設定がされているのが前提。詳細は、こちら。
$ kubectl config use-context sasbrk // コンテキストの切り替え
$ helm init // これで、client / server(tiller) がインストール。ある場合は、再インストール
ところが、実際にやると問題が起きた。サーバー(Tiller) のバージョンが古いらしい。
$ helm install stable/mongodb
Error: incompatible versions client[v2.7.0] server[v2.6.2]
$ helm version
Client: &version.Version{SemVer:"v2.7.0", GitCommit:"08c1144f5eb3e3b636d9775617287cc26e53dba4", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.6.2", GitCommit:"be3ae4ea91b2960be98c07e8f73754e67e87963c", GitTreeState:"clean"}
Tillter のアップグレード
Tiller をアップグレードすることにした。docker コンテナのバージョンをあげているだけ。
$ export TILLER_TAG=v2.7.0
invincible:service-catalog ushio$ kubectl --namespace=kube-system set image deployments/tiller-deploy tiller=gcr.io/kubernetes-helm/tiller:$TILLER_TAG
$ helm install stable/mongo
動作確認
ちゃんと動いている。
$ helm list
NAME REVISION UPDATED STATUS CHART NAMESPACE
steely-waterbuffalo 1 Sat Nov 18 23:59:37 2017 DEPLOYED mongodb-0.4.18 default
じゃあ、次にコンテキスト切り替えたらOKか？
$ kubectl config use-context sacluster
$ helm search mysql
NAME VERSION DESCRIPTION
stable/mysql 0.3.0 Fast, reliable, scalable, and easy to use open-...
stable/percona 0.3.0 free, fully compatible, enhanced, open source d...
stable/gcloud-sqlproxy 0.2.1 Google Cloud SQL Proxy
stable/mariadb 2.0.1 Fast, reliable, scalable, and easy to use open-...
$ helm install stable/mysql
$ helm list
NAME REVISION UPDATED STATUS CHART NAMESPACE
looming-aardvark 1 Sun Nov 19 00:02:00 2017 DEPLOYED mysql-0.3.0 default
よし入った。再度切り替え。完璧。
$ kubectl config use-context sasbrk
$ helm list
NAME REVISION UPDATED STATUS CHART NAMESPACE
steely-waterbuffalo 1 Sat Nov 18 23:59:37 2017 DEPLOYED mongodb-0.4.18 default
~/.helm ディレクトリ
一つ謎だったのが、~/.helm ディレクトリ。クライアント部分のディレクトリ。サーバーは、tiller が別のクラスタにそれぞれデプロイされる。
$ kubectl get pods --namespace kube-system
NAME READY STATUS RESTARTS AGE
heapster-342135353-2kzf7 2/2 Running 0 1h
kube-addon-manager-k8s-master-27305297-0 1/1 Running 0 1h
kube-apiserver-k8s-master-27305297-0 1/1 Running 2 1h
kube-controller-manager-k8s-master-27305297-0 1/1 Running 0 1h
kube-dns-v20-3003781527-1p9kw 3/3 Running 0 1h
kube-dns-v20-3003781527-51ld5 3/3 Running 0 1h
kube-proxy-26h6f 1/1 Running 0 1h
kube-proxy-fbmrb 1/1 Running 0 1h
kube-proxy-k2rgn 1/1 Running 0 1h
kube-proxy-r57gj 1/1 Running 0 1h
kube-scheduler-k8s-master-27305297-0 1/1 Running 0 1h
kubernetes-dashboard-3617030121-bk9wv 1/1 Running 1 1h
tiller-deploy-2745651589-89q25 1/1 Running 0 1h
コンテキストを変えると違うものが動いているのがわかる。
$ kubectl get pods --namespace kube-system
NAME READY STATUS RESTARTS AGE
heapster-342135353-02zrq 2/2 Running 0 4d
kube-dns-v20-1654923623-7v34r 3/3 Running 0 4d
kube-dns-v20-1654923623-x4qwq 3/3 Running 0 4d
kube-proxy-cd6dh 1/1 Running 0 4d
kube-proxy-sqgds 1/1 Running 0 4d
kube-proxy-szq0v 1/1 Running 0 4d
kube-svc-redirect-v97v6 1/1 Running 2 4d
kube-svc-redirect-vv3nt 1/1 Running 0 4d
kube-svc-redirect-xq5vw 1/1 Running 0 4d
kubernetes-dashboard-1672970692-plmdv 1/1 Running 0 4d
tiller-deploy-1114875906-n0x93 1/1 Running 0 3d
tunnelfront-653476575-bx1sl 1/1 Running 0 4d
しかし、ローカルの~/.helm/ ディレクトリは共通のはず。
実際に、~/.helm の下をのぞいて見たが、各クラスタのはなかった。それらは、各tiller で管理していると思われる。だから、kubectl の context を切り替えるだけで切り替わる感じ。ローカルにあるのは、キャッシュだけの模様。
両方のクラスタでデプロイしたものが両方格納されている。キャッシュだけ共通という感じですね。