“If you don’t have time to do it right, when will you have time to do it over?” - John Wooden
When a book is finished, intertwined with the relief that comes from having finished something so vast, is a growing sense of dread over all the things you worry you got wrong or plain just didn’t get around to writing. When I was done writing Cloud Native Data Center Networking, a topic that I felt I didn’t adequately cover due to a lack of time to frame the discussion accurately was Kubernetes.
Kubernetes has been of course all the rage for the past couple of years. VMWare bought Heptio for a good chunk of change to deal with the momentum behind Kubernetes. Kubernetes been in the limelight so much, that many who rushed to it thinking it could fix anything, from poorly written applications to bad parenting, are now angry and weeping tears of disappointment. The backlash has ranged from those who laughed at the gullibles to those complained about its complexity to whether it does anything useful(see here and here). Joe Beda, one of the inventors of Kubernetes, recently took to Twitter to defend his creation. More about that in a bit.
When I wrote the chapter on container networking, my hope was to equip the network engineer and architect with knowledge that they could use to design a better distributed system together with the application infrastructure operators. However, containers have been subsumed as a part of the larger cluster orchestration tool that is Kubernetes. So, dedicating more of the chapter to how Kubernetes views networking would’ve better served the readers, I fear, than just talking about container networking. The pleasure of a book is a heft that’s pleasing to hold. The pain of a book is that the world rushes by uncaring to hold sacred the truths the book speaks about.
So, when I got a chance to make amends, I took it. Cumulus wanted me to do a webinar or two as part of their sponsoring the book. I readily agreed and when someone said containers as a topic, I changed it promptly to Kubernetes and decided to do a Kubernetes in the Data Center webinar. The topic is vast, and I had only a hour or at best 90 minutes. So, instead of diving into packet traces, and detailed configuration snippets, I provided an overview of Kubernetes that I think is useful for a network operator to know. Just enough to be dangerous, to ask intelligent questions and guide the choices facing an application infrastructure provider.
When I first started talking about this webinar, I reached out to a few friends to ask them what they’d like to see covered in the webinar. More than one of them said, why should I know about Kubernetes as a network operator when I didn’t need to do that for VMs (virtual machines). The short answer is that this sentiment is false. Ask anybody who tried to build a pure L3 infrastructure with VMWare (see this post for how little this has changed in 2020). Prominent VM infrastructure providers and many enterprise application developers engaged in practices that led to building bad networks. For example, instead of using DNS for service discovery, many of the applications relied on using broadcast and multicast to discover each other. This meant the network had to be layer 2. Another example is the insistence on retaining the IP address when a VM had to be reinstantiated because of a failure. To be clear, there is nothing inherent in VMs that mandates all this, but this was how VMs could be consumed by enterprises. Kubernetes does not even attempt to retain the IP address of a container when it spins up. Understanding this means not having to rely on layer 2 constructs when deploying Kubernetes. Thus, there are good reasons to understand what Kubernetes wants as a network operator, to avoid continuing to pay for the sins of the past.
History, basic Kubernetes concepts, different CNIs (Container Network Interface), network design tradeoffs and more consumed about 90 minutes or so that included addressing the questions of a fairly engaged audience. You can watch the webinar here (I’m working on making the slides available as well).
Coming back to the backlash against Kubernetes, I found this post by Jason Moiron a very thoughtful and insightful one. One of the best points is this line from Joe Beda’s tweet: “…I think that, as engineers, we tend to discount the complexity we build ourselves vs. complexity we need to learn.”. I recommend reading it in full. To be clear, I’m no cheerleader for Kubernetes(besides, I don’t have the figure for it) . I’m simply trying to understand it and distill it to its essence. Then, I can begin to have an opinion.
Next, I plan to add Kubernetes support to the github repository that is companion to my book. With that in place, I can begin writing a little more in depth about Kubernetes from a networking angle, hopefully demystifying it in the process. As always, please feel free to reach out with questions and more. To rephrase John Greene, “Don’t forget to build an awesome network today”.
Suzieq
Try out Suzieq, our open source, multivendor tool for network observability and understanding. Suzieq collects operational state in your network and lets you find, validate, and explore your network.