kubernetes 集群_kubernetes虚拟集群作为开发环境

kubernetes 集群

Kubernetes has matured so much recently that it even expanded beyond its original space as operations technology. So, also at least 1.7 million developers are already using Kubernetes as “The State of Cloud Native Development” by the CNCF stated for Q2 2019. And one can only expect this number to rise even further.

Kubernetes最近已经非常成熟，以至于它甚至扩展到了最初的操作技术领域 。 因此，至少有170万开发人员已经在使用CNCB表示的Kubernetes作为2019年第二季度的“云原生开发状态”。而且人们只能期望这个数字还会进一步上升。

While such a fast growth is impressing, it also means that the ecosystem needs to evolve fast to solve the challenges that come with using Kubernetes for other scenarios than operations, such as development. One central challenge, that is also a basic requirement to make efficient Kubernetes development possible in the first place, is how to provide developers a Kubernetes work environment.

尽管这样的快速增长令人印象深刻，但这也意味着生态系统需要快速发展，以解决将Kubernetes用于诸如开发等运营以外的其他场景所带来的挑战。 首先要使有效的Kubernetes开发成为可能的一个基本挑战是如何为开发人员提供Kubernetes的工作环境 。

Since the access to the infrastructure is so critical for efficient workflows, developers even name “waiting for central IT to provide access to infrastructure” their top impediment to work productively, as VMWare’s “The State of Kubernetes 2020” study found out.

由于对基础架构的访问对于有效的工作流程至关重要，因此开发人员甚至将“等待中央IT提供对基础架构的访问”列为他们进行高效工作的最大障碍，正如VMWare的“ Kubernetes 2020年状态”研究发现的那样。

Interestingly, only 6% of executives share this opinion, which might be a reason why this topic has been underestimated in the past. However, executives should obviously take this matter very seriously if they want to increase development productivity.

有趣的是，只有6％的高管对此表示赞同，这可能是该主题过去被低估的原因。 但是，如果要提高开发效率，高管显然应该非常重视这一问题。

In this post, I will describe the problems with the ways Kubernetes access is currently provided to developers and why the rather new concept of virtual Kubernetes clusters (vClusters) might be a better alternative. I will then also shortly describe how to use vClusters to efficiently solve the Kubernetes access challenge.

在这篇文章中，我将描述当前向开发人员提供Kubernetes访问方式的问题，以及为什么虚拟Kubernetes集群(vClusters)这个相当新的概念可能是更好的选择。 然后，我还将简要介绍如何使用vClusters来有效解决Kubernetes的访问挑战。

Kubernetes访问的当前方法 (Current Approaches for Kubernetes Access)

本地Kubernetes (Local Kubernetes)

With local Kubernetes environments such as minikube or k3s, developers can create their own Kubernetes clusters on their local computers. This often leads to developers struggling with the management and setup of these pared-down Kubernetes technologies that are also not completely realistic compared to “real-world”, cloud-based environments. The upside of this approach is that the developers have full control over their environment and can independently create it whenever they need it.

借助minikube或k3等本地Kubernetes环境，开发人员可以在本地计算机上创建自己的Kubernetes集群。 这常常导致开发人员在管理和设置这些精简的Kubernetes技术方面苦苦挣扎，与“真实世界”的基于云的环境相比，这些技术也不是完全现实的 。 这种方法的好处是，开发人员可以完全控制其环境，并可以在需要时独立创建它。

流水线 (Pipelines)

By using a pipeline-based approach, the developers are not in direct contact with developers but rather trigger a pipeline to get their code running in Kubernetes. Such pipelines separate the developers from Kubernetes completely, which means that they usually do not have any option to make configuration changes. The advantage of pipeline-access to Kubernetes is that the developers do not have to manage their Kubernetes environments themselves, but admins can do this. Pipelines also are a relatively robust way of providing Kubernetes access because the developers have so limited access.

通过使用基于管道的方法，开发人员不会直接与开发人员联系，而是会触发管道以使其代码在Kubernetes中运行。 这样的管道将开发人员与Kubernetes完全分开 ，这意味着它们通常没有任何选择来进行配置更改。 通过管道访问Kubernetes的优势在于，开发人员不必自己管理 Kubernetes环境，但是管理员可以做到这一点。 管道也是提供Kubernetes访问的相对健壮的方式，因为开发人员的访问非常有限。

命名空间 (Namespaces)

