kubernetes开发环境的比较

There are several ways of providing developers with a Kubernetes work environment and all have advantages and disadvantages.

有几种方法可以为开发人员提供Kubernetes的工作环境，并且各有利弊。

Kubernetes has left the state when it was mostly an ops technology behind and now is also very relevant for many developers. As I wrote in my blog post about the Kubernetes workflow, the first step for every developer who starts to directly work with Kubernetes is to set up/get access to a Kubernetes development environment.

Kubernetes离开时主要是一种运维技术，现在对许多开发人员来说也很重要。 正如我在有关Kubernetes工作流程的博客文章中所写的那样，对于每个开始直接与Kubernetes合作的开发人员而言，第一步是建立/获取对Kubernetes开发环境的访问。

A Kubernetes work environment is not only the first step but also a basic requirement to be able to work with Kubernetes at all. Still, the access to such an environment is often a problem: A VMware study even found out that “access to infrastructure is the biggest impediment to developer productivity”. For this, Kubernetes development environments should have a high priority for every team that plans to use the technology.

Kubernetes的工作环境不仅是第一步，而且是完全能够与Kubernetes一起工作的基本要求。 尽管如此，访问这样的环境仍然是一个问题： VMware的一项研究甚至发现“访问基础架构是开发人员生产力的最大障碍”。 为此，对于每个计划使用该技术的团队来说，Kubernetes开发环境都应该具有较高的优先级。

In this article, I will describe and compare four different Kubernetes development environments and explain when to use which dev environment.

在本文中，我将描述和比较四种不同的Kubernetes开发环境，并说明何时使用哪种开发环境。

1. Local Kubernetes Clusters
   本地Kubernetes集群
2. Individual Cloud-Based Clusters
   各个基于云的集群
3. Self-Service Namespaces
   自助服务命名空间
4. Self-Service Virtual Clusters
   自助式虚拟集群

开发环境的6个评估标准(6 Evaluation Criteria For Dev Environments)

To make the different Kubernetes dev environments comparable, it makes sense to first define the evaluation criteria used. I will rate every environment using the following criteria:

为了使不同的Kubernetes开发环境具有可比性，首先定义所使用的评估标准是有意义的。 我将使用以下标准对每种环境进行评分：

Developer Experience: How easy is it for developers to get started with and to use the environment? This includes factors such as the speed of setup, the ease of use, and the required knowledge by the developers.

开发人员经验：开发人员开始使用该环境有多容易？ 这包括诸如设置速度，易用性以及开发人员所需的知识等因素。

Admin Experience: How easy is it for admins to manage the environments and to manage the system? Here, I will consider the complexity of the system, the effort to manage it, and to add additional users.

管理员经验：管理员管理环境和管理系统有多容易？ 在这里，我将考虑系统的复杂性，管理该系统以及添加其他用户的工作量。

Flexibility/Realism: How realistic is the dev environment compared to the production environment and how flexible is it for different use cases? A good development environment should be very similar to the production environment to avoid “it works on my machine”-problems and it should also be freely configurable and useable for many different use cases (e.g. coding, testing,…).

灵活性/现实主义：与生产环境相比，开发环境的现实性如何？对于不同的用例，它的灵活性如何？ 一个好的开发环境应该与生产环境非常相似，以避免出现“它可以在我的机器上工作”的问题，并且还应该可以自由配置并且可以用于许多不同的用例(例如，编码，测试等)。

Scalability: How scalable is the environment itself and how scalable is the approach if many users are using the system? Especially for complex applications, a lot of computing resources are needed, so the dev environment should be able to provide them. Additionally, the general approach to provide this kind of environment to developers should be feasible also for large teams.

可伸缩性：如果许多用户正在使用系统，环境本身的可伸缩性如何？方法的可伸缩性如何？ 特别是对于复杂的应用程序，需要大量的计算资源，因此开发环境应该能够提供它们。 另外，向大型开发人员提供这种环境的通用方法也应该可行。

Isolation/Stability: How are users isolated from each other and how vulnerable is the system? Developers should be able to work in parallel without interfering with each other and the system they use should be stable and secure to reduce inefficient outages.

隔离度/稳定性：用户之间如何隔离，系统有多脆弱？ 开发人员应该能够并行工作而不会互相干扰，他们使用的系统应该稳定且安全，以减少低效的中断。

