
Letter to Santa Kube - kiyanwang
https://jpetazzo.github.io/2017/12/06/letter-to-santa-kube/
======
notamy
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!). Am I missing something here?

~~~
kevin_nisbet
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](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...](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/](https://gravitational.com/telekube/).
*Please be aware though that I'm affiliated with gravitational and work on
telekube

~~~
notamy
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.

~~~
yebyen
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.

------
scjody
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 at a bunch of them and they seem to
be either half-baked solutions that someone put up on GitHub, or tools that
introduce way more complexity than I need right now (like Helm).

~~~
linkmotif
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](https://github.com/technosophos/helm-template)

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

~~~
bogomipz
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?

~~~
linkmotif
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.

~~~
bogomipz
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?

~~~
ecnahc515
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.

~~~
linkmotif
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.

------
lobster_johnson
To tail logs, you can use my tool, ktail:
[https://github.com/atombender/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

------
idiocratic
Regarding logs, I found this quite useful:
[https://github.com/johanhaleby/kubetail](https://github.com/johanhaleby/kubetail)

------
linkmotif
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?

~~~
bglusman
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](https://github.com/stellaservice/kubert)

