水族馆

K8s Optimise

阅读时间 1 分钟


记录一次 kubernetes 内的服务优化经历

我们最近有一个互联网数据采集的项目,号称要采集所有主流平台的舆情信息。项目成员有两个人,一位是爬虫同事,负责编写所有平台的采集程序和攻破反爬验证。另一位是我,负责开发给爬虫任务调度的 API 并运维一堆数据采集服务器。

据组里一位资历很深的 Java 老哥说,他们前公司有一个庞大的爬虫运维团队,每天的任务就是一台台登录服务器更新爬虫。“一杯茶,一口烟,一个部署搞一天”是他们的常态。鉴于现在运维只有我一个人,使用 kubernets 自动化部署和运维应该是非常合理的方案。但是组里一些站着说话不腰疼的 Java 老登还是认为 k8s 没必要,最多用个 docker + 脚本就能解决问题。我不知道他是否言之有理,但是这种抗拒新事物的态度狠狠加深我对 Java 佬的刻板印象。

我们的爬虫和接口很快就开发好了,两个都是无状态的程序。爬虫使用 python 开发,根据任务从指定的目标采集数据,然后将数据发送到集群外的 kfaka 队列。接口使用 golang 开发,负责给爬虫提供任务,管理任务状态,并使用一些缓存来保证快速响应。

整体逻辑并不复杂,我们期望这一套程序能够最大化爬取速度直到遇到网络 / CPU / 内存等硬件瓶颈。但是现实很残酷,我们遇到的问题数量远超想像,其中大部分是 skill issue,让我慢慢道来。

滥用 ingress

为了方便爬虫在集群外部调用集群内部的接口,我设置了一个 nginx load balancer 的入口和 api.k8s.local 的 ingress 规则。让外部的应用可以使用 api.k8s.local 这个域名访问到集群内部的服务,路径大致如下

h t i t n p g : r / e / s 1 s 9 - 2 n . g 1 i c 6 n s l 8 x e i . r p e 1 l v o n . o i d t 1 a c 3 d e : 8 b 0 a l ( a a n p c i e . r k 8 s . l o c a l