Skip to content

Kubernetes integration should filter pods using deployment selector

Problem to solve

Integrating GitLab Kubernetes into existing cluster is quite challenging. By making the GitLab pod selector consistent with apps/v1.Deployment.spec.selector, things get a little bit easier.

Further details

GitLab currently requires multiple tags on both Deployment and Pod. By leveraging existing Kubernetes functionality, the integration can be simplified to only require the tags on Deployment (or other supported ReplicaSet managers such as DaemonSet)

Kubernetes selector can also be quite complex, as opposed to the single app label filter GitLab does currently. This would be beneficial for complex infrastructures.

By making the GitLab and Kubernetes selectors consistent, we remove a pain point in setting up the GitLab Kubernetes integration and allow for more dynamic environments.

Furthermore, this simplifies further changes to the filtering, such as configurable label name (eg. gitlab-filter=$CI_ENVIRONMENT_SLUG).

Proposal

  • Rewrite builtin pod filters (app=$CI_ENVIRONMENT_SLUG) to fetching a tagged Deployment (or DaemonSet) and using spec.selector for filtering pods

What does success look like, and how can we measure that?

Pods are no longer required to have app=$CI_ENVIRONMENT_SLUG label and the integration is more simple to set-up.

Links / references

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#deploymentspec-v1-apps

Edited by Mikuláš Dítě