1. inajob

    Posted

    inajob
Changes in title
+addon-manager
Changes in tags
Changes in body
Source | HTML | Preview
@@ -0,0 +1,85 @@
+# これはなに?
+https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/addon-manager
+
+Kubernetesクラスタでデフォルトで動いておく必要のあるmanifestを自動的にデプロイするソフトウェア。GKEやminikubeでも利用されている。
+LeaderElectionの機能があり、クラスタ内で複数動作させることでHAを実現できる。
+実態はこのシェルスクリプト https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/addon-manager/kube-addons.sh
+
+# addonの管理方法
+`$ADDON_PATH`(デフォルトは `/etc/kubernetes/addons/` )にあるマニフェストテンプレートを管理する。
+2種類の管理方法があり、これらをラベルで指定する
+
+- `addonmanager.kubernetes.io/mode=Reconcile`
+ - もしリソースが消されていれば作り直す
+ - もしテンプレートがが変更されていたら反映し直す
+ - もしテンプレートが消されていたらリソースを消す
+ - バージョン・設定値も含めて固定で動く必要のあるmanifestの管理に使えそう
+- `addonmanager.kubernetes.io/mode=EnsureExists`
+ - 存在があることを保証する
+ - そのリソースがないときは作成・再作成する
+ - テンプレートが消えていても作ったリソースはそのまま
+ - バージョン・設定値は利用者にカスタマイズさせるようなmanifestの管理に使えそう
+
+**注意すること**
+
+- 上記どちらかの管理方法をラベルで指定する必要がある
+- namespaceに属するリソースについてはkube-systemのものにする必要がある
+
+# リーダー選出はどうやっているのか?
+
+addon managerでは、HAでマスターを構成している場合に、kube-controller-managerのリーダー選出を借りて自身のリーダー選出に利用している。
+
+(HAでのクラスタの構成はこちらを参照 https://kubernetes.io/docs/admin/high-availability/ )
+
+下記でkube-controller-managerがどのホストで動いているかを知ることができる
+
+```
+$ kubectl get ep -n kube-system kube-controller-manager -o yaml
+apiVersion: v1
+kind: Endpoints
+metadata:
+ annotations:
+ control-plane.alpha.kubernetes.io/leader: '{"holderIdentity":"現在のリーダーのホスト名","leaseDurationSeconds":15,"acquireTime":"2017-12-07T08:02:04Z","renewTime":"2017-12-08T02:59:44Z","leaderTransitions":49}'
+ creationTimestamp: 2017-10-24T05:00:36Z
+ name: kube-controller-manager
+ namespace: kube-system
+ resourceVersion: "7842073"
+ selfLink: /api/v1/namespaces/kube-system/endpoints/kube-controller-manager
+ uid: 45ac6cb7-b878-11e7-bc9c-fa163e6b368e
+subsets: null
+```
+
+addon-managerはmaster nodeで動くことを想定しており、上記コマンドで取得した現在のリーダーのホスト名と、自身のホスト名が同じであれば動作するようになっている。
+ちょっとトリッキーな方法だが簡単に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より大袈裟なので使う利点がなさそう
+
+# minikubeでの事例
+
+- /etc/kubernetes/manifestにaddon-managerのmanifestがある
+ - static pod
+ - 環境変数でkubeconfigを渡している
+ - hostpathで`/etc/kubernetes/addons/` をマウントしている
+ - addons enableしたときはlocalkubeが `/etc/kubernetes/addons` にファイルをコピーしている
+
+## どういう時に嬉しいか?
+kube-dnsなどクラスタを構成するために必要なコンポーネントを立ち上げる時
+逆にこの方式を使ったmanifestは通常のkubectlでの更新ができなくなる(mode=Reconcileのとき)
+Kubernetesクラスタを第三者に提供する時に、クラスタを構成するのに不可欠なリソースを注入する場合に利用する(minikubeやmanaged kubernetes提供業者)
+
+# おわりに
+このエントリは、Z Lab のメンバーによる [Z Lab Advent Calendar 2017](https://qiita.com/advent-calendar/2017/zlab) として業務時間中に書きました。