AKS architecture review

- [Instructor] I am excited we are done defining the manifests for our microservices and related infrastructure. Let's explore the Azure Kubernetes architecture for our containers and various related resources we have to configure. There is a site you can check out to review some architectural diagrams and adapt one to the application you wish to deploy to Azure Kubernetes service. The site address is displayed on the screen and it has several AKS related architectures if you filter by choosing containers on the categories. So just review what would work best for your use case and adapt it to your microservices design. One of the architectures, the advanced AKS architecture, has two isolated virtual networks paired in a hub-spoke network topology. In the hub virtual network, Azure Firewall and Bastion subnets are deployed. And this would act as an entry network to resources in the spoke network. For example, an administrator that wishes to connect remotely to the AKS cluster from an on-premise network and the firewall that would inspect egress traffic from the spoke network to other resources like external databases, service bus, et cetera. So if you would like an advanced setup, you can review this baseline. In this course, we would not deploy hub-spoke topology with firewalls and external databases. Instead, we would adapt to basic architecture with a single virtual network for the AKS and an application gateway to route traffic based on the URI path defined in an ingress resource. We would also configure Cert-manager and Let's Encrypt to automatically obtain a TLS certificate for our postop application. If you have purchased the domain name and want to acquire certificates for your custom domain, you can integrate Azure DNS in your setup and configure Cert-manager to automatically issue custom domain SSL certificates. Notice that an application gateway instead of a layer four load balancer is used in our set up for ingress traffic. Azure Application Gateway is a layer seven load balancer and provides an optional web application firewall feature that when enabled inspects and blocks malicious traffic to your cluster. Combine these features with Application Gateway Ingress Controller, and all you have to do for new services in the cluster is define an ingress to expose and direct HTTP or HTTPS traffic to that service. There are quite a number of features in Azure Application Gateway that will be useful with your Azure Kubernetes service so check out the docs to learn more. But some of the benefits of using an app gateway are, it eliminates the need for multiple load balancers per service that's defined as a load balancer kind, all your services can be deployed with cluster IP setup and linked to the ingress controller. You now have better control over your network design. Application Gateway has auto scaling capabilities, allowing it to spin up more instances depending on the traffic requirements and this happens outside of the cluster, effectively allowing better performance of your cluster without tying down cluster resources. And lastly, the Application Gateway is a layer seven load balancer that can route traffic based on the URI path for multiple microservices hosted in the cluster. And the best of it, it implements TLS termination for your microservices. One thing to note when planning to use Application Gateway is that you have to deploy your Kubernetes cluster with advanced networking configured because the Application Gateway would be deployed in a separate subnet of this virtual network and basic Kubernetes networking does not support Application Gateway integration.