Pourquoi Jiakaobaodian choisit APISIX Ingress Controller

Avec la prévalence de Kubernetes (abrégé en K8s), nous avons plus d'options à choisir que le contrôleur d'entrée NGINX Ingress Controller par défaut, et le Apache APISIX Ingress Controller est également devenu un choix populaire pour de nombreuses entreprises. De plus en plus d'entreprises remplacent progressivement leur Ingress Controller par APISIX Ingress Controller.

Contexte

Wuhan Mucang Technology Co., Ltd a été fondée en 2011, et ses principaux produits sont des dizaines d'applications automobiles telles que Jiakaobaodian. Depuis sa création il y a plus de 10 ans, l'entreprise a suivi la tendance technologique et a commencé à adopter le cloud-native en 2019, et divers projets de l'entreprise ont adopté Kubernetes.

Mais à l'époque, comme K8s venait d'émerger, il y avait peu de portails d'entrée de trafic à choisir. Par conséquent, nous avons utilisé le contrôleur d'entrée par défaut – NGINX Ingress Controller – pendant près de 4 ans. Cependant, pendant cette période, il est devenu de plus en plus évident que NGINX Ingress Controller ne pouvait plus répondre à nos besoins, nous obligeant à faire un nouveau choix. Après avoir comparé les principaux contrôleurs d'entrée, nous avons décidé d'utiliser Apache APISIX comme passerelle d'entrée de l'entreprise.

Le problème avec NGINX Ingress Controller

Les services de l'entreprise utilisent les protocoles HTTP et TCP, et seuls les ingénieurs d'exploitation et de maintenance savent exactement comment configurer le proxy TCP via NGINX Ingress Controller. Cependant, les ressources humaines en exploitation et maintenance sont limitées. Il serait préférable de confier certaines des opérations et configurations de base de NGINX à l'équipe de développement, afin de réduire les coûts d'exploitation et de maintenance.

En plus de cela, nous avons également rencontré les problèmes suivants :

Certains changements de configuration nécessitent un rechargement ;
Le proxy TCP a un coût d'utilisation élevé et ne peut pas couvrir tous les scénarios de trafic ;
Le routage ou les opérations de trafic ne peuvent être définis que par des annotations, et nous ne pouvons pas définir et réutiliser les configurations de manière sémantique ;
La réécriture, la coupure de circuit, le transfert de requêtes et d'autres opérations sont implémentées via des annotations ;
Manque de plateforme de gestion, et le personnel d'exploitation et de maintenance doit opérer via YAML, ce qui est sujet à des erreurs ;
Mauvaise portabilité ;
Peu propice à l'intégration avec la plateforme de conteneurs.

Pour ces raisons, nous avons décidé de remplacer notre ancien contrôleur d'entrée par un nouveau.

Pourquoi APISIX Ingress Controller

Nous avons étudié Apache APISIX et d'autres contrôleurs d'entrée, en les comparant en termes de performance, facilité d'utilisation, extensibilité et intégration de plateforme, et avons finalement sélectionné APISIX Ingress Controller comme passerelle d'entrée de trafic K8s pour les raisons suivantes.

Bonne extensibilité ;
Support du rechargement à chaud des configurations ;
Haute performance ;
Beaucoup de plugins ;
Support des CRD pour l'intégration avec la plateforme de conteneurs auto-développée.

Architecture globale

Cela dit, examinons l'architecture globale de la passerelle. Dans un scénario commercial réel, les utilisateurs redirigeront d'abord le trafic via SLB (Server Load Balancer), et lorsque le trafic entre dans K8s, chaque service sera invoqué via le cluster APISIX. Nous implémentons également de nombreuses fonctions communes (mise en production canari, contrôle de flux, coupure de circuit API, contrôle de sécurité du trafic, contrôle du trafic de requête/réponse, etc.) côté passerelle afin d'unifier la gestion des services, de réduire la complexité des activités et de réduire les coûts.

Diagramme d'architecture

Méthode de déploiement

Notre activité est déployée sur différentes plateformes cloud (Huawei Cloud, Tencent Cloud, Alibaba Cloud), et nous pouvons rapidement mettre en ligne notre activité via Helm Chart, qui est supporté par APISIX Ingress Controller. Lorsque nous utilisons APISIX Ingress Controller, si nous trouvons des fonctionnalités qui peuvent être améliorées, nous soumettons également des PR pour aider la communauté à mettre à jour et itérer les fonctionnalités. Dans le processus de déploiement réel, nous avons personnalisé certaines configurations selon les caractéristiques de notre activité, telles que :

Créer des NameSpace via K8s, déployer APISIX et APISIX Ingress Controller dans différents NameSpace, et segmenter le trafic selon les lignes de produits et l'importance des services ;
Optimiser les paramètres du noyau TCP Linux dans APISIX initContainer ;
Comme nous devons segmenter le trafic en termes de lignes de produits et d'importance des services, les informations de ClassName de K8s doivent être configurées.

