Opportunités et défis de l'évolution technologique dans le Cloud Native

De nos jours, le Cloud Native devient de plus en plus populaire, et la CNCF définit le Cloud Native comme suit :

• Basé sur un environnement moderne et dynamique, c'est-à-dire un environnement cloud.
• Avec la conteneurisation comme technologie fondamentale, incluant Service Mesh, l'infrastructure immuable, les API déclaratives, etc.
• Les caractéristiques clés incluent la mise à l'échelle automatique, la gestion, l'observabilité, l'automatisation, les changements fréquents, etc.

Selon l'enquête CNCF 2021, il y a un nombre très important (plus de 62 000) de contributeurs dans la communauté Kubernetes. Avec la tendance actuelle de la technologie, de plus en plus d'entreprises investissent davantage dans le Cloud Native et rejoignent cette voie tôt pour un déploiement cloud actif. Pourquoi les entreprises adoptent-elles le Cloud Native tout en se développant, et que signifie le Cloud Native pour elles ?

Avantages techniques du Cloud Native

La popularité du Cloud Native vient de ses avantages au niveau technique. Il y a deux aspects principaux de la technologie Cloud Native, incluant la conteneurisation menée par Docker, et l'orchestration de conteneurs menée par Kubernetes.

Docker a introduit les images de conteneurs dans le monde technologique, faisant des images de conteneurs une unité de livraison standardisée. En fait, avant Docker, la technologie de conteneurisation existait déjà. Parlons d'une technologie plus récente, LXC (Linux Containers) en 2008. Comparé à Docker, LXC est moins populaire car Docker fournit des images de conteneurs, qui peuvent être plus standardisées et plus faciles à migrer. De plus, Docker a créé le service public DockerHub, qui est devenu le plus grand référentiel d'images de conteneurs au monde. En outre, la technologie de conteneurisation peut également atteindre un certain degré d'isolation des ressources, incluant non seulement l'isolation des ressources CPU et mémoire, mais aussi l'isolation de la pile réseau, ce qui facilite le déploiement de plusieurs copies d'applications sur la même machine.

Kubernetes est devenu populaire grâce à l'essor de Docker. La technologie d'orchestration de conteneurs, menée par Kubernetes, fournit plusieurs capacités importantes, telles que l'auto-guérison des pannes, la planification des ressources et l'orchestration des services. Kubernetes dispose d'un mécanisme de découverte de services basé sur DNS intégré, et grâce à son architecture de planification, il peut être mis à l'échelle très rapidement pour réaliser l'orchestration des services.

Aujourd'hui, de plus en plus d'entreprises adoptent activement Kubernetes et transforment leurs applications pour se lancer dans le déploiement Kubernetes. Et le Cloud Native dont nous parlons est en fait basé sur la prémisse de Kubernetes, la pierre angulaire de la technologie Cloud Native.

Avantages de la conteneurisation

1. Livraison standardisée

Les images de conteneurs sont désormais devenues une unité de livraison standardisée. Grâce à la technologie de conteneurisation, les utilisateurs peuvent directement effectuer la livraison via une image de conteneur au lieu d'un binaire ou d'un code source. En s'appuyant sur le mécanisme d'emballage de l'image de conteneur, vous pouvez utiliser la même image pour démarrer un service et produire le même comportement dans n'importe quel environnement d'exécution de conteneurs.

2. Portable et léger, économie de coûts

La technologie de conteneurisation atteint une certaine isolation grâce aux capacités du noyau Linux, ce qui facilite la migration. De plus, la technologie de conteneurisation peut directement exécuter des applications, ce qui est plus léger en termes de mise en œuvre technique par rapport à la technologie de virtualisation, sans avoir besoin d'un système d'exploitation dans la machine virtuelle.

Toutes les applications peuvent partager le noyau, ce qui permet d'économiser des coûts. Et plus l'application est grande, plus les économies sont importantes.

3. Commodité de la gestion des ressources

Lors du démarrage d'un conteneur, vous pouvez définir les propriétés CPU, mémoire ou disque IO qui peuvent être utilisées pour le service de conteneur, ce qui permet une meilleure planification et un meilleur déploiement des ressources lors du démarrage des instances d'application via des conteneurs.

