注意：以下文档只适用于TOP接口，请谨慎使用！
注意：以下文档只适用于TOP接口，请谨慎使用！
1.1 正式环境集群和测试环境集群其实就是两个独立的集群，独立进行资源管理。其他并没有什么区别。
1.2 针对小程序开发，测试环境集群很有用。开发测试的时候通过测试环境网关来调用,这样不影响生产环境。
2.1 写一个helloword应用，试着在K8S里选择官方镜像进行部署，并熟悉应用发布流程。
2.1.1 将软件安装包打包后，外面再打一层zip，发布到/acs/code后会自动解压。
2.1.2 官方镜像里只包含必备的一些组件，可能不能满足实际业务要求。比如不带crond。
2.2 制作自己的私有镜像，并不断优化完善。
2.2.1 私有镜像尽量小并且可容纳的业务不可再分割，有利于更快的版本更新和横向扩容。
2.2.2私有镜像尽量通过环境变量做到可配置，以适应多变的发布需求。
2.3 将应用通过私有镜像部署，并不断强化私有镜像的能力。将原有ECS需要的能力包含在私有镜像中。
2.4 不同的应用类型通过不同的私有镜像部署。
3.1 先迁移对业务影响小的，比如多次部署失败，都不会导致正式服务不可用、停服等。
3.2 先迁移结构简单、业务单一的服务，假如部署失败，能更快的找到原因。
3.3 可根据自己的业务规模来统一购买某个规格的ECS。但是一般不要规格太小，否则会加大资源的浪费。因为每个NODE上都会安装K8S组件，并留足够的资源给K8S，一般购买16C32G、16C64G等高配规格。
3.4 应用迁移后要跟踪验证，不要一次性迁移太多应用。
3.5 尽量先迁移大内存应用，才能让节点内存利用率更高。
3.6 节点磁盘最好买大点，后期磁盘是不方便扩容的。
4.1如开启ARMS，容器需要的内存要多一点，否则容易被驱逐。
4.2 节点磁盘使用率不要超过80%，否则磁盘大户会被强制驱逐。
4.3 内存请求和内存限制尽量设置成一样。
4.4 CPU请求尽量接近服务正常运行后的数值，CPU限制尽量分配的大一点，保证冷启动的时候不因资源不够而卡住。
4.5 容器之间可通过私有SLB进行互访，单个SLB最多可以挂50个端口。
4.6 容器可通过私有域名对ECS进行访问。
4.7 有状态的应用可利用将状态数据迁移到REDIS、OSS、NAS等方式让应用变成无状态。
4.8 容器版本升级的过程是异步销毁旧容器，并启动一个新容器。所以要配置优雅退出脚本，减少同时有多份节点共存的时间。
4.9 节点被移除集群的时候，节点上的应用并不会主动销毁，要注意是否有数据多次处理风险。可将节点重新加回到集群，自动初始化磁盘。
4.10 容器配置目录尽量选择空目录或者nas目录，不配置空目录，文件在节点上是会存储2份的。
4.11 CPU和内存，在生产环境尽量不要设置为0，尽量让K8S来管理应用的部署。
4.12 一个应用多个实例情况下如果代码一样，但是配置不一样，那么可以建立多个环境，每个环境单独一份配置，用好部署配置模板会大大节省时间。
4.13 发布的时候尽量根据实例个数设置发布批数。默认分2批，在服务高峰的时候是比较危险的。
4.14 可通过策略在一个集群里划分出多个小集群。这样可以减少应用的互相影响。
4.15 SLB默认不支持JSON格式的GZIP压缩。可在镜像里安装nginx自己压。
5.1 同一个PVC如果被同个应用多个环境挂载，偶尔会出现无法重启应用的情况。
5.2 在webconsole复制文本很尴尬，经常复制不了。
碰到大促，以前的做法是提前购买ECS，配置ECS环境，部署各种依赖组件，拷贝服务并启动，配置SLB进行分流，配置监控，一套下来起码2个小时。
现在只需要有足够的资源，几秒内就可以完成扩容。大大节省运维时间。
主要体现在CPU和内存资源的节省。对比迁移前后，CPU节省14%，内存节省34%，当然还有很大的压缩空间。
后期要考虑的是如何在不影响应用性能的前提下，让空余内存尽量集中在一起，减少内存碎片化，可以部署更多大内存应用。
不再需要维护应用的启动和停止，不再担心应用无故停服。
不再登记应用部署在哪里，维护一大堆文件夹
不再配置非root用户权限和账号密码。
不再担心环境各种配置的不一致，改环境只要该镜像就好了
7.1 如何和公司的CI打通
7.2 如何自动扩缩容
