kubernetes ci_用于ci cd测试的kubernetes虚拟集群

kubernetes ci

How virtual Kubernetes clusters can solve current issues of integrating Kubernetes in CI/CD and testing processes.

虚拟Kubernetes集群如何解决当前在CI / CD和测试过程中集成Kubernetes的问题。

The use of virtual clusters (vClusters) in Kubernetes, i.e. running virtual clusters inside of physical clusters, has the potential to disrupt the use of Kubernetes in a variety of settings, from cloud-native development to machine learning experiments. (For an overview of the general benefits of virtual clusters and their use cases, refer to this article). One of these settings is continuous integration/deployment (CI/CD) and the related testing of software. In this post, I will describe how virtual clusters can be used for CI/CD and testing and what their benefits are for this use case.

在Kubernetes中使用虚拟集群(vClusters) ，即在物理集群内部运行虚拟集群，有可能破坏从云原生开发到机器学习实验的各种设置中对Kubernetes的使用。 (有关虚拟集群的一般好处及其用例的概述，请参阅本文 )。 这些设置之一是持续集成/部署(CI / CD)和相关的软件测试。 在这篇文章中，我将描述如何将虚拟集群用于CI / CD和测试，以及它们在此用例中的好​​处。

现状 (The Status Quo)

To understand the case for virtual clusters for CI/CD and testing, one needs to understand the current state of the art and the basic challenges:

要了解用于CI / CD和测试的虚拟集群的情况，需要了解当前的技术水平和基本挑战：

Many companies nowadays have implemented CI/CD pipelines in their development process to enable engineers to simply run their developed software in a real-life environment. This is also important to properly test the software as only in a real-life environment, realistic testing is possible. The benefit of such a pipeline-based approach is that the engineers do not need to care for or be experts about the environment their software is running in at the other end of the pipeline.

如今，许多公司已在其开发过程中实现了CI / CD管道，以使工程师能够在现实环境中简单地运行其开发的软件。 这对于正确地测试软件也很重要，因为只有在实际环境中，才可以进行实际测试。 这种基于管道的方法的好处是，工程师无需关心或在管道另一端运行其软件的环境，也不必成为专家。

For this, it is possible to even use the most realistic environment, which is the environment of the actual running system, also behind the pipeline and to run tests. And this environment is for many companies now a Kubernetes environment.

为此，甚至可以使用最实际的环境(即实际正在运行的系统的环境)，也在管道后面并运行测试。 对于许多公司来说，这种环境现在是Kubernetes环境。

Still, one question needs to be answered: Where does this environment come from? There are generally two approaches to solve this: The engineers can share one environment, that is managed centrally by an admin, or they can use individual Kubernetes clusters. Sometimes, the approaches are also mixed when micro-teams are sharing clusters. Unfortunately, all of the approaches come with some downsides:

尽管如此，仍然需要回答一个问题：这种环境是从哪里来的？ 通常有两种方法可以解决此问题：工程师可以共享一个环境，该环境由管理员集中管理，或者可以使用单个Kubernetes集群。 有时，当微型团队共享集群时，这些方法也会混杂在一起。 不幸的是，所有方法都有一些缺点：

共享环境 (Shared Environments)

• One-Size-Fits-All / Inflexibility. When all engineers use the same environment, this environment needs to work for all situations. However, this is not always the case because sometimes configuration changes are needed. Since these changes would affect the whole environment, all other engineers would also be affected, which is why engineers are not allowed to make any config changes. This makes the use of shared environments very inflexible.

  一刀切-全能/不灵活。 当所有工程师使用相同的环境时，该环境需要在所有情况下都可以工作。 但是，并非总是如此，因为有时需要更改配置。 由于这些更改会影响整个环境，因此所有其他工程师也将受到影响，这就是为什么不允许工程师进行任何配置更改的原因。 这使得共享环境的使用非常不灵活。

• Instability / Vulnerability. Even if engineers are not allowed to modify the cluster configurations, clusters can crash. And in these situations, all engineers are affected at the same time. This means that such an occasional crash will often completely halt the software development teams and so makes the shared system very critical. This can lead to postponing updates to prevent any risk associated with such an update. In turn, this can lead to workflow disruptions if some engineers have to wait for a necessary update. Additionally, to make the use of a shared environment for CI/CD and testing feasible in the first place, engineers need to be isolated, which is usually done with namespaces that provide a rather weak form of isolation.

  不稳定/漏洞。 即使不允许工程师修改群集配置，群集也可能崩溃。 在这种情况下，所有工程师都会同时受到影响。 这意味着这种偶然的崩溃通常会完全终止软件开发团队，因此使共享系统变得非常关键。 这可能导致推迟更新，以防止与此更新相关的任何风险。 反过来，如果某些工程师必须等待必要的更新，则可能导致工作流程中断。 此外，首先要使共享环境用于CI / CD并进行测试是可行的，工程师需要隔离，这通常是通过名称空间来完成的，该名称空间提供了相当弱的隔离形式。

