Ingress の構成
Kubernetes の Ingress は、リクエストのホストまたはパスに基づいてサービスにリクエストをルーティングする方法を提供し、多数のサービスを単一のエントリポイントに一元化します。
NetScaler Ingress Controller は Kubernetes Ingress を中心に構築されており、Ingress リソース構成に基づいて 1 つ以上の NetScaler を自動的に構成します。
ホスト名ベースのルーティング
次の Ingress 定義の例は、ホスト名に基づいてトラフィックをルーティングするように Ingress を設定する方法を示しています。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: virtual-host-ingress
namespace: default
spec:
rules:
- host: foo.bar.com
http:
paths:
- backend:
service:
name: service1
port:
number: 80
pathType: Prefix
path: /
- host: bar.foo.com
http:
paths:
- backend:
service:
name: service2
port:
number: 80
pathType: Prefix
path: /
Ingress 定義の例がデプロイされると、ホストヘッダーを持つすべての HTTP リクエストは NetScaler によって
service1 にロードバランスされます。また、ホストヘッダーを持つ HTTP リクエストは NetScaler によって service2 にロードバランサーされます。
パスベースのルーティング
次の Ingress 定義の例は、URL パスに基づいてトラフィックをルーティングするように Ingress を設定する方法を示しています。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: path-ingress
namespace: default
spec:
rules:
- host: test.example.com
http:
paths:
- backend:
service:
name: service1
port:
number: 80
path: /foo
pathType: Prefix
- backend:
service:
name: service2
port:
number: 80
path: /
pathType: Prefix
Ingress 定義の例がデプロイされると、ホスト
test.example.com と URL パスにプレフィックス /foo を持つすべての HTTP リクエストは NetScaler によって service1 にルーティングされ、その他のすべてのリクエストは service2 にルーティングされます。
NetScaler Ingress Controller は、パスを評価するために最初の一致ポリシーに従います。効果的なマッチングのために、NetScaler Ingress Controller はパスの長さの降順に基づいてパスを順序付けします。また、複数の Ingress リソースに属する同じホストのパスも順序付けします。
ワイルドカードホストルーティング
次の Ingress 定義の例は、ワイルドカードホストを持つ Ingress を設定する方法を示しています。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: wildcard-ingress
namespace: default
spec:
rules:
- host: '*.example.com'
http:
paths:
- backend:
service:
name: service1
port:
number: 80
path: /
pathType: Prefix
Ingress 定義の例がデプロイされると、
example.com のすべてのサブドメインへの HTTP リクエストは NetScaler によって service1 にルーティングされます。
注記：
ワイルドカードホストではないルールは、ワイルドカードホストよりも高い優先度が与えられます。異なるワイルドカードホスト間では、ルールはホストの長さの降順で順序付けされます。
正確なパスの一致
networking.k8s.io/v1 APIバージョンに属するIngressは、PathType: Exact を使用してパスを正確な一致として考慮できます。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: Path-exact-Ingress
namespace: default
spec:
rules:
- host: test.example.com
http:
paths:
- backend:
service:
name: service1
port:
name: 80
path: /exact
pathType: Exact
(Kubernetes 1.22以降では非推奨) デフォルトでは、
extension/v1beta1 に属するIngressの場合、パスは Prefix 式として扱われます。Ingress定義でアノテーション ingress.citrix.com/path-match-method: "exact" を使用すると、NetScaler Ingress Controllerはパスを正確な一致として考慮するように定義されます。
以下のIngress定義のサンプルは、正確なパスの一致のためにIngressを設定する方法を示しています。
apiVersion: extension/v1beta1
kind: Ingress
metadata:
name: path-exact-ingress
namespace: default
annotations:
ingress.citrix.com/path-match-method: "exact"
spec:
rules:
- host:test.example.com
http:
paths:
- path: /exact
backend:
serviceName: service1
servicePort: 80
サンプルIngress定義がデプロイされると、パス
/exact を持つHTTPリクエストはNetScalerによって service1 にルーティングされますが、/exact/somepath にはルーティングされません。
非ホスト名ルーティング
以下の例は、ホストベースのルートと一致しないデフォルトトラフィックのパスベースルーティングを示しています。このIngressルールは、指定されたIPアドレスを介したすべてのインバウンドHTTPトラフィックに適用されます。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: default-path-ingress
namespace: default
spec:
rules:
- http:
paths:
- backend:
service:
name: service1
port:
number: 80
path: /foo
pathType: Prefix
- backend:
service:
name: service2
port:
number: 80
path: /
pathType: Prefix
ホスト名を持つIngressルールと一致しないすべての受信トラフィックは、ルーティングのためのパスでここで一致します。
デフォルトのバックエンド
デフォルトのバックエンドは、どのIngressルールとも一致しないすべてのトラフィックを処理するサービスです。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: default-ingress
namespace: default
spec:
defaultBackend:
service:
name: testsvc
port:
number: 80
注：
NetScaler CPXがトラフィックをロードバランシングしている場合、グローバルなデフォルトバックエンドを指定できます。NetScaler VPXまたはMPXがIngressデバイスである場合、
frontend-ip:port の組み合わせごとにデフォルトバックエンドを作成できます。