Non-rhetorical question: Why would I use this instead of the many other approaches to running Kubernetes? Looking through the linked pages gave me no clue what the advantage is. I love Ubuntu, I've been a heavy Ubuntu user (on servers, laptops, etc.) for over 13 years, and I have a 25-node Kubernetes cluster running as part of https://cloud.sagemath.com. The kubernetes nodes all run Debian images, since that's what actually worked by default on GCE (with Kubernetes 1.3) when I setup the cluster. Soon I'll be making a new Kubernetes 1.5.x based cluster, and expanding how it's used.
Anyway, I feel like the documentation I was easily able to find about CDK misses the "comparison to the competition". I will maybe consider CDK as one option, instead of just using the install scripts that come with the Kubernetes source distribution.
First off, sage math looks awesome \m/. This is a great question, I'll be making sure we update our docs and pages to highlight these differences, here's a few that might be helpful for you:
From an installation standpoint you get the same Kubernetes /everywhere/. You can run this on all the public clouds, e.g. AWS, GCE, Azure, Rackspace, etc., and on private infrastructure like OpenStack, VMWare, and bare metal. And any Ubuntu machine, like a laptop, single server, etc.
CDK as a whole is really just applying operational knowledge around Kubernetes. We are not adding any additional bits to k8s, we distribute the same binaries as upstream. If you stop using our tools, you can still manage the cluster as if you'd stood it up by hand. Since we're distilling operations, and not just installation, we cover the entire breadth of lifecycle tasks. Come 1.5.3, 1.6.0 (+ etcd3), and beyond we work to make sure tasks like upgrades work reliably and consistently.
We also present a consistent interface to common maintenance tasks, so that everyone using the solution uses the same primitives for maintenance. This helps eliminate the need to SSH and hunt around for these tasks. All the operational code we produce is open source, it lives in the upstream tree, and we love contributions!
Our roadmap for features is driven almost exclusively by our users, both community and commercial.
I could probably write pages, but I think those are probably the starting points for things we're doing as a distribution of Kubernetes. If you have any specific issues while running k8s, I'm happy to help answer how we handle those, if we do.
How is the dynamic adding / removing of nodes story? I am really waiting for something like kubeadm to become stable, and be able to just run "kubeadm join X.X.X.X --token XYZ" and be good!
It's super clean already with CDK. You just issue a single command from your laptop, something like: `juju add-unit k8s-node` or `juju add-unit -n 10 k8s-node`. This will provision a new machine wherever you're running Kubernetes (AWS/GCE/Azure/Rackspace/OpenStack/VMWare/Bare metal/locally), install kubelet, configure the SDN you've chosen, and have it available to schedule workloads.
As kubectl moves to ready status, we'll look to use it more under the covers to help conform to upstream's recommendations.
Looking to install on DreamCompute, which supports OpenStack APIs. I just installed it, but don't see an option to install it on OpenStack. Is deployment via the OpenStack API supported? The linked article does say "designed to be easily deployable to public clouds, on-premises (ie vsphere, openstack)"
Thanks! I got through all of those steps but then hit the same error as you. I think this could be the standard for deploying K8S on DreamCompute once it works!
Anyway, I feel like the documentation I was easily able to find about CDK misses the "comparison to the competition". I will maybe consider CDK as one option, instead of just using the install scripts that come with the Kubernetes source distribution.