Развертывание Azure AKS вызвало ошибку «InsufficientSubnetSize» - PullRequest
0 голосов
/ 24 июня 2019

Я пытаюсь развернуть экземпляр Azure AKS через шаблон ARM.
У меня есть требование для интеграции экземпляра AKS в существующий Vnet.
У меня есть выделенная подсеть для службы 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 адресами.
У меня есть набор выделенных подсетей в этом Vnetкаждая маска / 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 

Подсеть XX.XX.XX.144 / 28 планируется использовать в AKS.
Текущий экземпляр AKS ARMшаблон выглядит следующим образом:

"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 относится к закрытому диапазону и не мешает моему существующему диапазону Vnet.

Мне нужен совет, как устранить эту ошибку развертывания.

Upd:
Я пробовал развертывание со значениями моей Vnet / подсетей, ноТем не менее, это не удается:
enter image description here

Upd2:

За MS документация "Минимальное количество стручковпри первоначальном создании кластера с использованием типа 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 будетприсутствовать всегда, даже если в шаблоне ARM установлено, например, количество стручков, равное 1.

Upd3:

Однако, поскольку мне не удалось расширить существующий диапазон подсети, мне удалось развернуть экземпляр 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-адресов.

Ответы [ 2 ]

1 голос
/ 24 июня 2019

Для вашей проблемы, когда вы используете сеть модуля Azure, как показано в методе вычисления в других ответах, ваша подсеть может иметь только один узел.Но на самом деле, номер IP-адреса вашей подсети недостаточно только для одного узла.Потому что уже есть стручки, которым требуется IP-адрес при создании кластера AKS по умолчанию, например, сервер метрик и т. Д.

Так что вы можете просто использовать сетевой узел-кублет.В этом модуле только узлу нужен IP-адрес в подсети.И просто используйте этот сетевой модуль, вы можете иметь 3 узла по своему усмотрению и использовать существующую подсеть с 8 IP-адресами.Дополнительные сведения см. В разделе Использование сети kubenet с собственными диапазонами IP-адресов в службе Azure Kubernetes (AKS) .

.
1 голос
/ 24 июня 2019

взяты из документов:

Subnets:

Должно быть достаточно большим, чтобы вместить узлы, модули и все Ресурсы Kubernetes и Azure, которые могут быть предоставлены в вашем кластер. Например, если вы развернете внутренний балансировщик нагрузки Azure, его внешние IP-адреса выделяются из подсети кластера, а не из общего IP-адрес. Размер подсети также должен учитывать операции обновления или будущие потребности масштабирования. Вычислить минимальный размер подсети включая дополнительный узел для операций обновления: (количество узлов + 1) + ((количество узлов + 1) * максимальное количество модулей на узел, который вы настраиваете)

Пример для кластера из 50 узлов: (51) + (51 * 30 (по умолчанию)) = 1,581 (/ 21 или больше)

Пример для кластера из 50 узлов, который также включает в себя положение для увеличения дополнительные 10 узлов: (61) + (61 * 30 (по умолчанию)) = 1891 (/ 21 или больше)

Если вы не указали максимальное количество модулей на узел при создании В вашем кластере максимальное количество модулей на узел установлено равным 30. минимальное количество требуемых IP-адресов основано на этом значении. если ты рассчитать ваши минимальные требования к IP-адресу на другой максимум Посмотрите, как настроить максимальное количество модулей на узел для установки. это значение при развертывании кластера.

это означает, что для вашего случая вам нужно минимум 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

...