Cost: How expensive is this approach? This category should be quite self-explanatory but still is an important factor when choosing the right development environment for your team.

成本：这种方法有多昂贵？ 该类别应该是不言自明的，但是在为团队选择正确的开发环境时，它仍然是一个重要因素。

Now that the evaluation criteria are clear, we can start with the comparison of the Kubernetes development environments:

既然评估标准已经明确，我们就可以开始比较Kubernetes开发环境：

1.本地Kubernetes集群 (1. Local Kubernetes Clusters)

Local Kubernetes clusters are clusters that are running on the individual computer of the developer. There are many tools that provide such an environment, such as Minikube, microk8s, k3s, or kind. While they are not all the same, their use as a development environment is quite comparable.

本地Kubernetes群集是在开发人员的单台计算机上运行的群集。 有许多工具可以提供这种环境，例如Minikube ， microk8s ， k3s或kind 。 尽管它们并不完全相同，但它们在开发环境中的使用却具有可比性。

开发人员经验：- (Developer Experience: -)

Local development environments need to be set up by the developers themselves as they run on their computers. This can be quite challenging, especially as the local setup is always slightly different (different hardware, different operating systems, different configurations, etc.) which makes it harder to provide a very simple setup guide. After the setup is completed, the developers are also responsible to care and manage their environments themselves, which they are often not used to if they do not have previous Kubernetes experience.

开发人员必须在计算机上运行时自行设置本地开发环境。 这可能是非常具有挑战性的，特别是因为本地设置总是稍有不同(不同的硬件，不同的操作系统，不同的配置等)，这使得很难提供非常简单的设置指南。 设置完成后，开发人员还负责自己护理和管理自己的环境，如果他们以前没有Kubernetes经验，他们通常会不习惯。

Therefore, the general developer experience is relatively bad for developers (at least without Kubernetes knowledge).

因此，一般的开发人员经验对开发人员而言相对较差(至少没有Kubernetes知识)。

管理员经验：o (Admin Experience: o)

Admins are not involved in the setup and the management of local Kubernetes clusters. That means that they have no effort here. However, they also do not know if the developers are able to work with their clusters and are generally excluded from the setup and management of the clusters. Still, the admins probably have to support the developers in case of problems and questions.

管理员不参与本地Kubernetes集群的设置和管理。 这意味着他们在这里没有任何努力。 但是，他们也不知道开发人员是否能够使用他们的集群，并且通常不参与集群的设置和管理。 尽管如此，如果出现问题，管理员可能仍必须支持开发人员。

Overall, the admin experience is mediocre because the admins do not face their typical challenges but rather have to educate and support the developers individually.

总的来说，管理员的经验是中等的，因为管理员没有面对典型的挑战，而是必须单独地教育和支持开发人员。

灵活性/现实性：o (Flexibility/Realism: o)

On the one hand, local clusters are always somewhat different from “real” clusters in a cloud environment. They are often pared-down Kubernetes versions that lack some features which cannot be replicated locally (and are often not needed locally). Exemplarily, this can be seen in the name “k3s”, which is an allusion to the original Kubernetes’ “k8s”. On the other hand, the engineers are able to do whatever they want with their local cluster, so they can also flexibly configure it.

一方面，本地集群在云环境中总是与“真实”集群有所不同。 它们通常是精简的Kubernetes版本，缺少一些无法在本地复制的功能(并且通常在本地不需要)。 示例性地，这可以在名称“ k3s”中看到，这是对原始Kubernetes的“ k8s”的暗示。 另一方面，工程师可以使用本地群集执行任何操作，因此他们也可以灵活地对其进行配置。

In sum, local clusters score high in terms of flexible configuration but low on realism as they do not have all Kubernetes features and so cannot be used for any use case.

总而言之，本地集群在灵活性配置方面得分很高，但在现实主义方面得分较低，因为它们不具有所有Kubernetes功能，因此不能用于任何用例。

可扩展性：- (Scalability: --)

Since local clusters can only access the computing resources that are available on the engineer’s computer, they reach their limit for complex applications relatively fast. Also, the approach to let engineers create their local clusters themselves is not really scalable as the same process has to be repeated for every engineer with little options for automation.

