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.

Considerations

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
services: 
  kubernetes: 
    charm: "cs:~kubernetes/trusty/kubernetes-6"
    annotations: 
      "gui-x": "1109"
      "gui-y": "122.20509601567676"
  "kubernetes-master": 
    charm: "cs:~kubernetes/trusty/kubernetes-master-6"
    num_units: 1
    annotations: 
      "gui-x": "1442.49658203125"
      "gui-y": "355.5472438428252"
    to: 
      - "0"
  docker: 
    charm: "cs:~lazypower/trusty/docker-15"
    num_units: 1
    annotations: 
      "gui-x": "1459"
      "gui-y": "116.79493450190131"
    to: 
      - "1"
  etcd: 
    charm: "cs:trusty/etcd-0"
    num_units: 1
    annotations: 
      "gui-x": "1111.94580078125"
      "gui-y": "506.0163547899872"
    to: 
      - "0"
relations: 
  - - "kubernetes-master:etcd"
    - "etcd:client"
  - - "kubernetes:etcd"
    - "etcd:client"
  - - "kubernetes:docker-host"
    - "docker:juju-info"
  - - "kubernetes-master:minions-api"
    - "kubernetes:api"
machines: 
  "0": 
    series: trusty
    constraints: "arch=amd64 mem=1g"
  "1": 
    series: trusty
    constraints: "arch=amd64 cpu-cores=2 mem=2g"

 

Deploy Today

juju quickstart https://gist.githubusercontent.com/chuckbutler/f9218cc74ef8cfa07205/raw/3dd5a12a7d17b7d9c1b07d6a3b5b2f868681bdf4/bundle.yaml

Deploy Happy!

Related posts


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


Marcin "Perk" Stożek
14 March 2024

How should a great K8s distro feel? Try the new Canonical Kubernetes, now in beta

Kubernetes Article

Try the new Canonical Kubernetes beta, our new distribution that combines ZeroOps for small clusters and intelligent automation for larger production environments that also want to benefit from the latest community innovations ...


mitabhattacharya
6 March 2024

Meet Canonical at KubeCon + CloudNativeCon

Kubernetes Article

Join Canonical, the publishers of Ubuntu, as we proudly return as a gold sponsor at KubeCon + CloudNativeCon EU 2024. Hosted by the Cloud Native Computing Foundation, the conference unites adopters and technologists from top open source and cloud-native communities. Mark your calendars for March 20-22, 2024, as we gather in Paris for this ...