The Canonical Distribution of Kubernetes: Development Summary #4

on 28 July 2017

This article is more than 6 years old.

This blog was originally posted by Tim Van Steenburgh

July 21st concluded our most recent development sprint on the Canonical Distribution of Kubernetes (CDK). Here’s a look at what we did.

Check out the full list on GitHub. Here are some notables:

Made load balancer port configurable
Changed default --service-cluster-ip-range to a /16 CIDR to allow more NodePort IP addresses
Fixed etcd snapshot action
Increased default worker node constraints to 4 cpu, 4GB RAM

Added a test to ensure dashboard is operational after deploy
Added a test for the built-in microbot example
Added a Jenkins job to test master charms with stable snaps. When this is green it means we can release whatever new fixes/features we have queued up in the charms, giving us the confidence to do more frequent releases.

Calico spike. We want to provide a CDK + Calico deployment option that works on any cloud, just like our CDK + Flannel option. We’ve decided to go with a Calico-on-Flannel (Canal) approach initially. Canal combines the network policy enforcement of Calico with the ease-of-deployment of Flannel. Work begins in the current sprint!
RBAC spike. We mapped out the work necessary for enabling RBAC via charm config. Work begins in the current sprint!
Updated the canonical-kubernetes-elastic bundle. This bundle has been added to our Jenkins build process and updated with the latest 1.7 charms.

If you’d like to follow along more closely with CDK development, you can do so in the following places:

Until next time!

Ubuntu offers all the training, software infrastructure, tools, services and support you need for your public and private clouds.