Avantages de l'orchestration de conteneurs

1. Simplifier le flux de travail

Dans Kubernetes, le déploiement d'applications est plus facile à gérer que dans Docker, car Kubernetes utilise une configuration déclarative. Par exemple, un utilisateur peut simplement déclarer dans un fichier de configuration quelle image de conteneur l'application utilisera et quels ports de service seront exposés sans avoir besoin de gestion supplémentaire. Les opérations correspondant à la configuration déclarative simplifient grandement le flux de travail.

2. Améliorer l'efficacité et économiser des coûts

Une autre caractéristique avantageuse de Kubernetes est la reprise sur incident. Lorsqu'un nœud dans Kubernetes tombe en panne, Kubernetes planifie automatiquement les applications sur celui-ci vers d'autres nœuds normaux et les remet en fonctionnement. L'ensemble du processus de récupération ne nécessite pas d'intervention humaine et d'opération, ce qui améliore non seulement l'efficacité opérationnelle au niveau opérationnel, mais permet également d'économiser du temps et des coûts.

Avec l'essor de Docker et Kubernetes, vous verrez que leur émergence a apporté une grande innovation et des opportunités à la livraison d'applications. Les images de conteneurs, en tant qu'unités de livraison standard, raccourcissent le processus de livraison et facilitent l'intégration avec les systèmes CI/CD.

Considérant que la livraison d'applications devient plus rapide, comment l'architecture des applications suit-elle la tendance Cloud Native ?

Évolution de l'architecture des applications : des monolithes, microservices à Service Mesh

Le point de départ de l'évolution de l'architecture des applications reste l'architecture monolithique. À mesure que la taille et les exigences des applications augmentent, l'architecture monolithique ne répond plus aux besoins du développement collaboratif en équipe, c'est pourquoi les architectures distribuées ont été progressivement introduites.

Parmi les architectures distribuées, la plus populaire est l'architecture microservices. L'architecture microservices peut diviser les services en plusieurs modules, qui communiquent entre eux, complètent l'enregistrement et la découverte des services, et réalisent des capacités communes telles que la limitation de débit et le disjonctage.

En outre, il existe divers modèles inclus dans une architecture microservices. Par exemple, le modèle de base de données par service, qui représente chaque microservice avec une base de données individuelle, est un modèle qui évite l'impact au niveau de la base de données sur l'application mais peut introduire plus d'instances de base de données.

Un autre est le modèle de API Gateway, qui reçoit le trafic d'entrée du cluster ou de l'ensemble de l'architecture microservices via une passerelle et complète la distribution du trafic via des API. C'est l'un des modèles les plus utilisés, et des produits de passerelle comme Spring Cloud Gateway ou Apache APISIX peuvent être appliqués.

Les architectures populaires s'étendent progressivement aux architectures Cloud Native. Une architecture microservices sous Cloud Native peut-elle simplement construire le microservice d'origine en tant qu'image de conteneur et le migrer directement vers Kubernetes ?

En théorie, cela semble possible, mais en pratique, il y a quelques défis. Dans une architecture microservices Cloud Native, ces composants doivent fonctionner non seulement dans des conteneurs, mais aussi inclure d'autres aspects tels que l'enregistrement, la découverte et la configuration des services.

Le processus de migration implique également une transformation et une adaptation au niveau métier, nécessitant la migration de logiques communes telles que l'authentification, l'autorisation et les capacités liées à l'observabilité (journalisation, surveillance, etc.) vers K8s. Par conséquent, la migration du déploiement sur machine physique d'origine vers la plateforme K8s est beaucoup plus complexe qu'il n'y paraît.

Dans ce cas, nous pouvons utiliser le modèle Sidecar pour abstraire et simplifier le scénario ci-dessus.

Typiquement, le modèle Sidecar se présente sous la forme d'un proxy Sidecar, qui évolue du côté gauche du diagramme ci-dessous vers le côté droit en immergeant certaines capacités génériques (telles que l'authentification, l'autorisation, la sécurité, etc.) dans Sidecar. Comme vous pouvez le voir sur le diagramme, ce modèle est passé de la nécessité de maintenir plusieurs composants à la nécessité de ne maintenir que deux éléments (application + Sidecar). En même temps, le modèle Sidecar lui-même contient certains composants communs, il n'a donc pas besoin d'être maintenu par le côté métier, résolvant ainsi facilement le problème de la communication des microservices.

