注意：以下文档只适用于TOP接口，请谨慎使用！
注意：以下文档只适用于TOP接口，请谨慎使用！
1. 创建集群时一定要记得下载密钥对，因为后面所有加入集群的服务器都会默认绑定集群密钥对，登录节点时需要使用该密钥对。如果加入集群后需要更改节点绑定的密钥对，更改后需要重启节点。
2. 因集群损耗，新购节点时尽量购买高规格节点，老的多个小节点可以考虑合并成少量的大节点。
3. 因为将节点添加进k8s集群时会初始化服务器，所以现有节点加入集群时，最好确保该节点上所有服务都已停止，所有服务的自动启动都已关闭，备份所有需要的数据，之后创建镜像，如有需要可以及时恢复镜像。
4. 把节点与所有应用的关联全部取消，否则k8s添加节点时将找不到该节点。同时确保节点在运行中，否则也找不到节点。将节点加入集群。
5. 因为与所有应用取消了关联，需要重新添加RDS白名单，建议添加网段。同时确认应用白名单是否已添加。
6. 节点加入集群需要3分钟左右，加入成功后，可以用集群密钥对登录，查看主机名是否正确，如果不对可以自行使用hostnamectl命令设置。
建议做一次系统升级，但需要排除kube及docker相关软件升级，执行命令：
yum update --exclude='kube*' --exclude='docker*' -y
7. 节点绑定标签。
8. 目前节点加入集群后云监控不会自动安装，可以在云监控控制台勾选节点批量安装。
9. 节点移除时，可以先去掉标签，然后重新发布所有存在该节点上的应用，直到所有应用全部迁至其他节点。节点移除后，该节点上的容器将全部停止，重启也不会自动启动。
1. 当迁移响应及时性要求高的应用时，可以考虑先购买等量的临时资源加入集群，通过slb切换流量到集群，如果有问题可以马上切回到老的环境。等集群环境稳定使用一段时间后再把老的节点全部加入集群替换临时节点。
2. 如果服务允许中断，可以考虑买一个临时节点加入集群，迁移一个老节点应用到集群，把老节点加入集群，应用扩容，再逐个节点迁入集群。如果应用允许，也可以考虑一次把所有节点全部迁入集群。
1. 不可调度资源，对于N台ECS的集群来说：
不可调度CPU = N*0.35C + 1C
不可调度内存 = N*500M(折损)+ N* 800M(系统预留)+ N*100M(系统proxy组件占用) + 1000M(集群其他组件)
2. limits必须大于等于requests。
3. 一个节点所有容器设置的requests之和小于等于该节点所有可分配资源。
4. 一个节点所有容器设置的limits之和可以大于该节点资源总量。
5. requests设置过高，集群节点资源利用率就会比较低。因为只有节点可分配资源大于requests时，集群才可能会把容器调度到该节点。
6. 如果混合部署多个应用在同一个节点，低优先级的应用需要设置资源限制，资源限制可以设置的严格一点，小一点。
7. cpu和内存的requests 设置为线上正常在跑资源最大占用量，比如cpu线上如果利用率为187%，则cpu requests可以考虑设置为2。
8. cpu和内存的limits上限可以设置为：节点总资源 - k8s资源损耗 - 所有容器实际消耗资源量。可视情况适度降低。
9. java应用如果没有预热，启动时会出现资源占用飙升，根本解决办法还是解决预热的问题。如果不行，cpu和内存的limits需要设置得高一点，比如正常跑cpu占用2核，启动时会飙到7核，则cpu limits可以考虑设置为8以上，如果又启用了livenessProbe，则可能出现容器不停重启。同时避免一个节点多个容器同时发布启动的情况，可以采用分批发布，每批一个容器实例，同时readinessProbe设置初始等待时间。
10. 测试应用都跑一个容器实例，可以采用争用模式。
1. 跑同一个应用的所有节点资源规格建议一致，并且打上同一个标签，发布应用时指定nodeSelector，让容器调度到指定的一组节点上。
2. 通过设置requests来合理分配每个节点容纳的容器数量，如果需要使每个节点的容器数尽量平均，可以考虑在控制台运维中心添加资源分配策略，启用容器尽力分配到不同宿主机。同时可以考虑把容器实例数设置为节点数的整数倍，资源限制也作相应调整。一般资源够用的情况下，也不用太考虑每个节点容器数均匀化。
1. 如果扩缩容对应用没有影响，则可以创建无状态应用，比如web应用。如果有影响则需要创建有状态应用。
2. 可以把容器名，容器IP地址，宿主机内网IP地址等以环境变量暴露出来，供有需要的容器应用使用。
3. 如果日志收集到nas存储，需要每个容器实例一个日志文件，日志文件名可以加上$POD_NAME，以防止多个容器实例写同一个日志文件导致被覆盖。
4. 默认挂载nas查看日志会有几十秒的延迟，容器挂载nas存储可以加上actimeo=0，禁用客户端缓存，延迟会降低到2-5秒。
5. 如果要实时查看日志，可以使用命令tail -f log_file，但是不能使用tailf。
6. 目前回滚发布策略是分两批，如果应用流量比较大，一半容器撑不住就会导致整个应用服务中断。建议如果需要回滚，可以再次分批发布。
7. dubbo服务可以在preStop中设置优雅下线。
分享者：杭州达西信息技术有限公司
