AKS使いの私がEKS構築でハマったこと

概要

Azure にも AWS にもマネージドな Kubernetes があり、それぞれ Azure Kubernetes Service (AKS) と Amazon Elastic Kubernetes Service (EKS) という名前です。

AKS（に限らず Azure のサービス）は、Azure ポータルから構築を進めるとすぐに使えることが多いです。

EKS も AKS と同じノリでポータルで構築したらなかなか動かなかったので、ハマったポイントを共有します。

ノードグループを追加しないと動かない

Kubernetes はワーカーノードが無いと Pod を動かすことができません。

AKS の場合、ワーカーノードを動かすためにはノードプールを用意する必要があります。 Azure ポータルから AKS クラスタを構築するときはノードプールの作成がデフォルトで指定されており、更にノードプール（厳密にはシステムモードのノードプール）の作成を指定していないとそもそも AKS 自体を構築できません。

これに対して EKS の場合は、AWS コンソールから EKS クラスタを作成しただけではワーカーノードを動かすために必要なノードグループを作成してくれません。 クラスタはできているので、EKS に対してマニフェストファイルを apply する分には実行できるのですが、待っていても永遠に Pod が立ち上がりません。

永続ボリュームとしての EBS のマウントにはアドオンを追加する必要がある

AKS の場合、永続ボリュームとしてマネージドディスクをマウントする場合、StorageClass や Persistent Volume Claim のマニフェストファイルを用意していけば使えるのでアドオンを意識することはありませんでした。 クラスタの構築時も特にアドオンの選択はさせられません。

EKS の場合は、クラスタの構築後にアドオンで EBS CSI driver を追加しないと EBS を永続ボリュームとして利用できません。

まとめ

その他、VPC やその他ネットワーク回りの悩みも出てくるんですが、そこは AWS を使う上で共通な話なので割愛しました。

EKS は 1 つ 1 つの技術要素が分離しているので、必要な技術を理解していないと動く状態が作れませんでした。 ただそれは、必要最小限のものだけで構成でき、リソースの利用効率やセキュリティ面でメリットがあると感じました。 Azure の簡単さに甘えずに、しっかり AWS について理解して技術力をレベルアップしていきたいと思います。