
Canonical Distribution of Kubernetes - loppers92
https://insights.ubuntu.com/2017/01/24/canonical-distribution-of-kubernetes-release-1-5-2/?utm_source=Facebook&utm_medium=Social&utm_campaign=CanonicalKubernetes
======
molecule
_> 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](https://www.merriam-
webster.com/dictionary/premise)

~~~
AlainRoy
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.

------
marcoceppi
Hey HN, PM for Canonical's Kubernetes (CDK) here. Feel free to ask questions!

~~~
williamstein
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](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.

~~~
marcoceppi
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.

------
arjie
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.

~~~
marcoceppi
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.

~~~
bonzini
> five business days of upstream

So you do not do any integration testing, or for that matter hardly any
testing at all?

~~~
andrewsomething
> we're able to constantly test master

You seemed to have missed this.

~~~
bonzini
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?

------
lima
How does this compare to OpenShift?

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/](https://www.openshift.org/)

~~~
marcoceppi
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.

~~~
lima
Thank you!

------
itomato
...now with (mandatory) Juju.

