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

21–30 of 30 posts

Re: Letter to Santa Kube

#21

Post by notamy »

nameless912 wrote: post #8
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!…

Check out Kubeadm. It's by far the best way to do k8s on Bare metal right now in terms of ease of use. If you want something highly customizable, check out kubespray, which is basically a big fat ansible playbook which will deployment k8s almost anywhere.

> Check out Kubeadm. It's by far the best way to do k8s on Bare metal right now in terms of ease of use.

I tried kubeadm a little while back, and the farthest I could get was just setting up the container network. The fact that it's still marked as alpha/beta in a lot of features[1] isn't reassuring.

I will check out kubespray though; thanks for the recommendation!

[1] https://kubernetes.io/docs/setup/independent/create-cluster-...

Re: Letter to Santa Kube

#22

Post by notamy »

kevin_nisbet wrote: post #12
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 commerci…

I use minikube locally for developing on, but so far I've not been able to get a production k8s cluster up. As I replied to the other poster, the last time I tried kubeadm, I was completely unable to get past setting up a cluster network, at best. This was some time ago, so I do want to spend time to try again soon, but so far my experience has been pretty negative.

telekube looks pretty interesting, but sadly I don't have the money for any commercial offerings; side-projects can be a pain like that.

Re: Letter to Santa Kube

#23

Post by ecnahc515 »

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?

Similar. The reason they say "package manager" rather than "configuration management" for your manifests is because it's actually much more about packaging than it is config management.

The chart packaging format and template language don't allow you to easily encapsulate or abstract away your dependent charts, it's really just a simple package which you can use as-is, but not really possible "tweak" or "extend" charts without forking them. Contrasted this to a CM system which typically make it possible to build new modules/cookbooks/recipes/whatever on top of others, with the possibility to hide away the details of the underlying module/recipe/etc.

It's really just tarballs with yaml templates and a way to specify values for the templates.

Re: Letter to Santa Kube

#24

Post by rzzzt »

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!…

CoreOS' Tectonic looks like a good candidate for bootstrapping a bare metal cluster: https://github.com/coreos/tectonic-installer

Re: Letter to Santa Kube

#25

Post by linkmotif »

ecnahc515 wrote: post #23
bogomipz wrote: post #16

Earlier quoted context omitted.

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?

Similar. The reason they say "package manager" rather than "configuration management" for your manifests is because it's actually much more about packaging than it is config management. The chart packaging format and template language don't allow you to easily encapsulate or abstract away your dependent charts, it's really just a simple package which you can use as-is, but not really possible "tweak" or "extend" char…

I have yet to appreciate with the whole tarball/package thing.

My application is 5-6 deployments, a 3 statefulset and a cron job. I have it all in one chart that I keep unpackaged on in a directory. The workflow is (i) update the templates/values, (ii) ensure necessary containers live on GCR, `helm upgrade` my application. And that's it.

I've yet to find a need for breaking this single chart into multiple charts with dependencies. Maybe once it gets much, much bigger? I also don't like the idea of pulling in third party charts as dependencies, even if they're public from github. This last point is probably irrational and me-specific, but something about it is less appealing than just copy/pasting the manifests I want into my project. So much more direct.

Re: Letter to Santa Kube

#26

Post by bogomipz »

ecnahc515 wrote: post #23
bogomipz wrote: post #16

Earlier quoted context omitted.

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?

Similar. The reason they say "package manager" rather than "configuration management" for your manifests is because it's actually much more about packaging than it is config management. The chart packaging format and template language don't allow you to easily encapsulate or abstract away your dependent charts, it's really just a simple package which you can use as-is, but not really possible "tweak" or "extend" char…

Thanks, this really helps to intuit the project's documentation for me. Cheers.

Re: Letter to Santa Kube

#27

Post by lobster_johnson »

To tail logs, you can use my tool, ktail: https://github.com/atombender/ktail

It's designed to be user friendly. For example, you can type "ktail foo", and it will match any pod containing the string "foo". (If you don't give it any filters, it will tail absolutely everything!)

Homebrew:

    brew tap atombender/ktail && \
    brew install atombender/ktail/ktail

Re: Letter to Santa Kube

#28

Post by lobster_johnson »

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…

You can use Helm with local files, instead of fiddling with the awkward "repository" concept:

  helm install .
We use this to wrap Helm with a nice deployment tool that does a lot more (e.g. automatically annotate our resources with git commit information).

Re: Letter to Santa Kube

#29

Post by yebyen »

notamy wrote: post #22
kevin_nisbet wrote: post #12

Earlier quoted context omitted.

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 commerci…

I use minikube locally for developing on, but so far I've not been able to get a production k8s cluster up. As I replied to the other poster, the last time I tried kubeadm, I was completely unable to get past setting up a cluster network, at best. This was some time ago, so I do want to spend time to try again soon, but so far my experience has been pretty negative. telekube looks pretty interesting, but sadly I don'…

I had some trouble setting up networking the first time, IMHO weave should be higher up in the suggested CNI plugins.

Since I started using weave-net, I have never had to think about it again. An example of one of those really great tools that just gets out of your way and does exactly what it's supposed to do.

My cluster is one node only but it was bootstrapped with kubeadm, and has served me well since 1.5.2. I've never heard of anyone having trouble with the Weave networking. I use my (production kube instance) as a Jenkins server with my own chart that is derived from the Jenkins helm chart, with kubernetes-plugin for slave scheduling.

Re: Letter to Santa Kube

#30

Post by scjody »

nameless912 wrote: post #9
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…

I just hacked together a solution using Jinja2. I literally throw template strings in whatever fields I need templated and render the whole thing to /tmp/ using a stupid simple python script. It's not pretty, and admittedly it's a little fragile and home spun, but it works.

I'll probably end up doing the same. For now we're just duplicating things in two places.
Post reply on HN