--- title: Kubernetes on Ubuntu VMs description: Recently /u/Elezium asked the following question on Reddit: Tools to deploy k8s on-premise on top of Ubuntu. This is a question that a lot of people have answered using a combination of MAAS/VMWare/OpenStack for on premise multi-node Kubernetes. If you’re looking for something with more than a two or three machines, those resources are bo […] url: https://canonical.com/blog/kubernetes-on-ubuntu-vms?format=md --- 1. [Blog](https://canonical.com/blog) 2. Article --- [Marco Ceppi](https://canonical.com/blog/author/marcoceppi "More about Marco Ceppi") on 6 October 2017 # Kubernetes on Ubuntu VMs Share on:* [Facebook](https://www.facebook.com/sharer/sharer.php?u=https://www.canonical.com/blog/kubernetes-on-ubuntu-vms "Share on Facebook") * [Twitter](https://twitter.com/share?text=Kubernetes%20on%20Ubuntu%20VMs&url=https://www.canonical.com/blog/kubernetes-on-ubuntu-vms&hashtags=ubuntu "Share on Twitter") * [LinkedIn](https://www.linkedin.com/shareArticle?mini=true&url=https://www.canonical.com/blog/kubernetes-on-ubuntu-vms&title=Kubernetes%20on%20Ubuntu%20VMs "Share on LinkedIn") --- --- ## Newsletter signup Get the latest Canonical news and updates in your inbox. Work email: \*I agree to receive information about Canonical's products and services. By submitting this form, I confirm that I have read and agree to [Canonical's Privacy Policy](https://canonical.com/legal/data-privacy). Sign up Recently [/u/Elezium](https://www.reddit.com/user/Elezium) asked the following question on Reddit: [Tools to deploy k8s on-premise on top of Ubuntu](https://www.reddit.com/r/kubernetes/comments/720yg7/tools_to_deploy_k8s_onpremise_on_top_of_ubuntu/). This is a question that a lot of people have answered using a combination of MAAS/VMWare/OpenStack for on premise multi-node Kubernetes. If you’re looking for something with more than a two or three machines, those resources are [bountiful](https://kubernetes.io/docs/getting-started-guides/ubuntu/). However, the question came to “How do I do Kubernetes on an existing Ubuntu VM”. This is different from LXD, which is typically a good solution — though without a bunch of networking modifications it won’t be reachable from outside that VM. So, how do you make a single — or even small handful — of VMs run Kubernetes in a production fashion? You could do it all by hand, but we’re well beyond the point where doing things from scratch in a non-repeatable fashion is reasonable, let alone desireable. First, get two VMs. This is probably the easiest thing, I’m going to use a simple VM running the latest [16.04 Ubuntu Server](https://www.ubuntu.com/download) — though you could use the Desktop or Cloud flavor of Ubuntu. I’ll also be doing these steps from a Mac terminal, but you could do this from an Ubuntu or Windows machine the steps are the same. Once you have two VMs running with at least 1 core and 1 GB RAM (ideally 2 core and 2 GB RAM each) you’ll need to make sure you have a few things set. First, make sure you can connect to the two VMs over SSH. This is important as the tools we’ll be using are for remote setups. From your host machine verify you can connect to the IP address of your VM. In my setup, this IP addresses are 172.16.94.129 and 172.16.94.130. Make sure you replace this with the address for your machine. ``` ssh ubuntu@172.16.94.129 ssh ubuntu@172.16.94.130 ``` If you created a different user, switch `ubuntu` with that username. You should get a successful connection and may be prompted for a password. Now that you have successfully connected, close this connection by typing `exit` this will return you to your host machine and we can continue! If you haven’t already, make sure you have conjure-up installed on your machine. In short, that’s either going to be `brew install conjure-up` or `snap install conjure-up` for MacOS and Linux respectively. To verify everything worked issue the following two commands: ``` conjure-up --version juju version ``` The output should be equal to or greater than 2.2 for both conjure-up and juju. Now we’re going to bootstrap Juju, creating a controller for which we can deploy software to. Normally, this is when you’d just run `conjure-up kubernetes` but since we’re working in such a unique case — deploying scale out software into a single machine — we’re going to do a lot of the steps conjure-up does, only manually. To do this, we need to know the IP address of the VM and the username for a sudo user on that machine. Again the user is typically `ubuntu` and the IP address is from earlier. ``` juju bootstrap manual/ubuntu@172.16.94.129 marcos-blog ``` You may get prompted several times for a password, which are all passwords for your VM user. Once the bootstrap is complete, issue a `juju status` to verify that you have an empty model. *This is an abbreviated instruction for manual bootstrapping, a lot more*[*details are available in the full Juju documentation*](https://jujucharms.com/docs/stable/clouds-manual)*.* Juju uses models like namespaces for deployment. If you notice when you issue a `juju status` the default model name is `default` and there are no machines, applications, or units deployed. However, there is *a* machine because we used it for bootstrapping. We are tip-toeing into dangerous territory as you shouldn’t use the controller (the machine we bootstrapped) to deploy software. However, that means we would need more VMs! If you can create more VMs, I’d suggest adding another machine to this deployment and avoid doing this switch to the controller. To do this, skip this step and continue below. If you only have/want two VMs, continue with this step. If you issue `juju models` you’ll notice there is a controller model in addition to the default model. If we switch to that model, `juju switch controller` and issue another `juju status` you’ll see that there are no applications, no units, but one machine — and it’s our VM from earlier! Now that we have a model with a machine we can get to work. What we’re going to do is manually place a few components, then let the process take care of the rest! We’ll need to add our other VMs. During this step you can add as many VMs as you’d like, the process is the same. In the following sections I’ll address how to scale out the components beyond this very small deployment. In order to do so, we’ll need to add the other machines so Juju knows where we want to put our components. To do this, run the following command for each additional machine we’ve not yet told Juju about: ``` juju add-machine ssh:@ ``` *As with before, replace*``*and*``*with the proper values from your setup.* Run `juju status` to verify you have all machines added and registered. Kubernetes is comprised of a handful of components: etcd, easyrsa, kubernetes-master, kubernetes-worker, and flannel. When you complete a deployment of Kubernetes using conjure-up these components are installed, configured, and connected for you. Conjure-up uses Juju as the driver for these instructions and we’re doing this “manual” deployment manually with the Juju pieces directly. First, we need to deploy EasyRSA and ETCD onto the machine. However, we don’t want to just smash them together, we’ll use LXD to separate and isolate these components. ``` juju deploy ~containers/easyrsa --to lxd:0 juju deploy ~containers/etcd --to 0 ``` Depending on your networking, this will take a few moments to create LXC machines and setup the software. Eventually you’ll end up with a state where etcd is blocked. You don’t need to wait for this to complete before issuing the following commands: ``` juju deploy ~containers/kubernetes-master --to 0 juju deploy ~containers/kubernetes-worker --to 1 ``` This will combine these two components on the single machine. We’re not going to use LXD for these components since it won’t be routable from outside the VM without messing with the network configuration. As such, we’re deploying `--to` machine 0, the components will be directly accessible through the VMs IP address. After a few moments, you’ll find something like the following in `juju status` As you can see, there’s still items executing. We could wait for these to complete, but if you’re as impatient as I am, then be thankful we live in an asynchronous world and press forward! The final step is to glue all these components together (and deploy the SDN). To do that, we’ll take the `kubernetes-core` bundle, which is a super light weight Kubernetes cluster, and deploy that now. It’ll skip over any component you’ve already deployed, add any components not yet deployed, and execute all the required relationships. ``` juju deploy kubernetes-core ``` The output for this is pretty verbose, and should look something like the following: This is to be expected. We see in several places Juju skips over components we’ve already deployed, adds things (flannel) that we’re missing, and finally adds all the relations for these components. This is how we resolve the etcd “blocked” message that it’s missing a certificate authority. You’ll notice that `etcd:certificates` is connected to `easyrsa:client` which will provider certs for etcd! Eventually, after running `juju status` for a few mins you should end up with the following. A completely deployed Kubernetes cluster. From this point forward, we’ll need to get the credentials for the cluster. This is done automatically for you with `conjure-up`. With this method you’ll just need to issue the following ``` juju scp kubernetes-master/0:config ~/.kube/config ``` If you already have a Kubernetes config file, choose another path, like `~/.kube/config.cdk` and make sure you use `export KUBECONFIG=$HOME/.kube/config.cdk` to use the new configuration file. For the final touch, I wanted to show how to scale this up. Ideally, you’d want to use a public cloud, private cloud (VMWare, OpenStack), or MAAS for bare metal. The manual provider is just that — very manual. That said, if you have more VMs you can add them and scale the applications to spread across them. I’m going to add another machine and use it for both etcd and kubernetes-worker. ``` juju add-machine ssh:ubuntu@172.16.94.131 juju add-unit -n2 etcd --to 1,2 juju add-unit etcd --to 2 ``` The result will be a three node etcd and two nodes for Kubernetes workloads. Again, `juju status` will show you the status of the cluster at anytime. Eventually everything will converge on `active` and `idle`. Once this is done you’ve scaled out the deployment. From here you can continue to add VMs, redeploy everything again, or actually start [using Kubernetes!](https://kubernetes.io/docs/tutorials/kubernetes-basics/deploy-intro/) #### Related posts --- [estelacarmona](https://canonical.com/blog/author/estelacarmona) 28 August 2026 ### [AI harnesses for telco autonomous networks](https://canonical.com/blog/ai-harnesses-for-telco-autonomous-networks) 5G Article As the telco industry transitions toward Autonomous Networks Level 4, a fundamental architectural challenge has emerged: how do you build a secure, reliable and interoperable AI harness that bridges probabilistic AI reasoning with deterministic, carrier-grade network execution? ... --- [Canonical](https://canonical.com/blog/author/canonical) 25 August 2026 ### [Arduino® VENTUNO™ Q is available for pre-order with Ubuntu pre-installed](https://canonical.com/blog/arduino-ventuno-q-is-available-for-pre-order-with-ubuntu-pre-installed) Canonical announcements Ubuntu tech blog London, UK – August 25, 2026 – Following our initial collaboration announcement in March 2026, Canonical and Arduino (a subsidiary of Qualcomm Technologies, Inc.) are excited to announce that VENTUNO Q is now generally available for pre-order, pre-loaded with Ubuntu. VENTUNO Q is a dual-brain developer board designed for edge AI and robot ... --- [Mikhail Khazov](https://canonical.com/blog/author/khazov-m) 13 August 2026 ### [Advantech AOM-2721 is now Ubuntu Certified](https://canonical.com/blog/advantech-aom-2721-ubuntu-certified) Hardware Enablement Ubuntu tech blog Canonical announces that the Advantech AOM-2721 is officially joining the list of Ubuntu Certified Hardware. ...