by Michael Douglass

迈克尔·道格拉斯(Michael Douglass)

如何选择正确的容器编排以及如何进行部署 (How to choose the right container orchestration and how to deploy it)

Running server processes inside containers is here to stay. If your environment is small with a couple of servers running a few dozen containers, you can likely get away with doing everything by hand. Beyond that scale, you need great tooling to deal with the heavy lifting and provide a common, baseline functionality. The alternative is a lot of tedious, error-prone, repetitive, manual work.

在容器内运行服务器进程的过程将一直存在。 如果您的环境很小，并且有几个服务器运行着几十个容器，那么您可能不需手动完成所有工作。 超出这一范围，您需要出色的工具来应对繁重的工作并提供通用的基准功能。 另一种选择是很多繁琐，容易出错，重复的手动工作。

If you do not utilize a CI/CD pipeline and an orchestration system, development and operations will have to perform extreme, continuous collaboration and coordination.

如果您不使用CI / CD管道和业务流程系统，则开发和运营将必须执行极端的，持续的协作与协调。

When I began investigating the world of microservices earlier this year, I had no idea of the extensive support infrastructure I would discover. Kubernetes has been an absolute treasure trove of a find, and Istio appears to be simply amazing for microservices — even though I know I have only scratched the surface of both these technologies.

当我今年初开始研究微服务领域时，我不知道会发现广泛的支持基础架构。 Kubernetes绝对是一个发现的宝库，而且Istio对于微服务而言似乎简直是惊人的-尽管我知道我只是摸索了这两种技术的表面。

From its humble beginnings less than three years ago, Kubernetes has quickly grown to be an amazing orchestration engine employed by countless corporations and embedded in many other projects. As a software designer with multiple decades under my belt, I am quite impressed with the Kubernetes architecture. It is extremely modular and built under the expectation that many pieces can be replaced. In some cases there are already numerous choices for a given component.

从不到三年前的不起眼起步，KubernetesSwift发展成为无数公司使用并嵌入到许多其他项目中的惊人编排引擎。 作为拥有数十年工作经验的软件设计师，我对Kubernetes架构印象深刻。 它具有极高的模块化性，并且可以替换很多部件。 在某些情况下，给定组件已经有很多选择。

All of this newness and multiplicity of choice can make getting started quite daunting. Just as I sit on the precipice of going full bore into Kubernetes, I am struck by a more fundamental decision…

所有这些新颖性和选择的多样性会使入门变得相当艰巨。 就在我正全力投入Kubernetes的悬崖上时，我对一个更根本的决定感到震惊……

做出正确的容器编排选择 (Making the Right Container Orchestration Choice)

As I began to dig deeper into the world of container orchestration, it became apparent that there are more than a few choices available. My instincts told me Kubernetes is the thing to use, but I also began to question how I’d know if I was right. There is nothing quite like uncertainty to make one dig deeper.

当我开始更深入地研究容器编排的世界时，很明显可以选择的余地更多。 我的直觉告诉我，Kubernetes是要使用的东西，但我也开始质疑如何知道自己是否正确。 没有什么比不确定性更深层次了。

The first question I had was, what are the alternatives for container orchestration?

我的第一个问题是，容器编排有哪些替代方案？

After spending a reasonable amount of time searching and reading, here is the list of orchestration systems I could find:

在花了相当长的时间搜索和阅读之后，这是我可以找到的编排系统的列表：

• Kubernetes - The apparent big-daddy of them all. The project itself is very active, and the architecture gives me comfort that continued development is going to be swift and safe. This is my instinctive choice.

  Kubernetes-所有人中明显的老爸。 该项目本身非常活跃，并且该体系结构使我感到放心，持续开发将Swift而安全。 这是我的本能选择。