The Kubernetes-native construct of namespaces allows for multi-tenancy on a shared cluster as every developer gets an individual namespace to work with. However, namespaces are only a soft form of multi-tenancy, which means that the overall system can be less stable because it is possible that one engineer breaks the whole system. Since namespaces are only a construct within Kubernetes, developers are also limited in their options to make configuration changes to Kubernetes. Nevertheless, namespaces are a rather efficient approach to provide Kubernetes access to engineers as the sharing of a cluster is cost-efficient and the ability to create namespaces on-demand is easy for engineers. With existing solutions such as loft (which also offers vClusters, see below), the implementation of a namespace-platform for developers is also quite simple and easy to maintain for admins.

Kubernetes的本机名称空间构造允许在共享集群上进行多租户，因为每个开发人员都可以使用一个单独的名称空间。 但是，名称空间只是多租户的一种软形式 ，这意味着整个系统可能不稳定，因为一个工程师可能会破坏整个系统。 由于名称空间只是Kubernetes中的一种构造，因此开发人员在选择配置以更改 Kubernetes时也受到限制 。 尽管如此，命名空间是一种向Kubernetes提供给工程师访问权限的相当有效的方法 ，因为集群的共享具有成本效益，并且按需创建命名空间的能力对于工程师来说很容易 。 借助loft等现有解决方案(该解决方案还提供vClusters，请参见下文)，对于开发人员来说，命名空间平台的实现也非常简单，并且易于管理员维护 。

个别集群 (Individual Clusters)

In principle, every engineer could just get an individual Kubernetes in the cloud which is even managed by the cloud providers. However, this approach to provide Kubernetes to developers is rarely used as it can easily become extremely expensive, especially as every developer would need some form of admin rights for the cloud provider to be able to create new clusters. Additionally, such a system is very hard to oversee, which leads to an increasing amount of unused computing resources and thus ever-increasing cost. Still, such a setup has some appeal because it would isolate developers perfectly while they still have full cluster access.

原则上，每个工程师都可以在云中获得单个Kubernetes，甚至可以由云提供商进行管理。 但是，这种为开发人员提供Kubernetes的方法很少使用，因为它很容易变得非常昂贵 ，尤其是因为每个开发人员都需要某种形式的管理权限才能使云提供商能够创建新集群。 另外，这种系统很难监督 ，这导致未使用的计算资源的数量增加，从而导致成本不断增加。 尽管如此，这样的设置还是有一定吸引力的，因为它可以在开发人员仍然具有完全集群访问权限的同时将他们完美地隔离开来 。

To get a deeper understanding of the pros and cons of individual clusters vs. shared clusters, take a look at my blog post about this topic.

要更深入地了解单个集群与共享集群的优缺点，请参阅我关于此主题的博客文章 。

用于Kubernetes访问的虚拟集群 (Virtual Clusters for Kubernetes Access)

Virtual Clusters are fully functional clusters that are running on Kubernetes themselves. As such, they are conceptually similar to virtual machines and give the users the feeling of real clusters, while the vClusters actually run on a single physical Kubernetes cluster.

虚拟集群是在Kubernetes本身上运行的功能齐全的集群。 这样，它们在概念上类似于虚拟机，并为用户提供真实集群的感觉，而vClusters实际上在单个物理Kubernetes集群上运行。

For a more detailed introduction to virtual clusters, you can read this article.

有关虚拟集群的更详细介绍， 请阅读本文 。

Virtual Kubernets clusters so combine the advantages and strengths of the current approaches in a way that makes them ideal for development settings and a simple Kubernetes access distribution for developers.

虚拟Kubernets集群因此以某种方式结合了当前方法的优点和优势，使其非常适合开发设置和开发人员的简单Kubernetes访问分配。

• Full Flexibility/Access. As every developer gets an individual virtual cluster, they have full admin access to it and can do whatever they want with it. This includes changing all available configurations, even the Kubernetes version, independently from all the other users that are also working on the same physical cluster.

  完全的灵活性/访问性。 随着每个开发人员获得一个单独的虚拟集群，他们对它具有完全的管理员访问权限，并且可以使用它进行任何操作。 这包括独立于也在同一物理集群上工作的所有其他用户，更改所有可用配置，甚至包括Kubernetes版本。

