Skip to main content
  1. Blog
  2. Article

Matt Bruzek
on 23 July 2015

Deploy a Kubernetes development cluster with Juju!


Our team has been working to make Kubernetes easy to deploy in a public cloud. In March we created some Juju charms that have the ability to deploy specific releases of Kubernetes on a public cloud. In April we worked to get the charm and bundle code in the Kubernetes project itself. Making it even easier for people to deploy a cluster from the official Kubernetes repository.

We have reached another milestone in the Kubernetes story. We added the ability to deploy a Kubernetes cluster with binaries built from local source! This is important to software engineers because it gives them an easy way to stand up a cluster and see their changes right away.

Development setup

To use this new feature the local environment must be set up for development. Refer to the Development Guide for details on how to set up your environment for development in the Go programming language.

Deploy local binaries

We are calling this deploy from source option “local”. Here is how it works:

  • Clone the Kubernetes project from Github:
    git clone http://github.com/GoogleCloudPlatform/kubernetes.git
    cd kubernetes
  • Set the Kubernetes provider to “juju”:
    export KUBERNETES_PROVIDER=juju
  • Change/edit the source code, and when you are ready, run the kube-up.sh script to deploy a cluster with your locally built binaries:
    cluster/kube-up.sh

The kube-up.sh script will build the required binary files (using make all), copy the binary files to the charm directory and deploy a cluster to the public cloud you have configured with Juju, if you do not have a public cloud configured you will be presented with the opportunity to configure one.

The resulting cluster consists of one kubernetes-master, two kubernetes nodes on different hosts. The etcd and flannel parts are there so the containers on different hosts can communicate with each other.

To get access to the controller node use juju ssh kubernetes-master/0 or the minion nodes with juju ssh kubernetes/0 commands. You will find the kubectl is already installed on the controller node.

When you are done with the cluster running kube-down.sh will destroy the cluster as expected.

cluster/kube-down.sh

Why use Kubernetes with Juju?

Juju provides a way to model deployments in a cloud agnostic language. The same commands can deploy a cluster on the major public clouds Amazon, Google Compute Engine, any OpenStack cloud, Windows Azure and many others. You will need to put your cloud credentials into Juju but that only needs to be done one time. This allows you to deploy a cluster on AWS, juju switch gce and deploy the same cluster on the GCE public cloud using the same kube-up.sh command. Juju reduces the cost of experimentation on other clouds and lets you focus on the Kubernetes development.

Help us improve!

There is a small team working on the Kubernetes story @whitmo, @chuckbutler, and @mbruzek. We are always trying to improve and make something useful for the community. If you find a bug in the code create an issue and reference one or all of us in the issue and we will have a look. If you have any feedback or a use case that we can help with please let us know. You can reach us on IRC in #system-zoo on irc.freenode.net.

Related posts


Luci Stanescu
14 May 2026

Fragnesia Linux kernel local privilege escalation vulnerability mitigations

Ubuntu Article

A local privilege escalation (LPE) vulnerability affecting the Linux kernel has been publicly disclosed on May 13, 2026. The vulnerability does not have a CVE ID published, but is referred to as “Fragnesia.”  The vulnerability affects multiple Linux distributions, including all Ubuntu releases. The affected components are the Linux kernel ...


Bertrand Boisseau
13 May 2026

Rethinking BYOD security: protecting data without trusting devices

Ubuntu Article

BYOD (bring your own device) has always looked better on paper than it does in real life. The promise is clear: let people use the gadgets they already own. Less friction, lower costs, and more freedom. But when security and privacy are non-negotiable, the conversation around BYOD usually ends quickly. Not because BYOD is a ...


Luci Stanescu
8 May 2026

Dirty Frag Linux kernel local privilege escalation vulnerability mitigations

Ubuntu Article

Two local privilege escalation (LPE) vulnerabilities affecting the Linux kernel have been publicly disclosed on May 7, 2026. The vulnerabilities have been assigned the IDs CVE-2026-43284 and CVE-2026-43500 and are referred to as “Dirty Frag.” The affected components are Linux kernel modules. The first vulnerability impacts the modules tha ...