无法创建Azure服务容器

时间:2017-03-09 17:49:36

标签: azure azure-container-service

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

  

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

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

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

我试过了:

  1. 很难刷新并再次完成整个过程。
  2. 清除我的网络缓存并再次完成整个过程。
  3. 打开隐身窗口并完成整个过程 试。
  4. 我还确保Azure容器服务和Azure容器注册表已在我的订阅ID上注册。最初我尝试部署的资源组设置为UK West,但是在西欧删除并重新创建后,我仍然无法创建服务容器。

    更新:

    我在此案例中获得了Microsoft Azure支持。看起来我的订阅ID无法在西欧地区创建服务容器。这已被提交给技术团队。我收到它时会在这里发布解决方案。

3 个答案:

答案 0 :(得分:0)

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

您显然没有展示如何创建群集,我们需要有关您所遵循的步骤和一些屏幕截图的更多信息。但只是你知道,它确实有效,我刚刚在Az cli 2.0上使用以下命令将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的官方文档:

答案 1 :(得分:0)

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

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

改变了dns,没关系。

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

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

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

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

  • 尝试将您的dns更改为其他内容,它可能无效。虽然它不会告诉你这一点,但只是部署失败。

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

我会在收到的任何进一步相关更新中编辑此答案。

答案 2 :(得分:0)

  1. 即使它通过了所有验证检查,告诉我部署失败也没关系。 改变了dns,没关系。
  2. 现在不应该发生这种情况,因为ACS已经开始出现更详细的错误消息。另外,ACS目前正在推出另一个关于DNS名称已经采取错误的变更,并且应该在~2周内在全球范围内可用。通过此更改,错误消息应该更加详细和可操作。

    1. 确保您已在订阅ID上注册了Azure容器服务和Azure容器注册表。
    2. 用户不需要注册ACR就可以使用ACS,除非他们的场景需要它。

      1. 确保部署到实际支持您的功能的区域,不仅要确保您的资源组位于同一个有效区域。 (它允许您通过选择位于无效区域中的资源组的所有验证)
      2. 我假设你使用门户部署了。有一次,门户网站显示了所有公共Azure区域,而不仅仅是ACS区域。这已经解决了。

        1. 确保您的资源组尚未由之前的失败部署创建。
        2. 这是设计使然(即使资源组名称在全局范围内,也将在资源组所在的区域中创建ACS。)

          1. 尝试将您的dns更改为其他内容,它可能无效。虽然它不会告诉您这一点,但只是部署失败。
          2. 已创建的ACS资源不允许用户更改DNS名称前缀。如果您不介意共享操作ID /资源名称,我可以查看并回复您。