re:Invent 2024: AWSが解説するKubernetesのネットワーキング戦略
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Networking strategies for Kubernetes (KUB406)
この動画では、KubernetesのネットワーキングについてContainer Specialistの2名が解説しています。Amazon EKSのAuto modeによるクラスター運用の簡素化、AWS Load Balancer Controllerを使用したアプリケーションの外部公開、Istio Ambient MeshによるmTLSの実装とChaos Engineeringの実践など、具体的な実装方法をデモを交えながら説明しています。特に注目すべきは、従来のIngressに代わるKubernetes Gateway APIの活用と、Amazon VPC Latticeとの統合による新しいネットワーキングアプローチです。また、EKS Workshopを通じて、これらの技術を実践的に学べる方法も紹介されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Kubernetesネットワーキング戦略セッションの導入
みなさん、こんにちは。本日のセッションへようこそ。私はFederica Ciuffoと申します。イタリア出身ですが、現在はスペインのマドリッドに住んでいます。本日は皆様とご一緒できることを大変嬉しく思います。そして本日は、Sai Vennamも一緒です。みなさん、こんにちは。私はAWSのContainer Specialistで、テキサス州オースティンを拠点としていますが、出身はインドです。今日は、Kubernetesのネットワーキング戦略についてお話しできることを楽しみにしています。これは400レベルのトークですが、最初は基本的なところから始めて、セッションの終わりに向かって徐々に複雑な内容に進んでいきたいと思います。
それでは、始めましょう。私たちはどちらもContainer Specialistとして、2024年中に顧客との間で行った対話をもとにアジェンダを組み立てました。Kubernetesのネットワーキングに関する会話を数多く重ねてきましたので、この1年で最も興味深かった顧客とのやり取りや、最も多く寄せられた質問を取り上げたいと思います。このセッションをより双方向的なものにするため、それらの顧客からの質問やトピックをアプリケーションの要件として置き換えてみました。 これはレンタルアプリケーションで、今日は少しロールプレイをしてみたいと思います。
私はクラウドアーキテクトとして、クラウドの設計とこのアプリケーションを実行するクラスターの構築を担当します。私はCluster Operatorを担当します。今日のセッションで話をした方々の多くは、おそらく皆さんの会社のプラットフォームチームでKubernetesクラスターを運用されている方々だと思います。今日はその役割を演じてみたいと思います。Federicaは私に要件を提示します。彼女は経験豊富なCloud Architectとしての立場から、プラットフォームチームである私が満たすべき要求を出してくれます。
アプリケーション要件とAmazon EKSの活用
それでは、アプリケーションの様々な要件について見ていきましょう。まず最初に行いたいのは、クラスター運用を簡素化して皆さんの作業を楽にすることです。私たちのアプリケーションは外部向けアプリケーションなので、お客様は外部からアクセスできるようになります。また、全般的な、特にネットワークの回復性を向上させる必要があります。私たちの調査によると、多くのマイクロサービスを扱う中で、明確な観察方法がないまま多くの時間を費やしているアプリケーションチームの負担にならないような方法で、このアーキテクチャとアプリケーションを観察できるようにしたいと考えています。
また、セキュリティチームからの要件も満たす必要があります。クラスター内での新しいアップデートを行う際の中断に対して、異なるアプローチを取れるようにしたいと考えています。例えば、3ヶ月ごとのクラスターアップデートなどです。現在、これらの中断を伴う操作はIn-placeアップグレードで行っていますが、Blue-Greenデプロイメントのような、より中断の少ない方法についても深く検討したいと考えています。
アプリケーションのデプロイ方法について振り返ってみましょう。私たちの組織には異なるビジネスユニットがあり、各ビジネスユニットには専用のアカウントがあります。 また、考慮に入れる必要のあるオンプレミスのデータセンターもいくつかあります。そしてこれらはすべて
Transit Gatewayで接続されています。アプリケーションの準備はできていますね。はい、できています。タイミングばっちりですね。
少し大きく表示してみましょう。先ほど話していたように、 アプリケーションのローカルバージョンが稼働しています。Federicaのチームは基本的に自分たちのローカルマシンでコンテナをビルドし、そのために、クラウド上ではなくローカルで動作するこのリテールストアのサンプルアプリケーションのバージョンを作成しました。ここで簡単なコマンドを実行して、そのアプリケーションがどのようなものか見てみましょう。MySQLのパスワードを「pass」に設定して、docker compose upを実行します。
これは、ローカルでコンテナを扱うのに素晴らしい方法だと思います。何が行われたのかご覧いただけますね。コンテナイメージがダウンロードされ、 今、ローカルでアプリケーションが起動しています。数秒後には完全に起動するはずです。では、アプリケーションにアクセスするために、ローカルホストに移動してみましょう。 はい、できました。これが私たちの素晴らしいリテールストアのサンプルアプリケーションで、ローカルで動作しています。これは開発には最適で、 ローカルマシン上でコンテナを使った反復開発を非常に素早く行うことができます。しかし、これをクラウドで実行する方法が必要です。それが次のステップとなります。
実際に必要なのは、 リテールアカウント専用の各VPCにこのアプリケーションのレプリカを配置することです。私が先ほど お見せしたアプリケーションは、異なる分離されたコンポーネントで構成されており、MySQLなどのインフラストラクチャの依存関係もあります。では、 早速取り掛かりましょう。最初にやりたいのは、皆さんの作業を簡単にすることです。
Kubernetesクラスターの運用簡素化とAWS Load Balancer Controller
Kubernetesのアーキテクチャについて考えると、設定や考慮が必要なネットワークコンポーネントが数多くあります。Control Planeとそのコンポーネントがどのように通信するかだけでなく、Control PlaneとData Planeをどのように連携させるかも重要です。Data Plane内にも、考慮すべき重要なネットワークコンポーネントがあります。例えば、Kube-proxy、CoreDNS、CNIなどがあり、クラスターでこれらを使用するには適切な設定が必要です。このような複雑さを簡素化するのが、まさにEKSの役割なのです。
Amazon EKSについて少しお話ししましょう。このネットワーキングに関する講演で、なぜEKSの話をするのかと思われるかもしれません。でも、これから関連性が分かってきますよ。Amazon EKSは単なるマネージドKubernetesです。私たちの特別なバージョンのKubernetesではなく、オープンソースの上流に準拠したKubernetesを私たちがお客様のために管理しているのです。約6年前にAmazon EKSを最初にローンチした時、焦点はControl Planeの管理をお客様のためにサポートすることでした。先ほどの分かりやすいアニメーションでご覧いただいたように、Control Planeの機能を私たちが管理しています。
しかし、私たちはさらに一歩進んでいます。今週初めに発表したことについて、皆さんもご存知だと思います。現在、Amazon EKSはData Planeの一部の管理もお客様をサポートしています。Auto Modeにより、お客様はすぐに本番環境で使用できるEKSクラスターを手に入れることができます。プラットフォームチームとして、また私自身もプラットフォーム運用者として以前は自分で管理しなければならなかったこれらのコンポーネントが、今では全て管理されています。Auto Modeの範囲と対象は継続的に拡大しており、その多くはGitHub上で公開されているロードマップで確認できます。
特に重要なのは、Auto Modeによって主要なネットワークコンポーネントが管理されるということです。これらについて簡単に見ていきましょう。まず、VPC CNIが管理されるようになりました。これはすべてのEKSクラスターでデフォルトで設定されるものですが、もはやData Planeで自分で管理する必要はなく、私たちが代わりに管理します。つまり、Control Planeをアップグレードする際、これらのアドオンも自動的にアップグレードされます。Data Planeの異なるコンポーネントを管理する認知的負荷が軽減されるということです。さらに、CoreDNSやKube-proxyもすべて最初から管理されます。
実は、もう1つ管理されるものがあります。すべてのAmazon EKS Auto Modeクラスターに最初から組み込まれているApplication Load Balancer Controllerです。Amazon EKSは、Control PlaneとData Planeでより多くの機能を管理します。
Service Meshの導入とIstio Ambient Meshの活用
Federica、Container Network Interfaces (CNIs)について調査されたとのことですが、要件と、なぜ他のCNIではなくこのCNIを選択したのか説明していただけますか？はい、その通りです。私たちはAmazon VPC CNIを採用することにしました。これはAWS内での作業を簡素化してくれるからです。Amazon VPC CNIは、Amazon VPCという基盤となるネットワークと深く統合されており、Amazon VPCからPodにIPアドレスを割り当てます。これは私たちにとって素晴らしい利点です。なぜなら、VPC Flow Logsによるセキュリティと可観測性など、Amazon VPCのすべての利点を活用できるからです。また、このCNIは高度にカスタマイズ可能で、私たちのニーズに合わせてCNIの仕様を細かく調整できます。
Amazon EKSと互換性のある他の代替CNIもありますが、サポート対象外です。これは、選択したCNIのベンダーからのサポートを受けることが推奨されるということです。しかし、私たちはAmazon VPC CNIを使用し続けることにします。Amazon EKSのAutoモードが、チームの作業を効率化し、面倒な作業をAWSに任せられる点が気に入っています。VPC CNIの使用を承認していただき嬉しく思います。プラットフォームチームとして、AWS エコシステムと統合されているため、管理の心配が少なくて済むからです。
Load Balancer Controllerについて言及されましたが、これは実は次の要件に関連しています。私は今、顧客に私のアプリケーションにアクセスしてもらいたいと考えています。先ほどお見せしたのはローカルで実行していましたが、これは私たちが必要としているものではありません。クラスター外部から私たちのバックエンドPodにアクセスする方法を考える際、常にKubernetesオブジェクト、つまりIngressリソースとServiceリソースが必要になります。Ingressリソースはレイヤー7（アプリケーション層）で動作し、Serviceリソースはネットワークトランスポート層で動作します。
さらに必要なのは、クラスター外部からクラスター内部へのトラフィックを可能にするインフラストラクチャーの要素です。この要素は通常、プロキシまたはロードバランサーです。AWSでは、AWS Load Balancer Controllerを使用することで、これをネイティブに実現できます。AWS Load Balancer Controllerの機能に私はとても期待しています。なぜなら、AWS上のKubernetesでの作業をチームにとってより簡単にしたいからです。AWS Load Balancer Controllerは、Ingressリソースに対してApplication Load Balancerを、Serviceリソースに対してNetwork Load Balancerを自動的にデプロイします。
私たちは実際にApplication Load Balancerを使用しているので、レイヤー7でできることについてより深く掘り下げたいと思います。Application Load Balancer自体がレイヤー7のロードバランサーであり、これはすべての機能とレイヤー7の処理がロードバランサー層で行われることを意味します。これにより、アプリケーションチームが行う必要のある設定作業をロードバランサーに任せることができます。例えば、証明書の処理をロードバランサーに任せ、AWS Certificate Managerで管理することができます。これはAWS Load Balancer Controller自体と深く統合されています。また、AWSロードバランサーとAWSのセキュリティおよびネットワークスイート間のすべての統合を活用できるため、運用が簡素化されます。
また、サードパーティのIngress Controllerを使用してトラフィックを処理する方法もあります。この場合、処理レイヤーと機能の責任が、Load BalancerからController自体に移行することがわかります。これは重要なポイントです。例えば、以前はSSL証明書の管理をLoad Balancerに任せることができましたが、今度はそれをIngress Controllerに提供する必要があります。
もう一つの違いとして、管理の複雑さが増す点があります。Ingressリソースのみを扱うことになるため、Serviceリソースを扱う必要がある場合は、EKSで追加のService Controllerが必要になります。これまではAWS Load Balancer ControllerまたはService Controllerで透過的に処理されていましたが、その機能がなくなったわけではありません。まだ存在していますが、重要なセキュリティアップデートのみを提供している状態です。Load Balancerのサービスデプロイメントには、現在もAWS Load Balancer Controllerの使用が推奨されています。 興味深いことに、Ingress Controllerを使用する場合でも、選択したIngress Controllerの前段に配置するLoad BalancerをデプロイするためにAWS Load Balancer Controllerが必要になります。
ControllerとサードパーティControllerでできることの違いについて説明してきましたが、実際のアプリケーションで動作を確認してみましょう。最初の実践デモに入ります。ここでは、レイヤー7ベースのロードバランシングのためにApplication Load Balancerを使用してアプリケーションを公開します。このダイアグラムが気に入っているのは、Ingressリソースを作成すると、レイヤー7レベルで動作する高度なパスベースのルーティングが提供されることがよくわかるからです。これらはカスタムIngress ControllerやAWS Load Balancer Controllerで作成でき、レイヤー4レベルでは、個々のサービスごとにLoad Balancerが必要な場合、AWS Load Balancer Controllerで作成できるNetwork Load Balancerを使用できます。
それでは、実際に見ていきましょう。このEKSクラスターでは、 今日使用するリテールサンプルアプリケーション用のコンテナがすでにデプロイされています。重要なポイントとして、AWS Load Balancer Controllerもデプロイされていることがわかります。Auto Modeクラスターでこのコマンドを実行した場合、Load Balancer Controllerは管理されているため、これらのPodは表示されません。しかし、私は標準的なクラスターを使用しているため、Auto Modeではなく、自分でインストールする必要がありました。クラスターをアップグレードする際には、Load Balancer Controller自体のアップグレードも対応する必要があります。
このControllerがインストールされると、KubernetesはIngressリソースが作成されるか、タイプがLoad BalancerのServiceが作成されるたびに、Controllerが適切な処理を行うことができます。バックエンドでは、AWSでリソースの作成が開始され、深く統合されています。特にカスタムドメインを使用し、証明書がある場合、Route 53やACM証明書機関との連携など、バックエンドでは多くの処理がLoad Balancer Controllerによって自動的に行われます。
私はIngressリソースを作成しましたので、全ネームスペースでget ingressを実行してみましょう。ここで見ていただけるように、アクセス可能なアドレスを持つIngressがあることがわかります。ただし、そのアドレスをコピーして使用する前に、 Ingress YAMLの中身を簡単に見てみましょう。Ingressの指定方法を理解する上で、これは非常に重要なポイントです。いくつかの注目すべき点があります。特に、アノテーションがあり、これによってApplication Load Balancer controllerに対して、このIngressがinternal onlyではなくinternet-facingであることを指定しています。つまり、パブリックインターネットからのアクセスを許可したいということです。
target typeはIPモードに設定されています。もう一つのオプションはインスタンスモードです。この詳細については今は深く触れませんが、なぜ両方のオプションを提供しているのか、そしてTarget Groupが正常性を判断するためのヘルスチェックパスについて、より詳しく学べるリソースを後ほど共有させていただきます。もう一つの重要な点は、実際にルーティングしているServiceです。UIネームスペースでget serviceを実行すると、ポート80のUI Serviceが表示されます。これが、このIngressでルーティングしている対象です。
最後に強調しておきたいのは、この週によく質問を受けた点なのですが、Auto modeについてです。AWS Load Balancer ControllerのAWSマネージドバージョンを使用する場合と、non-auto modeクラスターで単にコントローラーを実行する場合で、特別な設定が必要かどうかという点です。既存のクラスターにAuto modeを追加できるため、これはマネージドバージョンのコントローラーに移行する方法として重要です。ここでIngress Class Nameが指定されていることにお気づきでしょう。Auto modeのマネージドバージョンのコントローラーを使用する場合、新しいIngress Classが作成され、Ingressリソースがそのコントローラーによって処理されることを指定します。これにより、クラスターをAuto modeに移行するのがとてもスムーズになります。新しいIngress Classをインストールし、既存のIngressを新しいIngress Classに切り替えるだけでよいのです。その後、もう必要なくなったLoad Balancer Controllerをクラスターから削除できます。
これらを確認したところで、デモの神様にお祈りしてみましょう。あ、完璧なスピードで読み込めましたね。ありがとうございます。 ご覧の通り、Kubernetesのクラウド上で実行されているアプリケーションは、Application Load Balancingを使用したIngressリソースでフロントエンドが構成されています。約束通り、シンプルな構成から始めて、プレゼンテーションを進めながら徐々に複雑さを上げていきます。ここでFedericaに戻して、もっと面白い内容に進めていきましょう。
Ambient MeshによるmTLSの実装と可観測性の向上
ありがとうございます。これが私たちの最初の要件でした。Amazon EKSでクラスターを採用しているチームのために、シンプルに始めたいと考えていました。このドメインに証明書を追加するなど、他にもできることがたくさんあります。これらの方法を示していただき、ありがとうございます。ただし、他の要件もあります。 私のチームでは、すでにベストプラクティスに従い、Topology Spread Constraintsを使用してPodをAvailability Zone全体に分散させ、アプリケーション内に多くの信頼性メカニズムを組み込んでいるにもかかわらず、ネットワークの回復性に関して多くの課題を抱えています。
しかし、私たちにとって災害復旧シナリオのテストは本当に難しい課題です。 そこで役立つのが、Amazon EKSとARC（Amazon Recovery Controller）の新しい統合機能です。これにより、サービスのヘルスチェックが失敗するのを待つ必要がなくなるため、災害復旧シナリオのテストと復旧が容易になります。代わりに、ARCがAZのダウンを通知し、影響を受けるゾーンにあるターゲットやエンドポイントが自動的にサービスから登録解除されます。これは私たちにとって素晴らしい機能です。
ARCについてまだよく分からないので、Kubernetesを使用している理由そのものが、Podが不健全な場合に自動的にトラフィックのルーティングが停止されることなのに、なぜARCが必要なのか説明していただく必要があります。問題は、そこに遅延が発生することです。ヘルスチェックが失敗するのを待つ必要があり、その後ターゲットが登録解除されるまでの間に多くの問題が発生する可能性があります。ARCはAZの障害が発生した瞬間に自動的に信号を送信するため、この時間を短縮できます。確かに、アプリケーションの回復力を確保するのも私のチームの責任です。基本的に、Kubernetesはポッドの不健全性を検出してトラフィックのルーティングを停止できますが、Readinessプローブやヘルスプローブが失敗するまでに時間がかかり、その間顧客に影響を与える可能性があります。しかし、この機能では、AZに問題が発生した瞬間にトラフィックをゾーンシフトすることで可用性を向上させています。その通りですし、とても興味深い点です。
このゾーンシフトは適切にトラフィックを制御し、実際の障害がなくてもそのようなシナリオをテストすることができます。テストシナリオに関して、私のチームは信頼性を確保するためにアプリケーションを広範に構築してきました。これは長いプロセスでした。まずボトルネックや潜在的な障害がどこにあるかを観察し、その後アプリケーション内でソリューションを実装する必要があったからです。異なるプログラミング言語を使用するアプリケーションがあるため複雑性が増し、私はアーキテクチャの観点から、これらの運用を統一し、アプリケーションチームの負担を軽減する方法を探していました。
エコシステムにおいて、最も一般的なアプローチはService Meshの採用です。Service Meshの最も一般的なアーキテクチャでは、プロキシをアプリケーションコンテナの隣に配置し、クラスター内の各アプリケーションコンテナに対してこれを行います。これにより、すべてのプロキシで構成される新しいレイヤーが作成されます。そして、高度なネットワーキング、ネットワークセキュリティ、ネットワーク運用の責任をそのレイヤーに委譲します。これにより、開発者が引き続き担当するアプリケーションのビジネスロジックからこれらの機能を切り離すことができます。各アプリケーションで同じプロキシを使用するため、これらの機能は1つのプログラミング言語で統一されます。
これにより私の仕事が楽になり、アプリケーションチームの仕事も楽になります。そして、Service Meshがもたらす機能を見ると、非常に強力です。実装したい機能がすべて揃っています。例えば、リクエストのトレーシングやボトルネックの理解など、観察能力が欲しいと考えています。信頼性の機能をアプリケーション内ではなくService Mesh内に実装したいと考えています。また、セキュリティ機能も同様です。セキュリティチームから相互TLSやワークロードのセキュリティ確保について多くの要請を受けています。
それは重要なリクエストですが、Service Meshには課題もあります。Federicaさん、利点については全て説明してくれましたが、私がOperatorとしてService Meshを運用する際の課題について触れていない部分があります。ここで話題にしているIstioのような従来のService Meshは、Sidecarモデルで動作します。課題には、Sidecarが最大効率で利用されていない場合や、各Podとともにスケールアップする必要があるなどのリソース効率の問題があります。クラスターにSidecarをインストールするにはPodの再起動が必要で、これは理想的ではありません。また、障害ポイントの増加やセキュリティ境界など、Platform Teamとして、相互TLSによるサービス間の暗号化通信といった組織のベストプラクティスを実装する際に考慮すべき点が多くあります。
Service Meshの利用は良いアイデアだと考えています。なぜなら、Federicaのチームが各アプリケーションに可観測性とセキュリティの要件を全て実装する必要がないからです。私たちのチームに複雑さが増す代わりに、彼女のチームから複雑さを取り除くことができます。この課題に対する私たちのアプローチがAmbient Meshです。基本的に、Istio Ambient Meshを使用することで、従来のSidecarモデルのIstioと同じメリットを、Sidecarなしで得ることができます。これは、サービス間のトラフィックをZTUNNEL Proxyで暗号化することで実現しています。使用されているプロトコルは、IstioのHBONE（HTTP-based Overlay Network Environment）と呼ばれるものです。これを分解して考えると、そこまで複雑ではありません - HTTPベースのネットワーク上に構築されたオーバーレイ環境です。
興味深い点は、サービス間のすべてのトラフィックがこのZTUNNELを通過するようになり、Podを再起動することなく、すぐにmTLSを利用できることです。
トラフィックはネットワークレイヤーでの動作からZTunnelを経由する形に移行します。これを示すために、デモに移りたいと思います。Waypoint Proxyについても情報を見ていただいたと思いますが、これについては後ほど説明します。これはレイヤー7の機能のためのものですが、今回はレイヤー4に焦点を当てます。レイヤー4は、完全修飾ドメイン名やパス、ドメインではなく、IPアドレスとポートといった認証に関わる部分を扱います。
クラスター環境を見てみましょう。K9sを使用しますが、もしまだ使用していない方がいれば、強くお勧めします。クラスターの状態を確認する優れたツールです。このクラスターでは、すでにIstioをインストールしていることが分かります。これは、Helm Chartのようにクラスターにインストールするだけの非破壊的な作業です。これらのPodが起動し、GrafanaやPrometheus、Kialiといった可観測性ツール、Istioのコントロールプレーン、そしてIstioを通じてトラフィックをルーティングするためのIngress Gatewayが含まれていることが確認できます。
これらのPodは過去26日間再起動されていません。便利なコマンド「ztunnel config workloads」を見てみましょう。 これでクラスター内のすべてのワークロードが表示され、現在プロトコルがTCPであることがわかります。これは基本的に、HBONEプロトコルを使用しておらず、まだmTLSが有効になっていないことを示しています。これを有効にするには、defaultネームスペースにdata plane modeをambientに設定するラベルを付けるだけです。 このコマンドを再度実行すると、以前TCPだったすべてのワークロードが、今度はHBONEプロトコルを使用するようになります。adminコントロールプレーン型のサービスは変更の必要がないので無視して構いません。
サービスにアクセスするために、すぐにサービス情報を取得してみましょう。Istio Ingress Gatewayのものを取得します。 アプリケーションは再起動していないことを覚えておいてください。アプリケーションにアクセスするために、キャッシュを数回リロードする必要があります。 はい、アプリケーションにアクセスできました。Pod間の通信はmTLSで行われており、ダウンタイムもPodの再起動も必要ありません。これでクラスターでAmbient Meshが有効になりました。
Istioについて考えるとき、単にmTLSのためだけに使用するのはオーバーキルに思えます。Istioには、特に重要な機能の1つである可観測性など、他にも多くの利点があります。 ZTUNNELでは、すぐに使えるmTLSとレイヤー4の認可ポリシーを実装できます。Istioは高度なトラフィックルーティングなど、レイヤー7の機能に優れています。Waypointを使用すると、 トラフィックはクラスター上で実行される別のWaypointを経由するようになり、Istioがレイヤー7の機能と豊富な可観測性を提供できるようになります。
Waypointのレイヤー7機能の人気のある使用例として、Canaryデプロイメントがあります。新機能を一部のユーザー、例えばFirefoxユーザーやモバイルユーザーにのみロールアウトしたい場合を考えてみましょう。これらはすべてネットワークレイヤーで切り替えられるスイッチとなります。アプリケーションチームはコードを変更する必要はなく、ネットワークレイヤー、つまりオーバーレイレイヤーで設定できます。Waypointを有効にするには、defaultネームスペースにWaypointを適用するヘルパーコマンドを実行します。 これだけです。新しいPodを起動するだけなので、既存のPodは再起動されません。 7秒前に新しいWaypointが起動したことが確認できます。
これでアプリケーションの可観測性が確保されるはずです。ログとメトリクスがアプリケーションを通して流れていることを確認するために、数回リフレッシュしてみましょう。 ポケットウォッチをカートに追加して、チェックアウトボタンを押してみましょう。次に、コマンドラインに戻って「istio kubectl dashboard Kiali」を実行します。
オープンソースの可観測性ツールであるKialiは、アプリケーションの状態を正確に把握するのに役立ちます。まずは直近3時間分のデータを確認してみましょう。これは読みづらくあまり面白くないので、少し整理していきましょう。まず不明なノードを非表示にして、Appグラフを表示します。ここでいくつかの設定を有効にしていきます。Serviceノードを非表示にして、トラフィックのアニメーションとWaypoint Proxyを追加します。はい、このようになりました。すでにより多くの情報が見えるようになりましたね。Prometheusの情報は見たくないので、TCPトラフィックを無効にしましょう。これでよし。
Kubernetes Gateway APIとAmazon VPC Latticeの統合
これで、アプリケーションのアーキテクチャを視覚的に確認できるようになりました。私はチェックアウトを完了していないので、この線が黒くなっています。チェックアウトプロセスを実行していないため、このPodではmutual TLSが確立されていないためです。しかし、サンプルアプリケーションでクリックして回った際に有効化された他のPodへのトラフィックがここに表示されているのが分かります。これらのいずれかをクリックすると、UIからCartsへのトラフィックにmutual TLSが有効になっているのが確認できます。私の意見では、これはとてもクールな機能です。実際、Cartsなどの詳細を確認して、どのアプリケーションが何と通信しているのかを正確に把握することもできます。ここで、あるサービスが本来通信すべきでないサービスと通信していることに気付くかもしれません。これを利用して、Authorization PolicyやNetwork Policyを実装し、本来通信すべきでないサービス間のアクセスを防ぎ、影響範囲を制限してより良いセキュリティプラクティスを実装することができます。
では、ここで何が分かったでしょうか？Istio Ambient Meshを使用することで、Podやアプリケーションを再起動することなく、Layer 4の機能とmutual TLSを有効にし、さらに優れた可観測性も得られることが分かりました。Chaos Engineeringのデモをお見せしたいと言いましたね。それについて少しお話ししましょう。このクラスターにデプロイしたGatewayは非常にシンプルで、基本的に先ほどお見せしたIngress Resourceと同様のIstioの方法で実装しています。UIサービスを公開し、そのUIサービスにFaultを挿入します。75%の確率で失敗するように設定しますが、まだ適用はしていません。まずはアプリケーションに正常にアクセスできることを確認しましょう。はい、問題ありません。
では、この新しいGatewayを適用してみましょう。Virtual Serviceが設定されたはずです。はい、設定されました。これで75%の確率で失敗するはずです。はい、もうFaultが発生しました。これこそが本当のChaos Engineeringです - アプリケーションが障害にどう対応するかを確認できます。失敗時のRetry Policyを実装して、アプリケーションが正しく応答するかを確認することもできます。25%の確率で成功するはずなので、もう少し試してみましょう。これは驚きです - 6回も。今日はギャンブルに行くべきではありませんね。7回目でようやく成功しました。すでにキャッシュの無効化に問題があることが分かります。バグを発見したようですね。Faultが発生した際のキャッシュの扱いを改善して、ユーザーがこのようなページを見ることがないようにすべきでしょう - これは私のチームが検討すべき課題です。
どう思いますか、Federica？デモをありがとうございます。クラスター内でmutual TLSを簡単に実装できるのは素晴らしいですね。これはセキュリティチームからの重要な要求事項です。また、Ambient Meshを使用してサービス性を向上させ、アプリケーションの機能を強化できる点も気に入っています。ここで少し厳しい質問をさせていただきたいのですが、Istio Ambientについて、知っておくべき制限事項はありますか？はい、制限事項があります。このサンプルアプリケーションでAmbient Meshを最初に実装した際、あるサービスがAmbientモードとうまく連携しないことが分かりました。具体的には、あるPodがMySQLプロトコルを使用して永続層にアクセスしており、このプロトコルがZTUNNELとうまく動作しなかったのです。しかし、Ambient Meshの柔軟性を示す素晴らしい解決策があります。基本的に私たちが行ったのは - Kubernetesの画面をターミナルUIで開いてCatalogデプロイメントを確認してみましょう - ここで少しズルをしたのですが - このPodには2つのコンテナが実行されていることが分かります。2つ目のコンテナが何かというと、Envoy Proxyです。このCatalogサービスでは、デプロイメント設定で「sidecar.istio.io/inject: "true"」というラベルを追加することでSidecarを有効にしました。
先ほどZTUNNEL config workloadsコマンドを実行した際、すでにHBONEプロトコルを使用していたサービスが1つありました。これは実は、事前にSidecarを設定したPodを用意していた私の小細工だったのですが、これはAmbient Meshが特定のワークロードに対していかに柔軟に対応できるかを示す良い例となっています。
そのPodには、Sidecarが有効になっていました。これはKialiでも確認することができました。 では、これを元の状態に戻してみましょう。 Catalogを見てみると、あそこに小さなアイコンがあり、これがSidecarが含まれていることを示しています。 このように、ZTUNNEL Proxyとの相性が良くない特定のワークロードに対しては、単純にSidecarを実装して進めることができるんです。 特に価値があるのは、チームがサービスメッシュを全く使用していない状態から、セキュアなLayer 4のサービスメッシュ状態を経て、完全な実装へと進化できることです。その際、すぐにLayer 7の機能をすべて採用する必要がないという点です。
先ほど話題に上がったIngressについて戻りますが、Ingressは便利ではあるものの制限があります。Ingressで高度なネットワーク機能を実装するには、数多くのAnnotationやCustom Resource Definitionが必要になります。Kubernetesのエコシステムは、もはやIngressに新機能を追加していません。 代わりに、Kubernetes Gateway APIがそれらの機能をすべて備えており、新機能はすべてGateway APIに追加されています。Gateway APIは、Ingressで直面した課題に対処し、サービスメッシュから得られた教訓を取り入れています。興味深いことに、このGateway APIは、私たちがLayer 7の実装に使用しているものです。
エコシステムは急速にKubernetes Gateway APIを採用しており、誰もが使える統一されたAPIを提供しています。これにより、異なるサービスメッシュやIngress仕様間の移行が困難だった問題が解消されます。以前は、異なるIngress Controllerに対して異なるAnnotationが必要でした。 Gateway APIを使用すれば、IngressAPIでできることすべてに加えて、Gammaプロジェクトによるサービス間通信も処理できます。 最新のKubernetesリリースでは、Kubernetes Gateway APIのEgressトラフィックへの適用も確認されており、これは素晴らしいことです。なぜなら、これらのユースケースやシナリオすべてを処理できる1つのAPIを手に入れ、真のKubernetesネットワーキングの統合が実現したからです。
Kubernetes Gateway APIについて、さらに詳しく探求したい特定のトピックとして、クラスター間のBlue-Greenシナリオがあります。私のチームは、クラスターのアップグレードにかなりの時間を費やしています。現在はIn-placeアップグレードを行っていますが、Blue-Green Deploymentを検討したいと考えています。これにより、より高い信頼性が得られ、必要に応じてロールバック機能を利用でき、新バージョンへのCanary Deploymentも可能になります。エコシステムを見てみると、マルチクラスター機能が必要だと判断しましたが、どのようなオプションが利用可能なのでしょうか？
私たちはIstio Ambientを採用しましたが、Istio AmbientではまだMulti-clusterがサポートされていません。 Service Meshにおけるマルチクラスターへのアプローチを考える際、 アーキテクトとして検討すべき点が複数あります。例えば、Control Planeをどのように構築するかを考える必要があります。 クラスターを管理するためにControl Planeを外部化し、高可用性モードで設定するかどうかを決定する必要があります。その他にも、 クラスター間でのAPI権限の共有について考慮する必要があります。また、暗号化やテナンシーの境界についても対応が必要です。 さらに、Mesh間の信頼関係も確保しなければなりません。Service Meshの導入自体が課題となる中で、複数のクラスターをMeshに追加することは、さらなる複雑さを生み出すことになります。
先ほど触れましたが、これはKubernetes Gateway APIを使用して実現することもでき、これは異なるアプローチを提供します。Multi-cluster Services API、Service Import、Service Exportといった別のAPIセットと組み合わせることで、 必要なマルチクラスター機能をより簡単に、ネイティブな方法で実現できます。AWSでは、Gateway APIとMulti-cluster Services APIをAmazon VPC Latticeを使って インフラストラクチャとして実装しています。以前AWS Load Balancer Controllerがロードバランサーを実装していたのと同様に、Kubernetes Gateway APIコントローラーがAmazon VPC Latticeリソースを実装しているのです。
Amazon VPC Latticeについて説明させていただきます。Amazon VPC LatticeはTransit GatewayやVPC Peeringと同様のネットワークサービスですが、Transit GatewayやVPC Peeringとは異なり、OSIモデルのレイヤー7で動作します。これらのサービスを使用せずに、Amazon VPC Latticeを使用するだけで、VPCやアカウントを越えてアプリケーションを接続することができます。また、AWSネイティブなセキュリティアプローチも実装しています。 さらに便利な機能として、Amazon VPC Latticeを使用すると、単一のURLで一部のトラフィックをAmazon EC2内のサービスに、他のトラフィックをコンテナやAWS Lambda内のサービスに振り分けることができます。これは私たちにとって非常に魅力的です。なぜなら、EC2上で動作している従来型のワークロードがまだあり、それらをモダナイズしたいと考えているからです。多くの課題がある中で、ネットワーキングもその一つですが、このアプローチによってそのプロセスが大幅に簡素化されます。
セッションのまとめと学習リソースの紹介
Gateway APIについて私たちが特に期待しているのは、コミュニティ全体とプロバイダーの中心的な焦点となっていることです。Gateway APIはKubernetesのオープンソースのアップストリームコンポーネントで、本質的にIngressの進化版です。AWSのようなクラウドプロバイダーは、FedericaがさきほどカバーしたGateway APIコントローラーのようなコントローラーを作成して、これらのリソースをAWSやVPC Latticeに実装しています。IngressやIngress API、Serviceを作成する代わりに、GatewayとHTTP Routeを使用する新しいアプローチです。コミュニティやお客様がこの新しいアプローチに移行すると考えているのは、多くの利点があるからです。特に、他のクラスター、Lambda、ECS、その他のサービスなど、クラスター外のターゲットにルーティングできる機能が魅力的です。本日は、これまでの議論を簡単にまとめたいと思います。 クラスター運用の簡素化から始まり、コンテナベースのアプリケーションを実行するためのAmazon EKSの選択について話し、Pod間のネットワーキング統合にVPC CNIを使用する方法について説明しました。
Auto modeを使用すれば、本日デモで紹介した多くのコンポーネント（AWS Load Balancer Controller、VPC CNI、CoreDNSなど）が管理されるため、より効率的になっていたでしょう。クラスターをアップグレードする際、これらのコンポーネントも自動的にアップグレードされます。Auto modeでは、Carpenterのような他のコンポーネントも、ネットワーキングコンポーネント用の専用コンピューティングリソースや専用ノードを必要とせずに管理されます。
Load Balancer Controllerを使用してアプリケーションを外部に公開する方法について説明しました。 Load Balancer Controllerを使用してレイヤー7のApplication Load Balancerを作成する方法と、レイヤー4では、Load Balancerタイプのサービスを作成して個別のNetwork Load Balancerを作成する方法について説明しました。 また、ACM Ambient Meshについても説明しました。これは、レイヤー4とレイヤー7の認可ポリシー、レイヤー7の高度なルーティング、そして特定のワークロードに必要な場合にはSidecarとの相互運用性を維持しながら、アプリケーションを中断することなくmTLSをすぐに利用できるようにするものです。さらに、Amazon VPC Latticeと新しいKubernetes Gateway APIについても取り上げ、お客様がこの新しいネットワーキングバージョンへと進化できるようにする方法や、AmazonのVPC機能としてのVPC Latticeがそれをどのようにサポートするかについて説明しました。
これらの内容を自宅で学び続けるにはどうすればよいか、と考えている方も多いでしょう。最初にお見せしたIngressのデモは、実はAmazon EKS Workshopがベースになっています。 クラウド上のVS Codeで同じ環境を自分で構築することができます。EKS Workshopで自分のペースで学習することを強くお勧めします。 基礎セクションのアプリケーションの公開の部分では、環境をセットアップして、同じIngressのデモを自分で試すことができます。 複数のIngressパターンについても説明しており、複数のIngressリソースを作成しながら単一のALBで公開したい場合に何が起こるのかについても解説しています。 また、Load BalancerのIPモードとInstanceモードについても説明しています。
EKS Workshopは、Amazon EKSについてのすべてを自分のペースで学べる素晴らしい方法で、私たちは常にコンテンツを更新しています。自分のアカウントで環境を構築したくない場合は、AWSのアカウントマネージャーに連絡してEKS Workshopをリクエストすることもできます。このQRコードには、 フォームがあり、ご記入いただければセットアップのお手伝いをさせていただきます。AWS Docsに統合されたEKS Best Practices Guideは、ネットワーキングのベストプラクティスを学ぶのに最適な場所です。Federicaとそのチームによって、最新の最適化されたネットワーキングセットアップの推奨事項が含まれるよう、大幅な更新が行われています。また、コースを修了することでバッジを取得することもできます。セッションにご参加いただき、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion