<p>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.</p>

<p>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.</p>

CC BY-SA 4.0
2018-05-19T01:17:23.747Z
Drone CI is interesting as well, but not active enough. I am following closely Argo + Argo CI, really promising
DevLounge
CC BY-SA 4.0
2018-08-29T09:27:27.993Z
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
CC BY-SA 3.0
2018-02-16T11:54:18.973Z
2018-02-16T11:54:18.973Z
Andy Hume
<p>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.</p>

<p>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?</p>

<continuous-integration><kubernetes><containers><configuration>
Why Run Concourse CI in Kubernetes
Vipin Menon
# Why Run Concourse CI in Kubernetes

(Asked by: username_0 on 2018-02-16)

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?

**Tags:** continuous-integration, kubernetes, containers, configuration


---

## 1 answers

### Answer by username_1 on 2018-02-16. Score: 2

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.

> **Comments:**
> **username_2**: Drone CI is interesting as well, but not active enough. I am following closely Argo + Argo CI, really promising  
> **username_3**: 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  

---

