どんな場面で検討するか
既存の Kubernetes マニフェスト、Operator、共通 CI/CD を活用し、複数チームのコンテナを共通基盤で管理したい場合。コントロールプレーンの運用を AWS に任せつつ Kubernetes の運用標準を維持する用途。
組織で使う条件
Kubernetes 版・ノードイメージ・CNI 等のアドオンを一覧化し、非推奨 API の検出と更新順序を管理する。コントロールプレーン更新だけでノードやアプリも更新済みとは扱わない。 Namespace と RBAC、Pod に付与する AWS 権限、監査ログ、バックアップ対象を設計する。永続データの復旧は Pod の再作成と別に試験する。
採用前に試すこと
- 2 Namespace にアプリを配置し、それぞれの操作権限と AWS アクセスを分ける。
- Pod の停止と正常・異常イメージのローリング更新を試し、readiness probe と必要レプリカ数を確認する。
- Cluster Insights とアドオン・マニフェストの対応版を確認し、検証クラスターの版更新と永続データの復元を行う。
合格と判断する条件
- 両 API が期待値を返し、別チームの Secret・設定の閲覧や更新が拒否される。
- 不健康な Pod に利用者のリクエストが流れず、業務データが失われない。異常更新の検出と前版への戻しを担当者が実行できる。
- 非推奨 API が解消され、ノード・アドオン・アプリの更新結果を個別に記録でき、復元した件数とデータ照合が一致する。
見落としたくない点
- 単一アプリを動かすだけで Kubernetes 固有の要件がなければ、ECS や専用アプリ実行サービスと総運用負荷を比較する。 古い Kubernetes 版の長期固定、非推奨 API の放置、権限分離やアドオン更新を担当できない体制では採用を急がない。Auto Mode でもアプリ・権限・互換性の判断は残る。
- 単一アプリを動かすだけで Kubernetes 固有の要件がなければ、ECS や専用アプリ実行サービスと総運用負荷を比較する。
- 古い Kubernetes 版の長期固定、非推奨 API の放置、権限分離やアドオン更新を担当できない体制では採用を急がない。Auto Mode でもアプリ・権限・互換性の判断は残る。
根拠となる資料
Managed Kubernetes Service – Amazon EKS