☺️

kubernetes(EKS)への憧れ

2024/03/26に公開

AWS

はじめに

私はAWSメインのインフラエンジニアであることと、まだAWSにEKS(Elastic Kubernetes Service)が無かった時代からECS(Elastic Container Service)を利用しており、ECSの経験しかありません。

インフラエンジニアとしてkubernetes(以降k8s)の知見がないというのは、なんとなくコンプレックスを感じており、Kubernetesの知識地図といった書籍でお勉強中です。

なお、ECSとEKSの違いについてはこちらの記事ですごくわかりやすく整理していただいていました。

本記事では、ECSしか使ったことがない者からみた、ECSからEKS(=kubernetes)へ移行したいと思うモチベーション要素をいくつか紹介したいと思います。

モチベーション要素

永続ボリュームの存在

現状ECSでコンテナオーケストレーションを行い、データプレーンはFargateを利用しています。

そして、監視はPrometheus + Victoria-Metrics , Grafanaで行っているのですが、これら監視の仕組みはすべてEC2で稼働させています。

理想的にはPrometheusなどもすべてFargateで稼働したかったのですが、ECSには永続ボリュームがありません。

EFSを利用することでNFSを永続ボリュームとして利用することは可能ですが、Prometheusでは明確にNFSはサポートしていない、使うなと言っています。

CAUTION: Non-POSIX compliant filesystems are not supported for Prometheus' local storage as unrecoverable corruptions may happen. NFS filesystems (including AWS's EFS) are not supported. NFS could be POSIX-compliant, but most implementations are not. It is strongly recommended to use a local filesystem for reliability.

そこで仕方なく、EC2で、さらに冗長化のためEC2 2台での運用を余儀なくされています。

kubernetesではどうかというと、kubernetesには 永続ボリューム(persistent-volumes) という種類のボリュームがあり、コンテナから永続的なデータストアを利用することができるようです。

つまり、

EKSであればPrometheusなどを含めてすべてFargate化し、脱EC2ができる可能性がある

というのが1つめのモチベーション。

HelmやOperatorの存在

Helmによるパッケージ化やOperatorによる自動化の仕組みによる効率的な構築・運用ができるイメージです。

Helm参考

https://helm.sh/ja/

Operator参考

PrometheusもHelmのchartが提供されていますし、Operatorもメンテナンスされ提供されているものがあるようです。

こちとらEC2なのでChef(CINC)で頑張って構築しているのですが、うらやましい。

スキルの汎用性

ECSはAWSでしか使えません。kubernetesはデファクトスタンダードであるため、その生みの親とも言えるGoogleのGCPでは当然マネージドサービスとして利用できますし、Azureでも、OCIでも、どこでも利用できます。

スキルの汎用性が高い点が、エンジニアとしては羨望の眼差しを送るに値する技術だと思います。

最後に

3つしかなかったですが。。

ECSが悪い訳では全くなく、ECSはEKSのように定期的なk8sのバージョンアップに振り回されることもなく、AWSサービスとのスムーズな連携、シンプルな構成といった点で素晴らしいサービスです。

ただ、特に「永続ボリューム」についてECSで提供されることになれば最高だなと個人的には期待しています。

kubernetesにはそれはそれで利用している方にしかわからない苦労があると思いますが、今のところは引き続き憧れていたいと思います。