NGINX Ingress Controller for Kubernetes 1.7.0のリリースを発表
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)の両方で構成できます。
- Kubernetes Ingressリソースは、Ingress Controllerの実装全体にわたって最大の互換性を実現します。また、アノテーションとカスタムテンプレートを使用して拡張でき、高度な構成を生成できます。
- NGINX Ingressリソースは、一般のKubernetes Ingressリソースをカスタマイズする場合よりも機能が豊富で、NGINX固有の構成スキーマを提供します。 リリース1.7.0では、次の主要な機能が強化されています。
リリース1.7.0では、次の主要な機能が強化されています。
- Red Hat OpenShift Operator – Operatorを使用すると、使い慣れた簡単な方法で、OpenShift上のNGINX Ingress Controllerのライフサイクルを管理できます。NGINX Ingress Controllerは、Red Hatによって認定されており、OpenShiftで完全にサポートされているソリューションです。
- NGINX IngressリソースはHTTP以外のプロトコル（TCP、UDP、TLSパススルー）をサポートします – シンプルかつ直感的な方法で、カスタムリソースを使用し、KubernetesからHTTP以外をベースとする複雑なサービスをデリバリできます。NGINXでは、今後、このようなアプローチを推進していく方針です。
- NGINX Ingressリソースはマイクロサービスのサーキットブレーカーパターンをサポートします – 指定したサービスが正しく機能していないときに、NGINX Ingress Controllerが返すデフォルトのエラーページを指定できるようになりました。
- NGINX Ingressリソースの検証とレポート機能が改善されました – OpenAPI検証を使用するより厳密な検証により、NGINX Ingressリソースでエラーが発生する可能性を低減し、エラーメッセージが大幅に改善されます。
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からビルド済みのコンテナをダウンロードしてください。
"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."