1
1
# Connecting GitLab with a Kubernetes cluster
2
2
3
- > [ Introduced] ( https://gitlab.com/gitlab-org/gitlab-ce/issues/35954 ) in 10.1.
3
+ > [ Introduced] ( https://gitlab.com/gitlab-org/gitlab-ce/issues/35954 ) in GitLab 10.1.
4
+
5
+ Connect your project to Google Kubernetes Engine (GKE) or an existing Kubernetes
6
+ cluster in a few steps.
4
7
5
8
With a cluster associated to your project, you can use Review Apps, deploy your
6
9
applications, run your pipelines, and much more, in an easy way.
7
10
8
- Connect your project to Google Kubernetes Engine (GKE) or your own Kubernetes
9
- cluster in a few steps.
10
-
11
- NOTE: ** Note:**
12
- The Cluster integration will eventually supersede the
13
- [ Kubernetes integration] ( ../integrations/kubernetes.md ) . For the moment,
14
- you can create only one cluster.
11
+ There are two options when adding a new cluster to your project; either associate
12
+ your account with Google Kubernetes Engine (GKE) so that you can [ create new
13
+ clusters] ( #adding-and-creating-a-new-gke-cluster-via-gitlab ) from within GitLab,
14
+ or provide the credentials to an [ existing Kubernetes cluster] ( #adding-an-existing-kubernetes-cluster ) .
15
15
16
16
## Prerequisites
17
17
18
- In order to be able to manage your GKE cluster through GitLab, the following
19
- prerequisites must be met:
18
+ In order to be able to manage your Kubernetes cluster through GitLab, the
19
+ following prerequisites must be met.
20
+
21
+ ** For a cluster hosted on GKE:**
20
22
21
23
- The [ Google authentication integration] ( ../../../integration/google.md ) must
22
24
be enabled in GitLab at the instance level. If that's not the case, ask your
23
- administrator to enable it.
25
+ GitLab administrator to enable it.
24
26
- Your associated Google account must have the right privileges to manage
25
27
clusters on GKE. That would mean that a [ billing
26
28
account] ( https://cloud.google.com/billing/docs/how-to/manage-billing-account )
@@ -31,41 +33,88 @@ prerequisites must be met:
31
33
- You must have [ Resource Manager
32
34
API] ( https://cloud.google.com/resource-manager/ )
33
35
34
- If all of the above requirements are met, you can proceed to add a new GKE
36
+ ** For an existing Kubernetes cluster:**
37
+
38
+ - Since the cluster is already created, there are no prerequisites.
39
+
40
+ ---
41
+
42
+ If all of the above requirements are met, you can proceed to add a new Kubernetes
35
43
cluster.
36
44
37
- ## Adding a cluster
45
+ ## Adding and creating a new GKE cluster via GitLab
46
+
47
+ NOTE: ** Note:**
48
+ You need Master [ permissions] and above to access the Clusters page.
49
+
50
+ Before proceeding, make sure all [ prerequisites] ( #prerequisites ) are met.
51
+ To add a new cluster hosted on GKE to your project:
52
+
53
+ 1 . Navigate to your project's ** CI/CD > Clusters** page.
54
+ 1 . Click on ** Add cluster** .
55
+ 1 . Click on ** Create with GKE** .
56
+ 1 . Connect your Google account if you haven't done already by clicking the
57
+ ** Sign in with Google** button.
58
+ 1 . Fill in the requested values:
59
+ - ** Cluster name** (required) - The name you wish to give the cluster.
60
+ - ** GCP project ID** (required) - The ID of the project you created in your GCP
61
+ console that will host the Kubernetes cluster. This must ** not** be confused
62
+ with the project name. Learn more about [ Google Cloud Platform projects] ( https://cloud.google.com/resource-manager/docs/creating-managing-projects ) .
63
+ - ** Zone** - The [ zone] ( https://cloud.google.com/compute/docs/regions-zones/ )
64
+ under which the cluster will be created.
65
+ - ** Number of nodes** - The number of nodes you wish the cluster to have.
66
+ - ** Machine type** - The [ machine type] ( https://cloud.google.com/compute/docs/machine-types )
67
+ of the Virtual Machine instance that the cluster will be based on.
68
+ - ** Environment scope** - The [ associated environment] ( #setting-the-environment-scope ) to this cluster.
69
+ 1 . Finally, click the ** Create cluster** button.
70
+
71
+ After a few moments, your cluster should be created. If something goes wrong,
72
+ you will be notified.
73
+
74
+ You can now proceed to install some pre-defined applications and then
75
+ enable the Cluster integration.
76
+
77
+ ## Adding an existing Kubernetes cluster
38
78
39
79
NOTE: ** Note:**
40
- You need Master [ permissions] and above to add a cluster.
41
-
42
- There are two options when adding a new cluster; either use Google Kubernetes
43
- Engine (GKE) or provide the credentials to your own Kubernetes cluster.
44
-
45
- To add a new cluster:
46
-
47
- 1 . Navigate to your project's ** CI/CD > Cluster** page
48
- 1 . If you want to let GitLab create a cluster on GKE for you, go through the
49
- following steps, otherwise skip to the next one.
50
- 1 . Click on ** Create with GKE**
51
- 1 . Connect your Google account if you haven't done already by clicking the
52
- ** Sign in with Google** button
53
- 1 . Fill in the requested values:
54
- - ** Cluster name** (required) - The name you wish to give the cluster.
55
- - ** GCP project ID** (required) - The ID of the project you created in your GCP
56
- console that will host the Kubernetes cluster. This must ** not** be confused
57
- with the project name. Learn more about [ Google Cloud Platform projects] ( https://cloud.google.com/resource-manager/docs/creating-managing-projects ) .
58
- - ** Zone** - The [ zone] ( https://cloud.google.com/compute/docs/regions-zones/ )
59
- under which the cluster will be created.
60
- - ** Number of nodes** - The number of nodes you wish the cluster to have.
61
- - ** Machine type** - The [ machine type] ( https://cloud.google.com/compute/docs/machine-types )
62
- of the Virtual Machine instance that the cluster will be based on.
63
- - ** Project namespace** - The unique namespace for this project. By default you
64
- don't have to fill it in; by leaving it blank, GitLab will create one for you.
65
- 1 . If you want to use your own existing Kubernetes cluster, click on
66
- ** Add an existing cluster** and fill in the details as described in the
67
- [ Kubernetes integration] ( ../integrations/kubernetes.md ) documentation.
68
- 1 . Finally, click the ** Create cluster** button
80
+ You need Master [ permissions] and above to access the Clusters page.
81
+
82
+ To add an existing Kubernetes cluster to your project:
83
+
84
+ 1 . Navigate to your project's ** CI/CD > Clusters** page.
85
+ 1 . Click on ** Add cluster** .
86
+ 1 . Click on ** Add an existing cluster** and fill in the details:
87
+ - ** Cluster name** (required) - The name you wish to give the cluster.
88
+ - ** Environment scope** (required)- The
89
+ [ associated environment] ( #setting-the-environment-scope ) to this cluster.
90
+ - ** API URL** (required) -
91
+ It's the URL that GitLab uses to access the Kubernetes API. Kubernetes
92
+ exposes several APIs, we want the "base" URL that is common to all of them,
93
+ e.g., ` https://kubernetes.example.com ` rather than ` https://kubernetes.example.com/api/v1 ` .
94
+ - ** CA certificate** (optional) -
95
+ If the API is using a self-signed TLS certificate, you'll also need to include
96
+ the ` ca.crt ` contents here.
97
+ - ** Token** -
98
+ GitLab authenticates against Kubernetes using service tokens, which are
99
+ scoped to a particular ` namespace ` . If you don't have a service token yet,
100
+ you can follow the
101
+ [ Kubernetes documentation] ( https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/ )
102
+ to create one. You can also view or create service tokens in the
103
+ [ Kubernetes dashboard] ( https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/#config )
104
+ (under ** Config > Secrets** ).
105
+ - ** Project namespace** (optional) - The following apply:
106
+ - By default you don't have to fill it in; by leaving it blank, GitLab will
107
+ create one for you.
108
+ - Each project should have a unique namespace.
109
+ - The project namespace is not necessarily the namespace of the secret, if
110
+ you're using a secret with broader permissions, like the secret from ` default ` .
111
+ - You should ** not** use ` default ` as the project namespace.
112
+ - If you or someone created a secret specifically for the project, usually
113
+ with limited permissions, the secret's namespace and project namespace may
114
+ be the same.
115
+ 1 . Finally, click the ** Create cluster** button.
116
+
117
+ The Kubernetes service takes the following parameters:
69
118
70
119
After a few moments, your cluster should be created. If something goes wrong,
71
120
you will be notified.
@@ -85,6 +134,91 @@ added directly to your configured cluster. Those applications are needed for
85
134
| [ Ingress] ( https://kubernetes.io/docs/concepts/services-networking/ingress/ ) | 10.2+ | Ingress can provide load balancing, SSL termination, and name-based virtual hosting. It acts as a web proxy for your applications and is useful if you want to use [ Auto DevOps] ( ../../../topics/autodevops/index.md ) or deploy your own web apps. |
86
135
| [ Prometheus] ( https://prometheus.io/docs/introduction/overview/ ) | 10.4+ | Prometheus is an open-source monitoring and alerting system useful to supervise your deployed applications |
87
136
137
+ ## Setting the environment scope
138
+
139
+ When adding more than one clusters, you need to differentiate them with an
140
+ environment scope. The environment scope associates clusters and
141
+ [ environments] ( ../../../ci/environments.md ) in an 1:1 relationship similar to how the
142
+ [ environment-specific variables] ( ../../../ci/variables/README.md#limiting-environment-scopes-of-secret-variables )
143
+ work.
144
+
145
+ The default environment scope is ` * ` , which means all jobs, regardless of their
146
+ environment, will use that cluster. Each scope can only be used by a single
147
+ cluster in a project, and a validation error will occur if otherwise.
148
+
149
+ ---
150
+
151
+ For example, let's say the following clusters exist in a project:
152
+
153
+ | Cluster | Environment scope |
154
+ | ---------- | ------------------- |
155
+ | Development| ` * ` |
156
+ | Staging | ` staging/* ` |
157
+ | Production | ` production/* ` |
158
+
159
+ And the following environments are set in [ ` .gitlab-ci.yml ` ] ( ../../../ci/yaml/README.md ) :
160
+
161
+ ``` yaml
162
+ stages :
163
+ - test
164
+ - deploy
165
+
166
+ test :
167
+ stage : test
168
+ script : sh test
169
+
170
+ deploy to staging :
171
+ stage : deploy
172
+ script : make deploy
173
+ environment :
174
+ name : staging/$CI_COMMIT_REF_NAME
175
+ url : https://staging.example.com/
176
+
177
+ deploy to production :
178
+ stage : deploy
179
+ script : make deploy
180
+ environment :
181
+ name : production/$CI_COMMIT_REF_NAME
182
+ url : https://example.com/
183
+ ` ` `
184
+
185
+ The result will then be:
186
+
187
+ - The development cluster will be used for the "test" job.
188
+ - The staging cluster will be used for the "deploy to staging" job.
189
+ - The production cluster will be used for the "deploy to production" job.
190
+
191
+ ## Multiple Kubernetes clusters
192
+
193
+ > Introduced in [GitLab Enterprise Edition Premium][ee] 10.3.
194
+
195
+ With GitLab EEP, you can associate more than one Kubernetes clusters to your
196
+ project. That way you can have different clusters for different environments,
197
+ like dev, staging, production, etc.
198
+
199
+ To add another cluster, follow the same steps as described in [adding a
200
+ Kubernetes cluster](#adding-a-kubernetes-cluster) and make sure to
201
+ [set an environment scope](#setting-the-environment-scope) that will
202
+ differentiate the new cluster with the rest.
203
+
204
+ ## Deployment variables
205
+
206
+ The Kubernetes cluster integration exposes the following
207
+ [deployment variables](../../../ci/variables/README.md#deployment-variables) in the
208
+ GitLab CI/CD build environment:
209
+
210
+ - ` KUBE_URL` - Equal to the API URL.
211
+ - ` KUBE_TOKEN` - The Kubernetes token.
212
+ - ` KUBE_NAMESPACE` - The Kubernetes namespace is auto-generated if not specified.
213
+ The default value is `<project_name>-<project_id>`. You can overwrite it to
214
+ use different one if needed, otherwise the `KUBE_NAMESPACE` variable will
215
+ receive the default value.
216
+ - ` KUBE_CA_PEM_FILE` - Only present if a custom CA bundle was specified. Path
217
+ to a file containing PEM data.
218
+ - ` KUBE_CA_PEM` (deprecated) - Only if a custom CA bundle was specified. Raw PEM data.
219
+ - ` KUBECONFIG` - Path to a file containing `kubeconfig` for this deployment.
220
+ CA bundle would be embedded if specified.
221
+
88
222
# # Enabling or disabling the Cluster integration
89
223
90
224
After you have successfully added your cluster information, you can enable the
@@ -111,4 +245,62 @@ To remove the Cluster integration from your project, simply click on the
111
245
**Remove integration** button. You will then be able to follow the procedure
112
246
and [add a cluster](#adding-a-cluster) again.
113
247
248
+ # # What you can get with the Kubernetes integration
249
+
250
+ Here's what you can do with GitLab if you enable the Kubernetes integration.
251
+
252
+ # ## Deploy Boards (EEP)
253
+
254
+ > Available in [GitLab Enterprise Edition Premium][ee].
255
+
256
+ GitLab's Deploy Boards offer a consolidated view of the current health and
257
+ status of each CI [environment](../../../ci/environments.md) running on Kubernetes,
258
+ displaying the status of the pods in the deployment. Developers and other
259
+ teammates can view the progress and status of a rollout, pod by pod, in the
260
+ workflow they already use without any need to access Kubernetes.
261
+
262
+ [> Read more about Deploy Boards](https://docs.gitlab.com/ee/user/project/deploy_boards.html)
263
+
264
+ # ## Canary Deployments (EEP)
265
+
266
+ > Available in [GitLab Enterprise Edition Premium][ee].
267
+
268
+ Leverage [Kubernetes' Canary deployments](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)
269
+ and visualize your canary deployments right inside the Deploy Board, without
270
+ the need to leave GitLab.
271
+
272
+ [> Read more about Canary Deployments](https://docs.gitlab.com/ee/user/project/canary_deployments.html)
273
+
274
+ # ## Kubernetes monitoring
275
+
276
+ Automatically detect and monitor Kubernetes metrics. Automatic monitoring of
277
+ [NGINX ingress](../integrations/prometheus_library/nginx.md) is also supported.
278
+
279
+ [> Read more about Kubernetes monitoring](../integrations/prometheus_library/kubernetes.md)
280
+
281
+ # ## Auto DevOps
282
+
283
+ Auto DevOps automatically detects, builds, tests, deploys, and monitors your
284
+ applications.
285
+
286
+ To make full use of Auto DevOps(Auto Deploy, Auto Review Apps, and Auto Monitoring)
287
+ you will need the Kubernetes project integration enabled.
288
+
289
+ [> Read more about Auto DevOps](../../../topics/autodevops/index.md)
290
+
291
+ # ## Web terminals
292
+
293
+ NOTE : **Note:**
294
+ Introduced in GitLab 8.15. You must be the project owner or have `master` permissions
295
+ to use terminals. Support is limited to the first container in the
296
+ first pod of your environment.
297
+
298
+ When enabled, the Kubernetes service adds [web terminal](../../../ci/environments.md#web-terminals)
299
+ support to your [environments](../../../ci/environments.md). This is based on the `exec` functionality found in
300
+ Docker and Kubernetes, so you get a new shell session within your existing
301
+ containers. To use this integration, you should deploy to Kubernetes using
302
+ the deployment variables above, ensuring any pods you create are labelled with
303
+ ` app=$CI_ENVIRONMENT_SLUG` . GitLab will do the rest!
304
+
114
305
[permissions] : ../../permissions.md
306
+ [ee] : https://about.gitlab.com/gitlab-ee/
0 commit comments