ブログ | NGINX

Kubernetes のイングレスおよびエグレス トラフィック管理を簡素化する方法

NGINX-F5 水平黒タイプ RGB の一部
ケイト・オズボーン サムネイル
ケイト・オズボーン
2021年6月28日公開

サービス メッシュによってKubernetes環境の管理が実際に複雑になる原因の 1 つは、サービス メッシュをIngress コントローラーとは別に構成する必要がある場合です。 個別の構成は時間がかかるだけではありません。 それにより、適切なトラフィック ルーティングを妨げる可能性のある構成エラーが発生する可能性が高まり、セキュリティの脆弱性 (悪意のあるユーザーが制限されたアプリにアクセスするなど) やエクスペリエンスの低下 (顧客が許可されたアプリにアクセスできないなど) につながる可能性があります。 個別の構成を実行するのにかかる時間に加えて、エラーのトラブルシューティングにさらに多くの時間を費やすことになります。

NGINX Plus ベースのNGINX Ingress Controller をNGINX Service Meshと統合して、入力と出力の両方の mTLS トラフィックを制御することで、これらの問題を回避し、時間を節約できます。 このビデオ デモでは、完全な手順を説明します。

サポートドキュメントは次のセクションで参照されます。

前提条件 (0:18)

実際のデモを開始する前に、次の前提条件を実行しました。

  1. Kubernetes クラスターにNGINX Server Mesh コントロール プレーンをインストールし、サービス メッシュの mTLS と厳格なポリシーを設定しました。

  2. NGINX Plus ベースのNGINX Ingress Controller をデプロイメント (DaemonSet ではなく) として Kubernetes クラスターにインストールし、 egress を有効にして、 LoadBalancerタイプのサービスとして公開しました。

    注記： このデモは、NGINX オープンソース ベースの NGINX Ingress Controller では動作しません。 読みやすくするために、このブログの残りの部分では、 NGINX Plus ベースのNGINX Ingress Controller を単に「NGINX Ingress Controller」と呼びます。

  3. 指示に従ってサンプルのbookinfoアプリをダウンロードし、NGINX Service Mesh サイドカーを挿入して、アプリをデプロイしました。

ステップ 1 で作成された厳格なポリシーの結果、メッシュ外部のクライアントからのbookinfoアプリへのリクエストはサイドカーで拒否されます。 デモでは、まず次のコマンドを実行してポート転送を設定することでこれを説明します。

> kubectl port-forward svc/product-page 9080 127.0.0.1:9080 から転送 -> 9080 [::1]:9080 から転送 -> 9080 9080 の接続を処理しています

アプリにアクセスしようとすると、ステータスコードが表示されます503ローカルマシンはサービスメッシュの一部ではないため:

>ローカルホスト:9080 をカールする503

NGINX サービス メッシュを使用した NGINX Ingress Controller のデプロイ (1:50)

アプリを公開するプロセスの最初の段階は、NGINX Ingress Controller インスタンスをデプロイすることです。 対応する手順は、チュートリアル「Kubernetes 用 NGINX Plus Ingress Controller を使用してデプロイする」に記載されています。

NGINX は、この目的のために Deployment マニフェストと DaemonSet マニフェストの両方を提供します。 デモでは、デプロイメント マニフェストnginx-plus-ingress.yamlを使用します。 これには、同じ NGINX Ingress Controller インスタンスを介して入力トラフィックと出力トラフィックの両方をルーティングするためのアノテーションが含まれています。

マニフェストにより、NGINX Ingress Controller と NGINX Service Mesh の証明機関 (CA) である Spire を直接統合できるようになり、NGINX Service Mesh サイドカーを NGINX Ingress Controller に挿入する必要がなくなります。 代わりに、NGINX Ingress Controller は、メッシュ内のポッドで mTLS に使用する証明書とキーを Spire CA から直接取得します。 マニフェストは、Spire エージェントのアドレスを指定します。

Spire エージェント UNIX ソケットを NGINX Ingress Controller ポッドにマウントします。

