kubernetes方案_为什么采用kubernetes不是最终的解决方案

kubernetes方案

Adopting Kubernetes can only be a first step towards organizational-wide diffusion to get the real Kubernetes benefits.

采用Kubernetes只是向全组织范围扩散以获得Kubernetes真正利益的第一步。

Kubernetes is everywhere. You can easily get this feeling if you hear about one of its many impressive adoption figures. Does that mean that Kubernetes has reached its “final stage” and already brings all its benefits to the companies using it?

Kubernetes无处不在。 如果您了解其众多令人印象深刻的采用数字之一，就可以轻松获得这种感觉。 这是否意味着Kubernetes已进入“最终阶段”，并已将其所有利益带给使用它的公司？

Kubernetes的采用只是第一步 (Kubernetes adoption is only the first step)

To answer this question, it makes sense to take a closer look at what adoption actually means. The term “Kubernetes adoption” is pretty vague and can have a wide range of meanings ranging from embracing Kubernetes in the whole organization running all workloads on it to just having one engineer playing around with it in a test environment.

为了回答这个问题，有必要仔细研究采用的实际含义。 “采用Kubernetes”一词含糊不清，含义广泛，从在整个组织中使用Kubernetes来运行所有工作负载，到只有一名工程师在测试环境中进行尝试。

If you take a closer look at adoption statistics, you will find out that adoption is often still very limited. Gartner, for example, found out that less than 30% of companies are using containerized applications in production and less than 5% of enterprise applications run in a container environment. Further proof that Kubernetes usage is still at an early stage can be found in VMWare’s “The State of Kubernetes 2020” survey which states that 57% of companies are operating fewer than 10 Kubernetes clusters.

如果仔细研究收养统计，您会发现收养通常仍然非常有限。 例如，Gartner发现，只有不到30％的公司在生产中使用容器化应用程序，而只有不到5％的企业应用程序在容器环境中运行 。 在VMWare的“ Kubernetes 2020年状况”调查中可以找到进一步证明Kubernetes使用率的证据， 该调查指出57％的公司运行的Kubernetes集群少于10个。

While these numbers are expected to grow tremendously in the next years, this also means that today, companies that have already “adopted” Kubernetes cannot lean back and enjoy its full benefits yet. Just ticking the next box of fancy technologies by running little, unimportant experiments with Kubernetes does not bring any benefits aside from looking like a modern tech company at first glance.

尽管预计这些数字在未来几年将大大增长，但这也意味着今天，那些已经“采用” Kubernetes的公司仍无法依靠并享受其全部利益。 仅仅通过对Kubernetes进行很少，不重要的实验来打勾下一个新奇的技术框，除了乍看起来看起来像是一家现代科技公司，不会带来任何好处。

However, people will quickly see that such a Kubernetes adoption is quite useless if it ends here and developers may even be disappointed. This is especially true as many developers actually like Kubernetes and want to learn more about it, as the latest Stack Overflow survey discovered.

但是，人们很快就会看到，如果这种Kubernetes的采用到此结束，那将是毫无用处的，并且开发人员甚至可能会感到失望。 正如最新的Stack Overflow调查发现的那样，这尤其如此，因为许多开发人员实际上喜欢Kubernetes，并希望了解更多有关它的信息。

For this, adopting Kubernetes is only the first step towards a meaningful use of Kubernetes.

为此，采用Kubernetes只是朝着有意义地使用Kubernetes的第一步。

您需要实际的Kubernetes扩散 (You need actual Kubernetes diffusion)

What you actually need to get the full benefits of Kubernetes and make your developers happy working with it, is true Kubernetes diffusion, which means an organizational-wide roll-out and access to Kubernetes.

要真正获得Kubernetes的全部好处并让您的开发人员乐于使用它，您真正需要的是真正的Kubernetes扩散，这意味着在整个组织范围内推出和访问Kubernetes。

Although Kubernetes is still a rather new technology, there is little doubt that it is mature enough for this and the initial adoption step can be seen as evaluation period to answer the question IF to use Kubernetes at all. Given its widespread endorsement by major players and cloud providers, Kubernetes has become a dominant technology and you can be fairly sure that it is a future-proof solution.

