概要
EKSを触るなどした際のメモ
EKSとは
Elastic Kubernetes Service。AWSのマネージドKubernetes
はじめる
eksctl コマンドを使うと一発でクラスタとワーカーが立つ
$ brew install eksctl $ eksctl create cluster --name test
作成されるリソース
裏ではCloudFormationが動いて、イチからリソースを構築してくれます。
イチからというのはVPCやIAMのような、K8sではなくAWSサービスのリソースからです。
デフォルトだとVPC、EKSクラスター、EC2( r5.large )を2台を立ててくれます。
これはeksctlのオプション次第で変更できて、既存のVPCに参加させたりすることが可能です。
"cluster"と"nodegroup"という2つの単位で構築してくれることがポイントになります。
それぞれCloudFormationのスタックとして別れていて、個別に立てることも可能です。
"cluster"が指すのはVPC・EKS用IAM・セキュリティグループ・EKSクラスタです。
"nodegroup"はセキュリティグループ・EKSワーカー用IAM・起動テンプレート・オートスケールグループです。
料金
2019年6月時点
- EC2: $222.54
- r5.large($111.27) x2
- EKS: $144
GKEならミニマルなクラスタを $0 で構築できるらしいですよ。
おわる
サブコマンドの delete を使うことで作成されたリソース群を全て削除してくれます。
eksctlの実体としてはCloudFormationなのでスタックを削除するだけですね。
$ eksctl delete cluster --name test
所感
GKEと異なりAWSのインフラな領域（IAM, SecurityGroup,...）を意識しない点があるなというのが一番言いたいことです。
ECSもコントロールプレーンとデータプレーンの管理が分離されていて、EC2クラスターをゴリゴリ管理する必要がありますね。
EKSも同じようにコントロールプレーンとデータプレーンが分離されているのを感じます。
K8sの領域だけじゃなくAWSのインフラな領域を意識しないといけないのは当たり前といえば当たり前なのですが、IAMとRBAC・VPCとNetworkPolicyなど、わりと似たような責務を持ったリソースを意識しないといけないのがしんどいですね。
「とりあえずKubernetes触りたいんだ〜」というモチベーションならGKEを触ると良いのかなと。
あえてEKSを使うのは管理しなければいけない領域が広いので、AWSをあえて選ぶ理由はAWSの豊富なマネージドサービスや既存の資産の都合だったりしないと選べないのかなーと。
最終的にクラスタアドミンが出てきて、複数のサービスやチームが1つのクラスタの上で動かすようになってやっとうまみが出るんじゃないんだろうか（個人の意見）
