Introduction

In AKS, an internal load balancer is the standard way to expose services privately inside a virtual network. Assigning a static private IP keeps DNS records, firewall rules, and dependent systems stable across service updates. The setup requires correct subnet planning, service annotations, and permission checks for the AKS managed identity.

Prerequisites

Before creating the service:

• AKS cluster running in the target virtual network.
• A subnet with available private IP addresses.
• Permission for AKS identity to manage load balancer resources.
• kubectl connected to the correct cluster context.

Validate cluster access:

kubectl get nodes

Validate subnet information in Azure:

1az network vnet subnet show \
2  --resource-group rg-network \
3  --vnet-name vnet-app \
4  --name aks-subnet

Kubernetes Service Manifest

Create a service of type LoadBalancer with internal load balancer annotation and static IP.

1apiVersion: v1
2kind: Service
3metadata:
4  name: api-internal
5  namespace: apps
6  annotations:
7    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
8    service.beta.kubernetes.io/azure-load-balancer-internal-subnet: "aks-subnet"
9spec:
10  type: LoadBalancer
11  loadBalancerIP: 10.20.2.50
12  selector:
13    app: api
14  ports:
15    - name: http
16      protocol: TCP
17      port: 80
18      targetPort: 8080

Apply it:

kubectl apply -f service-internal.yaml

This requests a private frontend IP on the specified subnet.

Verify Provisioning

Check service status and assigned IP.

kubectl get svc api-internal -n apps -o wide
kubectl describe svc api-internal -n apps

If provisioning succeeds, EXTERNAL-IP field shows the private static address, not a public IP.

You can also verify in Azure load balancer resources.

az network lb list --resource-group MC_rg-cluster_aks-prod_eastus

Identity and Permission Issues

If service stays pending, AKS identity may lack network permissions. The managed identity needs at least network contributor access for relevant resource scope.

Check AKS identity:

az aks show --resource-group rg-cluster --name aks-prod --query identity

Assign role if needed:

1az role assignment create \
2  --assignee <principal-id> \
3  --role "Network Contributor" \
4  --scope /subscriptions/<sub-id>/resourceGroups/rg-network

Permission propagation can take a few minutes.

Static IP Planning Best Practices

Reserve IPs intentionally to avoid collisions and accidental reassignment.

Recommendations:

• Keep an allocation map for service IPs per environment.
• Use subnet ranges dedicated to internal load balancers.
• Avoid manual reuse of addresses still attached to old services.

If address conflicts occur, service events usually show allocation failures.

DNS Integration

After static IP assignment, map an internal DNS record to the service address.

Example private DNS record:

• Host: api.internal.company.local
• Value: 10.20.2.50

Because the IP is static, application clients can keep stable DNS dependencies during rolling updates. This also simplifies allowlists in upstream systems that require fixed source or destination ranges. Stable addressing reduces change-management overhead during controlled releases.

Troubleshooting Checklist

If the internal load balancer is not created:

1. Confirm service annotation value is exactly true string.
2. Confirm subnet name exists and is reachable by cluster network config.
3. Confirm requested IP belongs to the specified subnet and is free.
4. Confirm AKS identity has network permissions.
5. Inspect kubectl describe svc events for Azure cloud-provider errors.

Most issues are annotation typos, subnet mismatches, or permission gaps.

Common Pitfalls

• Forgetting internal LB annotation. Fix by setting service.beta.kubernetes.io/azure-load-balancer-internal to "true".
• Choosing static IP outside target subnet range. Fix by selecting an unused IP from the configured subnet.
• Missing managed identity permissions. Fix by granting required network role assignments.
• Reusing an IP already bound to another frontend config. Fix by reserving unique addresses and cleaning stale resources.
• Relying on public DNS for private endpoints. Fix by using private DNS zones for internal service names.

Summary

• Internal AKS load balancers provide private service exposure inside the virtual network.
• Static private IP assignment stabilizes integrations and DNS mappings.
• Correct annotations, subnet selection, and identity permissions are required.
• Validate provisioning with kubectl describe svc and Azure resource checks.
• Maintain IP allocation discipline to avoid conflicts and failed deployments.