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.
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.
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!
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.
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.
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. :)
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.
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.
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.
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.
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.
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.
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.
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`
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.
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
50 comments
[ 2.8 ms ] story [ 107 ms ] threadIt's the easiest way we've seen to set up a Kubernetes cluster and get started immediately.
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.
https://github.com/vyshane/docker-compose-kubernetes
Mind elaborating on what you mean?
[0] https://github.com/kubernetes/kubernetes/tree/master/cluster...
[1] https://coreos.com/kubernetes/docs/latest/kubernetes-on-vagr...
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.
It makes spread a really attractive way to start the Kubernetes journey.
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.
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!
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!
Mattermost, Postgres and Kubernetes set up in minutes. Great work.
"Every problem in computer science can be solved by adding one more layer of indirection — except for too many layers of indirection".
Additionally, kubernetes will soon be able to use both docker and rkt containers.
http://kubernetes.io/docs/getting-started-guides/rkt/
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