カスタムコントローラは万能だからアプリケーションを作るためにも使える
View Slide
自己紹介name: 小林優吾org: 信州大学team: kstmgithub: koba1ttwitter: 0x6b6f62role: infrastructure engineer -> software engineerOS: "Arch Linux"2
1. 概要3
概要CRD+カスタムコントローラは非常に強力な機能- カスタムコントローラのReconciliation loop- CustomResourceDefinitionによるAPIの拡張4
Reconciliation loopDeclarative Managementの実装部分> 定義された状態になるように常に自律的に動き続ける>kubernetesの高い耐障害性や自動化を実現する部分5
APIの拡張独自のリソースをk8sのリソースと同等に扱える- kube-apiserverを使ったリソースのCRUD- etcdでリソースの永続化- kubectl,dashboardが使える- k8sのRBACを利用したアクセスの認可> あまり言及されないけど、とても便利https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/6
今回のセッションの趣旨私が構築、開発しているシステムが要件的にk8s上で動かすのが困難だった。CRDの利点を行かしてカスタムコントローラを1つのmicroserviceのように扱うことで困難だった点を解消して全体的にcloudnativeなアーキテクチャにできた。7
目次1. 概要2. 開発の経緯3. 構成の検討4. カスタムコントローラの実装5. システム全体の構成6. まとめ8
2. 開発の経緯9
状況大学で授業で使用するために、学生がブラウザから操作できるIDEとかのアプリケーションを提供してる--------->-> この演習を行う環境を作成、運用するためのシステムを作成することになった10> ソフトウェアを変更できるようにする必要がある
要件既存のソフトウェアをそのまま使用したい> プログラミングに使うCloud9> データベースに使うmariadb+phpmyadmin-> ユーザが1Serverを要求する感じになる11
ユーザが1ホストを要求する12
追加の制約このシステムの運用作業を行うのは1+1人しかもどちらも運用に専念するわけではない-> 可能な限り自動化して手がかからないようにする私は学生という性質上卒業というイベントがある-> (このプロジェクトが続けば)後任の学生が引き継ぐ-> 見通しが利くように構成したい13
3. 構成の検討14
kubernetesを使う上での課題1ユーザにつき1つコンテナを割り当てる機能はk8sには無い> 公式の機能では簡単に実装できない何らかのシステムをk8sとは別に作る必要がある--> kubernetesで作るのは向いていないのでは?15
kubernetesの利点- Auto-scaling- Self-healing- Scheduling- Portability> なんとかこの利点を生かして構築したい16
カスタムコントローラを使えば良さそうカスタムコントローラを使えばkubernetes上でかなり自由なことができるこれを使ってkubernetesに無い機能を実装すれば良さそう> ただ、全部の機能をカスタムコントローラで実装するのは複雑になる> かなりの回数くり返し呼ばれるからあまり複雑な処理はしない方が良さそう17
必要になる機能は...- ユーザ用のコンテナを作成し- ユーザを識別するための認証をして- ユーザのhttpアクセスをそのユーザ用のコンテナに流す18
正直kubernetesで上手く扱えなさそうなのはユーザごとのコンテナを作る部分だけここのみをカスタムコントローラにすれば実装が複雑にならなくて良い感じになりそう> 他の部分は普通に実装しても大丈夫そう> 認証部分とかproxy部分とかを柔軟に変えられる19
CRD+CC- 構成が複雑にならない- k8sのエコシステムに適合する- k8s本来の挙動から外れた使いかたにならない20
4. 実際の実装21
実際に作成した22
定義したCRDの内容`Template`と`Userland`の二種類のリソースを定義した- Templateで実際にどんなコンテナが必要か定義(実態はdeploymentのspec.template.specの定義をそのまま使ってる)- Userlandで使用するユーザのユーザ名(と対応するTemplate)だけを定義23
24
25
26
27
28
29
カスタムコントローラの実装- kubebuilderで実装コンテナの定義とユーザの定義を分けることでコンテナの内容(imageのversionとかconfigとか)の集中的な管理をしている-> ユーザごとのdeploymentの内容に差があると運用が大変になりそうTemplateリソースとUserlandリソースを見て、Templateリソースを元にusernameを入れたDepoymentとServiceを作成するだけの単純な動作をする30
システム全体で見るとcrdのリソースを操作するコンポーネントがあるmicroserviceっぽくなった31
5. システム全体の構成(例)32
33
34vscode-koba1t-svc.default.svc.cluster.localX-User: koba1tgithub.com/koba1t
35yamlで定義
CRDならSAで権限管理できるServiceAccountで権限を与える形式にすれば、最小限の範囲の権限にできる-> Templateを定義するリソースとUserを定義するリソース分離した-> ユーザ管理と作成されるコンテナの定義のための権限を分けることができる> ユーザを追加削除する権限で、作成されるコンテナの内容を変更されたくない36
proxyでリソース作るのならcrdは必要無いのでは?- proxyで作ったリソースを管理するのが困難になる- imageのアップデートとか- deploymentだけでなくserviceとかも必要だけどまとめて管理したい37
kubebuilderの不便な点内部的にcontroller-runtimeを使っている- crdのリソースをclient-goで使えない!!!!!!!-> https://github.com/kubernetes-sigs/kubebuilder/issues/1152-> kubebuilderでサポートする予定はないらしい-> コントローラ外からの場合でもcontroller-runtimeを使えば良いらしい38
6. まとめ- システム全体を良い感じに分割して構成できる気がする-> 結果的にmicroserviceっぽくなった-> 各コンポーネントも複雑なことをしていなくてシンプル- CloudNativeに適さないようなシステムだが、CRD+カスタムコントローラの活用でk8sに適したアーキテクチャにすることができた- カスタムコントローラはReconcile loop自体のメリットも大きいが、kubernetesのAPIの一部として扱うことができるメリットも大きい-> SAでのRBACだったり、api-serverを自前で用意しなくて良いのは便利 39
kubernetesに合わないようなworkloadだったり要望だったりがあるシステムでもカスタムコントローラを柔軟に活用すれば良い感じにCloudNativeなシステムを簡単に作れるかもしれない40
カスタムコントローラはできることも豊富だけどカスタムコントローラを使う方法も豊富で便利41
END42
koba1t
mongodb
kastner
ufuk
danielanewman
notwaldorf
roundedbygravity
lara
reverentgeek
tanoku
paigeccino
erikaheidi
thekraken