Je migre un certain nombre d'applications d'AWS ECS vers Azure AKS et étant le premier déploiement de production pour moi dans Kubernetes, j'aimerais m'assurer qu'il est correctement configuré dès le départ.
Les applications déplacées utilisent toutes des ressources à des degrés divers, certaines étant plus gourmandes en mémoire et d'autres plus gourmandes en CPU, et toutes s'exécutant à des échelles différentes.
Après quelques recherches, je ne sais pas quelle serait la meilleure approche pour exécuter un seul grand cluster et les exécuter tous dans leur propre espace de noms, ou exécuter un seul cluster par application avec Federation.
Je dois noter que je vais devoir surveiller l'utilisation des ressources par application pour la gestion des coûts (entre autres), et une communication est nécessaire entre la plupart des applications.
Je suis capable de configurer les deux mises en page et je suis sûr que les deux fonctionneraient, mais je ne suis pas sûr des avantages et des inconvénients de chaque approche, si je devrais en éviter une complètement ou si je devrais envisager d'autres options?
4 Réponses :
Comme vous l'avez dit, la communication est nécessaire entre les applications, je vous suggère d'utiliser un seul cluster. L'isolation des applications peut être obtenue en déployant chaque application dans un espace de noms distinct. Vous pouvez collecter des métriques au niveau de l'espace de noms et définir un quota de ressources au niveau de l'espace de noms. De cette façon, vous pouvez agir au niveau de l'application
Parce que vous êtes au début de votre aventure avec Kubernetes, j'irais avec des clusters séparés pour chaque étape que vous avez (ou au moins des développeurs et des prod séparés). Vous pouvez très facilement supprimer votre cluster (je l'ai fait plusieurs fois avec une famine de ressources). Si vous ne définissez pas correctement ces stratégies réseau, vous constaterez peut-être que les services de différentes étapes / espaces de noms (comme le test et le sandbox) communiquent entre eux. Ou des pipelines qui devraient déployer dev pour changer quelque chose dans un autre espace de noms. Pourquoi la production risque-t-elle d'être affectée par le travail de développement?
Même si vous n'avez pas à mettre à niveau le plan de contrôle vous-même, aks a toujours ses versions et ses indicateurs et il est préférable de les tester avant de passer à la production sur un cluster séparé.
Ma décision initiale serait donc de fixer des limites strictes: des clusters différents. Plus tard, une fois que vous aurez plus de connaissances avec aks et kubernetes, vous pourrez revoir votre décision.
Un seul cluster (avec des espaces de noms et RBAC ) est plus facile à configurer et à gérer. Un seul cluster k8s prend en charge la charge élevée .
Si vous voulez vraiment plusieurs clusters, vous pouvez essayer istio multi-cluster ( istio service mesh pour plusieurs clusters) également.
Cela dépend ... Sachez qu'AKS ne prend toujours pas en charge plusieurs pools de nœuds (sur la feuille de route à court terme), vous devrez donc exécuter ces charges de travail dans un type de machine virtuelle à pool unique. Lorsque vous pensez à plusieurs clusters, pensez également aux exigences de la multi-location et au rayon de souffle d'un seul cluster. Je vois généralement des utilisateurs déployer plusieurs clusters même s'il y a une certaine surcharge de gestion, mais de bonnes pratiques de gestion de la configuration et du SCM peuvent aider avec cette surcharge.
il suffit d'ajouter une note qu'il prend désormais en charge plusieurs pools de nœuds. laissant cela ici pour quiconque trouve que cela va de l'avant.
C'est une énorme discussion architecturale mais mes 2 cents. Je suggère d'utiliser 1 cluster avec plusieurs espaces de noms. Votre cluster unique pourrait avoir différents types de nœuds (certains avec peu de CPU / RAM et des nœuds hautes performances). Vous pouvez ensuite utiliser
NodeSelector,taints,tolérancespour lier les applications qui exigent des performances élevées à des nœuds qui fournissent des performances élevées. Le tout géré par un serveur API.Malheureusement, vous ne pouvez pas encore faire cela dans AKS, tous les nœuds doivent être de la même VM de spécification.