Table of Contents
Azure Kubernetes Service (AKS) is Microsoft’s managed container orchestration service, built on the open-source Kubernetes system, which is available on the Azure public cloud. An AKS cluster consists of at least one master and multiple worker nodes that host containerized applications. Configuring network connections for an AKS cluster involves creating, managing, and maintaining communication within the cluster as well as with the external network. The key networking components to configure include the cluster networking model, services, ingress, Network Policies, and Azure networking resources.
There are two primary networking models available in AKS:
When creating an AKS cluster, the network model must be chosen. The following example illustrates creating an AKS cluster with Azure CNI networking:
az aks create \
–resource-group myResourceGroup \
–name myAKSCluster \
–network-plugin azure \
–vnet-subnet-id /subscriptions/<subscription-id>/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVnet/subnets/mySubnet \
–service-cidr 10.0.0.0/16 \
–dns-service-ip 10.0.0.10 \
–pod-cidr 10.244.0.0/16 \
–docker-bridge-address 172.17.0.1/16
Services in AKS expose your application to the network. Service types in AKS include:
Ingress controllers are used to route external HTTP/S traffic to services. To configure ingress, an ingress controller like NGINX or Traefik needs to be deployed. Below is an example of deploying the NGINX ingress controller:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.41.0/deploy/static/provider/cloud/deploy.yaml
Network policies in AKS enable filtering and controlling network traffic within the cluster. Azure provides its native implementation of network policy using Azure Network Policy Manager. To use Azure network policies, the AKS cluster must be configured with Azure CNI networking and the network policy parameter should be set to ‘azure’.
Example command to enable Azure network policies during AKS creation:
az aks create \
–resource-group myResourceGroup \
–name myAKSCluster \
–network-plugin azure \
–network-policy azure \
# Other necessary flags
AKS can integrate with several Azure networking resources:
Feature | Kubenet | Azure CNI |
---|---|---|
IP Assignment | Pod IP assigned from node CIDR | Pod gets own IP from VNet |
Network Policies | Third-party tools required | Native support |
Integration with VNet | Basic | Advanced, pods are first-class VNet citizens |
VNet Peering | Supported | Supported |
Load Balancer Services | Available | Available |
Performance | May have lower performance overhead | Better network performance |
Address Space Planning | Less planning needed | Requires more careful IP management |
In summary, setting up network connections for an AKS cluster involves several aspects ranging from choosing the correct networking model to integrating with Azure-specific networking resources and configuring ingress and network policies. Proper planning and configuration ensure that the applications running on AKS are secure, efficient, and able to communicate as needed within the cluster and with external services.
AKS supports both Azure CNI and Kubenet as networking plugins. Azure CNI provides a more integrated experience with Azure networking resources, while Kubenet is a simpler, more basic networking plugin.
AKS requires a dedicated subnet within an Azure Virtual Network (VNet) to ensure that networking resources such as IP addresses are properly isolated and managed.
With Azure CNI, each pod gets an IP address from the subnet and can be directly accessed from the VNet.
Answer: A, B, C, D
Azure CNI allows for all listed networking features, enabling advanced scenarios such as VNet peering, enforcing network policies, enabling pod-to-pod communication across nodes, and using service endpoints for securing Azure service resources.
The network plugin and configuration cannot be changed after the AKS cluster has been created; you have to choose the correct network model and design before deployment.
Answer: A
Azure Role-Based Access Control (RBAC) needs to be configured to integrate Azure Active Directory with AKS for user and group authentication.
Network policies in AKS can be applied to control both ingress (incoming) and egress (outgoing) traffic at the pod level to enforce security and communication requirements.
Answer: C
Azure Service Endpoints provide secure access to Azure services from AKS by extending your VNet identity to the Azure service.
Network Security Groups (NSGs) can be associated with the subnet used by an AKS cluster to control inbound and outbound traffic at the network interface (NIC), VM, and subnet level.
Resizing the subnet might require redeploying or reconfiguring networking resources, which could cause downtime. It is generally recommended to plan your subnet size carefully before creating the AKS cluster.
Answer: B, C
To expose an AKS service to the internet, you can create a Service with type LoadBalancer which automatically provisions an Azure Load Balancer or set up an Ingress Controller for more advanced routing and TLS termination.
Additional configurations are necessary for an AKS cluster deployed with Kubenet to work with Azure Application Gateway, as it requires configuring an Ingress Controller that supports Application Gateway, like the Application Gateway Ingress Controller (AGIC).
A virtual network is a logically isolated network within the Azure cloud that you can use to deploy your AKS cluster.
A subnet is a range of IP addresses within a virtual network that you can use to deploy your AKS cluster.
NSGs are a set of firewall rules that control inbound and outbound network traffic for your AKS cluster.
You can use the Azure portal, Azure CLI, or Azure PowerShell to create a virtual network for your AKS cluster.
You can use the Azure portal, Azure CLI, or Azure PowerShell to create a subnet within a virtual network for your AKS cluster.
Azure CNI is the recommended networking model for AKS because it provides a more efficient and scalable networking solution than the kubenet networking model.
You can use NSGs to limit access to your AKS cluster and reduce the risk of attacks by controlling inbound and outbound network traffic.
Using private IP addresses within your virtual network is more secure than using public IP addresses because it reduces the surface area of attack for your AKS cluster.
You can use the Azure portal, Azure CLI, or Azure PowerShell to create and configure load balancers in AKS.
Best practices for configuring network connections in AKS include using Azure CNI, using private IP addresses, and using NSGs to control traffic.
If this material is helpful, please leave a comment and support us to continue.