document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2024-12-26 21:30:55 +08:00
Code Issues Packages Projects Releases Wiki Activity

translated

Browse Source 
translated
This commit is contained in:
Unknown 2017-12-19 22:55:27 +08:00
parent 839e207fec
commit 4397a37ae4
2 changed files with 90 additions and 95 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

95
sources/tech/20171120 Adopting Kubernetes step by step.md
View File

@ -1,95 +0,0 @@
translating by aiwhj
Adopting Kubernetes step by step
============================================================
Why Docker and Kubernetes?
Containers allow us to build, ship and run distributed applications. They remove the machine constraints from applications and lets us create a complex application in a deterministic fashion.
Composing applications with containers allows us to make development, QA and production environments closer to each other (if you put the effort in to get there). By doing so, changes can be shipped faster and testing a full system can happen sooner.
[Docker][1] — the containerization platform — provides this, making software  _independent_  of cloud providers.
However, even with containers the amount of work needed for shipping your application through any cloud provider (or in a private cloud) is significant. An application usually needs auto scaling groups, persistent remote discs, auto discovery, etc. But each cloud provider has different mechanisms for doing this. If you want to support these features, you very quickly become cloud provider dependent.
This is where [Kubernetes][2] comes in to play. It is an orchestration system for containers that allows you to manage, scale and deploy different pieces of your application — in a standardised way — with great tooling as part of it. It’s a portable abstraction that’s compatible with the main cloud providers (Google Cloud, Amazon Web Services and Microsoft Azure all have support for Kubernetes).
A way to visualise your application, containers and Kubernetes is to think about your application as a shark — stay with me — that exists in the ocean (in this example, the ocean is your machine). The ocean may have other precious things you don’t want your shark to interact with, like [clown fish][3]. So you move you shark (your application) into a sealed aquarium (Container). This is great but not very robust. Your aquarium can break or maybe you want to build a tunnel to another aquarium where other fish live. Or maybe you want many copies of that aquarium in case one needs cleaning or maintenance… this is where Kubernetes clusters come to play.
![](https://cdn-images-1.medium.com/max/1600/1*OVt8cnY1WWOqdLFycCgdFg.jpeg)
Evolution to Kubernetes
With Kubernetes being supported by the main cloud providers, it makes it easier for you and your team to have environments from  _development _ to  _production _ that are almost identical to each other. This is because Kubernetes has no reliance on proprietary software, services or infrastructure.
The fact that you can start your application in your machine with the same pieces as in production closes the gaps between a development and a production environment. This makes developers more aware of how an application is structured together even though they might only be responsible for one piece of it. It also makes it easier for your application to be fully tested earlier in the pipeline.
How do you work with Kubernetes?
With more people adopting Kubernetes new questions arise; how should I develop against a cluster based environment? Suppose you have 3 environments — development, QA and production — how do I fit Kubernetes in them? Differences across these environments will still exist, either in terms of development cycle (e.g. time spent to see my code changes in the application I’m running) or in terms of data (e.g. I probably shouldn’t test with production data in my QA environment as it has sensitive information).
So, should I always try to work inside a Kubernetes cluster, building images, recreating deployments and services while I code? Or maybe I should not try too hard to make my development environment be a Kubernetes cluster (or set of clusters) in development? Or maybe I should work in a hybrid way?
![](https://cdn-images-1.medium.com/max/1600/1*MXokxD8Ktte4_vWvTas9uw.jpeg)
Development with a local cluster
If we carry on with our metaphor, the holes on the side represent a way to make changes to our app while keeping it in a development cluster. This is usually achieved via [volumes][4].
A Kubernetes series
The Kubernetes series repository is open source and available here:
### [https://github.com/red-gate/ks][5]
We’ve written this series as we experiment with different ways to build software. We’ve tried to constrain ourselves to use Kubernetes in all environments so that we can explore the impact these technologies will have on the development and management of data and the database.
The series starts with the basic creation of a React application hooked up to Kubernetes, and evolves to encompass more of our development requirements. By the end we’ll have covered all of our application development needs  _and_  have understood how best to cater for the database lifecycle in this world of containers and clusters.
Here are the first 5 episodes of this series:
1. ks1: build a React app with Kubernetes
2. ks2: make minikube detect React code changes
3. ks3: add a python web server that hosts an API
4. ks4: make minikube detect Python code changes
5. ks5: create a test environment
The second part of the series will add a database and try to work out the best way to evolve our application alongside it.
By running Kubernetes in all environments, we’ve been forced to solve new problems as we try to keep the development cycle as fast as possible. The trade-off being that we are constantly exposed to Kubernetes and become more accustomed to it. By doing so, development teams become responsible for production environments, which is no longer difficult as all environments (development through production) are all managed in the same way.
What’s next?
We will continue this series by incorporating a database and experimenting to find the best way to have a seamless database lifecycle experience with Kubernetes.
_This Kubernetes series is brought to you by Foundry, Redgate’s R&D division. We’re working on making it easier to manage data alongside containerised environments, so if you’re working with data and containerised environments, we’d like to hear from you — reach out directly to the development team at _ [_foundry@red-gate.com_][6]
* * *
_We’re hiring_ _. Are you interested in uncovering product opportunities, building _ [_future technology_][7] _ and taking a startup-like approach (without the risk)? Take a look at our _ [_Software Engineer — Future Technologies_][8] _ role and read more about what it’s like to work at Redgate in _ [_Cambridge, UK_][9] _._
--------------------------------------------------------------------------------
via: https://medium.com/ingeniouslysimple/adopting-kubernetes-step-by-step-f93093c13dfe
作者：[santiago arias][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://medium.com/@santiaago?source=post_header_lockup
[1]:https://www.docker.com/what-docker
[2]:https://kubernetes.io/
[3]:https://www.google.co.uk/search?biw=723&bih=753&tbm=isch&sa=1&ei=p-YCWpbtN8atkwWc8ZyQAQ&q=nemo+fish&oq=nemo+fish&gs_l=psy-ab.3..0i67k1l2j0l2j0i67k1j0l5.5128.9271.0.9566.9.9.0.0.0.0.81.532.9.9.0....0...1.1.64.psy-ab..0.9.526...0i7i30k1j0i7i10i30k1j0i13k1j0i10k1.0.FbAf9xXxTEM
[4]:https://kubernetes.io/docs/concepts/storage/volumes/
[5]:https://github.com/red-gate/ks
[6]:mailto:foundry@red-gate.com
[7]:https://www.red-gate.com/foundry/
[8]:https://www.red-gate.com/our-company/careers/current-opportunities/software-engineer-future-technologies
[9]:https://www.red-gate.com/our-company/careers/living-in-cambridge

90
translated/tech/20171120 Adopting Kubernetes step by step.md Normal file
View File

@ -0,0 +1,90 @@
一步步采用 Kubernetes
============================================================
为什么选择 Docker 和 Kubernetes 呢？
容器允许我们构建，发布和运行分布式应用。他们使应用程序摆脱了机器限制，让我们以一定的方式创建一个复杂的应用程序。
使用容器编写应用程序可以使开发，QA 更加接近生产环境（如果你努力这样做的话）。通过这样做，可以更快地发布修改，并且可以更快地测试整个系统。
[Docker][1] 可以使软件独立于云提供商的容器化平台。
但是，即使使用容器，移植应用程序到任何一个云提供商（或私有云）所需的工作量也是非常重要的。应用程序通常需要自动伸缩组，持久远程光盘，自动发现等。但是每个云提供商都有不同的机制。如果你想使用这些功能，很快你就会变的依赖于云提供商。
这正是 [Kubernetes][2] 登场的时候。它是一个容器编排系统，它允许您以一定的标准管理，缩放和部署应用程序的不同部分，并且成为其中的重要工具。它抽象出来以兼容主要云的提供商（Google Cloud，Amazon Web Services 和 Microsoft Azure 都支持 Kubernetes）。
通过一个方法来想象一下应用程序，容器和 Kubernetes 。应用程序可以视为一条身边的鲨鱼，它存在于海洋中（在这个例子中，海洋就是您的机器）。海洋中可能还有其他一些宝贵的东西，但是你不希望你的鲨鱼与小丑鱼有什么关系。所以需要把你的鲨鱼（你的应用程序）移动到一个密封的水族馆中（容器）。这很不错，但不是特别的健壮。你的水族馆可能会打破，或者你想建立一个通道连接到其他鱼类生活的另一个水族馆。也许你想要许多这样的水族馆，以防需要清洁或维护... 这正是应用 Kubernetes 集群的地方。
![](https://cdn-images-1.medium.com/max/1600/1*OVt8cnY1WWOqdLFycCgdFg.jpeg)
Evolution to Kubernetes
Kubernetes 由云提供商提供支持，从开发到生产，它使您和您的团队能够更容易地拥有几乎相同的环境。这是因为 Kubernetes 不依赖专有软件，服务或另外一些基础设施。
事实上，您可以在您的机器中使用与生产环境相同的部件启动应用程序，从而缩小了开发和生产环境之间的差距。这使得开发人员更了解应用程序是如何构建在一起的，尽管他们可能只负责应用程序的一部分。这也使得在开发流程中的应用程序更容易的快速完成测试。
如何使用 Kubernetes 工作？
随着更多的人采用 Kubernetes，新的问题出现了；应该如何针对基于集群环境开发？假设有 3 个环境，开发，质量保证和生产， 如何适应 Kubernetes？这些环境之间仍然存在着差异，无论是在开发周期（例如：在正在运行的应用程序中看到修改代码所花费的时间）还是与数据相关的（例如：我不应该在我的质量保证环境中测试生产数据，因为它里面有敏感信息）
那么，我是否应该总是在 Kubernetes 集群中编码，构建映像，重新部署服务？或者，我是否不应该尽力让我的开发环境也成为一个 Kubernetes 集群的其中之一（或一组集群）呢？还是，我应该以混合方式工作？
![](https://cdn-images-1.medium.com/max/1600/1*MXokxD8Ktte4_vWvTas9uw.jpeg)
Development with a local cluster
如果继续我们之前的比喻，使其保持在一个开发集群中的同时侧面的通道代表着修改应用程序的一种方式。这通常通过[volumes][4]来实现
一个 Kubernetes 系列
Kubernetes 系列资源是开源的，可以在这里找到：
### [https://github.com/red-gate/ks][5]
我们写这个系列作为练习以不同的方式构建软件。我们试图约束自己在所有环境中都使用 Kubernetes，以便我们可以探索这些技术对数据和数据库的开发和管理造成影响。
这个系列从使用 Kubernetes 创建基本的React应用程序开始，并逐渐演变为能够覆盖我们更多开发需求的系列。最后，我们将覆盖所有应用程序的开发需求，并且理解在数据库生命周期中如何最好地迎合容器和集群。
以下是这个系列的前 5 部分：
1. ks1: 使用 Kubernetes 构建一个React应用程序
2. ks2: 使用 minikube 检测 React 代码的更改
3. ks3: 添加一个提供 API 的 Python Web 服务器
4. ks4: 使 minikube 检测 Python 代码的更改
5. ks5: 创建一个测试环境
本系列的第二部分将添加一个数据库，并尝试找出最好的方式来发展我们的应用程序。
通过在所有环境中运行 Kubernetes，我们被迫在解决新问题的时候也尽量保持开发周期。我们不断尝试 Kubernetes，并越来越习惯它。通过这样做，开发团队都可以对生产环境负责，这并不困难，因为所有环境（从开发到生产）都以相同的方式进行管理。
下一步是什么？
我们将通过整合数据库和练习来继续这个系列，以找到使用 Kubernetes 获得数据库生命周期的最佳体验方法。
这个 Kubernetes 系列是由 Redgate 研发部门的 Foundry 提供。我们正在努力使数据和容器的管理变得更加容易，所以如果您正在处理数据和容器，我们希望听到您的意见，请直接联系我们的开发团队。 [_foundry@red-gate.com_][6]
* * *
我们正在招聘。您是否有兴趣开发产品，创建[未来技术][7] 并采取类似创业的方法（没有风险）？看看我们的[软件工程师 - 未来技术][8]的角色吧，并阅读更多关于在 [英国剑桥][9]的 Redgate 工作的信息。
--------------------------------------------------------------------------------
via: https://medium.com/ingeniouslysimple/adopting-kubernetes-step-by-step-f93093c13dfe
作者：[santiago arias][a]
译者：[aiwhj](https://github.com/aiwhj)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://medium.com/@santiaago?source=post_header_lockup
[1]:https://www.docker.com/what-docker
[2]:https://kubernetes.io/
[3]:https://www.google.co.uk/search?biw=723&bih=753&tbm=isch&sa=1&ei=p-YCWpbtN8atkwWc8ZyQAQ&q=nemo+fish&oq=nemo+fish&gs_l=psy-ab.3..0i67k1l2j0l2j0i67k1j0l5.5128.9271.0.9566.9.9.0.0.0.0.81.532.9.9.0....0...1.1.64.psy-ab..0.9.526...0i7i30k1j0i7i10i30k1j0i13k1j0i10k1.0.FbAf9xXxTEM
[4]:https://kubernetes.io/docs/concepts/storage/volumes/
[5]:https://github.com/red-gate/ks
[6]:mailto:foundry@red-gate.com
[7]:https://www.red-gate.com/foundry/
[8]:https://www.red-gate.com/our-company/careers/current-opportunities/software-engineer-future-technologies
[9]:https://www.red-gate.com/our-company/careers/living-in-cambridge