Show HN: Localkube – zero to Kubernetes 1.2 in one command | Hacker News Reader

Show HN: Localkube – zero to Kubernetes 1.2 in one command

github.com

173 pointsmfburnett48 comments

I don't have a Google Container Engine account or kube cluster yet. So big props for making it easy to set one up locally.

Because of this I had to hunt for how to install kubectl. I found a snippet on one of Kelsey's guides

https://github.com/kelseyhightower/intro-to-kubernetes-works...

``` curl -O https://storage.googleapis.com/bin.kuar.io/darwin/kubectl chmod +x kubectl sudo cp kubectl /usr/local/bin/kubectl ```

It could be helpful to inline in the Localkube Readme.

I'm having some trouble with the example mattermost app, `spread build .` is stuck on "Waiting for load balancer deployment...".

I did a bit of debugging the docker logs / containers. One time it was stuck waiting for the database. The second time it got past that. The mattermost platform server is running on the container.

I'm looking at the `localkube` container logs for more hints. Even with this I can't believe I'm playing with and debugging with my first kube cluster in minutes.

Great tools!

Yes so the "Waiting for load balancer deployment..." is a confusing message leftover from its original use for a remote cluster - we're fixing it asap, but it actually has already worked. Go ahead and get your Docker daemon IP and then grab the NodePort with `$ kubectl describe services/mattermost-app` and put in the IP:NodePort into your browser to see the Mattermost instance running.

The easiest way to install kubectl is actually to install gcloud first (https://cloud.google.com/sdk/#Quick_Start) and then install kubectl with `$ gcloud components update kubectl`

Thanks for bringing this up!

That's the trick. I was expecting some sort of message to tell me where to find the service.

Mattermost, Postgres and Kubernetes set up in minutes. Great work.

Fixed this issue with the message showing "waiting for load balancer" - now it returns the NodePort!

Hey everyone, cofounder of Redspread (YC W16) here. We just shipped Localkube, local development with Kubernetes. You can set up a full configured Kubernetes 1.2 cluster on your local machine in one command with Spread, our command line tool. Localkube has everything you need for networking, and is a single executable, single container, and single process.

It's the easiest way we've seen to set up a Kubernetes cluster and get started immediately.

In 1.2 docs, isn't there a docker run command that deploys local Kubernetes cluster?

Yeah, there's a container. I've not had great luck with it, though -- every time I'd get a kernel panic after a few minutes.

What I'm doing now, and what I recommend to others, is just running the hack/local-up-cluster.sh script, which gets you a local kubernetes cluster in a single command. It's intended for local development and will build & run a cluster.

Furthermore, you can run hack/build-go.sh and get the kubectl binary in _output/local/... pretty easily. Just symlink (or copy) it into your path, and it becomes pretty easy to grab the latest tag or even just HEAD, which is what I tend to play with.

Another option is to use docker compose to start kubernetes

https://github.com/vyshane/docker-compose-kubernetes

Oh haven't seen this! Is it compatible with Kubernetes 1.2? Not a huge fan of scripting - we think it breaks the abstraction of a container.

> Not a huge fan of scripting - we think it breaks the abstraction of a container.

Mind elaborating on what you mean?

Speaking about scripting, look at the Vagrant cluster scripts. A lot of bash [0] (I like bash). But there have been so many issues. I've been using K8s for so long and I tried so long to help vagrant work, but it sucks. Anyways, went to use GCE and GKE instead and have never looked back since. Yes it does suck conceptually to rely on remote GCE for repo development but it is so seamless and I spend less time wrestling and waiting for booting clusters in VMs locally.

[0] https://github.com/kubernetes/kubernetes/tree/master/cluster...

I had good success with the CoreOS Kubernetes Vagrant boxes [1]. However, I switched once Kubernetes became usable via Docker because the latter gives me super fast setups and teardowns, allowing me to iterate quickly on infrastructure code.

[1] https://coreos.com/kubernetes/docs/latest/kubernetes-on-vagr...

Both my fork: https://github.com/huggsboson/docker-compose-kubernetes

And vyshane's rename of this for 1.2 are compatible: https://github.com/vyshane/kid

I'm gonna work with him to get us merged.

You should clarify how this is different from https://github.com/kubernetes/kubernetes/blob/master/hack/lo...

Thanks for sharing. Kube is a direction we want to go with our servers and this looks to reduce the barrier to entry.

Of course - glad you think so! That's exactly why we built it.

We have Docker. On top of it, we have docker-compose. On top of it, we have Kubernetes. On top of it, we have Spread. And it all goes on top of AWS or Google Cloud instances.

"Every problem in computer science can be solved by adding one more layer of indirection — except for too many layers of indirection".

Not sure what makes you think Kubernetes is on top of docker-compose. It's a fundamentally different model for deployment. Pods, scheduling, DNS vs. links, autoscaling, etc.

Additionally, kubernetes will soon be able to use both docker and rkt containers.

> Additionally, kubernetes will soon be able to use both docker and rkt containers

http://kubernetes.io/docs/getting-started-guides/rkt/

I understand the concern with too many layers but you have it wrong in this case.

The low level platform is Kubernetes. This is a managed service on Google Cloud, or you can run the open source project on other substrates.

What you are seeing here from Redspread is a super easy way to run kube locally.

Redspread represents a growing suite of tools to make managing stuff on Kubernetes easy anywhere.

The best analogy I've seen for the pattern is "porcelain" and "plumbing", which I learned from Git.

We certainly need pipes and valves everywhere. But we really want a toilet and sink, simple specialized interfaces to the holes in the ground.

Kube is low level plumbing for managing raw compute and network resources.

Kube itself has some higher level tools. But it's great that Redspread is making some too. There are plenty of unique use cases and workflows we all want

Nice idea to generalize this. At my last job we did a lot of this automation against k8s on GCP using make and bash scripts calling gcloud and kubectl. A general use framework for promoting docker images to k8s services could be quite cool.

Thanks! What else would you want to see in a general use framework?

Basically tooling that takes you from a collection of images and service/replication controller definitions to a running stack. The main questions we ended up trying to answer were things like: how many nodes in the cluster? What machine type? Which images need to be deployed and which tag of each image? Which k8s objects need to be created and what customization has to be done to them in the process? We ended up with a combination of make files and shell scripts that defined all these aspects of a specific running cluster, created the cluster, deployed the images, created the services, etc.

kubernetes is that general use framework.

Yeah in many respects it is a general use framework, but there are gaps. Build tooling and automation to deploy images and update service and replication controller definitions is an area k8s really doesn't cover. There are a lot of different ways to approach it, but I think some sort of "ansible for clusters" makes sense.

Is anyone here using Kubernetes in production ?, what does your usecase look like ?

Nice! I love how you are building the spread tools as smaller composable parts and focusing on really practical use cases for experimenting, developing and deploying.

It makes spread a really attractive way to start the Kubernetes journey.

Thank you! Yes, we're approaching it with a Unix philosophy :)

Mattermost seems to be a new Hello World of Docker examples. Just made yesterday an example how to deploy Mattermost to production with Kontena: https://github.com/kontena/examples/tree/master/mattermost

I wrote this a while back when trying to install Kubernetes when it was young: https://zwischenzugs.wordpress.com/2015/04/06/play-with-kube...

Very cool - thanks for sharing!

Nice work, Redspread team. Can't wait to play with your tools this summer (:

Thanks! :)

