Skip to main content

Nichi Yorozuya

Notes on infrastructure

       咕咕了好久,总算抽出时间来写点东西了其实只是懒。这次就写写关于基础设施的一些想法吧。个人很喜欢基础设施与分布式系统,也断断续续地部署了不少公开服务(大多短命而死。目前只剩下了一个个人源和一个反代,还有的话就是关于基础设施的一些经验了。(容器相关,不喜勿看)

       个人用IaaS比较多,这里就跳过baremetal相关的内容了,如果确实需要部署大量裸机的话,C社的MaaS似乎不错的样子。至于host system的选择,我的偏好是vendor optimized distro>常规发行版>特化发行版。何为vendor optimized distro?如AWS上的Amazon Linux。作为基础设施的一部分,host system所起到的概念与其说是一个运行环境,称为capacity provider更为恰当。故而与其要求host system能带给我什么先进的特性,我更加希望它能给我的workload提供一个稳定、高性能的、受商业化支持的平台,而vendor optimized distro恰恰符合这一点。当然它也有它存在的问题,如vendor lock-in,或者陡峭的学习曲线,不过这一切正逐渐被容器化所抹平。再说特化发行版,在如今的语境下,特化发行版几乎已经成为了容器运行时的代名词,最小化的基础系统,塞上个oci compatible runtime,没了。确实,我的workload也几乎全部以容器的形式存在,使用一个为容器特化的发行版似乎也无不妥,事实上,我也很赞同这种减小attack surface的方式。如果是on-premise的集群,我也会毫不犹豫的选择它。但IaaS平台通常也会提供CaaS,如AWS Fargate,此时再选择特化发行版无异于为自己增加麻烦,既无法获得serverless computing带来的弹性伸缩,debug时也往往会因utility的缺失而手足无措。

       再说容器调度器,曾经的我很反感在小规模集群上使用kubernetes,一套reference deployment(此指kubeadm的标准部署)会在每个节点上占用约0.8GiB的内存,显然是无法接受的。故而我长时间使用docker-compose配合docker swarm做集群管理。然后?真香!rancher开发了一套精简化的certified k8s distro,k3s(嗯,还真是恶趣味的名字呢。k3s作为单一二进制分发,具有极低的memory fingerprint,并整合了一套简单的LB/ingress controller与storage provider,足以在苛刻的限制下运行一个高可用的集群(Why not if we can?¯\_(ツ)_/¯ (gpu hang again…… 5.4.2内核的i915驱动还是没修好诶….)