サービスベースへと進化するネットワーク（後編）

ネットワーク アクセスの制御

これまで動的にサービスを検出し、IDとイベントに基づいてセキュリティポリシーを適用し、ネットワークソリューションに自動化を組み込む必要性について説明してきました。

あとは何が残るでしょうか。エンドユーザーやクライアントがネットワークやそこで実行されているサービスにアクセスできない場合、これまで話題にしていたことはまったく問題になりません。

アクセスがADCとファイアウォールで規制されていた時代を思い出してみてください。スケーリングやボトルネックの存在が課題でした。仮にネットワークポリシーをサービスベースのネットワークソリューションに移行できたとしても、従来のネットワークテクノロジーを維持したままでは、一貫性を実現する能力が妨げられる可能性があります。

理想としては東西のトラフィック（サービス間）と同様に、南北のトラフィック（ingress/egress）管理にサービスベースのトラフィック管理ソリューションを適用する必要があります。

Kubernetesになじみがあるなら、この課題への解決策が想像できるかもしれません。そう、イングレスコントローラーです。一般的には、特定のトラフィック管理機能とセキュリティプロトコルを適用する機能を備えたKubernetesクラスターへのアクセスを、イングレスコントローラーが許可することです。

これらのコントローラーはKubernetes環境の一部のように扱うため、クラスター内の他のサービスを認識できることがメリットとなります。ただし、これらのイングレスコントローラーはユーザーが望むほど常に動的であるとは限りません。多くの場合、特定のクラスター内のレプリカの数を増やすには、より長いロールアウトサイクルが必要になります。

こうしたダイナミズムの課題に対処するために、現在KubernetesコミュニティではGateway API仕様を導入し、イングレスソリューションでサポートされているものを強化しました。ゲートウェイAPI仕様により、ゲートウェイサービスやルートのより動的な管理が可能になり、サービスメッシュでより密接に連携します。

これにより、ユーザーはすべてのトラフィック管理とサービスメッシュへのアクセスに対して一貫したコントロールプレーンを作成できるようになります。

もしKubernetes Gateway API仕様に慣れていないなら、専用のゲートウェイポッドをクラスターにデプロイし、カスタムリソース定義を介してルートを動的に適用することができます。

このモデルを使用すると、Kubernetesユーザーは必要に応じて複数のバージョンのゲートウェイをクラスター内にデプロイし、特定のルーティングポリシーまたはリスナー プロトコルを各ゲートウェイインスタンスに適用できます。サービスメッシュと組み合わせればユーザーは単一のソリューションを使用して、すべてサービスID に基づいて、南北および東西トラフィックの両方のトラフィックポリシーを制御できるようになります。

もちろん、典型的なエンタープライズ環境はKubernetesだけではありません。Kubernetesを超え、これらと同じポリシーとプラクティスをすべての環境に適用する必要があります。コンテナが複数のオーケストレーターで実行できても、一部のアプリケーションは決してコンテナ化されません。

サービスIDに基づくネットワークへのアクセスを管理するために、中央で制御できるプレーンが必要になります。こうすればクラウド環境と非クラウド環境の両方にわたり、一貫性が生まれます。

サービスベースのネットワークの中核となる原則で構成を

これまで見てきたように、最新のネットワークの課題に対処するには、ユーザーはサービスの検出、ネットワークの保護、ネットワークタスクの自動化、およびアクセスの制御という4つの主要なワークフローの課題を解決する必要があります。これらはサービスベースのネットワークの中核となる原則で構成していきます。

ここ何年にもわたり、サービスベースのネットワークへのシフトが進化してきたことを認識しておくべきでしょう。今でもサービス ネットワーク ソリューションは新しい機能の実装を続けています。進化を続けているとはいえ、IPベースのネットワークからサービスベースのネットワークへの移行という主要な目標はぶれていません。

この変化を受け入れることで、組織のネットワークはネットワークの展開と管理の方法や、セキュリティポリシーの一貫性を損なうことなく、最新鋭のアプリケーションデリバリープラクティスに追随できるのです。