Canonical Distribution of Kubernetes(insights.ubuntu.com)
insights.ubuntu.com
Canonical Distribution of Kubernetes
https://insights.ubuntu.com/2017/01/24/canonical-distribution-of-kubernetes-release-1-5-2/?utm_source=Facebook&utm_medium=Social&utm_campaign=CanonicalKubernetes
21 comments
OpenShift is an interesting product, because it's not just Kubernetes, but a PAAS on top of Kubernetes packaged as a single solution. As a result you're not using k8s, but OpenShift / Origin. This has pros and cons which mainly boild down to simplicity vs lock in.
Honestly, I'd suggest you shop around, comparing CDK to OpenShift would be kind of like comparing virtual machines to a cloud provider. In that, virtual machines are implemented in a ton of ways, but cloud providers are a platform which abstracts that whole VM layer and provides a product on top of VMs.
Much in the same way we're packaging up and distributing that underlying engine. There's a lot of flexibility with that. You can use Kuberentes directly, you can leverage Helm which is what a lot of the community seems to be moving towards for package management on k8s, and then things like Deis and others implement that PAAS layer similar to OpenShift.
Why I'd recommend this method over OpenShift is the flexibility we afford you. For starters, things like Helm and Deis don't come as a part of CDK but will work out of the box on it. Since it's just delivering Kubernetes the platform. As such, if you try Deis and don't like it, you could try Kel or any other PAAS / tool built to work against vanilla Kubernetes. With OpenShift - you use it and that's the choice you're saddled with.
At the end of the day, take some time to try both. Deis is quite polished and would give you an idea of what to expect from other PAAS solutions. It's built on Helm which is part of Kubernetes so it's less deltas from what upstream is doing.
Honestly, I'd suggest you shop around, comparing CDK to OpenShift would be kind of like comparing virtual machines to a cloud provider. In that, virtual machines are implemented in a ton of ways, but cloud providers are a platform which abstracts that whole VM layer and provides a product on top of VMs.
Much in the same way we're packaging up and distributing that underlying engine. There's a lot of flexibility with that. You can use Kuberentes directly, you can leverage Helm which is what a lot of the community seems to be moving towards for package management on k8s, and then things like Deis and others implement that PAAS layer similar to OpenShift.
Why I'd recommend this method over OpenShift is the flexibility we afford you. For starters, things like Helm and Deis don't come as a part of CDK but will work out of the box on it. Since it's just delivering Kubernetes the platform. As such, if you try Deis and don't like it, you could try Kel or any other PAAS / tool built to work against vanilla Kubernetes. With OpenShift - you use it and that's the choice you're saddled with.
At the end of the day, take some time to try both. Deis is quite polished and would give you an idea of what to expect from other PAAS solutions. It's built on Helm which is part of Kubernetes so it's less deltas from what upstream is doing.
Thank you!
...now with (mandatory) Juju.
Hey HN, PM for Canonical's Kubernetes (CDK) here. Feel free to ask questions!
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.
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.
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.
https://kubernetes.io/docs/getting-started-guides/ubuntu/sca...
As kubectl moves to ready status, we'll look to use it more under the covers to help conform to upstream's recommendations.
https://kubernetes.io/docs/getting-started-guides/ubuntu/sca...
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)"
There's a bit of pre-setup. I'll make sure we have DreamCompute in the installer out of the box soon.
Here's what that setup looks like: https://asciinema.org/a/7ba3snjdkxybmgisbm8430c34
Here's what that setup looks like: https://asciinema.org/a/7ba3snjdkxybmgisbm8430c34
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!
I copied the discussion over to https://github.com/dreamhost/dreamcloud-docs/issues/67 I think the DreamCompute community could benefit from updates there
I copied the discussion over to https://github.com/dreamhost/dreamcloud-docs/issues/67 I think the DreamCompute community could benefit from updates there
How long do you expect CDK to lag behind upstream Kubernetes releases? So far it's been pretty tight, but I'm curious about what sort of expectation you have here.
We're still "beta" so we have been able to release within 10 after upstream.
With recent updates to our build/ci process, we're able to constantly test master. This means we can bless releases days after being cut. Expect GA for CDK around 1.6.0 release time, which we will be driving for release blessed within five business days of upstream.
With recent updates to our build/ci process, we're able to constantly test master. This means we can bless releases days after being cut. Expect GA for CDK around 1.6.0 release time, which we will be driving for release blessed within five business days of upstream.
> five business days of upstream
So you do not do any integration testing, or for that matter hardly any testing at all?
So you do not do any integration testing, or for that matter hardly any testing at all?
We don't begin integration testing at day 0 of release, we are constantly integration testing.
That said, five days is a goal of ours, not a hard deadline or SLA. An example of this was the 1.5.2. This came out 8 or 9 days after upstream because we had failing integration and e2e tests starting a few days before release and it took some time to hunt down, address, and make sure it was an issue with how we're deploying k8s and not k8s itself.
Hopefully that clarifies how we're able to to stride towards that goal. To be honest, testing like this is as much and art as it is a science and it's taken quite a while to get to where we are now (and admittedly, still a ways to go until we're satisfied).
Let me know if have any other questions!
That said, five days is a goal of ours, not a hard deadline or SLA. An example of this was the 1.5.2. This came out 8 or 9 days after upstream because we had failing integration and e2e tests starting a few days before release and it took some time to hunt down, address, and make sure it was an issue with how we're deploying k8s and not k8s itself.
Hopefully that clarifies how we're able to to stride towards that goal. To be honest, testing like this is as much and art as it is a science and it's taken quite a while to get to where we are now (and admittedly, still a ways to go until we're satisfied).
Let me know if have any other questions!
> we're able to constantly test master
You seemed to have missed this.
You seemed to have missed this.
It also said "With recent updates to our build/ci process" but there is more to testing than continuous integration, especially for something as complex as Kubernetes.
In particular, continuous integration can run regression tests but how many bugs will it find due to interactions between features?
In particular, continuous integration can run regression tests but how many bugs will it find due to interactions between features?
Right now we're about 3-5 days behind an upstream release, so right now we're at 1.5.2.
> This is a pure upstream distribution of Kubernetes, designed to be easily deployable to public clouds, on-premise (ie vsphere, openstack), bare metal, and developer laptops.
Since this is an official announcement and the author is here: the proper phrase is "on premises"-- 'premise' is a term of speech, 'premises' is a place.
https://www.merriam-webster.com/dictionary/premise
Since this is an official announcement and the author is here: the proper phrase is "on premises"-- 'premise' is a term of speech, 'premises' is a place.
https://www.merriam-webster.com/dictionary/premise
Language evolves, and this is a great example. From the Oxford English dictionary: (note the last sentence)
3.b. In pl. In extended use. A house or building together with its grounds, outhouses, etc., esp. a building or part of a building that houses a business. Now also occas. with sing. concord.
3.b. In pl. In extended use. A house or building together with its grounds, outhouses, etc., esp. a building or part of a building that houses a business. Now also occas. with sing. concord.
Currently evaluating it for a new setup and Red Hat did a great job at it. It's basically devops tooling on top of Kubernetes.
https://www.openshift.org/