AISpeechがk8s Ingress ControllerとしてNGINXではなくApache APISIXを選ぶ理由

はじめに

こんにちは、皆さん。私はAISpeechのJin Weiです。AISpeechはコンピュータ音声認識と分析に特化したハイテク企業で、今日はApache APISIXとKubernetes（K8s）の統合について、特にネイティブIngressの代わりにAPISIXを使用する方法についてお話しします。

執筆時点で、Apache APISIXはすでに私たちの本番環境に導入され、一部のビジネスエントリートラフィックを引き継いでいます。以下の図に示すように、ネイティブIngressのトラフィックを徐々に移行しています。

アーキテクチャ図

実際、APISIX-ingress-controllerはPodのIPをアップストリームノードに登録し、ビジネストラフィックがkube DNSを迂回して直接Podにアクセスできるようにします。これに基づいてプラグインを使用することで、特定のロードバランシングポリシーを実装できます。したがって、一方ではApache APISIXの動的ルーティング機能に依存してトラフィックを分散し、他方ではビジネスニーズを満たすためにカスタムプラグインを追加しています。

上の図から、APISIX-ingress-controllerはネイティブIngressと重複しているように見えます。この記事では、なぜ私たちがネイティブIngressを放棄し、Apache APISIXに基づいて独自のIngressコントローラーを構築したのかを簡単に説明します。

Ingressとは何か

一言で言えば、IngressはKubernetesが外部トラフィックを処理する方法です。

Ingressが解決する問題

Kubernetesクラスター内のサービスは仮想ネットワークであるため、外部トラフィックは少なくともパブリックIPと適切にマッピングされたポートを必要とし、クラスター内の内部サービスにアクセスします。

Kubernetesには、Kubernetes内部サービスにアクセスするためのインターフェースを公開するさまざまな方法（NodePort、LoadBalancer、Ingressなど）があります。比較すると、Ingressは限られた数のパブリックIPを公開することでリバースプロキシを実現するより経済的な方法です。

リバースプロキシに関して言えば、NGINXを直接構築することもできますが、Kubernetes内の頻繁に変化するサービスステータスをNGINXと同期させるのは非常に難しいです。

良いニュースは、Kubernetesが公式にNGINX ingressコントローラーを提供し、維持していることです。このNGINX ingressコントローラーを使用することで、Kubernetesにアクセスしたいすべてのトラフィックをプロキシし、バックエンドサービスに正しく向けることができます。

KubernetesネイティブIngressコントローラーの問題点

NGINX ingressコントローラーは、KubernetesクラスターとNGINXの間のステータス同期を維持し、基本的なリバースプロキシ機能を提供しますが、なぜ私たちは独自のIngressを構築するのでしょうか？私たちは、より多くのビジネスニーズを満たすためにIngressコントローラーにさらに期待しています。

KubernetesネイティブIngressコントローラーを使用した後、以下の問題が顕著であることがわかりました：

リロード問題

KubernetesネイティブIngressは、YAML設定ファイルをIngressコントローラーに渡し、それをNGINX設定ファイルに変換してからリロードをトリガーして設定を有効にするように設計されています。

これは特にトラフィックが長い接続を使用している場合に受け入れられず、事故を引き起こす可能性があります。

対照的に、Apache APISIXは設定のホットリロードをサポートしているため、NGINXのリロードをトリガーすることなく、いつでもルートを定義および変更できます。
アノテーションでのスクリプト作成とパラメータ入力

ネイティブIngressコントローラーは、YAMLファイル内のアノテーションで定義されたスクリプトスニペットをサポートしていますが、これは高度な機能をサポートするための一時的な解決策のように感じられ、正直なところ、管理が非常に難しいです。多数のアノテーションスクリプトは、DevOpsスタッフにとって問題を引き起こします。

Apache APISIXでは、プラグインコードを介してロジックを記述し、シンプルな設定インターフェースを公開することで、設定のメンテナンスを容易にし、DevOpsスタッフへのスクリプトの干渉を避けることができます。
ステートフルロードバランシングのサポート不足

「セッション永続化」などの高度なロードバランシングポリシーはサポートされていません。Kubernetesは運用指向のコンテナ化アプリケーション管理システムであり、Kubernetesがステートレスなデプロイメントアプローチを推進していることと関係があるかもしれません。そのため、Kubernetesは近い将来、これらの矛盾するロードバランシングポリシーを公式にサポートしないでしょう。実際、Googleはすでにサービスメッシュソリューション（Istio）でこれらの問題に対処しようとしています。Istioのアーキテクチャは完璧ですが、パフォーマンスを犠牲にしており、これはmixer v2で解決されるかもしれません。

Kubernetesはスケーリングをサポートしているため、Apache APISIXを拡張して高度なロードバランシングニーズを満たすこともできます。Apache APISIXは「セッション永続化」などのロードバランシングをネイティブでサポートしているだけでなく、バランサーフェーズを拡張する能力も持っています。
動的重み付け

ビジネスサービスでは、しばしばトラフィックをパーセンテージで制御する必要がありますが、これはKubernetesでは問題になります。

Kubernetesは1.8以降IPVS（IP Virtual Server）をサポートしていますが、「kube-proxy」の起動パラメータや「kube-route」のアノテーションは、Apache APISIXほど使いやすくありません。Apache APISIXは内部的にルート、サービス、コンシューマー、アップストリーム、プラグインなどの主要なオブジェクトを抽象化しています。そのため、アップストリームの「ノードの重み」を変更するだけで、このような操作の重み付けを自然にサポートします。
柔軟性のない拡張機能

Ingressはもともと外部トラフィックに対処するために設計されましたが、外部トラフィックに対する需要は内部トラフィックに対する需要と同様に少なくありません。

サービスレベルのカナリアリリース、サーキットブレーカー、フロー制御、認証、トラフィック制御などの要件は、Ingressでより一般的に実装されます。

Apache APISIXは拡張性のためのプラグインサポートを提供しており、公式プラグインに加えて、独自の特性を満たすためにカスタムプラグインを作成できます。

ConfigMapやNamespacesによる設定の問題もありますが、これらは私たちの使用方法に関連しており、一般的ではないため、ここでは詳しく説明しません。

Apache APISIX Ingressコントローラー

Apache APISIXの強力なルーティングと拡張機能により、Ingressの実装としてApache APISIXを使用することで、上記の課題を簡単に解決し、コミュニティに追加のIngressコントローラーオプションを提供できます。タイミング図は以下の通りです：

タイミング図

Apache APISIX ingressコントローラーを実装するためには、2つの基本的な問題を解決する必要があります。1つはKubernetesクラスターとApache APISIXのステータス間の同期を解決すること、もう1つはApache APISIX内のオブジェクトをKubernetesで定義すること（CRD）です。

Apache APISIXを迅速に統合し、その利点を活用するために、Apache APISIX ingressコントローラープロジェクトを作成しました（皆さんの参加を歓迎します）。現在、最初の基本的な問題であるKubernetesのPod情報をApache APISIXのアップストリームに同期すること、および自身の高可用性問題を解決するためのプライマリーバックアップを実装しています。

KubernetesはYAMLを使用してクラスターのステータスを宣言的に定義するため、Apache APISIX内のオブジェクト（ルート/サービス/アップストリーム/プラグイン）をKubernetesに統合するためにCRD（カスタムリソース定義）を定義する必要があります。

また、既存のKubernetes ingressユーザーの移行を容易にするために、既存のingress設定項目との互換性を確保しようとしています。

これらの機能は、私たちの次の取り組みの目標であり、皆さんの参加を歓迎します。