尽管Kubernetes仍然是一项相当新的技术，但毫无疑问，它已经足够成熟，并且最初的采用步骤可以看作是评估问题的答案，该评估阶段可以回答是否要使用Kubernetes的问题。 鉴于它得到了主要参与者和云提供商的广泛认可，Kubernetes已经成为一种主导技术，您可以肯定地确定它是面向未来的解决方案。

So now, as a next step, you can focus on Kubernetes diffusion, which comes with some new requirements and challenges. Particularly, there are two central questions that need to be answered for a widespread Kubernetes use within an organization and to bring your Kubernetes adoption to the next level:

因此，现在，下一步，您可以专注于Kubernetes扩散，它带来了一些新的要求和挑战。 特别是，要在组织内广泛使用Kubernetes并使您的Kubernetes普及率提高到一个新水平，需要回答两个核心问题：

1.如何使所有人都能使用Kubernetes (1. How to make Kubernetes available for everyone)

The first fundamental question is how to give everyone access to Kubernetes. Solving this question is central because without a Kubernetes access, it is not possible to work with it. That is why this question should be addressed first and with a high priority if you plan a further Kubernetes roll-out for your company.

第一个基本问题是如何使所有人都能使用Kubernetes。 解决这个问题至关重要，因为没有Kubernetes访问，就不可能使用它。 这就是为什么如果您计划为公司进一步部署Kubernetes，则应该首先解决此问题，并将其放在优先位置。

首次采用的解决方案： (Solution for first adoption:)

If you are in the early adoption and experimentation phase, answering this question is relatively simple. You can either just pay the fees for a managed Kubernetes service in a public cloud, which may be a few hundred dollar per month for the cluster management fee and the computing resources, or you let the engineers set their Kubernetes clusters up themselves. The setup can be done in a public cloud, a private cloud, or even on the local computers of the engineers. Since these adopters are Kubernetes experts (or are supposed to become experts) and often also have admin access to the cloud environment, all of this is not a big challenge during the early adoption stage.

如果您处于早期采用和试验阶段，则回答此问题相对简单。 您可以只支付公共云中托管的Kubernetes服务的费用，这可能是每月几百美元的集群管理费和计算资源，或者您可以让工程师自己设置Kubernetes集群。 可以在公共云，私有云甚至工程师的本地计算机上进行设置。 由于这些采用者是Kubernetes专家(或应该成为专家)，并且通常还具有对云环境的管理员访问权限，因此在采用早期阶段，这并不是一个很大的挑战。

传播挑战： (Challenge for diffusion:)

It becomes much more complex during the diffusion stage. Now, not only a few Kubernetes experts with admin rights to a cloud environment need Kubernetes, but every engineer in your organization. To make this efficiently possible, you need an automized way of providing Kubernetes even to non-experts, which rules out local Kubernetes solutions (no automatization, individual setup) and also simple managed Kubernetes offerings (average engineers should not have admin access).

在扩散阶段，它变得更加复杂。 现在，不仅有几位对云环境具有管理员权限的Kubernetes专家都需要Kubernetes，而且组织中的每个工程师也都需要Kubernetes。 为了有效地做到这一点，您需要一种甚至向非专家提供Kubernetes的自动化方式，该方式排除了本地Kubernetes解决方案(不实现自动化，单独设置)以及简单的托管Kubernetes产品(普通工程师不应具有管理员权限)。

扩散解决方案： (Solution for diffusion:)

This means that you need to provide an easy to use internal Kubernetes platform to your engineers that allows them to create a work environment on-demand. At the same time, this self-service platform needs to enforce usage limits to prevent excessive cloud computing cost.

这意味着您需要为工程师提供一个易于使用的内部Kubernetes平台，使他们能够按需创建工作环境。 同时，此自助服务平台需要强制使用限制，以防止过多的云计算成本。

That such an internal platform is the way to go can be seen in the fact that some industry leaders and innovative companies, such as Spotify and Datadog (page 25) have already built them for their engineering teams.

这样的内部平台之路可见一斑，因为一些行业领导者和创新公司，例如Spotify和Datadog (第25页)已经为他们的工程团队建立了它们。

However, developing such a platform from scratch can be quite costly and is not so easy, so it may make sense to build upon existing solutions. kiosk, for example, was exactly made for such a use case and can be used as an underlying multi-tenancy extension for an internal Kubernetes platform.