• Docker Swarm - This is built into Docker by default, and has a lot of core functionality you want in a system. It has a lot of parity with Kubernetes, but it lacks a key item in that the free, open-source version is Role Based Access Control (RBAC). You can get that in the paid, Enterprise version.

  Docker Swarm-默认内置于Docker中，并具有系统中所需的许多核心功能。 它与Kubernetes具有很多同等的优势，但是它缺少一个关键项，因为免费的开源版本是基于角色的访问控制(RBAC)。 您可以在付费的企业版中获得它。

• Marathon on Mesos - Mesos itself is a highly scalable clustering system for running tasks of all kinds. It relies on frameworks to support different kinds of tasks, and Marathon is the plugin which provides the support for container orchestration within the Mesos ecosystem. The list of frameworks is impressive.

  Mesos上的 Marathon -Mesos本身是一个高度可扩展的集群系统，用于运行各种任务。 它依赖于框架来支持各种任务，而Marathon是一个插件，为Mesos生态系统中的容器编排提供支持。 框架列表令人印象深刻。

• Titus - As I was writing this, Netflix open-sourced their internal orchestration system. Thanks Netflix! Titus was designed to provide the tightest of integrations with the Amazon AWS infrastructure (where Netflix maintains its operations). One of their intentions is that other projects will use their technology so that Netflix can use them in the future.

  Titus(Titus) -在我撰写本文时，Netflix 公开了其内部编排系统的源代码 。 感谢Netflix！ Titus旨在提供与Amazon AWS基础架构(Netflix维持其运营)最紧密的集成。 他们的目的之一是其他项目将使用他们的技术，以便Netflix将来可以使用它们。

• Cattle - This is the orchestration engine made for and embedded within the Rancher system. I did not give Cattle a very deep look, since its parent project has apparently bought into Kubernetes as its preferred and primary orchestration engine. The main title on the Rancher website reads, “Enterprise Kubernetes Made Easy.” The page is riddled with how it helps you run Kubernetes clusters. No mention of Cattle exists on the webpage. It is clear the Rancher project has made its choice.

  牛 -这是为Rancher系统制作并嵌入其中的编排引擎。 我没有给Cattle一个非常深刻的印象，因为它的父项目显然已被Kubernetes收购，成为其首选的主要编排引擎。 Rancher网站上的主要标题是“ Enterprise Kubernetes Made Easy”。 该页面充满了如何帮助您运行Kubernetes集群的谜题。 网页上没有提及Cattle。 很明显，Rancher项目已做出选择。

• Nomad - Okay, this is Hashicorp. As a huge fan of Hashicorp, I would feel unjust if I did not give their product at least a once over. The product looks interesting on the surface with some fairly major paywall concerns. Namespaces are only available in the enterprise version. For service discovery, you’d have to add on Consul, and for secret management, you’d need to add on Vault. By a review of the documentation, it also appears to lack basic CNI configuration — the primary discussion for networking configuration is on mapping ports and static IP mappings.

  Nomad民族 -好的，这是Hashicorp。 作为Hashicorp的忠实拥护者，如果我至少一次不给他们产品一次，我会感到不公正。 该产品表面上看起来很有趣，并且存在一些相当大的付费专区问题。 命名空间仅在企业版本中可用。 对于服务发现，您必须添加Consul，对于秘密管理，您需要添加Vault。 通过查阅文档，它似乎也缺少基本的CNI配置-网络配置的主要讨论是在映射端口和静态IP映射上。

• Kontena - This is a visually stunning product. You can run in their cloud offering, or you can setup your own platform master on your infrastructure of choice. If you choose to bring your own infrastructure, you can either choose to connect it to the Kontena Cloud for $15/month or not. The pretty web interface is what you give up in that case. Not having delved beyond a few hours of digging around their site, I am not certain the impact that would cause.
  Kontena-这是一款外观精美的产品。 您可以在他们的云产品中运行，也可以在选择的基础架构上设置自己的平台主机。 如果您选择自带基础架构，则可以选择以每月15美元的价格将其连接到Kontena Cloud。 在这种情况下，您会放弃漂亮的Web界面。 我还没有深入挖掘他们的站点几个小时，所以我不确定会带来什么影响。

