NGINX.COM
Web Server Load Balancing with NGINX Plus
Amir Rawdat of F5
Solutions Engineer
April 30, 2020

NGINX Ingress Controller for Kubernetes 1.7.0のリリースを発表いたしました。本リリースは、Amazon Elastic Container Service for Kubernetes（EKS）、Azure Kubernetes Service（AKS）、Google Kubernetes Engine（GKE）、Red Hat OpenShift、IBM Cloud Private、DiamantiなどのKubernetesプラットフォームでのIngressリソース向けに設計されています。


リリース1.7.0でもパワフルでありながら、柔軟で使いやすいIngress Controllerが引き続き提供され、Kubernetes IngressリソースとNGINX Ingressリソース(CRD)の両方で構成できます。

リリース1.7.0では、次の主要な機能が強化されています。

NGINX Ingress Controller for Kubernetesとは

NGINX Ingress Controller for Kubernetesは、Kubernetes環境でNGINX Open SourceまたはNGINX Plusインスタンスと一緒に実行されるデーモンです。このデーモンは、Kubernetes IngressリソースとNGINX Ingressリソースを監視して、Ingressロードバランシングが必要なサービスリクエストを検出します。次に、このデーモンは自動的にNGINXまたはNGINX Plusを構成して、Serviceにトラフィックをルーティングおよびロードバランスします。

複数のNGINX Ingress Controller実装パターンがあります。正式なNGINX実装は、高性能であり、本番環境ですぐに利用でき、長期的なデプロイメントに適しています。NGINXは、エンタープライズスケールでデプロイできる機能を提供し、新しいリリースにおいても安定して動作するように注力しています。NGINX Plusのサブスクライバーは、追加費用なしで包括的なテクニカルサポートを利用できます。NGINX Open Sourceユーザーは、NGINXが重点的に取り組んでいる安定した動作と充実したサポートのメリットを享受できます。

NGINX Ingress Controller 1.7.0の新機能

Red Hat OpenShiftのサポート

Red Hat OpenShiftがリリースされました。これは、OpenShiftプラットフォーム上のNGINX Ingress Controller（NGINX Open SourceとNGINX Plusの両方に対応）のライフサイクル管理ソリューションであり、包括的なサポートが提供されます。これにより、NGINX Ingress Controllerを簡単な操作でインストールでき、いくつかのパラメーターを指定するだけ基本的なデプロイを完了できます。

Operatorは、Kubernetesのネイティブオブジェクト（deployment, replica, Podなど）周りの複雑さを解消し、アプリケーション開発者や他のチームがKubernetesコンテナーインフラストラクチャを詳細に理解する必要性がなくなります。さらに、OperatorはIngress Controllerのデプロイメントをカスタマイズするパラメーターを提供します。

ワンステップのデプロイメントプロセスで、NGINX Ingress Controllerの高度な機能をOpenShiftに導入できるようにすることが、Operatorの目標です。たとえば、NGINX Ingressリソース（VirtualServer、VirtualServerRoute、およびTransportServer）を利用して、ブルーグリーンデプロイメント、トラフィックの分割、A/Bテストなどの多くのユースケースに対応できます。

また、NGINX Ingressリソースのロールベースアクセス制御（RBAC）とクロスネームスペース機能を活用して、ユーザーのセルフサービスとマルチテナンシーをサポートし、異なるチーム間におけるアプリケーションデリバリコンポーネント管理の明確な境界設定と委任を可能にします。

OpenShiftの管理者がOperatorをインストールすると、エンドユーザーは次のようなシンプルなマニフェストを使用して、NGINX Ingress Controllerをデプロイできます。

apiVersion: k8s.nginx.org/v1alpha1
kind: NginxIngressController
metadata:
  name: nginx-ingress-controller-foo
  namespace: nginx-ingress-controller-foo-ns
spec:
  type: deployment
  image:
    repository: registry.hub.docker.com/nginx/nginx-ingress
    tag: edge
    pullPolicy: Always
  serviceType: NodePort

