Kong Inc.は、Kong for Kubernetesバージョン0.8をリリースした。Kong API Gatewayで動作するKubernetes Ingressコントローラである。このリリースには、Knativeインテグレーション、新しいクラスタレベルのカスタムリソース定義、構成を最小限に抑えるためのアノテーションが追加されている。
Kong Gatewayは、NGINXの上に構築されたオープンソースのAPIゲートウェイである。アナウンスブログへの投稿によると、Konger for Kubernetes製品は「K8S入力構成向けのKongの状態を管理するKubernetesコントローラと、入力APIリクエストを処理および管理するKong Gateway」の2つの部分で構成されている。パブリッククラウド上のほとんどのマネージドKubernetesデプロイメントは、クラウドベンダが提供するIngressコントローラを利用する。これらのコントローラは、ベンダのロードバランサやその他の計算の抽象化を利用して機能する。Kubernetesのデプロイには、他のコントローラを使用するオプションもある。オプションにはNGINXとHAProxyがある。
InfoQは、このリリースと、Kong for Kubernetesの機能全般に関して詳しく知るために、Kong Inc.の製品担当副社長であるReza Shafii氏に連絡を取った。
Shafii氏は、Kong for KubernetesがKong API Gatewayの持つすべての機能をIngressに追加すると説明している。これらはAPI管理機能であり、「OIDCベースの認証の適用、高度なレート制限、リクエストキャッシング、ログとメトリックのさまざまな分析プロバイダーへのストリーミング提供などのAPIトラフィックの動的なポリシー管理を同時に有効にする」機能である。Shafii氏は、パフォーマンスの側面についてさらに詳しく説明する。
これらには、高パフォーマンスプロファイル（例えば、サブミリ秒の遅延で、1秒あたり25,000以上のトランザクション処理）や、複数のプロトコルと対話パターン（REST、graphQL、gRPC、TCPなど）のサポートなどが含まれています。一方で、Kubernetes CRDを通じてKong Gatewayのすべてのオペレーションを提供します。この最後のポイントは重要です。理由は、これによって、Ingressの運用面がすべてのクラウドプロバイダーとオンプレミスを通して一貫したものになるためです。
Shafii氏によると、Kongはnginx上に構築されているが、そのIngressコントローラは、デフォルトのnginx-ingress-controllerやnginx独自の商用コントローラと比較して、大きな違いがある。これらの違いは、Kongが持つAPI管理機能にあり、そして、Kong Gatewayのユーザに対して、KubernetesとKubernetes以外のワークロード全体で「一貫したAPI管理ライフサイクル」を提供するという事実にある。
画像提供 : https://konghq.com/blog/kong-for-kubernetes-0-8-released/ (許可を得て使用)
0.8リリースでは、Knative向けにIngressサポートが追加されている。Knativeは、Kubernetes上のコンテナーベースのワークロード用のサーバーレスプラットフォームであり、「一般的なアプリのユースケースのより高レベルの抽象化」を提供する。Knative向けのデフォルトのIngressはIstioに基づいており、Glooなどの代替も利用できる。 Shafii氏は、KnativeのデフォルトのIngressとKongが提供するIngressの違いを説明している。
コミュニティと顧客から学んだことは、ほとんどのユースケースでは、サーバーレスワークロードを実行するためにIstioの力を必要としないことです。そして実際、Istioの大きな力は、Kumaサービスメッシュプロジェクトを開始するきっかけとなった理由の1つです。Kong Gatewayのプラグインアーキテクチャと拡張性を重視することで、Knativeワークロードをビジネスロジックのみに集中させることができます。
クラウドベンダのロードバランサをKongのイングレスコントローラで使用することもできる。Shafii氏が詳細を述べている。
クラウドロードバランサは、複数のKong Gatewayノード間でトラフィックを分散する方法を提供します。Kong Gatewayノードは、クラスタ内の複数のサービスへのトラフィック管理に役立ちます。実際、ほとんどのユーザに対して、AWSまたはGCPなどのロードバランサーを使用して、Kong Gatewayのフロントに配置することをお勧めします。これにより、クラウド内の仮想プライベートネットワーク内にエンドポイントが提供されます。そうすると、それは他のネットワーク（異なるAWSアカウント）や、他のパートナーネットワークに公開したり、インターネットに直接公開したりできるようになります。
GCPやAWSなどのクラウドベンダや、IstioやGlooなどのゲートウェイによって提供されるネットワークトラフィックメトリックと同様に、Kong for Kubernetesは「HTTPステータスとエラーコード、トラフィックのスループット/遅延、ルートごととサービスレベルごとの（入力/出力）帯域幅などのメトリック」を収集できる。Shafii氏によると、「提供される接続、現在使用中の接続、共有メモリの使用状況、キャッシュヒット率」など、Kong Gateway自体のヘルス関連のメトリックも利用できる。また、彼は、これらの指標は、Prometheus、Data Dog、StatsD、Zipkin、Jaegerと統合できると付け加えた。
0.8リリースには、パスベースのルーティングに関する大きな変更があり、一部のアノテーションは非推奨になっている。変更ログには、変更の全てがリスト化されている。