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

11–20 of 62 posts

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

#11

Post by polyrand »

tdubey wrote: post #6
edwardmcfarlane wrote: post #4

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

The firm I work at developed an internal library (open source soon hopefully!) that does all our templating in Python, example: import os """ Imports redacted, but this imports our library """ NAME = "my_app" PORT = 5000 DEPLOY_ENV = os.environ["DEPLOY_ENV"] deploy_all( create_stateful_service( NAME, http_port=PORT, cpu=2000, memory=500 ), create_ingress( NAME, service_name=NAME, service_port=PORT, hostnames=["myapp.…

I was tinkering with a similar approach to this, using Python objects to generate the YAML. I'm not working in it right now, but I'd love to see other tools use this approach.

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

#12

Post by 0xbadcafebee »

edwardmcfarlane wrote: post #4

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

What do you use templating for that made you not want to use Helm? Granted it's buggy as hell, but the fact that it automates so much operational process makes it save way more time over templating, in my experience.

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

#14

Post by hosh »

- Actually getting CloudFoundery for K8S (korifi) production ready.

I think one of the big pitfalls teams using Kubernetes is the level of abstraction you are working with. With teams that have expertise, working with Kubernetes directly can work well … but if you are asking about developer experience, Kubernetes is the wrong level of abstraction. You really need an application platform built on top of Kubernetes — CloudFoundery is exactly that, but it has taken them a while to build something using native k8s resources.

Using native k8s resources is important. You can make an opinionated workflow, but if you know what you are doing, you can still take it apart and reconstruct it into something specific for the team that will be using it.

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

#15

Post by epilogue »

simiones wrote: post #5

One thing I just hit is that there doesn't seem to be any way to ask from a Pod to get a TLS certificate signed by the cluster itself (that would only be valid inside the cluster, of course) that is valid for the IP(s) and DNS names associated by Kubernetes itself with the pod (and to automatically rotate etc such certs). Since the infrastructure already knows (and controls) this information, it would be the ideal pl…

We’ve been using Linkerd as our service mesh which does this without really much effort at all required on our part. They bind the certs to the ServiceAccount identity of each pod, which is apparently more secure than doing it via IP.

https://linkerd.io/2.13/features/automatic-mtls/

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

#16

Post by hosh »

simiones wrote: post #5

One thing I just hit is that there doesn't seem to be any way to ask from a Pod to get a TLS certificate signed by the cluster itself (that would only be valid inside the cluster, of course) that is valid for the IP(s) and DNS names associated by Kubernetes itself with the pod (and to automatically rotate etc such certs). Since the infrastructure already knows (and controls) this information, it would be the ideal pl…

Couldn’t do this with cert-manager or maybe one of the service meshes?

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

#17

Post by hitpointdrew »

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 seems to break the GitOps paradigm. Multiple branches or repos means you now have helm templates all over the place and quickly you get drift. Having one branch and repo consolidates your templates, but now you need to either allow any dev to change any value for any environment, or you have to slowdown your devs and gatekeep the repo and only those who are allowed to make prod changes are responsible for merging in ALL changes to every environment.

Ultimately it seems like the best compromise is you end up with multiple deployments of Argo/Rancher (whatever CD tool you have), which monitor your helm charts pointing at least two separate repos, one that is for non-prod, and another that is prod.

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

#20

Post by kevin_nisbet »

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/

Post reply on HN