由于本地群集只能访问工程师计算机上可用的计算资源，因此它们相对较快地达到了复杂应用程序的极限。 而且，让工程师自己创建本地集群的方法实际上并没有扩展性，因为对于每个工程师来说，几乎没有自动化选择，必须重复相同的过程。

Scalability is thus a clear weakness of local Kubernetes clusters.

因此，可伸缩性是本地Kubernetes集群的明显弱点。

隔离度/稳定性：++ (Isolation/Stability: ++)

Every developer has a separate environment that is completely disconnected from any other environment. In theory, they can even be used without an internet connection. For this, the isolation of local clusters is perfect. This disconnection also ensures that only the individual environment can fail and never all environments at the same time, which minimizes the vulnerability of this approach to provide developers with a Kubernetes environment.

每个开发人员都有一个单独的环境，该环境与任何其他环境完全断开。 从理论上讲，它们甚至可以在没有互联网连接的情况下使用。 为此，隔离本地群集是完美的。 这种断开连接还确保了只有单个环境会发生故障，而不会同时导致所有环境都不会发生故障，这最大程度地降低了此方法为开发人员提供Kubernetes环境的脆弱性。

Isolation and security are definitely a strength of local clusters.

隔离和安全性绝对是本地集群的优势。

费用：++ (Cost: ++)

Local Kubernetes clusters do not require sometimes costly cloud computing resources but only use the locally available computing resources. The different local Kubernetes solutions are all open-source and free to use.

本地Kubernetes集群有时不需要昂贵的云计算资源，而仅使用本地可用的计算资源。 不同的本地Kubernetes解决方案都是开源的，可以免费使用。

Using the local Kubernetes cluster for development does not have any direct cost, so it is the cheapest solution possible.

使用本地Kubernetes集群进行开发不会产生任何直接成本，因此它是最便宜的解决方案。

2.单个基于云的集群 (2. Individual Cloud-Based Clusters)

Individual clusters running in the cloud are the second type of Kubernetes dev environment. They can either be created by the admins who then give an individual access to the developers or the developers are enabled to create them themselves if they have their own account for the cloud provider.

在云中运行的各个集群是Kubernetes开发环境的第二种类型。 它们可以由管理员创建，然后管理员可以单独授予开发人员访问权限，或者如果开发人员拥有自己的云提供商帐户，则可以让他们自己创建开发人员。

开发人员经验：o (Developer Experience: o)

The developer experience can be very different and depends on the way the individual clusters are created: If developers have direct access to the cloud, e.g. with an elaborated Identity and Access Management (IAM), they can create their work environment on-demand and the setup is quite easy (especially in public clouds) as it is always the same. Still, they must do this themselves and might need some help for the management of the cluster.

开发人员的体验可能会非常不同，并且取决于创建各个群集的方式：如果开发人员可以直接访问云，例如使用精心设计的身份和访问管理(IAM)，则可以按需创建他们的工作环境，并且设置非常简单(尤其是在公共云中)，因为它总是一样的。 但是，他们必须自己执行此操作，并且可能需要一些帮助来管理群集。

If admins create the clusters and distribute the access to the developers, the dev experience can become quite bad. While the management of the cluster is now cared for, the admins become a bottleneck. Here, you will face the previously mentioned problem of waiting for central IT to provide the dev environments.

如果管理员创建集群并将访问权限分发给开发人员，则开发人员的经验可能会变得很糟。 现在可以照管群集的管理，而管理员却成为瓶颈。 在这里，您将面临前面提到的等待中央IT提供开发环境的问题。

Overall, in the best case, the dev experience is sufficient if developers have direct cloud access.

总体而言，在最佳情况下，如果开发人员具有直接的云访问权限，那么开发人员的经验就足够了。

管理员经验：- (Admin Experience: --)

No matter in which way the developers get their cluster, the admin experience is always quite bad. If every developer has an own cloud account, the admins will have a hard time getting an overview of the whole system (What is still used? Who is using what?). In this case, they also have to support the developers in managing the clusters. Since the number of clusters grows proportionally with the number of engineers, the effort also grows with the team size.

无论开发人员以哪种方式获取集群，管理经验总是非常糟糕。 如果每个开发人员都有自己的云帐户，则管理员将很难获得整个系统的概述(仍然使用什么？谁在使用什么？)。 在这种情况下，他们还必须支持开发人员管理集群。 由于集群的数量与工程师的数量成比例地增加，因此工作量也随团队规模而增加。

