Unable to choose subnet to avoid CIDR overlap

[IvanLieckens]

Describe the bug

Command Name
az aks enable-addons

Errors:

(ServiceCidrOverlapExistingSubnetsCidr) The specified service CIDR 10.0.0.0/16 is conflicted with an existing subnet CIDR 10.0.239.0/24
Code: ServiceCidrOverlapExistingSubnetsCidr
Message: The specified service CIDR 10.0.0.0/16 is conflicted with an existing subnet CIDR 10.0.239.0/24
Target: networkProfile.serviceCIDR

To Reproduce:

Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

• az aks enable-addons -a monitoring -n {} -g {} --workspace-resource-id {} --subnet-name {}

Expected Behavior

Monitoring successfully added to AKS

Environment Summary

Windows-10-10.0.19041-SP0
Python 3.8.9
Installer: MSI

azure-cli 2.30.0

Additional Context

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @Azure/aks-pm.

Issue Details

---

Describe the bug

Command Name
az aks enable-addons

Errors:

(ServiceCidrOverlapExistingSubnetsCidr) The specified service CIDR 10.0.0.0/16 is conflicted with an existing subnet CIDR 10.0.239.0/24
Code: ServiceCidrOverlapExistingSubnetsCidr
Message: The specified service CIDR 10.0.0.0/16 is conflicted with an existing subnet CIDR 10.0.239.0/24
Target: networkProfile.serviceCIDR

To Reproduce:

Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

• az aks enable-addons -a monitoring -n {} -g {} --workspace-resource-id {} --subnet-name {}

Expected Behavior

Monitoring successfully added to AKS

Environment Summary

Windows-10-10.0.19041-SP0
Python 3.8.9
Installer: MSI

azure-cli 2.30.0

Additional Context

Author:	IvanLieckens
Assignees:	-
Labels:	Service Attention, question, AKS, customer-reported, needs-triage
Milestone:	-

[jiasli]

Routing to service team to take a look. Please expect delay due to the holiday season.

[navba-MSFT]

@IvanLieckens Apologies for the delayed response. AFAIK, changing the service range is not possible once cluster is created. From the AKS / Network standpoint the validations are done to check and block against possible conflicts. Here is the GitHub on this behavior.

So I am sharing some of the suggestions below if that is feasible for you:

1. You can create a new subnet within the VNet. The newly allocated address space will be used for this subnet. You can now create the cluster in the new subnet. There should be no issues with communicating since both address spaces are in the same VNet.

2. You can create a separate VNet and deploy the cluster in this new VNet. You can use VNet peering.

Note that the range must be unique within the address space for the virtual network. The range cannot overlap with other subnet address ranges within the virtual network. The address space must be specified by using Classless Inter-Domain Routing (CIDR) notation. You can find additional information and details in this document.

You may also find the following documentation helpful to as well:
https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni#plan-ip-addressing-for-your-cluster
kubernetes/kops#2294

Hope this helps. Please let me know if you need any further assistance on this.

[navba-MSFT]

@IvanLieckens
I wanted to do quick follow-up to check if you had a chance to look at my above comment. This github issue is open for quite sometime. Please let us know if you need any further assistance on this. Awaiting your reply.

[IvanLieckens]

@navba-MSFT Sorry this ticket was a bit out of my observation. I actually tried to use method nr 1 before creating this ticket and was unable to have it succeed. Hence the --subnet-name {} at the end of my command, I had manually created one and was trying to have the monitoring to be created and assigned to this subnet to prevent the overlap... Alas this gave the very same error. Hence I opened this ticket as it feels as if my preferred subnet setting is being ignored while the installation command is being executed.

How would I go about having monitoring created in another vnet and peer them? (option 2) I can give it a try to see if that's a viable solution to this.

[navba-MSFT]

@IvanLieckens Apologies for the late reply. Could you confirm if you are able to enable the monitoring addon directly from the portal as explained here ? Awaiting your reply.