Advanced Kubernetes/AKS Network & Infrastructure

Review the AKS architecture, from the managed control plane and its API server to worker nodes, node pools, and application pods. Trace management and application traffic, distinguish managed-identity responsibilities, and connect networking choices and availability zones to the platform design.

Follow creation of an AKS cluster in the Azure portal and review the configuration choices presented during provisioning. Identify settings for nodes, networking, access, and availability, and understand that Azure CLI exposes additional configuration options beyond the portal walkthrough.

Inspect the Azure resources created with the sample AKS cluster, including its managed node resource group, virtual machine scale set, networking, load balancer, and public addresses. Relate those resources to the cluster's node pools and examine individual node properties in the portal.

Create a sample NGINX pod and inspect its status, assigned node, and IP address using kubectl. Review the existing namespaces and system workloads so you can distinguish the application pod from the components already supporting the cluster.

Create a Deployment for the sample application and examine its relationship with ReplicaSets and pods. Inspect the generated replicas and their placement to understand how a controller-managed workload differs from creating a single standalone pod.

Open an interactive shell in a running container using kubectl exec and inspect its environment. Make an HTTP request from that container to another pod to explore the demonstrated in-cluster connectivity and distinguish container-side commands from commands run on your own machine.

Scale the sample Deployment up and down, then inspect the resulting replica counts, pod addresses, and node assignments. Distinguish changing the number of application replicas from changing the cluster's worker-node capacity.

Expose the sample Deployment through an internal ClusterIP Service rather than addressing individual pods directly. Test the Service from another pod and see how its name and endpoint let clients reach the application as backend pods change.

Change the sample Service to type LoadBalancer and observe the external IP allocated alongside its ClusterIP. Open the application through that public address and connect the Kubernetes Service configuration to the Azure load balancer entry point.

Explore the sample pods, Deployments, and Services through the AKS views in the Azure portal, including namespace filtering. Trace the public Service address to the managed resource group's public IP and load balancer frontend configuration.

Compare the control-plane access models introduced in this section: public and private clusters, with private endpoints or API server virtual-network integration. Focus on how operators and worker nodes reach the Kubernetes API, separately from how end users reach application workloads.

Trace the recorded public-cluster API access pattern for administrators, deployment tools, and worker nodes. Review authorized IP ranges and inspect the Azure infrastructure associated with the cluster, keeping management-endpoint exposure distinct from application Service exposure.

Examine how a private endpoint provides a private network path to the Kubernetes API server. Connect the endpoint, private IP, DNS names, and private DNS zone to the access requirements of worker nodes and administrators using a connected network.

Explore the public-cluster variant of API server virtual-network integration. See how an internal load balancer and delegated subnet provide a private node-to-control-plane path while the configuration retains a public API access option for administrators and deployment tools.

Examine API server virtual-network integration with private cluster access. Trace the internal load balancer, delegated subnet, and private DNS configuration, and understand why administrators and pipelines need an appropriate network and name-resolution path to the private API endpoint.

Compare the administration and deployment access options discussed for private AKS clusters, including command invocation and network-connected administration hosts. Consider which path fits troubleshooting, operator access, or CI/CD, and why private endpoint reachability and DNS resolution must be planned together.

Consolidate the differences between public and private clusters and their API server virtual-network integration variants. Use the comparison to relate endpoint exposure, public and private DNS names, private endpoints, delegated subnets, and the access paths needed by operators and nodes.

Explore the network-isolated AKS approach and how it differs from simply making the API server private. Review outbound traffic restrictions and the role of a private container registry and artifact caching in supplying the cluster's required images.

Follow the recorded setup of a network-isolated AKS cluster and its private registry access and artifact-cache configuration. Compare a direct public image pull with an image obtained through the configured registry path, and inspect pod status to validate the demonstrated result.

Trace the access path from an operator through Azure Bastion to a jump-box virtual machine and then to a private AKS API endpoint. Understand the separate roles of Bastion, the administration host, private network connectivity, and name resolution in this architecture.

Follow the Terraform-based creation of the private AKS cluster, virtual network, jump box, and Bastion resources used in the lab. Walk through the demonstrated portal and command-line connections to the VM, then validate cluster administration from that network-connected host.

Extend the Bastion and jump-box access pattern to a hub-and-spoke network, with Bastion and AKS in different connected virtual networks. Review VNet peering and the private DNS-zone links needed so the administration path can resolve the private cluster's API name.

