AWS上でKubernetesを実行することでインフラストラクチャのオーバーヘッドを削減できますが、ネットワーク、セキュリティ、スケーリング、コスト、監視に関する意思決定が不要になるわけではありません。AWS EKSは、AWSが担う責任と、お客様のチームが担う責任を区別します。この記事では、AWS EKSの仕組み、コスト、ネットワークとデプロ​​イメントモデルの違い、他のマネージドKubernetesサービスとの比較、そして本番環境でEKSを保護、スケーリング、運用、監視する方法について説明します。

AWS EKSとは何ですか？

AWS EKSはAmazon Elastic Kubernetes Serviceの略です。 マネージドKubernetesサービスKubernetes APIサーバー、スケジューラー、コントローラーマネージャー、etcdを複数のアベイラビリティゾーンで自動的に実行するため、コントロールプレーンのインストール、パッチ適用、運用を自分で行う必要はありません。ワークロードと、ほとんどのデプロイモードではワーカーノードを用意するだけで済みます。

これを具体的に示す比較対象は、セルフマネージドKubernetesとEKSです。

• 自己管理型Kubernetesコントロールプレーンのインストール、パッチ適用、アップグレード、およびセキュリティ強化はすべてお客様自身で行います。完全な制御権と運用コストをお客様が負担することになります。
• AWS EKSAWSがコントロールプレーンを管理します。お客様はアプリケーション、ノード、および統合に集中できます。

EKS は AWS のエコシステム全体への入り口でもあります。クラスターはデフォルトで ID 用の IAM を取得しており、 VPC 隔離されたネットワークの場合、 トラフィック分散のための弾性負荷分散コンテナイメージにはAmazon ECRを使用します。コントロールプレーンは、クロスアカウントのElastic Network Interface（ENI）を介してVPCに接続します。これについては、後述のネットワークセクションで詳しく説明します。

チームがEKSを特に選ぶ理由とは？ 

Datadogの調査によると、コンテナワークロード向けのパブリッククラウドとしてはAWSが依然として最も広く利用されており、AzureやGoogle Cloudを上回っている。 コンテナとサーバーレスの現状に関するレポートそのため、EKSはIAM、VPC、ECRといったAWSサービスを既に標準化しているチームにとって、デフォルトのKubernetesパスとなる。

AWS EKSはどのように動作するのですか？

EKSは、すべてのクラスターを2つのプレーンに分割し、AWSと顧客の間で明確な所有権の境界線を設けています。

1. その コントロールプレーン （AWSが管理）は、AWSマネージドアカウントで実行されます。これには、Kubernetes APIサーバー、スケジューラー、コントローラーマネージャー、およびetcdが含まれます。AWSはこれらのコンポーネントを3つのアベイラビリティゾーンに分散させ、パッチの適用、証明書のローテーション、およびKubernetesのマイナーバージョンアップグレードにおけるコントロールプレーン部分を実行します。
2. その データプレーン （お客様が管理する）サービスは、お客様のVPC内で実行されます。ここでは、ワーカーノード（EC2、Fargate、またはハイブリッド）が実際にPodを実行します。インスタンスタイプ、スケーリングポリシー、セキュリティグループ、ワークロードの配置はお客様が選択できます。

Podをデプロイするとどうなりますか？

あなたが走るとき kubectl apply -f deployment.yaml5つの操作が順番に行われます。

1. kubectlはEKS APIサーバーに対して認証を行います。 CLIはTLS経由でマネージドAPIエンドポイントに接続します。EKSはAWS IAM認証機能を使用して、IAM IDをKubernetes RBACロールにマッピングします。
2. APIサーバーはetcdに書き込みます。 ご希望の状態は、管理対象のetcdクラスタに永続的に保存されます。
3. スケジューラがノードを選択します。 スケジューラは、リソース要求、汚染度、許容度、およびノー​​ド親和性に基づいて、ポッドをワーカーノードに割り当てます。
4. kubelet は仕様を取得します。 ノードのkubeletはAPIサーバーをポーリングし、ECR（または別のレジストリ）からコンテナイメージを取得し、ポッドを起動します。
5. ネットワークが配線される。 デフォルトでは、Amazon VPC CNIプラグインはPodにVPCルーティング可能なIPアドレスを割り当て、VPC内でPodに第一級のネットワークIDを与えます。

コントロールプレーンとデータプレーン：どちらが何を所有するのか

分割は次のとおりです。 

EKSネットワークはどのように機能するのですか？

