I've just started exploring Kubernetes and Concourse CI. Learning still, so I'm still understanding all the concepts. Forgive me if this question sounds naive.

Why would we deploy Concourse CI in Kubernetes. Is it just for the ease of deployment? I mean concourse has its own way for scaling workers which itself if I've understood is through containers. So why run something that can already scale and handle containers(I mean concourse) inside Kubernetes?


In our case yes, it is just ease of deployment/operations. We have existing skills with k8s and that's what we're most comfortable operating.

I guess you're right that its somewhat odd to run Concourse's scheduling inside of k8s scheduling, and it would be great to see Concourse being able to leverage Kubernetes directly at some point.

  • Drone CI is interesting as well, but not active enough. I am following closely Argo + Argo CI, really promising
    – DevLounge
    May 19 '18 at 1:17
  • another case is that concourse is using its own scheduler Garden, its own container management and orchestration. Why not use the most used community orchestrator? k8s already have jobs and if you need a new abstraction it can be extended easily by CRD
    – Walid
    Aug 29 '18 at 9:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.