About Me

My photo
I am an MCSE in Data Management and Analytics, specializing in MS SQL Server, and an MCP in Azure. With over 19+ years of experience in the IT industry, I bring expertise in data management, Azure Cloud, Data Center Migration, Infrastructure Architecture planning, as well as Virtualization and automation. I have a deep passion for driving innovation through infrastructure automation, particularly using Terraform for efficient provisioning. If you're looking for guidance on automating your infrastructure or have questions about Azure, SQL Server, or cloud migration, feel free to reach out. I often write to capture my own experiences and insights for future reference, but I hope that sharing these experiences through my blog will help others on their journey as well. Thank you for reading!

Service of type LoadBalancer IP Address will change after AKS Upgrade(yes/no)

Introduction:

When working with Azure Kubernetes Service (AKS), one of the concerns for developers and DevOps engineers is whether the Load Balancer IP Address assigned to services will change during an AKS cluster upgrade. In this guide, we’ll walk through the key concepts related to load balancers in AKS, discuss the persistence of IP addresses across cluster upgrades, and provide a demo that demonstrates how the IP address remains unchanged during an AKS upgrade.

By the end of this guide, you will understand how AKS Load Balancers behave during upgrades and gain confidence in upgrading your clusters without losing external IP configurations.


Table of Contents:

  1. Key Concepts in AKS Load Balancers
    • Types of Services in AKS
    • Load Balancer and External IP Assignment
    • AKS Cluster Upgrades
  2. Step-by-Step Demo: Load Balancer IP Persistence During AKS Upgrade
    • Checking Existing Services and IPs
    • Upgrading AKS Cluster
    • Verifying Load Balancer IP Addresses Post-Upgrade
  3. Memory Techniques for Key Concepts
    • Mnemonics for Load Balancer IP Address Persistence
    • Story-based Learning for AKS Upgrades
  4. Use Case: Ensuring IP Stability During Cluster Upgrades in Production
  5. Conclusion

1. Key Concepts in AKS Load Balancers

Before we dive into the demo, it’s crucial to understand some key concepts related to AKS (Azure Kubernetes Service) and Load Balancers:

Types of Services in AKS:

In Kubernetes, services expose applications running on a set of pods. One common service type is a LoadBalancer, which provides a stable external IP address that can be accessed from outside the Kubernetes cluster.

  • ClusterIP: Internal IP accessible only within the cluster.
  • NodePort: Exposes the service on each node’s IP at a static port.
  • LoadBalancer: Exposes the service externally using a cloud provider’s load balancer (in this case, Azure).

Load Balancer and External IP Assignment:

When a LoadBalancer service is created, AKS provisions an Azure Load Balancer that assigns an external IP address. This IP address typically remains stable as long as the service is not deleted.

AKS Cluster Upgrades:

Upgrading an AKS cluster involves updating the Kubernetes version without affecting the existing running services. One concern during upgrades is whether the LoadBalancer IP address will change. The good news is that the IP address remains the same, ensuring continuity in production environments.


2. Step-by-Step Demo: Load Balancer IP Persistence During AKS Upgrade

Let’s walk through a real-world demo where we’ll upgrade an AKS cluster and verify that the Load Balancer IP addresses remain unchanged.

Step 1: Check Existing Services and IP Addresses

First, list the services in your namespace (in this case, rak) to see the LoadBalancer type services and their external IPs.

bash

kubectl get services -n rak

Example output:

bash

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE webserver-service LoadBalancer 10.0.217.211 20.242.248.124 80:30326/TCP 34m webserver-service--persist LoadBalancer 10.0.202.73 20.120.120.54 80:30085/TCP 21m

Here, we have two services (webserver-service and webserver-service--persist) with their external IPs assigned by the Azure Load Balancer.

Step 2: Check the Current AKS Kubernetes Version

Now, we will check the current version of the Kubernetes cluster.

bash

az aks show --resource-group RGP-USE-AKS-DV --name AKS-USE-AKS-DEV --query "kubernetesVersion" --output table

Output:

bash

-------- 1.24.9

The current Kubernetes version is 1.24.9.

Step 3: Upgrade the AKS Cluster

Next, we will upgrade the AKS cluster to a newer version (in this case, 1.25.5).

bash

az aks upgrade --resource-group RGP-USE-AKS-DV --name AKS-USE-AKS-DEV --kubernetes-version 1.25.5

This command initiates the cluster upgrade. Depending on the size of your cluster, this may take some time.

Step 4: Verify the AKS Kubernetes Version After the Upgrade

Once the upgrade is complete, verify the Kubernetes version again to ensure the upgrade was successful.

bash

az aks show --resource-group RGP-USE-AKS-DV --name AKS-USE-AKS-DEV --query "kubernetesVersion" --output table

Output:

bash

-------- 1.25.5

The version has successfully been upgraded to 1.25.5.

Step 5: Recheck the Services and Load Balancer IP Addresses

Finally, check the services again to verify that the LoadBalancer IP addresses remain unchanged.

bash

kubectl get services -n rak

Output:

bash

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE webserver-service LoadBalancer 10.0.217.211 20.242.248.124 80:30326/TCP 60m webserver-service--persist LoadBalancer 10.0.202.73 20.120.120.54 80:30085/TCP 47m

As you can see, the external IPs (20.242.248.124 and 20.120.120.54) remain unchanged after the upgrade.


3. Memory Techniques for Key Concepts

Mnemonic for Load Balancer IP Address Persistence:

To help remember the behavior of Load Balancers during AKS upgrades, use the mnemonic “L-I-P”:

  • L: LoadBalancer service type
  • I: IP address persistence
  • P: Persists during upgrades

Story-based Learning for AKS Upgrades:

Imagine you’re running an e-commerce platform, and you have multiple web servers exposed to customers via external IP addresses. During a busy sales period, you need to upgrade your cluster to a newer Kubernetes version to take advantage of security patches. You’re concerned about downtime and losing the IP addresses that your customers are using to connect. Fortunately, after the upgrade, you check your services and see that your external IPs are exactly the same. Business continues as usual, without any disruption.


4. Use Case: Ensuring IP Stability During Cluster Upgrades in Production

Scenario:

Your organization runs a production application with multiple external-facing services. Each service is tied to a LoadBalancer IP address, which customers use to access the application. You need to upgrade the Kubernetes version of your AKS cluster to improve performance and apply security patches.

Solution:

By upgrading the AKS cluster using the method shown above, you ensure that the external IP addresses tied to your services remain unchanged. This allows for seamless upgrades without requiring changes to DNS records or client configurations, minimizing downtime and disruption.

Command Example for Use Case:

bash

az aks upgrade --resource-group Prod-RG --name Prod-AKS-Cluster --kubernetes-version 1.25.5

This command upgrades the AKS cluster without affecting the LoadBalancer IP addresses, ensuring stable external access to the services during and after the upgrade.


5. Conclusion

Upgrading an AKS cluster can be daunting, especially when you’re concerned about the stability of your services’ external IP addresses. However, as demonstrated in this guide, the LoadBalancer IP addresses assigned to your services remain unchanged during AKS cluster upgrades, ensuring continuity for your applications.

With the confidence that your IPs won’t change, you can focus on upgrading your cluster to the latest Kubernetes version without worrying about reconfiguring external connections or impacting users.

By following the practical steps and Azure CLI commands provided, you can upgrade your AKS cluster smoothly and maintain external access for all your services.

No comments: