I like the idea of Kro very much, similar to Crossplane or Kratix, because it creates abstractions by extending the K8s API with new objects. So far, so good. I am particularly interested in Kro because I like the way it lets people write a CRD, as you mentioned in your video. It could be the start of something cool, but as you also mentioned, it is still very green, and I would like to see how the project builds a community. Will it be a Crossplane killer? In terms of abstraction creation, it could be. Maybe if you throw AWS Controllers for Kubernetes (ACK) into the mix, you could end up with a purely AWS Frankenstein version of Crossplane. However, there is still a long way to go, and there is no guarantee that the project will be maintained or develop a large community behind it.
The best part of this video is the news that Crossplane 2.0 will make resources namespaces scoped and not cluster scoped. It has been a blocker for use to using CrossPlane for infrastructure. I checked out the Crossplane Roadmap and I don't see that feature. I don't see anything about it in the release schedule. I guess this is a 2026 release?
Honestly, I'm not sure where it is. I am in a lot of conversations and often I do not even know any more where some info comes from. I would suggest going to the next crossplane community meeting. They are on Thursdays and I am sure that will be discussed there soon. If you go through crossplane repo there is most like a document or two describing it as well. Sorry for not bring more helpful. I am not very organized and do not keep track of conversations and documents i read.
Great video! I've once started a project that took a system/application definition written in a groovy-based DSL and generated multiple outputs depending on the selcted target. It was basically an MDA pipeline, but geared towards IaC code generation instead of regular code. It seems that the demand for such tools does exist, but we're still looking for the right compromise between usability x flexibility (both for user and platform providers).
You can reduce sync frequency to reduce costs. In general, the cost will depend on the number or managed resources you have. I haven't heard complaints though.
@ thank you very much. I didn’t that by setting -max-reconciliation-rate to 1 already. I even used a specific deploymentRuntimeConfig/serviceAccount per provider.
Thanks for another great video 🎉 I must say kro sounds really immature, but most of all I asked myself the same question while watching the video: why? We'll see about that. For now I'd say that kro is rather... KO!
I was thinking of choosing it for my IDP but after watching this video l will not. It’s not matured and Crossplane is far more better choice. Anyway thanks for the video it’s was awesome 🙌
At around 5:30 - 6:00 you mention benefits of exposing services through API's as opposed to helm charts. Do you have a previous video that elaborates on this and goes in more depth? Thanks for this video.
I talked about it in quite a few videos but I'm not sure whether i have one dedicated to only that. Th gost of it Is thst all cloud providers are api-first for a reason. A big part in kubernetes success is it's API and since the introduction of CRDs that API is now extensible so there is no reason not to use it. Actually, almost everything we do today is using APIs and the question is only whether we should create our own. I'm working on a video about implementation of everything needed to build a developer Platform and the conversation about building our own APIs is certainly going to be a part of it.
@tshayan, i think @devopstoolkit is preferring to compose kube resources with kube-native runtime building blocks (controllers and CRDs). helm charts are putting final resources by assembling text files to look like k8 spec yaml. helm charts is external (file templating) thing. kubernetes resources are reporting events, expose APIs to communicate with them after deployment and follow a schema. helm does text templating (pretty much).
17 дней назад+1
Note that there is a crossover solution, thus to convert a helm chart to an operator as part of Operator SDK.
Just to reassure you: in my mind, the fact that you're actively involved in Crossplane makes you the perfect test subject for trying out other projects like kro that aim to achieve the same thing. That being said, there is and will always be an internal challenge you're having, where one part of your mind tries to be open and the other tries to constantly reflect upon and compare those other projects to Crossplane. You seem like a guy that wants tools that help us get things done, and with Crossplane, all you do in the end is help make it better by what you learned trying out kro - and hopefully contributing to the latter as well, if you find anything negative about it that you want fixed, or anything prositive that you want to improve even further. "How you use your power" is all up to you :D
Thanks for the good review! Lack of statuses and events, problems with updating and deleting resources is a total showstopper, at least for me. BTW, do you have any plans to make video about Kratix?
Great Tutorial! Could you please create a video tutorial on application auto-instrumentation with Grafana Beyla without using Grafana Cloud? It would be fantastic if you could explore this topic in-depth, providing detailed steps and examples to set up and use Grafana Beyla in a self-hosted environment. Looking forward to your response and hoping for a comprehensive guide on this topic!
Thank you for your informative videos as always😊. I have a question. I saw you deleting application finalizer when the namespace got stucked in deletion. 1. Is it a good practice to remove a finalizer when a k8s object is stucked in deletion? 2. Won't they be orphaned resources left behind? 3. What other ways could be used to address this issue without removing finalizer?
1. It is NOT a good practice. It is the last resort. 2. You could end up with orphaned resources. 3. In situations like that one I could not find another way to resolve it. Whenever you see me removing finalizes it is because nothing else worked. All in all, remove finalizes only as the last resort.
That could be it. Still, it's not documented so it's a wild guess. In any case, both options should be available. Service owners should be able to update ResourceGroup resources that should update all instances of it when the objective is to update all and changes are not breaking. There should also be an option to create a new API version of a ResourceGroup and that should not affect any existing instances of it. That's the opt in option.
Thank you for a great video! You said that Crossplane will have NS scoped resources in v2, two questions: 1. Do you know when v2 supposed to be released? 2. Does it also included NS ProviderConfigs/ProviderConfig that use credentials based on NS in a way that each NS will have it own creds for the ProviderConfig to use? That will be really helpful for my needs
Kro helps us create CRDs and controllers that compose resources in kubernetes clusters. That is the same objective as the one crossplane compositions have. Crossplane also has other features like providers that we use to create kubernetes resources that manage resources somewhere else (e.g. AWS). In that video I am comparing kro only with Crossplane compositions and ignore the rest. Helm, on the other hand, does not create CRDs and controllers. It is an engine that converts templates into yaml before applying them to the cluster. On way to look at it is to say that helm does "stuff" on the client-side before we get to kubernetes API while kro and crossplane extend the API and perform in-cluster operations.
@@DevOpsToolkit In my head I couldn't stop thinking about Helm and making library charts, but I didn't consider about the server vs client side work involved so makes sense as to why Helm wasn't mentioned in this video
Yeah. Otherwise I would have to open a completely different Pandora's box. I did not want to go through client vs server side processing, APIs, and other differences in that video.
On the slack channel we had the same discussion and the maintainers leaned more towards it being more along the lines of helm than crossplane - text below. *Comparing it to Helm is fair - think of it as "helm as controller running inside your cluster".
True. All tools that compose resources (kubevela, crossplane compositions, kro, etc.) are like helm inside a cluster where values file is similar to CRDs and templates are similar to controllers (assuming that templating is dobe periodically so that there is some kind of drift detection and reconciliation).
This was very helpful. I agree. Patching not working is unacceptable and weird. Do they really test this by recreating all the time? Hope they fix it soon enough along with the metadata.ownerReferences. Also why not use CEL in conditionals?
@@DevOpsToolkit Yeah, same here. I did not like the way Azure Devops included loops into their pipelines neither. It really makes YAML more complex as it should be.
you got me scared for a while... we invested a lot in crossplane so it could be easily upstaged by such a new project. I usually reason that mature projects dealt with so many issues that new ones have not even realized. I assume the major reason people drift to such new projects that reinvent the wheel is the complexity of the more mature ones. but complexity is unavoidable at times and unfortunately our industry is full of people losing their time and $ in dead ends that only are more simple in the short term :( .
there is also the platform engineering perspective of this complexity. platform engineering is complex, but using a platform should be simple ... that is the goal. frameworks for building platforms, like crossplane are very hard to design in a simple way especially if we want them to be flexible but they are to be configured by experts on the subject. if people dont understand this internal platform perspective, together with other adjacent topics like team topologies, they are bound to have bad ideas for new frameworks.
Thank you for making this video, especially since I was interested in this subject!
Now I am patiently waiting for a video about kratix :D
nice, and now we are back to helm2
I like the idea of Kro very much, similar to Crossplane or Kratix, because it creates abstractions by extending the K8s API with new objects. So far, so good. I am particularly interested in Kro because I like the way it lets people write a CRD, as you mentioned in your video. It could be the start of something cool, but as you also mentioned, it is still very green, and I would like to see how the project builds a community. Will it be a Crossplane killer? In terms of abstraction creation, it could be. Maybe if you throw AWS Controllers for Kubernetes (ACK) into the mix, you could end up with a purely AWS Frankenstein version of Crossplane. However, there is still a long way to go, and there is no guarantee that the project will be maintained or develop a large community behind it.
The best part of this video is the news that Crossplane 2.0 will make resources namespaces scoped and not cluster scoped. It has been a blocker for use to using CrossPlane for infrastructure. I checked out the Crossplane Roadmap and I don't see that feature. I don't see anything about it in the release schedule. I guess this is a 2026 release?
I can't guarantee anything. My best guess is that 2.0 will be released on 2025. Just don't take that as a promise.
@@DevOpsToolkit do you have some kind of link or doc where this is mentioned?
Honestly, I'm not sure where it is. I am in a lot of conversations and often I do not even know any more where some info comes from. I would suggest going to the next crossplane community meeting. They are on Thursdays and I am sure that will be discussed there soon. If you go through crossplane repo there is most like a document or two describing it as well.
Sorry for not bring more helpful. I am not very organized and do not keep track of conversations and documents i read.
A new wave of new tools... should be good news eventually.
Thanks for the great video! A little bit of competition is always healthy, wonder what new ideas AWS folks can give in this space :)
I was hoping you'd have a look at KRO, though it's alpha and I'm generally wary of internal open source projects pre-released at annual conferences.
Great video! I've once started a project that took a system/application definition written in a groovy-based DSL and generated multiple outputs depending on the selcted target.
It was basically an MDA pipeline, but geared towards IaC code generation instead of regular code.
It seems that the demand for such tools does exist, but we're still looking for the right compromise between usability x flexibility (both for user and platform providers).
That is awesome!
Thank you for the video. Very useful.
Quick one: have you faced the high cloudwatch costs related to crossplane when EKS audit logs are enabled?
You can reduce sync frequency to reduce costs. In general, the cost will depend on the number or managed resources you have. I haven't heard complaints though.
@ thank you very much. I didn’t that by setting -max-reconciliation-rate to 1 already. I even used a specific deploymentRuntimeConfig/serviceAccount per provider.
Thanks for another great video 🎉 I must say kro sounds really immature, but most of all I asked myself the same question while watching the video: why? We'll see about that. For now I'd say that kro is rather... KO!
I was thinking of choosing it for my IDP but after watching this video l will not. It’s not matured and Crossplane is far more better choice. Anyway thanks for the video it’s was awesome 🙌
At around 5:30 - 6:00 you mention benefits of exposing services through API's as opposed to helm charts. Do you have a previous video that elaborates on this and goes in more depth? Thanks for this video.
I talked about it in quite a few videos but I'm not sure whether i have one dedicated to only that. Th gost of it Is thst all cloud providers are api-first for a reason. A big part in kubernetes success is it's API and since the introduction of CRDs that API is now extensible so there is no reason not to use it. Actually, almost everything we do today is using APIs and the question is only whether we should create our own.
I'm working on a video about implementation of everything needed to build a developer Platform and the conversation about building our own APIs is certainly going to be a part of it.
@tshayan, i think @devopstoolkit is preferring to compose kube resources with kube-native runtime building blocks (controllers and CRDs). helm charts are putting final resources by assembling text files to look like k8 spec yaml. helm charts is external (file templating) thing. kubernetes resources are reporting events, expose APIs to communicate with them after deployment and follow a schema. helm does text templating (pretty much).
Note that there is a crossover solution, thus to convert a helm chart to an operator as part of Operator SDK.
Just to reassure you: in my mind, the fact that you're actively involved in Crossplane makes you the perfect test subject for trying out other projects like kro that aim to achieve the same thing. That being said, there is and will always be an internal challenge you're having, where one part of your mind tries to be open and the other tries to constantly reflect upon and compare those other projects to Crossplane. You seem like a guy that wants tools that help us get things done, and with Crossplane, all you do in the end is help make it better by what you learned trying out kro - and hopefully contributing to the latter as well, if you find anything negative about it that you want fixed, or anything prositive that you want to improve even further. "How you use your power" is all up to you :D
Thanks for the good review! Lack of statuses and events, problems with updating and deleting resources is a total showstopper, at least for me.
BTW, do you have any plans to make video about Kratix?
I have Kratix on my TODO list but cannot (yet) say when its turn will come. It's a very big TODO list...
I think as much such kind of projects appears, even buggy, as fast we come to "gold standard" for control planes, like it was in k8s.
Reading the documentation I see that kro will validate and create the required CRDs automatically, Crossplane have this capacity?
Yes it does 🙂
Great Tutorial!
Could you please create a video tutorial on application auto-instrumentation with Grafana Beyla without using Grafana Cloud? It would be fantastic if you could explore this topic in-depth, providing detailed steps and examples to set up and use Grafana Beyla in a self-hosted environment.
Looking forward to your response and hoping for a comprehensive guide on this topic!
Adding it to my to-do list...
@@DevOpsToolkit Appreciated. Thank you so much!
which kro version did you test?
Not sure... Whichever was the latest few months ago.
Thank you for your informative videos as always😊. I have a question.
I saw you deleting application finalizer when the namespace got stucked in deletion.
1. Is it a good practice to remove a finalizer when a k8s object is stucked in deletion?
2. Won't they be orphaned resources left behind?
3. What other ways could be used to address this issue without removing finalizer?
1. It is NOT a good practice. It is the last resort.
2. You could end up with orphaned resources.
3. In situations like that one I could not find another way to resolve it. Whenever you see me removing finalizes it is because nothing else worked.
All in all, remove finalizes only as the last resort.
That could be it. Still, it's not documented so it's a wild guess.
In any case, both options should be available. Service owners should be able to update ResourceGroup resources that should update all instances of it when the objective is to update all and changes are not breaking. There should also be an option to create a new API version of a ResourceGroup and that should not affect any existing instances of it. That's the opt in option.
Thank you for a great video!
You said that Crossplane will have NS scoped resources in v2, two questions:
1. Do you know when v2 supposed to be released?
2. Does it also included NS ProviderConfigs/ProviderConfig that use credentials based on NS in a way that each NS will have it own creds for the ProviderConfig to use? That will be really helpful for my needs
I cannot answer those questions with certainty since it's not official yet. I hope that there will be an announcement very soons.
But isn‘t kro.run more similar to helm instead of crossplane?
Kro helps us create CRDs and controllers that compose resources in kubernetes clusters. That is the same objective as the one crossplane compositions have. Crossplane also has other features like providers that we use to create kubernetes resources that manage resources somewhere else (e.g. AWS). In that video I am comparing kro only with Crossplane compositions and ignore the rest.
Helm, on the other hand, does not create CRDs and controllers. It is an engine that converts templates into yaml before applying them to the cluster. On way to look at it is to say that helm does "stuff" on the client-side before we get to kubernetes API while kro and crossplane extend the API and perform in-cluster operations.
@@DevOpsToolkit In my head I couldn't stop thinking about Helm and making library charts, but I didn't consider about the server vs client side work involved so makes sense as to why Helm wasn't mentioned in this video
Yeah. Otherwise I would have to open a completely different Pandora's box. I did not want to go through client vs server side processing, APIs, and other differences in that video.
On the slack channel we had the same discussion and the maintainers leaned more towards it being more along the lines of helm than crossplane - text below.
*Comparing it to Helm is fair - think of it as "helm as controller running inside your cluster".
True. All tools that compose resources (kubevela, crossplane compositions, kro, etc.) are like helm inside a cluster where values file is similar to CRDs and templates are similar to controllers (assuming that templating is dobe periodically so that there is some kind of drift detection and reconciliation).
This was very helpful. I agree. Patching not working is unacceptable and weird. Do they really test this by recreating all the time? Hope they fix it soon enough along with the metadata.ownerReferences.
Also why not use CEL in conditionals?
In general, I am okay using CEL as yaml values but not as keys. I suspect that kro will eventually have to do that to support conditional and loops.
@@DevOpsToolkit Yeah, same here. I did not like the way Azure Devops included loops into their pipelines neither. It really makes YAML more complex as it should be.
Crossplanes is complex!
you got me scared for a while... we invested a lot in crossplane so it could be easily upstaged by such a new project. I usually reason that mature projects dealt with so many issues that new ones have not even realized. I assume the major reason people drift to such new projects that reinvent the wheel is the complexity of the more mature ones. but complexity is unavoidable at times and unfortunately our industry is full of people losing their time and $ in dead ends that only are more simple in the short term :( .
No worries. Your investment is safe. kro is not a "real" competition.
there is also the platform engineering perspective of this complexity. platform engineering is complex, but using a platform should be simple ... that is the goal. frameworks for building platforms, like crossplane are very hard to design in a simple way especially if we want them to be flexible but they are to be configured by experts on the subject. if people dont understand this internal platform perspective, together with other adjacent topics like team topologies, they are bound to have bad ideas for new frameworks.
@@DevOpsToolkit not yet... if they fix some issues kro could be really useful
😲