Jenkins on Kubernetes Reference Architecture | Hacker News Reader

Jenkins on Kubernetes Reference Architecture

operator-service.com

2 pointsantoniaklja5 comments

> Running Jenkins in a cloud-native environment is possible, but it is not a piece of cake. Kubernetes is designed to run stateless software, where Jenkins is a stateful application.

If going the Jenkins route, why run it in Kubernetes when there are battle tested alternatives?

If going the Kubernetes route, why not use a Kubernetes native CI system?

Thanks for the comment! Interesting questions :)

> If going the Jenkins route, why run it in Kubernetes when there are battle tested alternatives?

With full interoperability with Kubernetes, we can take an advantage of built-in capabilities like declarative configuration, autoscaling, auth, etc. The old static VM-based approach, might be not effective cause you need to build everything around that VM - provisioning scripts, maintenance, autoscaling, security, etc. A lot of manual work and effort at the end of the day :)

> If going the Kubernetes route, why not use a Kubernetes native CI system?

There are no Kubernetes native CI systems, Kubernetes itself doesn't provide CI/CD capabilities. It's just another software with interoperability in this environment :)

Moreover, I'd say the effort related to migration two the new "battle tested" CI/CD system might be significant. Especially, in a large, complex deployment strategies.

For people already familiar with Jenkins ways of working and willing to explore k8s ecosystem, this might be good starting point.

With Jenkins on Kubernetes, you now need two levels of autoscaling, Jenkins workers and Kubernetes cluster. Without advanced configuration you will have many underutilized nodes. Jenkins has builtin scaling for VM workers. Those same points about provisioning and security apply to all software, regardless of running in K8s or not.

There are Kubernetes native CI systems, many of them. Tekton Pipelines is the basis for many like Jenkins X (the next gen Jenkins)

What company size and deployment model would make maintaining this worth it? 50 engineers and daily builds? I know there are much more complex systems in big tech where you would want a lot of control over the CI process. I assume this is for a mid market or even small company.

Today, average businesses spend months of engineering time dealing with day-one activities like installation, patching, and lifecycle management of the core services such as CI/CD tooling.

A typical development team spends 30% of their time on managing software delivery services with a lot of ad-hoc human intervention activities involved.

So, engineering time costs a lot of money and I'd say regardless of company size this is worth it. Especially, during the time of talent pool shortcomings you want to spend engineering effort more wisely.

Reply on news.ycombinator.com