Azure Kubernetes Service (AKS) forbidden address ranges for vnet
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 https://docs.microsoft.com/en-us/azure/aks/configure-kubenet: 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.
Announcing Active Directory Identity Improvement on AKS on Azure Stack HCI
We’re very pleased to announce that Group Managed Service Account (gMSA) for Containers with non-domain joined host solution is now available in the recently announced AKS on Azure Stack HCI https://github.com/Azure/aks-hci/releases/tag/AKS-HCI-2104! “gMSA with non-domain joined host” vs. “gMSA with domain-joined host” gMSA with non-domain joined host gMSA with domain-joined host Credentials are stored as K8 secret and authenticated parties can retrieve the secret. These creds are used to retrieve the gMSA identity from AD. This eliminates the need for container host to be domain joined and solves challenges with container host updates. Updates to Windows container host can pose considerable challenges. All previous settings need to be reconfigured to domain join the new container host. Simplified end-to-end gMSA configuration process by build-in cmdlets In AKS on Azure Stack HCI, even though you don't need to domain join Windows worker nodes anymore, there are other configuration steps that you can't skip. These steps include installing the webhook, the custom resource definition (CRD), and the credential spec, as well as enabling role-based access control (RBAC). We provide a few PowerShell cmdlets to simply the end-to-end experience. Please refer to Configure group Managed Service Accounts with AKS on Azure Stack HCI - AKS-HCI | Microsoft Docs. Getting started We have provided detailed https://docs.microsoft.com/en-us/azure-stack/aks-hci/prepare-windows-nodes-gmsa#before-you-begin on how to integrate your gMSA with containers in AKS-HCI with non-domain joined solution. Preparing gMSA in domain controller Configure group Managed Service Accounts with AKS on Azure Stack HCI - AKS-HCI | Microsoft Docs Prepare the gMSA credential spec JSON file (This is a one-time action. Please use the gMSA account in your domain) Install webhook, add Kubernetes secret and add gMSA Credential Spec can be finished by three cmdlets Deploy your application. As always, we love to see you try it out, and give us feedback. You can share your feedback at our https://github.com/microsoft/Windows-Containers/issues , or contact us directly at mailto:win-containers@microsoft.com. Jing Twitter: https://twitter.com/JingLi00465231
