1. inajob

    No comment

    inajob
Changes in body
Source | HTML | Preview
@@ -60,11 +60,11 @@
# addon-managerをどうやってデプロイするか?
addon-managerはコンテナとして提供されています ( https://console.cloud.google.com/gcr/images/google-containers/GLOBAL/kube-addon-manager ) これをデプロイするにはいくつかの方法が考えられます。
-**方法1 クラスタを構成master NodeにDaemonSetsで起動するようにしておく**
+**方法1 クラスタを構成するmaster NodeにDaemonSetsで起動するようにしておく**
- クラスタ提供者からすると、利用者に消される恐れがある
- そのdaemonsetsを提供する仕組みで必要なmanifestをデプロイすれば良いのではないか
- kube-systemを触る権限がある人はこの機能を停止できてしまう
- RBACでkube-systemの操作を限定するならそれでも良さそう
@@ -85,14 +85,15 @@
方法を3つ書きましたが、利用者に消して欲しくないmanifestを提供するには 方法2がよさそうです。
# minikubeでの事例
-minikubeはStatic podと呼ばれる方法。具体的には `/etc/kubernetes/manifestにaddon-manager` に `https://github.com/kubernetes/minikube/blob/master/deploy/addons/addon-manager.yaml` のようなマニフェストを配置することで、addon-managerをデプロイしています。
+minikubeはStatic podと呼ばれる方法。具体的には `/etc/kubernetes/manifestにaddon-manager` に
+ https://github.com/kubernetes/minikube/blob/master/deploy/addons/addon-manager.yaml のようなマニフェストを配置することで、addon-managerをデプロイしています。
-このmanifestでは環境変数でkubeconfigを渡し、hostpathで`/etc/kubernetes/addons/` をマウントしています。
-`minikube addons enable`したときはminikueがlocalkubeに指令を出し、localkubeが `/etc/kubernetes/addons` にファイルをコピーし、 それをhostpathでマウントしているaddon-managerが検知して、Kubernetesにaddonをデプロイするという流れになっています。
+このmanifestでは環境変数でkubeconfigを渡し、hostPathで`/etc/kubernetes/addons/` をマウントしています。
+`minikube addons enable`したときはminikueがlocalkubeに指令を出し、localkubeが `/etc/kubernetes/addons` にファイルをコピーし、 それをhostPathでマウントしているaddon-managerが検知して、Kubernetesにaddonをデプロイするという流れになっています。
## どういう時に嬉しいか?
kube-dnsなどクラスタを構成するために必要なコンポーネントを立ち上げる時に便利そうです。
さらに、この方式を使ったmanifestは通常のkubectlでの更新ができなくなる(mode=Reconcileのとき)ため、Kubernetesクラスタを第三者に提供する時に、クラスタを構成するのに不可欠なリソースを注入する場合に利用できそうです。 (managed kubernetes提供業者はこういうことをしたいのでは?)