一个人在北京自我隔离， 无聊的要死，自己给自己加加班

其实都是大都都是开源东西拼起来的，没啥好讲的

持续集成测试的都是老的功能， 新的功能只有提测后才能添加对应的自动化测试用例

不好意思才看到你的留言， 之前漏掉了。 实际上 jenkins 的 master 节点放入中并不是必须的。 master 节点是可以放到 k8s 外面独立部署的， 只是配置略有不同。 首先你需要为 jenkins 创建一个 service account， 然后为它配置相应的 rbac 规则。 在这个 sa 下找到它的 screct 中的 token 复制下来。 然后到 jenkins 中的配置中添加一个云配置。 在云配置中填写 ca 证书 (kubectl config view 中 cluster 那部分内容就是证书，注意需要用 base64 转码)。 再添加一个 jenkins 认证， 选择 screct 认证，填写这个 token 内容就行了。 其他的配置都一样了。 抱歉你么晚才回复你。 希望对你有帮助

我记得武汉的医生说他们已经做好疫情持续到 5 月份的准备了

不是 ceph 不好。而是现在没那么强的需求了。我们一直用 k8s。本来是想引入 ceph 增加分布式存储能力来解决 k8s 持久化能力。 但是后来没那么强的需求了。 所以一直搁置着呢。现在就是我们自己测试中试用的程度了

ceph 曾经的用户报道

原来如此

没做过移动端，移动端是非常不稳定么？

差不多把。 所以我们的浏览器集群有 2 种浏览器来源。 一种是部署在 k8s 中容器化的浏览器。 另外一种是部署在虚拟机中用来做浏览器兼容性的。 我们根据不同的测试目标可以选择使用特定的浏览器。 部署在 k8s 中的浏览器全部以 linux 系统驱动，优点是节省资源，利用 k8s 的分布式和自动化运维能力能很好的管理和迁移。降低了很大的运维成本。 但它的缺点是无法模拟 windows 和 mac 的内核。 所以做兼容性测试还是需要到 windows 和 mac 系统上部署浏览器再加入到集群的 hub 上来。但这种浏览器的缺点就是运维成本很高，并且极其占用资源，无法部署太多的浏览器。 不像部署在 k8s 上的浏览器，随随便便部署几百个是很轻松的。

不是的。兼容性测试还是需要实际用 Windows 和 mac 操作系统部署浏览器注册到集群中的，这样才最真实。 那几百个容器化的浏览器是用来做与浏览器兼容性无关的测试的。 比如功能测试， Hadoop 集群的兼容性测试，数据库版本的兼容性测试，k8s 版本的兼容性测试。 ps：我们是 to b 的项目，产品要部署在客户场地。所以对接客户的 Hadoop，k8s，数据库，操作系统等。 所以才延伸出了上面说的这些兼容性测试

过奖了，规模都不大。没多少代码量的

process on 会员 135/年 你值得拥有~~~

就冲着这么认真写总结的劲~ 先👍一个

后面讲了流量切换等后续 failover 流程的事哈。 不过你说的对， 我是应该在一开始就强调出来

基本上 linux 的知识越多越好~ 知道的越多，你能做的事就越多。 我工作中 9 成以上的工作内容都是跟 linux 相关的

已改~~~ 不要在意这些细节~~~

你的服务是不是其实还没有完全启动好， 所以在没启动好之前都 502 了。 你可以给容器设置探针来做健康检查。 探针就去探活你的服务，只有返回 200 的时候 pod 才是 ready 状态。