Carvel ytt Instead Of Helm? A Better Way To Manage Kubernetes Resources?
ฝัง
- เผยแพร่เมื่อ 10 ก.ค. 2024
- VMWare Carvel ytt is yet another attempt to replace Kubernetes Helm. Is it any good?
#carvel #ytt #kubernetes
Consider joining the channel: / devopstoolkit
▬▬▬▬▬▬ 🔗 Additional Info 🔗 ▬▬▬▬▬▬
➡ Gist with the commands: gist.github.com/d56800b720e4d...
🔗 Carvel ytt: carvel.dev/ytt
🎬 Kustomize - How to Simplify Kubernetes Configuration Management: • Kustomize - How to Sim...
🎬 Helm vs Kustomize - The Fight Between Templating and Patching in Kubernetes: • Helm vs Kustomize - Th...
🎬 Helm And Kustomize Replacement? Jsonnet With Grafana Tanka: • Helm And Kustomize Rep...
🎬 Should We Replace Docker Desktop With Rancher Desktop?: • Should We Replace Dock...
▬▬▬▬▬▬ 💰 Sponsoships 💰 ▬▬▬▬▬▬
If you are interested in sponsoring this channel, please use calendly.com/vfarcic/meet to book a timeslot that suits you, and we'll go over the details. Or feel free to contact me over Twitter or LinkedIn (see below).
▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬
➡ Twitter: / vfarcic
➡ LinkedIn: / viktorfarcic
▬▬▬▬▬▬ 🚀 Courses, books, and podcasts 🚀 ▬▬▬▬▬▬
📚 Books and courses: www.devopstoolkitseries.com
🎤 Podcast: www.devopsparadox.com/
💬 Live streams: / devopsparadox
▬▬▬▬▬▬ ⏱ Timecodes ⏱ ▬▬▬▬▬▬
00:00 Introduction To ytt
02:30 Using Carvel ytt
15:49 Carvel ytt Pros And Cons - วิทยาศาสตร์และเทคโนโลยี
What do you think of Carvel ytt? Better than Helm or yet another failed attempt to replace it?
Ive been a fan of ytt and the other tools in that package for a couple of years now. I much prefer using them to Helm, even tough Helm's UX is better now, its still not good.
Helm + schema.json at the moment covers what I need. The main problem I see with this new tool is you have to change everything you have implemented, and that's usually a lot of work. And probably other tools, like argoCD or Flux are not prepared for that. So, from my point of view I would continue with the Helm standard because it generates less problem with other tools and standard deployment ways.
Another failed attempt
I'd rather like to see something built on top of Helm that makes it more user-friendly. Sort of like a helm compiler/transpiler, which takes simplified YAML and outputs Helm charts/values so Helm can use them. Not sure if I'm the only one with this one, but as a developer, I think this would be the best solution. Simply because Helm is pretty much standard these days, or at least the most widely spread option out there currently. No idea how that compiler/transpiler would look like, though, as I'm not too fond of the Kubernetes internals, but in my Kubernetes-infant-vision it makes sense what I said. Would love to hear Kubernetes experts' opinions on this.
Edit: On second thought, that thing would probably end up being a compiler of a compiler of a compiler at some point, depending on the future of Kubernetes in general. Let's just hope that's not gonna be the case :D
I think ytt offers an alternative to Kustomize which often used to post-process helm templates. You can't really replace helm with it especially if you need to do a helm install, but that's a bigger scope than just the go template vs. ytt template. Carvel as a whole might be able to replace helm, gradually... A set of little tools to solve pieces of the puzzle. I'd recommend looking at imgpkg & kbld before Kapp.
I would love more talk about the difference between client-side and server-side complexity. Carvel ytt and CRD's seem to be playing a different game. Having a mental framework for how to recognize client-side tools and when to use them, and vice versa for server-side tools, would be useful for architecture tool selection.
I'll add that topic to my TODO list for one of the upcoming videos. A hint while waiting... The main difference is in the API. That opens new doors that were closed with client-side.
There is an argocd plugin for ytt put together by a former carvel maintainer which allows the integration of the 2 but indeed there is not huge support from other tooling yet. With carvel now applying to be a cncf project hopefully we will see more integrations coming!
Getting into CNCF should give it a boost. That's great news.
Right now we have a helm chart-of-charts that you can deploy locally (pulling stuff from the open internet) or in our private environment and we use ytt to change the dependent charts and images to point to the private registries. I would love to simplify this or move the complexity elsewhere but I haven't found a good way of doing it.
I can feel your list of cons regarding ytt! We had in my company similar discussions and I didn’t want to use ytt as I have literally no other connection to the vmware/tanzu eco-system!
I think that's the most important next step for ytt or Carvel in general. It needs to disassociate itself from Tanzu. That does not mean that it shouldn't be included in Tanzu but that it should become clearer that it's a separate project (or a group of projects) that is not tied or coupled with Tanzu. Otherwise, the adoption is going to keep being low, and that can damage not only the project itself but even Tanzu as a whole (for having some obscure components).
I love YTT and the carvel tools in general. I hope you will do a video on kapp controller, which can bring helm and ytt and other things together into a server side approach which gives us flexibility and support for third party apps while still gaining the benefits of ytt.
Kapp is already on my todo list :)
Kapp or kapp controller?
@@vrabbi both :)
Awesome! I love them both and this week will have a huge UX improvement release for kapp controller packaging APIs via the kctrl CLI tool
Not a big fan of the syntax. At that point, if I have more complex needs, I would rather just use jsonnet
YTT also has overlaying which wasnt shown here in the video but is a huge capability and can actually be used as a a helm post renderer tool to add custom logic to third party charts
I kept that one for the next video that combines ytt with crossplane :)
@@DevOpsToolkit uuuuh what a tease you are. Combining ytt with crossplane. Sounds super interesting.
Bear in mind that it will be published on the Upbound channel. I'm avoiding crossplane on my personal channel (this one) so that I do not get labeled as biased
Looking at this, it seems that we're getting closer to something like the pulumi kubernets template engine. Perhaps creating something like Jinja but designed to work with Helm dependencies and CRDs is the answer. Just a library that you can use in different languages focussed on creating kubernetes yamls. In that case, we are using Helm as a package manager for kubernetes instead of a templating engine.
Something like cdk8s?
That's actually a very good idea. The major issue with all the similar tools is that none can beat Helm charts in terms of support for third party apps. If someone would come up with a good replacement for helm templates while still being able to use third party charts, we would get a winner.
As a side note, I don't think that Jinja should be part of the solution. It is a free text templating solution while yaml is essentially a data language. It would make sense to treat it as data.
@@DevOpsToolkit That makes complete sense. I've been using helm and pulumi to create/template yamls for me. The issue I always run into is using Helm dependencies are essentially string like objects. As soon as you start changing/overriding some of the values in the values file, you lose the pros of using objects, since those charts you are dependant on are only pulled in runtime.
If we want to create k8s yamls in a proper language, we need to be able to download and manage dependencies so you can run static analysis, linting, etc based on those dependencies. Helm dependencies should, essentially, be treated as interfaces that you implement.
I don't see any major advantage in learning and switching over to ytt. For creating simple pods ytt could have some advantages. But when it comes to complex deployments and have to use features like `coalesce` helm is way mature than any other boilerplates. Thanks for finding and bringing interesting stuffs.
There's more to ytt than is exposed in this vid. As @devopstoolkit is referring to ( in other comments on this vic ) a later vid. will look into this. Think the capability to avoid storing Helm charts locally or in your own chart repo. when you need to customize whatever in x Helm chart because it doesn't support xyz. I've had to customize several Helm charts. E.g. to get Kubernetes services created for exposing a metrics endpoint for Prometheus to scrap. Just as an example. There's more.
Using ytt allows me to use the overlay function of ytt and thereby still be using the upstream helm chart and follow that charts release cycle. Good stuff!
You're right. There is much more to ytt than what I showed. I had to limit the scope to keep the duration reasonable. I might create another one though.
Love for helm
On the support con. For Helm, use the `--post-renderer` parameter and call ytt in there. That's a good start of using it together with Helm. And on the cmdline sent it to e.g. yq and you can continue your YAML magic.
You're right. That is certainly an option, but not a "pretty" one. I heard of some incoming improvements that will make helm+ytt experience much better so I'm waiting for it to be released.
@@DevOpsToolkit is it the YAML ghost you don't like about the solution? I mean what is making it not that pretty?
Initially, there is a feeling that it's doing too much. However, the more I used it, the more it sticks with me. I would say I don't like it but rather that it makes sense only if what we do is complex and that it requires time to wrap ones head around it. It is likely going to become my tool of choice in the future, and only for specific use cases. Right now, I'm still weighting it against jsonnet but, as it stands now, it'll probably get on top.
YTT is a serious candidate for my DevOps pipelines to generate Override Values (i.e. inputs to Helm Install operations) across 50+ environments. Reason for this is: config changes needs to be propagated across the envs and if we make values yamls as templates (i.e. environment agnostic) it's dead easy to change the template and then render env-specific values yaml (then run _helm upgrade_). One point in ytt which makes me *very* upset is that you can't (easily) parametrise multi-line block config (this one starting from : | ). As far as I know the only way to work with this part is to use ytt libs generating a function for overlays. This is annoyingly overcomplicated. Other than that this is very powerful tool. Cheers!
Have you considered using ArgoCD applicationsets + generator for paramaters?
My initial reaction is that Helm should either replace their existing templating engine with ytt or at least add ytt as an alternate templating engine.
The post-renderer flag allows the templating engine to be changed
Never understood why go template got used instead of jinja2, which is actually a template language
Since Helm was written in Go, choosing Go templates is the default option (not necessarily the best).
Nevertheless, my complaint is that free-text templating is wrong when applied to data language (YAML). Using Jinja instead of Go templates would not be a significant improvement.
@@DevOpsToolkit at.least jinja2 is object based, where go template is string based. Whoever accepted nindent() has no children
Jinja2 is developed for Python. And as Helm is written in Go, so it uses Go templating. I would also prefer Jinja2 over Go templating, but what can we do, right? 🤓
Can you make a video on cilium , cni network driver alternative to aws vpc netowrk dirver
I recently tried it and it was great
Cilium was just released: th-cam.com/video/sfhRFtYbuyo/w-d-xo.html
Is it possible to use helm and create one ingress object for multiple service deployment with one chart with multiple values.yaml ?
Normally, you have one ingress controller and as many ingress resources for each service you want to expose. Is that what you're trying to do or... ?
@@DevOpsToolkit I have one aws alb ingress controller on eks and I want one ingress resource for multiple services.
It is possible when using yaml and kubectl cli to deploy ingress object but if you are using one helm chart with multiple service yaml in it then you will get issue like release name is already there kind of error because helm adds annotations like managed by and release name.
What would be the reason for having one ingress resource for multiple services? If you have many, there is still one controller and one ELB (not using ALB but I guess it's the same).
Is that a problem given that resource names are still chosen by you, even though they might be prefixed by chart name, they are still unique.
it would be nice if ytt could just manipulate helm charts directly instead of their output
You can use ytt overlays to modify helm charts.
@@DevOpsToolkit yeah but then I can't use helm for deployment anymore and ytt can't handle go template syntax inside yaml files
That's true. If you are using helm to deploy and not only to define manifests, you need to stick with helm exclusively.
@@DevOpsToolkit I have seen that carvel has an (experimental) terraform provider so I think I will try the post-processing route anyways.
@@zoop2174 You might also want to explore GitOps and ditch deployments with `helm` directly or similar actions.
Too many boilerplate for me
Don't you think that Helm results in more boilerplate and repetition inherited from Kubernetes itself?
Oh my god! This is even worse than Tanka! 😜 Advise for everyone looking for a tool to deploy Kubernetes resources: use Helm and you will stay sane! 😎