In the case of a central creation and distribution of the clusters by the admins, the administrators will also have a lot of effort. They will have to answer all requests by developers for clusters and configuration changes and have to be always available for them because they are critical for the developers’ performance. In general, many clusters lead to more management effort for admins.

在管理员集中创建和分发群集的情况下，管理员也将付出很多努力。 他们将必须回答开发人员对集群和配置更改的所有请求，并且必须始终可用，因为它们对于开发人员的性能至关重要。 通常，许多集群会为管理员带来更多管理工作。

The individual cloud-based cluster approach is a bad solution from the admin’s perspective and necessarily leads to a lot of work on their side that can even become impossible for them to handle.

从管理员的角度来看，基于云的个体群集方法是一个不好的解决方案，并且必然导致他们身边的许多工作，甚至使他们无法处理。

灵活性/真实性：++ (Flexibility/Realism: ++)

Since the production systems usually also run in Kubernetes in the cloud, having such an environment for development is perfectly realistic. The individual environments can also be freely configured, so they exactly match the needs of the developers or are identical to the production system’s settings.

由于生产系统通常也可以在Kubernetes的云中运行，因此拥有这样的开发环境是完全现实的。 各个环境也可以自由配置，因此它们完全符合开发人员的需求或与生产系统的设置相同。

Individual cloud-based clusters are the best solution to get a highly realistic development environment.

基于单个云的群集是获得高度现实的开发环境的最佳解决方案。

可扩展性：o (Scalability: o)

In terms of scalability, it is important that the clusters are running in a cloud environment, which allows you to scale them up almost infinitely. Still, the scalability criterion also includes the scalability of the general approach for larger teams and here, individual clusters can reach a limit as the admin effort grows with the team size.

在可伸缩性方面，群集在云环境中运行非常重要，这使您几乎可以无限扩展它们。 尽管如此，可伸缩性标准还包括针对较大团队的通用方法的可伸缩性，并且随着管理工作量随团队规模的增长，各个集群可能会达到极限。

Scalability in terms of computing resources is not a problem for individual clusters in the cloud but rolling out such a system in larger organizations will often be infeasible.

对于云中的各个群集而言，就计算资源而言的可伸缩性不是问题，但是在大型组织中推出这样的系统通常是不可行的。

隔离度/稳定性：+ (Isolation/Stability: +)

Having an isolation of developers on a cluster level is very secure. If you are using a public cloud, the isolation of developers is almost the same as the isolation of different companies, which of course is a high priority for the cloud providers.

在群集级别隔离开发人员非常安全。 如果您使用的是公共云，则开发人员的隔离与不同公司的隔离几乎相同，这当然是云提供商的高度优先事项。

100% stability and isolation will probably never be reached in the cloud, but they are as good as possible with individual clusters.

100％的稳定性和隔离性可能永远不会在云中实现，但是对于单个群集而言，它们尽可能地好。

费用：- (Cost: --)

Running many clusters is very expensive. This is due to several factors: At first, you will have a lot of redundancy because every cluster will have its own control plane. Secondly, having oversized or unused clusters is almost inevitable with this approach as either developers are responsible for right-sizing and shutting down clusters or admins have to do it centrally but they do not have the oversight and knowledge what is still used.

运行许多集群非常昂贵。 这是由于以下几个因素引起的：首先，您将具有很多冗余，因为每个群集都有自己的控制平面。 其次，采用这种方法几乎不可避免地会有超大型或未使用的集群，因为要么开发人员负责正确调整集群的大小并关闭集群，要么管理员必须集中管理，但他们没有监督和了解仍在使用的内容。

Additionally, dev environments are also only used if developers are working, so many clusters will probably run idle at night, during holidays and weekends. Finally, public cloud providers charge a cluster management fee that needs to be paid for every cluster, i.e. for every developer in this case.

此外，开发人员环境也仅在开发人员正在工作时使用，因此许多群集可能在夜间，节假日和周末处于空闲状态。 最后，公共云提供商会向每个集群(即，在这种情况下为每个开发人员)收取集群管理费。

Individual clusters for every engineer in the cloud are a very expensive approach to provide Kubernetes development environments.

