Skip to content
Hallway
0:00 / 0:00

#kluctl#helm#kustomize

Hands-on Introduction to kluctl | Rawkode Live

Rawkode Academy

28K subscribers • 3 videos on Hallway

YouTube
  • Recommended by 2 people: 2 in engineering communities.
  • Presented by David Flanagan, founder of Rawkode Academy, and David Behrends, creator of Kluctl
  • Linked in the descriptionkluctl/kluctl
  • May be out of date. The tools, versions or practices it shows have likely moved on.

Intermediate. Assumes working knowledge.

1.4K views4 years ago2 recommendations

Cloud and DevOpsTools and practiceKubernetesDocker and containers

David Flanagan and David Behrends demonstrate Kluctl, a declarative Kubernetes deployment tool that unifies Helm and Kustomize.

Kluctl is the missing glue that puts together your (and any third-party) deployments into one large declarative Kubernetes deployment, while making it fully manageable (deploy, diff, prune, delete, ...) via one unified command line interface. Kluctl tries to be as flexible as possible, while remaining as simple as possible. It reuses established tools (e.g. Kustomize and Helm), making it possible to re-use a large set of available third-party deployments. Kluctl is centered around "targets", which can be a cluster or a specific environment (e.g. test, dev, prod, ...) on one or multiple clusters. Targets can be deployed, diffed, pruned, deleted, and so on. The idea is to have the same set of operations for every target, no matter how simple or complex the deployment and/or target is. - kluctl.io/ - github.com/kluctl/kluctl

Why it's here

2 people recommend this

What people say. Recommended by the tool's creator and community members as a comprehensive hands-on introduction to Kluctl.

u/matzeihnin r/kubernetes • Recommends

On “Need advice on techniques to configure kubernetes clusters with different application values”

…We use Cluster-API and control it via Kluctl as well. Versioning in a Git repository allows you to easily publish different versions to different clusters. It will solve your problems without having to write Helm charts yourself or going 100% all-in with GitOps. The maintainer has two videos that illustrate the full range of functionalities: link to this video [video…
2View on Reddit

u/codablockin r/kubernetes • Recommends

On “Kustomize: I must be doing it wrong”

Templating doesn’t have to be bad. Just don’t overuse it and use proper tooling. If you end up with a bash script that does some envsubst or sed then you actually got a poor man’s templating solution that can easily get worse then any real templating system. Please look into https://kluctl.io, it should nicely fit into what you ask for. Check this video for a fast introduction: link to this video Also check this demo project: https://github.com/codablock/podtato-head/tree/kluctl/delivery/kluctl, it’s currently the best demo project if you want to compare it to other solutions (it implements many delivery scenarios)
0View on Reddit

u/codablockin r/kubernetes • Mentions

On “Am I wrong for avoiding helm completely?”

What exactly is it that gives you bad feelings about Helm? What do you mean by "cheating"? Cheating sounds like you don't like that you don't have to solve things by yourself, that others have done it for you. But for some reason I believe you actually mean something else, but correct me if I'm wrong. Is it maybe more about "loosing control"? Not knowing what exactly is happening when installing charts? Or worse...not knowing what will happen if you upgrade a chart that was running perfectly fine so far? It's easier to understand the implications of a change if you are the sole author of the change, e.g. by working on plain yamls. If I'm right, maybe take a look at kluctl.io (I'm the main…
7View on Reddit

u/codablockin r/kubernetes • Mentions

On “advice on automation approach. moving from ansible & muti-VMs to kubernetes multi-tenant pods”

I just read through all the comments and the discussions about Helm vs Kustomize. I also read about your concerns in regard to templating. Let me first handle that part. I believe that many people got some scars from templating in the past because it was hard to figure out why something went wrong. IMHO the real reason here is bad tooling/debugging support which could be made better. A tool that leverages templating should be able to show you what real-life consequences your changes have, e.g. by allowing you to easily print out the rendered yamls or by allowing to perform dry-runs against the target environment. Also, templating can easily get overused and thus become unreadable/unmaintai…
2View on Reddit