Update Kubernetes deployments label selector
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.
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
Links / references
CPU/Memory metrics detection, which wants to match the podname to
Deploy boards: https://docs.gitlab.com/ee/user/project/deploy_boards.html
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.
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 #6389