コントロールプレーンとワーカーノードは、それぞれ異なるVPCで実行されます。コントロールプレーンはAWSが管理するVPC内で動作し、ワーカーノードはユーザー自身のVPC内で実行されます。両者が通信できるように、AWSはVPCのサブネット内にクロスアカウントENIを作成します。これらのENIにより、マネージドAPIサーバーはパブリックインターネットを経由することなく、kubeletに直接アクセスできます。

この設定には、計画段階で考慮すべき2つの実用的な事項があります。

1. サブネットには、予想以上に多くの空きIPアドレスが必要です。 ワーカーノードをホストする各サブネットには、ENIとPodのIPアドレス用に十分な空きIPアドレスが必要です。デフォルトのAmazon VPC CNIは、すべてのPodにVPCルーティング可能なIPアドレスを割り当てますが、これは大規模なサブネットではIPアドレス空間を急速に消費します。250ノード用に設計されたサブネットでは、コンピューティングリソースが不足するよりもずっと前にアドレスが不足する可能性があります。
2. 必要に応じて、公開パスを閉じることができます。 プライベートAPIエンドポイントへのアクセスを有効にすると、すべてのkubectlトラフィックはVPCまたは接続されているプラ​​イベートネットワーク内に留まり、パブリックインターネットからコントロールプレーンへの経路は存在しません。

ほとんどのチームは、これを簡単に学ぶことはできません。「IPアドレス不足」アラートが発生したり、セキュリティ監査でパブリックエンドポイントが問題視されたりして初めて気づくのです。サブネットのCIDRは、初日からポッド密度に合わせてサイズを設定しましょう。

AWS EKSのデプロイモデルにはどのようなものがありますか？

EKSはワーカーノードを実行するための複数の方法をサポートしています。最適な方法は以下によって異なります。

• どの程度のコントロールを望みますか？
• どの程度の運用業務を引き受ける意思がありますか？
• あなたの仕事量には何が必要ですか？

前哨基地とハイブリッドノードは、関連するものの異なる問題を解決する。 

• ハイブリッドノード AWS上で動作するEKSコントロールプレーンに、オンプレミスサーバーやエッジサーバーを接続できます。 
• 前哨 さらに、AWSは物理インフラストラクチャをお客様のデータセンターに配送するため、コンピューティングと（オプションで）コントロールプレーンのエクスペリエンスは、お客様がホストするハードウェア上で実行され、EKS APIとツールを通じて管理されます。

AWS EKSの料金はいくらですか？

EKSクラスターには3つの独立したコスト項目がありますが、ほとんどのチームはそのうちの1つ（コントロールプレーン料金、ワーカーノードのコンピューティング、データ転送）しか見ていないため、請求額を過小評価しています。

1. クラスター料金

パー AWS EKSの料金ページAWSは、クラスターのKubernetesバージョンサポートティアに基づいて、クラスター1つあたり1時間あたり0.10ドルを課金します。 

この料金はコントロールプレーンの実行費用ですが、AWS の請求書ではコントロールプレーン料金ではなくクラスター料金と記載されています。 標準サポート対象のKubernetesバージョン （バージョンごとに14ヶ月）は重要です。なぜなら、延長サポートに入ると料金が1時間あたり0.60ドルに跳ね上がるからです。  

2. ワーカーノードの計算とストレージ

料金は別途請求され、ノードの実行方法によって異なります。

• EC2（マネージドまたはセルフマネージドのノードグループ）： 標準料金をお支払いください EC2の料金 インスタンスと接続されたEBSストレージの両方に対して課金されます。料金は1秒単位で、最低1分からとなります。リザーブドインスタンスやセービングプランは、他のEC2利用と同様に適用されるため、定常状態のワークロードでは通常、EC2ベースのノードの方が安価な選択肢となります。
• ファーゲート: AWSの請求 EKS Fargate 料金は、各ポッドに要求されたvCPU、メモリ、ストレージに基づいて計算されます。課金はイメージのダウンロード開始時からポッド終了時までで、秒単位の課金となり、最低利用時間は1分です。米国東部（オハイオ）リージョンでは、vCPU時間あたり約0.04048ドル、GB時間あたり約0.004445ドルです。ストレージ、パブリックIPv4アドレス、ログ記録、データ転送には追加料金が発生する場合があります。
• EKS自動モード: AWS が管理します ノードのプロビジョニング、スケーリング、セキュリティパッチ適用、アップグレード、健全性維持、およびノー​​ドの交換これにより、EKSデータプレーンの管理に必要な運用作業が削減されます。 

3. データ転送およびサポートサービス

データ転送料金は、アベイラビリティゾーン、AWSリージョン、およびパブリックインターネット間でのトラフィックの移動方法によって異なります。 

