ON THIS PAGE
Contrail Kubernetes ネットワークポリシーの使用事例
このセクションでは、’Contrail 環境でのネットワークポリシーの仕組みを検証するユースケースを作成します。’まず、テストに必要ないくつかの Kubernetes 名前空間とポッドを作成します。’デフォルトのネットワークモデルによって、すべてのポッドが dut (テスト中のデバイス) と通信できることを確認し、ネットワークポリシーを作成して、同じトラフィックパターンを使用した変更を監視します。
ネットワーク設計
Figure 1は、ユースケース設計を示しています。
Figure 1では、次の3つの部門に6つのノードが分散されています。開発、qa、jtac 開発部門では、顧客から収集した貴重なデータをすべて保持するデータベースサーバー (dbserver) を実行しています。この設計では、このデータベースサーバーに直接アクセスできない人はいないことが求められます。その代わりに、データベースサーバーへのアクセスは、dev 部門の別の Apache フロントエンドサーバーを通じてのみ許可されます。さらに、セキュリティ上の理由により、顧客情報へのアクセスは許可されたクライアントにのみ付与する必要があります。たとえば、jtac 署のノード、dev department 内のノード 1 ~ client1、およびソース IP 10.169.25.20 は、web サーバ経由でデータベースにアクセスできます。最後に、データベースサーバー dbserver は他のノードへの接続を開始するべきではありません。
ラボの準備
ここでは、きわめてシンプルで簡素化されたネットワーク設計をどこでも見ることができます。Kubernetes の世界でこれらのすべてのネットワーク要素をモデル化すると、Figure 2のようになります。
ポッドには、以下のリソースを作成する必要があります。
3つのネームスペース: 開発、qa、jtac
6個のポッド:
2つのサーバーポッド: webserver-dev、dbserver
同じ名前空間で2つのクライアントポッドをサーバーポッドとして: client1-dev, client2-dev
2つの異なる名前空間からの2つのクライアントポッド: クライアント-qa、クライアント-jtac
2つの CIDRs:
cidr 10.169.25.20/32 は、ノード cent222 のファブリック IP です。
cidr 10.169.25.21/32 は、ノード cent333 のファブリック IP です。
Table 1: Kubernetes ネットワークポリシーテスト環境
ECN | pod | ロール |
向け | client1-dev | web クライアント |
向け | client2-dev | web クライアント |
保証 | クライアント-qa | web クライアント |
jtac | クライアント-jtac | web クライアント |
向け | web サーバ-dev | web サービスを提供するクライアント |
向け | dbserver-dev | dbserver サービスウェブサーバ |
ここ’では、必要な k8s 名前空間を準備し、dev、qa、および jtac 名前空間を定義するオールインワンの yaml ファイルを使用してリソースをポッドにします。
各ポッドを異なる画像で実行するのが理想的です。また、TCP ポートは、通常、web サーバーとデータベースの間では異なります。この例では、テストを容易にするために、すべてのポッドに関して本書’全体で使用していたのとまったく同じ contrail の画像を使用しています。そのため、クライアントから web サーバーへの接続には、同じ HTTP サーバーが提供する同じポート番号80を使用します。また、ラベルを追加しました。すべてのポッドのポリシーにより、このテストに使用されているすべてのポッドを簡単に表示できます。
では、すべてのリソースを作成しましょう。
Kubernetes ネットワークポリシー作成前のトラフィックモード
すべての名前空間とポッドがあるため、ネットワークポリシーを定義する前に、’クライアントとサーバー間でトラフィックを送信してみましょう。
もちろん、デフォルトでは Kubernetes ネットワークは any モデルに準拠しているため、完全メッシュアクセスの関係となる pod 間でアクセスが機能することを前提としています。しかし、このテストの DUT は webserver であり、dbserver は、さらに注目すべきものであることを覚えておいてください。図8.4 に示すように、検証’を簡素化するために、クライアントポッドからのサーバーポッドへのアクセスに重点を置いています。
図8.4 の重要な点は、すべてのクライアントがサーバーにアクセスできるということです。すべてのモデルには次のものがあります。
クライアントと webserver のデバイスポッドの間に制限はありません。
クライアントと dbserver のポッドの間に制限はありません。
さらに、クライアントとサーバー間の通信は、双方向–で対称に行われており、セッションを開始したり、セッションを受け入れたりすることができます。これらの Kubernetes では、送信ポリシーと受信ポリシーがそれぞれマップされます。
これらは設計の目標を満たしていません。その理由は、Kubernetes ネットワークポリシーが必要なこと’です。この部分についてはすぐに説明します。ここでは、’どのようなネットワークモデルかを簡単に確認してみましょう。
まず、’web サービスの開発および dbserver ポッドのポート80で実行されている HTTP サーバーを確認してみましょう。
$kubectl exec -it webserver-dev -n dev -- netstat -antp| grep 80 tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1/python $kubectl exec -it dbserver-dev -n dev -- netstat -antp| grep 80 tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1/python
前述したように、このテストでは、すべてのポッドが同じコンテナイメージを使用しているため、すべてのポッドがコンテナーで同じ web サーバアプリケーションを実行しています。各ポッドに名前を指定するだけで、それぞれの役割が図に反映されます。
これで、以下のコマンドを使用して、他のポッドからこの HTTP サーバーへのアクセスを検証できます。受信トラフィックをテストするには、次のようにします。
これらのコマンドは、2つのノードのすべてのクライアントおよびホストから、ウェブ・デバイス・ポッドに対して HTTP リクエストをトリガーします。-M5 curl コマンドオプションを使用すると、curl がタイムアウトする前に、応答に対して最大5秒間待機します。期待どおり、すべてのアクセスが通過し、次に示す同じ出力を返します。
Client1 から (dev):
$ kubectl exec -it client1-dev -n dev -- \ curl http://$webserverIP | w3m -T text/html | grep -v "^$" Hello This page is served by a Contrail pod IP address = 10.47.255.234 Hostname = webserver-dev
W3m は、curl からの出力を取得して、web ページの HTML コードを返し、それを読みやすいテキストにレンダリングしてから、それを grep に送って空の行を削除しています。コマンドを短くするには、次のようにエイリアスを定義します。
alias webpr='w3m -T text/html | grep -v "^$"'
その結果、コマンドは短くなります。
$ kubectl exec -it client1-dev -n dev -- curl http://$webserverIP | webpr Hello This page is served by a Contrail pod IP address = 10.47.255.234 Hostname = webserver-dev
同様に、’他のポッドから dbserver dev へのアクセスについても、同じテスト結果が得られます。