カスタムコントローラは万能なのでアプリケーションを作るためにも使える

Transcript

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