本来想在 github 上提个建议，但是看到一堆 open 的 issue ，感觉提了也没什么用。
不反对实用至上，因此很多地方看起来是以实用为主的临时方案。但是都 v3 版了，应该考虑一些优化。看了 Dockerfile ，以下是认为这个项目不太合理的地方
- 把 Docker 当做虚拟机用，用 supervisor 在单个容器中启动了 nginx ，redis ，spug-api ，spug-worker 等不同的进程应用。容器是进程的封装，单容器单进程比较合理
- 代码不是随容器镜像发布，而是在启动脚本中 git clone ，这要是离线部署就没辙了，也不利于做版本控制
- 另外容器基础镜像可以与时俱进一下，CentOS7 已经淘汰了。

看起来是在酝酿新版本，所以希望上面的问题可以优化下

这个问题让我想起了风电火电听音乐的差别

我最近也发现 plex 的刮削经常失败，不知道是不是网络相关的问题。
在路由器上把 plex.tv 指向代理的话，会导致 plex 上报的公网 ip 为代理的 ip ，公网访问会有问题。

unraid ，docker 版本

如果你能从机房拉一条便宜的专线到你家，那确实和 nas 效果一样了。
不然的话，流量走公网进出？ 30M 上传？

ssh -A {your ubuntu}
then
git

你这个属于部署方式，和 go 语言有什么关系。任何语言写的程序基本都能用你说的两种方式来部署

* 不想安全 >> 不想安装

没有必要，helm 如果不想安全，有子命令直接就能渲染出 yaml 。
再者就是直接用 yaml 部署，修改变量太麻烦了，特别是 secret

这你就认下了？不应该让他拿出异常的指标证据吗？再问问异常的标准

遇事不决 777

除了 8 楼说的调用的指令集等性能问题，其他基本上没什么大问题。k8s 整套的基础组件都有 arm 版本，golang 生态编译本就方便。
前司就这么干的，在 aws 上生产环境不 arm 比例已经大于 x86 了，为什么，因为 aws 上的 arm 机器比 x86 便宜 20%左右。

当然，还得看实际业务是否用了 x86 独有的指令集

看我名字

@LFO 可以直接查看他人解析，按点赞排名之类的

试了一下，好像和智谱里面的刷题没差太多啊。
有时候主要想看解析，或者计算方法。

第一个问题的本质和 k8s 没有关系，你用虚拟机部署，或者买云厂商的 MySQL/Redis ，难道就不需要根据需求或者业务量来选择购买什么样配置的虚拟机或者实例规格吗？

第二个问题同样和 k8s 集群规模相关，也没有规定不同应用还得按比例来部署，这不都得根据业务需求来。

两个问题都没有标准答案，

@lhstack #5 你确定吗？你所说的是滚动参数，还有一个保留份数的，都设置了也没用？

根据你第一条附言的逻辑，不搭建内部 dns 的情况就是，先跑到距离家里几（十）公里外的 xx 行政服务中心，问一下自己家钥匙，然后拿回来自己开

没看明白，这个 eip 直通什么关系，报错不是 registry.k8s.io 镜像仓库连不上吗？