Kubernetes Casual Talk: Custom Controller in CyberAgent

Transcript

1. Kubernetes Casual Talk
 カスタムコントローラ CA 編
 2022/02/24

2. Katsuya Kawabe @KKawabe108 • CyberAgent group Infrastructure Unit ◦ ソフトウェアエンジニア ◦ プライベートクラウドのサービスを作っています • 趣味 ◦ 音楽、漫画、スノボ
3. CIU でのカスタムコントローラ
 AKE ML Platform GKE のような Kubernetes as a Service Cluster API という Kubernetes が Kubernetes を作る仕組みを利用しています オンデマンドでユーザに GPU 付きのコンテナを払い出したり、 学習したモデルをワンコマンドで外部向けにデプロイできるような基盤 モデルの払い出しに応じて LB と証明書を払い出したりするようなコントローラを作っ たりしています
4. CIU でのカスタムコントローラ
 AKE ML Platform GKE のような Kubernetes as a Service Cluster API という Kubernetes が Kubernetes を作る仕組みを利用しています オンデマンドでユーザに GPU 付きのコンテナを払い出したり、 学習したモデルをワンコマンドで外部向けにデプロイできるような基盤 モデルの払い出しに応じて LB と証明書を払い出したりするようなコントローラを作っ たりしています 今回は時間の都合で AKE に焦点を当てていきます
5. Cluster API で作る KaaS

6. Cluster API で作る KaaS
 https://cluster-api.sigs.k8s.io/image s/management-cluster.svg Cluster API 本体が用意するリソー スとコントローラ と Provider ごとのリソースとコント ローラが協調して Kubernetes を作 り上げる複雑なシステム
7. Cluster API と Provider の OwnerReference
 OpenStackCluster OpenStackMachine Template OpenStackMachine Cluster KubedmControlPlane MachineDeployment MachineSet Machine KubeadmConfig Template
8. Cluster API と Provider の OwnerReference
 OpenStackCluster OpenStackMachine Template OpenStackMachine Cluster KubedmControlPlane MachineDeployment MachineSet Machine KubeadmConfig Template 🤯 とにかくリソース関係が複雑 🤯
9. Cluster API と Provider の OwnerReference
 OpenStackCluster OpenStackMachine Template OpenStackMachine Cluster KubedmControlPlane MachineDeployment MachineSet Machine KubeadmConfig Template リソース関係は複雑ですが Provider ご との実装はこれらのリソースと Controller さえ実装すればいいのでそこまでコスト はかからない どのパラメータを実装すればいいのかも公式ドキュメントに あるよ！
10. Cluster API OpenStack Provider のコントローラ
 OpenStackCluster OpenStackMachine Template OpenStackMachine - セキュリティグループの調整 - コントロールプレーン用の外部 LBの調整 ← AKE Original - ネットワーク、サブネットの調整 - サーバグループの調整 ← AKE Original - VM に紐づくポートの調整 - VM に紐づくボリュームの調整 - VM の作成、削除 - cloud-init の調整← AKE Original
11. Cluster API を改造したメリットとデメリット
 • OpenStack や物理 LB の API の挙動把握 ◦ どういうエラーが返信されるのか ◦ 冪等性はあるのか ▪ 担保されていない場合は Controller の実装で保証してあげなきゃいけない • リソース同士の依存関係 ◦ 特定のリソースのフィールドが別コントローラによってセットされたりする ◦ 中途半端に子のリソースだけ削除するとクラスタごと作り直しになったり しかし、 • 元からあった OSS をベースに実装できたのである程度の品質を最初から担保できた ◦ OpenStack のラッパー部分や基礎的なコントローラ • メンテが活発なので不具合修正などもチェリーピックしやすい ◦ とは言っても基礎的な部分はほぼ完成してるのであんまない ◦ 逆にコントリビュートしたことはある (Port の GC 周り) • 何より OpenStack Heat をデバッグしなくていいのは本当に楽
12. Thank you for listening