(cumu)lonimbus

My final corrections and preparation, how it went, and future thoughts as I wrap up this four post series of my experience leading up to and speaking at KubeCon 2017.

The opportunity to present a “dry run” of this talk was the most important lesson learned of the level of preparation required to really pull off a solid performance at KubeCon.

Having performed a good portion of the research and validation prior to being accepted as a form of passing the time, I’ll admit I let the scope creep a bit too far.

In this four part blog series on my journey to speaking at KubeCon 2017, I want to share the knowledge that I have learned in the hopes that it encourages others in the community to muster the courage and confidence to bring their own unique experiences to light.

At work, we use kube-aws to deploy our Kubernetes clusters running on top of Container Linux inside of AWS. I wanted to be able try new things with Kubernetes in my personal lab without having to rack up huge AWS bills, so that means figuring out a good way to deploy Kubernetes to baremetal in the least painful way. I wanted to try Tectonic because it offers a simplified graphical installer, and that means I also need to install Matchbox to support the baremetal provisioning aspects.

I’ve found these talks really helpful in understanding what Kubernetes does and how it works from an architectural level:

In part 3, I identified several weaknesses to my approach to this project as shown in part 1 and part 2. To summarize:

In part 1 and part 2, I’ve got the basis for a simple network-based hardware provisioning system. However, it has some issues that I’d like to list here to drive future improvement efforts.

In part 1, I walked through the initial network booting process to be able to start the Centos 7.x installation process. In this part, part 2, I’ll continue on to explain the Centos 7.x specific portions of things as well as break down the kickstart configuration file.

When building a “Metal as a Service” (MAAS) layer, the idea is to make it very easy to go from “box to rack to ready” for a large number of servers. To make this easier and to reduce complexity at this layer, most organizations purchase one or more sets of similar servers from a single manufacturer. Depending on the level of service, they may have the manufacturer/vendor prepare the systems a certain way before they show up at the door. A technician can just unbox them, inventory the asset, slide them into the rack, cable it up, and be done with their part.

The advancements brought about by the DevOps culture movement in the past 6+ years are nothing short of a computing renaissance, and the pace isn’t slowing. Where one or two tools used to exist to administer large numbers of systems, there is now an entire industry of open-source and commercially backed software built by many talented teams and individuals that can solve nearly every problem. What I’ve noticed, though, is that the scope of knowledge needed to fully understand each layer has exploded with that growth.