• Secure Isolation. Even though the developers have all flexibility and even admin access, they are securely isolated within their vClusters that act as dev sandboxes. Breaking out of these is very unlikely which secures the stability of the underlying physical cluster considerably, especially in comparison to namespace-based cluster sharing approaches.

  安全隔离。 即使开发人员具有所有灵活性，甚至具有管理员访问权限，但他们仍可以安全地隔离在充当开发人员沙箱的vCluster中。 突破这些限制的可能性很小，这可以极大地确保基础物理群集的稳定性，尤其是与基于名称空间的群集共享方法相比。

• Limited Admin Effort. Since every dev environment is running on the same physical cluster, there only needs to be one cluster for all engineers. For this, the effort to provide this is much reduced for the sys admins. Again, the secure isolation further reduces the admin effort as it prevents the underlying cluster from breaking due to misconfigurations by the developers. At the same time, the underlying cluster can be a “dumb” cluster without many additional installtions and add-ons.

  有限的管理工作量。 由于每个开发环境都在同一物理群集上运行，因此所有工程师只需一个群集。 为此，对于sys管理员，减少了为此提供的精力。 再次，安全隔离进一步减少了管理工作，因为它可以防止基础群集由于开发人员的错误配置而损坏。 同时，基础群集可以是“哑”群集，而无需进行许多其他安装和附加操作。

• Self-Service. Similar to namespace-based solutions, developers are also enabled to create virtual clusters themselves whenever they need them (as long as they stay within their resource limits). This eliminates the previously mentioned problem of “waiting for central IT to provide access to infrastructure” completely.

  自助服务。 与基于命名空间的解决方案类似，开发人员还可以在需要时(只要在资源限制范围内)自己创建虚拟集群。 这完全消除了前面提到的“等待中央IT提供对基础架构的访问”的问题。

• No Management Effort for Developers. Besides the self-service, also the fact that developers do not need to set up or manage their dev environments themselves improves their productivity a lot. After the admins set up the vCluster platform once and the engineers have access to it, the engineers do not have to care about the infrastructure anymore and can rather focus on their actual development tasks.

  开发人员无需管理。 除了自助服务，开发人员无需自己设置或管理开发环境的事实也大大提高了他们的生产率。 在管理员一次设置vCluster平台并且工程师可以访问它之后，工程师不再需要关心基础架构，而可以专注于他们的实际开发任务。

• Cost Efficiency. Finally, virtual clusters save some cloud computing cost as the underlying environment is shared. Additional features such as an automatic sleep mode makes this approach even more cost efficient as idle times that are a problem with other cloud-based approaches can almost be eliminated. (To learn more about cost savings with shared Kubernetes clusters, take a look at this post.)

  成本效益。 最后，由于共享了基础环境，虚拟集群节省了一些云计算成本。 诸如自动睡眠模式之类的其他功能使该方法更具成本效益，因为几乎可以消除其他基于云的方法所存在的空闲时间。 (要了解有关共享Kubernetes集群节省成本的更多信息， 请参阅此文章 。)

如何有效地向开发人员提供vClusters (How to provide vClusters to developers efficiently)

Virtual clusters and even a direct Kubernetes access for developers are rather new concepts. However, there are already specific solutions to solve both challenges:

虚拟集群甚至对开发人员的直接Kubernetes访问都是相当新的概念。 但是，已经有解决两个挑战的具体解决方案：

阁楼 (loft)

loft is a proprietary solution that facilitates the provisioning of virtual clusters and namespaces to developers and provides the virtual cluster technology in the first place. loft can either be run in your infrastructure (on-premise) or you can use a managed version of it.

loft是一种专有的解决方案，可帮助向开发人员提供虚拟集群和名称空间，并首先提供虚拟集群技术。 放样可以在您的基础结构中(内部部署)运行，也可以使用其托管版本。

In any case, you connect your own Kubernetes cluster to loft and in this cluster, the virtual clusters will be created. Then, you add the developers that are supposed to be able to create vClusters in a self-service way and you can set limits for their computing resource consumption. loft cares for the user management (with optional SSO) and the enforcement of the limits. Additionally, it provides cost saving features such as a sleep mode that reduces cost for unused vClusters.

无论如何，您都将自己的Kubernetes集群连接到放样，并且将在该集群中创建虚拟集群。 然后，添加应该能够以自助方式创建vClusters的开发人员，并且可以设置其计算资源消耗的限制。 loft关心用户管理(带有可选的SSO)和限制的执行。 此外，它还提供节省成本的功能，例如睡眠模式 ，可减少未使用的vCluster的成本。

To get started with loft, follow the loft Quickstart.

要开始使用loft，请遵循loft快速入门 。