There are still others that you find hints of if you look hard enough: Deis, Mantl, Cloud Foundry, and Amazon ECS to name a few. These guys probably deserve more than this simple, honorable mention.

您还可以通过其他方式找到一些提示，例如Deis，Mantl，Cloud Foundry和Amazon ECS。 这些人可能值得这个简单而光荣的提及。

需求至上 (Requirements First)

Making the choice here is difficult. Of course it depends on your requirements, and so let me list out a few important ones to me:

在这里做出选择很困难。 当然，这取决于您的要求，因此，让我列出一些对我来说很重要的要求：

1. Active development: The container orchestration world is relatively young. Inactive projects will quickly fall behind and signify that bugs are not being addressed. I get the sense that Cattle is on the way out. So I’m scratching it off here.

   积极发展：容器编排世界还比较年轻。 不活动的项目将很快落后，并表示未解决错误。 我感觉到牛即将出路。 因此，我在这里进行介绍。

2. No cloud vendor lock-in: I am not interested in being tied to any single cloud provider at this time. Titus falls out here due to its tight integration with AWS, which is definitely a down side here.

   没有云供应商锁定：我现在不希望与任何一个云供应商建立联系。 由于Titus与AWS紧密集成，因此在这里失败了，这绝对是不利的一面。

3. Simplicity: The more complex a system, the harder it will be to operate it. This requirement causes me to drop Mesos out of the running, because it is not a container orchestration system first. It tries to be many things to many people, and that feels like a wrong fit.

   简便性：系统越复杂，操作起来就越困难。 这个要求使我放弃运行Mesos，因为它不是首先是容器编排系统。 对于许多人来说，它尝试了很多事情，这感觉是不对的。

4. CNI Networking: The ability to have trivial network connectivity between my services is important. I do not want the developers spending time on special purpose code for finding dependent services. Docker Swarm and Kubernetes, you are both still in the running.

   CNI网络：在我的服务之间建立简单网络连接的能力很重要。 我不希望开发人员花时间在专用代码上以查找依赖的服务。 Docker Swarm和Kubernetes，你们都还在运行中。

5. Namespaces with RBAC - I work in a corporate environment, and one of my goals is to provide development, QA, staging, and production setups that do not collide. I could setup a separate cluster for each, or I could use RBAC and share my compute power. Docker Swarm, I am sorry to see you go, but this is the end of our journey together. I love Hashicorp, but Nomad too puts this functionality behind a paywall.

   使用RBAC的命名空间-我在公司环境中工作，我的目标之一是提供不会冲突的开发，QA，登台和生产设置。 我可以为每个数据库设置一个单独的集群，也可以使用RBAC并共享我的计算能力。 Docker Swarm，很抱歉看到您离开，但这是我们共同旅程的终点​​。 我爱Hashicorp，但Nomad也把此功能的付费墙。

There you have it, some pretty high-level requirements that pretty quickly whittle down the playing field. It might not seem fair to drop Mesos out on the “simplicity” category. But if you spend half the time I have investigating all of these options, you will understand that at some point you must simplify your decision making in order to actually start moving forward.

在那里，您有一些相当高级的要求，这些要求很快就会使竞争环境缩水。 将Mesos排除在“简单性”类别之外似乎并不公平。 但是，如果您花了一半的时间研究所有这些选项，您将理解，在某些时候您必须简化决策过程才能真正开始前进。

I am left with the bizarre state of having Kubernetes and Kontena still on the list. Kontena is literally an 11th hour investigation. I almost left it relegated to the list of others. If I had done so, this final hour of authorship would have been less painful. But here it is. A decision has to be made, and while I will eventually circle back around to Kontena, Kubernetes is my current vote.

我留下了Kubernetes和Kontena仍然在名单上的怪异状态。 Kontena实际上是第11个小时的调查。 我差点把它降级到其他名单。 如果我这样做了，那么最后一小时的创作就不会那么痛苦了。 但是在这里。 必须做出一个决定，尽管我最终将回到Kontena，但Kubernetes是我目前的投票。

