この記事はCyberAgent Developers Advent Calendar 2018の21日目の記事。
Docker/Kubernetes 実践コンテナ開発入門（技術評論社）が大ヒットした１年であるが、最近ではコンテナに関してはそれほど興味もなく、モトブログばかり見ている@stormcat24です。著書においては付録でAmazon Elastic Container Service(ECS)について軽く紹介しているが、当時はEKSが東京リージョン未サポートされてなかったためスルーした。
この度めでたく東京リージョン着弾ということでEKSについて雑な所感を書く。
クラスタ作成地味につらい
とりあえずクラスタ作成はMangement Consoleからポチポチやっていく。現時点で、Kubernetesのバージョンは1.11までサポートしているのは良い。バージョンの追従は大変だと思うが、特にインパクトのあるバージョンの投入は他のマネージドに大きく遅れないようにしてほしい。クラスタができるとMasterのEndpointやCertificate authorityが表示されるので、これをkubectlで利用できるように~/.kube/configを編集すれば、普通にクラスタの操作はできるようになる。
個人的に大きく違和感を感じたのが、クラスタ作成のチュートリアルにおいてWorkerノードを作成できないことだろうか(GKEでいうとこのNodePool）。てっきり最初の段階でデフォルトのノードを起動するためのAutoScaling Groupを設定できるのかと思っていた。EKSにおいてはあらかじめ用意されているCloudFormationのテンプレートでWorkerノード（つまりEC2インスタンス）を作成し、クラスタに追加することができる。サンプルのテンプレートを利用し、AutoScaling Groupを設定していくのだが、なんだろうこの釈然としない感じは・・・。CloudFormationを普段使いしてないプロジェクトだとツラミある。
CloudFormationによる柔軟なカスタマイズが可能な反面、クラスタの作成とWorkerノードの追加の手順に直感性が無いのは本当に良くないて十分に初見殺しだと思う。AWSに精通していればまだしも、一介のデベロッパーが軽い気持ちでKubernetesクラスタを立てよう！ってなった場合、これは普通に利用障壁になると思ってる。
Workerノードの作成を楽にするというよりも、Fargate化を強く推し進めて欲しい気持ちもある。
雑所感
と、ここまではなかなか辛辣にならざるを得ないのだが、クラスタが作成さえできれば普通のKubernetesと同様に利用できる。つい最近ALBも統合して利用できるようになった。「Docker/Kubernetes 実践コンテナ開発入門」でGKEでやったサンプルアプリのくだりも（脳内でEKSで変換してもらえれば）普通にできるようになってるので、暇な人は試してみてほしい。
個人的にEKSで一番良いと思っているのがAmazon VPC CNI plugin for Kubernetesだ。CNI(Container Networking Interface)はいわゆるノード間でoverlayネットワークを構築するための仕様であり、代表的な実装はflannelだったりWeaveだったりがある。非マネージドのAWSでKubernetesクラスタを利用していたときはflannelを使っていたが、若干不安定な面があった。Amazon VPC CNIの何がうれしいかというと、VPC Network上でのIPアドレスをそのまま使えるということにほかならない。設計・運用上ともに見通しが良くなることは間違いないし、何より直感的。
GCPよりAWSを利用したいというときのモチベーションの一つに、豊富なサービスを選択できるということがあると思う。データストア周りはGCPもSpannerやMemorystoreの登場で充実してきたが、多くのマネージドサービスについてはまだAWSに利があるとは思っているので、肝心のコンピューティングリソース分野で強みを出していってほしいお気持ち🙏