当您在自我管理的 kubernetes 集群上使用 AKS 时,您不能做什么?

What you cannot do when you use AKS over self-managed kubernetes cluster?

我正在决定是否应该为我的 CI 构建代理提供使用 vanilla kubernetes 或使用 Azure Kubernetes 服务。

使用AKS会失去什么控制;集群内的SSH?打开和关闭 VMS?成本如何,我看到AKS使用的是VM定价,还有没有其他的

我想到了几个限制,但它们都不应该限制您的用例:

  1. 您失去了对主节点(控制平面)的控制。在您的用例中不应该成为问题,而且我很难想象这可能是一个限制。您仍然可以通过 SSH 连接到 AKS 中的工作节点。
  2. 您失去了对工作节点大小的细粒度控制。节点池成为控制 VM 大小的抽象。在自我管理的集群中,您可以将大小完全不同的 VM 附加到集群。在 AKS 中,同一池中的所有节点都必须具有相同的大小(但您可以创建多个具有不同 VM 大小的节点池)。
  3. 无法在 AKS 中选择节点的 OS(基于 Ubuntu)。
  4. 你在k8s的网络插件选择上不够灵活。它是 kubenet 或 Azure CNI。但只要您不使用一些需要 L2 网络的奇怪应用程序,就可以了,更多信息 here

AKS 绝对有好处:

  1. 您没有管理真正的止痛药控制平面。
  2. AKS 可以动态扩展其节点,这对于构建代理等突发性工作负载来说可能是一个不错的选择,但也会在节点扩展过程中造成额外的延迟。
  3. 集群(控制和数据平面)升级只需在 Azure 门户中单击几下。
  4. 控制平面在 AKS 中是免费的(与亚马逊中的 EKS 相比),您只需为工作节点付费,您可以计算您的价格 here