見出し画像

K8s、EKSを支えるツール群

べにや

はじめに

K8s、EKSはマイクロサービス開発において欠かせない技術です。
しかし、その運用はECSや単体でDockerを利用している時より難易度が上がります。
本稿では、k8s、EKSの運用を支援するためのツールに焦点を当てて紹介していきます。

ここで扱うのは、現場で名前がよく挙がる代表的なツールたちです。
「どのレイヤーを担当しているか」「どんな場面で使うか」を中心に整理していきます。

全体像：EKSを支える4つのレイヤー

まず、EKSまわりのツールを次の4つに分けて考えます。

  1. クラスタをつくるレイヤー

  2. アプリを載せるレイヤー

  3. クラスタを守るレイヤー

  4. クラスタを見張るレイヤー

全体の流れを1枚にするとこうなります。

```mermaid
flowchart LR
  Dev[開発者] --> Git[Gitリポジトリ]
  Git --> CI[CIパイプライン]
  CI --> Image[コンテナイメージ]
  Image --> ECR[ECR]
  ECR --> GitOps[Argo CD / Flux]
  GitOps --> EKS[EKSクラスタ]
```

左側がアプリ開発の世界、右側がEKSクラスタの世界です。
この間を、IaC、Helm、GitOps、監視系のツールが支えていきます。

クラスタをつくるツール群

EKSを使うには、VPC、サブネット、クラスタ、ノードグループといった土台を先に準備します。
ここを自動化するのが「クラスタをつくる」レイヤーです。

eksctl

eksctlは、EKS専用のCLIツールです。
YAMLファイルとコマンドだけで、EKSクラスタとノードグループをまとめて作成できます。

特徴は次の通りです。

  • シンプルなYAMLでクラスタ定義を書ける

  • 内部でCloudFormationを使うため、AWSアカウント側の変更履歴も追いやすい

  • 小さめの検証環境を素早く立ち上げる用途と相性が良い

個人検証やPoCでは、まずeksctlで始め、その後TerraformやCDKに寄せる構成もよくあります。

Terraform

Terraformは、HCLという独自言語でインフラを定義するIaCツールです。
AWSだけでなく、他クラウドやSaaSも含めて一括管理する用途で選ばれることが多いです。

EKSまわりでTerraformを使うときのポイントは次の通りです。

  • VPC、EKSクラスタ、ノードグループを一式コード化できる

  • dev / stg / prod を同じコードベースで再現しやすい

  • Pull Requestベースでインフラ変更をレビューしやすい

EKS用のモジュールも整備されており、細かいリソースを1つ1つ書かずに、入力パラメータ中心で組み立てられます。

CloudFormation / CDK

CloudFormationはAWS純正のテンプレート型IaC、CDKはプログラミング言語でCloudFormationを生成するツールです。
EKSを含むAWSリソース一式を、AWS標準スタックで揃えたいケースで選ばれます。

  • 既にCloudFormation中心で運用している組織

  • 開発者がTypeScriptやPythonでテンプレートを書きたい組織

こういった前提がある場合、CDKでEKSスタックを構成し、その上に後述のツールを重ねていく形になります。

アプリを載せるツール群

クラスタが用意できたら、アプリケーションとアドオンをどう載せるかが課題になります。

kubectl

kubectlはKubernetes標準のCLIです。

  • マニフェストのapply

  • PodやServiceの状態確認

  • ログの取得やポートフォワード

といった基本操作を一通り担います。
本番環境での恒常的なデプロイ手段にするというより、デバッグやスポット対応用のツールという位置づけで捉えた方が整います。

Helm

Helmは「Kubernetes向けパッケージマネージャ」と呼ばれるツールです。
Chartと呼ばれる単位で、Deployment、Service、ConfigMapなどをまとめて管理します。

  • 共通部分をテンプレート化し、環境ごとの差分は values.yaml に寄せる

  • IngressコントローラやPrometheusスタックなど、複数リソースで構成されるアドオンを1つのChartとして扱う

  • Chartのバージョンを上げるだけで、アプリのリリースを表現する

