When I wrote my last post about stepping back, I didn’t anticipate it’d be over four years until I posted again. And yet, 1,486 days have passed since I posted last.

Whoops.

Even more embarassing, the SSL cert expired sometime over the summer. My process for rotating the certs required around ~15 minutes of manual ops work every 90 days.¹ Honestly, I’m giving myself credit for keeping the cert fresh for over three and a half years, but over a delightfully packed summer, the need to manual action caught up with me.

Hiya folks, just a quick post from me today :)

After over a year of daily(-ish) contributions, I just want to let folks know I’m going to be taking a step back from contributing to Kubernetes. Once this diff is merged, I won’t be a reviewer for sig-node anymore. Additionally, with the KEP for Building Kubelet Without Docker complete, my major projects are all wrapped up, and I doubt I’ll be picking up new ones.

tl:dr;

By the end of this blog post, you’ll understand the tests your proposed Kubernetes diffs must pass before being merged. You’ll have all the background information to be ready for part 2 (coming soon), in which we discuss how to actually run all the different test suites locally.

Background

As a brief reminder, I’ve been focusing the majority of my open-source development capacity on Kubernetes for almost a year. During that time, and going forward, I’m writing blog posts geared towards potential new Kubernetes’ contributors. I hope these blog posts will augment existing Kubernetes documentation,¹ and decrease the barriers for potential contributors to making meaningful commits.

Just a quick post :) Yesterday, I had the pleasure of being a guest on the Kubernetes projects' awesome monthly Meet Our Contributors session, led by Paris Pittman. Nikhita Raghunath and Paul Morie were also guests; it was great to speak with, and learn from, them.

Here’s the recording of the session!

These sessions happen every month and are a great resource. A big thanks to Paris for organizing them, and would definitely encourage everyone to check them out and ask questions. See the #meet-our-contributors channel on the k8s slack for more info!

In my last post, I discussed how I was spending the majority of my non-work programming time focusing on Kubernetes contributions, with a particular focus on sig/node. Well, that statement is still true :) Hopefully, I’ll find the time in 2020 to blog more regularly about this work, but it’s not what I’m going to share today.

Introducing Nuage

via GIPHY

Rather, I’m excited to post today about Nuage. Nuage is the name I’ve given to my project to manage all aspects of my personal computing in the cloud.

Since I last posted, I’ve been focusing almost all of my “fun coding” time on contributing to the Kubernetes code base. You can see my contributions on my Github. I’ve been particularly focusing on the components of the code base owned by sig/node. It’s been rewarding and a great learning experience… but it does mean I haven’t been focusing on adding features to my personal Kubernetes cluster. And since that’s what I mainly blogged about, it also means I’ve been blogging less. While I hope to blog more about my k8s contributions in the future, I currently feel I should be 100% focused on writing and reviewing code.

Regularly updating our k8s cluster, and the applications running on it, is one of the most powerful tools we have for ensuring our cluster functions securely and reliably. Staying vigilant about applying updates is particularly important for a fast moving project like Kubernetes, which releases new minor versions each quarter. This blog post outlines the process we’re proposing for ensuring our cluster, and the applications running on it, remain up to date. We believe its lightweight and manageable, requiring only a relatively small amount of work on a monthly cadence. We also believe it applies updates in a reasonable time frame.

Kubernetes is a incredibly exciting and fast moving project. Contributing to these types of projects, while quite rewarding, can have a bit of a startup cost. I experienced the start up cost a bit myself, after returning to contributing to the Kubernetes after a couple of months of focusing on running my own Kubernetes cluster, as opposed to contributing source code. So this post is partially for y’all and partially for future me :)

We’re excited to announce all connections to mattjmcnaughton.com, and its subdomains (i.e. blog.mattjmcnaughton.com, etc.), are now able, and in fact forced, to use HTTPS. After reading this post, we hope you’ll be convinced of the merits of using HTTPS for public-internet facing services, and also have the knowledge to easily modify your services to start supporting HTTPS connections.

Why do we care about HTTPS?

via GIPHY

Offering, and defaulting to, HTTPS is good web hygiene. It has been a particular focus of the EFF over the last year, as they describe in this summary of their Encrypt The Web initiative.

So far, most of our posts on this blog have been about the exciting parts of running our own Kubernetes cluster. But, running a Kubernetes cluster isn’t all having fun deploying applications. We also have to be responsible for system maintenance. That need became particularly apparent recently with the release of CVE-2019-5736 on 2/11/19.

What is CVE-2019-5736

via GIPHY

CVE-2019-5736 is the CVE for a container escape vulnerability discovered in runc. Runc is a CLI tool which runs containers in accordance with the Open Containers Initiative (OCI) spec.