{"id":3099,"date":"2022-01-27T18:52:38","date_gmt":"2022-01-27T06:52:38","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=3099"},"modified":"2022-01-28T10:36:32","modified_gmt":"2022-01-27T22:36:32","slug":"kubernetes-home-vagrant-nodes","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/3099\/","title":{"rendered":"Kubernetes @ Home: Vagrant Nodes"},"content":{"rendered":"[Estimated Reading Time: <\/span> 8<\/span> minutes]<\/span><\/span>\n

The first significant practical step in establishing my Bare Metal Kubernetes cluster was to provision 4 VM’s. At this point it is worth mentioning that actually installing Kubernetes is almost trivial once you have the necessary hardware in place. Since my ‘hardware’ was going to be virtual, this meant that provisioning the VM’s was by far the biggest job so after an initial manual install, so I set about automating as much of this process as I could.<\/p>\n\n\n\n\n\n\n\n

The Task<\/h2>\n\n\n\n

Having settled on 4 VM’s to provide my 4 nodes, I had 4 VM’s to be configured and 4 installations of Ubuntu Server 20.04 to be performed.<\/p>\n\n\n\n

I had already previously established a working Kubernetes cluster by manually creating and configuring each VM and installing Ubuntu Server on them all. Although not complicated, this was tedious and I foresaw much frustration if\/when I ever needed to rebuild the cluster so looked for something to automate this repetitive and fiddly business.<\/p>\n\n\n\n

The ‘Vagrant’ Mis-Step<\/h2>\n\n\n\n

Vagrant<\/a> appeared to offer a perfect solution.<\/p>\n\n\n\n

Though not related to Kubernetes, Vagrant<\/strong> employs a similar approach, using a declarative mechanism rather than imperative. That is, Vagrant<\/strong> takes a description of a VM (or VM’s) and compares it to the current “real world”, making whatever changes are required to bring the real world into line with the declared desired state.<\/p>\n\n\n\n

Vagrant<\/strong> supports a number of virtual machine platforms with VirtualBox<\/strong> being the default. Crucially, it offered support for Hyper-V<\/strong>.<\/p>\n\n\n\n

It initially appeared that all I needed was a VagrantFile<\/code> describing the 4 VM’s for my nodes, something similar to:<\/p>\n\n\n\n

Vagrant.configure("2") do |config|\n  # This is a multi-machine VagrantFile.\n  # These settings are applied to all VM's\n  config.vm.box = "deltics\/focal64"\n\n  config.vm.network "public_network"\n\n  config.vm.provider "hyperv" do |vm|\n    vm.cpus = 4\n    vm.memory = "8192"\n    vm.vlan_id = 2\n  end\n\n  # The remaining settings are applied individually\n  # to each separate machine that is defined\n\n  config.vm.define "master" do |node|\n    node.hostname = "master"\n    \n    node.vm.provider "hyperv" do |vm|\n      vm.vmname = "k8s.master"\n      vm.mac = "ffffffffff00"\n    end\n  end \n  \n  config.vm.define "worker1" do |node|\n    node.hostname = "worker1"\n    \n    node.vm.provider "hyperv" do |vm|\n      vm.vmname = "k8s.worker1"\n      vm.mac = "ffffffffff01"\n    end\n  end \n  \n  config.vm.define "worker2" do |node|\n    node.hostname = "worker2"\n    \n    node.vm.provider "hyperv" do |vm|\n      vm.vmname = "k8s.worker2"\n      vm.mac = "ffffffffff02"\n    end\n  end \n  \n  config.vm.define "worker3" do |node|\n    node.hostname = "worker3"\n    \n    node.vm.provider "hyperv" do |vm|\n      vm.vmname = "k8s.worker3"\n      vm.mac = "ffffffffff03"\n    end\n  end \nend<\/code><\/pre>\n\n\n\n
A VagrantFile<\/mark> is specified in a project (folder).  It may describe a single VM or a number of them.  In the context of that project (i.e. folder), when the command vagrant up<\/mark> is performed, Vagrant<\/strong> examines the VagrantFile<\/mark> and compares it against the state of the virtual machines currently established in that project, the VM’s themselves being created in a .vagrantd<\/mark> subfolder.<\/p>\n\n\n\n
The first time the command is run, for example, there are no actual VM’s that exist at all, so Vagrant<\/strong> will apply the configuration described in the VagrantFile<\/mark> and create the specified VM’s in that .vagrantd<\/mark> folder.  If changes are made to the VagrantFile<\/mark>, those changes are applied to any existing VM’s the next time vagrant up<\/mark> is performed.<\/p>\n\n\n\n
The “2” in the initial configure<\/mark> statement indicates the desired Vagrant API Version and is nothing to do with the number of VM’s defined by the file.<\/p>\n\n\n\n
A quick note on VagrantFile<\/mark> syntax.  Although it looks<\/em> like a declarative configuration file such as yaml<\/strong> or json<\/strong>, it is in fact a Ruby program; the Vagrant<\/strong> Api is specifically designed to make it appear<\/em> as declarative as possible.<\/p>\n\n\n\n
Almost everything needed for my VM’s could be specified in a VagrantFile<\/mark>, as illustrated above.<\/p>\n\n\n\n
Almost<\/strong><\/em> everything.<\/p>\n\n\n\n
As illustrated above, my project required a “Multi-Machine<\/a>” file, with basic configuration that applied to all machines and further configuration specific to each individual machine (which in turn identifies those machines as needing to be created).  In addition, whilst many properties of a VM are configurable through generic Vagrant<\/strong> properties, some are specific to the particular provider being used, in my case Hyper-V<\/strong>.   Provider-specific properties<\/a> are accessible using the …vm.provider “hyperv” do |vm|<\/mark> configuration blocks.<\/p>\n\n\n\n
Properties common to all VM’s in the project are specified at the “top level”.  VM-specific settings are then provided within a nested configuration block that define<\/mark>s each VM.  For example, this block defines and configures the VM for the master<\/strong> node, including the hostname supported by the general Vagrant Api<\/strong> and the Hyper-V provider-specific<\/strong> configuration for the name of the VM (as identified in Hyper-V<\/strong> itself) and MAC address:<\/p>\n\n\n\n
  config.vm.define "master" do |node|\n    node.hostname = "master"\n    \n    node.vm.provider "hyperv" do |vm|\n      vm.vmname = "k8s.master"\n      vm.mac = "ffffffffff00"\n    end\n  end <\/code><\/pre>\n\n\n\n
In my case, Hyper-V<\/strong> provider-specific properties are required both in the common section and in each VM-specific section.<\/p>\n\n\n\n
We can see that the VagrantFile<\/mark> specifies the same amount of RAM for each VM as well as the CPU count and VLAN ID since these are consistent across all VM’s:<\/p>\n\n\n\n
  config.vm.network "public_network"\n\n  config.vm.provider "hyperv" do |vm|\n    vm.cpus = 4\n    vm.memory = "8192"\n    vm.vlan_id = 2\n  end<\/code><\/pre>\n\n\n\n
The network specification here seems to be more for Vagrant’s purposes than for configuring the VM’s themselves as it has no bearing on or relation to the Network Switch<\/strong> settings of the VM’s that I can determine.<\/p>\n\n\n\n
Then, as we’ve seen, a number of VM’s are define<\/mark>d with configuration specific to each, including:<\/p>\n\n\n\n