合計金額には、Elastic Load Balancing、NAT Gateway、EBSまたはEFSストレージ、パブリックIPv4アドレス、CloudWatchのログ記録および監視といった関連サービスも含まれる場合があります。これらの費用は別途請求され、トラフィックやクラスタの使用量が増加するにつれて高額になる可能性があります。

EKSはどのAWSサービスと連携しますか？

EKSは、以下の4つのカテゴリにわたってAWSエコシステムの他の部分と接続します。

• ネットワークと負荷分散： 隔離された環境にはAmazon VPC、トラフィック分散にはElastic Load Balancing、サービス間接続にはAWS PrivateLinkを使用します。
• ストレージ： 永続的なブロックストレージにはAmazon EBS、アプリケーションオブジェクトストレージにはAmazon S3、共有ファイルストレージにはAmazon EFSを使用します。
• 本人確認とセキュリティ： ID管理にはIAM、EKS Pod Identity、IRSAを使用し、暗号化キーにはAWS KMS、DDoS攻撃対策にはAWS Shieldを使用しています。
• 観測可能性と監視: メトリクスにはAmazon CloudWatch、監査ログにはAWS CloudTrail、分散トレーシングにはAWS X-RayとAWS Distro for OpenTelemetry（ADOT）を使用しています。

AWS EKSの主な特徴は何ですか？

主な機能は次のとおりです。 

• EKSアドオン： AWS は、VPC CNI、CoreDNS、kube-proxy、EBS CSI ドライバー、EFS CSI ドライバー、およびいくつかのオブザーバビリティ エージェントなど、Kubernetes の中核ツールをバージョン管理された状態で提供しており、すぐに使用できます。クラスターのアップグレード時にどのバージョンが互換性があるかを手動で追跡する必要はありません。AWS が自動的に処理します。
• サービスアカウント（IRSA）のIAMロール： IRSA は、すべてのノードに広範な IAM 権限を付与する代わりに、特定の IAM ロールをノードにバインドします。 Kubernetesサービスアカウントそのため、Pod は必要な AWS 権限を正確に継承します。たとえば、ノード全体の S3 アクセス権ではなく、特定の S3 バケットへの読み取りアクセス権などです。
• EKSポッドの識別情報: IRSAに代わる新しい選択肢です。EKSで管理されるエージェントを使用してAWS認証情報を仲介するため、クラスターごとにIRSAの信頼関係を設定する場合と比べて、複数のクラスターにわたるセットアップが簡素化されます。
• サービスメッシュの統合： EKSは以下と連携します イスティオ, リンカードさらに、AWSと統合されたメッシュツールも利用できます。サービスメッシュは、サービス間のmTLS接続、きめ細かなトラフィックポリシー、およびサービス間呼び出しの追跡機能を追加します。
• EKS Anywhereとハイブリッドノード： どちらも、標準的なEKSクラスターと同じAPIとツールを使用して、AWS以外の環境にもKubernetesの管理機能を拡張します。

AWS EKSは、セルフマネージドKubernetesと比較してどのような利点がありますか？

マネージドKubernetesは、チームの日々の業務方法を実際に変革して初めて効果を発揮します。EKSがどのような点で変革をもたらすのか、そしてそれぞれのメリットの背後にあるメカニズムを以下に説明します。

1. 制御プレーンの実行を停止します。 etcdのバックアップも、APIサーバー証明書のローテーションも、アップグレード計画をゼロから構築する必要もありません。これらの作業はAWSに移行し、エンジニアはこれまでプラットフォームの基盤構築に費やしていた時間を取り戻します。
2. MTTR コントロールプレーンがデフォルトで高い可用性を備えているため、ドロップが発生します。 EKSは、3つのアベイラビリティゾーンにまたがってAPIサーバーとetcdを実行します。1つのアベイラビリティゾーンで障害が発生してもクラスター全体が停止することはなく、冗長性の設計をユーザー自身で行う必要もありません。
3. リリースサイクルが高速化： 管理アドオン、IRSA、IAM統合、および統合 CI / CDデプロイメントは、「プラットフォームチームが四半期ごとにクラスターを再構築する」状態から「開発者が毎日リリースする」状態へと移行します。ArgoCDやFluxを使用してEKS上でGitOpsを実行しているチームは、一般的に週単位のリリースから日単位のリリースへと移行します。
4. 業務人員が減少する： 以前は2人の専任Kubernetes管理者が必要だった50人規模のエンジニアリングチームは、EKSがコントロールプレーンの作業を吸収することで、より小規模なプラットフォームチームで運営できるようになることが多い。エンジニアたちは、クラスターのアップグレード対応に追われるのではなく、社内開発者プラットフォームの構築に専念できるようになる。
5. セキュリティの基本レベルは予測可能である。 AWS は、既知のスケジュールに従ってコントロール プレーンにパッチを適用します。コンプライアンス チームは、AWS API 監査ログと Kubernetes 監査ログの統合に CloudTrail をデフォルトで利用できます。監査ログ自体に加えて、これにより、ID とアクセスの決定がノード構成やアドホック スクリプトに分散されるのではなく、IAM に一元化されます。これは、コンプライアンス レビュー担当者が実際に確認する点、つまり、過剰な権限が気づかれずに蓄積される場所が少なくなることを意味します。この組み合わせは、規制業界において EKS を単独で導入する十分な理由となる場合が多いです。

