Skip to main content

Your submission was sent successfully! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates from Canonical and upcoming events where you can meet our team.Close

Thank you for contacting us. A member of our team will be in touch shortly. Close

  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


Benjamin Ryzman
2 April 2025

The future of Kubernetes networking: Cilium and other CNIs with Canonical Kubernetes

Ubuntu Article

Choosing the right Container Network Interface (CNI) for Kubernetes is critical to achieving optimal performance, security, and scalability. With the launch of  Canonical Kubernetes LTS (long-term support) last month, Canonical decided to integrate Cilium as the default CNI in order to reflect our commitment to delivering a modern, securi ...


Michelle Anne Tabirao
2 April 2025

How does MongoDB work?

Data Platform Article

Explore what MongoDB is, how it functions, and how organizations utilize it for specific applications to achieve business benefits. ...


Rajan Patel
31 March 2025

Automated patching for the Linux kernel

Security Article

To start securely and efficiently, Linux systems follow a carefully orchestrated sequence of steps to initialize firmware and manage services. Applying security patches to the software responsible for some of these early steps of Linux startup often requires a full system reboot. Frequent reboots driven by unplanned critical patching is d ...