Updating Azure Virtual Machine Scale Set - azure

I have hosted a website in azure virtual machine scale set by following the below steps
Create a VM and do the necessary changes/installations in iis.
Create a snapshot of the VM. This ensure that the above instance can be used for future changes.
create a disk from the snapshot.
create a vm from the disk.
RDP to the instance and generalize the instance for deployment (sysprep)
Run %WINDIR%\system32\sysprep\sysprep.exe as admin.
Enter System Out-of-Box Experience (OOBE),
Generalize check box is selected
Shutdown Option = Shutdown
Create Image (capture) from the above instance.
Create VSS from the above image
Suppose their is a change in the web build , Is there a way to update the scale set without following these steps again ?

Azure virtual machine extensions provide capabilities such as post-deployment configuration and management, monitoring, security, and more. Production deployments typically use a combination of multiple extensions configured for the VM instances to achieve desired results.
This is also is a good way to ensure availability of your system. The scale set will apply the update to one VM at a time, leaving the other VMs up and running.
Below example taken from the learn:
Deploy the update by using a custom script extension
In the Azure portal, run the following command to view the current upgrade policy for the scale set:
Azure CLI:
az vmss show \
--name webServerScaleSet \
--resource-group scalesetrg \
--query upgradePolicy.mode
Verify that the upgrade policy is set to Automatic. You specified this policy when you created the scale set in the first lab. If the policy were Manual, you would apply any VM changes by hand. Because the policy is Automatic, you can use the custom script extension and allow the scale set to do the update.
Run the following command to apply the update script:
az vmss extension set \
--publisher Microsoft.Azure.Extensions \
--version 2.0 \
--name CustomScript \
--vmss-name webServerScaleSet \
--resource-group scalesetrg \
--settings "{\"commandToExecute\": \"echo This is the updated app installed on the Virtual Machine Scale Set ! > /var/www/html/index.html\"}"

Related

Unable to create Windows B2s nodepool in AKS

I need to add a Windows B2s nodepool to AKS. I am getting the folowwing error:
Error: Code="VMSizeIsNotPermittedToEnableAcceleratedNetworkingForVmss" Message="Virtual machine at index 0 of VM scale set /removed id of VMSS/ has size Standard_B2s, which is not compatible with enabling accelerated networking in the network profile on the scale set. Allowed sizes: Standard_D2_v4, Standard_D2s_v4, Standard_D2ds_v4, etc.
I am sure before this was allowed because I had created B2s and B2ms Windows nodepools before. I see it is related to accelerated networking, but how can I influence accelerated netoworking for VMSS that is yet to be created and is controlled by Azure?
I have tested to add B2s in my environment with Linux nodepool and it was successful.
If your instance supports then it should be deployed with Accelerated Networking. If it does not, it should be deployed without AN. Please issue a support ticket if you can. And you can give these steps a try.
Create nodepool with AN supported instance type.
Scale nodepool to zero.
Change instance type to B2s.
Scale nodepool to one.
I shared a link below. Not the same thing but it also can give an idea.
https://github.com/Azure/AKS/issues/1404
Error: Code="VMSizeIsNotPermittedToEnableAcceleratedNetworkingForVmss"
Message="Virtual machine at index 0 of VM scale set /removed id of
VMSS/ has size Standard_B2s, which is not compatible with enabling
accelerated networking in the network profile on the scale set.
Allowed sizes: Standard_D2_v4, Standard_D2s_v4, Standard_D2ds_v4, etc
from the above error we can understand, VMSS/ has size Standard_B2s is not NotPermitted ToEnableAcceleratedNetworking.
You can check the same using this Az CLI cmdlet.
The list of Virtual Machine SKUs that support Accelerated Networking can be queried directly via the following Azure CLI az vm list-skus command.
az vm list-skus \
--location westus \
--all true \
--resource-type virtualMachines \
--query '[].{size:size, name:name, acceleratedNetworkingEnabled: capabilities[?name==`AcceleratedNetworkingEnabled`].value | [0]}' \
--output table
Would suggest you to select the node pool which is recommended one.
You can refer this MS Document for the same information.

Cannot update azure container image in existing vnet, error NetworkProfileCannotChange

I have an azure container instance running in a vnet within a subnet.
I have been (until now) able to update the image of this container instance with a command like this one:
az container create \
--resource-group my_rg\
--name containername \
--image containerregistry.azurecr.io/myimage:latest \
--registry-login-server containerregistry.azurecr.io \
--registry-username username \
--registry-password password \
--vnet my_vnet \
--subnet my_subnet
Until now, when I needed to update the image in my container, I would build it, push it to my container registry in azure, and run this command.
The container would stop and restart with the new image.
It may not be the issue but I upgraded my azure cli recently, I am now on version 2.34.1.
When I run this command now I get this message:
(NetworkProfileCannotChange) The network profile of existing container group 'containername' cannot be changed. To change a network profile, you must delete and then create the container group with the changed property.
Code: NetworkProfileCannotChange
I don't want to change my network profile, I just want to update the image.
I have seen it with
az network profile list --resource-group my_rg
It looks fine for me.
I have double checked, my vnet and my subnet have not changed.
I don't understand why this command does not work anymore.
Any idea of what's happening ?
Cheers
Tested in my enviroment it is working fine for me with both the version.
Earlier i was using the AZ CLI version 2.32.0 able to create the Container.
Now i have updated the AZ CLI version to 2.34.1 and trying to change or update the image of container using the same command with same existing VNET and Subnet
Getting Simmillar Kind of Error when i am changing the Subnet name.
Suggestion 1 : Would suggest you to recheck if your existing container is not taking another subnet or VNET when you are creating container with updated images.
Suggestion 2 : Sometimes it might stopes you to update the Image on Running and exist conatainer, you get this error: "If you are going to update the os type, restart policy, network profile, CPU, memory or GPU resources for a container group, you must delete it first and then create a new one"
Suggestion 3 : TO avoid the recreation of conatainer scheduled container instance that is running once a day. Whenever it starts it is pulling the docker image with the :latest tag from the azure container registry. This avoids re-creation of the container group.
For more information You can refer this https://circleci.com/blog/azure-custom-images/ and Related Issue