Alternatives: The concept of virtual clusters is rather new, so only few solutions for it exist. However, there are also open-source proof-of-concepts for a virtual cluster technology, such as k3v or the project from the Kubernetes multi-tenancy SIG.

替代方案：虚拟集群的概念是一个相当新的概念，因此仅存在很少的解决方案。 但是，也存在用于虚拟集群技术的开源概念验证，例如k3v或Kubernetes多租户SIG的项目 。

开发空间 (DevSpace)

While loft is a solution to create the work environments for the developers, the developers themselves rarely interact directly with loft. They can rather use solutions that are made for development specific use cases, such as the open-source software DevSpace. DevSpace facilitates the introduction of Kubernetes development by standardizing and automating workflows. For example, developers can easily deploy to Kubernetes with the command devspace deploy or they can even develop software directly in Kubernetes with devspace dev.

尽管放样是一种为开发人员创建工作环境的解决方案，但是开发人员本身很少直接与放样进行交互。 他们可以使用针对开发特定用例的解决方案，例如开源软件DevSpace 。 DevSpace通过标准化和自动化工作流来促进Kubernetes开发的引入。 例如，开发人员可以使用devspace deploy命令轻松地将其部署到Kubernetes，甚至可以使用devspace dev在Kubernetes中直接开发软件。

To make the introduction of Kubernetes into the development workflow even easier, there is a loft-devspace-plugin that integrates the loft commands to create virtual clusters directly into DevSpace, so the developers do not even need to know that they are using loft at all.

为了使Kubernetes更加轻松地引入开发工作流程，提供了一个loft-devspace-plugin ，该插件集成了loft命令以将虚拟集群直接创建到DevSpace中，因此开发人员甚至根本不需要知道他们正在使用loft 。

If you want to try out DevSpace, follow the DevSpace getting started-guide.

如果您想试用DevSpace，请遵循DevSpace入门指南 。

Alternatives: There are some alternatives for Kubernetes development tools. Besides DevSpace, Skaffold and Tilt are probably most notable.

替代方案： Kubernetes开发工具有一些替代方案。 除了DevSpace， Skaffold和Tilt可能也是最著名的。

结论 (Conclusion)

Many challenges that companies face or will face when they introduce Kubernetes for developers are already addressed today. The most fundamental of these challenges is how to provide developers a Kubernetes access. Here, virtual Kubernetes clusters are the newest solution that combine the advantages of existing approaches but without their disadvantages. Developers so get a fully isolated, very flexible self-service Kubernetes access that is also cost-efficient and does not require much effort from the sys admins. This makes vClusters a powerful new approach to solve the number one challenge of providing developers with infrastructure access to Kubernetes.

公司在为开发人员引入Kubernetes时面临或将面临的许多挑战已经得到解决。 这些挑战中最根本的问题是如何为开发人员提供Kubernetes访问。 在这里，虚拟Kubernetes集群是结合了现有方法的优点但没有缺点的最新解决方案。 开发人员因此获得了完全隔离的，非常灵活的自助服务Kubernetes访问，这也具有成本效益，并且不需要系统管理员的大量努力。 这使vClusters成为一种强大的新方法，可以解决为开发人员提供对Kubernetes的基础结构访问的第一大挑战。

Solutions such as loft provide all of this out-of-the-box in an engineering-friendly fashion. Combining loft’s vCluster platform with dev tools such as DevSpace makes the transition to Kubernetes even easier. Eventually, this can lead to a situation in which developers can mostly “ignore” the fact that they are using Kubernetes while they still have the freedom to directly interact with Kubernetes if they need it. Such a system will reduce organization-internal resistance against Kubernetes and so contributes to further Kubernetes adoption even during development.

阁楼之类的解决方案以工程友好的方式提供了所有现成的功能。 将loft的vCluster平台与开发工具(例如DevSpace)相结合，可以更轻松地过渡到Kubernetes。 最终，这可能导致这样一种情况：开发人员几乎可以“忽略”他们使用Kubernetes的事实，而他们仍然可以自由地与Kubernetes进行直接交互(如果需要)。 这样的系统将减少组织内部对Kubernetes的抵抗力，因此即使在开发过程中也有助于进一步采用Kubernetes。

Photo by fabio on Unsplash

照片由法比奥上Unsplash

Originally published at https://loft.sh.

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

翻译自: https://medium.com/swlh/kubernetes-virtual-clusters-as-development-environments-c38ad9404e0e

kubernetes 集群