Request for help:
Conflict create in the masters during cluster creation
aks-engine version:
Kubernetes version:
12.1
What happened:


Error message:
{
"status": "Failed",
"error": {
"code": "ResourceDeploymentFailure",
"message": "The resource operation completed with terminal provisioning state 'Failed'.",
"details": [
{
"code": "VMExtensionProvisioningError",
"message": "VM has reported a failure when processing extension 'cse-master-2'. Error message: \"Enable failed: failed to execute command: command terminated with exit status=30\n[stdout]\n\n[stderr]\nConnection to k8s.gcr.io 443 port [tcp/https] succeeded!\nConnection to gcr.io 443 port [tcp/https] succeeded!\nConnection to docker.io 443 port [tcp/https] succeeded!\n\"."
}
]
}
The cluster deployment fails because of a conflict in the masters.
What you expected to happen:
No conflicts.
How to reproduce it (as minimally and precisely as possible):
The input parameters:
{
"apiVersion": "vlabs",
"properties": {
"orchestratorProfile": {
"orchestratorType": "Kubernetes",
"orchestratorVersion": "1.12.1",
"kubernetesConfig": {
"apiServerConfig": {
"--enable-admission-plugins": "NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,ExtendedResourceToleration"
},
"useManagedIdentity": true,
"addons": [
{
"name": "cluster-autoscaler",
"enabled": true,
"config": {
"minNodes": "4",
"maxNodes": "50"
}
}
]
}
},
"masterProfile": {
"count": 3,
"dnsPrefix": "@__Master_dnsPrefix__@",
"vmSize": "Standard_D2_v2",
"vnetSubnetId": "@__resourceGroupName__@/providers/Microsoft.Network/virtualNetworks/@__clusterVnetName__@/subnets/@__Master_vnetSubnetName__@",
"firstConsecutiveStaticIP": "10.10.0.230",
"vnetCidr": "10.10.0.0/16",
"subjectAltNames": [
"@__Master_dnsPrefix__@.@__Master_DomainSuffix__@"
]
},
"agentPoolProfiles": [
{
"name": "agentstgeus",
"count": 2,
"vmSize": "Standard_D4_v2",
"vnetSubnetId": "@__resourceGroupName__@/providers/Microsoft.Network/virtualNetworks/@__clusterVnetName__@/subnets/@__agent_vnetSubnetName__@",
"availabilityProfile": "VirtualMachineScaleSets",
"storageProfile": "ManagedDisks",
"osDiskSizeGB": 400,
"acceleratedNetworkingEnabled": true
}
],
"linuxProfile": {
"adminUsername": "wdatpuser",
"ssh": {
"publicKeys": [
{
"keyData": "@__ClusterSshPublicKey__@"
}
]
}
}
}
}
Anything else we need to know:
馃憢 Thanks for opening your first issue here! If you're reporting a 馃悶 bug, please make sure you include steps to reproduce it.
@oroboni "Conflict" is just how ARM chooses to present this error on the VMs. The core problem is a "CSE 30" issue.
Can you take a look at our VMExtensionProvisioning error troubleshooting doc and see if it helps you?
The exit code is 30:
Enable failed: failed to execute command: command terminated with exit status=30
Is this reproducible--does it happen every time you try to deploy this apimodel? If so, it likely points to something in the model creating a problem. There are many configuration options available to aks-engine and not every possible permutation is workable.
In aks-engine-0.29.1 it happens every time.
I tried the same api-model with the same deployment process with acs-engine 0.24 and there was no issue.
The fact that this is happening on every master VM means that this is not transient. Let's figure out what might have changed between the two versions that could cause this error.
Exit 30 means that kubelet was unable to start.
Could you please check kubelet logs on one of the master VMs? sudo journalctl -u kubelet.
Also, I see that you didn't specify a --non-masquerade-cidr. Please check that value to make sure it is compatible with your Vnet definition.
Seems like these logs aren't complete, can you try sudo journalctl -u kubelet | tail?
Jan 16 16:45:07 k8s-master-88504733-0 kubelet[8036]: F0116 16:45:07.257391 8036 server.go:233] failed to run Kubelet: could not init cloud provider "azure": Getting the managed service identity endpoint: open /var/lib/waagent/ManagedIdentity-Settings: no such file or directory
Jan 16 16:45:07 k8s-master-88504733-0 systemd[1]: kubelet.service: Main process exited, code=exited, status=255/n/a
Jan 16 16:45:07 k8s-master-88504733-0 systemd[1]: kubelet.service: Unit entered failed state.
Jan 16 16:45:07 k8s-master-88504733-0 systemd[1]: kubelet.service: Failed with result 'exit-code'.
Jan 16 16:45:07 k8s-master-88504733-0 systemd[1]: kubelet.service: Service hold-off time over, scheduling restart.
Jan 16 16:45:07 k8s-master-88504733-0 systemd[1]: Stopped Kubelet.
Jan 16 16:45:07 k8s-master-88504733-0 systemd[1]: kubelet.service: Start request repeated too quickly.
Jan 16 16:45:07 k8s-master-88504733-0 systemd[1]: Failed to start Kubelet.
Jan 16 16:45:07 k8s-master-88504733-0 systemd[1]: kubelet.service: Unit entered failed state.
Jan 16 16:45:07 k8s-master-88504733-0 systemd[1]: kubelet.service: Failed with result 'start-limit-hit'.
So Getting the managed service identity endpoint: open /var/lib/waagent/ManagedIdentity-Settings: no such file or directory seems to be the issue here. Let me investigate to see if anything in that surface area changed recently.
Seems like it could be related to https://github.com/Azure/aks-engine/pull/185.
@ritazh do you know what could be happening here?
It seems when "orchestratorVersion": "1.12.1" is used in the api model, you get "orchestratorNameVersionTag": "Kubernetes:1.10.12", which is < v1.11, the supported k8s version for IMDS per this commit: https://github.com/kubernetes/kubernetes/commit/b1b930a39b5a602611023b47fea1063acfd5bc53#diff-681659ab9abb4b4883e78e8aaa980dba
To use a supported v1.12, you can use "orchestratorRelease": "1.12", in your api model.
k8s version 1.12.1 isn't supported in the latest release (1.12.4 is). There is a bug in the deploy command where the version defaults to 1.10.12 instead of returning an error when the version isn't supported. It is currently being fixed. You can track it at https://github.com/Azure/aks-engine/issues/191.
To clarify, Rita's recommendation
To use a supported v1.12, you can use "orchestratorRelease": "1.12", in your api model.
you'll also need to remove "orchestratorVersion": "1.12.1",, so your config will become:
"orchestratorProfile": {
"orchestratorType": "Kubernetes",
"orchestratorRelease": "1.12",
...
}
(or you can use a specific supported orchestratorVersion such as 1.12.4 but that is harder to maintain as you will have to change the version every time a patch is deprecated.)
Thank you
Most helpful comment
To clarify, Rita's recommendation
you'll also need to remove
"orchestratorVersion": "1.12.1",, so your config will become:(or you can use a specific supported
orchestratorVersionsuch as 1.12.4 but that is harder to maintain as you will have to change the version every time a patch is deprecated.)