I would like to stop and deallocate the nodes in a kubernetes cluster in azure so It cannot be billed during weekends for example. I just can set to a minimun of 1 node using the az CLI
Any idea will be appreciated
If your are using scale sets (used for autoscaling and multiple node pools) you can deallocate the scale sets via ui (search in the resource the scale sets are created) or via az cli az-vmss-deallocate
Usually if we use PowerShell then Automation runbook can work for us. Unfortunately I could not find PowerShell to start/ stop AKS. Azure CLI do support AKS start and stop. Also it maintains the state of AKS cluster so that you can start where you had left.
One way is to use Azure CLI and find a way to automate on your own. Refer this link for Azure CLI of start stop automation - https://learn.microsoft.com/en-us/azure/aks/start-stop-cluster?tabs=azure-cli
Other way is to use ready solution. I found this marketplace solution that runs a VM and shuts down/ starts AKS cluster on the time specified. Refer this link for the deployment -
https://azuremarketplace.microsoft.com/en-in/marketplace/apps/bowspritconsultingopcprivatelimited1596291408582.aksautomation2?tab=Overview
If you are good with automation and writing scripts then use option 1 else go for option 2.
You can use AKS Start/Stop option or Stop VMSS manually by going to Infrastructure Resource Group, but that isn't supported and shouldn't be used.
https://learn.microsoft.com/en-us/azure/aks/start-stop-cluster?tabs=azure-cli
Also, for any user Nodepool, you can put the count to 0 now.
https://learn.microsoft.com/en-us/azure/aks/scale-cluster
Related
I currently deal 10-15 environment 100% IaC with Terraform in Azure. One of the recent projects was to change some log collection settings for all AKS Cluster. Here is a link of how to do it via kubectl - https://learn.microsoft.com/en-us/azure/azure-monitor/containers/container-insights-agent-config#data-collection-settings.
What I've found so far?
Terraform has a kubernetes_config_map resource which I was able to successfully create. (https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs/resources/config_map)
My next question is how do I apply or attach the kubernetes_config_map resource to the AKS cluster? Assuming I want this applied to all the namespaces. I wasn't able to find config_map parameter on any of the resources.
We also use helm_release, is it possible to attach/pass that kubernets_config_map to the helm_release?
Any guidance would be greatly appreciated. Thanks..
Working with Azure, we started with AKS last year. On creation of the AKS clusters we use, we checked what needed to be done up front to enable rbac at a later moment and we then thought that setting 'rbac' to 'enabled' was the only thing we needed. This results in the following:
Now we're trying to implement rbac integration of AKS with AAD, but I read some seemingly conflicting pre-requisites. Some say that in order to integrate AAD and AKS, you need rbac enabled at cluster creation. I believe we have set that correct, looking at the picture above.
But then in the Azure docs, it is mentioned that you need to create a cluster and add some AAD-integration keys for the client and server applications.
My question is actually two-fold:
when people say you need rbac enabled in your aks cluster during creation do they actually mean you should select the 'rbac:enabled' box AND make sure you create the AAD-related applications up front and also configure these during cluster creation?
Is there a way to setup the AKS-AAD rbac connection on a cluster that has rbac:enabled but misses the aadProfile configuration?
I believe we indeed need to re-create all our clusters, but I want to know for sure by asking here as it's not 100% clear to me from what I've read online (also here at stack exchange) and it's going to be an awful lot of work.
For all of your requirements, you only need to make sure the RBAC enabled for your AKS cluster and it only can enable in the creation time. Then you can update the credential of the existing AKS AAD profile like this:
Before update:
CLI update command:
az aks update-credentials -g yourResourceGroup -n yourAKSCluster --reset-aad --aad-server-app-id appId --aad-server-app-secret appSecret --aad-client-app-id clientId --aad-tenant-id tenantId
After update:
yes, that is correct
no, there is no way of doing that. you need to recreate.
I have two separate Azure accounts.
One for each project in which I am involved, these accounts are totally independent, that is, they do not share any type of resource and do not have the same domain. They are from two totally different companies.
I find that both accounts respond to me at the time of login from PowerShell and I can access those resources.
Both work with Kubernetes (kubectl) but only one of the two accounts is shown. Whatever you do always shows the content of co-owners of one and not the other.
I have the Azure CLI (v.2.0.76) and the PS version is (5.1)
someone know how to I can do?
EDIT with pictures -
Although the account is default, I am not able to access the kubernetes of the same
PS Default Account
Services from the other account..not the default account
services from other cluster
I just found the solution.
When we access from PS with Az Login and select the account, it allows us to access all the resources of that account (the one that is predetermined)
What I have done is basically see the
kubectl config view
This returns the result of all the clusters that it finds with its context. The next thing we have to do is tell kubectl what CONTEXT we want to work with in the following way:
kubectl config use-context "CONTEXT NAME"
And thats it.
We were experiencing timeouts the first time a function from a Function App was being called so we move from a normal to premium service plan as in theory you can have always a warmed instance ready to answer a call (based on this documentation).
The thing is that when trying to configure the functionality we cannot see the setting present in the documentation. This is our portal:
And this is the portal settings appearing in the documentation:
The functions are still timing out the first time they are called so we did not see any difference moving from a normal plan to the premium one. Are we missing something?
Didn't reproduce your problem, I can set the pre-warmed instances on my portal. But I have an idea to solve this problem.
Try to use powshell in Azure Cloud Shell to configure the pre-warmed instances of your function app instead of using portal:
az resource update -g <resource_group> -n <function_app_name>/config/web --set properties.preWarmedInstanceCount=<desired_prewarmed_count> --resource-type Microsoft.Web/sites
Test whether it can be setted. If can't, have a look of the error. This may be an error with the portal.
If you have doubts, please let me know.
Turns out that you need to modify the Function App settings while we were tweaking the Service Plan.
We have there the warmed instances setting but it is not having the expected result, we are still facing the timeouts we had with the normal Service Plan.
We have our corporate requirement ( due to pricing and whitelisting) to have Availability sets in our Azure subscription and resources like Compute should be spun inside that particular availability set. Since Packer while creating the Image spins up a temporary VM inside a temporary resource Group , I am confused (since did not find any documentation around it) if we can configure packer to spin the temporary VM inside the whitelisted availability set.
One possible way I can think of is to spin up the VM in the Resource Group which we created for the Availability Set (Since everything in Azure needs to be inside the Resource Group) that way I am guessing it will be tracked as part of billing but I am still not sure if the intermittent VM will be part of availability set.
Please help and suggest if there is an alternate way to the same .