1. inajob

    No comment

    inajob
Changes in body
Source | HTML | Preview
@@ -3,12 +3,14 @@
Kubernetesクラスタでデフォルトで動いておく必要のあるmanifestを自動的にデプロイするソフトウェア。GKEやminikubeでも利用されている。
LeaderElectionの機能があり、クラスタ内で複数動作させることでHAを実現できる。
実態はこのシェルスクリプト https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/addon-manager/kube-addons.sh
+k8sクラスタにあらかじめ特定のPodを稼働させておく場合などに使えそうなので、詳細を調べてみました。
+
# addonの管理方法
-`$ADDON_PATH`(デフォルトは `/etc/kubernetes/addons/` )にあるマニフェストテンプレートを管理する
+addon-managerは `$ADDON_PATH`(デフォルトは `/etc/kubernetes/addons/` )にあるマニフェストテンプレートを管理します
2種類の管理方法があり、これらをラベルで指定する
- `addonmanager.kubernetes.io/mode=Reconcile`
- もしリソースが消されていれば作り直す
- もしテンプレートがが変更されていたら反映し直す
@@ -23,13 +25,16 @@
**注意すること**
- 上記どちらかの管理方法をラベルで指定する必要がある
- namespaceに属するリソースについてはkube-systemのものにする必要がある
+
+要するにaddon-managerというのは、あるディレクトリにあるマニフェストをapplyし続けるデーモンのようなアプリケーションなのです。
+
# リーダー選出はどうやっているのか?
-addon managerは、HAでマスターを構成している場合に、kube-controller-managerのリーダー選出を借りて自身のリーダー選出に利用している。
+addon-managerは、HAでマスターを構成している場合に、kube-controller-managerのリーダー選出を借りて自身のリーダー選出に利用している。
(HAでのクラスタの構成はこちらを参照 https://kubernetes.io/docs/admin/high-availability/ )
下記でkube-controller-managerがどのホストで動いているかを知ることができる
@@ -47,39 +52,48 @@
selfLink: /api/v1/namespaces/kube-system/endpoints/kube-controller-manager
uid: 45ac6cb7-b878-11e7-bc9c-fa163e6b368e
subsets: null
```
-addon-managerはmaster nodeで動くことを想定しており、上記コマンドで取得した現在のリーダーのホスト名と、自身のホスト名が同じであれば動作するようになっている。
+addon-managerはmaster nodeで動くことを想定しており、上記コマンドで取得した現在のリーダーのホスト名と、自身のホスト名が同じであれば動作するようになっている。 ( https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/addon-manager/kube-addons.sh#L156 )
+
ちょっとトリッキーな方法だが簡単にHAが実現できる方法である。
# addon-managerをどうやってデプロイするか?
-- クラスタを構成するマシンにDaemonSetsで起動するようにしておく
- - クラスタ提供者からすると、利用者に消される恐れがある
- - そのdaemonsetsを提供する仕組みで必要なmanifestをデプロイすれば良いのではないか
- - kube-systemを触る権限がある人はこの機能を停止できてしまう
- - RBACでkube-systemの操作を限定するならそれでも良さそう
- - EnsureExistsの挙動はaddon-mangerを使わないと実現できない
-- クラスタを構成するマシンにstatic podで起動するようにしておく
- - static pod https://kubernetes.io/docs/tasks/administer-cluster/static-pod/
- - kubectlで消すことができない
- - minikube方式
-- クラスタを構成するマシンにsystemdで起動するようにしておく
- - kubectlで消すことができない
- - static podより大袈裟なので使う利点がなさそう
+addon-managerはコンテナとして提供されています ( https://console.cloud.google.com/gcr/images/google-containers/GLOBAL/kube-addon-manager ) これをデプロイするにはいくつかの方法が考えられます。
+
+## 方法1 クラスタを構成master NodeにDaemonSetsで起動するようにしておく
+
+- クラスタ提供者からすると、利用者に消される恐れがある
+- そのdaemonsetsを提供する仕組みで必要なmanifestをデプロイすれば良いのではないか
+ - kube-systemを触る権限がある人はこの機能を停止できてしまう
+ - RBACでkube-systemの操作を限定するならそれでも良さそう
+ - EnsureExistsの挙動はaddon-mangerを使わないと実現できない
+
+## 方法2 クラスタを構成するmaster Nodeにstatic podで起動するようにしておく
+
+- Static pod と呼ばれる方法 https://kubernetes.io/docs/tasks/administer-cluster/static-pod/
+- kubectlで消すことができない
+- minikubeもこの方法を使っている(後述)
+
+## 方法3 クラスタを構成するマシンにsystemdで起動するようにしておく
+
+- kubectlで消すことができない
+- static pod(方法2)より大袈裟なので使う利点がなさそう
# minikubeでの事例
- /etc/kubernetes/manifestにaddon-managerのmanifestがある
- - static pod
- - 環境変数でkubeconfigを渡している
- - hostpathで`/etc/kubernetes/addons/` をマウントしている
- - addons enableしたときはlocalkubeが `/etc/kubernetes/addons` にファイルをコピーしている
+ - Static pod と呼ばれる方法
+ - https://github.com/kubernetes/minikube/blob/master/deploy/addons/addon-manager.yaml
+ - 環境変数でkubeconfigを渡している
+ - hostpathで`/etc/kubernetes/addons/` をマウントしている
+- addons enableしたときはlocalkubeが `/etc/kubernetes/addons` にファイルをコピーしている
## どういう時に嬉しいか?
kube-dnsなどクラスタを構成するために必要なコンポーネントを立ち上げる時
逆にこの方式を使ったmanifestは通常のkubectlでの更新ができなくなる(mode=Reconcileのとき)
-Kubernetesクラスタを第三者に提供する時に、クラスタを構成するのに不可欠なリソースを注入する場合に利用する(minikubeやmanaged kubernetes提供業者)
+Kubernetesクラスタを第三者に提供する時に、クラスタを構成するのに不可欠なリソースを注入する場合に利用できそう(minikubeやmanaged kubernetes提供業者)
# おわりに
このエントリは、Z Lab のメンバーによる [Z Lab Advent Calendar 2017](https://qiita.com/advent-calendar/2017/zlab) として業務時間中に書きました。