Concepts – Networking in Azure Kubernetes Services (AKS)

December 15, 2018 admin Networking 0







  • 10/16/2018


  • 6 minutes to read


  • Contributors

    • Iain Foulds




In this article






In a container-based microservices approach to application development, application components must work together to process their tasks. Kubernetes provides various resources that enable this application communication. You can connect to and expose applications internally or externally. To build highly available applications, you can load balance your applications. More complex applications may require configuration of ingress traffic for SSL/TLS termination or routing of multiple components. For security reasons, you may also need to restrict the flow of network traffic into or between pods and nodes.

This article introduces the core concepts that provide networking to your applications in AKS:

Kubernetes basics

To allow access to your applications, or for application components to communicate with each other, Kubernetes provides an abstraction layer to virtual networking. Kubernetes nodes are connected to a virtual network, and can provide inbound and outbound connectivity for pods. The kube-proxy component runs on each node to provide these network features.

In Kubernetes, Services logically group pods to allow for direct access via an IP address or DNS name and on a specific port. You can also distribute traffic using a load balancer. More complex routing of application traffic can also be achieved with Ingress Controllers. Security and filtering of the network traffic for pods is possible with Kubernetes network policies.

The Azure platform also helps to simplify virtual networking for AKS clusters. When you create a Kubernetes load balancer, the underlying Azure load balancer resource is created and configured. As you open network ports to pods, the corresponding Azure network security group rules are configured. For HTTP application routing, Azure can also configure external DNS as new ingress routes are configured.

Services

To simplify the network configuration for application workloads, Kubernetes uses Services to logically group a set of pods together and provide network connectivity. The following Service types are available:

  • Cluster IP – Creates an internal IP address for use within the AKS cluster. Good for internal-only applications that support other workloads within the cluster.

    Diagram showing Cluster IP traffic flow in an AKS cluster

  • NodePort – Creates a port mapping on the underlying node that allows the application to be accessed directly with the node IP address and port.

    Diagram showing NodePort traffic flow in an AKS cluster

  • LoadBalancer – Creates an Azure load balancer resource, configures an external IP address, and connects the requested pods to the load balancer backend pool. To allow customers traffic to reach the application, load balancing rules are created on the desired ports.

    Diagram showing Load Balancer traffic flow in an AKS cluster

    For additional control and routing of the inbound traffic, you may instead use an Ingress controller.

  • ExternalName – Creates a specific DNS entry for easier application access.

The IP address for load balancers and services can be dynamically assigned, or you can specify an existing static IP address to use. Both internal and external static IP addresses can be assigned. This existing static IP address is often tied to a DNS entry.

Both internal and external load balancers can be created. Internal load balancers are only assigned a private IP address, so can’t be accessed from the Internet.

Azure virtual networks

In AKS, you can deploy a cluster that uses one of the following two network models:

  • Basic networking – The network resources are created and configured as the AKS cluster is deployed.
  • Advanced networking – The AKS cluster is connected to existing virtual network resources and configurations.

Basic networking

The basic networking option is the default configuration for AKS cluster creation. The Azure platform manages the network configuration of the cluster and pods. Basic networking is appropriate for deployments that do not require custom virtual network configuration. With basic networking, you can’t define network configuration such as subnet names or the IP address ranges assigned to the AKS cluster.

Nodes in an AKS cluster configured for basic networking use the kubenet Kubernetes plugin.

Basic networking provides the following features:

  • Expose a Kubernetes service externally or internally through the Azure Load Balancer.
  • Pods can access resources on the public Internet.

Advanced networking

Advanced networking places your pods in an Azure virtual network that you configure. This virtual network provides automatic connectivity to other Azure resources and integration with a rich set of capabilities. Advanced networking is appropriate for deployments that require specific virtual network configurations, such as to use an existing subnet and connectivity. With advanced networking, you can define these subnet names and IP address ranges.

Nodes in an AKS cluster configured for advanced networking use the Azure Container Networking Interface (CNI) Kubernetes plugin.

Diagram showing two nodes with bridges connecting each to a single Azure VNet

Advanced networking provides the following features over basic networking:

  • Deploy your AKS cluster into an existing Azure virtual network, or create a new virtual network and subnet for your cluster.
  • Every pod in the cluster is assigned an IP address in the virtual network. The pods can directly communicate with other pods in the cluster, and other nodes in the virtual network.
  • A pod can connect to other services in a peered virtual network, including to on-premises networks over ExpressRoute and site-to-site (S2S) VPN connections. Pods are also reachable from on-premises.
  • Pods in a subnet that have service endpoints enabled can securely connect to Azure services, such as Azure Storage and SQL DB.
  • You can create user-defined routes (UDR) to route traffic from pods to a Network Virtual Appliance.

For more information, see Configure advanced network for an AKS cluster.

Ingress controllers

When you create a LoadBalancer type Service, an underlying Azure load balancer resource is created. The load balancer is configured to distribute traffic to the pods in your Service on a given port. The LoadBalancer only works at layer 4 – the Service is unaware of the actual applications, and can’t make any additional routing considerations.

Ingress controllers work at layer 7, and can use more intelligent rules to distribute application traffic. A common use of an Ingress controller is to route HTTP traffic to different applications based on the inbound URL.

Diagram showing Ingress traffic flow in an AKS cluster

In AKS, you can create an Ingress resource using something like NGINX, or use the AKS HTTP application routing feature. When you enable HTTP application routing for an AKS cluster, the Azure platform creates the Ingress controller and an External-DNS controller. As new Ingress resources are created in Kubernetes, the required DNS A records are created in a cluster-specific DNS zone. For more information, see deploy HTTP application routing.

Another common feature of Ingress is SSL/TLS termination. On large web applications accessed via HTTPS, the TLS termination can be handled by the Ingress resource rather than within the application itself. To provide automatic TLS certification generation and configuration, you can configure the Ingress resource to use providers such as Let’s Encrypt. For more information on configuring an NGINX Ingress controller with Let’s Encrypt, see Ingress and TLS.

Network security groups

A network security group filter traffic for VMs, such as the AKS nodes. As you create Services, such as a LoadBalancer, the Azure platform automatically configures any network security group rules that are needed. Don’t manually configure network security group rules to filter traffic for pods in an AKS cluster. Define any required ports and forwarding as part of your Kubernetes Service manifests, and let the Azure platform create or update the appropriate rules.

Default network security group rules exist for traffic such as SSH. These default rules are for cluster management and troubleshooting access. Deleting these default rules can cause problems with AKS management, and breaks the service level objective (SLO).

Next steps

To get started with AKS networking, see Create and configure advanced networking for an AKS cluster.

For additional information on core Kubernetes and AKS concepts, see the following articles:





Source

Be the first to comment

Leave a Reply

Your email address will not be published.


*