Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Concourse Kubernetes Operator #45

wants to merge 2 commits into
base: master
Choose a base branch


Copy link

Signed-off-by: Ciro S. Costa <>
Signed-off-by: Ciro S. Costa <>
@cirocosta cirocosta changed the title RFC 045: Concourse Kubernetes Operator RFC: Concourse Kubernetes Operator Mar 4, 2020
name: hush-house
replicas: 2

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Am I correct to infer that this CRD only represents ATC's, and isn't responsible for creating workers? Or is this looking to a point beyond having worker pods, where the cluster itself is a "worker"?

I'm not too familiar with how the k8s worker experiment you created works, but it may be the case that with "k8s workers", the ATC creates pods for steps/resource checks (and there's no dedicated "worker" pods)?

Copy link

One blocker for this is that the core team has no desire to build or maintain an operator right now. I don't see the team trying to support anything k8s-related besides the chart right now.

This talk also got me wondering if writing an operator is even a good idea for Concourse:

  • Secret generation is really rough on k8s right now. I think this is a problem the platform needs to solve. The operator solution here feels like a stopgap until the platform catches up
  • The motivation for k8s Operators seems to be for stateful applications. Concourse itself is a pretty good example of a classic 12-factor app. All state is in the db which users are probably not using the postgres chart for.

Postponing for now, we'll see how the k8s landscape changes in the future.

Copy link

The k8s runtime for Concourse feels like a natural fit. If a team correctly sizes (resource.limits) a given step or task then k8s does scheduling and scaling.

Sad to see this delayed.

Copy link

Postponing for now, we'll see how the k8s landscape changes in the future.

Agree. I don't see a need for concourse operator right now, There are other proposals that should be prioritized.

Copy link

rkoster commented Sep 1, 2022

One other way to go about this issue is to use and its secret-gen-controller. This is the approach that has been taken by the [reusable concourse templates used by the bosh community][].

Copy link

DrummyFloyd commented Mar 31, 2023

any news ?
a K8S runtimes would be great to deal a better granularity/scalbility on K8S cluster.
atm it's not very intuitive or easy to set those thing.. we have too much options
K8S side and Concourse side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
7 participants