The trend in adopting applications based on microservices requires the use of state-of-the-art solutions capable of managing a large number of containers and the ways in which these interact in application with each other, as Azure Kubernetes Service (AKS). As part of the design of Azure Kubernetes Service architectures (AKS) there are several elements that need to be evaluated to obtain an appropriate network topology that can ensure maximum efficiency and security. This article outlines the main points to consider, accompanied by some proposals, to make informed choices when designing network architectures for AKS.
What is Azure Kubernetes Service (AKS)?
Azure Kubernetes Service (AKS) is the fully managed Azure service that allows the activation of a Kubernetes cluster, ideal for simplifying the deployment and management of microservices-based architectures. Thanks to the features offered by AKS it is possible to scale automatically according to the use, use controls to ensure the integrity of the services, implement load balancing policies and manage secrets. In microservices-based architectures, it is also common to adopt the Azure Container Registry that allows you to create, store and manage container images and artifacts in a private registry. The use of this managed service is integrated with the container development and deployment pipelines.
Figure 1 - Azure Kubernetes Service architecture example (AKS)
The network topology
In the network architecture of type Hub and Spoke, theHub is a virtual network on Azure that serves as the point of connectivity to the on-premises network. This connectivity can be done through VPN Site to site or through ExpressRoute. TheSpoke are virtual networks running the peering with the Hub and can be used to isolate workloads.
Figure 2 - Hub and Spoke network topology
This network topology is also recommended for AKS architectures as it can offer several advantages, including:
- Environmental segregation to more easily enforce governance policies and gain greater control. This topology also supports the concept of "landing zones" by contemplating the separation of duties.
- Minimizing the direct exposure of Azure resources to the public network (Internet).
- Possibility of contemplating workloads attested on different Azure subscriptions, becoming a natural choice in these scenarios.
- Ability to easily extend the architecture to accommodate new features or new workloads, simply by adding additional spoke virtual networks.
- Ability to centralize Azure services shared by multiple workloads in a single location (attested on different VNet), such as DNS servers and any virtual network appliances. It also reduces the VPN Gateways to provide connectivity to the on-premises environment, resulting in savings on Azure costs and simplification of the architecture.
Figure 3 - Hub and Spoke network topology for AKS
Hub Virtual Network
In the Hub network it is possible to evaluate the adoption of the following services:
- VPN or ExpressRoute Gateway: necessary to provide connectivity to the on-premises environment.
- Firewall Solutions, necessary in case you want to control the traffic from your AKS environment, as pods or cluster nodes, outgoing to external services. In this context, the choice can fall between:
- Azure Firewall, the firewall-as-a-service solution (FWaaS) which allows to secure the resources present in the Virtual Networks and to govern the related network flows.
- Network Virtual Appliances (NVA's) provided by third party vendors. Such solutions are numerous and can offer advanced functionality, but typically the configuration of these solutions is more complex and the cost tends to be higher than the solution provided by the Azure platform. A comparison between the new Azure Firewall and third-party virtual appliances can be found in this article.
- Azure Bastion, the PaaS service that offers secure and reliable RDP and SSH access to virtual machines, directly through the Azure portal.
Spoke Virtual Network
The AKS cluster is placed in the Spoke network together with other resources closely related to its operation. Spoke VNet is split into different subnets to accommodate the following components:
- The two groups of nodes (node pools) in AKS:
-
- AKS System Node pool: the pool of system nodes that host the pods needed to run the core services of the cluster.
- AKS User Node pool: the pool of user nodes that run the application workloads and the ingress controller.
For multi-tenant application environments or for workloads with advanced needs, it may be necessary to implement isolation mechanisms of node pools that require the presence of different subnets.
- AKS Internal Load Balancer: the balancer to route and distribute inbound traffic for Kubernetes resources. In this case the component is used Azure Load Balancer, which enables Layer-4 load balancing for all TCP and UDP protocols, ensuring high performance and very low latencies.
- Azure Application Gateway: it is a service managed by the azure platform, with inherent features of high availability and scalability. The Application Gateway is a application load balancer (OSI layer 7) for web traffic, that allows you to govern HTTP and HTTPS applications traffic (URL path, host based, round robin, session affinity, redirection). The Application Gateway is able to centrally manage certificates for application publishing, using SSL and SSL offload policy when necessary. The Application Gateway may have assigned a private IP address or a public IP address, if the application must be republished in Internet. In particular in the latter case, it is recommended to turn onWeb Application Firewall (WAF), that provides application protection, based on rulesOWASP core rule sets. The WAF protects the application from vulnerabilities and against common attacks, such as X-Site Scripting and SQL Injection attacks.
Thanks to the adoption of Azure Private Link you can bring Azure services to a virtual network and map them with a private endpoint. In this way, all traffic is routed through the private endpoint, keeping it on the Microsoft global network. The data does not pass ever on the Internet, this reduces exposure to threats and helps to meet the compliance standards.
Figure 4 - Overview of Azure Private Link
In AKS environments theAzure Private Link they are usually created in the Spoke virtual network subnets for Azure Container Registry and Azure KeyVault.
Below is a diagram with the incoming and outgoing network flows for an AKS environment, which also includes the presence of Azure Firewall to control outgoing traffic.
Figure 5 - Example of network flows in a typical AKS architecture
Management traffic
In order to allow the management of the environment, such as creating new resources or carrying out activities to scale the cluster environment, it is advisable to provide access to the Kubernetes API. Good practice is apply network filters to authorize this access in a timely manner.
Private AKS cluster
In case you want to implement a totally private AKS environment, where no Internet service is exposed, it is possible to adopt a AKS cluster in "private" mode.
Conclusions
The increasing demand for microservices-based application architectures that useAzure Kubernetes Service (AKS) requires you to locate and build network architectures designed to be secure, flexible and with a high level of integration. All this must take place through a modern approach able to fully exploit the potential offered in the field of networking by Azure.
