人はなぜk8sを初め、そしてやめるのか
Mediumをみていたら、Kubernetes(以下、k8s)をやめたらDevOpsチームが幸せになった、という記事をみつけました。
有料記事なので詳細には触れませんが、記事を読む限りはk8sというインフラがチームに合っていなかったことは明らかだと思いました。
一般的にK8sは開発者の視点ではオーバースペックに感じることが多いと思います。
もし開発者自身に決定権があれば、CI/CDを考慮しても、本番サービスはECSやApp Runnerなどで提供した方が楽になるでしょう。
しかしK8sを喜んで利用する人達はそういう次元では考えていないと思います。
K8sの利点
K8sはフルスタック・インフラエンジニアにとっては魅力的で実際に便利なツールですが、その観点では次のような特徴が魅力的に映ると思います。
- 物理サーバーの統合
- アプケーションの集約
- ネットワークの統合
物理サーバーにはOSの管理コストやストレージ装置を含みます。
アプリケーションの集約には、複数のアプリケーションの共通部分をマイクロサービスのような形で実装・利用するといった変更を含みます。
最後のネットワークの統合というのはL2やL3レベルの機器統合だけではなく、ロードバランサーやL7レベルのFirewall/WAFやnamespaceによる通信の制御といった点を含みます。
完全仮想化によるOSレベルの仮想化は、OSレベルの管理コストが物理機器と同様に必要になるので、コンテナレベルの仮想化を選択するニーズに変化はないと思います。
しかしコンテナツール(docker/podman)の延長線上にあるECSのようなサービスを選択する余地があるのであれば、ほとんどの場合はそれが最適でしょう。
あるいはオンプレミスk8sクラスターをまったく持たずにEKSやGKSだけを利用するのであれば、ECSのようなサービスでほとんどのニーズは満たせるように思えます。
K8sの利用というのにはもう少し経営的な理由が含まれると思います。
K8sが向かない用途
反対に次のような利用方法では問題になるでしょう。
- アプリケーション単体を動かすプラットフォームとしてk8sを利用する
- 部署やチーム毎にK8sクラスターが存在する
- スケールアウトしないからベアメタルサーバーが使いたいのに、K8sを選択する
- ミッション・クリティカルな業務アプリケーションの稼動
私はDevOpsという言葉は嫌いですが、デリバリー・チームがリードせずに、開発チームが主体となる点に多くの問題があると思います。
よほど大規模にならないとベアメタルDBサーバーのようなものは不要だとは思いますが、それが必要であればK8s上で代替手段を確保することは難しいでしょう。K8sのノードに登録したところで専用サーバーとしてノードを指定してPodを動作させることになって余計に煩雑でしょう。
セキュリティの観点からドメインを分離したい気持ちは理解できますが、顧客やアプリを別々のクラスターに分散させてしまったことで、統合・集約というk8sのメリットを十分に引き出せなかったのではないでしょうか。
またミッション・クリティカルな業務向けのアプリケーションであれば、不確定要素を削除することも大切で、抽象度の高いインフラの選択にはリスクを詳細に分析することが必要になります。この観点ではECSなども同様に不適かもしれません。
High-Availability(HA)構成で十分な用途であれば、k8sは最適なインフラになるでしょう。
k8sを初めて、そしてやめてしまう理由
始める理由はそんなに深刻なものではないのだと思います。流行っているということもあるでしょうし、GoogleのBorgが元になっていることなど、関心が高いことは間違いありません。
コンテナ・オーケストレーションという概念が、DevOps開発において重要であるかのように喧伝されていることも大いに影響していると思います。
関心の高さや、CI/CDとの関連からk8sに手を出してしまうのだと思いますが、やめてしまう背景には開発チームがk8sの運用面に手を出してしまう点にもあると思います。
Mediumの記事を書いたチームが幸せになった理由には、k8sをやめた事ではなく、本番環境のインフラを1つに統一した事が本当の理由ではないでしょうか。
本来は規模の大きなk8sクラスターの中に、自分たちが強みを持っているビジネスロジックを共通コンポーネントとしてデプロイし、それらを利用する個別アプリケーションを別々のnamespaceにデプロイするべきだったのだろうと思います。
共通部分のほとんどないアプリケーションを分散したk8sクラスターにデプロイしたとしても、幸せにはならないだろうなと記事を読みながら感じたところです。
開発チームが主体となってK8sクラスターを管理することは問題か？
一般的にK8sは複雑なシステムだといわれています。そう感じる理由には「アプリケーションを安定稼動させる」という目的からは過剰に思えるような選択肢が用意されていることがあると思います。
K8sを導入して幸せになる組織
まず組織のインフラ基盤として自社のためにk8sクラスターを整備することには多くのメリットがあります。
デリバリー・チームがk8s環境を整備し、利用できるMiddlewareやストレージ基盤、他のサービスを整理して開発チームに提供することで管理コストを下げることが可能になります。
従業員の認証基盤をk8sのサービスとして共通利用するといった統合化はセキュリティ上だけでなく、全体最適を促すため経営的な観点でも理想的といえます。
開発チームは自由な選択肢を失いますが、本来あるべき姿とはそういうものです。
K8sを導入しても幸せを感じられない組織
反対に必要に応じてアプリケーションを様々な会社から購入するような組織であれば、k8sを整備しても購入先の選択肢が狭まってしまいメリットがないでしょう。
またSIerのような受託開発を行うチームや組織がK8sを利用することにも、CI/CDの恩恵はあると思いますが、本番環境をk8sにするメリットはあまりないと思います。
いずれも完全仮想化の方が幅広いニーズに素早く答えられるはずです。
K8sをやめたくなる組織はDevOpsチームといっても、実際には受託開発をメインとするような業態ではなかったのかなと思われます。
認証基盤やストレージ装置の統合といったニーズがなく、もしセキュリティ上の理由で環境を分割するように求められるのであれば、サーバーの統合といった本来のメリットはそのままデメリットになってしまいます。
さいごに
K8sはとても便利なインフラ環境ですが、同時に難しさも感じています。
例えばLAMP環境での動作を前提としているようなWebアプリケーションや、フレームワークはスタンドアロン型での動作に最適化されていて、マルチテナント型システムでの動作に対応していない場合があります。
ホスト名やURLパス(context-root)の専有を必要とするWebアプリケーションは有名、無名を問わず多く存在します。
またJavaは総合的にすばらしいエコ・システムを提供していますが、コンテナにはJavaランタイムを含めなければいけないため、イメージに数十MBのオーバーヘッドが存在します。
1サーバーで複数JVMを起動する時のメモリコストが問題だった時に、ライブラリの共有化が行われた時の状況に似ているかもしれません。
またDevOpsという言葉があまり好きではない理由は、Dev"→"Ops というフローを感じるからです。
オペレーションの最適化のために開発チームが力を発揮するべきだと思うのですが、工程の上流側にあることで運用チームが開発チームの決定を受け入れなければいけない場合がまだ多いのではないでしょうか。
これはある種の文化ですが、O'Reillyから出版されている「SREの探求 (Seeking SRE)」ではSREチームへの権限の委譲、運用メンバーのエンジニアリングチームへの参画など、運用重視による全体の見直しがキーであることは繰り返し述べられています。運用チームの最適化がSREやDevOpsのポイントでは決してありません。
開発者のk8sに対するネガティブな反応は、本能的に自分達の活動に制約が導入されることに気がついているからかもしれません。
いっそk8sの運用に最適化した形で組織体制を刷新できれば良いのですが、それは革命であって感情面も含めてチームがバラバラになってしまいます。
メンバーの協力を得て穏かな体制の転換を徐々に図るようなk8sの導入や浸透を模索していって、開発者が喜んでk8sを導入するようになって欲しいです。
TODO: Qiitaに投稿するならコードをきちんと含めること