2021-01-31 更新:多跑了几个服务,K8s 经常 100% CPU 占用,太卡了,我又换回了docker-compose。
我树莓派上的各种服务,之前大多数都是基于 docker-compose 跑起来的。 总体来说,其实还不错。不用像直接用 docker 那样需要写长长的命令行,而是把环境变量、目录挂载、端口映射等信息写在 YAML 配置文件中。
比如下面是我的 transmission 下载客户端的 docker-compose 配置文件:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
|
可以看到,非常的简洁明了。而且不出意外地,也工作得非常好。
但是这个五一假期,我做了一件事: 把 docker-compose 干掉了,用了 K8s 代替。
差不多花了整整两天来搞这么东西,遇到了大量的网络问题。非常好,我对网络(像是 ifconfig、route、ip、iptables)的熟悉程度提到了新的高度。没有白折腾。
其实,准备来说不是 K8s,而是 K3s。 K3s 和 K8s 的功能几乎一样。只是少了一些不是特别实用的功能,而且对嵌入式更友好。 比起 K8s 来说,少了很多的 CPU 和内存占用。 没错,我就是在树莓派上跑的 K3s。
下面看看我把上面的 transmission 的 docker-compose 文件转换成 k8s 的 deployment:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 |
|
复杂了很多,是不是?哪个写起来更舒服?当然是 docker-compose 啊。
那么问题来了,我为什么要用 K8s 替换掉 docker-compose?
答案很简单:因为相对于 Kubernetes 来说, docker-compose 简直无人问津。
学了一项技能,但是工作上用不到,有什么用?换句话说,这项技能不能变现。白学了。 其实也没这么极端,只是目前来说,多花时间钻研 K8s(Kubernetes) 的收益远大于 docker-compose。 前几年感觉一直挺浑浑噩噩的,学了一些乱七八糟的东西。你,不要再瞎搞了。
睡觉了,这几天差不多搞了几个通宵,太累了。竟然出现了黑眼圈,而且很严重。 噢对了,明天公司为斋月节(Ramadan)搞活动,还得去值班。能调两天休那种。。。你懂我的意思吧?
晚安,おやすみ。(最近在学日语,iPhone 的键盘很好输入。)