Éleveur avec bétail vs éleveur avec Kubernetes vs autonome Kubernetes
J'essaie de creuser dans Rancher et je me demandais si le fait que Rancher soit connecté à Kubernetes présente des avantages supplémentaires par rapport à Cattle, qui est le cadre d'orchestration de Rancher chez lui. Jusqu'ici, je n'ai pas pu comprendre pourquoi quelqu'un opterait pour Rancher avec Kubernetes. Cela facilite-t-il seulement la configuration initiale de Kubernetes? En quoi ces options diffèrent-elles d'une configuration autonome de Kubernetes?
Il existe maintenant une très bonne réponse à cette question. Rancher vient tout juste d’emménager à Kubernetes en annonçant Rancher 2.0: http://rancher.com/announcing-rancher-2-0/ . Il n'utilise plus de bétail.
Après plus d'un an d'utilisation simultanée de Rancher + Cattle et de Kubernetes en production, je peux partager quelques observations personnelles, mais permettez-moi d'abord de partager quelques réflexions sur Kubernetes vs Rancher + Battle:
- Kubernetes est incroyablement flexible et conçu pour être extensible. Le cluster Kubernetes repose sur deux piliers - kube-apiserver en tant qu’unité principale et etcd en tant que stockage. D'autres composants de base sont essentiels pour un cluster, mais ils ont été conçus pour utiliser l'API de kube-apiserver comme toute extension Kubernetes. Vous pouvez concevoir votre cluster comme vous le souhaitez, utiliser différents fournisseurs de réseau, services d'authentification/autorisation, fournisseurs de volume et remplacer presque tous les composants du cluster. S'il est configuré correctement, votre cluster Kubernetes étendu sera plus stable qu'un cluster Cattle de base dans presque tous les cas. , ne parlons pas d’extensions de bétail.
- Kubernetes dispose de nombreuses fonctionnalités prêtes à l'emploi pour conserver vos données, les garder secrètes et en contrôler l'accès. C'est un élément important, rancher-nfs est assez fragile , de plus, le stockage NFS est la seule option plus ou moins stable dont vous disposez dans Cattle pour conserver des volumes, sans mentionner le stockage local.
- Kubernetes est un excès pour les déploiements peu fréquents et le développement dans une petite équipe. Sans aucun doute, Cattle a été créé comme un simple clone de Kubernetes et a hérité de ses concepts de base d'espaces de noms, de pods, de planification, etc., tout en facilitant le déploiement et la maintenance d'un cluster, ce qui le rend utile aux développeurs sans compréhension préalable. conteneurisation et mise en réseau. En raison de sa simplicité, il est devenu pratiquement inutilisable pour des projets de production lourds et en mutation dynamique.
- La communauté Kubernetes se développe rapidement, étant supportée par des fournisseurs de cloud et par un nombre incalculable de projets et de startups open-source, il est donc plus sage d’apprendre Kubernetes que Cattle, qui n’est plus qu’à un pied dans Grave.
- Et enfin - Le bétail est instable, très instable . Surtout si vous envisagez de l'utiliser avec du métal nu. Croyez-moi, vous ne voulez pas utiliser le bétail dans la production.
Et en parlant de Rancher + Kubernetes - C’est une très belle combinaison, l’interface utilisateur Web de Rancher simplifie les concepts de Kubernetes, la maintenance et l’approvisionnement des clusters deviennent beaucoup plus simples, mais il y a toujours des «buts»: Rancher 2.0 est également très instable. , les bugs le rendent inutilisable pour la production maintenant. Je ne peux rien dire sur Rancher 1.x + Kubernetes.
D'après notre expérience, Le bétail n'est qu'un jouet. C'est juste approprié pour le développement ou un petit environnement. Si vous avez utilisé Cattle in PROD, vous saurez ce que je dis.
Mais Rancher est beaucoup plus concis et simple que les K8.
Donc, je suis impatient de le Rancher 2.0 ,
Rancher 2.0 est une plate-forme complète de gestion de conteneurs construite sur Kubernetes.