K8S system OOM 和资源配置实践
背景
我们目前服务是托管在 Aws K8S 的,近期出现了一次由于生产环境流量增大而导致的 system OOM 问题,进而导致了部分核心业务受损。在此之前,团队并没有思考过关于 K8S 资源配置上存在的一些问题,也没有按照业务自身情况使用对应的 QoS 类,从而导致了故障的产生。
本文将从这个角度切入,对 K8s 中的资源属性以及 QoS 进行介绍,最后给出生产环境使用的一些建议。
我们目前服务是托管在 Aws K8S 的,近期出现了一次由于生产环境流量增大而导致的 system OOM 问题,进而导致了部分核心业务受损。在此之前,团队并没有思考过关于 K8S 资源配置上存在的一些问题,也没有按照业务自身情况使用对应的 QoS 类,从而导致了故障的产生。
本文将从这个角度切入,对 K8s 中的资源属性以及 QoS 进行介绍,最后给出生产环境使用的一些建议。
一个业务量很小的系统,所有的代码都放在一个项目中,部署在一台服务器上。所有的服务都由这台服务器提供,这就是常说的单机模式;我们知道单机模式的缺点是:1、处理能力有限,2、存在单点问题。单机模式大致如下图所示:
为了解决这些问题,出现了集群模式。
在传统IT企业,项目的架构是什么样的呢?无论项目内部的如何复杂,都可简化分为前台和后台两部分,也就是垂直的烟囱式架构(业内人士把见招拆招、垂直化发展、未做足够抽象通用的架构称之为烟囱型架构)。什么是前台?所谓前台即包括各种和消费者用户直接交互的界面业务功能,比如web页面(PC端),手机app(无线端或移动端)。什么是后台?后台是面向运营人员的配置管理系统,比如商品管理、物流管理、结算管理。后台为前台提供业务管理等。前台、后台、用户之间的关系,可以用下图简单表示:
本篇主要来看下蚂蚁金服开源的 SOFAArk 这个产品。SOFAArk 是一款基于 Java 实现的轻量级类隔离容器,主要提供类隔离和应用(模块)合并部署能力;本文主要基于 telnet 指令的方式进行应用 Biz 的装载和卸载操作。去年在上海 KubeCon 大会上有分享过 《SOFABoot 动态模块实践》,主要是通过 SOFADashboard 来下发指令的,基于 SOFABoot 3.1.4 和 SOFAArk 0.6.0 版本;目前 SOFABoot 已经发布到 3.3.x+ ,SOFAARK 1.1.1 版本,其中 ,SOFAARK 提供了很多新的特性,包括全生命周期的事件机制、卸载优化等。