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

Letter to Santa Kube

jpetazzo.github.io

Post reply on HN
Print view View original

11–20 of 30 posts

Re: Letter to Santa Kube

#11

Post by linkmotif »

scjody wrote: post #3

As a relatively new Kubernetes user, the big thing on my wishlist is templates (for example so I can share YAML between my production and staging environments). Unfortunately the k8s team have already said "no" to that, and point to a list of alternatives. But without a simple solution that lots of people use, it's hard to know which one to pick and it doesn't look like any are particularly good. I took a quick look…

Helm is a lot simpler than it looks, and it’s awesome.

I also had this exact perspective, not wanting to introduce more complexity and therefore held off on Helm for a long time. But then I got comfortable enough with Kubertnes and also my project got complex enough that I needed templating and then Helm was great to pick up.

I just use one chart that I wrote for my application and I don’t mess around with repositories. I render the chart locally with helm template[0] to build my containers on Google Cloud container builder[1]. Then I deploy with helm upgrade. It’s a great flow!

[0]https://github.com/technosophos/helm-template

[1]https://github.com/dminkovsky/kube-cloud-build

Re: Letter to Santa Kube

#12

Post by kevin_nisbet »

notamy wrote: post #7

Somewhat off-topic, but as someone interested in k8s, why is it seemingly such a pain to set up in non-"cloud" environments? I know that Rancher exists - and I'm waiting for 2.0 to drop before migrating to Rancher-managed k8s - but beyond that the whole "ecosystem" of k8s seems pretty unfriendly to get started in without using AWS/GCE/Azure/etc (to the point of not being able to set up a cluster on bare metal at all!…

Depending on what you're looking for, if it's just an environment to play around with, minikube is a good option: https://github.com/kubernetes/minikube

And as another poster stated, kubeadm is a good way to get started on a VM or local system by following this guide: https://kubernetes.io/docs/setup/independent/install-kubeadm...

And last, possibly not what you're looking for but worth mentioning, there are commercial options available such as gravitational telekube which includes among other features a way to consistently install kubernetes amongst different environments and providers https://gravitational.com/telekube/. *Please be aware though that I'm affiliated with gravitational and work on telekube

Re: Letter to Santa Kube

#13

Post by linkmotif »

donaldguy wrote: post #5
scjody wrote: post #3

As a relatively new Kubernetes user, the big thing on my wishlist is templates (for example so I can share YAML between my production and staging environments). Unfortunately the k8s team have already said "no" to that, and point to a list of alternatives. But without a simple solution that lots of people use, it's hard to know which one to pick and it doesn't look like any are particularly good. I took a quick look…

helm recently(ish) added a helm template command to do client side rendering of a chart So if you wanted to just create a folder with a Chart.yaml, and a templates/file.yml.tpl with some `{{.Values.foo}}` template strings It is sufficient to just run `helm template --set foo=bar | kubectl apply -f -` at that point. Idk if that is little enough complexity for you. Similarly I use https://github.com/gliderlabs/sigil a…

Same here, helm template is great. It’s nice to pipe output from helm template to https://github.com/dminkovsky/kube-cloud-build if you’re on GKE.

If you’re using helm, is your json interpolation for things that can’t be in values.yaml?

Re: Letter to Santa Kube

#14

Post by bogomipz »

linkmotif wrote: post #11
scjody wrote: post #3

As a relatively new Kubernetes user, the big thing on my wishlist is templates (for example so I can share YAML between my production and staging environments). Unfortunately the k8s team have already said "no" to that, and point to a list of alternatives. But without a simple solution that lots of people use, it's hard to know which one to pick and it doesn't look like any are particularly good. I took a quick look…

Helm is a lot simpler than it looks, and it’s awesome. I also had this exact perspective, not wanting to introduce more complexity and therefore held off on Helm for a long time. But then I got comfortable enough with Kubertnes and also my project got complex enough that I needed templating and then Helm was great to pick up. I just use one chart that I wrote for my application and I don’t mess around with repositori…

I've really confused by Helm. From their github repo Helm bills itself as:

"The Kubernetes package manager."

Then it goes on to state:

"Helm is a tool for managing Kubernetes charts."

Then reading further I see:

"Charts are packages of pre-configured Kubernetes resources."

I find this extremely confusing. Also its my understanding that unit of deploy in K8 is a pod which is built on Docker containers. Isn't installing packages into running containers considered an anti-pattern?

Could someone give a better explanation of Helm/Charts and when someone might use it?

Re: Letter to Santa Kube

#15

Post by linkmotif »

bogomipz wrote: post #14
linkmotif wrote: post #11

Earlier quoted context omitted.

Helm is a lot simpler than it looks, and it’s awesome. I also had this exact perspective, not wanting to introduce more complexity and therefore held off on Helm for a long time. But then I got comfortable enough with Kubertnes and also my project got complex enough that I needed templating and then Helm was great to pick up. I just use one chart that I wrote for my application and I don’t mess around with repositori…

