结论

上来先发结论，方面出现同样问题的同学解决问题：

问题表现：

新创建的ACK托管版集群节点上被加了污点( node.kubernetes.io/network-unavailable: Effect: NoSchedule )

问题原因：

VPC中每个路由表中可保有的自定义路由条目数量(vpc_quota_route_entrys_num)超过配额限制，被ACK监测到从而给部分集群节点添加了污点标记

解决方法：

1.申请增加vpc_quota_route_entrys_num

1. 2.手动删除对应节点的路由让ccm自动更新（推荐）或移除节点重新加入

问题解决感受：

1.阿里云容器服务kubernetes版本一直在不断地迭代，发展的越来越好，尤其是托管版，对于没有kubernetes专业人才甚至连专业运维人员都确认的企业非常方便适用；当然，阿里云容器服务kubernetes并不完美，还是有一些小问题的。
2.阿里云的支持人员非常敬业，晚上快11点了，还在帮忙排查和解决问题。点个赞。

问题发现和处理过程

下面是问题发现和处理过程，有兴趣或者需要了解详情的同学可以参考下：

近期，因业务需要，在测试环境新搭建了几个阿里云容器服务kubernetes托管版。
原本的#搭建过程非常顺利。在原有VPC网络中新建交换机、配置SNAT路由、创建新集群、指定了Pod网络CIDR和Service CIDR、指定使用新的ECS、配置日志服务等，点击创建集群，过个10来分钟，集群就创建好了。
然后取KubeConfig配置在发布系统中开始发布业务应用。
发布了几个应用之后，问题开始显露出来了。这个测试集群虽然只有几个节点，但也没道理应用一直都只往一个节点上部署啊。

仔细一检查，发现其他几个节点上都有污点。
再仔细一看，发现是创建集群时添加路由失败了。

然后去VPC控制台下检查路由，发现路由是存在的。
跟ACK支持同学确认，怀疑是创建时路由配额满了，导致ACK给节点标记了污点。
至于为啥路由是存在的，我怀疑是ACK有特殊权限，虽然路由满了，但是依然可以成功添加路由；同时，ACK仍然记录了此处路由数的限制问题,而在节点上标记了污点(纯粹合理猜想，因为复现成本较高，所以没有继续排查这方面的原因了)。
找到原因，就可以开始解决了。
首先，在配额管理中申请增加配额。
配额增加后，再查看路由表，没发现变化；查看节点详情，也没有变化，污点依然在，依然没有应用可以调度过去。
那么，试试手动去掉污点应该可以吧。

命令是执行成功了，但不管是describe node还是阿里云控制台上，污点依然在。
试了试调度，这时候有应用可以调度上去了。
好吧，看来是有些地方不太一致啊！
这时候，ACK支持的同学说，可以后台重启下ccm(cloud-controller-manager)，ccm会自动检查路由表并更新状态。
那么，我们就重启下吧。
重启之后，发现节点上的污点标记依然在。
这时候，我试了试把节点从集群中移除然后重新加入，发现污点没有了，节点状态完全正常了。
不过，移除节点再加入的方式比较重，集群处理起来也很慢。
这时候，ACK支持的同学建议把路由手动删除来触发CCM自动更新。
我们手动删除了路由，然后刷新路由表，发现路由很快被加回来了。
然后去查看节点详情，发现节点上的污点已经去掉了；
再调度下业务应用，发现业务应用可以正常调度上去了。
到此，问题解决。