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.
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!
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.
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).
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
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
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.
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.
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.
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.
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.
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.
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!
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.
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? 🤓
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.
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).
