3.8 KiB
| stage | group | info |
|---|---|---|
| Configure | Configure | To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments |
Connecting a Kubernetes cluster with GitLab
- Introduced in GitLab 13.4.
- Support for
grpcsintroduced in GitLab 13.6.- Agent server introduced on GitLab.com under
wss://kas.gitlab.comthrough an Early Adopter Program in GitLab 13.10.- Introduced in GitLab 13.11, the GitLab agent became available on GitLab.com.
- Moved from GitLab Premium to GitLab Free in 14.5.
- Renamed from "GitLab Kubernetes Agent" to "GitLab agent for Kubernetes" in GitLab 14.6.
You can connect your Kubernetes cluster with GitLab to deploy, manage, and monitor your cloud-native solutions.
To connect a Kubernetes cluster to GitLab, you must first install an agent in your cluster.
The agent runs in the cluster, and you can use it to:
- Communicate with a cluster, which is behind a firewall or NAT.
- Access API endpoints in a cluster in real time.
- Push information about events happening in the cluster.
- Enable a cache of Kubernetes objects, which are kept up-to-date with very low latency.
For more details about the agent's purpose and architecture, see the architecture documentation.
Workflows
You can choose from two primary workflows.
In a GitOps workflow, you keep your Kubernetes manifests in GitLab. You install a GitLab agent in your cluster, and any time you update your manifests, the agent updates the cluster. This workflow is fully driven with Git and is considered pull-based, because the cluster is pulling updates from your GitLab repository.
In a CI/CD workflow, you use GitLab CI/CD to query and update your cluster by using the Kubernetes API. This workflow is considered push-based, because GitLab is pushing requests from GitLab CI/CD to your cluster.
Supported cluster versions
GitLab supports the following Kubernetes versions. You can upgrade your Kubernetes version to a supported version at any time:
- 1.21 (support ends on November 22, 2022)
- 1.20 (support ends on July 22, 2022)
GitLab supports at least two production-ready Kubernetes minor versions at any given time. GitLab regularly reviews the supported versions and provides a three-month deprecation period before removing support for a specific version. The list of supported versions is based on:
- The versions supported by major managed Kubernetes providers.
- The versions supported by the Kubernetes community.
This epic tracks support for other Kubernetes versions.
Some GitLab features might work on versions not listed here.
Migrate to the agent from the legacy certificate-based integration
Read about how to migrate to the agent for Kubernetes from the certificate-based integration.