Nane Kratzke


A Self-service User-interface for Creating Gitlab-projects with Kubernetes Integration

Published: 07 Sep 2020 (latest update: 27 Jan 2021)
Type: Bachelor (B. Sc.)
Author: Tom Christopher Böttger
State: completed
Study: Computer Science
Language: English
Laboratory: myLab

As part of its computer science teaching and other (research) projects, the myLab at the TH Lübeck (THL) uses both GitLab and Kubernetes. The intention is to establish a Kubernetes cluster as a flexible shared hosting platform for research and student projects of any kind.

However, Kubernetes has the disadvantage of a very steep learning curve. Therefore, this service has not been widely used by students. Due to its limited usability, it is mostly used “behind the scenes” at the THL.

This bachelor thesis will address this problem and develop a “scaffolding” solution that generates preconfigured Kubernetes namespaces and example GitLab projects (Git repositories) that are built and deployed automatically using GitLab CI pipelines. These projects can serve as a starting point for further project work and should flatten the Kubernetes and CI pipeline learning curve.

  • The scaffolding solution (in the following referred to as Scaffolder) shall be distributed and configured via Helm 3 and then deployed as an application in any Kubernetes cluster.
  • Users should authenticate to the Scaffolder by using the OAuth 2.0 interface integrated into GitLab (The OAuth 2.0 interface of the THL GitLab instance should be used as a reference).
  • The Scaffolder is to be designed stateless. It should not maintain a state over the namespaces and related user projects and therefore, cannot enforce limits on the number of projects per user.
  • The Scaffolder is intended to create Gitlab repositories on behalf of the authenticated user. These repositories should contain:
    • Access credentials to the created namespace in the Kubernetes Cluster
    • A configured GitLab CI pipeline example (.gitlab-ci.yml) that allows automated builds and deployments
    • Deployment examples (to be selected by users via the Scaffolder interface) covering typical Kubernetes workloads (Deployment, StatefulSet, CronJob, Job), common languages (e.g. Java, Python, NodeJS, etc.), and possibly standard stateful services (e.g.~Redis, MySQL, etc.) in such a way that a user can quickly configure his source template (e.g. Python + Redis)
    • Exposing examples (also selectable by users) should cover Kubernetes Service and Ingress resources.
  • The Scaffolder should create Kubernetes namespaces, provided that the particular namespace is still available. The namespaces must be configured as follows:
    • Resource quotas for CPU, memory, and storage for namespaces must be specified (values must be configurable)
    • Limit ranges for containers must be specified (values must be configurable)
    • The namespace should include a service account.
    • This service account should be bound to a read/write role that allows the service account to manipulate and view only resources within its namespace.

A suitable architecture must be developed for the Scaffolder. A setup composed of a single page web app and a REST-based backend is preferable. The Scaffolder (web app) should be easy and intuitive to use! Simplicity comes before functionality!