Kubernetesチームは、2015年に最初に導入された後、先頃の1.19リリースで、Ingress APIを一般提供 (GA) に移行した。
Ingress APIは、外部HTTP/HTTPSトラフィックをバックエンドのKubernetesサービスにルーティングするために使用される。APIはベータ版ではあったが、Kubernetesにデプロイされた複数のサービスへの外部トラフィックのパスベースのルーティングを行う唯一の方法であったため、広く使用されていた。Googleオープンソースブログの記事にあるように、GAに移行する2つの主要な変更は、pathTypeとIngressClassである。
2019年11月のKubeCon/CloudNativeConの講演で、Christopher M Luciano氏 (IBM) とBowei Du氏 (Google) がGAの機能強化のプレビューを発表した。彼らは、以前のAPIは「大規模な移植性を確保する」ために範囲が限定されていることを指摘し、GAバージョンに加えられた変更について説明した。これらの制限により、ルーティング、認証、アクセス制御、レート制限、およびメトリック収集のためのアドオン機能を備えたサードパーティの拡張機能と製品 (無料および商用) が急増した。これらのいくつかを例に挙げると、HAProxy、nginx、Traefik、Kong、およびContourが含まれる。Kubernetesプロジェクト自体は、GCE (Google Kubernetes Engineで使用) とnginxコントローラを維持する。
Ingressコントローラーは、通常、マネージドKubernetesのクラウドベンダーによってIngressを「当てはめ」て実装されるコンポーネントである。つまり、通常はロードバランサによって外部トラフィックプロキシをセットアップし、Ingress構成に基づいてルーティングルールを構成および同期する。KubernetesがGCP、AWS、AKSなどのクラウドベンダープラットフォームにデプロイされている場合、Ingressコントローラの実装はベンダーによって提供され、クラウドベンダーのロードバランサによってサポートされる。nginxやHAProxyなどのサードパーティのIngressコントローラを使用するオプションもある。
ルーティングに関しては、pathTypeの変更により、基盤となるIngressコントローラへの移譲を許可することにより、以前使用可能だった構成が拡張される。「pathType: ImplementationSpecific」を設定することによる移譲とは別に、可能な値は完全一致とプレフィックス一致である。これにより、より柔軟な構成が可能になり、Kubernetes 1.19では必須になる。
IngressClassは、コントローラとその構成に関する情報をカプセル化するリソースである。Ingress定義はこのクラスを参照し、これは古い非標準のkubernetes.io/ingress.classアノテーションに取って代わるものである。
以前は、Ingress構成はアノテーションとConfigMapを使用して拡張されていた。Luciano氏とDu氏は講演の中で、APIの主な変更点は、オブジェクトモデルのクリーンアップ、仕様の微調整、および代替バックエンドタイプに関する柔軟性であるとも述べている。最後のポイントは、Kubernetesサービスだけでなく、ストレージバケットなどの代替バックエンドをサポートすることである。新しいバージョンで述べられている目標の1つは、拡張メカニズムを介したベンダー固有の動作の標準メカニズムを持つことだった。Ingress APIは、汎用的でクラウドに依存せず、Ingressコントローラから独立していることを目的としている。これらの機能のほとんどは、1.18リリース自体に含まれていた。
Ingressのロードマップは、「V2 Ingress APIまたは機能のスーパーセットを備えたまったく異なるAPIのいずれか」で作業している間、このバージョンをv1として維持することであるということを示す。「Gateway」は、「Ingressの機能を進化させるように設計された」オープンソースのKubernetes APIであり、おそらくその方向への一歩である。