本篇文章给大家分享的是有关怎么在Kubernetes上大规模运行CI/CD，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。在云原生领域中，Kubernetes累积了大量用例。它能够在云中部署应用容器、安排批处理job、处理工作负载以及执行逐步升级。Kubernetes使用高效的编排算法来处理这些操作，即便是大规模集群这些算法依旧表现良好。此外，Kubernetes主要用例之一是运行持续集成或持续交付（CI/CD）流水线。也就是说，我们部署一个CI/CD容器的唯一实例，该实例将监控代码版本控制系统。所以，每当我们推送到该仓库时，该容器都会运行流水线步骤。其最终目标是达到一个“true or false”的状态。True即在集成阶段commit通过了各种测试，False即未通过测试。除了以上描述的CI流水线之外，在CI测试通过之后，另一个流水线可以接管余下的过程，以处理发布过程的CD部分。在这一阶段，流水线将尝试将应用程序容器交付到生产中。需要明白的是，这些操作是按需运行或者是由各种行为（如代码check-in、测试触发器、流程中上一步的结果等）自动触发的。因此我们需要一种机制来增加单个节点以运行那些流水线的步骤，并在不需要它们时将其淘汰。这种管理不可变基础架构的方法有助于我们节省资源并降低成本。当然，最关键的机制就是Kubernetes，它具有声明式的结构和可定制性，因此可以让你在任何场景下高效地调度job、节点以及pod。适用于Kubernetes的CI/CD平台Kubernetes是一个运行CI/CD的理想平台，因为它拥有许多特性使得在上面运行CI/CD更为简单。那么，到底有多少CI/CD的平台可以在Kubernetes上运行呢？可以这么说，只要它们能够被打包为一个容器，Kubernetes都能够运行它们。以下是几个最为流行的CI/CD平台：Jenkins：Jenkins是最为流行也最为稳定的CI/CD平台。在世界范围内有数以千计的企业都在使用它，因为它拥有强大的生态和可扩展性。如果你打算要在Kubernetes上使用它，非常建议你安装它的官方插件。JenkinsX是专门为云原生领域设计的Jenkins版本。它与Kubernetes更加兼容，并且提供了更好的集成功能，如GitOps、自动CI/CD和预览环境。Spinnaker：Spinnaker是一个可扩展的多云部署的CD平台，得到了Netflix的支持。使用相关的Helm Chart即可安装它。https://github.com/helm/charts/tree/master/stable/spinnakerDrone：这是有多种功能的通用云原生CD平台。可以使用关联的Runner在Kubernetes中运行它。GoCD：Thoughtworks的另一个CI/CD平台，提供了适用于云原生部署的各种工作流程和功能。它可以在Kubernetes中作为Helm Chart运行。此外，还有一些与Kubernetes紧密合作的云服务，并提供诸如CircleCI和Travis的CI/CD流水线。如果你不打算托管CI/CD平台，那么这些也十分有用。现在，我们来看看如何在Kubernetes集群上安装Jenkins。首先，我们需要安装Helm，它是Kubernetes的软件包管理器：同样，我们还需要安装Tiller，以让Helm正常运行：完成这些步骤之后，我们需要运行检查命令，以查看deployment的配置值：仔细检查配置值并在需要的时候进行更改。然后安装Chart：安装过程中会有一些关于下一步操作的说明：注意：运行以下命令获取”admin“用户的密码：在相同的shell中获取Jenkins URL以访问这些命令：遵循这些步骤，它们将在http://127.0.0.1:8080 启动代理服务器。到那里输入你的用户名和密码。你将会拥有自己的Jenkins 服务器：不过，请记住，还有许多配置选项尚未修改，你可以访问chart文档以了解更多信息：https://github.com/helm/charts/tree/master/stable/jenkins在默认情况下，服务器会安装好最基本的插件，如Git和Kubernetes-Jenkins，我们可以根据自己的需要安装其他插件。总而言之，使用Helm安装Jenkins十分轻松。既然我们已经大致了解CI/CD如何在Kubernetes上运行的，那么我们来看一个在Kubernetes中部署高度可扩展的Jenkins部署的示例用例。人们通常用它（进行了少量修改）来处理基础结构的CI/CD，开始吧！虽然官方Jenkins镜像很适合入门，但它需要的配置超出了我们的期望。许多用户会选择一个固定的发行版，如my-bloody-jenkins（https://github.com/odavid/my-bloody-jenkins ），它提供了一个较为完整的预安装插件以及配置选项。在可用的插件中，我们使用saml插件、SonarQubeRunner、Maven和Gradle。它能够使用以下命令通过Helm Chart安装：我们选择使用以下Dockerfile部署自定义镜像：其中plugins.txt文件是我们要预安装到镜像中的其他插件列表：然后，只要dockerfile发生更改，我们就使用此通用Jenkinsfile来构建master：我们所使用的专用集群由AWS中的一些大中型实例组成，用于Jenkins jobs。接下来，我们进入下一个部分。为了扩展我们的一些Jenkins slaves，我们使用Pod模板并将标签分配给特定的agent。因此在我们的Jenkinsfiles中，我们可以为jobs引用它们。例如，我们有一些需要构建安卓应用程序的agent。因此，我们引用以下标签：并且将使用特定于安卓的pod模板。我们使用这一Dockerfile，例如：我们还使用了Jenkinsfile，该文件与上一个文件类似，用于构建master。每当我们对Dockerfile进行更改时，agent都会重建镜像。这为我们的CI/CD基础架构提供了极大的灵活性。尽管我们为deployment分配了特定数量的节点，但我们还可以通过启用cluster autoscaling，来完成更多的事情。这意味着在工作负载增加和峰值的情况下，我们可以增加额外的节点来处理job。目前，如果我们有固定数量的节点，那么我们只能处理固定数量的job。基于以下事实，我们可以进行粗略地估计：每个slave通常分配500ms CPU和256MB内存，并且设置一个很高的并发。这根本不现实。举个例子，当你的版本被大幅削减并且需要部署大量微服务时，可能会发生上述情况。然后，大量的job堆积在流水线，造成严重的延误。在这种情况下，我们可以增加该阶段的节点数。例如，我们可以添加额外的VM实例，然后在过程结束时将其删除。我们可以在命令行中使用自动伸缩选项来配置“Vertical”或“集群”自动伸缩选项。但是，此方法需要仔细计划和配置，因为有时会发生以下情况：越来越多的job达到平稳阶段Autoscaler增加新的节点，但是需要10分钟来进行部署和分配旧的job已经完成任务，新的job将填补空白，进而减少了对新节点的需求新节点可用，但需要X分钟保持稳定且未利用，X由–scale-down-unneeded-time标志定义同样的事情每天发生很多次在这种情况下，最好是根据我们的特定需求进行配置，或者只是增加当天的节点数，并在流程结束后将其还原。所有这些都与寻找最佳方法来利用所有资源并使成本最小化有关。在任何情况下，我们都应该有一个可伸缩且易于使用的Jenkins集群。对于每个job，都会创建一个pod来运行特定的流水线，并在完成后将其销毁。现在我们已经了解了Kubernetes有哪些CI/CD平台以及如何在你的集群上安装一个平台。接下来，我们将讨论一些大规模运行它们的方法。首先，选择Kubernetes发行版是我们需要考虑的最关键因素之一。找到最合适的解决方案才能够进行下一步。其次，选择合适的Docker镜像仓库和应用程序包管理器同样重要。我们需要寻找可以按需快速检索的安全可靠的镜像管理。至于软件包管理器，Helm是一个不错的选择，因为它可以发现、共享和使用为Kubernetes构建的软件。第三，使用现代集成流程，如GitOps和ChatOps，在易用性和可预测性方面提供了显著优势。将Git用作单一数据源，使我们可以运行“通过拉取请求进行操作”，从而简化了对基础架构和应用程序的部署控制。使用诸如企业微信或钉钉之类的团队协作工作来触发CI/CD流水线的自动化任务，有助于我们消除重复劳动并简化开发云主机域名集成。总体而言，如果我们想更深入地了解，你可以自定义或开发自己的K8S Operator，与K8S API配合更紧密。使用自定义operator的好处很多，因为它们可以建立更好的自动化体验。以上就是怎么在Kubernetes上大规模运行CI/CD，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注开发云行业资讯频道。
这篇文章将为大家详细讲解有关如何使用公共Registry ，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。保存和分发镜像的最直接方法就是使用 Docker Hub。Docker Hub 是 Docker 公司维护…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
