@kevinwan 如果是一间部署 K8s 的脚本工具集的话，就不要重复造轮子了，兄弟见笑可以参考我原先写的

https://github.com/mingcheng/deploy-k8s-within-aliyun-mirror

@yzbythesea 本地编译的二进制文件再打包到 Docker 镜像中不符合 CI 的规范，同时也不方便交叉编译等情况，所以正确规范的做法是 docker golang 镜像 build 通过后，将产出二进制文件 cp 到第二 stage 的 base 镜像。

不过楼主的 Dockerfile 我建议使用 make 等构建工具去构建（ golang 镜像自带的），因为如果涉及到更改配置、参数什么的，就又要该 Dockerfile 文件了，会很麻烦而且容易出错。

其实个人觉得改动不大：首先，K8s 将 dockershim 抽离出来然后统一使用 CRI 维护这个符合解耦的原则，对比其实还有 CSI 以及 CNI 等 interface 的实现；其次 docker 背后的 docker 公司作为家商业组织其实也做过很多容器管理的实践（例如 docker swarm ），但不得不承认目前这块 K8s 已经是事实上的标准。从话语权上说 K8s 肯定不会使用一种容器实现，而 docker 也不会再开个炉灶对着和 K8s 干，两者达成了某种意义上的默契和界限。第三就是实际上 docker 下面跑的也是 containerd，对于技术这块的改动其实不大对于用户的感知应该更小。

Tips：可以搭配读下这个项目 https://github.com/ziozzang/socks5-proxy/blob/master/socks5/server.go

刚好看到这个 https://zhuanlan.zhihu.com/p/305601019

如果开发使用，建议还是等二代

如果真的要买，Air 和 Pro 就差两千块钱，但是带来的屏幕和散热体验不一样，建议预算充足的话还是上 Pro