我几乎可以肯定的是，我们将选择Docker作为容器，而Swarm作为业务流程。但是，我希望在我们的领域中看到Kubernetes，因此可以将这些技术合并在一起以获得更强大的解决方案的提议吸引了我。感谢任何见识。
#1 楼
更新：Docker刚刚发布了对Kubernetes作为调度程序的支持，这改变了现状，并使Kubernetes成为Docker Swarm的替代调度程序。TL; DR：不要这样做。工程师们总是试图创造这些狗。您带来的每一项不必要的技术都会带来另一整套故障。如果您可以选择一个，那么选择一个就可以了，您不必两者都做。如果您想使用Kubernetes，只需在Google Cloud上获得一个私人帐户即可随意使用它。但是，不要让公司中的每个人都遭受不必要的麻烦。
这是两个并行且基本相同的技术。例如，如果您的企业出于正当的商业理由需要在多个云提供商中进行部署以提高可靠性，并且想同时部署到AWS ECS（基于Docker的弹性容器服务）和Google GKE（基于Kubernetes的容器引擎）中，您想知道如何您是否建立了一个管道，该管道将在容器中构建软件和程序包以在两者中进行部署，这是另一回事，但是仅仅因为您想使用一种新技术就这样做是不负责任的。
评论
我不会说我想和Kubernetes一起玩。有商业原因为什么我比Swarm更喜欢它。一个是社区，而您认为我只想做某事的想法是错误的。我不同意您的狗狗评论，它来自于我曾经多次看到/预防过或至少尝试过的系统工程师职位。您没有提供任何迹象表明您已经从中吸取了教训，也没有提供任何关于原因的技术细节；我觉得这没有解决我的问题。
–EvanM
17-4-12在11:38
我有时使用“玩游戏”而不是“使用游戏”，部分是出于工作乐趣的考虑，部分是基于母亲的最爱：“您整天都在玩电脑，从不做任何真正的工作。” :)
–吉里·克劳达（Jiri Klouda）
17年4月12日在11:45
知道了，我也是。只是想说明一下，这不是强迫Kubernetes吞噬我公司的喉咙的一半危险尝试。因此是一个问题。直觉是没有“好的”理由，但我也不能简单地忽略该文章。
–EvanM
17年4月12日在11:49
看，我们都去过那里。当您认为另一种技术更好，并且您想以某种方式仍然与另一种技术或至少两者兼而有之，并向他们展示如何选择更好时，企业计划采用一种技术。这是经典。无论您怎么想，都不要为了做到这一点或证明自己是对的而将两者结合在一起。即使您可以证明其合理性，您的工作也是设计解决方案，以免这样做。吻。使它与Swarm一起使用，说服所有人使用Kubernetes或退出并在可以使用Kubernetes的地方工作。
–吉里·克劳达（Jiri Klouda）
17年4月12日在11:53
#2 楼
如果使用或考虑将Azure用作云提供商，则将Kubernetes用作调度程序的一个原因是它们相对较新的AKS服务（托管kubernetes）。在这种情况下，您不会将kubernetes与docker swarm结合使用。对我来说，这清楚地表明了社区的发展方向。我不想学习以后需要扔进垃圾桶的东西。
评论
这里的动词是“引起我的兴趣”。您是公司的一部分。这样做应该有有效的商业理由。不是您的兴趣，不是技术向导，而是将这两者结合在一起的坚实的业务理由。如果没有这样的商业理由，那么发明它就是不道德的。您提出的建议由于个人原因导致浪费业务资源，从道德上讲，这类似于挪用公款。我就是否应对此进行辩论，因为坦率地说，我觉得这次对话是在浪费时间。是的，我是企业的一员，是的，这使我很感兴趣，不，我没有发明任何东西，而且从一开始就没有态度。阴谋是推动技术前进的动力，寻找为什么/为什么不成为工作的一部分，并简单地问那些已经超越您的人的问题是最佳实践。该问题旨在获得实际在这些平台上进行过工作并对该主题有有效意见的人们的反馈。
我不是在寻找关于流行语或可爱缩写的哲学辩论，而是在寻找技术优势或短期缺陷，并在必要时可以弥补空白。发表的所有内容都是没有事实根据的观点。如果您能解释使用哪种技术来解决容器化和编排以及所发现的短期缺点，将不胜感激。在那时，对我和我的企业来说，决定什么是我们最好的选择。研究不是贪污或偷窃，它被称为尽职调查，这是好的技术如何转变为好的解决方案。
那时您可能在错误的论坛中提问。 DevOps是一门有关如何通过文化，流程和技术手段提高业务效率的学科。我们确实对技术进行了热烈的讨论，但这是从这个角度出发的。如果您从严格的技术角度来寻找答案，我相信Kubernetes会有很多技术工作组可以为您提供答案。