Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What tools would make your Kubernetes development experience better?

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 62 posts

Re: Ask HN: What tools would make your Kubernetes development experience better?

#41

Post by tecleandor »

hitpointdrew wrote: post #17

I have yet to find a good solution that accomplishes both these goals. 1. Have a central location for our helm charts so that we have one copy of our charts with separate values for our various environments. 2. Have tight controls around who is allowed push what where (allow devs to push to the dev environment, allow team leads push to QA, etc.) Separately each goal is easy to accomplish, but if you want both, it see…

To avoid drift, I would keep the charts in one repo, but separate the values files in different repos per environment.

IIRC, Argo CD now allows to get your values.yaml from a different repo than the one you're using for the chart. So you create a very restricted repo for the charts, and then one repo por every environment that only (or mostly) contains a values.yaml.

You deploy then X applications or application sets, all pointing to the same chart, but pulling the values from different repos.

Re: Ask HN: What tools would make your Kubernetes development experience better?

#42

Post by verdverm »

edwardmcfarlane wrote: post #4

Better templating, example https://github.com/emcfarlane/kubestar which uses starlark for kubernetes config.

We use CUE directly to generate yaml resources

Have our eyes on Timoni

https://github.com/stefanprodan/timoni

Re: Ask HN: What tools would make your Kubernetes development experience better?

#43

Post by coxley »

YAML hell.

It's very difficult to have standard, company (or org) wide "templates" for creating resources. And I don't mean literal templates.

In my ideal world, everything would be defined within Starlark. And we could build our own abstractions. Do we want every resource to be associated with a team or cost-center label? Cool - this is now a required argument for the make_service() function.

Even with Kustomize, there's a lot of context switching needed to understand fully what resources a simple service is comprised of. And depending on the team, you don't need to know all of them. But because they are files crafted by hand — or at best, initially generated by a common template and modified by hand later — it's extra stuff to pay attention to.

Re: Ask HN: What tools would make your Kubernetes development experience better?

#44

Post by hosh »

verdverm wrote: post #36
drones wrote: post #27

Earlier quoted context omitted.

Kubernetes that automatically toasts a bagel and makes a cup of tea during compilation. Sets slack status to away just before a coworker messages me. Swipes tinder matches based on biometric data on my behalf. Sky's the limit!

If kubernetes won't, there's always a CRD that will

That’s the thing. When I think if Kubernetes, I think of the whole ecosystem, and not just the bits released by the Cloud Native Foundation.

Re: Ask HN: What tools would make your Kubernetes development experience better?

#45

Post by redeux »

kevin_nisbet wrote: post #20
redeux wrote: post #3

I understand that this is contrary to your question, but I might suggest a different approach to your inquiry. Instead of asking people for their dev tool ideas, ask them what problems they have with Kubernetes that aren't yet solved well for them. With that information you can iterate on dev tool ideas that could potentially solve those problems. In my experience people understand their problems better than the pote…

This. A good reference on how to ask these types of product questions is the mom test by Rob Fitzpatrick. https://www.momtestbook.com/

Agreed! I highly recommend The Mom Test for anyone doing product work.

Re: Ask HN: What tools would make your Kubernetes development experience better?

#46

Post by edwardmcfarlane »

verdverm wrote: post #42
edwardmcfarlane wrote: post #4

Better templating, example https://github.com/emcfarlane/kubestar which uses starlark for kubernetes config.

We use CUE directly to generate yaml resources Have our eyes on Timoni https://github.com/stefanprodan/timoni

CUE is really interesting in comparison with protobuffers with CEL. Thanks for linking the project.

Re: Ask HN: What tools would make your Kubernetes development experience better?

#47

Post by jaguar75 »

Reitet00 wrote: post #38
potatocannon wrote: post #25

Earlier quoted context omitted.

tilt.dev

Looks okay but I was looking for something that wouldn't require learning yet another config language and would rather take k8s yamls that I already have (or require minimal modifications).

Check out https://www.signadot.com/. Full disclosure, I'm the founder, but it could help with what you’re looking for.

Re: Ask HN: What tools would make your Kubernetes development experience better?

#48

Post by omniglottal »

Reitet00 wrote: post #24

Having a tool that'd make it easy to run the app locally for development and at the same time have roughly the same files used in production. Docker compose got this mostly right, compare compose with the complexity of running locally service in micro Kubernetes cluster.

Minikube

Re: Ask HN: What tools would make your Kubernetes development experience better?

#49

Post by verdverm »

edwardmcfarlane wrote: post #46
verdverm wrote: post #42

Earlier quoted context omitted.

We use CUE directly to generate yaml resources Have our eyes on Timoni https://github.com/stefanprodan/timoni

CUE is really interesting in comparison with protobuffers with CEL. Thanks for linking the project.

you're welcome, I also maintain https://cuetorials.com

Re: Ask HN: What tools would make your Kubernetes development experience better?

#50

Post by KickW »

redeux wrote: post #3

I understand that this is contrary to your question, but I might suggest a different approach to your inquiry. Instead of asking people for their dev tool ideas, ask them what problems they have with Kubernetes that aren't yet solved well for them. With that information you can iterate on dev tool ideas that could potentially solve those problems. In my experience people understand their problems better than the pote…

That's a great point! I really appreciate it.
Post reply on HN