Azure Kubernetes Service (AKS) forbidden address ranges for vnet

%3CLINGO-SUB%20id%3D%22lingo-sub-2702256%22%20slang%3D%22en-US%22%3EAzure%20Kubernetes%20Service%20(AKS)%20forbidden%20address%20ranges%20for%20vnet%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2702256%22%20slang%3D%22en-US%22%3E%3CP%3EI%20installed%20some%20months%20ago%20an%20AKS%20cluster%20with%20kubenet%20networking%20without%20problems.%20In%20our%20last%20version%20upgrade%20something%20changed%2C%20because%20it%20complained%20that%20we%20were%20using%20for%20the%20vnet%20where%20the%20cluster%20is%20placed%20a%20private%20address%20range%20that%20is%20disallowed%20in%20the%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Faks%2Fconfigure-kubenet%22%20target%3D%22_self%22%20rel%3D%22noopener%20noreferrer%22%3Edocumentation%3C%2FA%3E%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%20class%3D%22lia-indent-padding-left-30px%22%3E%3CEM%3EAKS%20clusters%20may%20not%20use%20169.254.0.0%2F16%2C%20172.30.0.0%2F16%2C%20172.31.0.0%2F16%2C%20or%20192.0.2.0%2F24%20for%20the%20Kubernetes%20service%20address%20range%2C%20pod%20address%20range%20or%20cluster%20virtual%20network%20address%20range%3C%2FEM%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20problem%20is%20that%20we%20use%20these%20%22forbidden%22%20private%20address%20ranges%20for%20our%20network%20infrastructure%20in%20azure%20(we%20have%20a%20hub%20%26amp%3B%20spoke%20architecture)%20and%20on-premises%20(we%20have%20an%20ExpressRoute%20connection)%20and%20it%20seems%20that%20we%20have%20to%20make%20a%20huge%20change%20in%20all%20our%20network%20to%20be%20able%20to%20upgrade%20or%20reinstall%20the%20AKS%20cluster%20with%20full%20connectivity.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20tried%20with%20Azure%20support%20but%20they%20say%20that%20it%20is%20a%20design%20decision%20that%20can%20not%20be%20changed.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIf%20anybody%20has%20any%20suggestion%20to%20deal%20with%20this%20AKS%20upgrade%2Freinstall%20problem%20(that%20does%20not%20require%20a%20complete%20change%20in%20our%20IP%20addressing%20policy)%2C%20that%20would%20be%20very%20helpful.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-2702256%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAKS%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EAzure%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EKubenetes%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E
New Contributor

I installed some months ago an AKS cluster with kubenet networking without problems. In our last version upgrade something changed, because it complained that we were using for the vnet where the cluster is placed a private address range that is disallowed in the documentation:

 

AKS clusters may not use 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16, or 192.0.2.0/24 for the Kubernetes service address range, pod address range or cluster virtual network address range

 

The problem is that we use these "forbidden" private address ranges for our network infrastructure in azure (we have a hub & spoke architecture) and on-premises (we have an ExpressRoute connection) and it seems that we have to make a huge change in all our network to be able to upgrade or reinstall the AKS cluster with full connectivity.

 

I tried with Azure support but they say that it is a design decision that can not be changed.

 

If anybody has any suggestion to deal with this AKS upgrade/reinstall problem (that does not require a complete change in our IP addressing policy), that would be very helpful.

0 Replies