但是，从头开始开发这样的平台可能会非常昂贵，而且并非易事，因此在现有解决方案的基础上进行开发可能很有意义。 例如， 信息亭正是针对这种用例而制作的，可以用作内部Kubernetes平台的基础多租户扩展。

If this is still too much effort, you can also use an out-of-the-box solution that includes all the self-service, user isolation, and user management features. loft is such a solution that turns any regular Kubernetes cluster into a self-service internal Kubernetes platform for your team. All you have to do in this case is install loft into your Kubernetes cluster that is supposed to serve as internal platform. To try it out, you can follow the loft quickstart.

如果这仍然太费力，您还可以使用开箱即用的解决方案，其中包括所有自助服务，用户隔离和用户管理功能。 loft是一种可以将任何常规Kubernetes集群变成您团队的自助式内部Kubernetes平台的解决方案。 在这种情况下，您要做的就是将loft安装到应该用作内部平台的Kubernetes集群中。 要进行尝试，可以按照loft快速入门进行 。

2.如何使Kubernetes可供所有人使用 (2. How to make Kubernetes useable for everyone)

After you have figured out how to give everyone Kubernetes access, you need to enable engineers to efficiently work with it. The solution to this is essential as Kubernetes can be quite complex and not every engineer is (or should become) a Kubernetes expert, but you still want to ensure that you improve development productivity by introducing Kubernetes.

在弄清楚如何为所有人提供Kubernetes访问权限之后，您需要使工程师能够有效地使用它。 解决方案至关重要，因为Kubernetes可能非常复杂，并非每个工程师都是(或应该成为)Kubernetes专家，但是您仍然希望通过引入Kubernetes来确保提高开发效率。

首次采用的解决方案： (Solution for first adoption:)

Again, this challenge is not really a problem for the initial adoption period, when just a few engineers use and explore Kubernetes. They usually either are Kubernetes experts or can become experts by working with it. Learning and trying out things in Kubernetes is actually part of their job and in the exploration phase, time and efficiency are not so critical.

同样，在最初的采用阶段，当只有少数工程师使用和探索Kubernetes时，这一挑战并不是真正的问题。 他们通常要么是Kubernetes专家，要么可以通过与之合作成为专家。 在Kubernetes中学习和尝试事物实际上是他们工作的一部分，在探索阶段，时间和效率并不是那么关键。

传播挑战： (Challenge for diffusion:)

The situation for wider adoption, i.e. the diffusion phase, is much different. Here, “average” engineers are supposed to work with Kubernetes. However, their job is not to learn and master Kubernetes perfectly, but to get their regular tasks done as efficiently as possible. The use of Kubernetes should thus be as easy, efficient, and as fast as possible, so it does support and does not interfere with their actual work.

广泛采用的情况(即扩散阶段)大不相同。 在这里，“普通”工程师应该与Kubernetes一起工作。 但是，他们的工作不是完美地学习和掌握Kubernetes，而是尽可能高效地完成其常规任务。 因此，Kubernetes的使用应尽可能简单，高效且尽可能快，因此它可以提供支持，并且不会干扰其实际工作。

扩散解决方案： (Solution for diffusion:)

You need to provide solutions to your engineers that cover their whole workflow. This starts with getting a Kubernetes access in a simple way (see Question 1). Then, the engineers need to be able to develop with Kubernetes. For this, there are already some popular open-source tools that facilitate and standardize development workflows, such as DevSpace (which also has an optional loft integration, so creating a Kubernetes work environment and subsequent development can be done with the same tool), Skaffold, or Tilt.

您需要为工程师提供涵盖其整个工作流程的解决方案。 首先从简单的方式获得Kubernetes访问(请参阅问题1 )。 然后，工程师需要能够使用Kubernetes进行开发。 为此，已经有一些流行的开源工具可以促进和标准化开发工作流程，例如DevSpace (它也具有可选的loft集成 ，因此可以使用相同的工具创建Kubernetes工作环境并进行后续开发)， Skaffold或Tilt 。

And finally, the engineers need to be able to easily deploy to Kubernetes, which can either be done with the same tools or with specialized CI/CD tools, such as Jenkins, Circle CI, or Travis CI.