云中每个工程师的单独集群是提供Kubernetes开发环境的非常昂贵的方法。

3.自助服务命名空间 (3. Self-Service Namespaces)

Instead of giving every developer a whole cluster, it is also possible to just give them Kubernetes namespaces. Again, these can either be created centrally by the admins or developers are provided with a tool to create self-service namespaces on-demand. Providing them centrally comes with many disadvantages I already managed for individual clusters, so I will focus on the self-service namespace approach here.

除了为每个开发人员提供整个集群之外，还可以为他们提供Kubernetes命名空间。 同样，这些可以由管理员集中创建，也可以为开发人员提供按需创建自助名称空间的工具。 集中提供它们会带来我已经为单个集群解决的许多缺点，因此在这里我将重点介绍自助名称空间方法。

开发人员经验：+ (Developer Experience: +)

As engineers can create the namespaces themselves, they are independent of the admins and never have to wait to get a Kubernetes development environment. At the same time, the namespaces are running on a cluster that is managed by admins, so the developers do not have to care for the management of the environment. Namespaces as constructs within clusters will often be enough for simpler development work, so developers will be able to do most standard tasks and are only limited in some situations, e.g. when they need CRDs or want to install Helm charts that use RBAC.

由于工程师可以自己创建名称空间，因此它们独立于管理员，无需等待获取Kubernetes开发环境。 同时，名称空间在由管理员管理的群集上运行，因此开发人员不必关心环境的管理。 命名空间作为集群中的构造通常足以完成更简单的开发工作，因此开发人员将能够执行大多数标准任务，并且仅在某些情况下受到限制，例如，当他们需要CRD或要安装使用RBAC的Helm图表时。

Therefore, the developer experience with self-service namespaces is very good for “standard” development tasks and developers without special Kubernetes configuration requirements.

因此，对于“标准”开发任务和没有特殊Kubernetes配置要求的开发人员来说，具有自助服务名称空间的开发人员经验非常有用。

管理员经验：+ (Admin Experience: +)

Admins need to set up an internal, self-service Kubernetes platform once, which may take some time if they want to build it from scratch, which companies such as Spotify did. Alternatively, it is also possible to buy solutions that add this self-service namespace feature to any cluster, such as Loft. In any case, the admins can focus on other tasks such as the security and stability of the underlying cluster once the system is properly set up. Additionally, it is relatively easy to get an overview of the whole system as everything is running in just one cluster.

管理员需要一次建立一个内部自助式Kubernetes平台，如果想从头开始构建它，这可能会花费一些时间，例如Spotify这样的公司。 或者，也可以购买将此自助服务名称空间功能添加到任何集群的解决方案，例如Loft 。 无论如何，一旦系统正确设置，管理员就可以专注于其他任务，例如基础群集的安全性和稳定性。 此外，由于整个系统都在一个集群中运行，因此获得整个系统的概述相对容易。

Self-service namespaces are an admin-friendly solution that requires some initial setup effort.

自助名称空间是一种易于管理的解决方案，需要一些初始设置工作。

灵活性/现实性：- (Flexibility/Realism: -)

Since namespaces are running on a shared Kubernetes cluster, it is not possible to configure everything individually by the developers. For example, all engineers have to use the same Kubernetes version and cannot modify cluster-wide resources. Still, namespaces are running in a cloud environment that resembles the production environment, which at least makes namespaces a relatively realistic work environment.

由于名称空间在共享的Kubernetes集群上运行，因此开发人员无法单独配置所有内容。 例如，所有工程师都必须使用相同的Kubernetes版本，并且不能修改群集范围的资源。 尽管如此，名称空间仍在类似于生产环境的云环境中运行，这至少使名称空间成为相对现实的工作环境。

Overall, namespaces may restrict the flexibility of developers in some situations but are generally not an unrealistic dev environment.

总体而言，名称空间在某些情况下可能会限制开发人员的灵活性，但通常不是不切实际的开发环境。

可扩展性：++ (Scalability: ++)

The scalability of a self-service namespace system is very good in both aspects: It is possible to scale up the resources of the namespaces because they are running in the cloud (it is also possible to limit developers to prevent excessive usage, of course). At the same time, it is also no problem to add additional users to the system, especially if it provides a Single-Sign-On option.