Operatorは、上級者向けに、デプロイメントをカスタマイズするための広範なオプションを提供しています。利用可能なすべてのパラメーターを含むサンプルマニフェストについては、GitHubリポジトリをご覧ください。

「Red Hat OpenShiftでNGINX Ingress Operatorを使ってみる（英語）」も参照してください。

NGINX IngressリソースでのTCP、UDP、TLSパススルーサービスのサポート

1.7.0リリースの新機能として、NGINX Ingressリソースが拡張され、TCP、UDP、TLSパススルーのロードバランシングがサポートされました。

  • Ingress Controllerで、TCPおよびUDPがサポートされたことで、さらに広範なプロトコルを管理できるようになり、DNSおよびSyslog（UDP）からデータベースや他のTCPベースのアプリケーションも対応できるようになりました。
  • NGINX Ingress Controllerは、TLSパススルーによって、TLSで暗号化された接続を復号化したり、TLS証明書やキーへのアクセスを要求したりしてなくても、SNI(Server Name Indication) に基づいてルーティングできるようになります。

リリース1.7.0では、TCP、UDP、およびTLSパススルーを構成するための2つの新しいNGINX IngressリソースであるGlobalConfigurationおよびTransportServerをプレビューしています。次のリリース（1.8.0）を開発するにあたって、このアプローチに関するフィードバック、問題点の指摘、および改善提案をお願いしています。堅牢な構成アーキテクチャが完成したら、構成を確定し安定版として提供します。

HTTP以外のプロトコルが直接サポートされたことで、NGINXのストリーム構成がKubernetes Ingressリソースに直接埋め込まれていた過去の推奨オプションよりも、シンプルで信頼性の高いオプションを利用できるようになりました。

NGINX Ingress ControllerでTCPおよびUDPサービスをサポートする新しいシンプルで信頼性の高い設定方法を順番に見ていきましょう。

クラスタ管理者は、GlobalConfigurationリソースを使用して、ユーザーが割り当てた特定のポートを介してアプリケーションのTCPおよびUDPロードバランシングを構成できます。インストール時に-global-configuration=namespace/nameコマンドライン引数を追加するだけで、Ingress Controllerのグローバル構成のリソースを定義できます。

次の2つのリスナーが設定されたnginx-ingressネームスペースのこのGlobalConfigurationのサンプル定義を見てみましょう。

  • ポート5353でリッスンするTCPプロトコル
  • ポート5353でリッスンするUDPプロトコル
apiVersion: k8s.nginx.org/v1alpha1
kind: GlobalConfiguration
metadata:
  name: nginx-configuration
  namespace: nginx-ingress
spec:
  listeners:
  - name: dns-udp
    port: 5353
    protocol: UDP
  - name: dns-tcp
    port: 5353
    protocol: TCP

その後、ユーザーは、NGINX Ingress Controllerを構成してTCPおよびUDPをロードバランシングするときに、TransportServerリソースでは名前（dns-udpまたはdns-tcp）でリスナーを参照する必要があります。以下に、TCPのロードバランシングをプロビジョニングするTransportServerリソースの実装例を示します。

apiVersion: k8s.nginx.org/v1alpha1
kind: TransportServer
metadata:
  name: dns-tcp
spec:
  listener:
    name: dns-tcp
    protocol: TCP
  upstreams:
  - name: dns-app
    service: coredns
    port: 5353
  action:
    pass: dns-app

specセクションでは、ユーザーはGlobalConfigurationリソース定義で設定されたdns-appリスナーを参照し、TCP接続をdns-appアップストリームに渡します。ポート5353のみが、dns-appリスナーに割り当てられています。UDPプロトコルについても、TransportServerを同様に構成できます。詳細なTCP/UDPの例はGitHubを参照してください。

さらに、TLSパススルーについてもTransportServerリソースを使用して、TLSで暗号化された接続をアップストリームサービスにルーティングできます。TLSパススルーを有効にするには、インストール時に-enable-tls-passthroughコマンドライン引数を追加します。以下に、TLSパススルーを設定するTransportServerリソースの実装例を示します。

