本記事は AWSアワード受賞者祭り 21日目の記事です。
✨🏆 20日目 ▶▶ 本記事 ▶▶ 22日目 🏆✨

ozawaです。この度、2025 Japan AWS Top Engineer に選出されました。ALLCertも継続です。ありがとうございます。
金ジャケはまだ未開封です。~~メ○カリには出品してないです~~

この記事を書く背景

かれこれ数年間お付き合いのあるEKS、改めて各種アップデートを経ていく中で、クラスター作成するだけでも結構考えること多くね？という気持ちが芽生えてきました。
なので今回は、これまでの運用における経験をもとに、こういう部分を気にかけておけばとりあえずなんとかなるよ！という箇所についてまとめてみようと思います。

ちなみに、過去ECSでも似たようなタイトルの記事を書きましたが、モチベーション的にも似たようなものになります。

tech.nri-net.com

今回はクラスターの設計に焦点を当てます。そのため、ノード群におけるコンピューティング最適化とかスケーリング設計のようなアプリケーションレイヤーの可用性の話には触れません。
どちらかというと管理機能や運用面、Kubernetesエンジンバージョンアップに関わる話をします。

Kubernetesとは

まずEKSとは Elastic Kubernetes Service の略です。なので、大元のKubernetesについてもざっくり触れておきます。

KubernetesはOSSなコンテナオーケストレーションツールで、現在はCNCF (Cloud Native Computing Foundation) によってメンテナンスされています。
ざっくりいうと、コンテナをよーさんよしなに管理してくれる便利なツールです。

Kubernetesは大きく分けて２つの構成からなります。

コントロールプレーン
- Podの管理やスケジューリングなど、クラスター全体の管理を司る
ノード
- Podの実行環境、実際に稼働させたいアプリケーションが動く環境

kubernetes.io

コンテナをワークロードに展開する場合、一般的には同じアプリケーションコンテナを複数台展開する形をとります。
その際に、

コンテナをどのノードに配置するか
コンテナに障害が発生した際にどうリカバリーするか
デプロイメントをどのように展開するか

といった運用の煩雑さが課題となります。

そのような課題を解消するために、Kubernetesといったコンテナオーケストレーションツールを用いて運用を効率化するというのがこれらを用いる目的です。
ちなみにAWSにおいては Amazon ECS というサービスがあり、こちらはAmazonが提供するコンテナオーケストレーションサービスになります。
EKSと似ているように見えますが、EKSはKubernetesというある種のプラットフォームをAWS上でフルマネージドに稼働させるためのサービスです。そのため、同じコンテナオーケストレーションなツールといえど、EKSとECSは似てかなり非なるサービスになります。

Amazon EKS とは

上述の通りですが改めて、Amazon EKS は AWSにおけるフルマネージドなKubernetesサービスです。
Kubernetesは構成上、コントロールプレーンとノード群を用意する必要があります。コントロールプレーンは管理機能を司っており、ここで障害が発生するとKubernetesにおけるコンテナオーケストレーションな機能の恩恵を受けられなくなるため、コントロールプレーンの可用性や耐障害性といった部分はよりシビアに考慮する必要があり、その分のランニングコストもかかります。
EKSではこのコントロールプレーンをAWSのマネージドな基盤で展開することができるため、可用性や耐障害性の責任領域をAWS側に移すことができ、ユーザ側の運用負荷を軽減できます。
また各種AWSサービスとの統合によって、他AWSサービスとの親和性を高めながらKubernetesサービスを稼働させることができる点がメリットです。

EKSクラスターの設計

今回は、下記項目についてフォーカスしようと思います。

アドオン
アクセス
オブザーバビリティ

加えて、Kubernetes運用では避けることのできないエンジンバージョン更新についてもお話しします。

アドオン

ざっくりいうと、Kubernetesの管理機能をAWSで動かすために必要なツール です。
具体的には下記のリンクにあるアドオンが存在します。

自分で書いていて「こんなにあるんや〜」と思いました。

もちろん全てが必須というわけではなく、アプリケーション要件や利用したいAWSサービス等によって必要なアドオンをインストールしていくという流れになります。
また、FargateやAutoModeといったタイプ毎でインストールの要否も変わります。ですので、必要そうなアドオンがあればそれを選択していくことになります。

アドオンの利点としては、AWSリソースの一部として扱うことができる点になります。
EKSアドオンを利用しない場合は、これらのアドオンツールをkubectlコマンドベースでクラスターに対してインタラクティブに設定反映をします。

## vpc-cni マニフェストをクラスターに適用
kubectl apply -f aws-k8s-cni.yaml

EKSアドオンを使うと、クラスター上でアドオンをぽちっと追加するだけで反映できるようになります。
また、Terraform といった IaC ツールと組み合わせることで、アドオンツールを宣言的に管理することができ、冪等性を維持することが可能になります。
独自にカスタムしたアドオンツールを使用したい場合は上記アドオンを使わずに従来のやり方でマニフェストをapplyします。
特に要件がなければEKSアドオンを利用し、要件がある場合は独自設定する、といった選択になります。

