Update Kubernetes deployments label selector
Description
The label selector used on the deploy boards (operations >> environments) queries for pods matching app=$CI_ENVIRONMENT_SLUG in the namespace configured on the project.
This presents the following problems
-
Some users deploy their apps via helm charts that already set the
applabel value on releases and have to overwrite this manually to see it on the deploy board, otherwise all deployments will appear to be for the same app. -
Some users experience a collission when tagging deployments with
CI_ENVIRONMENT_SLUGas the variable is set to be the environment name (ie production, staging, etc) the conflict comes where every app has a CI env called "production", if two applications are depoyed to the cluster in the same namespace, both apps will appear in the same place on the deploy boards.
Proposal
In order to prevent conflicts when doing our filtering in https://gitlab.com/gitlab-org/gitlab-ee/blob/541fee2676a73236c02921850b4d3a323951f407/app/models/project_services/kubernetes_service.rb#L134 we will need to add a separate label to distinguish different apps. Otherwise multiple apps will have the same value production when deploying via Auto DevOps. Provide 2 separate key values, such as app.gitlab.org/app=$CI_PROJECT_PATH_SLUG and app.gitlab.org/env=$CI_ENVIRONMENT_SLUG.
11.10: Deploy boards will match by app.gitlab.com/app and app.gitlab.com/env, or app
- Filter deploy boards on new labels with app fallback: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/25623 https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9759
- Set new labels on deployments: charts/auto-deploy-app!36 (merged)
- Give new values for labels to helm chart: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/26004
12.0: Deploy boards will match by app.gitlab.com/app and app.gitlab.com/env. This may not be possible until all existing deployments have been deployed with the updated chart.
Links / references
Related issues:
https://gitlab.com/gitlab-org/gitlab-ee/issues/6389
https://gitlab.com/gitlab-org/gitlab-ee/issues/5470
Related features:
-
Pod Logs: https://docs.gitlab.com/ee/user/project/clusters/kubernetes_pod_logs.html
-
CPU/Memory metrics detection, which wants to match the podname to
CI_ENVIRONMENT_SLUG: https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/kubernetes.html -
Deploy boards: https://docs.gitlab.com/ee/user/project/deploy_boards.html
-
Web terminals: https://docs.gitlab.com/ee/user/project/clusters/#web-terminals
Original issue content
We're trying to move over to GitLab for our CI/CD needs, and are testing out the new Kubernetes integrations for some projects here. We have some tooling we wish to deploy using Helm that works great, but we find the label selector used on the Environments dashboard screen when pulling out Kubernetes deployments is messing with our workflow a bit.
As far as I can tell, it tries to query for pods matching app=$CI_ENVIRONMENT_SLUG in the namespace configured on the project; the problem is that most Helm charts we deploy already set another app label on the releases - and we'd prefer not having to overwrite that one per-environment.
Would it be possible to have GitLab use a more appropriate label selector here? At least personally, I feel like using env=$CI_ENVIRONMENT_SLUG is a much better query than using the app label. The app is the same app regardless of environment, the varying factor is the environment.
Proposal
I propose that the label selector used by the Kubernetes environment deployment status is either configurable, or that it uses a label that makes it easier for people moving over to GitLab from other CI/CD systems to get up and running.
Links / references
Related issue https://gitlab.com/gitlab-org/gitlab-ee/issues/6389