apiVersion: k8s.nginx.org/v1alpha1
kind: TransportServer
metadata:
  name: secure-app
spec:
  listener:
    name: tls-passthrough
    protocol: TLS_PASSTHROUGH
  host: app.example.com
  upstreams:
    - name: secure-app
      service: secure-app
      port: 8443
  action:
    pass: secure-app

TLSパススルーを有効にする場合、名前がtls-passthroughでプロトコルが TLS_PASSTHROUGHの組み込みのリスナーを参照します。詳細なTLSパススルーの例はGitHubを参照してください。

サーキットブレーカーパターンのサポート

NGINX Ingress Controllerにおけるサーキットブレーカーパターンの実装では、次の2つの処理を行います。

  • 不安定なサービスを検出して分離し、アプリケーションから削除します（リリース1.6.0以降でサポート）
  • 不安定なサービスにリクエストルーティングする代わりに、定型文応答(Sorryメッセージやリダイレクト)をクライアントに提供します（リリース1.7.0の新機能）

障害が発生したサービスを呼び出す場合、タイムアウトしたり遅延を引き起こしたりする場合がありますが、サーキットブレーカーを使用すると、このような呼び出しを排除でき、アプリケーションのパフォーマンスを向上できます。

たとえば、アプリケーションはWebやモバイルのインターフェイスを表示することがあり、その中には記事へのコメント、リコメンデーション、広告などの付属アイテムのリストが含まれます。このリストを生成したKubernetesサービスが不安定な場合、サーキットブレーカーは、内部で生成されるエラーメッセージ（502 Service Unavailable）などのエラーメッセージを、より適切なレスポンスに置換できます。

この方法では、アプリケーションによって提供されるサービスが不安定になった場合にも、送信元クライアントにエラーを表示せず、アップリケーションの内部エラーを適切に処理できます。

次の例では、NGINX Ingressリソースはapp-svcサービスへのトラフィックを管理しています。このリソースは、アクティブヘルスチェック（NGINX Plus専用）を使用して、/statusリクエストに対してエンドポイントが適切なステータスコード（デフォルトでは2xxまたは3xx）で応答することを確認し、502エラー応答の原因となったリクエストをリダイレクトします。

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: app
spec:
  host: app.example.com
  tls:
    secret: app-secret
  upstreams:
  - name: app
    service: app-svc
    port: 80
    healthCheck:
      enable: true
      path: /status
  routes:
  - path: /
    errorPages:
    - codes: [502]
      redirect:
        code: 301
        url: https://nginx.org
    action:
      pass: app

VirtualServer定義を適用して、アプリケーションのアップストリームが正常かどうかを定期的かつNGINXが能動的にチェックできます。app-svcサービスの全てのエンドポイントで定期的なヘルスチェックが失敗する場合、アプリケーションのアップストリームは使用できなくなり（サーキットブレーカーが働きます）、アプリケーションのアップストリームにリクエストを行うクライアントはバックアップWebサイトにリダイレクトされます（この例ではhttps://nginx.org）。

このサーキットブレーカーのユースケースをテストするときには、以下のシナリオでNGINXがどのように応答するか考察できます。

  • エンドポイントへのリクエストにより、一時的なエラーが発生する。この場合、リクエストの再試行ロジックの構成方法に応じて、NGINXはリクエストを再試行するか、諦めてリクエストをリダイレクトします。
  • ヘルスチェックが、サービスの全てのエンドポイントで失敗する。この場合、NGINXは、指定されたURLにリクエストをリダイレクトすることができます。
  • サービスにエンドポイントがない（おそらく、エンドポイントの準備が整っていないことが原因と考えられる）。この場合、NGINXはリクエストを直ぐにリダイレクトします。 ready state). NGINX redirects the request promptly.

検証とレポートの改善

NGINX Ingress Controllerリリース1.7.0では、NGINX Ingressリソースを検証する仕組みが改善されました。NGINX Ingressリソースオブジェクト（VirtualServer、VirtualServerRoute、およびTransportServer）のOpenAPIの仕様に基づいて、kubectlおよびKubernetes APIサーバーは、たとえば、文字列フィールドに整数値が割り当てられている場合など、リソース構造の間違いを検出できるようになりました。この改善によって、アプリケーションのロードバランシングを構成しているユーザーのトラブルシューティングが短縮されます。

