Skip to main content
  1. Blog
  2. Article

Canonical
on 10 August 2017

Canonical Distribution of Kubernetes: Dev Summary 2017 (Week 32)


August 4th concluded our most recent development sprint on the Canonical Distribution of Kubernetes (CDK). Here are some highlights:

Testing & Planning

  • CDK offline testing plan. We wrote up a plan for testing CDK in an environment where there is no (or severely limited) egress internet access. The end goal is to ensure that CDK can be deployed in this scenario, and create docs describing how to do it. Initial testing begins in the current sprint.
  • etcd2-to-etcd3 migration plan. We wrote up a plan for upgrading existing CDK clusters from etcd2 to etcd3 if desired, and making etcd3 the new default. While the plan is in place, we don’t have any implementation work planned in the current sprint.
  • Canal. We wrote up a design doc for implementing Canal (Calico-on-Flannel) for CDK. Implementation of the Canal charm was scheduled for the current sprint and is currently in code review.
  • We added a Jenkins job to test our stable charms against the latest upstream patch release. A passing build here tells us that we can release the latest binaries for CDK without breaking currently-deployed clusters.

Features

  • Completed RBAC proof-of-concept work. At this point we know how to turn RBAC on/off via charm config, and what changes are needed in CDK to make this work. In the coming weeks we’ll be working on moving from proof-of-concept to production-ready.
  • s390x support. We started by snapping the major cluster components. There are some docker images that don’t have s390x builds, namely nginx-ingress-controller, heapster-grafana, and addon-resizer. We’ll be following up on these in the current sprint.
  • Calico. We updated the Calico CNI charm to use the latest Calico binaries, and added the Calico charm and bundles to CI.

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

Until next time!

This was originally featured on Tim Van Steenburgh’s blog

Related posts


Pedro Lazzarotto
11 June 2026

AI at the edge: simplifying infrastructure with Cisco and Canonical

AI Article

Legacy infrastructure was not designed for the requirements of the AI era. While large-scale model training remains centralized in data centers, test-time inference is rapidly shifting to the edge to reduce latency and bandwidth consumption. This shift creates a new frontier for enterprise AI, but deploying at the edge introduces signific ...


estelacarmona
11 June 2026

The next era of telco clouds: get open infrastructure choice with Sylva and Canonical Kubernetes

5G Article

Achieving vendor neutrality in telco clouds requires an infrastructure layer that respects open standards, without wrapping them in rigid platform layers. By combining upstream alignment with up to 15 years of support longevity, Canonical’s approach to Sylva is built around a requirement that matters deeply to telcos: follow upstream clou ...


Benjamin Ryzman
9 June 2026

What is RDMA over Converged Ethernet (RoCE)?

AI Networking

Previous articles walked through RDMA (Remote Direct Memory Access) as a programming model and InfiniBand as the fabric that was built around it. Both led to the same conclusion, even if it was never stated outright: moving data, not compute, becomes the bottleneck once systems scale. So what happens when you want RDMA, but you’re ...