This is really awesome! One question: what's redspread's business model?

Hey, thank you! We're building out "git for deployment" - starting with a series of commands to make it easy to deploy to and develop with Kubernetes, and working our way to application versioning (capturing and versioning the expected state of an application before it's deployed by an orchestrator, like Kubernetes). Then, we'll make money on the "Github" - collaborative deployment tools built on top of our versioning workflow.

Thanks for the info. I can definitely see the need for something like this at my work. Hope it works out for you guys!

what did you have to do for local kubernetes before? if you didnt have any options before this is awesome.

Previous options were either figuring out how to set up hyperkube (which was kind of a pain) or monokube. Neither were set up for Kubernetes 1.2 or had good networking options!

This seems really similar to what Convox does for AWS, would I be right in saying that?

Love the Convox team! We're both trying to make deploying to our respective orchestrators (EC2 for Convox and Kubernetes for Redspread) easier.

Convox team member here. Big fan of the Redspread team too :)

As Mackenzie says, we do have very similar goals of making deployments easy. I think we're also seeing the problems in a very similar way.

Most devs and teams want to focus solely on writing, deploying and maintaining their business apps and services. There are a lot of technical details to sort out for any container orchestration system, so we're building great tools that make these low level challenges vanish.

Redspread wants to be the Kubernetes experts so you don't have to be. Same with Convox and AWS.

The bad thing about this project name is, if just glancing, it can be misread in a funny way. Like an automotive startup or more questionable establishment.

So backstory: first we went with "omnikube", but that name was already taken and caused some early and funny confusion (see our issue on local development). But monokube and hyperkube were already taken, so localkube was our compromise.

It's just something I consider ever since the Coq theorem prover. Gotta think of how they might perceive and spell it. Yours aint so bad. Just a smirk at worst. Wait, worst will be if a speaker misreads it on a slide deck. Memorable moment for audience. :)

As a non-native English speaker I don't understand what are you talking about. What's so questionable about the name?

You may be inclined to Google the string "define: cock"

Nice try but it's misleading results unless they click on Urban Dictionary result. Best to use it for this one. ;)

Well there is coq au vin already...

Reply on news.ycombinator.com