La dernière version de Kong pour Kubernetes 0.8 est sortie. Les mises à jours sont nombreuses comme l’intégration de Knative ou de Kong Gateway. L’architecture de Kong pour Kubernetes 0.8 se compose désormais de 2 parties Kubernetes ingress controller qui gèrent la configuration des entrées réseau, et Kong Gateway gère les demandes API entrantes.
Kong pour Kubernetes est un ingress controller de Kubernetes basé sur le projet open source Kong Gateway. Il est entièrement natif à Kubernetes.
Si vous voulez mettre votre logiciel à jour, assurez-vous d’installer les 2 nouveaux custom resource definition dans votre cluster Kubernetes. Il se peut que le routage d’entrée réseau pour votre cluster se casse si vous utilisez le routage basé sur le chemin.
Avant 0.8, Kong supprimait le chemin de requête par défaut. Maintenant, cette fonctionnalité est désactivée. Vous pouvez l’activer en utilisant les ressources de KongIngress ou la nouvelle annotation konghq.com/strip-path sur la ressource Ingress.
Intégration de Knative
Knative est un projet open source basé sur Kubernetes qui permet d’exécuter des workloads sans serveur. Il permet d’améliorer la productivité des développeurs et réduire les coûts d’exploitation.
Kong peut maintenant effectuer l’entrée réseau pour les workloads de Knative. Mais aussi, exécuter des plugins pour les workloads du service Knative, en prenant la responsabilité de l’authentification, de la mise en cache, de la mise en forme et de la transformation du trafic.
Ce qui signifie que lorsque des événements sans serveur HTTP Knative se produisent, ils peuvent être automatiquement acheminés par Kong et gérés de manière appropriée.
Nouveau cluster Custom Resource Definition
Désormais, les service owners doivent posséder le plugin de configuration (KongPlugin) en plus des ressources d’Ingress, de Service, de Deployment et les autres ressources liées au service. Ce modèle fonctionne bien dans la majorité des cas, mais présente deux limites :
- Il est parfois important que la configuration du plugin soit homogène pour tous les équipes ou groupes de services qui fonctionnent dans des espaces de noms différents.
- Il arrive aussi que la configuration du plugin soit contrôlée par une équipe différente et que le plugin soit appliqué sur une entrée réseau ou un service par une équipe différente. C’est généralement le cas des plugins d’authentification et de mise en forme du trafic, dont la configuration pourrait être contrôlée par une équipe d’exploitation.
Pour résoudre ces problèmes, en plus des ressources de KongPlugin, une nouvelle ressource personnalisée a été ajoutée au niveau du cluster : KongClusterPlugin.
Vous pouvez désormais créer un KongClusterPlugin et le partager dans les espaces de noms. Vous pouvez également contrôler l’accès de cette ressource différemment pour tenir compte des cas où seuls les utilisateurs ayant des rôles spécifiques peuvent gérer des configurations de plugin ou quand les services owners ne peuvent utiliser que les KongClusterPlugins bien définis.
Annotations pour minimiser la configuration
Cette version est livrée avec de nouvelles annotations qui devraient minimiser et simplifier la configuration de l’entrée réseau :
- konghq.com/plugins
- konghq.com/override
- konghq.com/client-cert
- konghq.com/protocoles
- konghq.com/protocole
- konghq.com/preserve-host
- konghq.com/plugins
- konghq.com/override
- konghq.com/path
- konghq.com/strip-path
- konghq.com/https-redirect-status-code
Avec ces nouvelles annotations, vous n’aurez plus besoin d’utiliser la ressource personnalisée KongIngress. Pour une liste complète des annotations et savoir comment les utiliser, vous pouvez consulter le document github sur les annotations Kong Ingress Controller écrit en anglais.
Ajout de toutes les fonctionnalités de l’API de Kong Gateway
Il s’agit des fonctions de gestion de l’API, des capacités qui améliorent la gestion dynamique du trafic de l’API, l’application d’une authentification basée sur l’OIDC, la limitation avancée du débit, la mise en cache des requêtes ou la transmission en continu des logs et des métriques à différents fournisseurs d’analyses en même temps.
Bien que Kong soit construit sur NGINX, ces deux programmes ont des ingress controllers différents. Ces différences résident dans les fonctionnalités de gestion de l’API de Kong, ainsi que dans le fait que pour les utilisateurs de Kong Gateway, il offre un « cycle de vie de gestion de l’API cohérent » pour les workloads.
Routage basé sur le SNI
En plus d’exposer les services de base de TCP, Kong prend également en charge les flux TCP cryptés en TLS. Kong peut alors acheminer le trafic sur le même port TCP vers différents services au sein de Kubernetes basé sur le SNI du handshake TLS. Kong met également fin à la session TLS et transmet le flux TCP au service en plain text ou peut également le recrypter.
A retenir
- L’intégration de Knative permettra d’exécuter des workloads sans serveur pour les fonctions et les applications logiques de tout cluster Kubernetes pour n’importe quel fournisseur cloud
- L’intégration des KongClusterPlugins permet aux service owners de pouvoir configurer le KongPlugin
- L’ajout de l’API de Kong Gateway améliore la gestion dynamique du trafic de l’API, l’application d’une authentification basée sur l’OIDC, la limitation avancée du débit, la mise en cache des requêtes, la transmission en continu des logs et des métriques
- Si vous voulez former sur cet outil, nous vous recommandons formation Kubernetes
Cet article a été inspiré par l’article de l’annonce du release de Kong pour Kubernetes 0.8 disponible sur le site officiel de Kong.
Mise à jour : Kong pour Kubernetes 0.9
Kong pour kubernetes a été mis à jour le 26 mai 2020, voici ces nouvelles fonctionnalités :
- Configuration des plugins via Kubernetes Secrets. La configuration des plugins peut être stockée dans Kubernetes Secrets puis référencée dans les ressources KongPlugin et KongClusterPlugin.
- Authentification mTLS. Le contrôleur peut configurer les certificats CA à Kong et ceux-ci peuvent être utilisés par le plugin mtls-auth à Kong. Le plugin est actuellement réservé aux entreprises.
- Entités personnalisées de Kong en mode sans DB. Les entités personnalisées utilisées dans les plugins personnalisés peuvent maintenant être configurées pour les déploiements de Kong sans DB.
- Manipulation de l’en-tête de l’hôte. L’en-tête de l’hôte d’une requête destinée à un service Kubernetes peut maintenant être manipulé en utilisant l’annotation konghq.com/host-header sur la ressource du service.
- Routage basé sur une méthode. Le routage basé sur une méthode peut être effectué en utilisant la ressource Ingress. Une nouvelle annotation konghq.com/methods peut maintenant être utilisée pour faire correspondre la méthode HTTP en plus de l’hôte et du chemin HTTP. Auparavant, cette fonction n’était prise en charge que par la ressource personnalisée KongIngress.
- Nouvelles options de configuration. Suite aux nouveaux drapeaux CLI et aux variables d’environnement correspondantes ont été ajoutés :
- –admission-webhook-cert, –admission-webhook-key et –kong-admin-ca-cert. Ils ont été ajoutés pour faciliter la configuration en permettant aux utilisateurs de fournir des valeurs sensibles en utilisant des références secrètes dans PodSpec.
- –kong-custom-entities-secret flag a été ajouté pour supporter les entités personnalisées en mode sans DB.
Quelques erreurs ont été corrigés :
- Certaines erreurs qui étaient auparavant ignorées sont maintenant détectées et traitées correctement
- Les règles d’entrée avec des barres obliques consécutives (//) sont maintenant ignorées
D’autres changements importants ont été apportés comme :
Le comportement du manifeste par défaut a été modifié pour utiliser l’interface de statut de Kong au lieu d’un simple bloc de serveur Nginx. Ce changement est transparent et ne nécessite pas de travail supplémentaire.
Mise à jour : Kong pour Kubernetes 0.10
Kong pour kubernetes a été mis à jour le 15 septembre 2020, voici ces nouvelles fonctionnalités :
- Ajout du support pour Ingress v1.
- Ajout de la prise en charge de la fonctionnalité de cartographie des ports dans les versions 2.1 et plus récentes des manifestes d’exemple de Kong. Cette fonctionnalité améliore la fonctionnalité de Kong lorsque derrière un équilibreur de charge qui utilise des ports différents que le proxy de Kong écoute.
- Ajout d’un support pour l’annotation ingress.kubernetes.io/force-ssl-redirect.
- Passage à une exploitation forestière structurée.
- Ajout de drapeaux pour permettre le traitement des ressources Ingress et KongConsumer sans annotations ingress.class, quelle que soit la classe du contrôleur. Auparavant, cette fonctionnalité n’était disponible que lors de l’utilisation de la classe de contrôleur par défaut, et ne pouvait pas être désactivée.
- Ajout d’un support pour les webhooks de validation d’admission.k8s.io/v1.
- Migration vers un système de gestion des erreurs de type Go 1.13.
- Ajout d’une documentation sur l’utilisation du contrôleur avec Istio.
- Mise à jour de la documentation pour inclure des informations sur Kong 2.1.
Quelques erreurs ont été corrigés :
- Suppression du contexte de sécurité des déploiements d’exemples. Les versions antérieures de Kong devaient fonctionner en tant que root pour prendre en charge certaines fonctionnalités d’Enterprise. Ce n’est plus le cas dans les versions modernes de Kong.
- Ajout de la documentation manquante pour le drapeau –enable-reverse-sync.
- Correction d’un bogue où le contrôleur ne suivait pas les mises à jour de ressources qui n’auraient pas dû nécessiter l’annotation ingress.class, sauf si cette annotation était présente.
- Clarification des instructions de construction pour pousser les artefacts Docker.
- Amélioration du comportement de démarrage du contrôleur dans les scénarios où Kong n’était pas disponible. Le contrôleur va maintenant réessayer et sortir avec une erreur après un délai d’attente, plutôt que d’attendre indéfiniment.
- Adresser plusieurs fautes de documentation et des exemples incongrus.
- Correction d’un exemple de Helm 3 qui utilisait encore des drapeaux Helm 2 dépréciés.
D’autres changements importants ont été apportés comme :
- Les ressources d’entrée nécessitent désormais par défaut les annotations kubernetes.io/ingress.class. Kong recommande d’ajouter cette annotation aux Ingress qui ne l’avaient pas auparavant, mais vous pouvez passer outre ce changement et demander au contrôleur de traiter les Ingres sans cette annotation si vous le souhaitez. Voir la documentation sur les classes d’intrusion pour plus de détails.
- Les ressources KongConsumer nécessitent désormais par défaut les annotations kubernetes.io/ingress.class. Ce changement peut également être annulé à l’aide d’un drapeau.
- Les ressources TCPIngress nécessitent désormais des annotations kubernetes.io/ingress.class. Ce changement ne peut pas être annulé.
- Les secrets des certificats de l’AC nécessitent désormais des annotations kubernetes.io/ingress.class. Ce changement ne peut pas être annulé.
- Suppression du soutien aux ressources mondiales de KongPlugin. Vous devez maintenant utiliser les ressources KongClusterPlugin pour les plugins globaux. Vous devez lancer kubectl get kongplugin -l global=true –all-namespaces pour lister les KongPlugins globaux existants afin de les trouver et de les convertir avant la mise à niveau. Le contrôleur enregistrera également un avertissement s’il trouve des KongPlugins globaux qui sont encore en place.
