Kubernetes クラスターにおいて、APIG Ingress はサービス向けに外部からアクセス可能な API オブジェクトを管理します。また、レイヤー 7 のロードバランシング機能を提供します。本トピックでは、クラスター内の Ingress トラフィック管理に用いる APIG Ingress の高度な機能について説明します。
カナリーリリース
APIG Ingress は、リクエストヘッダー、クエリパラメーター、Cookie、および重みに基づくカナリーリリースを含む高度なルーティングをサポートします。カナリーリリースはアノテーションで設定します。カナリーリリースを有効化するには、アノテーション nginx.ingress.kubernetes.io/canary: "true" を設定します。異なるアノテーションにより、異なるカナリーリリース機能が有効化されます。
複数のカナリーメソッドを設定した場合、優先順位は「ヘッダーまたはクエリパラメーターによる方式」→「Cookie による方式」→「重みによる方式」の順となります。
ヘッダーによるカナリーリリース
nginx.ingress.kubernetes.io/canary-by-headerのみを設定する場合:トラフィックはリクエストヘッダーに基づいて分割されます。設定されたheaderの値がalwaysの場合、トラフィックはカナリーサービスのエンドポイントにルーティングされます。それ以外の場合、トラフィックは安定版サービスにルーティングされます。nginx.ingress.kubernetes.io/canary-by-header-valueとnginx.ingress.kubernetes.io/canary-by-headerの両方を設定する場合:リクエストヘッダーおよびその値が設定値と一致する場合のみ、トラフィックはカナリーサービスにルーティングされます。それ以外の場合、トラフィックは安定版サービスにルーティングされます。
NGINX Ingress や ALB Ingress ではカナリーリリースに最大 2 つのサービスバージョンしか対応していませんが、APIG Ingress ではサービスバージョン数に制限がありません。
例:
リクエストヘッダーが
apig: alwaysの場合、リクエストは `demo-service-canary` カナリーサービスにアクセスします。それ以外の場合、`demo-service` 安定版サービスにアクセスします。以下のように設定します:Kubernetes バージョン 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-by-header: "apig" name: demo-canary spec: ingressClassName: apig rules: - http: paths: - backend: service: name: demo-service-canary port: number: 80 path: /hello pathType: Exact --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo spec: ingressClassName: apig rules: - http: paths: - backend: service: name: demo-service port: number: 80 path: /hello pathType: ExactKubernetes バージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-by-header: "apig" name: demo-canary spec: ingressClassName: apig rules: - http: paths: - path: /hello backend: serviceName: demo-service-canary servicePort: 80 --- apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: demo spec: ingressClassName: apig rules: - http: paths: - path: /hello backend: serviceName: demo-service servicePort: 80リクエストヘッダーが
apig: v1の場合、リクエストは `demo-service-canary-v1` カナリーサービスにアクセスします。リクエストヘッダーがapig: v2の場合、`demo-service-canary-v2` カナリーサービスにアクセスします。それ以外の場合、`demo-service` 安定版サービスにアクセスします。以下のように設定します:Kubernetes バージョン 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-by-header: "apig" nginx.ingress.kubernetes.io/canary-by-header-value: "v1" name: demo-canary-v1 spec: ingressClassName: apig rules: - http: paths: - backend: service: name: demo-service-canary-v1 port: number: 80 path: /hello pathType: Exact --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-by-header: "apig" nginx.ingress.kubernetes.io/canary-by-header-value: "v2" name: demo-canary-v2 spec: ingressClassName: apig rules: - http: paths: - backend: service: name: demo-service-canary-v2 port: number: 80 path: /hello pathType: Exact --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo spec: ingressClassName: apig rules: - http: paths: - backend: service: name: demo-service port: number: 80 path: /hello pathType: ExactKubernetes バージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-by-header: "apig" nginx.ingress.kubernetes.io/canary-by-header-value: "v1" name: demo-canary-v1 spec: ingressClassName: apig rules: - http: paths: - path: /hello backend: serviceName: demo-service-canary-v1 servicePort: 80 --- apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-by-header: "apig" nginx.ingress.kubernetes.io/canary-by-header-value: "v2" name: demo-canary-v2 spec: ingressClassName: apig rules: - http: paths: - path: /hello backend: serviceName: demo-service-canary-v2 servicePort: 80 --- apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: demo spec: ingressClassName: apig rules: - http: paths: - path: /hello backend: serviceName: demo-service servicePort: 80
クエリパラメーターによるカナリーリリース
higress.ingress.kubernetes.io/canary-by-query のみを設定する場合
トラフィックは URL のクエリパラメーターに基づいて分割されます。リクエスト URL に設定されたクエリパラメーターキーが含まれ、かつその値が always の場合、トラフィックはカナリーサービスのエンドポイントにルーティングされます。それ以外の場合、トラフィックは安定版サービスにルーティングされます。
higress.ingress.kubernetes.io/canary-by-query-value と higress.ingress.kubernetes.io/canary-by-query の両方を設定する場合
リクエストの
query parameter keyおよびquery parameter valueが設定値と一致する場合のみ、トラフィックはカナリーサービスにルーティングされます。それ以外の場合、トラフィックは安定版サービスにルーティングされます。説明ヘッダーによるカナリーリリースとクエリパラメーターによるカナリーリリースを併用できます。両方の条件が満たされた場合にのみ、トラフィックはカナリーサービスにルーティングされます。
例:
リクエスト URL にクエリパラメーター
canary: grayが含まれる場合、リクエストは `demo-service-canary` カナリーサービスにアクセスします。それ以外の場合、`demo-service` 安定版サービスにアクセスします。以下のように設定します:Kubernetes バージョン 1.19 以降のクラスター
apiVersion:networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/canary: "true" higress.ingress.kubernetes.io/canary-by-query: "canary" higress.ingress.kubernetes.io/canary-by-query-value: "gray" name: demo-canary spec: ingressClassName: apig rules: - http: paths: - backend: service: name: demo-service-canary port: number: 80 path: /hello pathType: Exact --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo spec: ingressClassName: apig rules: - http: paths: - backend: service: name: demo-service port: number: 80 path: /hello pathType: ExactKubernetes バージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/canary: "true" higress.ingress.kubernetes.io/canary-by-query: "canary" higress.ingress.kubernetes.io/canary-by-query-value: "gray" name: demo-canary spec: ingressClassName: apig rules: - http: paths: - path: /hello backend: serviceName: demo-service-canary servicePort: 80 --- apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: demo spec: ingressClassName: apig rules: - http: paths: - path: /hello backend: serviceName: demo-service servicePort: 80リクエスト URL にクエリパラメーター
canary: grayが含まれ、かつリクエストヘッダーにx-user-id: testが含まれる場合、リクエストは `demo-service-canary` カナリーサービスにアクセスします。それ以外の場合、`demo-service` 安定版サービスにアクセスします。以下のように設定します:Kubernetes バージョン 1.19 以降のクラスター
apiVersion:networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/canary: "true" higress.ingress.kubernetes.io/canary-by-query: "canary" higress.ingress.kubernetes.io/canary-by-query-value: "gray" nginx.ingress.kubernetes.io/canary-by-header: "x-user-id" nginx.ingress.kubernetes.io/canary-by-header-value: "test" name: demo-canary spec: ingressClassName: apig rules: - http: paths: - backend: service: name: demo-service-canary port: number: 80 path: /hello pathType: Exact --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo spec: ingressClassName: apig rules: - http: paths: - backend: service: name: demo-service port: number: 80 path: /hello pathType: ExactKubernetes バージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/canary: "true" higress.ingress.kubernetes.io/canary-by-query: "canary" higress.ingress.kubernetes.io/canary-by-query-value: "gray" nginx.ingress.kubernetes.io/canary-by-header: "x-user-id" nginx.ingress.kubernetes.io/canary-by-header-value: "test" name: demo-canary spec: ingressClassName: apig rules: - http: paths: - path: /hello backend: serviceName: demo-service-canary servicePort: 80 --- apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: demo spec: ingressClassName: apig rules: - http: paths: - path: /hello backend: serviceName: demo-service servicePort: 80
Cookie によるカナリーリリース
nginx.ingress.kubernetes.io/canary-by-cookie:トラフィックは Cookie に基づいて分割されます。設定された cookie の値が always の場合、トラフィックはカナリーサービスにルーティングされます。それ以外の場合、トラフィックは安定版サービスにルーティングされます。
Cookie によるカナリーリリースではカスタム値はサポートされていません。設定された cookie の値は必ず always でなければなりません。
例として、リクエスト Cookie が demo=always の場合、リクエストは `demo-service-canary` カナリーサービスにアクセスします。それ以外の場合、`demo-service` 安定版サービスにアクセスします。以下のように設定します:
Kubernetes バージョン 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-cookie: "demo"
name: demo-canary
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service-canary
port:
number: 80
path: /hello
pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /hello
pathType: ExactKubernetes バージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-cookie: "demo"
name: demo-canary
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service-canary
servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service
servicePort: 80重みによるカナリーリリース
アノテーション | 説明 |
nginx.ingress.kubernetes.io/canary-weight | 指定されたサービスにルーティングされるリクエストの割合(0~100 の整数)を設定します。 |
nginx.ingress.kubernetes.io/canary-weight-total | 合計重みを設定します。デフォルト値は 100 です。 |
例として、`demo-service-canary-v1` カナリーサービスに 30 % の重み、`demo-service-canary-v2` カナリーサービスに 20 % の重み、`demo-service` 安定版サービスに 50 % の重みを割り当てます。以下のように設定します:
Kubernetes バージョン 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "30"
name: demo-canary-v1
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service-canary-v1
port:
number: 80
path: /hello
pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "20"
name: demo-canary-v2
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service-canary-v2
port:
number: 80
path: /hello
pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /hello
pathType: ExactKubernetes バージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "30"
name: demo-canary-v1
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service-canary-v1
servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "20"
name: demo-canary-v2
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service-canary-v2
servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service
servicePort: 80サービスサブセット
サービスサブセットは、Service が複数の Deployment に関連付けられている場合に適用されます。Ingress は、その Service の下にある Pod のサブセットにリクエストを転送します。通常、これは特定のラベルを持つ Service 内の Pod にリクエストを転送することを意味します。この設定は以下の 2 通りの方法で行えます:
APIG Ingress で定義された Pod ラベルを使用する
アノテーション higress.ingress.kubernetes.io/service-subset を使用して、Service バージョンを設定できます。デフォルトでは、APIG Ingress は、`opensergo.io/canary` というプレフィックスが付いた Pod ラベルに、設定されたサービスバージョンを関連付けます。このアノテーションは、以下を指定します。
""またはbaseとして設定した場合、opensergo.io/canary: ""のラベルを持つ Pod、またはopensergo.io/canaryで始まるキープレフィックスを持つラベルを持たない Pod にリクエストが転送されます。これには空のラベルやラベルがない Pod も含まれます。その他の値で設定した場合、
grayなどと設定すると、opensergo.io/canary-gray: grayのラベルを持つ Pod にリクエストが転送されます。
例として、Kubernetes Service の名前が `go-httpbin` であり、2 つの Deployment に関連付けられているとします。1 つ目の Deployment は、opensergo.io/canary で始まるキープレフィックスを持つラベルを持たない Pod を管理します。2 つ目の Deployment は、opensergo.io/canary-gray: gray のカナリーラベルを持つ Pod を管理します。以下のように設定します:
# go-httpbin k8s service
apiVersion: v1
kind: Service
metadata:
name: go-httpbin
namespace: default
spec:
ports:
- port: 8080
protocol: TCP
selector:
app: go-httpbin
---
# go-httpbin base deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-httpbin-base
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: go-httpbin
template:
metadata:
labels:
app: go-httpbin
spec:
containers:
- image: registry.cn-hangzhou.aliyuncs.com/apig/go-httpbin
args:
- "--version=base"
imagePullPolicy: Always
name: go-httpbin
---
# go-httpbin gray deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-httpbin-gray
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: go-httpbin
template:
metadata:
labels:
app: go-httpbin
opensergo.io/canary-gray: gray
spec:
containers:
- image: registry.cn-hangzhou.aliyuncs.com/apig/go-httpbin
args:
- "--version=gray"
imagePullPolicy: Always
name: go-httpbinリクエストヘッダーに x-user-id: test が含まれる場合に go-httpbin-gray に、それ以外の場合に go-httpbin-base にリクエストを転送するには、以下のように設定します:
Kubernetes バージョン 1.19 以降のクラスター
apiVersion:networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "x-user-id"
nginx.ingress.kubernetes.io/canary-by-header-value: "test"
# opensergo.io/canary-gray: gray のカナリーラベルを持つ Pod にリクエストを転送
higress.ingress.kubernetes.io/service-subset: gray
name: demo-canary
namespace: default
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: go-httpbin
port:
number: 8080
path: /test
pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
# opensergo.io/canary で始まるキープレフィックスを持つラベルを持たない Pod にリクエストを転送
higress.ingress.kubernetes.io/service-subset: ""
name: demo
namespace: default
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: go-httpbin
port:
number: 8080
path: /test
pathType: Exact Kubernetes バージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "x-user-id"
nginx.ingress.kubernetes.io/canary-by-header-value: "test"
# opensergo.io/canary-gray: gray のカナリーラベルを持つ Pod にリクエストを転送
higress.ingress.kubernetes.io/service-subset: gray
name: demo-canary
namespace: default
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /test
backend:
# Service を go-httpbin として設定し、アノテーションでバージョンを指定
serviceName: go-httpbin
servicePort: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
# opensergo.io/canary で始まるキープレフィックスを持つラベルを持たない Pod にリクエストを転送
higress.ingress.kubernetes.io/service-subset: ""
name: demo
namespace: default
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /test
backend:
# Service を go-httpbin として設定し、アノテーションでバージョンを指定
serviceName: go-httpbin
servicePort: 8080カスタムラベルを使用する
サービスサブセットの Pod をカスタムラベルで定義するには、higress.ingress.kubernetes.io/service-subset および higress.ingress.kubernetes.io/subset-labels の両方のアノテーションを設定します。
このサブセットは、opensergo.io/canary で始まるラベルとは関連付けられません。
例として、Kubernetes Service の名前が go-httpbin であり、2 つの Deployment に関連付けられているとします。1 つ目の Deployment は、opensergo.io/canary で始まるキープレフィックスを持つラベルを持たない Pod を管理します。2 つ目の Deployment は、version: gray のカナリーラベルを持つ Pod を管理します。以下のように設定します:
# go-httpbin k8s service
apiVersion: v1
kind: Service
metadata:
name: go-httpbin
namespace: default
spec:
ports:
- port: 8080
protocol: TCP
selector:
app: go-httpbin
---
# go-httpbin base deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-httpbin-base
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: go-httpbin
template:
metadata:
labels:
app: go-httpbin
spec:
containers:
- image: registry.cn-hangzhou.aliyuncs.com/apig/go-httpbin
args:
- "--version=base"
imagePullPolicy: Always
name: go-httpbin
---
# go-httpbin base gray
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-httpbin-gray
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: go-httpbin
template:
metadata:
labels:
app: go-httpbin
version: gray
spec:
containers:
- image: registry.cn-hangzhou.aliyuncs.com/apig/go-httpbin
args:
- "--version=gray"
imagePullPolicy: Always
name: go-httpbinリクエストヘッダーに x-user-id: test が含まれる場合に go-httpbin-gray に、それ以外の場合に go-httpbin-base にリクエストを転送するには、以下のように設定します:
Kubernetes バージョン 1.19 以降のクラスター
apiVersion:networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "x-user-id"
nginx.ingress.kubernetes.io/canary-by-header-value: "test"
# version: gray のカナリーラベルを持つ Pod にリクエストを転送
higress.ingress.kubernetes.io/service-subset: gray
higress.ingress.kubernetes.io/subset-labels: version gray
name: demo-canary
namespace: default
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: go-httpbin
port:
number: 8080
path: /test
pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
# opensergo.io/canary で始まるキープレフィックスを持つラベルを持たない Pod にリクエストを転送
higress.ingress.kubernetes.io/service-subset: ""
name: demo
namespace: default
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: go-httpbin
port:
number: 8080
path: /test
pathType: Exact Kubernetes バージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "x-user-id"
nginx.ingress.kubernetes.io/canary-by-header-value: "test"
# version: gray のカナリーラベルを持つ Pod にリクエストを転送
higress.ingress.kubernetes.io/service-subset: gray
higress.ingress.kubernetes.io/subset-labels: version gray
name: demo-canary
namespace: default
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /test
backend:
# Service を go-httpbin として設定し、アノテーションでバージョンを指定
serviceName: go-httpbin
servicePort: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
# opensergo.io/canary で始まるキープレフィックスを持つラベルを持たない Pod にリクエストを転送
higress.ingress.kubernetes.io/service-subset: ""
name: demo
namespace: default
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /test
backend:
# Service を go-httpbin として設定し、アノテーションでバージョンを指定
serviceName: go-httpbin
servicePort: 8080クロスドメイン
クロスオリジンリソース共有(CORS)により、Web アプリケーションサーバはクロスドメインアクセスを制御し、ドメイン間での安全なデータ転送を確保できます。詳細については、「クロスオリジンリソース共有(CORS)」をご参照ください。
アノテーション | 説明 |
nginx.ingress.kubernetes.io/enable-cors | CORS を有効化または無効化します。 |
nginx.ingress.kubernetes.io/cors-allow-origin | リソースへのアクセスを許可するオリジンを指定します。複数のオリジンをカンマで区切って指定できます。ワイルドカード文字 (*) を使用できます。デフォルト値は * であり、すべてのオリジンを許可します。 |
nginx.ingress.kubernetes.io/cors-allow-methods | 許可するリクエストメソッドを指定します(例:GET、POST、PUT)。複数のメソッドをカンマで区切って指定できます。ワイルドカード文字 (*) を使用できます。デフォルト値は GET、PUT、POST、DELETE、PATCH、OPTIONS です。 |
nginx.ingress.kubernetes.io/cors-allow-headers | 許可するリクエストヘッダーを指定します。複数のヘッダーをカンマで区切って指定できます。ワイルドカード文字 (*) を使用できます。デフォルト値は DNT、X-CustomHeader、Keep-Alive、User-Agent、X-Requested-With、If-Modified-Since、Cache-Control、Content-Type、Authorization です。 |
nginx.ingress.kubernetes.io/cors-expose-headers | ブラウザに公開できるレスポンスヘッダーを指定します。複数のヘッダーをカンマで区切って指定できます。 |
nginx.ingress.kubernetes.io/cors-allow-credentials | ブラウザがリクエストとともに資格情報を送信できるかどうかを指定します。デフォルト値は true です。 |
nginx.ingress.kubernetes.io/cors-max-age | プリフライトリクエストの結果をキャッシュできる最大時間(秒)を指定します。デフォルト値は 1728000 です。 |
例として、クロスドメインリクエストを example.com ドメインに制限し、GET および POST メソッドのみを許可し、X-Foo-Bar リクエストヘッダーを許可し、資格情報の送信を禁止するには、以下の構成を使用します:
Kubernetes バージョン 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/enable-cors: "true"
nginx.ingress.kubernetes.io/cors-allow-origin: "example.com"
nginx.ingress.kubernetes.io/cors-allow-methods: "GET,POST"
nginx.ingress.kubernetes.io/cors-allow-headers: "X-Foo-Bar"
nginx.ingress.kubernetes.io/cors-allow-credentials: "false"
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /hello
pathType: ExactKubernetes バージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/enable-cors: "true"
nginx.ingress.kubernetes.io/cors-allow-origin: "example.com"
nginx.ingress.kubernetes.io/cors-allow-methods: "GET,POST"
nginx.ingress.kubernetes.io/cors-allow-headers: "X-Foo-Bar"
nginx.ingress.kubernetes.io/cors-allow-credentials: "false"
name: demo
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service
servicePort: 80正規表現によるマッチ
標準の Kubernetes Ingress では完全一致およびプレフィックス一致のみをサポートしていますが、APIG Ingress では正規表現によるマッチも追加でサポートしています。Ingress スペックで定義されたパスに対して正規表現マッチを有効化するには、アノテーション nginx.ingress.kubernetes.io/use-regex: true を追加します。
例として、ドメイン名が example.com で、パスが /app または /test で始まるリクエストを demo サービスに転送するには、以下の構成を使用します:
Kubernetes 1.19 以降を実行するクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/use-regex: 'true'
name: regex-match
namespace: default
spec:
ingressClassName: apig
rules:
- http:
paths:
- backend:
service:
name: demo
port:
number: 8080
path: /(app|test)/(.*)
pathType: PrefixKubernetes 1.19 より前のバージョンを実行するクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/use-regex: 'true'
name: regex-match
namespace: default
spec:
ingressClassName: apig
rules:
- http:
paths:
- path: /(app|test)/(.*)
backend:
serviceName: demo
servicePort: 8080パスおよびホストの再書き込み
ターゲットバックエンドサービスにリクエストを転送する前に、再書き込みにより元のリクエストのパスおよびホストドメインを変更します。
アノテーション | 説明 |
nginx.ingress.kubernetes.io/rewrite-target | パスの再書き込み。キャプチャグループをサポートします。 |
nginx.ingress.kubernetes.io/upstream-vhost | ホストの再書き込み。 |
パスの再書き込み
リクエスト example.com/test をバックエンドサービスに転送する前に、example.com/dev に再書き込みします。以下のように設定します:
Kubernetes 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/rewrite-target: "/dev" name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /test pathType: ExactKubernetes 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/rewrite-target: "/dev" name: demo spec: ingressClassName: apig rules: - http: paths: - path: /test pathType: Exact backend: serviceName: demo-service servicePort: 80/v1/ で始まるプレフィックスを持つリクエスト(例:example.com/v1/xxx)をバックエンドサービスに転送する前に、パスプレフィックス /v1 を削除し、example.com/xxx に再書き込みします。以下のように設定します:
Kubernetes 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/rewrite-target: "/$1" name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /v1/(.*) pathType: PrefixKubernetes 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/rewrite-target: "/$1" name: demo spec: ingressClassName: apig rules: - http: paths: - path: /v1/(.*) pathType: Prefix backend: serviceName: demo-service servicePort: 80/v1/ で始まるプレフィックスを持つリクエスト(例:example.com/v1/xxx)をバックエンドサービスに転送する前に、パスプレフィックス /v1 を /v2 に変更し、example.com/v2/xxx に再書き込みします。以下のように設定します:
Kubernetes 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/rewrite-target: "/v2/$1" name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /v1/(.*) pathType: PrefixKubernetes 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/rewrite-target: "/v2/$1" name: demo spec: ingressClassName: apig rules: - http: paths: - path: /v1/(.*) pathType: Prefix backend: serviceName: demo-service servicePort: 80
ホストの再書き込み
例として、リクエスト example.com/test をバックエンドサービスに転送する前に、test.com/test に再書き込みします。以下のように設定します:
Kubernetes 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/upstream-vhost: "test.com"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactKubernetes 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/upstream-vhost: "test.com"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80リダイレクト
リダイレクトにより、クライアントからの元のリクエストがターゲットリクエストに変更されます。
HTTP から HTTPS へのリダイレクトの設定
アノテーション | 説明 |
nginx.ingress.kubernetes.io/ssl-redirect | HTTP を HTTPS にリダイレクトします。 |
nginx.ingress.kubernetes.io/force-ssl-redirect | HTTP を HTTPS にリダイレクトします。 |
APIG Ingress では、両方のアノテーションを同一視し、HTTP のリダイレクトを強制的に HTTPS へ行います。
例として、http://example.com/test を https://example.com/test にリダイレクトするには、以下のように設定します:
バージョン 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "true"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: Exactバージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "true"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80恒久的なリダイレクト
アノテーション | 説明 |
nginx.ingress.kubernetes.io/permanent-redirect | 恒久的なリダイレクトのターゲット URL を指定します。スキーム(HTTP または HTTPS)を含める必要があります。 |
nginx.ingress.kubernetes.io/permanent-redirect-code | 恒久的なリダイレクトの HTTP ステータスコードを指定します。デフォルト値は 301 です。 |
例として、http://example.com/test を http://example.com/app に恒久的にリダイレクトするには、以下のように設定します:
バージョン 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/permanent-redirect: "http://example.com/app"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: Exactバージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/permanent-redirect: "http://example.com/app"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80一時的なリダイレクト
nginx.ingress.kubernetes.io/temporal-redirect:一時的なリダイレクトのターゲット URL を指定します。スキーム(HTTP または HTTPS)を含める必要があります。
例として、http://example.com/test を http://example.com/app に一時的にリダイレクトするには、以下のように設定します:
バージョン 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/temporal-redirect: "http://example.com/app"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: Exactバージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/temporal-redirect: "http://example.com/app"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80ヘッダー制御
ヘッダー制御により、バックエンドサービスにリクエストを転送する前に、リクエストヘッダーを追加、削除、または変更できます。また、クライアントにレスポンスを転送する前に、レスポンスヘッダーを追加、削除、または変更することもできます。
リクエストヘッダー制御
アノテーション | 説明 |
higress.ingress.kubernetes.io/request-header-control-add | バックエンドサービスにリクエストを転送する前に、指定されたヘッダーをリクエストに追加します。ヘッダーが既に存在する場合は、既存の値に新しい値を追加します。構文:
|
higress.ingress.kubernetes.io/request-header-control-update | バックエンドサービスにリクエストを転送する前に、指定されたヘッダーをリクエストで更新します。ヘッダーが既に存在する場合は、その値を上書きします。構文:
|
higress.ingress.kubernetes.io/request-header-control-remove | バックエンドサービスにリクエストを転送する前に、指定されたヘッダーをリクエストから削除します。構文:
|
例:
example.com/test に対するリクエストに、2 つのヘッダー(foo: bar、test: true)を追加します。以下のように設定します:
Kubernetes 1.19 以降を実行するクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: higress.ingress.kubernetes.io/request-header-control-add: | foo bar test true name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /test pathType: ExactKubernetes 1.19 より前のバージョンを実行するクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: higress.ingress.kubernetes.io/request-header-control-add: | foo bar test true name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - path: /test backend: serviceName: demo-service servicePort: 80カナリーリリースとヘッダー制御を組み合わせて、カナリー通信をタグ付けします。リクエストヘッダー apig: v1 が存在する場合、トラフィックをカナリーサービス demo-service-canary-v1 にルーティングし、ヘッダー stage: gray を追加します。それ以外のすべてのリクエストでは、トラフィックを本番サービス demo-service にルーティングし、ヘッダー stage: production を追加します。以下のように設定します:
Kubernetes 1.19 以降を実行するクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-by-header: "apig" nginx.ingress.kubernetes.io/canary-by-header-value: "v1" higress.ingress.kubernetes.io/request-header-control-add: "stage gray" name: demo-canary-v1 spec: ingressClassName: apig rules: - http: paths: - backend: service: name: demo-service-canary-v1 port: number: 80 path: /hello pathType: Exact --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: higress.ingress.kubernetes.io/request-header-control-add: "stage production" name: demo spec: ingressClassName: apig rules: - http: paths: - backend: service: name: demo-service port: number: 80 path: /hello pathType: ExactKubernetes 1.19 より前のバージョンを実行するクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-by-header: "apig" nginx.ingress.kubernetes.io/canary-by-header-value: "v1" higress.ingress.kubernetes.io/request-header-control-add: "stage gray" name: demo-canary-v1 spec: ingressClassName: apig rules: - http: paths: - path: /hello backend: serviceName: demo-service-canary-v1 servicePort: 80 --- apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: higress.ingress.kubernetes.io/request-header-control-add: | foo bar test true name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - path: /hello backend: serviceName: demo-service servicePort: 80
レスポンスヘッダー制御
アノテーション | 説明 |
higress.ingress.kubernetes.io/response-header-control-add | クライアントにレスポンスを転送する前に、指定されたヘッダーをレスポンスに追加します。ヘッダーが既に存在する場合は、既存の値に新しい値を追加します。構文:
|
higress.ingress.kubernetes.io/response-header-control-update | クライアントにレスポンスを転送する前に、指定されたヘッダーをレスポンスで更新します。ヘッダーが既に存在する場合は、その値を上書きします。構文:
|
higress.ingress.kubernetes.io/response-header-control-remove | クライアントにレスポンスを転送する前に、指定されたヘッダーをレスポンスから削除します。構文:
|
例として、example.com/test に対するリクエストのレスポンスから req-cost-time ヘッダーを削除するには、以下のように設定します:
Kubernetes 1.19 以降を実行するクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/response-header-control-remove: "req-cost-time"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactKubernetes 1.19 より前のバージョンを実行するクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/response-header-control-remove: "req-cost-time"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80リトライ
APIG Ingress はルーティングレベルのリトライ設定を提供し、失敗したリクエストを自動的に再試行します。接続確立の失敗、バックエンドサービスの利用不可、特定の HTTP ステータスコードを返すレスポンスなどの条件に応じて、必要に応じてリトライ条件を設定できます。
アノテーション | 説明 |
nginx.ingress.kubernetes.io/proxy-next-upstream-tries | リクエストの最大再試行回数を指定します。デフォルト値は 3 です。 |
nginx.ingress.kubernetes.io/proxy-next-upstream-timeout | リクエストの再試行タイムアウト(秒)を指定します。デフォルトではタイムアウトは設定されません。 |
nginx.ingress.kubernetes.io/proxy-next-upstream | リクエストの再試行条件をカンマで区切って指定します。デフォルト値は
|
例として、example/test リクエストの最大再試行回数を 2 回、再試行タイムアウトを 5 秒、HTTP ステータスコード 502 のみを対象とした再試行、および非等冪リクエストの再試行を有効化するには、以下のように設定します:
Kubernetes 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/proxy-next-upstream-tries: "2"
nginx.ingress.kubernetes.io/proxy-next-upstream-timeout: "5"
nginx.ingress.kubernetes.io/proxy-next-upstream: "http_502,non_idempotent"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactKubernetes 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/proxy-next-upstream-tries: "2"
nginx.ingress.kubernetes.io/proxy-next-upstream-timeout: "5"
nginx.ingress.kubernetes.io/proxy-next-upstream: "http_502,non_idempotent"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80IP ブラックリストおよびホワイトリストによるアクセス制御
APIG Ingress は、ドメインおよびルートレベルでの IP ブラックリストおよびホワイトリストによるアクセス制御をサポートします。ルートレベルのアクセス制御は、ドメインレベルのアクセス制御よりも優先されます。
ルートレベルの IP アクセス制御
アノテーション | 説明 |
nginx.ingress.kubernetes.io/whitelist-source-range | ルートの IP ホワイトリストを指定します。IP アドレスまたは Classless Inter-Domain Routing (CIDR) ブロックをサポートします。複数のエントリをカンマで区切ります。 |
higress.ingress.kubernetes.io/blacklist-source-range | ルートの IP ブラックリストを指定します。IP アドレスまたは CIDR ブロックをサポートします。複数のエントリをカンマで区切ります。 |
例:
クライアント IP アドレス 1.1.X.X のみからの example.com/test へのアクセスを許可するには、以下の構成を使用します:
バージョン 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/whitelist-source-range: 1.1.X.X name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /test pathType: Exactバージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/whitelist-source-range: 1.1.X.X name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - path: /test backend: serviceName: demo-service servicePort: 80クライアント IP アドレス 2.2.2.2 からの example.com/test へのアクセスを拒否するには、以下の構成を使用します:
バージョン 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: higress.ingress.kubernetes.io/blacklist-source-range: 2.2.2.2 name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /test pathType: Exactバージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: higress.ingress.kubernetes.io/blacklist-source-range: 2.2.2.2 name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - path: /test backend: serviceName: demo-service servicePort: 80
ドメインレベルの IP アクセス制御
アノテーション | 説明 |
higress.ingress.kubernetes.io/domain-whitelist-source-range | ドメイン名の IP ホワイトリストを指定します。ドメインレベルの設定は、ルートレベルの設定よりも優先度が低くなります。IP アドレスまたは CIDR ブロックをサポートします。IP アドレスをカンマで区切ります。 |
higress.ingress.kubernetes.io/domain-blacklist-source-range | ドメイン名の IP ブラックリストを指定します。ドメインレベルの設定は、ルートレベルの設定よりも優先度が低くなります。IP アドレスまたは CIDR ブロックをサポートします。IP アドレスをカンマで区切ります。 |
例:
example.com ドメイン名のすべてのルートへのアクセスを、クライアント IP アドレス 1.1.X.X および 2.2.2.2 のみから許可するには、以下の構成を使用します:
バージョン 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: higress.ingress.kubernetes.io/domain-whitelist-source-range: 1.1.X.X,2.2.2.2 name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /test pathType: Exact - backend: service: name: app-service port: number: 80 path: /app pathType: Exactバージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: higress.ingress.kubernetes.io/domain-whitelist-source-range: 1.1.X.X,2.2.2.2 name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - path: /test backend: serviceName: demo-service servicePort: 80 - path: /app backend: serviceName: app-service servicePort: 80ドメインレベルおよびルートレベルの IP アクセス制御を組み合わせます。例として、クライアント IP アドレス 1.1.X.X および 2.2.2.2 からの example.com ドメインのすべてのルートへのアクセスを許可し、クライアント IP アドレス 3.3.X.X からのみ example.com/order ルートへのアクセスを許可するには、以下の構成を使用します:
バージョン 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: higress.ingress.kubernetes.io/domain-whitelist-source-range: 1.1.X.X,2.2.2.2 name: demo-domain spec: ingressClassName: apig rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /test pathType: Exact - backend: service: name: app-service port: number: 80 path: /app pathType: Exact --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/whitelist-source-range: 3.3.X.X name: demo-route spec: ingressClassName: apig rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /order pathType: Exactバージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: higress.ingress.kubernetes.io/domain-whitelist-source-range: 1.1.X.X,2.2.2.2 name: demo-domain spec: ingressClassName: apig rules: - host: example.com http: paths: - path: /test backend: serviceName: demo-service servicePort: 80 - path: /app backend: serviceName: app-service servicePort: 80 --- apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/whitelist-source-range: 3.3.X.X name: demo-route spec: ingressClassName: apig rules: - host: example.com http: paths: - path: /order backend: serviceName: demo-service servicePort: 80
インスタンス単位のレート制限
APIG Ingress は、ルーティングレベルでのインスタンス単位のレート制限をサポートします。指定された期間内に、各ゲートウェイレプリカ上で指定されたルートに一致するリクエスト数を、設定されたしきい値を超えないように制限します。
このレート制限はインスタンス単位で適用されます。設定されたしきい値は、各ゲートウェイインスタンスで個別に適用されます。ゲートウェイクラスター全体でルートのトラフィックを制限するには、グローバルレート制限を使用してください。
アノテーション | 説明 |
higress.ingress.kubernetes.io/route-limit-rpm | 各ゲートウェイインスタンスにおけるこのルートの 1 分あたりの最大リクエスト数を指定します。最大バーストリクエスト数は、この値に limit-burst-multiplier を乗算した値となります。 レート制限がトリガーされた場合、レスポンス本文には
|
higress.ingress.kubernetes.io/route-limit-rps | 各ゲートウェイインスタンスにおけるこのルートの 1 秒あたりの最大リクエスト数を指定します。最大バーストリクエスト数は、この値に limit-burst-multiplier を乗算した値となります。 レート制限がトリガーされた場合、レスポンス本文には
|
higress.ingress.kubernetes.io/route-limit-burst-multiplier | 最大バーストリクエスト数のバースト乗数を指定します。デフォルト値は 5 です。 |
例:
example.com/test へのリクエストを 1 分あたり 100 件に制限し、バースト容量を 200 件に設定します。以下のように設定します:
Kubernetes 1.19 以降を実行するクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: higress.ingress.kubernetes.io/route-limit-rpm: "100" higress.ingress.kubernetes.io/route-limit-burst-multiplier: "2" name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /test pathType: ExactKubernetes 1.19 より前のバージョンを実行するクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: higress.ingress.kubernetes.io/route-limit-rpm: "100" higress.ingress.kubernetes.io/route-limit-burst-multiplier: "2" name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - path: /test backend: serviceName: demo-service servicePort: 80example.com/test へのリクエストを 1 秒あたり 10 件に制限し、バースト容量を 50 件に設定します。以下のように設定します:
Kubernetes 1.19 以降を実行するクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: higress.ingress.kubernetes.io/route-limit-rps: "10" # デフォルト値は 5 # higress.ingress.kubernetes.io/route-limit-burst-multiplier: "5" name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /test pathType: ExactKubernetes 1.19 より前のバージョンを実行するクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: higress.ingress.kubernetes.io/route-limit-rps: "10" # デフォルト値は 5 # higress.ingress.kubernetes.io/route-limit-burst-multiplier: "5" name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - path: /test backend: serviceName: demo-service servicePort: 80
グローバルレート制限制御
APIG Ingress は Sentinel と統合し、ゲートウェイクラスター全体でルートレベルのグローバルレート制限を提供します。この機能により、ルートの 1 秒あたりの最大リクエスト数をクラスター全体で制限できます。
この機能は、APIG Ingress ゲートウェイのバージョン 1.2.25 以降が必要です。
higress.ingress.kubernetes.io/rate-limit アノテーションを使用して、ゲートウェイクラスター全体でルートの 1 秒あたりの最大リクエスト数を設定できます。レート制限がトリガーされた場合、デフォルトの動作は、ステータスコード 429 およびレスポンス本文「sentinel rate limited」を含むレスポンスを返すことです。APIG Ingress では、この動作をカスタマイズするための 2 つの方法(カスタムレスポンスおよびリダイレクト)を提供しています。これらのオプションは、いずれか 1 つだけ使用できます。
カスタムレスポンス
higress.ingress.kubernetes.io/rate-limit-fallback-custom-response-code:レート制限がトリガーされた場合のレスポンスステータスコードを指定します。デフォルト値は 429 です。higress.ingress.kubernetes.io/rate-limit-fallback-custom-response-body-type:レート制限がトリガーされた場合のレスポンス本文の形式を指定します。デフォルト値はtextです。textとして設定した場合、レスポンスの Content-Type 値はtext/plain; charset=UTF-8となります。jsonとして設定した場合、レスポンスの Content-Type ヘッダーの値はapplication/json; charset=UTF-8となります。
higress.ingress.kubernetes.io/rate-limit-fallback-custom-response-body:レート制限がトリガーされた場合のレスポンス本文を指定します。デフォルト値はsentinel rate limitedです。
例 1:以下の構成は、ゲートウェイクラスター全体で example.com/test へのリクエストを 1 秒あたり 100 件に制限し、デフォルトのレート制限動作を使用します。
Kubernetes バージョン 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/rate-limit: "100"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactKubernetes バージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/rate-limit: "100"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80例 2:以下の構成は、ゲートウェイクラスター全体で example.com/test へのリクエストを 1 秒あたり 100 件に制限します。レート制限がトリガーされた場合、ゲートウェイはステータスコード 503 と「server is overloaded」というレスポンス本文を返します。
Kubernetes バージョン 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/rate-limit: "100"
higress.ingress.kubernetes.io/rate-limit-fallback-custom-response-code: 503
higress.ingress.kubernetes.io/rate-limit-fallback-custom-response-body: "server is overload"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactKubernetes バージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/rate-limit: "100"
higress.ingress.kubernetes.io/rate-limit-fallback-custom-response-code: 503
higress.ingress.kubernetes.io/rate-limit-fallback-custom-response-body: "server is overload"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80リダイレクト
higress.ingress.kubernetes.io/rate-limit-fallback-redirect-url:レート制限がトリガーされた場合のリダイレクト URL を指定します。
例 1:以下の構成は、ゲートウェイクラスター全体で example.com/test へのリクエストを 1 秒あたり 100 件に制限します。レート制限がトリガーされた場合、リクエストは example.com/fallback にリダイレクトされます。
Kubernetes バージョン 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/rate-limit: "100"
higress.ingress.kubernetes.io/rate-limit-fallback-redirect-url: "example.com/fallback"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactKubernetes バージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/rate-limit: "100"
higress.ingress.kubernetes.io/rate-limit-fallback-redirect-url: "example.com/fallback"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80グローバル同時実行制御
APIG Ingress は Sentinel と統合し、ゲートウェイクラスターのルーティングレベルでグローバル同時実行制御を提供します。これにより、ゲートウェイクラスター全体でルートが処理できる同時リクエストの最大数が制限されます。
この機能には、APIG Ingress ゲートウェイバージョン 1.2.25 以降が必要です。
アノテーション higress.ingress.kubernetes.io/concurrency-limit を使用して、ゲートウェイクラスター全体でのルートの同時リクエストの最大数を設定します。グローバル同時実行制御がトリガーされると、応答状態コードは 429 であり、応答本文は sentinel rate limited です。APIG Ingress は、同時実行制御の動作をカスタマイズするための2つの方法 (カスタム応答とリダイレクト) をサポートしています。これらのオプションのいずれか1つのみを使用できます。
カスタム応答
higress.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-code: 同時実行制御がトリガーされたときに返される HTTP ステータスコード。デフォルトは 429 です。higress.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-body-type: 同時実行制御がトリガーされたときの応答本文の形式。デフォルトはtextです。textに設定されている場合、応答 Content-Type はtext/plain; charset=UTF-8です。jsonに設定されている場合、応答 Content-Type はapplication/json; charset=UTF-8です。
higress.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-body: 同時実行制御がトリガーされたときの応答本文。デフォルトはsentinel rate limitedです。
例 1: ゲートウェイクラスター全体で example.com/test への同時リクエストの最大数を 1000 に制限します。デフォルトの同時実行制御動作を使用します。
Kubernetes 1.19 以降を実行しているクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/concurrency-limit: "1000"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactKubernetes 1.19 以前を実行しているクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/concurrency-limit: "1000"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80例 2: ゲートウェイクラスター全体で example.com/test への同時リクエストの最大数を 1000 に制限します。同時実行制御がトリガーされたときに、状態コード 503 と応答本文 server is overloaded を返します。
Kubernetes 1.19 以降を実行しているクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/concurrency-limit: "1000"
higress.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-code: 503
higress.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-body: "server is overload"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactKubernetes 1.19 以前を実行しているクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/concurrency-limit: "1000"
higress.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-code: 503
higress.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-body: "server is overload"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80リダイレクト
higress.ingress.kubernetes.io/concurrency-limit-fallback-redirect-url: 同時実行制御がトリガーされたときにリダイレクトする URL。
ゲートウェイクラスター全体で example.com/test への同時リクエストの最大数を 1000 に制限します。同時実行制御がトリガーされたときに、example.com/fallback にリダイレクトします。
Kubernetes 1.19 以降を実行しているクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/concurrency-limit: "1000"
higress.ingress.kubernetes.io/concurrency-limit-fallback-redirect-url: "example.com/fallback"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactKubernetes 1.19 以前を実行しているクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/concurrency-limit: "1000"
higress.ingress.kubernetes.io/concurrency-limit-fallback-redirect-url: "example.com/fallback"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80トラフィックミラーリング
トラフィックミラーリングを設定することで、トラフィックを指定されたサービスにコピーできます。この機能は、運用監査やトラフィックテストなどのシナリオで広く利用されます。
higress.ingress.kubernetes.io/mirror-target-service:トラフィックを指定されたミラーサービスにコピーします。サービスのフォーマットは 名前空間/サービス名:ポート です。
名前空間:Kubernetes サービスが存在する名前空間です。省略可能で、デフォルト値は Ingress が存在する名前空間です。
サービス名:Kubernetes サービスの名前です。必須項目です。
ポート:Kubernetes サービスへトラフィックを転送する際のポート番号です。省略可能で、デフォルト値は最初に定義されたポートです。
higress.ingress.kubernetes.io/mirror-percentage:コピー対象とするトラフィックの割合(%)です。設定可能な範囲は 0 ~ 100 です。デフォルト値は 100 です。
コピーされたトラフィックがターゲットサービスに転送される際、元のリクエストの Host ヘッダーには自動的に -shadow サフィックスが追加されます。
たとえば、example.com/test からのトラフィックを、名前空間が test、サービス名が app、ポートが 8080 のターゲットサービスにコピー・転送する場合を示します。
この例では、コピーされたトラフィックがターゲットサービスに転送される際に、Host は自動的に example.com-shadow に書き換えられます。
バージョン 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/mirror-target-service: test/app:8080
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: Exactバージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/mirror-target-service: test/app:8080
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80たとえば、example.com/test からのトラフィックを、名前空間が test、サービス名が app、ポートが 8080、かつコピー割合が 10 % のターゲットサービスにコピー・転送する場合を示します。
この例では、コピーされたトラフィックがターゲットサービスに転送される際に、Host は自動的に example.com-shadow に書き換えられます。
バージョン 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/mirror-target-service: test/app:8080
higress.ingress.kubernetes.io/mirror-percentage: 10
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: Exactバージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/mirror-target-service: test/app:8080
higress.ingress.kubernetes.io/mirror-percentage: 10
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80バックエンドサービスプロトコルの設定:HTTPS または gRPC
デフォルトでは、APIG Ingress は HTTP プロトコルを使用してリクエストをバックエンドアプリケーションコンテナーに転送します。アプリケーションコンテナーが HTTPS プロトコルを使用する場合は、リクエストをバックエンドアプリケーションコンテナーに転送するために、アノテーション nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" を追加します。アプリケーションコンテナーが gRPC サービスを提供する場合は、リクエストをバックエンドアプリケーションコンテナーに転送するために、アノテーション nginx.ingress.kubernetes.io/backend-protocol: "GRPC" を追加します。
NGINX Ingress とは異なり、APIG Ingress では、バックエンドサービスの Kubernetes Service リソースにおけるポート名(Port Name)が grpc または http2 として定義されている場合、自動的に gRPC または HTTP/2 を使用します。この場合、アノテーション nginx.ingress.kubernetes.io/backend-protocol: "GRPC" の設定は不要です。
例:
リクエスト example/test を HTTPS プロトコルでバックエンドサービスに転送します。以下の構成を使用します:
Kubernetes 1.19 以降を実行するクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: / pathType: ExactKubernetes 1.19 より前のバージョンを実行するクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - path: /test backend: serviceName: demo-service servicePort: 80リクエスト example/test を gRPC プロトコルでバックエンドサービスに転送します。以下のいずれかの方法をご利用ください:
方法 1:アノテーションを使用する場合。以下のように構成します:
Kubernetes 1.19 以降を実行するクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/backend-protocol: "GRPC" name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /test pathType: ExactKubernetes 1.19 より前のバージョンを実行するクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/backend-protocol: "GRPC" name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - path: /test backend: serviceName: demo-service servicePort: 80方法 2:Service のポート名(Port Name)を使用する場合。以下のように構成します:
Kubernetes 1.19 以降を実行するクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /order pathType: Exact --- apiVersion: v1 kind: Service metadata: name: demo-service spec: ports: - name: grpc port: 80 protocol: TCP selector: app: demo-serviceKubernetes 1.19 より前のバージョンを実行するクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - path: /test backend: serviceName: demo-service servicePort: 80 --- apiVersion: v1 kind: Service metadata: name: demo-service spec: ports: - name: grpc port: 80 protocol: TCP selector: app: demo-service
バックエンドサービスの負荷分散アルゴリズムの設定
負荷分散は、ゲートウェイがバックエンドサービスにリクエストを転送する際に、ノードを選択する方法を決定します。
標準の負荷分散アルゴリズム
nginx.ingress.kubernetes.io/load-balance: バックエンドサービスの標準の負荷分散アルゴリズムです。デフォルト値は round_robin です。有効な値は次のとおりです:
round_robin: ラウンドロビン負荷分散。
least_conn: 最小接続負荷分散。
random: ランダム負荷分散。
クラウドネイティブゲートウェイは EWMA アルゴリズムをサポートしていません。EWMA を設定した場合、ゲートウェイはラウンドロビンにフォールバックします。
たとえば、バックエンドサービス demo-service の負荷分散アルゴリズムを least_conn に設定します。次のように設定します:
Kubernetes 1.19 以降を実行するクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/load-balance: "least_conn"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /order
pathType: ExactKubernetes 1.19 より前のバージョンを実行するクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/load-balance: "least_conn"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80コンシステントハッシュ負荷分散アルゴリズム
コンシステントハッシュ負荷分散は、リクエストアフィニティを保証します。同じハッシュキーを持つリクエストは、常に同じノードに転送されます。APIG Ingress は、選択された NGINX 変数、リクエストヘッダー、およびリクエストパスパラメーターをハッシュキーとして使用することをサポートしています。
nginx.ingress.kubernetes.io/upstream-hash-by: コンシステントハッシュ負荷分散アルゴリズムです。クラウドネイティブゲートウェイは、次のハッシュキータイプをサポートしています:
クラウドネイティブゲートウェイは、選択された NGINX 変数をサポートしています:
$request_uri: パスパラメーターを含むリクエストパスがハッシュキーとして使用されます。
$host: リクエストホストヘッダーをハッシュキーとして使用します。
$remote_addr: クライアント IP アドレスをハッシュキーとして使用します。
リクエストヘッダーに基づくコンシステントハッシュ。アノテーションを $http_headerName に設定します。
リクエストパスパラメーターに基づくコンシステントハッシュ。アノテーションを $arg_varName に設定します。
例:
クライアント IP アドレスをハッシュキーとして使用します。同じクライアント IP からのリクエストは、常に同じノードに転送されます。次のように設定します:
Kubernetes 1.19 以降を実行するクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/upstream-hash-by: "$remote_addr" name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /test pathType: ExactKubernetes 1.19 より前のバージョンを実行するクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/upstream-hash-by: "$remote_addr" name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - path: /test backend: serviceName: demo-service servicePort: 80x-stage リクエストヘッダーをハッシュキーとして使用します。同じ x-stage ヘッダー値を持つリクエストは、常に同じノードに転送されます。次のように設定します:
Kubernetes 1.19 以降を実行するクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/upstream-hash-by: "$http_x-stage" name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /test pathType: ExactKubernetes 1.19 より前のバージョンを実行するクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/upstream-hash-by: "$http_x-stage" name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - path: /test backend: serviceName: demo-service servicePort: 80x-stage パスパラメーターをハッシュキーとして使用します。同じ x-stage パスパラメーター値を持つリクエストは、常に同じノードに転送されます。次のように設定します:
Kubernetes 1.19 以降を実行するクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/upstream-hash-by: "$arg_x-stage" name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /test pathType: ExactKubernetes 1.19 より前のバージョンを実行するクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/upstream-hash-by: "$arg_x-stage" name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - path: /test backend: serviceName: demo-service servicePort: 80
サービスのウォームアップ(グレースフルな起動)
サービスのウォームアップにより、新規ノードがオンラインになった際に、指定されたラップアップ期間内においてトラフィックを段階的に増加させることができます。これにより、新規ノードが確実にウォームアップを完了することが保証されます。
higress.ingress.kubernetes.io/warmup:サービスのラップアップ期間(単位:秒)。デフォルトでは無効です。
サービスのウォームアップは、選択されたロードバランシングアルゴリズムに依存します。現在、ラウンドロビンおよび least_conn のみがサポートされています。
たとえば、バックエンドサービス demo-service に対して 30 秒のラップアップ期間を設定してウォームアップを有効化する場合は、以下の通り設定します。
Kubernetes 1.19 以降を実行するクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/warmup: "30"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactKubernetes 1.19 より前のバージョンを実行するクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/warmup: "30"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80クッキーアフィニティ (セッション維持)
ゲートウェイによって、同じクッキーを持つリクエストは常に同じノードにルーティングされます。最初のリクエストにクッキーが含まれている場合、APIG Ingress は最初の応答でクッキーを生成します。このクッキーにより、後続のリクエストは常に同じノードにルーティングされることが保証されます。
アノテーション | 説明 |
nginx.ingress.kubernetes.io/affinity | アフィニティのタイプ。サポートされているのはクッキーアフィニティのみです。デフォルト値は `cookie` です。 |
nginx.ingress.kubernetes.io/affinity-mode | アフィニティのモード。クラウドネイティブゲートウェイでは `Balanced` モードのみがサポートされます。デフォルト値は `Balanced` です。 |
nginx.ingress.kubernetes.io/session-cookie-name | 指定したクッキーの値をハッシュキーとして設定します。デフォルトは `INGRESSCOOKIE` です。 |
nginx.ingress.kubernetes.io/session-cookie-path | 指定したクッキーが存在しない場合に生成されるクッキーのパス値です。デフォルト値は `/` です。 |
nginx.ingress.kubernetes.io/session-cookie-max-age | 指定したクッキーが存在しない場合に生成されるクッキーの最大有効期間 (秒) です。デフォルト値はセッションレベルです。 |
nginx.ingress.kubernetes.io/session-cookie-expires | 指定したクッキーが存在しない場合に生成されるクッキーの有効期限 (秒) です。デフォルト値はセッションレベルです。 |
例:
デフォルトの APIG Ingress 構成を使用してクッキーアフィニティを有効にします。クッキー名は INGRESSCOOKIE、クッキーパスは /、クッキーのライフサイクルはセッションレベルです。次のように構成します:
Kubernetes 1.19 以降を実行しているクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/affinity: "cookie" name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /test pathType: ExactKubernetes 1.19 より前のバージョンを実行しているクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/affinity: "cookie" name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - path: /test backend: serviceName: demo-service servicePort: 80クッキー名を test、クッキーパスを /、クッキーの有効期限を 10 秒としてクッキーアフィニティを有効にします。次のように構成します:
Kubernetes 1.19 以降を実行しているクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/affinity: "cookie" nginx.ingress.kubernetes.io/session-cookie-name: "test" nginx.ingress.kubernetes.io/session-cookie-max-age: "10" name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /test pathType: ExactKubernetes 1.19 より前のバージョンを実行しているクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/affinity: "cookie" nginx.ingress.kubernetes.io/session-cookie-name: "test" nginx.ingress.kubernetes.io/session-cookie-max-age: "10" name: demo spec: ingressClassName: apig rules: - host: example.com http: paths: - path: /test backend: serviceName: demo-service servicePort: 80
ゲートウェイとバックエンドサービス間の接続プール構成
ゲートウェイ上の特定サービスについて、接続プールを構成します。この設定は、ゲートウェイとバックエンドサービス間の接続数を制御します。これにより、バックエンドサービスの過負荷を防止し、バックエンドサービスの安定性および高可用性を向上させます。
higress.ingress.kubernetes.io/connection-policy-tcp-max-connection:ゲートウェイとバックエンドサービス間で確立可能な最大接続数です。
higress.ingress.kubernetes.io/connection-policy-tcp-max-connection-per-endpoint:ゲートウェイとバックエンドサービスのシングルノード(1 つのエンドポイント)間で確立可能な最大接続数です。
higress.ingress.kubernetes.io/connection-policy-http-max-request-per-connection:ゲートウェイとバックエンドサービス間の単一接続上で許容される最大リクエスト数です。
たとえば、demo-service バックエンドサービスの構成では、ゲートウェイとバックエンドサービス間で確立可能な最大接続数は 10、またゲートウェイとバックエンドサービスの各シングルノード間で確立可能な最大接続数は 2 となります。
バージョン 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/connection-policy-tcp-max-connection: 10
higress.ingress.kubernetes.io/connection-policy-tcp-max-connection-per-endpoint: 2
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: Exactバージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/connection-policy-tcp-max-connection: 10
higress.ingress.kubernetes.io/connection-policy-tcp-max-connection-per-endpoint: 2
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80クライアントとゲートウェイ間の TLS バージョンと暗号スイートの構成
デフォルトでは、APIG Ingress は最小の Transport Layer Security (TLS) バージョンを TLSv1.0 に、最大の TLS バージョンを TLSv1.3 に設定します。デフォルトの暗号スイートは次のとおりです:
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA
ECDHE-RSA-AES128-SHA
AES128-GCM-SHA256
AES128-SHA
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-SHA
ECDHE-RSA-AES256-SHA
AES256-GCM-SHA384
AES256-SHA
特定のドメイン名に対して最小または最大の TLS バージョンと暗号スイートを設定するには、次のアノテーションを使用します。
アノテーション | 説明 |
higress.ingress.kubernetes.io/tls-min-protocol-version | 最小の TLS バージョンを指定します。デフォルト値は TLSv1.0 です。有効な値は次のとおりです:
|
higress.ingress.kubernetes.io/tls-max-protocol-version | 最大の TLS バージョンを指定します。デフォルト値は TLSv1.3 です。 |
nginx.ingress.kubernetes.io/ssl-cipher | TLS 暗号スイートを指定します。複数のスイートを指定するには、コロン (:) で区切ります。この設定は、TLS バージョン 1.0 から 1.2 を使用する TLS ハンドシェイクにのみ適用されます。 |
たとえば、ドメイン名 example.com の場合、最小および最大の TLS バージョンを TLSv1.2 に設定します。構成は次のとおりです:
バージョン 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/tls-min-protocol-version: "TLSv1.2"
higress.ingress.kubernetes.io/tls-max-protocol-version: "TLSv1.2"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: Exactバージョン 1.19 より前のクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
higress.ingress.kubernetes.io/tls-min-protocol-version: "TLSv1.2"
higress.ingress.kubernetes.io/tls-max-protocol-version: "TLSv1.2"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80ゲートウェイとバックエンドサービスの相互 TLS (mTLS)
デフォルトでは、APIG Ingress は HTTP プロトコル を使用して、バックエンド アプリケーション コンテナー にリクエストを転送します。アノテーション nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" を使用して、APIG Ingress が HTTPS プロトコル を使用して バックエンド サービス にアクセスするように設定できます。ただし、これは 一方向 TLS であり、APIG Ingress は バックエンド サービス によって提供される 証明書 のみを検証することを意味します。バックエンド サービス の 証明書 は通常、信頼された 認証局 (CA) によって発行される必要があります。より安全な パターン は ゼロトラスト であり、ゲートウェイ が バックエンド サービス の 証明書 を検証し、バックエンド サービス が ゲートウェイ の 証明書 を検証します。これは 相互 TLS (mTLS) と呼ばれ、ゲートウェイ と バックエンド サービス が 相互認証 を実行します。
アノテーション | 説明 |
nginx.ingress.kubernetes.io/proxy-ssl-secret | バックエンド サービス による 身分認証 のために ゲートウェイ が使用する クライアント 証明書 。形式: secretNamespace/secretName。 |
nginx.ingress.kubernetes.io/proxy-ssl-name | TLS ハンドシェイク 中に使用される サーバ名表示 (SNI)。 |
nginx.ingress.kubernetes.io/proxy-ssl-server-name | TLS ハンドシェイク 中の SNI を 有効 または 無効 にします。 |
例えば、ゲートウェイ と バックエンド サービス 間で 相互 TLS (mTLS) を 有効 にするには、デフォルト の 名前空間 にある gateway-cert という名前の シークレット を使用します。次のように設定します。
Kubernetes 1.19 以降を実行するクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/proxy-ssl-secret: "default/ateway-cert"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactKubernetes 1.19 以前を実行するクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/proxy-ssl-secret: "default/gateway-cert"
name: demo
spec:
ingressClassName: apig
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80