こういった運用がしやすくなります。
EKSアドオンの多くはHelmチャートとして配布されているため、Helmを押さえておくと選択肢が広がります。

Argo CD

Argo CDは、Kubernetes上で動作するGitOpsツールです。
Gitリポジトリを「望ましい状態」とみなし、クラスタとの同期を自動で行います。

特徴を整理すると次のようになります。

  • Gitリポジトリごとに「Application」という単位で管理する

  • HelmチャートやKustomizeにも対応している

  • UIから差分表示やロールバック操作ができる

「Gitにマニフェストを書いた時点でデプロイ完了」という運用を作りたい場合、Argo CDが分かりやすい選択肢になります。

Flux

FluxもGitOpsツールです。
Argo CDと同様に、Gitをソースとし、クラスタと同期します。

Fluxならではの特徴として、次のような点があります。

  • KubernetesのCRDとして構成されており、ツール本体の設定もYAMLで扱いやすい

  • アプリだけでなく、クラスタ内のインフラ定義もまとめて管理しやすい

UIを重視するならArgo CD、Kubernetesリソースとしての一体感を重視するならFlux、というような分け方もあります。

GitOpsの流れをシーケンス図で整理します。

```mermaid
sequenceDiagram
  participant Dev as 開発者
  participant Git as Git
  participant CI as CI
  participant ECR as ECR
  participant GitOps as Argo CD / Flux
  participant EKS as EKS

  Dev->>Git: コードとマニフェストをpush
  Git->>CI: Webhookで通知
  CI->>ECR: コンテナイメージをpush
  CI->>Git: マニフェストのイメージタグを更新
  GitOps->>Git: 変更されたマニフェストを取得
  GitOps->>EKS: 差分を反映してデプロイ
```

CIはイメージのビルドとテスト、GitOpsツールは状態同期、という分担になります。

クラスタを守るツール群

EKS運用では、「誰がどこに何をデプロイできるか」「どのPodがどの外部リソースに触れるか」をきちんと決めておく必要があります。

IAM と IRSA

EKSでは、IAMロールとKubernetesのサービスアカウントを紐付けるIRSA（IAM Roles for Service Accounts）が使えます。

  • マイクロサービス単位で専用のIAMロールを用意する

  • 各サービスアカウントに対応するロールを割り当てる

  • Podは自分のサービスアカウント経由でAWSリソースにアクセスする

こういった構成にすることで、「誰がどのAWSリソースにアクセスできるか」を細かく制御しやすくなります。

Kyverno

Kyvernoは、Kubernetesネイティブなポリシーエンジンです。
ポリシー自体をYAMLで定義し、Admissionのタイミングでマニフェストを検証したり、書き換えたりします。

よく使われるパターンは次のようなものです。

  • 特定の名前空間では指定のラベルを必須にする

  • root権限で動くコンテナや特定の特権設定を拒否する

  • 監査用のアノテーションやサイドカーコンテナを自動付与する

ポリシーもGitで管理できるため、「セキュリティ要件をコードとして扱う」運用と相性が良いです。

External Secrets Operator

External Secrets Operatorは、外部シークレットストアとKubernetes Secretを橋渡しするオペレータです。

  • AWS Secrets ManagerやSSM Parameter Storeなどに機密情報を保存

  • Kubernetes側では「どのSecretをどこに同期するか」だけを設定

  • ESOが定期的に外部ストアから値を取得し、Secretリソースを更新

アプリ側は通常のSecret参照と同じ書き方で済むため、実装の複雑さを増やさずに安全性を高めやすくなります。

クラスタを見張るツール群

最後は、稼働中のクラスタを監視するレイヤーです。
メトリクス、ログ、トレースの3つを意識して構成を考えます。

