debian-mirror-gitlab/doc/user/group/clusters/index.md

193 lines
7.8 KiB
Markdown
Raw Normal View History

2019-09-04 21:01:54 +05:30
---
type: reference
2020-05-24 23:13:21 +05:30
stage: Configure
group: Configure
2021-02-22 17:27:13 +05:30
info: 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
2019-09-04 21:01:54 +05:30
---
2021-12-11 22:18:48 +05:30
# Group-level Kubernetes clusters (certificate-based) (DEPRECATED) **(FREE)**
2019-02-15 15:39:39 +05:30
2021-12-11 22:18:48 +05:30
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/34758) in GitLab 11.6.
> - [Deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
WARNING:
This feature was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5. To connect clusters to GitLab,
2022-05-07 20:08:51 +05:30
use the [GitLab agent](../../clusters/agent/index.md).
2019-02-15 15:39:39 +05:30
2019-07-31 22:56:46 +05:30
Similar to [project-level](../../project/clusters/index.md) and
[instance-level](../../instance/clusters/index.md) Kubernetes clusters,
group-level Kubernetes clusters allow you to connect a Kubernetes cluster to
your group, enabling you to use the same cluster across multiple projects.
2019-02-15 15:39:39 +05:30
2021-11-18 22:05:49 +05:30
To view your group-level Kubernetes clusters:
1. On the top bar, select **Menu > Groups** and find your group.
1. On the left sidebar, select **Kubernetes**.
2021-01-03 14:25:43 +05:30
2021-09-04 01:27:46 +05:30
## Cluster management project
2019-02-15 15:39:39 +05:30
2021-09-04 01:27:46 +05:30
Attach a [cluster management project](../../clusters/management_project.md)
to your cluster to manage shared resources requiring `cluster-admin` privileges for
installation, such as an Ingress controller.
2019-02-15 15:39:39 +05:30
## RBAC compatibility
2020-06-23 00:09:42 +05:30
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/29398) in GitLab 11.4.
2021-12-11 22:18:48 +05:30
> - Project namespace restriction was [introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/51716) in GitLab 11.5.
2019-02-15 15:39:39 +05:30
2020-05-24 23:13:21 +05:30
For each project under a group with a Kubernetes cluster, GitLab creates a restricted
service account with [`edit` privileges](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)
in the project namespace.
2019-02-15 15:39:39 +05:30
## Cluster precedence
2020-05-24 23:13:21 +05:30
If the project's cluster is available and not disabled, GitLab uses the
project's cluster before using any cluster belonging to the group containing
the project.
2021-03-11 19:13:27 +05:30
In the case of subgroups, GitLab uses the cluster of the closest ancestor group
2019-02-15 15:39:39 +05:30
to the project, provided the cluster is not disabled.
2020-07-28 23:09:34 +05:30
## Multiple Kubernetes clusters
2019-02-15 15:39:39 +05:30
2021-12-11 22:18:48 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35094) in GitLab 13.2.
2020-07-28 23:09:34 +05:30
You can associate more than one Kubernetes cluster to your group, and maintain different clusters
2020-05-24 23:13:21 +05:30
for different environments, such as development, staging, and production.
2019-02-15 15:39:39 +05:30
2020-05-24 23:13:21 +05:30
When adding another cluster,
2020-11-24 15:15:51 +05:30
[set an environment scope](#environment-scopes) to help
2020-05-24 23:13:21 +05:30
differentiate the new cluster from your other clusters.
2019-02-15 15:39:39 +05:30
2019-09-04 21:01:54 +05:30
## GitLab-managed clusters
2019-07-31 22:56:46 +05:30
2020-03-13 15:44:24 +05:30
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22011) in GitLab 11.5.
> - Became [optional](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/26565) in GitLab 11.11.
2019-07-31 22:56:46 +05:30
2020-05-24 23:13:21 +05:30
You can choose to allow GitLab to manage your cluster for you. If GitLab manages
2021-02-22 17:27:13 +05:30
your cluster, resources for your projects are automatically created. See the
2021-11-18 22:05:49 +05:30
[Access controls](../../project/clusters/cluster_access.md)
2020-05-24 23:13:21 +05:30
section for details on which resources GitLab creates for you.
2019-07-31 22:56:46 +05:30
2021-02-22 17:27:13 +05:30
For clusters not managed by GitLab, project-specific resources aren't created
2020-05-24 23:13:21 +05:30
automatically. If you're using [Auto DevOps](../../../topics/autodevops/index.md)
2019-12-26 22:10:19 +05:30
for deployments with a cluster not managed by GitLab, you must ensure:
- The project's deployment service account has permissions to deploy to
2021-09-30 23:02:18 +05:30
[`KUBE_NAMESPACE`](../../project/clusters/deploy_to_cluster.md#deployment-variables).
2019-12-26 22:10:19 +05:30
- `KUBECONFIG` correctly reflects any changes to `KUBE_NAMESPACE`
2020-06-23 00:09:42 +05:30
(this is [not automatic](https://gitlab.com/gitlab-org/gitlab/-/issues/31519)). Editing
2019-12-26 22:10:19 +05:30
`KUBE_NAMESPACE` directly is discouraged.
2019-07-31 22:56:46 +05:30
2020-01-01 13:55:28 +05:30
### Clearing the cluster cache
2020-06-23 00:09:42 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/31759) in GitLab 12.6.
2020-01-01 13:55:28 +05:30
If you choose to allow GitLab to manage your cluster for you, GitLab stores a cached
version of the namespaces and service accounts it creates for your projects. If you
modify these resources in your cluster manually, this cache can fall out of sync with
your cluster, which can cause deployment jobs to fail.
To clear the cache:
2021-11-18 22:05:49 +05:30
1. On the top bar, select **Menu > Groups** and find your group.
1. On the left sidebar, select **Kubernetes**.
1. Select your cluster.
1. Expand **Advanced settings**.
1. Select **Clear cluster cache**.
2020-01-01 13:55:28 +05:30
2019-03-02 22:35:43 +05:30
## Base domain
2020-03-13 15:44:24 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24580) in GitLab 11.8.
2019-03-02 22:35:43 +05:30
Domains at the cluster level permit support for multiple domains
2020-07-28 23:09:34 +05:30
per [multiple Kubernetes clusters](#multiple-kubernetes-clusters) When specifying a domain,
2021-02-22 17:27:13 +05:30
this is automatically set as an environment variable (`KUBE_INGRESS_BASE_DOMAIN`) during
2019-03-02 22:35:43 +05:30
the [Auto DevOps](../../../topics/autodevops/index.md) stages.
2021-09-30 23:02:18 +05:30
The domain should have a wildcard DNS configured to the Ingress IP address. [More details](../../project/clusters/gitlab_managed_clusters.md#base-domain).
2019-02-15 15:39:39 +05:30
2019-09-30 21:07:59 +05:30
## Environment scopes **(PREMIUM)**
2019-02-15 15:39:39 +05:30
2019-07-07 11:18:12 +05:30
When adding more than one Kubernetes cluster to your project, you need to differentiate
them with an environment scope. The environment scope associates clusters with
2020-05-24 23:13:21 +05:30
[environments](../../../ci/environments/index.md) similar to how the
2021-09-30 23:02:18 +05:30
[environment-specific CI/CD variables](../../../ci/variables/index.md#limit-the-environment-scope-of-a-cicd-variable)
2019-02-15 15:39:39 +05:30
work.
While evaluating which environment matches the environment scope of a
2020-05-24 23:13:21 +05:30
cluster, [cluster precedence](#cluster-precedence) takes
effect. The cluster at the project level takes precedence, followed
2019-02-15 15:39:39 +05:30
by the closest ancestor group, followed by that groups' parent and so
on.
2020-05-24 23:13:21 +05:30
For example, if your project has the following Kubernetes clusters:
2019-02-15 15:39:39 +05:30
| Cluster | Environment scope | Where |
| ---------- | ------------------- | ----------|
| Project | `*` | Project |
| Staging | `staging/*` | Project |
| Production | `production/*` | Project |
| Test | `test` | Group |
| Development| `*` | Group |
2021-09-30 23:02:18 +05:30
And the following environments are set in [`.gitlab-ci.yml`](../../../ci/yaml/index.md):
2019-02-15 15:39:39 +05:30
```yaml
stages:
2020-07-28 23:09:34 +05:30
- test
- deploy
2019-02-15 15:39:39 +05:30
test:
stage: test
script: sh test
deploy to staging:
stage: deploy
script: make deploy
environment:
name: staging/$CI_COMMIT_REF_NAME
url: https://staging.example.com/
deploy to production:
stage: deploy
script: make deploy
environment:
name: production/$CI_COMMIT_REF_NAME
url: https://example.com/
```
2020-05-24 23:13:21 +05:30
The result is:
2019-02-15 15:39:39 +05:30
2020-05-24 23:13:21 +05:30
- The Project cluster is used for the `test` job.
- The Staging cluster is used for the `deploy to staging` job.
- The Production cluster is used for the `deploy to production` job.
2019-02-15 15:39:39 +05:30
2019-12-04 20:38:33 +05:30
## Cluster environments **(PREMIUM)**
2020-05-24 23:13:21 +05:30
For a consolidated view of which CI [environments](../../../ci/environments/index.md)
2019-12-21 20:55:43 +05:30
are deployed to the Kubernetes cluster, see the documentation for
[cluster environments](../../clusters/environments.md).
2019-12-04 20:38:33 +05:30
2020-11-24 15:15:51 +05:30
## Security of runners
2019-10-12 21:52:04 +05:30
2020-11-24 15:15:51 +05:30
For important information about securely configuring runners, see
2021-09-30 23:02:18 +05:30
[Security of runners](../../project/clusters/cluster_access.md#security-of-runners)
2019-10-12 21:52:04 +05:30
documentation for project-level clusters.
2020-03-13 15:44:24 +05:30
## More information
For information on integrating GitLab and Kubernetes, see
2021-11-18 22:05:49 +05:30
[Kubernetes clusters](../../infrastructure/clusters/index.md).
2020-03-13 15:44:24 +05:30
2019-09-04 21:01:54 +05:30
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->