首页 文章

无法创建Azure服务容器

提问于
浏览
4

我试图在英国西部地区创建一个Azure服务容器 . 我经历了所有步骤而没有问题,但是一旦我点击“创建”一段时间后我遇到了:

LocationNotAvailableForResourceType提供的位置'ukwest'不适用于资源类型'Microsoft.ContainerService / containerServices' . 资源类型的可用区域列表是'japaneast,centralus,eastus2,japanwest,eastasia,southcentralus,australiaeast,australiasoutheast,brazilsouth,southeastasia,westus,northcentralus,westeurope,northeurope,eastus' .

好吧,我意识到这是我的错误,并继续在西欧创建容器 .

现在,当我尝试创建容器时,尽管将位置设置为西欧,但我遇到了同样的错误 .

我试过了 :

  • 难以刷新并再次完成整个过程 .

  • 清除我的网络缓存并再次完成整个过程 .

  • 打开隐身窗口并再次完成整个过程 .

我还确保Azure容器服务和Azure容器注册表在我的订阅ID上注册 . 最初我尝试部署的资源组设置为UK West,但是在删除并在West Europe上重新创建后,我仍然无法创建服务容器 .

Update:

在这种情况下,我有Microsoft Azure支持 . 看起来我的订阅ID无法在西欧地区创建服务容器 . 这已被提交给技术团队 . 我收到它时会在这里发布解决方案 .

3 回答

  • 0

    westeurope区域支持Azure容器服务,您可以在此链接中看到服务的支持:

    您显然没有展示如何创建群集,我们需要有关您所遵循的步骤和一些屏幕截图的更多信息 . 但是你知道, it actually works ,我刚刚在'westeurope'上使用以下命令将kubernetes集群部署到了'westeurope':

    RG=stackoverflowtest
    LOCATION=westeurope
    az group create --name=$RG --location=$LOCATION
    az acs create --orchestrator-type=kubernetes --resource-group $RG --name=$CLUSTER_NAME --dns-prefix=$DNS_PREFIX
    

    这是5-10分钟后得到的结果:

    creating service principal.........done
    waiting for AAD role to propagate.done
    {
      "id": "/subscriptions/xxxxxxxx-xxx-xxxx-xxx-xxxxxxxxxxxd/resourceGroups/stackoverflowtest/providers/Microsoft.Resources/deployments/azureclixx.xx",
      "name": "azureclixx.xx",
      "properties": {
        "correlationId": "xxxxxxx-xxxx-xxx-xxxx-xxxxxxxxxx",
        "debugSetting": null,
        "dependencies": [],
        "mode": "Incremental",
        "outputs": null,
        "parameters": {
          "clientSecret": {
            "type": "SecureString"
          }
        },
        "parametersLink": null,
        "providers": [
          {
            "id": null,
            "namespace": "Microsoft.ContainerService",
            "registrationState": null,
            "resourceTypes": [
              {
                "aliases": null,
                "apiVersions": null,
                "locations": [
                  "westeurope"
                ],
                "properties": null,
                "resourceType": "containerServices"
              }
            ]
          }
        ],
        "provisioningState": "Succeeded",
        "template": null,
        "templateLink": null,
        "timestamp": "2017-03-14T21:00:39.066034+00:00"
      },
      "resourceGroup": "stackoverflowtest"
    }
    

    而且,这是关于如何部署kubernetes ACS的官方文档:

  • 0

    好的,所以我已经和我一起使用MSFT支持了几个星期 . 解决方案!

    我有一个你无法使用的dns . 即使它通过了所有验证检查,告诉我部署失败也没问题 .

    改变了dns,没关系 .

    所以总结一下你需要做的所有事情,它没有在任何地方陈述:

    • 确保已在订阅ID上注册Azure容器服务和Azure容器注册表 .

    • 确保部署到实际支持您的功能的区域,不仅要确保您的资源组位于同一个有效区域 . (它允许您通过选择位于无效区域中的资源组的所有验证)

    • 确保先前失败的部署尚未创建您的资源组 .

    • 尝试将您的DNS更改为其他内容,它可能无效 . 虽然它不会告诉你这个,但是部署失败了 .

    • 本质上根本不信任Azure上的验证 . 它会告诉你,你能做的事情,一切都很好,而事实并非如此 .

    我将使用我收到的任何进一步相关更新来编辑此答案 .

  • 0
    • 即使它通过所有验证检查,告诉我's fine the deployment failed. Changed the dns and it'很好 .

    现在不应该发生这种情况,因为ACS已经开始出现更详细的错误消息 . 另外,ACS目前正在推出另一个关于DNS名称已经采取错误的变更,并且应该在~2周内在全球范围内可用 . 通过此更改,错误消息应该更加详细和可操作 .

    • 确保已在订阅ID上注册Azure容器服务和Azure容器注册表 .

    除非他们的场景需要,否则用户无需注册ACR即可使用ACS .

    • 确保部署到实际支持您的功能的区域,不仅要确保您的资源组位于同一个有效区域 . (它允许您通过选择位于无效区域中的资源组的所有验证)

    我假设您使用门户部署 . 有一次,门户网站显示了所有公共Azure区域,而不仅仅是ACS区域 . 这已经得到修复 .

    • 确保你的先前失败的部署尚未创建资源组 .

    这是设计的(即使资源组名称在全局范围内,也将在资源组所在的区域中创建ACS) .

    • 尝试将您的DNS更改为其他内容,它可能无效 . 虽然它不会告诉你这个,但是部署失败了 .

    已创建的ACS资源不允许用户更改DNS名称前缀 . 如果您不介意共享操作ID /资源名称,我可以查看并回复您 .

相关问题