今から始める「EKS」 ~ 本番稼働する上で知っておきたい8のこと ~
Amazon EKS は 2018 年にリリースされ、現在まで多くの機能を実装してきました。
そのため、新規で EKS クラスタを構築する際に様々な選択肢が存在しており、全体像を理解するまでにそれなりの時間がかかると思います。
特に EKS を触ったことがない人が業務で利用することになった場合にどこからキャッチアップすれば良いのか迷ったりすることもあるでしょう。
そこで、本記事では EKS クラスタを構築・運用する上で知っておきたい事を 8 の項目に分けて説明します。
前半では EKS が提供する機能について、後半では利用者が管理するコンポーネントについて紹介します。
EKS を触っていて「これなんで必要なんだ」、「なんでこれ使ってるんだ」となった場合に参照できるような記事を目指します。
1. EKS アーキテクチャ
まずは、EKS のアーキテクチャを紹介します。
Kubernetes では、クラスタの管理を行う Control Plane とワークロードを実行する Data Plane が存在します。
EKS では、Control Plane の管理は AWS、Data Plane の管理は利用者が行う必要があります。
Control Plane
Control Plane 内には AZ を跨いで少なくとも 2 つの API サーバーと 3 つの etcd インスタンスが配置されています。 SLA も定義されており、月間稼働率を下回った場合にはクレジットを受けることができます。
Data Plane
Data Plane ではワークロードを管理します。EKS では、ワークロードをデプロイする Node の管理方法がいくつかあります。Karpenter と Manged Nodegroup で利用する Cluster Autoscaler については Autoscaling の項でも詳しく説明します。
AWS Fargate
Pod を Fargate 上で起動することができます。
Pod のプロビジョニングやスケーリングも自動的に管理します。
Managed Nodegroup
Node の作成から更新までまとめて管理できます。
Cluster Autoscaler を利用することで、Nodegroup ごとに Node のオートスケーリングを実現します。
Nodegroup は EC2 Autoscaling で管理されており、作成時にはインスタンスタイプや IAM Role の指定も可能です。
更新時には、自動的に Node を Drain しワークロードを新しい Node で利用できる状態にします。
Karpenter
ワークロードの負荷に応じて Node のスケーリングを行います。
Managed Nodegroup と違って EC2 Autoscaling を使用せず直接 EC2 インスタンスを利用します。
また、Karpenter 自身で Pod のスケジューリングも可能なため、kube-scheduler に依存した Cluster Autoscaler と比較して、高速な Node のスケーリングを実現します。
新たに EKS Cluster を構築する場合は、基本的には Karpenter を採用すれば良いでしょう。
2. EKS Addon
CoreDNS や kube-proxy などクラスタを構築する上でほぼ必須となるコンポーネントについては、EKS Addon を使って管理します。
EKS Addon は利用者のマニフェスト管理が不要です。そのため、作成・更新時にも新しいマニフェストを取得してデプロイするといった必要が無くなります。
| EKS Addon | 概要 |
|---|---|
| Amazon VPC CNI | VPC ネットワークを利用して Pod の IP 割り当てと Pod ネットワークの設定を行う |
| CoreDNS | クラスタ内の Service や Pod の名前解決を行う |
| kube-proxy | 各ノード上で Service に基づいたネットワークの管理を行う |
| Pod Identity | EKS クラスタから AWS サービスへアクセスするクレデンシャルの取得を行う |
他にも ADOT や GuardDuty Agent など多くのアドオンが存在します。
新規でコンポーネントを作成する場合は、EKS Addon に対応しているか確認するのがおすすめです。
また、多くのソフトウェアベンダが提供するコンポーネントについてもアドオンとして管理できます。
例えば、コストを管理する kubecost や監視を行う New Relic などが存在します。
3. EKS Auto Mode
re:Invent 2024 で発表された最新の機能になります。
Auto Mode では、これまで EKS Addon で管理していた CoreDNS や kube-proxy についても AWS 側で管理します。
他にも、これまで利用者で管理していた AWS Load Balancer Controller、Karpenter の管理も可能になっています。
今後は、Auto Mode を使うことで利用者はさらにワークロードの構築だけに集中できることが期待できそうです。
4. EKS Upgrade
EKS のバージョンアップにはいくつかの手法が存在します。
- In-place 方式
- eksctl やマネコンを使用して最新バージョンを指定することで、AWS が自動的に Upgade する
- Cluster Migration 方式
- 新規クラスタを事前に構築して、既存のクラスタからトラフィックをシフトすることで Upgrade する
- Nodegroup Blue/Green 方式
- 新しい Nodegroup を事前に作成して、NodeAffinity に新しい Nodegroup を指定する事で Upgrade する
また、Karpenter では古くなった Node を検出して新しいバージョンの Node にプロビジョンする機能が提供されています。
どの手法を採用するかは何を優先するかで変わってきます。各手法の比較についてはこちらご覧ください。
ここまでは、EKS が提供する機能にフォーカスして説明しました。
ここからは、利用者側で設定する必要があるコンポーネントについて紹介します。
5. オートスケーリング
Node のスケーリングには、Cluster Autoscaler と Karpenter の 2 つの選択肢があります。
基本的には後発の Karpenter を利用すれば良いですが、Cluster Autoscaler を利用している会社も多いかと思います。
ここでは、それぞれの特徴を簡単にまとめます。
Cluster Autoscaler
Cluster Autoscaler は Nodegroup が管理する Node の増減を行います。
Nodegroup は EC2 Autoscaling を使って実現されているため、実際には EC2 Autoscaling のインスタンス数を調整することで Node の増減を実現します。
Node の増減は Cluster Autoscaler が一定の間隔で評価を行い決定します。
また、Pending の Pod が存在する場合も Node をプロビジョンします。
Karpenter
Cluster Autoscaler は、EC2 Autoscaling が EC2 インスタンスのプロビジョンを実施します。
それに比べて、Karpenter では EC2 Autoscaling を利用せず、EC2 インスタンスをプロビジョンします。
そのため、リソース使用量に応じた柔軟なインスタンスの選定が可能になります。
また、kube-scheduler と協調して、Karpenter 自身も Node をプロビジョンするため kube-scheduler でのみプロビジョンを行う Cluster Autoscaler と比較して高速にスケーリングします。
6. 認証・認可
ここでは、EKS クラスタへアクセスする方法と EKS クラスタから AWS サービスを利用する方法を紹介します。
EKS クラスタへアクセスする (aws-auth、Access Entry)
EKS クラスタ へのアクセスを AWS の IAM User に許可する方法は 2 つあります。
aws-auth は Access Entry が登場する前に提供されていた方法で現在は非推奨です。新規で構築する場合は Access Entry を使用しましょう。
aws-auth (非推奨)
この方法は非推奨ですが、Access Entry の登場まで長い間利用されていたためここでも紹介します。
aws-auth では、IAM User や IAM Role を Kubernetes 内の User や Role に紐づけることで EKS クラスタ へアクセスできます。
aws-auth では、この紐付けを ConfigMap を使用して定義します。
apiVersion: v1
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam::111122223333:role/my-role
username: system:node:{{EC2PrivateDNSName}}
mapUsers: |
- groups:
- system:masters
userarn: arn:aws:iam::111122223333:user/admin
username: admin
Access Entry
現在、推奨されている方法です。aws-auth と違って ConfigMap を編集する必要が無く、アクセス管理が簡素化されています。
EKS クラスタへアクセスするには、アクセスポリシーとアクセスエントリが必要になります。
アクセスポリシーでは、Kubernetes のリソースに対するアクセス許可が設定されます。このポリシーの内容は変更できません。
> aws eks list-access-policies --output table
-------------------------------------------------------------------------------------------------------------------------------------------
| ListAccessPolicies |
+-----------------------------------------------------------------------------------------------------------------------------------------+
|| accessPolicies ||
|+--------------------------------------------------------------------------------------+------------------------------------------------+|
|| arn | name ||
|+--------------------------------------------------------------------------------------+------------------------------------------------+|
|| arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy | AmazonEKSAdminPolicy ||
|| arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy | AmazonEKSAdminViewPolicy ||
|| arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy | AmazonEKSClusterAdminPolicy ||
|| arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy | AmazonEKSEditPolicy ||
|| arn:aws:eks::aws:cluster-access-policy/AmazonEKSHybridPolicy | AmazonEKSHybridPolicy ||
|| arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy | AmazonEKSViewPolicy ||
|| arn:aws:eks::aws:cluster-access-policy/AmazonEMRJobPolicy | AmazonEMRJobPolicy ||
|| arn:aws:eks::aws:cluster-access-policy/AmazonSagemakerHyperpodClusterPolicy | AmazonSagemakerHyperpodClusterPolicy ||
|| arn:aws:eks::aws:cluster-access-policy/AmazonSagemakerHyperpodControllerPolicy | AmazonSagemakerHyperpodControllerPolicy ||
|| arn:aws:eks::aws:cluster-access-policy/AmazonSagemakerHyperpodSystemNamespacePolicy | AmazonSagemakerHyperpodSystemNamespacePolicy ||
|+--------------------------------------------------------------------------------------+------------------------------------------------+|
アクセスポリシーを選択後、アクセスエントリに紐づけます。
アクセスエントリを使って、IAM User や IAM Role とアクセスポリシーを紐づけることで EKS クラスタへアクセスできます。
EKS クラスタから AWS サービスへアクセスする (IRSA、Pod Identity)
続いて、EKS クラスタ上から AWS サービスへアクセスする場合のクレデンシャルの取得方法を紹介します。
EKS クラスタ内の Pod に IAM 権限を付与する方法は 2 つあります。
新規でクラスタを構築する場合は、設定が簡素な Pod Identity を利用するのが良いでしょう。
IAM Role for Service Account (IRSA)
IRSA では、Kubernetes の Service Account に IAM Role を紐づけることで Pod に IAM 権限を付与します。Service Account のアノテーションにeks.amazonaws.com/role-arn: <IAM Role Principal ARN>を指定する事で IAM Role に紐づけます。
Pod は紐づいた Service Account から OIDC トークンを発行します。この OIDC トークンを受け取った AWS はトークンを検証し、クレデンシャルを発行、Pod に送信します。この受け取ったクレデンシャルを利用して AWS サービスへアクセスできます。
そのため、IRSA を利用するには EKS クラスタの OIDC Provider の設定が必要になります。
Pod Identity
Pod Identity では、OIDC Provider が不要になるため IRSA より簡単に設定できます。
各ノードには、Pod Identity Agent と呼ばれる Daemonset がデプロイされます。
この Agent では、EKS Auth API から一時的な認証情報を取得します。この一連の動作は Agent 内で完結しており、OIDC Provider が必要ありません。
また、新しいクラスタで同じ IAM Role を利用する場合に IRSA では IAM Role の信頼ポリシーを設定する必要がありますが、Pod Identiy では不要になります。
設定を簡素にしたい場合や新規でクラスタを構築する場合は Pod Identity を採用すれば問題ないでしょう。Pod Identity は EKS Addon で管理できます。
7. ネットワーキング
ワークロードにアクセスするには Pod ネットワークの設定や外部に Service を公開する必要があります。
ここでは、VPC を利用した Pod ネットワークの構築、ワークロードを外部に公開する方法を紹介します。
Amazon VPC CNI
VPC CNI を利用することで VPC ネットワークから Pod に IP を割り当てることができます。
VPC CNI は、CNI バイナリと ipmad から構成されます。
- CNI バイナリ
- Pod 間通信を可能にする Pod ネットワークを設定します。
- ipamd
- Node 上の ENI を管理し、利用可能な IP を Pod に割り当てます。
VPC CNI では、Node ごとに保持する ENI の柔軟な設定が可能になっています。VPC 内の CIDR の IP が枯渇する可能性がある場合は調整しましょう。
AWS Load Balancer Controller
Kubernetes の Ingress や Service を監視して、必要に応じて ELB をプロビジョニングします。
Ingress をデプロイすると Application Load Balancer(ALB) をプロビジョニングします。
Ingress に annotation を付与することで起動する ALB の設定が可能です。
LoadBalancer type の Service をデプロイすると Network Load Balancer(NLB)をプロビジョニングします。
Service に annotation を付与することで起動する NLB の設定が可能です。
8. モニタリング
Control Plane や Data Plane のテレメトリデータ(ログ、メトリクス、トレースなど)を記録することは本番運用する上で必須になります。
ここでは、テレメトリデータを収集するいくつかの方法を紹介します。
Control Plane
Control Plane には、API サーバーや kube-scheduler など Kubernetes の一般的なコンポーネントに加えて監査ログや IAM 認証のログを管理する Authenticator ログがあります。
これらの Log は CloudWatch Logs に送信することが可能です。
また、後述する Container Insights でも Control Plane のメトリクスの収集が可能です。
Data Plane
Data Plane のログやメトリクスの取得には色々な方法が存在します。
Container Insights
Container Insights は、メトリクスやログを収集し自動的にダッシュボードを作成するなど利用者の分析をサポートにします。
ログ、メトリクスの収集には CloudWatch Agent や Fluent Bit を利用します。
CloudWatch Agent は EKS アドオンで管理できます。
Fluent Bit については手動でインストールする必要があります。
ADOT Operator
ADOT Operator は、ワークロードが発行するテレメトリデータを CloudWatch や X-Ray などの AWS サービスに送信できます。
詳しくはこちらをご覧ください。
さいごに
いかがだったでしょうか？
ここに書ききれなかった重要な機能はまだまだ沢山あるので EKS の学習コストはそれなりに高くなっている気がしました。
また、EKS Best Practice も一度見ておくとさらに理解が深まるかと思います。
皆さんの快適な EKS ライフの助けになれば幸いです。
Discussion