summaryrefslogtreecommitdiff
path: root/doc/user/project/clusters
diff options
context:
space:
mode:
Diffstat (limited to 'doc/user/project/clusters')
-rw-r--r--doc/user/project/clusters/index.md227
1 files changed, 164 insertions, 63 deletions
diff --git a/doc/user/project/clusters/index.md b/doc/user/project/clusters/index.md
index f2289fcb3d1..e87b4403854 100644
--- a/doc/user/project/clusters/index.md
+++ b/doc/user/project/clusters/index.md
@@ -2,15 +2,16 @@
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/35954) in GitLab 10.1.
-NOTE: **Note:**
-The Cluster integration will eventually supersede the
-[Kubernetes integration](../integrations/kubernetes.md).
+Connect your project to Google Kubernetes Engine (GKE) or an existing Kubernetes
+cluster in a few steps.
With a cluster associated to your project, you can use Review Apps, deploy your
applications, run your pipelines, and much more, in an easy way.
-Connect your project to Google Kubernetes Engine (GKE) or an existing Kubernetes
-cluster in a few steps.
+There are two options when adding a new cluster to your project; either associate
+your account with Google Kubernetes Engine (GKE) so that you can [create new
+clusters](#adding-and-creating-a-new-gke-cluster-via-gitlab) from within GitLab,
+or provide the credentials to an [existing Kubernetes cluster](#adding-an-existing-kubernetes-cluster).
## Prerequisites
@@ -41,20 +42,13 @@ following prerequisites must be met.
If all of the above requirements are met, you can proceed to add a new Kubernetes
cluster.
-## Adding a Kubernetes cluster
+## Adding and creating a new GKE cluster via GitLab
NOTE: **Note:**
You need Master [permissions] and above to access the Clusters page.
-There are two options when adding a new cluster to your project; either associate
-your account with Google Kubernetes Engine (GKE) so that you can create new
-clusters from within GitLab, or provide the credentials to an existing
-Kubernetes cluster.
-
-Before proceeding to either method, make sure all [prerequisites](#prerequisites)
-are met.
-
-**To add a new cluster hosted on GKE to your project:**
+Before proceeding, make sure all [prerequisites](#prerequisites) are met.
+To add a new cluster hosted on GKE to your project:
1. Navigate to your project's **CI/CD > Clusters** page.
1. Click on **Add cluster**.
@@ -71,24 +65,56 @@ are met.
- **Number of nodes** - The number of nodes you wish the cluster to have.
- **Machine type** - The [machine type](https://cloud.google.com/compute/docs/machine-types)
of the Virtual Machine instance that the cluster will be based on.
- - **Project namespace** - The unique namespace for this project. By default you
- don't have to fill it in; by leaving it blank, GitLab will create one for you.
- **Environment scope** - The [associated environment](#setting-the-environment-scope) to this cluster.
1. Finally, click the **Create cluster** button.
----
+After a few moments, your cluster should be created. If something goes wrong,
+you will be notified.
-**To add an existing cluster to your project:**
+You can now proceed to install some pre-defined applications and then
+enable the Cluster integration.
+
+## Adding an existing Kubernetes cluster
+
+NOTE: **Note:**
+You need Master [permissions] and above to access the Clusters page.
+
+To add an existing Kubernetes cluster to your project:
1. Navigate to your project's **CI/CD > Clusters** page.
1. Click on **Add cluster**.
-1. Click on **Add an existing cluster** and fill in the details as described
- in the [Kubernetes integration](../integrations/kubernetes.md#configuration)
- documentation.
-1. Select the [environment scope](#setting-the-environment-scope).
+1. Click on **Add an existing cluster** and fill in the details:
+ - **Cluster name** (required) - The name you wish to give the cluster.
+ - **Environment scope** (required)- The
+ [associated environment](#setting-the-environment-scope) to this cluster.
+ - **API URL** (required) -
+ It's the URL that GitLab uses to access the Kubernetes API. Kubernetes
+ exposes several APIs, we want the "base" URL that is common to all of them,
+ e.g., `https://kubernetes.example.com` rather than `https://kubernetes.example.com/api/v1`.
+ - **CA certificate** (optional) -
+ If the API is using a self-signed TLS certificate, you'll also need to include
+ the `ca.crt` contents here.
+ - **Token** -
+ GitLab authenticates against Kubernetes using service tokens, which are
+ scoped to a particular `namespace`. If you don't have a service token yet,
+ you can follow the
+ [Kubernetes documentation](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)
+ to create one. You can also view or create service tokens in the
+ [Kubernetes dashboard](https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/#config)
+ (under **Config > Secrets**).
+ - **Project namespace** (optional) - The following apply:
+ - By default you don't have to fill it in; by leaving it blank, GitLab will
+ create one for you.
+ - Each project should have a unique namespace.
+ - The project namespace is not necessarily the namespace of the secret, if
+ you're using a secret with broader permissions, like the secret from `default`.
+ - You should **not** use `default` as the project namespace.
+ - If you or someone created a secret specifically for the project, usually
+ with limited permissions, the secret's namespace and project namespace may
+ be the same.
1. Finally, click the **Create cluster** button.
----
+The Kubernetes service takes the following parameters:
After a few moments, your cluster should be created. If something goes wrong,
you will be notified.
@@ -108,45 +134,6 @@ added directly to your configured cluster. Those applications are needed for
| [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. |
| [Prometheus](https://prometheus.io/docs/introduction/overview/) | 10.4+ | Prometheus is an open-source monitoring and alerting system useful to supervise your deployed applications |
-## Enabling or disabling the Cluster integration
-
-After you have successfully added your cluster information, you can enable the
-Cluster integration:
-
-1. Click the "Enabled/Disabled" switch
-1. Hit **Save** for the changes to take effect
-
-You can now start using your Kubernetes cluster for your deployments.
-
-To disable the Cluster integration, follow the same procedure.
-
-## Removing the Cluster integration
-
-NOTE: **Note:**
-You need Master [permissions] and above to remove a cluster integration.
-
-NOTE: **Note:**
-When you remove a cluster, you only remove its relation to GitLab, not the
-cluster itself. To remove the cluster, you can do so by visiting the GKE
-dashboard or using `kubectl`.
-
-To remove the Cluster integration from your project, simply click on the
-**Remove integration** button. You will then be able to follow the procedure
-and [add a cluster](#adding-a-cluster) again.
-
-## Multiple Kubernetes clusters
-
-> Introduced in [GitLab Enterprise Edition Premium][ee] 10.3.
-
-With GitLab EEP, you can associate more than one Kubernetes clusters to your
-project. That way you can have different clusters for different environments,
-like dev, staging, production, etc.
-
-To add another cluster, follow the same steps as described in [adding a
-Kubernetes cluster](#adding-a-kubernetes-cluster) and make sure to
-[set an environment scope](#setting-the-environment-scope) that will
-differentiate the new cluster with the rest.
-
## Setting the environment scope
When adding more than one clusters, you need to differentiate them with an
@@ -201,5 +188,119 @@ The result will then be:
- The staging cluster will be used for the "deploy to staging" job.
- The production cluster will be used for the "deploy to production" job.
+## Multiple Kubernetes clusters
+
+> Introduced in [GitLab Enterprise Edition Premium][ee] 10.3.
+
+With GitLab EEP, you can associate more than one Kubernetes clusters to your
+project. That way you can have different clusters for different environments,
+like dev, staging, production, etc.
+
+To add another cluster, follow the same steps as described in [adding a
+Kubernetes cluster](#adding-a-kubernetes-cluster) and make sure to
+[set an environment scope](#setting-the-environment-scope) that will
+differentiate the new cluster with the rest.
+
+## Deployment variables
+
+The Kubernetes cluster integration exposes the following
+[deployment variables](../../../ci/variables/README.md#deployment-variables) in the
+GitLab CI/CD build environment:
+
+- `KUBE_URL` - Equal to the API URL.
+- `KUBE_TOKEN` - The Kubernetes token.
+- `KUBE_NAMESPACE` - The Kubernetes namespace is auto-generated if not specified.
+ The default value is `<project_name>-<project_id>`. You can overwrite it to
+ use different one if needed, otherwise the `KUBE_NAMESPACE` variable will
+ receive the default value.
+- `KUBE_CA_PEM_FILE` - Only present if a custom CA bundle was specified. Path
+ to a file containing PEM data.
+- `KUBE_CA_PEM` (deprecated) - Only if a custom CA bundle was specified. Raw PEM data.
+- `KUBECONFIG` - Path to a file containing `kubeconfig` for this deployment.
+ CA bundle would be embedded if specified.
+
+## Enabling or disabling the Cluster integration
+
+After you have successfully added your cluster information, you can enable the
+Cluster integration:
+
+1. Click the "Enabled/Disabled" switch
+1. Hit **Save** for the changes to take effect
+
+You can now start using your Kubernetes cluster for your deployments.
+
+To disable the Cluster integration, follow the same procedure.
+
+## Removing the Cluster integration
+
+NOTE: **Note:**
+You need Master [permissions] and above to remove a cluster integration.
+
+NOTE: **Note:**
+When you remove a cluster, you only remove its relation to GitLab, not the
+cluster itself. To remove the cluster, you can do so by visiting the GKE
+dashboard or using `kubectl`.
+
+To remove the Cluster integration from your project, simply click on the
+**Remove integration** button. You will then be able to follow the procedure
+and [add a cluster](#adding-a-cluster) again.
+
+## What you can get with the Kubernetes integration
+
+Here's what you can do with GitLab if you enable the Kubernetes integration.
+
+### Deploy Boards (EEP)
+
+> Available in [GitLab Enterprise Edition Premium][ee].
+
+GitLab's Deploy Boards offer a consolidated view of the current health and
+status of each CI [environment](../../../ci/environments.md) running on Kubernetes,
+displaying the status of the pods in the deployment. Developers and other
+teammates can view the progress and status of a rollout, pod by pod, in the
+workflow they already use without any need to access Kubernetes.
+
+[> Read more about Deploy Boards](https://docs.gitlab.com/ee/user/project/deploy_boards.html)
+
+### Canary Deployments (EEP)
+
+> Available in [GitLab Enterprise Edition Premium][ee].
+
+Leverage [Kubernetes' Canary deployments](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)
+and visualize your canary deployments right inside the Deploy Board, without
+the need to leave GitLab.
+
+[> Read more about Canary Deployments](https://docs.gitlab.com/ee/user/project/canary_deployments.html)
+
+### Kubernetes monitoring
+
+Automatically detect and monitor Kubernetes metrics. Automatic monitoring of
+[NGINX ingress](../integrations/prometheus_library/nginx.md) is also supported.
+
+[> Read more about Kubernetes monitoring](../integrations/prometheus_library/kubernetes.md)
+
+### Auto DevOps
+
+Auto DevOps automatically detects, builds, tests, deploys, and monitors your
+applications.
+
+To make full use of Auto DevOps(Auto Deploy, Auto Review Apps, and Auto Monitoring)
+you will need the Kubernetes project integration enabled.
+
+[> Read more about Auto DevOps](../../../topics/autodevops/index.md)
+
+### Web terminals
+
+NOTE: **Note:**
+Introduced in GitLab 8.15. You must be the project owner or have `master` permissions
+to use terminals. Support is limited to the first container in the
+first pod of your environment.
+
+When enabled, the Kubernetes service adds [web terminal](../../../ci/environments.md#web-terminals)
+support to your [environments](../../../ci/environments.md). This is based on the `exec` functionality found in
+Docker and Kubernetes, so you get a new shell session within your existing
+containers. To use this integration, you should deploy to Kubernetes using
+the deployment variables above, ensuring any pods you create are labelled with
+`app=$CI_ENVIRONMENT_SLUG`. GitLab will do the rest!
+
[permissions]: ../../permissions.md
[ee]: https://about.gitlab.com/gitlab-ee/