Pour éviter les scènes complexes de configuration séparée et de reconstruction de roues lors de l'introduction d'un Sidecar pour chaque microservice, le processus peut être mis en œuvre en introduisant un plan de contrôle ou par injection de plan de contrôle, ce qui forme progressivement le Service Mesh actuel.

Service Mesh nécessite généralement deux composants, c'est-à-dire le plan de contrôle + le plan de données. Le plan de contrôle complète la distribution de la configuration et l'exécution de la logique associée, comme Istio, qui est actuellement le plus populaire. Sur le plan de données, vous pouvez choisir une passerelle API comme Apache APISIX pour le transfert de trafic et la communication des services. Grâce à la haute performance et à l'extensibilité d'APISIX, il est également possible d'effectuer certaines exigences de personnalisation et de logique personnalisée. Ce qui suit montre l'architecture de la solution Service Mesh avec Istio+APISIX.

L'avantage de cette solution est que lorsque vous souhaitez migrer de l'architecture microservices précédente à une architecture Cloud Native, vous pouvez éviter des changements massifs du côté métier en utilisant directement une solution Service Mesh.

Défis techniques du Cloud Native

L'article précédent a mentionné certains des avantages de la tendance actuelle du Cloud Native en termes techniques. Cependant, chaque médaille a son revers. Bien que certains éléments nouveaux et des opportunités puissent être apportés, des défis émergeront en raison de la participation de certaines technologies.

Problèmes causés par la conteneurisation et K8s

Au début de l'article, nous avons mentionné que la technologie de conteneurisation utilise un noyau partagé, et le noyau partagé apporte de la légèreté mais crée un manque d'isolation. Si une évasion de conteneur se produit, l'hôte correspondant peut être attaqué. Par conséquent, pour répondre à ces défis de sécurité, des technologies telles que les conteneurs sécurisés ont été introduites.

En outre, bien que les images de conteneurs fournissent une méthode de livraison standardisée, elles sont sujettes à des attaques, telles que les attaques de la chaîne d'approvisionnement.

De même, l'introduction de K8s a également entraîné des défis en matière de sécurité des composants. L'augmentation des composants a entraîné une augmentation de la surface d'attaque, ainsi que des vulnérabilités supplémentaires liées aux composants sous-jacents et aux niveaux de dépendance. Au niveau de l'infrastructure, la migration des machines physiques ou virtuelles traditionnelles vers K8s implique des coûts de transformation de l'infrastructure et plus de coûts de main-d'œuvre pour effectuer des sauvegardes de données de cluster, des mises à niveau périodiques et des renouvellements de certificats.

De plus, dans l'architecture Kubernetes, l'apiserver est le composant central du cluster et doit gérer tout le trafic interne et externe. Par conséquent, afin d'éviter les problèmes de sécurité aux frontières, la protection de l'apiserver devient une question clé. Par exemple, nous pouvons utiliser Apache APISIX pour le protéger.

Sécurité

L'utilisation de nouvelles technologies nécessite une attention supplémentaire au niveau de la sécurité :

• Au niveau de la sécurité réseau, un contrôle granulaire du trafic peut être mis en œuvre par Network Policy, ou d'autres méthodes de chiffrement de connexion comme mTLS pour former un réseau de confiance zéro.

• Au niveau de la sécurité des données, K8s fournit la ressource secret pour gérer les données confidentielles, mais en réalité, elle n'est pas sécurisée. Le contenu de la ressource secret est encodé en Base64, ce qui signifie que vous pouvez accéder au contenu via le décodage Base64, surtout s'il est placé dans etcd, qui peut être lu directement si vous avez accès à etcd.

• Au niveau de la sécurité des permissions, il y a également une situation où les paramètres RBAC ne sont pas raisonnables, ce qui conduit un attaquant à utiliser le Token pertinent pour communiquer avec l'apiserver afin d'atteindre l'objectif de l'attaque. Ce type de paramétrage des permissions est surtout vu dans les scénarios de contrôleur et d'opérateur.

Observabilité

La plupart des scénarios Cloud Native impliquent des opérations liées à l'observabilité telles que la journalisation, la surveillance, etc.

Dans K8s, si vous souhaitez collecter des journaux de diverses manières, vous devez les collecter directement sur chaque nœud K8s via agrégation. Si les journaux étaient collectés de cette manière, l'application devrait être exportée vers la sortie standard ou les erreurs standard.

Cependant, si l'entreprise ne fait pas les changements pertinents et choisit toujours d'écrire tous les journaux d'application dans un fichier dans le conteneur, cela signifie qu'un Sidecar est nécessaire pour la collecte de journaux dans chaque instance, ce qui rend l'architecture de déploiement extrêmement complexe.

Revenant au niveau de la gouvernance de l'architecture, la sélection des solutions de surveillance dans l'environnement Cloud Native pose également certains défis. Une fois que la sélection de la solution est erronée, le coût d'utilisation ultérieur est très élevé, et la perte peut être énorme si la direction est mauvaise.

De plus, il y a des problèmes de capacité impliqués au niveau de la surveillance. Lors du déploiement d'une application dans K8s, vous pouvez simplement configurer sa limitation de débit pour limiter les détails des ressources que l'application peut utiliser. Cependant, dans un environnement K8s, il est encore assez facile de sur-vendre des ressources, de sur-utiliser des ressources et de déborder de la mémoire en raison de ces conditions.

En outre, une autre situation dans un cluster K8s où l'ensemble du cluster ou un nœud manque de ressources entraînera l'éviction des ressources, ce qui signifie que les ressources déjà en cours d'exécution sur un nœud sont évacuées vers d'autres nœuds. Si les ressources d'un cluster sont tendues, une tempête de nœuds peut facilement provoquer l'effondrement de l'ensemble du cluster.

Évolution des applications et modèle multi-cluster

Au niveau de l'évolution de l'architecture des applications, le problème central est la découverte de services.

K8s fournit un mécanisme de découverte de services basé sur DNS par défaut, mais si l'entreprise inclut la coexistence de métiers cloud et de métiers existants, il sera plus compliqué d'utiliser un mécanisme de découverte de services DNS pour gérer la situation.

En même temps, si les entreprises choisissent la technologie Cloud Native, avec l'expansion de l'échelle des métiers, elles envisageront progressivement la direction du traitement multi-nœuds, ce qui impliquera alors des problèmes multi-clusters.

Par exemple, nous voulons fournir aux clients un modèle de haute disponibilité via plusieurs clusters, et cette fois, cela impliquera l'orchestration des services entre plusieurs clusters, la distribution de charge multi-clusters et la synchronisation de la configuration, et comment gérer et déployer des stratégies pour les clusters dans des scénarios multi-cloud et hybrides. Ce sont quelques-uns des défis qui seront rencontrés.

Comment APISIX permet la transformation numérique

Apache APISIX est une passerelle API Cloud Native sous la Fondation Apache Software, qui est dynamique, en temps réel et haute performance, fournissant des fonctionnalités riches de gestion du trafic telles que l'équilibrage de charge, l'amont dynamique, la publication canari, le disjonctage, l'authentification, l'observabilité, etc. Vous pouvez utiliser Apache APISIX pour gérer le trafic traditionnel nord-sud, ainsi que le trafic est-ouest entre les services.

Actuellement, basé sur l'évolution de l'architecture et les changements d'application décrits ci-dessus, des solutions de contrôleur Ingress et Service Mesh basées sur APISIX ont également été dérivées dans Apache APISIX pour aider les entreprises à mieux mener leur transformation numérique.

Solution APISIX Ingress

Apache APISIX Ingress Controller est une implémentation de contrôleur Ingress Kubernetes qui sert principalement de passerelle de trafic pour gérer le trafic Kubernetes nord-sud.

L'architecture du contrôleur Ingress APISIX est similaire à celle d'APISIX en ce qu'elle est une architecture séparée pour le plan de contrôle et le plan de données. Dans ce cas, APISIX est utilisé comme plan de données pour le traitement réel du trafic.

Actuellement, le contrôleur Ingress APISIX prend en charge les trois méthodes de configuration suivantes et est compatible avec tous les plugins APISIX dès le départ :

• Prise en charge des ressources Ingress natives de K8s. Cette approche permet au contrôleur Ingress APISIX d'avoir un niveau d'adaptabilité plus élevé. Jusqu'à présent, le contrôleur Ingress APISIX est la version la plus supportée de tout produit de contrôleur Ingress open source et influent.

• Prise en charge de l'utilisation de ressources personnalisées. Les ressources personnalisées actuelles du contrôleur Ingress APISIX sont un ensemble de spécifications CRD conçues selon la sémantique d'APISIX. L'utilisation de ressources personnalisées facilite l'intégration avec APISIX et est plus native.

• Prise en charge de l'API Gateway. En tant que prochaine génération de la norme Ingress, le contrôleur Ingress APISIX a commencé à prendre en charge l'API Gateway (étape bêta). À mesure que l'API Gateway évolue, elle est susceptible de devenir une ressource intégrée directement dans K8s.

Le contrôleur Ingress APISIX présente les avantages suivants par rapport à Ingress NGINX :

• Séparation architecturale. Dans APISIX Ingress, l'architecture du plan de données et du plan de contrôle est séparée. Lorsque la pression de traitement du trafic est élevée et que vous souhaitez augmenter la capacité, vous pouvez simplement effectuer l'extension du plan de données, ce qui permet à plus de plans de données d'être servis à l'extérieur sans avoir besoin de faire des ajustements au plan de contrôle.

• Haute extensibilité et prise en charge des plugins personnalisés.

• En tant que choix de plan de données, avec des fonctionnalités de haute performance et entièrement dynamiques. Grâce à la fonctionnalité entièrement dynamique d'APISIX, il est possible de protéger le trafic métier autant que possible avec l'utilisation d'APISIX Ingress.

Actuellement, le contrôleur Ingress APISIX est utilisé par de nombreuses entreprises dans le monde, telles que China Mobile Cloud Open Platform (un produit d'API ouvert et d'IDE cloud), Upyun et Copernicus (partie des Eyes on Earth de l'Europe).

Le contrôleur Ingress APISIX est encore en itération continue, et nous prévoyons d'améliorer plus de fonctions de la manière suivante :

1. Compléter la prise en charge de l'API Gateway pour permettre plus de configurations de scénarios.
2. Prendre en charge le proxy de service externe.
3. Prendre en charge nativement plusieurs registres pour rendre le contrôleur Ingress APISIX plus polyvalent.
4. Mises à jour architecturales pour créer un nouveau modèle architectural ;
5. Intégration avec Argo CD/Flux et d'autres outils GitOps pour créer un écosystème riche.

Si vous êtes intéressé par la solution APISIX Ingress, n'hésitez pas à suivre les mises à jour de la communauté pour les itérations de produits et les tendances de la communauté.

Solution APISIX Service Mesh

Actuellement, en plus de la passerelle API et de la solution Ingress, la solution Service Mesh basée sur APISIX est également en itération active.

La solution Service Mesh basée sur APISIX se compose de deux composants principaux, à savoir le plan de contrôle et le plan de données. Istio a été choisi pour le plan de contrôle car il est un leader de l'industrie avec une communauté active et est soutenu par plusieurs fournisseurs. APISIX a été choisi pour remplacer Envoy du côté des données, permettant à la haute performance et à l'extensibilité d'APISIX de jouer un rôle.

Le Service Mesh d'APISIX est encore activement poursuivi, avec des itérations ultérieures prévues dans les directions suivantes :

• Effectuer une accélération eBPF pour améliorer l'efficacité globale.

• Effectuer une intégration des capacités de plugins pour permettre une meilleure utilisation des capacités d'APISIX Ingress dans l'architecture Service Mesh.

• Créer un outil de migration transparent pour fournir des outils plus faciles et simplifier le processus pour les utilisateurs.

En général, l'évolution de l'architecture et de la technologie à l'ère du Cloud Native nous apporte à la fois des opportunités et des défis. Apache APISIX en tant que passerelle Cloud Native s'est engagé à plus d'adaptations et d'intégrations techniques pour la tendance Cloud Native. Diverses solutions basées sur APISIX ont également commencé à aider les utilisateurs d'entreprise à mener leur transformation numérique et à aider les entreprises à passer plus facilement à la voie Cloud Native.