Bien que la ressource Kubernetes Ingress standard soit idéale pour provisionner et configurer l'équilibrage de charge Ingress de base, elle n'inclut pas le type de fonctionnalités de personnalisation requises pour rendre Kubernetes de qualité production . Au lieu de cela, les utilisateurs non-NGINX doivent utiliser des annotations, des ConfigMaps et des modèles personnalisés qui sont sujets aux erreurs, difficiles à utiliser, non sécurisés et manquent de portée précise. Les ressources NGINX Ingress sont notre réponse à ce problème.
Les ressources NGINX Ingress sont disponibles pour les versions NGINX Open Source et NGINX Plus de NGINX Ingress Controller. Ils fournissent un style de configuration natif, sécurisé et indenté qui simplifie la mise en œuvre de l’équilibrage de charge Ingress. Dans ce blog, nous nous concentrons sur deux fonctionnalités introduites dans NGINX Ingress Controller 1.11.0 qui facilitent la configuration des politiques WAF et d'équilibrage de charge :
NGINX Ingress Controller 1.11.0 étend la ressource TransportServer (TS) dans les domaines suivants :
Note: Les ajouts à la ressource TransportServer dans la version 1.11.0 sont un aperçu technologique en cours de développement actif. Ils seront mis à niveau vers une norme de qualité stable et prête pour la production dans une future version.
Dans NGINX Ingress Controller , nous avons introduit des extraits de configuration pour les ressources VirtualServer et VirtualServerRoute (VS et VSR) qui vous permettent d’étendre nativement les configurations NGINX Ingress pour les clients basés sur HTTP. La version 1.11.0 introduit des extraits pour les ressources TS, afin que vous puissiez facilement exploiter toute la gamme des fonctionnalités NGINX et NGINX Plus pour fournir des services basés sur TCP/UDP. Par exemple, vous pouvez utiliser des extraits pour ajouter des directives de refus
et d'autorisation
qui utilisent des adresses IP et des plages pour définir quels clients peuvent accéder à un service.
Version de l'API : k8s.nginx.org/v1alpha1kind : TransportServer
métadonnées :
nom : café
spécification :
hôte : café.exemple.com
extraits de serveur : |
refuser 192.168.1.1 ;
autoriser 192.168.1.0/24 ;
amont :
- nom : thé
service : thé-svc
port : 80
Pour surveiller l'état de santé d'un cluster Kubernetes, NGINX Ingress Controller prend non seulement en compte les sondes Kubernetes locales aux pods d'application, mais surveille également l'état du réseau entre les services en amont basés sur TCP/UDP, avec des contrôles de santé passifs pour évaluer l'état de santé des transactions en cours et des contrôles de santé actifs (exclusifs à NGINX Plus) pour sonder périodiquement les points de terminaison avec des demandes de connexion synthétiques.
Les contrôles de santé peuvent être très utiles pour couper les circuits et gérer les erreurs d'application. Vous pouvez personnaliser le contrôle d'intégrité à l'aide de paramètres dans le champ healthCheck
de la ressource TS qui définissent l'intervalle entre les sondes, le délai d'expiration de la sonde, les délais entre les sondes, etc.
De plus, vous pouvez définir le service en amont et la destination du port des sondes d’intégrité à partir de NGINX Ingress Controller. Cela est utile dans les situations où l’état de santé de l’application en amont est exposé sur un écouteur différent par un autre processus ou sous-système qui surveille plusieurs composants en aval de l’application.
ingressClassName
Lorsque vous mettez à jour et appliquez une ressource TS, il est utile de vérifier que la configuration est valide et a été appliquée avec succès au déploiement du contrôleur d'entrée correspondant. La version 1.11.0 introduit le champ ingressClassName
et le rapport d'état pour la ressource TS. Le champ ingressClassName
garantit que la ressource TS est traitée par un déploiement Ingress Controller particulier dans les environnements où vous avez plusieurs déploiements.
Pour afficher l'état d'une ou de toutes les ressources TS, exécutez la commande kubectl
get
transportserver
; la sortie inclut l'état ( valide
ou invalide
), la raison de la mise à jour la plus récente et (pour un seul TS) un message personnalisé.
$ kubectl get transportserver NOM ÉTAT RAISON ÂGE dns-tcp Valide Ajouté ou mis à jour 47 m $ kubectl describe transportserver dns-tcp . . .
Statut:
Message: La configuration de default/dns-tcp a été ajoutée ou mise à jour Raison : État ajouté ou mis à jour : Valide
Si plusieurs ressources TS sont en concurrence pour le même hôte/auditeur, NGINX Ingress Controller sélectionne la ressource TS avec les horodatages les plus anciens, garantissant un résultat déterministe dans cette situation.
Les ressources NGINX Ingress rendent non seulement la configuration plus simple et plus flexible, mais elles vous permettent également de déléguer le contrôle du trafic à différentes équipes et d'imposer des restrictions de privilèges plus strictes aux utilisateurs propriétaires de sous-routes d'application, comme défini dans les ressources VirtualServerRoute (VSR). En donnant aux bonnes équipes l’accès aux bonnes ressources Kubernetes, les ressources NGINX Ingress vous offrent un contrôle précis sur les ressources réseau et réduisent les dommages potentiels aux applications si les utilisateurs sont compromis ou piratés.
La version 1.11.0 introduit un objet de stratégie
de pare-feu d’application Web (WAF) natif pour étendre ces avantages à la configuration de NGINX App Protect dans vos déploiements Kubernetes. La politique exploite les objets APLogConf et APPolicy introduits dans la version 1.8.0 et peut être attachée aux ressources VirtualServer (VS) et VSR. Cela signifie que les administrateurs de sécurité peuvent avoir la propriété de l'ensemble de la configuration Ingress avec les ressources VS, tout en déléguant les responsabilités de sécurité à d'autres équipes en référençant les ressources VSR.
Dans l'exemple suivant, la politique waf-prod
est appliquée aux utilisateurs routés vers webapp-prod
en amont. Pour déléguer les responsabilités de sécurité pour la route /v2
entre les espaces de noms appartenant à différentes équipes, la directive de route
en surbrillance fait référence à une ressource VSR.
Version de l'API : k8s.nginx.org/v1kind : Métadonnées du serveur virtuel : nom : webapp spec : hôte : webapp.example.com stratégies : - nom : waf-prod tls : secret : app-secret upstreams : - nom : webapp-prod service : webapp-svc port : 80 routes : - chemin : /v2 route : test/test - chemin : /v1 action : pass : webapp-prod
Les équipes qui gèrent l’espace de noms de test
peuvent définir leurs propres paramètres et politiques WAF à l’aide des ressources VSR dans cet espace de noms.
Version de l'API : k8s.nginx.org/v1kind : VirtualServerRoute
métadonnées :
nom : test
espace de noms : test
spécification :
hôte : webapp.example.com
flux en amont :
- nom : webapp
service : webapp-test-svc
port : 80
sous-routes :
- chemin : /v2
politiques :
- nom : waf-test
action :
passe : webapp
Cet exemple sépare les locataires par espace de noms et applique une stratégie WAF différente pour le service webapp-test-svc
dans l'espace de noms de test
. Il illustre comment la délégation de ressources à différentes équipes et leur encapsulation avec des objets simplifient le test de nouvelles fonctionnalités sans perturber les applications en production.
Avec NGINX Ingress Controller 1.11.0, nous poursuivons notre engagement à fournir un contrôleur Ingress de qualité industrielle, flexible, puissant et facile à utiliser. Outre les améliorations apportées au WAF et au TS, la version 1.11.0 inclut les améliorations suivantes :
de stratégie
avant qu’ils ne soient appliqués à la configuration d’entréeEn nous appuyant sur les améliorations apportées à la validation des annotations introduites dans la version 1.10.0, nous validons désormais les annotations supplémentaires suivantes :
Annotation | Validation |
---|---|
nginx.org/client-max-body-size |
Doit être un décalage valide |
nginx.org/fail-timeout |
Doit être une heure valide |
nginx.org/max-conns |
Doit être un entier non négatif valide |
nginx.org/max-fails |
Doit être un entier non négatif valide |
nginx.org/proxy-buffer-size |
Doit être une taille valide |
nginx.org/proxy-buffers |
Doit être une spécification de tampon proxy valide |
nginx.org/proxy-connect-timeout |
Doit être une heure valide |
nginx.org/proxy-max-temp-file-size |
Doit être une taille valide |
nginx.org/proxy-read-timeout |
Doit être une heure valide |
nginx.org/proxy-send-timeout |
Doit être une heure valide |
nginx.org/upstream-zone-size |
Doit être une taille valide |
Si la valeur de l'annotation n'est pas valide lorsque la ressource Ingress est appliquée, le contrôleur Ingress rejette la ressource et supprime la configuration correspondante de NGINX.
La commande kubectl
get
policy
signale désormais l'état de la politique ( valide
ou non valide
) et (pour un seul TS) un message personnalisé et la raison de la mise à jour la plus récente.
$ kubectl get policy NOM ÉTAT ÂGE webapp-policy Valide 30 s $ kubectl describe policy webapp-policy . . .
Statut:
Message: La configuration de default/webapp-policy a été ajoutée ou mise à jour Raison : État ajouté ou mis à jour : Valide
NGINX Ingress Controller peut désormais être utilisé comme contrôleur d’entrée pour les applications exécutées dans un maillage de service Istio. Cela permet aux utilisateurs de continuer à utiliser les fonctionnalités avancées fournies par NGINX Ingress Controller sur les environnements basés sur Istio sans recourir à des solutions de contournement. Cette intégration implique deux exigences :
Pour satisfaire à la première exigence, incluez les éléments suivants dans le champ d’annotations
de votre fichier de déploiement NGINX Ingress.
annotations : traffic.sidecar.istio.io/includeInboundPorts : ""
traffic.sidecar.istio.io/excludeInboundPorts : « 80 443 » traffic.sidecar.istio.io/excludeOutboundIPRanges : "10.90.0.0/16,10.45.0.0/16" sidecar.istio.io/inject: 'true'
La deuxième exigence est satisfaite par une modification du comportement du champ requestHeaders
. Dans les versions précédentes, avec la configuration suivante, deux en-têtes d'hôte
étaient envoyés au backend : $host
et la valeur spécifiée, bar.example.com
.
Version de l'API : k8s.nginx.org/v1kind : Métadonnées du serveur virtuel : nom : foo spécification : hôte : foo.example.com amont : - nom : foo port : 8080 service : backend-svc use-cluster-ip : true routes : - chemin : « / » action : proxy : en amont : foo requestHeaders : set : - nom : Valeur de l'hôte : bar.example.com
Dans la version 1.11.0 et ultérieure, seule la valeur spécifiée est envoyée. Pour envoyer $host
, omettez entièrement le champ requestHeaders
.
Les points de terminaison en amont dans la configuration du contrôleur d’entrée NGINX peuvent désormais être renseignés avec des adresses IP de service/cluster, au lieu des adresses IP individuelles des points de terminaison de pod. Pour permettre à NGINX Ingress Controller d'acheminer le trafic vers les services Cluster-IP, incluez le champ use-cluster-ip:
true
dans la section upstreams
de votre configuration VS ou VSR :
en amont : - nom : service de thé : tea-svc port : 80 use-cluster-ip: true - nom: service café: port coffee-svc: 80 utilisation-cluster-ip : vrai
Pour le journal des modifications complet de la version 1.11.0, consultez les Notes de version .
Pour essayer NGINX Ingress Controller pour Kubernetes avec NGINX Plus et NGINX App Protect, démarrez votre essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation .
Pour essayer NGINX Ingress Controller avec NGINX Open Source, vous pouvez obtenir le code source de la version ou télécharger un conteneur prédéfini depuis DockerHub .
Pour une discussion sur les différences entre les contrôleurs d'entrée, consultez Attendez, quel contrôleur d'entrée NGINX pour Kubernetes suis-je en train d'utiliser ? sur notre blog.
« Cet article de blog peut faire référence à des produits qui ne sont plus disponibles et/ou qui ne sont plus pris en charge. Pour obtenir les informations les plus récentes sur les produits et solutions F5 NGINX disponibles, explorez notre famille de produits NGINX . NGINX fait désormais partie de F5. Tous les liens NGINX.com précédents redirigeront vers un contenu NGINX similaire sur F5.com."