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

https://github.com/redspread/spread#localkube

by mfburnett • 10 years ago

173 48 10 years ago

mfburnett13• 10 years ago

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.

atemerev2• 10 years ago

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

andrewstuart22• 10 years ago

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.

soldveggie• 10 years ago

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

mfburnett13• 10 years ago

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!

mmgutz• 10 years ago

Another option is to use docker compose to start kubernetes

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

mfburnett13• 10 years ago

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.

TheDong• 10 years ago

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

Mind elaborating on what you mean?

sporkland• 10 years ago

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.

timemachine• 10 years ago

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

mfburnett13• 10 years ago

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

nickpsecurity3• 10 years ago

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.

mfburnett13• 10 years ago

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.

nickpsecurity3• 10 years ago

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. :)

markbnj3• 10 years ago

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.

mfburnett13• 10 years ago

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

markbnj3• 10 years ago

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.

p4lindromica• 10 years ago

kubernetes is that general use framework.

markbnj3• 10 years ago

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.

nzoschke5• 10 years ago

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.

mfburnett13• 10 years ago

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

tommoor• 10 years ago

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

mfburnett13• 10 years ago

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

nzoschke5• 10 years ago

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.

jupp0r2• 10 years ago

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

mfburnett13• 10 years ago

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.

jupp0r2• 10 years ago

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

zwischenzug• 10 years ago

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

mfburnett13• 10 years ago

Very cool - thanks for sharing!

nzoschke5• 10 years ago

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!

mfburnett13• 10 years ago

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!

nzoschke5• 10 years ago

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.

quadrature• 10 years ago

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

atemerev2• 10 years ago

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".

andrewstuart22• 10 years ago

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.

agelast2• 10 years ago

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

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

nzoschke5• 10 years ago

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

agelast2• 10 years ago

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

mgallowa• 10 years ago

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

mfburnett13• 10 years ago

Thanks! :)

nevalau• 10 years ago

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

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

Related Stories