アクセス

EKSへのアクセスの話になりますが、具体的には下記のような棲み分けになります。

クラスターへのアクセス
- aws-auth ConfigMap
- EKSアクセスエントリ
Podへのアクセス
- EKS Pod Identity

aws-auth ConfigMap

EKSクラスターを作成した場合、aws-auth ConfigMapというKubernetes ConfigMapリソースが作成されます。aws-auth ConfigMapはIAMプリンシパルをもとにクラスターにアクセスできるIAMアイデンティティを制御します。

デフォルトではクラスター作成時のIAMアイデンティティが登録されます。そのため、別のIAMアイデンティティがクラスター操作したい場合はこのConfigMapを更新する必要があります。
ちなみに現在はこの方法は非推奨で、後述のEKSアクセスエントリが推奨になります。

docs.aws.amazon.com

EKSアクセスエントリ

ざっくりいうと、 aws-auth ConfigMap で管理してたのがIAMでできるようになったよ です。
クラスターにアクセスさせたいIAMエンティティに対してエントリーを作成することで、アクセス制御します。このIAMエンティティ（具体的にはIAMロール or ユーザ）に対してグループ権限を割り当てることで、RBAC (Role-based access control) 認証を実現します。なので、aws-auth ConfigMapでの制御と比べて、IAMでの柔軟な権限制御が可能になったという点が違いになります。

docs.aws.amazon.com

EKS Pod Identity

先ほどまではクラスターに対するアクセスでしたが、こちらは Podに対するIAMベースのアクセス制御 になります。Kubernetes の Service AccountリソースとIAMロールを紐づけることで、Podにアクセスできる機能です。

実ははあまりこの機能を活用したことがないのですが、１クラスター内で複数マイクロサービスを複数チームが管理しているようなケースであれば、チームごとにIAMロールを分けて権限統制ができるので便利だろうなーと考えています。

docs.aws.amazon.com

アクセス制御については、クラスターはEKSアクセスエントリ、開発規模が大きいクラスターではEKS Pod Identityでの権限統制を検討する、といった具合で考えるのが良さそうです。

オブザーバビリティ

PrometheusメトリクスやCloudWatch Application Signalsといった設定はあるのですが、ここではコントロールプレーンのログについて触れたいと思います。コントロールプレーンのログでは、下記のログがCloudWatch Logsによって収集できます。

APIサーバー
監査
Authenticator
コントローラーマネージャー
スケジューラ

要件によって設定有効化を検討するのが基本ではありますが、気にしておきたいのがKubernetesエンジンバージョンアップの際です。特に、新しいリソースの追加時やAPIVersionを更新した際などはこれらのリソースが正常に処理されているかをデバッグする必要があります。その際、もしノード側でエラー応答となった場合、詳細な原因に踏み込む際はコントロールプレーン側でのAPIサーバー応答等を確認しなければいけません。このような事象に対応するため、常時出力していない場合はエンジンバージョン更新時のみAPIサーバー（必要であればその他も）ログ出力を有効化しておくといった運用を検討するのが良いと思います。

docs.aws.amazon.com

エンジンバージョン更新

Kubernetesのリリースライフサイクル上、エンジンバージョンアップを1Q単位で回していく必要があり、EKSのクラスターバージョンもこれに追随する必要があります。
かれこれ十数回くらいは更新をかけ続けた気がしますが、

1Qなので更新頻度が結構多い
リリースバージョンごとに変更箇所をピックアップし影響範囲を特定する必要がある
これらに伴うEKSクラスター側への変更点も整理する必要がある

ざっくり考えてこの辺が更新運用で大変だなーと思うポイントです。いかんせん考えることも多いです。
ですので更新作業に関してはなるべく定型作業化して効率よく回していくことがポイントになります。かと言いつつ毎回変わるリリース内容についても柔軟に対応する必要はあるので、

Kubernetes リリースノートの確認(EKSへの影響範囲の精査も含む)
Kubernetesマニフェストへの影響確認
更新作業
検証

といった、かなりざっくりではありますが大枠の作業工程を定型フローとして回して運用するといった対応が必要になります。私のチームにおいてもこのような作業フォーマット（もう少し細かめ）を作成して、毎度バージョンごとにドキュメント作成をしたりしています。

設計ポイントからは少し逸れますが、こういったエンジンバージョン更新に伴う影響調査においては、pluto といったKubernetes APIの非推奨バージョンを特定するツールをCICDワークフローに組み込むなどして積極的に検知するといった対応も重要です。

github.com

また、EKSにおいてはアップグレードインサイトという機能が利用でき、こちらから更新に必要なアクションを確認することができます。

docs.aws.amazon.com

まとめ

最後の方は運用ポイントについてもお話ししましたが、クラスター設計についてざっくりまとめてみました。
本当はAutoModeとの比較とかまでまとめたかったですが次回に期待です。
ただ、AutoModeを使う場合においても、今回まとめてみたポイントについては意識しておくべき部分かと思いますので、今後EKSに関わるような人たちの一助になれば幸いです。