Just my luck, straight after creating my last blog post on deploying and using AKS Edge Essentials, a new version of the tool was released which renders some of the previous instructions and config invalid. This is due to some of the steps being streamlined and an updated JSON schema. (Thanks to @LiorKamrat for highlighting this to me)
For information, the previous articles were using the following module versions:
| AKS Edge version | 0.7.22335.1024 |
| AKS Edge shell version | 1.0.221212.1200 |
| AKS Edge deploy version | 1.0.230123.1500 |
The latest modules are the following versions:
| AKS Edge version | 1.0.266.0 |
| AKS Edge shell version | 1.0.230203.1200 |
| AKS Edge deploy version | 1.0.230203.1200 |
Here’s what I did to deploy the new version.
Uninstall AKS Edge Essentials
If you have previous versions of AKS Edge deployed, go ahead and remove the cluster and then remove the tool as per the official documentation instructions: https://learn.microsoft.com/en-gb/azure/aks/hybrid/aks-edge-howto-uninstall
Install the latest version of AKS Edge Essentials
Preparing your system follows the same pattern as per my previous instructions (here), but with the new version of the tool, you can simplify the process by using the Install-AksEdgeHostFeatures command from the AKSEdgePrompt PowerShell Window, once the latest version of the AKS Edge tool has been installed.
Get the latest version of AKS Edge for K8s here: https://aka.ms/aks-edge/k8s-msi
(The MSI file will be named AksEdge-K8s-1.0.266.0.msi)
Above, we can see that I have already got all the pre-reqs configured correctly
At this point, I would also get the latest version of Helm (instructions taken from here)
#download helm from web
Invoke-WebRequest -Uri "https://get.helm.sh/helm-v3.6.3-windows-amd64.zip" -OutFile ".\helm-v3.6.3-windows-amd64.zip"
#Unzip to a local directory
Expand-Archive "helm-v3.6.3-windows-amd64.zip" C:\helm
#set helm in the env Path
$env:Path = "C:\helm\windows-amd64;$env:Path"
[Environment]::SetEnvironmentVariable('Path', $env:Path, 'Machine')I ran the commands above from the AksEdgePrompt PowerShell session. I’ve added the path to the system environment variable (Machine) as I found that the path for Helm was not persistent across sessions when this was not specified.
Check the helm version
Helm version 3.6.3
create config file for scalable cluster
With the new version of the AKS Edge tool, the as previously mentioned, the JSON schema has been updated, so any previous config cannot be used. Here is the config I used to deploy a ‘scalable cluster’ (in my case, it is still a single machine cluster, but I can access the services running on it over my home network).
Whereas before, there were two config files, this has been collapsed into one.
The Arc section is used to register the cluster with Azure Arc and doesn’t need to be populated for the initial cluster deployment.
If you do want to populate the Arc section, you can obtain details such as SubscriptionID and TenantId using the following commands:
az login
#optional - run if you have multiple subscriptions and want to select which one to use
az account set --subscription '<name of the subscription>'
#SubscriptionId
az account show --query id -o tsv
#TenantId
az account show --query tenantId -o tsvIf you haven’t created an Azure AD Client App for use by Azure Arc for this cluster, then the official docs tell you to create one using the process here. That works, but you can use the updated AKS Edge tools to help create a more locked down assignment.
From the AKS-Edge repo, edit .\tools\scripts\AKSEdgeAzureSetup\AzureConfig.json
Fill in the details highlighted in the picture below.
From the AKS Edge prompt PowerShell window, change the directory to .\scripts\AKSEdgeAzureSetup and run:
.\AksEdgeAzureSetup.ps1 -jsonFile .\AzureConfig.json -spContributorRoleThis will:
Check if Azure CLI is installed (and install if not)
Check if the resource group exists - if not will create
Checks if Microsoft.HybridCompute provider registered - if not, will register
Checks if Microsoft.GuestConfiguration provider registered - if not, will register
Checks if Microsoft.HybridConnectivity provider registered - if not, will register
Checks if Microsoft.Kubernetes provider registered - if not, will register
Checks if Microsoft.KubernetesConfiguration provider registered - if not, will register
Checks if Microsoft.ExtendedLocation provider registered - if not, will register
Check if a Service Principal exists, if not, will create it (assuming you have permissions)
Populate the AzureConfig.json file with the
Arcconfiguration items.
You can now copy the Arc config items into the aksedge-config.json file. If the ”AksEdgeConfigFile”: “../../aksedge-config.json“ parameter is set, the script will populate the Arc parameters for you.
Using a similar procedure to create the aksedge-config.json per my previous post, use the following JSON document as a template:
{
"SchemaVersion": "1.5",
"Version": "1.0",
"DeploymentType": "ScalableCluster",
"Init": {
"ServiceIPRangeSize": 10,
"ServiceIPRangeStart": "<Free IpV4 address>"
},
"Arc": {
"ClusterName": null,
"Location": "uksouth",
"ResourceGroupName": "rg-aks-edge-demo-uks",
"SubscriptionId": "<Your Azure SubscriptionId>",
"TenantId": "<Your Azure AD Tenant Id>",
"ClientId": "<Azure AD App Client Id>",
"ClientSecret": "<Azure AD App Client Secret>"
},
"Network": {
"NetworkPlugin": "calico",
"ControlPlaneEndpointIp": "<Free IpV4 address>",
"Ip4GatewayAddress": "<IPv4 Gateway address>",
"Ip4PrefixLength": 24,
"DnsServers": [
"<Your DNS Server e.g.:>8.8.8.8",
"1.1.1.1"
]
,
"InternetDisabled": false,
"Proxy": {
"Http": null,
"Https": null,
"No": null
}
},
"User": {
"AcceptEula": true,
"AcceptOptionalTelemetry": false
},
"Machines": [
{
"NetworkConnection": {
"AdapterName": "<Your Adapter Name for External Switch>",
"Mtu": 0
},
"LinuxNode": {
"CpuCount": 4,
"MemoryInMB": 4096,
"DataSizeInGB": 20,
"Ip4Address": "<Free IP Address for the Linux host>"
}
}
]
}With regards to the NetworkConnection section, you only have to provide the name of the network adapter that you have already created a vSwitch for, or that you want to automatically create. The default name of the vSwitch that is created is aksedgesw-ext
create config file for Single Machine cluster
Here’s the config file I used for the single machine cluster.
You can use the details here to get the Arc config settings
{
"SchemaVersion": "1.5",
"Version": "1.0",
"DeploymentType": "SingleMachineCluster",
"Init": {
"ServiceIPRangeSize": 10
},
"Arc": {
"ClusterName": null,
"Location": null,
"ResourceGroupName": null,
"SubscriptionId": null,
"TenantId": null,
"ClientId": null,
"ClientSecret": null
},
"Network": {
"NetworkPlugin": "calico"
},
"User": {
"AcceptEula": true,
"AcceptOptionalTelemetry": false
},
"Machines": [
{
"LinuxNode": {
"CpuCount": 4,
"MemoryInMB": 4096,
"DataSizeInGB": 10,
"TimeoutSeconds": 300
}
}
]
}Deploying the cluster
There’s no change from the previous version, so follow the instructions here.
Connectingthe cluster to Azure Arc
This process is simplified than previously documented in the previous blog post when I first looked at AKS-EE.
From the AKS Edge prompt PowerShell window, run the following:
# Connect Arc-enabled kubernetes
Connect-AksEdgeArc -JsonConfigFilePath .\aksedge-config.jsonI have now done this a few of time, and I’ve found that the command can halt at the following step ( I left for longer than 10 minutes…):
If it does, I found closing the window, opening a fresh AKS Edge prompt PowerShell window and running the command again works.
And that’s it. I guess that with the AKS Edge tool now being v1, it’s pretty much GA release ready.
