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