如何選擇正確的容器編排以及如何進行部署 (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:

在這里做出選擇很困難。當然，這取決于您的要求，因此，讓我列出一些對我來說很重要的要求：

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.
積極發展：容器編排世界還比較年輕。不活動的項目將很快落后，并表示未解決錯誤。我感覺到牛即將出路。因此，我在這里進行介紹。
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緊密集成，因此在這里失敗了，這絕對是不利的一面。
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，因為它不是首先是容器編排系統。對于許多人來說，它嘗試了很多事情，這感覺是不對的。
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，你們都還在運行中。
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，我感到很受力去嘗試一下。？