Prometheus

Prometheusは、時系列メトリクスの収集と保管を行うツールです。
Kubernetesクラスターとの相性が良く、PodのCPU/メモリ、リクエスト数、エラーレートなどを一括で集約できます。

  • Exporterを通じてKubernetesやアプリからメトリクスを取得

  • PromQLで集計し、アラートルールを定義

  • Grafanaのデータソースとして利用

EKSでは、Prometheus OperatorやマネージドPrometheusを使う構成がよく採用されています。

Grafana

Grafanaは、各種データソースからメトリクスを取得してダッシュボードを作るツールです。

  • クラスタ全体の状態を見るダッシュボード

  • 名前空間ごとのリソース使用量を見るダッシュボード

  • マイクロサービスごとのレイテンシとエラーレートをまとめたダッシュボード

こういった画面を作り、開発チームと共有することで、性能や障害の議論がしやすくなります。

CloudWatch Container Insights と Fluent Bit

AWS寄りの構成では、CloudWatch Container InsightsとFluent Bitの組み合わせもよく使われます。

  • Container Insightsでクラスタ・ノード・Podなどのメトリクスを収集

  • Fluent BitをDaemonSetとして各ノードに配置し、コンテナログをCloudWatch Logsへ転送

ログの流れを図にすると次のようになります。

```mermaid
flowchart LR
  Pod[アプリケーションPod] --> FB[Fluent Bit DaemonSet]
  FB --> CWL[CloudWatch Logs]
  CWL --> Dash[CloudWatchまたはGrafanaのダッシュボード]
```

Prometheus+Grafanaでアプリ寄りのメトリクスを、Container Insights+CloudWatch Logsでインフラ寄りのメトリクスとログを、というように棲み分ける構成も扱いやすいです。

小さなチーム向けのツール構成例

最後に、3〜5人ほどの開発チームでEKSを運用する場合のひとつの組み合わせ例をまとめます。

  • クラスタ構築

    • TerraformでVPCとEKSクラスタ、マネージドノードグループを定義

    • 初期検証ではeksctlも併用し、最終的な構成をTerraformに落とし込む

  • アプリ配布

    • アプリとアドオンをHelmチャート化

    • GitHub Actionsでイメージビルドとテスト

    • Argo CDでGitリポジトリからEKSへ自動同期

  • セキュリティ・ガバナンス

    • IRSAでサービス単位のIAMロールを割り当て

    • KyvernoでPodセキュリティとネームスペースごとの制約を定義

    • External Secrets OperatorでSecrets Managerと連携

  • 監視・ログ

    • Prometheus+Grafanaでアプリとクラスタのメトリクスを可視化

    • CloudWatch Container InsightsとFluent Bitでログとインフラメトリクスを集約

まずはこのあたりから構成を始めて、チームのスキルやサービスの規模に合わせて少しずつ拡張していく形が扱いやすいと感じます。

参考ページ

詳しく深掘りしたいときの入り口として、主な公式情報やドキュメントを挙げておきます。
URLは省略し、名称のみ記載します。

  • Amazon EKS 公式ドキュメント

  • eksctl User Guide / GitHub リポジトリ

  • Terraform AWS Provider / EKS関連モジュールドキュメント

  • AWS CloudFormation / AWS CDK 公式ドキュメント

  • Helm 公式ドキュメント

  • Argo CD 公式ドキュメント

  • Flux 公式ドキュメント

  • Kyverno 公式ドキュメント / サンプルポリシー集

  • Prometheus 公式ドキュメント

  • Grafana 公式ドキュメント

  • Amazon CloudWatch Container Insights ドキュメント

  • Fluent Bit 公式ドキュメント

  • External Secrets Operator 公式ドキュメント

チートシート：ツール別の役割早見表

ここから先は

2,852字

¥ 100

ログイン

この記事が気に入ったらチップで応援してみませんか？