re:Invent 2024: AWSが語るAmazon EKSのHybrid/Edgeソリューション
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Amazon EKS for edge and hybrid use cases (KUB310)
この動画では、Amazon EKSのHybridとEdgeソリューションについて、AWSのSenior Product ManagerのEric ChapmanとContainer Specialist Solutions ArchitectのGokul Chandraが解説しています。AWS Outposts上のAmazon EKS、Amazon EKS Anywhere、そして新機能のAmazon EKS Hybrid Nodesという3つの主要なソリューションの特徴と使い分けについて詳しく説明されています。特に、NTT DOCOMOが約15,000のセルサイトと35,000以上のベアメタルサーバーでEKS Anywhereを活用している事例や、DarktraceがEKS Hybrid Nodesを採用してKubernetesの管理をAmazon EKSに統合した事例など、具体的な導入事例も紹介されています。各ソリューションのアーキテクチャやベストプラクティス、責任共有モデルについても詳細な説明がなされています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon EKSによるハイブリッドとエッジユースケースの紹介
セッションへようこそ。本日は「Cube 10 Amazon EKS for Edge and Hybrid use cases」についてお話しさせていただきます。私はAmazon EKSチームのSenior Product Managerで、HybridとEdgeを担当しているEric Chapmanです。本日は、TelcoバーティカルにおけるEKS HybridとEdgeソリューションの導入を専門とするContainer Specialist Solutions ArchitectのGokul Chandraと一緒に登壇させていただきます。今回は、Amazon Elastic Kubernetes Service（EKS）が、EdgeやオンプレミスでのワークロードデプロイメントとAWS上での実行を含むHybrid戦略を採用しているお客様が直面する課題をどのように解決できるかについて、詳しくご説明させていただきます。
まず、複数の環境で運用する際にお客様が直面する一般的な課題について説明します。次に、標準化がどのように役立つのか、なぜますます多くのお客様が標準プラットフォームとしてKubernetesを選択し続けているのか、そしてKubernetes採用後も残る課題について説明します。Amazon EKSチームとして、環境全体でのKubernetesのデプロイメントをより簡単に、より効率的に、より一貫性のあるものにするために、どのような取り組みを行っているかをご紹介します。また、EKS Hybridソリューションそれぞれのアーキテクチャとベストプラクティスについて説明し、最後にre:Inventやそれ以降でEKSについてより詳しく学ぶ方法をご紹介します。
ハイブリッド環境における課題とKubernetesの標準化
まずは、お客様がHybridアプローチを選択する理由と、それに伴って発生する課題を含むシナリオからお話を始めましょう。 例えば、複数の事業部門を持つ企業のプラットフォームエンジニアリングマネージャーだとします。クラウド運用はAWS上のEKSで動作するKubernetesに標準化されており、多くのアプリケーションはクラウドネイティブで、ネットワーク、ストレージ、データベースにAWSサービスを利用しています。しかし、依然として多くのアプリケーションがオンプレミスで動作しており、近い将来もオンプレミスでの運用が続く予定です。これらのアプリケーションの中には、クラウドへの移行が困難なレガシーテクノロジーと密接に統合されているものもあれば、エンドシステムとの物理的な近接性が必要なコンピューティングを必要とするもの、あるいは低レイテンシーのためにEdgeで実行する必要があるものもあります。また、機密性の高い顧客データを扱い、厳格なデータレジデンシー要件に直面しているアプリケーションもあります。
これらのアプリケーションは、異なるシステム上で動作し、異なる運用モデルと異なるスキルセット要件を持っているため、チーム間でスケールできないサイロが生まれています。プラットフォームのパフォーマンスを向上させたり、開発チームのイノベーションを支援するための機能を追加したりすることに注力するのではなく、プラットフォームの安定性とビジネスの継続性を維持するために、基盤システムの手動パッチ適用やメンテナンスに多くの時間を費やしています。もし、チームが行っている差別化されていない運用作業の一部を軽減できれば、開発者エクスペリエンスを向上させ、最終的にはお客様自身のエクスペリエンスを改善するようなイノベーションに注力できるはずです。
アプリケーションが様々な統合を伴う異なるシステム上で動作しているため、サポートが必要なテクノロジースタックが複数存在します。複数のテクノロジースタックをサポートすることで、さらなる課題が生じます。 まず、開発チームのための迅速なイノベーションが妨げられ、あるテクノロジースタックへの改善が他のスタックに継承されないため、個々の改善のROIが制限されます。手動プロセスの増加、古いバージョン、他の依存関係との厳密な結合により、迅速な変更が困難になっています。 さらに、各テクノロジースタックには、必ずしも環境間で転用できない異なるスキルセットが必要で、プラットフォームを定常状態で維持するためだけにチームを拡大せざるを得ない状況になっています。
単一のプラットフォームに標準化できれば、チームのイノベーション能力を解き放てると考えられます。クラウドでのKubernetesの爆発的な人気により、オンプレミスとクラウド環境の両方で運用している多くのお客様が、Kubernetesを標準として採用し、実行環境を問わず一貫したツールで統合していることが分かります。 クラウドでミッションクリティカルなアプリケーションの高可用性とスケーラビリティを確保するため、コンテナ管理プラットフォームとしてKubernetesを選択したとしましょう。Kubernetesのオープンで拡張可能な性質により、チームが容易に採用できるツールの健全なエコシステムやGitOpsのような革新的な手法の発展が促進されました。そして、Kubernetesはオープンソースの標準であるため、アプリケーションの実行が必要なあらゆる環境で運用することができます。
実際、オンプレミスで運用している多くのアプリケーションチームが、すでにKubernetesを採用しているとしましょう。このような標準化によるメリットは確かに得られていますが、運用上のオーバーヘッドが依然としてチームのイノベーション能力の妨げとなっています。 この標準化により、環境間での開発リソースの互換性は向上しましたが、Kubernetesクラスターの管理を任されている担当者にとって、依然として非常に急な学習曲線が存在します。Kubernetesコントロールプレーン自体の管理、クラスターの健全性維持、証明書の適時ローテーション、DHCPのIPリースの期限切れ防止など、その複雑さを過小評価していたかもしれません。
また、クラスターフリート全体でワークロードが拡大するにつれて、コントロールプレーンを継続的にスケールすることも予想以上に困難でした。これらは、多くの組織がクラウドでAmazon EKSを選択する要因となった課題と同じであり、複数のクラウドにまたがって運用する顧客がマネージドKubernetesソリューションを選択する理由でもあります。
Amazon EKSのハイブリッドソリューション：AWS OutpostsとEKS Anywhere
Amazon EKSは年間数千万のクラスターを管理しており、管理されるクラスター数は前年比33%の成長を続けています。AWSのKubernetesチームの目標は、お客様がどこで運用する必要があっても、Kubernetesの運用面を後回しにできるようにすることです。2019年のAWS OutpostsでのAmazon EKSの導入以来、Amazon EKSチームの重点分野の1つは、マネージドサービスのメリットを提供し、環境間での運用の一貫性を実現するために、Amazon EKSをハイブリッド環境に展開することでした。
ご存じない方のために説明すると、AWS Outpostsは、お客様のデータセンターやコロケーション施設にAWSサービスを拡張するAWSマネージドインフラストラクチャで、コンピューティング用のAmazon EC2、ストレージ用のAmazon S3とAmazon EBS、ネットワーキング用のAmazon VPCなどが含まれます。Amazon EKSは2019年の一般提供開始以来AWS Outpostsで利用可能であり、AWS OutpostsでこれらのAWSサービスが利用可能であることと、Amazon EKSによってクラウドでKubernetesコントロールプレーンが管理されることから、AWS OutpostsでAmazon EKSノードを実行することで、リージョンでのAmazon EKSノードの実行と最も一貫性のある体験とAWSとの緊密な統合が実現できます。
AWS Outpostsのお客様は、一般的な自動化や、銀行業務やリアルマネーゲームなどのローカルデータ処理が必要なユースケースにおいて、Amazon EKSを採用されています。お客様は、Amazon EKSをリージョンで実行する場合と比較して、AWS Outposts上で実行する際の運用の一貫性を高く評価されています。多くのお客様がオンプレミスインフラを刷新できる状況にないことから、2021年にAmazon EKS Anywhereを発表し、お客様のニーズに応えることにしました。Amazon EKS Anywhereは、仮想環境やベアメタル環境でお客様が管理するハードウェア上で実行されるクラスターのインフラストラクチャプロビジョニングとライフサイクル管理を簡素化する、AWSがサポートするKubernetesマネジメントソフトウェアを提供します。
Amazon EKS Anywhereは、AWSによってテストおよびサポートされているインフラストラクチャプロバイダー、Kubernetesコンポーネント、およびオペレーティングシステムを備えた、完全にお客様が管理するソリューションです。Amazon EKS Anywhereのサブスクリプションには、ロードバランシング、Ingress、モニタリングなどのコアKubernetes機能を拡張する、厳選されたアドオンパッケージに対するAWSサポートが含まれています。Amazon EKS Anywhereは、オンプレミスネットワークに関してより厳格な要件を持つお客様や、ネットワーク接続が切断、中断、断続的、または制限された環境で運用する必要のあるお客様に特に人気があります。
これらのユースケースには、ネットワークエッジのベアメタル上で実行する必要のあるTelcoアプリケーション、より厳格なネットワークおよび規制要件に直面する金融サービスアプリケーション、そしてインターネット接続が数日から数週間にわたって利用できない可能性のあるクルーズ船を運航する旅行・ホスピタリティ企業のアプリケーションが含まれます。私たちは主要なTelco ISVソリューションとの互換性のためにAmazon EKS Anywhereを強化しており、Gokulが大手Telcoのお客様がAmazon EKS Anywhere上で5Gワークロードを実行するために使用しているアーキテクチャについて説明します。お客様は、Amazon EKS Anywhereで既存のオンプレミス投資を活用しながら自社のハードウェア上で継続して運用できる一方、AWS OutpostsのAmazon EKSではKubernetesコントロールプレーンをクラウド上でAmazon EKSに管理してもらえることを評価しています。数十社のお客様との対話を通じて、既存のハードウェアで運用を継続しながら、コントロールプレーンの管理を必要としないソリューションへのニーズが明確になりました。そこで私たちは、既存のハードウェア上でKubernetesノードを実行し、クラウドで実行されているAmazon EKSコントロールプレーンに接続できる新機能、Amazon EKS Hybrid Nodesの一般提供を発表できることを嬉しく思います。
Amazon EKS Hybrid Nodesは、クラウドでのAmazon EKSの実行とオンプレミスでの実行との間で、より一貫性のある運用体験を実現します。Hybrid Nodesでは、既存のオンプレミスハードウェア投資を活用しながらワークロードをオンプレミスで実行し続けることができる一方で、Kubernetesコントロールプレーンの管理運用の責任をAWSが担います。これにより、オンプレミスのキャパシティをアプリケーションワークロード専用に確保することができます。
クラウド上のAmazon EKSと同様に、Kubernetesコントロールプレーンのスケールアップとスケールダウンについて心配する必要はありません。これらはすべてEKSによって管理されます。EKS Hybrid Nodesは、オンプレミスまたはエッジロケーションがAWSとネットワーク接続できるお客様にとって最適な選択肢であり、ほとんどのハイブリッドのお客様にとってスイートスポットになると考えています。Hybrid Nodesは、メディアストリーミングや製造業などの分散エッジユースケース、さらには一般的な企業のモダナイゼーション、そして現在お客様がEKS on AWS Outpostsで使用している多くの同様のユースケースで特に人気が出ると予想しています。
EKSクラスターにHybrid Nodesを導入すると、単一のクラスター内でクラウドノードも実行できるようになり、オンプレミスとクラウドのGPUを活用してトレーニング能力を強化したり、推論処理のバースティングを行ったりするAIやML用途への道が開かれます。EKS Hybrid Nodesについて、もっと詳しくお話しできることを大変楽しみにしています。ただその前に、Amazon EKS on AWS OutpostsとAmazon EKS Anywhereについて、より詳しく説明してくれるGokulにバトンを渡したいと思います。
AWS OutpostsでのAmazon EKSの活用とNTT DOCOMOの事例
ありがとうございます、Eric。では、現在のAWS OutpostsがAmazon EKSを使ってどのようにオンプレミスインフラを強化できるのか、お話ししていきましょう。お客様がオンプレミスでKubernetesクラスターやPodをデプロイする主な理由は、レイテンシーの削減とセキュリティの強化です。ハイブリッドキャパシティが単なる要件ではなく必須となるユースケースは数多くあります。クラウドからオンプレミス環境へのクラスター拡張であれ、ハイブリッドコンピュートキャパシティの管理であれ、ハイブリッドコンピューティングプラットフォームの設計であれ、AWS Outpostsはそれらすべてのユースケースに対応できます。
AWS OutpostsでのAmazon EKSクラスターのデプロイには、2つのオプションがあります。1つ目は拡張クラスターで、通常のリージョンベースのクラスターと同じように、まずEKSのクラウドベースのコントロールプレーンを作成し、その後、実際のワークロードをホストするクラスターノードを、データセンターに設置されリージョンに接続されたAWS Outpostsラック上のハイブリッドモデルにデプロイします。このアプローチでは、AWSによって完全に管理されるKubernetesコントロールプレーンと、現在リージョンで利用可能な他のサービスエコシステムとの統合された体験が得られます。
2つ目のモデルはローカルクラスターです。これは、特定のユースケースを念頭に置いて開発されました。データセンターが都市圏の最終地点に位置している場合や、AWS OutpostsでEKSを実行するために必要な継続的なネットワーク接続に問題がある隔離された環境など、信頼性の高いネットワーク接続を確保できない環境やデプロイ設定を持つお客様の声に応えたものです。このような状況に対応するため、ローカルクラスターを導入し、接続が切断された場合でもKubernetesベースの運用を継続できるようにしました。
ローカルクラスターは接続が切断された状況でもワークロードを中断なく実行できる拡張機能を提供しますが、AWSとしては拡張クラスターを推奨オプションとしています。なぜなら、拡張クラスターでは、KubernetesコントロールプレーンがAWSによって完全に管理され、よりシームレスな統合された体験をお客様に提供できるからです。また、クラウド内には多数のエコシステムサービスが用意されており、お客様はこれらを直接利用してワークロードポートフォリオ全体を強化することができます。
先ほど説明したExtended Clustersのアーキテクチャがどのように構成されているか見ていきましょう。 まず、お客様はAWS Outpostsラックを注文することから始まります。このAWS Outpostsラックはお客様に出荷され、お客様自身のデータセンターに設置された後、Service Linkアプローチを使用してAWS Regionに接続されます。
Service LinkではAWS Direct Connectサービスを利用して、Outpostsの環境からRegionへの高スループットで安全な接続を提供します。その後、お客様はVPCを作成できます。 ネットワーキングに関しては、Region内の複数のAvailability Zoneにまたがる複数のサブネットを持つVPCを作成できるという点で、Regionベースのアプローチと同様の方法でネットワークが作成されます。
AWS Outpostsがお客様のアカウントに登録され、データセンターに設置されると、Region内に作成された同じVPCをこのOutpostsラックまで拡張することができます。つまり、同じVPC内に複数のサブネットを作成する際に、Outpostsをアベイラビリティゾーンとして選択できるということです。これにより、AWS Outpostsがシームレスに実現する構成要素を使用して、クラウドからお客様自身のデータセンターへとネットワークを拡張することが可能になります。
このネットワーク構成が確立されると、現在のクラウドベースのクラスターと同じ方法で、Amazon EKSコントロールプレーンを作成できます。 重要なポイントとして、Amazon EKSコントロールプレーンはRegionに作成され、クロスアカウントENIアーキテクチャを使用してRegionベースのサブネットにアンカリングされます。この際、Amazon EKSコントロールプレーンは完全にAWSによって管理されます。これは、Outpostsインフラストラクチャまで拡張した同じVPC内のサブネットにアンカリングされます。
コントロールプレーンのデプロイ後、データセンター内に配置されたインフラストラクチャに拡張した同じOutpostsサブネット内にSelf-managed Node Groupsを作成することから始めます。Amazon EKSコントロールプレーンはRegionベースのサブネットで作成できますが、実際のKubernetesノードはOutposts環境に配置されたサブネット内で実行されることになります。Self-managed Node Groupは複数のノードで構成されており、これらは技術的にはEC2インスタンスです。なぜなら、AWS OutpostsラックはAWSポートフォリオの一部として複数のサービスを提供しており、RegionベースのEC2サービスに依存することなく、お客様自身の環境でEC2インスタンスを実行できるからです。
このOutposts環境内でアプリケーションをデプロイする際、データセンター環境内ですでに稼働している別の環境やポートフォリオが存在するかもしれません。そこで私たちは、Local Gatewayと呼ばれる仕組みを提供しています。これにより、Amazon EKS環境で稼働しているアプリケーションと、データセンターのインフラ上で稼働している既存のアプリケーションとの通信が可能になります。この機能によって、Outposts上で稼働するアプリケーションと、データセンター内のインフラコンポーネントとのシームレスな接続が実現できます。
Amazon EKS Anywhereの詳細と導入事例
ここまで、AWSが提供・管理するハードウェアであるAWS Outpostsを活用し、その上にAmazon EKSクラスターをデプロイすることで、クラウドからお客様自身のデータセンターへとアプリケーションポートフォリオを拡張する方法について説明してきました。では、お客様が自社のハードウェア上でアプリケーションを実行したい場合はどうでしょうか？これには、サードパーティのハードウェアを調達した場合や、すでにデータセンターに存在する自社のハードウェアに多額の投資をしている場合などが含まれます。ここでは、お客様が完全に分離された環境でクラスターをデプロイしたい場合の要件について説明させていただきます。
完全に分離された環境というのは、リージョンベースの接続やインターネット接続が環境外に一切出ていかないことを意味します。そこで登場するのがAmazon EKS Anywhereです。Amazon EKS Anywhereを使用することで、お客様は自社のコストベースのハードウェアや、VMwareクラウドスタックなどの既存の仮想化環境上にクラスターをデプロイすることができます。これにより、リージョンベースのAmazon EKSクラスターと同じ一貫性を持ってクラスターをデプロイすることが可能になります。
それでは、Amazon EKS Anywhereのアーキテクチャがどのようなものか見ていきましょう。 これは、AWSが提供する一貫したKubernetesプラットフォームとしてのAmazon EKS Anywhereを構成する完全なコンポーネントスタックです。インフラストラクチャプロバイダーの説明に入る前に、Amazon EKS AnywhereがCluster APIの基盤に基づいて設計されていることを強調しておく必要があります。Cluster APIは、クラスターのライフサイクル管理を標準化・簡素化するサブプロジェクトです。Amazon EKS AnywhereはCluster API（コミュニティではCAPIと略称）から様々なアーキテクチャパターンを継承しています。
インフラストラクチャプロバイダーとは、Amazon EKS Anywhereが様々な選択肢にデプロイできることを意味します。ベアメタルサーバー上にデプロイすることができ、その場合はベアメタルサーバーを完全に活用してAmazon EKS Anywhereクラスターをその上にデプロイできます。ベアメタルアプローチでは、クラスターのデプロイだけでなく、Tinkerbellを使用したサーバーのイメージング管理という面倒な作業も私たちが担当します。Tinkerbellは、AWSがクラウドネイティブにするために多大な貢献をしたオープンソースプロジェクトです。もう一つのインフラストラクチャプロバイダーは仮想化環境です。つまり、すでにVMware環境やクラウドスタック環境をお持ちの場合、仮想マシンを管理するこの既存の仮想化レイヤーを使用して、その上にAmazon EKS Anywhereをデプロイすることができます。私たちは、仮想化環境上でクラスターを作成するための完全に自動化されたシームレスなアプローチで、エンドツーエンドの体験を提供します。また、Nutanixなどのパートナー環境もサポートしており、AWSのエッジベースデバイスであるAWS Snow上でもAmazon EKS Anywhereクラスターをデプロイする機能を完備しています。
Amazon EKS Anywhereで使用されるKubernetesディストリビューションは、AWSのKubernetesディストリビューションであるAmazon EKS Distroと呼ばれています。重要なポイントとして、これは現在、本番環境で数百万のクラスターを稼働させているお客様が各リージョンで使用している、まさに同じKubernetesディストリビューションだということです。このディストリビューションにより、ユーザーはAWSに信頼を置くことができます。AWSがセキュリティパッチの管理や、このディストリビューションのベースイメージの構築に責任を持つため、セキュリティパッチの適用やCVE分析、脆弱性分析などに時間を費やす心配をすることなく、クラスターをデプロイすることができます。
次に、クラスターのライフサイクル管理、クラスター運用、そしてContainer Network Interface（CNI）の層があります。CNIは、Kubernetes環境上で実行されるPodとServiceの基本的な接続性を提供します。Amazon EKS Anywhereには、クラスターの作成、削除、アップグレード、更新、ノードの追加と削除などの運用をシームレスに行うためのコントローラー群が同梱されています。Amazon EKS AnywhereでメインでサポートされているCNIは、Ciliumです。
EKS AnywhereのデフォルトCNIとしてCiliumを採用していることは、重要な差別化要因となっています。Amazon EKSがリージョン内でどのように動作するかご存知の方は、リージョン内でフラットなネットワークモデルを提供するAWS VPCを使用していることをご存じでしょう。しかし、Amazon EKS Anywhereは、お客様のデータセンター内で動作する完全に独立したオプションであるため、AWS VPCを使用することができません。先ほど説明したAWS Outpostsでのオプションと同様に、OutpostsのクラスターではVPCを使用しますが、EKS Anywhereの場合は、完全にAWSの管理外であり、お客様自身のデータセンターの独自のハードウェア上に配置されるため、お客様独自のネットワークを使用することになります。そのため、EKS AnywhereではデフォルトのCNIとしてCiliumを同梱しています。
次は運用とツーリングの層です。EKSクラスターやKubernetes環境を作成するだけでは、本格的なアプリケーションポートフォリオを実行するには十分ではありません。エンドユーザーがアプリケーションを利用できるようにするために必要な様々な活動を行うため、Kubernetes環境にデプロイしなければならない特定のツールが必要です。例えば、ロードバランサーやIngress、イメージレジストリなどが挙げられます。お客様からよく聞かれる課題として、これらのコンポーネントをアップストリームのコミュニティから直接利用する場合、コミュニティベースのサポートに頼らざるを得ないということがあります。あるいは、パートナーネットワークや企業ベンダーからコンポーネントが提供されている場合、そのベンダーのサポートを受ける必要があります。
そこで私たちは、Curated Packagesを導入しました。これにより、お客様はAWSが設計・定義した事前キュレーションされたパッケージを使用できるようになり、AWSがKubernetes環境上でのこれらのコンポーネントの管理責任を持ちます。例えば、Harbor、Emissary、MetalLBは、よく知られたオープンソースのコミュニティベースのプロジェクトです。Curated Packagesを使用する場合、これらのメンテナンス、バージョン互換性の管理、実行しているKubernetesバージョンとの互換性について心配する必要はありません。AWSがEKS環境上のこれらのアドオンの完全なサポートを提供します。セキュリティの観点からも、Kubernetes上で使用している特定のアドオンにセキュリティ脆弱性が見つかった場合、Curated Packagesを使用していれば、コミュニティがパッチバージョンを提供するのを待つ必要はありません。AWSがコードの管理を含め、ポートフォリオで利用可能なすべてのアドオンの完全なサポートを提供します。
次に、現在、EKSクラスターを作成・管理する方法には複数のアプローチがあります。1つ目はCLIモデルです。私たちは包括的なCLIメカニズムを提供しています。リージョンでのEKSクラスターの運用に慣れている方々にとって重要なポイントは、Kubernetesクラスターを提供するベンディングマシンとして機能する一貫したAPIエンドポイントが用意されていることです。AWS CLIやインフラストラクチャ・アズ・コードのツールを使って、このAPIエンドポイントを直接呼び出し、リージョン内にEKSクラスターを作成することができます。ただし、EKS Anywhereの場合は、お客様自身のデータセンターに設置され、お客様が運用するため、この方法は適用できません。そこで、CLIで利用可能な包括的なオプションを使用して、同様の一貫した体験を提供しています。eksctlは当初からリージョン内でクラスターを作成するためのアプローチでしたが、anywhereという拡張機能を追加し、お客様の環境内でクラスターを運用・管理する機能を提供しています。2つ目のオプションは、インフラストラクチャ・アズ・コードツールを好む方向けのTerraformです。
Amazon EKS Anywhereクラスターの作成と管理のために、カスタムTerraform Providerを提供しています。推奨されるアプローチは、Cluster APIから継承したアーキテクチャパターンを活用するもので、クラスターの設定全体をGitリポジトリに保存し、GitOpsを使用してクラスターを完全に管理することができます。EKS Anywhereでは、パッケージの1つにFlux Controllerが含まれています。これは、コミュニティで利用可能な主要なGitOpsベースのコントローラーで、私たちも貢献しEKS Anywhereにパッケージングしており、GitHubベースのアプローチをインフラストラクチャに対して実現します。ここで重要なのは、アプリケーションの管理のためのGitOpsではなく、インフラストラクチャ自体の管理について説明していることです。
リージョンベースの接続性に関して、EKS Anywhereがエアギャップ環境や隔離環境でリージョンベースの接続に依存せずに運用できることについて説明しましたが、クラウド内のマネージドサービスの利用に興味のあるお客様は、必要に応じてリージョンへのオプションの接続を確立することができます。お客様の一般的なユースケースとして、Amazon Managed Service for PrometheusやAmazon Managed Grafanaなど、リージョンで利用可能なサービスを通じて、数千のEKSクラスターの一元的な監視ダッシュボードメカニズムを使用するケースが見られます。これは、EKS Anywhereが必要に応じてクラウドベースの接続性を維持できることを示しています。
EKS Anywhereは、ワークロードクラスターと管理クラスターを持つ標準化された手順に従って、2つの異なるデプロイメントトポロジーをサポートしています。1つ目のオプションは、シングルクラスターベースのアプローチで、ノードの追加、削除、クラスターのアップグレードなどのクラスター管理タスクに必要なすべてのコントローラーがプロビジョニングされた単一のクラスターを管理できます。2つ目のアプローチは、管理クラスターとワークロードクラスターのトポロジーです。このセットアップでは、デプロイされたクラスターの作成、更新、ライフサイクル管理を担当する完全なコントローラーセットを備えた中央管理クラスターを持ちます。この管理クラスターをエンドポイントとして使用し、エンドユーザーのワークロードがデプロイされるワークロードクラスターのフリートを作成・運用することができます。管理クラスターとワークロードクラスターの間には明確な区別があり、管理クラスターにデプロイされたコントローラーはワークロードクラスターには存在せず、クラスターのライフサイクル運用ではなくエンドアプリケーション用にリソースを確保します。
通常、3つ以上のEKS Anywhereクラスターを持つお客様には管理クラスターアプローチを推奨しています。これは、クラスター管理において具体的なガバナンスを提供し、データセンター環境内のクラスターポートフォリオ全体のシングルペイン監視を可能にするためです。宣言的オプションとセルラークラスター管理については（これは数百のKubernetesクラスターを実行するお客様にとって重要です）、シンプルなYAMLベースの設定インターフェースを使用しています。この設定ファイルには、クラスター名、ネットワーク名、コントロールプレーンノードの数、ワーカーノードの設定など、クラスターの仕様が定義されています。GitOpsベースのアプローチと管理クラスタートポロジーを組み合わせることで、特定の管理クラスターがGitを使用してワークロードクラスターのフリートを運用するセルラー管理を実装できます。管理クラスターは同期ポイントとして機能し、Gitソースを通じて提供されたすべての設定を実現して、複数のワークロードクラスターを作成・運用します。
顧客へのヒアリングを行うと、それぞれの顧客が独自の要件を持っていることがわかりました。Kubernetesクラスターを作成する際、リソースに制約がある場合もあるため、必ずしもマルチノードクラスターの作成を強制することはできません。そこで、私たちは異なるデプロイメントオプションをサポートしています。第一のオプションは、各ノードがコントロールプレーンまたはデータプレーンノードとして機能するマルチノードアプローチです。第二のオプションは、マスターノードとワーカーノードを同一ホストに配置するもので、高可用性マスターを持つ3つのノードで、同じマシン上でワーカーノードを実行できます。第三のオプションは、シングルノードアプローチで、Amazon EKS Anywhere環境またはEKS Anywhereクラスター全体を1台のベアメタルノード上で実行できます。
これらが現在Amazon EKS Anywhereでサポートしている異なるデプロイメントオプションですが、ここで具体的なユースケースをご紹介したいと思います。EKS Anywhereを活用して、日本のある通信事業者が全国規模のOpen Radio Access Network（O-RAN）アーキテクチャを展開し、9,000万人の加入者にサービスを提供している事例です。EKS AnywhereをContainer as a Serviceオプションとして使用するこのトポロジーは、約15,000の異なるセルサイトと35,000以上のベアメタルサーバーで構成されています。このアプローチにより、NTT DOCOMOは、リージョンから最終段階の地域まで、セルタワーやセルサイトを含めて、クラウドベースのパターンを展開することが可能になりました。
NTT DOCOMOは、現在の市場における他の通信事業者と同様に、AWSリージョン、リージョナルデータセンター、エッジサイト、セルサイトにまたがるトポロジーを持っています。ここでの特徴は、リージョンがクラウドベースモデルであり、リージョナルサイトはマルチノードクラスターをホストするのに十分な容量を持つ標準的なデータセンターであることです。エッジサイトはリソースに制約のある環境で、ハードウェアに関して多くの選択肢を持つことができず、セルサイトはセルトポロジーにおける最もエッジに位置するサイトで、特定のハードウェア制限によりシングルノードクラスターしかホストできません。
これらの特殊なトポロジーの接続は、AWS Direct ConnectアプローチによってNTT DOCOMOにとって容易になりました。リージョンからセルサイトまでを直接接続で結ぶことができ、アプリケーションとインフラストラクチャの両方において、一貫性があり、信頼性が高く、安全な接続を提供します。この接続バックボーンは、インフラストラクチャとアプリケーションの両方に使用することができます。
EKS Anywhereクラスターのセルラー管理により、NTT DOCOMOはリージョナルサイトに配置された管理クラスターで複数のワークロードクラスターを作成・管理することができます。リージョナルサイトはマルチノードクラスターをホストするのに十分な容量があるため、異なるトポロジーを使用しています。リージョナルサイトではワークロードクラスターを使用して複数のワークロードクラスターを作成・運用し、リージョナルデータセンターには管理クラスターがホストされ、エッジサイトで複数のワークロードクラスターを運用・デプロイすることができます。このような拡張されたトポロジーとセルラークラスター管理により、DOCOMOはリージョンからエッジサイトまで、フル機能を備えたContainer as a Serviceプラットフォームを展開することができました。リージョンではEKSサービスが常時利用可能で、NTT DOCOMOは、コアとRANプロバイダーと協力して、リージョンでGraviton上のワークロードを認証した最初の顧客の一つとなり、5GコアとRANをホストしています。RANは、リージョナルサイトからエッジサイトにまたがるEKS Anywhere環境上で、DU（Distributed Unit）とCU（Centralized Unit）で構成されています。
このアプローチにより、NTT DOCOMOはクラウドからリージョンにかけて、異なるアプリケーションセットをデプロイすることが可能になりました。各サイトには分散ユニットと集中ユニットが配置され、RAN Intelligent Controllerはリージョナルサイトにデプロイされ、主要な5Gコアコンポーネントはリージョンにデプロイされています。
EKS Anywhereのトピックを、デプロイメントのベストプラクティスで締めくくらせていただきます。まず一つ目は、GitOpsベースのクラスター管理アプローチです。これにより、クラスター全体の設定をコードとしてGitHubリポジトリに保存し、クラスターの管理と作成を同期することができます。二つ目は、AWSが提供するキュレーテッドパッケージを使用して、EKS Anywhereクラスターにデプロイされるすべてのアドオンを管理できるという点です。EKS Anywhereでのクラスターアップグレードについては、様々なアップグレードパターンをサポートしています。ハードウェア上で動作するOSバージョンをアップグレードできるローリングアップグレードやインプレースアップグレード、さらにはハードウェア上で動作するOSにもパッチを適用する本格的なローリングアップグレードなどが可能です。
既存のメカニズムを使用して、クラスターのアップグレード、LDAPやOIDCによるセキュリティベースの認証を行うことができます。データセンター環境内の既存のLDAPインフラストラクチャとEKS Anywhereを統合することが可能です。EKS AnywhereではCNIパッケージとしてCiliumが利用可能であり、Kubernetesが提供するネットワークポリシーによるeBPFセキュリティを使用して、クラスター内の東西トラフィックを保護できます。これにより、PodとPod間、またはServiceとPod間の通信といったワークロード間の通信を保護するために、Kubernetesが提供する本格的な機能を活用することができます。
Amazon EKS Hybrid Nodesの仕組みと実装のベストプラクティス
EKS on OutpostsとEKS Anywhereの運用経験、そしてお客様からの学びを通じて、お客様が管理するハードウェア上で実行されるクラスターのKubernetesコントロールプレーンを管理することが、オンプレミスでのKubernetes運用における差別化されない重労働を軽減する重要なステップになるという確信を得ました。EKS Hybrid Nodesを使用すると、オンプレミスやエッジのインフラストラクチャをクラウドで実行されているEKSコントロールプレーンに接続できるため、ワークロードをオンプレミスに保持しながら、コントロールプレーンの管理責任をAmazonに委ねることができます。
EKSコントロールプレーンは、クラウドでEKSを実行する際と同じAPI、ツール、機能を備えたまま、AWSリージョンで継続して実行されます。オンプレミスのワーカーノードは、このBring-Your-Own-Infrastructureアプローチで管理する物理マシンまたは仮想マシンです。EKSはインフラストラクチャプロバイダーのAPIを呼び出してノードキャパシティをプロビジョニングするのではなく、Hybrid Nodesでは、オンプレミスで確立したツールやシステムを再利用してキャパシティをプロビジョニングします。
オンプレミスやエッジデバイスをクラウド上のEKSコントロールプレーンに接続できるようにするため、私たちはEKS最適化されたAmazon Linux AMIの初期化に使用していたツールを応用しました。 その結果として生まれたのが、ハイブリッドノードCLIユーティリティの「nodeadm」です。これは、kubelet、containerd、AWS IAM authenticatorなど、オンプレミスホストをKubernetesノードとして実行し、EKSコントロールプレーンに対して認証を行うために必要なコンポーネントをインストールします。nodeadm initコマンドを実行すると、インストールされたアーティファクトを設定してクラウド上のEKSコントロールプレーンにノードを参加させることができます。
ここで少し寄り道して、nodeadmの機能についてもう少し詳しく見ていきましょう。 オンプレミスの各ホストでnodeadmを実行することで、ハイブリッドノードのインストール、設定、登録、アップグレード、アンインストールが簡単に行えます。私たちは、さまざまなインフラストラクチャや特定のオペレーティングシステムで動作するようnodeadmを強化し、AWS Systems ManagerやAWS IAM Roles Anywhereと統合することで、オンプレミスノードのKubernetesクラスターへの認証プロセスを効率化し、クラウド上で実行されているEKSコントロールプレーンへのハイブリッドノードの初期化を自動化しました。ISOやOVAなどのイメージフォーマットでは、ホスト起動時に実行されるように設定された、ゴールデンOSイメージにnodeadmを含めることをお勧めします。
概要に戻りましょう。 クラスターに参加するために、EKSハイブリッドノードはAWSアカウントで作成するEKSハイブリッドノードIAMロールを引き受けます。これは、現在使用しているEKSノードIAMロールと同様です。EKSハイブリッドノードがこのロールを引き受けるために、AWS Systems ManagerハイブリッドアクティベーションまたはAWS IAM Roles Anywhereを使用して一時的な認証情報を取得します。Systems Managerはよりシンプルなソリューションであり、オンプレミスに独自の認証局と証明書を使用したPublic Key Infrastructureがすでに確立されている場合を除き、一般的にハイブリッドノードの認証にはこちらをお勧めします。後者の場合は、IAM Roles Anywhereが適切な選択となります。
また、オンプレミスまたはエッジ環境からAWSリージョンへの安定したプライベート接続も必要です。お客様が最も一般的に使用する技術として、AWS Direct Connect、AWS Site-to-Site VPN、または顧客管理のVPNソリューションを想定しています。Direct Connectは、一貫した高性能な低レイテンシーが必要な場合によく選ばれます。一方、AWS Site-to-Site VPNは物理的なネットワーク機器の設置が不要で、そこまでのネットワークの一貫性を必要としないデプロイメントでは、コスト効率の良い選択肢となります。
AWSとEKSハイブリッドノードのお客様との間で、責任はどのように共有されているのでしょうか？AWSは、EKSコントロールプレーン、アイデンティティおよび可観測性サービス、Amazon ECRコンテナレジストリを含む、リージョン内で実行されるAWSサービスの管理を継続して行います。kube-proxy、CoreDNS、ADOTやCloudWatchの可観測性エージェント、Pod Identityエージェント、CSIスナップショットコントローラーを含む、一部のEKSアドオンがAmazonによってサポートされ、ハイブリッドノードと互換性があります。お客様は、オンプレミスストレージソリューション、ネットワーキング、ハイブリッドノードを実行するオペレーティングシステムを含む、お客様の環境内で実行されるコンポーネントの管理に責任を持ちます。AWSは、ハイブリッドノードでのCiliumとCalico CNIドライバーの統合をサポートし、オーバーレイネットワーキング、IPアドレス管理、Border Gateway Protocol（BGP）を使用した動的なPod IPアドバタイジングなど、これらのドライバーの基本機能をサポートします。AWSは、ハイブリッドノードで特定のオペレーティングシステムをサポートし、それらのオペレーティングシステムの統合をサポートしますが、オペレーティングシステムの管理、パッチ適用、メンテナンスの責任はお客様にあります。EKSハイブリッドノードは、ベアメタルおよび仮想化環境向けのUbuntuとRHEL、そして仮想化環境のみを対象としたAmazon Linux 2023と互換性があります。
それでは、EKS Control PlaneとオンプレミスのNodeおよびPod間のトラフィックがどのようにルーティングされるのか、詳しく見ていきましょう。Hybrid Nodeの設定をしていないEKSクラスターでは、Control Planeはお客様の環境で実行されているNodeやPodのIPアドレスにアクセスする方法がわかりません。これに対応するため、Hybrid Node対応のEKSクラスターを作成する際には、Remote Node Network CIDRレンジとRemote Pod Network CIDRレンジを指定します。Remote Node Network CIDRは、kubectl execやlogsコマンド、Port Forwardingに使用され、Remote Pod Network CIDRは、Control PlaneがWebhookにアクセスする必要がある場合に使用されます。これらの新しいパラメータにより、EKS Control PlaneはこれらのIPアドレスにクラスターVPCを経由してアクセスできることを認識します。これらのCIDRレンジは互いに重複してはならず、クラスターVPCのレンジやEKSサービスとも重複してはいけません。現時点では、このリモートネットワーク設定を扱えるのは新規のEKSクラスターのみで、そのため新規クラスターのみがHybrid Nodeを実行できますが、将来的には既存のEKSクラスターでもHybrid Nodeを実行できるようにする予定です。
トラフィックは、Control PlaneからVPCへ、クラスター作成時にAmazon EKSがサブネット上に作成するElastic Network Interface（ENI）を経由して流れます。これは、現在のAmazon EKSがControl PlaneとクラウドNode間の通信に使用しているのと同じメカニズムです。VPC内のデータをデータセンターや環境に届けるためには、NodeとPod CIDRへのトラフィックが、作成して接続するゲートウェイを経由するように、VPCルーティングテーブルにルールを追加する必要があります。
このゲートウェイは通常、小規模から中規模の導入やシンプルなネットワークトポロジーに適したVirtual Private Gateway、あるいは大規模でより複雑なネットワークに推奨されるAWS Transit Gatewayのいずれかになります。その後、データはゲートウェイからAWS Direct ConnectまたはAWS Site-to-Site VPNを経由してプライベート接続で環境に流れます。データセンターやエッジロケーションを保護するファイアウォールルールでは、クラウド上で実行されているAmazon EKS Control Planeとオンプレミスで実行されているHybrid Node間の双方向通信を有効にする必要があります。
また、Hybrid NodeとPod CIDRに対して、オンプレミスのルーティングテーブルにも転送ルールを追加する必要があります。Podは一時的なものであり、そのIPアドレスは頻繁に変更されるため、Pod IPアドレスをオンプレミスルーターに動的にアドバタイズすることをお勧めします。CiliumとCalicoの両方でサポートされているBGPを使用してPodをルーティング可能にする場合は、EKSクラスターのENIセキュリティグループで、Control PlaneとオンプレミスEnvironment間の双方向通信を許可する必要があります 。
私たちは、お客様がAmazon EKS Hybrid Nodesをどのように活用し、どこで最も価値を見出すのかを楽しみにしています。ベータ版のお客様の一つであるDarktraceは、このソリューションが提供する環境間の運用の一貫性を高く評価しています。DarktraceはAIベースのサイバーセキュリティプラットフォームを提供しており、各顧客固有のパターンを学習して、堅牢な脅威保護と対応を実現します。Darktraceは、オブザーバビリティ、アプリケーションのスケーリング、災害復旧のためのKubernetesツールを活用し、一貫した展開環境をチームに提供するため、オンプレミスでKubernetesを使用しています。クロスサイトクラスターを作成してControl Planeを自社で管理する代わりに、DarktraceはAmazon EKS Hybrid Nodesを使用してKubernetesの管理をAmazon EKSに統合し、スケーラビリティ、可用性、効率性を向上させることを選択しました。
それでは、Amazon EKS Hybrid Nodesのベストプラクティスについてお話ししましょう。 ノードのブートストラップを自動化するために、Golden OSイメージにnodeadmを組み込み、必要に応じてsystemdサービスとしてホスト起動時に実行するように設定します。Amazon EKSクラスターは、ハイブリッド環境、データセンター、またはエッジロケーションに最も近いリージョンに作成してください。最適なパフォーマンスを得るために、最低帯域幅100Mbps、最大ラウンドトリップレイテンシー200ミリ秒を推奨していますが、これらのパラメータはユースケースやHybrid Nodesの使用方法によって異なります。
イメージサイズやノード数などの要因がレイテンシーに影響を与えるため、独自のネットワークテストを実施することをお勧めします。その際は、ネットワークチームと緊密に連携してください。モニタリング、ロギング、アイデンティティ管理には、互換性のあるAmazon EKSアドオンを活用してAWSサービスを利用しましょう。nodeadmについて注目すべき点は、各Hybrid Nodeに「compute-type=hybrid」というラベルを作成することです。このラベルを使用することで、Hybrid Nodesとクラウドノードが混在する混合モードクラスターにおいて、ワークロードを特定のノードに向けたり、逆に避けたりすることができます。
Amazon EKSハイブリッドソリューションの選択ガイド
最後に、そして最も重要な点として、Hybrid Nodesの導入プロセス全体を通じて、ネットワークチームとセキュリティチームと緊密に連携することが不可欠です。これにより、オンプレミスやエッジロケーションからコントロールプレーンや他のAWSサービスへの双方向通信に必要なファイアウォールルールとセキュリティグループが適切に設定されることを確保できます。次に、 どのAmazon EKSハイブリッドソリューションがニーズに最も適しているかを判断するためのシンプルな決定木についてお話ししましょう。いくつかの質問に答える必要があります。まず、「すでにAWS Outpostsをオンプレミスで運用しているか、またはインフラの刷新を検討しているか」です。答えが「はい」の場合、AWS OutpostsでのAmazon EKSの実行が、クラウドでのAmazon EKSノードの実行と最も一貫性のある体験とAWSとの緊密な統合を提供します。答えが「いいえ」の場合、「エアギャップ環境が必要か」と自問してください。必要でない場合、Amazon EKS Hybrid Nodesが最も価値を提供します。既存のハードウェアを継続して使用しながら、コントロールプレーンの管理責任をAWSに委ねることができるためです。
エアギャップソリューションが必要な場合は、Amazon EKS Anywhereが最適な選択となります。
Amazon EKSの学習リソースと締めくくり
re:Inventの期間中およびその後もAmazon EKSについてさらに学ぶために、まずはKubernetesトラックの他の素晴らしいセッションにご参加ください。 KUB402では、Amazon ECRと自動化を使用してAmazon EKS上でワークロードを構築・デプロイするための様々なアーキテクチャについて学ぶことができます。KUB320では、組織がEKS上でペタバイト規模のデータ処理パイプラインを構築する方法に焦点を当てています。そしてKUB201では、AmazonのKubernetesプロダクトリーダーシップから、Kubernetesを使用してプラットフォームやアプリケーションをより迅速に構築するための最新のイノベーションと戦略について説明があります。また、HYB301などのハイブリッドおよびエッジトラックのセッションへの参加もお勧めします。直接参加できないセッションについては、特にブレイクアウトセッションの場合、そのセッションの開催から数日以内にYouTubeで動画が公開される予定です。
re:Inventの後も、Amazon EKS の学習の旅を続けていただけます。EKS Workshopに参加したり、EKS Best Practices Guideに取り組んだりすることができます。また、EKS Hybrid Nodesのドキュメントにもぜひ目を通してください。チームが多大な労力を費やして作成しており、とても価値のある内容が豊富に用意されています。このQRコードとURLで、AWS re:Inventセッションの資料もご覧いただけます。 また、このセッションのスライド資料は、このQRコードとGitHubのURLで入手できます。写真を撮りたい方のために、少しお時間を取らせていただきます。
本セッションにご参加いただき、誠にありがとうございました。オンプレミスインフラのモダナイゼーションを進めていく中で、皆様にとって学びの多いセッションとなっていれば幸いです。私やGokul Chandraへのご質問などございましたら、画面に表示されているメールアドレスまでお気軽にご連絡ください。また、モバイルアプリでのセッションアンケートへのご協力もお願いいたします。皆様からのフィードバックは、私たちの現状把握と今後のセッション改善に大変役立ちます。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion