Scénarios d’usage

Effectué

Maintenant que vous avez établi les avantages et les inconvénients des critères de décision, il est préférable de passer en revue certains scénarios.

Développement

Effectuer le développement de plusieurs fonctionnalités dans un espace d’adressage IP limité peut être problématique. kubenet est conçu dans un esprit de conservation de l’espace d’adressage, ce qui en fait un bon choix pour les environnements de développement ou expérimentaux.

Si une ou plusieurs des conditions suivantes ne sont pas vraies, vous pouvez envisager d’opter pour un environnement de développement en utilisant la mise en réseau d’Azure CNI :

• Les fonctionnalités expérimentales ou en développement n’ont pas besoin des capacités de mise à l’échelle rapide fournies par les nœuds virtuels avec Azure Container Instances.
• Une latence mineure dans l’environnement due à un tronçon supplémentaire pour la communication des pods est acceptable.
• La surcharge opérationnelle liée à la gestion des tables de routage et des routes définies par l’utilisateur dans l’environnement de développement est acceptable.
• L’environnement de développement utilise uniquement des pools de nœuds Linux.

Avec kubenet, la plateforme Azure crée et configure automatiquement les ressources de réseau virtuel lorsque vous créez un cluster AKS. Vous pouvez créer et configurer manuellement les ressources de réseau virtuel et joindre ce dernier à ces ressources au moment de la création. Toutefois, la modification des ressources réseau managées par Azure n’est pas prise en charge.

Production

Gardez à l’esprit qu’il existe plusieurs facteurs qui peuvent empêcher kubenet d’être une option de mise en réseau acceptable pour la production. Kubenet resplendit comme une méthode rapide pour prototyper et tester de petites applications en développement.

Au lieu de cela, Azure CNI est plus adapté aux environnements de production pour son option de mise en réseau configurable qui inclut :

• Latence réduite.
• Possibilité de mise à l’échelle rapide via des nœuds virtuels avec Azure Container Instances.
• Des pods directement adressables simplifient la connectivité aux services qui s’exécutent en dehors du cluster.
• Prise en charge des topologies réseau avancées et des fonctionnalités associées.

Vous pouvez également choisir d’utiliser Azure CNI pour les environnements de développement si une ou plusieurs fonctionnalités sont nécessaires pour votre cas d’usage. Par exemple, si des nœuds Windows Server sont nécessaires, Azure CNI doit être utilisé à la fois pour les clusters de développement et de production. N’oubliez pas que ce choix introduit la nécessité d’une supplémentaire planification de topologie de réseau, ce qui exige un expert.