Carlos Mendible

Some months ago a customer asked me if there was a way to deploy a Windows node pool with spot virtual machines and ephemeral disks in Azure Kubernetes Service (AKS). The idea was to create a cluster that could be used to run Windows batch workloads and minimize costs by deploying the following:

This post will show you the steps you’ll have to take to deploy an Azure Files Storage with a Private Endpoint and use it to create volumes for an Azure Kubernetes Service cluster: Create a bicep file to declare the Azure resources # You’ll have to declare the following resources:

When configuring Azure Kubernetes Service with Azure Container Network Interface (CNI), every pod gets an IP address of the subnet you’ve configured. So how do you plan you address space? What factors should you consider? Each node consumes one IP. Each pod consumes one IP. Each internal LoadBalancer Service you anticipate consumes one IP. Azure reserves 5 IP addresses within each subnet. The Max pods per node is 250. The Max pods per nodes lower limit is 10. 30 pods is the minimum per cluster. Max nodes per cluster is 1000. When a cluster is upgraded a new node is added as part of the process which requires a minimum of one additional block of IP addresses to be available. Your node count is then n + 1. When you scale a cluster an additional node is added. Your node count is then n + number-of-additional-scaled-nodes-you-anticipate + 1. With all that in mind the formula to calculate the number of IPs required for your cluster should look like this:

Microservices architectures are inherently distributed and building such solutions always bring interesting challenges to the table: resilient service invocation, distributed transactions, on-demand scaling, idempotent message processing and more. Deploying Microservices on Kubernetes doesn’t solve these problems and Developers need to learn and use SDK’s on top of frameworks such as .NET, while building distributed Microservices architectures.

Microservices architectures are inherently distributed and building such solutions always bring interesting challenges to the table: resilient service invocation, distributed transactions, on-demand scaling, idempotent message processing and more. Deploying Microservices on Kubernetes doesn’t solve these problems and Developers need to learn and use SDK’s on top of frameworks such as .NET, while building distributed Microservices architectures.

I’m a proud owner of a Surafe Pro X SQ2 which is an ARM64 device. If you’ve been reading me, you know I like to tinker with kubernetes and therefore I needed a solution for this device. I remembered reading about k3s a lightweight kubernetes distro built for IoT & Edge computing, and decided to give it a try.