Topics Discussed:
- Computer Networking Basics
- Azure Networking Overview
- AKS (Azure Kubernetes Service)
- POD and Service Connectivity
- Azure Network Plugin
Computer Networking Basics:
Switch: In a LAN network, devices connected together with the help of a switch form a LAN network. The switch internally keeps a table containing the interfaces and MAC addresses of the devices in the network. With the help of that table, the switch interconnects those devices. Hence, the switch works at Layer 2.
Router: To connect two LAN networks, we use a device called a router. The router has routing rules defined for traffic flow.
Firewall: In our homes, we use a MODEM to connect to the public internet, where our private IP is translated to the public IP, enabling the connection. This conversion is called NAT. Inside the firewall, we can filter traffic.
DNS and DHCP: DNS is for converting between Domain Names and IP addresses. DHCP provides IP addresses from a pool of IPs.
Load Balancer: To distribute traffic to backend servers, where it will not send traffic if a server is down but instead send it to healthy nodes. There are two types of Load Balancers: one works at Layer 7 and the other at Layer 4. The one that works at Layer 7 is the traditional Load Balancer, usually called an Application Delivery Controller. We can use it as a reverse proxy by assigning a public IP. A reverse NAT process is happening behind.
Network Virtualization or Software Defined Network (SDN): This concept was also discussed.
Azure Networking Overview:
The ultimate boundary is the tenant or the Azure account. Inside that, we can create subscriptions. Azure AD or Microsoft Enterprise ID is an Identity and Access Management service that holds the identities and their authentication. The info of users and groups are available under Azure AD. There are different types of subscriptions available. Then comes the resource group, which is a logical grouping of resources for ease of management and to establish isolation. If we create a Virtual Network, we cannot create any resource there. For that, we need to create a subnet under the address space of the VN. The NSG will filter traffic to the subnet. By default, all the subnets are interconnected with the help of default routing rules. To override the same, we can write our rule and attach it to the subnet. Virtual networks in Azure enable network address space and provide IPAM. We can add multiple IP address spaces into VNET; however, resources cannot lease IP addresses directly from the VNET. Instead, the VNET address spaces need to break down into smaller IP address spaces called subnets. Each Subnet can be associated with an NSG (Network Security Group) that filters traffic to and from the subnet. By default, all the subnets within a VNET are interconnected with the help of default routing rules. To override the same, we can write our rule called UDR (User Defined Routing) and attach it to the subnet.
AKS (Azure Kubernetes Service):
Kubernetes is a container orchestration tool, and AKS is the Azure managed Kubernetes service. The Control plane and Data plane (worker nodes) were given a basic overview. The API server, Scheduler, controller manager, ETCD are the main components in the control plane while kubelet, Container runtime, containers, kube-proxy etc in nodes. The Nodes are created in Virtual machine scale sets for scalability. In AKS, the control plane is managed by Azure, but there are some responsibilities on our end also. The AKS is accessible via a public API. It is possible to enable the private DNS zone to enable access only via a private IP. The public IP/ DNS can also keep enabled and secure the access with IP rules setting. Also, the ETCD database is by default encrypted using a platform-managed key, which can be encrypted using a customer-managed key, which increases the security posture.
Vnet Integration:
It’s a preview feature where the AKS API can be made accessible simultaneously with private and public IPs.
Azure Kubernetes Networks:
There is a Set of addresses associated:
- POD CIDR: depends on the network plugin
- Service CIDR
- Azure VNET CIDR
- Docker CIDR (Deprecated)
The traffic associated:
- Traffic towards the API server
- Traffic between PODS
- Traffic between PODs and Services
- Traffic between Nodes in a cluster
- Traffic between AKS and other Azure resource
Suppose we have a Virtual Network and an AKS subnet inside it. Two worker nodes will lease IP addresses from the subnet. Kubelet runs in the nodes. POD is the smallest compute unit in Kubernetes, which encapsulates the container. So the use of services reduced that by implementing IP address access to the pods with the same application via load balancing to the Pods. The service Type ClusterIP will enable communication of PODS inside the cluster only. But the load balancer Type will enable outside access, which can be Public or Private, where an actual load balancer will be created to communicate with the AKS.
POD and Service Connectivity:
The service can be considered as an Object which is having CIDR and POD is also having a separate CIDR. The communication from POD to service possible via a router, here the IP Table will serve the purpose. Any updation on the IPs of the POD by deletion of pods etc need to be updated in the IP tables, This task will be done by a Kubernetes component called kube-proxy. The kube-proxy will communicate with the API server and update the IP tables on changes. The service load balances the traffic to the PODs randomly, and we cannot implement load balancing algorithms here. In order to do so, we can use VPS.
Azure Network Plugin:
- KUBENET: In this type of network plugin, the POD CIDR will be created inside the cluster. PODs are connected internally via a switch and externally with the help of services. We have to define UDR, user-defined routing, on the subnet. This limits the node scalability. Also, the IP forwarding should be enabled in the Nodes Network Interface.
Azure CNI: Here the PODs are getting the IPs from the node subnet CIDR itself. So no need for the UDR.
a. Azure CNI Dynamic: In this network plugin, a separate subnet CIDR will be created dedicated to the POD. Azure CNI, where the PODs must be leased IP addresses from Nodes subnet. It provides more flexibility, overcoming the Cons of kubenet.
b. Azure CNI Overlay: This type of network plugin is more similar to kubenet, But instead of using the UDR, it uses NAT. Thus, overcoming the cons of Kubenet and providing higher node scalability.
All the above-mentioned concepts are more clearly shown with the help of a live Demo.