AWS EKSの制限事項は何ですか？また、どのような場合に適さないのでしょうか？

EKSは、すべてのチームやすべてのワークロードにとって最適なデフォルト設定ではありません。導入を決定する前に、以下の5つの制限事項と、実際に必要な要件を比較検討してください。

実際の運用フロアがあります

EKSだけでなくKubernetes自体も、名前空間、RBAC、イングレスコントローラー、CNIネットワークといった概念への理解を前提としている。 

その技術スタックに精通したエンジニアが少なくとも1人いないチームでは、Kubernetesの学習に費やす時間の方が、その恩恵を受ける時間よりも多くなってしまうでしょう。シンプルでステートレスなサービスであれば、ECSやApp Runnerを使えば、学習量を減らしつつ、より迅速に本番環境に移行できます。

ベンダーロックインは「AWSサービスを利用している」という表面的な問題よりも根深い。 

依存対象はIAMやVPCだけではなく、チームがそれらを中心に構築する運用習慣も含まれる。 

IRSAベースの権限モデル、VPC CNIネットワークの前提条件、ECRとCodeBuildに接続されたCI/CDパイプライン、CloudWatchメトリクスに基づいて構築された可観測性ダッシュボードはすべて、技術的な依存関係だけでなく、プロセス上の依存関係にもなります。後々EKSから移行するということは、マニフェストを再デプロイするだけでなく、ワークフローを再設計する必要があることを意味します。

安定した低トラフィックのワークロードでは、コストは予測不可能である。

1時間あたり0.10ドルのコントロールプレーン料金は、クラスターが何らかの処理を実行しているかどうかに関わらず適用され、Fargateは使用されたリソースではなく、要求されたリソースに対して課金します。 

トラフィック量の少ない少数の内部ツールを実行するクラスターは、特に複数の環境（開発、ステージング、本番）にまたがり、それぞれに独自の制御プレーン料金が発生する場合、ワークロードに見合わないほどのコストがかかる可能性があります。

トラブルシューティングは複数の領域にまたがる

EKS環境で発生した障害は、Kubernetes内部にとどまることは稀です。単一のインシデントがKubernetesのスケジューリング、AWS IAMの権限、VPCネットワーク、ロードバランサーの健全性に同時に影響を与えることはよくあります。つまり、デバッグにはkubectlのログだけでなく、これら4つの要素すべてに関する知識が必要になります。

作業負荷の規模と間接費は必ずしも一致しない 

EKSを単一の小規模サービスに運用するということは、Kubernetesのスケジューリング機能やスケーリング機能を必要としないワークロードに対して、完全なコントロールプレーンとネットワークのオーバーヘッドを支払うことを意味します。ある一定の規模を下回ると、運用上の複雑さがメリットを上回ります。

EKSが適していない可能性が高いケース： 

• 1つのチームが1つか2つの小規模でトラフィックの少ないサービスを運営しており、短期的な拡張計画はない。
• チーム内にKubernetesの経験を持つエンジニアはおらず、そのスキルを育成するための予算もない。
• 厳格なコスト予測要件と最小限かつ安定したトラフィックを伴うワークロード
• 単純なバッチジョブやスケジュールされたタスクは、Lambda または ECS で処理する方が適しています。

AWS EKSはAKS、GKE、OpenShiftと比べてどう違うのか？

EKSを評価しているほとんどのチームは、Azure Kubernetes Service (AKS)、Google Kubernetes Engine (GKE)、またはRed Hat OpenShiftも検討している。

• Azure Kubernetes Service（AKS） は、Microsoft が提供する Azure 上のマネージド Kubernetes サービスであり、Microsoft Entra ID、Azure Monitor、Azure DevOps ツールと密接に統合されています。
• Google Kubernetes Engine（GKE） Google Cloudが提供するマネージドKubernetesサービスであり、Kubernetesを開発した企業によって構築され、自動化と効率的なクラスタ管理に重点を置いています。
• Red Hat OpenShift は、Kubernetes上に構築されたエンタープライズ向けKubernetesアプリケーションプラットフォームです。Kubernetesの上に、統合された開発者ツール、CI/CD機能、セキュリティポリシー、ハイブリッドクラウド管理機能を追加します。

