Apache Hadoop Yarn contre Kubernetes
- Depuis les versions 2.6 (Apache Hadoop) Yarn gère les conteneurs docker. Fondamentalement, il distribue la quantité demandée de conteneurs sur un cluster Hadoop, redémarre les conteneurs défaillants, etc.
- Kubernetes semblait faire le même.
Quelles sont les principales différences?
Kubernetes est développé presque à partir d'une table rase pour étendre le noyau du conteneur Docker pour devenir une plate-forme. Le développement de Kubernetes a adopté une approche ascendante. Il a une bonne optimisation pour spécifier les exigences de ressources par conteneur/pod, mais il manque un planificateur global efficace qui peut partitionner les ressources en regroupement logique. La conception de Kubernetes permet à plusieurs planificateurs de s'exécuter dans le cluster. Chaque planificateur gère les ressources au sein de ses propres modules. Cependant, le cluster Kubernetes peut souffrir d'instabilité lorsque l'application demande plus de ressources que les systèmes physiques ne peuvent en gérer. Il fonctionne mieux en termes de capacité d'infrastructure dépassant les demandes des applications. Le planificateur Kubernetes tentera de remplir les nœuds inactifs avec les demandes d'application entrantes et de mettre fin aux conteneurs de faible priorité et de famine pour améliorer l'utilisation des ressources. Les conteneurs Kubernetes peuvent s'intégrer à un système de stockage externe comme S3 pour fournir une résilience aux données. Le framework Kubernetes utilise etcd pour stocker les données du cluster. Les nœuds de cluster Etcd et Hadoop Namenode sont tous deux des points de défaillance uniques dans la plate-forme Kubernetes ou Hadoop. Etcd peut avoir plus de réplique que Namenode, donc, du point de vue de la fiabilité, il semble favoriser Kubernetes en théorie. Cependant, la sécurité de Kubernetes est ouverte par défaut, sauf si RBAC est défini avec une liaison de rôle à granularité fine. Le contexte de sécurité est correctement défini pour les pods. S'il est omis, le groupe principal du module par défaut sera root, ce qui peut être problématique pour les administrateurs système essayant de sécuriser l'infrastructure.
Apache Hadoop YARN a été développé pour exécuter des processus isolés Java pour traiter la charge de travail Big Data, puis amélioré pour prendre en charge les conteneurs Docker. YARN fournit une gestion des ressources au niveau mondial, comme des files d'attente de capacité pour le partitionnement des ressources physiques en unités logiques. Chaque entreprise l'unité peut être affectée avec un pourcentage des ressources du cluster. Le système de partage des ressources de capacité est conçu en faveur de la disponibilité des ressources garanties pour la priorité Entreprise au lieu de réduire toutes les ressources physiques disponibles. YARN marque plus de points en matière de sécurité. Il y a plus de fonctionnalités de sécurité à Kerberos, contrôle d'accès pour les conteneurs privilégiés/non privilégiés, les images de docker de confiance et les contraintes de stratégie de placement. La plupart des sécurités liées aux dockers sont fermées par défaut et l'administrateur système doit activer manuellement les indicateurs pour accorder plus de puissance aux conteneurs. Les grandes entreprises ont tendance à exécuter Hadoop plus que Kubernetes car la sécurisation du système coûte moins cher. Il existe davantage de moteurs SQL distribués p de YARN, y compris Hive, Impala, SparkSQL et IBM BigSQL. Les options de base de données font de YARN une option intéressante car il permet d'exécuter le traitement des transactions en ligne dans des conteneurs et le traitement analytique en ligne à l'aide d'une charge de travail par lots. Les chaînes d'outils Hadoop Developer peuvent être écrasantes. Mapreduce, Hive, Pig, Spark et etc, chacun a son propre style de développement. L'expérience utilisateur est incohérente et prend un certain temps pour les apprendre tous. Kubernetes se sent moins obstructif en comparaison car il ne fait que déploie des conteneurs Docker. Avec l'introduction des services YARN pour exécuter la charge de travail du conteneur Docker, YARN peut sembler moins verbeux que Kubernetes.
Si vous prévoyez d'externaliser les opérations informatiques source vers le cloud public, choisissez Kubernetes. Si votre plan est de construire un cloud privé/hybride/multi-cloud, choisissez Apache YARN.
Alors que cette question et réponse n'est pas exactement ce que vous demandez, cela touche un certain nombre des mêmes points.
La dernière fois que j'ai vu, Yarn n'était qu'un mécanisme de partage de ressources, tandis que Kubernetes est une plate-forme entière , englobant ConfigMaps, la gestion de l'environnement déclaratif, la gestion secrète, les montages de volume, une API très bien conçue pour interagir avec toutes ces choses, le contrôle d'accès basé sur les rôles et Kubernetes est largement utilisé, ce qui signifie que l'on peut très facilement trouver des candidats à embaucher et des outils à acheter.
A article de blog J'ai trouvé cité un mémoire de maîtrise qui décrit certains des compromis fascinants entre la vision du monde des différents programmateurs. C'est beaucoup de mots, donc si vous cherchez un tl; dr réponse, ce lien ne l'est peut-être pas, mais si vous cherchez une recherche réelle sur le sujet, cela semble solide.