注意:以下文档只适用于TOP接口,请谨慎使用!

文档中心 > 聚石塔

【风火递】云原生迁移经验分享

更新时间:2020/05/28 访问次数:645

了解集群

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复制文本很尴尬,经常复制不了

 

K8S带来那些方面的收益

6.1 应用扩缩容变得容易。

碰到大促,以前的做法是提前购买ECS,配置ECS环境,部署各种依赖组件,拷贝服务并启动,配置SLB进行分流,配置监控,一套下来起码2个小时。

现在只需要有足够的资源,几秒内就可以完成扩容。大大节省运维时间。

6.2 资源节省。

主要体现在CPU和内存资源的节省。对比迁移前后,CPU节省14%,内存节省34%,当然还有很大的压缩空间。

后期要考虑的是如何在不影响应用性能的前提下,让空余内存尽量集中在一起,减少内存碎片化,可以部署更多大内存应用。

6.3 运维效率提升。

不再需要维护应用的启动和停止,不再担心应用无故停服。

不再登记应用部署在哪里,维护一大堆文件夹

不再配置非root用户权限和账号密码。

不再担心环境各种配置的不一致,改环境只要该镜像就好了

 

后期的一些展望

7.1 如何和公司的CI打通

7.2 如何自动扩缩容

FAQ

关于此文档暂时还没有FAQ
返回
顶部