1

这听起来像是一个无意义的问题，也许确实如此，但是 Azure 容器服务的一些事情让我有点困惑。我已经成功地在资源组内的 Azure 上启动并运行了一个 Kubernetes 集群，所以对于初学者来说，我已经准备好并完成了。

现在我的问题如下：

  • 谁将负责修补和升级主虚拟机和代理虚拟机？
  • 谁将负责修补和更新 Kubernetes 组件？
  • 我需要自己备份etcd数据库吗？
  • 我是否获得了 Kubernetes 集群的 SLA，或者 VM SLA 之上的一切都取决于我（即确保 Kubernetes 的行为）？

我感觉这些问题的答案是“我”、“我”、“是”和“否”，这不禁让我问自己，ACS 是否只是一组资源管理器模板，或者附加值在哪里？我的假设是对的，还是我错了？

4

2 回答 2

3

我在 Azure 容器服务团队，您的声明：

“ACS 只是一组资源管理器模板”

目前或多或少是正确的（2017 年 1 月）

在接下来的几个月中，我们将改进对您提到的所有场景的支持： * 备份 * 升级 * 健康维护和修复

这不仅适用于 Kubernetes，也适用于 ACS 也支持的 DC/OS 和 Docker Swarm。

如果我能提供更多信息，请告诉我。

于 2017-01-06T22:35:48.820 回答
0

截至 2016 年 12 月 30 日的状态，这将在接下来的几个月内发生变化。

我实际上向微软提出了这些问题，并得到了以下答案：

  • 由我来修补和升级运行 Kubernetes 的虚拟机，即主虚拟机和代理虚拟机
  • Azure 团队尚未决定如何进行 Kubernetes 升级，但至少会有关于如何进行升级的文档，或者通过自动升级，或者如何手动进行（目前相当复杂）
  • 在主 VM 上运行的 vanilla 部署etcd中，将所有内容存储在该计算机的磁盘上，而磁盘又存储在 Azure 中的存储帐户中。这意味着您的etcd数据是相当安全的，即使etcd不是以 H/A 方式运行（使用 3 个或更多专用 VM 来运行etcd）。注意：这是我对这个问题的解释，我没有得到明确的答案。
  • 关于 Kubernetes 上的 SLA：这还完全不清楚，但会在 Azure 上的 Kubernetes 进入 GA 之前解决（也不会）。

总而言之：事情仍在发生一些变化，但看起来很有希望。也许其他人正在寻找这种信息，因此我发布了我自己问题的答案。

于 2016-12-30T14:49:23.547 回答