Introduction
While planning out the Network for Azure Kubernetes Cluster, we think of the following considerations.
- Does my Azure Kubernetes Cluster need to integrate with other components outside Cluster, or is it self-contained and need not integrate with external components?
- Do you need to access the Pods in a cluster directly, or you need to isolate the Pods in the Cluster so that no one can access it directly?
- What is the strategy you should follow to communicate with the Pods?
- Do you need to configure network policies and firewalls at the Pods level?
- What is the number of networking components and pods you are planning for the Cluster, and do you have enough IP addresses to assign?
These considerations form the basic building block for your Azure Kubernetes Cluster Network design. You need to plan out the Network for your Azure Kubernetes cluster before provisioning the Cluster. Or you may end up recreating the Cluster to accommodate any network-level changes at a later point of time. Azure Kubernetes Service provides the following types of Virtual Networks to address the networking concerns for your Cluster.
- Basic Networking using Kubenet
- Advanced Networking using Azure CNI
Kubenet does not allow you to connect to the Pod directly. However, using Azure CNI, you can directly access the Pod. Let us explore Kubenet Virtual Network for Azure Kubernetes Service in this article and reserve Azure CNI Virtual Networking for the next article.
The following are the previous articles of the Azure Kubernetes Series that helps you build the basic concepts in this area.
Basic Networking using Kubenet
Kubenet is the simplest networking option provided by any Kubernetes cluster. The Virtual Network of a Kubenetes cluster using Kubenet is created and managed by the Kubernetes Master. You do not have any control over it. By design, you cannot integrate the Kubenet Virtual Network with any other Virtual Networks. Each of the Nodes in the Cluster gets an IP address from the underlying Virtual Network range. However, the Pods get an IP address that is not from the Virtual Network range. Kubernetes Master assigns the IP address to the Pod while creating it in the Cluster. That is the reason why the Pods are not accessible directly from outside the Cluster. Each of the Pods in the Node gets connected to a Bridge. This design helps the Pods to communicate with each other inside the Node. The Bridge connects to a Router that routes the traffic from the Bridge to the external world. The Network Address Translation helps to translate the IP address to an external IP address as recognized by the destination Node that can also be in a different Virtual Network. IP Forwarding gets enabled for the Nodes, and the User Defined Route sends the traffic to the destination Node based on the external IP address translated by the Network Address Translation.
Figure 1 depicts a Kubernetes Cluster networked using Kubenet, where the Master Node has provisioned a Virtual Network with Address Range as 10.220.0.0/16. Node 1 and Node 2 gets an IP Address assigned from the underlying Virtual Network. There are two Pods in each of the Nodes, and the Pods have acquired IP addresses different from the underlying Virtual Network. Suppose we have a scenario where Pod 1 in Node 1 communicates with Pod 4 in Node 2. Pod 1 sends traffic to the Bridge, and the Router routes the traffic beyond Node1 from the Bridge. The Network Address Translation translates the IP address to the destination address. User-Defined Route delivers the traffic to Node 2. The Network Address Translation and the Router delivers the traffic to the Bridge in Node 2, and the Bridge delivers the Network to the Pod 4. Pod 1 can communicate directly with Pod 2 without needing to route the traffic beyond the Bridge.
Figure1
When you use Kubenet, you cannot secure your Pods using firewalls. You cannot have a Firewall configured for your Pod. You can configure Kubernetes Networking using Kubenet along with Calico that helps you configure Firewalls for the Pods.
You can replace the Bridge in the Cluster with Calico component that plays the same role like that of Bridge. Also, Calico facilitates configuring Firewall Policies for the Pods. Figure 2 depicts a Kubernetes cluster with Kubenet networking and Calico.
Figure 2
Winding Up
In this article, we learned the Networking options available for the Azure Kubernetes Cluster and the Basic Networking option using Kubenet. We also learned how Calico could be used with Kubenet to configure Firewall policies for the Pods. In the next article, we will explore the Advanced Networking option using Azure CNI.