これら4つはすべてKubernetesによって管理されています。違いは、デフォルト設定、統合方法、エコシステムへの適合性に現れます。

それぞれを選択するタイミング:

• 選択する EKS AWSが主要なクラウドであり、別のプラットフォームを導入することなく、IAM、Amazon VPC、Amazon ECR、その他のAWSサービスとの緊密な統合を実現したい場合。
• 選択する AKS Microsoft Entra ID、Microsoft開発ツールに多額の投資をしている場合、またはMicrosoftと既存のエンタープライズ契約を結んでいる場合。
• 選択する G.K.E. 高度な自動化、強力なデフォルト設定、迅速な機能導入、そして成熟したクラスタ管理機能を備えたKubernetes環境を求めるなら、Kubernetesが最適です。KubernetesはGoogleが開発したものであり、その経験はプラットフォーム全体に反映されています。
• 選択する OpenShift クラウドとオンプレミスの両方で単一のプラットフォームが必要で、CI/CD、開発者セルフサービス、より厳格な運用ガードレールが標準で組み込まれている場合。

AWS EKSの一般的なユースケースにはどのようなものがありますか？

マイクロサービス、Webアプリケーション、機械学習といった一般的なユースケースは、あらゆる場面で繰り返し登場します。そこで、EKSが他の選択肢よりも明らかに優れている理由を、それぞれのシナリオごとに具体的に説明します。

• SaaSマルチテナント向けマイクロサービス： テナントごとの名前空間または仮想クラスターを実行するSaaSプラットフォームは、EKSを使用して、負荷の高い顧客を分離し、テナントごとのリソース制限を適用し、テナントごとに機能を展開します。
• フィンテックと規制対象業務： 金融サービス業界のチームは、SOC 2 を満たすために、IRSA、KMS、CloudTrail と EKS を使用しています。 PCI-DSSまた、独自のコンプライアンスレイヤーをゼロから構築することなく、内部監査要件にも対応できます。
• 高トラフィックのストリーミングおよびイベント駆動型アプリケーション： ストリーミングサービスは、トラフィックが急増した際に、管理対象ノードグループとFargate全体でポッドを柔軟に拡張し、オフピーク時には規模を縮小します。
• 機械学習のトレーニングと推論： EKSはGPUノードグループを備え、大規模なトレーニングジョブを実行します。S3、SageMaker、EFSとの統合により、データセットとモデル成果物を計算対象の近くに保持します。
• バッチ処理とビッグデータ処理： Kubernetes 上の Spark, ApacheAirflow, Argoワークフロー EKS上ではうまく動作します。特に、ノードを常に温めておくことが無駄になるような、負荷が急激に変化するワークロードに対しては、Fargateと組み合わせると効果的です。
• エッジコンピューティングとIoT： EKS Anywhere Kubernetesは、工場、小売店、遠隔地など、AWSとの接続が断続的または切断されている状況下でもワークロードを継続的に実行する必要がある場所に導入されます。
• ブルー/グリーンデプロイメントとカナリアデプロイメント： チームは、サービスメッシュやプログレッシブデリバリーツールで EKS を使用します。 アルゴのロールアウト (NAIST) と 報告者 クラスター全体に展開する前に、トラフィックのごく一部に対して新バージョンをリリースする。

AWS EKSはハイブリッドおよびマルチクラウド環境に対応していますか？

はい、AWS EKSは、EKS Anywhere、EKSハイブリッドノード、およびAWS Outpostsを通じて、AWS、オンプレミスインフラストラクチャ、およびエッジ環境全体にわたって一貫したKubernetes運用を実現します。 

環境ごとに個別のツールを管理する代わりに、インフラストラクチャがどこで稼働しているかに関わらず、同様のKubernetes API、ポリシー、および運用パターンを利用できます。

ハイブリッドKubernetesは、運用上の問題を解決できる場合にのみ、その複雑さに見合う価値があります。実際には、それは通常、次の4つのシナリオのいずれかに該当します。

