vclusterでお手軽Kubernetesマルチテナント

Slide 1

Slide 1 text

vclusterでお手軽 Kubernetes マルチテナント

Slide 2

Slide 2 text

KAZUTO KUSAMA @jacopen Senior Cloud Native Architect @VMware 知らない間にタイトル変わってた

Slide 3

Slide 3 text

About me ● VMware Tanzuの導入支援やプラットフォームチームづくりの支援をしています ● CloudNative Days TokyoのCo-chairを@amsy810と一緒にやっています ● DevOps Meetupで話すのは2回目かな？

Slide 4

Slide 4 text

Kubernetesクラスタいくつ欲しいですか？

Slide 5

Slide 5 text

自由に使える Kubernetesクラスタいくつ欲しいですか？

Slide 6

Slide 6 text

A. いっぱい欲しい

Slide 7

Slide 7 text

こんなん、なんぼあってもいいですからね

Slide 8

Slide 8 text

なんぼあってもいいKubernetesクラスタの理由 ● 気軽に作ったり壊したりしたい ● 周りを気にせず試行錯誤したい ● 用途を分けたい ● 障害時の影響範囲を分けたい

Slide 9

Slide 9 text

なんぼあってもいいKubernetesクラスタの理由 ● 気軽に作ったり壊したりしたい ● 周りを気にせず試行錯誤したい ● 用途を分けたい ● 障害時の影響範囲を分けたい Minikubeとかkindとかを活用どうする？

Slide 10

Slide 10 text

1つのKubernetesで複数用途に使う場合 (Soft Multi-tenancy) ● Namespace ● RBAC (ClusterRole/Role) ● Network Policy ● ResourceQuota ● Pod Security Policy

Slide 11

Slide 11 text

Soft Multi-tenancyのつらいところ ● 管理者による適切な管理が必要 ● Cluster-wideな Resourceの管理が難しい(CRD, Ingress controllerなど) ● Helm chartでポンとアプリを入れるのすら難しい ● 複数バージョンのCRDを扱うことができない ● Noisy neighborを完全に排除できるわけではない

Slide 12

Slide 12 text

じゃあKubernetesクラスタを分けちゃう (Hard Multi-tenancy) ● Managed Kubernetesで複数のKubernetesクラスタを作る ● Tanzu Kubernetes Gridを使う! ○ Cluster APIでポンポンクラスタが作れる

Slide 13

Slide 13 text

Hard Multi-tenancyの辛いところ ● オーバーヘッドがデカい ○ クラスタ分だけリソースが必要 ● 共通リソースのセットアップがめんどくさい ○ 各環境にIngress controller入れないといけないとか ● プロビジョニングにちょっと時間がかかる ○ 10分とか15分とか。すごく困るわけではないけど、カンタンに作ったり消したりは難しい

Slide 14

Slide 14 text

Kubenetesを使って Kubernetes立ち上げればいいのでは

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

DEMO

Slide 17

Slide 17 text

DEMOでやった内容あらかじめKubernetesクラスタを用意してあります。これは普段自分がいろんな用途に使っているクラスタです。これをそのまま流用します

Slide 18

Slide 18 text

DEMOでやった内容 vclusterコマンドでクラスタを作成します。 10秒も経たずにクラスタが立ち上がります

Slide 19

Slide 19 text

DEMOでやった内容 vcluster connectコマンドで接続します。立ち上がった KubernetesクラスタのAPIにポートフォワードが行われる他、繋ぐための kubeconfigが作成されます

Slide 20

Slide 20 text

DEMOでやった内容 kubeconfigを指定してkubectl get allしてみます。corednsのみが立ち上がっているまっさらなKubernetesクラスタが立ち上がりました。

Slide 21

Slide 21 text

DEMOでやった内容 deploymentでnginxを立ち上げ、type LoadBalancerでexposeしてみます。ちゃんと LoadBlancer作られてますね

Slide 22

Slide 22 text

DEMOでやった内容ちゃんと接続できました。 Kubernetesクラスタが1分も経たないうちに作成され、普通に使えているわけです

Slide 23

Slide 23 text

きっとここなら伝わるなるほど、”Nested”なクラスタが作れるんだね (VMware DevOps Meetup)

Slide 24

