I was attempting to test the new VNet Integration for App Services so I connected my App Service to the subnet 'AppServicesSubnet'. It never worked, always was showing a loading message. So after a few days I then disconnected it, which it said failed but the status showed as 'not configured' regardless.
However I am unable to delete the subnet 'AppServicesSubnet'. It says
"Failed to delete subnet 'AppServicesSubnet'. Error: Subnet
AppServicesSubnet is in use by
AppGroup-DEV/providers/Microsoft.Web/serverfarms/AppServicePlan-DEV
and cannot be deleted."
So I then deleted the app service plan 'AppServicePlan-DEV' this took about 30 minutes and succeeded. However I can still not delete the subnet 'AppServicesSubnet' with the same error given above.
I also cannot delete the virtual network 'Network-DEV' as a similar message is reported:
"Failed to delete virtual network 'Network-DEV'. Error: Subnet
AppServicesSubnet is in use by
AppGroup-DEV/providers/Microsoft.Web/serverfarms/AppServicePlan-DEV
and cannot be deleted."
The app service plan 'AppServicePlan-DEV' doesn't even exist anymore so I'm not sure how to clean up this subnet.
Any help on how to just get rid of this lingering subnet would be much appreciated.
Background on the new App Service VNet Integration Preview can be found here:
https://blogs.msdn.microsoft.com/appserviceteam/2018/10/17/new-app-service-vnet-integration-feature/
and here:
https://learn.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet#new-vnet-integration
Was able to work around this error after it hit us this week. Wanted to test the preview vnet integration. Turned it on, decided it was what we were looking for, then deleted it (to go back and add to automation) only to have automation fail because of this error.
I worked around it by:
adding back the preview connection to the app service I had originally add/ deleted it from.
Then disconnected it again.
This time, however, I was able to delete the subnet as expected.
Definitely a bug somewhere. If you have gone so far as to delete the app service itself and are still having this error...that's a different story.
I had a similar issue. I wasn't able to delete a a subnet because it was in use by some resource that didn't exist (in my point of view)....
So i ran this cli script to delete my subnet and my vNet.
RES_GROUP={Replace to your rg}
VNET_NAME={Replace to your vnet}
SUBNET_NAME={Replace to your subnet}
NETWORK_PROFILE_ID=$(az network profile list --resource-group $RES_GROUP --query [0].id --output tsv)
az network profile delete --id $NETWORK_PROFILE_ID -y
SAL_ID=$(az network vnet subnet show --resource-group $RES_GROUP --vnet-name $VNET_NAME --name $SUBNET_NAME --query id --output tsv)/providers/Microsoft.ContainerInstance/serviceAssociationLinks/default
az resource delete --ids $SAL_ID --api-version 2018-07-01
az network vnet subnet update --resource-group $RES_GROUP --vnet-name $VNET_NAME --name $SUBNET_NAME--remove delegations 0
az network vnet subnet delete --resource-group $RES_GROUP --vnet-name $VNET_NAME --name $SUBNET_NAME
az network vnet delete --resource-group $RES_GROUP --name $VNET_NAME
I tried again after a month and was able to delete the subnet in question. I guess it just takes some time for the new App Service VNet Integration (Preview) to be unregistered after it is disconnected.
Related
I am trying to create a new node pool in a newly created subnet with this command
az aks nodepool add \
--resource-group nems12 \
--cluster-name nems-cluster \
--name aksperfnode \
--node-count 1 \
--vnet-subnet-id aks2
But getting an error Agent pools subnet is not in Vnet CIDR but it is actually added in vnet address space and a subnet is created for it
I tested in my environment its working fine for me. You need to provide --vnet-subnet-id in this format /subscriptions/b83c1eXXXXX5ba-2bXXXXX23f/resourceGroups/v-raxXXXXee/providers/Microsoft.Network/virtualNetworks/TestVNET/subnets/AKS-Subnet.
Note : As Andriy Bilous also check that suggestion if you are still getting an error after followed my solution.
please check that the subnet assigned to the AKS node pool is not a delegated subnet.
Select NSG as None for your existing Subnet. Which might sometime cause error.
I'm attempting to create a new AKS cluster using Kubernetes version 1.19.7 and virtual machine scale sets and connect it to an existing on-prem vnet. On my first attempt, everything succeeded except for the creation of the actual ACI in Azure. The aci-connector node got created in Kubernetes but remained in a CrashLoopBackOff state, each time with the following error in the kubernetes logs:
Error: error initializing provider azure: error setting up network
profile: unable to delegate subnet 'xxxxxxxxx' to Azure Container
Instance since it references the route table
'/subscriptions/yyyyyyyy/resourceGroups/zzzzzzzz/providers/Microsoft.Network/routeTables/rrrrrrr'.
I tried recreating the cluster differently, according to limitations buried in MS documentation (using service principal, with empty subnet containing no other resources, with proper role permissions applied to the service account). Still no luck. Tried a few other tweaks on the networking side as well, but to no avail.
Here are the Azure CLI commands I used (names obfuscated) with/without service principal:
Using managed identity
az aks create -g yyyyyyyyy -n zzzzzzzz --aad-admin-group-object-ids 00000000-0000-0000-0000-000000000000 --aci-subnet-name myAciSubnet --assign-identity /subscriptions/xxxxxxx/resourcegroups/yyyyyyy/providers/Microsoft.ManagedIdentity/userAssignedIdentities/k8s-admin-qa --docker-bridge-address 172.17.0.1/16 --dns-service-ip 10.2.0.10 --enable-aad --enable-addons virtual-node --enable-managed-identity --generate-ssh-keys --kubernetes-version 1.19.7 --location eastus2 --network-plugin azure --service-cidr 10.2.0.0/16 --subscription xxxxxxx --vnet-subnet-id /subscriptions/xxxxxxx/resourceGroups/myNetworkResourceGroup/providers/Microsoft.Network/virtualNetworks/myVnet/subnets/mySubnet
Using Service Principal
az aks create -g yyyyyyy -n zzzzzzz --aad-admin-group-object-ids 00000000-0000-0000-0000-000000000000 --aci-subnet-name myAciSubnet --docker-bridge-address 172.17.0.1/16 --dns-service-ip 10.2.0.10 --enable-aad --enable-addons virtual-node --generate-ssh-keys --kubernetes-version 1.19.7 --location eastus2 --network-plugin azure --service-cidr 10.2.0.0/16 --subscription xxxxxxx --vnet-subnet-id /subscriptions/xxxxxxx/resourceGroups/myNetworkResourceGroup/providers/Microsoft.Network/virtualNetworks/myVnet/subnets/mySubnet --service-principal ppppppppp --client-secret SSSSSSSSSSS
If anyone out there has been able to successfully deploy/configure an AKS cluster using ACI with virtual machine scale sets, connected to an on-prem network, or can otherwise assist in troubleshooting or configuration, I'd love to hear from you!
The subnet for the ACI should have no other resources except the ACI and also no attached route table. Because Azure will attach a profile of the container group for it. And the error shows the subnet you want to use for the ACI already attached a routing table. So you can create a new subnet with nothing or just disassociate the routing table from the subnet.
I created a new Azure container instance (ACI) with a new vnet and subnet by Azure CLI
I deleted ACI from Azure portal and now Im trying to delete subnet but gives me the following errors:
Failed to delete subnet 'SubnetNAme'. Error: Subnet SubnetNAme is in use by aci-network-profile-VNETNAME-SubnetNAme/eth0/ipconfigprofile and cannot be deleted. In order to delete the subnet, delete all the resources within the subnet. See aka.ms/deletesubnet.
If I tried to access aci-network-profile-VNETNAME-SubnetNAme/eth0/ipconfigprofile, it tells me that doesnt exist this resource:
Details
The resource was not found, it may have been deleted. If this was launched from a pinned tile on the dashboard, it should be removed.
For your issue, instead of finding the aci-network-profile-VNETNAME-SubnetNAme/eth0/ipconfigprofile in the portal, you need to delete the Network Profile through Azure CLI command like this:
NETWORK_PROFILE_ID=$(az network profile list --resource-group yourResourceGroup --query [0].id --output tsv)
az network profile delete --id $NETWORK_PROFILE_ID -y
After you delete the Network Profile, then you can delete the subnet as you want. For mor details, see Delete network resources.
well, i'd assume your best bet is to try and find the lingering resource and delete it (rest api would work best here, probably). another option is to recreate the ACI with the same name and remove the binding to the network before deleting it.
And your last option would be to contact support ;)
I had the same issue and me help below steps to remove aci subnet and vnet with trash container nic:
1st - find name of problem network profile by command - > az network profile list --query [].name -o tsv
2nd - create resource by terraform -> resource "azurerm_network_profile" "example" with the same network profile name and problem subnet id.
3rd - after terraform successfully create network profile, remove it by -> az network profile delete --id ...(you can find id by az network profile list --query [].id -o tsv)
4th - go to portal and change subnet delegate from container to none, after save I could delete subnet and vnet.
Below is the solution. Sometime trying just delete doesn't work. Follow the below steps and which is tested and worked for me.
NETWORK_PROFILE_ID=$(az network profile list --resource-group yourResourceGroup --query [0].id --output tsv)
az network profile delete --id $NETWORK_PROFILE_ID -y
This is a known issue and Microsoft is working on it. The workaround that worked for me is to update the containerNetworkInterfaceConfigurations property in Network profile properties to an empty list
# Get network profile ID
NETWORK_PROFILE_ID=$(az network profile list --resource-group <reource-group-name> --query [0].id --output tsv)
az resource update --ids $NETWORK_PROFILE_ID --set properties.containerNetworkInterfaceConfigurations=[]
And then deleting it works
az network profile delete --id $NETWORK_PROFILE_ID -y
I am attempting to create a private link service that can be reached from a different region. I am getting conflicting information from Azure documentation, with one link suggesting "global reach" and another link limiting that
Global reach
Limitations
In practice, I have one private-resource-vnet in westus and one vnet in eastus. After creating a load balancer per the documentation in the private-resource-vnet, I add a private link to that vnet and resource, and attempt to link it to a private endpoint. The below sample shows adding an endpoint in both eastus (where the private link is) and westus (where the vnet to reach the link is)
PS Azure:\> az network private-endpoint create --name privateEndpoint --resource-group MyResourceGroup --vnet-name clientVNet --subnet clientSubnet --private-connection-resource-id "/subscription/link/to/private/resource/in/eastus" --connection-name myPLS --location westus
This command is in preview. It may be changed/removed in a future release.
InvalidResourceReference - Resource /subscriptions/[...]/CLIENTVNET referenced by resource /subscriptions/[...]/privateEndpoint was not found. Please make sure that the referenced resource exists, and that both resources are in the same region.
PS Azure:\> az network private-endpoint create --name privateEndpoint --resource-group MyResourceGroup --vnet-name clientVNet --subnet clientSubnet --private-connection-resource-id "/subscription/link/to/private/resource/in/eastus" --connection-name myPLS --location eastus
This command is in preview. It may be changed/removed in a future release.
Deployment failed. Correlation ID: [...]. Resource /subscriptions/[...]/myPLS not found.
I would greatly appreciate some insight on what I'm missing here!
Cross-region works with Azure services (SQL, Storage) that are behind Private Link. Customer owned services are limited to same region. Cross-region will be supported in the future.
I've setup kubernetes in azure using the azure acs and the azure cli.
az account list
az account set --subscription foobar
az group create --name foobar --location westus
az acs create --orchestrator-type=kubernetes --resource-group foobar --master-count 1 --name=foobar --dns-prefix=foobar
I want to be able to setup a site to site vpn, so that kubernetes can reach internal services in my datacenter.
Unfortunatly azure acs sets up kubernetes on a 10.0.0.0 network which overlaps with other resources in azure and my datacenter.
I can't find any way to change which subnet kubernetes runs on in acs. Is there a way to change the prefered network?
There does not appear to be a way to choose network from the acs create command
az acs create --name
--resource-group
[--admin-password]
[--admin-username]
[--agent-count]
[--agent-vm-size]
[--client-secret]
[--dns-prefix]
[--generate-ssh-keys]
[--location]
[--master-count]
[--no-wait]
[--orchestrator-type {Custom, DCOS, Kubernetes, Swarm}]
[--service-principal]
[--ssh-key-value]
[--tags]
[--validate]
[--windows]
No, there's no way of doing that. There might be a way to create a new kubernetes to existing vnet, but I'm not aware of that.
Your another option would be to delete all vm's and recreate them in the new vnet. No guarantee it would work.
With ACS through its CLI you can specify subnet id so the acs is created in a particular VNET. However this is only available in certain regions