1. データ保存場所: EUにおける金融記録や米国の一部の州における医療データなど、一部のワークロードは法的に管轄区域外への移動が禁止されています。こうした環境でEKSをオンプレミスで実行することで、データはローカルに保持され、プラットフォームの残りの部分はAWS上で動作します。
2. 災害からの回復： 重要なワークロードをオンプレミスのEKSクラスターにミラーリングすることで、単一のAWSリージョンの可用性への依存度を低減する復旧ターゲットが確保されます。
3. クラウドバースト： ベースラインワークロードは自社所有のオンプレミスハードウェア上で実行され、需要急増時のオーバーフローはAWS EKSによって処理されます。これにより、固定費を低く抑え、AWSの利用コストを年間を通して確保するのではなく、ピーク時のみに充当することができます。
4. 規制環境とエアギャップ環境： 防衛、政府機関、および一部の産業顧客は、エアギャップネットワーク内で運用を行っています。EKS Anywhereを使用することで、これらの顧客はシステムをパブリックインターネットに公開することなく、一貫したツールを使ってKubernetesを実行できます。

AWS EKSのベストプラクティスとは何ですか？

2日目の作業は、チームがコスト削減と回復力の維持に成功するか、あるいは意図せず両方を失ってしまうかの分かれ目となる。これらの実践方法は、私たちが最もよく目にするEKSクラスター全体に共通している。

Kubernetesの運用を自動化する

クラスターを定義する テラフォーム or AWS CloudFormation そのため、クラスタの再構築は再現可能であり、手動ではありません。アプリケーションコードには標準の CI/CD パイプラインを使用し、 ヘルメット さらに アルゴCD （または Flux）クラスターの状態について。これは、ほとんどのプロダクション EKS チームが採用している DevOps パターンであり、クラスター構成をアプリケーション コードと同じように扱います。

複数のセキュリティ対策を通じてセキュリティを強化する

単一の制御ですべてを網羅することはできないため、EKSのセキュリティは単一の大きなポリシーではなく、レイヤーとして構築するのが最適です。

• アイデンティティ： IAM、EKS Pod Identity、またはIRSAを使用して、PodがAWSの最小権限アクセスパターンに従うようにしてください。ワーカーノードに広範なIAMロールを割り当てることは避けてください。そうすると、ノード上のすべてのPodに同じアクセス権限が付与されてしまうためです。
• ネットワーク： ワーカーノードをプライベートサブネットで実行し、セキュリティグループを使用してトラフィックを制限し、フォレンジック調査のためにVPCフローログを有効にします。
• 暗号化機能： AWS KMSを使用して、保存時のシークレットを暗号化し、転送中のデータにはTLSを適用し、定期的にキーをローテーションします。
• クラスター衛生： Kubernetesのバージョンを定期的にアップグレードし（拡張サポートは存在するが、コストが大幅に高くなる）、ノードAMIを最新の状態に保ち、kube-benchのようなツールをCISベンチマークに対して実行してください。
• 名前空間とワークロードの分離： 本番環境、ステージング環境、共有サービス環境のワークロードをそれぞれ異なる名前空間に分離し、RBACの境界を各名前空間にスコープ設定します。これにより、影響範囲を限定できます。ステージング環境で設定ミスのあるデプロイメントが本番環境にネットワークやRBACの経路で到達することはなく、大規模なアクセスレビューを困難にするIDの乱立も軽減されます。

クラスターのパフォーマンスとコストを最適化する

適切なサイズのクラスターは、コストが低く、動作も高速です。

• 有効にする カーペンター または、Kubernetes Cluster Autoscalerを使用して、実際の保留中のPod需要に基づいてノードを追加および削除します。
• AWS Compute Optimizerを使用して、過剰なサイズのインスタンスを特定します。
• スケジューラがワークロードを効率的に配置できるように、ポッドのリソース要求と制限を適用します。
• ステートレスでフォールトトレラントなワークロードで、中断を処理できる場合は、マネージドノードグループでEC2スポットインスタンスを使用してください。スポットインスタンスの料金はオンデマンドインスタンスよりも大幅に安く、バッチジョブ、CIランナー、およびユーザーへの影響なしにポッドが失われる可能性のある水平スケーリングサービスに適しています。

AWS EKSの運用ライフサイクルとは何ですか？

運用ライフサイクルとは、クラスターのデプロイ後にチームが担当する作業、つまりアップグレード、スケーリング、可用性とフェイルオーバー、および災害復旧を指します。

アップグレード

上記の料金セクションで説明したように、AWS は各 Kubernetes マイナー バージョンを標準サポートで 14 か月サポートし、その後拡張サポート (およびそれに伴うより高いクラスター料金) が適用されます。一般的な EKS のアップグレードは、次の 3 つのステップで行われます。 

1. コントロールプレーンをアップグレードします（インプレース、AWSマネージド）。
2. 管理対象アドオンをアップグレードします。
3. ワーカーノードを回転させる。

