A large part of our (Real Kinetic's) business is helping organizations implement platform engineering, but we've found the existing tooling to be lacking. For IaC, Terraform state becomes a pain because TF treats infrastructure as "one-shot" commands. The Kubernetes controller model provides a nicer approach to managing infrastructure, but the tooling here is also lacking. For configuration management, Helm just doesn't really scale with complexity, nor does Kustomize. For resource orchestration, Crossplane is a step in the right direction but still has challenges and limitations.<p>As a result, we ended up building something that's sort of a "meta-controller programming language" on top of Kubernetes called Koreo. It provides a solution for configuration management and resource orchestration in Kubernetes by basically letting you program controllers. We've been using Koreo for a while now to build internal developer platform capabilities for our commercial product and our clients, and we recently open sourced it to share it with the community.<p>Koreo has some similarities to configuration languages like KCL, Jsonnet, etc. since it is a means of configuration management (e.g. you can define base configurations, apply overlays, point patches, and so forth). Where it really diverges though is Koreo provides a unified approach to config management <i>and</i> resource orchestration. This means you can start to treat Kubernetes resources as "legos" to build pretty sophisticated workflows. For instance, the output of a resource can be used as the input to another resource. This isn't really possible with Helm, even with `lookup` because `lookup` requires the resource to already be in-cluster in order to reference it.<p>This is why we refer to Koreo as a meta-controller programming language because it effectively lets you program and compose Kubernetes controllers into cohesive platforms—either built-in controllers (think Deployment or StatefulSet), off-the-shelf ones such as AWS ACK or GCP's Config Connector, or custom operators. It lets you build or combine controllers without actually needing to implement an operator. Through this lens, Koreo is really more akin to Crossplane but without some of the limitations such as Providers and cluster-scoped managed resources.<p>It seems crazy and maybe it is, but I've found working in Koreo to actually be surprisingly fun since it kind of turns Kubernetes primitives into legos you can easily piece together, reuse, and build some pretty cool automated workflows. You can learn more about the motivation and thinking behind it here: <a href="https://theyamlengineer.com" rel="nofollow">https://theyamlengineer.com</a>
I feel like it needs a comparison with <a href="https://kro.run/" rel="nofollow">https://kro.run/</a> and crossplane v2 which makes it more generic and less cluster scoped.
I'd love to offer a few words of encouragement for this excellent project. This space only appears crowded to those that have already been here for a while. To everyone else, this might just be <i>the</i> most obvious thing to adopt for Kubernetes and they might not even have heard of Kustomize/Helm. So I would suggest two separate personas to target in the docs and communication: 1) Jaded devs that need to be convinced with detailed proof that Koreo isn't yet-another YAML tool. 2) Everyone else, to whom the pitch is that Koreo is the most obvious choice when the need is A, B, or C.<p>Looking forward to trying this out soon!<p>I also think more high level patterns would make Koreo more approachable. Real world problems and how they could be addressed with Koreo.
Just one more YAML bro I swear trust me bro just one more meta level will solve everything just one more yaml please I promise you it's not bad just write yaml it's simple and clean just some more yaml man just one more yaml file you will certainly not regret it just add one more yaml<p>(Congratulations on the launch, looks interesting!)
I’ve been really interested in understanding how these things work better, but I’m having a lot of trouble understanding the devex / UX. I _think_ the idea behind Koreo is that any user can upload some resource definition, and koreo essentially shores it up on the backend. If I say I want an s3 bucket, Kori will look at my custom resource, then maybe if I have a label a that says it’s a temporary bucket it adds yams to my resource to add a 30 day lifecycle policy to delete the resource.<p>But I’m not sure I feel the advantage of this indirection. It feels confusing to be that the applied resource will be different from what’s in VCS, and the code feels super heavy for what you’re getting. I’ve been at like this and cross plane, and can’t quite grok why this is better than doing it in a classical programming language. But I think I’m wrong, can you help me understand?
I feel I've built something similar using fluxcd + cuelang. FluxCD allows having order through depends on and how you organize your <i>Kustomization resource</i>.
I still believe the FluxCD project needs a UI that matches what you can get from the cli. CLI has so many features that you might or might not get fully from the available UI's.
I think I can see some of where this could be utilized, but I think I'm still missing a step and I'm hopeful someone can fill me in.<p>There's a comparison against Argo Workflows, but with the description here and in other comments, Koreo seems to be aiming more for what I would use Argo CD for - managing the entire state of the cluster, the controllers, configuration, etc. Because of it tying into repos, you can then define the entire state of your cluster in code, and Argo CD has tools for doing some of the interpolation of variables into your YAML.<p>The project looks cool, and I don't think that the world suffers from having multiple ways of doing something, I just want to understand it better.
Since I'm Ops type so I took a look. Here are my thoughts in random order.<p>Templating systems are always frustrating, and I couldn't find CLI to spit out exactly what I was going to get. Kustomize ability to build exactly what cluster is going to consume is one of those features you miss when you don't have it.<p>Tying it to Kubernetes is both good and bad. Alot of companies use Kubernetes so for those companies, this is great. Downside is I think many companies are not ready to deal with complexity of Kubernetes so system that could put them outside of it might be great. That's just taste I guess.<p>This is a crowded field so good luck I guess.<p>Finally, the problem here everyone is trying to solve is skill gap and that's hard to fix with technology. Most devs are bad at Ops and that's where friction comes. It's like watching Product Owner develop their feature using LowCode or AI. It works until it doesn't and when it doesn't, here we go. I also realize few companies want us around since they see as pure money sink.<p>Most of my frustration around building platforms is lack of communication. Most of it due to developers not understanding or just not thinking about it (See skill issue above) so Ops is forced to put in something ugly to get them into Prod at 11 hour so we don't get tossed under the bus.
why k8s ecosystem is so filled with yaml on-top-of-yaml, configuration on-top-of-configuration? where does this end? can we have less yaml, less configuration, not more?
Here's the tension I find with projects like these: App developer knowledge seems to end with a helm chart. Anything more complex than that, they won't be able to deliver themselves. For platform/k8s admins, these tools are more cumbersome than just writing a dedicated operator in go.<p>What advantages does this offer over rolling my own CRD and operator? Assume it takes me 4 hours to write an operator end to end.
We use Python to generate these configs at my work. Ends up working out pretty well. I previously worked on the biggest deployment of gcl (the inspiration for KCL, Jsonnet) at Google and it was a giant nightmare and the cause of many outages.
> Koreo is the engine that powers Konfigurate, a batteries-included developer platform for startups and scaleups.<p>Yaml is no go for me.<p>Gradually typed languages, with support of unkown values, like Nickel can be good.
Why half of Kubernetes and AWS look like technogies to support... themselves instead of shipping a new product such as LXC/LXD?<p>Most of the current technologies can be virtualized, and with LVM snapshots are a breeze, even extending media it's perfectly done. There's no need to use half-backed namespaces when kernel-level deduplition for memory pages exist when you run similar parallel VM's.<p>I find virtualisation far easier than containers. Not as fast to deploy, sure; but far more manageable for rollbacks.