Kubernetes Virtual Node Pool虚拟机意外收费

Question

我在Azure中使用Kubernetes with Virtual Nodes .这是一个使用Azure容器实例创建虚拟节点的插件。

设置这个的说明需要创建一个AKSNet/AKSSubnet，它似乎自动伴随着一个VMSS，称为类似的东西。我按照下面链接上的说明操作了。

https://learn.microsoft.com/en-us/azure/aks/virtual-nodes-cli

这是一个单实例虚拟机，无论我创建什么容器实例，我都要支付全价，并且我要为我的虚拟节点池提供每个容器实例收取额外费用，即使它们只适合1个虚拟机。这些资源似乎没有关系。

我目前正在处理微软的意外账单，但这个过程非常缓慢，所以我回到这里看看是否有人有过这样的经历?

我的主要问题是:

• 我可以使用没有VMSS的Azure容器实例吗?
• 如果不是，我可以以某种方式使这个VM对我的集群可见，这样我至少可以使用它来提供容器并从中获得一些价值?
我刚才做错了什么吗?

更新，注意:这不是我的控制节点，这是一个B2s，我可以看到我的系统容器运行。

任何建议都会很有帮助。

Answer 1

可以在没有VMSS的情况下使用Azure容器实例吗?

当前在AKS集群中不能有没有节点池的虚拟节点类型为VirtualMachineScaleSets或AvailabilitySet。AKS集群至少有一个节点，一个运行Kubernetes节点组件和容器运行时的Azure虚拟机(VM)。[参考文献]每个AKS集群中至少包含一个系统节点池，该系统节点池中至少包含一个节点。系统节点池的主要用途是承载CoreDNS、kube-proxy和metrics-server等关键系统pod。但是，如果您希望在AKS集群中只有一个池，则可以在系统节点池上调度应用程序pod。

有关系统节点池的更多信息，请查看本文档。

实际上，如果您运行kubectl get pods -n kube-system -o wide，您将看到所有的系统pod都在vmss支持的节点池节点上运行，包括连接集群到虚拟节点的aci-connector-linux-xxxxxxxx-xxxxx pod，如下所示:

NAME                                  READY   STATUS    RESTARTS   AGE   IP            NODE                                NOMINATED NODE   READINESS GATES
aci-connector-linux-859d9ff5-24tgq    1/1     Running   0          49m   10.240.0.30   aks-nodepool1-29819654-vmss000000   <none>           <none>
azure-cni-networkmonitor-7zcvf        1/1     Running   0          58m   10.240.0.4    aks-nodepool1-29819654-vmss000000   <none>           <none>
azure-ip-masq-agent-tdhnx             1/1     Running   0          58m   10.240.0.4    aks-nodepool1-29819654-vmss000000   <none>           <none>
coredns-autoscaler-6699988865-k7cs5   1/1     Running   0          58m   10.240.0.31   aks-nodepool1-29819654-vmss000000   <none>           <none>
coredns-d4866bcb7-4r9tj               1/1     Running   0          49m   10.240.0.12   aks-nodepool1-29819654-vmss000000   <none>           <none>
coredns-d4866bcb7-5vkhc               1/1     Running   0          58m   10.240.0.28   aks-nodepool1-29819654-vmss000000   <none>           <none>
coredns-d4866bcb7-b7bzg               1/1     Running   0          49m   10.240.0.11   aks-nodepool1-29819654-vmss000000   <none>           <none>
coredns-d4866bcb7-fltbf               1/1     Running   0          49m   10.240.0.29   aks-nodepool1-29819654-vmss000000   <none>           <none>
coredns-d4866bcb7-n94tg               1/1     Running   0          57m   10.240.0.34   aks-nodepool1-29819654-vmss000000   <none>           <none>
konnectivity-agent-7564955db-f4fm6    1/1     Running   0          58m   10.240.0.4    aks-nodepool1-29819654-vmss000000   <none>           <none>
kube-proxy-lntqs                      1/1     Running   0          58m   10.240.0.4    aks-nodepool1-29819654-vmss000000   <none>           <none>
metrics-server-97958786-bmmv9         1/1     Running   1          58m   10.240.0.24   aks-nodepool1-29819654-vmss000000   <none>           <none>

但是，您可以部署Azure容器实例[如何]，而不需要AKS集群。对于需要完整容器编排的场景，包括跨多个容器的服务发现、自动扩展和协调应用程序升级，我们建议使用Azure Kubernetes service (AKS)。

如果不是，我可以以某种方式使这个VM对我的集群可见，所以我至少可以使用它来配置容器并从中获得一些价值?

当然可以。实际上，如果您执行kubectl get nodes，并且来自vmss支持的节点池的节点(在您的示例中为aks-control-xxx-vmss-x)将STATUS显示为Ready，那么kube-scheduler就可以使用它来调度工作负载。请检查这份文件。

如果您执行kubectl describe node virtual-node-aci-linux，您应该在输出中发现以下内容:

...
Labels:             alpha.service-controller.kubernetes.io/exclude-balancer=true
beta.kubernetes.io/os=linux
kubernetes.azure.com/managed=false
kubernetes.azure.com/role=agent
kubernetes.io/hostname=virtual-node-aci-linux
kubernetes.io/role=agent
node-role.kubernetes.io/agent=
node.kubernetes.io/exclude-from-external-load-balancers=true
type=virtual-kubelet
...
Taints:             virtual-kubelet.io/provider=azure:NoSchedule
...

在您所遵循的文档中，在部署示例应用程序一节中调度虚拟节点上的容器，在部署示例应用程序一节中定义了nodeSelector和容差，如下所示:

...
nodeSelector:
kubernetes.io/role: agent
beta.kubernetes.io/os: linux
type: virtual-kubelet
tolerations:
- key: virtual-kubelet.io/provider
operator: Exists
- key: azure.com/aci
effect: NoSchedule

如果您从Deployment清单中删除此部分，或者未在您正在部署的工作负载的清单中指定此部分，则相应的资源将在vmss支持的节点上调度。

我刚才做错了什么吗?

也许你可以根据我对你之前问题的回答来评估这个问题的答案。不过，这里还有一些内容可以帮助您理解:

如果一个节点没有足够的计算资源来运行一个请求的pod，那么这个pod就不能通过调度进程。除非节点池中有额外的计算资源可用，否则pod无法启动。

当集群自动伸缩器注意到由于节点池资源限制而无法调度的pod时，将增加节点池中的节点数量以提供额外的计算资源。当这些额外的节点被成功部署并且可以在节点池中使用时，pod就会被安排在它们上面运行。

如果您的应用程序需要快速伸缩，一些pod可能会保持等待调度的状态，直到集群自动伸缩器部署的其他节点可以接受调度的pod。对于具有高突发需求的应用程序，您可以使用虚拟节点和Azure容器实例进行扩展。

然而，并不意味着我们可以免除VMSS或可用性集支持的节点池.