When developing against/for Kubernetes, there are two major technologies that you need to have setup:
I have what I believe to be a very, very simple local development setup using these two technologies that I want to share with you. That being said, let's get started.
Before we install the two tools below, we must first install corectl.app. To do this, visit the
releases page and download the latest .dmg. Double-click the downloaded .dmg and drag the
corectl.app application to /Applications using the provided shortcut. Once you've installed the corectl.app, run
the application (/Applications/corectl.app) and you should see a menu bar icon that looks like the CoreOS logo with
an X in the middle.
There are many ways to install and use Docker from an OS X box. My Docker setup requires using a standalone application that is controllable from the OS X menu bar. This project is called the CoreOS VM.
To install the CoreOS VM, visit the releases page and download the latest .dmg. Double-click
the .dmg and drag the CoreOS.app application to /Applications using the provided shortcut. Once you've installed
the CoreOS VM, run the application (/Applications/CoreOS.app) and you should see a menu bar icon that looks like the
CoreOS logo. Click the menu bar icon, select Run and follow the prompt. It's that simple.
Once the CoreOS VM is running, you have Docker running within the VM but you still need to update your CLI environment to be able to find the Docker executables and the Docker server. To do this, you will need to run the following, preferably by updating the appropriate shell startup script to do this for you:
- Add the
dockerexecutable (and others) toPATH:export PATH="~/coreos-osx/bin:$PATH" - Tell the
dockerexecutable where your Docker server is:export DOCKER_HOST=tcp://192.168.64.3:2375
At this point you should be able to run docker images and see something like this:
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
uifd/ui-for-docker latest 526a9ea81a62 9 weeks ago 7.391 MB
Using this Docker server is no different than any other Docker installation. It just works. But
there is one more useful thing that the CoreOS VM provides, it contains a Docker registry located at
http://192.168.64.1:5000. Why might you need this? Well Kubernetes has to download images from
somewhere and typically during development you will want to build/run/test things locally. Having a
local Docker repository allows you to build/tag/push/... to your local repository as part of your
development process without having to perform these operations against your live Docker repository.
The cool thing is that Kubernetes can just as easily use the Docker images in your local Docker
repository just as easily as it does images stored on DockerHub.
To give you an idea of how I use a local Docker repository for development, let me show you how I build/tag/push when developing the k8s-router. These are the steps I use:
- Build my image:
docker build -t k8s-router . - Tag my image:
docker tag -f k8s-router 192.168.64.1:5000/k8s-router - Push my image:
docker push 192.168.64.1:5000/k8s-router
Then in Kubernetes land, I use 192.168.64.1:5000/k8s-router as my image name and Kubernetes will pull
the image I just built from my local Docker registry as expected. I was able to do this without updating
the deployed images on DockerHub.
Now when you're done with development and you want to build your official images that will land in your Docker repository of choice, just use the same commands above but alter them for your production environment. Here is an example:
- Build my image:
docker build -t k8s-router . - Tag my image (version):
docker tag -f k8s-router thirtyx/k8s-router:1.0.2 - Tag my image (latest):
docker tag -f k8s-router thirtyx/k8s-router:latest - Push my image(s):
docker push thirtyx/k8s-router
The cool thing abou this is that you're building your development images using the same procedure that you will do for production but having a local Docker repository allows you to only push things to your official Docker repository when you're ready.
Just like with Docker, there are many ways to create a development cluster for Kubernetes. And just like with my Docker setup, I rely on a standalone application that is controllable from the OS X menu bar for Kubernetes. This project is called Kube-Solo and it's from the same person that brought you the CoreOS VM mentioned above.
Just like the CoreOS VM mentioned above, to install the CoreOS VM, visit the releases page and
download the latest .dmg. Double-click the .dmg and drag the Kube-Solo.app application to /Applications using
the provided shortcut. nce you've installed the Kube-Solo VM, run the application (/Applications/Kube-Solo.app) and
you should see a menu bar icon that looks like the Kubernetes logo. Click the menu bar icon, select Run and follow
the prompt. Again, super simple.
I'm sure you're seeing a consistent them here but just like the CoreOS VM mentioned above, at this point you have a VM running a Kubernetes cluster but you need to update your environment to use it. To do this, you will need to run the following, preferrably by updating the appropriate shell startup script to do this for you:
- Add the
kubectlexecutable (and others) toPATH:export PATH="~/kube-solo/bin:$PATH" - (Optional) Tell the
kubectlwrapper where to find your Kubernetes client configuration file (kubectlfrom Kube-Solo is a wrapper that defaults to another location otherwise):export KUBE_CONFIG=~/.kube/config(This can be useful when you already have akubectlconfig file, you want to use the same location thatkubectluses by default or you plan on using a singlekubectlconfig file for multiple clusters)
At this point you should be able to run kubectl get nodes and see something like this:
NAME STATUS AGE
192.168.64.2 Ready 1m
Using this Docker server is no different than any other Kubernetes installation. It just works.
Note: All of this was prior to minikube existing. I still haven't had the time to look into minikube but if it changes my development setup, I will let you know.