Я пытаюсь развернуть экземпляр Azure AKS с помощью шаблона ARM.
Мне нужно интегрировать экземпляр AKS в существующую виртуальную сеть.
У меня есть выделенная подсеть для службы AKS.
Однако развертывание завершилось со следующей ошибкой:
{"code":"DeploymentFailed","message":"At least one resource deployment operation failed.
Please list deployment operations for details. Please see
https://aka.ms/arm-debug for usage details.","details":
[{"code":"BadRequest","message":"{\r\n \"code\": \"InsufficientSubnetSize\",\r\n
\"message\": \"Pre-allocated IPs 93 exceeds IPs available in Subnet 11\",\r\n
\"target\": \"agentPoolProfile.count\"\r\n}"}]}
Я использую следующее адресное пространство для Vnet: XX.XX.XX.0/24 (XX.XX.XX.0 - XX.XX.XX.255
, которое имеет 256 адресов.
У меня есть набор выделенных подсетей в этой виртуальной сети, каждая из которых имеет маску /28 (глубина 11+5 адресов):
XX.XX.XX.0/28
XX.XX.XX.16/28
XX.XX.XX.64/28
XX.XX.XX.128/28
XX.XX.XX.144/28
XX.XX.XX.160/28
XX.XX.XX.176/28
Подсеть ХХ.ХХ.ХХ.144/28 планируется использовать в АКС.
Текущий шаблон ARM экземпляра AKS выглядит следующим образом:
"resources": [
{
"type": "Microsoft.ContainerService/managedClusters",
"apiVersion": "2019-04-01",
"name": "[parameters('resourceName')]",
"location": "[parameters('location')]",
"dependsOn": [],
"tags": {},
"properties": {
"kubernetesVersion": "[parameters('kubernetesVersion')]",
"enableRBAC": "[parameters('enableRBAC')]",
"dnsPrefix": "[parameters('dnsPrefix')]",
"agentPoolProfiles": [
{
"name": "agentpool",
"osDiskSizeGB": "[parameters('osDiskSizeGB')]",
"count": "3",
"vmSize": "[parameters('agentVMSize')]",
"osType": "[parameters('osType')]",
"storageProfile": "ManagedDisks",
"maxPods": "30",
"vnetSubnetID": "/subscriptions/XXXXX/resourceGroups/XXXX/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/akssubnet"
}
],
"servicePrincipalProfile": {
"ClientId": "[parameters('servicePrincipalClientId')]",
"Secret": "[parameters('servicePrincipalClientSecret')]"
},
"networkProfile": {
"networkPlugin": "azure",
"serviceCidr": "10.0.0.0/16",
"dnsServiceIP": "10.0.0.10",
"dockerBridgeCidr": "172.17.0.1/16"
},
"addonProfiles": {
"httpApplicationRouting": {
"enabled": "[parameters('enableHttpApplicationRouting')]"
},
"omsagent": {
"enabled": "[parameters('enableOmsAgent')]",
"config": {
"logAnalyticsWorkspaceResourceID": "[parameters('omsWorkspaceId')]"
}
}
}
}
},
"subscriptionId": "[split(parameters('omsWorkspaceId'),'/')[2]]",
"resourceGroup": "[split(parameters('omsWorkspaceId'),'/')[4]]"
}
]
Параметры сетевого профиля были установлены в соответствии со следующей статьей: Справочник по шаблону управляемых кластеров Microsoft.ContainerService
CIDR 10.0.0.0/16 относится к частному диапазону и не мешает моему существующему диапазону виртуальной сети.
Мне нужен совет, как справиться с этой ошибкой развертывания.
Обновление:
Я пробовал развертывание со значениями моей виртуальной сети/подсетей, но все равно не получается:
Обновление2:
Согласно документации РС «Минимальное количество модулей при первоначальном создании кластера с использованием типа Azure CNI равно 30», что приводит к следующему количеству диапазонов подсетей в моем случае в соответствии с формула: (number of nodes + 1) + ((number of nodes + 1) * maximum pods per node that you configure) = (3+1) + ((3+1)*30) = 124
Таким образом, множитель 30 будет всегда присутствовать, даже если количество модулей установлено, например, на 1 в шаблоне ARM.
Обновление 3:
Однако, поскольку мне не удалось расширить существующий диапазон подсети, мне удалось развернуть экземпляр AKS, используя следующую конфигурацию:
"parameters": {
"SvcCidr": {
"type": "string",
"defaultValue": "10.0.0.0/16",
"metadata": {
"description": "Maximum number of pods that can run on a node."
}
},
"PodCidr": {
"type": "string",
"defaultValue": "10.244.0.0/16",
"metadata": {
"description": "Maximum number of pods that can run on a node."
}
},
"DnsSvcIP": {
"type": "string",
"defaultValue": "10.0.0.10",
"metadata": {
"description": "Maximum number of pods that can run on a node."
}
},
"DockerCidr": {
"type": "string",
"defaultValue": "",
"variables": {
"vnetSubnetId": "[resourceId(resourceGroup().name, 'Microsoft.Network/virtualNetworks/subnets', parameters('vnetName'), parameters('vnetSubnetName'))]",
"resources": [
{
"type": "Microsoft.ContainerService/managedClusters",
"agentPoolProfiles": [
{
"vnetSubnetID": "[variables('vnetSubnetId')]",
"networkProfile": {
"networkPlugin": "[parameters('NetPlugin')]",
"serviceCidr": "[parameters('SvcCidr')]",
"podCidr": "[parameters('PodCidr')]",
"DNSServiceIP": "[parameters('DnsSvcIP')]",
"dockerBridgeCidr": "[parameters('DockerCidr')]"
Это приводит к предоставлению IP-адресов диапазона моей подсети только узлам кластера, в то время как модули будут использовать диапазон частных IP-адресов.
взято из документов:
Subnets:
Must be large enough to accommodate the nodes, pods, and all Kubernetes and Azure resources that might be provisioned in your cluster. For example, if you deploy an internal Azure Load Balancer, its front-end IPs are allocated from the cluster subnet, not public IPs. The subnet size should also take into account upgrade operations or future scaling needs. To calculate the minimum subnet size including an additional node for upgrade operations: (number of nodes + 1) + ((number of nodes + 1) * maximum pods per node that you configure)
Example for a 50 node cluster: (51) + (51 * 30 (default)) = 1,581 (/21 or larger)
Example for a 50 node cluster that also includes provision to scale up an additional 10 nodes: (61) + (61 * 30 (default)) = 1,891 (/21 or larger)
If you don't specify a maximum number of pods per node when you create your cluster, the maximum number of pods per node is set to 30. The minimum number of IP addresses required is based on that value. If you calculate your minimum IP address requirements on a different maximum value, see how to configure the maximum number of pods per node to set this value when you deploy your cluster.
это означает, что для вашего случая вам нужно минимум 30 * 4 + 4 = 124 IP-адреса, необходимых для этого, но имейте в виду, что если вы захотите добавить 4 узла и обновить, это не сработает. если вы захотите масштабироваться до 5 узлов, это не сработает. Кроме того, какой смысл, если такие маленькие подсети? вы не платите за размер подсети, поэтому сделать их достаточно большими не проблема
означает, что вам нужно / 25, технически. 128-4 (зарезервировано лазурью) = 124 ;)
Чтение: https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni#plan-ip-addressing-for-your-cluster
нет, ни один из них не должен перекрываться, а serviceCidr — это виртуальный диапазон IP-адресов, он не обязательно должен находиться в подсети (на самом деле лучше, чем без диапазона подсети). vnetsubnetid — идентификатор ресурса рабочих узлов vnet kubernetes, которые получают предоставление. servicecidr — диапазон виртуальных IP-адресов для модулей в kubernetes.
Большое спасибо. Оставив свои первоначальные настройки как есть (vnetSubnetID XX.XX.XX.144/28, serviceCidr 10.0.0.0/16), в соответствии с вашими расчетами выше, с параметром «maxPods», установленным на «1» (поскольку он находится в диапазоне 1 -110) развертывание должно быть в порядке. Количество IP-адресов равно 1*4+4 = 8, что соответствует моей маске /28. Но это не удается, и (та же) ошибка четко гласит: при развертывании было предварительно выделено 93 IP-адреса, но в указанной подсети доступно только число 11. Таким образом, вопрос - почему число 93 вычисляется, если число 8 должно быть? Что не так с моим конфигом, я не могу понять.
ваше максимальное количество стручков установлено на 30, и установка его на 1 не имеет смысла. вы сможете иметь только 1 контейнер на узел
Попросили сеанс чата, чтобы оставить зону комментариев
Что касается вашей проблемы, когда вы используете сеть модулей Azure, как показано в методе расчета в других ответах, в вашей подсети может быть только один узел. Но на самом деле номера IP-адреса вашей подсети недостаточно только для одного узла. Потому что уже есть поды, которым нужен IP-адрес при создании кластера AKS по умолчанию, например, сервер метрик и т. д.
Так что вы просто можете использовать сетевой узел kubelet. В этом модуле только узлу нужен IP-адрес в подсети. И просто используйте этот сетевой модуль, вы можете иметь 3 узла по своему усмотрению и использовать существующую подсеть всего с 8 IP-адресами. Дополнительные сведения см. в статье Используйте сеть kubenet с собственными диапазонами IP-адресов в службе Azure Kubernetes (AKS)..
Если я вас правильно понял, вы советуете перейти на kubenet вместо Azure CNI. Однако kubenet не поддерживает интеграцию с Vnet, что в моем случае является обязательным требованием. Не могли бы вы подтвердить, что с помощью kubenet я смогу интегрировать кластер AKS в существующую виртуальную сеть?
@Сергей А почему бы и нет? Вы можете использовать идентификатор подсети так же, как вы используете сетевой модуль Azure.
Поскольку параметр vnetSubnetID опускается, когда во время развертывания используется kubenet, не могли бы вы посоветовать, какое из следующих значений следует заменить моим существующим диапазоном подсети виртуальной сети — Pod CIDR или Service CIDR?
@Сергей Это сработает, даже если вы ничего не измените. Модули будут использовать метод NAT для связи с внешним миром через IP-адрес узла. Просто замените networkPlugin
значением kubelet
.
Пожалуйста, смотрите мой первоначальный пост обновлен. Спасибо за совет, я перешел на этот подход из-за ограничений.
Вероятно, вы правы. Я выбрал ваш подход, и объяснение @4c74356b41 было о том, как все работает под капотом. Изменил свое решение наоборот.
@Sergey Расчет, который он сказал, верен. Но для вас IP-номера существующей подсети недостаточно. Так что вы просто можете использовать сетевой модуль kubelet. Это окончательный результат.
Не могли бы вы уточнить — значение «vnetSubnetID» и значение «serviceCidr» должны быть в пределах одной виртуальной сети, но принадлежать разным подсетям? Или «serviceCidr» должен быть «частью» «vnetSubnetID»?