I've really confused by Helm. From their github repo Helm bills itself as: "The Kubernetes package manager." Then it goes on to state: "Helm is a tool for managing Kubernetes charts." Then reading further I see: "Charts are packages of pre-configured Kubernetes resources." I find this extremely confusing. Also its my understanding that unit of deploy in K8 is a pod which is built on Docker containers. Isn't installin…

Yeah it’s not the best docs. But the tool is great.

Helm just renders a bunch of templates of kubernetes manifests against a values file. It then takes the resulting manifests, compares them to what’s running on your cluster and makes sure nothing less or more is running. That’s it. What’s nice about it is that you can then change the manifest templates or values files, and when you install the updated result, you have a single concrete new state that your entire application is in. Which makes it easy to version your entire application, whether you changed just one env var in one manifest or made many changes thoughout.

There’s a package manager component but you can skip that completely and imo it’s just confusing that they lead front and center with that component.

The essential commands are helm ls and helm upgrade. And helm rollback is nice too.

Re: Letter to Santa Kube

#16

Post by bogomipz »

linkmotif wrote: post #15
bogomipz wrote: post #14

Earlier quoted context omitted.

I've really confused by Helm. From their github repo Helm bills itself as: "The Kubernetes package manager." Then it goes on to state: "Helm is a tool for managing Kubernetes charts." Then reading further I see: "Charts are packages of pre-configured Kubernetes resources." I find this extremely confusing. Also its my understanding that unit of deploy in K8 is a pod which is built on Docker containers. Isn't installin…

Yeah it’s not the best docs. But the tool is great. Helm just renders a bunch of templates of kubernetes manifests against a values file. It then takes the resulting manifests, compares them to what’s running on your cluster and makes sure nothing less or more is running. That’s it. What’s nice about it is that you can then change the manifest templates or values files, and when you install the updated result, you ha…

Thank you for this. This is helpful.

So its kind of like configuration management for your manifests then? Would that also be an accurate analogy?

Re: Letter to Santa Kube

#18

Post by bglusman »

linkmotif wrote: post #17

I've always assumed there must be some really solid reason you can't natively stream logs from multiple pods at the same time. Does anyone know what that is?

There isn't one, it's just not built in.

I added it as a feature to my package kubert[0] but that needs a little love/work I haven't had time or motivation to do recently, and there's upstream work in Kubeclient needed to make it work with GKE (when I started work was doing kube on AWS but since moved to GKE, and helm instead of ky for templating/deploy). But I really wish there was a fairly cnanonical tool a bit like this but working with helm and more or less adaptable or most kube deployments, maybe via a few adapters or something. If anyone knows of one, or wants to help to turn kubert into that, let me know.

[0] https://github.com/stellaservice/kubert

Re: Letter to Santa Kube

#19

Post by xur17 »

linkmotif wrote: post #11
scjody wrote: post #3

As a relatively new Kubernetes user, the big thing on my wishlist is templates (for example so I can share YAML between my production and staging environments). Unfortunately the k8s team have already said "no" to that, and point to a list of alternatives. But without a simple solution that lots of people use, it's hard to know which one to pick and it doesn't look like any are particularly good. I took a quick look…

Helm is a lot simpler than it looks, and it’s awesome. I also had this exact perspective, not wanting to introduce more complexity and therefore held off on Helm for a long time. But then I got comfortable enough with Kubertnes and also my project got complex enough that I needed templating and then Helm was great to pick up. I just use one chart that I wrote for my application and I don’t mess around with repositori…

I do something similar, but we only use helm to render the templates - we do not utilize any of its deployment processes. Instead we use gitlab to render and deploy a template as a normal k8s object.

Re: Letter to Santa Kube

#20

Post by linkmotif »

bogomipz wrote: post #16
linkmotif wrote: post #15

Earlier quoted context omitted.

Yeah it’s not the best docs. But the tool is great. Helm just renders a bunch of templates of kubernetes manifests against a values file. It then takes the resulting manifests, compares them to what’s running on your cluster and makes sure nothing less or more is running. That’s it. What’s nice about it is that you can then change the manifest templates or values files, and when you install the updated result, you ha…

Thank you for this. This is helpful. So its kind of like configuration management for your manifests then? Would that also be an accurate analogy?

Great to hear.

> So its kind of like configuration management for your manifests then?

Basically, yep.

Which is why, for example, it makes it easy to deploy staging environments. Instead of writing your manifests are the final finished product, you set up your manifests to be interpolatable templates. Then you can deploy your application one way to your production environment, but then staging another way (different env vars, different replicas, different anything, but still the same app).

The whole package management/sharing of charts thing falls out as a result of this, but I've yet to find this useful. I don't pay attention to my chart's version number (it's always 1.0), but instead aggregate all the tags for each image I need throughout my manifest templates in the values file. Then when I upgrade my helm release to deploy those latest tags, helm provides me with a monotonically increasing integer for the resultant release. I can always point to this integer and ask, "what manifests were running at this release?"

Post reply on HN