How UCloud Built a Kubernetes‑Powered CI/CD Platform with GitLab and KUN

UCloud has long used GitLab for code management, but found its CI/CD agility insufficient, with release cycles still measured in days. To improve, they created an internal Kubernetes‑based container service platform called KUN, integrated GitLab with KUN, and leveraged Kubernetes' cloud‑native advantages for faster CI/CD.

CI/CD Goals

Continuous Integration (CI) requires all code changes to pass automated tests before merging, ensuring rapid iteration without sacrificing quality. Continuous Delivery (CD) means every change is validated and ready for production, while Continuous Deployment automates the final production rollout; UCloud aims for the latter.

GitLab Branch Management

The branch model remains unchanged after adopting KUN:

master : main branch, code is verified; releases are created from tags.

dev : development branch for feature and patch integration.

temporary branches : feature branches for new features and patch branches for bug fixes.

CI/CD Development Flow Example

Using the StepFlow visual workflow product, the team developed the optimize-allocate feature. The process included creating an Issue, branching from dev, committing code (triggering static checks, unit tests, and reviews), merging back to dev after approval, then merging to master, tagging the release, and finally deploying.

Note: Tag version format follows v{major}.{minor}.{patch}.

GitLab CI/CD Pipeline

GitLab 8.0+ includes GitLab‑CI, which defines Pipelines, Stages, and Jobs via a .gitlab-ci.yml file. A Pipeline runs on code changes; each Pipeline contains ordered Stages (e.g., static check, unit test, image build), and each Stage contains parallel Jobs with properties such as image, stage, tags, and service.

For the StepFlow example, the feature pipeline includes static checks, unit tests, and two manual code‑review steps. Additional pipelines handle pre‑release deployment and production deployment, each adding appropriate stages and jobs.

GitLab Runner

Runners execute Jobs; the Kubernetes executor runs each Job in a Pod created from a specified image. The workflow is: register Runner → GitLab notifies Runner on code change → Runner creates Pod → commands run → results reported back.

Kaniko Integration

To build Docker images inside CI jobs without privileged containers, the team customized the Kaniko image (adding the full busybox toolset) so it can run as a regular Job. Example commands:

# use Docker:
$ cd /path/to/project && \
    docker build -t uhub.service.ucloud.cn/myimage:0.0.1 -f deploy/Dockerfile && \
    docker push uhub.service.ucloud.cn/myimage:0.0.1
# use Kaniko:
$ /kaniko/executor -c /path/to/project -f deploy/Dockerfile -d uhub.service.ucloud.cn/myimage:0.0.1

KUN + GitLab: Kubernetes‑Based CI/CD

The overall CI/CD flow in KUN combines CI (unit tests, pre‑release deployment, integration tests, debugging) with CD (deployment via a backend system). Users trigger deployments through a UI that submits generated YAML files to the deployment system.

YAML Editor

KUN provides a specialized YAML editor offering template snippets, hover tooltips with documentation links, and search‑replace shortcuts, enhancing the authoring experience for deployment manifests.

Deployment System

The system manages resource sets (collections of Kubernetes objects) with versioning, and creates deployment tasks (jobs) that invoke the Kubernetes API using the user's permissions, allowing users to view logs for each task.

Conclusion

By embedding GitLab into the KUN platform and running on Kubernetes, UCloud achieved a highly efficient CI/CD pipeline, reducing compile job times to about three minutes and other jobs to under one minute, significantly improving development efficiency and service quality.