介绍
在这篇文章中，我们将介绍如何将 GitLab 的 Auto DevOps 功能与 Rancher 管理的 Kubernetes 集群连接起来，利用 Rancher v2.2.0 中引入的授权集群端点的功能。通过本文，你将能全面了解 GitLab 如何与 Kubernetes 集成，以及 Rancher 如何使用授权集群端点简化这一集成工作的流程。本文非常适合 Kubernetes 管理员、DevOps 工程师，或任何想将其开发工作流与 Kubernetes 进行集成的人。
背景
什么是 GitLab Auto DevOps？
Auto DevOps 是在 GitLab 10.0 中引入的功能，它让用户可以设置自动检测、构建、测试和部署项目的 DevOps 管道。将 GitLab Auto DevOps 与 Kubernetes 集群配合使用，这意味着用户可以无需配置 CI / CD 资源和其他工具，即可以部署应用程序。
什么是 Rancher 的授权集群端点？
从 v2.2.0 开始，Rancher 引入了一项名为 Authorized Cluster Endpoint 的新功能，用户可以直接访问 Kubernetes 而无需通过 Rancher 进行代理。在 v2.2.0 之前，如果要直接与下游 Kubernetes 集群通信，用户必须从各个节点手动检索 kubeconfig 文件以及 API 服务器地址。这不仅增加了操作的复杂度，而且还没有提供一种机制来控制通过 Rancher 管理集群时可用的细化权限。
从 Rancher v2.2.0 开始，部署 Rancher 管理的集群时，默认情况下会启用授权群集端点（ACE）功能。ACE 将部分 Rancher 身份验证和授权机制推送到下游 Kubernetes 集群，允许 Rancher 用户直接连接到这些集群，同时仍遵守安全策略。
如果您已为某些项目中的某个用户明确授予了权限，则当该用户使用授权集群端点进行连接时，这些权限能自动生效应用。现在，无论用户是通过 Rancher 还是直接连接到 Kubernetes 集群，安全性都能得到保障。
授权集群端点功能的相关文档对此有更详细的说明：
注意
目前，授权集群端点功能暂时仅适用于使用 Rancher Kubernetes Engine（RKE）启动的下游 Kubernetes 进群。
前期准备
要将 GitLab Auto DevOps 与 Rancher 管理的 Kubernetes 集群进行对接，您需要实现准备好：
一个 GitLab.com 帐户，或一个自托管 GitLab 实例上的帐户（需已启用 Auto DevOps） ：GitLab.com 帐户需要已经配置好了 Auto DevOps。如果您使用的是自托管 GitLab 实例，则可以参考这一 GitLab 文档了解如何启用 Auto DevOps：https://docs.gitlab.com/ee/topics/autodevops/
运行版本 v2.2.0 或更高版本的 Rancher 实例 ：您可以以单节点模式启动 Rancher（https://rancher.com/quick-start/），也可以创建HA安装（https://rancher.com/docs/rancher/v2.x/en/installation/ha/）。
Rancher 管理的 Kubernetes 集群 ：您还需要一个通过 RKE 配置的、Rancher 上管理的集群。此外，集群中需要有一个 管理员用户 ，如果您使用的是 GitLab.com，则 需要通过公共网络访问控制平面节点 。
设置 Rancher 和 Kubernetes
首先，我们需要先将 Rancher 和 Kubernetes 设置好。该过程的第一部分主要涉及收集信息。
注意
为简单起见，这些步骤使用的是 Rancher 中默认的 admin 帐户。最佳实践要求您使用独立用户执行此类过程，并限制该用户对正在集成 GitLab 的集群的权限。
登录 Rancher 并导航到要集成的下游集群。在本演示中，我们将在 EC2 实例上创建一个名为 testing 的集群，该集群在 Amazon 中运行：
在集群的仪表板上，单击顶部的 Kubeconfig File 按钮。这将打开 kubeconfig 集群的文件，其中包括授权集群端点的信息。
kubeconfig 文件中的第一个条目是通过 Rancher 服务器的集群端点。向下滚动以标识此集群的授权群集端点，该集群列为单独的集群条目：
在我的示例中，此集群的名称是 testing-testing-2，并且端点 server 是 AWS 提供的公共 IP。
复制 server 和 certificate-authority-data 字段的值，不包括引号，并保存它们。
在 kubeconfig 文件中进一步向下滚动并找到您的用户名和 token：
复制 token 字段（不包括引号）并保存。
接下来解码证书授权机构数据的 base64 版本，将其转换回原始版本并保存。根据您的工具，一些可行的选项包括：
设置 GitLab 项目
通过我们从 Rancher 收集的信息，我们现在可以配置 GitLab 了。我们将首先在 GitLab 中创建一个新项目，该项目将使用 Auto DevOps 功能与我们的 Kubernetes 集群集成。
首先，登录 GitLab，然后选择 New Project 。
在“新建项目”页面上，选择“ 从模板创建 ”选项卡。这将为您提供要使用的模板项目列表。选择 NodeJS Express ，然后单击“ Use template ”：
为项目命名，并将“ 可见性级别 ”设置为“ 公共 ”。完成后单击“ 创建项目 ”。
注意
在我撰写本文时，可见性级别可以设为“私密”，不过这是 GitLab 的 Auto DevOps 实验性功能。
在项目页面左侧的菜单窗格中，选择“ 设置 ”>“ CI / CD ”。展开“ 环境变量 ”部分，并设置以下变量：
我们这次会禁用下图这些功能，因为我们的简单示例暂时不需要它们，并且它们会延长部署所需的时间。在实际项目中，您可以根据您的实际需求启用其中一些选项：
单击“ 保存变量 ”以完成 GitLab 项目配置。
连接 GitLab 和 Rancher
现在，我们已准备好将我们的 GitLab 项目与 Rancher 管理的 Kubernetes 集群集成。
在 GitLab 中，选择新克隆的项目。在左侧菜单中，选择“ 操作 ”>“ Kubernetes ”。单击绿色“ 添加 Kubernetes 集群 ”按钮。在下一页上，选择“ 添加现有集群 ”选项卡。
按以下信息填写相应字段：
单击“ 添加 Kubernetes 集群 ”。GitLab 将添加集群，并在其中创建新的命名空间。您可以查看 Rancher 接口，确认新创建的命名空间已经创建成功。
注意
GitLab 连接到集群时所做的第一件事就是为项目创建一个命名空间。如果您在一段时间后没有看到创建名称空间，则说明可能出现了一些问题。
将集群添加到 GitLab 后，将显示要安装到集群中的应用程序列表。第一个是 Helm Tiller 。继续，单击“ 安装 ”将其添加到集群。
接下来，安装 Ingress ，它将允许 GitLab 将流量路由到您的应用程序：
根据您配置进群的方式，您的入口端点可能会自动填充，也可能不会。在本教程中，我将使用 xip.io 主机名来指向单个节点的流量。至于您的用例，您可能需要设置通配符域并将其指向此 ingress（或指向您的节点 IP 等）。
部署好 ingress 后，滚动到页面顶部并找到“ 基本域 ”字段。输入其中一个节点的公共 IP 地址，然后输入.xip.io。这将创建一个解析为该 IP 地址的通配符域，这对于我们的示例就足够了：
接下来，在导航栏中，选择“ 设置 ”>“ CI / CD ”。展开“ 自 动 DevOps ”部分，然后选中“ 默认为自动 DevOps 管道 ”框。这不仅意味着 Auto DevOps 已被设为默认值，还能够触发构建。将“ 部署策略 ”设置为“ 继续部署到生产 ”：
检查 Auto DevOps 框后，管道运行将开始。导航到 GitLab 中的 CI / CD>管道 。您应该看到类似于下图的内容，这表明 GitLab 正在部署您的应用程序：
验证 Rancher 中的部署
下面让我们回到 Rancher，查看一下我们的部署的情况，看看资源是如何转换为 Rancher 界面中的 Kubernetes 对象的。
在 Rancher 中，导航到您的进群，然后单击顶部导航菜单中的 Projects / Namespaces 。
GitLab 代表您创建了两个命名空间：一个是 gitlab-managed-apps，另一个是唯一的应用程序命名空间。gitlab-managed-apps 命名空间包含资源，如用于部署应用程序的 nginx 和 Helm tiller 实例。那个应用程序的唯一命名空间，包含着应用程序的部署。
为了将这些进一步可视化，我们可以将这些命名空间移动到我们的 Default 项目中。您也可以使用任何其他项目。单击“ 移动 ”按钮，然后选择所需的项目：
移动命名空间后，导航到他们所属的项目，然后导航到 Workloads 页面。该页面将在其特定于应用程序的命名空间中显示您的新部署：
请注意部署名称下的 443 / https 链接。单击该链接，您就可以跳转至您的部署的通配符域的 ingress。如果一切顺利，你将可以看到这个象征着成功的页面：
结语
恭喜！您刚刚成功地使用授权集群端点将 GitLab 的 Auto DevOps 与 Rancher 管理的 Kubernetes 集群连接，以实现更安全、直接的连接了！
当探索 Rancher 的其他区域时，你可能会注意到 GitLab 以你的名义为你创建的其他对象。例如，“ 负载均衡 ”选项卡显示已部署的 L7 ingress 以及创建的主机名。您还可以在“ 服务发现 ”选项卡下查看部署的应用程序的内部服务。
GitLab 的 Auto DevOps 功能不仅易于使用，而且可定制且功能强大。在本文的演示中，我们禁用了一些高级功能，如自动测试、依赖项扫描和许可管理。这些功能在后期也可以重新启用，并通过配置 GitLab，为您的开发环境提供更多意想不到的便利与价值。除了 Auto DevOps 之外，GitLab 还为 CI / CD 提供了.gitlab-ci.yml 文件，用户可以借此进行更多的扩展定制。在 GitLab 的文档中您可以了解到更多信息：
在 Kubernetes 和 Rancher 上构建 CI / CD 流水线
Kubernetes 的一大价值，就是为企业优化开发操作流程，而 CI 工作流与 Kubernetes 的集成，是大多团队极关注的重要部分。
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论