A Kubernetes Lab Story: The Vagranting Movie Trailer Voice:
In a world flooded with Vagrant Kubernetes labs . . . .
ONE blogger tried to set himself apart . . .
Title Vote Winner:
Looks like 2 people voted for the main title and the results are unanimous: A Kubernetes Lab Story: The Vagranting wins! Thanks for voting, 50% of my readers!
In Part 1 here, I talk about what I went through to build a Vagrant Kubernetes Lab. In Part 2 next week I will post the lab in all it’s coded glory along with its options.
What Might Set My Lab Apart from Others
You can decide for yourself, but the way I try to set myself apart is by teaching you other things “along the way” . . . sometimes you may not even know it. It’s an approach I picked up teaching high school English in the 90’s.
Yeah. You read at right. Teaching high school English in the 90’s.
You can’t just teach the thing. The thing is just a vessel to teach other, equally important things. I could just post the title, and then a link to the github repo like I do for those “TL;DR jackanapes” and call it a day.
It’s OK. I can call them that. They aren’t reading this anyway.
My point is that learning how to build the lab using Vagrant is just as important as using the Kubernetes lab. Vagrant uses Ruby syntax. These are all worthy skills in cloud engineering. You can put them on a resumé.
So I try to give you the best of both worlds. Once I post the Details in Part 2, you can make your way through the post . . . or you can simply go straight up to the github repo and dive right in.
A Disclaimer: What I Know about K8s
You should know I am not an expert at Kubernetes, nor am I an expert at Vagrant:
On a whim, I used Vagrant only once, before this venture.
I’ve read Nigel Poulton’s The Kubernetes Book. I have done Kubernetes the Hard Way. I have gone through the free training that VMware is offering through kube.academy. I have built a few non-prod, home-lab Kubernetes clusters, both from CLI and on Public Clouds. And launched an app or two. I took the official VMware vSphere on PKS class.
Right now I am making my way through Kubernetes Up and Running, which, as of this writing, you can get for free here, and now K8s is starting to congeal for me.
. . . But nothing I can put on a resume yet. That’s what I need the Kubernetes Lab for in the first place!
Learn from My Mistakes: Trials and Tribulations
So, laying everything bare, blemishes and all, I started to build this one from scratch using Vagrant with the CentOS Vagrant Box and the VirtualBox Provider. One of my goals was to build this so it can be used by me and by others. I knew I would eventually share this with you, dear reader.
I have a Kubernetes master node on my old Dell Laptop with CentOS sitting around, so I just needed some workers to play around with. So, at first, I built a worker-node-only Vagrant Build. That actually worked. But I figured who would want just worker nodes? However, I stuck with VirtualBox bridged networking. I didn’t know it at the time, but this would prove to be my downfall.
For the next iteration I attempted to roll out the K8s Master and Worker nodes all into one Vagranty package. Still building from scratch, I went down that path. The problem, however, is that try as I might, kubeadm init failed miserably on the master node . . . for almost two weeks.
I tried everything. I tweaked package versions and CentOS versions. I consulted the Goole Machine and tried various fixes. I think I even switched to Ubuntu on a night of Churchill Martinis. I suspected it was a networking problem, so I altered how the network was setup on CentOS for the lab. Nothing worked.
I started to look at other Vagrant Lab setups and I found that all of them used VirtualBox host-only networking. Sure enough, once I switched to that, it lit right up.
The problem is, I am still not sure why? I assume it has something to do with Kubernetes that currently escapes me. I am assuming as my K8s journey continues, I will find out. But for now, I felt it was time to move on.
Additionally, I feel obligated to share the most elegant solution with you. Mine worked, but holy crap the code for it was a dumpster fire. As part of this journey, I found this jewel posted by a company called Exxactcorp. I have no idea who they are, but they have one of the best Vagrant K8s labs I’ve seen.
Exxactcorp . . . . whoever you are and whoever posted that . . . I thank you!
It conceptually did everything mine did in the same way only it was way better, way more efficient, and way more elegant. Those details on the “how” will be in Part 2.
But, you might be thinking, “What a waste. You built it from the ground up and used someone else’s implementation anyway? Pfffft!”
Well, Captain Negative, how do you think I learned how to recognize the more elegant solution? . . . Hmmmmmm?
So I took what ExxactCorp posted and ran with it. I did alter their code for two scenarios:
- A fully installed initialized K8s Cluster version of the lab.
- A non-initialized version that has all the K8s/Docker components installed, but no K8s cluster(s). This would be for practicing various flavors of kubeadm init and join.
- All of the above as a nuke and pave approach (thank you, Vagrant).
Scenario 2 is where I came in; I did alter the Vagrant file and an ENV variable to make that happen, so I got to learn Ruby Conditionals! YEAH!
In Part 2 I will disclose all the nasty details. Stay tuned!
Questions? Hit me up on twitter @RussianLitGuy or email me at bryansullins@thinkingoutcloud.org. I would love to hear from you.
Thinking Out Cloud 