ぼくのかんがえるKubernetes(EKS)のツラミと理想のターゲット
Kubernetes（EKS）を業務で使い始めてほんの少し感覚が掴めてきました。いわゆる ダイニング=クルーガー効果 で言うところの カンゼンニリカイシタ！ というやつですね。
Kubernetes(EKS)はすごく強力な技術なのですがやはりツラミもあります。今回は触ってみて感じたツラミをまとめました。
技術導入を検討されている方への参考になれば幸いです。
前提
- 記事の内容は完全に私個人の意見です。
- ここの記事で記載している
Kubernetesとは主にAWSのEKS(またはその他のマネージド・サービスでのKubernetes)であり、自前運用の素のKubernetesのことではありません。- 自前でKubernetesをまるっと管理する場合にはここで書いてあること以上のツラミが出てくると思います...。
- ネガティブなポイントを多く記載していますが、これはEKSをディスりたいための記事ではありません。
- EKSは非常に便利で強力ですが銀の弾丸では決して無く、自分たちの目的に合う場合に使うのが良いということを伝えたいための記事です。
結論
長くなるので、結論としてはざっくり以下の感じです。
- Kubernetesを使うにはKubernetes以外の様々な技術スタックへの理解も必要
- 構築時にやることたくさんある
- 運用時にもやることたくさんある
- まぁまぁ固定費かかる
- よって、Kubernetesの本来の力を発揮できるサービス構成（いわゆるマイクロサービスなど）でのみ使うべきだと思う
- モダンという言葉に踊らされてはいけない
- 構築ではなく運用を見据えて検討すべき
ツラミ
1. 必要な知見の幅が広すぎる
Kubernetesを使ってシステム運用を行う場合、Kubernetesそれ単体では開発や運用はまわりません。例えばKubernetes上にアプリケーションをデプロイするためには、ArgoCDなどのデプロイツールを利用するのが一般的だと思います。
その他にもCNCFが提供しているKubernetesの周辺エコシステムやクラウドインフラ固有の知見が必要となります。
少し古い記事ですがこちらに周辺エコシステムがまとまっていました。 Kubernetesのエコシステム ー その他雑多
もちろんすべてのツールを使う必要はありませんが、「使わないと不便で開発や運用がスムーズにいかない」といった意味でいくつか導入する必要はあると思います。
例えば（個人的に）代表的なものだと以下のような技術スタックが必要になるかと思います。
- Kubernetes(EKS)
- Kubernetes標準機能
- クラウドインフラ特有の事項（例えばEKSであればIRSA, aws-auth, OIDCなどなど）
- Helm
- パッケージマネージャーは無いと辛い
- ArgoCD
- デプロイもKubernetes単体では管理するのが非常に難しい
- Istio
- アプリケーションが大きいのであればService Meshも導入したい
- Terraform(またはクラウドベンダーが出しているIaC)
- クラウドベンダーが提供しているKubernetesはmaster nodeをマネージドで管理してくれるが、自前でのリソース定義/管理はやはり必要
またKubernetes自体は非常に情報が揃ってきていますが、その周辺のエコシステムは基本的に情報があまり出回っていません。
1次情報収集（もちろん英語）は当たり前として、時にはツールの内部実装を見に行かないといけないケースもあります。
2. バージョンアップデートが頻繁にある
Amazon EKS Kubernetes バージョン を見る限り、EKSは約3~4ヶ月に1度バージョンアップデートがあり、それに追従していく必要があります。
またAmazon EKS 最適化 Amazon Linux AMI バージョンにあるように、EKS用のEC2のバージョン更新も頻繁に行われています。
*昨今ではFargateも出てきていますが、起動速度の問題や使用できるリソースに制限があることから、必ずしもFargateを使えるわけではないと思います。
その上、運用で使用しているその他のツール（HelmやArgoCDなど）のバージョンアップも必要です。Kubernetesもそうですが、その周辺エコシステムもバージョンアップの度に便利な機能がどんどんリリースされる（逆に言うとバージョンアップしないと不必要なワークアラウンドを強いられる場合もある）ので、追従していくことは重要だと思います。
3. クラウドインフラの固定費がかさむ
EKSではアプリケーションなどを動かすノード（EC2 or Fargate）単位でも費用が発生しますが、クラスターそのものの費用もかかります。
Amazon EKS の料金表 によると、
作成した個々の Amazon EKS クラスターについて、毎時課金 0.10USD されます。
とのことで、クラスター毎に$72/月かかります。
もちろんちゃんと構成するには環境毎（本番、ステージング、検証、etc.）にクラスターを分けますし、シングルノードで動かすことも少ないでしょう。そう考えると、EC2(またはFargate)に加えて固定費が追加でかかります。
おすすめしないターゲット層
ツラミで紹介した点を元に、おすすめしないケースをまとめました。
1. 人員/資金に余裕がない場合
既述の通り必要とされる知識の量が非常に多いこと、また頻繁なアップデートなどの対応を考えると、クラウドインフラ専任のチームが無くバックエンドエンジニアが片手間で構築/運用するのは非常に非効率であると思っています。
もちろん片手間でも構築はできるとは思いますが、安定運用できず障害発生率が以前より上がったり、各種ツールのバージョンアップなどができておらずセキュリティリスクを抱える、といった結末になりやすいかなと思います
クラウドインフラやコンテナのメリットとしてimmutableな環境構築が手軽にできることであり、インフラリソースが状態を持つことはアンチパターンとして扱われています。状態を持つことによりリソースの入れ替えなどが難しくなり、せっかくのメリットが台無しになります。
また費用削減のために1クラスター上にnamespaceで環境を分割するようなことは絶対におすすめしません。
2. システムアーキテクチャがプロダクトの競争優位性に寄与しずらい場合
一般的な構成のwebサービスにとってはEKSはオーバースペックであると思っています。世間がクラウドネイティブだ何だと言ってるからといって、無理してナウでイケてる方式を採用する必要はないと思います。
特にコンテナを採用する方針であれば、AWSであればECSがあります。つい最近ではECS内のコンテナにアクセスするための機能がリリースされ、進化がかなり速いです。
NEW – Using Amazon ECS Exec to access your containers on AWS Fargate and Amazon EC2
「EKSでサービス展開してるけど、シングルノードです！」みたいなのは本当に宝の持ち腐れだと思うので、よりコストパフォーマンスの良い技術スタックを使うのが良いのではないかと思います。
このtweetがすべてを物語っています。
おすすめするターゲット層
おすすめしないケースに当てはまらない条件の上で、以下の条件にマッチする場合にはEKSを最大限に有効活用できるのではないかと思っています。
サービス全体の複雑度が高い場合
マイクロサービスがその代表例だと思います。 そもそもKubernetesが生まれた背景には複雑化するコンテナ管理があったと思います。
数十/数百のシステムが連動しているような、巨大なサービス群を管理するには非常に強力な技術だと思います。
とまぁ「それ知ってる」という感じの内容だったかもしれないが、ほんとそのとおりだと思います。
モダンだの何だのという言葉に踊らされず、地に足つけた技術選定が必要だと思います。
雑感
EKSは本当に強力な技術だけど、その分使うの難しい
Discussion