自助名称空间系统的可伸缩性在两个方面都非常好：可以扩展名称空间的资源，因为它们在云中运行(当然也可以限制开发人员以防止过度使用) 。 同时，向系统添加其他用户也没有问题，特别是如果它提供了Single Sign-On选项。

Namespaces are an efficient way of providing many developers with a Kubernetes environment that can be flexibly scaled up or down.

命名空间是为许多开发人员提供可灵活扩展或缩减的Kubernetes环境的有效方法。

隔离度/稳定性：- (Isolation/Stability: -)

Namespaces are a native solution for Kubernetes multi-tenancy but the isolation is not perfect and rather a form of soft multi-tenancy. However, since the tenants (developers) are trusted, this is not necessarily a problem for development environments. Additionally, namespaces share the same underlying cluster, which means that all namespaces fail if the cluster is down, so the stability of the cluster is essential.

命名空间是Kubernetes多租户的本机解决方案，但隔离不是完美的，而是一种软多租户的形式。 但是，由于承租人(开发人员)是受信任的，所以这对于开发环境而言不一定是问题。 此外，名称空间共享同一基础群集，这意味着如果群集关闭，所有名称空间都会失败，因此群集的稳定性至关重要。

Namespaces are a Kubernetes-native isolation solution, but it is certainly not perfect. However, if the underlying cluster is running solidly, namespaces are still a good solution for trusted engineers within an organization.

命名空间是Kubernetes原生的隔离解决方案，但它当然不是完美的。 但是，如果基础群集运行良好，那么对于组织内的受信任工程师而言，名称空间仍然是一个不错的解决方案。

费用：o (Cost: o)

To get the self-service experience, you might need to buy a self-service namespace software. Additionally, namespaces running in a cloud environment are not free as they also require cloud computing resources. However, the underlying cluster and its resources can be shared by many developers, which drives utilization up and prevents unnecessary redundancies. It is also easier to get a central overview of what is running idle, so these namespaces can be shut down. This process can even be automized by a sleep mode.

为了获得自助服务体验，您可能需要购买自助服务名称空间软件。 此外，在云环境中运行的名称空间不是免费的，因为它们还需要云计算资源。 但是，许多开发人员可以共享基础群集及其资源，从而提高了利用率并防止了不必要的冗余。 获得空闲状态的集中概述也更加容易，因此可以关闭这些名称空间。 这个过程甚至可以通过睡眠模式实现自动化。

Overall, namespaces are a very cost-efficient approach to provide developers with Kubernetes access.

总体而言，名称空间是为开发人员提供Kubernetes访问的一种非常经济高效的方法。

4.自助式虚拟集群 (4. Self-Service Virtual Clusters)

Virtual clusters (vClusters) are a solution that lets you create Kubernetes clusters within a Kubernetes cluster. Like namespaces, virtual clusters run on a single physical cluster and can be created on-demand by developers if they have access to a vCluster platform.

虚拟集群(vClusters)是一种解决方案，可让您在Kubernetes集群中创建Kubernetes集群。 像名称空间一样，虚拟集群在单个物理集群上运行，并且如果开发人员可以访问vCluster平台，则可以由开发人员按需创建。

开发人员经验：++ (Developer Experience: ++)

The developer experience with virtual clusters is similar to namespaces. Developers can easily create them on-demand and are so independent of central IT but still do not have to manage the underlying cluster themselves. At the same time, vClusters feel like “real” clusters for developers, so they will usually not be limited by them at all.

虚拟集群的开发者体验类似于名称空间。 开发人员可以轻松地按需创建它们，并且它们独立于中央IT，但仍然不必自己管理基础集群。 同时，对于开发人员而言，vClusters感觉像是“真实的”集群，因此它们通常完全不受它们的限制。

Therefore, the dev experience with vClusters is similarly good as with namespaces but even gives the developers more freedom to do and configure what they want.

因此，vClusters的开发经验与名称空间类似，但是甚至为开发人员提供了更多的自由来执行和配置他们想要的东西。

管理员经验：++ (Admin Experience: ++)

Considering the admin experience, it is again very similar for self-service namespaces and vClusters. After the initial setup, the management effort for admins is very limited, so they can focus on other tasks again. However, compared to namespaces, vClusters isolate users better and so make it less likely that developers can get the underlying cluster to crash. Additionally, most of the Kubernetes configuration and installation can happen in the vCluster so that the underlying cluster can be very simple and just has to provide the basic features, which makes the admins’ job even easier.

