Combinez Docker Swarm et Kubernetes

Mon entreprise essaie de rattraper son retard dans l'espace DevOps. J'ai fait beaucoup de recherches sur la conteneurisation des applications et les systèmes d'orchestration qui vont avec. Je suis tombé sur un article (que j'aurais aimé avoir enregistré) où ils parlaient de combiner Swarm avec Kubernetes pour obtenir de meilleures fonctionnalités. Dans cet article, ils n'ont pas défini ce qu'ils ont gagné en faisant cela.

Je me demandais quels avantages cela apporterait-il? L'ajout de la couche supplémentaire de complexité vous donnera-t-il vraiment beaucoup de retour?

EDIT: Je recherche des avantages / inconvénients techniques. KISS est une bonne devise mais ne tient pas dans un débat avec votre PDG ou votre conseil d'administration.

Je suis presque certain que nous allons sélectionner Docker pour nos conteneurs et Swarm pour une orchestration. Cependant, j'aimerais voir Kubernetes dans notre espace afin que la proposition que vous puissiez fusionner les technologies ensemble pour une solution plus robuste m'intrigue. Merci pour tout aperçu.

— EvanM
source

Les mots clés ici sont «m'intrigue». Vous faites partie d'une entreprise. Il devrait y avoir une raison commerciale valable de le faire. Pas votre intérêt, pas la magie technique, une raison commerciale solide pour combiner ces deux. S'il n'y a pas une telle raison commerciale pour commencer, l'inventer est tout simplement contraire à l'éthique. Ce que vous proposez conduit à un gaspillage des ressources de l'entreprise pour des raisons personnelles et, d'un point de vue éthique, cela s'apparente à un détournement de fonds.

— Jiri Klouda

J'ai débattu de l'opportunité de répondre à cela ou non car, franchement, j'ai l'impression que cette conversation est une perte de temps. Oui, je fais partie du monde des affaires, oui ça m'intrigue, non je n'invente rien et l'attitude que vous avez eu dès le départ est injustifiée. L'intrigue est ce qui fait avancer la technologie, rechercher les raisons pour lesquelles / pourquoi pas fait partie du travail et simplement poser des questions à ceux qui vous ont précédé est une meilleure pratique. Cette question visait à obtenir des commentaires de personnes qui ont effectivement travaillé sur ces plateformes et qui ont des opinions valables sur le sujet.

— EvanM

Je ne cherche pas un débat philosophique sur des mots à la mode ou des acronymes mignons Je cherche des avantages techniques ou des lacunes et où les lacunes peuvent être comblées si nécessaire. Tout ce qui a été affiché est une opinion sans argument factuel. J'apprécierais si vous pouviez expliquer quelle technologie vous utilisez pour résoudre la conteneurisation et l'orchestration et les lacunes que vous avez trouvées avec. À ce stade, c'est à moi et à mon entreprise de décider quelle est la meilleure voie à suivre pour nous. La recherche n'est pas un détournement de fonds ou un vol, elle s'appelle duediligence et c'est ainsi que les bonnes technologies se transforment en excellentes solutions.

— EvanM

Vous pourriez alors demander dans un mauvais forum. DevOps est une discipline sur la façon de rendre les affaires plus efficaces grâce à la culture, aux processus et aux moyens techniques. Nous avons une discussion animée sur la technologie, mais c'est dans cette perspective. Si vous cherchez une réponse d'un point de vue strictement technique, je suis sûr qu'il existe de nombreux groupes de travail techniques pour Kubernetes qui peuvent vous donner une réponse que vous recherchez.

— Jiri Klouda

Réponses:

Mise à jour: Docker vient de publier la prise en charge de Kubernetes en tant que planificateur, ce qui change la situation et fait de Kubernetes un planificateur alternatif à Docker Swarm.

TL; DR: NE LE FAITES PAS. Les ingénieurs essaient toujours de créer ces chiens-cochons. Chaque technologie inutile que vous apportez entraînera un autre ensemble de défauts. Si vous pouvez en choisir un, choisissez-en un et soyez heureux de ne pas avoir à faire les deux. Si vous aimez jouer avec Kubernetes, obtenez simplement un compte privé sur Google Cloud et jouez avec lui autant que vous le souhaitez. Mais ne faites pas souffrir tout le monde dans votre entreprise de complications inutiles.

Ce sont deux technologies parallèles et pour la plupart équivalentes . Si votre entreprise avait des raisons commerciales légitimes de se déployer dans plusieurs fournisseurs de cloud pour la fiabilité par exemple et voulait se déployer à la fois dans AWS ECS (Elastic Container Service - basé sur Docker) et Google GKE (Container Engine - basé sur Kubernetes) et vous demandiez comment construisez-vous un pipeline, qui construirait votre logiciel et votre package dans des conteneurs pour le déploiement dans les deux , ce serait autre chose, mais le faire simplement parce que vous voulez jouer avec une nouvelle technologie est très irresponsable.

— Jiri Klouda
source

Je ne dirais pas que je veux «jouer» avec Kubernetes. Il y a des raisons commerciales pour lesquelles je le préfère à Swarm. L'un étant la communauté et votre supposition que je veux juste faire quelque chose est mal. Je ne suis pas en désaccord avec votre commentaire de chien-cochon, venant d'un poste d'ingénieur système que j'ai vu / empêché ces nombreuses fois, ou du moins essayé. Vous n'avez fourni aucune indication que vous avez travaillé avec les leçons apprises, ni aucun détail technique expliquant pourquoi; Je ne pense pas que cela réponde à ma question.

— EvanM

J'utilise «jouer avec» au lieu de «travailler avec», parfois en partie dans le sens de travail amusant et en partie basé sur le favori de ma mère: «Vous jouez avec des ordinateurs toute la journée et ne faites jamais de vrai travail. :)

— Jiri Klouda

Gotcha, je fais de même. Je voulais juste préciser que ce n'était pas une tentative à moitié hasardeuse de forcer Kubernetes à descendre la gorge de mon entreprise. D'où la question. Le sentiment profond est qu'il n'y a pas de «bonne» raison, mais je ne pouvais pas non plus simplement ignorer cet article.

— EvanM

Regardez, nous avons tous été là. L'entreprise envisage d'aller avec une technologie, lorsque vous pensez que l'autre est meilleure et que vous souhaitez en quelque sorte continuer à travailler avec l'autre ou au moins les deux et leur montrer en fin de compte comment votre choix était tellement meilleur. C'est un classique. Peu importe ce que vous pensez, ne combinez pas les deux pour le faire ou pour prouver que vous avez raison. Même si vous pouviez le justifier, votre travail consiste à concevoir la solution pour éviter de le faire. BAISER. Faites-le fonctionner avec Swarm, convainquez tout le monde d'utiliser Kubernetes ou quittez et travaillez sur place où ils utiliseront Kubernetes.

— Jiri Klouda

L'une des raisons de l'utilisation de Kubernetes en tant que planificateur si vous utilisez ou considérez Azure comme fournisseur de cloud est leur service AKS relativement nouveau (kubernetes managés). Dans ce cas, vous ne devez pas combiner kubernetes avec docker swarm.

Pour moi, cela indique clairement où va la communauté. Je ne voudrais pas apprendre quelque chose que je devrai plus tard jeter à la poubelle.

— Chat Botté
source