[この投稿は、eBook「Managing Kubernetes Traffic with F5 NGINX: A Practical Guide」からの抜粋です。今すぐ無料でダウンロードしてください]
組織の規模が大きくなるにつれて、Kubernetesにおける開発および運用ワークフローはより複雑になっていきます。一般的に、各チームが独自のクラスタを用意するよりも、チームでKubernetesクラスタとリソースを共有する方がコスト効率が高く、より安全であると考えられます。しかし、チームでこれらのリソースを安全かつセキュアな方法で共有を行っておらず、ハッカーに設定を悪用されるなどした場合には、デプロイしたものに対し深刻なダメージを与える場合があります。
マルチテナントを実践すること、そしてネットワークやリソースレベルでのネームスペースの分離はチームがKubernetesリソースを安全に共有できるようになります。またテナント単位でアプリケーションを分離することは、攻撃による被害を大幅に抑えることができます。この方法では、特定のチームが管理するアプリケーションの部分のみが影響を受ける可能性があり、その他の機能を提供するシステムはまったくの無傷となるため、システムの復元力を高めることができます。
NGINX Ingress Controllerは複数のマルチテナントモデルをサポートしており、主に2つのパターンが見られます。インフラサービスプロバイダのパターンでは、物理的に分離された複数のNGINX Ingress Controllerのデプロイメントが一般的で、一方エンタープライズのパターンでは共有のNGINX Ingress Controllerでネームスペースを分けた実装が一般的です。この章では、エンタープライズパターンについて詳しく説明します。複数のNGINX Ingress Controllerを実行するための情報については、弊社ドキュメントを参照してください。
NGINX Ingress ControllerはKubernetes標準のIngress リソースとカスタムのNGINX Ingress リソースの両方をサポートしており、より高度なトラフィック管理と複数のチームでの適切な設定管理を可能にします。このカスタムリソースは、VirtualServer、 VirtualServerRoute、GlobalConfiguration、TransportServer、 および Policy です。
NGINX Ingress Controllerではクラスタ管理者がVirtualServerリソースを利用し、外部トラフィックを後段のアプリケーションに転送するIngressのドメイン(ホスト名)の設定を行うことができ、VirtualServerRouteリソースで特定URLの管理をアプリケーション管理者やDevOpsチームに委譲することができます。
Kubernetesクラスタでマルチテナントを実装する場合、「フルセルフサービス」と「制限付きセルフサービス」の2つのモデルを選択することが可能です。
フルセルフサービスモデルでは、管理者はNGINX Ingress Controllerの日々の設定変更に関与しません。管理者は、NGINX Ingress Controllerのデプロイと、そのデプロイを外部に公開するKubernetesのサービスのみに関する責任を負います。その後、開発者は管理者を介することなく、割り当てられたネームスペース内にアプリケーションをデプロイします。開発者は、TLS証明書・鍵の管理、ドメイン名のロードバランシングの定義、およびVirtualServerまたは標準のIngressリソースを作成することによるアプリケーションの公開に対する責任を負います。
このモデルを説明するために、次の図に示すように、a.bookinfo.com
と b.bookinfo.com
という 2 つのサブドメインを持つサンプル bookinfo アプリケーション (Istio が作成) をデプロイしてみます。管理者が NGINX Ingress Controller を nginx-ingress
ネームスペース(緑でハイライト)にインストールしデプロイした後、チーム DevA(ピンク)と DevB(紫)は独自の VirtualServer リソースを作成し、それぞれのネームスペース(それぞれ A
と B
)内に独立したアプリケーションをデプロイします。
チームDevAとDevBは、それぞれのドメインに対してIngressルールを設定し、外部からの接続をアプリケーションにルーティングします。
チームDevAは、A
ネームスペースのa.bookinfo.com
としてアプリケーションを公開するため、以下のVirtualServerリソースを適用します。
同様に、チームDevBは、B
ネームスペースのb.bookinfo.com
としてアプリケーションを公開するため、以下のVirtualServerリソースを適用します。
制限付きセルフサービスモデルでは、管理者はクラスタに着信するトラフィックを適切なネームスペースに転送するため、VirtualServerリソースを構成しますが、ネームスペース内のアプリケーションに関する設定はその担当の開発チームに委任します。これらの各チームはVirtualServerリソースで示された、アプリケーションのサブルートのみに責任を持ち、VirtualServerRouteリソースを利用し、トラフィックのルールを定義し、自身のネームスペース内のアプリケーションのサブルートを設定します。
図に示すように、クラスタ管理者は NGINX Ingress Controller を nginx-ingress
ネームスペース (緑でハイライト)にデプロイし、VirtualServerRoute リソースの定義を参照するパスベースのルールを設定する VirtualServer リソースを定義しています。
この VirtualServer リソースの定義では、2つのパスベースのルールを記述し、/productpage-A
と /productpage-B
という2つパスに対するVirtualServerRoute リソースの定義を参照します。
ネームスペース A
と B
のアプリケーションを担当する開発チームは、 VirtualServerRouteリソースを定義して、ネームスペース内のアプリケーションサブルートを公開します。各チームはネームスペースによって分離され、管理者が設定した VirtualServer リソースで指定されたサブルートのアプリケーションに限定されます。
チーム DevA (図のピンク色) は、以下の VirtualServerRoute リソースを適用して、管理者が /productpage-A
に割り当てたアプリケーションのサブルートを示すルールを公開します。/p>
チーム DevB (紫色) は、以下の VirtualServerRoute リソースを適用して、管理者が /productpage-B
に割り当てたアプリケーションのサブルートを示すルールを公開します。
VirtualServer および VirtualServerRoute リソースで設定できる機能の詳細については、 NGINX Ingress Controller のドキュメントを参照してください。
注:Mergeable Ingressタイプを使用してネームスペース間のルーティングを設定できますが、制限付きのセルフサービスデリゲーションモデルでは、そのアプローチにVirtualServerおよびVirtualServerRouteリソースと比較して3つのデメリットがあります。
Kubernetesのロールベースアクセスコントロール(RBAC)を使用すると、ユーザに割り当てられたロールに基づいて、ネームスペースとNGINX Ingressリソースへのユーザアクセスを制御することができます。
例えば、制限付きセルフサービスモデルでは、特別な権限を持つ管理者のみがVirtualServerリソースへのアクセスを安全に許可されます。これらのリソースはKubernetesクラスタのエントリポイントを定義するため、誤った利用がシステム全体の停止につながる可能性があります。
開発者は VirtualServerRoute リソースを使用して、自分が所有するアプリケーションへのルートを Ingress ルールで構成します。管理者は開発者がこれらのリソースのみを作成できるように RBAC ポリシーを設定します。開発者のアクセスをさらに規制する必要がある場合は、その許可を特定のネームスペースに制限することも可能です。
フルセルフサービスモデルでは、開発者は安全に VirtualServer リソースへのアクセスを許可されますが、ここでも管理者はその許可を特定の ネームスペースに制限することができます。
RBACによる認可の詳細については、Kubernetesのドキュメントを参照してください。
NGINX Policyリソースは、複数のチームがKubernetesのマルチテナントデプロイメントを設定するためのもう一つのツールです。ポリシーリソースは、OAuthやOpenID Connect(OIDC)を使った認証、レート制限、Webアプリケーションファイアウォール(WAF)などの機能を実現する事ができます。ポリシーリソースは VirtualServer と VirtualServerRoute リソースで参照され、Ingress の設定として反映されます。
例えば、クラスタのアイデンティティ管理を担当するチームは、OIDCのアイデンティティプロバイダ(IdP)としてOktaを使用する際に、次のようなJSON Web Token(JWT)またはOIDCポリシーを定義することができます。
NetOpsやDevOpsのチームは、VirtualServerやVirtualServerRouteリソースを利用し、これらのポリシーを参照します。以下がその例です。
NGINX Policy、VirtualServer、VirtualServerRouteリソースを組み合わせることで、管理者が他のチームに簡単に設定を委譲できる分散構成アーキテクチャが可能になります。チームは、ネームスペース全体でモジュールを組み立て、安全でスケーラブルかつ管理しやすい方法を用いて、高度なユースケースに対応したNGINX Ingress Controllerを構成することができます。
Policyリソースの詳細については、NGINX Ingress Controllerのドキュメントを参照してください。
この投稿は、当社のeBook「Managing Kubernetes Traffic with F5 NGINX: A Practical Guide」からの抜粋です。今すぐ無料でダウンロードしてください。
NGINX PlusをベースにしたNGINX Ingress Controllerを30日間の無料トライアルで今すぐお試しいただくことが可能です。また、お客様環境での使用例については弊社までお問い合わせください。
"This blog post may reference products that are no longer available and/or no longer supported. For the most current information about available F5 NGINX products and solutions, explore our NGINX product family. NGINX is now part of F5. All previous NGINX.com links will redirect to similar NGINX content on F5.com."