考虑到管理员的经验，自助式名称空间和vClusters再次非常相似。 初始设置后，管理员的管理工作非常有限，因此他们可以再次专注于其他任务。 但是，与名称空间相比，vClusters可以更好地隔离用户，因此使开发人员使基础群集崩溃的可能性较小。 此外，大多数Kubernetes的配置和安装都可以在vCluster中进行，因此基础群集可以非常简单，只需提供基本功能即可，从而使管理员的工作更加轻松。

A self-service vCluster platform thus also provides a very smooth admin experience once it has been set up properly.

一旦正确设置，自助服务vCluster平台也将提供非常流畅的管理员体验。

灵活性/现实主义：+ (Flexibility/Realism: +)

Virtual Clusters run in the cloud, which makes them quite realistic dev environments, especially because the developers can configure them individually to fit their needs. However, vClusters are not exactly the same as real clusters, so the realism is not as perfect as with individual clusters.

虚拟集群在云中运行，这使它们成为相当逼真的开发环境，尤其是因为开发人员可以单独配置虚拟集群以满足他们的需求。 但是，vClusters与真实集群并不完全相同，因此现实主义并不像单个集群那样完美。

Overall, vClusters can be flexibly configured to meet the requirements of different use cases. Since they are a virtual construct, they are still some minor differences to physical clusters.

总体而言，vClusters可以灵活配置以满足不同用例的要求。 由于它们是虚拟构造，因此它们与物理群集之间仍然存在一些细微差异。

可扩展性：++ (Scalability: ++)

The scalability of vClusters is as good as for namespaces. vClusters can have different and basically endless computing resources in the cloud. The self-service provisioning on a platform that runs on a single cluster also makes it possible to use vClusters with many engineers.

vClusters的可伸缩性与名称空间一样好。 vClusters可以在云中拥有不同且基本上无穷无尽的计算资源。 在单个群集上运行的平台上的自助式配置还使vClusters与许多工程师一起使用成为可能。

A self-service vCluster solution will fulfill all needs in terms of scalability for development environments.

自助服务vCluster解决方案将满足开发环境可伸缩性方面的所有需求。

隔离度/稳定性：o (Isolation/Stability: o)

The isolation of virtual clusters is better than the isolation on a namespace-level, but vClusters are still a form of Kubernetes multi-tenancy and as such, the vClusters share a common physical cluster. A benefit of virtual clusters is that the underlying cluster can be very basic, which makes it easier to get it stable.

虚拟集群的隔离比命名空间级别的隔离要好，但是vClusters仍然是Kubernetes多租户的一种形式，因此vClusters共享一个公共的物理集群。 虚拟集群的一个好处是基础集群可以是非常基础的，这使得稳定集群变得更加容易。

Overall, the isolation of vClusters is decent and the stability of the whole system can be quite good. However, a lot of the stability is determined by the stability of the underlying cluster.

总体而言，vClusters的隔离性很好，并且整个系统的稳定性可以很好。 但是，很多稳定性是由基础群集的稳定性决定的。

费用：o (Cost: o)

A virtual cluster platform is not free because it requires cloud computing resources and a software for the platform. In this category, vClusters are again very similar to namespaces: The cluster sharing improves the utilization and makes it easier to get an overview and to shut down unused virtual clusters, which can again even be automized by a sleep mode.

虚拟集群平台不是免费的，因为它需要云计算资源和该平台的软件。 在此类别中，vClusters再次与名称空间非常相似：群集共享提高了利用率，并使查看概述和关闭未使用的虚拟群集变得更加容易，甚至可以通过睡眠模式将其自动化。

A virtual cluster platform is as cost-efficient as a namespace platform, but all cloud-based solutions will necessarily not be completely free.

虚拟集群平台与命名空间平台一样具有成本效益，但是所有基于云的解决方案都不一定完全免费。

何时使用哪个开发环境 (When to use which dev environment)

After having described the four different types of Kubernetes development environments, the question remains which environment is right for your situation.

在描述了四种不同类型的Kubernetes开发环境之后，问题仍然是哪种环境适合您的情况。

