One of the things I’ve been doing a lot of recently is deploying RancherOS nodes into VMware’s vCloud Director. While automating the process entirely has provided its own set of challenges, the one that has been the most difficult to overcome is that of asking the cloud-init network interface settings to set themselves correctly. The Problem In most cloud providers, container-optimised operating systems have no real issue in determining their network settings given to them (including from vSphere/ESXi hypervisors).
In this edition: longer lasting data! If you’re coming here from part one, you should have a single-node Rancher Kubernetes node just waiting to be explored. This part will go into more detail about some important components and how to use them to your advantage. Storage in a Nutshell Kubernetes, just like Docker, is stateless. As soon as you stop a pod, the data it contained is gone forever. This is only really a bad thing if you’re running something that needs to have persistent storage, like a database or wiki.
A working Kubernetes installation in a single lunch break! This is a write-up of my project to get Kubernetes working as a single-node, general purpose install on a baremetal server provided by OVH. It took me a long time to find the right information on how to do this, as many of the components are new with little documentation provided. DISCLAIMER A single-node instance like the one I’m about to describe is incredibly useful for a personal system or learning tool, but should not be confused with something that’s acceptable for production workloads.