元 Azure エンジニア視点で気になった Amazon EKS の特徴

下記の特徴ドキュメントから、Azure Kubernetes Service (AKS) と比較して Amazon Elastic Kubernetes Service (Amazon EKS) について気になった部分を記載します。

https://aws.amazon.com/jp/eks/features/

## AKS と同様の機能

### コントロールプレーンの自動管理

マネージドなクラスタなので当然ではあると思いますが、下記の記載がありましたのでコントロールプレーンは自動管理されます。

> Amazon EKS は、Kubernetes API サーバーと etcd 永続レイヤーの可用性とスケーラビリティを自動的に管理します。

### クラスターのインプレースアップデート

クラスターの Kubernetes のバージョンを上げる手段もあります。

> Amazon EKS は、アップデート作業を管理することなく、実行中のクラスターを、最新バージョンの Kubernetes に簡単にアップデートできます。Kubernetes バージョンのアップデートはインプレースで実行されるため、新規クラスターの作成やアプリケーションの新規クラスターへの移行の必要もありません。

具体的な手順は下記にありました。

https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/update-cluster.html

上記の冒頭にもありますが、(AKS と同様、)インプレースアップデートを実施して良いかは慎重な検討が必要です。

### ロードバランサーのサポート

Kubernetes Ingress リソースまたは LoadBalancer タイプの Service リソースを公開する際に AWS のロードバランサーが自動的にプロビジョニングされます。

> Amazon EKS は、Application Load Balancer (ALB)、Network Load Balancer (NLB)、および Classic Load Balancer を含む Elastic Load Balancing の使用をサポートしています。
>
> Amazon EKS クラスターでは、標準の Kuberentes クラスターロードバランシング、または Kubernetes をサポートする任意のイングレスコントローラーを実行することができます。

具体的な対応は下記の辺りを見ると良さそうです。

https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/aws-load-balancer-controller.html

### ログ記録

クラスタのログが確認できることは重要です。下記の記述で確認できました。

> Amazon EKS は、AWS CloudTrail と統合され、監査履歴を含む EKS 管理操作の可視性を提供します。CloudTrail を用いると Amazon EKS API への API コールを表示することができます。Amazon EKS は、分析、デバッグ、監査を行う目的で、Kubernetes コントロールプレーンログを Amazon CloudWatch に配信します。

具体的な対応は下記の辺りを見ると良さそうです。

https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/eks-observe.html

### Windows ワーカーノードのサポート

Windows コンテナを一時期よく触っていたので、Windows ワーカーノードのサポートがされているかは気になりましたが、下記の記述から問題ありませんでした。

> Amazon EKS は、Windows ワーカーノードと Windows コンテナスケジューリングをサポートしています。

## 違う機能

### Fargate でサーバーレス化できる

AWS Fargate を使うことで、ワーカーノードの提供を AWS に任せることができます。

https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/fargate.html

AKS の場合、Azure Container Instances(ACI)を繋ぐことで一部のワーカーノードをサーバーレス化できますが、システムノードプールが必ず必要なのでワーカーノードの全てをサーバーレス化とはいきません。

https://azure.microsoft.com/ja-jp/blog/bringing-serverless-to-azure-kubernetes-service/

ただ AKS の場合と同様、GPU は使えなかったり、EBS ボリュームを Fargate Pods にマウントできなかったりするなど考慮事項はあるので、注意して使う必要があります。

Pod の起動時間も仕組み上遅くなると予想しましたが、下記を見ると改善がなされているようなので、考慮事項に関してクリアできるようであれば検討したいですね。

https://aws.amazon.com/jp/about-aws/whats-new/2022/04/aws-fargate-delivers-scaling-applications/

### カスタム ノード イメージの使用が可能

下記に記載があって気づきましたが、EKS の場合は独自のノードイメージ(カスタム AMI イメージ)の使用が可能です。

https://learn.microsoft.com/ja-jp/azure/architecture/aws-professional/eks-to-aks/migrate-eks-to-aks

具体的には下記を確認すると良さそうです。

https://github.com/aws-samples/amazon-eks-custom-amis

## その他

### ストレージのドライバは事前に入っていない

下記に比較記事があります。

https://learn.microsoft.com/ja-jp/azure/architecture/aws-professional/eks-to-aks/storage

AKS の場合は最初から Blob やファイル共有、マネージドディスクを利用するためのストレージクラスが最初から入っていますので、永続ボリュームとの接続が比較的容易な印象です。

これに対して EKS はドライバーのアドオンを追加しないと EBS に接続できないです。
分かればやるだけではあるものの、注意が必要ですね(私は嵌りました...)

### AKS はシステムノードプールが必要だが、EKS は無くても構築できる

AKS はシステムノードプールがないと構築できません。

https://learn.microsoft.com/ja-jp/azure/aks/use-system-pools?tabs=azure-cli#system-and-user-node-pools

> AKS クラスターには、少なくとも 2 つのノードを含むシステム ノード プールが、少なくとも 1 つ含まれている必要があります。

EKS の場合はノードグループ(または Fargate)がない状態で構築できました。
もちろんノードグループがなければアプリが立ち上がりませんので、余談ですが初めて構築したときにマニフェストファイルを apply して待っていても永遠に Pod が立ち上がらず困惑しました...

### クラスター単位の固定料金は必ず有料

AKS の場合、クラスターの「レベル」によって固定料金が変わり、Standard レベルは 1 時間あたり 0.10 USD ですが、 Free レベルを選択することで SLA を犠牲に 1 クラスターあたりの料金が無料になります。

https://azure.microsoft.com/ja-jp/pricing/details/kubernetes-service/#pricing

> SLA なし (Free レベル): 無料 (基になるリソースに対してのみ支払う)

SLA なしなので本番利用は厳しいですが、開発用途であれば魅力的な料金設計です。

こちらに対して EKS の場合は AKS と同様、EKS クラスターごとに、1 時間あたり 0.10 USD の料金が発生します。

https://aws.amazon.com/jp/eks/pricing/