最后，工程师需要能够轻松部署到Kubernetes，这可以使用相同的工具或专用的CI / CD工具(例如Jenkins ， Circle CI或Travis CI)来完成 。

Throughout the whole engineering process, it is important that every step is well documented and that the tools are pre-configured and set up as much as possible, so that the engineers can simply follow standardized guidelines and become productive very fast.

在整个工程过程中，重要的一点是，每个步骤都必须有完整的文档记录，并且必须尽可能地对工具进行预配置和设置，以便工程师可以简单地遵循标准化的指导原则并非常快速地投入生产。

Since it is inevitable that problems occur (some of them are actually desirable because so bugs can be discovered before they enter the production system), it is also important that a constant learning of how to work with these tools and Kubernetes is encouraged and facilitated. (Still, normal engineers should not become k8s experts but should rather know how to handle “standard issues” and understand basic Kubernetes concepts.)

由于不可避免地会发生问题(其中一些问题实际上是可取的，因为这样可以在bug进入生产系统之前就将其发现)，因此鼓励和促进对如何使用这些工具和Kubernetes的持续学习也很重要。 (不过，普通工程师不应该成为k8s专家，而应该知道如何处理“标准问题”并了解Kubernetes的基本概念。)

采用Kubernetes后应该怎么做 (What should you do after you adopted Kubernetes)

To sum up, let’s assume you have successfully adopted Kubernetes at small scale and now want to boost diffusion in your organization. Your next steps should be:

综上所述，假设您已成功采用了小规模的Kubernetes，现在想促进组织中的扩散。 您的下一步应该是：

1. Make Kubernetes easily available in a streamlined process via an internal Kubernetes platform. Either build it yourself from scratch like Spotify, build upon existing solutions such as kiosk or directly start with an off-the-shelf solution like loft.

   通过内部Kubernetes平台以简化的流程轻松使用Kubernetes。 要么像Spotify这样从头开始自己构建它，要么基于现有的解决方案(例如信息亭)构建，或者直接从像loft这样的现成解决方案开始。

2. Prepare the rollout in your organization. Choose tools for development and deployment workflows, write internal documentation, and set up/pre-configure the tools as much as possible.
   准备组织中的首次展示。 选择用于开发和部署工作流的工具，编写内部文档，并尽可能设置/预配置这些工具。
3. Roll out Kubernetes in your organization step-by-step. Maybe kick it off with a training and onboarding session. It’s best to start with just a few engineers or one team and see how the shift to Kubernetes works for them, so you can improve it for the next one.
   逐步在您的组织中推出Kubernetes。 也许通过培训和入职培训就可以开始了。 最好只从几个工程师或一个团队开始，然后看看向Kubernetes的转变对他们的工作原理，因此您可以在下一个团队中进行改进。
4. Continuously improve your system, your workflows, and your communication. Listen to feedback from the engineers and keep educating and helping with problems. You should also monitor the diffusion progress and keep an eye on cloud computing cost.
   不断改善您的系统，您的工作流程和沟通。 倾听工程师的反馈，并继续教育和解决问题。 您还应该监视扩散进度，并注意云计算成本。

结论 (Conclusion)

Kubernetes has now reached the masses of companies but not of people. While initial adoption in form of experimentation is a good first step, it cannot be the final destination to get the real benefits of Kubernetes. The adoption rather needs to continue, so Kubernetes also reaches the majority of engineers. To get to this step without losing productivity, you need to make Kubernetes readily available and easily useable to the engineers by providing them an internal, self-service Kubernetes platform and a variety of tools for their workflows.

Kubernetes现在已经达到了公司的群众，但没有达到人们的群众。 虽然最初采用试验形式是一个很好的第一步，但它并不是获得Kubernetes真正利益的最终目的地。 需要继续采用，因此Kubernetes也吸引了大多数工程师。 为了在不损失生产力的情况下实现这一目标，您需要通过为工程师提供内部自助式Kubernetes平台和用于其工作流程的各种工具，使Kubernetes易于使用并易于被工程师使用。

Photo by Lindsay Henwood on Unsplash

Lindsay Henwood在Unsplash上拍摄的照片

Originally published at https://loft.sh.

最初发布在 https://loft.sh 。

翻译自: https://itnext.io/why-adopting-kubernetes-is-not-the-final-solution-18f867d5a408

kubernetes方案