En isolant le trafic par différentes lignes de produits et importance, vous pouvez minimiser les pertes causées par des pannes logicielles.

Intégration avec les plateformes de conteneurs auto-développées en utilisant CRD

APISIX Ingress Controller supporte actuellement de nombreuses ressources CRD, nous pouvons donc utiliser les ressources CRD pour intégrer APISIX Ingress Controller avec notre propre plateforme de conteneurs. Cependant, comme APISIX ne fournit pas de client Java, nous devons utiliser l'outil de génération de code fourni par K8s pour générer le modèle et utiliser CustomObjectApi pour gérer les CRD. Les objets ApisixRoute sont associés aux applications de la plateforme de conteneurs et structurés avec des objets de base, permettant au personnel d'exploitation et aux chefs de projet d'opérer dans la plateforme de conteneurs.

Scénarios d'application

Authentification

Avant d'utiliser Apache APISIX, nous avons implémenté l'authentification basée sur la passerelle Istio, et après la migration vers Apache APISIX, nous avons choisi d'utiliser le plugin forward-auth, qui déplace astucieusement la logique d'authentification et d'autorisation vers un service d'authentification externe. La requête de l'utilisateur est redirigée vers le service d'authentification via la passerelle, et lorsque le service d'authentification répond avec un statut non-20x, la requête originale est bloquée et le résultat est remplacé. De cette manière, il est possible de retourner un rapport d'erreur personnalisé ou de rediriger l'utilisateur vers la page d'authentification si l'authentification échoue.

Lorsqu'un client envoie une requête à une application, elle est d'abord traitée par le plugin forward-auth d'APISIX, et la requête est redirigée vers un service d'authentification externe via forward-auth, et le résultat est finalement retourné à la passerelle APISIX. Si l'authentification réussit, le client peut demander le service normalement. Si l'authentification échoue, un code d'erreur est retourné.

Contrôle de flux

En raison des caractéristiques de l'activité de l'entreprise, il y a cinq ou six mois de trafic de pointe chaque année. Une fois qu'il y a trop de requêtes, nous devons augmenter manuellement la capacité, mais en raison de l'accumulation de requêtes, le service peut ne pas démarrer après l'augmentation, ce qui entraînera une panne en avalanche de toute la chaîne, nous devons donc limiter le flux et la vitesse du cluster.

Par conséquent, nous utilisons les plugins limit-conn, limit-req, et limit-count d'APISIX pour limiter les requêtes et prévenir les pannes en avalanche. Il est plus facile de limiter le flux et la vitesse en modifiant les plugins, et grâce au mécanisme de rechargement à chaud d'APISIX, il n'est pas nécessaire de redémarrer les plugins lors de leur configuration, ils prennent donc effet immédiatement. En contrôlant le trafic, il peut également arrêter certaines attaques malveillantes et protéger la sécurité du système. Nous avons également implémenté HPA (Horizontal Pod Autoscaler) dans la plateforme K8s, qui augmente et diminue automatiquement la capacité une fois que la quantité de trafic est trop importante ou trop faible, avec les plugins de limitation de flux et de taux d'APISIX pour arrêter les pannes massives.

Observabilité

En termes d'observabilité, nous surveillons actuellement le trafic sur l'ensemble de la plateforme via SkyWalking. Le plugin SkyWalking d'APISIX permet une interface directe avec la plateforme SkyWalking existante, et l'interface utilisateur de SkyWalking permet de voir facilement les nœuds de la chaîne qui consomment des performances. De plus, comme les points de surveillance sont situés côté passerelle, donc plus proches de l'utilisateur, il est plus facile de vérifier les points chronophages.

Avec le plugin kafka-logger, les journaux d'accès et d'erreur générés par APISIX peuvent être écrits directement dans le cluster Apache Kafka. Avec cet avantage, le cluster APISIX peut s'étendre de manière stateless et horizontale sans avoir besoin de formater des disques, de faire tourner des journaux ou d'effectuer d'autres opérations. Si les journaux sont stockés localement, nous devons effectuer des opérations supplémentaires et ne pouvons pas réaliser une extension rapide. En envoyant les journaux au cluster Apache Kafka, nous pouvons également analyser les journaux en temps réel, et améliorer et optimiser le système en fonction des résultats de l'analyse.

Conclusion

Comme APISIX Ingress Controller vient d'être lancé, il n'y a pas encore beaucoup de scénarios d'application. Nous continuerons à explorer les scénarios d'application et à apporter plus d'exemples d'utilisation à la communauté.

De plus en plus d'équipes utilisent Apache APISIX Ingress Controller en environnement de production. Si vous utilisez également APISIX Ingress Controller, nous vous encourageons à partager vos cas d'utilisation dans la communauté.