容器服务
一、写在前面
1. 可用(调度)资源
ECS总可用资源：ECS新加入到集群后，机器上剩余可以分配给容器的资源。
集群总可用资源：集群中ECS可用资源总和。
2. 已分配资源
分配给容器的资源，一般来说是部署配置中设置的容器规格(CPU内存请求值)。
集群已分配资源：集群中ECS已分配资源的总和。
3. 集群水位
集群已分配资源 / 集群总可用资源。用于衡量集群内剩余可分配给容器的资源，水位越高，说明剩余可以调度容器的资源越少。
注：运维中心集群列表中的水位展示会有5分钟左右的延迟。
4. 集群可用资源计算原理
首先，每台ECS交付到手后，内存会有500-1000M左右折损，8G的机器实际最大容量只有7.5G(7500M)左右；
其次，每台接入到集群后的ECS，会预留额外的800M内存，给集群内部组件以及除开集群外的其他进程使用(这个是为了保证集群中每个节点的稳定性)；
再次，每台接入到集群后的ECS，会启用集群节点相关组件，占用 0.35C+100M内存；
最后，集群各个核心组件，一共还需要占用1C + 1000M资源，这些资源量会随机地占用集群内机器的资源。
总之，对于N台ECS的集群来说，
不可调度CPU = N*0.35C + 1C
不可调度内存 = N*500M(折损)+ N* 800M(系统预留)+ N*100M(系统proxy组件占用) + 1000M(集群其他组件)。
前面太长只看最后
集群自身总共需要占用资源1.5核 1.5G左右，剩下的才可以用于创建容器。占用是固定的，比如只加一台机器加入集群中，那么该机器就直接被占用了1.5核 1.5G; 后面加入集群的机器，就基本都是可以用资源了。
二、常见问题
1.每台4c8G的机器，只能部署一个2C4G的容器，很浪费
如上面所述，集群管理ECS，实际可以调度的资源可以认为要比购买规格少2G左右，比如购买4C8G的机器，可以用来部署容器的大约3C 6G（如果你只有一两台机器，可能连一个3C 6G的机器也部署不起来，集群规模太小，可能这台机器被占用了很多资源来运行集群核心组件）。另外，为了稳定性，集群要保证资源水位健康，集群中的机器也不建议跑满。
1）建议买更大规格的机器；10台4C8G的机器，不如买5台 8C16G
2）建议增加节点数量，节点越多，集群自身占用的资源就可以忽略不计，其他的资源都可以被集群调度了
3）建议增加集群中的实例规格类型，大小搭配，可以将集群可调度的资源发挥到最大
2.Insufficient cpu Insufficient memory
如果提示Insufficient cpu, 则说明集群cpu核数不足以支撑本次发布; 如果提示Insufficient memory, 则说明集群内存资源不足以支撑本次发布; 即添加到集群的ECS上，没有可以调度给容器的资源了。具体剩余资源可以在集群详情-基本信息里看到。
解决方案：
1）添加其他ECS或者垂直升级ECS规格
2）部署配置中，调小容器规格，然后重新提交一次发布单
很多伙伴会有疑惑，为什么我一台或者两台 2核的机器，连1核的容器都部署不起来？
简而言之，机器太少了，资源太少了。由于集群自身需要占用资源，总的大概1.5vCPU 1.5G左右，如果你只有一台机器，那么资源都被集群占用了。后面新加机器就不会了，因为集群的占用基本是固定的
3.集群管理中工作负载说明
1）“请求值”为部署配置中设置的请求值，即已分配资源。
2）“使用量”是每台ECS实际使用量的总和，实际使用量和请求值没有必然联系。
3）剩余可分配的容器数量为什么和集群中总的剩余可分配不符？
容器是(动态)分配到机器上的，单个机器上剩余可分配资源要比容器请求值大才能创建出容器。
举个例子：每台机器剩余0.5核，十台机器的集群一共剩余可分配5核。假设内存充足，那么依然无法部署1vcpu的容器。可以部署一些对cpu要求不高的应用，设置容器规格0.5，则可以利用每台ECS上的剩余资源了。