Slide 24 text

Nested Hardware Hypervisor VM Hypervisor Nested VM Nested VM VMを活用している人たちがイメージする Nested環境ってこんな感じですよね。 VMの中にさらにハイパーバイザを立ち上げ、 VMをネストさせる。

Slide 25

Slide 25 text

Nested Hardware Hypervisor VM Hypervisor Nested VM Nested VM 便利だけど無視出来ない速度低下便利な一方無視出来ない速度低下があり、検証用途にしか使えないイメージじゃないでしょうか

Slide 26

Slide 26 text

vcluster - No Performance Degradation ただ、vclusterは性能低下がないことをウリにしています。これはどういうことでしょうか。

Slide 27

Slide 27 text

vcluster vclusterのしくみ Host Kubernetes Vcluster Control plane vclusterを立ち上げると、ホスト側の Kubernetesにk3sという軽量k8s ディストリビューションの Control PlaneがPodとして立ち上がります。 k3sによって、もう一つの Kubernetesが生まれたわけで、上の箱にそれを表現しています

Slide 28

Slide 28 text

vclusterのしくみ Host Kubernetes Vcluster Control plane vcluster Namespace 1 Namespace 2 Pod svc Pod svc では、上の箱(仮想k8sクラスタ)にkubectlでPodを立ち上げます。仮想 k8sクラスタ側では当然、対象の NamespaceにPodやServiceが作られたように見えます。

Slide 29

Slide 29 text

vclusterのしくみ Host Kubernetes Vcluster Control plane vcluster syncer Namespace 1 Namespace 2 Pod svc Pod svc Pod svc Pod svc しかし、ここでsyncerというコンポーネントが動きます。 syncerはPodや Serviceの作成を検知すると、仮想 k8sではなくホストKubernetesのほうにPod, Serviceを作成します。実体はホスト側に出来るわけです。

Slide 30

Slide 30 text

vclusterのしくみ Host Kubernetes Vcluster Control plane vcluster syncer Namespace 1 Namespace 2 Pod svc Pod svc Pod svc Pod svc 実体がホスト側にあるが故に、仕組みとしては通常の k8sと同じであり、性能低下は起きないというわけです。 Pod間ネットワークも、ホスト側のものをそのまま使います。

Slide 31

Slide 31 text

DEMO もうちょっと実物をみてみましょう

Slide 32

Slide 32 text

DEMOでやった内容先ほどはvclusterコマンドを使いましたが、出力を見ると実際には helmコマンドを実行していることが分かります。これを直接実行してもクラスタが作れます。 helmで作れるということは、 ArgoCDなどで自動化も可能ですね。

Slide 33

Slide 33 text

DEMOでやった内容クラスタ作成時にオプションを渡すこともできます。先ほどのデモではport forwardでAPIに繋いでいましたが、みんなで使うには不便ですよね。port forward無しでkubectl叩きたい。この例では、 TLSのSANにFQDNを指定しています。

Slide 34

Slide 34 text

DEMOでやった内容クラスタ作成後、ホスト側で NodePort, LoadBalancer, Ingressなどを使って仮想クラスタのAPIをexposeします。今回はTLS passthroughを使いたかったので、 Contour のHTTPProxy(Ingressの高機能版)を使っています。 port forward無しでkubectl叩けるようになりました。

Slide 35

Slide 35 text

DEMOでやった内容先ほどと同じように、 nginxをdefault namespaceに作成して、LoadBalancerで exposeしてみます。ふつうに立ち上がってますね。

Slide 36

Slide 36 text

DEMOでやった内容ここでホスト側のKubernetesのPodを見てみると、vc3 namespaceにnginx, coredns, control planeが立ち上がっていることが分かります。仮想クラスタで作成されたPodは、ホスト側では全て同一の Namespaceに作成されるのです。

Slide 37

Slide 37 text

DEMOでやった内容新しいnamespaceを作成し、そこにnginxとLBを立ち上げてみました。仮想クラスタ側では当然指定したnamespace側に見えますが、ホスト側では vc3 namespaceにPod が作成されてますね。 pod名でどのns向けか判断できます。 LoadBalancerも同じようにホスト側に作成されているのが見えます。

Slide 38

Slide 38 text

手軽に動かせるので試してみて