このページの改善にご協力ください

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。

EKS 機能と考慮事項

このトピックでは、EKS 機能を使用する際の重要な考慮事項について説明します。具体的には、アクセスコントロール設計、EKS 機能かセルフマネージドソリューションかの選択、マルチクラスターデプロイ用のアーキテクチャパターン、運用のベストプラクティスなどです。

機能 IAM ロールと Kubernetes RBAC

EKS 機能リソースごとに、機能 IAM ロールが設定されています。機能ロールを使用すると、自分の代わりに EKS 機能を動作させるための AWS サービスアクセス許可を付与できます。例えば、EKS Capability for ACK を使用して Amazon S3 バケットを管理するには、S3 バケットの管理アクセス許可を機能に付与して、バケットを作成および管理できるようにします。

機能を設定すると、クラスター内の Kubernetes カスタムリソースで AWS の S3 リソースを作成および管理できます。Kubernetes RBAC は、こうしたカスタムリソースをどのユーザーとグループが作成および管理できるかを決定するためのクラスター内アクセスコントロールメカニズムです。例えば、特定の Kubernetes RBAC ユーザーとグループに、選択した名前空間で Bucket リソースを作成および管理するためのアクセス許可を付与します。

このように、IAM と Kubernetes RBAC は、エンドツーエンドのアクセス管理システムを二等分して、EKS の機能とリソースに関連するアクセス許可を管理しています。ここで重要なのは、ユースケースに適した IAM アクセス許可と RBAC アクセスポリシーを組み合わせることです。

機能 IAM ロールと Kubernetes アクセス許可の詳細については、「EKS 機能のセキュリティに関する考慮事項」を参照してください。

マルチクラスターアーキテクチャパターン

複数のクラスターに機能をデプロイする際は、よく使用される次のアーキテクチャパターンを考慮してください。

一元管理でのハブとスポーク

一元管理クラスターで 3 つすべての機能を実行して、ワークロードをオーケストレーションし、複数のワークロードクラスター全体にわたってクラウドインフラストラクチャを管理します。

このパターンにより、ワークロードとクラウドインフラストラクチャの管理が一元化されるため、組織が多数のクラスターを管理する場合の運用をシンプルにできます。

分散型 GitOps

ワークロードとクラウドインフラストラクチャは、ワークロードが実行されているのと同じクラスター上の機能で管理されます。

このパターンでは運用が分散され、各チームは 1 つ以上のクラスターでそれぞれ独自の専用プラットフォームサービスを管理します。

ハイブリッド ACK デプロイでのハブとスポーク

モデルを一元化および分散すると共に、範囲と所有権に基づいてアプリケーションのデプロイとリソース管理を一元化します。

このパターンは関心を分離します。プラットフォームチームは管理クラスター上で重要なインフラストラクチャを (必要に応じてワークロードクラスターも) 一元管理し、アプリケーションチームはワークロードと共にクラウドリソースを指定および管理します。

パターンを選択する

アーキテクチャを選択する場合は、次の要因を考慮してください。

EKS 機能をセルフマネージドソリューションと比較する

EKS 機能では、EKS で実行される一般的な Kubernetes ツールとコントローラーを完全に管理できます。これは、クラスターにインストールして運用するセルフマネージドソリューションとは異なります。

主な違い

デプロイと管理

AWS が EKS 機能を完全に管理するため、コンポーネントソフトウェアのインストール、設定、メンテナンスが必要ありません。また、AWS はクラスターに必要なすべての Kubernetes カスタムリソース定義 (CRD) を自動的にインストールして管理します。

セルフマネージドソリューションでは、Helm チャート、kubectl、またはその他の演算子を使用して、クラスターソフトウェアをインストールおよび設定します。セルフマネージドソリューションのソフトウェアライフサイクルとランタイム設定を完全に制御できるため、ソリューションのどのレイヤーでもカスタマイズを実施できます。

運用とメンテナンス