マニフェストについて最後に注目すべき点は、出力サービスへのルーティングを可能にする-enable-internal-routes CLI 引数です。

デモを開始する前に、 kubectl apply -f nginx-plus-ingress.yamlコマンドを実行してNGINX Ingress Controller をインストールし、この時点でnginx-ingress名前空間内のデプロイメントを検査します。 次の出力のREADY列に示されているように、NGINX Service Mesh サイドカーを挿入していないため、NGINX Ingress Controller ポッドのコンテナーは 1 つしかありません。

また、NGINX Ingress Controller の外部 IP アドレス (ここでは 35.233.133.188) をクラスターの外部に公開するために、 LoadBalancerタイプのサービスもデプロイしました。 その IP アドレスでサンプルbookinfoアプリケーションにアクセスします。

> kubectl get pods --namespace=nginx-ingress NAME READY STATUS RESTARTS AGE pod/nginx-ingress-867f954b8f0fzdrm 1/1 Running 0 3d3h NAME TYPE CLUSTER-IP EXTERNAL-IP ... service-nginx-ingress LoadBalancer 10.31.245.207 35.233.133.188 ... ... ポートの年齢... 80:31469/TCP、443:32481/TCP 4日2時間...

標準の Kubernetes Ingress リソースを使用してアプリを公開する (3:55)

ここで、 bookinfo-ingress.yamlで定義されている標準の Kubernetes Ingress リソースを使用して、メッシュでbookinfoアプリを公開します。 対応する手順は、チュートリアル「NGINX Plus Ingress Controller を使用してアプリケーションを公開する」に記載されています。

リソースは、10 行目でbookinfoアプリの Kubernetes Secret を参照し、 bookinfo.example.comへのリクエストがproductpageサービス ( 11 ～ 18 行目) に送信されることを指定するルーティング ルールを含みます。 Secret はbookinfo-secret.yamlで定義されています:

デモでは自己署名されているキーと証明書をロードするには、次のコマンドを実行します。

> kubectl apply -f bookinfo-secret.yaml secret/bookinfo-secret は変更されていません

Ingress リソースをアクティブ化します。

> kubectl apply -f bookinfo-ingress.yaml ingress.networking.k8s.io/bookinfo-ingress が削除されました

出力の最後にあるイベントで確認されるように、Ingress Controller がリソースで定義されたルートを追加したことを確認します。

> kubectl describe ingress bookinfo-ingress ...
イベント:
  タイプ 理由 経過時間 メッセージから ---- ------ ---- ---- ------- 正常 AddedOrUpdated 5s nginx-ingress-controller 構成 ... ...default/bookinfo-ingress が追加または更新されました

デモでは、ブラウザを使用してhttps://bookinfo.example.com/のbookinfoアプリにアクセスします。 (以前に、Ingress Controller サービスの IP アドレス (上記のデモでは 35.233.133.188) とbookinfo.example.com の間のマッピングをローカルの/etc/hostsファイルに追加しました。 手順については、ドキュメントを参照してください。 ページの「書籍レビュー」セクションの情報は、 bookinfo.yaml (ダウンロード) で定義されているレビューサービスの 3 つのバージョン間でリクエストが循環するにつれて定期的に変更されます。

次に、クラスターへの入力トラフィックを検査します。 generate-traffic.shスクリプトを実行して、NGINX Ingress Controller のパブリック IP アドレス経由でproductpageサービスにリクエストを送信し、次にnginx-meshctl topコマンドを実行してトラフィックを監視します。

> nginxmesh-ctl top deploy/productpage-v1デプロイメント方向 リソース 成功率 P99 P90 P50 ... productpage-v1 から details-v1 へ 100.00% 3ms 3ms 2ms から reviews-v2 へ 100.00% 99ms 90ms 20ms から reviews-v3 へ 100.00% 99ms 85ms 18ms から reviews-v1 へ 100.00% 20ms 17ms 9ms から nginx-ingress へ 100.00% 192ms 120ms 38ms ... リクエスト数... 14 ... 5 ... 5 ... 12

