Thanks to Collabnix community member Mewantha Bandar , a Senior Software Engineer at IFS for contributing this content for KubeLabs – The #1 Kubernetes Resources for all Levels. Do you have anything exciting to share with Collabnix community? Do visit Collabnix community Slack and we might feature you in Collabnix website.
If you’re a great fan of Minikube and have been using it to host your Kubernetes clusters, it is important to understand that it might be a great tool for development and testing but however, when it comes to production, you need a Cloud-based, scalable, and highly available solution. Implementing this out of scratch on our own server would be very challenging, and make little sense, which is why all major cloud providers have an implementation that allows you to run your Kubernetes cluster on the cloud. AKS helps achieve this to some degree.
What is AKS?
To start understanding exactly what AKS is, let’s backtrack to the beginning. If you’ve forgotten the Kubernetes architecture, perhaps this is a good time to revisit this article.
Consider the following architecture, which is how Kubernetes works:
You have the master node which handles and provisions worker nodes, which do the actual work of holding pods. Previously, when we used minikube, we ran everything on our local machine. However, now, we can move part of this to AKS. One thing to note is that AKS does not act as an alternative to the entire Kubernetes architecture, rather, it only replaces the master node. As such, AKS is free and only requires a normal Azure subscription. The processes which take place within the master node would be invisible to you, and you should not really care as to what goes on in the background. Instead, you only have to think about the service it provides, and how your worker nodes would use that service. In short, AKS abstracts away anything specific to the master node, and provides a host of other features as well. It does this by hosting everything on Azure, and providing it as a service.
Why use AKS?
You can reap the full benefits of AKS if the rest of your application, or your organization uses Azure cloud as their main cloud platform. The master node, which is handled by AKS allow you to upgrade your cluster with minimal hassle, allows seamless integration with other Azure services. Azure policies that you may have defined can be applied across clusters, and AKS handles provisioning and scaling with autoscaler integrations which takes all the manual work away from your. If you use Azure Container Instances (ACI), then you can schedule your containers in conjuction with AKS.
A major part of AKS is it’s ability to network, so we’ll be taking a look at that further.
AKS Networking
When deploying a cluster, there are two networking models to consider:
- Kubenetes networking
- Azure Container Networking Interface (CNI) networking
Kubenetes Networking
This model works off the Kubenet Kubernetes plugin, and is the default configuration for AKS. Since you would want to integrate your cluster with services across Azure, you would rely on your Azure Virtual Network (VNet). Your VNet is essentially your private network within Azure, and allows unrestricted communication between you Azure resoureces. It also allows communication with external resources, as well as the internet, and this is what Kubenet will be using as well. Both your nodes and your pods will get IP addresses from VNet, grouped by two different address spaces. That is to say, pods don’t get real IP’s. Since they reside in different address spaces, they have to use IP forwarding and Azure routing services. If you are not sure about these concepts, feel free to take a look at how traffic gets routed around Azue VNets from the official docs. Any resources that need to be addressed that are outside the Azure VNet get accessed by NAT (Network Address Translation). Once again, if this concept is unfamiliar to you, the official docs are you best friend.
Advantages
Why would you want to use Kubernetes networking? There are a couple of reasons:
- Not too much pre-planning required
- Little setup time (default option)
- Only node get real IP addresses, not Pods, which means you don’t need as many allocatable IP addresses.
Disadvantages
There are several disadvantages of Kubernetes network, which can make organisations consider Azure CNI instead. They are:
- User defined routes can be hard to manage as your cluster gets bigger
- Since pods don’t have IP addresses, there is addional latency when communicating among nodes
- You can only have one AKS cluster per subnet
Azure Container Networking Interface (CNI) networking
Unlike Kubenet, where the pods didn’t get real IPs, using CNI’s assigns real routable IP addresses to pods. This is a slightly more advanced form of networking and will require some planning ahead. This method allows the pod to be accessed directly using the IP addresses they get from the subnet. The number of IP addresses needed is set aside for the node. Since this is a hard limit, this is where planning is needed to prevent exhausting IP addresses. Both pods and nodes get IPs from the same subnet and therefore support up to 250 pods per node.
So how would a pod communicate between resources? If the resource is within the same VNet, the target resource will see the pod’s IP directly, while if the resource is outside the VNet, then the target resource sees the node IP. Not the pod IP.
Advantages
There are a couple of advantages to using CNI, which contrasts with Kubenet:
- Supports Azure network policies and Windows Containers
- No additional latency since each pod has its own IP address
Disadvantages
- Proper planning needed to prevent IP address exhaustion
- Setup is more complex
In our next blog post, you will see how to manage roles in AKS. Stay tuned!
References:
Comments are closed.