My focus for the last 18 months having been on deployment to Kubernetes, I was excited to hear the news back at DockerCon that Docker Inc were recognising the dominance of Kubernetes. This included adding support to Docker Enterprise Edition (alongside Swarm) and to Docker for Mac/Windows. The latter has now hit beta in the edge channel of Docker for Mac and the following are my first impressions.
Having not had any particular need for the latest and greatest Docker for some time, my first step was to switch from the stable channel back to edge. That’s a pretty painless process. You do lose any of your current containers/images but you’ve got the ones you care about stored away in a registry somewhere haven’t you?! Then open up the preferences, switch to the shiny new Kubernetes tab, check the box to Enable Kubernetes and hit Apply followed by Install. As promised, it took a couple of minutes for the cluster to be created.
The UI leaves you a bit in the dark at this point but thankfully the email that arrived touting the new capability gave you a pointer as to where to go next: the install creates a kubectl context called docker-for-desktop. With this information I could access my new cluster from the command line:
|
1 2 3 4 5 |
$ kubectl config use-context docker-for-desktop Switched to context "docker-for-desktop". $ kubectl get nodes NAME STATUS ROLES AGE VERSION docker-for-desktop Ready master 16m v1.8.2 |
Now to take the cluster for a quick spin. Let’s deploy Open Liberty via the Helm chart:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
$ helm init Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster. Happy Helming! $ helm repo add ibm-charts https://raw.githubusercontent.com/IBM/charts/master/repo/stable/ "ibm-charts" has been added to your repositories $ helm install ibm-charts/ibm-open-liberty NAME: jaunty-aardvark LAST DEPLOYED: Mon Jan 8 22:39:00 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE jaunty-aardvark-ibm-open NodePort 10.110.64.99 <none> 9080:31978/TCP 0s ==> v1beta1/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE jaunty-aardvark-ibm-open 1 1 1 0 0s ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE jaunty-aardvark-ibm-open-859d86f87d-jl7dn 0/1 ContainerCreating 0 0s NOTES: 1. Get the application URL by running these commands: export NODE_PORT=$(kubectl get --namespace default -o jsonpath="{.spec.ports[0].nodePort}" services jaunty-aardvark-ibm-open) export NODE_IP=$(kubectl get nodes --namespace default -o jsonpath="{.items[0].status.addresses[0].address}") echo http://$NODE_IP:$NODE_PORT |
And, due to the magic of Docker for Mac networking, after a short wait we are treated to the exposed NodePort running on localhost:
Undoubtedly there will be issues but, at least at first glance, this support would seem to go a long way to answering those who see minikube as an inhibitor to making Kubernetes a part of the developer’s workflow.