A Deeper Look at the Networking for TKGs
It's not Me, It's the Network
I created a TKGs Networking web page that supplements the Quick Start Guide with a focus on the networking sections. It tries to teach three things, culminating in a concrete, very usable example.
- It gives a history of applications ending in modern apps (fragmented into many microservices) and explains how containers, Kubernetes, and finally TKG make it all manageable.
- It explains what all the appliances, machines, clusters, and subnets in a TKGs (or Workload Management) environment are doing, and explains what network addresses/ranges they need.
- It lays out example addresses/ranges in a complete TKGs block diagram and then correlates all of them with screen shots of the dialog boxes where the addresses are configured.
The web page lets you progress through its sequence of instruction with single steps, or in a "play-all" mode. It even has an audio narration, if you want it.
Follow the link to the TKGs Networking web page and you will see it is on a private site for now.
Or you can begin with a video of it in "play-all" mode.
I created this web page because the first time I set up a TKGs environment, I was easily understanding and following the Quick Start Guide until I needed to enter all of the networking information to configure HAProxy and Workload Management (vCenter's name, more or less, for TKGs). Then I got lost and had to ask for help. There were too many components for me to track in my head. The names of things in vCenter were not matching with the labels I had for them conceptually. And there were a lot addresses and ranges to assign.
Maybe it was just me and my beginner-level understanding of TKGs, but I found others who struggled with the exact same networking questions. So, I thought I would try to help anyone else who needed help over this hurdle. I thought a big block diagram of components, addresses and dialog box screen shots ought to clear things up.
If you want to know more before clicking on the link, you can find a few highlights from the web page below.
The Journey to TKG
In the "Brief History of Computing" section of the site, we look at how a few simple applications moved into the many, fragmented microservice applications of today. To manage all the pieces well (or at all), we see that Tanzu provides the quick-launching substrate for multiple Kubernetes clusters which, in turn, orchestrate the teeming pods of containerized services.
Figure 1: History of computing has cycles of proliferation, modularization, complexity, unification & management
TKGs, its Components, and their Addresses
This section should help you mentally distinguish the Supervisor from other TKCs, understand the role of HAProxy, and see how the two subnets (workload and management) divide their addresses among the components. You should learn that TKGs network configuration breaks down into two parts: configuring the HAProxy appliance during deployment, and configuring the supervisor cluster as part of setting up "Workload Management" from vCenter.
Figure 2: Explanations of TKGs components and planning for TKGs networking
TKGs Example
The site finishes with interactive screen shots, plus lines between configuration fields and the example addresses/ranges on the block diagram. If you understand the one, you can understand the other.
Figure 3: TKGs networking example correlates addresses on block diagram with those in configuration dialog box
Everything You Wanted to Know about TKGs, but Were Afraid to Ask
My astonishment is evergreen. I've been a tech nerd all my life and no sooner have I gotten a handle on the latest new layer of computing abstraction, than I found forces have built two more above me. TKGs, Kubernetes, and containers are marvelous tools — they herd cats like nobody's business — but, at first, you may find yourself holding a tiger by the tail (if I can subtly shift feline metaphors). I'm hoping this new web page makes it far easier to conceptualize the TKGs components, causes their networking requirements to seem obvious, and then sets the configuration task in work-a-day concrete.