个别集群 (Individual clusters)

• Cost Inefficiency / Expensiveness. The use of individual clusters for developers is a much more secure and flexible solution. However, it is also very expensive and cost inefficient. Since most CI/CD pipelines have a per-minute-pricing, it is normally not possible to start clusters on demand in the pipeline process because this would hold up the pipeline and increase the cost. For this as well as for general convenience, clusters for CI/CD and testing often keep running all the time, no matter if they are used or not. Given the high cost for computing resources, especially in public clouds, this is a very wasteful way of providing an execution environment.

  成本低效/昂贵。 为开发人员使用单个群集是一种更加安全和灵活的解决方案。 但是，它也非常昂贵并且成本低效。 由于大多数CI / CD管道都有按分钟定价的功能，因此通常无法在管道过程中按需启动集群，因为这会阻塞管道并增加成本。 出于此目的以及通常的便利，用于CI / CD和测试的群集通常始终保持运行状态，无论是否使用它们。 考虑到计算资源的高昂成本，尤其是在公共云中，这是提供执行环境的非常浪费的方式。

• Complexity / No oversight. Additionally, clusters are usually only created by administrators who have more extensive rights that allow them to start or shut down clusters. With the abundance of clusters especially for large teams, it becomes very hard for these admins to keep control as it is not so easy to figure out which clusters are still used and which are running idle and should be shut off. Since engineers will tend to ask for new clusters from time to time, this problem becomes worse over time leading to a situation of many unused clusters that nobody really knows about but still create cost.

  复杂性/无监督。 此外，群集通常仅由拥有更广泛权限的管理员创建，这些管理员可以使它们启动或关闭群集。 由于存在大量的集群，尤其是对于大型团队而言，这些管理员很难控制，因为要弄清哪些集群仍在使用以及哪些集群处于空闲状态并应将其关闭并不容易。 由于工程师往往会不时要求新的群集，因此随着时间的流逝，此问题变得更加严重，导致出现许多未使用的群集的情况，这些人实际上并不了解，但仍然会产生成本。

Combining the two approaches of many clusters that are shared only in very small teams can even be worse. This will only increase the confusion about which clusters are still needed as not every engineer knows exactly what their teammates are doing and may even have never used a cluster that is still needed by others. In these situations, the admins may often hear answers like “What cluster?”, “I don’t know if XYZ is still needing this”, or “Oh yes, you can delete that” (when the cluster is actually still needed).

将仅在很小的团队中共享的许多集群的两种方法结合起来，甚至会变得更糟。 这只会增加关于仍需要哪些集群的困惑，因为并非每个工程师都确切地知道他们的队友正在做什么，甚至可能从未使用过其他人仍然需要的集群。 在这种情况下，管理员可能经常会听到诸如“什么集群？”，“我不知道XYZ是否仍需要此集群”或“哦，是的，您可以删除它”之类的答案(当实际上仍需要集群时) 。

用于CI / CD和测试的虚拟集群 (Virtual clusters for CI/CD and testing)

If any of these problems sounds familiar to you, you should take a look at vClusters. Virtual clusters have some advantages that can solve the challenges of using Kubernetes in CI/CD and for testing:

如果您对这些问题中的任何一个听起来很熟悉，就应该看看vClusters 。 虚拟集群具有一些优势，可以解决在CI / CD和测试中使用Kubernetes的挑战：

• Quick Startup: One benefit of virtual clusters is that they are ready to use in just 3–5 seconds. This makes it possible to start fresh vClusters when they are really needed, e.g. when the CI/CD pipeline is triggered. For this, you will not need any standby clusters anymore that are running all the time even when unused, which saves a lot of time and cost while it also perfectly integrates into engineering workflows.

  快速启动：虚拟集群的一个好处是可以在3-5秒内准备使用。 这样就可以在真正需要它们时(例如，在触发CI / CD管道时)启动新的vCluster。 为此，您不再需要一直处于运行状态的备用集群，即使它们不使用时也是如此，这样既节省了很多时间和成本，又可以完美地集成到工程工作流程中。

• Easy Cleanup and Restoring: Since vClusters can be easily started, it is also possible to clean them up or throw them away, e.g. after a test if finished. If the engineer needs a cluster again, they can restore or recreate it with the exact same specification. So, standby clusters are even not needed when one needs the same configuration later again.

  易于清理和还原：由于vClusters可以轻松启动，因此也可以清理或扔掉它们，例如在完成测试后。 如果工程师再次需要集群，他们可以使用完全相同的规格来还原或重新创建集群。 因此，当以后再次需要相同的配置时，甚至不需要备用群集。

