在kubernetes上运行WASM负载
WASM一般用在前端业务中,但目前有扩展到后端服务的趋势。本文使用Krustlet 将WASM服务部署到kubernetes。
简介
Krustlet 是一个可以在kubernetes本地运行WebAssembly负载的工具。Krustlet作为kubernetes集群中的节点。当用户使用特定node tolerations来调度Pod时,kubernetes API会将该负载调度到一个Krustlet节点,Krustlet会拉取并运行模块。
为了在Krustlet 节点上运行一个应用,首先必须将该应用编译为WebAssembly 格式,并推送到镜像仓库中。
准备
首先使用kind安装一个kubernetes集群(minikube要求使用virtualBox驱动)。
安装Krustlet
安装二进制文件
首先从官网下载并安装Krustlet,拷贝到一个系统可识别的路径即可(如/usr/local/bin
)
生成bootstrap文件
Krustlet和kubelet的初始化流程类似,执行如下命令生成Krustlet的bootstrap.conf
文件,默认路径为/root/.krustlet/config
。
$ bash <(curl https://raw.githubusercontent.com/deislabs/krustlet/master/docs/howto/assets/bootstrap.sh)
运行Krustlet
找到kind使用的默认网关地址:
# docker network ls
NETWORK ID NAME DRIVER SCOPE
...
b48010373347 kind bridge local
# docker network inspect b48010373347|grep "Gateway"
"Gateway": "172.18.0.1"
运行Krustlet:
$ export KUBECONFIG=~/.krustlet/config/kubeconfig
$ krustlet-wasi --node-ip 172.18.0.1 --bootstrap-file=/root/.krustlet/config/bootstrap.conf
运行界面如下,提示需要审批CSR:
# krustlet-wasi --node-ip 172.18.0.1 --bootstrap-file=~/.krustlet/config/bootstrap.conf
BOOTSTRAP: TLS certificate requires manual approval. Run kubectl certificate approve ubuntu-tls
审批CSR
$ kubectl certificate approve <hostname>-tls
校验
运行kubectl get nodes -o wide
,可以看到新增了一个节点ubuntu
,在该节点上可以运行WebAssembly负载:
# kubectl get node -owide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP
kind-control-plane Ready master 16m v1.19.1 172.18.0.2 <none>
ubuntu Ready <none> 8m37s 0.7.0 172.18.0.1 <none>
部署应用
下面安装官方的一个例子/demos/wasi/simpleserver/
。运行如下命令即可:
# kubectl apply -f simpleserver.yaml
该pod会启动一个伪服务,代码如下:
use std::thread::sleep;
use std::time::Duration;
fn main() {
loop {
println!("Hello, World!");
sleep(Duration::from_secs(5));
}
}
需要注意的是,在k8s.yaml中镜像字段为webassembly.azurecr.io/simpleserver:v1.0.0
,但它并不是一个标准的容器镜像,而是WASM的module,默认会放到/root/.krustlet/.oci/modules
目录下。在/root/.krustlet/.oci/modules/webassembly.azurecr.io/simpleserver/v1.0.0
目录下查看拉取到的module
# ll
-rw-r--r-- 1 root root 71 May 6 22:34 digest.txt
-rw-r--r-- 1 root root 1998989 May 6 22:34 module.wasm
可以看到module.wasm
的大小只有约2M,是一个支持跨平台运行的二进制文件,由此可以看出WASM和容器的区别:容器是需要基础镜像的,而WASM则不需要,它是一个可以跨平台运行的二进制文件,且需要特定的runtime工具运行。
# file module.wasm
module.wasm: WebAssembly (wasm) binary module version 0x1 (MVP)
可以使用wasmtime运行.wasm文件,wasmtime的下载方式如下:
curl https://wasmtime.dev/install.sh -sSf | bash
运行如下:
# wasmtime module.wasm
Hello, World!
Hello, World!
Hello, World!
...
WASM POD分析
查看该Pod,可以看到它就是一个正常运行的pod
# kubectl get pod
NAME READY STATUS RESTARTS AGE
simpleserver 1/1 Running 0 7m59s
运行kubectl describe pod simpleserver
查看该pod信息
apiVersion: v1
kind: Pod
metadata:
name: simpleserver
labels:
app: simpleserver
spec:
containers:
- image: webassembly.azurecr.io/simpleserver:v1.0.0
imagePullPolicy: Always
name: simpleserver
tolerations:
- key: "node.kubernetes.io/network-unavailable"
operator: "Exists"
effect: "NoSchedule"
- key: "kubernetes.io/arch"
operator: "Equal"
value: "wasm32-wasi"
effect: "NoExecute"
- key: "kubernetes.io/arch"
operator: "Equal"
value: "wasm32-wasi"
effect: "NoSchedule"
源代码编译运行
编译
由于上例的代码是rust编写的,因此需要安装rust套件:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
在rust工具链中添加wasm:
$ rustup target add wasm32-wasi
生成可执行文件:
$ cargo build --target wasm32-wasi --release
推送module
由于生成的二进制并不是标准的镜像,因此无法直接推送到OCI仓库中,可以使用wasm-to-oci将module推送到OCI 仓库。
但需要注意的是,并不是所有的镜像仓库都支持推送WASM module,目前支持的镜像仓库为:
- Distribution (open source, version 2.7+)
- Azure Container Registry
- Google Container Registry
- Google Artifact Registry
- Harbor Container Registry v2.0
- Bundle Bar
PS: 我使用了harbor镜像库,但无论使用http(报token无法解析)还是https(ca issuer无法识别),krustlet-wasi都无法成功拉取镜像。因此,建议有条件的话使用Azure或Google的镜像仓库
参考这篇文章搭建harbor镜像仓库(使用https方式)。搭建成功后,登录仓库,并执行如下命令,将WASM module推送到仓库中:
# wasm-to-oci push simpleserver.wasm registry.harbor.com/library/wasm-hello-world:v1 --use-http
在harbor仓库中可以看到刚上传的module。
运行自己的module
将k8s.yml中的image
修改为自己的module地址:
image: registry.harbor.com/library/simpleserver:v1
总结
WASM本身支持多种语言,因此可以方便地将市面上已有的服务转换为WASM格式。后续WebAssemble有可能成为一种新的容器类型,类似Linux容器或Windows容器。
WASM由WASM虚拟机实现隔离性,但目前的隔离程度有限(如CPU、mem、network、共享存储等),且WASM虚拟机实现各异。这里给出了一系列WebAssembly Runtimes。
可以参考一下这篇文章Using WebAssembly and Kubernetes in Combination,里面详细讲解了WASM的现状。WASM目前还处于早期,WASI标准后续也需要进行迭代更新。但由于其本身具有的轻量级以及可移植的优点,相信前途会一片光明。
PS:对服务端的WASM支持最多最好的语言是RUST,是否是时候捡起来了?