EKSアップグレードインサイトは、アップグレードを開始する前にマニフェスト内の非推奨APIを警告表示し、本番環境に影響を与える前に破壊的な変更を検出します。

スケーリング

EKSは3つのレベルで拡張可能で、それぞれ異なるツールが用意されています。

1. ポッドレベル： 水平ポッドオートスケーラー（HPA）はレプリカ数を調整し、垂直ポッドオートスケーラー（VPA）はリソース割り当てを調整します。
2. ノードレベル: Cluster AutoscalerまたはKarpenterは、保留中のPodに基づいてデータプレーンを拡張または縮小します。EC2ベースのマネージドノードグループの場合、Cluster AutoscalerはEC2 Auto Scaling Groupを介して動作しますが、KarpenterはAuto Scaling Groupを経由せずにEC2のキャパシティを直接プロビジョニングするため、スケジューリングの負荷に対して通常はより迅速に対応できます。
3. コントロールプレーン: AWS は API サーバーと etcd のコントロール プレーンのスケーリングと可用性を管理します。このレイヤーはユーザーが設定するものではありません。

可用性とフェイルオーバー

AWS はデフォルトで複数のアベイラビリティゾーンに EKS コントロールプレーンをデプロイするため、単一のアベイラビリティゾーンの障害に対するクラスタの耐障害性が確保されます。ポッドトポロジーの分散制約を使用してポッドをゾーン間で分散することで、ワークロードにも同様の耐障害性を適用できます。

リージョンごとのフェイルオーバーを実現するには、別のAWSリージョンに2つ目のEKSクラスターをデプロイします。 ヨット バックアップとリカバリをサポートする一方、 カルマダ 複数のクラスターにわたるワークロードを管理します。

Disaster Recovery

地域的な災害に備え、別のAWSリージョンに2つ目のEKSクラスターをデプロイします。災害復旧には、Kubernetesリソースと永続データのバックアップも必要です。Veleroはバックアップとリストア操作をサポートしており、Karmadaなどのツールは、マルチリージョン展開における複数のクラスターにわたるワークロードの管理に役立ちます。

AWS EKSで監視すべき項目は何ですか？

ほとんどのチームはEKSの監視に十分な投資をしていません。なぜなら、クラスターは問題が発生するまでは正常に動作しているからです。実用的な監視戦略は、次の3つの段階に分けられます。 

1. 毎日の健康診断
2. 週ごとのキャパシティレビュー
3. 事象発生時の診断

1. 毎日 – 継続的に監視すべき健康指標：

• コントロールプレーンの指標: APIサーバーのレイテンシ、etcdのリクエスト処理時間、スケジューラのレイテンシ、および保留中のPodの動作。API応答の遅延は、ユーザーへの影響が現れる前に発生することが多い。
• ノードレベルのメトリクス： CPUとメモリの負荷、ディスク使用率、ノードの準備状況が不明なイベント、およびkubeletエラーは、ポッドのスケジューリング障害が発生する前に予測します。
• Podとワークロードのメトリクス： 再起動回数、OOMKilledイベント、準備状況プローブの失敗、リクエストレート、エラーレート、およびレイテンシ。

2. 週次 – 定期的に見直すためのキャパシティとコストのシグナル：

• ノードあたりのポッド密度と未使用容量を監視し、クラスターが過剰プロビジョニングに向かっている兆候を検知する。
• アイドル状態のポッドや利用率の低いノードグループは、回避可能なEKSコストの最も一般的な原因です。

3：インシデント発生時 – 何かが劣化した場合に即座に引き起こす信号：

• 最近の配備状況やマニフェストの変更が、インシデント発生時のタイムスタンプと相関していた。
• EKSのインシデントは単一のレイヤーに限定されることはほとんどないため、Kubernetesのスケジューリング、IAMの権限、VPCネットワーク、ロードバランサーの健全性など、ドメインを横断したチェックが必要です。
• サービスとユーザーへの影響に関するコンテキスト：どのサービスとユーザーが実際に影響を受けたか、単にどのポッドが再起動したかだけでなく。

LogicMonitorはAWS EKSの監視にどのように役立ちますか？

EKSはクラスターを提供しますが、そのクラスター内の問題がユーザーが実際に経験している問題と関連しているかどうかは教えてくれません。

LogicMonitorは、EKSシグナルレイヤーをより広範な自律型IT運用モデルに統合します。 

• ハイブリッドインフラストラクチャ全体にわたる統一された可視性 LMエンビジョン 
• インターネットパフォーマンス監視 デジタル体験のコンテキストを通じて Catchpoint（現在はLogicMonitorの一部）
• AI支援による相関関係 エドウィン AI. 

