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 our team. We will be in touch shortly.Close

  1. Blog
  2. Article

Charles Butler
on 30 July 2015

Juju & Kubernetes: The power of components

While dogfooding my own work, I decided it was time to upgrade my distributed docker services into the shiny Kubernetes charms now that 1.0 landed last week. I’ve been running my own “production” (I say in air quotes, because my 20 or so microservices aren’t mission critical – if my RSS reader tanks, life will go on!) services with some of the charm concepts I’ve posted about over the last 4 months.

Its time to really flex the Kubernetes work we’ve done and fire up the latest and greatest, and start to really feel the burn of a long-running kubernetes cluster, as upgrades happen and unforseen behaviors start to bubble up to the surface.


One of the things I knew right away, is that our provided charm bundle was overkill for what I wanted to do. I really only needed 2 nodes, and using colocation for the services – I could attain this really easily. We spent a fair amount of time deliberating about how to encapsulate the topology of a Kubernetes cluster, and what that would look like with the mix and match components one could reasonably deploy with.

Node 1

  • ETCD (running solo, I like to live dangerously)
  • Kubernetes-Master

Node 2

  • Docker
  • Kubernetes Node (the artist formerly known as a minion)

Did you know: The Kubernetes project retired the minion title from their nodes and have re-labeled them as just ‘node’?

Why this is super cool?

I’m excited to say that our attention to requirements has made this ecosystem super simple to decompose and re-assemble in a manner that fits your needs. I’m even considering contributing a single server bundle that will stuff all the component services on a single machine. This makes it even lower cost of entry to people looking to just kick the tires and get a feel for Kubernetes.

Right now our entire stack consumes bare minimum of 4 units.

  • 1x ETCD node
  • 2x Docker/Kubernetes Nodes
  • 1x Kubernetes-Master node

This distributed system is more along the lines of what I would recommend starting your staging system with, scaling ETCD to 3 nodes for quorem and HA/Failover and scaling your Kubernetes nodes as required. Leaving the Kubes-Master to only handle the API/Load of client interfacing, and ecosystem management.

I’m willing to eat this compute space on my node, as I have a rather small deployment topology, and Kubernetes is fairly intelligent with placement of services once a host starts to reach capacity.

What does this look like in bundle format?

Note, I’m using my personal branch for the Docker charm, as it has a UFS filesystem fix that resolves some disk space concerns that hasn’t quite landed in the Charm Store yet due to a rejected review. This will be updated to reflect the Store charm once that has landed.

series: trusty
    charm: "cs:~kubernetes/trusty/kubernetes-6"
      "gui-x": "1109"
      "gui-y": "122.20509601567676"
    charm: "cs:~kubernetes/trusty/kubernetes-master-6"
    num_units: 1
      "gui-x": "1442.49658203125"
      "gui-y": "355.5472438428252"
      - "0"
    charm: "cs:~lazypower/trusty/docker-15"
    num_units: 1
      "gui-x": "1459"
      "gui-y": "116.79493450190131"
      - "1"
    charm: "cs:trusty/etcd-0"
    num_units: 1
      "gui-x": "1111.94580078125"
      "gui-y": "506.0163547899872"
      - "0"
  - - "kubernetes-master:etcd"
    - "etcd:client"
  - - "kubernetes:etcd"
    - "etcd:client"
  - - "kubernetes:docker-host"
    - "docker:juju-info"
  - - "kubernetes-master:minions-api"
    - "kubernetes:api"
    series: trusty
    constraints: "arch=amd64 mem=1g"
    series: trusty
    constraints: "arch=amd64 cpu-cores=2 mem=2g"


Deploy Today

juju quickstart

Deploy Happy!

Related posts

Michael C. Jaeger
29 April 2024

Kubernetes backups just got easier with the CloudCasa charm from Catalogic

Charms Article

For a native integration for Canonical’s Kubernetes platform, Juju was the perfect fit, and the charm makes consuming CloudCasa seamless for users. ...

Hugo Huang
9 April 2024

Canonical Delivers Secure, Compliant Cloud Solutions for Google Distributed Cloud

Canonical announcements Article

Today, Canonical is thrilled to announce our expanded collaboration with Google Cloud to provide Ubuntu images for Google Distributed Cloud. This partnership empowers Google Distributed Cloud customers with security-focused Ubuntu images, ensuring they meet the most stringent compliance standards. Since 2021, Google Cloud, with its charac ...

Karen Horovitz
18 March 2024

Canonical accelerates AI Application Development with NVIDIA AI Enterprise

Kubernetes Article

Charmed Kubernetes support comes to NVIDIA AI Enterprise Canonical’s Charmed Kubernetes is now supported on NVIDIA AI Enterprise 5.0. Organisations using Kubernetes deployments on Ubuntu can look forward to a seamless licensing migration to the latest release of the NVIDIA AI Enterprise software platform providing developers the latest AI ...