Discover how networking plugins determine pod connectivity and IP address assignment in AKS. This introduction outlines the section's recorded examples of kubenet, Azure CNI, Azure CNI Overlay, and bring-your-own plugins before the detailed comparisons.

Explore the recorded kubenet configuration, where nodes use subnet addresses while pods receive addresses from a separate pod CIDR. Inspect node, pod, and service addresses alongside the cluster's route table to understand address translation and how this networking model conserves subnet address space.

Examine the flat Azure CNI configuration demonstrated in the recording, where both nodes and pods draw addresses from the virtual network subnet. Follow the creation parameters and inspect resource and IP assignments to understand why pod capacity requires subnet planning, while service addresses remain in a separate service CIDR.

Use the lecture's subnet-sizing exercise to compare address consumption in the recorded kubenet and flat Azure CNI configurations. Focus on where node and pod addresses come from, then consider available address space, communication patterns, and feature requirements when evaluating the two designs.

Explore how an overlay separates pod addressing from the subnet addresses used by AKS nodes. Follow the Azure CNI Overlay creation parameters and inspect node, pod, and service addresses, including the cluster's JSON configuration, to see how the demonstrated setup reduces demand on subnet address space.

Compare the recorded kubenet and Azure CNI Overlay designs, focusing on route-table dependencies and pod-networking configuration. Review the policy and node-platform considerations discussed in the lecture to understand the architectural differences beyond their shared use of separate pod address space.

Get a brief introduction to bringing your own networking plugin rather than selecting one of the preceding AKS networking configurations. Explore Cilium as an example, including its open-source and enterprise offerings, and recognize CNI as an interface implemented by multiple networking projects.

Plan distinct address ranges for the cluster subnet, pods, and services, including the Docker bridge range discussed in the recording. Examine how overlap with connected virtual networks or on-premises networks can cause connectivity problems and why address planning matters before cluster creation.

In this lightboard walkthrough, compare the public-FQDN and private-DNS-zone settings used when creating a private AKS cluster. Examine system-managed and bring-your-own zones, network links, and identity permissions, while distinguishing DNS name resolution from network access to the private control plane.

Compare public-FQDN resolution, a shared private DNS zone, and separate private zones for individual AKS clusters. Identify how worker nodes, jump boxes, and deployment pipelines resolve the private control plane, then weigh DNS ownership and cluster-identity permissions in a hub-and-spoke design.

Lab files are available here: https://github.com/HoussemDellai/docker-kubernetes-course/tree/main/201_private_aks_no_private_dns_zone

Follow a demonstration of multiple private AKS clusters using a shared private DNS zone in a hub-and-spoke network. Inspect network links, A records, and activity logs to understand how each cluster's managed identity updates the shared zone and what that means for central DNS ownership.

Explore a Terraform-based setup where each spoke owns its AKS cluster and private DNS zone. Follow the zone links to the spoke and hub networks, inspect the control-plane records, and observe access from a hub virtual machine to understand how decentralized DNS supports shared administrative connectivity.

Trace how ExternalDNS watches Kubernetes services and ingress resources to synchronize their domain names with Azure DNS. This lightboard explanation contrasts manual record maintenance with automated updates and shows how the controller's access to Kubernetes resources and Azure DNS enables that workflow.

Use the slide-based walkthrough to connect Kubernetes service and ingress configuration with the DNS records managed by ExternalDNS. Examine how hostname changes and changing public IP addresses drive synchronization, and recognize the A and TXT records shown in the Azure DNS example.

Follow the installation of ExternalDNS with the Azure access configuration and Kubernetes permissions used in the recording. Expose a sample application through a LoadBalancer service and an NGINX ingress example, then inspect controller output and Azure DNS records to see how custom hostnames become usable.

Explore CoreDNS as Kubernetes' service-discovery component and identify its pods, service, and configuration maps. Learn how a custom rewrite rule can resolve an alternative internal domain name to the same service address as the standard Kubernetes name, without creating a public DNS record.

Follow a demonstration of adding rewrite rules through the CoreDNS custom ConfigMap and reloading the DNS pods. Test alternative service names from a sample pod, then compare namespace-qualified names with a shorter alias to understand how the rewrite configuration shapes internal name resolution.

Enable the CoreDNS log plugin through a custom ConfigMap, restart the deployment, and compare query logs before and after the change. Follow nslookup requests from a sample pod and inspect the search-domain attempts to understand the DNS queries behind a single lookup.