これらを組み合わせることで、インシデント発生時に手動で相関関係を調査するのではなく、ポッドの再起動と、それが影響を与えたサービス、変更されたユーザーエクスペリエンス、および再起動を引き起こした依存関係を関連付けることができます。

EKSの場合、LogicMonitorはAPIサーバーの状態、ポッドのリソース使用状況、コンテナのメトリクスに関する専用ダッシュボードを提供し、Edwin AIが注意が必要な情報とノイズを優先順位付けします。 

それが、ポッドアラートに溺れているチームと、どのインシデントに最初に対応すべきか、そしてその理由を理解しているチームとの違いです。

AWS EKS の利用開始方法を教えてください。

まず最初に、ネットワーク、アクセス制御、ワーカーノード、および可観測性の順に設定を行います。

1. VPCを計画する： ノード、ポッド、ENIに十分な容量を持つCIDR範囲を選択してください。ほとんどの運用環境では、3つのアベイラビリティゾーンにまたがる3つのプライベートサブネットが使用されます。
2. IAMを設定する： EKSクラスターとワーカーノード用のIAMロールを作成し、ワークロードがAWSアクセスにIRSAを使用するかEKS Pod Identityを使用するかを決定します。
3. クラスターを作成します。 デプロイするには exctlAWS CLI、Terraform、または AWS CDKアップグレードのリスクを軽減するために、標準サポート対象で十分な期間提供されているKubernetesバージョンを使用する。
4. kubectl アクセスの設定：実行 aws eks update-kubeconfig –name -地域 デプロイを行う前に、ローカルのkubeconfigにクラスターを追加し、アクセス権限を確認してください。
5. ワーカーノードを追加する： デプロイメントモデルを選択してください。ほとんどのチームは、AWSがノードのライフサイクル管理を担うマネージドノードグループから始め、ワークロードの増加に応じて後から容量を調整します。
6. コアアドオンをインストールします。 VPC CNI、CoreDNS、kube-proxy、およびEBS CSIドライバーをインストールします。EKSが管理するアドオンは互換性のあるバージョンを追跡するのに役立ちますが、アドオンの更新は引き続きご自身で開始する必要があります。
7. 可観測性とアクセス権限を設定する： LogicMonitor、Prometheus、CloudWatchなどの監視・ログツールを接続し、CI/CDパイプラインを構成し、ユーザーとサービスに対するRBACポリシーを定義します。

AWS EKSのセットアップでよくあるトラブルとは？

初期設定時にチームが最も頻繁に直面する問題点は以下のとおりです。

• サブネットIPアドレスの枯渇： VPC CNIは各ポッドにVPC IPアドレスを割り当てますが、ポッド数が増えるにつれて、小規模なサブネットでは利用可能なIPアドレスがすぐに不足してしまいます。
• aws-authの設定が不足しています。 aws-auth ConfigMapまたはその新しい代替バージョンがない場合、アクセスエントリ、ワーカーノード、およびユーザーの認証または認可が失敗する可能性があり、IAM ユーザーは Kubernetes リソースへの kubectl アクセスを失います。
• 公開APIエンドポイントの公開： EKSクラスターは、エンドポイントへのアクセス設定が制限されていない場合、デフォルトでKubernetes APIエンドポイントを公開することがよくあります。本番環境のワークロードを稼働させる前に、公開アクセスを制限してください。
• ピン留めされたアドオンバージョン: 自己管理型のアドオンは、Kubernetesのアップグレード後に互換性を失う可能性があります。EKS管理型のアドオンは、バージョン間のずれを軽減し、メンテナンスを簡素化します。
• 不足しているポッドリソース要求: CPUとメモリの要求がないと、Kubernetesはワークロードを効率的にスケジュールできず、その結果、オートスケーリングの動作が不安定になり、不要なインフラストラクチャコストが発生します。

LogicMonitorでKubernetesへの投資効果を最大化しましょう

AWS EKSはKubernetesコントロールプレーンの運用という負担を軽減しますが、プラットフォーム単体ではEKSの問題がユーザーに影響を与えているかどうか、あるいはどのインシデントが実際に最も重要かを判断することはできません。モニタリングを行うことで、EKSは「クラスターは技術的に正常です」という状態から、チームが信頼して迅速に対応できるシステムへと変わります。

LogicMonitorは専用の Kubernetes モニタリング APIサーバーのパフォーマンス、コンテナの状態、ポッドのリソース使用状況などを網羅したダッシュボードには、チームが問題が深刻化する前に検知して解決するのに役立つリアルタイムのメトリクスが含まれています。