HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
kubernetes-sigs
kustomize
Go2018–2026
kubernetes-sigs / kustomize

kustomize

Customization of kubernetes YAML configurations

Command LineSystems & InfrastructureDevOps & Cloud
Explore on GitHubRead Hacker News discussions
12Distinct people
13Mentions
0Explicit recommenders
12.2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Customization of kubernetes YAML configurations

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year13 dated mentions

Observed mentions: 2018-08-10 13:39:14 UTC to 2026-10-17 23:34:16 UTC.

02462018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC312
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC606
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC101
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC202
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

13 sources
Benjamin_Dobell·Apr 20, 2019
There seems to be some confusion here, in no small part due to the title of this article. But... > kustomize lets you customize raw, template-free YAML files for multiple purposes, leaving the original YAML untouched and usable as is. That's the very first line of Kustomize's README[1]. Kustomize is not a templating DSL. The conversations here mocking templating DSLs are not relevant. The next sentence[1]: > kustomize targets kubernetes; it understands and can patch kubernetes style API objects. It's like make, in that what it does is declared in a file, and it's like sed, in that it emits editted text. Kustomize is a patching framework. It takes valid k8s resources, and allows you patch them, with partial k8s resources. The entire point of Kustomize to not invent something new. [1] https://github.com/kubernetes-sigs/kustomize
In Kustomize – Templating in Kubernetes
Benjamin_Dobell·Apr 20, 2019
I just did the big 1.x -> 2.x refactor myself, and whilst it's not exactly pretty you can still reuse patches to some degree. It's just that every patch that will be applied independently now needs to be part of its own "base". You can then pull in the "base" wherever you want the patch applied. It's far from ideal, so I do hope the process improves, but it does at least work EDIT: Although, after properly reading that linked issue, I see you mean applying the same patch to different resources. I interpreted "target" to mean build target (e.g. deployment/app), you can use the same patch across different deployments (apps) and overlays (environment). However, I see your use case is a bit different. > I wish it folowwed a similar pattern as `kubernetes` resources where each resource had an `apiVersion`, and the `kustomization` itself had an
Read the rest
`apiVersion`. As of 2.0, this is now the case[1]: > apiVersion: kustomize.config.k8s.io/v1beta1 > kind: Kustomization [1] https://github.com/kubernetes-sigs/kustomize/blob/a5bb5479fb...
In Kustomize – Templating in Kubernetes
mkobit·Apr 20, 2019
`kustomize` is an interesting and useful tool, and it is cool to see it available directly in `kubectl` in 1.14. A lower barrier to entry is nice to have for tools like this. It is useful on its own, but I'm also looking forward to additional features like being able to reuse a single patch on multiple targets (https://github.com/kubernetes-sigs/kustomize/issues/720). I'd also like to see a clear schema for what the YAML needs to look like and what the keys do. I wish it folowwed a similar pattern as `kubernetes` resources where each resource had an `apiVersion`, and the `kustomization` itself had an `apiVersion`. Some newer documentation can be found at https://kubectl.docs.kubernetes.io/ which is still a little bit barren, but I expect it to improve. Some of the older documentation can be found at https://github.com/kubernetes-sigs/kust
Read the rest
omize/tree/a5bb5479fb... (before the tool was integrated directly as a subcommand)
In Kustomize – Templating in Kubernetes
jrockway·Feb 8, 2019
I saw this title and immediately knew the article would be about Helm. I don't think anyone wants to use Helm. People use it for a set-and-forget thing that they don't care about (who cares that it's called impressive-leopard-kubernetes-dashboard, after all.) kustomize is much more sane for your own stuff: https://github.com/kubernetes-sigs/kustomize It is actually a little bit too magical for my taste, but I continue to use it because it hasn't done anything stupid. I have one file that maps logical names to images in a container repository. If I create a service called "foo" pointing to selector.app.label="foo" in the base, then in production it's called foo-prd and the label magically updates to foo-prd for the selector. It actually understands what it's generating, and while they might have taken it a little bit too far, it's far
Read the rest
better than just dumb text replacement.
In Why are we templating YAML?
einstand·Jan 30, 2019
For me -- as I am outsider -- it's hard to understand all the non-technical arguments and social dynamics. From technical point of view, I really like the composition-based/declarative approach of Kustomize. I am testing different type of bigdata clusters in k8s (Hadoop, Hdfs, Spark, HBase, Hive, Ozone, etc.). I need a method to easily create/install different type of clusters with a set of predefined components. Sometimes I need Spark, sometimes not. Sometimes I need HDFS HA sometimes not. With or without kerberos. With Helm chart it's almost impossible: all the charts would be full with different conditional branches and which hard to be maintained (and hard to handle dependencies: for example if both hdfs/yarn cluster would like to add something to the core-site.xml configuration). The composition based approach works better for my use
Read the rest
-case, but I found Kustomize very difficult to use. It has strict opinion/limitation how the thing should be defined/worked [1], which are very smart, but sometimes not for my use-case. Also it requires very verbose configuration. Finally I just created my tool which is more flexible (shameless plug, it's here: [2]) which can do anything with the help of composition and more easy to use. I respect the Kustomize developers and development and I am very happy that it exists. (And I know that it's way more mature/smart than my tiny tool) I am just not sure if it it's possible to cover all the use-cases (or majority of the use-cases) with one existing tool (neither with Helm nor with Kustomize). Therefore I would prefer to keep all these tools in separated repo. Personally I would prefer to have more similar tools with new ideas and prefer to have better and better (and more flexible) Kustomize. But this is just my personal preference. [1]: https://github.com/kubernetes-sigs/kustomize/blob/master/doc... [2]: http://github.com/elek/flekszible
In The Kubernetes Kustomize KEP Kerfuffle
ghayes·Aug 24, 2018
For me, Helm caused more problems than it solved. Pulling in packages always seems good, but as soon as you want customization, you're back to merging in the (relatively) straight-forward yaml files from the chart. Also, instead of Helm's templates (which get crazy complex and unintuitive), a simple tool like Kustomize[0] is very straight-forward and allows per-environment configuration. Finally, tiller pods do present (yet another) security risk for Kubernetes. [0] https://github.com/kubernetes-sigs/kustomize
In Edge Computing at Chick-fil-A

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.