It’s amazing how in the past year or so, efforts in the telecom industry to move next generation systems into containers and manage them with Kubernetes have moved from theory to practice. The 5G core, for example, was specified by 3GPP in a cloud native way from the start, and even things like Open Radio Access Network (Open-RAN), whose specification effort started a bit earlier and hence is still based on Virtual Machine technology is moving quickly to container based solutions in the real world. This was one of the reasons while about a year ago I had another look at Docker and Kubernetes which resulted in my Docker and Kubernetes introduction posts on this blog. Also, I have dockerized a number of services I host for myself (e.g. this blog!) and use containers in my own software development and deployment process. This has made it much easier to spawn independent instances of my document research database for various friends in minutes instead of hours. But as far as Kubernetes is concerned, I don’t really have a practical use case myself, so I did not go beyond a Minikube installation. So one thing that always remained a bit opaque to me is how Amazon and other hyperscalers make Kubernetes clusters available from their data centers.
What I imaged was that perhaps one would have to get a username and password for a hyperscaler Kubernetes service, and would then interact with single and gigantic Kubernetes cluster used by thousands of companies and deploy services into that. But how would one access those services from outside, would I get a dedicated IP address for them, how would I get TLS certificates for https and how would the whole thing be built? How would the hyperscaler know how much processing power and storage I would want and bill that? Many questions that I finally had a bit of time to follow up. The answers to all of these questions are surprisingly simple if you have some basic Kubernetes knowledge and have perhaps already installed Minikube locally.
A friend recently pointed me to this great 3+ hours video on YouTube by Nana Janashia which follows pretty much the same path as my 4 part Kubernetes intro. In addition she also has a section on Helm Charts and Kubernetes Ingress, which I did not look at so far. There are a bunch of other interesting videos on here Youtube channel, including an introduction of how to deploy a Kubernetes project on Linode or Amazon.
Kubernetes at a hyperscaler works very differently from what I thought so far. Instead of getting an account on a huge Kubernetes cluster, you virtually build your own Kubernetes cluster for your project. On Linode, that’s straight forward. Once registered, you go to the Kubernetes session, create a new cluster and then tell Linode how many worker nodes you require for that cluster. The worker nodes are virtual machines and you can choose how much RAM and storage you require for that cluster. Once done, the cluster is created and can be accessed from your notebook or local machine with the kubectl command just like that local Minikube cluster I experimented with. No difference!
So how do I access my services in that cluster over https? This is done by using the Kubernetes Ingress module. Basically, the module needs to be told in a yaml file which domain name and path should be routed to which internal service (i.e. to which container to abstract it a bit). And if you want https instead of http, a TLS certificate has to be provided (e.g. generated with Letsencrypt). And that’s it, no need to install a reverse proxy or anything, just a domain name, path and a TLS certificate need to be configured. And if you have several projects and want to use different worker nodes for them, you just create several Kubernetes clusters. Why only have one when you can have several?
Nana also has a video where she shows how Amazon (AWS) makes Kubernetes available. In principle this works the same way as described above, but there are many more configuration options that make the setup process of a cluster look way more complicated than it actually is.