Changing --network-plugin in Azure Kubernetes Service for existing cluster

I'm trying to implement Azure Key Vault such that API keys, credentials and other Kubernetes secrets are read into production and staging environments. Ultimately, I'd like to try to expand that to local development environments so devs don't have to mess with it at all. It is just read in when they start their cluster.
Anyway, I'm following this to enable Pod Identities:
https://learn.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity
When I get to this step, I'm modifying the:
az aks create -g myResourceGroup -n myAKSCluster --enable-managed-identity --enable-pod-identity --network-plugin azure
To the following because I'm trying to change an existing cluster:
az aks update -g myResourceGroup -n myAKSCluster --enable-managed-identity --enable-pod-identity --network-plugin azure
This doesn't work and figured out I need to run each flag one at a time, so I had to run --enable-managed-identity first since --enable-pod-identity depends on it.
At any rate, when I get to the --enable-pod-identity I get the following error:
Operation failed with status: 'Bad Request'. Details: Network plugin kubenet is not supported to use with PodIdentity addon.
So I try the --network-plugin azure and get:
az: error: unrecognized arguments: --network-plugin azure
Apparently this is flag is not available with update.
Poking around in the Azure portal for the AKS resource, I do see kubenet listed, but I'm not able to change it.
So, the question: Is it possible to change the Network Plugin on existing cluster or do I need to start a new?
EDIT: Looks like others are having similar issues on existing clusters:
https://github.com/Azure/AKS/issues/2094
Is it possible to change the Network Plugin on the existing cluster or do
I need to start a new?
It's impossible to change the network plugin on the existing cluster, so you need to create a new cluster and set the network plugin with azure at the creation time. You can find there is no parameter --network-plugin in the CLI command az aks update even if you install the aks-preview extension. It means it does not support changing the network plugin of the existing cluster.

Error while applying Node Autoscaler for existing AKS cluster

I am trying to experiment with Preview feature available in Azure AKS as per documentation available we need to have the following requirements
Kubernetes version 1.12.4 or later
Azure CLI version 2.0.55 or later.
add aks preview :- az extension add --name aks-preview
register scale set provider:- az feature register --name VMSSPreview --namespace Microsoft.ContainerService
ensure that it is registerd
created AKS cluster with terraform
when i try to apply following command
az aks update --resource-group rg-euwest-d04-dvag-001 --name k8s-euwest-d04-dvag-dfs-dfsapp-001 --enable-cluster-autoscaler --min-count 3 --max-count 5
error
Operation failed with status: 'Bad Request'. Details: AgentPool
'' has set auto scaling as enabled but is not on Virtual
Machine Scale Sets, this is not allowed
As per my understanding, it is not supported at this time through terraform or from Azure Portal but only possible from Azure CLI
Your cluster needs to be created via Azure CLI to enable autoscaling. So if you have created on evia Azure portal, you need to delete it and create new one through Azure CLI. Ref: https://github.com/MicrosoftDocs/azure-docs/issues/29199

Azure vmss without a load balancer

My requirement is to scale vm instance (linux based custom image) based on CPU usage. Tried to follow steps mentioned in VMSS (virtual machine scale sets : https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-linux-autoscale), but it creates a LB in front which we don't want. Is it possible to avoid LB in vmss ?
If VMSS without LB is not the option, is there any other way in azure to do this ?
I am able to achieve this in AWS (using autoscale group) and GCP (instance group), so trying to get similar functionality in Azure.
hp
In powershell to make this work you need to provide both double quotes wrapped in single quotes: --load-balancer '""'
az vmss -n myName -g myGroup --load-balancer '""' --image UbuntuLTS
Pass empty id as a load-balancer
az vmss create -n myname -g mygroup --load-balancer "" --public-ip-per-vm --image UbuntuLTS
Though a load balancer is created when you create a VM scale set in the portal, other modes supporting external connectivity to scale sets include:
Create a separate VM with a public IP address in the same VNET as the scale set which can route connections to the scale set VMs (also known as a jump box). E.g. https://github.com/Azure/azure-quickstart-templates/tree/master/201-vmss-windows-jumpbox or https://github.com/Azure/azure-quickstart-templates/tree/master/201-vmss-linux-jumpbox
Assign a public IP address to each VM in the scale set. This feature is currently in limited preview. See here for more details: https://github.com/gbowerman/azure-myriad/tree/master/publicip-dns
Public IP per VM in a scale set is not supported today but is on the roadmap. If you submit a support request (e.g. from the question mark in the top-right of the azure portal), we can keep you informed on the timeline :).

Resources