• Shared Physical Cluster: As virtual clusters are just an abstraction, still only one physical cluster is needed, although the engineers have the experience of individual clusters. The physical cluster even does not need to have extensive installations and can be quite “pure” and simple. Since managing and overseeing one simple cluster is much easier, the management effort for admins is significantly reduced.

  共享的物理群集：由于虚拟群集只是一个抽象，因此尽管工程师具有单个群集的经验，但仍然只需要一个物理群集。 物理群集甚至不需要进行大量安装，并且可以非常“纯粹”且简单。 由于管理和监督一个简单的群集要容易得多，因此大大减少了管理员的管理工作量。

• Strong Isolation: Virtual clusters are similar to physical clusters and so provide a stronger isolation than namespaces. Engineers thus work and test in encapsulated environments that feel like individual clusters, so breaking out of a vCluster is much less likely.

  高度隔离：虚拟群集类似于物理群集，因此比名称空间提供更强的隔离。 因此，工程师在感觉像单个群集的封装环境中进行工作和测试，因此脱离vCluster的可能性大大降低。

• Individual Configuration: In virtual clusters, engineers have the freedom to configure everything as they need it because they will not affect other virtual clusters. For this, it is for example even possible that engineers work with different Kubernetes versions in their virtual clusters on a shared physical cluster. This also allows them to experiment with configurations and even if they make a mistake, they can start from scratch again with a fresh vCluster in no time.

  单独配置：在虚拟集群中，工程师可以自由配置所需的一切，因为它们不会影响其他虚拟集群。 为此，例如，工程师甚至有可能在共享物理集群上的虚拟集群中使用不同的Kubernetes版本。 这也使他们能够尝试配置，即使出错，也可以立即使用全新的vCluster从头开始。

Virtual Clusters so solve all current problems with Kubernetes access and environment provisioning for CI/CD and testing.

虚拟集群因此可以解决Kubernetes访问和CI / CD和测试环境配置的所有当前问题。

From an administrator perspective, a virtual cluster setup is easy to manage and maintain as only one simple physical cluster exists that is also stable because every engineer is encapsulated in a separate sandbox environment. To get this setup, the admin only has the to create a Kubernetes cluster and install a virtual Cluster software, e.g. loft, so the whole setup can be done in less than an hour.

从管理员的角度来看 ，虚拟群集设置易于管理和维护，因为仅存在一个简单的物理群集，该群集也很稳定，因为每个工程师都封装在单独的沙盒环境中。 要进行此设置，管理员只能创建Kubernetes集群并安装虚拟集群软件(例如loft) ，因此整个设置可以在不到一个小时的时间内完成。

From an engineer perspective, virtual clusters feel like physical clusters giving them the freedom to experiment and make config changes, if needed and desired. They are also never interrupted in their workflow to wait for a cluster to be newly provisioned as they can create virtual clusters easily on demand, especially in solutions that are made for these use cases and even provide engineering-friendly GUIs, such as loft.

从工程师的角度来看 ，虚拟集群就像物理集群一样，可以根据需要和期望自由地进行实验和更改配置。 他们也永远不会中断工作流程，等待新配置的集群，因为他们可以轻松地按需创建虚拟集群，尤其是在针对这些用例制作的解决方案中，甚至提供了工程友好的GUI(例如loft) 。

From a business perspective, virtual cluster solutions minimize cost for computing resources as idle standby clusters are eliminated. Additionally, the engineering team’s productivity can be expected to improve as the Kubernetes environment issues are solved by standardized solutions.

从业务角度看 ，虚拟群集解决方案可消除闲置的备用群集，从而将计算资源的成本降至最低。 此外，随着Kubernetes环境问题通过标准化解决方案解决，工程团队的生产率有望提高。

结论 (Conclusion)

Overall, virtual clusters have the potential to disrupt the use of Kubernetes for CI/CD and testing as they solve all current challenges with providing a Kubernetes environment for these cases. By eliminating concerns about cost, stability, and productivity at the same time, all involved stakeholders can benefit from introducing virtual Kubernetes clusters. This again can help to drive Kubernetes adoption in many organizations where there are still doubts if Kubernetes should be integrated in current CI/CD and testing processes.

总体而言，虚拟集群有可能破坏Kubernetes用于CI / CD和测试的过程，因为它们通过为这些情况提供Kubernetes环境解决了当前的所有挑战。 通过同时消除对成本，稳定性和生产率的担忧，所有参与的利益相关者都可以从引入虚拟Kubernetes集群中受益。 这再次有助于推动Kubernetes在许多组织中的采用，这些组织仍然怀疑是否应该将Kubernetes集成到当前的CI / CD和测试流程中。

Photo by Just a Couple Photos from Pexels

Pexels拍摄 的情侣照片

Originally published at https://loft.sh.

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

翻译自: https://itnext.io/kubernetes-virtual-clusters-for-ci-cd-testing-ccc3664d21e0

kubernetes ci