我对 Kubernetes 了解不多，但据我所知，它是一个可以让您控制和管理容器化应用程序的系统。所以，一般来说，我们从 kubernetes 中获得的好处的本质是能够“告诉”kubernetes 我们想要运行哪些容器，其中有多少，在哪些机器上，以及其他细节，kubernetes 将负责这样做为我们。对吗？
如果是这样，我只是看不到使用 kubernetes pod 运行 CI 管道的好处，因为我知道有些人会这样做。假设您将构建工具放在 Docker 容器上，而不是将它们安装在特定的机器上，这很好——您可以在构建过程中使用这些容器，为什么选择 kubernetes？是否有任何性能提升或类似的东西？
欣赏一些见解。
【问题讨论】：
标签： jenkins kubernetes continuous-integration devops
强烈建议充分了解what Kubernetes is 以及它能做什么和不能做什么。
通常，容器与编排工具相结合可以更好地管理您的机器和服务。它可以显着提高应用程序的可靠性并减少在 DevOps 上花费的时间和资源。
一些值得注意的功能是：
水平基础架构扩展：可以轻松添加或删除新服务器。
自动缩放：根据 CPU 利用率或其他应用程序提供的指标自动更改运行容器的数量。
手动伸缩：通过命令或界面手动伸缩正在运行的容器数量。
复制控制器：复制控制器确保您的集群有相同数量的 Pod 在运行。如果 pod 太多，复制控制器会终止多余的 pod。如果太少，它会启动更多的 pod。
健康检查和自我修复：Kubernetes 可以检查节点和容器的健康状况，确保您的应用程序不会遇到任何故障。 Kubernetes 还提供自我修复和自动替换功能，因此您无需担心容器或 pod 是否出现故障。
流量路由和负载平衡：流量路由将请求发送到适当的容器。 Kubernetes 还带有内置的负载平衡器，因此您可以平衡资源以响应中断或高流量时段。
自动推出和回滚：Kubernetes 无需停机即可处理新版本或更新的推出，同时监控容器的运行状况。如果推出不顺利，它会自动回滚。
Canary 部署：Canary 部署使您能够在生产环境中与之前的版本并行测试新部署。
不过你也应该知道what Kubernetes is not:
Kubernetes 不是传统的、包罗万象的 PaaS（平台作为 服务）系统。由于 Kubernetes 在容器级别运行 而不是在硬件级别，它通常提供一些 PaaS 产品共有的适用功能，例如部署， 扩展、负载平衡，并让用户集成他们的日志记录， 监控和警报解决方案。然而，Kubernetes 不是 单片，这些默认解决方案是可选的和可插拔的。 Kubernetes 为构建开发人员提供了构建块 平台，但保留了用户的选择和灵活性 很重要。
特别是在您的用例中，请注意 Kubernetes：
不部署源代码，也不构建您的应用程序。 持续集成、交付和部署 (CI/CD) 工作流程是 由组织文化和偏好以及 技术要求。
决定权在您手中，但牢记上述主要概念将有助于您做出决定。
【讨论】：
一个重要的细节是你没有告诉 Kubernetes 给定的 pod 应该在哪些节点上运行；它会自行选择，如果集群资源不足，在许多情况下，它实际上可以自己分配更多节点（通过集群自动扩缩器）。
因此，如果您的 CI 系统相当繁忙，并且所有内容都使用所有容器，那么将单个构建作业作为 Kubernetes 作业运行可能更有意义。如果您有 100 个同时启动的构建，则集群可能会为自己提供更多硬件，并且构建队列将更快地清除。特别是如果您将 Kubernetes 用于其他任务，与维护一个需要单独更新的专用 CI 系统工作人员池相比，这可以节省您相同的管理工作量，并且在大量构建到达之前大部分时间都处于空闲状态。
Kubernetes 的安全设置也大大优于 Docker。假设您的 CI 系统需要在构建过程中启动容器。在 Kubernetes 中，它可以在 服务帐户 下运行，并被授予在特定命名空间中创建和删除部署的权限，除此之外别无其他。在 Docker 中，标准方法是让 CI 系统访问主机的 Docker 套接字，但这很容易被利用来接管主机。
【讨论】：