kubernetes - 如何为私有(private) GKE 集群启用 Gitlab CI/CD？

Question

我想设置 Gitlab CI/CD 的 AutoDevops 功能，为此我正在尝试将现有的 kubernetes 集群设置为我的环境。

但是，Gitlab 需要用于访问 Kubernetes API 的 Kubernetes Master API URL。库伯内斯公开了几个 API，我们想要所有这些都通用的“基本”URL，例如，https://kubernetes.example.com而不是 https://kubernetes.example.com/api/v1 .我们将通过运行此命令获取 API URL:

kubectl 集群信息 | grep 'Kubernetes 大师' | awk '/http/{打印 $NF}

它返回一个 https://

在我的例子中，我有一个私有(private) IP，它是 https://172.10.1.x

没有任何文档可以帮助为私有(private) GKE 集群设置 gitlab CI。

如何设置 gitlab 以借助正在运行的 VM 实例或 pod 的服务 IP 访问我的 kubernetes master？或者如果有任何解决方案/解决方法建议来实现此目的，请提供帮助。

Add Existing GKE cluster as Environment

Answer 1

现在(2020 年 9 月)有一个替代方案，但它不是免费的(仅限 GitLab.com Premium/Ultimate)，在 14.5+(2021 年 11 月)中部分免费。然后完全与 15.3(2022 年 8 月)

参见 GitLab 13.4

Introducing the GitLab Kubernetes Agent

GitLab’s Kubernetes integration has long enabled deployment to Kubernetes clusters without manual setup. Many users have enjoyed the ease-of-use, while others have run into some challenges.

The current integration requires your cluster to be open to the Internet for GitLab to access it. For many organizations, this isn’t possible, because they must lock down their cluster access for security, compliance, or regulatory purposes. To work around these restrictions, users needed to create custom tooling on top of GitLab, or they couldn’t use the feature.

Today, we’re announcing the GitLab Kubernetes Agent: a new way to deploy to Kubernetes clusters. The Agent runs inside of your cluster, so you don’t need to open it to the internet. The Agent orchestrates deployments by pulling new changes from GitLab, rather than GitLab pushing updates to the cluster. No matter what method of GitOps you use, GitLab has you covered.

Note this is the first release of the Agent. Currently, the GitLab Kubernetes Agent has a configuration-driven setup, and enables deployment management by code. Some existing Kubernetes integration features, such as Deploy Boards and GitLab Managed Apps, are not yet supported. Our vision is to eventually implement these capabilities, and provide new security- and compliance-focused integrations with the Agent.

https://about.gitlab.com/images/13_4/gitops-header.png -- Introducing the GitLab Kubernetes Agent

See Documentation and Issue.

---

另见 GitLab 13.5 (2020 年 10 月)

Install the GitLab Kubernetes Agent with Omnibus GitLab

Last month we introduced the GitLab Kubernetes Agent for self-managed GitLab instances installed with Helm.

This release adds support for the official Linux package.

In this new Kubernetes integration, the Agent orchestrates deployments by pulling new changes from GitLab, rather than GitLab pushing updates to your cluster.

You can learn more about how the Kubernetes Agent works now and check out our vision to see what’s in store.

See Documentation and Issue.

---

这已通过 GitLab 13.11 确认(2021 年 4 月):

GitLab Kubernetes Agent available on GitLab.com

The GitLab Kubernetes Agent is finally available on GitLab.com. By using the Agent, you can benefit from fast, pull-based deployments to your cluster, while GitLab.com manages the necessary server-side components of the Agent.

The GitLab Kubernetes Agent is the core building block of GitLab’s Kubernetes integrations.
The Agent-based integration today supports pull-based deployments and Network Security policy integration and alerts, and will soon receive support for push-based deployments too.

Unlike the legacy, certificate-based Kubernetes integration, the GitLab Kubernetes Agent does not require opening up your cluster towards GitLab and allows fine-tuned RBAC controls around GitLab’s capabilities within your clusters.

参见 Documentation和 issue .

---

参见 GitLab 14.5 (2021 年 11 月)

GitLab Kubernetes Agent available in GitLab Free

Connecting a Kubernetes cluster with the GitLab Kubernetes Agent simplifies the setup for cluster applications and enables secure GitOps deployments to the cluster.

Initially, the GitLab Kubernetes Agent was available only for Premium users.

In our commitment to the open source ethos, we moved the core features of the GitLab Kubernetes Agent and the CI/CD Tunnel to GitLab Free.
We expect that the open-sourced features are compelling to many users without dedicated infrastructure teams and strong requirements around cluster management.
Advanced features remain available as part of the GitLab Premium offering.

See Documentation and Epic.

---

参见 GitLab 14.8 (2022 年 2 月)

The agent server for Kubernetes is enabled by default

The first step for using the agent for Kubernetes in self-managed instances is to enable the agent server, a backend service for the agent for Kubernetes. In GitLab 14.7 and earlier, we required a GitLab administrator to enable the agent server manually. As the feature matured in the past months, we are making the agent server enabled by default to simplify setup for GitLab administrators. Besides being enabled by default, the agent server accepts various configuration options to customize it according to your needs.

See Documentation and Issue.

---

与 GitLab 15.3 (2022 年 8 月):

GitOps features are now free

When you use GitOps to update a Kubernetes cluster, also called a pull-based deployment, you get an improved security model, better scalability and stability.

The GitLab agent for Kubernetes has supported GitOps workflows from its initial release, but until now, the functionality was available only if you had a GitLab Premium or Ultimate subscription. Now if you have a Free subscription, you also get pull-based deployment support. The features available in GitLab Free should serve small, high-trust teams or be suitable to test the agent before upgrading to a higher tier.

In the future, we plan to add built-in multi-tenant support for Premium subscriptions. This feature would be similar to the impersonation feature already available for the CI/CD workflow.

See Documentation and Issue.

---

参见 GitLab 15.4 (2022 年 9 月)

Deploy Helm charts with the agent for Kubernetes

You can now use the agent for Kubernetes to deployHelm charts to your Kubernetes cluster.

Until now, the agent for Kubernetes only supported vanilla Kubernetes manifest files in its GitOps workflow.
To benefit from the GitOps workflow, Helm users had to use a CI/CD job to render and commit resources.

The current release ships with Alpha support for Helm.
Because Helm is a mature product, we consider the solution performant. However, known issues exist and the API might change without prior notice. We welcome your feedback in therelated epic, where we discuss future improvements and next steps.

See Documentation and Issue.