k8s概要
- Googleのborg
- コンテナオーケストレーションシステム
- 2014年公開、2016年にv1.0のproduction ready
なぜk8sを使用するべきじゃないのか -> なぜコンテナなのか
スタートアップの課題
生産性が上がらない。
組織が大きくなると、チーム間の調整コストが高くなり、意思決定の摩擦、プログラミング言語の相違、宗教戦争を持ち出すetc...いろんな人がいる。エンジニアが足りない。人件費が高騰。この流れで、マイクロサービスアーキテクチャ、リモートワークが最近流行っている感じがする。
マイクロサービスアーキテクチャにすると、機能毎ではなくサービス毎に同期し、サービス間はAPIを使用し疎結合にして、チームが独立して働くことが可能になり、上記の解決になるのではないか、そういう文脈で取り上げられている。
リモートワークは分散チームの流れで、Slackやコミュニケーションツールを使用し、Githubだけで開発する会社も出てきた。これらツールが増えてきたおかげで、必ずしも東京にチームがいなくても同じサービスをみんなで作ることが出来るようになった。エンジニアが足りない問題を解決するのではないか？
我々はコンピュータ上でビジネスをしている以上、作ったソフトウェアをコンピュータ上で動作させる事は絶対避けて通れないので、それをどの抽象レイヤーでやるか。
仮想マシン、コンテナ、etcそれらの違いはそもそも何？
バージョンサービスアーキテクチャだと、仮想マシン、コンテナ関数そんな違いがある。
仮想マシンは、物理マシーンで動いているが意識することは少ない。
1マシーンで複数プロジェクトで動かしたりして、複数チームのサービスが1つの仮想マシンにうっかり乗ってしまい、「この機能だけこのサーバーが停止している、個別にスケジューリング出来ると嬉しい」とか、そのようなモチベーションが高まり、コンテナをやりたいとなる。
コンテナはコンテナイメージから作る。仮想マシンと似ている。物理マシーンか仮想マシン上でコンテナは動作する。上記のような事象はコンテナでも起こりうるが、VMと同じように、この機能だけコンテナを分割したいとなる。
その先にあるのは関数。スクリプトやバイナリから関数と呼ばれる単位でデプロイする。それらは、LambdaといったPaaS上で動作する。関数になると上記のような事象はない。
関数をデプロイの単位とした。それまでは違っていた。
マシーンにデプロイしたいのは、application bundle。これまでの悩みが解決される。
PaaSで済むならPaaSがベスト。
何で今更関数ではなく、コンテナなのか
運用ツールの違いからわかる。
仮想マシンはイメージから物理マシンで動作するので、コンフィグレーションマネジメントchef、ansibleを使用してインフラコードで運用する。
コンテナイメージは物理・仮想マシンで動作するので、Docker・ECS・k8sで運用する。
関数は作成してバイナリ化して、動作するのは、仮想マシン、コンテナ、Lambda、OpenFaaS、etc...
関数の管理はどうしたらいいのかわからない。
関数のオーケストレーションシステムの最適解はまだない。
だから個人的にはコンテナを使用している。
ツールが少なくて運用が大変だから。逆にツールが揃ってなくても問題ない小さなマイクロサービスであればどんどん使用するべき。
上記を使用基準にして欲しい。
コンテナオーケストレーションはなぜいるのか
コンテナをデプロイするのにsshだけでは済まないから。
コンテナが落ちた時に他のノードに自動移動したい場合、
EC2であればAutoScalingGroupがあるが、コンテナの場合は？
コンテナをロードバランサーにつなぎたい場合、
EC2であればALBがあるが、コンテナの場合は？
サーバーのリソース内でコンテナ数を増やしたい場合、
AWSであれば、小さいEC2インスタンスを並べてASGでオートスケーリング出来るが、コンテナの場合は？
AWSのコンテナオーケストレーションはECSとk8sの2つのソリューションがある。
ECSは、コンテナデプロイだけだったが、今は下記の機能が増えた。
初期にIAMロール対応し、同じインスタンスに違うIAMロールのコンテナが動作可能。
コンテナのヘルスチェック。
サービスディスカバリ（LoadBalancer）。
k8sも同じ。
運用面では違いがある。
ECSでは、AMIがあるので、DockerとかECSエージェントの相性が良いかのデバッグしなくても良いので、ビジネスに集中出来る。
k8sだと自分達で選定しないといけない。
ECSは、大きな会社で大規模なECSクラスタを構築している事例があり、それを運用するOSSツールも公開してくれている、日本でも採用事例が多いので、トラブルシューティングしやすい。機能も少ないのもいい(機能が増えるとアップグレードが大変だから)
k8sは、専用AMIはない、マネージド・サービスもない、日本での採用事例がない、情報が少ないのでデバッグも大変、k8sを使える人材を育てるのも大変。
k8sは、ECSより機能が多い。
k8sの機能
コンテナデプロイ
サービスディスカバリ
ロードバランサー
kubectl: fruentd,sshコマンドみたいなやつ
helm: パッケージマネージャー(wordpressをコマンド1発で入れたり出来る)
k8sを構築するのは大変だが、便利なAPIがたくさんある。
ｋ８ｓはlinuxに例えられる。
k8sのAPIはlinuxのシステムコール。
k8sのシステムもk8sのAPIをコールするようにGolangで実装されているので、
自分達でAPIを使用してk8sを実装することも可能。
それらをサポートする便利なライブラリもあり(nodeｊｓ，java,golang)、
認証やバリデーションやDBにもなりうる。
豊富な周辺ツールもある。
メタコントローラー: bluegreenデプロイ出来るもの
squash: デバッガー(エラーが起きた時どこのコンテナが何でエラーが発生したのか把握するのに便利)
k8sの使い所
コンテナの運用は勝手にやってくれる。
Lambda、ECSより汎用的。
コンテナの運用を自動化したい。
k8sのAPIとSDKがあり、他のクラウドで作成されたツールをそのまま適応出来るので、自分達で作り込まなくてもちょっとしたPaaSみたいなものは作成出来る。
コンテナオーケストレーションというより、分散システムフレームワーク。
k8sで動作するFaaSもある。
PaaSで済まないならk8s上でFaaSを選ぶのもあり。
そのぶん激しく学習コストが高い。
Linuxをすべてわからないのに使用しているのと同じように、k8sを使用するとはそういうレベル。
コンテナをプロセスと見立てると、linuxはk8s。裏でEC2インスタンス何千台あるか不明だが、１つのPCと見立てた時に、OSはk8sで、システムコールはAPI。
躊躇するなら採用はするな。
freeeでの利用例
新規サービスはk8s化。
既存サービスはまずDocker化から、必ずしもk8s化しない。
目的は運用の効率化なので、既存が自動化されているなら、無理にk8sする必要はない。
新規サービスは自動化する暇がないので、最初からk8s化。
しかし、学習コストが高いので、オンボーディング勉強会を開催している。
可能な限り作り込まない。
k8sで動作するPaaSはないので、自動化する余地があるが、ツールを作るリソースはないので、自社で開発することはせず、OSSのメンテナーになるとか、メジャーなOSSを使用するとか、自社で持たず自動化を進めている。
EKS
k8sのコントロールプレーン(etcd,k8sのsystemとか)をマネージドするサービス。
EC2は自分で用意する。
k8sの封鎖された内部ネットワークがVPCでマネージドされる。
GCP、Azureだったらフルマネージする(但しカスタマイズ性が制限される)
未来の話
k8sが規格化されてくる。
k8sクラスタの運用が楽になってくる。
デバッグツールなどが増えてk8s上のアプリの運用が楽になってくる。
我々が求めるものはサーバーレスだけど、裏側はk8sだったりするかも。
まとめ
抽象レベルを意識できるように
正しいツールを選べるように
k8sは銀の弾丸ではない
コンテナだったらコンテナオーケストレーション
ファンクションの運用の選択肢が定まったら...？
将来的にk8sになっていくので、学習目的なら早めにやっといて損はないが、ビジネス利用が計画的に。