Est-ce que Kubernetes + Docker + AWS = Azure + Service Fabric?
Je vois les avantages de Kubernetes qui incluent les déploiements continus, la surveillance automatique de la vérification de l'état et le basculement d'un nouveau serveur en action lorsqu'un échec existant échoue. Je comprends également que Kubernetes n'est pas seulement pour Docker.
Donc, cela amène quelques questions!
Lorsque Azure et Service Fabric peuvent fournir tout ce que j'ai dit (et au-delà), pourquoi aurais-je besoin de Kubernetes?
Serait-il sensé d'utiliser Kubernetes avec Service Fabric pour des déploiements à grande échelle sur Azure?
Examinons d'abord les similitudes entre Kubernetes et Service Fabric.
- Ce sont à la fois des logiciels de clustering, d'orchestration et de planification indépendants du cloud.
- Ils peuvent tous les deux être déployés manuellement, par vous, sur n'importe quel ensemble de machines virtuelles, n'importe où.
- Il existe des offres "gérées" pour les deux, ce qui signifie qu'un fournisseur de cloud comme Azure ou Google Cloud hébergera un cluster pour vous, mais généralement vous possédez toujours les machines virtuelles.
- Ils déploient et gèrent tous les deux des conteneurs.
- Ils ont tous deux des opérations de gestion riches, telles que des mises à niveau continues, des contrôles de santé et des capacités d'auto-guérison.
C'est une vue assez élevée, mais cela devrait vous donner une idée de quoi et où vous pouvez exécuter avec chacun.
Voyons maintenant où ils sont différents. Il y a une tonne de petites différences, mais je veux me concentrer sur deux des très grandes différences conceptuelles:
modèle d'application:
- Service Fabric vous permet d'orchestrer n'importe quel conteneur arbitraire ou EXE (qu'il s'agisse d'une petite application node.js ou d'une application héritée géante), et en ce sens, il est similaire à Kubernetes. Mais dans l'ensemble, il est plus axé sur le développement d'applications en particulier, avec des modèles de programmation intégrés à la plate-forme. À cet égard, il est plus comparable à Cloud Foundry qu'à Kubernetes.
- Kubernetes se concentre davantage sur l'orchestration de l'infrastructure d'une application. Il ne se concentre pas vraiment sur comment vous écrivez votre application. C'est à vous de comprendre; Kubernetes veut juste qu'un conteneur s'exécute, peu importe ce qu'il contient.
Gestion de l'État
- Kubernetes vous permet d'y déployer des logiciels avec état, en fournissant des volumes de stockage sur disque persistants aux conteneurs et en attribuant des identificateurs uniques aux pods. Cela vous permet de déployer des choses comme ZooKeeper ou MySQL.
- Service Fabric est un logiciel avec état . Service Fabric est conçu comme une plate-forme dynamique et sensible aux données. Il fournit des primitives d'état HA et de mise à l'échelle. Ainsi, alors que Kubernetes vous permet de déployer des choses avec état, Service Fabric vous permet de construire choses avec état. C'est l'une des principales différences souvent négligées. Par exemple:
- Sur Kubernetes, vous pouvez déployer ZooKeeper.
- Sur Service Fabric, vous pouvez réellement créer ZooKeeper vous-même à l'aide des primitives de réplication et d'élection de leader de Service Fabric.
- Kubernetes utilise etcd pour un stockage distribué et fiable sur l'état du cluster.
- Service Fabric n'a pas besoin etcd, car Service Fabric lui-même est une plate-forme de stockage distribuée et fiable. Les services système de Service Fabric l'utilisent pour stocker de manière fiable l'état du cluster. Cela rend Service Fabric entièrement autonome.
Le fait que Service Fabric soit une plate-forme avec état est essentiel pour la comprendre et en quoi elle diffère des autres principaux orchestrateurs. Tout ce qu'il fait - planification, vérification de l'état, mises à niveau progressives, version des applications, basculement, auto-réparation, etc. - sont tous conçus autour du fait qu'il gère des données répliquées et distribuées qui doivent être cohérentes et hautement disponibles à tout moment.