NGINX VirtualServer リソースを使用してアプリを公開する (6:45)

次に、 NGINX VirtualServer リソースを使用してアプリを公開する別の方法を示します。 これは、トラフィック分割やコンテンツベースのルーティングなど、より複雑なトラフィック処理をサポートするカスタム NGINX Ingress Controller リソースです。

まず、標準の Ingress リソースを削除します。

> kubectl delete -f bookinfo-ingress.yaml ingress.networking.k8s.io "bookinfo-ingress" が削除されました

bookinfo-vs.yamlファイルは、bookinfo-ingress.yaml (行 7 ～ 8 ) と同じ Secret を使用して mTLS を構成します。 9 行目から 12 行目では、 productpageサービスをアップストリームとして定義し、 13 行目から 24 行目では、 bookinfo.example.comで行われたすべてのGETリクエストをそのアップストリームに送信するルートを定義します。 GET以外のHTTPメソッドの場合はステータスコードを返します。405 。

次のリソースを適用します:

> kubectl apply -f bookinfo-vs.yaml virtualserver.kubernetes.nginx.org/bookinfo-vs が作成されました

次に、Ingress リソースと同じ手順を実行します。つまり、 kubectl describeコマンドを実行して正しいデプロイメントを確認し、ブラウザーでアプリにアクセスします。 アプリが正しく動作していることを示すもう 1 つの確認方法は、 POSTメソッドを拒否することです。

> curl -k -X POST https://bookinfo.example.com/メソッドは許可されていません

NGINX Ingress Controller を使用した安全な出力ルートの設定 (8:44)

ここでは、NGINX Ingress Controller を介して出力トラフィックをルーティングする方法を示します。 チュートリアル「NGINX Plus Ingress Controller を使用して安全な出力ルートを構成する」では、さまざまなサンプル アプリを使用してプロセスについて説明します。

すでにbash.yamlでシンプルなbashポッドを定義し、リクエストを送信しているデフォルトの名前空間にデプロイしています。 この出力のREADY列に示されているように、NGINX Service Mesh サイドカーが挿入されています。

> kubectl get all NAME READY STATUS RESTARTS AGE pod/bash-6ccb678958-zsgm7 2/2 Running 0 77s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.31.240.1 <なし> 443/TCP 4d2h ...

ポッド内から出力サービス（ NGINX Service Mesh の一部ではない任意のエンティティ）へのリクエストを有効にする必要があるユースケースがいくつかあります。 展開されるサービスの例:

  • クラスター外
  • 別のクラスター
  • 同じクラスタ上だが、NGINX Service Meshサイドカーは挿入されていない

デモでは、最終的なユースケースを検討しています。 レガシー名前空間にデプロイされたアプリケーションがあり、これは NGINX Service Mesh によって制御されておらず、NGINX Service Mesh サイドカーの自動挿入が無効になっています。 アプリに対して実行されているポッドは 1 つだけです。

> kubectl get all --namespaces=legacy NAME READY STATUS RESTARTS AGE pod/target-5f7bcb96c6-km9lz 1/1 Running 0 27m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/target-svc ClusterIP 10.31.245.213 <なし> 80/TCP,443/TCP 27m ...

NGINX Service Mesh に厳格なmTLS ポリシーを設定していることに留意してください。その結果、両者が相互に認証できないため、 bashポッドからターゲット サービスに直接リクエストを送信することはできません。 試してみるとステータスコードが返されます503ここに図示されているように:

> kubectl exec -it bash-6ccb678958-zsgm7 -c bash -- curl target-svc.legacy curl: (56) 受信失敗: ピア 503 によって接続がリセットされました。コマンドは終了コード 56 で終了しました。

解決策は、 bashポッドが NGINX Ingress Controller を介して出力トラフィックを送信できるようにすることです。 bash.yamlの14〜15行目の注釈のコメントを解除します。

次に、新しい構成を適用します。

> kubectl apply -f bash.yamlデプロイメント.apps/bash が設定されている