From my experience, many companies and engineers start with local dev environments. The fact that they are free and run on local computers reduces the initial hurdle as no complicated budget approvals are needed. Local environments are also a good solution for hobby developers and small applications but also for Kubernetes experts who know how to handle and set up these environments.

根据我的经验，许多公司和工程师都是从本地开发环境开始的。 它们是免费的并且可以在本地计算机上运行，​​这一事实减少了最初的障碍，因为不需要复杂的预算批准。 对于爱好开发人员和小型应用程序而言，本地环境也是一个很好的解决方案，但对于知道如何处理和设置这些环境的Kubernetes专家来说，本地环境也是一个很好的解决方案。

As organizations progress on their cloud-native journey, they want to roll out Kubernetes to more developers who do not have any experience with Kubernetes. These organizations often start with the “obvious” solution: Just give every developer an own cluster. After some time, they then often realize that this approach is very expensive and becomes more complex with a growing number of developers working with it. For this, the individual cloud-based cluster solution is often just a temporary solution unless the number of developers is relatively low and the cost so does not matter too much.

随着组织在云原生之旅中的进步，他们希望将Kubernetes推广给更多没有使用Kubernetes经验的开发人员。 这些组织通常从“显而易见的”解决方案入手：只需为每个开发人员提供一个自己的集群。 一段时间之后，他们通常会意识到这种方法非常昂贵，并且随着越来越多的开发人员一起使用它而变得更加复杂。 为此，除非开发人员数量相对较低且成本无关紧要，否则基于单个云的群集解决方案通常只是一个临时解决方案。

To avoid the high cost and the management effort for larger teams, many organizations want to provide developers with either namespaces or virtual clusters (virtual clusters are relatively new, so namespaces are still more common). However, as these companies have realized that scalability of the approach matters a lot, they want to do this in an automized fashion and therefore either start developing own internal Kubernetes platforms as Spotify did or just buy existing solutions, such as Loft. Thereby, it depends on the complexity of the application and the expertise and requirements of the developers if namespaces are sufficient or if virtual clusters are a better solution.

为了避免大型团队的高昂成本和管理工作，许多组织希望为开发人员提供命名空间或虚拟集群(虚拟集群相对较新，因此命名空间仍然更为常见)。 但是，由于这些公司已经意识到该方法的可伸缩性非常重要，因此他们希望以一种自动化的方式进行，因此要么像Spotify一样开始开发自己的内部Kubernetes平台，要么就购买诸如Loft之类的现有解决方案。 因此，如果名称空间足够，或者虚拟集群是否是更好的解决方案，则取决于应用程序的复杂性以及开发人员的专业知识和要求。

结论 (Conclusion)

As more companies want their developers to work with Kubernetes, also more developers need to have access to a Kubernetes work environment. For this, there are several options that all have their strengths and weaknesses.

随着越来越多的公司希望其开发人员与Kubernetes合作，更多的开发人员也需要访问Kubernetes工作环境。 为此，有几种选择都有其优点和缺点。

While local development clusters are a good and cheap starting point, they are often not the right solution for inexperienced developers or larger organizations.

尽管本地开发集群是一个好而便宜的起点，但对于经验不足的开发人员或大型组织而言，它们通常不是正确的解决方案。

These organizations then turn to the “obvious” solution of individual cloud-based clusters, which are unbeatable in terms of flexibility and realism but are also hard to manage for admins and can become very expensive.

然后，这些组织转向各个基于云的群集的“明显”解决方案，这些解决方案在灵活性和真实性方面无与伦比，但对于管理员来说也难以管理，并且可能变得非常昂贵。

Finally, shared clusters, which are the basis for either self-service namespaces or virtual clusters, are a solution that combines cost-efficiency with a good developer and admin experience. Although these solutions are not free and require some initial setup effort, they are a long-term solution even for larger companies.

最后，共享集群是自助式名称空间或虚拟集群的基础，是一种结合了成本效益和良好的开发人员和管理员经验的解决方案。 尽管这些解决方案不是免费的，并且需要一些初始设置工作，但即使对于较大的公司，它们也是一个长期的解决方案。

Photo by RawFilm on Unsplash

RawFilm在Unsplash上拍摄的照片

Originally published at https://loft.sh.

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

翻译自: https://itnext.io/kubernetes-development-environments-a-comparison-4a2276254c98