MSE Ingress assure l'équilibrage de charge de niveau 7 pour gérer l'accès externe aux services d'un cluster Kubernetes. Configurez des fonctionnalités basées sur les annotations dans les ressources Ingress, allant des déploiements canaris et de la limitation de débit à TLS et à la mise en miroir du trafic.
Tous les exemples incluent des configurations pour Kubernetes v1.19+ (networking.k8s.io/v1) et les versions antérieures (networking.k8s.io/v1beta1).
Récapitulatif des annotations
Toutes les annotations présentées dans cette rubrique utilisent le préfixe nginx.ingress.kubernetes.io/ ou mse.ingress.kubernetes.io/. Le tableau ci-dessous répertorie chaque annotation avec ses valeurs acceptées, sa valeur par défaut et son champ d'application.
|
Annotation |
Valeurs acceptées |
Valeur par défaut |
Champ d'application |
|
|
|
— |
Route |
|
|
string |
— |
Route |
|
|
string |
— |
Route |
|
|
string |
— |
Route |
|
|
entier (0–100 ou 0–total) |
— |
Route |
|
|
entier |
|
Route |
|
|
string |
— |
Route |
|
|
string |
— |
Route |
|
|
string |
— |
Route |
|
|
|
— |
Route |
|
|
|
|
Route |
|
|
origines séparées par des virgules ou |
|
Route |
|
|
méthodes HTTP séparées par des virgules ou |
|
Route |
|
|
en-têtes séparés par des virgules ou |
|
Route |
|
|
en-têtes séparés par des virgules |
— |
Route |
|
|
|
|
Route |
|
|
entier (secondes) |
|
Route |
|
|
|
— |
Route |
|
|
chaîne de chemin |
— |
Route |
|
|
nom d'hôte |
— |
Route |
|
|
|
|
Route |
|
|
|
|
Route |
|
|
URL (avec schéma) |
— |
Route |
|
|
code d'état HTTP |
|
Route |
|
|
URL (avec schéma) |
— |
Route |
|
|
|
— |
Route |
|
|
|
— |
Route |
|
|
noms d'en-têtes séparés par des virgules |
— |
Route |
|
|
|
— |
Route |
|
|
|
— |
Route |
|
|
noms d'en-têtes séparés par des virgules |
— |
Route |
|
|
entier |
|
Route |
|
|
entier (secondes) |
aucun délai d'attente |
Route |
|
|
conditions séparées par des virgules |
|
Route |
|
|
adresses IP ou CIDR séparées par des virgules |
— |
Route |
|
|
adresses IP ou CIDR séparées par des virgules |
— |
Route |
|
|
adresses IP ou CIDR séparées par des virgules |
— |
Domaine |
|
|
adresses IP ou CIDR séparées par des virgules |
— |
Domaine |
|
|
entier |
— |
Route |
|
|
entier |
— |
Route |
|
|
entier |
|
Route |
|
|
entier (RPS) |
— |
Route |
|
|
code d'état HTTP |
|
Route |
|
|
|
|
Route |
|
|
string |
|
Route |
|
|
URL |
— |
Route |
|
|
entier |
— |
Route |
|
|
code d'état HTTP |
|
Route |
|
|
|
|
Route |
|
|
string |
|
Route |
|
|
URL |
— |
Route |
|
|
|
— |
Route |
|
|
entier (0–100) |
|
Route |
|
|
|
— |
Route |
|
|
|
|
Route |
|
|
variable ou expression NGINX |
— |
Route |
|
|
entier (secondes) |
désactivé |
Route |
|
|
|
— |
Route |
|
|
|
|
Route |
|
|
string |
|
Route |
|
|
chaîne de chemin |
|
Route |
|
|
entier (secondes) |
limité à la session |
Route |
|
|
entier (secondes) |
limité à la session |
Route |
|
|
entier |
— |
Route |
|
|
entier |
— |
Route |
|
|
entier |
— |
Route |
|
|
|
|
Domaine |
|
|
|
|
Domaine |
|
|
suites de chiffrement séparées par des virgules |
voir les valeurs par défaut |
Domaine |
|
|
|
— |
Route |
|
|
nom d'hôte |
— |
Route |
|
|
|
— |
Route |
Déploiement canari
MSE Ingress prend en charge quatre stratégies de déploiement canari. Pour activer le mode canari sur n'importe quelle ressource Ingress, ajoutez l'annotation nginx.ingress.kubernetes.io/canary: "true". Appliquez ensuite une ou plusieurs des annotations spécifiques à la stratégie décrites ci-dessous.
MSE Ingress permet d'inclure plus de deux versions de service dans un seul déploiement canari, sans limite supérieure. NGINX Ingress et ALB Ingress ne prennent en charge que deux versions au maximum.
Lorsque plusieurs stratégies sont configurées simultanément, MSE Ingress les applique selon l'ordre de priorité suivant :
Basé sur les en-têtes ou les paramètres de requête (priorité la plus élevée)
Basé sur les cookies
Basé sur le poids (priorité la plus faible)
Déploiement canari basé sur les en-têtes
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
Achemine les requêtes vers la version canari lorsque l'en-tête spécifié est présent et défini sur |
— |
Oui (pour le déploiement canari basé sur les en-têtes) |
|
|
Achemine les requêtes vers la version canari uniquement lorsque l'en-tête correspond à la fois à la clé (définie par |
— |
Non |
Exemple 1 : Routage basé sur la présence d'un en-tête
Lorsque l'en-tête de requête mse est défini sur always, les requêtes sont envoyées vers demo-service-canary. Toutes les autres requêtes sont dirigées vers demo-service.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "mse"
name: demo-canary
spec:
ingressClassName: mse
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: mse
rules:
- http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /hello
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "mse"
name: demo-canary
spec:
ingressClassName: mse
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service-canary
servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: mse
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service
servicePort: 80Exemple 2 : Routage de plusieurs versions canari par valeur d'en-tête exacte
Lorsque l'en-tête mse: v1 est présent, les requêtes sont envoyées vers demo-service-canary-v1. Lorsque mse: v2 est présent, elles sont dirigées vers demo-service-canary-v2. Toutes les autres requêtes vont vers demo-service.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "mse"
nginx.ingress.kubernetes.io/canary-by-header-value: "v1"
name: demo-canary-v1
spec:
ingressClassName: mse
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: "mse"
nginx.ingress.kubernetes.io/canary-by-header-value: "v2"
name: demo-canary-v2
spec:
ingressClassName: mse
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: mse
rules:
- http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /hello
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "mse"
nginx.ingress.kubernetes.io/canary-by-header-value: "v1"
name: demo-canary-v1
spec:
ingressClassName: mse
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: "mse"
nginx.ingress.kubernetes.io/canary-by-header-value: "v2"
name: demo-canary-v2
spec:
ingressClassName: mse
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: mse
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service
servicePort: 80Déploiement canari basé sur les paramètres de requête
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
Achemine les requêtes vers la version canari lorsque le paramètre de requête spécifié est présent et défini sur |
— |
Oui (pour le déploiement canari basé sur les requêtes) |
|
|
Achemine les requêtes vers la version canari uniquement lorsque le paramètre de requête correspond à la fois à la clé et à cette valeur. |
— |
Non |
Il est possible de combiner les conditions basées sur les en-têtes et celles basées sur les paramètres de requête. Les requêtes sont envoyées vers la version canari uniquement lorsque les deux conditions sont remplies simultanément.
Exemple 1 : Routage par valeur de paramètre de requête
Lorsque l'URL contient canary=gray, les requêtes sont envoyées vers demo-service-canary. Toutes les autres requêtes sont dirigées vers demo-service.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
mse.ingress.kubernetes.io/canary-by-query: "canary"
mse.ingress.kubernetes.io/canary-by-query-value: "gray"
name: demo-canary
spec:
ingressClassName: mse
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: mse
rules:
- http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /hello
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
mse.ingress.kubernetes.io/canary-by-query: "canary"
mse.ingress.kubernetes.io/canary-by-query-value: "gray"
name: demo-canary
spec:
ingressClassName: mse
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service-canary
servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: mse
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service
servicePort: 80Exemple 2 : Combinaison des paramètres de requête et des conditions d'en-tête
Lorsque l'URL contient canary=gray ET que l'en-tête de requête contient x-user-id: test, les requêtes sont envoyées vers demo-service-canary. Les deux conditions doivent être satisfaites.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
mse.ingress.kubernetes.io/canary-by-query: "canary"
mse.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: mse
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: mse
rules:
- http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /hello
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
mse.ingress.kubernetes.io/canary-by-query: "canary"
mse.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: mse
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service-canary
servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: mse
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service
servicePort: 80Déploiement canari basé sur les cookies
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
Achemine les requêtes vers la version canari lorsque le cookie spécifié est défini sur |
— |
Oui (pour le déploiement canari basé sur les cookies) |
Example: Lorsque le cookie de requête demo=always est présent, les requêtes sont envoyées vers demo-service-canary. Toutes les autres requêtes sont dirigées vers demo-service.
Kubernetes v1.19 et versions ultérieures :
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: mse
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: mse
rules:
- http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /hello
pathType: ExactVersions de Kubernetes antérieures à la v1.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: mse
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service-canary
servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: mse
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service
servicePort: 80Déploiement canari basé sur le poids
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
Pourcentage de requêtes envoyées vers la version canari. Entier compris entre 0 et 100 (ou 0 et |
— |
Oui (pour le déploiement canari basé sur le poids) |
|
|
Poids total utilisé comme dénominateur lors du calcul de la distribution des requêtes. |
|
Non |
Example: Répartissez le trafic sur trois versions : 30 % vers demo-service-canary-v1, 20 % vers demo-service-canary-v2 et 50 % vers demo-service.
Kubernetes v1.19 et versions ultérieures :
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: mse
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: mse
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: mse
rules:
- http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /hello
pathType: ExactVersions de Kubernetes antérieures à la v1.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: mse
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: mse
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: mse
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service
servicePort: 80Sous-ensemble de service
Un sous-ensemble de service vous permet d'acheminer les requêtes vers un groupe spécifique de Pods au sein d'un même Service Kubernetes. Cette fonctionnalité s'avère utile lorsqu'un Service est soutenu par plusieurs Deployments exécutant différentes versions. MSE Ingress propose deux méthodes pour définir ces sous-ensembles.
Utilisation des labels de Pod dans MseIngressConfig
Utilisez l'annotation mse.ingress.kubernetes.io/service-subset pour sélectionner les Pods en fonction de leurs labels canari OpenSergo :
""oubase: achemine vers les Pods sans préfixe de labelopensergo.io/canary, ou avecopensergo.io/canary: "".Toute autre valeur (par exemple,
gray) : achemine vers les Pods portant le labelopensergo.io/canary-{value}: {value}— par exemple,opensergo.io/canary-gray: gray.
Example: Un Service nommé go-httpbin est soutenu par deux Deployments. Les Pods de base ne possèdent aucun label canari OpenSergo. Les Pods gris portent le label opensergo.io/canary-gray: gray.
Manifestes du Service et du Deployment :
# go-httpbin Service
apiVersion: v1
kind: Service
metadata:
name: go-httpbin
namespace: default
spec:
ports:
- port: 8080
protocol: TCP
selector:
app: go-httpbin
---
# Base Deployment — no OpenSergo canary label
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/mse/go-httpbin
args:
- "--version=base"
imagePullPolicy: Always
name: go-httpbin
---
# Gray Deployment — has the OpenSergo canary label
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/mse/go-httpbin
args:
- "--version=gray"
imagePullPolicy: Always
name: go-httpbinConfiguration Ingress — les requêtes contenant x-user-id: test sont envoyées vers go-httpbin-gray ; toutes les autres vont vers go-httpbin-base :
Kubernetes v1.19 et versions ultérieures :
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"
# Forward to Pods labeled opensergo.io/canary-gray: gray
mse.ingress.kubernetes.io/service-subset: gray
name: demo-canary
namespace: default
spec:
ingressClassName: mse
rules:
- http:
paths:
- backend:
service:
name: go-httpbin
port:
number: 8080
path: /test
pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
# Forward to Pods without the opensergo.io/canary label prefix
mse.ingress.kubernetes.io/service-subset: ""
name: demo
namespace: default
spec:
ingressClassName: mse
rules:
- http:
paths:
- backend:
service:
name: go-httpbin
port:
number: 8080
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.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"
# Forward to Pods labeled opensergo.io/canary-gray: gray
mse.ingress.kubernetes.io/service-subset: gray
name: demo-canary
namespace: default
spec:
ingressClassName: mse
rules:
- http:
paths:
- path: /test
backend:
serviceName: go-httpbin
servicePort: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
# Forward to Pods without the opensergo.io/canary label prefix
mse.ingress.kubernetes.io/service-subset: ""
name: demo
namespace: default
spec:
ingressClassName: mse
rules:
- http:
paths:
- path: /test
backend:
serviceName: go-httpbin
servicePort: 8080Utilisation de labels personnalisés
Combinez mse.ingress.kubernetes.io/service-subset avec mse.ingress.kubernetes.io/subset-labels pour définir le sous-ensemble à l'aide de n'importe quel label de Pod, plutôt que du préfixe opensergo.io/canary.
Lorsquesubset-labelsest défini, le sous-ensemble n'est plus mappé aux labels préfixés paropensergo.io/canary.
Example: Le Deployment gris possède version: gray au lieu d'un label OpenSergo.
Manifestes du Service et du Deployment :
# go-httpbin Service
apiVersion: v1
kind: Service
metadata:
name: go-httpbin
namespace: default
spec:
ports:
- port: 8080
protocol: TCP
selector:
app: 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/mse/go-httpbin
args:
- "--version=base"
imagePullPolicy: Always
name: go-httpbin
---
# Gray Deployment — uses a custom label instead of opensergo.io/canary
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/mse/go-httpbin
args:
- "--version=gray"
imagePullPolicy: Always
name: go-httpbinConfiguration Ingress — les requêtes contenant x-user-id: test sont envoyées vers go-httpbin-gray ; toutes les autres vont vers go-httpbin-base :
Kubernetes v1.19 et versions ultérieures :
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"
# Forward to Pods labeled version: gray
mse.ingress.kubernetes.io/service-subset: gray
mse.ingress.kubernetes.io/subset-labels: version gray
name: demo-canary
namespace: default
spec:
ingressClassName: mse
rules:
- http:
paths:
- backend:
service:
name: go-httpbin
port:
number: 8080
path: /test
pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/service-subset: ""
name: demo
namespace: default
spec:
ingressClassName: mse
rules:
- http:
paths:
- backend:
service:
name: go-httpbin
port:
number: 8080
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.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"
# Forward to Pods labeled version: gray
mse.ingress.kubernetes.io/service-subset: gray
mse.ingress.kubernetes.io/subset-labels: version gray
name: demo-canary
namespace: default
spec:
ingressClassName: mse
rules:
- http:
paths:
- path: /test
backend:
serviceName: go-httpbin
servicePort: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/service-subset: ""
name: demo
namespace: default
spec:
ingressClassName: mse
rules:
- http:
paths:
- path: /test
backend:
serviceName: go-httpbin
servicePort: 8080CORS
Le partage de ressources entre origines multiples (CORS) permet aux applications web d'accéder à des ressources hébergées sur une origine différente. Pour consulter la spécification CORS, reportez-vous à la page Partage de ressources entre origines multiples (CORS).
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
Active le CORS pour cet Ingress. |
|
Oui (pour activer le CORS) |
|
|
Origines tierces autorisées. Accepte les valeurs séparées par des virgules et les caractères génériques ( |
|
Non |
|
|
Méthodes HTTP autorisées. Accepte les valeurs séparées par des virgules et les caractères génériques ( |
|
Non |
|
|
En-têtes de requête autorisés. Accepte les valeurs séparées par des virgules et les caractères génériques ( |
|
Non |
|
|
En-têtes de réponse exposés au navigateur. Accepte les valeurs séparées par des virgules. |
— |
Non |
|
|
Indique si les identifiants peuvent être inclus dans les requêtes CORS. |
|
Non |
|
|
Durée de mise en cache des résultats de pré-vol (preflight), en secondes. |
|
Non |
Example: Autorisez example.com comme origine, limitez les méthodes à GET et POST, autorisez l'en-tête de requête X-Foo-Bar et désactivez le transfert des identifiants.
Kubernetes v1.19 et versions ultérieures :
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: mse
rules:
- http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /hello
pathType: ExactVersions de Kubernetes antérieures à la v1.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: mse
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service
servicePort: 80Correspondance par expression régulière
Outre la correspondance exacte et par préfixe, MSE Ingress prend en charge la correspondance par expression régulière. Définissez nginx.ingress.kubernetes.io/use-regex: "true" pour traiter le chemin défini dans la spécification Ingress comme une expression régulière.
Example: Transférez vers le service demo les requêtes adressées à example.com dont les chemins commencent par /app ou /test.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/use-regex: 'true'
name: regex-match
namespace: default
spec:
ingressClassName: mse
rules:
- http:
paths:
- backend:
service:
name: demo
port:
number: 8080
path: /(app|test)/(.*)
pathType: PrefixVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/use-regex: 'true'
name: regex-match
namespace: default
spec:
ingressClassName: mse
rules:
- http:
paths:
- path: /(app|test)/(.*)
backend:
serviceName: demo
servicePort: 8080Réécriture du chemin et de l'hôte
Les opérations de réécriture modifient le chemin ou l'hôte d'une requête avant qu'elle n'atteigne le service backend.
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
Chemin de destination. Prend en charge les groupes de capture issus du modèle de chemin Ingress. |
— |
Oui (pour la réécriture de chemin) |
|
|
Hôte de destination. |
— |
Oui (pour la réécriture d'hôte) |
Réécriture de chemin
Example 1: Réécrivez example.com/test en example.com/dev avant de transférer la requête au backend.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/rewrite-target: "/dev"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/rewrite-target: "/dev"
name: demo
spec:
ingressClassName: mse
rules:
- http:
paths:
- path: /test
pathType: Exact
backend:
serviceName: demo-service
servicePort: 80Example 2: Supprimez le préfixe /v1 : réécrivez example.com/v1/xxx en example.com/xxx.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/rewrite-target: "/$1"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /v1/(.*)
pathType: PrefixVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/rewrite-target: "/$1"
name: demo
spec:
ingressClassName: mse
rules:
- http:
paths:
- path: /v1/(.*)
pathType: Prefix
backend:
serviceName: demo-service
servicePort: 80Example 3: Remplacez le préfixe /v1 par /v2 : réécrivez example.com/v1/xxx en example.com/v2/xxx.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/rewrite-target: "/v2/$1"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /v1/(.*)
pathType: PrefixVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/rewrite-target: "/v2/$1"
name: demo
spec:
ingressClassName: mse
rules:
- http:
paths:
- path: /v1/(.*)
pathType: Prefix
backend:
serviceName: demo-service
servicePort: 80Réécriture d'hôte
Example: Réécrivez l'hôte de example.com à test.com avant de transférer example.com/test au backend.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/upstream-vhost: "test.com"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/upstream-vhost: "test.com"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Redirection
Redirection HTTP vers HTTPS
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
Force la redirection des requêtes HTTP vers HTTPS. |
|
Oui (pour activer la redirection) |
|
|
Force la redirection des requêtes HTTP vers HTTPS. |
|
Oui (alternative à |
MSE Ingress traite de manière identique les annotationsssl-redirectetforce-ssl-redirect: toutes deux forcent la redirection HTTP vers HTTPS.
Example: Redirigez http://example.com/test vers https://example.com/test.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "true"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "true"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Redirection permanente
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
URL de destination pour la redirection permanente. Doit inclure le schéma ( |
— |
Oui (pour la redirection permanente) |
|
|
Code d'état HTTP pour la redirection. |
|
Non |
Example: Redirigez de manière permanente http://example.com/test vers http://example.com/app.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/permanent-redirect: "http://example.com/app"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/permanent-redirect: "http://example.com/app"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Redirection temporaire
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
URL de destination pour la redirection temporaire. Doit inclure le schéma ( |
— |
Oui (pour la redirection temporaire) |
Example: Redirigez temporairement http://example.com/test vers http://example.com/app.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/temporal-redirect: "http://example.com/app"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/temporal-redirect: "http://example.com/app"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Contrôle des en-têtes
Le contrôle des en-têtes vous permet d'ajouter, de modifier ou de supprimer des en-têtes de requête avant que MSE Ingress ne transfère une requête à un service backend, ainsi que des en-têtes de réponse avant que celle-ci ne soit renvoyée au client.
Contrôle des en-têtes de requête
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
|
Ajoute un en-tête à la requête. Si l'en-tête existe déjà, la valeur est ajoutée à la valeur d'origine. Pour un seul en-tête, utilisez une paire clé-valeur. Pour plusieurs en-têtes, utilisez un scalaire de bloc YAML ( |
`) avec une paire clé-valeur par ligne. |
— |
Non |
|
|
Modifie un en-tête existant dans la requête. Si l'en-tête existe déjà, la valeur écrase l'originale. Même syntaxe que |
— |
Non |
|
|
|
Supprime un en-tête de la requête. Pour plusieurs en-têtes, séparez-les par des virgules ( |
— |
Non |
Example 1: Ajoutez foo: bar et test: true à toutes les requêtes adressées à example.com/test.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/request-header-control-add: |
foo bar
test true
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/request-header-control-add: |
foo bar
test true
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Example 2: Combinez le contrôle des en-têtes avec les déploiements canaris. Lorsque l'en-tête de requête est mse: v1, la requête est dirigée vers demo-service-canary-v1 avec l'ajout de stage: gray. Toutes les autres requêtes sont dirigées vers demo-service avec l'ajout de stage: production.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "mse"
nginx.ingress.kubernetes.io/canary-by-header-value: "v1"
mse.ingress.kubernetes.io/request-header-control-add: "stage gray"
name: demo-canary-v1
spec:
ingressClassName: mse
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:
mse.ingress.kubernetes.io/request-header-control-add: "stage production"
name: demo
spec:
ingressClassName: mse
rules:
- http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /hello
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "mse"
nginx.ingress.kubernetes.io/canary-by-header-value: "v1"
mse.ingress.kubernetes.io/request-header-control-add: "stage gray"
name: demo-canary-v1
spec:
ingressClassName: mse
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service-canary-v1
servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/request-header-control-add: "stage production"
name: demo
spec:
ingressClassName: mse
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service
servicePort: 80Contrôle des en-têtes de réponse
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
Ajoute un en-tête à la réponse du backend avant de la transmettre au client. Si l'en-tête existe déjà, la valeur est ajoutée. Même syntaxe que pour le contrôle des en-têtes de requête. |
— |
Non |
|
|
Modifie un en-tête de réponse existant. Si l'en-tête existe déjà, la valeur écrase l'originale. Même syntaxe que pour le contrôle des en-têtes de requête. |
— |
Non |
|
|
Supprime un en-tête de réponse avant de le transmettre au client. Pour plusieurs en-têtes, séparez-les par des virgules ( |
— |
Non |
Example: Supprimez l'en-tête req-cost-time des réponses adressées à example.com/test.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/response-header-control-remove: "req-cost-time"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/response-header-control-remove: "req-cost-time"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Nouvelle tentative
MSE Ingress propose une fonctionnalité de nouvelle tentative automatique au niveau des routes pour les requêtes échouées. Définissez les conditions, les limites et les délais d'expiration des nouvelles tentatives à l'aide des annotations suivantes.
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
Nombre maximal de nouvelles tentatives. |
|
Non |
|
|
Délai d'expiration global pour toutes les tentatives combinées, en secondes. |
Aucun délai d'expiration |
Non |
|
|
Conditions de nouvelle tentative, séparées par des virgules. Valeurs valides : |
|
Non |
Par défaut, MSE Ingress n'effectue pas de nouvelle tentative pour les requêtes non idempotentes (POST, PATCH), même si d'autres conditions de nouvelle tentative sont remplies. Ajouteznon_idempotentàproxy-next-upstreampour activer les nouvelles tentatives pour ces méthodes.
Example: Pour example.com/test , définissez un maximum de 2 nouvelles tentatives avec un délai d'expiration de 5 secondes, déclenchez les nouvelles tentatives uniquement en cas d'erreur HTTP 502 et activez-les pour les requêtes non idempotentes.
Kubernetes v1.19 et versions ultérieures :
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: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.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: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Listes d'autorisation (whitelists) et listes de blocage (blacklists) d'adresses IP
MSE Ingress prend en charge les listes d'autorisation (whitelists) et les listes de blocage (blacklists) d'adresses IP, tant au niveau des routes qu'au niveau des domaines. Les règles au niveau des routes sont prioritaires sur celles au niveau des domaines.
Contrôle des adresses IP au niveau des routes
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
Adresses IP ou blocs CIDR autorisés pour cette route. Séparés par des virgules. |
— |
Non |
|
|
Adresses IP ou blocs CIDR bloqués pour cette route. Séparés par des virgules. |
— |
Non |
Example 1: Autorisez l'accès à example.com/test uniquement depuis 1.1.X.X .
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/whitelist-source-range: 1.1.X.X
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.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: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Example 2: Bloquez l'accès à example.com/test depuis 2.2.2.2 .
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/blacklist-source-range: 2.2.2.2
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/blacklist-source-range: 2.2.2.2
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Contrôle des adresses IP au niveau des domaines
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
Adresses IP ou blocs CIDR autorisés pour toutes les routes d'un domaine. Les listes d'autorisation au niveau des routes sont prioritaires. Séparés par des virgules. |
— |
Non |
|
|
Adresses IP ou blocs CIDR bloqués pour toutes les routes d'un domaine. Les listes de blocage au niveau des routes sont prioritaires. Séparés par des virgules. |
— |
Non |
Example 1: Autorisez l'accès à toutes les routes de example.com depuis 1.1.X.X et 2.2.2.2 .
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/domain-whitelist-source-range: 1.1.X.X,2.2.2.2
name: demo
spec:
ingressClassName: mse
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: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/domain-whitelist-source-range: 1.1.X.X,2.2.2.2
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80
- path: /app
backend:
serviceName: app-service
servicePort: 80Example 2: Autorisez toutes les routes de example.com depuis 1.1.X.X et 2.2.2.2 , mais restreignez /order à 3.3.X.X uniquement. La liste d'autorisation au niveau de la route pour /order est prioritaire sur la liste d'autorisation au niveau du domaine pour cette route.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/domain-whitelist-source-range: 1.1.X.X,2.2.2.2
name: demo-domain
spec:
ingressClassName: mse
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: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /order
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/domain-whitelist-source-range: 1.1.X.X,2.2.2.2
name: demo-domain
spec:
ingressClassName: mse
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: mse
rules:
- host: example.com
http:
paths:
- path: /order
backend:
serviceName: demo-service
servicePort: 80Limitation du débit pour une seule passerelle
La limitation du débit pour une seule passerelle restreint le taux de requêtes sur une route par réplica de passerelle. Utilisez cette fonction pour contrôler le débit par instance. Pour un contrôle du débit à l'échelle du cluster, consultez la section Contrôle global de la limitation du débit.
MSE Ingress utilise un modèle de bucket à jetons pour gérer les pics de trafic. L'annotation route-limit-rpm ou route-limit-rps définit le débit soutenu, c'est-à-dire la vitesse à laquelle le bucket à jetons se remplit. L'annotation route-limit-burst-multiplier définit la capacité de pic comme un multiple de ce débit : limite de pic = débit × multiplicateur. Les requêtes dépassant la capacité de pic sont rejetées avec local_rate_limited dans le corps de la réponse.
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
Nombre maximal de requêtes par minute (RPM) par réplica de passerelle. Limite de pic = RPM × |
— |
Non |
|
|
Nombre maximal de requêtes par seconde (RPS) par réplica de passerelle. Limite de pic = RPS × |
— |
Non |
|
|
Multiplicateur de capacité de pic appliqué à la limite RPM ou RPS configurée. |
|
Non |
Example 1: Limitez example.com/test à 100 RPM avec une limite de pic de 200 (multiplicateur = 2).
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/route-limit-rpm: "100"
mse.ingress.kubernetes.io/route-limit-burst-multiplier: "2"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/route-limit-rpm: "100"
mse.ingress.kubernetes.io/route-limit-burst-multiplier: "2"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Example 2: Limitez example.com/test à 10 RPS avec la limite de pic par défaut de 50 (multiplicateur = 5).
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/route-limit-rps: "10"
# Default burst multiplier is 5, giving a burst limit of 50 RPS
# mse.ingress.kubernetes.io/route-limit-burst-multiplier: "5"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/route-limit-rps: "10"
# Default burst multiplier is 5, giving a burst limit of 50 RPS
# mse.ingress.kubernetes.io/route-limit-burst-multiplier: "5"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Contrôle global de la limitation du débit
MSE Ingress s'intègre à Sentinel pour appliquer une limite globale de RPS sur tous les réplicas d'un cluster de passerelles au niveau des routes. Lorsque la limitation est déclenchée, le code de réponse par défaut est 429 et le corps de la réponse est sentinel rate limited .
Le contrôle global de la limitation du débit nécessite une version de la passerelle MSE Ingress 1.2.25 ou ultérieure.
Configurez la limite de débit à l'échelle du cluster avec mse.ingress.kubernetes.io/rate-limit . Pour personnaliser la réponse en cas de limitation, choisissez l'une des deux approches suivantes : réponse personnalisée ou redirection. Une seule approche peut être active à la fois.
Réponse personnalisée
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
RPS maximal pour cette route sur l'ensemble du cluster de passerelles. |
— |
Oui |
|
|
Code de réponse HTTP renvoyé lorsque la limitation est déclenchée. |
|
Non |
|
|
Type de contenu du corps de la réponse. |
|
Non |
|
|
Contenu du corps de la réponse lorsque la limitation est déclenchée. |
|
Non |
Example 1: Limitez example.com/test à 100 RPS à l'échelle du cluster avec la réponse par défaut (HTTP 429, sentinel rate limited ).
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/rate-limit: "100"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/rate-limit: "100"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Example 2: Limitez example.com/test à 100 RPS à l'échelle du cluster. En cas de limitation, renvoyez le code HTTP 503 avec le corps server is overloaded .
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/rate-limit: "100"
mse.ingress.kubernetes.io/rate-limit-fallback-custom-response-code: 503
mse.ingress.kubernetes.io/rate-limit-fallback-custom-response-body: "server is overloaded"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/rate-limit: "100"
mse.ingress.kubernetes.io/rate-limit-fallback-custom-response-code: 503
mse.ingress.kubernetes.io/rate-limit-fallback-custom-response-body: "server is overloaded"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Redirection
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
URL vers laquelle rediriger le client lorsque la limitation est déclenchée. |
— |
Non |
Example: Limitez example.com/test à 100 RPS à l'échelle du cluster. En cas de limitation, redirigez vers example.com/fallback .
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/rate-limit: "100"
mse.ingress.kubernetes.io/rate-limit-fallback-redirect-url: "example.com/fallback"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/rate-limit: "100"
mse.ingress.kubernetes.io/rate-limit-fallback-redirect-url: "example.com/fallback"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Contrôle global de la concurrence
MSE Ingress s'intègre à Sentinel pour limiter le nombre de requêtes en cours sur une route, et ce, sur l'ensemble du cluster de passerelle. Lorsque cette limite est dépassée, le code de réponse par défaut est 429 et le corps de la réponse indique sentinel rate limited.
Le contrôle global de la concurrence nécessite une version 1.2.25 ou ultérieure de la passerelle MSE Ingress.
Configurez la limite de concurrence à l'échelle du cluster à l'aide de l'annotation mse.ingress.kubernetes.io/concurrency-limit. Pour personnaliser la réponse renvoyée lorsque la limite est atteinte, vous pouvez opter pour une réponse personnalisée ou une redirection. Une seule de ces approches peut être active à la fois.
Réponse personnalisée
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
Nombre maximal de requêtes en cours pour cette route sur l'ensemble du cluster de passerelle. |
— |
Oui |
|
|
Code de réponse HTTP renvoyé lorsque le contrôle de concurrence est déclenché. |
|
Non |
|
|
Type de contenu du corps de la réponse. La valeur |
|
Non |
|
|
Contenu du corps de la réponse renvoyé lorsque le contrôle de concurrence est déclenché. |
|
Non |
Example 1: Limitez le nombre de requêtes en cours simultanées vers example.com/test à 1 000 sur l'ensemble du cluster, en utilisant la réponse par défaut.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/concurrency-limit: "1000"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/concurrency-limit: "1000"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Example 2: Limitez le nombre de requêtes en cours simultanées vers example.com/test à 1 000 sur l'ensemble du cluster. Lorsque la limite est dépassée, renvoyez un code HTTP 503 avec le corps de réponse server is overloaded.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/concurrency-limit: "1000"
mse.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-code: 503
mse.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-body: "server is overloaded"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/concurrency-limit: "1000"
mse.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-code: 503
mse.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-body: "server is overloaded"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Redirection
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
URL vers laquelle rediriger le client lorsque le contrôle de concurrence est déclenché. |
— |
Non |
Example: Limitez le nombre de requêtes en cours simultanées vers example.com/test à 1 000 sur l'ensemble du cluster. Lorsque la limite est dépassée, redirigez le trafic vers example.com/fallback.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/concurrency-limit: "1000"
mse.ingress.kubernetes.io/concurrency-limit-fallback-redirect-url: "example.com/fallback"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/concurrency-limit: "1000"
mse.ingress.kubernetes.io/concurrency-limit-fallback-redirect-url: "example.com/fallback"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Mise en miroir du trafic
La mise en miroir du trafic consiste à copier les requêtes en direct vers un service secondaire sans affecter la réponse originale. Cette fonctionnalité est utile pour l'audit, les tests ou le débogage du trafic dans un environnement shadow.
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
Service de destination pour le trafic mis en miroir. Format : |
— |
Oui (pour activer la mise en miroir) |
|
|
Pourcentage du trafic à mettre en miroir. Plage valide : 0–100. |
|
Non |
Lorsque le trafic mis en miroir est transféré vers le service de destination, le suffixe-shadowest automatiquement ajouté à l'en-têteHost. Par exemple,example.comdevientexample.com-shadow.
Example 1: Mettez en miroir 100 % des requêtes vers example.com/test vers le service test/app:8080.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/mirror-target-service: test/app:8080
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/mirror-target-service: test/app:8080
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Example 2: Mettez en miroir 10 % des requêtes vers example.com/test vers le service test/app:8080.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/mirror-target-service: test/app:8080
mse.ingress.kubernetes.io/mirror-percentage: 10
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/mirror-target-service: test/app:8080
mse.ingress.kubernetes.io/mirror-percentage: 10
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Protocoles des services backend : HTTPS et gRPC
Par défaut, MSE Ingress utilise le protocole HTTP pour transférer les requêtes aux conteneurs backend. Utilisez l'annotation nginx.ingress.kubernetes.io/backend-protocol pour basculer vers HTTPS ou gRPC.
Si le port de la ressource Kubernetes Service associée à votre backend est nommégrpcouhttp2, MSE Ingress utilise automatiquement le protocole correspondant sans nécessiter l'annotationbackend-protocol. Ce comportement diffère de celui de l'Ingress NGINX standard.
Example 1: Transférez les requêtes vers un backend via HTTPS.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Example 2: Transférez les requêtes vers un backend gRPC. Deux méthodes sont disponibles.
Méthode 1 — utilisez l'annotation backend-protocol :
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/backend-protocol: "GRPC"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/backend-protocol: "GRPC"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Méthode 2 — nommez le port du Service grpc afin que MSE Ingress détecte automatiquement le protocole :
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: mse
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-serviceVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: demo
spec:
ingressClassName: mse
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-serviceAlgorithmes d'équilibrage de charge
MSE Ingress prend en charge plusieurs algorithmes d'équilibrage de charge pour distribuer les requêtes vers les Pods backend. Choisissez l'algorithme adapté en fonction de la répartition de votre trafic et de vos exigences en matière de session :
|
Algorithme |
Valeur de l'annotation |
Description |
Cas d'utilisation |
|
Tourniquet (Round robin) |
|
Distribue les requêtes uniformément entre les Pods, de manière rotative. |
Valeur par défaut ; convient aux backends sans état aux performances homogènes. |
|
Moins de connexions |
|
Achemine chaque requête vers le Pod présentant le moins de connexions actives. |
Backends avec des durées de requête variables. |
|
Aléatoire |
|
Achemine les requêtes vers un Pod sélectionné aléatoirement. |
Répartition simple et uniforme sans gestion d'état. |
|
Hachage cohérent |
Voir ci-dessous |
Achemine les requêtes partageant la même clé de hachage vers le même Pod. |
Affinité de session basée sur l'adresse IP, l'en-tête ou le paramètre de requête. |
L'algorithme EWMA (Exponentially Weighted Moving Average) n'est pas pris en charge. S'il est configuré, le système revient automatiquement au mode round robin.
Algorithmes d'équilibrage de charge courants
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
Algorithme d'équilibrage de charge. Valeurs valides : |
|
Non |
Example: Utilisez l'algorithme « moins de connexions » pour le service demo-service.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/load-balance: "least_conn"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /order
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/load-balance: "least_conn"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Hachage cohérent
Le hachage cohérent achemine les requêtes possédant la même clé de hachage vers le même Pod backend. MSE Ingress permet de réaliser le hachage à partir de variables NGINX, d'en-têtes de requête ou de paramètres de requête.
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
Expression de la clé de hachage. Valeurs prises en charge : variables NGINX (par exemple, |
— |
Oui (pour le hachage cohérent) |
Example 1: Hachage basé sur l'adresse IP du client — les requêtes provenant de la même adresse IP atteignent toujours le même Pod.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/upstream-hash-by: "$remote_addr"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/upstream-hash-by: "$remote_addr"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Example 2: Hachage basé sur l'en-tête de requête X-Stage — les requêtes ayant la même valeur X-Stage atteignent toujours le même Pod.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/upstream-hash-by: "$http_x-stage"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/upstream-hash-by: "$http_x-stage"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Example 3: Hachage basé sur le paramètre de requête x-stage — les requêtes ayant la même valeur x-stage atteignent toujours le même Pod.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/upstream-hash-by: "$arg_x-stage"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/upstream-hash-by: "$arg_x-stage"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Préchauffage (démarrage progressif)
La fonctionnalité de préchauffage augmente progressivement le trafic vers un Pod nouvellement démarré sur une période définie. Cela évite qu'un Pod froid ne reçoive immédiatement la charge complète. Seuls les algorithmes Round Robin et Least Connections prennent en charge le préchauffage.
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
Durée de la fenêtre de préchauffage en secondes. Lorsqu'un nouveau Pod démarre, le trafic augmente progressivement durant cette période. |
Préchauffage désactivé |
Non |
Example: Activez une fenêtre de préchauffage de 30 secondes pour demo-service.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/warmup: "30"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/warmup: "30"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Affinité de cookie (persistance de session)
L'affinité de cookie associe un client au même Pod backend pour toutes ses requêtes grâce à un cookie généré par la passerelle. Lors de la première requête, MSE Ingress définit un cookie dans la réponse. Les requêtes suivantes du même client incluent ce cookie et sont acheminées vers le même Pod.
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
Active l'affinité de cookie. La seule valeur valide est |
— |
Oui (pour activer l'affinité de cookie) |
|
|
Mode d'affinité. La seule valeur valide est |
|
Non |
|
|
Nom du cookie utilisé comme clé de hachage. |
|
Non |
|
|
Attribut de chemin du cookie généré. |
|
Non |
|
|
Durée de validité du cookie généré, en secondes. |
Limitée à la session |
Non |
|
|
Durée de validité du cookie généré, en secondes. |
Limitée à la session |
Non |
Example 1: Activez l'affinité de cookie avec les valeurs par défaut : nom du cookie INGRESSCOOKIE, chemin /, durée limitée à la session.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/affinity: "cookie"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/affinity: "cookie"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Example 2: Activez l'affinité de cookie avec un cookie personnalisé nommé test, le chemin / et une expiration de 10 secondes.
Kubernetes v1.19 et versions ultérieures :
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: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.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: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Pool de connexions entre une passerelle et un service backend
Configurez un pool de connexions pour contrôler le nombre de connexions entre la passerelle et un service backend. Cela empêche la surcharge du backend lors des pics de trafic.
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
Nombre maximal total de connexions TCP entre la passerelle et le service backend. |
— |
Non |
|
|
Nombre maximal de connexions TCP entre la passerelle et un seul Pod du service backend. |
— |
Non |
|
|
Nombre maximal de requêtes HTTP par connexion entre la passerelle et le service backend. |
— |
Non |
Example: Pour demo-service, définissez un maximum de 10 connexions totales et de 2 connexions par Pod.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/connection-policy-tcp-max-connection: 10
mse.ingress.kubernetes.io/connection-policy-tcp-max-connection-per-endpoint: 2
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/connection-policy-tcp-max-connection: 10
mse.ingress.kubernetes.io/connection-policy-tcp-max-connection-per-endpoint: 2
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80Versions TLS et suites de chiffrement
La plage de versions TLS par défaut pour MSE Ingress va de TLSv1.0 (la plus ancienne) à TLSv1.3 (la plus récente). Les suites de chiffrement par défaut sont les suivantes :
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
Utilisez les annotations suivantes pour configurer les paramètres TLS par nom de domaine.
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
Version TLS minimale acceptée. Valeurs valides : |
|
Non |
|
|
Version TLS maximale acceptée. |
|
Non |
|
|
Suites de chiffrement TLS, séparées par des virgules. S'applique uniquement aux versions TLS 1.0–1.2. |
Voir la liste par défaut ci-dessus |
Non |
Example: Limitez example.com à TLSv1.2 uniquement.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/tls-min-protocol-version: "TLSv1.2"
mse.ingress.kubernetes.io/tls-max-protocol-version: "TLSv1.2"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
mse.ingress.kubernetes.io/tls-min-protocol-version: "TLSv1.2"
mse.ingress.kubernetes.io/tls-max-protocol-version: "TLSv1.2"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80TLS mutuel (mTLS) entre une passerelle et un service backend
Par défaut, MSE Ingress utilise HTTP pour transférer les requêtes vers les conteneurs backend. Lorsque nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" est défini, MSE Ingress utilise un TLS unidirectionnel : il authentifie le certificat du backend, qui doit être émis par une autorité de certification (CA) reconnue.
Avec le TLS mutuel (mTLS), la passerelle et le service backend s'authentifient mutuellement via leurs certificats respectifs.
|
Annotation |
Description |
Valeur par défaut |
Obligatoire |
|
|
Certificat client utilisé par la passerelle pour s'authentifier auprès du backend. Format : |
— |
Oui (pour mTLS) |
|
|
Indication du nom du serveur (SNI) utilisée lors du handshake TLS. |
— |
Non |
|
|
Active ou désactive le SNI lors du handshake TLS. |
— |
Non |
Example: Configurez mTLS entre la passerelle et demo-service en utilisant gateway-cert dans le namespace default.
Kubernetes v1.19 et versions ultérieures :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/proxy-ssl-secret: "default/gateway-cert"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /test
pathType: ExactVersions de Kubernetes antérieures à la v1.19 :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/proxy-ssl-secret: "default/gateway-cert"
name: demo
spec:
ingressClassName: mse
rules:
- host: example.com
http:
paths:
- path: /test
backend:
serviceName: demo-service
servicePort: 80