AWS は、自動更新とセキュリティパッチを使用して、EKS 機能のパッチ適用やその他のソフトウェアライフサイクルの運用を管理します。EKS 機能は、AWS 機能との統合により設定を効率化し、高可用性と耐障害性を備えており、コントローラーワークロードをクラスター内でトラブルシューティングする必要がありません。

セルフマネージドソリューションでは、コンポーネントのヘルスとログのモニタリング、セキュリティパッチとバージョン更新の適用、複数のレプリカとポッド中断の予算による高可用性の設定、コントローラーのワークロードに関する問題のトラブルシューティングと修復、リリースとバージョンの管理を行う必要があります。デプロイを完全に制御できますが、そのためには組織の標準とセキュリティコンプライアンス要件に沿ってプライベートクラスターアクセスやその他の統合を実現するカスタムソリューションが必要です。

リソース消費

EKS 機能はクラスターとは別に EKS で実行されるため、ノードリソースとクラスターリソースが解放されます。クラスターワークロードリソースを使用せず、ワーカーノード上で CPU やメモリを消費しません。また、自動的にスケールして、クラスターキャパシティプランニングへの影響を最小限に抑えます。

セルフマネージドソリューションは、ワーカーノードでコントローラーやその他のコンポーネントを実行するためのワーカーノードリソース、クラスター IP、その他のクラスターリソースを直接消費します。クラスターサービスを管理するには、ワークロードのキャパシティプランニングが必要であり、スケールと高可用性の要件を管理するためにリソースのリクエストと制限を計画して設定する必要があります。

機能のサポート

EKS 機能は完全マネージド型のサービス機能であるため、セルフマネージドソリューションと比べると、本質的に自由度が低くなります。ほとんどの特徴とユースケースをサポートしますが、セルフマネージドソリューションと比べると、カバレッジに違いがあります。

セルフマネージドソリューションを使用すると、ソフトウェアの設定やオプションなど機能性のさまざまな側面を完全に制御できます。独自のカスタムイメージを実行する、設定のあらゆる側面をカスタマイズする、セルフマネージドソリューションの機能性を完全に制御するといったこともできます。

コストについて

EKS 機能のリソースごとに時間単位でコストが伴います。これは機能タイプによって異なります。EKS 機能で管理されるクラスターリソースにも、独自の料金に関連付けられた時間単位のコストが伴います。詳細については「Amazon EKS の料金」を参照してください。

セルフマネージドソリューションには AWS の料金に関連する直接コストはありませんが、コントローラーおよび関連するワークロードでクラスターコンピューティングリソースが使用された場合には料金が発生します。ノードとクラスターのリソースの消費以外にも、セルフマネージドソリューションに伴う総所有コストには、メンテナンス、トラブルシューティング、サポートの運用にかかるオーバーヘッドとコストが含まれます。

EKS 機能かセルフマネージドソリューションかを選択する

EKS 機能 基本要件を満たすためにクラスタープラットフォームを運用することではなく、運用オーバーヘッドを削減し、ソフトウェアとシステムの差別化された価値に集中する場合は、この選択肢を検討してください。セキュリティパッチとソフトウェアライフサイクル管理の運用に伴う負担を最小限に抑える、アプリケーションワークロードのノードとクラスターのリソースを解放する、設定とセキュリティ管理をシンプルにする、AWS サポートカバレッジからメリットが得られるといった場合は、EKS 機能を使用します。EKS 機能は、本番稼働のほとんどのユースケースに最適であり、新規デプロイに推奨されるアプローチです。

セルフマネージドソリューション 特定の Kubernetes リソース API バージョンを必要とする、コントローラーを独自に構築する、既存の自動化とツールがセルフマネージドデプロイを軸に構築されている、コントローラーランタイム設定をきめ細かくカスタマイズする必要があるといったは、この選択肢を検討します。セルフマネージドソリューションでは、特殊なユースケースに柔軟に対処し、デプロイとランタイム設定を完全に制御できます。

機能固有の比較

機能に固有の特徴、アップストリームの違い、移行パスなどの詳細な比較については、以下を参照してください。