自习周报: 从容器大会到运维大会

2017-09-16 18:08:21 oilbeater 我的观点

在写周报第一期的时候我说不会介绍容器相关的技术,主要因为现在太多和容器相关的技术文章写得比较水,都是想蹭容器的热度或者来做营销,质量就可想而知了。我自己现在周末如果参加技术的线下分享,一看是容器都都会选择忽略掉。记得两年之前容器大会上还经常能看到一些比较新奇的东西,大家都有着自己创意性的黑魔法,而最近都是换汤不换药的持续构建,持续部署,微服务化这样的老东西,甚至在一些付费的会上还能看到有人讲什么是容器,什么是镜像,介绍 Kubernetes 的基础概念这样的事情,作为圈里的人我自己脸上都挂不住。


这不,去年的 CNUTCon 大会还叫全球容器大会,今年就改叫全球运维技术大会了,估计主办方也发现只讲容器大概撑不起一场大会了。尽管这个大会上依然有我说的那些问题,不过还是有几个不错的干货分享值得仔细的看一下,另外扩充了运维的东西也可以看看运维方面的一些新东西。下面就摘几篇我觉得不错的推荐给大家。(可惜我厂容器这块的黑魔法现在不能说出来,不然的话绝对能带来一些全新的思路)


老规矩公众号里回复『 周报5 』获取自习资料,是一个好心人上传的 CNUTCon 17 的全部 ppt,包括我下面要重点介绍的(本来还想列一下哪些就不要浪费时间看的,然而怕被喷就算了,你们也知道容器这个圈子有多乱)。


1. Kubernetes在大规模场景下的 service 性能优化实战

这是一篇华为做的关于 service 利用 iptables 和 IPVS 两种不同实现方式的性能测量。我们都知道 iptables 在性能上有很大的劣势,但是 kubernetes 大概是因为历史原因默认使用了这种方式,小规模还好,但是当存在大量 service 的时候对 iptable 的压力肯定是特别大的。但是这个影响究竟有多大,华为的工程师做了细致的测试,包含了大量的测试数据。随便举量个,在 5k service 的情况下,新加一个 service 刷新 iptable 要 11 分钟,内存花费 1.9G,CPU 消耗 50%~85%。而当有 25k 个 service 的时候带宽就降到 0 了。至于为什么会有这么大的影响以及 IPVS 的性能如何,都可以通过 PPT 仔细的去看下,等待着 IPVS 的 service 实现早日合到主分支。


2. 华为使用Docker支持系统容器的优化实践

依然是来自华为的一篇分享,介绍的是一类之前被提及比较少的容器使用场景——系统容器。一般容器的使用场景划分是有状态无状态,但系统容器会特殊一些,比如需要把 LVS 容器化,LVM 容器化,在容器里管理宿主机的硬件设备,操作 systemd 等等这样一些操控宿主机的操作,如果想容器化会碰到一些意想不到的问题,包括权限,udev, namespace,cgroup 的种种坑。尽管碰到的机会可能不多,但碰到就足够喝一壶的,作者介绍了很多 hack 和 workaround 方法,值得 mark 一下,碰到问题后来借鉴一下。


3. 百度大规模时序指标自动异常检测实战

最近不知道为什么又火了一个词叫 AIOps,尽管这个分享没有蹭这个热词,但是从分享的技术层面上确实是使用了大量统计分析的知识来解决自动化设置监控阈值进行报警的功能。在我当运维的时候加监控报警的时候最头疼的就是该如何设置阈值,有的业务每天是有波动的不是一直在平稳状态,没法设置一个固定值又不能不设,有的业务是随着时间各种指标都会发生变化,之前加的不一定准确,总之加上去的报警不是没有问题误报就是出了问题没报出来,作者提供了最实际可行的通过数据分析的方法来改善当前监控报警不准确,不能动态变化,需要人凭借经验来设置阈值的情况,可以很大的改善监控的情况。


关注公众号在里面回复『 周报5 』获取自习资料。


周末愉快!