この検証は、以前のリリースよりも、NGINX Ingress Controller構成プロセスの早期の段階でエラーを捕捉し、さらに詳細なエラーメッセージを提供するように強化されました。

以下は、NGINX Ingress Controller レイヤ7パスベースルーティング用のVirtualServer実装のYAMLファイルです。黄色で強調表示されているフィールドには記述ミスがあります。

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: cafe
spec:
  host: cafe.example.com
  tls:
    secret: cafe-secret
  upstreams:
  - name: tea
    service: tea-svc
    port: DD
    healthCheck:
      enable: 3654
  - name: coffee
    service: coffee-svc
    port: 80
  routes:
  - path: /tea
    action:
      pass: tea
  - path: /coffee
    actionn:
      pass: coffee

次のコマンドを実行して、このYAMLファイルを適用します。

# kubectl apply -f cafe-virtual-server.yaml

この検証のメカニズムは、上記で強調表示されたエラーを捕捉し、次のメッセージを表示します。このメッセージはYAMLファイルでエラーが発生した順序とは逆に表示されています（最初のメッセージは最後のエラーであるスペルミス「actionn」に対応しています）。

error: error validating "cafe-virtual-server.yaml": error validating data: [ValidationError(VirtualServer.spec.routes[1]): unknown field "actionn" in org.nginx.k8s.v1.VirtualServer.spec.routes,

ValidationError(VirtualServer.spec.upstreams[0].healthCheck.enable): invalid type for org.nginx.k8s.v1.VirtualServer.spec.upstreams.healthCheck.enable: got "number", expected "boolean",

ValidationError(VirtualServer.spec.upstreams[0].port): invalid type for org.nginx.k8s.v1.VirtualServer.spec.upstreams.port: got "string", expected "integer"]; if you choose to ignore these errors, turn validation off with --validate=false

参考資料

1.7.0リリースの詳細な変更ログについては、リリースノートを参照してください。

是非この機会に、無料トライアル（30日間）をお試しください。NGINX Ingress Controller for KubernetesとNGINX Plusをお使いいただけます。また、その他ご質問などはこちらからご相談ください。

また、NGINX Open Sourceで NGINX Ingress Controllerをご利用の場合は、リリースソースコードを入手するか、DockerHubからビルド済みのコンテナをダウンロードしてください。

Tags
, , , ,
Hero image
Kubernetes のテスト環境から本番環境への移行

快適なKubernetes環境を実現するには、Kubernetesネイティブなやり方でトラフィックを理解し、管理する必要があります。
このEBOOK では、POC からカナリアリリース、ブルーグリーンデプロイメントを利用し本番環境にいたるまで、トラフィックフローを柔軟に効果的に管理する際に必要となる情報や、Kubernetes 戦略に求められる要素を明確でわかりやすい解説と共に提供いたします。

ダウンロードする


著者について

Amir Rawdat

Solutions Engineer

Amir Rawdat is a technical marketing engineer at NGINX, where he specializes in content creation of various technical topics. He has a strong background in computer networking, computer programming, troubleshooting, and content creation. Previously, Amir was a customer application engineer at Nokia.

その他のAmir Rawdatによるブログはこちら

About F5 NGINX

F5 NGINXについて
F5, Inc.は、人気のオープンソースプロジェクト「NGINX」を支援しています。NGINXはモダンアプリケーションを開発・構築するためのテクノロジースイートを提供しています。NGINXとF5製品との併用で、コードからユーザーまでの広範なアプリケーション領域をサポートし、マルチクラウドアプリケーションサービスとしてNetOpsとDevOps間の課題を解決します。

詳しくはnginx.co.jpをご覧ください。Twitterで@nginxをフォローして会話に参加することもできます。

NGINXを使ってみよう

rocket

NGINXを体験したい

無料トライアル

質問をしたい

お問い合わせ