K8s 是一个非常优秀的容器集群管理系统，是一个从云虚拟机部署到云容器部署的飞跃发展的过程产品。实现了资源的集中调度、优化部署、优化管理，让运维工作可以更加轻松， 尤其是应用越多越显示其优点。由于聚石塔对于 K8s 产品已经有了非常详细的操作说明，因 此我们的经验总结并不重复这个过程的说明，而是将遇到的实际操作问题做出总结，作为一个补充。
选择合适的集群机器：聚石塔文档有相关的参数说明，每台 ecs 需要有 k8s 的 agent 的资源 消耗，包括 cpu 和内存。太小容易造成浪费，太大的话对于共享资源容易因为应用抢夺资源 导致相互自己相互影响。针对 java 应用一般对于 cpu 和内存的使用统计结果来看，选择 8C32G 的 ecs 组成集群是一个比较好的方案。
1）在迁移之前做好应用登记。一般随着企业的发展，会产生很多的应用，同时因为现在都 是使用分布式架构或者微服务架构，这样各个小应用是很多的。将所有的应用整理出来， 同时按照应用的重要性进行排序，对于编制迁移计划特别重要。
2）识别每个应用的类型，决定是否迁移：一个企业的应用大致分类几类：
a. 淘系功能应用：此类应用占主体，适合迁移。
b. 进程外服务应用：例如自建的nas\kafka\memcache\redis\nginx\zookeeper 之类的， 此类调用尽量先不进入 k8s，因为此类调用一般可能使用 ip 地址直接调用，更改 会导致业务需要集中重启，可能出现业务中断或者隐形关联业务丢失等不可控的风 险。
c. 非淘系应用或者是企业管理软件：此类软件可能有自己的相关周边资源管理的特殊 性，而且进入容器并不能提高其管理的方便性和稳定性，因此不必要迁移。
3）登记每个应用的调用方式：清晰其业务驱动的方式，在迁移的时候作为参考。例如是 http 接口调用方式、dubbo（rpc）调用方式、kafka 消息驱动方式、数据库数据交换方式等。 以上方式在 k8s 中都可以实现。
4）登记每个应用当前的节点部署规模和消耗的 cpu、内存和硬盘使用情况。最好是通过 ecs 控制台了解一段时间内应用的实际消耗情况，以此作为在容器中分配资源的参考。
5）登记每个应用属于有状态还是无状态的应用：无状态应用部署简单，能够充分发挥容器 的弹性资源分配的能力。对于有状态服务，目前阿里云 k8s 也已经提供了 ingress 控制 器方案，可以满足业务的需求，不过需要更多的配置。
1）选择一个最具有业务代表性但是不是核心业务的应用作为迁移的第一个试验。因为虽然 有详细的说明，但是没有对整个流程操作一遍还是无法知道具体的细节的。
2）在迁移过程中会有较多的配置环节，配置环节意味着有很多命名的环节，这个时候需要 特别的关注每项配置中对于取名的限制，因为有些地方命名不规范但是也不会有强约束 的，不看清楚可能在下个环节出现莫名其妙的问题。命名自己需要规范，不要觉得只是 试验随便取名字，必修建立一个自己企业的命名规范，同时建议命名前部分代表业务信 息，后缀部分代表资源信息，这样避免在下游环节出现命名混乱和相同的情况。
3）在试验阶段即认为是正式操作的环节，命名都是按照正式编写，因为有些资源建立之后 不好删除或者修改的。
1）应用迁移必须考虑新旧环境的衔接，尤其是和前端交互的 http 接口服务接入。在容器中 调试运行正确后，通过灰度的方式逐步接入。最好并行运行 24 小时以上直到 100%，确 认没有问题后将旧的应用 ecs 彻底关闭，然后继续查看 24 小时。
2）一般每个应用都会有运行参数的。这些参数不会在发布包中包含，参数必修在容器外获 取，对于使用配置中心问题不大，如果使用配置参数的会有两个方案。一个是通过 ftp 方 式，一个是通过 nas 获取。我们采用前者，在 preshell 参数中通过 ftp 将参数获取到容 器中，使用 nas 方案首先必须有 nas，同时需要做 nas 引入的若干配置，比较复杂不推 荐。 3） 阿里云可以通过控制台操作发布应用，但是这个方式明显不适合大量的应用发布。我们 通过 openapi 去实现发布的过程。我们通过 jenkins 做自动化的编译，然后通过 api 去实 现发布，实现快速的部署。
4）日志是监控应用业务运行情况必不可少的内容，开始由于 k8s 不完善很难查看和配置日 志输出，现在已经很方便，快速的集成到阿里 sls 日志服务中去查看。这里需要关注的 是：
a. 日志的命名的规则约定，不规范可能不会报错，但是日志不能够出来。
b. 错误信息一般由多行表示一条错误，通过正则匹配方式最为合理。
c. 原来配置历史日志可能会有多天，现在在 k8s 容器中可以设置为保留 1 天，因为日 志是实时输出到 sls 中的，日志就没有必要占用空间了。
5）制作自己的环境 docker 镜像很有必要，因为官方鉴于只能提供一个标准的运行环境， 所以自己应用所需要的其它环境软件和调试工具没有集成到里面，因此以官方相似功能 镜像定制一个合适自己的就很必要，而且尽量少差异化的镜像，这样不会过多的占用空
空间。
6）素材类的资源文件采用官方 nas 服务接入，包括静态资源文件。
1）尽量采用阿里云的资源权限管理机制，人员分配权限做合理的管控。
2）日志服务输出的日志作为主要的业务信息查看来源，但是进入容器查看有时候还是必要 的，包括查看应用的运行参数、分配的资源，因此需要通过资源权限管理机制给程序员 分配权限。而创建应用的时候给与分配的开发者角色这些设置是没有权限管理能力的。
3）在应用运行过程中需要关注容器在运行过程中重新启动的次数。出现重新启动一般是两 个原因：一个是动态需求可分配资源不足。二是业务挂掉的原因，这里暂时没有警报信 息，需要自己去关注。
4）由于 java 程序对于内存使用是一个动态请求机制。如果开始即分配最大可能出现的资源 需求会造成可能的浪费，也失去了 k8s 最大程度资源共享的初衷，但是初始请求太小了， 则动态请求的时候可能出现应用重新启动的情况，甚至出现ecs操作系统crack的情况。 因此在后续的使用中应该将应用定义为3个级别。重要级别给与初始最大值的资源分配， 中等级别应用应该关注一定时间对 cpu 和内存的占用情况给与一个平均值的初始分配 值。而对于低等级的应用可以给与一个保守的初始值。这样的策略可以让资源池可以得 到最为合理的分配。
1）目前对于容器重新启动的原因、日志没有历史记录，也没有当时容器占用情况的分析和 报警，对于运维不好进行调优。
2）希望有节点维度的管理监控能力，查看节点上面运行的应用，每个应用当前占用的 cpu、 内存和硬盘空间。
3）增加硬盘空间占用的指标。
1）资源成本：应用从ECS部署迁移到聚石塔K8S容器平台后，ECS资源成本降低40%。
|
ECS 部署 |
K8S 部署 |
应用数量 |
150 |
150 |
POD 数量 |
900 |
900 |
CPU 总量（核） |
700 |
376 |
CPU 平均使用效率 |
35% |
70% |
内存总量（G） |
1960 |
1400 |
内存平均使用效率 |
50% |
70% |
2）运维效率：应用紧急扩容相比以前提速80分钟，以前完成一次应用紧急扩容（从购买机器到扩容上线）需要90分钟，容器化后只需10分钟。
3）应用安全：以前应用异常需要登陆ECS看日志，现在通过容器化集成日志服务，非运维人员不再需要触碰机器。
分享者：广州瑞云网络科技有限公司
