inductor's blog

nothing but self note :)

EKS(or Kubernetes on AWS)本番運用で導入を検討すべきな追加コンポーネントについて

はじめに

Amazon EKSを初期導入すると、最小限の構成でクラスターがセットアップされそのままの構成で本番運用をするのはとてもじゃないが厳しいみたいな状態になっています。

これには運用者が柔軟にミドルウェアを選定できるというメリットもありますが、そもそもどんな選択肢があるんだっけみたいなところまではちゃんと整理できていないと思うので、ここでは僕が考える入れておくべきアドオンについて今後のために整理しておきます。

github.com/aws/eks-charts を眺める

とりあえず脳死でこのサイトに行き、自分に必要そうなものを眺めることにします。Helmを使ってインストールするかどうかはさておき、それぞれのツールの必要性について検討しようという話です。

github.com

App Mesh関連

App Meshを使ったサービスメッシュをやっていきたいのであればこの辺のコンポーネントは過不足無く便利そうです（未検証）

AWS Node Termination Handler

スポットインスタンスを強気で導入したいという構成の場合、このアドオンは必須かなと思います。そうじゃなくともEC2のメンテナンスに起因するVMのシャットダウンや、ASG(Auto Scaling group)のイベントもフックできる便利くんなのでCluster Autoscalerと一緒に入れておくといいですね。

↑と思っていたが、マネージドノードグループを使っている場合はNTHは入れなくても良いらしい。スゴイぞMNG!!

AWS CloudWatch Metrics 及び AWS for Fluent Bit

CloudWatch関連とかそういうの。メトリクスをContainer Insightsとかであれこれしたいのであれば入れておいたほうが良いやつですが公式の手順にはHelmのほうが大々的には載っていないのでここにあるの知らなかった。

AWS Load Balancer Controller

自分的にはとりあえず脳死で入れておきましょう的やつ。ALB Ingressが便利というよりは、NLBのIPモードに対応しているのでContourやNginx Ingressなど他のIngress controllerを入れる場合だとしてもコンテナネイティブロードバランシングが使えるようになるのが便利。あとはKubernetesのin-tree AWS Service controllerがいつなくなるかもわからないので早めにこっちに移行しておきたいというモチベーションもある。

AWS VPC CNI

これはEKS Add-on側でもよくね？とは思うけど、環境変数をあれこれいじりたいって場合はHelmで管理したほうが捗るかもしれない

AWS SIGv4 Proxy Admission Controller

自分が使うケースは今までないんだけど、例えば何らかのAdmission webhookとかを共通で挟むって場合でAWSのAPIを独自処理で叩くって場合にはこのProxyがあると便利っぽい。なのでそういう要件があれば導入を検討してよさそう。

↓に便利なトリがいます。

Cluster Autoscaler on AWS

github.com

むしろこれはなんでHelm chartのところにねえんだって思う感じだけど、多分SIGに集約されてる関係かな。これもEKS側でサクッと入れられるようにしてくれると便利なんだけどな。

EC2ベースのクラスターの場合、基本的には入れておいたほうが便利なやつ。これがあるとNodeのキャパに対してPodの要求リソースが明らかに超過している場合オートスケールがバチッと走っていい感じにスケールできて「クラウドを使っている！」という感じになるので良い。

ただコントロールループ依存なのでめちゃめちゃ速やかなスケーリングって感じではない。Fargateとかと大きくは変わらないので、基本的には余裕のあるキャパシティ管理を用意しておくべき。もしくはHPAをいい感じに設定しておく（そもそもそれが難しいのでみんな苦労しているという話）

さいごに

まあ、ざっくりEKSだけで見るとこんなもんかな。他にも入れるべきものってのはたくさんあると思うが、EKSだけじゃなくKubernetesとして、みたいな話もあるので、今回は割愛してEKSに入れておくと便利そうなものをざっくりとピックアップした。

では、今日はこのへんで。