I feel guilty leaving so many amazing projects on the cutting room floor. This is what happens in today’s world of amazing options coupled with the age-old need to make a decision.

我很内leaving地把这么多惊人的项目留在了更衣室。 这就是当今世界上令人惊奇的选择以及古老的决策需要。

Kubernetes入门 (Getting Started With Kubernetes)

So I have chosen Kubernetes to be my container orchestration system of choice. How do I get a cluster operational for testing and production use? The answers to this question are quite varied as well.

因此，我选择Kubernetes作为我选择的容器编排系统。 如何使集群可运行以进行测试和生产使用？ 这个问题的答案也多种多样。

Kubernetes部署方法 (Kubernetes Deployment Methods)

• Minikube: The recommended method to get a single-node Kubernetes running quickly for testing and development purposes. I prefer to see things in full action, so I did not settle for a single node deployment for my tests.

  Minikube ：为了测试和开发目的而使单节点Kubernetes快速运行的推荐方法。 我更喜欢看到一切正常，因此我没有为测试进行单节点部署。

• Kubeadm: This is provided by kubernetes.io as a method to deploy a single-master, multi-node cluster. There are additional instructions for setting up a multi-master configuration, too. I have previously used Kubeadm through some Terraform scripting to setup my Digital Ocean testbed clusters.

  Kubeadm ：这是kubernetes.io提供的一种部署单主，多节点群集的方法。 还有其他有关设置多主机配置的说明。 我以前通过一些Terraform脚本使用Kubeadm来设置我的Digital Ocean测试平台群集。

• Docker Enterprise 2.0: As I was working on this article, Docker announced the upgrade to EE 2.0. This new version now incorporates a full Kubernetes deployment built into the product. From a quick reading, they utilize Swarm to bootstrap the cluster and deploy Kubernetes.

  Docker Enterprise 2.0 ：在撰写本文时，Docker宣布升级到EE 2.0。 现在，该新版本将完整的Kubernetes部署集成到该产品中。 通过快速阅读，他们利用Swarm引导集群并部署Kubernetes。

• Rancher: “Enterprise Kubernetes Made Easy” is their claim. Indeed, I was able to get a full Kubernetes cluster running on Digital Ocean in under an hour by following their guide. My initial reaction was: “Holy cow! Rancher is Amazing.” It supports managing the Kubernetes deployments into many environments and trivializes the High Availability deployment. It purports to allow management of multiple clusters along with managing other orchestration alternatives including their own Cattle and Apache Mesos.

  Rancher ：他们的主张是“ Enterprise Kubernetes轻松实现”。 确实，按照他们的指南，我能够在一个小时内获得在Digital Ocean上运行的完整Kubernetes集群。 我最初的React是：“圣牛！ Rancher很棒。” 它支持在许多环境中管理Kubernetes部署，并简化了高可用性部署。 它声称允许管理多个群集以及管理其他编排替代方案，包括它们自己的Cattle和Apache Mesos。

• Mesosphere DC/OS: Possibly coming in as an even heavier weight champion as a container orchestration system in its own right, but now also able to administer Kubernetes clusters as well. This product appears quite compelling… Except that the really good stuff is under the Enterprise pay wall. I am also unclear from their website if the DC/OS version is free and the DC/OS Enterprise version is paid (or if they are both paid). Anytime I see a “Contact us for pricing,” I tend to move on. This will keep me from looking too closely — apologies to anyone I offended.

  Mesosphere DC / OS ：本身可能是作为容器编排系统的重量更重的冠军，但现在也可以管理Kubernetes集群。 该产品看起来非常引人注目……除了真正的好东西位于企业薪酬壁垒之下。 从他们的网站上我也不清楚DC / OS版本是否免费，而DC / OS Enterprise版本是付费的(还是两者都付费)。 每当我看到“与我们联系以获取价格”时，我都会继续前进。 这将使我避免过于仔细地观察-对我冒犯的任何人表示歉意。