新しいbashポッドが起動したことを確認します。

> kubectl get pods NAME READY STATUS RESTARTS AGE bash-678c8b4579-7sfml 2/2 実行中 0 6秒 bash-6ccb678958-zsgm7 2/2 終了中 0 3分28秒

ここで、以前と同じkubectl execコマンドを実行して、 bashポッドからターゲットサービスにリクエストを送信すると、ステータスコードが返されます。404の代わりに503。 これは、 bashポッドがリクエストを NGINX Ingress Controller に正常に送信したが、ルート定義がないため、NGINX Ingress Controller がリクエストをどこに転送すればよいかわからないことを示しています。

legacy-route.yamlの次の Ingress リソース定義を使用して、必要なルートを作成します。 7 行目のinternal-routeアノテーションは、ターゲット サービスがインターネットに公開されず、NGINX Service Mesh 内のワークロードにのみ公開されることを意味します。

新しいリソースをアクティブ化し、NGINX Ingress Controller がリソースで定義されたルートを追加したことを確認します。

> kubectl apply -f legacy-route.yaml ingress.networking.k8s.io/target-internal-route が作成されました > kubectl describe ingress target-internal-route -n legacy ...
イベント:
  タイプ 理由 経過時間 メッセージから ---- ------ ---- ---- ------- 正常 AddedOrUpdated 6s nginx-ingress-controller の設定 ... ...legacy/target-internal-route が追加または更新されました

ここで、 kubectl execコマンドを実行すると、ターゲット サービスに到達します。 

{"要求": {"メソッド": 「GET」 「url」: 「/」、
「host」: 「target-svc.legacy」、
「remoteAddr」: 「10.28.2.76:56086」

NGINX Ingress Controller を介して出力トラフィックをルーティングする利点は、クラスター内からアクセスできる外部サービスを正確に制御できることです。つまり、ルートを定義したサービスのみにアクセスできるようになります。

デモで最後に紹介するのは、出力トラフィックを監視する方法です。 kubectl execコマンドを実行して複数のリクエストを送信し、次に次のコマンドを実行します。

> nginxmesh-ctl top deploy/nginx-ingress -n nginx-ingressデプロイメント方向 リソース 成功率 P99 P90 P50 リクエスト数 nginx-ingress ターゲットへ 100.00% 1ms 1ms 1ms 9 bashから 100.00% 0ms 0ms 0ms 9

レイテンシに「ノー」と言う – NGINX Ingress Controller で NGINX Service Mesh を試す

多くのサービス メッシュでは、イングレス ゲートウェイとエグレス ゲートウェイのオプションが提供されていますが、NGINX 統合の追加の利点であるレイテンシの低減も評価していただけると思います。 ほとんどのメッシュでは、Ingress コントローラーにサイドカーを挿入する必要があり、トラフィックがアプリに到達するまでに余分なホップが必要になります。 数秒は重要であり、余分なホップによってデジタル エクスペリエンスが遅くなると、顧客が他の場所に向かう可能性があります。 NGINX Service Mesh は、NGINX Ingress Controller にサイドカーを挿入しないため、不要なレイテンシを追加しません。 代わりに、メッシュの CA である Spire と直接統合することで、NGINX Ingress Controller は NGINX Service Mesh の一部になります。 NGINX Ingress Controller は、Spire エージェントから証明書とキーを取得し、それらを使用してメッシュ ポッドとの mTLS 証明書交換に参加します。

Kubernetes 用の NGINX Ingress Controller には 2 つのバージョンがあります。 NGINX オープンソースと NGINX Plus。 このブログで説明されているように、NGINX Ingress Controller を NGINX Service Mesh とともにデプロイするには、 30 日間の無料トライアルが利用できる NGINX Plus バージョンを使用する必要があります。

NGINX Service Mesh は完全に無料で、すぐにダウンロードでき、10 分以内に導入できます。 始めるには、ドキュメントを確認し、 GitHub経由で結果をお知らせください。

F5 NGINX に関するブログ投稿をもっと読む ›

「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"