• Kontena’s Pharos - It seems that even companies who have their own complete alternative to Kubernetes cannot keep their hands out of the Kubernetes deployment software initiatives. Their “Usage with Terraform” documentation looks to have a lot of power in making your Kubernetes installation a distinct, composable step. You can setup your infrastructure in one step using whatever tool you have for that and then setup Kubernetes on top of that. setup-infrastructure | install-kubernetes > profit

  Kontena的Pharos-看来，即使是拥有自己完全替代Kubernetes的公司，也无法脱离Kubernetes部署软件计划。 他们的“ 与Terraform一起使用 ”文档看起来在使Kubernetes安装成为一个独特的，可组合的步骤方面具有强大的功能。 您可以使用任何可用的工具来一步设置基础架构，然后在其之上设置Kubernetes。 setup-infrastructure | install-kubernetes > pro setup-infrastructure | install-kubernetes > pro

The list goes on: Pivitol’s Kubo, Apprenda Kismatic, CoreOS Tectonic, RedHat Openshift v3, Openshift Origin, and certainly more.

名单还在继续：Pivitol的Kubo，Apprenda Kismatic，CoreOS Tectonic，RedHat Openshift v3，Openshift Origin，当然还有更多。

托管选项 (Hosted Options)

• Amazon EKS - Elastic Container Service for Kubernetes — An Amazon hosted Kubernetes cluster. This is currently an “In Preview” technology by Amazon. This speaks towards the viability and future of Kubernetes…

  Amazon EKS -Kubernetes的弹性容器服务-Amazon托管的Kubernetes集群。 目前，这是亚马逊的“预览中”技术。 这说明了Kubernetes的可行性和未来……

• Google Kubernetes Engine (GKE) — This is Google’s hosted offering. I would like to say more, but for some reason my account is broken with respect to getting access to it.

  Google Kubernetes Engine(GKE) -这是Google的托管产品。 我想说更多，但是由于某种原因，我的帐户无法访问。

• OpenShift - Red Hat’s online container service.

  OpenShift -Red Hat的在线容器服务。

我的Kubernetes部署选择吗？ (My Kubernetes Deployment Choice?)

For deployment of Kubernetes, I plan on continuing to work with both Kubeadm (possibly replacing that with Pharos) as well as Rancher.

对于Kubernetes的部署，我计划继续与Kubeadm(可能用Pharos替换)和Rancher一起工作。

Rancher showed great promise the first time I used it. The only downside is that I must first have a control machine onto which I install Rancher, but that is a small price to pay. I am not certain that I will want to use the Rancher interface for interacting with my Kubernetes cluster, and so long as it does not get in the way of me using kubectl to control the cluster, we can get along just fine.

我第一次使用Rancher时就表现出了很大的希望。 唯一的缺点是我必须首先有一台安装Rancher的控制机器，但这是一个很小的代价。 我不确定我是否想使用Rancher接口与我的Kubernetes集群进行交互，并且只要它不会妨碍我使用kubectl控制集群，我们就可以很好地相处。

接下来是什么？ (What is Next?)

Now that I have gone through the exercise to understand the world of options, I am ready to go head down and experiment with Kubernetes. There is a lot of exploration I need to do with my deployment methods of choice.

现在，我已经完成了练习，了解了期权的领域，现在可以开始尝试使用Kubernetes了。 我需要对自己选择的部署方法进行很多探索。

I also talked before about Istio which lays on top of Kubernetes to provide even more foundation to support microservice communication and monitoring. Expect more of that in upcoming articles. Oh, and now that I tripped over Kontena, I feel pulled to give it a trial run through. ?

我之前也谈到过基于Kubernetes的Istio，它为支持微服务通信和监视提供了更多基础。 在即将到来的文章中期望更多。 哦，现在我绊倒了Kontena，我感到很受力去尝试一下。 ？

翻译自: https://www.freecodecamp.org/news/how-to-choose-the-right-container-orchestration-and-how-to-deploy-it-41844021c241/