(2000+) kubernetes 社群分享 QA 汇总

README

内容主要来自在里 dock one 微信群里有关企业 Kubernetes 实践过程的直播分享，下面截取聊天记录的自 QA 部分 。由于提问链接在石墨文档上协作编辑，而石墨文档里的内容是无法被搜索引擎检索到的。这些问题不整理起来就永远地躺尸在石墨文档了，所以就把这些提问的问题汇总到一起，方便大家自查。

2020-06-02：谊品生鲜如何从零开始快速打造 CI/CD 流水线

Q1：有对照过 jenkins，drone 等其他 CICD 工具吗，处于什么考虑最后选择 gitlab-runner，未来有考虑过 k8s 这方面的集成吗

A：gitlab-runner，jenkins，drone 都属于配置即操作的工具，因为使用 gitlab 来管理代码，gitlab-runner 又很好贴近 gitlab，维护成本也不 24177411244444117 期 71 个高，类 714 个 jenkins 的 node，安装注册，就能拿来用。 正在引入 K8S 中 71477448 7d;)eexsnjnkm&/hfb6;

Q2：从镜像到部署到 k8s，是通过什么实现的，kubectl 还是镜像更新触发？在这个过程中能不能调整一些 deployment 的配置，比如 resource.cpu.request 或者ingres1PS7hig4 是 GPSPSPPSPPSPPSP 确实好 1 是 1iss 的一些配置？务

A：这边，现在没有使用 k8s(二季度将 1 引入 k8s)，只将应用 docker 镜像，发布必要性给万兴也统计：：到目标机器上 如果引入 k8s，将开发调用 k8s 的 api server 接口，传递 yaml 配置文件宋*是啥说切让送说切让送说切让送说切让送说切让送说切让送 1 好 hi

Q3：对于项目是如何进行任部署检测的？对 tag 进行监听吗？

A：在项目根目录下添加配 49377071607499984 的图 拒绝置文件.gitlab-ci.yml，有 only 和 except 数组，支持 branch，tag，环境变量，MR，文件变动(像 README.md)

Q4：相比 jenkins 如何

是 1 去爬山去 1

Q5：产品代码迭代提交中，如何区别正常的合并代码、以及构建请求呢

A：构建请求时，是让开发选择要发布的分支，进行打包发布

Q6：gitlab-ci.yml 放在根目录下， 是否会增加维护成本。这些文件的改动是业务研发修改，还是专人维护呢？

A：.gitlab-ci.yml 四行代码，就这四行固定，加到项目脚手架里，没有维护成本，通过 include cicd 项目，运维在 cicd 项目里进行维护打包和发布操作代码，对业务代码，零影响

Q7-0.1 请问自动化测试准备怎么加入呢，

A: 发布成功后，调用自动化测试平台 API

Q7：针对 gitlab runner 是要驱动整个产品的研发去触发 CICD 吧，对于不懂 docker 及 k8s yaml 语法的同事，怎么让他们接受新的发布体系及使用呢？

A：.gitlab-ci.yml 的语法是运维写好的，开发只要在页面上点击发布，发布系统触发

Q8：请问有没有高并发拉取镜像的问题？有没有遇到过在高并发下 gitlab 性能下降的问题？

A：harbor（机器配置偏低）遇到过高并发拉取问题，在一次大量迁移的时候，没有按批次操作，平常开发发布，harbor 完全可以胜任，高并发下对 gitlab 影响不大，gitlab 主要还是触发 gitlab-runner 去运行打包和发布，gitlab-runner 机器配置稍微高些，因为除了 java 的 maven 和 gradle，我这边还将 node 打包也集成在这个项目里

Q9：k8s 持久化存储有什么方案推荐？

A：因为这边都上阿里云，现在引入 k8s 使用阿里云 ASK，存储直接使用云硬盘，像阿里云的 ACK，可以使用 OSS 对象存储

Q10：详细介绍一下灰度发布是怎么做的吧，例如两次发版数据库结构不一致，是如何做发布和回滚的，流量怎么分发到新旧版的

A：发布前，升级数据库结构版本，先执行数据库结构变更（凌晨）回滚: 将数据库结构回滚，应用 retry 上一次发布记录流量通过网关配置

Q11: 系统瓶颈如何测试，使用什么工具，测试方法是怎样的，包括应用层和中间件

A:应用层，使用阿里云性能测试，请求相关 API

Q12 公司目前就 20 来个开发，适合自己搞这套吗？

A:如果你们还在手动发布的话，建议你们使用 gitlab-runner，可以使用 git tag 方式，发布，我们也是一步一步走过来的，先前没有发布系统，开发使用打 tag 方式发布，这个没有约束看开发个人，后面开发了套发布系统，在上面做了工作流管理

Q13 发布系统权限怎么控制的？

A：分应用开发和应用 onwer，rbac 具体讲讲权限控制细节吗先对开发分配角色，dev，onwer，具体实现，可以参看 RBAC

2020-05-19：Kubernetes 在 AI 平台的落地实践

石墨文档

Q1：k8s 在做应用部署的时候，如果使用 statefulset 做部署，是否失去了故障恢复功能？比如 node 节点 down 机

A：我的理解是如果是选型 statefuleset 作为部署的资源类型，通常是指像 kafka、elasticsearch、etcd 等等这类的组件或服务，而这些本就有高可用机制可以保障

Q2：可否分享部署文档和踩坑的记录，我们好跟着搭建，动手实践下，这样是否可以避免踩坑？

A：可以，后期可以多分享一些文章在社区这边

Q3：怎么看待 kubeOperator 这个项目

A：这个还没去了解过，后期可以关注一下

Q4：日志收集如果保留原日志文件，如果使用 deployment 怎么做到多 container 各自写不冲突，如果不落实到文件，是否会有输出内容过多的问题，怎么做日志清理

A：日志收集和管理要做好，实际上是一个大工程，很多公司都是自己单独做了日志管理系统，像你说的做到各自写不冲突，实际上如果使用 EFK 这类的云原生日志管理方案，也是没问题的，对于输出过多，实际上你的 client 采集器采集到比如 ES 上的时候，这个时候的聚焦点应该是在 ES 的管理上，怎么定期清理 ES 的数据或者冷备等等，而这个 ES 是有专门 api 接口可以灵活做策略的

Q5：请问你们当前 calico 支持了多大规模的集群？

A：我们目前是 30 台物理机

Q6：各个 AI 厂商的计算模型不统一，如何使用统一的 AI 平台管理各种 AI 模型，是否有统一的建设标准？

A：我的理解是这个实际上就涉及到更加底层的封装了，现在 AI 像深度学习这一块，使用的主流框架大家都差不多，像 tensorflow，pytorch 等等，既然这些框架基本大家使用方式都一样的话，基本就可以统一标准了，实际上我的理解是这一块应该还在高速发展中，还不太适合过早进行统一

Q7：请问 dubbo 架构容器化，注册中心有集群内已容器化和传统部署同时存在阶段，能否分享下过度期的经验？谢谢

A：这个其实就是涉及到 dubbo 的注册机制了，底层使用的还是 ip 和端口进行通信，关键问题应该是传统部署的网络如何与容器网络打通的问题，我们之前另外一个平台也是遇到这个问题，最终是将 calico 网络和传统网络做了融合

Q8：对容器监控模块 prometheus 是否有高可用架构实践分享？谢谢

A：嗯这个可以后期分享给社区

Q9：请问 tf 分布式训练中，对于训练数据的多 worker 节点访问，采用的什么方案？

A：这个平台暂时还没引入分布式训练，不过后续有在考虑

Q10：请问有没有使用 vgpu 的方案？

A：这个目前我们使用的是 nvidia 官方的插件，跑在 K8s 上，以单颗 GPU 为维度进行虚化划分调度，后续准备结合开源方案把单颗 GPU 再虚化更小颗粒度的，比如 16G 显存的 GPU 切割成 8 块 2G 显存的 GPU

Q11：这里基于 k8s 大数据的方案，k8s 的容器是跑在虚拟机里面的，还是 baremetal 的物理机?

A：这个是跑在裸机上的

Q12：大数据部分，支持哪些计算框架，比如，hadoop, spark, flink 等，他们在基于 k8s 部署时，基于性能上的不同考量分别是什么?

A：大数据组件容器化我们也还在探索中，像 spark on k8s 从目前的测试效果来看，计算性能是个大问题
我 hefwehfweh
伟大

Q13：关于 spark on k8s 这块儿您那边目前有什么预想方案吗，比如说存储系统用哪个，是部署在 k8s 上还是单独部署，数据又如何传入存储系统之类的

A：目前我们的测试方案中使用的存储还是基于 HDFS 的，单独部署，如何传入存储，这个属于具体的实现了，后期等 spark on k8s 成熟了，我们可以针对这个 topic 做一次分享

Q14: 请问你们有专门针对监控或者日志系统考虑证书一类的安全策略否？

A：这个暂时没有考虑，优先级不高

Q15：是否有些应用产品如 springboot 的可以直接集成，还是另外用 sidecar 之类分开互相调用,或是服务调用会有什么策略问题么

A：平台后台应用使用的就是 spring boot，我们直接使用的就是它本身的服务发现机制，服务调用策略交给了 istio，包括鉴权，灰度发布等等

Q16: workflow 有何开源项目可以借鉴？

A：workflow 我们准备上线 argo，可以关注一下

Q17: k8s 容灾如何考虑的？是否考虑 k8s 和物理机混布？

A：针对 k8s 我们本身做了高可用，比如多 master，这里面有个注意点就是尽量使用不同机架来部署 master 组件，这样即使机架上的网络设备出问题，也可以轻松应对，如果条件允许的话，多机房部署 k8s 集群，暂时没有考虑 k8s 和物理机混布

2020-05-12：Kubernetes 在智联招聘内网的应用场景

石墨文档

Q1：管理存储（PVC/PV）创建容量相关实践是怎么样的？如何进行限制应用部署随便创建超级大的存储？

A：目前我们生产环境并未使用 pvc/pv。这两种存储方式，仅仅是在验收环境做过一些功能测试。生产环境主要是无状态应用。后期可能会使用这两种方式做部署有状态应用的服务。调研过 ceph/glusterfs，估计会采用 ceph 做 pvc/pv 的应用。

Q2：k8s 调度策略是怎样的？有没有出现调度不均衡问题？比如有些服务器内存剩余不多了，还频繁调度过去

A：k8s 的调度策略是 scheduler 这个组件完成的，里面有多种评分方式，根据节点的评分去做 pod 的资源调度，这个问题再踩坑分享里有介绍部分，如果感兴趣，可以看看相关的调度算法源码。

Q3：是否使用到 HPA 根据内存使用情况或自定义 metric 指标进行自动化扩缩容？有遇到什么问题吗？

A：HPA 目前生产环境仅部分业务使用。根据内存/自定义 metric 指标的自动扩展，并未在生产环境使用。主要还是以 cpu/mem 的指标作为 hpa 的 scale 策略。

Q4：所说的实例数量 600 多个，是指 600 多个 pod 吗？是否做到平滑更新？怎么做的？

A：600 多实例是指 pod 的数量。平滑更新采用 deployment 的更新策略去完成的。

Q5：请问一下智联内部是怎么做集群升级的？是原地升级还是迁移升级，如何做到对业务的影响最小化？

A：升级方式我们采用比较安全的做法。多集群滚动升级，比如生产有两套集群，我们从前端的流量内取出一套集群做完升级后，做流量的平滑切换

Q6：请问一下智联内部有没有做多 AZ 多活架构，流量分发策略是什么？

A：当前使用到的是 A/B 集群的模式，前端流量做轮询至两套集群，如果要做灰度级别的应用发布，采用 cookie 的方式，从前端的 nginx 做流量的负载

Q7：有没有对集群内的东西向和南北向流量做采集分析？技术栈有哪些？

A：不好意思，这个没太明白具体是指哪里

Q8：请问智联内部基于哪些因素来选型容器网络插件的？过程有没有踏过哪些坑？

A：我们从最早使用的 flannel 网络切换至 calico 网络。选型主要是考虑网络的稳定及吞吐量。calico 主要是解决业务系统排查问题，找不到真实容器的 IP 才做的切换

Q9：您好，想问一下内部 api 接口请求是直接用的 k8s 的 service 嘛？才接触到，感谢 🙏

A：内部服务之间，我们采用的是 service 的方式调用。因为如果使用域名的方式，相当于流量要再绕一圈。但是部分业务也是需要走域名的方式调用，这个取决于应用自身

Q10：我想问下如何部署几百个服务保证高可用，机器有限情况下

A：想要在机器有限的情况下保证多个服务的高可用可以从以下几个方面考虑。1. 应用自身的消耗，比如 CPU/MEM 等，基于这个真实的使用做好资源的限制。2. 最少提供 2 个及以上的副本数保证服务的可用性，利用 k8s 的探针去做服务高可用

Q11：对于容器安全方面有没有好的实践分享？例如基础镜像，PSP，操作系统层面安全加固等

A: 容器的安全方面，目前我们仅使用了 harbor 的镜像扫描组件，别的安全加固有安全团队负责在做

Q12: 四套 k8s 集群是指 4 套环境，每套环境对应一套 k8s 集群吗？监控系统几套？是否做了监控系统的高可用，如何做的？

A：4 套集群，我们这边是根据环境划分的。验收 1 套，预上线 1 套，生产 2 套。监控系统在各自集群都有指标采集器，这个在分享内有架构说明。监控系统的高可用也是采用的 prometheus 的多机方式做的

Q13: 请问你们 K8S 集群安装是用什么方式的呢？可不可以分享一下么？

A:目前采用的是二进制包的方式安装，利用 ansible 去做的。随着 kubeadm 的稳定，后期可能会采用 kubeadm 的方式做部署。跟你分享一个比较不错的开源部署解决方案（https://github.com/easzlab/kubeasz）

Q14:部署文档和踩过坑的文档能分享出来么？怎么查看集群的整体资源，用监控看的么？公开了大伙好仿照搭建一个类似的 ～

A:这个后期会考虑分享，因为文档内有一些数据不方便公开。整体资源的监控，可以用 prometheus 收集后，通过 grafana 看到

Q15:问问 vmware 用 calico 怎么创建ingress 跟 load balanxe 类型的 servicep

A:这个我倒是没有尝试过。你是指要创建类似于阿里/GCE 方式的服务 IP 直接暴露公网的么？如果是这样的话，估计需要开发对应的组件才可以

Q16:你们的 es 集群配置是多少？高峰期有没有统计过每分钟或者每秒写入日志的量，也就是能承载多少 qps？主要是参考

A:目前我们 es 集群共有 13 个 node，不过配置不太高，因为磁盘不好。如果你们要生产级别使用，建议用 ssd 的磁盘，这样会好很多。QPS 在峰值基本可以到 8000-1W

Q17:请问应用部署有没有做跨集群部署

A:我们目前就是多集群的应用部署方式

Q18:有状态应用请问是如何管理的？使用 statefulset?还是 operator？或者其它方式呢？

A:目前有状态的应用，我们只用到了少数，使用的是 statefulset

Q19:请问 filebeat 怎么在节点收集应用系统日志

A:我们是挂载物理节点的容器日志，使用 filebeat 的 kubernetes 模块去做的收集，具体可以参考 filebeat 的官方 kubernetes 部署方案，里面有比较详细的介绍

Q20:你们 node 节点内核是 3.10 版本，是否考虑升级内核版本，来优化性能？

A:之前做过升级至 centos8 的尝试，发现不行。主要是因为防火墙这里的功能升级导致。后面估计会考虑升级系统内核的方式去做一些性能优化

Q21:日志报警怎么做的？

A:

Q22:贵公司的 pod 日志收集使用 logsider 了吗，另外贵公司使用 hpa 时是否调整过 hpa 的伸缩速度

A:

Q23:前段时间公司集群节点报错，imagecollect 垃圾回收出问题了导致 pod 无法创建在该节点，请问遇到过马？有什么建议？

A:

Q24:600 个 pod，node 数量大概多少台？

A:

Q25:master replica a/b/c 中 api-server,etcd 做集群，其余组件只是 master replica a 提供服务？

A:

Q26:请问多集群部署怎么做的，能讲讲细节嘛？

A:

2020-05-07：酷家乐服务网格与 Serverless 落地情况

石墨文档

Q1：如何解决 knative Queue proxy 性能问题？和容器相比 Knative 引入 queue proxy 导致 Qps 性能有很大的降低，这方面有调优？ 能否介绍下？

A：这个问题要辩证来看，就像 Istio 也引入了 istio-proxy 这个边车，也同样带来性能下降是一致的。就是说你从引入这个新框架，给业务和团队带来的收益，能否覆盖引入这个新框架带来的损失？你是否接受这样的损失，这个损失是否可能会被你们团队或者社区优化？这些问题考虑清楚的话，才可以下决策或者判断。

在我们落地的实践中，我们尚未对 queueproxy 本身进行调优，这块我们的计划是等社区成熟到一定版本之后，再考虑自己的优化，不要 Hit a running target。举个反例，我们之前曾对 K8s, Istio 做过一些改造，但是由于版本更新很快，最后带来的兼容性问题，升级升不了等问题也很多。所以我的方法论是稳定之前不要提前优化，不要过度优化。

Q2：Istio 框架中对于网络请求的来源 IP 是如何通过应用层获取到的呢？一般来说 IP 地址会被换成 Sidecar 的地址或者是被 K8s 的 LB 换成 Node 的主机地址。 当然有一种办法是在请求进入 K8s 前面加 Reverse Proxy，写入 HTTP header。除此之外，还有什么比较好的办法吗？

A：这块似乎不是一个服务网格或者 k8s 的问题吧，http 请求里面有多个 header 跟 ip 相关，例如 x-forwarded-for, real-ip 等等，你只要保证网关层没有丢掉这些 header，其他中间层透传了这些 header，应该不会遇到拿不到客户端 ip 的情况啊。我遇见过的类似情况都是因为某些业务需求魔改了 nginx 导致的。。不魔改应该不会出这么基础的问题。

Q3：Custom Gateway 在 Istio 框架中是怎么实现的呢？Custom Gatway 如何与 Istio 的 Gatway 共存？例如 WAN -> istio Gatway(all-to-my-own-gatway) -> my gatway -> back to istio gateway(routing) -> microservice 是一个好的设计么？

A：你说的两种 Gateway 共存我没遇见过，不好说。我们内部的网关都是自己的写的，可以当作一个 service 来使用，严格来说不跟 istiogateway 并列。你说的这个链路我直观感觉是太长了，可能不是个最优设计

Q4：当前 Knative 成熟度怎么样？是否生产上使用，能否介绍下踩了哪些坑？

A：比较成熟，可以在生产上小规模使用(大规模使用建议等他发布 1.0). 大坑在分享中已经提到过了，小坑不少，可以举几个例子

由于我们自己改了 K8S 的源码导致 Knative 的 activator 不能正常扩缩容

新的 Revision 卡住起不来

webhook 组件偶尔不正常工作

这些小坑最后也都解决了，不是什么重大影响:

Q5：MicroService 统一配置管理 有什么比较好地解决方式么？尤其是对生产数据库密钥的下放。

A：这个问题应该是放在配置中心或者数据库中间价里？这应该是一个服务治理的基础问题吧，很多公司和团队解决过了，可以搜一下 nacos, tddl, etcd 等

Q6：你认为当前 Knative 存在哪些框架上的问题和缺陷？这些问题社区进展怎么样？

A：冷启动时间太长，这个社区有专项跟踪，应该会不断优化；proxy 臃肿，这个社区里似乎还不急，现在只能作为一个前提来接受了；还有一些杂七麻八的管理问题，这些肯定会被社区逐步完善，或者会出现专门管理 kantive 的三方系统。个人觉得 knative 社区进取心还是可以的，缺点是人比较少，劳动力不足。

Q7：KNative 的冷启动情况是怎么样的？有没有什么监测数据可以共享一下。官方说会有 10s 以上的冷启动时间且至今无解。相比 AWS Lambda 的冷启动时间会短很多。https://github.com/knative/serving/blob/master/docs/roadmap/scaling-2019.md

A：AWS 的冷启动做的已经非常好了，他们里面有很多优化。我们自己内部一直在关注了测试。我们的 benchmark 是找最简单的 go 语言的 helloword 服务，关闭 istio-proxy，做好镜像在 host 机器上的缓存，然后测冷启动平均值，这个值已经从 0.8 版本的 4 秒下降到现在的 3 秒左右了。社区还是在不断优化的.

Q8：Istio 本身的版本更新你们是怎么自动化的？我目前项目还是用 helm 打包成一个新的 Chart 实现的。但是 Helm 的安装方式已经被 deprecated 掉了。
A：我们没有做 Istio 版本更新的自动化。手动安装之前用的就是 helm。现在 Istio 推荐用 istioctl+ 配置的形式直接安装和升级

Q9：你们灰度发布也是放在 CI 流程里面的，还是 Ops team 手动发布的？

A：放在 ci 流程里，可以选择手动触发或者通过 api 触发(ci 主要是使用的 gitlab-ci)

Q10：基于这个 BFF 架构前端的 API Gateway 你们有什么选择？API Gateway 是用的 istio的ingress controller 吗?

A：API gateway 这层我们是自建的，但是现在也在考虑一些成熟的开源实现

Q11：兼容原有服务体系这块可以再详细介绍下吗？比如 dubbo 的 provider 是否可以一部分在原有服务体系，一部分在 istio 里。

A：兼容原有服务体系本质上就是能让两边服务互相调用。这个严重取决于你原来的服务治理体系的情况，因为我们的服务体系是魔改 + 自建的，所以可能对你直接参考意义不大，dubbo 这个问题我不是专家。

Q12：knative 部署的服务初始资源多少（cpu，内存）？什么条件去扩容和缩容？

A：如果 queueproxy 和 istioproxy 都在，那么起步要 80m 内存 + 你的业务服务内存。扩容缩容看你用的是什么组建了，k8s 的 hpa 用的是 cpu 或者自定义指标，knative 的 kpa 用的是并发量

2020-04-29：晨光科力普基于 GitLab CI/CD 持续集成服务的应用

石墨文档

Q1：gitlab-runner 在没有 CICD 任务时也是运行中的么？那这样是否会占用过多资源？是否可以做到类似 Jenkins + kubernetes 当有 CICD 任务的时候才按需启动一个新的 slaver 容器？

A：我们一个组的项目只启动一个 runner 容器，注册 4 个 worker，runner 依轮询方式监听 gitlab 构建任务，没任务时就 1 个容器，有任务时才会启动构建容器，构建容器的资源占用可通过配置文件限制。

Q2：我看到有些特性是在新版本的 gitlab 里面才有的，旧版本应该升级吗？你们采用的什么升级策略？

A：如果更新的特性对我们很有吸引力的话如 include 和 extends，我们会评估一下升级风险和近期是不是有重要任务发布，都没有的话，我们就做好备份进行升级，版本的话不会跟的特别近，也怕有风险。

Q3：和 Jenkins 比较，你觉得 gitlab ci/cd 有什么优势，或者说说他们的差别，适用场景？

A：jenkins 别的团队也有在用，我个人觉得 gitlab 的配置更加简单，因为分支策略，我们的合并动作都会在 gitlab merge request 里进行，合并完直接切到 ci cd->pipeline 页面，团队每个人都能实时获取构建进度。

Q4：有了解 GitOps 吗？将全部配置全部 all in git，Gitlab CI 算不算相关的实践？

A：抱歉，暂时不太了解。我们配置的确是全部保存在 git 上的，已经整合了 2 个组的配置，管理比以前方便。

Q5：问下你们实践的场景规模有多大？多大团队，多少仓库，占公司多少比例的仓库，多少并发和流量的应用，发布频率多少，每天一次吗？

A：我们组去年组建的现在有 10 个左右仓库，别的组项目比较多，整体大概有 100 多个项目。使用 gitlab ci/cd 的占一半。我们组已经完成了 CI/CD 的配置整合，正在向别的组推广。发布频率的话，dev、test、uat 比较频繁，线上环境看测试进度 1 天 1 次。

Q6：如果需要审批发布、通知这些功能，GitLab CI 能实现吗？

A：这一块的我们暂时还没有实践。

Q7：你们采用的私有部署（ce 还是 ee，有什么区别），还是公有服务？

A：私有部署，区别我这里了解的不多。

Q8：能否开源你们实践的一些 yaml ，我想对其他想试试 gitlab ci 的人会非常有帮助

A：这个还在探索当中，官方提供的有很多模板示例 templates 我们这边还要很多没有完善，有问题可以在群里或通过管理员 @ 我随时沟通。

Q9：你们的 ci runner 拉取私有仓库的 ssh key 怎么配置，可以介绍下经验吗？

A：构建容器镜像可通过 runner 配置文件配置。如果是业务的基础镜像，构建脚本里直接 doker login -u -p 操作。抱歉我当成私有镜像仓库的权限了，你需要的可能是这个 README.html 、repository_mirroring

Q10：有个小建议，通过判断 git log 里面的日志，可以控制一些 step 的执行 。比如，提交里面有 【deploy】才发布；没有的话就不发布。

A：感谢建议，我们是为了省事，按部署环境拆分了分支，push 对应分支直接发布，生产环境需手动触发一下。

Q11：目前遇到一个问题，master 对应生产环境，虽然分支做了保护，在 deploy 步骤设置成 when munual ，但是所有组员都可以点击发布。鉴权这方面 gitlabci 比较弱，是否有解决？

A：Setting->Repository->Protected Branches 下可以设置分支可由那些角色进行 merge 或者 push，可通过这里控制团队成员的权限是否能合并到 master。我们在 master 之前会有个 uat 验收分支，现在权限团队成员都有，后边会拿掉 master 的，交给测试团队那边。有时候 merge 了，但不确定是否发布。 有没有方法解决不是 mainter 角色，无法点击发布按钮这个功能呢权限控制这块我了解的不太多，目前也是通过角色控制的。

---

2020-04-21：哆啦 A 梦：基于 Prometheus 的企业监控报警平台

石墨文档

Q1：告警支持哪些平台的接口呢？自由度怎么样呢？可以在产品中，配置定制化的接口的 json 格式呢？

A：支持 hook 和公司内部的蓝信、短信以及电话，对于公司外部的用户可以暂时使用 hook 模式，后续会支持微信、短信、邮件、钉钉

Q2：告警触发器是如何管理的

A：prometheus 根据报警规则的阈值进行内部计算得来的

Q3：prometheus 如何对接多个 k8s 集群实现集群 pod 的弹性伸缩？

A：利用 k8s 的 hpa 通过报警平台的 hook 机制来做弹性伸缩

Q4：k8s 都需要配置哪些方面基础告警？kube-prometheus 默认的就够了吗？

A：默认就是节点监控、pod 监控、k8s 默认组件的监控

Q5：容器监控指标的采集是自研的，还是用的 cadvisor，还是用的其他什么呢

A：默认的

Q6：prometheus 原生是单点，在告警和存储方面，哆啦 A 梦是如何支持集群模式的

A：告警的存储使用 mysql，prometheus 只是用于计算规则的。集群模式可以使用多个 prometheus 进行计算，至于 promeheus 的架构由用户自身决定

Q7：开源地址是哪里？可以发下吗？

A：正在走开源流程，预计两周内开源

Q8：alertmanager 针对的是 group 维度的预警 那自研的版本如何去定义这个 group， 是否有新增针对单个对象去推送预警及预警的频次

A：哆啦 A 梦的告警是哆啦 A 梦内部机制实现，不依赖于 alertmanager 的 group。

Q9：prometheus 使用过程中存在哪些性能陷阱，能否举例。如何评估预判 prometheus 性能容量？

A：在 prometheus 的数据量非常大的时候会有性能瓶颈，特别是在计算直方图以及采集大量节点的时候，但一般场景下不会有这样的问题

Q10：prometheus 部署在集群内还是集群外，多个集群的实例如何统一监控告警？是否支持跨集群应用实例的监控告警？如何实现？

A：哆啦 A 梦不关心 prometheus 是部署在集群内还是集群外，只要能通过 url 访问即可。目前不支持基于多个 prometheus 的告警聚合，后续可以考虑实现

Q11：Wayne 和 Doraemon 的关联在哪，没有找到 Doraemon 的链接

A：wayne 是 k8s 集群管理工具，哆啦 A 梦是 wayne 团队的另一个作品，正在走开源流程，很快会开源

Q12 之前看到你们在用 thanos 怎么又变成联邦了？可以对比下常见扩展方案的优劣吗？

A：可能是其他部门使用 thanos，搜索部门使用的是联邦，具体比较可以见 thanos 官方文档

Q13: 按刚才分享的案例看, 其实这个系统可以类比为基于 alert rule id –> pageduty 的一个大系统么?

A：实际不是，因为真正的 alerts 和发送流程是由哆啦 A 梦控制的，而不是 Prometheus，prometheus 只是负责计算报警规则。

Q14: 告警规则是通过 prometheus 的接口下发至节点做 PROMQL 计算的？

A:是的

Q15 自动恢复这方面有考虑吗？比如告警触发对于脚本去自动恢复？

A：自动恢复目前没有做，这个不同公司不同场景差异很大。用户可以根据 Doraemon 发出的报警，自定义恢复逻辑

Q16 prometheus 在使用 promql 中的 rate 函数会经常遇到没数据的问题，数据图表断断续续，请问你们有遇到这种问题吗，怎么解决？

A：猜测应该是 rate 语句的使用方式有问题，具体参见 prometheus 官方文档 rate 函数说明

Q17 报警规则，下发到多个 Prometheus Server，能否说下是怎么实现的？直接修改 prometheus 的配置文件然后调用重载的接口？

A：这是基于 prometheus 的库进行的二次封装实现的

Q18 这套系统花了多少时间和人力啊？

A：这个不方便透露

---

2020-04-16：阿里云如何构建高性能云原生容器网络？

石墨文档

Q1：是否支持 IPV6，实现上遇到了什么问题吗？内核或 kube-proxy 代码问题？

目前支持通过 IPV6 的 LoadBalancer 暴露，但实现还是在 LoadBalancer 中做 6to4 转换

目前 Pod 还未支持 IPV6，k8s 从 1.16 中 kube-proxy 等开始支持 IPV6，我们也在积极跟进，计划今年会和阿里云 IAAS 一起实现原生的 Pod IPv4/IPv6 双栈

Q2：每次请求 coredns 解析，都去根据源 ip 去获取直接访问的服务，是调用 k8s api 获取吗，会不会增加 api 的压力?

A：不会的，那里那样画是为了让结构更易于理解，实际上 Coredns 的 AutoPath 会通过 watch&list 的机制去从 ApiServer 那里监听 Pod 和 Svc 的变化，然后更新本地的缓存

Q3：k8s 的 service 请求到一组 pod，这个过程是轮询的吗，请求到每个 pod 的概率是一样的吗

A：对，概率是一样的，可以理解为 LB 领域的 roundrobin 算法

Q4：ipvlan 和 ebpf 好像是高内核才支持的，是不是对宿主机内核有要求？

A：是的，在阿里云上，我们可以使用 aliyunlinux2 的 4.19 的内核。对于低内核，Terway 也是支持 veth pair+ 策略路由方式来共享 ENI 上的辅助 IP，只是性能会低一些

Q5：cilium 是如何管理 ip 的呢，或者说分配 ip？类似其他的 cni 插件管理 ip pool 吗

A：1. cilium 本身有两种分配 IP 的办法，host-local：就是每个节点分段，然后顺序分配， 另外一种是 CRD-backend，可以让 IPAM 插件自己实现分配

2. Terway 中的 cilium 只会做网络策略和 Service 的劫持和负载，不会做 IP 分配和配置

Q6：如果没有用这套网络方案，又觉得 service 大规模使用影响性能，有什么好的方案吗

A：kube-proxy ipvs 模式的性能在大规模中损失还好，但其实整体引入了过长的链路，所以延时会增加一些

Q7：cilium 应该不是注入 bpf 到容器的 veth，而是注入到 host 端的 veth？你们做了什么修改吗？

A：cilium 应该不是注入 bpf 到容器的 veth，而是注入到 host 端的 veth？你们做了什么修改吗？

是的，cilium 是修改的容器对侧的 veth，我们经过测试发现 IPvlan 的性能优于 veth，Terway 中是使用 IPvlan 做的高性能网络，是不存在对侧 veth 的

我们适配的修改请参考： https://github.com/cilium/cilium/pull/10251 另外 Terway 使用 Cilium 只会做 NetworkPolicy 和 Service 的劫持和负载

Q8：使用 terway 插件后， pod 是如何访问 service 的 clusterip 的？

A：使用内置在 Pod 网卡上的 ebpf 程序直接将 serviceIP 负载到后端的 pod

Q9：能聊下阿里云对 service mesh 这块有什么规划吗

A：阿里云目前已经产品化了 ASM 的 Service Mesh 产品，后面的发展会在易用性，性能，以及全球跨地域云边端一体化连接等方向。

Q10：和 node 的网络打通后，如果一个 pod 的 ip 被复用，之前的 arp 缓存应该会有影响吧？同时出现节点级别的故障，是否会有 IP 冲突？

A：首先云上的网络不会存在 arp 的问题，一般 IAAS 层的转发采用 3 层的转发。如果云下自己使用 IPvlan 也不存在这个问题，使用 Macvlan 的话会有 arp 缓存的影响，一般来说可以采用 macnat 的方式（ebtables,ebpf 都可以实现哈）

是否存在 IP 冲突是要看 IP 管理策略，在目前的 Terway 方案中 IPAM 直接调用 IAAS 的 IPAM，是不存在这个问题的，自己线下搭建得考虑 DHCP 策略或静态分配 IP 地址去规避。

Q11：“通过 eBPF 对链路的简化，性能有明显提升，相对 iptables 提升 32%, 相对 ipvs 提升 62%；”为什么对 ipvs 性能的提升更明显？如果主要是对 iptables 的线性匹配和更新优化的话？

A: 这里的这个对比是针对只有一个 Service 的对比，是主要看链路简化的影响。iptables 模式是 nat 表进行的 DNAT，是只有 forward 流程，而 ipvs 是会经过 INPUT 和 OUTPUT 的，所以在单个服务的情况下 iptables 可能还会更好一些，但是 iptables 的线性匹配会让服务数量很多时性能下降明显。

比如 5000 service 时就 ipvs 更好啦 XD；

---

2020-04-14：Spring Cloud Gateway 全链路实现

石墨文档

Q1：有没有 SpringCloud 高可用 demo 可供学习，或者有没有推介的资料

A：demo 可以去 github 或 gitee 上搜索，书籍推荐《Spring Cloud 微服务实战》和《Spring Cloud 与 Docker》。

Q2：如何代理的 Socket

A：全链路没有支持 socket

Q3：Gateway 服务这块如果要做防跨站攻击，有什么好的方案？

A：使用前置的 Filter 过滤，Jsoup 的标签白名单机制可以用来进行防止 XSS 攻击

Q1：灰度方案实现？

A：网关从配置中心获取实时的配置，动态变更路由权重信息

Q4：如何在 gateway 做权限认证。你们是如果做的

A：通过 jwt 实现，每个请求传递 token 进行权限认证

Q5：是在网关统一认证好，还是每个服务都去做认证。说说你们的建议吗？有 demo 例子吗

A：网关层做认证，通过认证后将用户信息传递给后续服务，后续服务查看是否有调用该 url 的权限

Q6：如何跟踪分析 gateway 调用耗时的问题

A：目前主流的方案是对各组件进行埋点，但不一定能定位到真正耗时的情况，此时要进行 Sampler 的方式获取慢方法

Q7：目前 gateway 全链路实现，比如 skywalking 探针能做到么？还是得自己去埋点？

A：skywalking 暂时没支持，可以根据提供的思路修改实现

Q8：JWT 一般怎么做吊销或者超时校验？每次都从 redis 读会不会压力比较大？

A：将 jwt 存储到中间件 redis 中，设置超时时间。吊销问题比较好解决，客户端退出或修改密码后调用中间件清除。本来 jwt 这种方式就属于比较弱安全的方式，jwt 本身可以放时间属性，设置过期时间。这种方式呢带来的问题就会是需要续签，定时续签。另外一种方式就是 redis,不会设置过期时间或者说时间比较长，依赖 logout 来注销。这两种方式并不是一直都是访问 redis，对 redis 压力不会很大，续签可以设置时间稍微长一点。

Q9：可以展示下你们的全链路监控产品吗？你们怎么怎么做到监控信息的收集，存储和转发，展示以及告警策略的制定。你从头到尾讲解 APM 监控原理讲的很不错，可以介绍下你们的产品吗？与开源的 pinpoint 和 skywalking 的区别

A：暂时没有提供公网访问,这是我微信：jiang1990ing，有兴趣加我微信，我可以把内网开放访问下。开源 pinpoint 和 skywalking 是专业的 apm 开源产品，从产品定位上说就有区别，我们监控产品是矩阵式监控，apm 只是我们其中一个技术。我们监控的定位主要从客户在运维过程中处理故障的实际需求，根据报告故障只有 24% 是纯应用问题，还有很大部分是网络的问题，所以我们矩阵从纵向来说包含了网络质量的监控和应用依赖的基础设施的资源监控，就是为了解决运维过程中的综合性问题。横向才是全链路追踪的层面。当然在 apm 本身层面我们也做了一些细节的优化。

Q10 目前用 skywalking 定位到耗时发生在 Gateway 的 webflux 的 handle 上面 但是不知道怎么分析如何产生的耗时

A：第 9 题我提到我们对慢方法的捕获做了优化，特别是针对开发写的代码出现慢的场景，有时候开源根据实现原理的细微差别会捕获不到。现在我觉得是 skywalking 监控粒度不够，导致没有获取到慢的调用，通过我们这种方式应用是可以解决的，具体问题还是需要我们来具体分析。有需要的话，加上面的微信，我们可以提供 saas 服务，帮助你们定位下。共同进步。

Q11：我不太理解“后续服务查看是否有调用该 url 的权限”，到了应用服务后，还是要去认证服务吗？

A: 网关跟认证服务的网络隔离，认证服务只对内可见的情况下要求应用服务去认证服务鉴权

---

2020-04-07：滴滴开源监控夜莺的架构设计思考

石墨文档

Q1：Open-Falcon 到 Nightingale 的改造过程中经历了哪些过程和阶段，踩过哪些坑，可否分享下？谢谢

A：这个话题有点大，展开可以说很多，就说一个吧，在告警方面的演进，滴滴在引进 falcon 之初，将原来的 judge 处理数据的方式有 push 改为了 pull，这样可以更好的支持与条件，nodata 等告警，后面为了提高告警的时效性，我们又将 pull 模式改为了 push 模式，并且保留了与条件，同环比，nodata 告警的能力，开源的夜莺就是演进到最后的状态

Q2 能否稍微解读下个模块作用以及如何方便二开

A：我们把每个模块的功能都封装成了 pkg，所以很容易进行二次开发，现在可以直接看代码，后续我们会发布每个模块的源码解读文章，可以关注我们的官方动态：）

Q3：roadmap 和社区建设能否分享一下

A：可以参考这个 https://n9e.didiyun.com/docs/intro/#nightingale%E5%90%8E%E7%BB%AD%E5%8F%91%E5%B1%95

Q4：falcon 里存在大量循环 sleep 检查的逻辑 出于什么目的这样设计，而不是使用 channel

A：没有特别的目的 :)

Q5：相比 CNCF 下推出 prometheus，夜莺有哪些胜出的地方？对于已经使用 Prometheus 的，如何向夜莺平滑的切换呢？

A：我们在产品的易用性上做的更好:) 后续我们也有兼容适配 Prometheus 的计划

Q6：兼容适配 Prometheus 大概什么时候呢？。

A：这个今年会做，具体时间还没定

Q7：现在夜莺在滴滴里面的机器数量规模可以透露下吗

A：这个不方便透露：）

Q8：请问你们采集的数据一般最终会持久存储到哪里？

A：夜莺的 tsdb 有数据归档的机制，默认会保存一年的数据，我们内部的核心数据会保存比较长的时间，持久化也是用的 rrdtool

Q10：日志数据是怎么限流的？整个体系限流怎么做的

A：collector 的日志采集是流式处理的，没有做限流，如果日志产生量太大，可以将想要监控统计的日志单独输出到一个文件中

Q11: 想问下，有什么高可用的解决方案吗？

A:指的是夜莺么，夜莺的架构本身就是高可用的

Q12 容量评估怎么实现的？

A:可以参考官方文档 https://n9e.didiyun.com/docs/install/product/

Q13 请问你们一般什么场景下会有扩容需求？

A:主要还是看系统的资源使用率，内存、cpu 和磁盘这三个指标

---

2020-03-24：Kubernetes 在边缘计算领域的发展

石墨文档

Q1：适不适合用来部署管理 CDN 节点？同时需要注意什么？

A：是说的边缘计算还是 KubeEdge？ 描述不清楚。

Q2：边缘计算的边在哪里？网络的边缘到底是指什么，如何具象化？如何确定边的位置？边的位置和应用的关系？所谓的边与端的区别是什么？比如说摄像头算是边还是端？边缘网关算是边还是端？这个概念如何判断

A：边缘计算的边具体在哪里 其实没有很明确的概念， 一般主要看你的业务场景。网络边缘一般是指靠近客户现场一侧的网络边缘，在边缘计算场景下，应用是部署在边侧，就近计算，一般情况下摄像头我们可以是认为是端，但是如果摄像头自己有计算能力，有网络接入，能够部署应用，我们也可以理解是是边侧的计算节点。
s

Q3：边缘 cloud 节点高可用方式怎么做的？

A：是说的 k3s 还是 KubeEdge？ 描述不清楚。

Q4：为什么需要边缘计算？边缘计算解决什么 h？发展边缘计算需要具备什么条件？

A：分享里已经说明了。

Q5：云边同步怎么做的？

A：KubeEdge 云边同步主要通过 edgehub 和 cloudhub 这两个模块构建的 websocket 连接进行 Kubernetes 资源的同步的，连接请求首先由 edge 端发起，一旦 websocket 建立后，云端就可以向边缘侧传递数据。

Q6：如何保证云边状态的统一？Docker 形式的边缘应用的优缺点有哪些？

A：KubeEdge 最新版支持可靠性消息传输。云端的 Kubernetes 资源状态发生变化后，会默认通过 websocket 通道进行下发，如果这时候网络断开或者网络质量不高，会进行重传。但是这里为了防止资源状态数据的积压导致内存占用率过高，Kubeedge 充分利用了 Kubernetes 的去重队列，对资源数据进行去重处理。

Q7：k8s master，k8s node，kubeedge edge 节点三者是什么关系？在 master 上部署 cloudcore 去管理 edge 节点，那 k8s node 是否参与其中？是不是说 edge 节点只需要跟 master 节点上的 cloudcore 进行通信，不关心 node；node 也只在 k8s 集群内通信，不关心 edge？

A：K8s node 和 KubeEdge edge 节点 没有本质区别，k8s 的 node 是由 kubelet 像 apiserver 进行注册的，而 KubeEdge edge 节点是 KubeEdge 通过云边协同机制通过 cloudcore 进行注册的。通过 kubectl get node 看到都是 node，区别在于 edge node 会有专门的标签。

Q8：在 k8s 中，云和终端节点如何通讯的，全双工还是半双工的？实时还是轮询的？Ipv6 和 5G 是否应用其中？如何连接其中节点的？对于大量节点之间如何规划网域？是否存在安全问题？如何解决安全隔离问题？

A：k8s 中，master 和 node 是用过 list-watch 机制进行通信的，node 上的 kubelet 启动后，会首先进行 list 获取全量的数据，之后进行 watch，只 watch 变化的数据。对于 k8s 的容器网络来说，社区都有比较成熟的 cni 插件，flannel，calico 等等，可以根据自己具体的业务需求来使用不同的网络插件。如果对于安全隔离要求很高，可以让 k8s 跑在 vm 上，使用 vm 本身的隔离性。

===》再问： 我说的安全问题是，因为考虑节点之间的自治势必存在节点互通情况，比如这种场景： 我和我家邻居冰箱都用同一个 cloud 服务，会不会出现对方通过节点之间的通讯，hack 访问到我的冰箱。

===》A: 这种我觉得应该是称作为 saas 服务 会比较合适，虽然你和你家邻居的冰箱感觉是在边缘侧，但是这种应该不属于边缘计算场景，而且节点自治和节点互通也没啥关系。

Q9：kubeedge 和 edgex 能结合使用吗？

A：我个人没有应用实践过。KubeEdge 是 Kubernetes 在云端向边端的延伸。如果你如果曾经将 Kubernetes 和 edgex 结合使用过，理论上 KubeEdge 也是可以的。

Q10：老师您好，请问是不是 每一个边缘侧 edge 节点都需要具备能够访问公网的能力，但是不需要公网 ip？如果要查看被调度到 edge 端容器的日志应该怎么查，边缘侧没有 kubelet，无法使用 kubectl logs 调用 kubelet api 查看日志。

A：是的，因为边缘侧节点需要与云端通信，一般情况下，边缘侧节点都需要具备访问公网的能力，但是不需要公网 ip。关于 kubectl logs 这个特性社区会在 1.3 版本发布。

Q11：完全是 kubeedge 新手的话，该从哪里入手呢?

A：https://kubeedge.io/zh/ ,另外有什么问题可以在 KubeEdge 社区里提 issue 或者 slack 里提问。另外 KubeEdge 社区没两周周三下午会有社区例会，相关连接可以查看：https://github.com/kubeedge/kubeedge

Q12:边缘设备上运行的容器支持 arm，有在 Android 上跑过没，需要哪些适配？之前试过 k3s 卡在 cgroup

A:android 暂时没有跑过。

Q13: KubeEdge 当前是否有应用于哪些商业场景？

A: 最典型的是摄像头类场景，比如汽车保养门店，园区人脸识别入园，车牌识别等等。把 AI 计算类应用部署在客户现场一侧（比如汽车门店或者园区），直接就进图像识别。

Q14: KubeEdge 现在有支持哪些终端直接跑 node? 除了前面提到的树莓派、交通灯

A: 树莓派一般是用于开发测试场景。有兴趣的可以尝试一下华为的 atlas 开发者套件。一般 arm 架构的服务器都可以。

Q15: 您觉得当前很多终端无法跑成 KubeEdge 的主要困难点在哪？

A:

Q16:现在运营商也在大力做边缘计算，请问 5G 与边缘计算结合的典型场景是什么？

A: 运营商主要是在做 MEC 层面。5G 与边缘计算最典型的场景就是自动驾驶。

Q17:请问 KubeEdge 实际部署中遇到哪些问题？如何解决的? 现今面临的主要挑战是什么？

A:主要是边缘场景下，客户对云原生，Kubernetes 的理解程度不一样，需要时间。这就跟最开始 Kubernetes 诞生以后，对传统观念是一个冲击。

Q18: KubeEdge 对关键功能是否有监控？监控方案是如何做的? 报警规则分别有哪些？

A: Kubeedge 1.3 版本计划提供 metric 功能，可以使用开源普罗米修斯去监控报警。

Q19: K8S 适合跑在 vmware 平台还是 openstack 平台？

A: 都可以。

Q20:可以介绍下边缘计算在自动驾驶场景的应用吗？

2020-04-02：Kubernetes 在本来生活网的落地实践

Q1:不使用 kubeshift rancher 等，直接使用原生 k8s，如何实现多租户管理？通过什么实现？

A：你可以尝试下我在分享中提到的 KubeSphere 平台

Q2：k8s 在生产上部署，推荐二进制还是 kubeadm 安装？kubeadm 安装除了提高运维难度，在生产上还有什么弊端

A：我们使用了 kubeadm 部署 k8s；建议选你们运维团队较熟悉的那种方式部署。

Q3：如何入门学习 k8s

A：很多方式，有本书可以推荐《Kubernetes in Action》

Q4：用 prometheus-operator 监控 k8s 的时候，有点不明白为啥默认的阈值要那么配置，比如说 apiserver，我怎么去定义我的阈值，只要报警了，我就知道 apiserver 有问题了

A：若要对 apiserver 的高可用进行监控，可先对 ready/desired 数量进行比对，其次可以在集群外部对 apiserver 进行访问监控。

Q5：我现在看好多项目，用户开始用 k8s 替换 yarn 做资源调度，这两者有什么区别或者优劣势？

A：对 yarn 不是很了解，不好下结论

Q6：我们这用的是 dubbo，pod 更新的时候，比如说已经进来的流量，我如何去优雅处理，我这 pod 更新的时候，有依赖这个服务的应用就会报 dubbo 超时了

A：这个我们也在优化中，目前的方案是在进程收到 SIGTERM 信号后，先禁止所有新的请求（可以使 readinessProbe 失败），然后等待所有请求处理完毕，根据业务特性设置等待时间，默认可以为 30 秒，超时后自动强制停止

Q7：请问你们服务如何做 HPA 的？

A：目前还没有使用 HPA

Q8：最近我们在调研把数据库跑在 k8s 上，不知道大佬有没有这方面的经验可以分享下

A：没有这方面经验，目前我们对存储还处于研究状态，尚未考虑把有状态应用全部部署在 k8s 之上。我的建议是，你必须有一个比较可靠的存储才能做这件事。

Q9：Jar 包启动时加 jvm 限制吗？还是只做 request 和 limit 限制？

A：我的理解是 request 和 limit 只是对整个容器的资源进行控制； 而 jvm 的相关参数是对容器内部的应用做限制。

这两者并不冲突；可以同时使用，也可以单独使用 request 和 limit ；只不过 jvm 的限制上限会受到 limit 的制约.

Q10：存储用的什么方案？能分享下么？

A：Ceph-RBD

Q11：ceph 用的 bluestore 还是 filestore?

A：BlueStore

Q12：net core 应用部署在 k8s 中相比 Java 操作复杂吗，想了解下具体如何从.net 转到 net core 的

A：1）实际在 k8s 内部署.netcore 和部署 java 都一样，选择好对应的 dotnetcore 基础镜像版本；然后以该版本的为基础制作应用的镜像后部署到 k8s 即可

只不过在选择 dotnetcore 的基础镜像时，我建议直接选择 sdk 正常版本。我们试过 runtime、sdk-alpine 等版本，虽然这些版本占用空闲小；但是你不知道它里面会少那些基础库的东西，我们在这个上面踩了很多坑。我们现在选择的基础镜像是：mcr.microsoft.com/dotnet/core/sdk:3.1

2）转换过程根据程序的复杂度决定，有些应用没修改业务逻辑，而有些改的很厉害。

Q13：镜像 tag 和代码版本是怎样的对应关系？

A：我们的镜像 tag = 源码的分支: [develop|master] + 日期 + jenkins 的编译任务序号; 如:master-200401-27 这样。

当这个 tag 的镜像在线下都测试完毕时准备上线了, 那么就以这个镜像的 Tag 作为应用代码的 Tag 编号. 这样就能够通过镜像的 Tag 追溯到应用代码的 Tag 版本

Q14：Centos7 的系统版本和内核版本号，能说明下么

A：内核版本：3.10.0-1062.12.1.el7.x86_64，这个对应的是 CentOS 7.7，具体可参见 https://access.redhat.com/articles/3078

Q15：本来生活的日志和监控方案是怎样设计的？

A：由于 KubeSphere 的日志在老版本有延时，因此我们线上是采集到 Kafka 然后通过现有的 Kibana 进行查询，也就是 ELK，监控是基于 KubeSphere 自带的 prometheus，没做太多修改

Q16：KubeSphere 是开源的吗？

A：是开源的，项目地址（https://github.com/kubesphere/kubesphere），是由青云团队研发的

Q17：你们有没有对 Porter 进行二次开发？

A：读过源码，目前还没有人力和需求进行二次开发

Q18：Jenkinsfile 调用接口是采用插件还是使用 shell 的呢

A：我们暂时采用的 shell 的方式。

Q19：kubesphere 的 terminal 不是很好用，请问您那边是否对此有何改进；另外我之前查看 kubesphere 的代码，发现开启 elk 之后，容器日志读取会直接转向 elasticsearch，如果不对容器做 elk 日志收集的话，那么我们在 kubesphere 界面中将无法读取到容器的日志，对此您那边有过类似的遭遇吗。谢谢

A：1）我们遇到的不好用的情况主要有会话保持问题，在进入 web terminal 时，输入 while :; do sleep 5; echo -n ‘ ‘ >&2; done & 即可保持会话。

2）关于日志延时的问题在 2.1.1 中修复了，你可以尝试下

Q20：应用的回滚过程 (Deployment 或者 Statefulset) 是手动回滚还是通过 pipeline 自动化回滚？

A：pipeline 自动化，分享里讲到我们有几种 pipeline 类型，其中一个就是应用回滚

Q21:你们对容器监控是采用哪种方式，另外应用的监控是如何做的，主要是性能这部分，比如阿里云的 ARMS，目前在看这个

A：监控的部分我们还在优化中，主要思路是对 ready/desired 数量进行比对；应用的监控是指业务监控吗？

Q22：kubesphere 对 Istio 微服务治理支持得怎么样？你们后续的微服务治理是基于 Istio 来管理吗？

A：KubeSphere 默认支持 Istio，不过我们目前的微服务还无法与 Istio 对接，因此没有使用，你可以参考他们官方的文档和视频

Q23:你们 yaml 模版复用是怎么使用的，helm 有用到吗？

A：我们把 yaml 文件内一些应用相关的数据抽取成变量，使之成为应用 yaml 文件的基础模板；

然后在 pipeline 构建时通过接口获取到对应应用的相关参数，将这些参数结合 yaml 文件模板自动填充后生成对应应用的 yaml 文件；然后进行部署操作。Helm 没有在应用部署中使用，但中间件有。

Q24:pod 绑定了 svc，使用 LoadBalancer 的 ip 自动注册注册中心，这块如何实现的。

A：我们的微服务是手动注册 IP，如果自动的话需要与 pipeline 结合

Q25:有做多集群管理吗？

A：未来计划

Q26:冷加载怎么重启

A：你说的冷加载是什么

---

2020-03-17：国内某知名婚恋网站的 Kubernetes 落地实践

石墨文档

Q1：请问 lnmp 网站架构容器化上 k8s，nginx 和 php 是各设 pod 吧？mysql 采用一主多从架构？用什么做存储？

A：lnmp 建议是 nginx 和 php 放在同一个 pod 中，然后外层再加一个 nginx，做 upstream。
mysql 应用上 k8s 要用 statefulset。不过我们目前内部这一块是还没有迁移到 k8s 集群中的

Q2：公司在 go 语言上有哪些项目，怎么看待 go 语言

A：我司目前尚未使用 go 语言，java 为主

Q3：pod 的滚动更新（优雅重启）怎么做的，有没有做 pod 落地升级？

A：滚动更新 k8s 的 deployment 中有相关的 rollingUpdate 策略，优雅停机有两个注意的点，一个是我们要确保应用发的 SIGTERM 信号，另一个是代码要确保收到 SIGTERM 信号后优先关闭端口或者取消服务注册。
pod 落地升级？是指原地升级吗？这一块我们目前未做

Q4：harbor 的使用版本？镜像的后端存储是什么？harbor 的部署形态？如何解决 harbor 的高可用问题？

A：harbor 使用版本这里不方便说。不好意思哈。镜像后端存储我们目前用的是腾讯云的 cfs，性能上目前够用。harbor 部署形态，我大概描述一下：ng/lb 反向代理到后端 harbor，harbor 存储用腾讯云的 cfs。如何解决 harbor 的高可用，这一块我们目前未做，后续研究一下

Q5：除开 k8s 自身的监控，容器内部服务监控是如何做的？如果在子网，监控怎么透出？pinpoint-agent 嵌入到 container 里面有没有需要优化的地方？

A：容器内部服务监控我们是用 pinpoint 做 apm 监控。监控怎么透出？这里不是很明白这个问题，不好意思哈。pp-agent 嵌入到 container 里边有没有需要优化的地方，这个还好，因为我们目前这一块都是做在基础镜像里边的，启动的时候加启动参数就好，步骤也挺简单的

Q6：请问前端是怎么暴露在外面的，ssl 证书怎么才能做到自动签发？

A:前端静态资源暴露我们有两种吧。一种是直接放在 ng 静态资源目录里边然后加上 cdn，另外一种是放在 k8s 集群中，前面 nginx 做反向代理，配上静态资源相关的缓存策略。
ssl 证书自动签发，k8s 集群内我们目前用的是托管类型的，所以这一块未涉及。集群外其他 ssl 证书未做自动签发的证书。

Q7：请问在哪里看视频??直播在哪……

A：哎呀，没有视频，后面会整理文章。

Q8：容器的 tcp 连接数怎么监控

A：这个目前未监控，后续打算用 prometheus

Q9：gitlab 接收一个 push event 触发构建，这个是监控所有的分支吗，分支模型是怎么样的

A：不是的，按需。我们内部分支模型大概有四种，dev——>test——>release——>master。master 以外的为了效率都会做自动触发

Q10：请问规模是？大概多少 node，会跨很多集群吗

A：我们内部的集群规模，生产集群数量是 4 个，不过是有大有小，是按业务来划分的。最大的一个集群是 2700G 内存，node 节点将近 50 个。node 节点数量要根据每个节点配置来看，配置高，节点数量就少。

Q11：为什么不直接用 gitlab-runner 而接 jenkins

A：gitlab-runner 需要每个仓库都配置构建信息，当需要统一修改构建的时候很麻烦

Q12：“pod 已实现与 node 节点在同一网络层面，促进了我们后面的快速落地。”这个是什么需求？

A：原生的 k8s 集群跨集群调用网络上默认是不通的。

Q13：请问 dubbo 在转向 K8S 或 istio 网格化改造过程中，传统环境与容器化环境共存互相调用时，是否遇到什么坑？如何化解的？谢谢~

A：网段冲突吧。我们曾经做过一段时间的 docker 单机，但是当时没有配置 docker 的网段，导致后面冲突的时候出现网络不通。解决方案：指定 docker 单机的网段

Q14：TKE 如何跟公司内部系统的用户权限打通，能否说下细节？

A：权限没有打通喔，这个还是依赖腾讯云的权限控制

Q15：长连接在ingress-nginx 场景下，nginx reload 时会断开。若ingress 进行增、删、改操作，每次都需要 reload，如何保证长连接业务的稳定性。ingress 有没有性能瓶颈？

A：目前还是依赖业务端的重连机制。性能瓶颈目前好像还没遇到过

Q16：『因为我们的服务暴露方式用的是ingress，所以直接利用 kubernetes 的 service 服务发现的能力来实现灰度发布』，请问一下具体怎么做的？根据 header 选择 lable 吗？

A：不是的，目前没有做到这么细致。就是 deploy 两个 deployment，用相同的 label，service 通过 label selector 做发现

Q17: 在 CD 的过程中 ，版本管理是怎么做的 ？是基于镜像的 tag 还是 helm 的版本？包括回滚的策略与方式

A：用的是 helm 的版本管理，回滚策略和方式都是用 helm 的

Q18: HPA 具体是咋做的，根据什么指标扩缩容的？集群升级咋做的

A：hpa 是根据 cpu 做的。集群升级是先升级 master 再升级 node 节点，这个还是按照 TKE 的来做

Q19: 后端存储是怎么做的？用的是厂商的存储还是开源的存储？

A：厂商的

Q20：）ingress-controller 节点上的短连接问题，短连接变长连接这个是怎么处理的？能提示一下吗？

A：这个不是指通过ingress-controller 去做短连接变长连接，是说客户端发起的连接要用长连接的意思

---

2020-03-12：Kubernetes 生态体系落地过程中的选型和踩坑

石墨文档

Q1：落地过程必然涉及到之前开发、测试和运维流程的变更，组织和相关人员都会面临调整，这部分工作贵公司是如何推进的，踩了哪些坑，如何解决的？

A：这个……一言难尽啊，人的问题是最难解决的，能用技术解决的都不是问题，要是说回答的话，初期打通公司各个关节，让大 boss 认可这件事，行政命令强推，很重要。不然做出来也没人用，就是白忙活在用户中找小白鼠迭代，而不是自己弄个自以为完美的推出去

Q： JAVA 容器瞬间拉起的过程, 整个集群都会被 CPU 用尽，如何解决 JAVA CPU 启动时候 CPU 资源互争的情况

A：这个问题我们也遇到过，后来把内核升级到 4.19 后就不再发生了，很多内存耗尽，cpu 爆炸的问题我们都通过内核升级解决了

Q2：elk 还有文件存储平台是搭建在 k8s 系统内的吗？另外贵公司管理 k8s 服务是否选用了诸如 rancher 之类的管理平台

A：elk 在集群里，开发测试环境用了 rancher，线上自己开发的管理平台，毕竟 rancher 是真的好用

Q3：日志平台怎么解决没法像 grep -C 查找上下文，日志平台怎么标准化日志格式

A：这个得看日志平台具体开发是怎么实现的了，一般来说这不是问题日志格式的标准化，得和业务合作。事实上日志平台一般是中台部门的单独的系统，它要单独开发

Q4 容器化落地怎么协调开发的需求，比如开发学习成本，比如本地调试和现场保留复现问题，排查问题的方法方式对开发友好

A：这还是人的问题，很多业务开发不愿意学习，不接受新事物，一叶障目否定容器，这真的没办法。还是从人身上寻求妥协吧。每个人的精力都是有限的，这种事情陷进去很难拔出来公开培训，讲座，驻场支持，培养业务部门懂的人

Q5：容器环境如何落地文件存储，或者对象存储，如何选择后端的块设备。

A：我们选用的是 cephfs 和 nfs

Q6：线上 k8s 集群采用什么方式部署，二进制还是 kubeadmin 等，部署架构是怎么样的

A：如果了解证书制作和 k8s 各个组件的作用，建议从二进制文件入手，企业环境可以自己写 ansible 等脚本。kubeadm 维护一般不适用于线上环境

Q7：能否直观的谈谈的用容器构建弹性服务过程中的业务系统存在哪些文化问题?请不要回避现实，谢谢!

A：文化问题？这我可以吐槽很久……但不适合在这里讨论

Q8：集群网络方案怎么选择的，对外提供服务如何做的

A：ingress controller 可以用 hostport 暴露，外层 nginx 去 upstream 一下

Q9：如果服务发现用 zookeeper，那 dubbo 服务要实现灰度发布如何实现？

A：目前我们的灰度发布都是基于ingress 方案，nginx ingress controller 允许直接使用 nginx 规则配置，traefik 功能也足够强大由于我主要的开发技术栈是 golang，不太了解 dubbo

Q10：长期存活的容器会造成容器日志堆积，请问有没有不重启容器就能实现清理与归档的方案？

A：这个问题我们有想过，但是没有什么方案。如果从源头上规避，可以让业务日志不要落地成文件，或者自行按日期流转

Q11： 如何采集 k8s 中的容器前台日志？filebeat 貌似只能采集文件吧

A:前台日志也就是 std 日志，分享中提到用 fluentd 和 hostpath 采集物理机 docker 目录中的内容可以去了解一下 docker 目录结构

Q12: 监控系统数据持久化方案是什么？ 如果保证监控系统的数据正确性呢？

B:数据持久化我们用了 tidb，外部用 zabbix 做了一层冗余

Q13: 我是一名 Java 工程师，有 7 年经验，想转行到容器相关领域，请问成为容器开发工程师需要哪些条件？

A: 对 linux 要非常了解，脱离 jvm 看一些系统方面的知识。此外容器的语言基本上都是 go，微服务那套和 java 没啥区别，熟悉 protobuf

Q14 std 日志是如何区分不同 pod 的？

A: fluentd 有对应模块，收集到之后直接就有 hostname 和 ns

Q15 如何保证日志 sidecar 的存活与否不会影响到业务容器？有没有考虑过未来增加数据面代理 sidecar 比如 istio 的 envoy 后，单 Pod 的状态判断会受到影响？

A: sidecar 和业务容器本来就是互相隔离的，现在 1.10+ 的 k8s 在 pod 内只会共享网络，不会默认共享 pid 了，应该不会有啥影响。后一个问题不太懂

Q16 event 采集是如何实现的, 是否可以开源代码?

A: 我记得 sentry 就有一个插件能实现。公司代码未得许可不会开源

Q17 PHP 容器镜像是自己编译的还是用官方的镜像? nginx 和 php 编译在同一个容器中吗？容器中的 Nginx 直接暴露 80 端口吗？身边使用 PHP 容器的好少，有什么要注意的地方或者坑? 这方面知识欠缺，谢谢。

A: 自己打，java 包含了 tomcat，我们的 php 也包含了 nginx，是的

Q18：sidecar 方式收集日志会出现延时，特别是丢失问题，这个如何解决减少 filebeat 的采集时间，这个我感觉无解。或者在 gracefultime 上做文章，让 filebeat 多活一会

Q19 集群压测方面可以介绍一下么，k8s 官方的 benchmark 工具？官方的用了，但是很鸡肋，这块我们的建设很不够

Q20 为什么只给 sts 做固定 ip 呢？

---

2020-02-25：Kubernetes 在喜马拉雅的实践：测试环境稳定性

Q1 测试环境只是开发自己用吗？开发和测试共用一个测试环境吧？

A：开发测试好了之后，钉钉沟通，哪个隔离组信息的。同步一下这个信息就好了哈

Q2：隔离组和 git 分支是一一对应吗，如何关联 git 分支、隔离组和 pod 版本

A：隔离组和 git 分支是一一对应吗？不一定，大部分场景下面是一致的。git 分支、隔离组和 pod 版本这些信息会以环境变量的形式注入到容器里面，我们这有一个 agent 容器，将这些信息同步。

Q3：k8s 集群的容器网络是怎么组成的呢

A：测试环境使用的是最简单的 macvlan，uat、线上用的 calico

Q4：请问下喜马拉雅现在运维团队大概是多少人,k8s 规模能大概说一下吗 K8s 环境是自建的还是选择公有云的 是基于什么样的考虑

A：运维团队比较精简，人数在个位数。之前都是只有一个大佬维护。k8s 在测试环境和 uat 自建，线上公有云。基于什么样的考虑？这个得运维大佬来解释了

Q5：您的隔离组访问的分配是用的什么技术，istio 还是 nginx ingress 或者其他？还有 cmdb-docker 是 cmdb 的一部分吗？非常感谢

A：istio 和 nginx ingress 暂时还没有使用，路由的方式比较传统，使用网关 + 微服务框架的路由功能。请求直接打到 nginx，转发给网关。将隔离组信息注入到请求里面。cmdb-docker 是 cmdb 的一部分吗？和 cmdb 并行的关系，用于容器服务的发布，说成 cmdb 也没啥错。service mesh 已经在落地中，后面的化应该会对 mesh 化的环境进行隔离策略的调整，主要的还是路由配置相关的

Q6:对于多集群你们怎么管理呢，例如安装，监控，日常维护，不同业务会怎么隔离

A：这个问题太运维了，我请教一下运维大佬，再来回复

Q7：您那边有没有调研过 rancher 或者 kubesphere 等其他容器管理平台

A：有研究过，但是没有引用

Q8：请问微服务监控具体怎么实施？

A：微服务的监控这个就涉及到了微服务方面的问题了，具体的实现可以参考 hystrix 里面的统计实现，本人没参与过这方面的开发哈

Q9：这个测试环境是不是测试工程师和开发工程师共用的，只要开发部署成功，测试就可以开始验证了？

A：是的

Q10：请教一下：目前喜马拉雅的每个容器集群规模有多大？是运行在物理机上还是虚拟化平台上呢？

A：每个容器集群规模 100+，物理机

Q11: 整个平台使用的容器网络是什么？ 目前测试平台是否交给公司的独立的运维部门运维，还是运维已经实现 DevOps 了？

A: 网络：测试环境 macvlan，uat、pro calico。交给运维管理。

Q12: 如果支持 canary deployment，两个版本的软件是怎么保持 session-sticky 的？是在
APIGateway 实现的么？

A: 是的

Q13：你们用的是什么微服务框架？流量到了 stable 环境之后怎么知道要回调到 feature 环境？需要在微服务框架注入相关代码吗？

---

2020-01-07：电视云服务的容器化实践

提问链接

Q1：微服务代理，能详细说说嘛？

A：一般两个作用，统一服务地址和负载均衡，可以用 LVS + Nginx 。在我们的业务中，有些业务逻辑解耦给了代理服务（统一网关），比如 JWT 用户统一认证等等，还有一些涉及业务逻辑的，比如电视抢红包，用随机算法只将一部分流量放到后端，进而使用了 OpenResty/Lua 组合。

Q2：监控使用的啥？

A：当前监控使用 sysinner/innerstack 内置的监控功能，基于 docker/sdk-golang 和 leveldb-go, 结合一些前端开发工作（主要是 chart 展现）

Q3：微服务改动时，代理是如何感知的？是否要频繁重启代理？这一块是怎么实现的?

A：微服务改动，先将配置推送到代理服务，再操作容器，LVS 和 Nginx/OpenResty 变更配置不需要重启，当然这个地方也需要容器应用配合，避免容器之间直接通信。

Q5：lxcfs 部分的说明缺失，你们是怎么处理容器内读取 cpu memory 一些指标反而读取到宿主机配置的呢？(目前已知 JDK8 131 之前也存在这个问题，另外可以通过修改文件系统获取到正确指标)希望得到解答，谢谢。

A：lxcfs 部分我们是参考了 pouch-container 里面的方案，只不过是创建容器时把 lxcfs 包含的目录 mount 到容器中即可

Q6：使用 XFS 限制容器挂载的目录大小具体是怎么做的呢？能否说下思路和相关参考

A：一般前端业务，容器挂载目录只存放日志，10GB 左右。后端涉及到数据持久的应用，比如 MySQL ，SSDB 这个按照业务预估，一般 50 ~ 500 GB 。具体可以搜索 “xfs quota , project quota”

Q7：你们线上基于 Docker 单节点部署服务吗？

A：单节点有测试服务器；其实单结点和集群对于 docker 的操作时一样的

Q8：有没有根据业务负载来操作容器伸缩（增减）的功能

A：有，比如元旦、春节前期，按照预估扩容 VPS 时，会预留部分资源，正式上线运行中如果有模块负载高，会实时把这个模块推送到预留资源；如果没有富余机器了，就按照优先级把部分模块降级服务

Q9：CPU 限制这一块能细说一下吗？貌似用的更多的是 CPUshare？

A：比如给一个容器 2 cores 资源，则 –cpu-period=1000000 –cpu-quota=20000000 –cpusets-cpus=0,1 (cat /proc/cpuinfo)

Q10：可以问一下视频存储用什么，还有搜索服务用什么搜索引擎，还有发布版本的时候，数据库结构更改怎么做到不停机更新的，作为一个小白我很好奇

A：视频存储用传统企业盘柜； 搜索用 sphinxsearch + 定制修改；数据库一般准备两套，如果升级涉及数据库变更（可能锁表），则是暂停写业务，再操作 （这个期间查询业务不受影响）

Q11:公有云的流媒体视频资源怎么做到低延时高带宽分发到不同地域的终端上的的，多地部署、运营商专线？

A： 这个当然是公有云服务商 CDN

---

2020-01-02 ：为你写诗：3 步搭建 Serverless AI 应用

提问链接

Q1：这个 FUNCRAFT 是 ALI YUN 定制的吗？有没有可以量化可以说明的支持并发计算量的内容呢?我理解是通过 API 屏蔽了容器和 ECS 对吗？

A1：Funcraft 是 aliyun 函数计算自己开发的工具。函数计算的默认最大并发度是 100（更高的值需要开工单），每秒请求数 * 请求处理时间（秒） = 最大并发度， 更多细节可以参考函数计算的文档 。函数计算不仅仅屏蔽了容器和 ECS 这些计算资源，还屏蔽了负载均衡，自动伸缩，网络资源和共享存储等一系列的基础设置，所以才被称作 Serverless。

Q2：预留资源的函数计算不就和弹性容器一样了吗？那么函数计算的最大优势并不能体现出来?

A2: 预留和按量是可以结合使用的。真实业务的负载往往是有基础的部分和变化的部分，所以函数计算推出预留可以以更低的成本来处理掉那基础不变部分的负载。当然弹性容器也可以处理基础部分。但是如果让用户把应用部署成弹性容器和函数计算相结合形式，那对应用的架构要求会比较高，所以预留和按量的结合的形式也可以降低用户的使用门槛。

Q3: 在做微服务开发本身就是把各类应用逻辑接口化!这个函数式计算是否就是微服务的先决环节呢？

A3: 函数计算也可以理解为微服务的一种形式。有人认为 FaaS 是下一代的微服务。微服务相对于单体服务来说，解决了两方面的问题。一方面，不同业务模块有更清晰的边界，不同模块支持以不同速度进行迭代。另外一方面，不同部署模块的负载和对稳定性的要求不同，可以更细粒度的去调节不同模块的实例个数。而函数计算（FaaS）采用了按量或者按照请求进行调度的方式，也就是说在 FaaS 平台下，如果某些业务模块没有访问量，实例个数可以收缩到零。虽然微服务架构也能弹性收缩，但是没法收缩到零。理论上 FaaS 进一步提高资源的利用率。

Q4: 对于数据面与控制面分开 funcraft 有没更好的理解呢?(指的是函数式计算接口是只考虑时延，速度以及成本，还是有从数据和控制层面整体优化考虑的呢)谢谢!

A4: funcraft 只是函数计算的工程工具，一个命令行而已。函数计算平台是有分数据平面和控制平面的。控制平面又有细分，用户可操作的和平台可操作的。函数计算暴露给用户的控制比较少，比如扩缩容是自动的，不需要用户干预。

Q5: FaaS 场景下文件过大问题,具体是什么问题？

A5: FaaS 为了达到百毫秒的延时，会要求应用的打包不大于 50M，这个限制会影响到很多应用，比如 Python 装一个 Tenserflow 就上百 M，java 随便搞个 web 应用也可以大几十 M。我们通过将 FC 和 NAS 服务结合，把一部分库和数据放到了 NAS 上，然后运行时加载，以解决大文件包冷启动过慢的问题。

---

2019-12-26：如何在 Kubernetes 中编写自定义控制器

提问链接

Q1：crd 如何解决验证参数合法性的问题？

A：这个知识点也是本文欠缺的，可以通过 Open API v3 schema 进行验证

Q2：yaml 文件如果最小化展示

A：kubernetes 有很多默认属性的，这需要具体查文档呀

Q3：operator 本身挂了怎么办？依赖其他系统重新调度吗？

A：operator 本身要是挂了，自定义资源的控制器是不能工作的，这时其他的调度系统也不能代替的

Q4：有什么方法可以监控并保存 pod 的 cpu，mem 使用情况，并将他们保存入数据库或者生成 cvs 文件？

A：prometheus，可以看看 prometheus operator

Q5：怎么解决 crd 升级的问题，比如更改字段，但是已有服务已经运行

A：这是 kubernetes 的控制器通过获取资源资源的实际运行状态与期望的状态对比，如果不相同则删除老的 pod 然后拉起期望的 pod

Q6：假如我想通过 cpu 负载的预测值改变 pod 数量，我如何将预测函数加入自定义控制器，从而改变 pod 数量？

A：理论上讲这部分逻辑写到控制器的 reconcile 函数中是没问题的。但是我觉得更应该从调度策略上解决这个问题，即在调度时通过策略选择合适的节点。

Q7：接着上面问题，改变 pod 数量时，可否通过函数判断，先使用垂直伸缩在进行水平伸缩，那请问如何实现垂直伸缩？

A：不知你说的垂直伸缩是不是意味给 pod 分配更多的资源。如果是可以通过自编控制时定义资源属性，用户可以自定义对应的资源属性实现垂直伸缩

Q9：能否讲解下 reflector 具体工作原理

A：大致为下面：1. 通过反射器实现对指定类型对象的监控 2. DeltaFiFo 队列，将上一步监控到有变化的对象加入到队列中 3.并将队列缓存到本地，并根据事件类型注册相应的事件 4. 最后将对象 pop 到 work queue 供 control loop 触发上一步注册的事件函数

Q10：触发更新事件时，代码里如何获取到 cr 更新之前的状态？

A：通过包 k8s.io/api/core/v1

Q12: 如何在一个对象控制器的 eventHander 中触发另外一个资源 controller 的 Reconcile 入队呢?

A： 理论上 kubernetes 控制器是在监测到资源的创建/更新/删除事件后，会自动去触发 reconcile 函数。我觉得我们做 kubernetes 二次开发首先要遵循 kubernetes 的编程规范呀

---

2019-12-19：阿里云如何基于标准 K8s 打造边缘计算云原生基础设施

提问链接

Q1：如何适配不同的平台？OS 不同（linux 及各种发行版、非 linux）、硬件架构不同（x86、ARM 等等）。不同平台的节点能在同一个集群内管理吗？

A1：可以的；当前 ack@edgemailto:ack@edge 支持 OS 类型：linux（centos、ubuntu），windows server；CPU 架构：X86，arm 边缘节点接入；支持异构节点在同一个集群管理；k8s 管控托管在云上，异构节点的支持主要在边缘端实施；

Q2：如何应对 worker 节点网络不一定通的问题，通过 servicename 或者 clusterIP 是否还能访问？

A2: 分两个角度：1. ACK@Edgemailto:ACK@Edge 提供了完整的标准的 k8s 能力，所以 servicename 和 clusterIP 默认是可以 work 的；2. 如果 worker 节点间网络不通，那么 Pod 间东西向流量是不可达的；所以我们扩展了 service 的 scope 能力，service 的流量只会被限制在一组网络可达的节点之间转发（就是分享中提到的 edgeunit）；

Q： 边缘能自治到什么程度，还能正常做增删改查吗？apiserver 资源发生变化时节点还能感知和同步吗？目前如果触发了边缘自治，对我的应用程序会有哪些影响？

A3: 首先，明确边缘自治工作的时机是在边缘节点和云端管控失联后，此时为了防止脑裂云端会限制相关应用和节点资源的操作；apiserver 资源的变化只能够在网络恢复后同步到 worker 节点，并且网络恢复后，woker 节点相关的资源状态仍然以 apiserver 数据为准；进入自治状态后，节点上 agent 和应用都只能够消费断网前一刻的资源状态，自治组件 edgehub 替代 apiserver 接管了所有发往 apiserver 的请求；

Q： k8s 具备很好的应用容灾能力，ack@edge 在应用容灾方面具备哪些能力？

A4: ack@edgemailto:ack@edge 就是标准的 k8s；除了具备 k8s 原生的应用、资源管理能力之外，在边缘场景还提供了断网自治，元信息保持等等能力，这些也都是为应用容灾考虑；除此之外，因为提供的标准 k8s 完整能力，k8s 周边生态 servicemesh、knative 等都能很好支持；

Q： 项目是否有开源的计划

A5: edgehub、edgetunnel、edgeunit、knative-edge 等相关边缘能力都在开源流程中，敬请期待；

Q：可否直接打通云，边，端的网络，比如我边上的 pod 访问云上的服务，直接通过 servicename.namespace.cluster.svc.local，而不是用ingress 暴露云上服务，目前 kubeedge 经过定制是具备这个能力的，还未做生产验证。,,,阿里的和 kubeedge 及 k3s 有什么区别

A6: 这个问题的本质是容器网络能否跨云，边，端；在 ack@edgemailto:ack@edge 中我们也支持 overlay 跨公网的安全方案，支持反向网络穿透打通云、边，支持 VPN 网络等；

Q：ack@edge 是否有提供原生 k8s API?还是经过封装后的 API?云边直连的安全问题，要把 apiserver 直接暴露到外网是不是不太安全？

A7: ack@edgemailto:ack@edge 的设计理念是将原生的 k8s 托管在云上，支持接入边缘算力；用户可以很便捷的通过产品界面配置并生产出一个原生的高可用的 k8s 集群，并默认安装上支持边缘能力的 addons 和 operator，因此边缘 k8s 提供了原生的 API；云上 apiserver 通过阿里云 slb 暴露，对外提供服务，通过云上 slb 服务的安全能力结合 k8s 的认证、鉴权能力保证了云上 apiserver 的安全；

Q： ack@edgemailto:ack@edge 容器化后的程序与激光雷达、深度相机、imu、com 通信协议的底层控制板等传感器的通信和数据交互是如何进行的？是否能够提供稳定的数据交互通道？点云及图像数据的传输与直接运行在操作系统上的程序是否会有差别 ？

A8: 应用容器化与否和对物联网协议的支持不冲突；传统的裸进程部署和容器化部署对应用而言是不感知的；数据通道需要依赖其他的物联网协议支持

Q9：ack@edge 在面向 IoT 设备接入是通过什么实现的？是通过容器加载的 IoT PaaS 还是有一些专门的组件支持，例如设备接入、M2M 引擎、MQTT Broker、设备影子这些。

Q10: 请问 operator 为 k8s 带来的意义是什么呢？operator 的应用现状可以给简单介绍吗。

---

2019-12-18:：Open Policy Agent 在 Kubernetes 中的应用

提问链接

Q：规则是否会对性能有影响，是否有压测的数据

A：决策过程就是一次 RPC 调用，因为策略的定义是声明式的数据都是静态存储，决策耗时可以忽略不计（在整个请求阶段中），即使是内部代理也会带来网络上的损耗。

Q：规则是否可以动态修改，即使生效，不需要重启服务

A：不需要重启服务，实时生效，这也是 OPA 的目的，不会因为策略的变动而改动代码或是重启服务。

Q：是否可以与 istio 结合，实现微服务权限管理下沉到网格？

A：当然可以，社区有相关的实现，这个得去关注具体的项目，我还没有深入了解。

Q：是否可以与 spring cloud 结合使用，或是与 docker 配合使用，因为没有用到 k8s

A：当然可以，OPA 可以用做第三方库集成到你的代码中，通过 API 进行调用，一次决策就是一次 RPC 调用，OPA 的核心理念在于把决策这个步骤给解耦出来，而不是和上下文逻辑混在一起。

Q：OPA 可以调用数据库吗？它能实现鉴权吗？

A：可以，可以自己实现外部调用的模块，但通用的做法是事先把需要决策的数据查询组装好发送给 OPA 进行决策。鉴权就是一种特殊的策略，策略需要关联到用户、用户组。可以把 OPA 和网关进行整合，每次用户请求都进行鉴权（通过 OPA 进行决策，该次请求是否放行）。

Q：微服务和 OPA 是不是结合的更紧密？可以把决策提出来？

A：和微服务概念本身关系不大，即使是单体应用，只要你可以把决策过程剥离出来就可以用到 OPA，这个很符合微服务的理念，OPA 就是一个集中的决策服务。

---

2019-12-10：Volcano 介绍及其在深度学习场景下的应用

提问链接

Q1：针对 kubeflow 这种工作流有没有计划做出针对性优化？#274 号 PR 提出要做拓扑优化，最后也 close 了，这是为什么？

A：针对 volcano 与 kubeflow 的结合，volcano 社区一直在推动，希望 kubeflow 下各个 operator 对接 volcano，现在，这一推动在 kubeflow 中的一些计算框架已经取得了比较明显的进展。task-topology 的算法已在内网实现，推入 github 的计划正在制定中，如您有切实需求，可到 volcano 社区留言讨论

Q2：针对数据局部性有没有优化

A： data aware scheduling 已列入特性计划

Q3：资源敏感型的深度学习任务具体有什么挑战？

A：本次分享，针对解决为深度学习提供算力方面的挑战，其他方面的挑战，不能为您解答。关于算力方面的挑战和应对策略，请留意后续分享文档。

Q4：请问对一个分布式 tensorflow 训练，worker 节点的 gpu 型号不同，会不会有问题，比如 v100 和 p40 混用

A：v100 和 p40 均为扩展资源，在调度过程中均同等对待，是否指定多个 gpu 卡对调度进程无影响，欢迎您使用 volcano 进行相关测试。

Q5：在使用 k8s 中，对于 IB 网络和 RDMA 的支持会不会有什么问题

A：没有问题，支持过程中，k8s 需要做一些适配。据我所知，一些云厂商使用 k8s 对 IB 网络和 RDMA 的支持已经商用。

Q6：对于 tf 的分布式训练，worker 节点之间共享数据集，您推荐用哪种分布式存储

A：对象存储和 NFS 均可以，取决于您使用的底层存储的读取和写入速度。

Q7：虽然一开始批调度成功。但是如果一个训练作业时间比较长，运行过程中一个 pod 挂了怎么办，重新调度之后 ip 端口等相关的信息可能都变了？

A：volcano 支持为 job 配置生命周期管理策略，支持配置计算节点失败后，计算集群重启。如果计算模型不支持容错，可进行相关配置。

Q8：大佬，最后这个分享内容能同步到 github 嘛，讲的很详细，使用 kubeflow 开发中，对 volcano 很感兴趣

A：下周公众号会发，发出后再同步。

Q9：volcano 是并行调度多个 pod 吗？调度过程中会不会发生冲突。

A：是并行调度，不会冲突。batch 调度，主要针对于同一批计算任务下任务的批量调度。调度过程中，仍然存在多个维度的优先级。优先级内有先后。

Q10：现在 volcano 是先来先服务模型是吗？有没有考虑通过调整作业顺序提高集群资源利用率和作业完成时间。比如一个作业有资源请求量和运行时间两个维度的话，就可以贪心的使执行时间少的作业排在前面以减少总体执行时间。《Y. Fan, Z. Lan, P. Rich, W. Allcock, M. Papka, B. Austin, and D. Paul, “Scheduling Beyond CPUs for HPC”, Proc. of HPDC’19 , 2019.》这篇论文就是通过滑动窗口调整顺序优化了集群资源利用率。

A：volcano 调度过程遵循优先级调度，优先级高的 pod 具有更高的优先级获取集群资源。优先级有多个维度，namespace、queue、job 等。随着集群下资源状况和 pod 运行情况不同，各维度优先级均会动态调整。虽有多个优先级维度，但均没有涵盖您提到的这种场景，欢迎到 volcano 社区留言讨论

Q11：提交 VCJOB 时可否只指定任务 GPU 总数，由调度器自己根据集群 GPU 空闲情况决定分配几个 worker 以及每个 worker 的卡数呢？

A：不支持

Q12：请问 volcano 和原生的 kube-scheduler 有做到调度 cache 的共享吗？也就是同一个节点可以同时被这俩个调度器管理而不冲突？

A：不支持。使用两个调度器调度同一个 pod，不可避免会出现调度冲突。目前，volcano 只处理配置调度器名称为 volcano 的 pod 调度

---

2019-12-05：Knative Serverless 之道 - 如何 0 运维、低成本实现应用托管？

提问链接

Q1：开发怎么远程调试 k8s 中的应用

A1：Kubernetes 底层首先是一个容器，那咱们就从容器谈起。容器相对于宿主机来说其实只是把业务进程限制在一个更合理的权限范围内。在调试容器里面的业务进程时可以直接 docker exec 到容器内。到了容器内部就和一个 vm 没有什么差别了。而 Kubernetes 的 Deployment 可以认为是编排很多容器，每一个 容器都可以通过 宿主机 docker exec 进去。当然也可以通过 Kubernetes 的方式 kubectl exec 到容器内进行调试。如果实在初期调试阶段建议使用比较完整的 CentOS 或者 Ubuntu 镜像，基础镜像内要有一些基本的调试工具。摸索熟悉了之后可以使用精简的基础镜像，这样更经济。

Q2：knative 的 build 和开发流程管理可以代替 jenkins 吗

A2：Knative 的 Build 现在长大了，单独开启了一个项目就是 Tekton。Tekton 的定位不是替换 Jenkins ，这两者在使用方式上差别还是很大的。对于比较习惯 Jenkins 的用户来说切换成 Tekton 是需要一个适应过程的。那么为什么要搞一个 Tekton 呢，Jenkins 不是已经很好了吗？具体 Tekton 的详细设计和实现咱们以后可以单独说明，这里选几个重要的介绍一下区别：Tekton 的 Kubernetes 原生特性体现在如下几点：

• Tekton 的所有 Task 都是以 Pod 的粒度执行的，每一个 Task 可以包含很多个 Step。一个 Task 的所有 Step 在同一个 Pod 内串行执行。不同的 Task 通过 Tekton Controller 编排，是跨 Node 节点执行的；
• Tekton 的最基本的执行单元是 Pod，这和 Kubernetes 云原生操作系统是非常契合的。一个人如果掌握了 Kubernetes，再学习 Tekton 就是一件非常容易的事情。但是想一下如果掌握了 Kubernetes 会对学习 Jenkins 有所帮助吗？不太可能。随着 Kubernetes 的流行这种影响也会变的越来越明显；
• 再说一下被集成的特性，Tekton 如果现在和 Jenkins 拼生态现在资历还不够，但是他的设计和云原生生态位决定了他可以很容易的通过 Kubernetes api 被集成，而 Jenkins 的 API 需要单独学习，这些都是成本；
• Kubernetes 生态的很多已有的工具，比如 Chart 等等都可以和 Tekton 非常容易的契合在一起，Jenkins 的生态自己比较孤单。长远看 Tekton 是有优势的，但 Tekton 自己的领域能力也需要不断完善；

Q3：knative 编排和 K8S 应用编排的区别及应用场景?

A3：Kubernetes 的最大价值是把对 IaaS 资源的操作标准化了，比如无论是在 aws 还是在阿里云上面使用计算、存储、网络等资源都可以直接通过 Kubernetes 语义完成，不需要关心不同厂商底层差异化的实现。而 Knative 才是面向应用的编排。Knative 对应用的 Serverless 编排主要体现在对：流量的管理、灰度策略和弹性的管理。并且流量、灰度和弹性这三者是完美的契合在一起的。从另一个角度来说 Knative 是建立在 Kubernetes 之上的，Knative 需要使用 Kubernetes 提供的对 IaaS 的标准化服务。这二者是上下层的依赖和被依赖的关系，不是竞争关系。

Q4：knative 有哪些成功的行业应用实践？

A4：在阿里云上面已经有很多用户在使用了。另外 Google 的 CloudRun 产品完全是建立在 Knative 之上的。

Q5：knative 的现状和预期达到的目的?

A5：Knative 现在已经被众多厂商开始支持了，Knative 的目标是标准化应用 Serverless 编排模型。比如：通过 Knative 对应用进行编排；通过 Knative 支撑上层 faas 系统实现。这里说的应用其实不限于在线服务，很多 AI 任务也是通过 Knative 驱动的，比如分享中提到的 KFServing

Q6：缩容时，怎么才能当 pod 内的流量消耗完？在销毁？

A6：Kubernetes 中 Pod 是可以设置 Prestop 的，Prestop 可以保证先卸载流量，然后再摘除服务

Q7：k8s 应用服务器内网无网络，入口只有一台 nginx 在 dmz 区域可以出公网（nginx 与应用服务器网络只开放访问 31380/31390），当 pods 容器直接回调第三方域名时，该如何解决这个问题。

A7：这个涉及到了具体业务模型和系统架构，可以单独联系我下线沟通

Q8：感觉 knative 就是另一种形式的配置即服务，和 jenkins X 发展的异同?

A8：Knative 是一个应用 Serverless 编排引擎，可以快速给普通应用赋予 Serverless 能力。比如流量、灰度和弹性的完美结合。另外 Knative 的事件模型可以对接外部事件做基于事件驱动的 Serverless 模型。

Q9：在企业私有云环境部署 knative 会有哪些挑战？

A9：只要是标准的 Kubernetes 集群之上就能部署 Knative，不过很多镜像需要翻墙

Q10：阿里云上的容器镜像服务是如何处理鉴权的？

A10：可以参考阿里云镜像仓库的官方文档：cn-hangzhou/instances/authorize， cn-hangzhou/instances/credentials

Q11: istio 层面的管控和维护成本比较高，如 envoy 性能问题，网络问题等，这部分工作是由云平台负责的吗，knative 这边有没有相应措施

A11: 目前阿里云容器服务 Kubernetes 集群控制台可以通过 UI 管理 Istio 和 Knative，可以快速上手。控制台也提供了很多便捷操作降低运维成本。Knative 主要依赖了 Istio 的 Gateway，Gateway 本身是可以横向扩展的，不会有太大影响。

Q12：容器的冷启动问题如何解决，第一个流量岂不是延时很高?

A12: 如果缩容到零以后，到一个请求的延时是会很高。第一个请求冷启动的问题是一个公认的业界难题，这也是各大云厂商在竞相解决的问题。相比使用云的客户而言，云厂商自己其实更迫切解决这个问题，敬请关注….

Q13: knative 的组件本身怎么部署？如何保证 HA？谢谢

A13: Knative 是建立在 Kubernetes 之上的，Knative 组件其实就是 CRD 的 Controller。在 Kubernetes 中 Controller 是可以部署多个实例，通过抢锁保证只有一个 Controller 可以执行写操作。HA 的问题容易解决。

---

2019-12-03：Kubernetes 在信也科技的落地实战

提问链接

Q：dns 记录是如何维护的，还有 maclvlan 的记录的维护？谢谢老师回答

A：dns 系统我们实现了 2 个服务，一个是监听在 53 端口提供 dns 查询的服务，一个是前台管理站点，前台站点负责 dns 记录的增删改查。支持单独设置和批量导入功能。这 2 个服务共享同一个数据库。内容的话是由信也科技各个研发团队共同维护的。macvlan 是在每台宿主机上创建的。我们一般会在每台宿主机上创建多个 macvlan 网段。

Q：Macvlan 是没有 service，选择 MacVLan 是基于哪些考虑呢？MacVLan 使用过程中，对于不同的内核版本，不同的高可用组网，是存在兼容性问题的，这一块实践能分享下么？

A：选择 macvlan 一是因为它的简单，使用 docker 命令就可以创建出来，不需要其他配套的服务或数据库来管理。二是因为它有独立的 IP 和 MAC 地址，这样可以让信也科技之前跑在虚拟机上的服务能够快速的迁移到容器。我们对于宿主机的内核版本是严格控制的，不存在内核版本不同的情况。但是 macvlan 的缺点也比较明显，它依赖于硬件，宿主机需要连到交换机 trunk 口。并且它的灵活性也不够高，不适合大规模的组网。由于目前信也科技内部的网络结构还是比较简单的，并没有遇到兼容性的问题。

Q：为什么不试着对 k8s 自动更新呢，每一次手动更新都需要一定的时间成本吧？

A：目前我们认为手动更新比较稳妥，并且更新不是一个频繁的操作，时间成本还好。

Q：请问下，这个是自建机房环境上的集群？是否适用公有云环境？外部访问流量是如何接入的呢？ingress controller 基于什么考虑来选择的，谢谢。

A：这个是自建机房环境上的集群。外部的流量会先经过 F5，然后经过 nginx 集群，所有的容器实例和虚拟机都是通过 nginx 负载均衡的。在 nginx 上面我们使用了新浪微博的 nginx-upsync-module 模块，可以从 consul 同步 upstream 中的实例。我们并没有使用ingress controller，而是通过用户在我们的容器发布平台上去手动的拉入和拉出流量。用户拉入流量的操作会在 consul 里面添加实例的 IP 和端口，nginx 自动从 consul 同步实例后该实例就接入流量了。

Q：直接使用 Pod 的话，副本控制是如何做的

A：副本控制目前是比较静态的。用户在容器发布平台部署可以选择副本数。此后如果用户不添加和删除实例那么副本数是不会变的。

Q: 如何更新证书

A：先重新生成证书，然后先在 master 节点上更新，需要依次重启 etcd、apiserver、controller-manager 和 scheduler 服务。master 更新完毕后，再把所有的 node 节点上证书更新一下，需要重启 kubelet。证书的更新过程中除了造成集群的短暂不可用之外不会影响已经运行的容器的，所以是安全的。

Q：蓝绿发布和灰度发布是如何实现的？

A：这 2 个都是通过我们的容器发布平台实现。蓝绿发布是通过创建 2 个发布组，每个发布组含有相同的实例数。通常一个发布组含有当前版本的实例并且是接入流量的，另外一个发布组包含上一版本的实例或者是即将上线版本的实例。通过在 2 个发布组切换流量来上线新版本或回滚到旧版本。灰度发布可以先上线一个实例的流量，没问题之后可以把剩下的实例都接入流量。这些操作目前都是平台上用户手动操作实现的。

Q：集群平台的高可用是怎么做了？有没有做多集群多活或者灾备？

A：我们生产环境有部署多个 k8s 集群，也有 2 个不同的机房部署。我们的容器发布平台会把实例均衡分发到不同的 k8s 集群。

Q：开发测试环境的镜像仓库如何同步到生产镜像仓库？

A：镜像仓库我们测试和生产用的是同一套。 公司使用的是阿里云的托管版 k8s 与,发现托管版的 k8s 并没有多个主节点,问一下阿里的托管版 k8s 与标准版 k8s

Q：问一个细节问题，请问 k8s 集群扩容是通过什么手段实现的？

A：我们实现了一套 ansible 脚本去实现自动添加 node 节点。

Q：我们也是用的 macvlan，这个模式下，你们为什么没用 cni 配置网络，而是用的 docker 来配置，这样维护成本高一些。另外，macvlan 模式，主机无法访问本机内的容器，这个怎么解决的？

A：我们是用 docker 命令去创建 macvlan，实际还是使用 k8s 的 cni。使用 vlan 之后可以解决主机无法访问本机内的容器。

Q：ingress 用的什么，为什么选择它？

A：见 Q5 问题的回答

Q：刚才提到节点证书过期导致集群异常，k8s 本身会在节点异常以后，调度迁移非正常节点的实例的。我的问题是，如果证书更新需要一个过程，那么，节点恢复也是一个过程，这个时候，仍在异常的节点实例，会迁移到正常节点，而且，因为 coredns和ingress 对接的是 apiserver，那么，节点异常基本上等同于这个节点上的实例，都会被 apisercer 摘掉，虽然容器也还在，但是流量入口和 dns 侧实例不在了，这样一来，证书过期，不就等同于所有实例全部不可用嘛？

A：因为我们只用了 k8s 中的 pod，并且关闭了 k8s 中的异常节点自动迁移实例的功能。这些高可用功能我们自己实现了一个类似的，这样可以按我们的需要去定制。coredns 我们只是简单的用来作为 dns 服务器，并没有和 apiserver 对接，也没有使用ingress，见 Q5 的回答。

Q：想问下老师你们目前是前后端完全分离的么？目前的前端应用部署方式是怎样的？如何控制一些前端的发布工作流？以及与前端相关的后端微服务部分，是如何保证发布顺序以及关联性的。

A：目前我们上容器的还是以 java 为主的后端服务偏多。目前能了解到的是前端应用都是放到 nginx 中来对外提供服务的。对于前端发布的工作流以及如何保证发布顺序以及关联性的目前都是通过人肉去控制和完成的，没有做到自动化。

---

2019-11-26：基于 CDN 的边缘计算平台设计和思考

提问链接

Q：阿里的 edge 有用在阿里的 cdn 上吗

A：目前我们以及有对外的产品 ENS，形态上就是在 CDN 节点售卖虚拟机。另外我们在做的另一见事情，就是把 CDN 业务迁移到容器里面，这样到目的就是最大化释放 CDN 的资源和能力。

Q：能否介绍一下，目前 cdn 节点改造成边缘计算节点，主要涉及哪些方面改造，阿里的实践情况，谢谢。

A：目前 CDN 改造有 3 个部分：基础设施到改造（交换机、机型)，软件层面的改造（容器化)，CDN 节点架构的改造（比如把传统的 7 层负载均衡改成 K8S 的 Ingress Controller)

Q：目前在边缘的 ENS 节点，有提供 GPU，物理机等产品吗？

A：ENS 能力上是对齐阿里云 ECS 的，目前提供 CPU 和 GPU，神龙裸金属如果有需要也是可以支持的。

Q：CDN 场景的落地场景来说，形态上就是在云中心部署 Kuberentes Master，将云中心所在 Region 附近的 CDN 节点接入到 Kubrentes 中 ，指的是在各个 Region 里面的节点当作 k8 的 node 处理吗 ？

A：比如我们在阿里云中心的杭州 Region 创建一个 K8S Master，然后会把杭州整个省的 CDN 节点，全部接入到这个 K8S Master 里面，CDN 节点指的是一个机房，一个机房会有 1～100 台机器，整个 CDN 节点的机器都会接入。

Q：请问阿里边缘计算有和 5g 结合的计划吗?具体有哪些结合点?

A：在今年云栖大会上，我们以及发布了 5G 边缘计算战略，这个可以网上找下视频回放。具体的结合点目前来看是城市大脑和城市云。不过因为 5G 还未大规模商用，所以我们也在探索。link

Q：请问未来 docker 会向安全容器转型嘛？安全容器是趋势,作为开发者要注意哪些点？

A：其实 kata 和普通 runc 容器，在行为上没有太大差别，如果非要说关注点的话，目前我觉得是内核部分，因为 kata 容器对于内核要求是比较高的，稳定性方面还需要打磨。

Q：目前阿里有没有什么比较成熟的或者已经在计划中的边缘计算相关项目？公司内部对于边缘计算的支持程度是怎么样的?（落点很多，结合 5g 等新形式，相对感觉视频分析等传统 cv 方面可能应用性更强一点

A：ENS 就是我们成熟的对外产品，我们对于边缘计算的投入也是不惜代价的。具体场景我们现在也在跟我们的客户、运营商都有广泛合作。只要有需求或者合作意向都可以找我沟通。

Q：在云上部署 k8s master 节点，cdn 节点作为边缘节点。对 k8s 来说，节点之前的网络通讯要求会比较高，那当网络不稳定时，边缘节点和 master 节点断开，这时如何实现边缘节点上的服务自治呢？

A：这个就是 ACK@Edgemailto:ACK@Edge 解决的问题了，ACK@Edge 在边缘测机器上部署了一个 Edgehub 的组件，kubelet 并不是直接请求 kube-apiserver，而是通过 edgehub 然后再请求到 APIServer。edgehub 做了缓存和代理的能力，即使在断网的情况下，也能保障边缘节点的 kubelet 正常工作。这个能力叫做边缘自治，是 ACK 加强的能力。

Q：请谈谈阿里看到的边缘计算 cover 的真实价值场景或者客户群，感觉很多现有场景中心计算也能满足，不一定要用边缘计算。特别是边缘计算节点也卖虚机，价值不大。谢谢。

A：以 cdn 为例，cdn 就是通过边缘做加速来提高用户体验。虚拟只是一种形态，比如你购买虚拟机自建 cdn。所以边缘的场景肯定是跟中心不一样，比如城市大脑，就是需要在就近有个节点可以做接入，如果全部回中心，对中心的压力也很大。

Q：阿里在边缘存储上有什么计划吗，能介绍一下是否有业务会需要把大量数据存储在边缘？

A：ENS 节点的虚拟机提供云盘的，但是并不建议把大量存储放在 边缘。因为边缘的存储冗余并没有中心那么高，就像我说的，目前不建议在边缘部署对数据可靠性要求非常高的业务。

Q：请问安全容器的存储性能有考虑过么？接入点在边缘还是放云端？

A：安全容器最终是跑着边缘上的，安全容器的存储目前是一个大的问题，kata 开源的存储方案性能并不好。阿里云的内核团队做了大量的优化，目前应该有了比较大的性能改进。

Q：请问 ACK@Edgemailto:ACK@Edge 是开源的吗？

A：ACK@Edge 是阿里云上的产品，目前已经在公测中，可以直接在阿里云官网开通使用。

Q：容器安全方面有什么需要注意的？除了 kata 之外，使用 dockerd 与 k8s 有什么安全建议 psp 之类的？

A：安全容器的使用，第一 K8S 需要做适配 runtimeClass，第二内核也要求比较高（应该是要 4.*内核比较文档)
安全建议：就是加证书、改端口，不然容易被外部注入容器。其他的安全建议：就是直接使用云上产品，云上产品具备了比较高的安全能力。

Q：接 Q8 问题，如果云上 master 和边缘节点网络恢复了，但 master 节点上的 pod 的状态和边缘节点上的服务的状态不一致（断开时间长后，云上 pod 的状态通常是 terminating 状态，而边缘节点上的服务仍能正常工作)，这时候如何解决呢？网络恢复后，会将边缘节点的服务重启吗？比如 pod 重建？

A：网络恢复后，就是继续往 K8S 设置的终态变化了，比如中心把 Pod 删了，那么网络恢复后自然相应的 Pod 就会被删除。因为有 edghub 的存在，pod 是不会处于 terminating 状态的。不过具体细节可以仔细 ACK 的同学，场景和需求可能不大一样。

Q：CDN 的流量分配是在哪里做的？是 DNS 还是 GSLB 那种?异地灾备也可以用同样的方式?

A：CDN 的流量分配就有 DNS、HTTPDNS、302 调度，CDN 本身就是成熟的技术了，调度这块都是非常成熟的技术。

Q：想问 edge 节点的升级问题？比如有了重大 CVE 或者 0day？或者和 master 版本差太多？

A：升级的话，我们目标保持跟 ACK 中心同步的节奏。主要根据 ACK 提供的信息。

Q：请问您那块容器主要跑在虚拟机还是物理机上？

A：都有

---

2019-11-21：给 K8s API “做减法”：阿里云原生应用管理的挑战和实践

提问链接

Q： rudr 是有某公司实际线上使用后开源的，还是纯开源项目？

A1：rudr 是一个 reference 项目，意思是用来做 OAM 实现的一个参考，目前是纯开源项目，不排除以后会演进为生产可用的项目。

Q：oam spec 中目前还没有看到属于 infra operator 的管理对象（补充：Component 是面向 app developer， Traits 和 AppConfiguration 面向 app operator，哪个对象是面向 infra operator 的？)

A2：OAM 本身就是基础设施运维手里的武器，包括 Kubernetes、Terraform 等一系列平台层的开源项目，基础设施运维可以通过这些开源项目构建 OAM 的实现（如 rudr 基于 Kubernetes)。所以 OAM 的实现层就是基础设施运维提供的，他们不需要额外的对象来使用 OAM。

Q：oam controller 和 admission controller 的分工标准是什么

A3：OAM 项目中的 admission controller 用于转换和检验 spec，定位完全等价于 K8s 中 admission controller。目前实现的功能包括转换 [fromVariable(VAR)] 这种 spec 中的函数，检验 AppConfig、Component、Trait、Scope 等 CR 是否符合规范，是否合法等。
OAM Controller，即目前的开源项目 rudr，就是整个 OAM 的实现层，它负责解释 OAM 的 spec 并转换为真实运行的资源，这里的资源可以是 K8s 原有的一些，也可以是像阿里云上的 RDS 这类云资源。目前 rudr 项目是 Rust 语言写的，考虑到 K8s 生态大多数都是用 Go 语言写的，我们后续也会开源一个 go 语言编写的 OAM-Framework，用于快速实现像 rudr 这样的 OAM 实现层。

Q：计划啥时候开源 go 的 oam-framework 呀？

A4： 已经在走内部流程了。同时我们也需要进一步打磨 oam-framework，让它适配大家的场景。

Q：想问个问题，阿里是如何降低 k8s 的复杂度来满足运维和研发一些共性诉求的？在 k8s 中的用户 user 角色可能是开发也可能是运维。

A5：目前我们遇到的大多数场景都能区分哪些是运维要关心的，哪些是研发要关心的。OAM 降低 K8s 复杂度的主要方法就是关注点分离，给 K8s 的 API 做减法，尽量让某一方可以少关注一些内容。如果你有这样一个无法分割的场景，其实我们也很感兴趣，欢迎把 case 提出来一起探讨。另一方面，我们并不是屏蔽掉 K8s，OAM spec 预留了充足的扩展性，完全可以把 K8s 原有的能力提供给用户。

Q：我认为 OAM 是基于 k8s 针对于不同应用上的抽象层，现在我们有很多应用都是用 Helm 包包装好的，如果切换成 OAM 的话，我们需要注意哪些地方呢？

A6：其实我们上半年一直在推广 helm 在国内的使用，包括提供了阿里的 helm 镜像站等，所以 OAM 跟 helm 也是相辅相成的。简单的说，OAM 其实就是 helm 包里面 template 文件夹里面的内容。Helm 是 OAM 做参数渲染（template)和打包（chart)的工具。如果切换到 OAM，helm 的使用方式不需要变，里面的 spec 换成 OAM 的 spec 即可。

Q：请问，rudr 用起来了吗，效果如何。rudr 的架构有没更丰富的资料

A7: rudr 一直是可以用的，大家要是用不起来可以提 issue，想要什么方面的资料或者疑问也可以提 issue，我们也在完善文档。目前相关的材料都在这里：oam-dev/rudr/tree/master/docs

Q：rudr 的 hello world 没跑起来，是不是 k8s 版本需要 >1.14 ?

A8：具体这个问题就在 github 上提 issue 吧，我们每天都会关注 issue，可以贴一些错误日志之类的。

Q：我们一直在用 helm 打包我们的应用，去做 gitops ，一个通用的 chart 对应不同的 values.yaml 做到了复用。听了分享，很期待 OAM，当然还有 openkruise。

A9：openkruise 是开源的哈，大家可以关注 openkruise kruise 我们也一直在迭代。

Q：oam 有哪些公司在用？实际体验反馈如何？

A10：OAM 刚刚发布一个月左右，具体有哪些公司已经在使用我们还没有来得及统计。阿里和微软内部都已经在使用，并且都有对外的产品使用 OAM。就我们接触到的用户来说，无论是社区的用户还是阿里内部，都对 OAM 的关注点分离等理念非常认同，也都在积极落地。

Q： rust 内部有哪些场景和业务使用了？贵司后续会继续运用在哪些场景？

目前有一些小的场景在使用，具体还没有统计过，后续会继续用在一些需要较高性能的场景。

---

2019-11-19：基于云原生日志分类处理方案与落地实践

提问链接

Q：filebeat 与 flunted 的区别大不？该如何选择

A：Fluentd 针对结构化的数据，灵活性是一个考量。

Q：filebeat 单纯采集 docker 日志发现不能获取 docker.container.name，docker.container.image 信息不知为何？

A：filebeat 支持多种采集方式，可以将 filebeat 以进程运行在 docker 容器中，收集容器日志，也可以单独部署 filebeat 采集 docker 生成的日志文件，可以参考 filebeat 官方 yaml 配置文件。

Q：能否对采集到的日志信息做到告警处理？

A：告警需要分场景，入库 ES 可以通过 sentinl 插件接入告警。 规范处理方式应将各类落地日志对接中心告警平台。

Q: es 的机器学习功能是否有实际价值？

A：在机器学习方面没有太多接触。

Q：采集 agent 是 sidecar 还是 daemon 模式？

A：守护进程与二进制部署。分场景部署，大部分采集场景使用 daemonset，部分集群外中间件等组件以 systemd 部署。

Q：有没有 EFKoperator 相关项目推荐？

A：暂时没有相关推荐。

Q：对于日志采集系统占用资源过多，怎么解决？

A：需要从各方面优化，技术层面也是优化项，如提取偏移量方式对流量有很大影响，如文件扫描频率，对 cpu 有很大影响。 优化点首先从原生参数根据业务场景进行适配调整，特殊场景考虑原生扩展。

Q：能用 filebeat 采集 journald 日志吗？怎么将系统日志和 pod 日志用同一个 filebeat 采集？

A：有 journalbeat 开源插件可以采集 journald 日志。系统日志和 pod 日志都落地文件，以多源目录采集，一般采用对接 logstash 做区分处理，若转发不采用 logstash，需要扩展 filebeat 组件支持多目录指定不同的输出采集。

Q：有没有调研过阿里开源的 log-pilot 来采集 pod 日志？

A：没有做过相关调研。

Q：beats 组件之间是否会有互相影响？比如 filebeat MySQL 的采集器 redis 的采集器 docker 的各种，部署很多是否会相互之间有影响

A：你指的是 filebeat 内置 module 模块和对外部采集方式如何统一一套部署采集而不相互有影响么？ 如果是这样，通过 filebeat 配置文件指定 module 采集以及 docker 产生的文件配置进行采集。

Q：日志告警是用的开源项目还是自研的呢？

A：根据自身的平台确定方案，本案例的场景可以通过开源方案做一些简单告警，如 ES 通过 sentinl 做告警，Loki 通过 grafana 告警，若自有大数据平台或者单独的告警平台，按照平台规则对接告警。

Q：日志系统接入消息队列的意义是什么？

A：消息队列是缓冲，重要日志接入消息队列可以提供缓冲存储，多次消费。

Q：都是默认 json 日志么，有没比较其他 log driver 使用场景

A：

Q：用 loki 主要目的是什么？是某些场景下 es 的替代品吗？二次开发考虑开源吗？promtail 的性能瓶颈具体表现在哪里？和 filebeat 相比有什么优缺点？

A：

Q: 我看 loki 现在还是在 beta 阶段，为什么考虑用？

---

2019-11-12：扇贝 Service Mesh 发展历程

提问链接

Q：istio 相关的 ymal 配置文件，比如流量百分比，在哪里配置，直接操作文件吗？

A：你是指单纯使用 Envoy 的时候如何如何实现 Istio 里流量百分比的功能吗？这个可以通过给 endpoints 配置不同的权重来做到

Q：这个现在是在哪里操作的是运维手工修改 ymal 文件？

A：不是的，举个例子，你可以在 xds 服务端实现根据不同 deployment pod 数量来下发新的配置

Q：service mesh 有对 mq 相关研究吗

A：我们的 mq 没有部署在集群里，Envoy 对这块协议也没有相应的支持
A： istio 应该暂时还不支持 kafka 和 amqp，gRPC/websocket 等可以实现异步调用。

Q：为啥自己实现 xds 服务器？有现成的为啥不用？例如 istio-pilot/rotor? istio-pilot 可以单独使用的。

A：其实是早期遗留问题，一开始我们用的 Istio 不稳定，后续的选择就趋于保守了。当时 rotor 应该还没有 release 版本

A：好吧，Rotor 一年前也没有更新了，他们团队好像被 twitter 招安了

Q：你们只用 envoy 做 front-proxy 吗？如果是这样，这就不叫 service mesh 了

A：分享里说了哈，既有 front-proxy，也有服务间的

Q：如何保证 envoy 对业务性能影响最小？

A：envoy 本身性能没什么问题，要注意的是配置的 filter 这些跟外部服务交互的地方，比如 ratelimit 之类的，要配置好超时时间以及失败后的策略

Q：被 sidecar inject 过的 prometheus 如何去 scrap 每个 pod 的 metrics?服务是基于 springboot 的。这个研究过吗？

A：抱歉，这个没有研究过。你是要抓取 sidecar 的数据？
A： 谢谢，没关系。我目前只能让 prometheus 直接去抓 pod 的 metrics。sidecar 的数据不用抓:)

Q：把 istio mixer 里的 jaeger 暴露出来，给 k8s 外部的服务使用，这个需要考虑些什么？

A：我们单纯的使用的 Envoy 哈

Q：istio 的配套监控体系如何，是直接用开源搭建还是自建？

A：我们的监控是 Prometheus 那一套技术栈

Q：你们的服务是基于 gRPC 还是 REST/http1.1 的？gRPC 要求至少 http2，如果需要把 gRPC 服务暴露给外部，对于ingress controller 你有什么推荐？你们服务部署的是阿里云吗？Edge Proxy 用的阿里的服务?

A：我们对外的 rest，内部服务是 gRPC。Envoy 也是有做ingress controller 的产品的，比如 Contour，不过我们没有实践过，谈不上推荐。是的，阿里云。最外面有一层阿里云的 slb
A： cool

Q： 你们目前网关怎么做健康检查的？lstio，第二个问题，sidecar 如何实现链路监控，自己日志文件怎么处理的？麻烦分享一下你们的监控指标和维度针对 service me sh

A：既可以让 Envoy 对 cluster 做主动健康检查，也可以在 xDS 服务端那边主动更新 envoy 的 endpoints，比如依赖 pod 配置的探活指针。我们日志都是到 pod 的标准输出，然后 ELK 那一套做收集处理
A：日志是怎么收集的呢？链路监控目前怎么用的呢？那个技术栈

Q：nginx+consul+consul-template 这个用 nginx 做 edge proxy?nginx 这一层如何做 cluster?

A：nginx 我们是部署多台，前面还有一层阿里云的 slb 对 nginx 做主动健康检查

Q：daemonset 模式下，如果一个服务挂掉了例如 timeout，如果实现 circuit-breaker? 服务挂了。

A：服务熔断我们最近刚开始调研，现在给不出实践经验
A：哦，那只好还是编码在代码里面

Q：网关怎么处理健康检查的，pod 日志怎么处理，统一收集吗？链路监控又是如何接入的？

不好意思，问题重复了

Q：istio 不好用，为什么不考虑 sofa mesh 来代替？

A：早期 0 点几版本的时候不稳定哈。现在不是特别在意大集群性能问题的话，istio 是可用的
A：实测过一下，istio sidecar injection 大概平均一次增加 1ms 的 latency，感觉不是很厉害。一般远程调用都是十毫秒以上的返回。

Q：请问如何实现的灰度发布和蓝绿部署

A：灰度发布也是基于配置不同 endpoints 权重这个思路来的，也可以部署不同的 deployment，基于 pod 比例来做。蓝绿部署实践不多哈

Q：你们服务 tracing 和流量监控是怎么做的呢？

A：traceing 目前还是原始的日志方式，在研究替代方案，后续有进展可以再分享一下。流量监控我们有做 pod 的进出流量统计，也有从 Envoy metrics 获取的请求统计

---

2019-11-10：蔚来汽车的 Kubernetes 实践

提问链接

Q：请问 Kubernetes 数据备份与恢复，这个是包括 kubectl-proxy，etcd，网络配置等吗？如果进行多集群下的数据备份？

A：备份的其实就是 etcd 中的数据，我们网络是用的 flannel，一些关键网段信息也是存在 etcd 中的，对于多集群来看的话，还是要针对数据存放对应的 etcd 集群数据去进行备份

Q：请问一下业务日志太多，一天一个节点的业务日志有 200G，怎么做日志收集及监控告警。

A：一天一个节点 200G 的话，这个要看你们集群节点多不多，我们上百个节点，一个节点的量大概在 100G 左右，线上日志量都是几十 T 的数据，用我分享的方案去落地应该是没问题的，ELK 的整体性能还是非常不错的，filebeat 现在最高的性能分配是占用 500m cpu 1G 内存，收集起来也是能应对的，这个根据你的量再调整，监控的话肯定就用 prometheus 就好，官方都是有自动发现的配置，很便利，当然如果你要对日志进行分析，这块就比较复杂了，可以通过 es 接口去聚合数据，当然日志的字段也要规范好。

Q：生产环境 k8s 采用二进制方式搭建还是 kubeadm ，还是其他方案？

A：线上采用的是二进制的方法，因为我们上 k8s 的时候 kubeadm 还是测试版本，当然现在高版本的 kubeadm 应该已经是正式版本，但是觉得还是二进制更方便一些，你改配置，以及自定义一些参数会方便一些。

Q：生产环境 k8s 都用哪种网络模式

A：我们用的是 flannel，不过后续会考虑打算换成 calico，现在发现线上有一定网络限制的需求，calico 的性能相对也会更好，但是维护的复杂度比较高，在集群节点多的情况下，要添加路由反射器，这个比较关键，而且网络选型前一定对未来的规模有个规划，规划好使用的网段。

Q：请问生产环境中 etcd 的数据需要备份吗？怎么备份？还有二进制安装 etcd 集群由 3 个节点增加到 5 个节点，需要重新生 e 成证书后再重启 etcd 服务吗？增加节点重启策略是一个一个节点依次重启吗

A：建议备份，其实主要用到的就是 etcd 的 snapshot 功能，不复杂，看下我分享的脚本即可，扩容的话需要修改 server 端证书对应的 host，逐台重启没有问题的，官方的方法也是要一台一台执行的，线上 etcd 节点我做过测试，即使操作失误都 down 掉的话也不会影响你现有服务的运行，而且保证法定节点的存在就更好。

Q：你分享的 prometheus 是 operator 方式吗？你的监控数据是有经过二次开发后作为标准格式输出吗？对于 nginx 和 java 监控如何实现呀？

A：prometheus 没有用 operator 的方式，是用的官方的 yaml 文件创建的，我们线上 java 服务居多，都是通过 spring 官方的 prometheus 插件就可以自定义监控数据，nginx 的话我们还真的不多，这个估计你要用相应的 exporter 就好，监控数据是开发自定义上传的，我们没有做限制。

Q：pod 挂掉之后如何保留现场，比如做内存 dump 有什么好的方案没？

A：我们这边是这样，对于健康检查没有添加 liveness 的检查，也是防止容器的重启，尤其是在第一次项目上线，难免无法正常启动，如果加了 liveness 就会一直，重启，不太方便查问题，所以只加了 readiness,只是保证不影响线上访问，对于生产中，java 项目遇到最多的就是 OOM 问题，这个我们也对 POD 重启的原因加了报警，至于 dump 我们还没这方面的操作，需要开发自行检查了。

Q：传统系统架构如何改造成 k8s 架构？

A：这个问题有点宽泛呢，还是得看您这边实际的场景，我觉得更多的也是得需要开发一起的配合，尽量保证服务模块都能够做到微服务话，不要耦合的太紧，您可以先搭建一个测试集群，然后从开发那边找一个模块进行 docker 化的转换，然后一点一点再去试吧。

Q：是否有ingress tcp/udp 应用的生产级网络方案？

A：我们没有用ingress，我们的用法也算是一种比较简单的用法，我们是把网关直接加入到 k8s 集群中，这样网关就可以调用到 k8s 的 service，因为我们以网关为中心，做了一些安全及认证功能，所以之前的网关必须要用到，而且加了ingress 相当于多加了一层性能消耗，所以也没有用，最后我们把之前部署在虚拟机上的网关也变成 docker 化去部署到集群内部。

Q：传统数据库负载过高时查询缓慢，但是会有结果，k8s 架构数据库负载过高直接 pod 重启，导致没有结果返回，请问应该如何处理的。

A：我们集群还没有跑数据库这种有状态的服务，但是听您描述，还是得看看 pod 重启的具体原因，如果 pod 都重启了，理论上跑在机器上一定也会有问题，还是在上云之前做好充分的性能压测，并且您可以考虑取消 liveness 的健康检查，只保留 readness 访问的检查。

Q：采集日志过程中，fluentd 或 fluent bit 通过读取 node 节点 docker log 目录采集日志，该目录包含了所有服务的日志。请问如何在 output 阶段中根据 namespace 和 container_name 创建 elasticsearch 的 index，并作为 index 的命名前缀？

A：首先不建议通过 docker 目录的方式采集，日志还是落盘到具体路径为好，因为我也碰到过您这个困惑，因为 docker 的目录都是软链接，而且当 docker 重启后路径会改变，当然我们线上用的是 filebeat 采集，不知道 fluentd 能不能解决这个问题，由于是软链接，很难用相对路径，必须用绝对路径采集到真正存放的那个目录日志，我们对于 es index 名称的创建是通过日志提供的一个 index 名称字段去匹配的，索引名称会引用这个变量进行区分不同的 index。

Q：fileneat node 模式采集，多个相同 pod 在同一节点情况下，如何映射日志目录耳不互相干扰，另外如何配置 filebeat 做到 pod 变动时的采集

A：您这个情况我们也遇到过，多个 pod 跑在同一个节点确实存在这个问题，因为你的 deploy yaml 是定死的，很难处理这种情况，我们的解决方法是添加 pod 的亲和性，保证每个节点都尽量只跑一个 pod，当然如果节点非常小的情况下，这种做法有一定问题，以生产使用上来看，我们最初多个 pod 跑在一个节点同时写一个文件的话也是还可接受。

Q：持续集成系统具体的细节可以透露下吗？基于 gitlab ci，jekins？或者小公司可以直接用 Spinnaker 这些吗？

A：ci cd 的话因为我们有自己现有的发布平台，背后的原理实际上还是调用 jenkins 去处理

Q：日志收集的 sidectar 模式具体是咋部署的。filebeat 和应用部署在一个 pod 里吗

A：对的，部署在一个 pod 里，相当于你的 deploy yaml 里会有两个 image 配置，一个是你的服务，另一个是 filebeat，具体的配置看下我的截图，把这部分配置放到你的服务配置后面即可，但是就像我分享说的，这种方式可能会比较消耗资源，但是确实自定义比较方便，但也增加了 yaml 配置

Q：我司测试环境搭建的 Harbor 版本是 1.5，使用 docker-compose 来按照 Harbor 各个组件的依赖顺序来启动的，但是当系统或者 docker 重启后，Harbor 的容器就无法按照依赖顺序来启动，经常会有容器启动失败。请问下这个该如何优化呢？

A：其实你需要在 docker 中注意一个参数，live-restore : true，这个参数很有用，你可能没有添加，这个参数能保证在你维护重启 docker 的时候，还能保证不影响正在运行的 docker 容器，另外你可以对 harbor 进行监控，如果 down 了的话大不了做个自动重启的操作也不妨大碍。

Q：（1)k8s 平台上线前有什么测试？如何测试？可以上线的依据？（2)常见互联网架构的业务，需要改造才可以在 k8s 跑吗？需要如何改造？有什么坑？（3)你们多个业务线都共用同一套 k8s？如何实现不会因为一个业务的高峰影响其他业务？（4)有什么方案可以实现最大限度的不丢日志？

A：1.因为我不是测试，对于测试这块可能干涉的不是很多，对于运维来讲可能更多的是比较关注上线之前的压力测试，这块会跟后续的稳定性有很大关系 2. 常见的架构业务理论上改造应该不需要很大，最主要的是解决 docker 镜像化，遇到的坑可能更多的是对于 dockerfile 打镜像理解的不好，导致一些启动问题以及配置的丢失等等，3. 我们是通过 namespace 区分业务线，需要提前规划好业务，指定的业务线只跑在对应的机器上比较关键。 4. 我使用的 ELK 过程中还真的很少遇到过丢日志，只要你架构足够健壮应该是没什么问题的，另外 ELK 中一定要用消息队列，降低你消息传递的压力，保证每个组件都不要出现性能瓶颈，如果实在怕丢日志，可以让 logstash 在消费的时候把消息落盘，es 也要合理配置好刷新的频率以及内存多大落盘等参数，提前做好各个组件的压测是保障。

Q： 你好，我是蔚来 es8 车主，很高兴看到蔚来的分享。我想了解下你们存储的方案，之前听说是用的 portworx，具体方案透露一下。你们这个 team 在北京还是上海？ 用 aws 的话有没有考虑直接使用 aws 的 k8s 服务？es 也运行在 k8s 里吗？

A： 您好，我们 team 在北京，因为我们的集群还未上有状态服务，所以暂时还未考虑分布式存储的问题，这块确实是很重要的一个环节，我们线上的服务基本也是通过 S3 去存储一些数据使用，portworx 这个好像也出了很久了，当时在还没有 k8s 的时候调研过，不过想大面积使用貌似是要花钱用商业版，建议还是用现在比较流行的 ceph 可能会更好一些吧，我们还未用到 aws 自己的 k8s 服务，es 有运行在 k8s 里的业务，但是不是通过 operator 部署，后端数据也没用到分布式存储，由于量不大，只是落在本地了，后期会进一步调研 ceph 以支持后期的有状态服务的迁移。

Q： 请问是否考虑过 fluent-bit ，目前 filebeat 有没有性能上的问题呢？

A： 因为在虚拟机的时候我们就用的 filebeat，就沿用下去了，filebeat 暂时还未发现性能问题，可以直接使用，总日志量我们应该有几十 T 的样子，在生产使用的过程中感觉 filebeat 还是比较靠谱的。

Q：k8s 一年的证书问题，你们怎么解决的呢？

A： k8s 的证书我们的时间都设置的是十年，kubelet 可能是一年，这个我们最初疏忽了，碰到过一次，最终通过删除现有的配置，让 kubelet 重启自动生成，当然如果您是最初规划的话，可以加上证书自动到期认证的功能，据了解好像现在高版本的 k8s 已经不存在这个问题，我还没了解的那么多，您可以再查查

Q：k8s 生产环境上的安全相关的配置有哪些呢？

A： 安全的话这个比较宽泛啊，这个还是要从各个方面完善，首先起码要保证流量流入方向的各个环节的安全限制，以及服务接口调用上的安全认证，以及开发人员使用时候的权限控制等等。

Q：prometheus 自定义监控具体怎么搞得，比如想要监控容器的端口连接数?

A：容器端口的连接数监控确实还未添加，在原来宿主机的时候是有的，这块有些忽略了，加的话也不是很费劲，可以通过你们自己自定义的 exporter 去监控。

Q：落盘的日志怎么定期清理

A： 落盘的日志通过写好的清理任务进行清理，因为我们的日志都是规范的落到统一的目录，并且目录名称也是很规范的，所以清理起来很方便，写个简单的脚本就可以啦，定时清理就 OK

Q：k8s 里 java 服务，你们是怎么做资源限制的？

A： 我们是在 yaml 注入了能获取设置资源的 env 参数，然后在 ci 打镜像的时候统一规范了服务启动的 start 脚本，jvm 里配置的是 k8s 配置的资源，所以 java 服务的使用也不会超过我们分配资源的使用。

Q：想了解下你们日志收集 你们的服务数也就是日志数大概多少？每个 k8s 节点分配到的 pod 大概多少 因为是 daemonset 部署想了解一下 filebeat 的配置文件是怎么管理的？ 后端日志分析完全靠 es 么？日志有没有入 hadoop 的需求？有 MR 或 spark

A： 我们一天的日志量最多能达到近 10T 的数据，当然这不全是 k8s 这边的日志，1 个节点最多的话大概能跑到 30 多个 pod，filebeat 我们是走的统一的一份配置，因为日志都是 json 规范好字段传输，也无需做过多处理，因为日志分析主要不在这个场景做，我们这个场景只是提供开发看日志，当然其中一些网关数据我们会做报警和具体的图示，需要分析的大数据专门走我们的 hadoop 集群，我们这边有用到 MR 和 spark，但是大数据相关的东西都没有在 K8S 上面。

---

2019-10-10：超大规模商用 K8s 场景下，阿里巴巴如何动态解决容器资源的按需分配问题？

提问链接

Q：请问 heapster 中采集到的 MetricMemoryWorkingSet 指标与 ps 命令获取到的 RSS 有何区别？heapster 的源码中对该指标的描述是“Total working set usage. Working set is the memory being used and not easily dropped by the kernel”，同时 heapster 也采集了 MetricMemoryRSS，kubectl top 为何采用 MetricMemoryWorkingSet 而不采用 MetricMemoryRSS？在 Kubernets 1.10 版本下，部分运行 Java 应用的 pod 出现 kubectl top 值超过 ps RSS 值的情况。

A1：阿里巴巴内部并不使用 heapster，我们是通过直接去读取容器 cgroup 值，获取容器实时资源使用情况。据我所知，社区对于 heapster 完全废弃。建议通过主流工具采集，汇聚，聚合数据。试试 custom-metrics-apiserver 和 kube-state-metrics 。在大规模场景下社区的很多开源工具都存在性能问题，一般这类工具我们倾向于自研。

Q：如何看待 suse 放弃 openstack?

A2：Openstack 是款伟大的软件，它给 IaaS 的研发和周边生态带了很多意想不到的成果，例如 ceph 等。SUSE 放弃 OpenStack 可能出于多种原因。或许是技术选型，或许是财政收益等等。顺便说说，SUSE 目前在 Kubernetes 相关领域的投入还是挺多的。最近的 Kubecon 上，SUSE 均展示了相关技术成果。

Q：直接修改 cgroup 容器一定会获得资源吗？

A3：容器技术隔离的技术基础就是 cgroup 层面。在宿主机腾出足够资源的情况下，给 cgroup 设置更大的值可以获取更多的资源。同理，对于一般优先级不高的应用，设置较低的 cgroup 资源值就会达到抑制容器运行的效果。

Q：底层是如何区分在线和离线优先级的？

A4：底层是无法自动获取谁是在线，谁是离线，或者谁的优先级高，谁的优先级低的。这个我们可以通过各种 Kubernetes 提供的扩展实现。最简单的是通过 label，Annotation 标识。当然通过扩展 QoS class 也是一种思路。社区版本的 QoS class 设置太过于保守，给予用户发挥的空间不大。我们通过这些方面也进行了增强。在合适的时候或许会推向社区。自来来来动感知是个方向，感知谁是干扰源，感知谁是某种资源型应用，这块我们还在研发中。做到真正的动态，肯定是具备自动感知的智能系统。

Q： “与社区版 Vertical-Pod-Autoscaler 不同，Policy engine 不主动驱逐腾挪容器，而是直接修改容器的 cgroup 文件；“，想问一下，不主动驱逐的话，如果 Node 的资源达到上线了会怎么处理？

A5：这是一个好问题。首先这里要先区分是哪种资源，如果是 CPU 型的，我们可以调整低优先级容器的 cgroup 下 cpu quota 的值，首先抑制低优先级的容器对于 CPU 的争抢。然后再适当上调高优先级容器的相关资源值。如果是内存型资源，这个不能直接去缩小低优先级容器的 cgroup 值，否则会造成 OOM，对于学习学习内存型资源的调整，我们会在其他分享中继续讨论。这个技术比较特殊。

Q： 只修改 cgroup，怎么保证 k8s 对单个物理机能够分配更多的容器

A6：文字直播有了一定说明，容器的资源消耗并非是一成不变的，很多时候它们的资源消耗呈现潮汐现象，相同的资源条件下部署更多应用，完成更多作业就是达到资源利用的最大化的效果。资源出现超卖才是我们这个主题讨论的最大价值。

Q：也就是说 低优先级的容器，request 设置的比 limit 小很多，然后你们再动态的调整 cgroup？

A7：在现有 QoS 场景下，你可以理解被调整的 Pod 都是 burstable 的。但是我们并不是直接调整 Pod 元数据的 limit 的值，而是调整 limit 在 cgroup 反映的值，这个值在资源竞争缓和的时候还会被调整回去的。我们并不建议单机的 cgroup 数据和 etcd 的中心数据割裂太久。如果长期偏离，我们会像 VPA 发出警报，联动 VPA 做调整。当然在容器运行的高峰期，任何重建容器的操作都是不明智的。

Q：你们现在 cpu 超卖的比例是多少？

A8：这个不方便回答，哈哈。等我确认可以回答的时候再修改这里。

Q：谢谢了，整体的理解就是你们开始就让物理机超配了一定比例的 pod，然后通过策略动态调整容器的 cgroup 值

A9：如果资源完全是富足冗余的，这个动态调整也有一定意义。就是并非资源用满场景下，高优先级应用会被干扰，实际上，当主机的 CPU 达到一定比例，打个比方例如 50%，应用的时延就变大。为了完全确保高优先级应用的 SLO，牺牲低优先级的 CPU 正常运行也是有价值的。

Q：如何确保一定是低优先级的容器和高优先级的服务部署在一起的，而不都是高优先级或者不都是低优先级，只用 packing 算法就可以？

A10：这个方法比较多，可以配置亲和性和非亲和性。可以通过预编排等手段。预编排就是在应用部署前，首先规划好各个应用部署在哪些 node 上。

Q：Policy engine 有没有考虑开源？

A12：有计划进行开源，Policy engine 更多的是和自身的应用属性相关，电商应用或者大数据处理应用的策略都是不相同的，我们开源会首先开源框架和附带一些简单的策略，更多的策略可以用户自定义。

Q：只是调整 Cgroup 的配置，对于应用中的配置如何改变？比如 JVM 根据中的一些参数？如果不重启 jvm 如何让 Cgroup 的限制生效？

A8: Java 进程还是比较特殊的。很多时候容器重启才能适配的参数才能生效。我们这里针对的是一种通用的方式。对于你提到的这类应用，压制低优先级的容器有效，但是给高优先级应用再分配资源应该无效。

Q：我之前遇到的大部分应用都无法正确感知 cgroup 的配置，因此很多情况都需要在启动参数里面根据 cpu 或者 mem 设置参数，那么也就是说即使改变了 cgroup 对于他们来说都无效，那么使用场景也就有限了

A14：限制容器的资源使用这个还是有价值的。限制低优先级应用本身也可以提升高优先级应用的 SLO，虽然效果没有那么明显。稳定性的考量同样也很重要。

Q：Policy engine 目前在阿里的使用如何？在生产上有多上的规模使用这种方式进行动态调整？是否和社区的 HPA VPA 配合使用？

A15: Policy engine 在阿里某些集群已经使用。至于规模暂时无法透漏。涉及到很多组件之间的联动，社区的 HPA 和 VPA 目前都不太能满足我们的需求。因此阿里的 HPA 和 VPA 都是我们自行开发的，但是和社区的原理是一致的。阿里 HPA 的开源可以关注 openkruise 社区。VPA 开源计划我这里还没有确切消息。

Q：data aggregator 通过什么方式采集数据?

A16：类似 cadvisor 方式直接从 node 的 cgroup 获取实时资源消耗数据。然后根据容器，node 为单位再进行聚合。

Q：当单机节点资源不足以提供容器扩容时，目前是否可以进行 HPA 或 VPA 扩容呢

A17：单机节点不足的时候，应用可以通过 HPA 进行增加副本应对。但是 VPA 如果选择原节点进行更新的话，是失败的。只能调度到其他资源丰富的节点。在流量陡升的场景下，重建容器未 h h 必能满足需求，很可能导致雪崩，即重建过程中，整个应用其他未升级的副本接受更多流量，OOM 掉，新启动的容器再瞬间被 OOM，所以重启容器需要慎重。快速扩容（HPA)或者快速提升高优先级资源，抑制低优先级容器资源的方式效果更明显。

---

2019-11-07：如何实现 K8s 一键部署？开发部署提速 8 倍？带你上手一款下载超 10 万次的 IDEA 插件

提问链接

Q： k8s 各组件，比如 etcd，建议部署在容器内还是物理机？有什么区别或者优劣吗？

A1：etcd 可以部署在容器里，物理机的话就是性能更好一点。

Q：如果登录是堡垒机，并且是动态密码，那个配置保存必须要密码，所以不方便吧！能动态密码登陆局域网服务器吗？

A2：这是个非常好的建议，我们需要在后续的版本中开发这些能力。

Q：如何在本地电脑(如 mac)部署 k8s 玩玩，以及写 Go 代码增删改查 k8s 资源，这块有啥玩一玩的优良经验嘛？目的是想本地开发测试 k8s，更加去熟悉 k8s 内部机制。

A3：本地 mac 要玩 k8s 可以去搜一下 minikube。

Q：k8s 一键部署是用 kubeadm 部署么，本地虚拟机部署多节点 k8s 集群，虚拟机网络应该怎么处理。由于是自己部署着玩玩，在公司里虚拟机网络不能使用桥接的方式。而使用网络地址转换 NET+hostonly 在起 calico 网络的时候 worker 节点 calico 起不来，提示网络冲突。谢谢

A4：nat 模式两个机器会用同一个 IP，所以会冲突，可以给虚拟机配两个网卡，1 个网卡用 NET+hostonly 用来访问外部网络，1 个网卡用 private network 用来节点间 Pod 的网络

Q：对于后端开发者来说(写 Go)，有必要去更加熟悉 k8s 么？毕竟 k8s 就是个运维工具，为了更爽的去部署软件以及扩容等等，有必要去深入了解 k8s 内部机制么，这块有没有什么建议和见解？

A5：首先，Kubernetes 本身是用 Go 语言写的，就是一个最好的 Go 语言开发和架构的最佳学习物。

Q：k8s 网络组件 calico 和自带的 flannel，请问建议采用哪一个？

A6：简单上手选 flannel，看重功能选 calico

Q：有哪些开源的管理 k8s Web UI 软件，这样可以部署在公司内，所有团队直接在该软件内傻瓜式操作 k8s 资源，自己部署上线代码？

A8：K8s 自带的 dashboard 可以试试

Q：我想深入学 k8s，但是 k8s 内部使用了 etcd/coredns，以及监控这块使用 prometheus，这些技术是不是先深入学习下，再去深入学习 k8s 呢，毕竟 k8s 太大了，一上来就深入会容易找不到门路，这块大大有啥经验没？

A9：建议从 K8s 核心开始学习，再学习周边组件。从中心到外围的顺序。推荐学习下 CNCF 和阿里云联合做的这个免费公开课：roadmap/cloudnative

Q：若 k8s 集群服务器宕机，请问如何快速恢复集群能力（除拉起 kubelet 等待其他组件自动拉起，是否还有其他方式)？

A10：配置 3master 高可用可降低宕机带来的损失，另外备份组件的配置文件。

Q：Master 节点如果同时作为 node 节点，请问存在哪些风险？

A11：master 节点不宜作为 node 节点部署应用，会导致集群不稳定。

Q： 您好！现在使用了 jenkins pipeline 做为 ci 工具，cd1: helm chart 对每个应用编写对应的 chart，通过 questions.yaml 在 rancher 定制化接口. cd2: 通过 argocd 和 helm chart 形成的 git ops ,请问有没有更好的工具推荐？ 想解决批量升级，现在每次升级都需要人工干预.

A12:

---

2019-11-07：k3s 在边缘计算中的应用实践

提问链接

Q：一台阿里云杭州服务器，一台阿里云美国服务器，都有公网 IP，如何方便，快捷的（并且不购买网络带宽费用)的搭建一个 2 台服务器的 K3S 集群？

A：你这个问题的话主要就是你的这个路由的问题，pod 网络和 service 网络的一个拉平的问题，涉及到这个路由的跳转需要你自己去去配置的。

Q：边缘节点的 K3S 集群可以很方便的被中心节点的 K8S 集群来管理吗？如何 管理？数据如何同步？中心节点需要存放边缘节点的数据吗？边缘节点挂了之后中心节点能拉起或管理吗？现在我们也计划做这放面的工作。我们有多个分公司？想在分公司部署集群，但没有维护人员，还有一个问题就是，现在集群 联邦不成熟，也不能很好纳管多个集群做资源调度？

A：这个 k3s 集群和 k8s 集群，它是一个平级的关系。他属于多个集群如果要管理多个集群我们可以采用向 rancher 这样的集群管理平台去管理它，我们现在就是这么做的在阿里云上有一个 rancher 的平台，然后管着我们在阿里云平台的业务集群和我们的多个边缘集群。然后你的第二个问题就是中心节点会存储我整个集群的所有的数据，因此我们应该周期性的对这个中心节点的这个数据进行一个备份，而且在未来的版本当中，k3s 会支持 HA，它是，它是通过实现后端存储，如 postgresql、MySQL 的一个高可用性保证我们的集群的可靠性的，这个现在已经是实验的特性了，估计在未来很快就会发布了。工作节点挂了的话分两种情况吧一种是你这个节点直接就不能工作了，还有一种情况点跟我的指甲想不通啊，那么前一种情况的话肯定是我的业务也不能正常工作了，后一种情况的话，其实我的业务还是在正常运行的，只不过是不能通过我的主节点去调度了，但是一旦它恢复这个通信的话，所有的都会自动恢复，因为这个边缘的这个设备的他有个特点就是网络不稳定，还有，还有就是经常会掉件这种情况，我们这个集群已经在跑了有两三个月了，表现一直是很好的。

Q：k3s 去哪获取 资料了？

A：k3s 相关的文档我们可以在 rancher 的官方网站上获取的。也可以到它的 github 主页上面去获取相关的材料。
补充：这题我会！k3s 的官网是：k3s.io，GitHub 的主页是：k3s，最新开始运营的官方微信公众号 ID 是：Dockerlab

Q：K3s 的 list-watch 请求没有走 tunel-proxy 吗？

A：k3s 的主节点和 agent 节点之间通信都是走的 tunnel 通道的。

Q：边缘网络不稳定的场景，list-watch 请求会有问题吗？K3s 有针对边缘网络不稳定场景做优化不？

A：这个场景其实就是 kubelet 跟我的主节点失联，一旦这个通信恢复的话，主节点他会直接把状态重新传到这个工作节点上去。

Q：k3s 在使用上和 k8s 相比有什么限制和优势？目前我理解来看主要就是占用较少资源。

A：对，因为边缘设备的话都是很小的工，一般都是公用的，工业用的工控机，工控机一般都是一个低压的 CPU 啊，然后还有一个就是内存比较小。实际上来讲的话我目前没有发现根 k8s 有太大的区别，基本上在我 k8s 上部署的应用全部可以部署在我的边缘端。

Q：k3s 的主节点和 agent 节点之间通信都是走的 tunnel 通道的。 List-watch 请求也走 tunnel 通道的吗，据我看源码，并没有走 tunnel，只有 logs 和 exec 接口走了 tunnel。

A：这里相关的源代码我没有深入去研究过，下来我详细去了解下 k3s 这里的机制。
补充：list-watch 就是直接访问 kube-apiserver 的端口。

Q：k3s 集群直接更改设备 IP 是否可用，如果不支持更改 IP，对于更改 IP 的需求有什么应对方案？

A：这里分两种情况，在集群部署完成后，如果要更改 server 节点的 IP，那么我们需要重新去将所有的 agent 节点重新加入到集群中，如果更改 agent 的节点 IP，那么可能导致 agent 节点对应存储在 server 节点中的身份凭证失效，也就是需要移除失效的节点，将修改后的节点重新加入，当然这种情况是在同一个子网内的情况，如果跨网段的话，那就会更复杂一些了。

Q：Rancher 管理 k3s 集群，k3s 的 master 要暴露公网 IP 吗？主讲人的多个边缘

A：server 节点不需要暴露公网 IP，只需要能从 server 节点内部访问 rancher 即可。通过 import 的形式将 k3s 集群导入到 Rancher 中即可管理起来，也可以管理应用和配置。

Q：k3s server 也支持 docker 吧

A：是的，agent 节点提供了–docker 参数，可以指定它的容器运行时为 docker

Q：rancher 可以自己部署，管理自己的 k3s?

A：是的，我们的 rancher 是部署在阿里云端，同时管理了我们的中枢业务 k8s 集群和多个客户的 k3s 边缘集群。

Q：有在 Android 上成功运行的经验或者案例么

A：我们暂时还没有涉及到 arm 的设备，也没有可供测试的 arm 设备，因此暂时没有这方面的实践。

Q：运行单个 Docker 容器来安装 Ranche？可以满足管理吗？

A：可以，但是这样可靠性会不好，推荐还是多实例通过负载均衡的形式来部署。

Q： k3s 支持 master 高可用吗？

A：暂时还不支持，但是已经发布了实验特性的版本，通过对 k3s 集群数据存储的高可用来实现的，我们可以部署高可用的 postgresql 作为 k3s 集群的管理节点的数据存储。这个特性应该不久就会 GA 了。

Q：边缘资源充足，是否可以直接用 k8s?

A：如果边缘设备资源充足的情况下，也可以使用 k8s 来维护，但是需要考虑的是边缘设备网络的复杂性和不稳定性。

Q： K3s 针对边缘设备网络的复杂性和不稳定性做了哪些改进

A：譬如刚刚有同学提到的 list-watch 问题，k3s 的我没有深入研究过，但是之前在调研 kubeedge 的时候，了解到其实就是在断网的情况下仍旧能够实现区域内自治，保证业务的稳定和持续性。

Q：针对 kubeedge 实现的区域内自治，K3s 当前没有实现的话，商用是否有风险呢，在边缘网络不稳定

A：这个还是还是得从那个边缘端的得从那个边缘端的这个特点来说。边缘端设备比较分散，每个节点的责任其实很有限，当然肯定有一些非常重要的节点，那这一部分我们可以采取一些额外的措施来保证可靠性，譬如直接从硬件上冗余来保证这一个区域的业务不中断。不是说 k3s 不能实现区域自治，譬如 worker 节点在于主节点失联不受控了之后，我怎么管理这台节点的应用，这种情况一般发生有两种情形，一种是断网，一种是断电，当然，断电的情形就不说了，断网的情况下。

Q：请问 k3s,k8s,kube,openflow,现在名词越来越多了,有没有办法在去区别这些名词是处在哪些的阶段，用于什么功能？

A：这个问题的话，首先还是根据项目需求来做对比调研工作，新技术层出不穷，不需要追求最新的，当下比较流行的一定是适应性最好的，一般经过了众多的验证。

Q：k3s 启动个 helm 的时候，由于众所周知的原因，经常下载不到镜像，怎么解决呢？

A：官方提供了离线镜像包，大约 200MB 不到，这个镜像包包含了我们启动 server 和 agent 节点所需的所有镜像，能够保证集群自身功能正常。helm 我们可以使用国内的 charts 源来代替，例如 azure 的源。

Q：containerd 可以配置 morror 么？

A：可以配置，但是比较麻烦，docker 提供了比较好的人际接口，所以推荐使用 docker。

Q：k3s 和 k8s 搭建的容器系统是否可以无缝的相互切换，如果不是，应该怎么做适配才能相互转化？

A：我不太清楚你这个无缝切换是什么意思，是业务迁移还是？首先这个需求可能并不常见，而且两者面向的场景不同。

Q：备份 k3s 的集群数据为什么是备份那几个目录而不是备份 sqlite 的 db 文件？k3s 的 server 支持类似 rke 对 etcd 定期自动备份配置吗？

A：因为还涉及到一些认证文件，譬如 agent 节点在 server 端存储有一个身份标记，agent 节点的恢复是会判断这些身份的。一旦丢失，重新注册相当于是一个新的节点了。

Q：请教老师，不管是基于 containerd 还是 docker，它们都是共享内核的，那么如何做到安全隔离呢？

A：在底层的资源隔离上，还是依赖于系统的各种命名空间，这块建议可以详细研究一下 pod 的安全策略。

Q：离线镜像文件是否只要放在 images 目录即可，文件名并不重要，都可以被识别出来？

A：是的，使用 containerd 作为 runtime 时，不需要手动导入，启动时会自动从这里获取镜像，如果使用 docker 作为运行时，需要手动 load 镜像，因为国内直接访问不了 gcr.io 下面的镜像。

Q：请问一个问题，单机版 K3S，容器内访问本机的一个服务端口，无法访问，这个问题官方测试过吗？

A：这个可能有很多种情形了，看是否是主机安全策略限制。例如 selinux 或者 iptables 规则限制了。

Q：centos 在边缘设备小内存设备上能装吗？也是有内存限制的吧，最小支持多少？

A：k3s server 官方给的需求是 512MB 就能满足，但是实际的观察中，一般情况下用到 200 多 MB，剩下的就看你部署的应用的资源需求了。另外我们需要保证应用不能把系统资源全部抢占了。

Q：k8 与 k3 在 api 上使用上有啥具体差别比如是否支持 crd?另外 k8 的网络组网方案有 flannel 和 calico，k3 是怎么组网的?

A：K3s 默认使用的是 flannel 网络。
补充：k3s 也支持手动指定其他的 CNI，都是比较灵活的配置。

Q：k3s 可以用来部署安全网关么？

A：暂时没有进行过相关的实践。

Q：iot client 设备没有固定公网 ip 下如何进行部署？需要自行组网吗？

A：这里是一个大家都会遇到的问题，一般来说，IOT 设备都是客户内网的，不可能给你在防火墙上打洞，我们现在是自己开发了一套系统，只用来偶尔维护边缘设备的后台，类似 ssh 反向代理就可以实现。

Q：容器运行时的查看的资源怎么跟宿主技做区分，比如我在运行的容器里面，free -h 看到的是宿主技的，怎么做饭只能看到容器本身的呢？

A：是否对容器做了资源限制。

Q：边缘设备是怎么被监控的，有的什么方案呢？是否也有监控的实时界面？？

A：我们可以考虑采取 prometheus pushgateway 的形式来在边缘内网部署监控代理，然后再介入到统一的监控平台。

Q：内网环境(可通过代理上网)，需要为 containerd 配制代理吗？还是 containerd 可以识别主机的代理配制？如果需要配制的话应该如何配制？

A：如果是全局代理的话，应该是支持的。

Q：k3s 跟 k8s 的迭代关系是什么，每发布新版 k8s，k3s 都要修剪出相应的版本，还是增量开发？用 k3s 需不需要定期升级？

A：我们一直在持续关注相关 release notes，当有重大新特性和安全问题、功能 Bug 修复时我们会考虑升级版本。

Q：Kubeedge 提供的设备管理能力，K3s 是否有相应的计划？

A：已经有了相应的计划，明年会在 k3s 的辅助产品中体现。不过，我们会更专注核心引擎 k3s 的迭代。

Q：Dind 中创建出来的容器 MTU 不正常，什么原因导致的？

A：Dind 不是本次分享的讨论范畴。dind 内部的 docker 也是可以指定 mtu 的，都是灵活的配置。

Q：请问一个问题，单机版 K3S，容器内访问本机的一个服务端口，无法访问。这个端口是我服务器上一个加密狗端口，程序需要从容器中调用这个加密狗。补充一下，我加密狗调用包含 tcp 和 UDP

A：没有在社区中收到过类似反馈，这里不适合讨论这种很细节技术的问题，建议您提一个 issue 到 k3s，我们在 comment 中讨论。

Q：我尝试给 containerd 配了代理，单独安装的 containerd 可以拉镜像，但是 k3s 内嵌的 containerd 确一直没法拉镜像。这个需要怎么解决

A：不确定你在 k3s 的 containerd 中如何配置的，k3s 的 containerd 中的配置文件会被重置，你需要以模版方式配置 containerd-and-docker。详细问题可以提 issue 到 k3s 来讨论。

Q：centos 在边缘设备小内存设备上能装吗？也是有内存限制的吧，最小支持多少？

A：官方给出的内存需求是 512MB，据我观察，在没有部署很多应用的情况下，内存占用一般在 200 多 MB，占用的内存会随着部署的应用增加而增加，但是一般边缘用的工控机内存最大一般 8GB，而且边缘不宜过重。

Q： 边缘设备上做 k3s ，岂不是增加运维人员工作量吗？本来是个简单应用，变成系统了！

A：因为边缘设备分散、网络情况不好，要统一管理和运维的话，是有难度的，后期的应用维护更新、配置变更、升级等等都是需要考虑的。如果采用传统的部署形式，虽然可以采用类似 Ansible 这样的自动化工具来做，但是要考虑到网络不稳定，部分设备离线情形的运维工作。所以采用类似 k3s 这样的统一管理平台是比较好的方案，在实践过程中发现，工作量下降了很多。如果不使用，你需要自己去 watch 你的应用的运行情况。自己去做类似 supervisord 这样的守护等等。

Q： 边缘设备及应用，监控用的是什么方案

A：采用在节点上部署 prometheus exporter, 然后再部署一个 pushgateway 来做。

Q： 最大支持多少个 agent，一个 server 带多少 agent

A：这个没有真正的去验证过，不过我们目前的集群状态已经达到 100+（1 server,剩余的全是 agent)，

Q： k3s 和 k8s 具体有多大的差别，有实例吗 ？或者数据对比。

A：在实际的应用部署中，几乎没有任何差异，至少到目前为止，我所遇到的场景,k8s 能满足的，k3s 也能满足，相信，通过不断的迭代，k3s 在未来会更完善边缘场景。

来自 18群 的无痕 2019-11-07 22:38:44，睡觉了拜拜！

---

2019-10-31：Jenkins X：基于 Kubernetes 的 Serverless Jenkins

提问链接

Q：这是干嘛的

A：在分享有关 Kubernetes 之上的 DevOps 产品 Jenkins X，有兴趣的话可以了解一下。可以加速软件的交付速度与可靠性。

Q：有实际应用案例吗？自己怎么快速体验 JenkinsX 的特性？

A：现在国内的应用案例相对较少，是属于下一代的 CI/CD 产品，在国外的用户会更多一些。jenkins x 支持一键在大型云厂商/现有 kubernetes 集群上进行部署，可以参考官网文档安装一下。

Q：和 gitlab ci 相比有什么优势

A： 和 gitlab ci 相比的优势可以参考下 jenkins 与 jenkins x 的对比。在用户角度来说，以应用为视角使用起来会更加方便，也方便利用社区资源。从架构和可维护性来说，Jenkins X 的架构会相对更加先进（与诞生年代有直接关系)。

Q：prow 现在支持 gitlab 了吗？现在大多数企业的代码仓库其实更多使用 gitlab。

A：prow 目前还没有支持 gitlab，这也是 jenkins x 目前最大的一个问题，据我所知目前 jenkins x 项目组在主要解决这部分问题，现在在 jenkins x 当中开发最活跃的模块 lighthouse 是做这部分工作的，有兴趣的话可以了解一下。

Q：从 Jenkins 迁移到 X 似乎需要大量功夫？

A：现在 Jenkins X 是有两个版本的，其中一种是使用传统的 Jenkins 架构，这个迁移过去相对平滑一些，但具体也和组织情况相关。不过社区主推的是基于 tekton 的方案，也被称为下一代 CI/CD 产品，如果是迁移到这种方案的话可以忘掉原来 Jenkins 所带来的经验，重新开始。

Q：KubeSphere 计划把 Jenkins X 用进去吗？

A：在目前版本当中还没有计划把 jenkins x 用进去，很大的原因是因为 Q4，现在 prow 支持的 scm 类型太过于单一了，不太适合企业客户。

Q：Jenkins X 可以直接用于生产环境的 CD 吗？可以结合公司的审批流吗？与 kubnetes 如何协作？

A：Jenkins X 是可以用于生产环境 CD 的，结合审批流应该有一定的开发量。可以看下分享有关 Jenkins X 的环境管理部分，Jenkins X 本身就是和 k8s 深度融合的。

Q：KubeSphere DevOps 对比原生的 Jenkins 有哪些优势呢？

A：KubeSphere DevOps 没有对原生 Jenkins 进行很大的改造。但是用户如果自己搭建 Jenkins 需要自己去了解 Jenkins 的原理以及各种和 k8s 结合的方案、如何运行的更稳定。如果使用 KubeSphere 的话用户可以直接使用流水线，避免掉了自己搭积木的过程。并且对于一些普遍的问题，我们会向 Jenkins 提交 PR 来改进 Jenkins 的功能。例如下面链接所对应的 PR 让 kubernetes 的 agent 调度从 10s 左右优化到了 10ms 左右 pull/598

Q：谢谢

A：所有人都在这里提问。

Q：其实 gitops 完全落地在一般企业是有难度的，考虑到有一些上线审批等流程。gitops 落地有什么好的建议和思考？

A：个人认为理想状况下最好的方案还是利用 PR/MR 的方式进行开发，在 PR/MR 里面进行审核，这可能和很多企业的现状不太符合，但其实这种方案在某种程度上也是可以落地上线审批流程的。可以先推行开发过程利用 PR/MR，用数据证明这种方式是可行的，再去推动生产环境部署切换工作方式。

Q：jenkins 如何做备份恢复

A： Jenkins 的备份有很多种方案。其中一种最常见也是比较暴力的方案就是备份下整个 Jenkins Home 目录，恢复的时候直接恢复整个目录就可以了。另外一种常见方案是 jenkins kubernetes operator 所采用的方案，在这个方案里面把 jenkins 的配置和操作历史记录进行了分离，配置（包括流水线的创建)都存储在 git 仓库中，而构建记录、日志等信息单独进行备份，有兴趣的话可以在 github 上找到这个项目了解一下。

Q： jenkins X 能支持 jenkins 现有的插件嘛？

---

2019-10-29：基于 Ceph 的 Kubernetes 数据持久化

提问链接

Q：k8s 里面使用 ceph，假设 ceph 出问题。这样会导致节点 hang 住吗？导致集群不可用情况。如果会，那该如何避免。谢谢。

A： 并不会，因为 Ceph 本身是分布式高可用的，而且即使 Ceph 节点全挂， 也仅仅会影响使用 Ceph 的 Pod，而不是节点。

Q：ceph 是通过 k8s 部署还是原生部署。ceph 和 k8s 节点超融合吗，还是分开。

A：一般生产环境中都是独立部署的，3 或 5 Monitor， 3 ～ 60+ OSD 等规模。

Q：K8S 中如果使用 RBD 作为数据库的存储，如果库比较大的情况下，对于数据日常的备份和维护是怎么做的？

A：可以利用快照，快速备份和恢复。在去年的 KubeCon 上，华为和谷歌的小姐姐们演示过 ceph 与 glusterfs 的优缺点

Q：在 K8S 中对于需要共享的存储，使用 CephFS 需要注意什么，会不会存在一些坑？

A：目前存在一种说法，就是 CephFS 不稳定，不推荐使用。具体如何不稳定、如何触发、怎么避免就很少有人知道了，另外还有，如果 CephFS 不稳定，那么我们还有其它哪些替代品呢？

Q：学习 ceph 有什么比较好的方式？以及如何比较有效率的实践？

A：快速阅读一下官方文档，然后自己安装一套，再结合文档深入研究。模仿需求场景测试使用。多实践。

Q：K8S 对外暴露服务用的是那种方式呢？ 如果在一个集群里面跑不同的业务，在对他们做对外的域名解析，访问控制是怎样实现的，会不会存在一些性能问题或端口的冲突？

A： 一般比较常见的就是单节点访问的 NodePort, 配置高可用模式的 Ingress 等等。
由于每个 Pod/Service 端口都是独立的，所以并不用担心会跟其它冲突。除非使用了 NodePort 且指定了端口。

Q：rook 和 原生的 Ceph 部署方式在性能和维护上是否有区别，这两种方式如何选择？

A：抱歉， rook 还没有使用过，不过相对来说，Ceph 集群维护的重点一般都在 OSD。在生产环境，一般也会独立部署 Ceph, 毕竟即使快速的重新调度 Monitor，也可能会对集群产生轻微影响。

Q：对于小中型公司来说 ceph 是个好选择么？自行维护，可以从多个方面说说 k8s 下如何进行存储选型么？谢谢！

A：相对可以接受，运维并不复杂。目前 k8s 上存储还是以 rbd 比较多一些。当然也有一些 NFS，不过因为其性能与稳定性，所以不推荐使用。

Q：如果使用 BlueStore 的方式，osd 磁盘文件的划分是怎样的，比如 WAL, DB 这种文件是单独存放在 SSD 盘中吗，还是都存储在 SAS 盘中?

A：有条件的话，且存储需求性能高的情况下，使用更高性能的 SSD 通常都会有更好的效果。

Q：Ceph 中 pool 数量是如何设定的，如果对集群进行扩容，PG 的数量是否需要调整，调整的时候需注意什么？ 网络方面怎么去规划比较合理，谢谢

A：目前 PG 的限制多一些，因为 Pool 里面 PG 是存在一定数量的，而 PG 数量又跟硬盘数量挂钩，所以调整时需要计算 Pool 的数量与 OSD 数量。网络方面的话，在生产环境，推荐使用至少 10Gbps 网络，双网卡以便分离业务和集群网络，提升性能。

Q：1.osd 是否需要做阵列？20 台物理机，单台物理机 1 个 OSD 阵列还是单台物理机 8 个 OSD 裸盘？2.当大量 osd 出现 slow ops 如何处理？3.纠删码和三副本，应该如何选择

A：磁盘数量较少时，不推荐 RAID，建议由 Ceph 直接管理磁盘，通过并行获取更好性能。另外 PG 的数量计算方式也跟 OSD 数量有关，所以需要综合考虑。这个可能需要结合监控系统，及时发现异常情况，是设备还是服务或者节点呀网络原因等等判断处理。可以结合业务场景需求与集群规模和硬件配置等情况来综合考虑决定采用哪种方式。

Q：rbd 分配给具体应用比如挂载到 mysql 后，如果空间不足，该如何扩容？谢谢

A：目前支持在线动态扩容。

Q：分布式存储应用于 hdfs 是否可行，相对于本地存储，分布式存储的读写性能如何提高，另外 ceph 的 bluestore 效果怎么样呢？

A：这个不太合适，因为 HDFS 本身自己就是做分布式的文件系统，且业务场景也不相同。Ceph 的性能提升无外乎两个方面：更快的磁盘/SSD 和 更大带宽的网络。由于直接管理了硬盘，所以其性能还是很好的。

Q：块存储模式下，磁盘在宿主机上的数据是加密的，如果要在容器外部操作这部分持久化的数据，需要怎么操作呢？

A：可以挂载操作。

Q：ceph 图形管理界面需安装什么软件？

A：现在不需要额外安装软件了，已经内置。

Q：请问怎样在 k8s 中，实现多个容器共享一个 ceph 文件系统，共享文件存储建议用哪种方式？

A： 这种需求就需要用 cephfs 了。共享文件存储的话，看最终客户场景，如果是给 Windows 等客户端使用的共享，那么可以通过 ISCSI 来挂载 RBD 到 Windows 共享服务器。

Q： Cephfs 之前在海量小文件读写测试时性能非常差，性能问题目前有没有解决？

A：性能需要靠硬件去堆。

Q： Ceph 最大支持多大的存储容量不影响性能，与分布式存储 HDFS 的区别有哪些？pgp 和 pg 什么关系

A：官方号称是 PB 级的。HDFS 适合大文件，上白 G 的那种单个文件。PG 是指定存储池存储对象的目录有多少个，PGP 是存储池 PG 的 OSD 分布组合个数。

Q： kubernes 中现在的块存储是一个部署绑定一个块，能否做成一个 pod 绑定一个块，有过这方便的实践吗？可否分享一下。

A：使用 StatefulSet 即可，会自动创建和绑定 PVC。

Q： 目前业界 ceph 集群的最大规模能达到多少个节点（大致的数量级)？是怎样的一种应用场景？

---

2019-10-15：Kubernetes 在 SHAREit 的落地实战

提问链接

Q：直接采用物理机还是有先做 IaaS 层虚拟化？

A：我们做的是出海业务，基本上考虑到合规等问题，我们主要项目全部运行在公有云上。

Q：有没有碰到调度的问题，某台服务器 CPU 或内存高了仍调度到这台上？

A：遇到过，一般情况下，需要考虑你的应用是否加了很多亲和性或是 nodeselector。正常的调度器，是会优先考虑资源平衡的。

Q：请问一下 coredns 如何反解析 pod 的 IP 地址？不用 svc 的情况下，是否可以解析 pod 的名字？是否有用 coredns 的 rewrite 插件。

A：这个不清楚，我们没有这样的场景。但是 coredns，支持编写自己的插件。

Q：请问下，不同云之间的延时怎么解决?你们是一朵云就部署一个完整的业务么？

A：我们会在不同云之间通过专线打通。基本上相关联的业务会部署在一家云上。但是我们会尽量保证同一个业务部署在不同的 AZ。

Q：告警策略上有没有最佳实践分享？

A：我们的统一报警平台基于 alertmanager 实现，基本上用到了它提供的静默，分组，抑制等特性。只不过我们对接了它的 api，也集成到 scmp 当中。

Q：配置管理是怎么做到不同环境，不同配置？

A：我们的配置是在 configmap 结合数据库来实现版本管理，本质上每个集群都需要单独设置。所以不同的环境，设置不同的 configmap 即可。

Q：业务的数据库是在 k8s 里面运行，还是单独搭集群？

A：我们除了 prometheus 和一些 mq，我们目前还没有尝试有状态应用。

Q：linux 内核参数优化具体你们碰到过哪些坑呢，怎么优化的呢？线上使用的 centos 版本和内核如何选择的？

A：我们使用的是公有云，内核版本一般公有云提供版本中最新的。其实不同的主机类型，相应的参数不一样，需要在选型主机的时候，做大规模测试。比如 net.netfiletr 下的参数。我们会基于公有云镜像，做优化，然后利用 pakcer 打成新的镜像使用。

Q：自研组件，可以开源吗？比如日志的那个

A：SHAREit 是一个技术非常 open 的单位。我们从上到下，鼓励技术人员去分享。所以如果大家有需要，我们会做一下内部的整理，开源出去。同时，我也会写一些具体的文章，来讲具体的细节。

Q：alertmanager 报警，我使用的 prometheus operator 安装的，使用默认的微信报警，这个报警时区问题，是修改源码解决，还是使用一个 webhook？报警的模板文件是如何管理的？

A：我觉得你应该需要重新定制 alertmanager 的镜像，在 dockerfile 中修改时区。其实我们这边也 fork 了 alertmanager，做了一些优化和功能增强，比如直接将 dingtalk 集成进来，避免引入 webhook 组件，所以我们也是自己打的镜像。至于报警模板，我们这边先把报警模板数据存放到数据库当中，然后结合 confd 来实现 altermanager 配置文件刷新的。

Q：hpa 部分你们怎么做到根据不同业务选择不同的策略?

目前最大的不太清楚，不少大公司可能不会公布。存储日志、备份数据等等。

---

2019-09-17：Prometheus 架构与实践分享

提问链接

Q：您好，我们 prometheus 监控系统需要持久化监控数据，目前约存储了 1.8T 数据，严重影响了查询速度，gafana 基本无法刷新数据了，请问有优雅的解决办法吗？

A：1.8T 都是保存在本地吗？SSD 有一定的加速作用。如果数据量比较大建议使用 m3db、clickhouse、opentsdb 等。

Q：如何登录 prometheus 数据库?

A：prometheus 本地 tsdb 没有登录入口，只有 go 的 api。

Q：企业级的 promtheus 监控的数据存储是基于什么呢？ES 吗，还是其他的存储？

A：我们使用 m3db，集群版本的 influxdb、opentsdb 等都支持

Q：现在有高可用方案吗？

A：prometheus 的联邦或者 Improbable 开源的 Thanos 都是高可用方案

Q：promethues 占用内存很好，我们的环境下 45w 指标大概要占用 8G 左右的内存，经常出现 prometheus 容器 OOM，请注意有什么办法可以优化内存占用吗？

A：数据指标如果确实比较大可以考虑 prometheus 的 hash 采集，分摊压力。在生产过程中很多指标都是可以省去的，譬如 kubernetes 中的 sandbox 容器的指标。

Q：面对海量微服务，好上千个 k8s 节点，日钧上千上万亿的时序点数据，如何解决 prometheus 高可用，如何选择和解决远程存储问题？宜信目前有多大规模？有多少指标，一天大概有多少量数据

A：目前宜信的容器大约 4000 左右，规模还并不大，很多服务都还部署在虚拟机里面。每天的监控数据量不到 100G。历史数据通过 M3db 存储。

Q：选择普通远程存储，面对持久化数据相对 prometheus 本地数据几十倍放大的问题如何解决，如何处理日 TB 级海量存储，后期如何取出数据进行分析？

A：prometheus 设计的初衷并非解决大容量存储。如果是 TB 数据建议保存到远端的 opentsdb 中。

Q：目前 prometheus 能否支持对网络设备的监控，如何支持采用 snmp ssh 等协议方式的监控；能否实现与 Zibbix 的对接？

A：prometheus 有 snmp 的 exporter 可以实现网络监控。目前还没听说可以对接 zabbix。

Q：目前 prometheus 的报警 rules 规则是怎么管理的？报警阀值是否可动态调整？

A：rules 也是通过 yaml 文件配置，可以动态调整，但需要 reload 配置。

Q：Prometheus 的 push 方式（push 推送给 pushgateway)和 pull 正常的方式方式的性能比较，谁更好呢？

A：pushgateway 本身作为数据转发的代理，本身性能损耗很少。建议直接提供 prometheus 的 pull 支持

Q：联邦配置时，实测抓取多个 job 的 metrics 存在延迟现像极其严重，不知道有没有好的解决办法？目前我是通过 grafana 直接获取两个 prometheus 集群作为后端数据库

A：这个主要看延迟的原因，是下面的 prometheus 采集慢还是联邦节点二次汇聚的慢。具体情况后续可以一起加微信排查一下。2 次汇聚，本地 prometheus 与线上 prometheus,本地配置联邦，本地汇聚线上 job 的 metrics，当 job 数量多了就会出现”federation failed” err=”write tcp 192.168.243.145:9090->10.0.0.12:33508: write: broken pipe”

Q：针对于一些公司自有业务的进程数据监控是依赖于自研 的 go-clent 上报吗？还是说一些三方的 client？

A：如果可以二次开发建议直接在代码里面加入 prometheus 采集的支持，处理 go 以外还有 java，Python 的 sdk 支持。如果不能二次开发也可以在外部通过 exporter 方式。

Q：如果有多个副本 CPU 利用率 还是用 container_name 来算就有问题了吧？另外问一下 不同版本的 pod（比如发版之后)怎么比较其 CPU 利用率？另外 histogram 的 metrics 有分析过吗？另外 查询一个月的数据应该蛮有压力的吧还是做了优化是否有必要？

A：嗯，多副本需要 group。不同版本数据都在 prometheus 存储，可以通过容器名称汇聚查询出来，一个月数据 step 可以调整的大一些。目前看一个月内的查询基本控制在 2s 以内。发版之后 pod name 名字是不一样的。一种方式是通过保持 container name，另外一种方式是通过前缀，正则匹配。我用得后者 不过会出现很多空线条 因为前面版本不存在这个 pod name 标签的 metrics，这个和多副本的 container_name 也算是有点冲突，暂时用正则的方式 多谢。metric 名称应该是固定的啊，你用正则匹配，不会有问题的，历史都会查出来。另外我发现 histogram 的 metrics 超过 7 天之后就没有什么参考价值了 所以对于查询一个月感觉意义不大，比如 prometheus_http_request_duration_seconds， metrics 还是重在实时性。

Q：Prometheus 的数据不知道宜信是否有存储，是存到 opentsdb 还是 influxdb 呢？

A：本地 +m3db

Q：prometheus 告警延时比较高，如果要做到秒级告警有什么方案！调整抓取频率不太靠谱

A：目前告警都是在几秒，你说的延迟是多长时间？

Q： 请问针对 Prometheus 不能监控日志的瑕疵，有什么好的方案可以和 Prometheus 形成互补呢？

A：公司自研了 watchdog 日志采集。社区常用 filebeat + es+kibana 方案

Q：宜信目前用 Prometheus 监控了多少个服务 target 了？Prometheus 使用的资源大概是多少？

A：宜信正在从 zabbix 迁移到 prometheus，目前是三台物理机。

Q：m3db 数据存储有没有放大？相对 prometheus 的 tsdb，有 大概有多少倍？

A：放大是啥意思？比如一天的数据 pro 的 tsdb 存储是多少 g，通过远程存储，就会放大几十倍，比如 100 个变成 1t

Q：请问应用进程 http 接口的性能监控是怎么实现的？

A：有 java 和 go、Python 的 sdk

Q：怎么过滤掉不需要的 metrics?通过 prom

A：这个可以在 pro 配置里面 drop

Q：本地存储用来做查询吗？多个 prometheus 是如何统一查询的？数据都存在汇聚的 prometheus 上吗

A：

Q：怎么实现 tsdb 历史数据保存到别的地方的？通过什么技术方式分开的？

A：remote write read

Q：时序数据库跟传统数据库的优势在哪？应该如何进行选型？

A：时序数据是保存随时间变化的量，查询也是时间维度，从而实现高压缩比。关系型数据有事在于数据管理。

Q：请问 m3db 能不能满足 ha prometheus 的数据去重？还是存两份？

A：m3db 不需要存两份

Q：比如要做每日用户登录数统计，具体应该怎么做？需要哪些流程和步骤？

A：需要程序里面集成 sdk，并提供查询累计登录用户的 http 接口，并在 prometheus 配置这个 target。

Q： 选型的时候为什么选择 m3？没考虑其他远程存储吗，是有什么考虑。远程存储你们只是用来备份一份吗还是也会一起从远程读数据？之前远程读的性能比较烂，目前 prom 新版本的 stream 远程读你们有试验吗

---

2019-09-19：云原生可观察性之日志管理

提问链接

Q：fluentd bit 在收集的容器 pod 中 启用 fluentd.io/parser 选项 采用正则表达式匹配，发现一个正则很难试用全部场景，而且发现匹配不到日志内容的时候 节点会 hung 住 再重启会无法启动 一直报 404 启动不了 请问这个如何解决的

A： 这个问题可以给 fluentbit 提 issue。KubeSphere 目前只用到 Parser 插件的 Decorders，主要是用 fluentbit 添加/删除/修改日志接收者，也会进行一些日志的过滤

Q：如何 debug Prometheus

A：如果您是要参与 Prometheus 的开发，可以参考 Prometheus Github 的开发指南。如果是使用中遇到问题可以结合日志，或者查看 Prometheus Console UI 有一些直观的异常提示，到 Prometheus 社区 slack 或 Google group 请教。

Q：Loki 你们在生产上有用到吗？有没有什么最佳实践？

A： 我们正在调研 Loki，Grafana Labs 已经用 loki 提供日志服务了。他们的部署方式参考 ksonnet 。建议就是几个组件要分开部署，每个组件可以有多个副本以实现高可用；另外就是根据情况选择 index 和 chunk 分别使用适合的存储。

Q：请问一下，用户想自定义日志解析，如何实现？目前我们实现方式是 fluentd parser 作为 agent 以 deamonset 的方式部署到 k8s 的每个节点上，一边收集一边解析，缺点是占用节点资源太多，请问咋们这边如何实现的呢？

A：收集日志的 agent 最好用比较轻量一点的比如 fluentbit，可以把 fluentd 作为 fluentbit 的接收者，用 fluentd 实现集中的解析后再发到最终的存储，这样就不用每个节点去部署 fluentd 了。类似这样的架构

Q：请问一下，单台日志量多少？

A：这个不太好说，看工作负载输出日志的情况。

Q：日志展示？ 是 kibana 还是自己单独

A：日志展示 KubeSphere 没用 kibana，是我们自己开发的日志 console

Q：接 Q4，谢谢您的答疑，目前我们想的是用户自定义解析策略不用通知任何人，日志就可以以流的方式输出到 es 或者其它终端，目前的问题就是如果用 fluentd 解析 如果添加一个解析规则就要修改 fluentd 的配置 就要重启下 这些感觉很不好，请问这边有什么建议吗？之所以用 fluentd bit 解析就是因为可以在 pod 上用 annotation 自定义 fluentd.io parser 解析策略

A：如果想每个节点都有自己的解析方式，而且不想频繁重启的话， 并且想用一个比较轻量的 agent 的话 可以试试 filebeat，filebeat 有自动加载配置的功能，解析日志也比较强大。

Q：KubeSphere 的日志系统看起来很漂亮啊，也是开源的吧

A：目前后端是开源的，前端也即将开源。目前的所有版本都是免费安装可用的。安装下载链接：kubesphere.io/zh-CN/install

Q：KubeSphere 的日志在多集群设计上是会用 Thanos 去实现吗？优点是什么

A：Thanos 适用于监控的多集群实现，可用实现多个 Prometheus 的全局查询。日志多集群的话用 es 实现的话 Elasticsearch 较新版本支持的。modules-cross-cluster-search

Q：fluent 和 filebeat 有做过压测吗？还是因为 fluentd 是 cncf 的项目才选择这个的？

A：ruby 也有 GIL 锁，只能压榨单核性能。选择 fluentbit 主要是因为内存占用少。filebeat 也很流行，go 写的，内存占用据我说知会比 fluentbit 多一些。fluentbit 是完全用 C 写的，不是用 ruby。Fluentd 核心用的 c，插件用的 ruby

Q：不同服务的日志都是混在一起的？而不是不同的 index？容器内的日志怎么采集呢？

A：目前是不同服务的日志每天一个 index，如果想不同 index 的话应该要用 filter 加 tag 实现。容器内没有输出到 stdout 落盘的日志可以用在容器内添加 sidecar 的方式将落盘日志转发到 stdout。kubesphere 2.1 即将发布，自带了收集落盘日志 sidecar 自动注入的功能

Q：标准输出，数据回落盘吗？怎么清理？

A：标准输出，日志不会落到容器内挂载的盘，但是会落到容器所在的节点的盘上，通常这个节点的容器日志会有 rotation 设置，定期清理

---

2019-09-19：当 K8s 集群达到万级规模，阿里巴巴如何解决系统各组件性能问题？

提问链接

Q：calico 网络中，如果节点跨三层，路由器不支持 BGP，RR 同步如何实现？

A：这个不清楚。

Q：由于节点 IO，网络，负载过高等问题，etcd 频繁选主，导致 kube-apiserver 方向超时。如何应对这种问题？

A：最重要的，我们需要为 etcd 配置相对稳定的资源，CPU/Mem 视集群规模而定，Disk 最好是 SSD，因为 disk io 性能对 etcd 写性能影响巨大。我们需要检查 etcd heartbeat timeout 和 election timeout，是否适合当前集群的环境。如果有条件，建议大家能去实践 etcd 3.4，pre-vote 的引入能有效减小异常情形下的抖动。此外，今天也给大家提到了 kube-apiserver 层面的优化，通过在 kube-apiserver cache 上实现 linearizable read，避免大量的读请求打到 etcd，从而可以大幅降低 kubernetes 集群中 etcd 的压力。

Q：当集群需要进行版本升级时，k8s 各组件应该怎么操作。需要遵循顺序吗？为什么？

A：一般遵循先升级 Server，再升级 Client 的做法。对 kubernetes 来说，先升级 kube-apiserver，再升级 controllers，最后灰度升级 kubelet。先升级 kube-apiserver 的原因是 server 是对外提供服务（接口)的，kubernetes 遵循向前兼容两个版本的机制，确保集群的兼容性，最后升级 kubelet 是因为在节点数非常多的情况下，kubelet 的升级需要一个较长的观察周期去灰度。同时提醒大家，一定要注意 kubelet 升级对节点上运行容器的影响。

Q：在 etcd 里面有三个 Instance，比如发生了以下场景:A 作为 leader，B 和 C 作为 follower，这时候用户通过 curl 指令发送了一个 Put 操作，A 收到后通知了 B 和 C，然后 B，C 回了 response,这个时候 A 提交日志到状态机，然后回复给用户，但在回复用户的过程中挂掉了。这时候假设用户不再发起请求，但 B 和 C 选出主机后会提交该日志，也就说用户认为失败了，但 etcd 内部已经提交了该操作。这种情况下 etcd 是怎么处理的？

A：这种情况只是告诉用户超时了（结果未知)，并未告诉用户你的请求成功或者失败了（结果已知)。理解了分布式系统调用的三态，用户系统为了确保正确性，可以选择重试或者其他的方式确认自身状态的推进。

Q：能否讲解以下 etcd 的幂等性的实现？

A：幂等简单理解多次调用同一个操作不会破坏系统的正确性，典型的 put key value 操作是幂等的，delete key 也是幂等的，因为这不会破坏系统的数据状态。试想一下如果提供一个操作叫做 inc key 对 key 做 +1 操作（比如 redis 提供了类似的操作)，用户很难“正确”的使用该 API 构建正确、一致的分布式系统。当然并不是说 redis inc 不好，它可以很好的应用于某一些对一致性要求不高的场景，一个典型的例子是统计微博的点赞次数。

Q：etcdctl 在最新版本中 get 一个不存在的 key 的时候为什么不返回 key not found 了（标准输出中)，没有任何的提示和返回，版本 3.5。

A：因为真实语意实际上是一个 range 操作，既然是 range，当然不存在 key not found 的错误了，如果需要可以根据返回的条目确定结果。

Q：在 3.3etcd 中有一个 etcd 处于故障状态，集群 api 暂时不可用这个问题除了升级 etcd 还有其余解决方案嘛

A：生产环境一定要配置定期的数据备份策略，用于极端情况下的集群恢复。当然对于超过 quorum 节点，理论上我们可以扩展支持 “不安全” 的 member 调整方案，用于最大可能的恢复最近的数据，欢迎到社区发起类似 issue 的讨论，或许它就会成为我们的下一个增强。

Q：Objects 是什么呢

A：指 kubernetes 中的 pod/node/configmap 等资源对象

Q：能不能整理出三个东西：名词列表、问题场景、解决办法图解版 😃👍

A：敬请期待

Q：kubelet 升级对节点上运行容器的影响大致有哪些呢？

A：比如因 spechash 的兼容性问题导致容器被意外重启

Q：为什么 acs 上 node 节点的最大 pod 数量是 110，和性能有关系吗？阿里云容器服务不是 acs 吗？

A：acs？还是 ack，大规模的 ack 集群也是支持的，非常欢迎提工单骚扰

Q：etcd 集群的 dbsize 的存储空间和 pod 等数量是正比增长吗？我们一个集群 400 个 pod db 竟然达到 2G，感觉不正常，另外一个集群才几十 M？

A：也和单个 pod 的数据量大小，etcd compaction 策略有关系，etcd 会储存数据的多个版本。一般从经验上，400 pod 2G 是不太正常的，确认是否存在其他用户数据（比如超大的 configmap)，确认 compaction 正常工作。

Q：k8s 的调度时延都和什么有关系？

A：和集群中的节点数量，节点的 label 数量和 affinity/anti-affinity 复杂性，以及集群的资源空闲层度有关系。前两者比较好理解，最后一个是因为对于一个资源分配较满的集群，从中找到可以容纳待调度的节点需要更多的尝试次数。

Q：目前您讲到的特性中有是否有贡献给社区的? 如果有的话,能简单说说吗?

A：etcd 增强已经回馈社区并且在 etcd 3.4 中发布，kubernetes bookmark 已经发布到 1.15,后续版本请保持关注。我们的策略是尽最大的努力回馈到社区中，请大家放心。

Q：请问在 k8s 中，遇到同一个接口对数据库查询时快时慢，然后整个系统中有很多应用都出现时快时慢的情况。这种情况下有什么好的方法去定位问题吗？感觉问题主要在 statefulset 的性能，和 k8s 内部网络上，但是却没有什么好的方法去定位.

A：不是特别明白你的问题。

Q：对于一个 JAVA 应用的 pod 的资源限制有什么好的经验？不知道到底应该限制多少合适？

A：这是一个比较复杂的话题（VPA)，一般来说我们可以通过放宽 resource limit 来观察应用实际的运行情况，并通过实际经验来判断应该采用多少的 request 值。

Q：如果 kube-apiserver/kube-controller-manager/kube-scheduler 是 static pod 形式部署的，那对这些 pod 做资源预留的方式，除了 request/limit 还有其他方法吗？

A：一般建议隔离 control planes 节点与其他 worker 节点，避免运维上的风险。如果一定要这么做，目前没有好的方法来确保他们。

Q：针对 etcd 集群，如何进行有效的监控，阿里云采用什么的方案监控集群的 cpu 和网络流量等，如果单节点冲高，有什么预警和排查思路吗？

A：阿里云一般采用 kubernetes on kubernetes 的方案，用户的 kubernetes 集群部署在一个叫做管控的 kubernetes 集群之上，因此用户集群上应用的监控采用典型的 Prometheus 的方案即可。kubernetes 到 etcd 流量不均衡问题，导致单个 etcd 流量偏高，实际上我们已经做了修复方案，这一块大家也可以关注 etcd 3.4 中的 load balancer 机制。

Q：能否再多介绍一些 apiserver 上实现

linearizable read 以及通过 cache 实现的对客户端查询的优化那部分。2.etcd、API server、Controller 及调度器优化实例

---

2019-09-03：基于 Kubernetes 的 DevOps 平台实战

提问链接

Q：请问老师是通过 Jenkinsfile 来控制版本管理吗，是否使用了 jenkins library，多个环境的情况下，是部署一个 Jenkins master，还是每个 K8s 集群都带有一个 jenkins master？

A：jenkinsfile 实现整个 CICD 流程，使用 git 对 jenkinsfile 代码进行版本管理；目前没有使用 jenkins library，但是 jenkins library 的方式正在重写过程中，还没有完成；多环境的实现是只在一个集群部署一套 jenkins master+jenkins agent，不同的环境通过不同 agent 实现

Q：我想知道这个分享有什么用？文字直播？

A：这个我来答一下，感觉没用可以不看，没有强制要求。

Q：每个 jenkins 的 job 里写一个 jenkinsfile 的 repo？这样是不是太浪费了。每个 repo 就一个 jenkinsfile 文件（多环境可能有多个分支)。我们是直接写成了 jenkinsfile 模板，然后 jenkins 构建参数传入的。不知道老师是如何权衡的

A：不是的，所有 job 使用一个 jenkiJenkinsnsfile。每个 job 就是传递一些基础参数，大多数配如编译命令，部署配置等，都是在 devops 平台先行配置好之后，触发 job 构建之后从 devops 拉取参数配置)

Q：为什么拉取代码后就要进行 Sonar 代码扫描呢？研发的代码都没有集成编译验证，扫描代码有什么意义？

A：不是拉取代码前进行的扫描，是拉取代码完成后进行的扫描。方便对接多语言。这个看取舍的，我们因为涉及语言种类比较多，不太容易顾全所有的语言，而且前期我们 php 语言的业务较多。

Q：你们生产环境也关闭防火墙了吗？不用防火墙吗？还是你们用的其他的安全措施

A：我们生产环境防火墙是关闭的，因为我们使用的是公有云环境，策略都是通过公有云安全组实现的。

Q：同 ansible 集成那部分怎么实现的？中间涉及到传参数，例如 IP 地址，端口号，服务名称，是通过什么控制的？

A：基础环境信息，都在 inventory 里维护。其他的一些参数放在一个 group_vars 中

Q：node 节点使用的是动态 token 还是 apiserver 内置的静态的 token 进行 bootstrap 的？

A：动态 token，不在 apiserver 的配置里指定 token.csv

Q：你们 master 节点和 node 节点都部署了多少台

A：master 节点 3 台，16c64G 的。node 有 600 台，配置种类比较多

Q：能否提供一下你们基于 pipeline 的 jenkinsfile 示例？

A：这个因为涉及公司隐私，不方便提供。但是后期基于 jenkins library 的代码完成后，会进行开源，请后续关注。

Q：knative 和 istio 现在未来前景咋样，国内有用到生产上去的吗？

A：我们暂时还没有使用到生产上去，只是调研阶段

Q：600 个 node calico 用的反射模式还是 node mesh?有做 pod 带宽限制么，谢谢！

A：node-mesh，目前没有对带宽做任何限制，calico 也遇到了不少坑，暂时也没精力进一步的使用功能

Q：感谢老师分享。想请问下您们的运维团队是怎么配置的，谢谢？！

A：我们分业务运维、系统运维、dba

Q：Jenkinsfile 使用文档较少，可以提供在此遇到的坑列举几个典型吗？谢谢！

A：使用的话，可以去参考有一本 groovy 的书。遇到的坑的话，大多数是 CI/CD 逻辑的问题，比如说，我们会有一个容器运行用户的配置，实际业务场景中有使用 root 的，有使用普通用户的，还会针对不同的环境适配不同的用户配置，逻辑处理出错就会导致实际部署后，pod 运行异常。

Q：请问 主机系统初始化 这一块对系统的发行版和内核版本有什么要求和建议？看到一些 docker 的问题是因为系统内核版本太低 （3.10 内核 kmem account 泄漏 bugs 导致节点 NotReady)，请问你们是如何选择的？

A：目前仅支持 Redhat、CentOS，内核版本是 3.10,没有进行升级。以我们集群运行这么长时间看，虽然有 NotReady 现象，但是概率比较小，固没对考虑对内核升级

Q： 请问下集群规模是怎么样的，node 节点是怎么做资源保护的？

A：目前 600 个 node 节点，我们目前是监控整体集群水位，在达到 60% 左右就会对集群进行扩容

Q：如何实现灰度发布以及蓝绿部署

A：基于ingress 实现的，部分是使用公有云的负载均衡，通过 api 实现切换

Q： 目前我们使用的 gitlab-ci-runner 部署于 k8s 之外实现 ci/cd。发现 gitlab-ci 在实际使用中，经常会遇到卡死报错。请问下，相比 jenkins 做 ci/cd 是会有什么优势，之前并没有使用过 jenkins.

A：gitlab-ci 生产环境中，我们也没有使用，我们调研的结果是 1、有侵入性 2、pipeline 功能较弱，但是有一个好处是遇到错误好像还可以继续执行。jenkins 遇到错误会中断流程。

Q：基于 kubeadm+calico，空闲时 CPU 占用达到 30-40% 是否正常？

A：实际使用中没有使用过 kubeadm 部署，因为封装东西太多，不易于排查问题。空闲时 cpu 到 30-40，需要具体情况分析。

Q：600 个 node 节点都遇到过什么问题， 有什么需要注意的？

A：前期网络上遇到的问题比较多，还包含 calico bug。后面多数是一些业务使用上导致的问题，还有业务增量之后引发的各种问题。

Q：请问是怎么配置的多个不同功能的 jenkins-slave pod 的还有 jenkins-slave 镜像怎么做的，还有一个任务中有发布和回滚怎么做呢，老师的 cicd 人工干预的地方在哪里?

A：jenkins-slave 镜像实际就是把 jenkins 的 agent.jar 运行在容器中。发布就如同前面所讲。回滚最终是调用 helm rollback。cicd 人工干预的话都是通过配置项来控制的。

Q：容器 web 应用，有没有做安全防护呢 有遇到用户恶意模拟 XFF，频繁访问接口么?

A：这个我们是在入口去做的，因为使用的公有云，直接就上了 waf、各种安全产品。

Q： k8s 的编排资源是怎么弄到 cmdb 上的–anonymous-auth=false 设置后，liveness 访问报 401 错误，我 Kube-apiserver 在不停重启，这个需要怎么配置？用 insecure ip 和 port,有不符合安全要求。

A：这个是没有通过验证，要确认证书或者相关配置，具体的配置可以参考我的文档 kubernetes 高可用集群之二进制部署

---

2019-08-29：Porter：面向裸金属环境的 Kubernetes 的开源负载均衡器

提问链接

Q1：Porter 和 calico 有啥区别，简单了看了下都是用的 BGP

A：Porter 是一个负载均衡器，而 calico 是 CNI 插件，用途不一样。

Q2：porter 有没有竞品？

A：有一个 metallb，以及基于 F5 的负载均衡器插件

Q3：leaf 节点是不是也需要部署服务?

A：不需要，只需要开启 BGP 就可以了

Q5：公司服务器就十台左右，部署的 Node 节点也比较少，网络方案使用静态路由是不是最好的选择？就是直接在上级路由器上添加 pod 的路由规则。性能方面是不是最好的选择？

A：pod 会有漂移情况的发生，手动更新一是比较麻烦，二是延迟较大。静态配置路由相比于开启 BGP 的路由器性能上会有一点优势，但是在 pod 漂移到手动更新路由中间，可能会出现服务中断，如果能承受应该是没问题的

---

2019-08-27：eBay Kubernetes 集群的存储实践

提问链接

Q：分布式数据库例如 MongoDB 在 k8s 上有实现方案吗?

A：有的，我们内部 NoSQL 就是完全运行在容器云上的，pod 部署由应用自己管理，通过 svc 暴露服务，存储上使用 local PV，并实现了 backup restore。社区应该也有比较多的实现参考。

Q：由于环境，如网络因素，出现短时间暂时大规模掉 node 的情况怎么处理？

A：如网络问题导致 node 连不通，对于网络存储来说，需要在网络恢复之后重连，比如 cephfs kernel client 和 fuse 都实现了 reconnect

Q：etcd 集群中，v2 和数据和 v3 的数据备份方式不一样，如何备份整个 etcd 数据呢？

A：etcd server 只能有一种版本，不会并存，所以按照各自版本的方式备份即可

Q：PVC 的 anti affinity 调度特性是 k8s 原生支持的吗？自研方案有计划贡献到 k8s 仓库吗？

A：不是，我们是在使用 MongoDB 的过程中，发现 master pod 的 io load 很高，所以基于此自己开发了这个功能。

Q：数据如何做容灾？

A：网络存储自己有多 replica 和 rack awareness 的分布，本地存储需要应用自己实现多拷贝，对于可靠性要求比较高的数据，需要做备份还原。

Q：本地存储能说的更清楚点么？比如 registar 是怎么把信息同步到 kubernetesnode 中的。pv 的删除是 csi 那个组件来做的？信息有哪些信息。谢谢。

A：registar 在注册节点的时候会将 vg 的相关信息以 annotation 的方式写到 node 对象中，pv 的删除由 csi-provisioner sidecar 完成，大体思路可参考社区的 design doc。

Q：容器镜像如何存储和管理？

A：我们目前用的是 quay，用 swift 存储镜像层

Q：redis 集群，3 主 3 从这种，如何跑在 k8s 上

A：可以用 statefulset 的方式，具体可以参考社区的做法

Q：使用 ceph rbd 会出现 multiattach error，导致新 pod 一直处于 creating 状态，需要人工介入，有无自动处理方案？比如，kubelet 挂掉

A：如出现 kubelet 挂掉或者 node hung 导致 kubelet 不工作，有可能出现这种情况，需要实现节点的 remediation，监控这些情况，重启或者下架节点，保证原来的连接断掉。

Q：请问日志存储是在专有的节点吗？如果不是会和业务数据存储产生影响吗？空间占用,cpu，内存方面的影响。

A：每个节点组件本身的日志和容器的日志都是通过 beats 来收集并上报到监控系统，不会和业务数据冲突或干扰。

Q：存储限制是怎么做的？

A：对于 emptydir，我们使用 xfs quota 限制。对于 PV/PVC，我们在 controller 层面做了每个 namespace 的 quota limit。

Q：ceph rbd 和本地磁盘有做过 benchmark 么？cg v2 应该只能限制本地盘吧？

A：

Q：kernel network storage 有没有什么好的学习材料？

A：具体是哪类存储类型，可以参见 linux-device-drivers

Q：有没有可能通过 StatfulSet 实现分布式存储？来做异地容灾

A：异地容灾是 federation 层面的部署，感觉和用哪类 workload api 没太大关系

Q：本地存储不需要另外的 scheduler-extender 么？用原有的 scheduler 就可以了？

A：我们是直接在原有的 scheduler 基础上做了修改，当时还没有 extender 机制，后续会考虑以 extend 方式放到外部

---

2019-08-20：小公司如何优雅地推进应用上 Kubernetes 容器云

提问链接

Q：有状态 springcloud 微服务如何进行管理和版本控制的？

A：微服务尽量做到无状态好。

Q：如何开发微服务应用 operator?

A：这个我看了三次，不太懂想问的问题是啥，我理解微服务应用与 operatorr 貌似没有什么必然的联系。

Q：Grafana 相比 Zabbix 有哪些优势和不足呢？

A：这两者是互补的，应该是问普罗米修斯吧。

Q：helm 如何落地？是否有方案开发替代的系统完成版本管理功能？

A：暂时没有使用 helm，公司使用版本管理是通过调用官方 API 接口来实现更新、回滚、重启等操作。

Q5：你们部署 k8s 应用 是有用到通用的 yaml 模板结合 helm 使用嘛 ？

A：是的，使用通用的 yaml 模板，但是并没有使用 helm。首先再运维平台网页上配置相关参数，发布时候传入变量值，例如启动参数、镜像地址、等生成 yaml 配置，然后通过 API 方式调用来实现部署应用。

Q：promethues server 后端存储 tsdb 高可用有做么 promethues server 起了多个么 ？有遇到过 server 会偶尔挂掉么

A：没有做高可用，server 端主动挂情况并没有出现，检查下日志看看是否有报错。

Q：请问从虚拟机正式环境迁移到 k8s 正式环境，需要做些什么准备，迁移过程会不会中断业务，数据库如何切换

A：不需要中断任务，应用部署后验证没有问题才切换负载，数据库其实不需要做啥操作，除非你是问数据库上容器的话，数据库这块暂时还没有迁移上去。

Q：前端和后端是不是改造完全分离的，有没有耦合在一起的项目，这些项目能用ingress 吗

A：大部分项目前后端分离，耦合一起的也能用，关键如何做好转发，现在逻辑上是 SLB–> 负载层–>ingress->-service–>pod

Q：开发环境中需要提供给开发使用的一些有状态的公共服务，在 k8s，网络部分如何处理，如注册在 zookeeper 的服务等等？

A：容器外访问容器内采取路由跳转，暂时通过 node 节点网络转发，这块后继需要优化。容器内访问容器外的，可以基于内网 DNS 配置公共服务地址即可。

Q：生产部署二进制还是 kubeadm？

A：开发、测试、预发布、生产环境都是使用二进制安装，主要基于 ansible 剧本安装，只需要修改部分地址变量（例如 vip、etcd 地址等)即可

Q：自建的 k8s 集群，当 node 节点资源不足时，你们公司是如何做自动扩展 node 节点的？

A：还没有实现自动扩容，暂时提供网页版扩容方案，这个也是下一步需要实现的功能之一。

Q：老师你们公司有做蓝绿发布或金丝雀部署吗？在容器云平台上是通过什么方式去实现的？

A：金丝雀部署功能已提供，容器这块暂时还没有开放出去，跑在原来服务器的已开发，不过公司有点特殊，金丝雀暂时只开放给测试人员测试使用。、方式以下两种：a、不同的入口，测试人员可以通过切换 hosts。b、浏览器设置 header 参数即可，负载层会判断来源实现不同转发。

Q：平时这么多微服务的 yml 文件是如何管理的？通过什么方式编辑和修改

A：文件其实是不存在的，是直接脚本生成 yaml 数据，通过 api 调用，python 脚本会写好基本变量，只需要传值即可，脚本截取部分你应该能看明白。

Q：听说你们汇桔网大裁员啊！还有几个运维？？

A： 现在运维 1 个

Q：一个微服务 yml 文件是 deployment 和 svc 配置一起，还是分开的 2 个文件？

A：文件其实是不存在的，是直接脚本生成 yaml 数据，通过 api 调用。

Q：etcd 看到 v2 的数据和 v3 的数据备份方式不一样。如何一起备份？是直接拷贝任意节点的数据文件备份就行了么？

A：备份需要了解网络和 pod 数据存放在 v2 还是 v3，明白了就可以确定那些需要备份了，容器的 IP 对业务应该来说是不影响的，也就是说网络地址变更后，业务还是可以正常运行。

Q：网络用的 canal 还是 flannel？有测试过性能么。能否满足需求？

A：网络使用 flannel，测试过暂时满足性能需要，后继这块有考虑替换其他，但短时间先不动为主。

Q：有让开发人员看监控么？比如说资源使用情况？

A： 监控平台是会开放出去的，开发人员能看到对应的 pod 使用情况。

Q：请问，我们是 java 项目，在业务代码打成 war 包后，war 包很大的情况下，在发布流程中，如何完成 pod 中的容器的代码更新，是采用挂载代码后重启容器方式，还是采用每次重新构建代码镜像，直接更新容器，或者有什么更好的建议吗

A：配置分离（上配置中心)，参数通过启动鉴权下载配置文件启动，这样子环境的更新只需要基于通过一个包即可。

Q：请问，那个管理告警并发送告警监控平台是怎么设计和实现的？

A：告警发送到监控平台不难，监控平台提供接口，数据过来做过滤存库处理，监控平台通过调用微信企业通讯录，绑定工号，发送也是调用 api 接口，并没有其他，只是简单做了合并收敛，5 分钟内非级别为高的，统一合并发送。

Q：有没有使用 volume，集成分布式存储场景？

A：volume 这块后面会上分布式，暂时文件上传暂时上传到 oss 上。

• Q：持续化存储推荐用的是什么，ceph 可以吗，这个数据做过持久化后，怎么做高可用
• Q：redis 有跑在 k8s 上么？主从或者集群有在 k8s 有跑么？传统的主从跑到 k8s 上需要做 redis 主从么？
• Q： K8S PYTHON client 的对象如何转 json 的？自己实现 decoder？

---

2019-10-24：玩转 Kubernetes 开发测试环境

Q：目前遇到的一个实际问题，就是开发测试环境如何进行数据冷启动？一般需求开发都依赖各类数据，开发人员需要在开发阶段往开发测试环境中灌入数据，还是从线上同步部分数据？请教下阿里内部是如何进行的。

A：在阿里内部开发测试环境是共用的一个日常测试数据库，不需要冷启动。在刚才介绍的模式里面我们希望日常测试环境足够稳定，只在需要发布的时候做部署和更新，其它的开发和联调测试行为都发生在本地，直接开发和测试

Q：数据库表的 Schema、nginx conf、RabbitMQ 的 Queue 等结构，开发测试环境是怎么和线上实时同步的呢？

A：会有专门平台做数据结构变更流程，从日常开始执行，测试完成后同步到预发、生产。开发中的 Schema 本身不够稳定，一定是日常验证通过之后才会往预发同步变更。

Q：我们公司有上千个应用，如何利用 Kubernetes 进行多版本并行开发？同时部署开发都非常困难，目前采用各个产品线提供多套服务的 IP，利用 hosts 配置进行联调，能否用 Kubernetes 改进？

A：首先应用的数量大，但是并不意味着所有的应用都会有相互间依赖。可能是一组应用共同对外提供了一个业务能力。Kubernetes 本身是可以简化应用的部署问题。在上面的分享里面，阿里每个应用在发布之后都会部署一个主干环境，这个主干环境的目标就是为了方便其他应用如果有联调需求的时候有一个相对文档的测试环境可以使用。另外提到的利用 hosts 配置，在 Kubernetes 中自带的服务发现能力可以帮忙解决这个问题。不过具体的场景会很多，这里就不展开。可以是按照组织架构的模式来划分，也可以按照应用所属的业务领域来划分。剩下的就是怎么把这些映射到 Kubernetes 的模型上。

Q：问一下，Service 走的 IPVS 模式，默认不是轮询的嘛，那么发布后端 Pod 的时候，哪怕是滚动更新，在旧的 Pod 消失前，不也会有流量走过来吗，怎么能让 Service 先把旧的 Pod 摘掉，在停服务呢？

A：KT Connect 的应用场景主要还是在开发测试环境，这块对本身的稳定性要求和线上环境不太一样。另外如果想确保服务始终可用的话 Mesh 模式刚好使用与这个场景。原生 Kubernetes 也提供了探针的能力来确保当服务不可用时，流量不会转发到 Pod 实例。

Q：容器化改造，业务转化成容器个数应该怎么评估？

A：这个问题也是一个很具体的问题，容器化改造和你目前的应用部署逻辑会有很大的关系。容器的个数并不是关键的衡量指标。比如在 Kubernetes 下一个 Pod 可以包含 1 到多个容器，这几个容器共同提供一个服务。所以还是看具体场景哈。

Q：对于开发人员来说，使用 Kubernetes 除了可以快速的生成代码运行环境之外，和传统的代码提交、拉取到指定运行环境的方式比较而言，还有什么好处？

A：在简单场景下直接对比这两种模式，不会有太大差异。不过就像今天的分享内容，我们希望对于开发人员而言，写完代码就不要去提交-部署然后在联调。直接在本地编码，本地运行然后和远端的服务进行集成。这样效率会明显提升很多

Q：KT 和 kubectl exec 的区别是？

A：KT Connect 主要是解决本地与集群内服务集成联调的问题，kubectl exec 是在已有的 Pod 上运行命令，不是一个维度的问题。

---

2019-09-25：HC Bridge 容器网络模式分享

Q：HC Bridge 支持 Kubernetes 的 Service 吗？

A：HC Bridge 原生就是支持 ClusterIP 和 Service 的。安装 Kubernetes 是就会开启 br_netfilter 的特性，基于 Netfilter 的 ClusterIP 仍然能够使用，所以 ServiceName 也是支持的。

Q：能讲讲 HC Bridge 负载均衡是怎么做的吗？

A：HC Bridge 采用 Linux Bridge，不同于 MacVLAN/SRIOV，本身具备 Kubernetes 原生的 ClusterIP 的机制。

Q：HC Bridge 对于 MacVLAN 有什么优劣势？

A：MacVLAN 性能略高于 Bridge，Pod 和 Node 二层隔离，需要借助三层才能通信；HC Bridge 能够使用 VLAN 使 Pod 和 Node 在二层隔离，使用 HC Bridge 的 Pod 网络流量能够经过 Node 的协议栈，Pod 流量能在 Node 层面统一管理和控制，并且具备 ClusterIP。

Q：多租户/VPC 模式下是否可以互相之间网段冲突？

A：HC Bridge 网段是否可以冲突取决于底层基础设施。

Q：HC Bridge 的监控怎么做的？

A：对于平台层面的网络质量监控、TCP 层的监控，kubelet 自带的 cAdvisor 就能够监控的要求；对于更加细粒度的业务层面的监控，我们自研的基于业务链路的监控来满足要求。

Q：HC Bridge 对于硬件交换机有要求么？

A：几乎没有要求，只要交换机允许一个端口能够转发多个 Mac 地址的流量即可，大部分交换机都能够满足要求。

Q：通常在什么情况下会选择使用 HC Bridge，而不是 Calico？

A：希望容器能够被集群外应用直接访问，业务能够感知 PodIP，而不是通过 Ingress 和 NodePort。例如中间件集群、Dubbo 集群、Spring Cloud 集群。在传统行业，网络管理员希望容器网络和物理网络一样，能够被传统的硬件设备管控。

Q：HC Bridge 在 OpenStack 环境下的兼容性怎么样？

A：如果使用 Neutron 网络，底层是使用的是 Linux ridge 当做网络驱动，则是可以兼容的；如果底层是 OVS 作为网络驱动，则默认情况下是不兼容的。

Q：HC Bridge 在 VMWare 环境下的兼容性怎么样？

A：在 VMWare 的绑定环境下的分布式交换机，要求网络是混杂网络，并且要求在宿主机上开启阻止混杂模式的重复数据包。

Q：为什么要自己在弄一个 etcd？

A：结构图只是示意，etcd 仍然可以复用 Kubernetes 本身的 etcd，对于大规模场景，也可以考虑使用独立的 etcd。

Q：HC Bridge 支持和 OpenStack 资源池互通吗？

A：可以的互通的，容器网络可以和物理网络、虚拟机网络在同一个层。

Q：是不是你们 Pod 直接挂在虚拟机网卡上，Node 之间是 VLAN 通信是不是二层互通？

A：这种设计应该也可以，但是动态扩展和容器网络管理完全依赖于虚拟机网络。我们没有直接使用虚拟机网卡，只是通过 Bridge 把容器网卡和虚拟机网卡连接起来，需要借助虚拟机网卡通信。

Q：HC Bridge 和 SDN 结合紧密吗？

A：谈不上紧密结合，HC Bridge 可以利用 SDN 的管理能力，这样 HC Bridge 本身不用做太多的网络管理。目前更多的是直接与传统网络对接。

Q：默认 Bridge 如果拉平网络，容器网关就是路由器的地址，Service 就用不了。HC Bridge 是如何支持 Sercice 的？

A：我们 Pod 的网关也是路由器地址，目前我们遇到 Service 不能使用的场景，主要是因为没有开启 br_netfilter。

Q：Contiv 的 VLAN 模式支持 Service 吗，还在学习中？

A：Contiv Service 应该是可以支持 Service 的，但是不能依赖于 Netfilter 来实现。

Q：既然同一个二层，为何不用 flannel hostgateway 模式？集群规模可扩展性也较差吧？

A：flannel host-gw 模式，跨 Node 的 Pod 通信时基于路由的，是三层；Flannel 是基于路由的方案，需要借助 BGP 才能实现与其他网络的互通，对交换机有一定的要求；对于规模而言，HCBridge 的规模主要受限于 VLAN 数量和 IP 地址余量；对于扩展性而言，HC Bridge 能够给 Pod 网络动态增加 VLAN 和 IPPool，能够保证扩展性。

Q：HC Bridge 方式有什么缺点？下一步发展方向是什么？

A：二层网络在虚拟机平台，都需要在虚拟机平台的网络开启混杂模式，这一点是比较消耗性能的；目前主要是继续关注双栈的支持、容器网络流量监控和流量管理方面的事情。

Q：IP 是如何分配的？追问：IPAM 部署在哪里呢？IP 地址段配置数据存在 etcd 里面是吗。

A：HC Bridge 提供 IPAM 管理的功能，可以根据 IP 地址 CIDR、VLAN 等创建 IPPool；然后可以根据业务、根据分区划分 IP 地址。HC Bridge 的 CNI 和 IPAM 都会以 DaemonSet 形式分发到每个 Node 中。IP 地址的相关信息肯定是存在 etcd 的。

---

2019-08-16：初探云原生应用管理之：聊聊 Tekton 项目

Q：请比较一下 Drone 和 Tekton，thx！

A：Drone 是一个 CI/CD 工具，Tekton 是用来做 CI/CD 的框架。Tekton 在更底层，也更为灵活。

Q：Tekton 作为一个执行引擎，可能会有很多执行节点串联运行，不同节点中运行状态和日志是如何反馈的？

A：Tekton Pipeline 本身就是 Kubernetes API object，我们通过汇总 Status 来透出运行状态。由于 Tekton Pipeline 启动的都是 Kubernetes Pod，我们可以复用原有的基础设施去收集，然后做一遍汇总。

Q：Tekton 如何与 GitOps 结合？

A：我们做了一个类似于 fluxfluxcd/flux 的 Operator，通过监听 webhook 事件等来触发操作。

Q：Tekton 集成方面有哪些特性？

A：灵活以及非常云原生。比传统工具更好在 Kubernetes 跟其他组件做集成。比方说，跟 Flagger 等在 Kubernetes 提供金丝雀发布策略的组件结合，做云原生应用发布。

Q： Tekton 既然作为 Knative 项目里面一个叫做 build-pipeline 的子项目，那请问下 Tekton 和 Knative 有什么不同或者对比优缺点吗，我最近有准备做 Knative，今天有幸看到这个分享，正好请教一下？

A：Knative 是 Serverless Framework，跟 Tekton 解决的不是一个层面的事情，没有比较性。相反，他们可以 inter-operate，Knative 里就使用了 Tekton。

Q：我的看法是 CD 和 CI 都只是 Tekton 的 Task，能否讲下你们的 CI？

A：你好，我们做的是 CD。不只是 Tekton Task，也用了其他的 Tekton 原生功能，比如 Pipeline、PipelineResource 等。我们做的是面向多云/多集群交付的、面向复杂有状态的阿里巴巴中间件应用的发布平台。

Q：你们做的这个和 Jenkins X Pipeline Operator and Tekton 的区别和两者的优缺点？

A：Jenkins X 是 CloudBees 团队基于原来 Jenkins 的需求，再使用 Tekton、Prow 等搭建的 CI/CD 平台。这也侧面说明了 Tekton 等云原生工具的优势。但 Jenkins X 做的比较重。而且以 CI 端为主，不支持复杂的发布策略。

Q：请问有什么好的 GitOpstrigger？我们使用的的是 Phabricator， 一直没有找到适合的 trigger。

A：这个主要看工具本身（比如 Phabricator）提供什么样的 Git trigger，然后才能集成到如 flux 这样的 GitOps 工具中。

Q：请比较一下 Prow 和 Tekton，发现 Kubernetes，Prometheus 以及 Tenkton 本身都是使用了 Prow。

A：Prow 是一款基于 GitHub 做的 Chatbot 工具。Tekton 则是用来实现后面对接的 CI/CD 的底层框架。本人恰好也是早期参与 Prow 项目，所以多说一点这个工具的历史。一开始 GitHub 功能不够强大，这个工具只是为了弥补 GitHub 的不足之处，主要是要经过 review 不能让人手动合并代码。后来功能做着做着变多了，有些被 GitHub 重复了。但是功能集合还是比 GitHub 多，而且 CNCF 里的 infra 默认使用。

---

2019-08-14：PPmoney 基于 Kubernetes 的 DevOps 实践

Q：怎么支持多租户不同流程定制使用及数据隔离需要？

A：这里我理解的是 CI 流程的定制？当前我们都是按照标准默认的 Jenkinsfile/Dockerfile 来接入，用户可自定义这两个文件。

Q：集群外部网络访问流量走向是：Client -> LVS -> nginx-ingress-controller -> Endpoints，不是 Ingress -> SVC -> 微服务？

A：ingress-controller 其实是通过 SVC 来获取到提供服务的微服务即 Endpoints。

Q：某个微服务节点比较，每次升级耗时特别长。有什么好的方式？

A：服务升级主要关系到的是 Kubernetes 的 rollingUpdate 策略，升级慢大部分时候其实是启动慢，服务没有很快达到 ready 状态。这个跟 resource 的 limit 以及 request 也有关系。

Q：目前生产环境 Kubernetes 是部署在公有云主机，还是物理机器上？有无做个性能测试对比？

A：生产环境我们目前还是小部分试点在 IDC 机房，之前也有在 Azure 上部署过 AKS 集群，AKS 的话会有一些网络的问题，例如 SVC 的模式只能是使用 iptables 而不能使用 ipvs。性能测试对比的话，对比过 AKS 上的实例跟内部云平台上的实例 QPS，大概是 1/3 这样子。

Q：请问你们日志收集是怎么做的呢？

A：分享内容里边有写到，Filebeat 收集之后发送到 Kafka，再由消费者取出做处理再入到 ES 集群。

Q：你们用过 Istio 吗，对容器性能有影响吗？

A：Istio 还在调研阶段，当然测试集群也有部署，对于用户可见的命名空间是 disable 的。对容器性能，应该说是对服务的性能影响，因为多了几次 iptables 的转发，开启 mixer 影响会更大些。性能与服务治理之间会有取舍。

Q：如何通过更改源码的方式来修改 kubeadm 证书期限问题？

A：1 年期的默认值是 hardcode 到 kubeadm 的源码中（在 k8s.io/kubernetes/cmd/kubeadm/app/util/pkiutil/pki_helpers.go{.prettyprint}文件中的 duration365d{.prettyprint}变量）的，改这个重新打包 kubeadm 的 binary 即可（非常不建议这种操作）。

Q：Istio 部署在 Kubernetes 高可用集群上，是每个 Master 都要安装吗？

A：不需要喔，如果是使用官方 Helm 部署安装的话 ControlPlane 默认会有 HPA 的。

Q：Istio 存在高可用吗？

A：上面指的我理解是控制层面的高可用。

Q：混沌测试怎么做，有介绍吗？

A：混沌测试借鉴了 Chaoskube 项目，我记得是，因为我们需要的混沌测试功能相对比较简单。阿里开源的 ChaosBlade 也非常不错。如果说有使用到 Istio 的同学试试 fault injection。

Q：监控方面有平台化吗，没有的话报警规则增加是谁来做的？

A：现在告警规则还是管理员来处理，其实平台化实现，prometheus-operator 中，Prometheus 的规则是从 CRD 即 PrometheusRule 生成再生成到 ConfigMap 中，我们只需要实现创建这个 PrometheusRule 的接口即可（还需要对应到 ruleSelector）。

Q：同一个宿主机上多个相同 Pod，日志文件怎么收集？

A：Pod 是不会有相同的 ID 的，通过 filebeat/fluent-bit 这类日志 Agent 收集都会有内置功能来支持将 Pod 的 metadata 信息也包含在每一条日志记录中。

Q：请问从开发到测试到生产的发布用到了哪些工具栈？分别起什么作用？

A：开发其实就只需要提交代码到 SCM，之后的工作由云平台来触发，在分享中的 CI/CD 图里边有画出来。涉及的工具主要还是 Jenkins，测试的同学会在 Jenkins 中做相应的任务。这种做法的缺点上面也有说到”似乎跟云原生背道而驰”。

---

2019-08-05：基于 OVS 自研容器网络插件在金融类企业的落地实践

Q：IPAM 的固定 IP 是怎么实现的？IP 与 Pod UID 关联吗？

A：管理员录入网络信息后，Fabric 会将所有 IP 地址存储到 etcd 中统一管理。目前固定 IP 是通过给 deployment 等 workload 对象增加 Annotation 实现的。IP 不与 Pod UID 关联。

Q：这里面提到的三层网络和二层网络是指七层协议的三层二层吗？

A：是的，比如交换机工作在 2 层，路由器工作在三层。

Q：服务负载均衡怎么实现的呢？

A：外部流量导入集群的负载均衡是通过另外一个组件，ingresscontroller 实现的，没有实现在 CNI 里面。 Kubernetes svc 的负载均衡是通过 iptables 实现的，Fabric 项目也会往 iptables 里面加入一些规则，主要是跨节点 SNAT。

Q：支持流量限流么？

A：支持 Ingress/Egress 限速，通过给容器加 Annotation 即可以实现容器的限速。

Q：有和 Contiv 做过对比吗？

A：选型阶段做过，比较早了，那时候貌似 Contiv 还不太成熟，所以没深入研究。

Q：这些网络方案有什么好的学习方式吗？

A：网络虽然很复杂，但万变不离其宗。容器网络这个词最近几年比较流行，是因为网络再容器环境下遇到了一些挑战，但网络本质的概念还是过去非常成熟的那一套。所以首先得学习基本的网络知识，然后去看下容器环境快速弹性等带来的痛点。

Q：TC 怎么实现的？

A：这个实现的比较久了，早在过去重点支持 Calico 的时候就已经做了。有些细节模糊了，但基本是通过 Linux tc 实现的，因为本质是 veth pair，所以限速可以在主机侧 veth 端实现。基本的限速命令可以查找 tc 机制就可以了，我们碰到限速不太准确，最后也通过调整参数解决了，误差控制在百分之几吧。

Q：与 Kube-OVN 做过对比吗？

A：Kube-OVN 是友商开源的产品，我了解过。首先 Kube-OVN 和 Fabric 项目都是基于 OVS 进行研发的，都支持 Overylay/underlay 模式，都可以实现 CNI 协议。但其实差别还是比较大。OVN 项目源于 OpenStack，OpenStack 里的网络模型是非常重的，概念、组件都比较多，OVN 也在试图统一 Kubernetes/OpenStack 的网络模型，所以 Kube-OVN 里有一些能力其实已经不在 CNI spec 的范围内了，比如负载均衡，DNS 等，其实在社区都有对应的实现。而 Fabric 会简单很多，是一个标准的 CNI 实现，网络模型也非常清晰，能够把容器直接融入现网环境，企业的网管一般都能掌控，对安全监管等已有体系兼容性比较好。

---

2019-07-24：TiDB Operator 的设计与实现

Q：升级开始时，partition = 节点数 - 1，也就是所有的 Pod 都不升级，为啥是 partition = 节点数 - 1？

A：这里要纠错一下，是 pod ordinal 从 0 开始计数，大于或等于 partition 序号的 Pod 会被升级，所以最大的序号是节点数 - 1，最开始的 partition 是等于节点数，分享时表达错了（我自己也记错了），抱歉。

Q：还有就是驱逐 leader 成功了怎么防止要升级的 Pod 重新被选为 leader？

A：我们实际上是在 PD 中提交了一个驱逐 leader 的任务，PD 会持续保证驱逐完毕后没有新 leader 进来，直到升级完毕后，由控制器移除这个任务。

Q：集群规模多大？多少 Pod Node？

A：我们在 Kubernetes 上内部测试的规模较大的集群有 100 + TiKV 节点 50+ TiDB 节点，而每位研发都会部署自己的集群进行性能测试或功能测试。

Q：想了解下数据库容器化，推荐使用 Local PV 吗，有没有哪些坑或最佳实践推荐？我们在考虑 MySQL 数据库容器化以及中间件容器化，是选择 Local PV 还是线下自建 Ceph 集群？

A：Local PV 其实不是一个选项，而是一个强制因素，因为网络盘的 IOPS 是达不到在线存储应用的生产环境需求的，或者说不是说线上完全不能用，而是没法支撑对性能要求比较高的场景。MySQL 的运维我相对不是很清楚，假如 MM 能够做到双副本冗余强一致的话，那理论上就能用。大多数中间件比如 Kafka、Cassandra 都有数据冗余，这些使用 Local PV 在理论上都是没问题的。

Q：看你的方案感觉 Kubernetes 和 PD 的逻辑结合在一起了，二者之间如何互通？会有代码互相侵入吗？明白了，就好像问题 2 驱逐问题，pd 收到驱逐任务，Kubernetes 控制器不断的检查是否驱逐成功，如果成功就开始升级，对吧？

A：这就是自定义控制器的绝佳场景了，Kubernetes 和 PD 本身完全没有交互，是控制循环在同步两边的状态，一方面控制循环会把 PD 记录的集群状态塞到 TidbCluster 对象的 status 里面，另一方面控制循环在将实际状态向期望状态转移时，也会生成一些 PD 的任务和操作子（Opeartor）提交到 PD 中来调谐集群状态。

---

2019-07-17：基于 Istio 的灰度平台实践

Q：如何判断 check、quota 下放 istio-proxy 引入的问题？

A：得通过压测了，看性能损耗了。我们后续会加入 Mixer 的功能再压测一轮。现在做的压测还是不开 Mixer 功能的场景下压的。因为我们线上目前还不打算开 Mixer。

Q：能否给个 demo？

A：目前还没有开放在外面的 demo。可以给些思路，请问你想要什么要的功能的 demo？没实践过，听理论总是有点虚！可以实践一下。我们主要是用的 Istio（Envoy）的流量管理的功能。主要是要配置 Istio 的流量管理策略。给业务人员再给他们配置 yaml 文件，学习成本太大，所以做了可视化，有按流量，按用户，自定义三种方式。主要是把页面配置编译成 yaml 流量配置。

Q：Istio 每个服务中得到的访问 IP 都是 127.0.0.1，这个该怎么搞？能拿到 realclient ip？

A：kubectl getsvc 应该可以查到 clusterip，接着 Q3，app 拿到外面访问的 address 都是 127.0.0.1 的。

Q：服务的应用运行日志在 Istio 中如何获取或者查看，例如 log4j 控制台的输出？

A：应用运行日志就在应用容器上看啊。我们是通过标准输出收集到了 InfluxDB 中。

Q：Envoy 的 CPU、内存的 request、limit 一般配置多少？

A：我们压测的是默认的 Envoy 的资源限制。没有修改默认的资源限制。

Q：里面在配合 Spring Clund 有必要吗？

A：感觉没必要，重复了，Istio 让程序员更关注业务，将维护管理分离

Q：有配合 Alibaba Nacos 试试吗实验落地的最好，consul.etcd 选哪个好点？

A：没有使用过 AlibabaNacos，我们未来会走 Kubernetes 的服务发现，所以会选择 etcd 吧。

Q：SpringCloud 向 Istio 迁移好迁移吗？

A：比较好迁移。我们遇到的问题主要就是通讯的问题。涉及到 Feign 和 gRPC 两种。需要升级一下 starter，传递一下 header。因为我们的流量标签是在 header 中传递。还有一个重要的就是分享里提到的，服务发现问题。因为要做渐进式升级，不能一下就给所有的服务上 Istio，边缘服务先上，热门服务后上，所以要兼容之前的服务发现（Consul），同时有两个服务发现机制的时候会有些问题。

---

2019-07-10：Kube-OVN 的设计思路和实现原理

Q：能说说组件 kube-ovn-cni 具体是做什么的？OVN 本身不是已经是 OVS 的控制面了么？

A：其实做的是容器网卡和 OVS 的对接，OVN 那边生成了 port 的信息，需要 kube-ovn-cni 把这个信息同步到 OVS 和容器网卡。

Q：能讲讲 Kube-OVN 负载均衡和会话保持是怎么做的吗？已经支持哪些策略？

A：目前的负载均衡用的是 OVN 的 L2Loadbalancer，这一块的负载均衡还比较简单只支持 IP Hash。

Q：多租户/vpc 模式下是否可以互相之间网段冲突，如何实现 livenessProbe？

A：这块暂时还不支持，主要是 kubelet 是在主机的 network namespace 进行 probe，其实可以改 kubelete 代码进入到对应容器的 ns 再 probe 就可以了，但是这块需要 upstream 来进行支持，自己魔改现在倒也是个方案。

Q：Kubernetes 的业务使用本身就是有局限的，这种无限制扩大虚拟网络的做法，基于业务风险和成本来讲，真的很勇敢，如果原有的 Kubernetes 生态被改掉了，怎么保证开源的东西可以业务延续？

A：这个问题有点大，我们现在看到的趋势还是 Kubernetes 不断的发展，各个业务都在往 Kubernetes 走，我们做这个其实也希望能尽量和 Upstream 同步，并且之后可以去影响 Upstream。还有很多复杂的功能，比如 IPv4/IPv6 的双栈，多租户我们暂时也还没开始，也是因为 Upstream 现在对这块的支持还不好

Q：和 ovn-kubernetes 的区别是什么？

A：ovn-kubernetes 我们之前调研主要问题在于他们是和 Flannel 类似的一个节点一个子网的模型，再就是看他们的代码过程中发现控制平面存在着丢消息的隐患。最后看到网络模型和控制平面都要改，工作量太大了我们就自己从头来了。

Q：容器内流量采集监控有没有什么实战和想法？

A：目前还是用的标准的采集网卡上 TX、RX 的一些指标的做法。不过 Kube-OVN 上现在有流量镜像的能力，未来其实可以做更详细的应用层数据包分析。

Q：使用 Flow 负载均衡器的性能怎么样，是否适合上生产环境？

A：大部分的 Flow 性能问题都可以用 DPDK 来解决，我们之前问过一些公有云的厂商性能方面是可以的，但是可能功能方面有些简单。

Q：请问网络相关的功能支持，目前是只针对以太网络吗，你们有对其它高速网络有支持不？

A：目前是只有以太网，但是其他形式的理论上只要 OVS 支持，适配起来应该都比较方便。

Q：使用 OVS 对 Host 机器的性能压迫有多大？

A：我们目前看来还好，OVS 本身带 cache 的机制，主要还是业务对性能用的比较多一些。

Q：Tracing 方面跟踪流表有没有想过做自动化？

A：有过这个计划，打算结合 ovn-tracing，ovs-tracing 再加上宿主机的探针做一个端到端的数据包跟踪，来解决网络不通排查方面的问题。

Q：kube-ovn-controller 如果来不及写入 podIP 这些信息，CNI 插件获取不到分配的 IP 信息，会不会导致 Pod 创建失败，还有 ovn-cni 是能过什么协议和 ovn-cni-server 进行协作的？

A：来不及写入的情况下 CNIServer 会重试等待 annotation ready，如果超时的话会失败等 kubelet 下次调用 CNI 的时候重新获取信息。CNI 和 CNIServer 现在是通过一个本机的 socket 走 http 协议进行通信。

Q：DPDK 怎么满足需求？使用容器，可以用 DPDK 加速么？

A：DPDK 主要做 OVS 的流表加速，社区由 ovs-dpdk 的 binding，容器相当于用的是 OVS 的网卡，这样 DPDK 就可以加速容器的网络。

Q：请问你们在使用网络相关的功能时，会在某些场景对特权模式有强需求吗？

A：需要使用特权模式，因为要对宿主机的网络进行一些操作。

Q：在没有硬件交换机的情况，这个网络插件怎么利用虚拟机模拟交换机呢？

A：还是要有硬件交换机做物理上的网络连通的，虚拟交换机是在机器中用软件的方式来模拟交换机的行为，这样一台机器上的多个容器或者虚拟机就好像接在了一个物理交换机上。

---

2019-07-03：震坤行的容器云实践

Q：Kubernetes 云平台和物理机平台，在性能对比上，Kubernetes 差多少？

A： Kubernetes 的最小单元是 Pod，Pod 是跑在云主机上的。整个 Kubernetes 都是基于云主机/物理机来完成的。

Q：数据库集群是否适合丢在 Kubernetes 上，如果千万级的日活是否有好的解决架构？

A： 首先数据库是可以跑在 Kubernetes 上的，数据库集群直接互连的 IP 是可以通过 Kubernetes 的内部.svc.cluster.local 来代替。如果跑数据库集群，则需要将 Pod 使用硬盘 volume mount 将数据映射到硬盘上。目前我们 DEV，UAT 环境的数据库在集群中。针对千万级的日活，主要是看瓶颈卡在那一块。

Q：根据你的描述：你们是从 18 年 8 月份开始使用容器的，到现在一共是 11 个月，把 Kubernetes 这套生态落地到生产，你们的筹备是几个阶段，然后难点是什么？是否发生重大的生产事故，怎么处理的？你们的后端存储使用的是商业存储数据库还是自己搭建的 Ceph 等开源数据库？电商活动临时购买阿里或者腾讯云机器，新增不同机房 Node 节点之间网络延迟如何解决的？

A：我们是分为了三个阶段，一个是测试 Kubernetes，一个是测试业务接入，一个是测试接入业务的稳定性。难点就在于以前的架构整改，包括 Kubernetes 结合微服务。重大的生产事故未发生过，因为涉及到 Ingress、网关等入口服务，一般都是多备份。我们后端的数据库，是在阿里云购买的，DEV，UAT 数据库是开源自建的。电商活动前，我们一般是会购买按量付费的机器，我们购买的都是阿里云。

Q：生产环境会跟着社区版本积极更新 Kubernetes 版本不？或者什么频率？

A：这个一般不会跟着社区积极更新，除非是当前版本出现重大 bug，或者新功能比较适用于我们，才会考虑更新。

Q：Istio 有没有进行优化，QPS 大概是多少？如有优化都是从那些方面进行优化的？

A：Istio 目前是进行过优化的，优化的细节暂时还未统计。当前的 QPS 我们大约是每秒 5000 个左右吧。更具体的要看业务。

Q：有在用统一的文件存储吗？不同用户间会考虑做隔离不？

A：统一的文件存储有，但是目前主要是拿来放日志，共享等。不通用户间的隔离不太清楚是啥意思，但是每个 Pod 之间是隔离的。我们在 DevOps 平台是有权限管理模块的。

Q：问下你们的日志采集方案是怎么做的？日志是否写在容器里？另外再问下 Kubernetes 的 CRI 是用的 Docker 吗？还是用其他的，谢谢。

A：日志收集是通过 ELK + 二次开发来完成的。日志也会也在容器里，写容器里边随着下一次发布日志就会消失。是 Docker。

Q：Eureka 和 Istio 不是同一类东西吧，作用都不一样，怎么理解替换不替换？

A：看架构类型用到那个组件吧，Istio 本身具备服务发现功能，我们刚好是服务发现这一块有问题。

Q：你们的 Kubernetes 集群节点规模有多大？日活？Kubernetes 运维团队多少人？

A： Kubernetes 集群节点有，dev 24 台 4C 32G，UAT 30 台 4C32G，生产 67 台 8C 64G，Kubernetes 运维团队 2 个人。

Q：更换成 Istio 之后，就不需要单独部署 Ingress 了吧？

A：需不需要不用 Ingress，具体还是得看下业务类型。我们是微服务 API 类的，走的 Istio，静态页面类，CDN –> Ingress 。或者是 CDN –> SLB –> Pod。

Q：请问 Kubernetes 如何和云服务的弹性伸缩配合使用，例如，因为业务需要，短时间内从 2 台节点扩展到十多台节点。可以做到像云服务的弹性伸缩那样吗？不提前配置节点，或者如何让 Kubernetes 自己触发云服务的弹性，自动添加云服务的弹性节点。

A：我们一般会对容器云的 ECS 资源保留 20%-25%。如果发现资源不够了，就会提前购买 ECS 加进去。短时间扩容 Node 几点的话，就多购买几台 ECS 同时加进去就可以了。Pod 是可以做弹性伸缩，ECS 云主机也可以做弹性伸缩增加到 Kubernetes 集群里边，这个阿里云提供服务的。

Q：Eureka 是类似 Dubbo 的注册中心吗？

A：是的，Eureka 也提供页面，可以查看到有多少个服务注册进来。

Q：请问一下注册到注册中心的 IP 是容器内 IP 的问题如何解决？

A：我们是将注册中心部署到 Kubernetes 集群中的。注册中心的内网 IP 和 Kubernetes 的内网是互相可以通信的。

---

2019-06-26：智能工厂的容器云实践

Q：您认为未来工业 PaaS 云平台的发展前景和发展模式有哪些？

A：工业场景本身是千差万别的，石油、金属、制造业等等，都有自己各自的需求，目前来看的话，主要还是要先完成信息化改造，然后才能以此为基础去做后续的比如工艺优化等等。后续应该会公有云、私有云并存，大集团型公司走私有云模式，中小型公司走公有云模式。

Q：生产很在乎高可用和数据的安全性，Kubernetes 如何保证持续存储和稳定性，单靠副本集和集群在网络事故发生后，如何快速迁移恢复？腾讯的王者荣耀采用了比较老的 Kubernetes 版本并进行了开发，才使用在了生产，中小型企业如何依靠自己的研发实力去处理生产事故。

A：目前我们遇到的生产事故主要在于机房的偶发性断电导致存储节点上的数据出现故障，现在的话是采用 3 个存储节点的 3 副本方式，来保障数据的可靠性。高可用目前还是依赖副本集的形式来保障。对于工厂来说，很少会出现互联网这样的流量峰值，基本都是平稳的。

Q：Kubernetes 的在线热升级容易做吗，请问是不是踩过很多坑呢？

A：目前对于 Kubernetes 的热升级，主要是大版本变动会带来一些配置上的改动，因为全部容器化，所以升级本身不复杂。

Q：现在生产服务的规模多大，服务数量，流水线是每个项目类型一个公共构建项目吗？针对多分支构建如何快速持续集成？针对服务的特殊化需求比如 Pipeline 的某个 stage 要跳过怎么办，每个项目一个标准的 Jenkinsfile 吗？

A：服务数量根据不同的项目规模，各有不同，智能工厂项目本身是一个很庞大的项目，下面会分很多的子项目，目前来看，一般的子项目服务数量是在 50 个以内。目前我们还没考虑多分支情况，因为项目不像自己运维的产品，不会存在频繁的更新，我们是按版本形式去走，所有的提交最后都要汇总到主干分支后，再打包发到现场。目前还没有跳过 stage 的需求。

Q：Jenkins 对开发和测试人员可见吗？如果可见，有没有考虑封装 Jenkins，如果不可见，Jenkins 日志怎么暴露的？每次构建都要填那么多信息感觉很复杂？有没有改建措施？

A：目前是可见的，但是没有修改权限，可以直接去看构建日志。

Q：Windows 节点支持情况？

A：我们会有一些场景需要用到 Windows 服务器，并且它需要跟容器云内部的服务进行通信。

Q：请问 Jenkinswebhook 那些构建参数如何传入 GitLab 触发？

A：webhook 的触发和界面参数会有一些区别，我们在脚本里面做了处理。

Q：离线部署，是不是通过打出镜像压缩包，然后带着镜像包到现场部署的容器云平台上，上传部署的方式？

A：是在家里打出镜像压缩包，然后到现场解压出来，根据镜像类型进行处理，比如一些基础镜像，会直接上传到节点，业务的镜像会在部署完成后上传到 Harbor，然后节点从 Harbor 去拉取。

---

2019-06-05：基于 Actor 模型的 CQRS/ES 解决方案分享

Q：单点故障后，正在处理的 Cache 数据如何处理的，例如，http、tcp 请求……毕竟涉及到钱？

A：actor 有激活和失活的生命周期，激活的时候使用快照和 Events 来恢复最新内存状态，失活的时候保存快照。actor 框架保证系统中同一个 key 只会存在同一个 actor，当单点故障后，actor 会在其它节点重建并恢复最新状态。

Q：eventID 生成的速度如何保证有效的 scale？有没有遇到需要后期插入一些 event，修正前期系统运行的 bug？有没有遇到需要把前期已经定好的 event 再拆细的情况？有遇到系统错误，需要 replayevent 的情况？

A：当时项目中 eventID 采用了 MongoDB 的 ObjectId 生成算法，没有遇到问题；有遇到后期插入 event 修正之前 bug 的情况；有遇到将已定好的 event 修改的情况，采用的方式是加版本号；没有，遇到过系统重新迁移删除快照重新 replayevent 的情况。

Q：数据落地得策略是什么？还是说就是直接落地？

A：event 数据直接落地；用于支持查询的数据，是 Handler 消费 event 后异步落库。

Q：actor 跨物理机器集群事务怎么处理？

A：结合事件溯源，采用最终一致性。

Q：Grain Persistence 使用 RelationalStorage 容量和速度会不会是瓶颈？

A：GrainPersistence 存的是 Grain 的快照和 event，event 是只增的，速度没有出现瓶颈，而且开源版本测试中 PostgreSQL 性能优于 MongoDB，在存储中针对这两个方面做了优化：比如分表、归档处理、快照处理、批量处理。

A：开发语言是 C#。Golang 我了解的不多，proto.actor 可以了解一下：AsynkronIT/protoactor-go。

Q：每个 Pod 的 actor 都不一样，如何用 Kubernetes 部署 actor，失败的节点如何监控，并借助 Kubernetes 自动恢复？

A：actor 是无状态的，失败恢复依靠重新激活时事件溯源机制。Kubernetes 部署 actor 官方有支持，可以参考官方示例。在实际项目中使用 Kubernetes 部署 Orleans，我没有实践过，后来有同事验证过可以，具体如何监控不清楚。

Q：Orleans 中，持久化事件时，是否有支持并发冲突的检测，是如何实现的？

A：Orleans 不支持；工作中，在事件持久化时做了这方面的工作，方式是根据版本号。

Q：Orleans 中，如何判断消息是否重复处理的？因为分布式环境下，同一个消息可能会被重复发送到 actormailbox 中的，而 actor 本身无法检测消息是否重复过来。

A：是的，在具体项目中，通过框架封装实现了幂等性控制，具体细节是通过插入事件的唯一索引。

Q：同一个 actor 是否会存在于集群中的多台机器？如果可能，怎样的场景下可能会出现这种情况？

A：一个 Id 对应的 Actor 只会在集群种存在一个。

---

2019-05-29：平安证券 Kubernetes 容器集群的 DevOps 实践

Q：镜像有进行安全扫描吗：

A：外部基本镜像进入公司内部，我们基于 Harbor 内置的安全功能进行扫描。

Q：Harbor 有没有做相关监控，比如发布了多少镜像，以及镜像同步时长之类的？

A：我们没有在 Harbor 上作扩展，只是在我们自己的 Prism4k 上，会统计各个项目的一些镜像发布数据。

Q：有没有用 Helm 来管理镜像包？后端存储是用的什么，原因是？

A：没有使用 Helm。目前集群有存储需求时，使用的是 NFS。正在考虑建基于 Ceph 的存储，因为现在接入项目越来越多，不同的需求会导致不同的存储。

Q：想了解下目前贵公司监控的纬度和监控的指标和告警这块。

A：监控方面，我公司也是大致大致划分为基础资源，中间件，业务指标三大块监控。方法论上也是努力在向业界提倡的 RED 原则靠拢。

Q：想了解下，Yaml 文件怎么管理的，可以自定义生成吗？

A：我们的 Yaml 文件，都统一纳到 Prism4k 平台管理，有一些资源是可以自定义的，且针对不同的项目，有不同的 Yaml 模板，然后，透过 django 的模块功能统一作解析。熟悉 Yaml 书写的研发同事可以自己定义自己项目的 Yaml 模板。

Q：Pipeline 会使用 Jenkinfile 来灵活 code 化 Pipeline，把 Pipeline 的灵活性和创新性还给开发团队，这比一个模板化的统一 Pipeline 有哪些优势？

A：Pipeline 的运行模式，采用单一 Job 和每个项目自定义 Job，各有不同的应用场景。因为我们的 Jenkins 是隐于幕后的组件，研发主要基于 Prism4k 操作，可以相对减少研发的学习成本。相对来说，Jenkins 的维护人力也会减少。对于研发各种权限比较高的公司，那统一的 Job 可能并不合适。

Q：想了解下贵公司使用什么网络方案？Pod 的网络访问权限控制怎么实现的？

A：公司现在用的是 Flannel 网络 CNI 方案。同时，在不同的集群，也有作 Calico 网络方案的对比测试。Pod 的网络权限，这块暂时没有，只是尝试 Istio 的可行性研究。

Q：一个 Job 生成所有的 Docker 镜像，如果构建遇到问题，怎么去追踪这些记录？

A：在项目前期接入时，生成镜像的流程都作了宣传和推广。标准化的流程，会减少产生问题的机率。如果在构建中遇到问题，Prism4k 的界面中，会直接有链接到本次建的次序号。点击链接，可直接定位到 Console 输出。

Q：遇到节点 Node 上出现 100+Pod，Node 会卡住，贵公司 Pod 资源怎么做限制的？

A：我们的业务 Pod 资源，都作了 limit 和 request 限制。如果出现有卡住的情况，现行的方案是基于项目作拆分。Prism4k 本身对多环境和多集群都是支持的。

Q：多环境下，集中化的配置管理方案，你们选用的是哪个，或是自研的？

A：我们现在正在研发的 Prism4k，前提就是要支持多环境多集群的部署，本身的功能里，yaml 文件的配置管理，都是其内置功能。

Q：etcd 的 –initial-cluster-state 选项设置为 new，重启 etcd 后会不会创建新的 etcd 集群？还是加入原有的 etcd 集群？

A：我们测试过轮流将服务器（3Master）完全重启，ectd 集群的功能均未受影响。但全部关机重启，还未测试过。所以不好意思，这个问题，我暂时没有考虑过。

Q：网络方案用的什么？在选型的时候有没有对比？

A：目前主要应用的还是 Flannel 方案，今年春节以来，还测试过 Flannel、Caclico、kube-router 方案。因为我们的集群有可能越机房，而涉及到 BGP 协议时，节点无法加入，所以一直选用了 Flannel。

Q：部署的动态过程是在 Jenkins 的 Web 界面上看还是在自研的 Prism4k 上能看到，如果是 Prism4k 的话，整个可视化过程的展示这些等等也是自己开发的吗？Prism4k 是用什么语言开发的，Python 吗？

A：部署的动态过程，是在 Prism4k 上显示。可视化方案，也只是简单的使用 ajax 及 websocket。Prism4k 后端是基于 Django2.0 以上开发，其中使用了 RESTfulframework、channels 等库，前端使用了一些 js 插件。

---

2019-04-30：荔枝运维平台容器化实践

Q：容器的 Pod 网络和外部网络全部打通吗，如何实现的？

A：因为 kube-router 是基于三层路由，所以只要在顶层交换上指定 PodIP 的静态路由即可，比如宿主机是 192.168.0.1，该宿主机上的 pod iprange 是 10.0.0.1/24，那只要在交换机或需要访问 Pod 的外部主机上添加路由 10.0.0.1/24 via 192.168.0.1 …即可。

Q：你们如何去保证 io 的隔离？

A：目前网络和硬盘的 io 没有做隔离，暂时还没有这方面的刚需。kube-router 对网络 IO 这方面控制比较弱。硬盘 IO 方面 Docker 支持 IOPS 控制，但 Kubernetes 我还不太清楚是否支持。

Q：Job 和 dind 如何配合去实现打包镜像的呢？

A：首先是 dind 技术，通过挂载宿主机的 docker client 和 dockersock，可以实现在容器内调用宿主机的 Docker 来做一些事情，这里我们主要就用于 build。Kubernetes 的 Job 则是用于执行这个构建 worker 的方式，利用 Kubernetes 的 Job 来调度构建任务，充分利用测试集群的空闲资源。

Q：从宿主机部署直接跨步到 Kubernetes 部署，不仅需要强力的 power 来推动，在落地实施的过程中，应该也会经历应用架构上的调整，能阐述你们在这方面遇到的困难和解决方式吗？

A：Pod 网络是最大的痛点，解决方式如文中所说。架构方面我们很早就是微服务去中心化的部署，API 网关，服务注册发现等也是在容器化之前就已经完成改造的，所以应用架构反倒是没遇到多大的难题。

Q：你们 Kubernetes 里面统一配置是用的 ConfigMap 还是集成了第三方工具，例如 Disconf。你们在 Kubernetes 中，APM 用的是什么呢？Pinpoint 还是 Sky 还是 Jeager？还是其他？

A：过去的项目配置文件是放运维平台上的，所以只要 ConfigMap 挂进去就可以了。后来新的项目开始采用携程的 Apollo，Kubernetes 上就只要通过 ENV 把 Apollo 的一些相关敏感信息传给 Pod 即可。APM 方面因为我们是 Java 栈所以使用的 skywalking，也是开篇提到的 Javaagent 技术。

Q：镜像仓库为什么选用 Harbor，选型上有什么考虑？

A：Harbor 主要有 UI 方便管理，相对来说也容易部署和使用，尤其是权限管理这方面。

Q：Macvlan 和 IPvlan 性能非常好，几乎没有损耗，但默认都是容器和宿主机网络隔离的，但是也有解决方案，你们这边是没有考虑还是使用了一些解决方案发现有问题又放弃的？如果是后者，有什么问题让你们选择放弃？

A：Macvlan 之类的方式需要交换机层面上做一些配置打通 VLAN，并且性能上并不会比基于三层的解决方案要高非常多，权衡之下我们还是选择比较易用的基于三层的方案，甚至为了易用而选择了更为激进的 kube-router。

Q：容器的多行日志收集如何解决？或者是，很多业务日志需要上下文关系，但是 ELK 只能查询到单条，这种情况怎么处理呢？

A：容器多行日志的问题只存在于标准输出里，我们应用的日志是输出到指定目录下的，Filebeat 有一些通用的多行日志解决方案。因为日志是存放在 ES 里的，所以可以通过调 ES 接口拿到某个 Pod 一个时间段里的日志，在 UI 上把它展示出来即可。

Q：请问用的存储是什么？如何集成的？存储架构是怎样的？有考虑过 Ceph 吗？

A：只有极少部分项目需要接分布式存储，并且对存储的管理，IOPS 限制等没有硬性要求，所以我们把已有的 MFS 集群挂载到宿主机，再挂到容器里来实现。

Q：Jenkins 的 Slave 是用 PodTemplate 创建的吗？Slave 是 Job 共享还是需要时自动创建？

A：Jenkins 还是传统的 master-slave 单机部署模式，因为版本比较旧连 KubernetesSlave 都不支持，所以我们只是调用了 Jenkins 的 API 来完成这个部署的过程。

Q：Kubernetes 在做存储挂载的时候，怎么保证容器漂移依然可以读取到共享存储？

A：MFS 挂载的话，文件是写入到 MFS 集群中的，那么挂载同样的 MFS 即可读到同一个文件。

Q：关于命名空间，这边有哪些应用场景呢？

A：按部门和场景区分 ns，按 ns 分配节点和资源。未来打算基于 ns 做网络上的隔离和控制。

Q：请问镜像大小是否有做优化？生产中有用 alpine 之类的 base 镜像吗？

A：暂时没有，我们镜像的大小大约在 100-300M 之间。而且比起镜像大小的优化，运行环境的稳定和调试的便利更为重要。镜像有分层的策略，即使是很大的镜像，只要每次版本部署时更新的是最底层的镜像就不会导致每次都要拉取完整镜像。

---

2019-04-24：华尔街见闻 Istio 生产实践

Q：学 Service Mesh 什么用？

A：ServiceMesh 是最近比较火的一个概念，和微服务、Kubernetes 有密切关系。出于以后业务发展需要，可以学习下，增加知识储备。见闻上 Istio 的主要目的在文章已说明，主要是基础服务的下沉，解决了语言兼容性问题，还有一个就是灰度发布。

Q：链路追踪的采集方式是怎样的，比如 Nodejs，C++ 等多语言如何支持的？

A：Envoy 本身支持链路追踪，也就是将 Envoy 会在请求 head 中增加链路追踪相关的数据头，比如 x-b3-traceid，x-b3-spanid 等等。业务要做的就是将这些 head 沿着调用链路传递下去即可。所以多语言的话需要在自己的业务侧实现该逻辑。所以 Istio 的链路追踪对业务代码还是有很小的侵入性的（这个分享中有说明）。

Q：Istio 与 Spring Cloud 两者的优缺点与今后的发展趋势会是怎么样？

A：见闻技术栈是 Golang，所以没太认真对比过两者。从社区活跃度上将，Istio ，Spring Cloud，稳定性方面，Spring Cloud 是更有优势，更适合 Java 沉淀较深的企业。但个人感觉对于更多企业来讲，跨越了语言兼容性的 Istio 未来发展很值得期待。

Q：Docker 镜像部署可以做到代码保护吗，比如像 Nodejs 这种非二进制执行程序的项目？

A：代码保护可以通过将镜像上传至指定云服务商上的镜像仓库中，见闻是将自己的业务镜像提交保存在了腾讯云。如果镜像泄露，那么非二进制执行程序的代码还是有泄露风险的。

Q：选型时为什么没考虑 Linkerd？

A：选型之初也调研了 Linkerd，对比下来，Istio 拥有更多活跃的开源贡献者，迭代速度快，以及 Istio 架构相较于见闻有较大可行性，所以选择了 Istio 作为实践方案。

Q：Istio 在做运维部署时没有 UI 工具，你们如何实现运维人员更加便捷地使用？

A：见闻基于 Kubernetes 官方的 Dashboard，对内容进行了扩充，增加了对 Gateway，VirtualService 等 Istio crd 资源的支持，同时增加了灰度部署等和见闻运维业务相关的功能，所以一定程度上解决了运维部署的问题。

Q：流量从 Sidecar 代理势必会对请求响应时间有影响，这个有没有更详细案例的说明性能上的损耗情况？

A：Sidecar 的转发其实带来了性能一定的性能损耗。4 核 8G 服务器，上面运行 Proxy 服务和 API 服务，API 服务只返回 ok 字样。（此测试只测试极限 QPS）单独测试 API 服务的 QPS 在 59k+，平均延时在 1.68ms，CPU 占用 4 核。通过代理访问的 QPS6.8k+，平均延时 14.97ms，代理 CPU 占用 2 核，API 服务 CPU 占用 2 核。CPU 消耗以及转发消耗降低了 QPS，增加了延时，通过增加机器核数并增加服务部署数量缓解该问题，经过测试环境测试，延时可以接受。

Q：Sidecar 在生产中资源占用为多少？是否会对集群资源占用很多？

A：以单个 Pod 为例，见闻业务单个 Pod 中 Sidecar 所占资源约占整个 Pod 所耗资源的 1/10。

Q：Jeager 你们是进行了代码埋点吗？更为底层代码级别的追踪，有用其他方案吗？

A：Envoy 本身对 tracing 有良好的支持，所以业务端所做的改动只需将其所产生的追踪数据延续下去即可。上 Istio 之前，见闻在相关微服务中通过在基础库中增加链路追踪逻辑（Zipkin）实现了链路追踪，不过只做了 Golang 版，多语言兼容开发运维难度较大。

Q：相信咱们的 mixer 在生产环境中，也出现过瓶颈，咱们从哪几个大方向优化的？如何优化的？方面讲解一下吗？

A：mixer 见闻在生产过程中所遇的坑在于 Policy 组件， 会疯狂的 listpod，导致 API server 负载骤增，之后见闻基于自身业务关闭了 Policy。

Q：Istio 组件实现了高可用么？

A：Istio 本身也是基于 Kubernetes，所以可用性还是有较好保证的。

---

2019-04-17：瓜子云平台的实践经验

Q：请问瓜子私有云是一朵独立的云还是多云部署？如果是多云部署，云间网络是采用的什么技术？如何打通多云之间的网络的？谢谢

A：我们在设计之初就考虑多集群 / 多 IDC 部署的，这也是选择 Calico 的一个原因。通过 BGP 协议将容器 IP 广播出去后，云间互联和普通虚拟机互联没有区别，当然这需要网络设备支持。

Q：云平台在 PaaS 层，采用的编排工具是什么，如何打通容器之间的部署，在容器的架构上是怎么实现负载均衡的？

A：采用的是 Kubernetes，打通使用的是 Calico，负载均衡使用的是 IstioIngress。

Q：新版本实例发布的时候怎么切 Istio 才能保障灰度的流量不丢失呢？

A：在流程发布里面，我们相当于先新建一组新的实例，在它们的 Readiness 检查通过后，切换 Istio 规则指向新实例做到的。

Q：稳定性方面有没有出现过比较大的问题，怎么解决的？

A：有两个时期稳定性故障较多，一个是 Istio 版本比较低的时候，这个只能说一路趟坑趟过来，我们甚至自己改过 Istio 代码，现在的版本已经没出过问题了；一个是集群用的太狠，当集群接近满载时，Kubernetes 会出现很多连锁问题，这个主要是靠监控来做及时扩容。

Q：自建机房的话为什么不接着使用 Macvlan + IPAM 方案呢？是为了之后上公有云做准备吗？

A：当时面临一个本机 Macvlan 容器互相不通的问题，再加上有熟悉的团队已经在生产跑了很久 Calico 了，所以就直接换到了 Calico。

Q：如果服务发现是基于 Dubbo +ZooKeeper，那 Kubernetes 自身的 Service 还有在使用吗？

A：Kubernetes 自己的 Service 我们现在内部管理工具在使用，在 2.x 版本也开始开放给业务使用了（文中截图能看到内部域名）。

Q：请问几秒的时延对一些高效的服务来讲也是不可接受的。咱们有想过通过何种方式去避免灰度的流量损失问题么？

A：还真没遇到过这个需求。我理解如果有一个服务如此关键，那么在整个流量变更环节（从机房入口开始）到灰度策略上都得仔细考虑。如果接受不了 Istio 这个延时，一个思路是完全抛弃 IstioIngress，直接使用一个切换迅速的负载均衡器。因为容器 IP 是直通的，完全可以从集群外直接连进来，只要解决服务发现的问题就行。

Q：应用服务追踪怎么处理的？对接 Istio？

A：语言栈比较多的情况下这是个痛点，目前我们也是在尝试，即使是 Sidecar 也不能完全对业务没侵入。公司内部 Java 技术栈更喜欢 Skywalking 这种完全无侵入的方式。

Q：使用 Istio 时，怎么解决性能损坏问题的？

A：目前还没有启用 Mixer 这些对性能影响比较大的组件，所以目前性能损耗还是比较小的。如果对性能有严格的要求，我们会建议他使用 service name 做直连。

Q：Prometheus 的告警是靠编辑大量的 rule.yml，请问生产中是怎么管理的？规则编辑比较麻烦，怎么解决？Prometheus 是单点，有没有扩容方案？

A：就是靠 Nier 这个组件，将规则抽象成模板，甚至在云平台上面对于简单的规则直接变成了选项。然后模板渲染成规则。我们的 Prometheus 用的官方的联邦集群模式，存储放在了 Ceph 上面。

Q：为什么 Kubernetes 默认的滚动更新不能满足要求？哪里有问题？

A：没办法精细控制灰度粒度，比如部署了 4 个实例，我要求切 10% 的流量灰度，这就做不到了。另外，滚动更新回滚也比较慢。

Q：注册到 ZooKeeper 的 IP 是 Pod IP？ZooKeeper 从外部直接访问 Pod IP 吗？

A：对的，Pod 和 VM 能直通，也就是说一个 Dubbo 服务能同时部署在 VM 和容器里面。

Q：目前支撑的生产应用服务规模和云平台的规模能介绍下？包括一些指标，比如多少应用进行灰度更新耗时？

A：应用规模的话目前超过 1000 了，每个月发布次数超过 10000。灰度更新是用户自行控制整个发布进度的，所以耗时不太有参考意义。

---

2019-04-03：容器环境下的持续集成最佳实践

Q：Kubernetes 上主流的 CI/CD 方案是啥？

A：其实这无关 Kubernetes，从市场占有率来看，前三名分别是 Jenkins、JetBrains TeamCity、CircleCI。来源：

Q：GitLab 自带的 CI 与 Jenkins 和 GitLab 结合的 CI，该如何选择？想知道更深层次的理解。

A：还是要结合自己团队的实际情况做选择。从成熟度来说，肯定是 Jenkins 用户最多，成熟度最高，缺点是侧重 Java，配置相对繁琐。GitLab 自带的 CI 相对简单，可以用 yaml，和 GitLab 结合的最好，但功能肯定没有 Jenkins 全面。如果是小团队新项目，GitLab CI 又已经可以满足需求的话，并不需要上 Jenkins，如果是较大的团队，又是偏 Java 的，个人更偏向 Jenkins。

Q：Jenkins 如果不想运行在 Kubernetes 里面，该怎么和 Kubernetes 集成？

A：从 CI 的流程来说，CI 应用是不是跑在 Kubernetes 的并不重要，CI 只要能访问代码库，有权限在生产环境发布，是不是跑在容器里从效果来说其实没有区别，只是用 Kubernetes 部署 Jenkins 的话，运维的一致性比较好，运维团队不用额外花时间维护一套物理机的部署方案。

Q：Kubernetes 的回滚方案是回滚代码，重做镜像，还是先切流量，后做修改？

A：代码一定是打包到镜像里的，镜像的版本就是代码的版本，所以一定是切镜像。至于回滚操作本身，Kubernetes 已经内置了很多滚动发布（Rollingupdate）的策略，无论是发新版本还是回滚版本，都可以做到用户无感知。

Q：镜像大到几 G 的话如何更新部署，有什么好的实践呢，以及如何回滚？

A：几个要点：> Q：Drone 开放 API 服务吗？这样方便其他系统集成。

A：可以调整一下思路，直接把需要的功能做成镜像在 Drone 里调用就好了。

Q：如果有 Drone 的 Server 怎么做高可用？

A：Drone serve r 用 Kubernetes 部署的话本身只起到了一个任务调度的作用，很难会遇到性能瓶颈。真的有性能问题可以尝试水平扩展 Drone server，共享同一数据库。

---

2019-03-28：基于 OVN 的 Kubernetes 网络架构解析

Q：OVS 方案与基于三层交换机方案对比，各有什么优缺点？

A：OVS 最大的优点在于可编程，灵活性比较好。虚拟网络不用手动插网线，而且有 OpenFlow 加持，可以实现一些普通交换机无法实现的流量控制。物理交换机的主要有点就是性能好，而且比较稳定，不容易出问题。

Q：OVN 不支持 ECMP，貌似现在还是 active-standby 机制，你们怎么解决 Gateway 瓶颈问题？

A：有几种方式：1. Gateway 用 DPDK 这样的高速 DataPath；2. 多 Gateway，用策略路不同的 IP 段走不同 Gateway，可以分担流量；3. 不使用 OVN 概念的 Gateway，自己做一些手脚从每台宿主机直接出去，也是分担流量降低单点的风险。

Q：OVN-Kubernetes 好像只支持每个部署节点一个虚拟网络网段。如何避免 IP 池浪费和不均衡？

A：这个其实是这个项目实现的网络模型的一个局限性。在我们的实现里是以 namespace 为粒度划分子网，可以对每个 namespace 进行控制，情况会好很多。

Q：OVN 如果有不同的 Chassis，但是相同 IP 就会造成网络异常（比如物理机，VM 装上 OVN，注册到远端后，被重建，后面又注册到远端，但是 Chassis 已经改变），会导致大量节点 Geneve 网络异常。你们怎么解决这个问题？

A：暂时没碰到这个问题，但是我们在实现的一个原则就是尽可能保证所有的操作都是幂等的。向这种可能需要在重连前做一个检查，判断是否有过期的数据需要清理，再连接，或者复用旧的连接信息去连接。

Q：如何 debug OVN 逻辑拓扑是否配置有问题？

A：目前 debug 确实很多情况只能靠眼看，也可以使用 ovn-trace 这个工具可以打印数据包在逻辑流里的链路来排查。

Q：OVS 跟 Calico 等有啥区别？

A：Calico 主要依赖 Linux 的路由功能做网络打通，OVS 是在软件交换机层面实现网络打通，并提供了更丰富的网络功能。

Q：OVS 的封包支持有 STT 和 Geneve，你们选用哪种，为什么？

A：其实还支持 VXLAN，我们选的 Geneve。原因比较简单，Geneve 是第一个 OVN 支持的封包协议，而且看了一些评测，据说在搞内核开启 UDP Checksum 的情况下性能会比 VXLAN 要好一些。

Q：OVS 如何实现固定容器 IP？

A：这个其实 OVS 有对应的设置可以给每个端口设定 IP 和 MACE，这样网卡启动时配置相同的信息就可以了，难点其实是如何控制 OVN 来分配 IP，感觉这个话题可以再开一场分享来讨论了。

Q：可以简单介绍下你们准备开源的网络功能吗？

A：每个 namespace 和一个 logical_switch 绑定，支持子网分配，支持固定 IP，支持 QoS，支持 NetworkPolicy，内置的 LB，内置的 DNS，大致就是把 OVN 的概念映射到 Kubernetes。

Q：想了解一下，如果采用 OVN，是不是意味着使用 OpenStack 平台和 Kubernetes 网络可以直接互通？完成业务在虚拟机和 Pod 之间的全新负载方式？

A：是这样的，如果涉及的合理可以做到容器和 VM 使用同一个底层网络基础设施，VM 和容器之间可以 IP 直达，所有的 ACL、LB 都是打通的。

Q：直接把 OpenShift OVS 抽出来做 Kubernetes 的网络插件和灵雀云做的这个区别在哪？

A：功能上有很多是相同的，因为底层都是 OVS。如果关注 Roadmap 会发现 OpenShift 之后也会采用 OVS 的模式。从架构的角度来看，现在 openshift-multitenant 的实现很类似 Neutron 之前那一套，各种 Agent，之后会统一到 OVN。另一方面 OpenShift 的网络插件绑定的太死了，所以我们决定还是自己抽出来，顺便能实现我们的一些特殊功能，比如固定 IP，子网共享，以及一些网关控制层面的功能。

Q：请问 Geneve 和 VXLAN 的区别有哪些？

A：Geneve 可以理解为下一代 VXLAN，VXLAN 相对 VLAN 来说头部更长可以支持更多的 VLAN，但是由于是固定长度的封装头，不能任意加控制信息。Geneve 采用变长的封装头，可以加很多自定义的控制信息，方便之后做更复杂的网络管控。

Q：Docker CNM 也支持固定 IP，和你说的固定 IP 是一回事吗？另外，基于 OVS 建立的网络是 CNI 还是 CNM 的呢？

A：基于 CNI，因为我们依赖 Kubernetes 的模型。不过话说回来我很喜欢 Docker CNM 那套模型，比 CNI 要实用很多。固定 IP 其实只是个功能，各种模型下都可以实现，效果就是可以给 Pod 指定 IP 启动，Workload 下的多个 Pod 实用的是一组固定的地址。

Q：目前你们对企业的解决方案里会默认采用这种网络模式么？

A：这个方案是我们这几年需求和碰到坑的一个积累吧，现在还不会直接给企业用，我们还需要一些功能的开发和测试，但是之后 Overlay 的场景这个肯定是主推了，主要是取代原来的 Flannel VXLAN 网络。

Q：你了解 Contiv 网络方案吗，和贵公司的实现有哪些区别？

A：Contiv 是思科做的，也是 OVS 实现的，不过它的实现比较早，自己手动实现了整个控制平面，可以认为自己写了个跟 OVN 类似的东西来控制 OVS。不过看它最近已经很少更新了。用 OVN 能用很少的代码就实现基本相同的功能。Contiv 有个比较独特的功能就是支持 BGP 的网络间通信，这个是 OVN 暂时不支持的。

---

2019-03-21：小团队微服务落地实践

Q：服务治理问题，服务多了，调用方请求服务方，超时或者网络抖动等需要可能需要重试，客户端等不及了怎么办？比如 A-> B-> C，等待超时时间都是 6s，因为 C 服务不稳定，B 做了重试，那么增加了 A 访问 B 的时长，导致连锁反应？

A：服务发现有两种，一种是客户端发现，一种是服务端发现。如果是客户端发现的话，客户端需要设置超时时间，如果超时客户端需要自己重试，此时如果是轮询应该可以调用到正常的服务提供方。Spring Coud 的 Ribbon 就是对这一流程做了封装。至于连锁反应的问题，需要有降级熔断，配置 Hystrix 相关参数并实现 fallback 方法。看源码能够发现 hystrixTimeout 要大于 ribbonTimeout，即 Hystrix 熔断了以后就不会重试了，防止雪崩。

Q：JVM 如何 export，是多 container 吗，监控数据，搜刮到 Prometheus？

A：JVM 的用的是 Prometheus 埋点，Java 里面的路径是/actuator/prometheus，在 yaml 里面定义 prometheus.io/path:/actuator/prometheu prometheus.io/port:’8090’ prometheus.io/scrape:'true'，再在 Prometheus 里面进行相应的配置，就可以去搜刮到这些暴露的指标。

Q：Kubernetes 和 OpenShift 哪个更适合微服务的使用？

A：OpenShift 是 Kubernetes 的下游产品，是 Kubernetes 企业级的封装，都是一样的。OpenShift 封装有功能更强大的监控管理工具，并且拥有 Kubernetes 不太好做的权限管理系统。

Q：可以介绍一下你们在优化镜像体积上面做了哪些工作吗？

A：RUN 命令写在一行上，产生的临时文件再删掉。只安装必须要的包。JDK 和 Node.Js 都有 slim 镜像，一般都是以那个为基础镜像去做。

Q：数据库是否真的适合最容器化？

A：我们生产数据库用的是 RDS，开发测试环境用的是 Docker Compose 起的。从理论上，数据库最好做容器化，模块的独立性高，需要考虑好的是数据库容器的数据永久化存储。

Q：为什么选择了 OpenShift？

A：因为 OpenShift 有个很方便的 UI，大多数都可以在 UI 里面操作，包括 yaml 文件的修改，重新部署回退等操作。对于开发测试来讲，学习的成本比较低，不需要花时间熟悉 CLI 操作。

Q：Python 基础镜像怎么制作最好，如果加入 GCC，C++ 等编译需要的工具，镜像会特别大？

A：Python 基础镜像直接从 Python 官方 Docker 镜像上做就行了。GCC，C++ 那个做出来的镜像大也没办法。如果没这个需求的话，可以用 Python slim 镜像去做。

Q：在 Gateway 中 Ribbon 如何根据客户端的 IP 负载到对应的 IP 注册的服务？

A：如果使用了 Eureka 的话，服务提供方启动时会自注册到 Eureka。服务调用方发起请求前会从 Eureka 上读取提供方的列表，再进行负载均衡定位到具体的 IP 和 Port。如果跟我们一样直接使用 Kubernetes 的 Service，其实就是由 Kubernetes 控制了，服务调用方访问 Kubernetes 暴露的 Service，然后由 Kubernetes 负载均衡到这个 Service 背后的具体的 Pod。

Q：如何实现远程发布、打包？

A：Jenkins 打包镜像发布到 Harbor 上，Jenkins 再调用 OpenShift 去从 Harbor 上拉取镜像，重新 tag 一下就可以实现发布。

Q：譬如客户端 IP 是 10，希望 Gateway 负载到 10 注册的 order 服务，而不是其他 IP 注册的 order 服务，希望开发使用集中的 Eureka 和 Gateway？

A：是说不需要负载均衡？最简单的可以看下 Ribbon 的实现，负载均衡算法可以自己定义，如果只是要固定 IP 的话，那么遍历服务列表再判断就可以了。两次判断，if serviceId=order，if ip = 10。

Q：Docker 管理工具一般用什么？

A：Kubernetes，简称 k8s 是目前较热门的 Docker 管理工具。离线安装 Kubernetes 比较繁琐，有两款比较好的自动化部署工具，Ubuntu 系统的 Juju 和 Red Hat 系统的 OpenShift，OpenShift 又称为企业版的 Kubernetes，有收费的企业版和免费版。

Q：Prometheus 是每个集群部署一套吗？存储是怎么处理？存本地还是？

A：每个集群部署一套，存储暂时存在本地，没有用持久化存储。因为现在环境都是在云上面，本身云厂商就有各种的监控数据，所以 Prometheus 的监控数据也只是做个辅助作用。

---

2019-02-28：骞云科技 DevOps 实践

Q：CMP 和各个云平台打通都使用了平台的 jar，并且需要各种资源生成，这个工作量也不小吧？并且如果 api 更新代码量也大吧？

A：我们的核心业务就是做云管理平台，我们产品已经完成了对各个云平台的对接，主要调用各个云平台的 API。公有云的 API 更新频率并不是很高，每当 API 有更新时，我们也及时去适配。

Q：Jenkins 初次提交也能触发构建吗？每次自动化构建版本号是如何更新的呢？

A：我们的项目代码具备构建条件后，才在 Jenkins 上创建了项目构建 Job，所以并没有在初次提交时触发构建。每次构建的版本号由两部分组成，一部分是产品的 Release 大版本号，另一部分直接使用的 Jenkins build number 这个环境变量。

Q：有了 Gerrit，为什么还要 GitLab，Gerrit 也可以托管代码啊？

A：这个是有历史背景的，我们是先选择使用 GitLab 做代码托管，后期才加入 Gerrit 做 code review。Gerrit 在代码 review 方面比 GitLab 的 merge request 要方便许多，更适合企业内部使用。关于这个，我的想法是，要么将 GitLab 迁移到 Gerrit，要么不用 Gerrit，可以使用 GitLab 的 merge request 来进行 review，那 GitLab 其实是可以不要的。

---

2019-02-22：房多多 Service Mesh 实践

Q：容器和微服务的区别以及它们的关联性、应用场景、客户群体、带来的价值？

A：微服务的应用场景主要是解决降低单个服务体积，满足业务的快速开发需求。容器可以说是微服务的载体，容器方面还是运维关注的比较多，带来的标准化流程和环境的提升对整个研发团队都有很大的作用。

Q：软件实现 Service Mesh，Istio？

A：我们目前只使用了 Envoy，Istio 也做过一些选型的调研，不是很符合我们现在的业务场景和业务需求，我们在之后的实践中会考虑使用一部分 Istio 的功能。

Q：实施过程当中有使用到 Istio 吗？有定制一些 Mixer 适配器吗？

A：目前还没有用，之后会考虑是用 Istio 中的 pilot，我们目前在流量的控制的精细程度上面还欠缺，粒度还很粗。

Q：请问，实现微服务过程中有没有考虑分布式跟踪和分布式？

A：Service Mesh 层可以做到简单的分布式追踪，比如可以做到基于请求的追踪，Envoy 可以把 trace 数据接入 Zipkin 这样的 trace 系统，但是更细粒度的 trace 目前还做不到。

Q：不论是使用都会产生大量的配置（yaml），尤其是 Envoy/Istio，系统中会有大量零散的配置文件，维护困难，还有版本管理，有什么很好的维护实践经验吗？谢谢。

A：是的，据我所知有些团队会使用 ConfigMap 来管理配置，我们做了一个配置的集中管理服务，从 CMDB 和 DNS 定时的抓取数据，数据会存在数据库里面，也会存一定量的副本用于配置回退，这个地方还是要结合你们现在其他配套系统的建设来看看怎么做比较好的。

Q：有没有遇到过 Envoy 被 oom kill 的情况，你们是如何处理的？

A：这个我有碰到过一次，之前我们在对 Envoy 做测试的时候，发现 Envoy 总会尽可能的占满 CGroup 的内存大小，这个之前在使用 TLS 的情况下碰到的比较多。但是目前我们内部服务间使用 TLS 的情况并不多，所以后续这个问题就没有继续跟进了。

Q：性化方案有哪些？

A：之前文章中有提到过，对于 http 服务可以全量接入 http2，http2 的长连接和多路复用对于一般的业务来说升是很明显的，我们在全量接入 http2 之后，网站的响应时间几乎下降了 50%。另外还可以在底层的依赖上面做一些优化，比如底层的 libc 库，以及尽可能的减少基础镜像的大小，我们基本上所有业务都使用了 alpine，这样可以保证发布性能和速度在一个很好的水平上。

Q：还是有一个服务治理/配置管理的问题请教，比如 CPU，内存，这种资源 request，在 dev，test，staging，prod 环境均不同，那么我们在编写 Kubernetes 配置的时候不同环境会不同，比如测试环境的 replics 数跟 CPU 需求就很低，生产就很高，另外这个配置在不同环境是多个还是一个呢？谢谢。

A：我们现在会在 CMDB 里面维护这些配置数据，一般来说在新建项目的时候，我们就会要求业务线评估一下这个业务需要的资源，比如你说到的 test 和 staging 环境这种，我们默认会给一个很低的需求，比如 1c1g 这样的，而且 replication 也会默认设置为 1，除非业务有特殊的需求，然后我们去根据配置的数据去生成 yaml 格式为配置。

Q：你们目前的项目中，大量的微服务，以及调度层，瓶颈和容灾是如何处理的？

A：由于我们的业务类型还是 B 端业务为主，流量的峰值是可以预估的，很少会出现突发的大流量的情况，我们一般都预留了 1 倍的容量用于临时的扩容。容灾和调度的话我们主要还是尽可能的隔离工作节点和调度节点，以及大量使用物理机集群，从我们的使用体验上来看，物理机的稳定性还是很不错的。

Q：如何用 Jenkins 自动完成 Kubernetes 部署？

A：自动部署这块我们有完善的发布系统，如果单纯只要实现 Jenkins 自动完成 Kubernetes 的话，Jenkins 可以直接调用 Kubernetes 的 API，这个网上有挺多资料的，你可以找找看。

Q：Service Mesh 比传统的微服务治理好在哪里？

A：降低框架开发成本、代理规则灵活，方便修改策略、框架功能的升级无需依赖业务，最大的好处我觉得就是可以降低框架开发成本。

Q：我理解房多多目前的 Mesh 方案没有给每个微服务配一个 Envoy 作为 Sidecar，而是使用一组 Enovy 并自研了 xDS 的配置发布管理系统，对吗？我想请问 backend 微服务之间的请求现在是怎么走的呢？谢谢。

A：是的，刚刚文章中说了，我们后端 SOA 服务还是基于 Dubbo 的，这块目前我们还没有做改动，之后的话我们的初步构想会通过 Sidecar 的方式把这些 Dubbo 服务都接入到 Mesh 里面来。我们目前的 Envoy 也是会充当网关的角色。

---

2019-01-25：得到 App 的容器及 Kubernetes 实践

Q：业务环境有跨机房么，还是云环境，是共用一个集群还是不同集群呢？

A：个人倾向多集群，上层 Federation Cluster 管理。

Q：代码使用发布是什么的呢 有使用 Helm 么？

A：通过 Kubernetes API Server 更新 Deployment 中 template 的 spc 里的 container image。

Q：单个应用发布一次耗时多长时间？主要耗时是在哪个阶段呢？

A：1 分钟内，主要耗时在 Kubernetes Replication Controller 滚动发布过程中的 Pod 状态同步。

Q：开发流程是什么样的，是开发创建镜像还是运维自己创建？谁负责发布到线上环境？

A：创建镜像有两种方式：CI 和开发人员手工操作，线上环境开发提交上线单，QA 审核。

Q：Kubernetes 目前是都在阿里云上面吗？有没有跨云去实现平台的搭建，如果使用混合云对你们最大的挑战？

A：目前还是主要用阿里云，未来会建设混合云，混合云方案还未确定，个人倾向多集群，上层 Federation Cluster 管理，也不排除自研 Controller，混个人认为混合云最大的挑战在于数据的同步，上层的服务容器中运行并且有 Kubernetes 来调度大大减轻了管理负担，我们正在设计多层次的调度：例如流量层调度、服务层调度、数据层调度。

Q：Chon 和 Dozer 是自研的平台吗？网上没有找到相关的介绍。

A：是自研的，可以认为 Dozer 是容器发版系统，Chons 是私有 PaaS。

Q：Overlay 为何不能用在生产环境？你们现在不算生产环境吗？Flannel 不就是 Overlay 吗？

A：Flannel 有高性能的 HOSTGW，在云上的话，还有各种公有云的 backend，借助云的 VPC 网络 API 实现。

Q：为什么大量短链接需要优化 DNS？大量短链接会导致什么问题？

A：Golang 默认编译会关闭 Glibc 中的 dns 查询实现，使用 golang 的实现，对于 DNS 服务有较多查询，会有 dns 查询失败情况。大量短连接一般情况下不会有问题，会增加少量延迟以及服务器上 TCP TIME_WAIT 状态连接数量大。

Q：日志这块使用 emptydir 的话会不会有日志丢弃的情况？

A：没有，logtail 和 filebeat 使用的是 Watch 和 tail 类似的模式，我们统计过，延迟最大在 5 秒。

---

2019-01-16：龙腾出行基于 Kubernetes 的 DevOps 流水线实战

Q：Kubernetes 本身技术框架带来的问题在生产环境中有碰到没，请举几个例子。

A：Kubernetes 如果出问题带来的都是雪崩效应，例如网络 Calico、存储 etcd 出现故障是灾难性的，我们也踩过不少这方面的坑，所以要做到高可用才能稳定生产。

Q：一个开发人员想在开发环境部署一个服务，他必须要懂 Kubernetes，去写那些 yaml 吗，有什么易用的可视化平台？

Q：公司环境较复杂：包含 Java 项目、PHP 项目，Java 项目目前大多是 SpringBoot 框架，PHP 是 ThinkPHP 框架，项目架构并不复杂，有少许 Java 项目需要用 Redis 到 Memcached、缓存机制。最大问题的是多，项目应该如何较好的依托 Kubernetes 顺利架构，将项目可持续集成？

A：我们的 Redis 这一类中间件还放在 VM 上，目前尚未打算搬移到 Kubernetes 上，Kubernetes+Docker 天然是跨平台的，PHP 也可以支持，并且对容器集群（既应用集群）管理非常出色，包含部分自动化运维，并不会因多种开发语言而增加负担，持续集成是另外一块，目前各大 CI 工具厂商也都支持 Kubernetes，比较友好，我们采用的是 GitLab-CI。

Q：Calico 网络你们如何解决跨中心的网络通信，BGP 只能在同一个交换机才行。

A：我们目前还没跨机房通讯，不过 etcd 需要高速网络才能数据同步，跨机房拉专线比较合适，BGP 协议还没用到，小规模部署可以考虑添加静态路由的方式打通 Kubernetes 集群内外的网络。

Q：应用有是否有状虑使用，用的什么存储解决方案？

A：我们提倡无状态部署，目前所有应用服务都是无状态，有状态服务存储可以考虑 NFS。

Q：用二进制安装可以不，Kubeadm 会有升级些问题，默认的 Iptables 不太好吧。现在是 IPVS。

A：二进制也可以，比较稳定，Kubeadm 滚动升级我们还在踩坑中，升级策略目前我们是另外搭集群，一键部署所有应用（每次部署都会统一存储最新部署 yml），对外网关可选择性切换应用，Iptables 被 Kubernetes 捡起来又放弃了，未来的趋势是 IPVS，目前我们也在测试环境中试验。

Q：服务监控和服务器监控这块的取舍，现在监控都是用 Prometheus？

A：Prometheus 是 CNCF 旗下仅次于 Kubernetes 的项目，对应用程序比较友好，做服务监控非常棒，配合 Grafana 图形展示体验非常好，跟 Zabbix 相比各有特色。

Q：请问你们是创业问团队还是大规模团队？考虑 Kubernetes 机缘是？对于 Kubernetes 来说生态所存在的不足，如安全问题是怎么考虑的？

A：不管创业还是大规模团队，适合自己业务，技术可持续演进、完善并提升效率就是好的方向，考虑 Kubernetes 是因为它的优秀功能，让技术团队可以站在更高的起点，看得更远；Kubernetes 生态已经非常强大，在内网运行，相对较为安全，另外也有启用 RBAC 权限访问控制，配合其他持续集成工具，安全控制都可以个性化定制。

Q：Kubernetes 集群你们为什么没有部实体机在署上？

A：虚拟机和实体机都行，我们实体机数量有限，包括中间件那些，做高可用会用占用比较多的 Node 机。

---

2019-01-11：如何评估 Kubernetes 持久化存储方案

Q：你好，我们公司采用 GlusterFS 存储，挂载三块盘，现在遇到高并发写小文件（4KB）吞吐量上不去（5MB/S），请问有什么比较好的监控工具或方法么？谢谢！

A：GlusterFS 本身对小文件就很不友好，GlusterFS 是针对备份场景设计的，不建议用在小文件场景，如果可以的话，要么程序做优化进行小文件合并，要么选用高性能的分布式文件存储，建议看看 Lustre 或者 YRCloudFile。

Q：我们用的是 Ceph 分布式存储，目前有一个场景是客户视频存储，而对于持续的写入小文件存在丢帧的现象，经过我们系统级别和底层文件系统调优，加上 Ceph 参数的设置，勉强性能得改善，但是数据量上来性能会如何也不得而知道了（经过客户裸盘测试，前面用软 RAID 方式性能还是可以）请问在这方面你有什么建议么？谢谢！我们客户是在特殊的场景下，属于特定机型，而且是 5400 的 sata 盘！rbd 块存储！还有一个现象就是磁盘利用率不均，这也是影响性能的一个人原因，即便我们在调 pg 数，也会有这个问题。在额外请教一个问题，bcache 可以用内存做缓存么？FlushCache 相比，这两个哪个会更好一点？

A：您用的是 CephFS 还是 rbdc 因为 Ceph 在性能上缺失做的还不够，有很多队列，导致延迟很不稳定，这个时候，只能忍了，不过还是建议用 Bcache 做一层缓存，可以有效缓解性能问题。Crush 算法虽然比一致性 hash 要好很多，但是因为没有元数据，还是很难控制磁盘热点问题。FlushCache 已经没有人维护了，Bcache 还有团队在维护，所以如果自己没有能力，就选用 Bcache。

Q：你好，目前开源在用 Rook 部署 Ceph，Ceph 对于块设备存储性能如何？可以提升吗？未来？

A：我们最近也在关注 Rook 项目，Rook 的理念是很好的，但是现在 Rook 就是 Ceph 的封装，把 Ceph 跑到容器中，复用 Kubernetes 的监控平台。而 Ceph 的运维复杂度很高，以目前的做法，项目想要做好，难度会非常大。

Q：我看您推荐分布式文件存储，文件系统能满足数据库应用的需求吗？块存储会不会好一些？

A：首先，我推荐的是高性能分布式文件系统。数据库一般对延迟都比较敏感，普通的万兆网络 +HDD 肯定不行，需要采用 SSD，一般能将延迟稳定在毫秒以内，通常能够满足要求。如果对延迟有特别要求，可以采用 NVMe+ RoCE 的方案，即使在大压力下，延迟也能稳定在 300 微秒以内。

Q：您用的分布式文件存储，不同用户间如何隔离？

A：分布式文件系统有 ACL 权限控制，也可以加 AD/LDAP

Q：请问为什么说块存储不支持 RWX？RWX 就是指多个节点同时挂载同一块块设备并同时读写吗？很多 FC 存储都可以做到。

A：传统的 SAN 要支持 RWX，需要 ALUA 机制，而且这是块级别的多读写，如果要再加上文件系统，是没办法做到的，这需要分布式文件系统来做文件元数据信息同步。

Q：传统 SAN 支持对同一数据块的并行读写，很多 AA 阵列都不是用 ALUA 的，而是多条路径同时有 IO，当然要用到多路径软件。相反用 ALUA 的不是 AA 阵列。

A：AA 阵列解决的是高可用问题，对同一个 lun 的并发读写，需要 trunk 级的锁去保证数据一致性，性能不好。

Q：的很多传统商业存储，包括块存储，也都做了 CSI 相关的插件，是不是如果在容器里跑一些性能要求高的业务，这些商业的块存储比文件存储合适？

A：生产环境中，我强烈建议选用商业存储。至于块存储还是文件存储，要看您的业务场景。首选是商业的文件存储。

Q：请问现在的 Kubernetes 环境下，海量小文件 RWX 场景，有什么相对比较好的开源分布式存储解决方案么？

A：开源的分布式文件存储项目中，没有能解决海量小文件的，我在文中已经将主流开源文件系统都分析了一遍，在设计之初，都是针对备份场景或者 HPC 领域。

Q：请问，为什么说 Ceph 性能不好，有依据吗？

A：直接用数据说话，我们用 NVMe + Ceph +Bluestore 测试出来的，延迟在毫秒级以上，而且很不稳定，我们用 YRCloudFile + NVMe + RoCE，延迟能 50 微秒左右，差了几十倍。

Q：Lustre 没接触过，性能好吗，和 Ceph 有对比过吗？

A：网上有很多 Lustre 的性能指标，在同样的配置下，性能绝对要比 Ceph 好，不过 Lustre 全部都是内核态的，容器场景没办法用，而且按照部署以及运维难度非常大。Lustre 在超算用的比较广泛。

Q：Lustre 只能靠本地磁盘阵列来保证数据冗余么？

A：Lustre 本身不提供冗余机制，都是靠本地阵列的，不过 EC 好像已经在开发计划中了。

Q：（对于小公司）如果不选用商业存储，那么推荐哪款开源实现作为生产存储（可靠，高性能）。我们之前试了 NFS 发现速度不稳定？

A：国内还是有很多创业公司，也不贵的。存储不像其他项目，存储经不起折腾，一定要用稳定可靠的，Ceph/GlusterFS 做了这么久，大家在采购的时候，还是会依托于某家商业公司来做，自己生产环境用开源项目，风险太大了。

Q：GPFS 用来做 Kubernetes 的 PV，性能怎么样？

A：用 GPFS 的话，性能还是有一定保障的，不过 GPFS 跟 Lustre 一样，都是带着阵列一起卖的，很贵。

---

2019-01-04：etcd 集群运维实践

Q：请问 etcd 监控和告警如何做的？告警项都有哪些？

A：告警要看用的什么监控吧，和 Kubernetes 配套比较常见的是普罗米修思和 Grafana 了。告警项我没有具体配过，可以关注的点是：endpoint status -w table 里可以看到数据量，endpoints health 看到健康状态，还有内存使用这些，具体可以参考普罗米修思的 exporter 是怎么做的。

Q：使用 Kubeadm 部署高可用集群是不是相当于先部署三个独立的单点 Master，最后靠 etcd 添加节点操作把数据打通？

A：不是，Kubeadm 部署会在最开始就先建一个 etcd 集群，apiserver 启动之前就需要准备好 etcd，否则 apiserver 起不了，集群之间就没法通信。可以尝试手动搭一下集群，不用 Kubeadm，一个个把组件开起来，之后对 Kubernetes 的组件关系会理解更好的。

Q：etcd 跨机房高可用如何保证呢？管理 etcd 有好的 UI 工具推荐么？

A：etcd 对时间和网络要求很高，所以跨机房的网络不好的话性能很差，光在那边选请输入链接描述举去了。我分享忘了提一个 etcd 的 mirror，可以去参考下做法。跨机房的话，我觉得高速网络是个前提吧，不过还没做过。UI 工具没找过，都是命令行操作来着。

Q：Kubeadm 启动的集群内 etcd 节 点，kubectl 操作 etcd 的备份恢复有尝试过吗？

A：没有用 kubectl 去处理过 etcd 的备份恢复。etcd 的恢复依赖用 SnapDb 生成数据目录，把 etcd 进程丢进容器里，类似的操作避免不了，还有启动的状态需要修改。kubeadm 启动的 etcd 可以通过 kubectl 查询和 exec，但是数据操作应该不可以，比如恢复 etcd ing 时，无法连接 etcd，kubectl 还怎么工作？

Q：kubeadm-ha 启动 3 个 Master，有 3 个 etcd 节点，怎么跟集群外的 3 个 etcd 做集群，做成 3 Master 6 etcd？

A：可以参考文档里的扩容部分，只要保证 etcd 的参数正确，即使一个集群一部分容器化，一部分宿主机，都是可以的（当然不建议这么做）。可以先用 kubeadm 搭一个集群，然后用扩容的方式把其他三个节点加进来，或者在 kubeadm 操作之前，先搭一个 etcd 集群。然后 kubeadm 调用它就可以。

Q：有没有试过 Kubeadm 的滚动升级，etcd 版本变更，各 Master 机分别重启，数据同步是否有异常等等？

A：做过。Kubeadm 的滚动升级公司内部有从 1.7 一步步升级到 1.11、1.12 的文档，或多或少有一点小坑，不过今天主题是 etcd 所以没提这部分。各个 Master 分别重启后数据的一致我们测试时没问题，还有比较极端的是直接把三 Master 停机一天，再启动后也能恢复。

---

2018-12-21：聚美优品云平台实践

Q：为啥采用 Consul 作为容器的服务发现与配置管理，而不采用默认的 etcd？

A：这个问题主要是聚美对于 Web 类服务已经存在了基于 Consul 的发现机制，所以云平台在推广时就利用了现有的架构。

Q：请问 IPVLAN 网络会不会导致容器内无法访问本地物理网卡？或者说宿主机无法访问本地的容器？

A：这个问题很好，最初我们采用 IPVLAN 时也遇到了 kubelet 在通过 Liveness 探针时与容器网络不通。后来我们通过将主机网络和容器网络分开，解决了这个问题。

Q：服务间的 Socket 通讯原理是通过挂载 Volume 方式进行访问，这个/var/run/service 内容能透露一下吗？是聚美优品的 RPC 框架通信协议文件吗？

A：/var/run/service 其实就是一个临时目录，里面就保存了 Pod 的各个 Container 中运行进程的 Sockets 文件。至于服务间（不同 Pod 间）通讯是聚美这边自己实现的一个私有的 RPC 框架通信协议。

Q：问一下，你那边的不同业务分配资源的时候是每个节点都打上 labels 吗？

A：是的，我们主要还是通过 label 的的形式来做容器的调度。另外每个 deployment 都会通过 resourcelimit 来做资源限制。目前对于高资源利用的容器还是通过平台 kill 容器的方式，重新拉起新的容器。

Q：Prometheus 是什么运行方式，拉取数据会有什么问题注意吗，单节点够用吗？

A：目前我们 Prometheus 是部署在 Kubernetes 当中，根据不通过的服务发现模式做了逻辑切分。上层通过 Prometheus Federation 来统一汇聚数据。

Q：那不同的业务之间访问有状态应用是通过定义 ExternalName 吗？比如访问 MySQL 或 Redis 等？

A：目前我们大部分跑在云平台上的容器都是无状态的服务，对于有状态的服务，还是建议通过传统的方式运行。

Q：请问你那边 Pod 是直接跑在虚拟机上吗，还是做了一层虚拟化分配使用虚拟机呢？

A：Pod 的运行主要分两块类型。对于 DaemonSet 方式运行的容器，我们大都通过虚拟机或者云主机来支撑，分享里面也提到我们通过 DaemonSet 方式来解决我们大促期间快速扩容的需求

Q：Pod 跨节点的访问是怎么做到的，如果两个节点不在同一个 swtich 下，需要跨路由器的情况下？

A：IPVLAN 的网络是提前规划好的，并保存在网络配置管理平台上。对于 IPVLAN 不同网段的之间的通信，还是在三层交换机上做路由来实现的。

---

2018-12-07：智融集团基于 OpenShift 的容器化 PaaS 平台实践

Q：请问通过 OpenShift 怎么做高可用？

A：OpenShift 的高可用是跟 Kubernetes 的高可用一致的，就是延用了 Kubernetes 的 Service IP 来做服务发现和负载均衡；另外，前面还有 DNS 服务，（例如：Hostname: service.abc-platform.svc，后端就是指向的 Cluster IP）。

Q：image 的版本管理怎么做？配置的版本管理怎么做？

A：OpenShift 本身会创建一个内部的 Registry，S2I 会根据 Build 来更新 image，image 的版本是通过 sha256 的值对应 Build 的版本号（例如：Build 版本#24 对应 registry.intra.XXXXX.com/abc/abc-platform@sha256:b41c8XXXXX）。

Q：OpenShift 的网络方案性能方面有多少损耗？与 Kubernetes 的其他网络方案如 Calico 相比如何？

A：OpenShift 的网络方案是选择的 OVS，性能上肯定是不如 Calico，但对于我们的服务足够了。目前跑了有 1000+ 个常驻 Pod，没有出现网络瓶颈。

Q：如果要做多机房部署，OpenShift 能搞吗？

A：多机房，只要网络能通并比较稳定，是没有问题的。我们的部署方案就是在阿里云上的多个可用区部署的。而且，实际部署中也是鼓励多机房部署的，服务容灾要求一个服务要分布在多个可用区（或者机房）。

Q：你们平台性能怎么测试的，如何集成？

A：平台性能测试分两部分。一个是在集群内部不经过 Nginx 直接压测 SVC，另外一个是在集群外部压测内网域名或者公网域名。

Q：我们之前用自己的镜像仓库，会报 tls 认证错误，不知道你们有没有遇到过？

A：我们自己创建的镜像仓库是用 Harbor 来建的，只是存储了内部服务的基础镜像。OpenShift 集群内的镜像仓库有自己的认证，是通过 Secrets 管理对应权限的 token（用户级别的权限是通过 LDAP 统一认证的）。S2I 创建服务镜像的时候就是通过这个来获取权限的。还是比较稳定的，没有出现过 tls 的问题。

Q：生产环境的节点磁盘是怎么分区分配的？

A：生产环境的节点磁盘分为两类，一个是系统盘（40G），另一个是数据盘（100G）；Docker 的所有镜像、实例等存储都是放在数据盘，服务的日志是挂载的 PV，PV 是使用的阿里云的 NAS 存储。

Q：我看你们在集群访问前加了个 API Gateway，用了 OpenResty，这个能详细介绍下不？

A：可以简单理解为一个自建的 Ingress，底层是 Nginx+Lua 实现的；我们已经在逐渐使用 Kong 来代替 OpenResty 了。Kong 底层是 Nginx+Lua+PostgreSQL，界面管理是使用的 Konga。选择 Kong 和 Konga 的理由是：1、Kong 的管理和插件比较方便，还支持自定义插件；2、Konga 的界面更友好，管理、更新都比较方面。

Q：看到你们是 3Master 高可用，请问 Kubernetes–Master 挂了一台，OpenShift 如何恢复，etcd 是否有做备份？

A：我们做过演练，Master 挂一台或者两台，甚至三台全挂，也不会影响已经运行的服务。只要 etcd 没有问题，重启 Master 或者新增一台 Master 都可以快速恢复集群。etcd 的备份是做的全量备份，上传到我们的备份存储中。

Q：内网域名是怎么跨 VPC 和经典网络的？

A：内网域名的 DNSPod 解析是解析到 VPC 网络的一台 ECS 机器上，通过 Nginx 来管理。经典网络的 ECS 服务集群可以在前面挂载一个 VPC 网络的 SLB，Nginx 的对应 Server Name 的 Upstream 设为这个 VPC 的 SLB 即可。

Q：监控和告警好像没有提到，感觉 OC 这块似乎缺失？

A：OpenShift 本身有很多服务状态，image 的 Build、pull、push 等状态，以及 Pod 的各种状态；另外还有强大 events。我们是通过 OpenShift 的 API 来获取这些信息，同步到 Open-Falcon 上来处理报警信息的。

Q：日志统一生产、采集用了什么方式能介绍一下吗？

A：日志是一个比较疑难的问题；我们的解决方案是，所有的日志都打到同一个 NaS 盘上，服务名来做该服务的日志路径。多个 Pod 打同一个日志的时候，会出现乱码。我们的解决方案是在日志中间加 hostname，例如 haadeers.melon-crm-b-9-nb9d5.log，melon-crm-b-9-nb9d5 为 Pod 的 hostname。日志收集，是几台 ECS 机器挂载改 NAS 盘，启动 flume 来收集。

Q：业务应用的自动化发布你们是怎么设计的，能否详细说说思路？

A：我们是自己定义了 S2I 的流程。Build 镜像统一在代码仓库里加一个 Makefile，定义一个 assemble 的 role，来做初始化（依赖包的安装、nodejs 的 Build 等等，这里还是比较灵活的）。自动发布：我们是自定义了部署模板，分享的内容里有（只需要简单的几步就可以部署一套服务）。

---

2018-11-29：猪八戒网 DevOps 容器云与流水线

Q：Ingress 是用的那个组建？

A：这里我再详细补充下，我们没有使用到 Ingress Service 这些对象，为了维护与虚拟机项目的统一管理，方便运维使用，我们的 Nginx 是部署在集群外部的，与 nginx-ingress-controller 一样，使用 Lua 扩展自己做服务发现，Nginx 直接向 Pod 转发流量。

Q：Nginx 和 PHP-FPM 采用什么方法部署和更新，Nginx 和 FPM 有分开部署吗？

A：Nginx 部署在集群外部虚拟机里，虚拟机网络与容器内部网络是打通的，直接转发流量给 Pod；PHP 是老项目，有一小部分做了容器化，基于 PHP 基础镜像使用 deployment 部署，PHP 项目是无状态的，跟其他项目一样进行滚动更新；Nginx 与 FPM 是分开部署的。

Q：请问下你们有没有使用 API 网关，自己开发的还是使用 Kubernetes 自带的，用户权限是做在 API 网关吗？

A：目前没有用到 API 网关项目，自己使用 Nginx 做的简单 API 网关，sahaba api 是我们自己开发的 Kubernetes 管理工具，使用 client-go 组件向 Kubernetes API 发起请求调用；用户权限我们对接了 DevOps 权限管理系统，区分超级管理员，运维人员，项目负责人，普通用户等，确定某个用户对某个项目容器 guest 或 admin 权限。

Q：你们的 Kubernetes 管理平台，考虑用 360 开源的 wayne 吗？Qihoo360/wayne 可以满足用户上线需求，也集成了 webshell 之类的，看起来挺不错的。

A：360 的 wayne 项目，我们也关注了，把源码下下来看了一下。我们 DevOps 平台与 wayne 的一大不同之处在于：wayne 给用户的发布是把 Kubernetes 的 deployment 模板放上去了，让用户去填写；我们是用 sahaba-metadata 项目将 deployment 模板抽象出来，只给用户填写 Git 项目分支，以及需要发布的 CPU/内存/节点等，镜像 url，超开策略等数据不需要用户填写，开发人员不需要关心这些。我们也参考了 wayne 的 webshell 实现，跟 kube dashboard 项目一样的，我们也正在基于他们的代码优化我们自己的 webshell。

Q：Prometheus 监控数据是用什么存储的了？采用了什么集群方案？存储没有集群化吗？

A：Helm install CoreOS/kube-prometheus，目前是完全容器化部署的，使用 hostpath 挂载，部署在一个专用节点上，公有云上使用 PVC。目前给了 30G 的内存资源够用，没有集群化部署。

Q：etcd 用哪个版本的，3 节点以上的 etcd 集群崩溃后如何用镜像快速恢复？

A：我们的集群各个版本都有，从 1.4 到 1.11，都是使用当时最新的稳定版部署，具体可以看 Kubernetes release note 里的 dependencies；etcd 集群恢复，只要有一个节点 etcd 的数据在，就可以恢复，先将这个节点 force-new，其他节点 join 进来，数据会自动从 leader 同步到 slave。你提到的使用虚拟机镜像恢复，这个我还没有使用过，我理解的整个云硬盘的数据都可以备份下来，数据恢复也是没问题的，参照公有云数据备份恢复方案。

Q：web terminal 怎么做的，有参考文档吗？

A：web terminal 新版的是参照 kube dashboard 源码，使用 client-go 调用 kubernetes api，spdyexecutor，然后转为 ws 连接实现，最近开源了一个 demo：

Q：etcd 数据备份是怎么做的，Crontab 吗，还是使用 Kubernetes 里的 Job，如何确保备份的数据是没有问题的？

A：因为 etcd 是二进制文件部署的，目前我们是使用 Crontab 定时任务每天备份一次数据，备份的内容包括 etcd snapshot，etcd 的数据目录，同时备份到本地及远程服务器，公有云上还有云硬盘镜像备份，多种备份方案保证数据正常。

Q：日志收集工具是否用了 Fluentd，日志收集到 ES 里，用 Kibana 查询有没有遇到过日志乱序的问题？

A：我们使用的是 Filebeat，将日志收集到 Kafka，再转给 Logtash，Logtash 处理后才转给 ES， Filebeat -> Kafka -> Logstash -> ES -> Kibana，乱序问题我没遇到过，应该可以在 Logstash 处理的时候确认。

Q：可否实现 Kubernetes 上容器与主机通讯？

A：容器与主机通信是可以的，具体可以参见 Calico 的网络方案，使用 calico routereflect 路由反射功能与核心交换机做 bgp peer 进行路由交换，公有云上使用 VPC 网络方案。

Q：Prometheus federation 有使用吗，关于监控性能这块有没有啥好的经验教训？

A：Prometheus 监控这块，我们只优化了每个 Job 抓取的时间间隔，保证 Prometheus Server 的负载不会太高，并给 Prometheus 足够的 CPU 内存以及 SSD 磁盘，查询时优化查询条件。

Q：日志解析具体用的什么？有什么对服务的日志二次解析？**

A：Filebeat -> Kafka -> Logstash -> ES -Kibana，在 Logstash 处会对日志进行二次解析打标，不规范的日志会丢弃掉。

Q：JVM Xmx 是堆内存，硬限制是物理内存，你们的配置是直接读环境变量设置一样了吗？会不会出现内存不足？堆外内存怎么办？

A：我们的环境变量配置的是 Pod 容器的 limit 大小，JVM Xmx 是使用 limit 大小*0.6 配置启动的，出现过内存不足，OOM 等情况，一般是让开发去调整 permsize 大小，或不要有内存泄露。

Q：容器 rootfs 大小怎么限制的？

A：在安装 Docker 时，使用 Devicemapper 驱动安装，会默认限制大小 10G，overlya 驱动对 rootfs 大小的限制不是很完善。

Q：DaemonSet 的日志收集具体是怎么做的？怎么采集日志？

A：我们参考了阿里云的 LogTail 日志采集方案，这里给大家推荐一个开源版的日志采集项目：AliyunConta/pilot。

Q：服务监控接口，类似于/zbjcheck 这块是怎么做的呢？是否可以发一个返回样例。

A：要求在每个项目里对/zbjcheck 路由进行匹配，根据 http 返回码做简单的 check 检测，具体可以参考官方文档：kubernetes.io/docs/robes。

Q：什么时候升级集群，Kubernetes 大版本升级的时候怎么做？

A：我们一般会在进行机房业务迁移的时候去升级集群，如从私有云迁到公有云，直接新建一套新版本集群，把旧集群的 deployment 文件更新过去。

Q：相关中间件和 DB 都没有上吗？有的话请介绍一下。

A：是的，中间件和 DB 数据库都有专门的团队来维护，在没有必要的情况下没有去做容器化，我们集群对接了 Ceph 存储，但 IO 性能不高，数据库容器化还是应该使用 local volume。

Q：DevOps 的资料都存在 etcd 中的吗？ 这个是怎么做的 能否讲讲设计思路？

A：是我们的 Deployment 发布模块及元数据都存在了 etcd 中，把 etcd 当做一个 K-V 数据库来用，当时在数据库选型时也考虑过 MySQL，但是我们的数据类型适合 KV 存储，如我们的每个项目 Deployment 模板都是不一样的，存放在/deployment/region/env/projectname/这样的路径下，并且 etcd 更加稳定高可用。

---

2018-11-22：容器化落地实践的一个案例

Q：PreStop Hook 的参考地址能给个外网地址看嘛？

A：这个看官方的文档就行吧，我这个场景里只是用了一个 curl，让开发提供一个接口就行。具体 PreStop Hook 官方文档上有详细的举例。

Q：Apollo 配置中心，配置怎么落到服务里的，或者容器里？

A：我们这边大部分是 Java 项目，使用的官方提供的 SDK，具体可以看下 Apollo 的使用文档。

Q：日志怎么采集和展示？用什么方案？

A：ELK，采集日志主要是程序直接输出到 Redis，这点有些不一样。

Q：CD 的配置是怎么管理的？

A：相关的上线配置都是存在运维平台上，服务的配置使用的 Apollo 配置中心。

Q：Kubernetes 的 HPA 组件是原生的吗，只根据 CPU 内存来进行伸缩，有没有出现过什么问题？

A：是原生的，出现过的问题是，之前都只采用了一个纬度的扩容（CPU），后来发现该 Pod 经常 OOM，后来加上了内存的扩容，Java 服务例外。

Q：Prometheus 数据怎么保存的，每个实例都存在本地目录吗？

A：我们有专门的 Node 节点来跑 Prometheus Pod 通过 Node Label 调度，采用的本地 SSD 磁盘，每个服务一个目录，大概这个样子。

Q：还有就是日志部分现在 Redis 是瓶颈吗，Redis 也是集群？

A：分享的时候提到了，Redis 是瓶颈，后来公司 Golang 工程师搞了一个 Reids--Kafka 的代理服务，采用的 Redis 协议，但是直接写入到了 Kafka，解决了性能问题。

Q：Prometeus 也是 Kubernetes 管理吗，配置文件他的配置文件怎么管理的？

A：这块我们写了一个简单的服务部署到了 Kubernetes 的 Master 节点上，当一个服务接入 Kubernetes 上以后，运维平台会去掉这个服务的接口，就会创建一个 Prometheus Server 专门抓取该服务的监控数据，通过 Prometheus 的配置可以做到只匹配该服务，我们这边是每个服务配置一个单独的 Prometheus Server 抓取端。

以上内容根据 2018 年 11 月 20 日晚微信群分享内容整理。分享人吴飞群，一下科技运维工程师。

---

2018-11-03：Spring Cloud Kubernetes 容器化实践

Q：使用 NFS 有存在性能瓶颈或单点故障的问题吗，如何解决，对于持久化要求高的 Redis 应该采用哪种存储？

A：具体看你的规模数量，测试、开发环境，单节点 NFS 毫无压力，数据是先写到缓存内存，速度很快，我文章中的说的内核注意 bug，没必要做高可用，公有云有 NAS 服务，不必担心，自建机房可以用 drbd Keepalived vip。

Q：为什么网络没有使用 Traefik，Spring Cloud 的相关组件是怎么部署的，是用 yaml 文件还是使用 Helm 方式？

A：考虑到 Traefik 性能没有 nginx 好，所以用 nginx，ymal 是自己写的模板生成的，没有用 Helm。我们正在调研，Eureka 可以单独定制多个 yml 互相注册。与外部服务通过打通网络直通，通过 SVC 对接。

Q：请问下所有环境都在一个集群，压测怎么办？

A：压测只是对应用产生压力，你可以把需要压测的应用调度到不同的节点 Node Selecto 隔离运行。

Q：对于局域网微信回调是如何做，没有公网 IP？

A：打通网络之后，设置 WIFI 指向 DNS 为 Kubernetes DNS，Service 直接互通。

Q：Eureka 注册时服务 IP 用的什么？

A：Kubernetes 集群内会用的 pod ip 去注册。

Q：有状态应用的场景，使用容器部署与传统部署有啥区别，容器部署是否存在一些坑？

A：有状态容器创建后，尽量少动，少迁移，遇到过卡住，容器无法迁移或删除，重要的 MySQL 之类的建议放外部运行。

以上内容根据 2018 年 10 月 30 日晚微信群分享内容整理。分享人涂小刚，新浪爱问普惠科技容器平台负责人，负责 Kubernetes 容器平台的推广与建设。

---

2018-09-29：有赞容器化实践

Q：你们的上线审批流程是怎样的？

A：我们主要是定义了发布窗口、发布次数等限制，如果在限制以内的，只需要走普通的发布审批流程，否则走紧急发布流程。

Q：在容器内打镜像怎么避免用户把仓库账号信息打印出来？

A：Clone 代码所使用的私钥是通过 Pod 的环境变量下发的，这里主要是把镜像集成分成多个步骤，我们会在最开始 Clone 完代码后就将所有敏感信息清理掉了。

Q：网络方面可以详细讲一下，没有遇到问题吗？

A：网络方面因为我上面说的原因，我们一开始就是 Macvlan 的方案，ipam 都是本地配置文件，这样风险确实是最低的，性能也很不错。后面我们随着有赞多云架构，也在使用 QCloud 的容器服务，当然这里的网络主要还是云厂商解决的。

Q：请问，你们是如何衡量应用容器发布之后的效率改进的？单纯看用户体验，还是有类似发布效率改进这类的指标？

A：容器化效率提升其实最主要的还是在开发测试环节，比如很多项目中都是 push 完代码就开始自动 CI、部署、测试等过程的，我们在持续交付里会有很多指标的产出作为参考。

Q：应用监控方案呢？Docker 内基础监控的采集、上报、存储和展示方案，能否分享下？

A：监控主要用的还是 Prometheus，主要包括采集容器的基础 Metrics 数据、kube-state-metrics 数据以及后续 Java 框架/Nodejs 框架统一输出的 Metrics 数据。这些监控数据会和容器之前的所有监控数据统一到”天网”中，展示是我们自己定制的，实现在我们的基础保障平台里面。

Q：之前看过有赞 SC 环境的文章，里面 Dubbo 的路由规则是否针对环境的逻辑隔离做过改造？关键实现的点是哪些？

A：是的，我们确实改造过整个调用链里的每个环节，会全链路透传一个环境标签，以及我们灰度实现的方案也是基于这个。

以上内容根据 2018 年 9 月 25 日晚微信群分享内容整理。分享人王波，十年运维老兵，现担任有赞运维平台负责人，负责有赞基础保障平台的建设，面向有赞开发、测试和运维提供涵盖应用生命周期管理、项目研发生命周期管理（持续交付）等功能的 DevOps 一站式服务。

---

2018-09-20：唯品会 Noah 云平台实现内幕披露

Q：灰度发布时，两个应用前要加负载均衡吗？

A：我在服务注册发现章节提到唯品会有自研的服务化框架，是通过服务化框架的 Proxy 做 LB 的，LB 是服务治理的一个重要功能。对于 HTTP 服务，最后还是注册到 HAProxy 的，因此还是通过它做 LB 的。

Q： 有状态的服务比如 IP 固定，不知道你们有没有这种服务，是怎么解决的？

A：我们是有写有状态的服务，如 Redis 和 MySQL，是通过 CentOS Operator 框架，自己编写 Operator 解决的。固定 IP 我们正在开发中，因为要结合唯品会的网络拓扑，实现起来稍微复杂点。还有，我们在做的 rebuild 方案，IP 也是相对固定的，如果没有触发 Kubernetes 的 scheduler 调度的话，比如 node evict。

Q：请问，外部请求如何路由到 Kubernetes 集群内，是使用的 Ingress 吗？

A：外部流量的接入，唯品会有 VGW 的 Gateway，通过 APP 上的智能路由找到最优机房的 VGW，然后一层一层到容器。

Q：超配的情况下，如果各个 pod load 都增大，驱逐策略是怎样的？

A：这里我没有讲细，你的问题很仔细啊，赞，我们开发了热点迁移容器的 API，监控系统如果收到告警（比如 CPU 过高，IO 过高），会调用我们 API ，我们 API 获取实时的监控数据，根据某个算法，迁移走部分热点容器。

Q：自动缩容的时候是如何选择 Pod，如何保证数据不丢失呢？

A：自动缩容之针对无状态应用的，而且我们要求所有上云平台的应用，都支持 Graceful Shutdown，由业务保证。

Q：Tomcat 类应用容器 Xmx 内存分配多少比例合适，就是 Xmx 使用百分多少容器内存合适？

A：JVM 内存的计算包括了 Heap＋Permgen＋ 线程数的 stack（1M／per 线程）＋ 堆外内存，所以我们监控容器的 RSS 数据，这是容器真实的内存占用。

Q：集群空闲率多少合适？我们的集群超过 60% 上面的容器就不稳定了。

A：我们为了提高资源利用率，做了很多事情，上面有说到，你说的 60% 就不稳定，需要具体分析下，因为我们也踩过一些 Kubernetes 和 Docker 的坑，同时也需要优化好系统参数，有时候问题也跟内核版本有关。

以上内容根据 2018 年 9 月 18 日晚微信群分享内容整理。分享人王志雄，唯品会云平台架构师，参与工作 15+，其中 10 多年在亿讯（中国电信），爱立信参与电信领域产品开发研究工作，4 年前加入唯品会基础架构部，主要负责服务化平台（唯品会 OSP）的研发和推广落地工作，OSP 现已经是唯品会主流的服务化框架。17 年开始云平台产品相关工作，现是唯品会云平台架构师，主要负责唯品会 Noah 云平台的产品研发和推广落地工作，Noah 云平台已经接入了大部分核心域和其他业务域，并顺利承载了公司的多次大促。

---

2018-09-09：gVisor 是什么？可以解决什么问题？

Q：gVisor 是 yet another container，gVisor = Kata Linux 的隔离性 + Docker 的隔离低消耗，可以这样理解吗？

A：基本上可以这样理解，看业界对 gVisor 的评价普遍认为隔离性与虚拟机方案的隔离性相当，但也有人顾虑是否真能提供到这么高的隔离性，个人觉得需要时间来证明。关于低损耗我觉得得看业务的场景，目前来说对于高性能的场景我觉得是不合适的。

以上内容根据 2018 年 9 月 4 日晚微信群分享内容整理。分享人王重山，深圳米筐科技有限公司运维总监。2014 年底加入米筐，先后参与米筐在线平台以及运维系统的建设，在运维体系建设期间调研和落地了容器相关技术。

---

2018-08-25：有货基于 Kubernetes 容器环境的持续交付实践

Q：为什么没有和 CI 结合在一起？使用这个比较重的 Spannaker 有什么优势？

A：可以和 CI 进行结合，比如 Webhook 的方式，或者采用 Jenkins 调度的方式。优势在于可以和很多云平台进行结合，而且他的 Pipeline 比较的完美，参数化程度很高。

Q：目前 IaaS 只支持 OpenStack 和国外的公有云厂商，国内的云服务商如果要支持的话，底层需要怎么做呢（管理云主机而不是容器）？自己实现的话容易吗？怎么入手？

A：目前我们主要使用 Spinnaker 用来管理容器这部分的内容，对于国内的云厂商 Spinnaker 支持都不是非常的好，像 LB，安全策略这些都不可在 Spinnaker 上面控制。若是需要研究可以查看 Cloud driver 这个组件的功能。

Q：Spinnaker 能不能在 Pipeline 里通过 http API 获取一个 deployment yaml 进行 deploy，这个 yaml 可能是动态生成的？

A：部署服务有两种方式：1. 在 Spinnaker 的 UI 中直接填入 Manifest Source，其实就是对应的 deployment YAML，只不过这里可以写入 Pipeline 的参数；2. 可以从 GitHub 中拉取对应的文件，来部署。

Q：Spannaker 的安全性方面怎么控制？

A：Spinnaker 中 Fiat 是鉴权的组件，配置权限管理，Auth、SAML、LDAP、GitHub teams、Azure Groups、 Google Groups，我们就采用 LDAP，登陆后会在上面显示对应的登陆人员。

Q： deploy 和 test 以及 rollback 可以跟 helm chart 集成吗？

A：我觉得是可以，很笨的方法最终都是可以借助于 Jenkins 来实现，但是 Spinnaker 的回滚与部署技术很强大，在页面上点击就可以进行快速的版本回滚与部署。

Q：Spannaker 之前的截图看到也有对部分用户开发的功能，用 Spannaker 之后还需要 Istio 吗？

A：这两个有不同的功能，【对部分用户开发的功能】这个是依靠创建不同的 service 以及 Ingress 来实现的，他的路由能力肯定没有 Istio 强悍，而且也不具备熔断等等的技术，我们线下这么创建主要为了方便开发人员进行快速的部署与调试。

---

2018-08-13：基于 Spring Cloud 的微服务容器化实践

Q：WSO2 的 APIManager 会将所有流量都统一到他这里进出，如何解决统一 API 网关的大流量问题？

A：API Manager 是可以拆开的，分开部署，比如调用你接口走网关模块，可以做高可用。当然不拆开也可以做高可用，前面加负载均衡。

Q：Eureka 在生产上的 Kubernetes 中是如何做到高可用和动态扩容的？

A ：好问题，Eureka 我们目前是指定数量，可以结合脚本（或代码）做动态扩容和高可用。目前我们 Hadoop 就是结合代码做到的。

Q：服务之间二阶段事务控制一般怎么做？或者说有没有现成工具或代码？服务间用 http 靠谱还是其他协议靠谱？

A：这个网上有一些思路比如补偿的方式，还有就是通过流数据库（Kafka），事件驱动的方式。我们目前正在尝试这种方式。

---

2018-08-11：滴滴弹性云 Kubernetes 实践

Q：利用 cgroup v2 的 blk-throttle 实现对非 driect io 场景下的磁盘读写速度隔离，这个怎么做的，Kubernetes 支持吗？

A：如果是 3 的内核，那么只支持 cgroup v1，v1 只支持对 driect io 的磁盘读写限制，而我们知道大多数情况下的写磁盘都是先写到内存里再 FLUSH 到磁盘上，所以要限制的是从内存到磁盘的这个环节。4 的内核支持 cgroup v2，这个功能已经比较成熟，你可以尝试升级内核或者将 v2 的功能移植到 v1 上。

Q：是要修改 dockerd 的配置，还是在 Kubernetes 上扩展？

A：如果是接着上面的问题的话，我们是使用了一个 Agent 的方式，单独的做加强的资源隔离的，没有在 Kubernetes 上做扩展。

Q：DGW 是基于什么实现的？

A：DGW 其实就是 LVS，我们这边的系统组实现了通过接口的方式动态的变更 LVS 配置的能力。

Q：容器网络和物理网络类型一样，具体是什么网络？原有的 ONOS SDN 网络还有用吗？不同 name space 之间隔离怎么做？

A：老的集群使用 SDN 网络，新集群使用物理网络。所谓物理网络就是和物理机同一个网络，只不过每个 tor 下划分出一段专门给容器分配使用。

Q：请问下”利用 tc 实现对容器网络带宽的限制”，具体怎么做的？

A：参考物理机使用 tc 对容器做网络流量限制，如果你用了 SDN 网络 DPDK/OVS 什么的，限速就更方便了。

Q：滴滴的卷管理是怎么设计的？有状态服务怎么设计调度，来保证数据持久化的？

A：目前我们这边有状态服务非常多，无状态非常少，用户的使用习惯还是和物理机趋同，对于这部分”老派”的用户我们提供了类似虚拟机这样的容器。使用本地卷（hostpath），容器只能本地重建不可跨宿主漂移。这也是对业务的一种妥协。另外我们也使用过 ceph，但是最后评估风险更大，故暂时放弃使用，或小范围使用。

Q：通过负载均衡的健康检查测试服务可用性，健康检查的周期内，如何保证流量不丢失？

A：我们这边 LVS 默认有 7 秒的探活间隔，在 7 秒的间隔内如果容器故障不可用那么确实会有流量的丢失，目前不可避免。

Q：容器的优雅下线怎么实现的？

A：我们之前的容器启动都是用 Supervisor 托管的，后来我们自己写了一个 dockerinit，用于用户业务服务的启停，他的功能比较强大能执行单独的一次性程序（类似物理机的 rc.local），也能托管进程。于此同时他会保证容器所有的业务进程退出后再销毁容器，避免粗暴的停止容器。

Q：有没有使用 cpu_quota 来做精细的限制呢？CPU request 绑定 CPU，超分的情况怎么处理呢？

A：你想问的其实是超售的问题，参考业内一些走在前面的大厂，我们的容器会根据容器的服务等级做适当的超售，这样一个 48 核的宿主就能承载更多的容器。这里面的细节比较多，这里不太好描述。

Q：我们在运维过程中发现：某些配置了探针的容器因为服务没有成功启动而不断的被 Kubernetes 杀掉重建，在重建超过几百或数千次之后会偶发性的导致宿主的一些异常。这个问题的原因我们尚未查明，但是这种容器不断的重建本身就显得没有意义，再加上我们使用了自研的服务发现，所以就对每个容器的重启次数做了限制，让负载均衡层去做健康检查。

A：启动上百个 Pod 以后我也遇见过这个问题，后来排查问题发现是 docker docker_storage 的 overlay 和 overlay2 没有使用 xfs 文件系统导致，不知道你们有没有研究 io 的问题。我们使用的是 overlayfs2，这个我们在生产环境中验证过，还是比较靠谱的。如果你是低版本的 Docker 的话，需要加一个参数就能使用 overlayfs2 了。有没有调研过 RedHat 的 OpenShift，感觉网上文档很全也解决了很多问题，听说小米在用，但是你知道基础架构是牵一发而动全身的，不能轻易变化。

---

2018-07-29：基于 GitLab 的 CI 实践

Q：您提到把各种依赖都以 Service 的提供，请问是以哪种方式呢？比如 Python 的依赖，怎么做成 Service 呢？

A：Service 化的依赖，主要是指类似 DB / MySQL/ Reids 之类的。 或者是 dind 其实它提供的是 2375 端口的 TCP 服务。 Python 的依赖，我推荐的做法是， 构建一个换了源的 Python 镜像。 安装依赖的时候，耗时会少很多。 或者说， 可以在定义 Pipeline 的时候， 将虚拟环境的 venv 文件夹作为 cache ，之后的安装也会检查这个，避免不必要的安装。

Q：请问，你们为什么不用 Jenkins Pipeline，而使用 GitLab CI？

A：主要原因是我提到的那几个方面。 集成较好， 界面美观优雅， 使用简单（所有有仓库写权限的人 都可以使用， 只要创建 .gitlab-ci.yml 并且配置了 Runner 即可使用） 。换个角度，我们来看下使用 Jenkins 的问题， Jenkins 对于项目的配置其实和 GitLab 的代码是分离的， 两部分的， 用户（或者说我们的开发者）在使用的时候， 需要有两个平台， 并且，大多数时候， Jenkins 的权限是不放开的。 对用户来讲， 那相当于是个黑盒。 那可能的问题是什么呢？ 遇到构建失败了， 但是只有运维知道发生了什么，但是研发无能为力，因为没有权限。 使用 GItLab 的好处，这个时候就更加突出了， 配置就在代码仓库里面，并且使用 YAML 的配置，很简单。 有啥问题，直接查，直接改。

Q：关于 Runner 的清理的问题，在长时间使用后，Runner 机器上回产生很多的 Cache 容器，如何清理呢。能够在任务中自动清除吗？

A：这个就相对简单了，首先， 如果你的 Cache 容器确认没用了， 每个 Cache 容器其实都有名字的， 直接按 Cache 的名字过略， 批量删掉。 如果你不确定它是否有用，那你直接删掉也是不影响的， 因为 Docker Excutor 的执行机制是创建完 Service 容器后， 创建 Cache 容器。 要是删掉了，它只是会再创建一次。 如果你想在任务中清除， 目前还没做相关的实践，待我实践后，看看有没有很优雅的方式。

Q：请问下 Maven 的 settings.xml 怎么处理？本地 Maven 仓库呢？

A：我们构建了私有的 Maven 镜像， 私有镜像中是默认使用了我们的私有源。 对于项目中用户无需关注 settings.xml 中是否配置 repo。

Q：在 GitLab 的 CD 方案中，在部署的时候，需要在变量中配置跳板机的私钥，如果这个项目是对公司整部门开发，那么如何保护这个私钥呢？

A：可以使用 secret variable 将私钥写入其中， （但是项目的管理员，具备查看该 variable 的权限）开发一个 web server （其实只要暴露 IP 端口之类的就可以） 在 CI 执行的过程中去请求， server 对来源做判断 （比如 执行 CI 的时候，会有一些特定的变量，以此来判断，是否真的是 CI 在请求）然后返回私钥。

Q：GitLab CI 适合什么类型的项目呢？国内目前还比较小众吧？

A：国内目前还较为小众（相比 Jenkins 来说）其实只要需要 CI 的项目，它都适合。

---

2018-07-20：小米弹性调度平台 Ocean

Q：请教下你们 ELB 用的什么代理软件，HAProxy、Nginx？是否遇到过缩容时出现部分请求失败的问题，有解决方案吗？

A：IDC ELB 底层封装的是公司的 LVS，LVS 管理平台提供了完事的 API 支持，ELB 这边调用 LVS 管理平台的 API 进行的相关操作。缩容目前没有遇到流量丢失问题，这个是在 docker init 内接收信号，然后做的回收处理。

Q：hostgw 如何访问外网？

A：是通过路由出网的，容器的 IP 是路由上真实存在的 IP 网段，由网络组提供的 API 进行的动态配置。

Q：都劫持了，为啥不用 LXCFS？

A：LXCFS 目前仅支持改变容器的 CPU 视图（/proc/cpuinfo 文件内容）并且只有 –cpuset-cpus 参数可以生效，对于系统调用 sysconf(_SC_NPROCESSORS_ONLN)返回的同样还是物理机的 CPU 核数。另：我们采用的劫持方案已开源，欢迎围观：agile6v/container_cpu_detection

以上内容根据 2018 年 7 月 17 日晚微信群分享内容整理。分享人赵云，小米云平台运维部 SRE，负责小米有品产品线运维工作。

---

2018-07-13：Hulu 大规模容器调度系统 Capos

Q：Capos 如何处理健康检查？之前了解到，Mesos 内置的健康检查不是特别完善。

A：目前 Capos focus 的作业大部分都是短作业类型，所以我们目前就是通过容器的退出码来判断 success 或者 fail，如果你说的健康检查是针对服务的，一般实现是支持多种健康检查的方式，bash，http 等，然后为了大规模容器运行情况下的可用性，建议这种健康检查的发起 client 和服务 instance 是在一台机器上，或者是一个 Pod 中，发现不健康通过某种机制上报，或者退出 Container，但是需要控制 Threshold 以免整个服务 downtime。这样可以探测 instance 的健康，整个服务的健康，可以在通过外部的一些子系统去 check。

Q：关于调度方面，分享中只提到了使用了一系列的可插拔的过滤函数和优先级函数，我想问下能否具体描述下如何被调度的？和 yarn 里使用的 Fair Schedule 或者 DRF 算法的异同有哪些？因为对于多种资源维度的调度是一个很复杂的问题，希望知道 Hulu 这方面有什么心得和思考？

A：目前实现是，会针对一个请求，首先根据过滤函数比如一些 constraints 进行 offer 过滤，然后剩下的 offer apply 所有的优先级打分函数，进行打分，打分的时候，会根据一个请求和 offer 的资源，算 CPU 和 mem 的比例，选取出 dominate 的 resource 进行主要评分，然后选取最优的 offer 进行 bind，bind 之后不会马上调度，而是会 delay scheduler，这样一般在比较繁忙的情况下，一次 offer launch 可以启动多个 tasks，这是对于大规模吞吐的考虑。 以上这些实现还是 queue-base 的调度，借鉴了一些 Fair Schedule 和 drf 的思路，具体差别你了解了 Capos scheduler 策略后，应该就会有自己的想法了。多种资源维度，目前我们是根据 dominate resource 作为主要评分标准的，当然你也可以看下我最后分享提到的一些 flow-base 的 scheduler 算法，比如 firmament。希望可以回答你的问题。

Q：Capos 是否支持，数据中心之间的备份/切换。比如 Zone-A 的数据中心出现网络故障，把服务迁移到另一个指定的区域 Zone-B（仍然考虑恢复以后优先部署到 Zone -A）。之前考虑是类似一个 Mask 的机制，如果故障就加一定的 Mask 值（比如 Opcacity）在某个集群上，然后调度的时候去参考这个 Mask 值，不知道 Hulu 有没有类似的需求或者考虑过这样的机制？

A：Capos 是 on Mesos，Mesos 是根据 zk 做选主，而且 Capos scheduler 中还有一个 raft base key value store，所以这些条件，使得 Capos 是一个 datacenter 的解决方案。目前 Hulu 是有多个 DataCenter 的，所以看架构组件图，你可以看到，我们有一个 Capos portal，在这个组件下，是可以选择不同 DataCenter 去 run workload。所以我们目前对于数据中心的备份和切换，主要是依赖 Capos portal 这个组件，在 Gateway 的位置做的控制。

Q：想请问下 Capos 的鉴权是怎么做的，有没有用户权限认证系统？此外，针对每个用户有没有容器资源使用量的限制？

A：可以翻到之前 share 的架构组件图，我们有一个 Capos portal 组件，这个组件是提供 Restful API 和 Portal，我们在这边集成 Hulu SSO，然后关联 Hulu yellowpages（Hulu 的服务权限控制系统），做的用户的认证，我们分成自己的 Capos APP， team 的 APP，别的组无法操作不属于自己的 Capos APP。对于 Quota 的管理，我们做了 Queue/Label 机制，每个服务会建一个标识，然后在标识底下配置总的资源使用量，以及可以用的机器列表（通配符），用这样的机制控制 Capos 的用户资源使用。

---

2018-06-28：基于 Pipeline 的 CI/CD 在趣头条的应用实践

Q：生成新的镜像怎么自动打新的 tag？

A：我们镜像 Tag 使用本次构建选定的 Git 版本，如分支名称或者 Tag。

Q：你们的 Jenkins 实例有多少，Jenkins 实例是怎么规划的？

A：1 个 Master 节点提供 UI 界面，几个 Agent 分别对应不同语言版本和不同环境 Kubernetes 集群，运行在容器中。规划就是按语言或版本分节点，按集群分节点（Agent）。

Q：SonarQube 跟 Jenkins 的集成，能否详细介绍一下，能否 show 一下 Groovy 代码。

A：这个比较简单，构建时将项目信息输入到 sonar-project.properties 文件中，再调用 sonar-scanner 命令即可。

Q: 这个 Pipeline Jenkinsfile 是多个在一起吗？ 还是直接写的 Groovy 文件？

A：多个 Groovy 文件，按类型分函数，一个功能尽量只写一次。

Q：Jenkins 的权限控制能否再细化一下？

A：我们这边权限实际上是在 CMDB 中完成的。构建时向 CMDB 发起查询请求，传递当前项目名称、选择的环境、用户名过去，CMDB 判断当前用户是否有权限构建选定的环境，允许则返回项目配置信息，否则返回错误代码，这边收到后报错终止。

Q：SonarQube 的权限控制及性能当面？

A：权限控制使用 SonarQube 提供的 API，将项目跟 GitLab 中相应项目权限匹配起来，GitLab 中可以查看这个项目代码，那么 SonarQube 中就能看到这个项目结果和 Code。

Q: 你们是直接将 SonarQube、GitLab/Jenkins 的权限控制到一起了？怎样做的统一？

A：使用 LDAP 认证。

Q：Sonar 使用的 sonar-scanner 还是 mvn sonar：sonar？

A：使用 SonarScanner。

Q：Kubernetes 的 services.yaml 文件在哪里管理？

A：deployment & service & configmap 之类文件都是提供 Git 进行版本控制，针对语言有模版，构建时进行替换。

Q：Pipeline 有回滚机制吗，你们集成覆盖率测试了吗？

A：回滚机制暂时不打算通过 Pipeline 进行，后续在另外的平台实现。
A：人工触发，因为有必须要人工选择的 Git 版本。为防止误发布，默认没有选定版本，不选则在预处理时报错终止。

Q：Pipeline 这套机制的脚本如果出错了如何调试？

A：echo 输出调试（手动滑稽）。

Q：Pipeline 语法和使用上有什么参考链接吗？

A：www.groovy-lang.org、www.w3cschool.cn/groovy、jenkins.io/doc/book/pipeline/syntax

Q：Git Checkout 的时候，你们的 Git SCM 没有考虑隐私安全的事情吗，比如代码权限受限？

A：Jenkins 使用了一个最小权限用户去 GitLab 上拉代码。安全方面，Jenkins 所有节点都是可控的。

Q: 你们的各工具间，有没有做集成？比如使用 Pipeline 来操作 Jira 相关 issue 等？或其他问题管理工具。

A：我们这边目前还没集成 Jira。如果有这需求肯定会对接起来。 > 至于其它的则根据需要在不同阶段进行上报。

Q：构建及部署都在容器中？要构建的文件或制品文件怎么存放与管理的？

A：Agent 容器启动时挂载了一个目录，里面有全套附属文件及 Jenkins > home 目录。build 节点完成自己工作后，其它节点按需接手处理。

---

2018-06-24：苏宁容器云基于 Kubernetes 和 Contiv 的网络架构技术实现

Q：网络限速的对于系统级别是如何实现的？

A：网络限速其实依然利用的操作系统的特性，比如 tc，其实不管是 OVS Ingress 还是 Netlink 都是通过和内核通信，将限速规则加入到对应的 port 上。

Q：上面提到的 Kubernetes 资源，对于实现 Pod-IP 固定是有限制的吗？

A：是的，当前仅仅支持 Deployment、ReplicaSet、StatefulSet，因为随着对不同资源类型的支持，我们发现处理越多的资源，对于实现 IP 固定的逻辑就越复杂，比如要判断这个资源是真正删除还是重新调度，在代码级别要处理的很细。所以，我们按照自身的业务特点，现在只实现三种。

Q：RSF 系统是什么系统？eBPF 和 XDP 是什么？能简单介绍下吗？

A：eBPF 和 XDF 是 Calico 网络插件的概念，eBPF（extended Berkeley Packet Filter）起源于 BPF，它提供了内核的数据包过滤机制。 BPF 的基本思想是对用户提供两种 SOCKET 选项：SO_ATTACH_FILTER 和 SO_ATTACH_BPF，允许用户在 sokcet 上添加自定义的 filter，只有满足该 filter 指定条件的数据包才会上发到用户空间。

Q：您现在用的 Contiv 版本是多少，通过 Pod 的什么属性实现 Pod IP？实现 pod-ip 固化目前代码改动量有多大，如果按人天算的话？

A：现在用 1.2.0 版本，Pod 的对应 pause 容器的 IP、Mac。改动量需要 30 人/天，前提是对代码以及数据结构比较了解，也比较清楚 Kubernetes 的 Pod 创建逻辑。

Q：你们做了大量定制化开发，是否提交社区了，如何保障与社区同步？

A：没有提交社区，但是我们发现了一些重要的 bug 提交了，可能是因为很多代码涉及比较广，并且我们改动的有些并不是思科能够接受的，比如 pod-ip 固定，这个其实不符合 Kubernetes 开源思想。

---

2018-06-14：盘点 Kubernetes 网络问题的 4 种解决方案

Q：今天讲了很多方法解决容器网络的问题，似乎可以从集群外部或集群内部可以直接访问容器的 IP，但是在集群外部访问容器 IP 的场景有吗？我觉得容器的 IP 不应该暴露出来，从外部不能直接访问容器的 IP，因为容器的 IP 可能是变化的。有的时候使用 RC 之类的。我的问题是能不能从集群外部通过 clusterip 或 node-port ip 来访问基于容器的业务呢？如果可以的话，今天介绍的 Flanel 或 Calico 的价值是什么呢，这两种方案，我感觉都是直接访问容器的 IP 地址，那么如果某个容器出问题，重启之后，肯定要换 IP，那这个时候怎么办呢？另外，集群内容器到容器的访问，到底是直接访问对端容器的 IP，还是访问 cluster-ip，我这个有点晕，谢谢。

A：集群内容器到容器的访问，可以直接通过 localhost 加端口即可。如果是同一主机上的 Pod，由于它们在同一个 docker0 网桥上，地址段相同，可以直接通信。如果是不同主机上的 Pod，则需要跨越物理机上的物理网卡，通过宿主机的 IP 转到 docker0 上再到对应的 Pod 里的某个容器。不管是 Flanel 或 Calico，都有各自的应用场景。Flanel 不是直接访问容器 IP 的，它还有自己的 flanel0 网桥，Calico 节点组网可以直接利用数据中心的网络结构（支持 L2 或者 L3），可以直接通信。从外部可以直接访问容器的 IP，需要做容器固定 IP，针对某些特定应用比如数据库。

Q：有没有碰到因为 Pod 数量大导致网络异常？

A：暂时没有，Pod 在大批量创建后有状态异常的，可以将其手工恢复到 Running 状态。

Q：想问一下，我们实际项目中有没有使用 Calico 网络，有没有遇到典型的问题？Calico ipip 生产环境应用有没有问题？

A：数据中心环境有用 Calico，问题是目前 stable 版本还无法很好的支持私有网络。

Q：对于 Kubernetes 版本选择是否可以提供一些建议？

A：建议使用 1.8 以上版本，在高可用、兼容性、稳定性上都更好一些。

---

2018-05-27：腾讯云 TSF 微服务平台及 ServiceMesh 技术实践

Q：感谢分享，请问目前 TSF 的集群规模大概是多大，ServiceMesh 从选型到落地大概用了多少人月？

A：公司内部万级的集群规模，ServiceMesh 落地大概 20 人月。

Q：请问你们微服务与 Kubernetes 的关系是怎么样的？下层跑的是 Kubernetes 容器吗？

A：Kubernetes 原则上是属于 PaaS 平台，PaaS 平台是负责服务的生命周期管理以及伸缩运维等能力。而我们微服务框架本身实际上更多是针对服务调用以及治理方面，其架构是与 PaaS 解耦，并且可以对接不同的 PaaS 平台（包括 Kubernetes），我们下层支持容器及虚拟机。

Q：请问一下 TSF 如何融合 Spring Cloud 和 ServiceMesh？

A：TSF 通过 3 种方式融合：一方面我们有一部分 ServiceMesh 方案基于 Spring Cloud 实现；二方面，是统一服务模型与配置模型；三方面，是体验统一，就是服务的部署/升级及运维的体验是一致。

Q：引入 Mesh 之后，会额外多一跳，这多一跳带来的性能损失，TSF 是如何找回来的？

A：其实很多团队会纠结引入 Mesh 后多了的那 1 跳的性能损失，其实经过我们验证，一方面 Envoy 性能极高，媲美 Nginx；二是这一跳的损耗，实际上与业务处理时延有比较大的关系，如果业务处理时延在 30 毫秒以上，那么这一跳带来的损耗实际上可以控制在可控范围内（具体要看机器性能）。

Q：30ms 时延算很大了。如果是 2ms 或者 0.xms 是不是必须考虑这个问题了？也就是说可能得看 Envoy 的性能与业务的性能是否接近？

A：根据我们在公有云的测试结果来看是的，假如业务是属于那种对快速响应而且对时延特别敏感的业务，确实需要跟进实际的测试模型来评估下具体的性能损耗。

Q：对于 Spring Cloud 与 Spring Cloud Sidecar 的区别是什么呢，对于从 SOA 转型到 Spring Cloud 有什么好的建议吗？谢谢。

A：Spring Cloud Sidecar 是以 Sidecar 方式支持非 Java 应用而提供的，和 Spring Cloud 没有太直接关系。具体从 SOA 到 Spring Cloud 转型这个不太好泛泛而谈，要结合实际情况分析。

Q：集群外的服务是如何调用集群内的服务的？自己做的反向代理么？还是用的 Zuul？

A：TSF 用的是自研的，性能更高，稳定性更好。对于小规模用户可以考虑用 Zuul。

Q：你好，根据你的介绍，你们使用 Sidecar 的部署模式，那在这种情况下，感觉开发人员在测试过程中也得了解如何通过配置服务本身及 Envoy Sidecar 实现服务的通讯，对于 Envoy 来说，开发人员来配置还是比较复杂的，你们是通过什么方式避免这种复杂的？

A：如果没有一套自动化的管理部署工具，仅靠人肉支持还是不靠谱的，定位问题也不方遍，这也是 TSF 集成 Envoy 耗时比较久的一个原因。

Q：Istio 和 Kubernetes 结合使用时，服务注册和服务发现是怎么用的？

A：Istio 本身支持多种服务注册发现机制（包括 Kubernetes、Consul、Digital Foundry、Ereuka 等），在启动 Istio 时作为参数来配置即可。

Q：请问是否有过使用 gRPC 通讯的相关案例或者需要注意的坑？目前是否能够在生产环境应用？

A：暂时没有发现 envoy-grpc 的坑，不过 Istio 官方对于 gRPC 的 feature 状态是 alpha，所以个人不建议在生产环境的使用 Istio。

---

2018-05-23：全面学习 Prometheus

Q：Prometheus 的数据能否自动同步到 InfluxDB 中？

A：可以，通过 remote_write 可以实现，可以参考：github.com/prometheus/apter。Prometheus 通过将采集到的数据发送到 Adaptor，再由 Adaptor 完成对数据格式的转换存储到 InfluxDB 即可。

Q：请问数据采集的时间戳是 Prometheus 采集数据的时间，还是微服务产生数据的时间？

A：采集时间，看 node exporter 里面返回的样本数据可以发现其中并不包含时间戳。

Q：Prometheus 做服务发现的时候 Job 是被自动分配到不同的 Server 节点的吗？具体分配策是？

A：需要手动分配，然后再通过 Prometheus Fedreation 进行汇集。

Q：Prometheus 一个 Server 最多能运行多少个 Job？

A：这个没有做具体的试验，不过需要注意的是 Job 任务量（写操作），会直接影响 Prometheus 的性能，最好使用 federation 实现读写分离。

Q：请问告警由 Grafana 实现比较好，还是 Alertmanager，常用的 metric 列表有没有汇总的清单链接分享下，历史数据默认保留时间如何设置？

A：Grafana 自身是支持多数据源，Promethues 只是其中之一。 如果只使用 Promthues 那用 Alertmanager 就好了，里面实现了很多告警去重和静默的机制，不然收到邮件轰炸也不太好。 如果需要基于 Grafana 中用到的多种数据源做告警的话，那就用 Grafana。

Q：Prometheus 监控数据推荐存哪里是 InfluxDB，或者 ES 里面，InfluxDB 单节点免费，多节的似乎收费的？

A：默认情况下，直接是保存到本地的。如果要把数据持久化到第三方存储只要实现 remote_write 接口就可以。理论上可以对接任意的第三方存储。 InfluxDB 只是官方提供的一个示例之一。

Q：请问告警规则文件可以动态配置吗？比如 Prometheus 已经启动，一个新的微服务上线，并需要配置新的告警规则，这时可以动态添加告警规则吗？

A： 这个不能，不过你可以自己实现一个 sideca 在, 下发告警文件以后，让 Prometheus Reload 一次。

Q：请问部署多套 Prometheus Server，这些不同实例间的数据会重复吗？还是每个 Prometheus 只管理不同的服务的数据收集？

A：如果在一个主机上运行几个 Node Exporter 那数据肯定会重复，这个应该从部署结构上去考虑。

Q： 请问”再有上层 Prometheus Server 实现对数据的汇聚。”是表示该 Prometheus 会对下层 Prometheus 进行数据收集吗？使用什么接口？

A： 请参考 Prometheus Fedreation，这里主要是指由一部分 Prometheus 实例负责采集任务，然后 Global 的 Prometheus 汇集数据，并对外提供查询接口。 减少 Global Prometheus 的压力。

Q：能否有集群方案分享一下？

A： 请参考 https://github.com/yunlzheng/prometheus-book。

Q：多个 Prometheus 监控方案数据能否共享？怎么持久化数据？

A：同上，请参考 https://github.com/yunlzheng/prometheus-book。

Q：Prometheus 怎么做告警聚合？

A： 不过如果是多个 Prometheus 的告警的数据的话，是可以都发送到一个 Alertmanager（单实例或者集群）然后再统一处理。Alertmanager 可以根据告警的标签，将多个告警合并成一个通知。

Q：两台 Prometheus server 可否用 Keepalived？

A： 直接负载均衡就可以了，对于 Prometheus 而言，实例之间本身并没有任何的直接关系。

Q：告警通知支持脚本吗？

A：Alertmanger 对接 webhook，通过这个可以自己扩展。

Q：咨询下在传统服务器上安装 node exporter 后，怎么才能做到被 Prometheus 自动感知？每增加一台服务器安装 node exporter 后，再修改 Prometheus 配置文件，这样太不方便了。有什么自动注册方案吗？

A：使用服务发现的能力，file_sd_config 和 consul_sd_config 应该都能解决你的问题。

Q：有个问题 Prometheus 是如何监控域名的？Zabbix 可以监控域名，Prometheus 不知道可不可以？

A： 上面分享的 Blackbox exporter 就是做这个的。

---

2018-05-13：Kubernetes 网络安全之访问控制技术实践

Q：根据 docker-network-cloud 的测试，Weave 网络方案在性能上比其他方案差很多，这是真的吗？

A：该文章测试的时候并未开启 fast-data-path，经过我们的测试，在 fast-data-path 开启的情况下，还是很可观的。况且这个测试到今天已经过去了 2 年时间，Weave 社区一直以来还是很活跃的，相信未来只会更好。

Q：请问针对 Azure 和 AWS 在网络方面有没有遇到什么坑？好像前面只看到 Aliyun 的。

A：AWS 有个”源/目标地址检查”，华为云也有类似功能，如果在你的网络设计中云主机出来或进去的 IP 与注册的云主机 IP 不符，则需要把它关掉，另外如果不关”源/目标”地检查，也无法把目标主机设置成路由的 next-hop；Azure 主要就是默认动态公网 IP，需要调整成固定 IP。另外要特别注意主机间 copy 数据的流量费。 AWS 上设置 Kubernetes for Windows 确实大费周折，我们当时和 Kubernetes 社区的 Windows AIG 的人一起搞了个方案，比较复杂。

Q：有没有什么办法为每个命名空间设置一个全局的 NetworkPolicy，还是说必须要先创建命名空间才能定义 NetworkPolicy（希望是就像 ClusterRoleBinding 一样）？

A：至少现在还不可以，一般来说这不应该是普遍的需求，因为每个应用在一个 Namespace 下，而每个应用的的访问控制策略不大可能是相同的。从另一个方面看，以 Kubernetes 社区的风格，任何普遍的需求最终都是会被实现的，而且速度很快。

---

2018-05-09：TalkingData 的 Spark On Kubernetes 实践

Q：我想问权限方面的问题，前面有看到一个提交作业的例子是 spark－summit –files hdfs://host:port/path/to/file1，即用 Spark 处理 HDFS 上的数据，出于数据安全的考虑，HDFS 一般会开启权限认证，用户在 kerberos 上做认证，用同一个身份信息访问 Spark 和 HDFS。对于 Spark on Kubernetes 这样一个方案，是如何认证并与 HDFS 结合的呢？

A：老实说，我们原生的 Spark 集群也还是基于 POSIX，并没有使用 kerberos。不过我认为一个可行的结合方案是使用 Kubernetes 的 webhook，在作业提交时，和 kerberos 交互换取身份验证信息。具体可参考：https://kubernetes.io/docs/hook/。

Q：为什么使用 node label 进行资源隔离，而不使用 ResourceQuota 对多租户进行资源隔离？

A：由于我们很多大数据计算作业对 SLA 有很高的要求，并且 Docker 实际上对很多应用的资源限制都支持的不好。所以我们前期为了稳妥，还是对计算资源进行了物理隔离。

Q：除了日志无法聚合外，每次查看 Driver UI 也是个问题。比如当我跑的程序较多时怎么有效地管理这些 completed driver pod？

A：是的，Spark On Kubernetes 还缺少应用管理的功能。不过这个功能已经列在官方的 todo list 里。

Q：比如 flannel 是把 flannel 参数传给 Docker，一种用 CNI 插件，他们有何差别？

A：实际上 CNI 是 Kubernetes 的标准网络接口，而 flannel 是实现 Pod 间通信的网络插件。CNI 中有两类插件：一个是 ipam，一个是 network plugins。flannel 属于后者，是可以纳入 CNI 管理的。

Q：这里的多租户隔离，只提到任务执行过程的调度，那对于不同租户的任务提交，状态监控，结果呈现如何实现隔离的？

A：不同的租户对应不同的 Kubernetes namespace，所以自然实现了任务提交和状态监控的隔离。至于计算结果，我们以往是单纯用 hdfs path 做隔离。我们目前内部有大数据平台，那里真正实现了多租户。

Q：Spark On Kubernetes 这种方式为开发人员增加了难度，不像其他的集群方案，开发人员除了要会 Spark 还要会 Kubernetes，请问怎么推？

A：实际上 Spark On Kubernetes 对大数据开发人员是透明的，任务的提交方式并没有改变，只是加了一些额外的 option。并且我们上层是有统一的大数据平台，进行作业提交。

Q：在使用 HDFS 存储资源下，如果不使用 Spark 的数据本地性，大量数据之间的传输，map 和 reduce 操作是否会影响 Spark 的计算性能呢？

A：个人认为肯定会有影响，因为每次从 HDFS 读取，会带来巨大的网络流量。但是我本身对 Spark 的数据本地性没有什么研究。后期我们计划将 HDFS 和 Kubernetes 混部，将数据尽量靠近计算节点，不知道这种方式能否缓解这个问题。同时，我们还可以使用 Spark on Kubernetes 的 external-shuffle-service，从而使用 hostpath volume 将 shuffle 和 executor pods 打通。

Q：Spark 会作为哪种资源部署方式部署？Deployment 还是 StatefulSet？或者其他？Spark 在生产环境上部署有需要什么资源配置？能否分享下 TalkingData 的生产环境是如何分配 Spark 资源的？

A：Spark On Kubernetes 实际就是创建了 Spark driver headless service，然后创建 Spark driver pod，最后由 driver 创建 executors pods。上述分享中我也提到了，目前我们还是以物理机作为 spark 资源分配的单位。

Q：Yarn vs Kubernetes 优缺点?

A：我们以前的 Spark 就是采用 Spark On Yarn 的方式，不过我对 Yarn 不是非常了解。之所以采用 Kubernetes 是因为，我们想统一底层的资源调度平台。但是 Yarn 目前还是和 Hadoop 生态强耦合的。

---

2018-04-24：Helm：强大的 Kubernetes 包管理工具

Q：Helm 结合 CD 有什么好的建议吗？

A：采用 Helm 可以把零散的 Kubernetes 应用配置文件作为一个 Chart 管理，Chart 源码可以和源代码一起放到 Git 库中管理。Helm 还简了在 CI/CD Pipeline 的软件部署流程。通过把 Chart 参数化，可以在测试环境和生产环境可以采用不同的 Chart 参数配置。

Q：请问下多环境（test、staging、production）的业务配置如何管理呢？通过 Heml 打包 ConfigMap 吗，比如配置文件更新，也要重新打 Chart 包吗？谢谢，这块我比较乱。

A：Chart 是支持参数替换的，可以把业务配置相关的参数设置为模板变量。使用 Helm install Chart 的时候可以指定一个参数值文件，这样就可以把业务参数从 Chart 中剥离了。例子：helm install –values=myvals.yaml wordpress。

Q：Helm 能解决服务依赖吗？

A：可以的，在 Chart 可以通过 requirements.yaml 声明对其他 Chart 的依赖关系。如下面声明表明 Chart 依赖 Apache 和 MySQL 这两个第三方 Chart。

Q：Chart 的 reversion 可以自定义吗，比如跟 Git 的 tag？

A：这位朋友应该是把 Chart 的 version 和 Release 的 reversion 搞混了，呵呵。 Chart 是没有 reversion 的，Chart 部署的一个实例（Release）才有 Reversion，Reversion 是 Release 被更新后自动生成的。

Q：这个简单例子并没有看出 Helm 相比 Kubectl 有哪些优势，可以简要说一下吗？

A：Helm 将 Kubernetes 应用作为一个软件包整体管理，例如一个应用可能有前端服务器，后端服务器，数据库，这样会涉及多个 Kubernetes 部署配置文件，Helm 就整体管理了。另外 Helm 还提供了软件包版本，一键安装、升级、回退。Kubectl 和 Helm 就好比你手工下载安装一个应用 和使用 apt-get 安装一个应用的区别。

Q：如何在 Helm install 时指定命名空间？

A：helm install local/testapi-chart --name testapi --namespace mynamespace。

以上内容根据 2018 年 4 月 24 日晚微信群分享内容整理。

---

2018-04-17：DBaaS 在金融生产环境的落地实践

Q：请问是采取什么策略升级这些数据库类型的服务？升级过程有宕机时间吗？如果没有，会有双写问题吗？

A：在设计中是升级操作就是更新容器镜像。更新策略会根据数据库的高可用结构进行摇摆升级。

Q：具体是实现方式是怎样，有没有用到 StatefulSet，或者 StatefulSet 的区别？

A：没有用到 StatefulSet，目前我们构建了一个名为服务对象，来管理服务的。应该说我们服务对象比 service 更复杂，可以理解为是由多个不同类型的 Pod 组成的。

Q：请问一下你们的 binlog 多长时间过期，有用什么持久化的方式存储吗？

A：我们在封装容器镜像时，针对不同服务镜像有外围的配套脚本。类似于 Kubernetes 中 sidecat 的实现。然后通过定期调用方式备份 binlog 到备份存储。并且清理备份过的 binlog。

Q：还有关于中间件和高可用的选择，我们用 MaxScale 和 MHA，但是并不是非常稳定？

A：的确，我们在设计 DBaaS 也考虑到了，由于目前在 MySQL 中间件和高可用套件没有一个很好的开源产品，所以很难说你必须用哪个方案实现。所以我们在开发中就将这样的需求设计为灵活的服务架构定义，我们平台支持不同类型 MySQL 高可用方案和中间件方案。我们在中国银联是自己开发的高可用中间件方案，通过高可用组件发现故障进行隔离，使用 Proxy 组件进行数据路由，使用 MySQL 做数据复制。在我们设计中，可定制不同服务架构来进行服务的管理。

Q：请问在这套平台里面支持比如说，前端可以让用户选择数据库运行的方式（单机）（还是读写分离、主从架构），这个是自动化配置的吗？这个过程是提前构建的容器镜像对吗？

A：数据库容器镜像是相同的，单机、主从、读写分离等不同服务架构会生成相应的配置文件和启动项，管理逻辑。整体管理会使用定义服务架构配置信息进行自动解析产生相对应的管理操作。

Q：单元、子服务、服务的理解还是比较抽象，有更易理解的例子吗？

A：单元相当于一个我们自己构建的 Pod，但不同于 Pod。单元只会包换一个容器。子服务内是多个相同类型的单元，这样单元就可以部署在不同物理机上，并且完成数据库的复制关系。服务是多个类型的子服务的集合，服务内的子服务会有关联关系，比如一个完整的 Redis 可以有一组三个 sentinel 组成的子服务 + 一组多 Redis Proxy 的子服务 + 多组主从复制的 Reids。同样的类型甚至可以映射到 TiDB 上，可以有一组三个 TiDB + 一组三个 PD + 一组五个 TiKV。

Q：如何理解数据库应用拆分和容器背道而驰？

A：在容器开始阶段，大家会有共同的认识就是容器只适合运行无状态服务。直到大家对容器需求越来越多，有了 Petset，有了 StatefulSet，甚至有了 MySQL Operater。但回归到容器本质还是为统一运维标准，快速灵活的管理资源。但是有状态服务天生就是重的，需要使用继承式的方式进行管理。但为了将有状态服务放到容器，享受容器的优势，就必须进行计算、存储、网络这些关键资源的分离。

Q：请问你们的平台是用什么语言写的，有用到链路跟踪吗？

A：我们平台全部组件都是用 Golang 写的。目前链路跟踪还没有，我们主要是通过我们的自研的监控平台，获取监控数据，监控物理机，容器，和容器内服务的信息，进行高可用的管理，也正在和人工智能公司合作，对运维数据进行分析，进行故障智能分析。

以上内容根据 2018 年 4 月 17 日晚微信群分享内容整理。

分享人鲍琳，富麦科技产品架构师，中国银联 DBaaS 项目架构师。

---

2018-04-16：Kubernetes on DC/OS 最佳实践

Q：目前有公司落地这套方案上生产吗？ 在 AWS 是否实践过这个方案？

A：Kubernetes on DC/OS 是去年九月份官方由 Mesosphere 支持，经过半年的迭代开发，版本已经 GA。目前国外的案例较多一些，国内的中国联通与中国石化正在尝试使用，国内的中国联通希望结合着 Fabric8 一起来使用，中石化希望用来运行微服务。目前 AWS Marketplace 支持 DC/OS，国外很多用户也在用 AWS 构建混合云方案，Kubernetes on DC/OS 屏蔽了底层，所以只要 DC/OS 运行在 AWS 上，Kubernetes 就没有问题。

Q：Kubelet、Kube-proxy、CoreDNS 是一一个 Pod 中的三个容器运行在 Agent 节点上？还是以三个独立的 UCR 容器运行在 Agent 上？

A：是通过三个 UCR 独立的容器运行在同一个 Mesos Agent 上。

Q: 进来的晚了，那个图形管理控制台叫什么名字？

A：Kube-dashboard，是 Kubernetes 的一个 add-on 组件。

Q：DC/OS 全称是什么？物理机跑虚拟机，虚拟机跑 DC/OS，DC/OS 又嵌套容器会不会无止境的架构，越来越复杂？

A：全称就是 DC/OS，也称 Datacenter Operating System，数据中心操作系统。不会无止境的，UCR 官方支持嵌套三十二层，但是我们容器层面一般只嵌套一层，而且容器与虚拟机最大的不同就是不会造成 OS 的开销，所以多几层嵌套问题也不大。

Q：如果同一个集群内部的其他应用没有和 Kubernetes 在一个 VXLAN 里面，他们如何通讯，可以通过 VIP 吗？

A：需要通过负载均衡、Node port 或 Ingress 的方式，不久之后 DC/OS 的服务会和 Kubernetes 的服务全面融合。

Q：很高兴能看到关于 Mesos 的分享，目前发现 Mesos 越来越被边缘化的趋势，比方说 Cassandra Framework 已经在 GitHub 上标记为过时了，我的问题是 DC/OS 以后会是 Mesos 主流的部署方式吗？用 Mesos 如果要使用 Framework 的话是不是要自己去封装？

A：不能说被边缘化，很多大型互联网厂商都是低调的在使用，毕竟技术定位还是不同，而且 Mesos 确实在资源管理方面有其独特的优势。而且 Cassandra 虽然在 GitHub 上过时了，但是在 Mesosphere 内部从未过时，版本更新的很快，还可以无缝迁移。DC/OS 的核心基于 Mesos，这个不会变，但是支持 Kubernetes 是我们的重中之中，这个也不会变。DC/OS 的 Framework 目前已经好几十种，Mesosphere 也在不断地扩大生态，感兴趣可以到官方 Universe 上查看，那里详细地例举了 Framework 以及不同的版本号。

Q：Server Agent 的高可用，以及它们任务调度和 Framework 上的容器调度，任务调度有关系吗？

A：Server Agent，您是指 Mesos Agent 吗？DC/OS 与 VMware 等虚拟化平台在某些方面有类似的功能，比如说，若 Agent 节点出现故障，DC/OS 上的 Framework 会将 task 自动重启，或者在其他主机重启，对于有状态服务，建议使用共享存储方案。

Q：如果同一个集群内的其他应用和 Kubernetes 不在一个 VXLAN 中，他们之间可以怎样通讯？有什么比较好的解决方案？

A：若 DC/OS 的服务与 Kubernetes 不在同一个 VXLAN 上，目前就需要使用 Kubernetes 的 NODE IP，Ingress 或则 LB，这个和开源 Kubernetes 使用方式一致。当前的 Kubernetes 内的服务还只能处在一个 flat network 内，但是可以集成第三方 Plugin，这个和 DC/OS 关系不大，用户可自行选择。

Q：实际使用中 Kafka、Elastic 组件会出现集群不稳定情况，比如 Kafka 起三个 broker，死活启动不了三个的情况，有好的解决办法吗？补充，因为是 Framework 的方式感觉不如 Docker 好管理。

A：起不来的原因有很多，但是我很少遇见一直起不来，有可能是单节点资源不够，有可能是网络原因导致一些镜像或 artifacts fetch 不下来或者是节点数量不够，但是 Framework 与 Docker 的定位毕竟不同，也不属于一个技术。这个我们可以私下交流，我可以帮助您解决一些部署服务的问题。

Q：刚才讲的节点规划，多区域管理是不是说的是企业版的功能？

A：这个是 DC/OS 1.11 的新功能，多区域，同时 Framework 支持故障感知。但是是不是只有企业版支持，我需要查看一下，您也可以到 DC/OS 社区网站查看。

Q：直接用 Mesos 可以部署 DC/OS 点 Framework 吗？

A：可以，只不过操作起来没那么容易，需要一定的专业知识。毕竟 Framework 就是基于 Mesos 开发而成，很多互联网厂商也是仅用了 Mesos，但是自己开发了很多 Framework，既满足自己的业务需求，也为了操作简便。

Q：DC/OS 社区版跟企业版有多大的差异？

A：当前的差异主要体现在安全、多租户、Edge-LB 等几个方面，其它方面差异不大。

Q：既然 Marathon 有容器编排功能，为何要弃 Marathon，而用 Kubernetes，增加体系复杂性，我的问题是，这只是为了满足用户偏好还是确实有设计或性能优势？

A：没有嫌弃不用，Kubernetes 的 Framework 不就是 Marathon 创建的吗？而且 Marathon 与 Kubernetes 的运行机制也不太一样，各有各的优势。只是因为 Kubemetes 在容器编排方面确实很优秀，而且生态很好，因此为客户提供更多的选择。这个绝对不是为了满足用户偏好，不然公司不会投入这么多，大家每天都在群里面讨论如何优化性能，提供差异化的服务。从发布到现在仅仅六个月，但是方便的话可以体验一下，确实在管理和运维上有很多优势。而且从 Roadmap 上看未来在性能和安全上会有很多新的提升。

Q：为什么不直接用 Kubernetes 就好了呢？引入 Mesos 一套技术栈，投入和产出相比如何？

A：还是分享时说的，Mesos 在管理分布式系统上有独特的优势，您可以体验一下，在 DC/OS 安装 Spark、HDFS、Cassandra、Kafka 等，再试着用 Kubernetes 上安装一下，就解释的通了。

---

2018-04-10：扇贝网微服务编排和治理实践

Q：Prometheus 只采集 Kubernetes 集群的指标数据，那非 Kubernetes 的指标数据用什么采集？

A：都是 Prometheus，应用是可以装 Prometheus 的 client，暴露自己的 metrics 的，然后 Redis 什么的也都有 exporter。

Q：请问下日志如果都落到 stdout 的话，会不会造成格式不一致，从而导致收集和归档困难？比如说业务日志和中间件日志都打到 stdout，在 Filebeat 或者 Logstash 内是怎么处理的？另外容器日志定期删除的策略是什么？

A：这是个好问题，需要分拣的日志会在 message 的开头做特定的标记。例如[DATABEAT] 表示打点数据。ES 有很多工具可以做定期 archive 的，策略比如保留多少天，多少月，根据不同的数据的策略不同。

Q：Envoy 对性能的损耗有多大，自身的性能消耗有多大？

A：Envoy 是有性能损耗的，因为 API 的平均响应时间差不多在 100-150 ms，同时相比其带来的好处，我们认为这些损耗是值得的，所以我们具体并没有测算。

Q：gRPC 做了服务注册吗，gRPC 新增减少字段兼容性如何处理的？

A：服务注册/发现是基于 Kubernetes 和我们写的 Kubernetes Endpoint 到 Envoy eds 的转化服务做的。

Q：Istio 和 Envoy 什么关系？

A：Istio 包括一个控制面 + 数据面，Envoy 可以作为 Istio 的数据面的一个实现。

以上内容根据 2018 年 4 月 10 日晚微信群分享内容整理。

---

2018-03-27：Kubernetes 官方集群部署工具 kubeadm 原理解析

Q：etcd 的升级是怎么处理？

A：etcd 也可以由 kubeadm 进行管理，这种情况下，etcd 的升级也就可以由 kubeadm 来进行了。可以参考分享中 kubeadm upgrade plan 中的提示。如果 kubeadm 配置为使用外部 etcd，则需要自行进行 etcd 的升级。

Q：你们使用的网络插件是？

A：我们使用的是中兴通讯自研的网络插件 Knitter，该插件可以原生支持多网络平面，适合 NFV 的场景。

Q：kubeadm 可以指定仓库地址，不然在国内就得先注入镜像，你可以试试。

A：对的，在分享中关于雷区的说明中有提到可以为 kubeadm 指定可用的第三方镜像库，需要在启动参数中进行设置。

Q：Dashboard、网络组件、日志这些组件是不是都需要自己再安装？这些安装过程有没有介绍文档？有没有办法通过 kubeadm 导出每个版本的镜像名字，这样可以通过 GitHub 和 Docker Hub 关联导出镜像。

A：对于您提到的其他组件，都是需要自己再安装的，直接按各个组件官方的安装文档进行安装即可。kubeadm 使用的 master 组件镜像名字一般为类似这样的名称：gcr.io/google_containers/kube-apiserver-amd64:v1.9.6。

Q：一定要使用 etcd 吗，可以用其他的数据库代替吗？

A：目前 Kubernetes 只支持使用 etcd，在大约两年前，社区有关于支持 Consul 的讨论，不过后来不了了之。

Q：etcd 默认有做故障恢复吗，如果没有，有没有好的方案？

A：由 kubeadm 启动的 etcd 应该是没有做故障恢复，个人理解可以通过建立外部 etcd 高可用集群的方式达到目的。

Q：knitter 能描述一下吗，跟 Calico、Flannel 有什么区别呢？你们有测试过多高的负载？

A：knitter 已经开源，可以在其项目地址查看其说明：ZTE/Knitter。不过由于刚刚开源不久，上面的文档还不是特别完善，敬请保持关注。

Q：CA 证书过期怎么处理？

A：kubeadm 创建的 CA 证书默认的有效期是 10 年，一般情况下不需要考虑 CA 证书过期问题。不过 apiserver 的证书有效期默认的是 1 年，这个需要考虑过期问题。我在 1.9 中提过一个 PR，在升级集群的时候，如果发现 apiserver 的证书到期时间小于 180 天，会重新生成其证书。

Q：我看过 kubelet 默认有主动注册的选项，如果提供证书密钥应该就不需要使用 kubeadm join？

A：是的，不过这个前提就是像你所提到的，需要它已经有相应的证书密钥，如果不使用 kubeadm join 的话，就需要手动去为它创建证书和密钥，可能还需要一些其他配置，过程比较繁琐。所以如果集群是由 kubeadm 来管理的话，还是建议使用 kubeadm join 来加入。

Q：kubeadm join 使用的 token 是不是有时效的？

A：对，我记得这个时效应该是 24 小时，如果超过时效，可以使用 kubeadm token create 来重新生成一个 token。

Q：kubectl get daemonset -o wide --all-namespaces 可以查到 kube-apiserver-master 的是 self-hosting 模式吗？

A：如果通过该命令可以查到，那应该就是了。kubeadm 在这些 DaemonSet 的名字中统一加了”self-hosted-“前缀。

以上内容根据 2018 年 3 月 27 日晚微信群分享内容整理。

---

2018-03-24：新东方利用容器技术在用户自服务方面的探索

Q：为什么不直接使用 Kubernetes 提供的编排方式？

A：新东方的 IT 人员与业务人员比值是比较低的，因此在小团队下直接搞 Kubernetes 是个不现实的事情，小团队，项目时间紧 ，先解决”有”的问题，综合起来看最后选择了 Rancher，我们的二期项目将基于 Kubernetes。

Q：混合云的话，网络组件用的哪个？

A：用的 Rancher 内置的 VXLAN，现在部署的环境完全在私有云部分部署。

Q：监控方案是什么？

A：监控暂时使用的是 Rancher 社区内置的普罗米修斯，宿主机层面沿用了 Zabbix，我们目前 Zabbix 监控非常完善了。普罗米修斯还在研究中。

Q：请问为什么不直接用 Helm？ 相关的包管理功能更加强大。

A：确实 Kubernetes 和 Helm 更强大。 但是对于一个刚刚接触容器的团队直接搞 Kubernetes 的成本还是有些大。我们不可能让所有人等我们一年半年埋头搞，因此我们选择了 Rancher，大家都会 Docker，都知道 docker-compose，稍微学一下就上手了。

Q：请问 Rancher 在 CI/CD 方面是如何做的？

A：CI/CD 这部分，之前我们自己搞过 Jenkins，后来 Rancher 出了 Pipeline 工具。Rancher Pipeline 也是基于 Jenkins，集成了 GitLab 和 GitHub，并配置了 UI，用户体验还不错。我们自己的镜像打包现在都切换到 Pipeline 了。Jenkins 部分准备直接交给测试部门来搞，我们配合他们，因为他们搞 Jenkins 更专业。

---

2018-03-11：聊聊 Docker 监控那点事儿

Q：既然当前已经存在很多指标监控方案，你们是基于什么考虑要自己写的？

A：因为现有的方案都是独立的系统，我们的监控对象可不止容器，而且排查问题的时候可能还需要看宿主机的监控、网络设备的监控等等，我们需要把容器的集成进来；另外用开源的方案不好做定制化。

Q：容器发生 OOM 时，计算的内存是包括 Cache+RSS 吗？生产环境经常会发生业务容器 OOM，可以从那几个方面排查问题，并解决？

A：是的，排查问题当然要基于监控，看是否是使用内存一直不释放，我们遇到的 OOM 一大部分都是应用本身有内存泄漏；这在使用虚拟机的时候没有暴露出来，在用 Docker 时候资源给得更少了就暴露出来了。

Q：是否可以将 Pod 下所有容器汇总的指标作为 Pod 的性能指标呢？

A：对于 Kubernetes 来说就更容易一些了，可以通过 kubelet API server 直接来获取的。

Q：当遇到偶发的 CPU throttled 情况，是否意味着已经开始出现性能瓶颈？

A：不是，CPU throttled 是在一个 period 里面 CPU 的时间片到了限制触发的，如果是 job 类型的应用，是会偶发 cpu throttled，这时候可能不需要关心。

Q：现在针对容器的监控方案特别多，也基本上很完善。比如 Telegraf 采集、普罗米修斯采集等。想问下，你们那边现在的告警是怎么做的？

A：告警现在我们更多地配置在应用上，这样反应地最直观。如果要在容器层面做的话，建议对持续的 CPU throttling 和 mem failcnt 做告警。

Q：请问指标的存储用的是什么数据库？

A：之前用的 Elasticsearch，现在用的 InfluxDB，自己包装实现了一套集群。

Q：对于无状态的 Java 微服务容器，是否有必要进行监控？

A：这个最好在应用层去监控，但是在排查问题的时候还是需要容器层面的指标数据。

Q：其实监控本身并不是最终目的，监控是为了发现问题然后解决问题，对于 Docker 容器问题的定界定位有什么好的方案？以 OOM 为例，监控可能会触发一个内存高的告警，那么下一步该如何定界定问题根因呢？

A：是的，这一般是开发者和 Docker 运维经常扯皮的地方；这个时候需要结构应用的监控来看，例如 OOM 来说，如果是 Java 应用就是看到 heap 的使用一直上升，那肯定是应用方去查问题了。

---

2018-02-03：基于 Kubernetes 的 DevOps 实践之路

Q：iSCSI 挂载 rbd 到 Windows Server 的性能如何？是用 tgt 来实现吗？

A：是的， 您可以查看这个文档 use-iscsi-to-windows。至于性能，目前存放了几 TB 的数据，只有网络是瓶颈（千兆）。

Q：多套环境通过 Kubernetes 如何分割开的？

A： 通过不同的 namespace，前端 Nginx 代理通过不同环境监听不同 IP 实现。

---

2018-01-26：TensorFlow on Kubernetes 的架构与实践

Q：Worker 为什么不直接用 Pod，而用的 Job？

A：Kubernetes 中是不建议直接使用 Pod 的，建议通过一个控制器（RS、RC、Deploy、StatefulSets、Job 等）来创建和管理 Pod。

Q：我看训练的时候并没有指定数据集和训练参数等，是都放到训练脚本内了吗，还有训练集是放到 Gluster，挂载到容器内吗，还是换存到本地？

A：目前训练数据和参数都是在脚本里用户自己搞定，正在把这些放到 Portal，提供”命令行参数自定义”的能力。目前我们的训练数据是从 HDFS 集群直接走网络读取，Kubernetes 本身也没有 HDFS 的 Volume Plugin。

Q：请问 PS 的个数是用户指定还是根据 Worker 的数量来指派？

A：PS 和 Worker 数都是通过用户指定，但实际上都是用户根据自己的训练数据大小来计算的。

Q：分布式训练的时候，Training data 是如何分发到各个 Worker 节点的？Tensorflow API 可以做到按节点数自动分发吗？

A：各个 Worker 都是从 HDFS 集群读取训练数据加载到内存的。数据的分配都是用户自己在脚本种实现的。

---

2018-01-17：Kubernetes 存储系统介绍及机制实现

Q：Kubernetes 和 Cloud Foundry 有什么区别，优势在什么地方？

A：Cloud Foundry 更像是 Application PaaS，Kubernetes 主要是 Container PaaS。CF 不会直接把 container 层暴露给用户，Kubernetes 则不然，你可以直接访问 container。个人觉得 kubernetes 的部署和使用更简单，更直接，操作起来也更方便。

Q：请问对于 Galera Cluster 的集群存储如何设计存储方案，CSI 有考虑有状态储存的解决方案吗？

A：对于有状态服务，请使用 StatefulSet 来部署你的应用。Volume 只是一个存储的地方。StatefulSet 会负责给 Pod 设置顺序等等，保证是有序的，优雅的删除停止和扩展。

Q：有没有对象存储，比如 CephRGW，在 Kubernetes 集群中的使用案例，比如用户通过客户端上传、下载 PVC 中的数据之类的？

A：有试过 RGW 来存储数据，但是性能不是很好，速度要慢很多。在 Kubernetes 集群中可以使用 RGW 来存储一些静态的文件，比如配置文件，Nginx 静态 html 文件之类，用户也可以下载 PV 中的数据。不建议对 RGW 中的数据进行频繁的更改。

Q：能否详细说下 CSI？

A：CSI 在 kubernetes v1.9 才引入。这部分内容比较多，可以去看看 CSI 文档，以及 Kubernetes 官方的介绍，以及 这个 feature 实现代码。

Q：RBD 用什么插件，有没有什么坑？

A：需要在 kubelet 节点上安装 ceph-common{.prettyprint}这个包，在 volume mount 的时候，会调用相关的命令。基本上没什么坑，RBD 提供的 volume 还是很好使的。

Q：存储这块 IO 性能下降大概多少呢，有实测过吗？

A：存储的性能与 Cluster 的能力、存储的类型有很大关系。实测过 RBD 的 IO 性能，当然 case by case，当时测出来的结果还是很不错的，相比较与 CephFS、GlusterFS。

Q：多个 Pod 共享一个 Nas，是否可行，需要注意什么？

A：可行，但是需要注意 Volume 的读写权限，这个可以通过 mount 时候的 PV 的 access mode 进行设置，比如 ReadWrite、ReadWriteOnce 等等。

Q：CSI 和社区孵化的 volume provisioner 有什么区别？

A：CSI 的主要目的还是为了给容器存储定义一个统一的接口，方便进行定制化，以及新功能添加。社区孵化的 volume provisioner，你指的应该是 external-storage 这个项目吧，这个项目的主要目的是为了方便对 in-tree 的那些 Plugin 进行修改和定制，这样可以独立地进行更新。

Q：请问你现在有把 MySQL 可以放进 PV 里面么？求介绍这方面的经验。

A：如果只是单节点的 MySQL，直接放进 PV 就好了，跟其它正常服务一样。对于多节点的 MySQL Cluster，在部署的时候就需要注意了，建议部署成 StatefulSet，有状态的服务。之前有试过用 Galera Cluster For MySQL 来部署集群，发现效果不是很好，尤其是在随意启停 Pod 的时候，Cluster 的没办法自组成新的集群，新节点也无法加入集群。你可以再次试验下，确认一下。 后来使用 MySQL Cluster CGE，效果很好，Cluster 能够及时回复并重新组织起来。

以上内容根据 2018 年 1 月 16 日晚微信群分享内容整理。

分享人徐迪，Kubernetes 社区 Member，毕业于上海交通大学，有着四年的开源软件开发经验。曾任职于 IBM 从事 Openstack 的开发，对 Kubernetes，Docker 以及微服务架构有丰富的经验。目前在 Arm 主要从事开源社区的相关研发工作。

---

2018-01-10：一个可供参考的企业应用容器化实践案例

Q：所有开发人员都是用一套 OpenShift 集群测试吗？CI/CD 也是同一套环境吗？

A：我们是按业务分的，原则上，一套业务线（一个业务部门）用一套系统，这样成本上也好分摊。

Q：OpenShift 也是用 Go 编写的？

A：是的，OpenShift 用的是源码级别的和 Kubernetes 的集成，不是通过 client-go 或者 REST API 的方式，所以我们可以看到，Kubernetes 发型的版本总是比 OpenShift 的快 1 到 2 个版本。

Q：对于 OpenShift 比较适合多大规模的团队？

A：这个怎么说呢，其实引入 DevOps 或者 CI/CD 的流程就是为了给企业减少人员成本，让有些能够自动化的东西通过计算机运行起来。所以因该是人员越少越好，但是人员如果少，就要求每个人的技术能里比较强，开源的东西往往用起来不难，但是真到出了问题的时候就需要看代码去解决了。所以如果人少的话，可能每个人就要求懂得就比较多一些。

Q：router 本身是否具备 HAProxy？

A：OpenShift 的 Router 就是用 HAProxy 实现的，当然我现在用的是 3.6.1 的版本，我不知道以后会不会支持 Nginx 或者其他别的 LB，因为我看到代码里已经有关于 Nginx 的相关配置了，但是没有激活。OpenShift 使用 HAProxy 的大致流程就是通过一个 Yaml 或者 jason 文件，配置一条 route 信息，然后通过 api-server 持久化到 etcd 中，router 的代码启动一个 goroutine，去通过 api-server watch etcd，然后根据配置信息和环境变量，通过 haproxy-template 模版，去生成 haproxy.conf，然后去动态 reload。

Q：OpenShift 的 project 和 Kubernetes 的 namespace 是一对一的关系么？project 可以设置资源配额么？怎么设的？

A：是一对一关系，当然有一些 namespace 是有一些特殊意义的，不建议在里面跑应用。project 可以设置资源配额，具体怎么设置就比较复杂了，建议参考一下官方文档，简单的说就是可以根据 CPU 内存做资源的限定，这个和 Kubernetes 是一样的。

Q：OpenShift 中原生性能指标监控服务的 Pod 总挂有没有相应的解决办法？

A：解决 Pod 总挂的问题就得具体问题具体分析了，我记得它做性能监控的那个 Pod 比较吃资源，其实可以对他进行一下限定，比如：oc env rc hawkular-cassandra-1 MAX_HEAP_SIZE=1024M -n openshift-infra。

Q：OpenShift 中的 router 默认情况下是跑在 Pod 里的，那么当 service 特别多，route 规则也特别多的时候，如何解决 router 服务的性能问题的？

A：这是一个好问题，但其实我觉得这个和 HAProxy 有很大的关系，跟在不在 Pod 中关系不大，因为 router 这个容器其实用的是主机网络，那么这个问题其实就转化成了如何提升 HAProxy 的性能，这种情况其实有很多可以参考的方案，比如前面在加一层 LVS 负载，或者用 DNS 做域名解析的时候进行一定的负载功能。

---

2017-12-26：分布式配置中心架构与实战

Q：请问配置中心存储的是配置文件还是 key-value?像数据库连接串之类的信息如何管理的？跟数据连接池怎么配合？

A：是 key-value 的，存储在 etcd 集群上，服务可通过 hawk-client 拉取配置到服务本地生成本地的配置或直接导入到本地环境变量，这些配置随着服务启动就会生效。

Q：为什么要自己开发一个配置中心，而不是直接使用 Spring Cloud Config？

A：其实很很简单，单纯的 Spring Cloud Config 没有办法充分地切合企业系统的生产需要。我这里有一个功能对比图，大家可以参考一下：

Q：请问这个配置中心只能应用于 Java 语音吗？

A：配置中心的代码是 Java 编写的，但是配置中心的使用方，即拉取配置的一方是不限制语言，因为配置拉取是基于 http 协议。

Q：请问 CI/CD 流程控制是自己研发的还是用的开源方案？

A：CI/CD 持续集成，持续交互其实是一个很大的概念，我理解你想问的是 Hawk 的操作流程以及所使用的技术栈的问题，最初我们参考过其他的一些开源比如携程的 Appolo，百度的 Disconf 等，结合他们的一些理念，我们又自己总结思考了自己的需求，对 CI/CD 的业务做出归纳，以达到简单直接的目标，技术方面，我们主要用到 Spring Boot， Spring Cloud 以及 etcd 等技术，其中 Spring Cloud 主要适用于服务注册发现，服务治理等方面。

Q：我想问下，关于配置中心部署问题，第一个，不同环境或者不同集群，你们配置中心是怎么部署的，还有，一些基础组件配置和应用配置放在一个配置中心吗？

A： 配置中心通过不同的存储集群，可以实现一个配置中心服务多个环境，但是原则上，建议测试，开发公用一个不熟而生产独立部署，配置中心的中心概念是基于微服务，所以从概念上说，我们的配置是生效于一个服务下的实例级别，而不是组件级别，每个实例下又分为不同的命名空间，命名空间可划分为：应用层，环境变量和自定义的组件，可由客户自定义，所以原则上涵盖了组件与服务的概念。

---

2017-12-25：在项目实践中，如何进行容器化改造和 DevOps 建设？

Q：您确定你们是 FTP 做文件管理？

A：FTP 只有用于存放活动宣传的图片，在容器环境中，需要把这些图片同步到 stN 容器中。

Q：用 Jenkins 测试完了以后如何发布到生产环境的？

A：由于这个项目的客户是开发和测试环境中一个容器管理平台，生产环境一个容器管理平台，开发测试写成，生成生产环境的镜像 tag；由于生产环境的应用 stack 更新，需要通过手动触发，进行更新。

Q：请问，日志的话，是不是每个服务都有规定格式？

A：做应用容器化改造，需要进行应用日志的收集，这样需要规定应用日志输出的格式和目录。这样方便进行统一的日志收集与管理。

Q：这个环境支持应用一键部署到公有云嘛？

A：如果使用 PaaS 云混合云部署，是可以支持一键部署到公有云环境中。

Q： 哪些类型的应用和系统，不适合容器化呢？

A：有一些对 IO 要求太高的应用或系统，不太适合容器化。

Q：请问数据库是怎样部署的，有进行容器化吗？

A：此客户项目实施中，使用 MySQL 和 MongoDB 两种数据库。其中 MongoDB 集群部署，做了容器化改造；另外，MySQL 数据库使用阿里云的 RDS 数据库，没有容器化。阿里云平台提供服务库服务和备份，快照。

Q：AKF 原则可以详细介绍嘛？

A：AKF 扩展立方体（参考《The Art of Scalability》）技术专家抽象总结的应用扩展的三个维度： Y 轴 ：是功能分解，将不同职能的模块分成不同的服务。从 y 轴这个方向扩展，才能将巨型应用分解为一组不同的服务，例如订单管理中心、客户信息管理中心、商品管理中心、支付系统等等。 详细请参考《The Art of Scalability》

Q：如何切换开发、测试、生产环境的参数配置？

A： 如果您有三个 Environment 环境，开发、测试、生产环境需求；我们可以创建三个环境分别如下：DEV（开发环境）、TEST（测试环境）、PRO（生产环境），每个环境下面的应用栈与其它环境想到隔离，互不影响；如果需要切换管理，只需要在管理平台中进行 ENV 环境的切换，即可对相应的环境与应用栈进行管理。

Q：请问目前监控使用的是什么方案？

A：容器管理平台本身是基于 cAdvisor 可以监控实时容器指标 CPU、Menory、I/O、网络资源资源。同时，它也可以部署使用其它监控应用栈。例如：Prometheus、Grafana、Datadog 等。

Q：代码怎么部署到容器中，是通过外部硬盘挂载吗，是不是每次都重新生成新的镜像？

A：容器本身是生命周期比较短暂，而且会根据策略自动迁移。一般不会把代码代码通过外部挂载到容器。通常做法如果代码变动或更新，重新 build 镜像。可以根据自己定义是时间段进行 build 镜像。

Q：对于数据库集群，现阶段是怎么运维的，有案例？同时对于数据安全是怎么保证的？数据的备份采用什么方式？

A：针对数据库集群的运维，这个是一个针对性很强的专业问题；数据库的备份/还原、监控、故障处理、性能优化、升级/迁移、健康检查，用户反馈数据库问题等等，这些都需要专门的 DBA 处理。数据库运维总原则：第一：能不给数据库做的事情不要给数据库，数据库只做数据容器；第二：对于数据库的变更必须有记录，可以回滚。 数据库的安全至关重要，有相应的权限管理，以最低粒度的控制权限。所有开发人员权限粒度到表一级，数据库管理员和系统管理员权限粒度到库一级等等。不同的数据库以及部署方式不一样，要求的备份也有差别。以 MySQL 为例，如果搭建主从架构，就要通过 binlog 文件同步复制主库的数据。另外，通过系统计划任务执行 mysqldump 做周期性全备份；还有，物理备份，直接拷贝数据文件、参数文件、日志文件。最后，专门的备份工具如：mysqlhotcopy、ibbackup 等。

---

2017-12-22：JDOS 2.0：Kubernetes 的工业级实践

Q：请问 Skynet 网络基于 OpenStack Neutron 吗？

A：我们的 Kubernetes 的网络是分为两套。最开始我们使用的是 Neutron，因为我们的 JDOS 1.0 已经稳定运行了多年。今年开始，我们很多数据中心采用的是 BGP 的网络。可以参考 Calico 的实现。

Q：LVM 的磁盘 IO 限制是怎么做的？

A：这是通过改造 kube-apiserver 以及 kubelet，把磁盘限制的指标也作为一种资源，底层最终使用 Cgroup 实现的。

Q：巡检工具是只检查不修复吗？

A：是的，巡检的目的就只是检查并通知，一般有问题会找运维修复。

Q：使用的什么 Docker storage driver？

A：我们 JDOS 1.0 是使用的自研的 Vdisk，2.0 使用的是 DM。

Q：为了提升 Pod 更新速度，我们对容器删除的流程进行了优化，将 CNI 接口的调用提前到了 stop 容器，没太明白这里。

A：删除容器的流程原本是 stop app 容器-> 调用 CNI->stop sandbox 容器。因为在实际中，stop app 容器时间会较长。因此我们将其调整为调用 CNI->stop app 容器->stop sandbox 容器。这样可以更快释放 IP。

Q：有用 PV PVC 吗？底层存储多的什么技术？

A：有用到 PV PVC，底层存储使用的是我们自研的 ContainerFS。目前已经开源在 GitHub 上，欢迎使用。

Q：请问相同 Service 的不同 Pod 上的 log，fm，pm 怎么做汇总的？

A：Pod 的日志是在每个节点上，启动有 daemonset 的一个容器，负责收集该节点上的日志，并发送到消息队列予以汇总的。

Q：能详细描述一下”gRPC 的问题导致了 apiserver 的性能瓶颈”的具体内容吗？

A：在 1.6 我们原来使用的单个 apiserver 在服务大概 300 个节点时，就会大量拒绝请求，出现 409 错误。后来我们查阅了社区的相关资料，发现是 gRPC 的问题，通过升级 gRPC 包，可以实现 600 以上节点无压力。

Q：请问多 IDC 的场景你们是如何管理的？

A：目前是分多个数据中心，每个数据中心再划分多个集群。控制单个集群规模，这样方便管理。但是镜像、配置、调度可以在不同数据中心、不同集群间通用。这样集群和数据中心对用户透明。

Q：加固环节（包括 etcd 故障、apiserver 全部失联、apiserver 拒绝服务等等极端情况）上面列举的几种情况发生时会造成灾难性后果吗，Kubernetes 集群的行为会怎样，有进行演练过不，这块可以细说一下吗？

A：当然，如果未经过加固或者不能正常恢复 etcd 数据，还可能导致 pod 大量迁移或销毁，甚至整个集群节点压力增大，发生雪崩效应，最终整个集群崩溃。

Q：Pod 固定 IP 的使用场景是什么？有什么实际意义？

A：呃，这个实际很多业务，特别是一些老业务，是无法做到完全无状态的。如果不能提供固定 IP，那么他们的配置上线都会很麻烦。

Q：请问有使用 SR-IOV 或者 DPDK 的技术吗？如果目前没有，是有哪方面的考量，将来会考虑吗？**

A： 有啊，可以参见我们的团队的分享：mp.weixin.qq.com/s/ZPDU66B_Cr1Zgb-k6t1zUA。

Q：请问系统开发完毕后，下一步有什么计划？进入维护优化阶段，优秀的设计开发人员下一步怎么玩？

A：容器化，自动化这才是万里长征的第一步啊。我们已经在调度方面做了很多的工作，可以参看我们团队关于阿基米德的一些分享。集群自治与智能化，我们已经在路上了。欢迎大家一道来实践。未来我们也会同大家分享这其中的经验。

Q：应用滚动升级，有无定制？还是采用 Kubernetes 默认机制？

A：是我们自己定制的 deployment，进行了适当的改造，可以支持暂停状态，比如说更新时，可以指定两个版本的 Pod 个数比例，中止在这个中间状态。

Q：能否介绍一下对 GPU 支持这块？

A：GPU 我们的玩法其实很简单，就是一个容器一块卡，每个卡只分给一个容器。这样的好处是安全，分配效率高，利用率也比较高。

---

2017-12-16：东方国信基于 Kubernetes 构建容器云平台的实践和思考

Q：请问不用 Jenkins，开发 shera 基于什么考虑？

A：刚开时，我们也用了 Jenkins，但是很难跟我们的多租户结合，所以我们就干脆自己开发一套了。

Q：请问灰度发布如何实现的？

A：灰度发布时通过一个 service 对应两个 rc 来实现，一个 rc 管理老的应用，一个 rc 管理新的应用。

Q：Pinpoint 是 Tomcat 启动时候加载的，不重启应用的情况下，如何控制 Pinpoint 开关？

A：我们增加了环境变量，通过脚本判断环境变量，然后控制 Tomcat 启动。

Q：请问挂在的 Ceph 存储的方式是什么，块还是文件系统？

A：块和文件系统我们都有用，需要多实例的就用文件系统，MySQL、Redis 等，就用的块。

Q：有没有把 MySQL 或者 Redis 之类的中间件放入容器中运行，如果是如何调试，如果没有，如何实现弹性扩容？

A：放到容器里面了，我们会把日志存储到块存储里面，我们也提供了 shell，可以登录到容器内部进行调试，有日志，又有命令行，运维基本没问题。我们暂时没有做 MySQL 和 Redis 的扩容和缩容，主要是 MySQL 用于测试使用，单机版就够了，等我们使用本地存储来存储 MySQL 数据时，我们会考虑做主被、双主、扩容等；Redis 我们提供单机版和 8 节点的集群版本，只是内存可以扩容，节点个数是不能变化的，8 个节点每个节点最大 16G，我们所有的业务都能满足了。

Q：请问 Ceph 是如何管理的，申请和开通挂载都是自动的吗？用的 CephRBD 吗？

A：有自动的也有不是自动的，我们有界面可以申请存储和进行快照管理，这就不是自动的，MySQL、Redis 这些应用我们是用的 PVC 自动管理的。RBD 跟 CephFS 都有用。

Q：使用 Ceph 承载有状态服务的数据持久化有遇到什么坑吗？

A：没有太多坑，就是 Scheduler 镜像里面没有 Ceph 的 RBD 可执行程序，需要自己重新做一下镜像，把 RBD 放进去。

Q：请问这个系统用了多少人多久完成的？

A：2 年前我们开始做容器，整套系统用了 20 多人开发调试了 1 年多，后面我们又做的升级，然后把 MySQL、Redis、Kafka、ZooKeeper、ActiveMQ、TensorFlow 等弄了进来，现在还在做 Hadoop 的容器化。

Q：请问这套架构，从规划到实施到推广完成用了多久？

A：推广周期很长，去年下半年推广上线了一匹业务，今年公司全部的产品都开始推广使用这套系统，所以说推广完用多久，不好说，现在也是边开发边推广。

以上内容根据 2017 年 12 月 12 日晚微信群分享内容整理。 分享人崔东：东方国信容器云技术负责人，主要负责国信容器云平台的架构和实现，支持公司各产品线的云化。

---

2017-12-13：Docker 在测试中的应用

Q：你好，我是 Docker 初学者同时对测试工作不是特别了解，我能简单的理解你们是根据 Web 界面填写的压测需求然后生成很多的 Docker 容器充当客户端去大量请求你们服务，然后达到压测效果的吗？

A：您理解的对，因为在传统的压测需求中，多台压测端的部署是个麻烦事，并且一台主机如果重复利用，环境管理是个很麻烦的事情，所以我们才有使用 Docker 的想法。

Q：想请问一下压力测试，都会对服务做那些方面的测试，比如有没有是高并发等？

A：一般来说，性能压测就是模拟多用户，一般是阶段性的压测，并发。我们关心的结果，业务的返回码，平响，平响分布时间等。

Q：Flannel 端口暴露和接口封装是怎么实现的，还有 Web 界面用的是什么？

A：Flannel 的 IP 暴露问题，您查询一下 Flannel 官网，这个网络插件可以达到暴露 IP、端口的目的。接口封装，我们主要是将 Docker 的原生接口进行了封装，达到可以控制多台 Node 的功能，主要封装了创建网络、service，容器等接口。Web 是采用 Python 的 Django 框架。

Q：非常感谢分享，我也是从事性能工作的。我有两个问题希望能解答下。第一个问题，对压测本身而言，关注的不仅仅是应用层面的性能，更多是为了明确的测试目标而设定的特定场景，我想问的是，Docker 在这方面如何定位性能瓶颈出现在哪个层级？第二个问题，如何利用 Docker 模拟生产环境的压力，比如全链路压测，JMeter 是否还适合这样的业务场景，有没有其他的解决方案？

A：我们的 Web 是提供传参功能的，用户可以自定义参数或参数列表，达到多样型的测试。并且我们提供用户自定义流量包的功能。到目前为此，压测过程中的瓶颈会偶尔出现在计算过程中，因为数据量大的时候后端计算时，会占用大量的内存。第二个问题，模拟生产环境，我们使用的是国产开源的 TCPCopy，您可以查询一下，原理就是 Dump 线上的流量，进行线下回访。或在特定时间回访到线上，不知道是否回答了您的问题。

---

2017-12-06：小型公司 DevOps 落地实践案例

Q：请问 Portainer 仅用于测试环境还是在生产也用这一套？

A：因为 Portainer 是直接通过 docker api 执行的，并没有在服务器上装有什么客户端（也就是无侵入，这也是我们选用他的原因），我们只是在 Docker 里面配置了个 http 的 TLS 证书，加上我们对它做了一些改造，所以我们使用了 Portainer 应用生产环境。

Q：请问下测试的时候接口模拟您这边是如何处理的？

A：Ostman 默认录入了几个多种情况下的出参，其次，我们前端每个人都有一套独立环境，通过 Web 端管理部署（数据库和测试人员共用），不会受后台开发人员对接口修改而中断服务。其次我们有少量前端页面使用了 mock.js。

Q：请问 Docker 里跑 Java 应用性能怎么调优，默认是共享资源池，对 Java 来说 CPU 切换很费性能，除了绑定 CPU，但这样就没有弹性之说，麻烦说下？

A：这个性能，我们对 Java 项目进行多次内存优化，通过 ide 的内存管理，线程查看等多重方法进行调优，单从 war 包体积上我们就缩小了 60%，内存也下调很多。我们并不能自动伸缩，目前是通过 Nginx 配置多容器来实现负载均衡。

Q：如何实现分布式事务？如何保证数据一致性？

A：我们在 Nginx 层通过策略保证同一个机器请求只会分布到一台机器上，用最少代价解决这个问题，其次我们项目中，大部分都使用全局 uuid 操作和插库。

Q：贵司的业务模式跟我们很像，感觉很受用。想问下，多客户、多版本共存的情况下，版本升级这块儿是怎么做的？

A：我们使用的是 Git 分支化管理，由 Jenkins 定义版本号，SQL 分为公共和私有的部分，比如某个客户升级 2.0.0 版本，会自动检测上个版本到此时的 SQL 语句，提示项目经理点击，自动执行。（我们现在回滚项目版本，不支持 SQL 回滚，所以我们 SQL 一般只增不减、不改），我们可以随时查看某客户线上版本和 SQL 执行到什么地方。

Q：日志如何存储和分析？用什么工具？系统异常如何监控？

A：先说说异常如何检测吧，我们做了一套 http 监控框架，以任务的形式添加，然后会对已配置的线上环境、多容器进行监控，比如任务为 http://xx.com/..../messages?token=>{token}，在配置任务执行时间及频率，然后配置项目列表，其中项目编辑的信息有 host，可理解为 http://xx.com/ 这块，还有变量列表，支持随意定义，比如 token 11111111 用户 token 信息，这种 k、v、说明文字，执行任务的时候，自动替换 host 和占位符。系统只记录变更，我们项目接口统一了出参，当状态码异常时显示，此方案可实现监控各种容器、各种测试、生产环境。

---

2017-11-15：Kubernetes 调度详解

Q：普通用户有自定义 Pod 优先级的权限吗？

A：可以，Pod 优先级定义与创建普通 Pod 类似，并没有特别权限控制。定义 Pod 优先级，需要先定义 kind 为 PriorityClass 类型的资源对象，然后通过在 Pod 的 spec. priorityClassName 中指定已定义的 PriorityClass 名称即可。

Q：Kubernetes scheduler extender 能介绍一下么？

A：extender 可理解为 Kubernetes 调度策略和算法的扩展，属于自定义调度器的一种方式，与 Kubernetes 默认调度器的过程类似，主要是针对一些不算受集群本身控制的资源（比如网络），需要通过外部调用来进行调度的情况。

Q：用户使用了 NodeSelector 指定了 Pod 调度的 node 节点后，如果 node 不可用，那么 scheduler 会采用别的策略吗？

A：nodeSelector 是目前最为简单的一种 pod 运行时调度限制，目前在 Kubernetes 1.7.x 及以下版本可用。Pod.spec.nodeSelector 通过 kubernetes 的 label-selector 机制选择节点，由调度器调度策略匹配 label，而后调度 Pod 到目标节点，该匹配规则属于强制约束，如果 node 不可用，Pod 会一直处于 pending 状态。nodeAffinity 具备 nodeSelector 的全部功能，所以未来 Kubernetes 会将 nodeSelector 废除。

---

2017-11-08：Kubernetes 的多集群管理实践

Q：Node 机器推荐命名规则与生成使用经验？

A：推荐使用”地理位置 + 机房编号 + 机柜号 + 应用名称”的缩写字母来命名，这样便于运维人员后续的管理和维护。

Q：为什么要修改 etcd 与 apiserver 的监听端口？

A：修改 etcd 监听 IP 为 0.0.0.0 是为了防止出现监听了 lo 网卡的 127.0.0.1 的 IP，出现不能连接的情况。apiserver 则是开启 8080 端口用于接收 http 请求，这样是为了测试时方便不用使用 CA 证书认证。

Q：请问 Docker 源怎么弄，国内一般不好连接，下载不了？另外还有 1.6 要升级到 1.7 怎么做？

A：建议使用科学上网方式，这样就不需要改动配置。1.6 升级到 1.7，先停止 Kubelet 服务，然后下载 1.7 版本的 kubernetes-server-linux-amd64.tar.gz 包，解压替换/usr/bin 目录下的同名文件，然后再把 Kubelet 服务启动。

Q：在联邦集群中部署服务，可以将服务只部署在一个集群中么？

A：可以只部署服务在一个集群中，通过编排文件中 federation.kubernetes.io/replica-set-preference 来控制副本分布在哪个集群。

Q：联邦集群的几个组件现在有支持高可用么？没有的话，我们应该怎么避免联邦组件的 bug 导致的服务不可用？

A ：联邦集群的 Federation 组目录没有支持高可用，但联邦功能主要是为了调度管理 Kubernetes 集群的，所以联邦集群 Federation 组件出现故障时并不会直接影响到下面各个集群自身的已经在运行的服务。

Q：根据应用地理区域需求，调度工作负载到不同的 Kubernetes 集群中，对于不同的终端用户，提供更高的带宽和更低的延迟.这个调度到不同的集群，是 Kubernetes 根据地理位置调度吗？是 Kubernetes 自己调度吗？

A：工作负载 Kubernetes 可以自己调度到比较空闲的集群上，地理位置调度这个需要通过编排文件控制应用的容器分配到更合适的区域机房。

Q：是先建立 3 个 Kubernetes 集群，然后在 1 个集群的 master 上 kubefed init fellowship 是吗？

A：是的，在其中 1 个集群的 master 上安装 Federation 组件，然后把 3 个 Kubernetes 集群加进来管理。

Q：添加联邦集群文件时，里面的 serverAddress 是什么地址？

A：serverAddress 就是 Kubernetes 集群的 API server 的 IP 和端口，c1.yaml 里面的 serverAddress 就是集群 01 的 API server 的 IP 和端口，c2.yaml 里面的 serverAddress 就是集群 02 的 API server 的 IP 和端口。

---

2017-10-31：瓜子云的任务调度系统

Q：请问下自动触发 med-sdk 构建 Docker 镜像，med-sdk 是什么开源项目，能介绍下么？

A：med-sdk 是瓜子自行开发的一个工具，用于把代码打成 Docker 镜像包。每个 Git 里面只需要添加一个 med.yml 就可以实现。

Q：请问为什么要集成 Kubernetes？

A：Airflow 的 Worker 需要手动搭建，可扩展性不好；Job 代码更新之后，需要手动部署到 Worker 上，非常繁琐；Airflow Worker 的环境太多，由各个团队自行维护，维护成本太高；云平台搭建之后，所有机器都会被回收，各业务线拥有的机器将会很少，Worker 将会没有地方部署。

Q：Airflow 处理的调度量是什么规模，也就是批量任务会不会阻塞，一次并发有多少 Pod，多少容器实例，一套 Kubernetes Master 能否扛得住，方便给个数据量进行参考吗？

A：目前瓜子每天有 2000 个任务。任务的执行地点都是在 Kubernetes 上的，不会阻塞。并发的 Pod 个数是由同时处理的 Job 数定的，Airflow 的 Worker 有设置一个 Worker 可以同时跑几个 Job。我们并发 Pod 有 20 个。一套 Kubernetes 可以抗住我们的规模。数据量不好给，因为任务的计算量不好估算，有的大有的小。

Q：为什么不考虑 Celery 之类的任务队列？

A：首先是我们之前选用的是 Airflow，用 Python 写的 DAG，非常符合我们的需求，我们的 DAG 需求很大，比如数据仓库，所以选择了 Airflow。

Q: 有做过类似软件的对比么，差异在哪？

A：Kubernetes 目前被 Docker 官方支持。Mesos 用 C 写的，不好运维。Rancher 社区不够大。其实功能大家都支持，主要是社区。

Q：并发的容器数量是多少，实际的 Docker 实例个数量级，20 个 Pod 可大可小。方便给个参考吗？谢谢！

A：我们测过每台机的上限在 100 个，我们的机器是 128G，24cores。我们 Airflow 的 Worker 有 20 个 Pod。

以上内容根据 2017 年 10 月 31 日晚微信群分享内容整理。

---

2017-10-10：乐高式微服务化改造

Q：配置中心使用 Consul 的配置共享，有没有考虑过？

A：我们的配置中心里面除了键值对形式的配置项，更多的是存储了文件形式的配置文件，而 Consul 一般存储的是键值对信息。另外，除了存储、读取配置的能力，我们还需要一些上层的能力，比如环境隔离、版本匹配、版本管理等，这些 Consul 也无法直接提供。

Q：今天讲的这些 Spring Cloud、Spring Boot、配置中心、授权中心等等，有没有好的入门书籍推荐下？

A：可以关注一下我的博客，里面提供了很多参考资源。emacoo.cn

Q：服务边界的划分，有没有什么好的建议？

A：这是一个好问题，也是一个见仁见智的问题。按照我目前的理解，边界至少意味着：1. 单数据库，保证数据独享；2. 各个服务层次清晰，无循环依赖。另外，很重要的一点是，随着业务复杂度的上升，一个微服务可能会需要进一步拆分，也就是说边界是跟复杂度挂钩的。

Q：微服务多大程度应该独享数据库还是共享数据库资源？

A：建议独享数据库，数据通过接口暴露给其他服务。

Q：请问下如果有一个 Spring Boot 服务挂了，能自动发现然后重启么？有没有什么方案推荐？

A：要实现这一点有很多方案。我们所有的服务都是跑在容器里面，借助 Marathon 的测活机制实现了服务意外宕机后的自动恢复。如果是非容器环境，可以通过监控平台（比如 Zabbix、Open-Falcon）实时监控服务并尝试恢复。

Q：看贵公司的架构，微服务是做了容器化部署的，微服务容器化之后采取什么样的网络方式暴露服务？

A：没错，我们所有微服务都是跑在容器里面的。测试环境通过 Marathon LB 暴露服务，生产环境通过 Consul Registrator 自动发现服务，然后由 Consul Template 定时刷新 LB 配置，LB 前面还有一层内网 DNS，最终服务调用方通过内网域名访问服务。

Q：集成 Nginx 实现负载均衡这个是怎么能实现的，能讲一下吗？

A：非常简单，利用 Nginx 自带的 upstream 特性，相当于一个虚拟主机挂多个服务地址。

Q：对一个系统做微服务改造时，什么样的功能或者应用不适合采用微服务模式，而是应该保留单体应用架构？

A：这也是一个很好的问题。在我看来，关键看两点，第一，业务复杂度以及团队对领域模型的熟悉程度；第二，团队技术实力，尤其是 DevOps 水平，看能不能 Hold 住微服务本身所需的技术框架，以及支撑微服务的各类中间件、运维平台。

Q：贵公司在进行微服务改造的时候，应该很难一下子全部改造成微服务同时上线，改造应用的顺序是横向还是纵向的？

A：对，我们采取的是改良式路线，基本的思路是，首先通过重构将原本单体应用中的某个模块的边界进行纵向划分，然后新建数据库、迁移老数据、双写新老数据库，最后等新服务开发完上线之后，再将原本同一应用里的代码调用切换为外部服务调用。

---

2017-09-26：BizCloud：基于 Kubernetes 的私有云实践

Q：有状态服务和无状态服务的主要区别是哪些？

A：有状态服务，是指服务器端具备上下文关系，如 Redis 服务，当服务挂掉之后，Redis 的内存数据丢失，我们不能简单地在另一个机器上拉起服务来恢复服务，必须同时恢复数据（状态），而无状态服务没有状态（数据）依赖。

Q：通过模板的方式，会不会影响灵活性啊？因为大多数配置都是基本固定的。

A：这个会牺牲一定的灵活性，但是会提升发布的安全性，并且达到对上层应用无感知。目前我们也会针对不同的应用类型定制不同的模板，如无状态服务、有状态服务的模板是不一样的。通过模板可以满足支持绝大多数服务需求，对于特定服务，我们也预留了特殊配置接口。后续我们也会尝试引入 Helm Chart 单元化模板。

Q：event 存在丢失的现象，请问如何处理？我觉得过度依靠 event 会造成很紧的偶合。

A：我们 watch event 的时候使用了 ResourceVersion，不会出现丢事件的情况，如果 watch 提示 ResourceVersion 过早，我们会先 List Pod，和服务管理模块做一次同步，清理脏数据。 出现过收到不完整 event 的情况，因为最初给 Kubernetes 加上 Nginx 代理时，Nginx 默认开启了 proxy_buffering，会收到不完整事件情况，关闭 proxy_buffering 解决这个问题。

Q：请问 k8s-monitor 是通过 Kubernetes 的哪个 API 监控到 Pods 的状态事件 ADD、MODIFY、DELETE？

A：kubernetes/client-go 的 watch API。

Q：能否讲下”Nginx 会实时从服务管理中心获取服务对应关系”的原理是什么？

A：我们在 OpenResty 基础上，通过 Lua 脚本从"服务管理中心"处查询和订阅服务对应关系，实时修改 Nginx 配置，进行负载均衡、服务发现。

Q：请问你们 Docker 是安装在物理机还是？

A：Docker 是安装在物理机上，而且 Docker 安装启动是需要 root 权限的。

Q：网络问题是如何处理的？没有使用自带的 service 吗？

A：网络问题是指我们的网络模式么？我们的容器分配的是一个内网 IP，对外部服务是可见的，如果发生了节点网络问题，在服务化这层本身会自动摘除这个节点，在调度层面一定超时后也会自动重新调度到另外一个节点上。我们没有采用 Kubernetes 的 service，原因是因为在早期 Kubernetes 的调研中，service 存在 iptables 条数过多导致性能下降问题，也担心 service 不稳定造成服务访问问题。

Q：请问下你们服务动态扩容是全自动化的么？

A：目前服务动态扩容是一键化的，不过我们也预留了一些 API，来实现全自动化，大致的方案是：云平台会对接一个统一监控中心，通过统一监控中心的实时监控数据（系统数据，流量数据），分析服务的访问压力，来实时扩缩容。

Q：问下你们程序包分发如何实现的，程序包放镜像内还是镜像外？

A：我们开发了自己的 CI 模块，可以一键从 SVN 中生程序包，然后成镜像，编译生成镜像的时候会从统一服务管理模块中获取必要的服务信息。程序包放在镜像内。

Q：请问你们 Docker 是基于 CentOS 制作的镜像吗？有什么优化地方？

A：是基于 CentOS 7.2 制作的镜像，我们在镜像中做了一些严格的权限控制，限制了应用的一些行为。

Q：WebShell 的话，是每个节点都有 Agent 的吧，还是通过 Kubernetes 原生提供的功能呢？

A：不需要每个节点都有 Agent，我们只要实现 Docker Controller 即可，Docker Controller 会去 Docker Daemon 上获取容器的具体信息。

Q：你们数据库集群是用的哪种方案呢，能介绍下吗？

A：无状态服务的话，就是使用 hostPath 本地挂载，日志数据我们会有实时采集的服务。有状态服务如数据库，我们目前还没有在生产环境进行大规模的数据库容器化。我们的基本思路是定制化 CRD + Ceph 分布式存储。也希望后面随着数据库容器化工作不断推进，能够和大家有更深入的交流。

---

2017-09-23：FreeWheel 基于 Kubernetes 容器云构建与实践：应用编排与服务质量保证

Q：这个东西的本质，是不是类似把 kubectl 的那一套指令做了封装呢，使操作简化？

A：不是的，Helm 的定位是 Kubernetes 应用的包管理工具，是对 Kubernetes 的补充而不是代替。Helm 对 Release 提供了非常强大的版本管理、配置以及 Hook 等功能，这些都是原生 Kubernetes 不具备的。

Q：Helm 是一个 cli client 对吧？tiller 有没有 API 可以调用？

A：是的。tiller 目前暂时不提供 API 调用，以 Pod 形式安装的 Tiller service，采用的是 clusterIP，然后 helm client 使用 kubectl proxy 连接。

Q：请问生产环境负载均衡和服务发现有什么好的方案？

A：对于生产环境负载均衡，可以采用 HAProxy/Nginx 等负载均衡器代替 kube-proxy 以求更好的转发性能。 对于 Kubernetes 服务发现：有 2 种方式，第一种是环境变量，第二种 Kubernetes DNS。推荐用 Kubernetes DNS，因为环境变量方式对 Pod 启动顺序有非常强的依赖，即先启动的 Pod 看不到在其之后启动 Pod 服务的环境注入信息。

Q：Kubernetes 的三种健康检查类型 exec，tcp，http 能在一个容器中同时使用吗？它们分别的应用场景是什么？

A：可以的，Kubernetes 并没有对此限制。但一般情况下，一个容器服务不会同时提供 TCP 和 HTTP 服务。 HTTPGetAction：适用于 HTTP 服务的健康检查，但使用前提是服务本身需要提供健康检查路径。

Q：使用 Helm 是否可以不用 kubectl 了？另外是否支持 Windows，支持的话如何配置呢？

A：不是的。Helm 是 Kubernetes 应用的包管理工具，对 Kubernetes 来说，Helm 是对其 Release 版本管理、配置等功能的补充。

---

2017-09-21：容器云在万达的落地经验

Q：Grafana 是实时显示数据的，请问他如何能做到告警？就是 grafana 达到一定告警阈值时做告警？

A：Grafana 新版本中添加了简单的告警功能，在 Notification Channels 页面有个新建通道，在里面设置一下，具体可以看下官方的文档。

Q：请问如何实现容器限速的？

A：你是说容器的网络限速吗？流量限制功能我们是通过在 pod 的 annotations 字段设置 kubernetes.io/ingress-bandwidth （设置输入流量带宽）和 kubernetes.io/egress-bandwidth （设置输出流量带宽）来实现。

Q：请问使用什么操作系统部署 Kubernetes，有什么考虑？

A：用的 CentOS 7，企业一般的用法，还有就是它稳定，不容易出问题，Kubernetes 和 Docker 的支持比较好。

Q：如何把所有告警信息全部递给 Zabbix，Zabbix 自身是否也获取了监控值信息了？

A：全部推送压力大，先将 APIserver、Heapster 中相关的信息放 MySQL，中间做个数据库。

Q：etcd 3 的容灾和安全做了吗？

A：etcd 非常关键，我们会在升级和定期用 etcdctl 做 backup。升级时需将 –initial-cluster-state 改为 existing ，安全方面还没有。

Q：做灰度发布或 HPA 自动扩容时，实现了不影响正在提供服务的服务吗？

A：灰度发布不会影响服务，我们使用了 Ingress + Nginx 来保证 Pod 的变化不受影响。HPA 这块我们不敢上线，功能完成了，但没有经过大量测试。

Q：使用 rbd 作为后端存储，当 pod 发生迁移到另外一个节点后如何再次挂载这个 rbd？

A：将 PVC 的 volume.beta.kubernetes.io/storage-class 和 StorageClass 的 name 名字一样就可。不需要管后面 Pod。

Q：etcd 3 在哪些方面不如 etcd 2？

A：没有去做对比，etcd 3 是通过搜集了 etcd 2 用户的反馈和实际扩展 etcd 2 的经验基础上全新设计了 API 的产品。etcd 3 在效率，可靠性和并发控制上改进比较多。etcd 2 支持多语言客户端驱动，etcd 3 由于采用 gRPC，很多需要自己实现驱动。

Q：请问有状态的 pod 迁移，使用 ceph pv 是怎么保证分到同一个 volume？

A：我们用的是 StorageClass，在 PVC 时指定和 StorageClass 名字一样就可。通过 volume.beta.kubernetes.io/storage-class 来指定该名字。

Q：请问运行在不同的 Node 上面的 Pod 如何共享 Volume 存储，比如要共享一份代码？

A：不同 Node 间的 Pod 卷共享方式比较多，但一般需要网络存储，比如：NFS，GlusterFS，CephFS，Ceph rbd，当然还包括很多大厂如：GCE 的 pd，AWS 的 ebs 等。甚至可以使用 ConfigMap 来共享，然后 mount 到相应的目录即可。

Q：请问有没有对比过共有的容器云和私有的容器云的优缺点？

A：公有云比较难做，我们之前是做私有云（物理资源隔离，用户数据更安全可控；独占资源，不受干扰；自行规划灵活调整资源复用比例，成本更优），公有云（公有云弹性，自如应对业务变化；具备跨机房、跨地区的容灾能力）我们也在做，正在和 IBM 合作。

Q：请教多 Master 下，当某个 Master down 掉，default/kubernetes endpoints 中的 IP 没更新的问题，你们是如何处理的？

A：这个主要是 Endpoints 控制器负责 Endpoints 对象的创建，更新。新 leader master 掌管后，Kubernetes 会用 checkLeftoverEndpoints 来删除 没有响应的服务的 endpoints，重启一下 kube-controller-manager 试试。

Q：做过集群联盟吗？

A：有测试过，但目前 Kubernetes 可以支持达 1000 节点了，能满足我们目前的需求，所以还没有上。

Q：HPA 不是 Kubernetes 支持的吗？你们对其做了哪些二次开发？支持蓝绿部署吗？

A：对的，目前是支持 CPU 还有一些应用程序提供的 metrics 了，之前在社区还没有的时候，我们有自己开发，主要是通过 heapster 监控 qps 还提供自定义的一些度量来完成 HPA。但 HPA 这个一旦出问题会不可控，所以暂时还不敢上线。蓝绿部署比较耗硬件资源，相当于要多一新版本备份，目前我们还不支持蓝绿部署。

Q：如果想看日志文件有没有好的办法，感觉在 ES 重被切割了不友好？

A：日志文件可以通过在启动的时候新建一个以应用名字命名的目录挂载到本地或者网络存储中，然后应用的标准或错误输出会直接输出到 docker daemon 的日志目录下，如果应用有自己的专门的文件输出方式，则可以用 tail -f 方式进行转发与 docker daemon 对接。

Q：还有就是基础容器是用的 CentOS 镜像吗？它默认就接近 200m。开发语言用的 Go 的话有啥优化容器的地方？

A：基础容器一般 CentOS 的多些，有些会直接采用 docker hub 提供的原始镜像，然后做些自定义组件添加并重打包。一般的会比较大一些，镜像可以对 Dockerfile 进行优化来变小。可以用 pprof 来分析 Go 代码性能，容器的优化还主要在 Dockerfile。

Q：请问你们对于用户体验方面是如何监控的？比如每个点击在不同服务层面上的延时各是多少，超时报警等？

A：这是个不错的想法，我们还没有做这块，不过可以通过应用提供的 url，对其监控 HTTP get 的 response 时间来控制。

Q：前端基于 Opads 和后端 Pluto 实现 CI，有具体的文档可以参考吗？

A：这两个都是自己内部开发的模块，一个基于 PHP，一个基于 Python，文档不方便分享。

Q：目前大规模落地云平台是建议上容器云吗？

A：建议上。

Q：服务启动依赖和应用版本控制如何做的？

A：这块我们做的不大好，一般可以将每个服务注册到发现服务，然后记录它们的依赖，在启动时进行服务发现及启动，这个在微服务框架中有些。我们在应用程序版本控制方面有自己的约束规范，但后面会有 helm 来试试。

Q：etcd 集群为什么不直接用 Compose 启动？

A：这个我们为了 ansible 部署方便

Q：Node 节点采用虚拟机还是物理机部署的？

A：物理机。

以上内容根据 2017 年 09 月 21 日晚微信群分享内容整理。

分享人陈强，万达网络资深工程师，毕业于华东师范大学。目前在万达网络科技集团云公司基础架构部负责 Kubernetes 与 Docker 的落地与实践工作。曾先后就职于 Intel、IBM 和爱奇艺。在云计算领域长年搬砖，对 Mesos/Kubernetes/Docker 等有较深入的研究。

---

2017-09-16：Serverless 云函数架构精解

Q：请问代码怎么部署到 Docker 中？

A：直接将代码下载至母机，再将代码目录挂载至 Docker。

Q：云函数是通用的还是只能在云平台运行？

A：云提供了云函数服务，自己也可搭建，目前 GitHub 上有不少开源云函数平台，比如 OpenLambda，Iron.io 等，建议直接使用云的服务，因为可以和多个云产品打通，单靠云函数自身难以构建完整服务。

Q：事件传递使用的是队列吗？

A：异步事件用了 CMQ 消息队列持久化存储，同步事件未使用。

Q：请问云函数对开发语言有限制否？如果有，目前对 Go 语言的支持如何？

A：目前支持 Python 2.7/3.6，Node.js 4.3/6.10，Java 8，如果有通用的用户需求，可以支持其它语言，比如 PHP、Go 等。

Q：有系统函数调用吗？自定义函数的颗粒度有何建议？

A：绝大部分的系统调用都可调用，除了一些危险操作，比如关机，重启，网络服务监听等，函数颗粒度可参考微服务的设计原则，将功能尽量拆细。

Q：能介绍下将请求调度到函数实例的实现吗？

A：这里有个 Invoker 模块对每个函数维持有一个请求队列，目前没设置优先级，按照先来先到的顺序依次调度，调度时会从函数所有可用的函数实例中，选择一个下发。函数实例里有个循环接受请求，收到时传递参数调用用户函数。

Q：代码可以下云落地吗？

A：代码里一般会涉及其它云产品的调用，所以一般对云平台有一些依赖，可以关注下开源的 Serverless 框架，在公有云云函数上封装了一层，用来解除依赖，实现在各个云平台的平滑迁移。

Q：云函数的代码有哪些限制？比如什么样的函数不可以调用，什么样的库不能 import？

A：可以基本认为无限制，但会禁止恶意行为，比如关机，重启，端口扫描等；也会禁止端口监听，因为常驻进程不符合云函数按需启用的原则。如果预装库不符合要求，可以自行将依赖库打包至 zip 里上传。

---

2017-08-25：基于 Kubernetes 的应用编排实践

Q：腾讯云 Kubernetes 网络用的是哪个组件呢？

A：我们用的是全局路由的方式，直接和我们腾讯云的 VPC 网络打通。

Q：使用 ConfigMap 的时候，在配置修改完，需要重启服务。腾讯云容器服务配置文件的变更如何触发服务的重新启动？

A：通过触发器的模式，可以在修改配置时触发服务的更新。

Q：应用配置如何实现版本控制的？

A：对于每一个配置文件，我们支持每一次修改默认创建一个新的版本，具有唯一的版本号。

Q：应用里的服务具体要怎么更新呢？

A：一般建议的更新方法是，先修改配置，会生成配置的一个新的版本，这样这次修改在配置中是可以记录的。然后更新应用汇总配置文件的版本。触发或者手动更新对应的服务。在修改配置文件的版本后，我们会比较出哪些服务有变化，需要更新。

Q：外部访问集群是通过 Nginx 转发到 Pod 还是通过 Kubernetes 本来都 DNS 服务来转发，两者优缺点是什么？

A：外部访问，支持两种方式。一种是通过服务的 LB 直接转发到对应的 Pod，但需要在创建服务时指定访问方式为外部访问（对应于 Kubernetes 中的 LoadBanace 方式）。另外一种是通过ingress 的方式。这种方式会有一个统一的 LB 作为入口。然后配置对应的后端域名转发规则。可以将外部的访问按照配置的规则转发后端的服务。

Q：应用的扩容缩容通过什么监控，有什么指标可以参考？

A：自动扩容和缩容我们参考的是社区 HPA 的方案。指标目前考虑的是 CPU 和内存。

Q：状态化的容器怎么做的？

A：目前看到的有三种方式：一种是社区推荐的 Stateful 资源 +headles service，另外一种是将服务的每一个实例拆分成独立的 headless service ，第三种是采用 CoreOS 提出的 operater 方式。存储部分一般推荐使用 PVC 的方式，但有其他的存储方式也可以。

---

2017-08-22：白话 Kubernetes 网络

Q：Kubernetes 的网络策略采用了比较严格的单向流控制，即假如允许服务 A 访问服务 B，反过来服务 B 并不一定能访问服务 A。为什么要设计成严格单向流呢？

A：主要是安全性的原因，这是一种更精细的权限控制策略，除了方向，Kuberetes 还允许对可访问的端口进行控制。

Q：Open vSwitch 有测过么？

A：没有测试，Open vSwitch 同样可以配置成 Overlay 网络或者 Macvlan 网络等不同的通信模式，速度也会落到相应的档位上。那个测试例子只是为了说明网络速度与采用的通信原理有关，同时引出几种主流的通信模式原理，测试数据是不准确的，建议以在自己的实际环境中测试结果为准。

Q：Calico 怎么做网段间的隔离？

A：各种网络工具的网络策略基本上都是基于内核的 Iptables 模块实现的。比如 Calico 只是根据用户配置，自动管理各个节点上的 Iptables 规则。其他有些改进的，比如 Romana 设计了一种基于”租户”的规则管理机制，可以用更少的 Iptables 规则实现网络隔离。

Q：如果在 Kubernetes 里面需要做到平行网络，让每一个 Pod 获取一个业务 IP，除了 Bridge+Vlan 的方式，还有更好的建议么？

A：这次讲的这些 CNI 插件都会让每一个 Pod 获得一个独立业务 IP。可以根据实际网络情况和对速度的需求选择。

Q：Calico BGP IPIP NAT 三种模式分别怎么配置？原理是怎样的？其中 IPIP 还有两种模式，区别在哪？

A：在 Calico 的配置中设置 spec.ipip.enabled: ture {.prettyprint}就会开启 IPIP 模式，否则默认是纯 BGP 模式。IPIP 的两种模式其实是指纯 IPIP（ipip always 模式）或者混合 IPIP 和 BGP（ipip cross-subnet），后者指的是”同子网内路由采用 BGP，跨子网路由采用 IPIP”，主要用于即想在内网获得高速，又想在跨公网时能保持联通的情况。这种模式需要每个节点启动时用 --ip {.prettyprint}参数预先配置节点的子网，并且所有节点版本都在 v2.1 以上。

Q：能麻烦具体介绍一下 kube-proxy 这种网络模式的优缺点吗，在测试过程中发现很不稳定，但是又没发现足够的证据。

A：kube-proxy 是 Kubernetes 的一个组件，提供通过 Service 到 Pod 的路由，并不是一种网络模式，不同的网络插件都会使用到这个组件。

---

2017-08-17：Kubernetes 主机和容器的监控方案

Q：容器监控和主机监控为何不能用同一套方案，比如 Prometheus？

A：可以，主要考虑到 Prometheus 的组件比较多，它将 DB、Graph、Statistic、Alert 都集于一体，但是它的扩展性不好，内存占用率大，在 SSD 盘下 IO 占用比较高，同时可能会有大量数据堆积内存，维护成本比较大，但是也可以避免，其实还是要看具体的业务场景和需求，如果是针对大规模的主机和容器监控，并且对 DB、Graph、Statistic、Alert 的要求都比较高，那么 Prometheus 肯定是比较好的选择，另外还可以使用 cAdvisor + Prometheus + Grafana 的组合方案，将这几个工具的有点结合起来使用。

Q：有没有能集成邮件或短信告警工具的呢？

A：比如 Prometheus 和 Zabbix 都有采集，展示，告警的功能。

Q：Prometheus 的数据存储在哪儿，用的文件系统是什么？

A：Prometheus 本身是用的 LevelDB 数据库，数据存储分两部分：内存和本地磁盘中。

Q：kubelet 和 cAdvisor 整合后，监控如果出问题岂不是会影响服务稳定性？这个如何解决？

A：在 Kubernetes 的新版本中已经集成了 cAdvisor，cAdvisor 作为一个 daemon 跑在 Kubernetes 上面，即使 cAdvisor 出现问题，对 Kubernetes 并没有影响，而且 Kubernetes 本身也有一套管理机制。

Q：想问一下对于 Pod 的生命周期的监控有没有好的解决方案，想监控一些 pod 不明原因频繁删除和新建？

A：cAdvisor 可以对 Pod 进行监控，如果想查原因，可以对日志进行监控和分析。

A：可以使用 Prometheus、Icinga、Zabbix 的告警功能。

Q：cAdvisor 的采集粒度是多长时间？当需要采集秒级的性能数据时 cAdvisor 是否能满足要求？

A：cAdvisor 采集了最近接近两分钟内的 8 组数据, 可以满足，这里主要是要考虑下存储问题，因为到采集到秒级别后，数据会很大。

Q：容器中使用像 JVM 这种都会怎么来进行监控呢？

A：ELK stack 应该适合这种场景，另外 Datadog 也是 SaaS 监测工具，Datadog 比较灵活，需要植入自己的代码，可能没有前者用起来简单。

Q：对于群集环境，能不能简单比较一下各数据采集软件的好坏？或者分享一下用过的工具和坑。

A：这几个采集工具不好说哪个好那个坏，还是要看具体应用场景和需求，适合自己的才是最好的（嘿嘿）。例如：功能全的工具可能会很臃肿，占用资源也多，而且并不一定使用所有场景，功能少的扩展性可能很好。

Q：容器监控应该是为了容器能更好的运行。那么当容器出现一些异常情况，比如 IO 占用过高，带宽占用很多时，该怎么处理呢。

A：这是监控系统中自动化处理的那部分，针对容器出现的异常到底是要采取什么自动化操作还是要看具体情况，一般如果容器异常挂掉，可能会选择自动拉起，但如果像 IO 占用过高这中问题，因为导致的原因太多了，可能是主机的问题，也可能是程序本身的问题，所以还是需要人为去排查才行。

Q：cAdvisor 是定时采集数据，但是有时候时间点采集不到数据，是为什么？

A：可以看下 cAdvisor 有没有异常重启过，然后可以手动区主机的文件下查看数据，然后跟 cAdvisor 取到的数据进行比较，有可能是是在采集数据的时候有问题。

Q：数据采集中，您提到主动输出到文件，那么涉及到日志文件的读取采集，那这块怎么做呢？

A：如果是传统的日志汇总收集有开源的软件 ELK 和 Facebook 开源的 Scribe，容器的日志管理可以参考 Fluentd。

Q：这些监控方案中从资源占用数据准确性角度来看，哪个更好用？

A：准确性都不会差，他们采集的源数据都是一样的，在资源占用这块，cAdvisor 是占用资源最少的，Prometheus 占用资源比较多。

Q16：有一处我不是很确定是否讲错了，我实践发现即便为容器设置了 MEM、CPU 限制，所监控到的依然是主机的总 MEM 和 CPU。

A：我测试了，在启动容器的时候设置 MEM 和 CPU 限制后，通过 docker stats 命令监控的是设置的值。

Q：如果要监控某个容器内正在跑的进程，你们现在的方案是如何的，能介绍下吗？

A：可以参考 Kubernetes 中 Pod 健康部分：kubernetes.io/docs，利用探针的方式监控进程。

以上内容根据 2017 年 07 月 27 日晚微信群分享内容整理。分享人李强，有容云后端开发工程师。有着多年的服务器、网络、容器、虚拟化等云计算技术相关工作经验，现主要负责 Kubernetes 安装、集群、监控等相关的后台研发工作。

---

2017-08-09：Kubernetes 健康检查策略

Q：请问 Pod 的状态是 crashbackoff 除了下载镜像失败有哪些可能？下载的镜像能否指定 registry？ pod 如果有一个容器是 exit 0，那是否就是您之前提到的 succeed?使用 livenessProbe 检测失败的是 failed 还是 crashbackoff？

A：Crashbackoff 大部分情况下是容器的启动命令失败，比如 tomcat 启动失败了，初学者比较容器犯的错误是 CMD 的命令是一个非阻塞命令，这样容器一运行就马上退出了。下载的镜像可以指定 registry，根据镜像的命令来的，比如 test.registry.com/image:version。容器 exit 0 了，得根据重启策略来判断。而 livenessProbe 检测是业务层面的检测。

Q：请问 readinessProbe 检测失败后，是手动 Scale 添加 Pod 确保业务稳定还是可以在 ReplicationController 的 yaml 里面定义？

A：这部分 Kubernetes 并不支持，是我们自己准备开发的功能。就是发现 Pod NotReady 后，一来保留问题容器，二来新增一个 Pod 顶替。

Q：请问 Supervisord 是手动在 Pod 里面的容器里面添加么？还是有专门的镜像已经自带？谢谢！容器出错后收集的现场信息都保存在哪里？

A：Supervisord 就安装到容器里面就行了，比如我们是 CentOS 基础镜像，然后 yum install 即可。当进程异常的时候，Supervisord 可以重启进程并且保证容器不会退出，这样一来就可以登录到容器里面排查问题，信息的话根据组件的情况来定了。

Q：请问，如果一个 deployment 有三个副本，分别部署再三个 Node 上，当其中一个 Node 宕机了，这时候对应的 service 中的 endpoint 更新需要一定的时间，用户在这个时间段访问就会有 1/3 的错误可能，这种情况怎么办？

A：当 Pod 异常的时候，比如是 NotReady，Service 的 endpoint 了马上就会剔除这个 Pod 了。Kubernetes 的实现都是实时 watch 的。

Q：保留容器现场如果造成多个僵尸容器怎么办？

A：当 Pod NotReady 的时候，新建 Pod 顶替，新建的 Pod 也异常的话，就不能一直重建。然后定位完成后，只能手动去清理 Pod 了。

Q：用 Supervisor 来启动服务，应用的日志是打到指定的目录的还是直接 std 输出然后再处理的啊？

A：应用的日志打印到文件处理。Stdout 被 Supervisor 占用了

Q:一个容器里面推荐只跑一个进程，对于遇到一个项目要跑多个服务的情况，是每个服务都单独生成一个容器吗？如果是这样的话代码是怎么管理的？每个服务一个分支吗？而且往往开发、测试、生产是不同的分支，这样服务多了的话对于代码管理很麻烦，如果一个容器里面用 Supervisor 来跑多个进程的话理论上可以，但是显然做法不好。

A：每个服务可以做成一个容器。那这个是管理的成本了，可以通过一些工具和脚本来自动化。至于要不要跑多进程，看实际场景，都是可以的，其实只要保证 Pod 提供的业务是正常的即可，所以我们用 Probe 来对业务检查，

Q：请问 Kubernetes 的应用的日志是怎么管理的，用的网络文件系统还是其他的方式？

A：我们是要求应用的日志全部输出到指定目录，比如/var/log。然后我们针对容器里面的日志目录统一挂载到 Ceph 存储。

Q：是否可以通过 preStop 元素在 pod failed 被移除前执行一些收集现场信息的命令？

A：也是可以的。但是大部分人定位问题还是希望能够登录到容器里面定位，这样是最快最方便的方式。

Q：Supervisor 的方式打乱了 Kubernetes 原来的容器重启方式，可能会带来更大的问题。不如考虑在 Kubernetes 的基础上修改增强。

A：是个问题。可以说 Supervisor 就覆盖了 Kubernetes 的重启方式，但是一方面 Supervisor 的重启方式更加灵活，另一方面修改 Kubernetes 的话侵入性比较大。所以我们选择用 Supervisor。

Q：你们的应用日志统一挂载存储的话，存储上是为每个容器新建一个目录吗？

A：这部门我们是修改了 Kubernetes 的代码，为每个 pod 在宿主机创建一个目录，然后宿主机的这个目录是挂载 Cephfs 的。

Q：假如 APP 不能正常进行业务处理（连不上数据等原因），而 health check 依然正常返回。怎么办？你们会强制要求开发对 APP 的状态进行管理，在 health check 里返回吗？

A：这是个好问题。我们会尽量要求应用提供的 health 接口尽量准确，但是这也很难保证 100% 的业务正常，所以目前就是需要权衡，这部门我们也在细化中。

以上内容根据 2017 年 08 月 08 日晚微信群分享内容整理。分享人吴龙辉，网宿科技云计算架构师，负责设计开发 PaaS 平台，《Kubernetes 实战》作者。

---

2017-08-06：求取一份极致的简单：海量应用容器化改造之路

Q：构建镜像用的什么技术？

A：我们使用的是 Docker 自身提供的 docker build 命令进行镜像构建的。

Q：Config Center 能否详细说一下？

A：我们使用 Config Center 主要来管理应用自身的配置文件，应该在启动前首先拽下自己的配置文件；还有就是对应用进行 Leader 控制，因为应用可能会跑多个实例的，像定时任务类的功能，在同一个时间点只能其中一个实例生效。

Q： 如何动态生成 Dockerfile，如何在 Docker 镜像里配置 JVM 参数？

A：Dockerfile 文件：我们是使用 sh 脚本生成的，将内容 >> Dockerfile 中；JVM 参数是在应用中配置的，发送构建消息时，作为消息内容送过去。

Q： Deployment 滚动更新如何设置间隔时间呢？

A：Deployment 对象有个 minReadySeconds 属性就是来解决这个问题的。

Q： Logstash 的日志为啥是发送到 HDFS 而不是 ES？有什么考虑么？

A：我们将 Logstash 采集到的日志输出到两个地方：ES、HDFS，输出到 ES 直接在 Kibana 上搜索到，而输出到 HDFS 便于在 Kibana 上面将日志文件进行下载下来。

Q：Docker Registry 的在 garbage collect 时怎么保证高可用？

A：我们使用的由 VMware 公司中国团队开源的 Harbor，无论安全、效率、可用性方面都提供了很强的保障了。

Q：kubectl set image 的时候 能不能限制每变更一个容器，再保证 http 访问正常的前提下，再变更下一个容器。毕竟有的服务启动时间超过 30 秒，对外的服务忍受不了信么久的不可访问时间的？

A：这个可以直接借助 Kubernetes 的 RollingUpdate 功能就可以做了。

Q：Dockerfile 动态生成怎么做的，用的是什么生成工具？

A：使用 sh 脚本生成,将内容 >> Dockerfile 中去可以了。

Q：统一的流程给实际的生产带来了怎样的好处能否介绍一下？

A：流程统一后，像源码管理、日志采集及搜索、应用发布，应用滚动升级等就不需要应用本身来管了，这样各业务系统本身就会更加专注于自身的业务功能了。

---

2017-08-02：国内某大型酒店管理集团基于 Kubernetes 的实践

Q：容器的日志怎么管理呢？不同应用的日志怎么管理？

A：我们在容器化之前已经开始使用 ELK 的解决方案，所以我们整个容器化平台的改造中也整合了 ELK 的方案。 1. Docker 启动的时候 mount 一个共享存储，日志都写在这个共享存储里，然后配置 Logstach 采集，最后吐到 ES 里，用 kibana 展示，缺点是挂共享存储，性能略差。优点是日志可以根据应用来分到不同的 ELK 上，并且日志做归档比较容易，我们有场景要查一年前的日志。 2. 我们在 Kubernetes 节点上安装 fluentd 组件，采集 Kubernetes node 上的日志，应用部分只需要在 log4j 的配置里将日志输出打到标准输出上系统即可采集，缺点是这个集群的日志会全部聚合到一套 ELK 上。优点是应用几乎无需做什么改造。

Q：容器中需要持久化的数据怎么处理？

A：原则上我们不建议在容器化平台上的应用有持久化数据 ，如果互联网应用的背景，应用无状态化设计对于应用有横向扩展需求是更加适合的，应用在上容器云平台前要完成这部分改造。但是我们的确有做过数据持久化的研究，当时主要考虑 ES 集群会有持久化数据，我们的方案是 Kubernetes+GlusterFS 的方案。但是由于 ES 集群本身很稳定，也不会有发布，容器化意义并不大，所以暂时我们这部分仍保留在 VM 上。

Q：请教下，如果开发机在本地，如何连到测试环境（联调环境）上去，你们的网络如何打通？

A：我们不建议开发使用本地资源进行开发，我们提供整套的 QA 环境（都在 Kubernetes 上）。 如果实在要登录到 Node 上看一些东西，我们有堡垒机。

Q：Docker 网络用的什么方案？

A：Flannel，能用，性能不太好，准备迭代掉它。这是坑！大家不要踩。

Q：服务对外暴露是用什么实现的？

A：集群内部访问之前说了，服务名的方式，集群外的访问，Kubernetes 每个节点都可以提供服务。但是如果所有请求都落在一个 Kubernetes 节点上，这个节点就是一个单点。 所以我们提供对外服务时仍然会在 node 前面加一层 loadbalance，LB 后面将 5-10 个 Kubernetes 的节点作为 backend 添加上去。另外这部分节点最好不要调度任务在上面跑。

Q：你们的 Docker 容器在 Windows 上是怎么解决 IP 通信的？

A：我们不用 Windows 的 Docker，Docker 是进程共享的虚拟化技术，Windows 和 Linux 共享哪门子进程？感觉不太靠谱，所以不用。（比较主观） 微软自己也在搞类似 Docker+Kubernetes 的架构的一套东西，大家可以关注一下，如果要上 Windows 的 Docker 那还是用 MS 的解决方案比较靠谱。

Q：你们的宿主机、容器、服务的监控告警系统架构是怎样的，能简单介绍下吗？

A：宿主机我们还是用 Zabbix，服务的可用性我们也用 Zabbix（这是容器化之前就保留下来的）但是只有当所有 pod 都挂掉才会报警，容器的监控我们是使用 Prometheus 和 Grafana。

Q：四个环境的发布权限你们怎么去合理配置呢？

A：原则上用户登录所有环境都需要通过堡垒机，4 个环境的发布，都是通过 Jenkins 来实现的，所以我们会控制 Jenkins 上对应的 Pipline 的权限。（Git->Jenkins->Kubernetes）这一段是自动化的，开发人员能做的就是触发构建任务。 如有特殊的需求，需要让运维人员操作。

Q：如果有开发人员需要上去看错误日志，假设这种错误日志是需要调试，不会被收集，是只能通过堡垒机去看吗？容器的日志怎么进行存储，如果挂到宿主机目录那好多容器怎么分文件夹呢？

A：我们方案里 fluentd 可以收集 node 上几乎所有的日志，另外关于错误调试日志，如果是应用的，那开发人员按照需求调整输出路径就好了，用 ELK 采集就好了。如果是系统级别的，运维人员就把它作为一个 Linux 主机查日志拍错就好了。 另外容器的日志，解释起来有些长，你可以参考我之前的帖子《Docker 日志那点事》，容器日志的目录和格式都有写到。

Q：用的 Overlay 网络，那你们用的 NodePort 暴露的服务，然后外部 LB 访问 NodePort？那你们现在容器一个集群内有多少容器？kube-proxy 的性能有做过压力测试吗？

A：回答后面一部分，我们每个环境都是一个集群，例如 QA 是一个集群，UAT 是一个集群，我们一个生产集群目前大概 1000+ 个容器。 另外我们应用上线前会做压力测试，目前我们没遇到过 kube-proxy 被压死的情况，多是我们的压力不够（我们使用 JMeter，大多时候是 JMeter 死掉）。

Q：各环境用的是同一个 imagebuild 用 env 区分？还是不同 build？有比较过或遇到什么坑吗？

A：开始的分享提到了，一个 image build 用 env 区分，就是坑。配置文件管理变成了 env 的管理。所以老老实实每个环境 build 一个镜像。

Q：各环境的 config 是怎样和什么时候打到 image 里的？

A：配置文件一起放在 Git 上，Jenkins 拉完代码再把配置文件拉下来，简单点使用 CP 命令把对应的配置文件和 war 或者 jar 以及 Dockerfile 放到对应的目录下，进行 build 就好了。

---

2017-07-21：深入理解 Kubernetes 网络策略

Q：Calico 和 Weave 从 Policy 处理性能来看，两者哪个更优？

A：两者在 iptables 层面上的实现原理是一样的。都用了 -m state 和 ipset 优化，性能差别不大。

Q：Calico 结合 Kubernetes 怎么实现多租户，比如网络隔离之类的？

A：可以考虑用 namespace 来隔离。没有 Network Policy 的情况下当然是互通的。但是 Kubernetes 的 Network Policy 支持 namespaceSelector，可以轻松搞定。

Q：Weave、Calico、Flannel 比较，适用场景和优缺点是什么，Flannel out 了么？

A：各有各的市场 :-)。 Flannel 比较简单，资源消耗也会小些。Flannel 不能算 out 了。Cannel 的出现将 Flannel 和 Calico 整合了起来。

Q：NPC 必须用 iptables 实现吗？在某些情况下，Pod 出向流量并不会由主机协议栈，这样 iptables 就用不了，这种情况下 NPC 怎么实现呢 ？

A：Calico、Weave、Romana 的 NPC 都是通过 iptables 实现的

---

2017-07-19：58 赶集基于 Docker 的自动化部署实践

Q：如何更新 nginx upstream？

A：Nginx 机器上部署有 Agent，Web 类的业务有统一的框架，服务启动时会向 Consul 注册。Agent 订阅 Consul 中的节点数据，然后配合 nginx dyups 模块，动态修改 nginx upstream。

Q：打包好镜像后，使用镜像还用再进行配置吗，就是说还用手动配置吗？

A：不用配置，不同环境之间流转的是同一个镜像，包含了各个环境的所有配置，通过启动容器的环境变量来识别切换。

Q：Docker 的正确的使用姿势，在本地环境已经构建了企业私有 Registry Harbor，那么我要构建基于业务的应用时，是先从 Linux 系列的像 Ubuntu 或 CentOS 的 Base 的 Docker 镜像开始，然后通过 Dockerfile 定制业务需求，来使用吗？

A：我们基础镜像统一采用 CentOS 6.8，不同的业务有不同的 Dockerfile 模板，生成镜像的过程业务对 Dockerfile 是透明的。

Q：这里实现灰度发布了吗？能否不停交易更新？

A：实现了 PV 灰度，暂时没实现 UV 灰度，对于无状态的业务已经能满足需求了，对于有状态的业务，比如交易类型的主要还是需要程序架构来实现。

Q：请问如何保证 NGINX 的高可用？

A：域名->CNAME（快速切换 IP 解析）->LVS（多个 rip）-> 多个 NGINX 实例（平行实例）；NGINX 同时和 LVS 保持心跳来自动踢掉故障的实例。

---

2017-07-13：Juice—一种基于 MesosFramework 的任务云框架

Q：Juice 与 Elastic-Job 有哪些差异？

A：我本身对于 Elastic-Job 并不算太熟悉，就随便说几点，如果有错还请各位纠正： Juice 目前版本并不支持作业分片。

Q：能详细介绍下任务资源分配这一块的算法吗？

A：之前已经简单介绍过了，通过接收'OFFERS'事件触发相关任务－资源分配的代码块。 由于得到的 Offer 对象实际为一个列表，处理逻辑会循环为每一个 Offer 分配具体的任务，而每个 Offer 的任务列表总资源（CPU、Memory 等）必需小于 Offer resources * RESOURCES_USE_THRESHOLD（资源使用阀值，可通过配置文件 resources.use.threshold 设置，默认 0.8），每分配完一个 Offer 的 task_infos 后，便生成 Accept Call 由发送线程池进行发送处理，整个过程都是异步非阻塞的。

Q：所有的任务都存档在 Docker 里面对于一些临时的任务如何处理?

A：临时的任务确实会产生一些垃圾的镜像，需要定期对 Docker 仓库进行清理，一般设置清理周期为 1 个月。

Q：任务系统是是否有帮助用户完成 Docker 封装的操作？

A：目前没有，所以使用者必需会一些 Docker 的基本操作，至少要会打镜像，提交镜像等。当然，像一些 Docker 的设置，比如挂载 Volume，网络（bridge、host）等可以在提交任务时通过参数设置。

Q：Mesos 和 Kubernetes 的优劣势是什么？

A：其实我主要使用 Mesos，Mesos 相对 Kubernetes 应该是一套更重的系统，Mesos 更像是个分布式操作系统，而 Kubernetes 在容器编排方面更有优势（Pod 之类）。

以上内容根据 2017 年 07 月 13 日晚微信群分享内容整理。分享人徐佳，沪江 Java 工程师，开源框架 Juice 作者，10 多年开发经验。

---

2017-07-12：探究 PaaS 网络模型设计

Q：有这么多虚拟网络，覆盖网络，会不会有网络延迟？

A：网络虚拟会带来性能损耗，比如 Flannel 需要将报文封装到 UDP 包中传输，这中间的封包解包就会带来损耗。所以网络虚拟化的部分，软件的实现还有待优化，其实更好的方式是硬件支持，比如现在提的很多的 SDN 网络。

Q：Pod 为什么要有个网络容器？

A： 一方面这是解耦，通过网络容器来负责网络配置，这样对于业务容器来说稳定性会更高，比如在多个业务容器中，某一个业务容器断了，这样就不会导致网络中断。

Q：Calico 默认全网是打通的，怎么做基于网段之间的隔离？

A：目前来说要做网段隔离，可能偏向安全性比较高的场景，我们目前是做私有云场景，对隔离的要求没那么高。所以如果要做隔离的话，可以参考 OpenStack 的 OVS 方案。

Q：在某些应用场景下，Pod 的 IP 需要固定，而不是重启之后 IP 可能会变化，请问如何满足这种场景的需求？

A：Pod 的 IP 需要固定的话，一种方式是修改 Docker 的代码，据我所知腾讯有实现过。另外的方案就是做 L3 的代理，给 Pod 一个浮动 IP，有点像 OpenStack 的实现。

Q：Ingress 的流量默认是先走 Service 然后到 Pod，还是直接到 Pod？

A：取决你的实现，官方的实现是先走 Sevice 再到 Pod，我们是直接到 Pod。

Q：Ingress-Controller 实现除了使用 LVS 和 Nginx 外，能否采用商用负载设备来实现？实现是否取决于和 Kubernetes API 的对接？

A：可以，只要有接口都可以实现，通过实现 Ingress-Controller，比如对接 F5 的硬件设备，只要 F5 支持相关的 API。

Q：代理入口上有哪些方法解决单点失效的问题呢？

A：这个比较传统了，软件实现就 Keepalived 之类的。

Q：Igress-Cntroller 比较好的库都有哪些，分别基于 Nginx Haproxy LVS 的？

A：GitHub 有蛮多实现的，其实还是比较简单的，像 go 语言的话，直接套用官方提供的 demo 即可，其他语言可以对接 Kubernetes 的 API 实现。

Q：这么多层的网络，多层转发后网络性能怎么样？有没有办法实现高速数据转发解决方案？

A：代理层，虚拟层都会有损耗，这个就是要考虑管理成本和性能的权衡了。如何要实现高性能的话，就是要往 SDN 网络研究，通过硬件层的支持来实现虚。

以上内容根据 2017 年 07 月 11 日晚微信群分享内容整理。分享人吴龙辉，网宿科技云计算架构师，负责设计开发 PaaS 平台，《Kubernetes 实战》作者。

---

2017-07-14：聊聊 Service Mesh：linkerd

Q：具体的测试性能有么，对比 LVS、Nginx？

A：linkerd 虽然是网络代理，但跟 LVS、Nginx 还是有不同的，所解决的问题也不同，比如 linkerd 常用的部署方式以 sidecar 模式部署。 对于性能数据，单个 linkerd 是可以可以处理 20K/sec 请求，p99 延迟在 10ms 以内，但是超过 20K，在我的测试环境，提高不大。而跟 Nginx 和 LVS 的对比，还没做过。

Q：能否说说 “熔断机制（circuit-breaking） “怎么理解？

A：linkerd 支持 2 种方式进行熔断，一种是基于会话或者链接，另一种是基于请求的熔断。对于会话层的熔断，linkerd 在转发请求到后端应用实例时，如果发现其中一个链接出现问题，linkerd 会将它从维护的一个池子里移除，不会有真实请求发送到该实例，而在后台，linkerd 会尝试连接，一旦连接成功，linkerd 再次将它加入池子继续提供服务。 而对基于请求的熔断，linkerd 会根据 linkerd 的配置进行处理，比如配置为 io.l5d.consecutiveFailures， linkerd 观察到指定数量的连续错误，则熔断，其他的方式可以查看 linkerd.io/config/1.1.。

Q：linkerd 如何实现水平扩展的？集群对 linkerd 计算节点数量有限制吗？

A：linkerd 本身是无状态的，所以水平扩展非常容易，集群对 linkerd 的数量取决于你是怎么部署 linkerd 的，https://linkerd.io/in-depth/deployment/这个地方列出各种部署方式优势及缺点。

Q：看最后的表格好像能实现展示服务调用链，展示上下游关系？能不能借此发现具体服务压力瓶颈在哪一环，是否有性能监控？

A：linkerd 提供详细的 metric, 这些 metric 会告诉你性能出现在哪个地方，还有 linkerd 原生跟 zipkin 集成，所以你能 trace 到服务的访问流，会展示每一环节的性能情况。

Q：可否对比一下 Istio？

A：对应 Istio 的底层 Envoy 和 linkerd 本质上实现了差不多类似的功能，linkerd 支持 Kubernetes、DC/OS，并且跟多种服务发现工具集成，而 Istio，就我了解，目前支持 Kubernetes，具体 Istio 的使用，没有使用过，不太清楚。

Q：如果 linkd 是无状态，那怎么维护内部的熔断池？

A：这里的无状态是指 linkerd 工作时各个实例之间不需要信息的同步，即使一个实例出现问题，对个整个环境的正常工作无关痛痒，只需重新启动即可，所有服务发现的信息都是存储在外部，比如 Consul、ZK 等，本地只会有缓存，没有持久化的数据，而熔断池的信息就是来自于服务发现系统。

以上内容根据 2017 年 07 月 04 日晚微信群分享内容整理。分享人杨章显，思科高级系统工程师。主要关注云计算，容器，微服务等领域，目前在思科负责内部 PaaS 平台的构建相关工作。

---

2017-07-04：容器化部署 OpenStack 的正确姿势

Q：容器虚拟 CPU 支持虚拟化吗？

A：容器只是一个进程服务，依赖于 CPU 虚拟化。

Q：Kolla-Ansible 部署的 OpenStack 是否满足生产环境？

A：完全满足，已有客户上生产环境跑重要业务。

Q：OpenStack 服务的可靠性，主被仲裁，配置变更等，可以怎么管理呢：

A：OpenStack 服务的可靠性，主被仲裁，Kolla 和 Ansible 均支持包括 HAproxy 等在内的 OpenStack 服务和 Mariadb 数据库的高可用性，社区推荐 DB 使用主主方式；至于管理，使用 Ansible。

Q： OpenStack 容器化部署后数据持久化的问题如何解决？

A：默认情况下，配置文件数据存放在主机的/etc/kolla 目录下，数据库数据则在容器中，对于持久化等，可以考虑 docker volume 等相关方案，多种多样。

Q：通过 Kolla-Ansible 部署之后的 OpenStack 对网络是否有要求，或者需要单独配置网络这块？

A：使用 Kolla-Ansible 部署的 OpenStack 环境，和使用其他方式部署的网络环境一样，管理网、业务网和外网等。

Q：可否对 Kolla-Ansible 项目做 Socker 化，目的是通过这个镜像去部署 OpenStack，减少重复配置 Kolla-Ansible 的运行环境？

A：Kolla-Ansible 只是一个部署工具，做配置管理。可以把 Kolla、Ansible 和 Docker 镜像都放在一个部署模板上，通过这个部署模板去任意 部署 OpenStack 环境，这类似于 Fuel ISO。

---

2017-06-30：容器如何监控？

Q：有对 Docker 本身做什么监控么？

A：可以认为 Docker 监控是类主机监控，只不过是缩小版，基本上分为 4 部分 CPU、内存、磁盘、网络。

Q：使用的整套监控工具是哪些？容器 CPU 内存网络如何监控？容器事件比如起停如何监控。

A：整套工具我们使用的是 Cadvisor + Prometheus + Grafana ,当然中间的组件是可以替换的，但基本上围绕着 采集、存储计算、展现来做。采集也可以使用自己的，比如文章说的自己写代理去拿。容器的监控数据当然靠采集程序了。起停这个一般通过监控 Docker 的事件来实现，采集工具也能收。

Q：分享的监控图片，有数据的，是使用什么监控工具达成的？

A：这个分两种，一种是靠底层的绘图引擎，将数据从存储里读出来自己绘制，一种就是用类 Grafana 的程序。

Q：如果用 Zabbix 监控，是否需要定义容器的的历史数据保留时间和趋势数据存储周期，我设定的时历史数据保留 7 天，趋势数据 14 天，这样是否合理？

A：我认为 Zabbix 是上一代监控体系，或者以主机为中心的监控体系，如果是容器监控，我建议还是考虑时序类的监控体系，比如 Influxdb\Prometheus 等，继续刚才的，Zabbix 还可以沿用作为主机的，只是 Docker 单独分离出来，这样基础建设可以复用。

Q：建不建议通过 Pod 中放一个监控容器来监控应用容器，比如 Zabbix 客户端的监控容器在 Pod 中，如果这么做优缺点哪些？

A：Pod 应该是 Kubernetes 的概念，和容器其实关系不大，这个 Kubernetes 自己应该会提供数据，具体我不是很清楚。但是 Abbix 还是建议保留在主机层面使用，除非大改，否则即使靠拆分数据库什么的解决，未来维护和性能也是运维大坑。

Q：做容器监控和 JVM 监控是否有什么工具可以推荐，感谢。

A：容器监控现在自己玩套路都是跟着开源走，可以考虑刚才我们的套路，不过可以中间组件任意换，比如存储 InfluxDB，JVM，我已知道没有什么好的套路，基本上走跟实例的路子，就是做个小程序跟着程序走，然后提供统一接口用软件抓。

Q：Cadvisor Heapster 和 Prometheus 哪种好用一些，各自优缺点有哪些。

A： Heapster 不熟悉， Prometheus 很好，Google 个人的开源项目，都是 Google 套路，唯独存储是个问题，这块还需要看他们未来如何处理，现在单机存储虽然性能上还可以，但是扩展能力比较差。

Q：请问如何监控网络带宽，并对带宽进行限制？

A：带宽监控可以按照容器提供的数据走，还是很准的，具体限制这个是另一个纬度了，属于容器网络，这个坑比较大不适合今天讨论。

Q：Docker 多套环境使用的域名要相同还是不同？如果相同的话如何隔离，如果不同的话如何维护配置？

A：这个设计到容器服务的网络规划问题，看网络选择。隔离也看网络选型。和之前说的一样这个属于容器网络。坑大。

Q：监控工具推荐那个？对于容器生命周期短，有何策略应对？容器快速后，如何实现快速监控策略？

A：监控工具推荐刚才已经说了，可以参考我们的方案然后自己摸索出适合自己的。至于容器生命周期短的问题，这个不就是容器设计嘛，很正常，多起几个相同的服务顶上。容器快速后是什么?

Q：容器的一大特点是 IP 或者 ID 信息变化频繁，这就会导致时间序列数据库存储的监控数据量增长和 vm 相比大上不少，这块有什么应对方案吗？尝试过固定 ID 的，但是效果不佳。

A：这块确实没有什么好办法，不过可以换个角度，你可以将底层的实例抽象一个纬度，比如起了 1 个服务 10 个容器，你可以吧容器编号 0-9，对应挂掉的容器，新启动继承这个编号。这样从时序上用这个作为标记，这样你就能看比较直观的显示了。这个功能我们 SWAN 实现了，可以考虑。

Q：容器的安全如何做监控？

A：这个问题问的好，现在比较通用的监控基本上走的是两条路，一个是监控性能，一个是监控业务，安全层面监控，到现在我觉得还是要靠网络层来监控比较靠谱。

Q：Docker 启动 Kafka 集群的问题，有没有控制内存方面的经验呢？

A：Kafka 集群，性能监控的话，可以沿用原来的 Kafka 集群监控软件，这个我记得原来有一个什么来着，当然如果想做数据汇聚，也可以使用开源软件将数据汇聚到一个数据存储，然后在汇聚出来。关于 Docker 内存的超出被杀问题，这个主要是看你对于容器内存设置的容忍度问题，这里你大可以把容器当成一个机器，看到底给这个机器插多少内存合适。

Q：Promethues 有没有做高可用？

A：如果存储高可用的话，可以考虑使用两台 Prometheus 同时抓，这样数据完全一样，也没啥压力。

---

2017-06-22：Docker 的另类用法，就是这么简单粗暴

Q：请问从开始看 Docker 到完成环境搭建大概用了多长时间？

A：前期的学习和选型用了 2 个月。后面基础搭建用了 1 个月，耗时最长的是旧服务的 Docker 化，这个到现在还没全部完成，因为技术债太多。

Q：可以说明下为什么生产环境不用 Docker 吗，跟你们是金融公司属性有什么关系？

A：因为金融公司对于稳定性有非常高的要求，同时对于生产服务器数量和空置率又不敏感。所以 Docker 这样的新技术应用还是需要不会那么快切入。同时运维团队也要去学习，技术储备等都是阻碍。所以现在很多银行也只是在周围不重要，变化频繁的系统开始尝试 Docker。

Q：主要想了解下你们集成的流程？

A：CI 的流程和普通的 CI 类似。代码变动后触发 Jenkins，Jenkins 会编译，打包，产生一个对应的发布单元的新容器版本。然后触发对应的脚本来停服务，取镜像，启动容器。

Q：为什么不考虑在私有云平台上玩？

A：因为资源限制，从硬件及人力上都不足。另外就几十台服务器，没必要。如果有几百台就要考虑资源调度等因素。

Q：请问容器做编排管理，你们选用什么工具

A：我们只用了原生的 Swarm。这样不用考虑开源软件二次开发及工具间的版本兼容问题。

Q：如何让宿主机挂载到存储之后，让容器全部跑在存储里面？

A：容器本身还是在 Docker 主机的磁盘中，但其他数据：例如配置文件都是从 SAN 上挂载到容器中。这样保证如果 Docker 主机 down 了，容器可以在其他主机上重启恢复。

Q：z387 的 ip 如何分配？

A：Contiv 会帮你分配 IP 的，不用自己管理。

Q：为什么把 JIRA 也 Docker？

A：因为资源不足，没有强大的主机来跑 JIRA，也没有办法主备。所以干脆把这些重要系统都放到容器里。这样就可以用较少的主机来保证性能和可用性。

Q：镜像带环境变量属性吗？

A：看情况，我们跑自动化测试的镜像有环境变量属性，因为有很多可变参数。

Q：如果服务挂了，重启服务。重新修改 DNS 和 Nginx，问题 1：服务挂了，Swarm 可以负责重启吧？问题 2：为什么重启后需要改 DNS Nginx。Swarm的ingress 网络可以从任何一台 node 路由到对应的 Container 吧。

A：如果镜像 down 了，Swarm 会管理的。但如果是服务不可用，Swarm 是不知道的。这时候就需要在服务监控那里触发重启。由于服务还有端口的问题，所以是在 Nginx 上转发到真实的服务端口上。DNS 基本都是配置到 Nginx 上，如果 Nginx 挂了，就要把 DNS 重新指向。

Q：应用是 Java 的吗，根据环境不同的配置文件如何处理？

A：大部分是 Java 的，也有 Python 等。我们自己开发了一套配置文件管理的系统，同时对配置文件里的配置项进行命名规范，这样从一套环境到另一套大部分情况是直接自动进行修改的。

Q：如何做多版本环境隔离测试？

A：目前我们没有这样的需求。测试环境基本上都是和生产对齐。特殊情况是在 Jenkins 上来选择特定的代码版本来进行部署。所以在不同的环境里可以部署不同的代码。

Q：请问 Ngin 配置的是 Container 的 IP 还是物理机 IP？

A：Nginx 是暴露出 80 端口在容器宿主机上的。

Q：不同环境的配置文件是在镜像层面替换进去还是在容器层面替换进去

A：是在容器层面的。每个容器上有个 Agent，负责去拉取配置文件。

---

2017-06-11：深信服容器云的负载均衡实现

Q：HAProxy 是在 Kubernetes 内部对 pod 互通，是如何实现 pod 的发现的？

A：Kubernetes 有一个开源机制，叫做ingress 模块，提供了 pod 基于 service 的发现。

Q：Haproxy 是通过配置模版生成的吗？更新然后重载吗？

A：是通过配置模板来生成负载均衡的分发规则，我们时刻动态刷新配置，我们重载配置，链接达到 0 丢失。

Q：如果你们的 HAProxy 的 lb和ingress 一样仅支持四，七层的 lb，那么对于 Nginx 或者 traefik 的优势在于哪里呢？

A：各有优缺点，HAProxy 更加适用于我们的平台。对于 Nginx 等，我们更加轻量，更加简单 ，迭代快。

Q：HAProxy 经常 reload 有性能消耗，怎么做对单个发布的应用进行动态更新？之前新浪有 Consul + Nginx？

A：不存在性能消耗，我们针对于单个应用的动态更新与多个的性能差异很小，因为都是配置 重载。

Q：如何做到 HAProxy 重载配置链接 0 丢失的？

A：首先重载之前的 iptable 规则，丢弃握手包，重启之后，去掉规则，达到重载时间内新请求不丢失，原有链接，haproxy 提供机制支持，接管原来的链接。

Q：HAProxy 是怎么调用 service 的？ 直接调用 service 的群集 ip？

A：基于 Kubernetes 的 listwatch 资源监听，通过 service 对应的 endpoint 获取到 pod 的 ip。

---

2017-06-10：轻松筹监控系统实现方案

Q：针对 Grafana 不支持的报警，你们自己实现的报警引擎是直接在 grafana 的基础上修改的么，还是独立于 Grafana 呢？

A：我们用 Go 自己实现的一个报警引擎，独立于 Grafana。

Q：Logstash 你们遇到过收集慢和丢日志的情况吗？现在你们 Logstash 收集日志到什么规模了？

A：我们目前的日质量大概每天 2 亿条，高峰时候每小时 2000 万条左右。Logstash 运行的还可以，如果后期遇到手机慢，做简单的方式是扩机器，先解决问题，再想更好的优化策略。

Q：如果类似于 Nginx、MySQL 这种日志，类型增加需要解析每增加一个就要去改 Logstash 的 grok 吗？

A：针对常用的服务，grok 已经提供了一些正则的 pattern，例如你提到的 Nginx、MySQL。目前是每增加一个就需要修改 grok，后期可以实现一个 UI 来提高修改效率。

Q：这个 lostash 日志格式转换怎么学习？

A：Logstash 有很完善的文档，感兴趣的话可以参考 www.elastic.co/guide/

Q：据说 Logstash 比较吃内存，fluentd 作为 EFK 组合也经常出现，请问你们有没有做过选型呢？

A：当时选择了 ELK，就没有做太多的选型了，Logstash 吃内存的问题现在还不是太突出。

Q：日志的完整性怎么保证的？怎么知道没丢日志，或丢失了多少日志？

A：Filebeat 和 Logstash 的输出插件都有一些重试的策略，但是也免不了日志丢失。日志的完整性确实和保证日志不丢也是我们目前在尝试解决的问题。

Q：请问监控系统需要考虑高可用吗？

A：肯定是要考虑高可用，当后期更多的业务依赖监控系统后，就要保证监控系统不挂，查询要快，实时监控，报警准确等。

---

2017-06-04：如何扩展 Kubernetes 管理的资源对象

Q：需要扩展管理资源对象的场景是什么？能否举个例子说明一下？

A：举个例子，假如有这样一个场景，Nginx 作为反向代理，我们需要非常详细的管理具体配置，并且 Nginx 的 upstream 不单单是容器还有许多部署在物理机和虚拟机上的应用，这就要求我们需要具体定义专门管理 Nginx 的资源对象；由于企业应用场景是十分具体的，也就需要对于资源做具体描述。

Q：能否讲下具体应用场景和联邦后的用法？

A：场景上个问题讲过了，关于联邦我目前的方案是在自定义的 Controller 里做相关联系和操作。

Q：扩展 API Server 和通过 third party resource +controller 的方式相比有哪些优点？支持和多个集群的联邦吗？Kubernetes 社区对这两种扩展模式的态度是怎么样的？

A：首先 third party resource 在 Kubernetes 里一直不是很稳定，再者 third party resource 和原生资源有很多不同（可以参考官方文档），满足一些小的场景可以，但是对于深度定制化（资源之间关联、权限限制等），我还是会选择扩展 API Server。

---

2017-06-02：探索 Kubernetes 的网络原理及方案

Q：A 的 Pod 如何连接 B 的 Pod？ kube-dns 起到什么作用？kube-dns 如果调用 kube-proxy？

A：这里说的 A 和 B 应当是指 Service，A Service 中 Pod 与 B Service Pod 之间的通信，可以在其容器的环境变量中定义 Service IP 或是 Service Name 来实现；由于 Service IP 提前不知道，使用引入 kube-dns 做服务发现，它的作用就是监听 Service 变化并更新 DNS，即 Pod 通过服务名称可以查询 DNS；kube-proxy 是一个简单的网络代理和负载均衡器，它的作用主要是负责 service 的实现，具体来说，就是实现了内部从 Pod 到 Service 和外部的从 NodePort 向 Service 的访问，可以说 kube-dns 和 kube-proxy 都是为 Service 服务的。

Q：网络问题 docker default 是网桥模式（NAT）如果用路由的模式，所以 Pod 的网关都会是 docker 0 IP ？ 那 Pod 1 与 Pod2 之间也走路由 ，这会使路由表很大？ Flannel 网络是不是可以把所有的 Node 上，相当于一个分布式交换机？

A：Docker 实现跨主机通信可以通过桥接和路由的方式，桥接的方式是将 docker0 桥接在主机的网卡上，而路由直接通过主机网口转发出去；Kubernetes 网络有 Pod 和 Server，Pod 网络实现的方式很多，可以参考 CNI 网络模型，Flannel 实质上是一种”覆盖网络（Overlay Network）”，也就是将 TCP 数据包装在另一种网络包里面进行路由转发和通信。

Q：大规模容器集群如何保证安全? 主要从几个方面考虑？

A：一个大规模容器集群从安全性考虑来讲，可以分为几个方面：1、集群安全，包括集群高可用；2、访问安全，包括认证、授权、访问控制等；3、资源隔离，包括多租户等；4、网络安全，包括网络隔离、流量控制等；5、镜像安全，包括容器漏洞等；6、容器安全，包括端口暴露、privileged 权限等。

Q：SVC 如何进行客户端分流，A 网段的访问 Pod1，B 网段的访问 Pod2，C 网段的访问 Pod3，3 个 Pod 都在 SVC 的 Endpoint 中？

A：内部从 Pod 到 Service 的实现是由 kube-proxy（简单的网络代理和负载均衡器）来完成，kube-proxy 默认采用轮询方法进行分配，也可以通过将 service.spec.sessionAffinity 设置为”ClientIP”（默认为”无”）来选择基于客户端 IP 的会话关联，目前还不能进行网段的指定。

Q：对于 Ingress+HAProxy 这种实现 Service 负载均衡的方式，Ingresscontroller 轮询 Service 后面的 Pods 状态，并重新生成 HAProxy 配置文件，然后重启 HAProxy，从而达到服务发现的目的。这种原理对于 HAProxy 来讲是不是服务会暂时间断。有没有好的替代方案？之前看到 Golang 实现的 Træfik，可无缝对接 Kubernetes，同时不需要 Ingress 了。方案可行么？

A：由于微服务架构以及 Docker 技术和 Kubernetes 编排工具最近几年才开始逐渐流行，所以一开始的反向代理服务器比如 Nginx/HAProxy 并未提供其支持，毕竟他们也不是先知，所以才会出现 IngressController 这种东西来做 Kubernetes 和前端负载均衡器如 Nginx/HAProxy 之间做衔接，即 Ingress Controller 的存在就是为了能跟 Kubernetes 交互，又能写 Nginx/HAProxy 配置，还能 reload 它，这是一种折中方案；而最近开始出现的 Traefik 天生就是提供了对 Kubernetes 的支持，也就是说 Traefik 本身就能跟 Kubernetes API 交互，感知后端变化，因此在使用 Traefik 时就不需要 Ingress Controller，此方案当然可行。

Q：1、一个 POD 里面的多个 Container 是同一个 Service 的？还是由不同的 Service 的组成？是啥样的分配逻辑？ 2、Flannel 是实现多个宿主机上的 N 多的 Service 以及 Pod 里面的各个 Container 的 IP 的唯一性么？3、Kubernetes 具备负载均衡的效果 。那是否就不用在考虑 Nigix？

A：Pod 是 Kubernetes 的基本操作单元，Pod 包含一个或者多个相关的容器，Pod 可以认为是容器的一种延伸扩展，一个 Pod 也是一个隔离体，而 Pod 内部包含的一组容器又是共享的（包括 PID、Network、IPC、UTS）；Service 是 Pod 的路由代理抽象，能解决 Pod 之间的服务发现问题；Flannel 的设计目的就是为集群中的所有节点重新规划 IP 地址的使用规则，从而使得不同节点上的容器能够获得”同属一个内网”且”不重复的”IP 地址，并让属于不同节点上的容器能够直接通过内网 IP 通信；Kubernetes kube-proxy 实现的是内部 L4 层轮询机制的负载均衡，要支持 L4、L7 负载均衡，Kubernetes 也提供了 Ingress 组件，通过反向代理负载均衡器（Nginx/HAProxy）+Ingress Controller+Ingress 可以实现对外服务暴露，另外使用 Traefik 方案来实现 Service 的负载均衡也是一种不错的选择。

Q：kube-proxy 是怎样进行负载？ Service 虚拟 IP 存在哪里？

A：kube-proxy 有 2 个模式实现负载均衡，一种是 userspace，通过 Iptables 重定向到 kube-proxy 对应的端口上，然后由 kube-proxy 进一步把数据发送到其中的一个 Pod 上，另一种是 Iptables，纯采用 Iptables 来实现负载均衡，kube-proxy 默认采用轮询方法进行分配，也可以通过将 service.spec.sessionAffinity 设置为”ClientIP”（默认为”无”）来选择基于客户端 IP 的会话关联；Service Cluster IP 它是一个虚拟 IP，是由 kube-proxy 使用 Iptables 规则重新定向到其本地端口，再均衡到后端 Pod 的，通过 apiserver 的启动参数--service-cluster-ip-range 来设置，由 kubernetes 集群内部维护。

Q：Kubernetes 网络复杂，如果要实现远程调试，该怎么做，端口映射的方式会有什么样的隐患？

A：Kubernetes 网络这块采用的是 CNI 规范，网络插件化，非常灵活，不同的网络插件调试的方法也是不一样的；端口映射方式的最大隐患就是很容易造成端口冲突。

Q：RPC 的服务注册，把本机 IP 注册到注册中心，如果在容器里面会注册那个虚拟 IP，集群外面没法调用，有什么好的解决方案吗？

A：Kubernetes Service 到 Pod 的通信是由 kube-proxy 代理分发，而 Pod 中容器的通信是通过端口，不同 Service 间通信可以通过 DNS，不一定要使用虚拟 IP。

Q：我现在才用的是 CoreOS 作为底层，所以网络采用的是 Flannel 但是上层用 Calico 作为 NetworkPolicy，最近有一个 Canal 的结构和这个比较类似，能介绍一下么，可以的话，能详细介绍一下 CNI 原理和 Callico 的 Policy 实现么？

A：Canal 不是很了解；CNI 并不是网络实现，它是网络规范和网络体系，从研发的角度它就是一堆接口，关心的是网络管理的问题，CNI 的实现依赖于两种 Plugin，一种是 CNI Plugin 负责将容器 connect/disconnect 到 host 中的 vbridge/vswitch，另一种是 IPAM Plugin 负责配置容器 Namespace 中的网络参数；Calico 的 policy 是基于 Iptables，保证通过各个节点上的 ACLs 来提供 workload 的多租户隔离、安全组以及其他可达性限制等功能。

Q：CNI 是怎么管理网络的？或者说它跟网络方案之间是怎么配合的？

A：CNI 并不是网络实现，它是网络规范和网络体系，从研发的角度它就是一堆接口，你底层是用 Flannel 也好、用 Calico 也好，它并不关心，它关心的是网络管理的问题，CNI 的实现依赖于两种 plugin，一种是 CNI Plugin 负责将容器 connect/disconnect 到 host 中的 vbridge/vswitch，另一种是 IPAM Plugin 负责配置容器 Namespace 中的网络参数。

Q：Service 是个实体组件么？那些个 Service 配置文件，什么部件来执行呢？

A：Services 是 Kubernetes 的基本操作单元，是真实应用服务的抽象，Service IP 范围在配置 kube-apiserver 服务的时候通过–service-cluster-ip-range 参数指定，由 Kubernetes 集群自身维护。

---

2017-05-24：喜马拉雅 FM 测试环境的 Docker 化实践案例

Q：镜像精炼影响很大吗？Docker 相同层不是只下载一次吗？

A：我们绝大部分是 Java 项目，通常一个 war 包五六十 M，更大的也有，占用一个 layer。频繁的发布和部署，仅仅是下载这一个 layer，时间上还是有一点耗时的。

Q：网络对于 Kubernetes 出来容易，进去很难。不知道你们说的物理机和 Docker 网络是怎么互通的？希望能详细说下。

A：首先通过 docker ipam driver 我们为每个容器分配一个 IP，Docker 本身也支持 MacVLAN，不准确的说，相当于每个容器有一个物理网卡，只是和物理机网段不同。我们通过交换机连通两个网段。

Q：问一下，配置的统一管理是怎么做的？哪些配置信息做了统一管理，数据库的链接信息也是放到配置信息里吗？

A：可能我文中用配置一词不太对，文中的配置更多指的是，Tomcat 的安装目录，Tomcat 的 Web 端口、debug 端口号，日志目录命名等约定。这个是做镜像时便已经确定的。

Q：容器有了固定 IP 那么就不需要 NAT 了，那么在原 Mesos 下的服务发现就不适用了，能详细介绍下这块怎么搞么？

A：从根本上，不管容器 IP 变不变，因为以后做扩容缩容，我们认为服务的 IP 总是会变得。因此我们写了 Nginx 插件等额外组件来屏蔽 IP 的变化，而不是尝试让 IP 不变。

Q：怎么收集 Tomcat 启动时的 log？ 有没有想过用 WebSocket？

A：我们公司有自己的日志采集系统，可以采集并分析业务日志。至于 Tomcat 日志，我们业务上暂时还不需要采集。我们有自己的手段来采集 Tomcat 运行状态。这里顺便说下，很多方案我们的选择，是基于公司目前已有的一些框架工具，大家要按照自己的情况因地制宜。

Q：将容器的应用端口映射到主机端口，能不能解决 IP 变化问题？

A：因为容器会在主机之间漂移，我们通过”物理机 IP：物理机 port”来访问容器时，容器对应的物理机 IP 在 deploy 后，还是会变得。

---

2017-05-19：基于 Kubernetes 的私有容器云建设实践

Q：请教一下处理 CI 时，比如集群自动化部署方面的粒度是怎样的？比如修复一个 bug 改了一个 class 文件，然后本地测试完之后需要到线上部署进 AB 测试，那么就直接通过 CI 自动部署到集群服务器吗？

A：我们的做法是只要有修改就触发重新构建，这只适合我们公司的情况，您可以根据自己的情况做出粒度选择。

Q：能详细说说 Dubbo 应用迁移遇到的问题及解决办法吗？

A：解决方案比较粗暴，对于 Flannel，Container 可以往出去，但是外面的请求进不到 Container，因为我们物理机规模有限，我们就配置静态路由，只要让到达 Node 的能找到 Container 就行了。

Q：自动生成 Dockerfile 的目的是什么？这样做有什么优势？

A：这个问题有两个方面，第一个是标准化规范化的问题，我们的应用大多是 Java Web，相似度很高，所以可以自动生成，没有什么特殊需要开发自己写的；另外，我们在 CI 平台里，留出了编辑 Docker 的口子，也可以针对特殊的情况自己编写，但是这种是非常少数的情况。CI 跟每个企业的业务情况紧密相关，还是具体情况具体分析吧。

Q：我起了一些 Pod，对外有 Service，然后我想让 Pod 实现单任务，但问题是，Service 对 Pod 选择机制是随机的，也就是说有可能会出现多个任务请求到一个 Pod 上，达不到我的要求，怎么解决？

A：这个问题我个人的理解，您要解决的问题跟一个 Service 对应多个 Pod 的场景不太吻合，我建议您考虑其他的方式实现，比如多个 sevice-pod 的组合等等，或者考虑其他的方式。

Q：「Kubernetes master 高可用」如何设计？多个数据中间是 stand-by 关系？

A：API Server 是无状态的，可以部署多个，前端负载均衡，Scheduler/ControllerManager 有状态可以做成主备。Kubernetes 还算稳定（当然我们的量小）。

Q：贵司使用的 Kubernetes 版本是？RBD 锁死的问题只能通过手动解锁来解决吗？有其他方案吗？

A：我们上线比较早，生产系统还是 1.2 版本，我们正在升级 1.6 版本。RBD 我只尝试了手动解锁的方法，别的方法没有尝试。

Q：想问下关于你们 Kubernetes 分布式存储的选择，以及在使用当中遇到了那些问题？

A：我们应用不挂盘，所以使用 Ceph 的场景不多。使用 RBD 没遇到什么问题，有些场景我们需要共享存储（Filesystem)，因为我们人手有限，没精力尝试 Ceph FS 或者其他方式，这算个问题吧。

Q：在 EFK 的架构中有 Kafka 的存在，目的何在？是保证日志不丢失，还是提高吞吐量？

A：主要是做 Buffering 缓冲，我们这个里还有个别日志需要中间处理的过程，从 Kafka 取出加工，再放入 Kafka，最后到 Elasticsearch。

Q：能否详细介绍下 CI 系统考核的重要标准:对常用技术栈和配置进行标准化。具体对哪些指标做了标准化？技术方面如何实现的？

A：对于 Java 应用，我们只提供 JDK 7 和 JDK 8，规定日志目录的位置，提供标准的 Log4j，配置与代码分离，war 包与环境不管等等强制的要求。

Q：Docker Registry 的镜像复制是如何实现的？

A：跑脚本、docker save、scp、docker load，这种做法比较 low，建议直接用 Harbor 做吧。

Q：请问 Dockerfile 自动生成是如何实现的？

A：根据模板生成了，比如对于 Java Web，在规定好日志输出目录等情况系，可变的只是工程名称等很少部分，名称 CI 系统知道，所以就可以自动生成了。

Q：kube-proxy 那边性能怎么样？还有一个问题就是一些特定的容器的固定 IP 是怎么做的？

A：我们量比较小，没有性能瓶颈，1.2（具体记不清了）以后 kube-proxy 是纯 iptables 实现，没那么差吧，业内也有用 HAProxy 等代替的，个人觉得没必要。特定的容器固定 IP 我们没有实现，我们没有这种场景。你可以折中一下，给个 NodePort，固定 IP 我个人觉得尽量少用为好。

Q：镜像的自描述能否展开讲讲呢？

A：就是每个镜像里都有描述它构建过程的 Dockerfile

Q：对于你们现在使用的这套容器云平台，服务之间的依赖是怎么实现的？怎么区分的环境？另外应用健康检查和追踪用的是什么方案？

A：服务之间的依赖指什么？如果是应用，他们还是通过 Dubbo 走，如果是非 Java 得应用，就通过 Service 调用。我们在不同的环境部署了 Kubernetes 集群，每个集群也部署了管理系统，这样就知道每个系统对应哪个环境了。健康检查就是通过 Kubernetes 的健康检查机制实现的，livenessprobe。

Q：多数据中心灾备能具体讲一下吗，是在多个 dc 有多套一样的集群，全部是冷备状态吗？

A：我们生产有三个数据中心，每次发布，我们都会向每个数据中心发请求，不是冷备，是多活。

Q：监控体系搭建得细节和监控内容都是哪些，比如 CPU 内存，Pod 事件等，包括告警体系？

A：这个问题很好，我们这方面做得非常不足，监控的标准我们刚刚拿出细节方案。我们现在的方案是把 CPU 这些指标输出到日志中心（包含监控报警部分），由日志中心来完成。Pod 事件等还没有监控报警。

Q：日志如何让组件方方便查看同时可以排查问题，比如启动时的日志？

A：应用日志通过日志中心（ELK）查看；启动日志通过容器云界面查看，通过 Kubernetes 的 API 接口实现。

Q：很多组件有 IP 白名单的问题，而 Kubernetes 集群 IP 经常变换 ，如何解决？

A：要么改组件，要么在网络层做限制（比如 Calico 或者其他的），尽量别在 Kubernetes 层解决。

Q：容器管理平台是自研的吗？使用何种语言开发的？是全部基于 API 接口吗？

A：是自研的，前台 AngularJS，后台 Golang，全部基于 Kubernetes 的 API，开发过程比较简单，Kubernetes 的 API 设计的非常完善，推荐尝试。

---

2017-05-14：容器技术在企业级服务里的实践

Q：请问在容器和虚拟机之间访问网络有什么经验，通过 Calico 使跨主机之间容器互访，容器外的虚拟机如何访问容器，特别是在公有云环境下 PaaS 服务如何与容器之间进行访问？

A：我们现在公有云 PaaS 每个用户是一个虚拟机的方式，虚拟机内部的通讯采用的默认的网络方式 Overlay，在不是大并发情况下这种问题并不明显。

Q：容器是否裸机部署、容器编排和调度工具？

A：我们私有云产品是裸机部署，容器编排和调度工具目前有版 Kubernetes。

Q：请问你们的私有云建设主要用了什么软件？

A：私有云就是裸机 + 容器 + 编排工具 + 基础能力容器（比如消息、SDN 等）。

Q：Auto Scaling 是垂直的，还是水平的？

A：是水平扩展的，就是在另外设备里面重新启动一组容器，并且将数据库容器加入到 ge 节点中取。

Q：微服务注册，服务发现是怎么做到的？

A：微服务注册分成 2 部分：1. 微服务是否经过了云审核，是否能通过 LOTE 网关验证；2. 在内部是通过 etcd 一整套来实现的（健康检查）。

---

2017-05-09：沪江容器化运维实践

Q：请问 Prometheus 具体怎么玩的呢？比如，冷热存储 Metrics 数据有做什么处理吗？告警只用了 Grafana4.0 的吗？

A：可以自己私下看看先关文档，这里一时半会也说不清；Metrics 数据时以时序方式持久化在 Prometheus 中，不做任何处理，基于类 SQL 方式查询；查询语句中可以设置过滤，或者条件查询；Grafana 4.0 及以后才支持报警，同时传统的监控报警也有 Zabbix。

Q：请问不同应用的 QoS 怎么实现的？容器的租户管理和粒度是怎样的？

A：流量控制这块可以考虑在 HAProxy、或者 Nginx 这块来做 API Gateway；目前我们容器就自己使用，租户管理这块没有细分。

Q：请问 Marathon 部署的流程是怎么样的，新版本是替换老版本是创建新的 APP，删除老的，还是怎么样的，APP 命名规范有没有什么建议。容器部署后如何注册到 Nginx 上，容器的 IP 如何与上游 Upstream 域名进行关联呢？

A：先按照一定比例（2 个）发布新的实例，然后删除老的实例，最终实现实例数目一致；命名最好有规范，防止冲突；Nginx + Consul serve r + Agent + Template 可以解决你的所有疑问。

Q：在此网络环境中是否会出现网络问题导致系统异常？

A：我们之前遇到过 Docker 1.9.1 低版本 bug 导致网络丢包，后来升级了 Docker 至 12.5，问题解决；目前使用内核 4.4.18，Docker 1.13.0，没有任何网络问题。

Q：问下普罗米修斯的集群这么做的？后端数据库没有没考虑过 OpenTSDB 呢？

A：目前单机没有性能瓶颈，如果存在性能问题可以考虑分机房部署，最终的展示和报警统一放在 Grafana 上面；没有使用 OpenTSDB。

以上内容根据 2017 年 5 月 9 日晚微信群分享内容整理。分享人耿旭东，沪江教育运维架构师。目前主要从事容器技术学习研究、Ceph 分布式存储系统维护、沪江部分业务运维相关工作。

---

2017-05-04：某股份制商业银行定制化 PaaS 介绍

Q：弹性这块，扩容好说，缩的话有个问题，就是还有用户请求在这个容器上，怎么办？

A： 在该项目中我们并未对这种情况做特殊处理，但是在我们另外的产品中，已经考虑到了该问题。正确的方法应该是基于ingress 设置一个销毁容器的宽限时间，即：在这段时间内，不允许新流量导入即将销毁的容器，这些容器在该宽限时间到期后，自动销毁。

Q：感谢分享，对弹性伸缩部分请教一下:您分享的弹性伸缩的场景业务周期性很明显，所以基于时间区间触发采取不同的伸缩操作，如果业务周期性不明显，伸缩机制能处理吗？如何处理？

A：在当前项目中，客户明确要求按照 1 天为周期。在我们自己的 PaaS 产品线中，弹性伸缩可以调整周期（比如：星期、月份等），另外，还可以不按照时间周期，直接基于 CPU、内存或者某一个可监控项。你可以理解为只要能够被监控的监控项，都可以作为弹性伸缩的依据。

Q：我目前关注的是日志这块，怎么才能把日志集中在一起，能不能说的具体点？

A：我们是将日志收集后，统一发送到 kafka 集群，你可以理解为拷贝一份集中存储到 kafka 集群。这里的集中不是什么难点，难点在于对日志的收集，涉及三个层面：主机、容器、应用。我们的方式是在各台主机上部署容器化后的 logstash，然后通过程序修改其配置模板，从而收集不同目录的日志。而这些目录就分别对应着主机日志、容器日志映射到主机的目录、以及应用日志映射到主机的目录。

Q：根据日志标签获得应用日志目录，请问容器标签具体是什么格式的，采集日志信息中包含节点信息，容器信息，应用信息等跟平台、应用相关的元数据字段吗？

A：这里的日志标签是可以自定义的，相当于主机上的 daemon 程序会监听该主机上容器的创建、销毁等 event，一旦发现容器创建，就去 check 其标签，是否有自定义的”日志目录信息”，”日志文件扩展名信息”。这些日志目录都有对应的 volume 挂载到宿主机上，因此通过分析容器的 inspect 信息，就能够找到日志目录映射到宿主机的目录。而你提到的节点信息，这些是每个宿主机上的日志收集的服务容器在启动的时候就定义好的，所有由它收集并发送出去的日志，都会有该宿主机的标签。

Q：关于日志收集的时间取值问题，是日志收集点的本地时间还是系统时间，具体如何保持一致？NTP？

A：是日志收集点的本地时间，具体通过 NTP，但是要注意，需要保障容器时间与宿主机时间（时区）要保持一致。

Q：弹性伸缩另一个问题，如果不是周期性弹性伸缩是否考虑避免短期脉冲现象引起的不必要的弹性伸缩操作？

A：所以在弹性伸缩的规则里面有一个参数为：”retrigger time” 也可以把它理解为一个安全的时间片，再一次伸缩动作之后，必须要等待这个时间片结束之后才会再次触发弹性伸缩行为。否则不予响应。

---

2017-04-20：基于 Neutron 的 Kubernetes SDN 实践经验之谈

Q：请问 Skynet 用到的 neutron-linux-agent 需要部署到所有 kubelet 节点上吗？另外有没有开源的 demo 版本学习下呢？

A：需要部署，这个 Agent 不只是安全组，对 VXLAN 类型的网络，它还可以编写 FDB 规则实现 VXLAN 网络。代码开源正在筹划中，再测试一波，就会发布。

Q：感谢分享，请问你们有没有在在一个虚机内的 pod 需要挂到不同网络的场景？如果有的话，pod 之间跨二层网络的互通你们是怎么做到的？

A：目前来看，单个 POD 挂接到不同网络里的场景还比较少，但逻辑上来说，跟设置单网络的方式区别不大，只是默认路由走哪张网卡的问题值得商榷。POD 之间跨二层网络互通可以通过物理交换机配置两个 VLAN 互通或者直接通过 Neutron 的 vRouter 做网关。

Q：还有个问题，当一个 Docker 物理机 down 了，上面的容器会自动迁移到另一个节点还是 Kubernetes 自动启动相关的容器！能否实现特定容器在不同的 Kubernetes 节点上自动迁移而且保持 ip 不变！

A：除非 POD 指定的调度需求无法满足，Kubernetes 会自动尝试迁移 POD 到其他主机上启动。POD IP 的保持还支持通过注解的方式设置 POD 的 IP，当然需要限制 RC 的副本数只能是 1 或者运行的是单 POD，否则会出现 IP 冲突。

Q：容器的 port 支持 Neutron 的一些 QoS 特性吗？例如限速。

A：据我对 OpenStack 的调研，Neutron 的网络限速使用的是 tc 规则定义的，在使用 Linux bridge+VLAN 网络的情况下，Skynet 可以保证 POD 的网络配置与 VM 的配置一致，从而使 QoS 规则能够正常运作，实现限速。其他特性暂时还没有研究过，后期会继续调研。

Q：Skynet 目前支持 Overlay 的网络吗？如何解决内网和外部网络相互访问呢？

A：目前 Skynet 支持使用 Neutron 的 VXLAN 网络实现 Overlay，结合 Neutron vRouter 的外网网关功能，通过设置路由为 vRouter 的外网网关，使内外网能够互通。

Q：请问 Veth 设备另一端连接的是什么设备？

A：Veth pair 是 Linux 网络的基础技术，Veth 总是成对出现的，所以 Veth 的另一端还是一个 Veth，可以连接到 bridge 上或者直接暴露在主机上。

Q：目前 OpenStack 社区也有一个类似的项目 Kuryr，你能简单介绍下你们的方案和 Kuryr 的差异吗？

A：Kuryr 是社区项目，考虑的不像我们 Skynet 这么简单，可以短平快地以实现功能为首要目标，而 Kuryr 需要考虑的就比较多，需要同时支持 Docker 的 CNM 和 Kubernetes 的 CNI。我们的 Skynet 从去年 11 月份开始调研实现，当时 Kuryr 的 Kubernetes 支持还只是个空壳子。现在，根据 Kuryr 在的 BP，我们的实现思路差别不大，只是 Kuryr 更多的考虑了租户对接等等问题。

Q：pod 的 IP 保持是怎么做到的能详细介绍一下吗？如果 pod 名字发生变化了，可以保持吗？

A：如前面两个类似问题，POD 的 IP 保持通过两种方式：如果 POD 名称不变（比如 StatefulSet 中的 POD），则对应的 port 就不会变，因此根据 port 设置的 POD IP、MAC、主机名都不会变。如果 POD 名称变化，在一定的约束下，通过注解保留 POD 的 IP 地址信息，强制使 POD 保持 IP 不变。

以上内容根据 2017 年 04 月 18 日晚微信群分享内容整理。分享人冯建建，天云软件 ECP 开发工程师，主要负责 ECP 容器管理平台的网络、存储等方面的功能实现。熟悉 CloudStack、OpenStack 等开源 IaaS 平台软件。最近专注于容器集群管理平台的技术实践，包括 Kubernetes、Swarm，对它们的网络实现、存储实现都有比较深入的了解。

---

2017-04-06：从一个实际案例来谈容器落地的问题

Q：我想问一下，日志打两份的话具体是怎么实现的呢，用到了哪些技术或现有的工具呢？

A：我们自己实现了一个 log-agent, 然后 log-agent 可以实现这个功能。

Q：如果应用有自己的写的日志，如 log4j 的，输出不到标准输出，还怎么处理？

A：log4j 貌似是可通过配置输出到标准输出的，另外如果有些应用不能输出到标准输出的，可以配置日志文件路径，我们会去读文件。

Q：缩容的产生条件是否有比较好的解决方案，比如根据 CPU、内存甚至业务规则多维度的进行考察？

A：缩容很容易，但是麻烦的是如何安全的缩容，我理解这个环节其实是跟应用的逻辑有直接关系的，如果应用是一个无状态的应用，那么缩容非常简单，只需要在前端控制流量，然后停止容器即可，但是如果是有状态的应用，那么就有可能对用户造成影响。

Q：配置管理这块，不断的覆盖会增加镜像体积，如何最大化减少镜像大小呢？

A：首先，一个镜像最多被覆盖 2，3 次，测试镜像一次，生产镜像一次，而且配置文件一般是很小的，几乎对镜像大小没有影响。

Q：测试环境配置文件覆盖开发环境镜像，是只用测试环境的 docket file 吗？如果每天打版，会很麻烦吗？

A：通过覆盖测试文件来解决环境问题，只是一个思路，不一定非要使用开发测试环境的信息，这个可以具体情况具体分析。

Q：log-agent 具体实现呢，日志直接打给 log-agent 还是 log-agent 读取本地日志文件呢？或者说 log-agent 读取标准输出的内容呢？

A：log-agent 可以通过 Docker 的 log-driver 获取标准输出的日志，同时也可以直接读取日志文件的日志。

Q：配置 ENV 化完全可以由运维来实现，容器的启动交由脚本来执行，然后在脚本中来读取所有的 ENV 并修改应用，完成后再启动应用，这样就只需要来维护脚本了。

A：是个好主意，但是我们当时考虑配置文件覆盖这个方案的时候，是基于开发人员不对代码做任何修改的思路来考虑的。

Q：容器生命周期很短？如何做到动态监控？你们具体监控了哪些重要指标？谢谢。

A：我们监控用的是 Prometheus 方案，监控做了 主机，容器，中间件 几个大的范围。

---

2017-04-02：Flannel 中 vxlan backend 的原理和实现

Q：Flannel 创建多个网络，并且实现网络之间隔离可以实现吗？

A：是的，最新的 Flannel 中已经加入管理多个网络的能力，你可以在启动时制定多个网络，etcd 中配置信息的的格式略有不同，启动 flanneld 时有参数可以制定初始化哪几个网络。> Q：如果使用 Flannel 过程中发现，跨节点无法访问，该从哪些方便着手排错？

A：首先看一下你指定的虚拟网络是否和现有物理网路中的网段冲突了；然后检查节点之间的 UDP 端口是否可以连通，最后还需要考虑当前系统是否支持 VXLAN，最低要求 v3.7，建议 v3.9+，CentOS7 的默认内核已经可以满足要求。

Q：过一组测试数据两台 VM to VM (vlan): 7.74 GBits/sec，使用 flannel vxlan，两个 container 之间 1.71 GBits/sec，请问这个数据正常吗，vxlan 的带宽损耗发生哪, 有啥调优思路，谢谢。

A：首先我想确认一下你测试的结果是 TCP 还是 UDP，建议实际测试一下，这个是我在 Digital Ocean 上 2 台 VPS 间的测试结果，仅供参考：搞清楚原理以后，相信很容易判断瓶颈位置：节点之间是通过 UDP 来转发 L2 的数据包的，我认为这部分可能有比较大的嫌疑。

Q：Flannel 在使用过程中，如果需要新增网段，如何让每个节点获取最新的路由表信息？需要更新所有节点的 Flannel 配置项，重启 Flannel 吗？

A：这个问题其实还不错，比较接近实战了；首先你确实可以重启 flanneld 来更新网络配置；然后 Flannel 每 24h 会自动重新分配集群内的网络，所以你就算不重启，每 24h 也会自动刷新本地网络的，如果发现本地网络配置不符合 Flannel 在 etcd 中配置的要求，会重新生成网络配置。

Q：我在项目中用了 flanne lvxlan backend。按照文中说法，转发由内核进行，Flannel 挂掉并不影响通宵。但是实际使用中，Flannel 挂掉确实导致外部其他访问不到 Docker。请问这个可能是什么原因？

A：首先要澄清一下，并不是说挂掉网络没影响，flanneld 挂掉会导致本地的 ARP entry 无法自动更新，但是已经生成的网络环境还是可用的，具体可以看我前面手动搭建 overlay network 的过程，根本在于 ARP table。

---

2017-03-19：Docker 在沪江落地的实践

Q：Ceph 集群在使用过程中有遇到过什么坑吗，能否分享一下？

A：Ceph 集群在产线环境上使用的确有很多问题要注意，但这和本次分享没有什么关系，下次我可以分享一些 Ceph 集群我们遇到的问题及解决方案。

Q：日志如何进行搜集，出现业务故障时如何快速定位问题或者线上 debug？

A：日志是通过卷挂载 Host 的方式放在了统一的文件夹下，由 Logstash 收集后上报 ES 后通过 Kibana 展现出来。如果出现故障，运维系统会出现报警，我们根据 ELK stack 看到问题所在。

Q：基础架构层的分布式存储是否使用的 Ceph，存储集群的规模是多大？

A：的确，我们使用的是 Ceph 作为分布式存储。主要使用的是它的 file system 与 Object storage。规模上，OSD 有 20 台，存储容量在 900T。

Q：存储方案为什么需要实现多种 volume 方案？

A：由于业务的需要，Docker 不但要把日志输出到 HOST 的磁盘上给 ELK 使用，还要挂载 Ceph 文件存储，两者对应的驱动是不一样的，HOST 磁盘使用的是 Direct-lvm，而 Ceph 分布式文件存储使用的是 ceph-fuse。

Q：Docker 怎么跟现有的业务之间相互访问，网络层 IP 怎么解决的？

A：正如刚才我分享的，我们使用 Docker Network 作为我们网络的解决方案。在 Docker Network 中，我们创建了一个 Overlay 网络，容器之间有内部网络，路由表存储在 zk 中，容器中有两个虚拟网卡，一个对在 Overlay 中同网段的容器，一个对 HOST。Overlay 的 IP 范围是可以设置，建议不要设置太大，容易引起网络风暴。

Q：使用 Docker Network 跨主机的容器 IP 是否能互通？

A：能，而且必须能，否则这种方案是无法使用的。补充一点，Docker Network 还能通过访问控制，来隔离各个 Overlay 网络的互访。

Q：网络存储是怎么和 Ceph 结合的呢，利用 Ceph 的 rbd 挂载到主机上吗？

A：很多公司都是这么做的。不过我们没有这么干，因为 rbd 是块存储设备，相当于在 Docker 中挂载了一块裸盘，没有文件系统无法使用。我们还是使用 ceph-fuse 并使用驱动的形式挂载载 Docker 内。

Q：转码是 CPU 和内存密集型操作，请问当初是基于怎样的考虑上 Docker 的？

A：这个问题其实挺有意思，有人大概还不了解转码，其实就是音视频的码率、编码格式转换的处理。例如把一个 mp4 视屏，转换成 HLS 切片格式。这的确是消耗 CPU 和内存的操作。但是，我们有 Mesos 这个强大的资源管家。如果一个视频过长过大，一台服务器转码速度太慢，可以切成小份让多台服务器一起工作，再合并起来。Docker 的优势就体现了，我们把转码称为 worker，当每个 work 接收到任务后，让 Mesos 调度资源，工作完成后立刻回收资源。这样既不浪费服务器也更能体现微服务，有兴趣的同学可以阅读我的另一片文章：Juice 任务调度系统。

Q：能做到根据压力自动扩容么？

A：可以的。我们开源一个自动扩容程序，它的主要思想是：定时检查 Mesos 的 Metrics 中 CPU 和内存的占用，如果达到一个阈值，便给 Marathon 发一个扩容请求，Marathon 接收到请求后便可按一定的比例扩充服务。如图所示：

Q：请教一下关于容器的资源分配和程序切分问题，我有很多服务容器，放的是 Java Web Serive，每次启动就占了 128m 内存，4G 内存的主机也就放 20 个服务，io wait 达到 10%，希望能给一些建议，谢谢。

A：这个问题我们曾经也遇到过。不光 io wait 高，连 Swap 区占用都很厉害。后来研究发现了，其实这是 Docker CGroup 内存隔离的锅。当我们的 Docker 容器分配过少的内存后，应用程序的内存不够用，Docker 会认为物理内存已经占完，会使用交换区，也就是硬盘中的 Buffer 作为内存，这样就会导致频繁的 io 交互。在高并发的状态下，io wait 就高了。解决方式是，扩大 Docker 的内存设置。

Q：传统的 Java Web 型应用如何放到容器里，一个镜像都要 600m 左右？

A：如果使用官方的 Java 基础镜像，它的操作系统选用的是 Debian，自然很大。我们使用的 java-jre:alpine 镜像，Alpine 是最小的 Linux 集合，只有 5m，加上使用 jre，基础镜像只有 140 多 m。Java 框架使用 Spring Boot，再加上微服务的拆分，一个典型的 Web 应用也就 200m 左右。

Q：Mesos 集群本身怎么鉴控？是否可以自动化排除集群故障，如网络异常导致的数据不一致？

A：Mesos 集群由 Mesos 的 master 监控着，我们也是用 Zabbix 等对上面的 Mesos 服务做着监控。但 Mesos 中任何 Slave 有问题，对线上业务不会受到影响，这得益于 Marathon 这个应用程序的保姆，会自动在可用集群内迁移应用程序。至于网络异常导致数据不一致的问题，我们还真没遇到过，我们大部分的服务是无状态的服务，对有状态的服务一般采用主、从、选主三服务的经典 HA 方案。

---

2017-03-09：中小型团队的容器化之路

Q：我有几个问题请教： 1.底层是否使用了虚拟化？2.技术选项时没考虑 Rancher？ 3.健康检查 i 是否可以动态设置？

A：底层使用了虚拟化，考虑过 Rancher，但是当时太早 Rancher 非常不稳定，后来还是放弃了，前几天线下跟他们团队交流过貌似重写了，值得大家试试。健康检查的 i 是逻辑上的，健康检查本身没有这个配置项，i 可以通过 Scale 功能随时调整。

Q：请问你们是否使用了 CI/CD 工具？如何贯穿整个应用的周期的？

A：这个问题太大了，可以另开一个头了。 我们使用 Jenkins 做 CI，生产的 CD 还有达到，发布的时候都是手动发布人盯着。

Q：我们目前在用你们的产品，只要用来统计安卓和 IOS 端的用户行为数据，我们也有自己的容器，并且编排工具是 Kubernetes，目前其他还算稳定，就是偶尔出现资源分发时不同集群的状态不一致，请问能否用 Marathon 去替换解决，是不是代价有点大？

A：我的建议是继续使用 Kubernetes，Marathon 并不是完全没有 bug，使用过程中同样会有坑在里面，Kubernetes 发展很好，只不过 Marathon 对我们而言更合适。

Q：问题 1. 数据库有用到容器吗？需要注意什么？问题 2.生产环境镜像更新，镜像较大，然而每次只更新一个文件，有什么好的建议？

A：问题 1. 测试环境有用到数据库的容器，主要是部署比较方便。生产没有用到，还是性能问题吧。问题 2. 基础镜像要选好，不要把容器当虚拟机用，JVM 的语言打包出来算大了，也可以控制在 200M 左右。

Q：你们是针对每个环境都打包不同的镜像？还是使用同一个镜像？配置管理怎么做的？可以做到配置动态加载吗？

A：不是针对每个环境打不同的镜像，是把应用本身对环境有要求的选项做成动态的，通过环境变量注入。动态加载需要自己编写工具通过 Consul 实现。

Q：你们研发的程序是怎么微服务化的呢？怎么用容器提高研发的效率？

A：微服务的话题也很大，我们在拆分服务的时候都会再三思考有没有必要，拆分带来的好处是什么。比如说我们把认证这块单独拆分成一个服务，这是根据功能拆分。还有为了提升性能的拆分，不同资源倾斜的拆分。容器带来的最大好处就是打包环境，能做到快速部署。

以上内容根据 2017 年 3 月 7 日晚微信群分享内容整理。分享人林生生，GrowingIO 服务端研发工程师。从事 GrowingIO 核心系统研发。奉行 DevOps，对一切能提高研发效率的技术痴迷。

---

2017-03-01：基于 Jenkins 和 Kubernetes 的 CI 工作流

Q：关于 Jenkins 和 Docker 集成的几个插件可以分享一下吗？

A：Docker Pipeline、Docker Plugin、docker-build-step 这几个插件。

Q：请问有容云的镜像复制大体思路是什么？目前我们是测试、预发布、发布共享一个仓库。通过辅助模块标签实现的。

A：镜像复制功能，简单来说实现了不同项目间的镜像克隆，根据我们镜像仓库的设计，对不同阶段（开发、测试、可上线）的镜像以不同项目分类，基于镜像复制功能即可快速实现不同阶段的产品发布，也就是镜像发布，此功能可下载 AppHouse 版本进行试用。

Q：贵公司的内部仓库和外部仓库镜像是实时同步的吗？你们的配置文件是通过配置中心管理还是镜像间的环境变量实现的？

A：不是实时同步的，而是通过了我们公司镜像库产品的镜像复制能力实现的。目前开发流程中的产品运行配置是通过自身增强的配置文件能力实现的，配置会用来修改应用部署的 YAML 文件，也会生成为 ConfigMap。

Q：有没有一个简单的 sample，可以上手跟着练习一下？

A：基于 Kubernetes 的 CICD 产品即将发布，会提供对应的 demo 演示平台，请及时关注，谢谢！

Q：Kubernetes 的 YAML 的部署文件的模板怎么去替换占位符？旧版本的容器怎么处理？

A：使用了自身开发的一套文本模板引擎，其实类似 Web 框架中的模板引擎，完成模板和配置的合并，通过使用配置中的 key-value，替换掉模板中 key 的占位符。另外由于是使用的 Kubernetes deployment 的 rolling update，升级完成后旧版本的容器/pod 会由 Kubernetes 自行删除。

Q：传统单体应用如何容器化改造，可否分阶段实施？

A：可以的，容器化改造或微服务化改造有很多实施方法，例如逐渐重构拆解，或新增模块进行微服务化和容器化，或开发新的模块替代原有应用的功能点，等等。各团队均可以选择合适自身的流程来进行改造。

Q：数据库可以容器化吗？

A：可通过将数据卷挂入容器的方式将数据库容器化，但是现在实际项目中还很少见。

Q：有这样一个场景，两个服务有依赖关系，服务 A 依赖于服务 B，如何保证服务 A 和 B 的启动顺序的？

A：良好的设计是使得 A 服务启动后自行完成对 B 服务的检测发现和调用，而不是强依赖其启动顺序.

Q：Kubernetes 的服务的模板和配置，这个模板怎么来的，是用户自己编排？还是自己事先准备好的？配置数据是怎么存储的？

A：因为当前模板和配置只用来启动我们自身开发的应用，因此这个模板是我们自己为我们的应用准备的。配置数据以文件的形式存储，但同时在使用文本引擎做模板和配置合并时，也可以接受参数作为配置。

Q：什么是 CI 和 CD，这个搞不懂？

A：CI 更多是偏向应用编译，代码检查，单元测试等动作，CD 是偏向于应用部署，运行流程。我们的开发过程在编译打包完成后，实际也会将应用跑起来用于测试，也可以算是针对测试的 CD。

Q：使用容器打包 Jenkins 流程的主要收益是什么？

A：由于不同程序对于编译环境的依赖各有不同，原有使用 Jenkins 方法是在 Jenkins node 上完成环境准备，现在可以利用容器完成环境准备，对于 Jenkins node 的依赖可以进一步降低。同时环境变更也可以由开发人员自行控制。

Q：多编译环境是用的不同镜像么？如何处理 Pipeline 处理编译环境的问题？

A：是的。由于我们本身产品开发各个模块有各个模块的开发语言和框架，因此各模块都要维护自身的编译环境镜像。使用 Pipeline 在进行编译时，是通过使用镜像运行容器然后在容器内编译的方式来使用编译环境的。

Q：请问 Jenkins 也是部署在 Docker 里面的吗？如果 Jenkins 在 Docker 里面怎么样在 Docker 里面使用 Docker 执行 CI？

A：是的，我们也在摸索将 Jenkins 本身放到容器中运行。在这种情况下，Jenkins 容器内使用 root 权限，挂载 docker.sock 和 Docker 数据目录到容器中就可以了。

Q：使用 Pipeline 先构建编译环境镜像，再编译，是否会导致整个流程需要很长时间？是否有优化方案？

A：编译镜像由于不会经常变动，因此这个镜像的构建通常使用 cache 就能直接完成，另外我们也把编译环境镜像打包这个步骤抽出来单独作为 job 执行了，这样在实际编译流程中就无需再进行编译环境构建。

Q：Jenkins 和 Kubernetes 的用户是怎么管理的？我的期望是用户只能看到自己得资源，别的用户是没有权限的。

A：我们本身只是使用这两种工具，在开发环境中不对外，所有不存在用户管理的问题。在我们公司正在开发的 CICD 产品中，对这块有我们自身理解基础上的设计。

Q：Jenkins 的持续集成是怎么实现的？比如不同的源码仓库的提交触发，如 GitHub、GitLab 版本号怎么控制的？

A：Jenkins 的 CI 流程触发可以有很多种，代码提交触发，定时触发，手动触发。版本号的控制也可以有很多方案，比如使用 job 的编号，使用 Git 的 commit 号，使用时间戳等等。

Q：容器化后发布也要通过 Jenkins，感觉 Docker 的发布没有 Jenkins 方便，除了容器化的可移植，还有什么原因值得推进项目容器化？

A：应用容器化，其实更多的是看重应用在容器管理平台上运行起来后所获得的能力，例如在 Kubernetes 上运行后的水平扩展，服务发现，滚动升级，等等。

Q：Kubernetes update 需要制定新的镜像才能做滚服更新（升级），如果只是更新了 ConfigMap，有办法做滚服更新吗？

A：我们的 CI 流程完成后，各模块的镜像 tag 会发生变化，我们利用具体生成的 tag 生成配置，然后部署的 YAML 文件写为模板，镜像的具体 tag 会根据每次 CI 流程生成的配置不同而组合为不同的 YAML 文件，然后使用组合后的 yaml，即 tag 已经变更为最新版本的 YAML 文件进行应用的滚动升级。

Q：Pipeline 采用在镜像里构建的方案，是怎么实现的？用 Jenkins 现成的插件 or 用 Groovy 脚本实现？

A：使用了 Jenkins 的 Docker 插件，同时使用方式是将相应命令写在 Groovy 脚本里，例如：stage('Build'){docker.image('golang:1.7').inside { sh './script/build.sh' } }{.prettyprint}。

以上内容根据 2017 年 2 月 28 日晚微信群分享内容整理。分享人**黄文俊，有容云资深系统架构师。主要负责容器云平台产品架构及设计，8 年工作经验，有着企业级存储，云计算解决方案相关理解。关注于微服务设计思考，开发流程优化，Docker 及 Kubernetes 技术在实际环境中的应用。

---

2017-02-22：SRE 工程实践——基于时间序列存储数据的报警

Q：告警信息收到后，系统有没有能力自动解决告警报告的问题？还是需要人工解决问题？谢谢

A：这个要分情况，好的机制是报警应该发出的是新的问题，然后通过反馈机制，让同类的问题不再发生，或者由监控系统自身解决。

Q：InfluxDB 系列方案是否有考虑，Grafana 最新版也有了很好的告警机制，是否有尝试？

A：曾经考虑并实践过 InfluxDB 的 TICK 组合方案，非常方便可以实现数据收集存储处理展示的完整流程。通过对比，我们发现 Prometheus 更符合 Google SRE 对于监控的理念，自身社区也非常活跃，就转向 Prometheus 的方案了。Grafana 实现了强大的可视化配置报警规则的功能，对于原本只做为展示的工具，是很好的增强，这个对我们的启发也很大，也在学习中。

Q：报警规则配置是什么语法，是否可以可视化？

A：Prometheus 是在配置文件中描述报警规则。可以自己动手实现可视化。

Q：数据量庞大的情况怎么解决，比如说万台机器，500 个指标数据等一分钟一个点 60243050010000 的数据量，如何保存，如何快速查询数据。需要什么样的架构和硬件？

A：简单回答，Prometheus 可以通过分组支持大规模的集群，但是达到某个确定的规模，那就需要实践给出答案了。

Q：请问在监控报警方面有没有考虑或实践过智能预警，比如基于历史监控数据，通过机器学习，实现提前预警等？

A：这个不是 SRE 推荐的方式，报警应该简单，高级的功能会模糊真实的意图。

Q：请问基于此方案部署的主机和容器规模有多大，基于什么频率进行监控收集？

A：本次分享的是测试环境，规模不大。Prometheus 定时从 cAdvisor 收集数据，抓取频率 5s。

Q：cAdvisor 采集数据的性能表现怎么样，占用主机的资源大嘛？

A：性能表现优异，担心占用资源，可以在启动容器时进行资源限制。

Q：APP 自身业务逻辑需要监控的数据，比如 Counter，Gauge 等，传统用 Zabbix 等可以进行数据采集。我明白 cAdvisor 是对 Container 进行数据采集。但是有没有可能把 APP 自身的监控和 Container 的监控结合？

A：后续话题，我们会实践有关应用的监控报警。Prometheus 的逻辑是定时从 exporter 抓取数据，然后对存储的时序数据，通过 PromQL 进行查询和分析，所以是可以实现 APP 自身的监控和容器监控的结合的。

以上内容根据 2017 年 2 月 21 日晚微信群分享内容整理。分享人**窦中强，数人云研发工程师。多年运维开发经验，熟悉配置管理，持续集成等相关技术和实践，目前负责数人云平台监控报警组件的研发工作。

---

2017-02-15：乐视云基于 Kubernetes 的 PaaS 平台建设

Q：你们的 IP 管理应该做了很大的开发工作吧？能详细介绍一下？

A：确实做了很多开发工作，其中很大的一个开发量是关于空闲 IP 获取这块。

Q：还有你们的灰度发布是用的 Kubernetes 本身滚动更新功能？还是自己实现的？

A：灰度发布没用 Kubernetes 的滚动更新更能，而是用了不同的 RC 的相互切换。

Q：多个 Region 的镜像管理，如何实现镜像同步与更新？

A： 我们不需要实现镜像的同步。分享中已经提到过，各个 Region 有自己的镜像仓库。

Q：你好请问你们大二层网络是用开源方案实现的还是自己根据 OVS 开发实现的？

A：是我们自己实现的，我们 CNI 中调用了 OVS，主要是使用了 OVS 的网桥功能。

Q：应用跨机房部署，我理解也就是可以跨 Kubernetes 集群部署，Kubernetes 里的调度是如何做的？

A：应用的概念，是在 Kubernetes 集群之上的，应用可以部署在多个 Kubernetes 集群中。

Q：请问贵公司内部服务之间的互相调用是怎么控制的？容器到容器还是容器-Nginx-容器（等同外部）？

A：1. 容器-> 容器 2. 外部服务->Nginx-> 容器 3. 容器->Nginx-> 容器 4. 容器-> 外部服务。 这种情况都有，主要看业务场景。

Q：构建服务集群用到什么 CI 工具，还是自己开发的？etcd 在其中有什么作用？

A：自己开发的，etcd 相当于消息队列，控制层收到构建请求后，etcd 中存放了现阶段集群下都有哪些构建机，当来到构建请求后，控制层会寻找一个构建机器，并向构建机器所在的 etcd key 中发送命令， 对应的构建机器在监控自己的 key 发生变化后，会执行相应的构建任务。

---

2017-01-18：度量驱动的 DevOps 转型

Q：基于 Jenkins 的 CI/CD 不同用户是怎么管理的 ？权限怎么控制的？

A：在 DevOps 实施里面提倡充分授权团队，所以在基础设施自服务的基础上让团队有自己独占的 Jenkins Master 能够有效的减少权限控制此类问题，同时可以避免不同团队之间构建任务的相互影响；如果是共用 JenkinsMaster，Jenkins 有权限控制的插件可以控制用户的权限。

Q：刚才你介绍的 CI 整个交付流程，每个细节都需要花大量的时间和精力去开发和实施，如果公司团队很多，如果分配自己团队的时间，时间少了自然达不到效果。

A：在实施 DevOps 转型过程里面，可以先尝试试点团队，通过试点团队去完成 DevOps 工具链相关的技术选型，在工具链成熟的情况下向其它团队推广。

Q：请问你们有 DevOps 的自动化运维平台吗？可能是一个 Web 页面，把 DevOps 相关的流程和工具集成在上面，方便管理的同时也方便运维开发一体化操作。这个平台可能还包括全链路检测系统？

A：目前我们公司做的基于容器持续交付平台主要就是解决此类问题，通过流水线来组织工具链，同时对相关的环节进行度量，为避免广告嫌疑就不便多说。

Q：你们在这个过程中怎么做沟通管理，以防止因为这造成的对需求理解的偏差等问题？

A：这块更多是团队的组织结构的问题，有兴趣可以尝试通过看板方法，团队的各个角色都会基于看板完成迭代的开发，通过看板可以帮助团队成员之间的沟通和需求确认。

Q：因为很简单，持续集成持续交付，快速迭代，小步快跑，稳扎稳打，这些都有所有的理论最后都回归到代码，所有的变更都回归到本源代码的变更，如何保障所有的变更无遗漏，如何保证每一次任务都在正确的代码基准线上进行，如何出了问题快速反馈到研发第一线，及时终止问题的蔓延？

A：这块其实主要的方式就是基于持续部署流水线的方式，上面分享的时候有提到。通过将流水线通过自动化流水线的方式进行控制，在任何阶段出现问题都应该让流水线失败（门禁），另外出问题不怕，快速解决问题是关键，对于流水线最好可以设置 Webhook 实时触发，可以确保当问题出现后，问题代码的域可以关联到最近的一次提交。

Q：请问你们容器发布是如何自动区分开发、测试、正式等不同环境的，是否需要人工介入修改应用访问关系和启动环境变量？

A：目前我们自己持续交付平台对接不同的容器运行环境（目前主要是 Rancher），团队会对环境进行分类管理，流水线中进行容器部署的时候选择相应的环境即可；另外由于主要是基于容器在做，所以也对容器镜像的不同状态也进行了划分，并且在多个 Registry 实例之间进行了流转，物理隔离了开发，测试以及发布状态的容器镜像。人工介入的部分主要是控制镜像状态的变化这块。

Q：Jenkins 的 Pipeline 和普通的 Project 都可以支持流水线 ，2 者有区别吗？

A：主要解决的问题就是当构建出问题的时候如何快速定位问题，假如在流水线线中涉及 8 个阶段，如果只是在一个 Project 中实现，需要开发者花很多时间定位；如果是 Build Pipeline 的话，则可以很直观的知道问题是发生在什么阶段。

---

2017-01-17：艺龙部署体系的演进

Q：麻烦问一下，桥接的网络是给容器的分配一个物理网络的 IP 吗？另外依据什么来确定每台主机运行多少容器？

A：是的，我们给每个容器分配了一个物理网络的 IP，我们根据目前我们物理机的规格去制定的容器数量，目前每台物理机分配上限是 64 个。

Q：Docker 存储考虑过 Overlay 当时吗？据说这种构建镜像比较快。

A：考虑过，当时也做过各个方面的测试，这种增量式的构建，肯定最快，但是我们需要有专人从源码级别对其进行维护，成本对于我们还是有点高，我们后期打算采用环境和代码分离的方式，即环境部署一次，代码多次部署来提升效率。

Q：.net 不是也可以跑到 Linux 上了吗？有.net 镜像吧？

A：我们调研过，但是这个技术太新了，稳定是我们使用一个新技术的前提，而且我们的.net 服务大多已经是很多年前的老服务，折腾起来比较费力，暂时.net 方面我们只能搁置，但是也会继续跟进。

Q：请问没有采用 ZooKeeper 和 etcd 而选择自研的原因是什么？是否如何进行技术对比的？

A：就是我刚才说的，对于 ZooKeeper 来说，ZooKeeper 基于 Java 编写，在 GC 层面存在一定的问题，数据量过大时候会导致服务可用性降低，我们希望用他做配置管理，我们甚至有一些上 M 的配置文件，最终的配置无论是配置项，还是最终大小，都会是一个比较大的量级。二是我们阅读了它的源码，它的 Recovery 在检测不一致时处理也比较暴力，同时 ZAB 协议较复杂，这个从它的论文上就可以看出来，因此运维起来成本较高。

---

2017-01-15：Kubernetes 有状态集群服务部署与管理

Q： 前面提到 Init Container，Kubernetes 里 Pod 初始化是基于 GCR 的 pause，这个初始化镜像是自定义的吗？

A：Init Container 和 GCR 的 Pause 是不同的概念，一个是初始化容器（运行完就结束），一个是基础容器（一直运行）。

Q：你介绍的 Kubernetes 存储技术都是比较新的，能否适应企业生产大规模使用，有没有什么性能和稳定性问题？

A： 性能和稳定性上我们也在不断尝试，先使用起来看看效果，目前创建过几百个集群，暂时没有碰到太多稳定性问题。

Q：存储系统如何动态创建 StorageClass，如果 Headless Service 没有 Cluster IP，服务如何调用？

A：Kubernetes 通过 StorageClass 让存储系统动态创建 PV，不是动态创建 StorageClass。Headless Service 用于集群内部通信，外部调用，再建普通 Service，二者并存。

Q：有状态集群还有其他的实现方式吗？

A： 在容器云里比较好的方式是用 PetSet，当然也能自己做，相当于自己实现 PetSet 的一些功能。

Q：同步到整个集群才算写入成功，是不是意味着不适合高负载的项目使用？有可能增加其它策略供选择吗？

A：由于采用多主方式，对外只写入一个，内部扩散同步可以并行，而且每个节点都能对外提供服务，相当于增加了服务带宽，所以性能不是问题。

Q：您好，你们是采用什么分布式存储的，io 性能如何？好像一些开源分布式的存储写 io 的性能普遍比较低，能撑得住一些 io 高性能的应用吗？

A： 性能上要等到支持 host 模式后，才能满足一些 IO 要求比较高的场景

以上内容根据 2017 年 01 月 10 日晚微信群分享内容整理。分享人**张寿红，时速云架构师。从事软件研发工作十余年，目前从事基于 Docker 和 Kubernetes 的企业级容器云平台研发工作，主要包括容器服务、存储服务、CI/CD 和镜像服务等。在加入时速云之前，先后在 CATechnologies 和 Symantec 担任 Tech Lead 和 Principal Software Engineer。参与研发的软件产品有：企业数据保护软件、云平台上的服务管理系统、企业客户服务平台等。

---

2017-01-06：基于容器的日志管理实践

Q：Overlay 是没有实现 inotify 接口的，是咋获取文件日志增量数据的？

A：通过循环读取文件的方式，记录文件 offset。

Q：既然主要框架是 ELK，采集端不直接用 Filebeat 是因为 Filebeat 有局限性吗？

A：Filebeat 没有满足我们产品基于 Docker 的需求，等于上面加了 Docker 的逻辑。

Q：自研的日志系统，打出来的每条日志格式都是规定好的吗？开发中每个人都要按这个规范来做吗？不管是什么级别的日志？

A：其实并没有，但是如果是内部使用，能规约好当然更好，可以更方便的处理，而且可以做更细粒度的分析。

Q：日志收集有做分析展示处理吗？用什么处理的。

A：对于日志内容的分析还没做，例如 Nginx 请求日志还是有分析意义的。

Q：采集方面有考虑直接使用系统的 Syslog 和 Logrotate 吗？

A：用过 Syslog 后来因为容器内的文件日志需求重新开发的。

以上内容根据 2017 年 1 月 5 日晚微信群分享内容整理。分享人郭已钦，数人云研发工程师。早期从事 Java&JavaScript 开发，爬虫大数据开发，之后开始写 Go，参与开源容器管理工具 Crane 的研发与维护，目前在数人云做云平台研发工作。

---

2017-01-03：构建容器服务平台（CaaS）

Q：跨区域的容器集群间是否能通信？

A：目前跨区域机器不能通讯。跨区域之间机器是租户完全隔离。如果租户需要通讯，需要针对具体机器进行开墙。

Q：请问使用 DeviceMapper 其中遇到了那些问题？

A：最常遇到的是 device busy。会导致容器无法删除。此时需要人工干预。

Q：镜像管理如果只是基于 distribution 的话，权限与多租户管理是如何实现的？

A：权限纳入平台管理，由我们自行实现。租户之间的镜像不可共享。租户内的可共享和私有。 租户间的镜像必须通过发布，由平台审核方能在各个区域和各个租户间共享。

Q：监控是用什么语言开发的，是自主开发还是用开源的？

A：监控，我这边针对镜像和容器这块做了一些监控数据的收集，然后提供给监控平台。监控平台由部门另外一组开发。目前基于 Zabbix 进行开发。

Q：请问：1. DockerHUB 只有一个实例吗？如何保证高可用？2. DockerServer 间同步的是什么内容呢？Docker 事件？

A：所有区域，包括 pub 和 mirror，都是 keepalive+lvs 搭建。目前使用双 registry+ 共享 nas。而这两个 Registry 所在的 vm 是跨 az。也就是一个 Registry 宕完全不影响另外一个提供。而 nas 是双写 nas，我们这边的存储组提供的 DNAS 服务。备份策略也是可以根据自己定义。

Q：pub hub 获取 docker hub 镜像的方式，目前是自动维护吗？

A：不是，从 docker hub 进入公司官方镜像仓库，都是人工维护同步。我们需要针对一些镜像做特殊处理。

Q：IPsec 的性能传说不是很好，你们有遇到过网络的问题吗？Rancher 的 IPsec 网络性能怎么样？容器有涉及到弹性伸缩吗？容器间采用 Rancher 实现网络通信，为什么没有选择类似组件？

A：这 3 个问题统一回答。目前是使用 IPsec。由于当前每个 Rancher 对接的容器数目不是特别大，还没产生网络问题。另外对外网络走的是云主机网络。 有考虑过其他组件，由于之前起步阶段，所有直接采取 rancher 提供的。最近 Rancher 提供支持 CNI 的方案。目前正在研究对应的组件。

Q：我能想到的一个方案是自己的用户体系加云平台的租户和云平台的用户体系，多对 1 的映射，当审核通过后，使用不同的云平台用户，这样权限就不一样了。是这样吗？

A：目前容器服务只针对公司内部开放，直接兼容云平台租户。

Q：请问内核版本是？用 4.9 的计划吗？平安云是 OpenStack 吗？用 Magnum 吗？

A：使用 CentOS 7.2，内核版本是 3.10.xxx,平安云使用 Cloud Foundry，平安云使用了多种虚拟机，VMware 和 KVM 是主要。

Q：容器是跑在物理机上还是虚拟机上，容器所在的操作系统归租户所有还是运营商所有？容器的分配规则由谁决定？一个宿主机跑多少个容器由谁决定？

A：目前资源限制还是交给 Rancher 来管理，我们对 Rancher 的规划是：让 Rancher 管理资源，分配容器。在页面提供 Docker 目前支持的资源参数。 容器所在的操作系统归租户所有。租户可以任意添加自己的云主机到容器华环境中。

Q：目前这个系统是内部用的吧？安全性有没有考虑？

A：安全：目前针对公司内部，使用公司 AD 认证登录。而计算资源限制采用租户隔离。镜像这块安全采用主机互信。

Q：很多业务日志是不直接输出到 stdout 的，这些业务日志如何搜集？容器日志的采集采用什么方式？容器规模大约有多大呢？当采集方出现采集中断的时候会有报警提示吗？打入到 es 后，做了哪些比较有效的报表数据呢？

---

2016-12-18：海航生态科技舆情大数据平台容器化改造

Q：Spark 直接运行在 Mesos 不是很方便么，容器化优势是否明显？主要考虑点在哪？

A：容器化主要考虑两点:一 解决海量数据计算的资源编排问题 ，未来也会基于 CaaS 云提供服务 , 二 研发体系的敏捷化与标准化问题。我们正在考虑根据计算需要实现弹性伸缩，容器化是一个助力。

Q：请问为什么 Elasticsearch，而没有选择 Solr 呢？

A：在有索引下，ES 性能会要好一些，而且它原生分布式支持，安装配置也简单。

Q：代码没有打包进镜像中是出于什么原因？

A：这样部署运行会更灵活，我可以代码放到本地，也可以上传到实例中。代码提交比较频繁，执行环境变化却不大，只替换变换的部分部署会更快速。主要是为了适应目前这种部署方式。

Q：爬虫容器如何调度，是分布式吗？

A：是分布式的，这个是按时间定时运行的，Rancher 提供的 crontab，爬虫程序提供执行入口。

Q：HBase 主键设计依然没有解决热点问题？

A：确实未完全解决，基于时间序列的暂时未找到更好的 rowkey 设计方法；把他分成 24 小段，加入时间，单独对每段来说，它是按时间排序的，也算是一种折中。

以上内容根据 2016 年 12 月 13 日晚微信群分享内容整理。分享人高颜，就职于海航生态科技技术研究院，任职大数据开发工程师，从事大数据平台应用开发年，负责大数据平台技术选型，架构设计及代码开发工作。

---

2016-11-23：爱油科技基于 SpringCloud 的微服务实践

Q：你们是部署在公有云，还是托管机房？

A：我们部署在阿里云上，使用了很多阿里云服务作为基础设施，这一点是为了节约运维成本。

Q：怎么解决服务过多依赖问题？开发也会有麻烦，因为要开发一个功能，为了把服务跑起来，可能要跑很多服务。

A：在我们的实际开发过程中，也遇到了这个问题。主要的是通过部署几个不同的仿真环境，一组开发者可以共用这组环境。本地开发也很简单，只需要把 Consul 指向到这个集群的 Consul 上即可。

Q：你们微服务业务调用最深有几层？restful 接口调用链的效率如何？比单体结构慢多少？

A：一般不超过 3 层，这是领域驱动设计给我们带来的优势，单个服务几乎自己就能完成职责范围内的任务，没有出现 RPC 灾难，一个业务我们也不倾向于拆分成若干个远程操作进行。

Q：你好，我们单位从 6 月份开始实施微服务化（O2O 业务），使用的是 Dubbo，使用事务型消息来做最终一致性，请问 CQRS+Event Sourcing 相对于事务型消息队列来处理一致性问题 有什么优势么？

A：其实 CQRS+Event Sourcing 是一种观念的转变，落地还是需要靠存储和消息队列，优势在于可以消除系统中的锁点，性能会更好。

Q：关于领域事件，如果本地事务提交后，下游的服务报错，是否只能在业务层面再发起一个补偿的事件，让本地事务达到最终一致性呢？

A：如果下游服务报错，那么事件不会被消费。会以退避重试的方式重发事件。

Q：分享很棒，请问你们的 Docker 的部署是基于原生的 Docker 和 Swarm，还是 Kubernetes 来做的？

A：谢谢，我们使用 Rancher 来管理集群。没选 Kubernetes 的原因是因为团队资源有限，Swarm 最初试过，调度不够完善。后来 Docker 1.12 以后的 Swarmkit 应该是更好的选择。

Q：微服务开发测试用例相比于单体应用是不是更复杂一些？你们是怎样保证测试覆盖率的？

A：事实上对于单元测试来讲，反而更容易进行了。因为系统拆分之后，把原来很难测试的一些节点给疏通了。

Q：你好请教一下，当微服务之间的依赖关系比较多，且层次比较深时，服务的启动，停止，以及升级之间的关系如何处理？

A：目前还几乎没出现过需要彻底冷启动的情况。而且启动服务时并不需要依赖服务也启动，只需要发生业务时，依赖服务启动即可。

以上内容根据 2016 年 11 月 15 日晚微信群分享内容整理。分享人刘思贤（微博 @starlight36），爱油科技架构师、PMP。主要负责业务平台架构设计，DevOps 实施和研发过程持续改进等，关注领域驱动设计与微服务、建设高效团队和工程师文化培养。

---

2016-11-16：树莓派上的 Docker 集群管理

Q：先问一个问题，您家里的树莓集群用来做什么？有哪些场景会用到树莓 Docker？

A：这个需求点来自 MBH 树莓派社区的朋友，他们提出希望能够简化多个树莓派上部署程序，同时我对未来 Docker 在 arm 服务器上的运行抱有很大期望，我只是对这块进行了一些探索。目前还没有找到真实的需求点，还需要更深入的落地。

Q：您对 CoreOS 和 RancherOS 的区别或优劣势上，您是怎么看的？多谢！

A：实际上使用了 CoreOS 和 RancherOS 后，会发现这两个在思路和理念上确实很像。RancherOS 比 CoreOS 的容器化做的更加深入，CoreOS 的稳定性会更好。RancherOS 设计面向 Rancher，CoreOS 更多会考虑 Kubernetes。CoreOS 应该会持续深耕服务器端，而 RancherOS 也许会在 IOT 端发力一下。

Q：树莓派的内存不大，单个主机上容器数会有很大限制吧？

A：树莓派上跑是为了只是为了单纯简化程序部署，当然不会追求计算密度。计算密度那是服务器关注的事，另外，树莓派的内存不大只是暂时的。

Q：请问在 arm 架构里 partition 是怎么做的?

A：dd 写完镜像后，默认又一个根分区，可以再建一个分区，把 docker 的目录挂上去，这样能充分利用整个 sd 卡。

Q：RancherOS 上使用 Docker，应用能在容器中通过 GPU 执行浮点运算吗？需要装驱动吗？在哪装？

A： RancherOS 是一个完全可以定制的操作系统。只要有对应的 module，都可以初始化到 RancherOS 中。

以上内容根据 2016 年 11 月 15 日晚微信群分享内容整理。分享人张智博（niusmallnan），初出茅庐在阿里巴巴口碑网，参与本地搜索业务研发工作，后与朋友联合创办美食点评社区”美食行”，之后在各种公司从事云计算研发工作。Rancher 中国社区布道师，MBH 树莓派社区成员，OpenStack 中国社区长期作者。热爱 coding，热爱技术分享，技术宅&科幻粉，树莓派热血青年。

---

2016-11-09：唯品会基于 Kubernetes 的网络方案演进

Q：想问下这个 IP 外网可以直接访问吗？

A：在 Flannel 网络下不可以直接访问 Pod，在 Contiv 网络下，Pod 所分配的网段是在交换机端打了 tag 的，默认办公网络是可以直接访问的。

Q：贵司花了相当大的精力去做容器互通并显著提高了复杂度，如果直接用 Kubernetes 的 host network 方式是否可以直接绕过这些复杂点？

A：首先是公司业务的需求。公司有 1k+ 的业务域，运行在不同的 Docker 容器里，每个业务域的配置基本是固定的，比如 Tomcat 或 Nginx 使用的端口，如果使用 host network 的话，端口冲突是面临的首要问题，整个服务化的管理方式也要改变了。

Q：文中提到一个应用的运行态对应 Kubernetes 的一个 RC 和 Service，RS 是否好过 RC？

A：我们的 Kubernetes 版本是 1.2，Kubernetes 1.2 里面 RS 这个东西还处于一个非常早期的版本，后面才有的，RS 也是推荐的下一代 RC。

Q：什么样的应用必须要固定 IP，是否有其他办法可以避开？

A：业务域之间相互调用，有些业务域要求提供调用方白名单。还有些业务域会需要线上的数据访问，要加入相应的防火墙权限等。

Q：固定 ip 的情况下：容器的 IP 是通过桥接到宿主机的网桥连接到宿主机网络的吗？

A：固定 IP 的情况下，仍然是基于 Contiv 的网络工作方式，只是在 Docker 运行时由 IPAllocator 负责分配好 IP，Docker 启动时使用--ip 的方式绑定该 IP。当前 OVS 的工作方式也是通过 ovsbridge 连接到宿主机的物理网卡的。

Q：固定 IP，分配的 IP 需要和宿主机同网段吗？

A： Kubernetes node 主机网段和 pod 网段是不同的。原则上可以相同也可以不同。

Q：Kubernetes 支持 Docker 启动加参数吗，例如 –ip？

A：默认不支持，我们对 kubelet 做了一些修改: 例如通过参数传入 vlan id 以及根据 PodSpec 中所分配 IP 指定 docker run 的 --ip。

Q：据我了解 Contiv 现在更多的是对 CNM 的支持， 对 Kubernetes 的话你们定制开发的多吗？

A：Kubernetes 用的 CNI，我们用的是 CNM。更多是适应当前的 Contiv 对相关组件做修改，以及后面的固定 IP（把 IPAM 集成到了 Kubernetes APIServer）。

以上内容根据 2016 年 11 月 8 日晚微信群分享内容整理。分享人王成昌，唯品会 PaaS 平台高级开发工程师，主要工作内容包括：平台 DevOps 方案流程优化，持续部署，平台日志收集，Docker 以及 Kubernetes 研究。

---

2016-11-05：魅族云 Docker 实践

Q：请问下负载均衡 LVS 是怎么和容器结合的？

A：现阶段我们的容器是当虚机来用，有固定 IP，所以 LVS 按照传统方式使用即可，在容器里面配上 VIP，如果是 FullNAT 方式则不需要。

Q：魅族云的编排工具优选哪个，有混合云的计划吗？

A：现阶段我们是原来的平台上做适配。今天的内容我们讲的都是对内的私有云，公有云正在开发测试阶段。

Q：你们的缩容，具体是怎么做的？

A：CPU、内存是修改 CGroup 配置，磁盘则通过 LVM 进行缩容。

Q：请问，日志集中存储与日志查看怎么实现的？

A：我们有基于 ELK 实现的统一日志管理中心，日志都发往日志中心存储，可在管理平台上进行查看。

Q：”默认情况下，容器内部的 proc 显示的是宿主机的信息，我们通过获取 CGroup 中的统计信息来覆盖掉这部分 proc 信息” 这个 Agent 是你们自研的？ 方便说下细节吗？谢谢！

A：简单点说就是通过拦截系统和程序读取 proc 目录下 cpuinfo、meminfo 等资源文件，让它去读取我们通过 CGroup 算好的文件，从而得到正确的容器资源使用情况。

Q：容器式虚拟机和虚拟机式容器之间，在业务上落地方案是怎么样的，倾向于哪个？

A：因为我们有虚拟机的历史包袱，所以落地方案上会选择虚拟机式容器， 如果没有历史包袱，直接可以上容器。

Q：容器有分有状态和无状态么，容器如果是有状态的容器分布式存储是怎么处理的呢？

A：有状态的容器存储有两种方式：一种是将本地目录挂载到容器，一种是在容器里面挂载分布式存储。

Q：请问一下容量系统主要用来监控哪些设备？有没有容量不足会提前预知的功能？

A：监控业务资源是使用情况。业务容量不足或者容量浪费都会有预警。

以上内容根据 2016 年 10 月 25 日晚微信群分享内容整理。分享人林钟洪，2014 年加入魅族研发中心，任运维架构师，负责魅族云平台虚拟化及魅族日志平台研发，主要包括：KVM 虚拟化，Docker 容器化、分布式存储、集中式日志系统。

---

2016-11-04：如何使用 Node.js 和 Docker 构建高质量的微服务

Q：请问 Kubernetes 的网络用的什么？

A：这个要看具体业务场景，简单的 Flannel、iptables 就够了。

Q：请问外部访问服务和内部访问微服务方式是一样的吗？都是通过 API Gateway 的话，是否有性能压力？另外，对外暴露的服务要分配外网地址，纯内部服务只要内网地址，怎么区分？

A：内部用或者微服务之间访问可以通过 内网地址 访问，外部用绑定一个外网地址就可以了，考虑性能的话，可以通过 Nginx 等实现 Kong 的高可用。

Q：感谢分享！我想问一下容器网络对微服务的影响，需要自定义网络吗？还是用 Kubernetes 就可以了？有更好的方案吗？

A：在我们实践过程中，是没有自定义网络的，微服务之间通过 rest api 进行交互，对客户端通过 Kong 提供统一入口，然后用 Kubernetes 的负载均衡就差不多了。

Q：Node.js 和 Vue.js 如何选择？

A：童鞋，这两个是完全不同的东西，Node.js 是后端，Vue.js 是一个前端库，如果你非要选择，我选择 react。

---

2016-11-01：打造百亿级数据处理量的弹性调度容器平台

Q：请问管理系统是基于什么开发的？这个系统会开源吗？

A：Dora 的调度框架是基本 GO 语言开发的。目前不会开源，但提供私有部署。

Q：刚开始看 Mesos 框架实现，请问自定义的 Scheduler 中如何调用自定义的 executor？

A：Schesuler 跟 executor 这个都是按照 Mesos 最新的 v1 版的 HTTP API 去做的，这个没有不兼容的问题，只是 mesos go 版本的 SDK 有些老旧，更新也比较缓慢，这个地方我们自己根据需要做了些更改。

Q：请问目前 Consul 集群是多大规模呢？有没有考虑 Consul 扩展的性能瓶颈呢？

A：Consul 是在每个 slave 节点上会有一个 Consul 的 Agent ，我们一个机房有 200 多台专门用于数据处理的机器，所以 Consul 的集群规模也就这么大，单机房。对我们当前来说不存在瓶颈，因为我们对 Consul 的使用的场景相对单一简单：作为 Metadata 的可靠存储，Metadata 的更新其实并不是很频繁，这个我们参考过别人做过的一些性能测试和我们自己的一些测试，性能是满足需求的。另外一个功能就是服务发现与实例的健康检查，健康检查是由运行在每个机器上的 Consul Agent 负责的，均摊到每个机器上，其实单个机器上的实例数不会特别的多，所以这部分也没有太大的压力。当然了，这个也是跟业务规模相关的，假定哪天 Consul 的扩展性成我们的问题了，也说明我们的业务量特别特别的大了，我们也是很期望这一天到来的。

Q：Dora 是否可以支持 MySQL 的自动伸缩扩容？

A：Dora 系统的应用场景还是运行一些数据处理命令这类无状态的服务。MySQL 这类系统不适合直接跑在 Dora 这个里面，如果期望 MySQL 跑在 Mesos 上面的话，需要自己实现一个专门针对 MySQL 的调度器，因为 MySQL 实例的扩缩容，实例故障的修复都有 MySQL 自身特定的需求。我们公司 MySQL 这类有状态服务的容器化是由公司另一个容器平台实现的。MySQL 的用的是 Percona XtraDB Cluster 方案，我们利用另一个容器平台的 API 写了一个 Percona XtraDB Cluster 的调度器，把 Percona XtraDB Cluster 的大部分运维操作在容器平台上自动化了。

Q：你们的 Ansible host 文件是动态生成的嘛？代码推送也是通过 Ansible 嘛？新增删除节点，以及回滚等操作是如何实现的？

A：最开始实践的时候不是动态生成的，其实我们是可以从 Consul 中获取到当前集群里面的节点和节点的一些简单的配置信息，后面有考虑从 Consul 里面拿节点信息，动态生成用于 Ansible 灰度的 host 文件。代码推送也是使用的 Ansible，如果能和外网连接的机器，也可以使用 GitHub。因为我们的 Playbook 的角色是通过组件区分的，新增删除节点只需要修改 Host 文件，把相应的节点加入安装或删除相应的组件。如回滚操作： ``` {.prettyprint} $ ansible-playbook rollback.yml -i hosts -e “hosts_env=XXX app_env=XXX version_env=XXX” hosts_env：表示要回滚的主机组，如 Masterapp_env：表示要回滚的组件，如 ZooKeeperxxx_version：表示要回滚组件的版本号，如 v1.0.1.20160918

Q：Dora 的调度策略是怎么样的？可否简单介绍一下。

A：首先保证同一种数据处理命令的实例尽量均匀分散在不同的机器上，然后再是保证均衡每个机器上的负载。

Q：Prometheus 目前是单机的，数据量大了怎么办？Prometheus 的监控数据是存在 InfluxDB 吗？

A：目前我们是按业务拆分 server，数据量可以支撑。我们没有使用 InfluxDB，还是用的原生的 LevelDB。

Q：这么大文件量，你们在存储技术方面有什么特别的处理吗？怎么实现高性能和海量存储之间均衡？

A：七牛云存储的设计目标是针对海量小文件的存储，所以它对文件系统的第一个改变也是去关系，也就是去目录结构（有目录意味着有父子关系）。所以七牛云存储不是文件系统，而是键值存储，或对象存储。我们每个大文件都是切割成小文件存储下来的，元信息单独存放在数据库中，用户请求的时候通过业务层合并处理后返回。因此理论上磁盘只存储小文件，大文件存储和读取的性能主要在于文件切割和合并。

以上内容根据 2016 年 11 月 1 日晚微信群分享内容整理。分享人陈爱珍，七牛云布道师，负责 DevOps ，容器，微服务相关技术的落地研究与布道。多年企业级系统运维管理经验，对大型分布式系统架构设计及运维有丰富的经验。

---

2016-10-25：猎豹移动基于 CoreOS 在 AWS 上的项目实践

Q：没有用到 Flannel，网络实现是什么，未来对 CoreOS 的容器管理工具 rkt 的计划？

A：网络上我们直接使用的 host 的方式，容器主要是看中了 CI 和 CD 的便利好没有往高密度的场景设计的计划，rkt 是个好东西，更有开源的感觉，看后期 Docker 社区发展情况是否越来越封闭。

Q：registry 怎么 ha 的，是在容器还是 VM？

A：这个问题之前也是一直困扰着我们，我们用 AWS 的 ELB 做负载均衡，后端放 2 台 EC2，镜像存到 S3，缓存写在 Redis 里，我们是使用官方的 image，随时用随时上传和使用，挂了就再启动一个，不依赖长期有效的 hub。

Q：最近暴漏的安全问题需要内核升级才能解决，这正是 CoreOS 的优势、不必重启系统，猎豹是否在线上有这种经验？实际中 CoreOS 在升级内核时是否真那么方便？

A：这个是我们非常喜欢的一个特性，自动升级内核，做过运维的同学都知道，做一次内核升级是多么痛苦，我们最开始用的是 stable766.4，现在都不用我们去升级就自动帮我们升级到 8xx 的 stable 版本了。

Q：集群中 etcd 节点数目是多少，奇数个 etcd 节点的优势具体怎么体现的，以及 etcd 的代理节点在业务中的价值？

A：etcd 很类似于 ZooKeeper，leader 节点必须是奇数个，我们一般是 3 个，最多 5 个，所有节点都会主动和 leader 节点通讯，leader 节点可以运行在集群任何节点上，也可以通过 API 接口手动调整 leader 节点所在的底层服务器，很灵活，任何一台都可以选举成 leader，不用部署任何额外配置，省心。

Q：编排调度都是自己开发的系统吗，如何管理那么多的容器？

A：用的 CoreOS 自带的模块，etcd+fleet+systemd，很底层，登陆任何一台机器做操作就可以管理整个集群，就像管理一台机器一样，我们把日常发布等操作基本都用 Jenkins 代劳了。

以上内容根据 2016 年 10 月 25 日晚微信群分享内容整理。分享人齐海澎（KumaQi），猎豹移动高级运维工程师。负责猎豹移动商业广告产品与大数据相关产品的运维团队管理，作为猎豹移动运维部的管理团队成员，负责商业广告业务和大数据计算在 AWS 服务上的稳定运行，并帮助公司开展容器技术的初步尝试。3 年 AWS 服务使用与运维经验，运维全球 8 个 region 数以千计的计算服务资源，搭建并运维起跨 5 个地区的基于 CoreOS 的 Docker 集群。

---

2016-10-25：恒生金融交易系统的 Docker 化实践

Q：请问下，你们现在这个系统容器规模多大？OverlayFS 有遇到什么坑吗？

A：现在系统容器是 100 多个。由于镜像数少，对文件 inode 占用少，所以 OverlayFS 基本满足需求。但是需要主机内核高一点，在 3.18 以上。

Q：请教一下。咱们这个容器管理平台是用什么语言开发的？直接调用 Docker Remote API 吗，用的是最新的 1.24 么？

A：Java 语言开发，直接调用的 Docker Remote API，版本是 1.24.

Q：MySQL 服务也 Docker 化了吗，怎么保证存储安全？

A：MySQL 这块是我们实现了 RDS，底层用 MySQL 的复制方案。

Q：交易系统应该涉及很多运行组件。在决定哪些组件容器化时有哪些考虑？

A：一般性能要求很高，延迟要求在微秒级的组件，比如高频交易等，基本不考虑 Docker 化。

Q：核心架构是 Swarm+Docker+Confd+Registrator，如何实现动态扩展？

A：组件还包括了 Etcd，利用 Etcd+Confd+Registrator 来做服务注册和发现及配置管理，利用 Docker Compose 的 Scale 做服务的扩展。

Q：请问你们用的编排系统都是 Docker 1.12 的 Swarm 吗，如何实现容器都是夸主机冗余部署？

A：1.12 也在试用，现在主要是老模式的 Swarm，利用容器的互斥性，相同集群的 2 个容器实例，不要部署到同一台主机上。

Q：请教下业务组件的镜像有多大？如何实现跨平台迁移，不如从华为云部署到阿里云之类？

A：镜像大小在几百 M，利用镜像中心的远程复制功能，同步到生产环境的镜像中心，比如阿里云和华为云上。

Q：镜像安全如何保证？

A：目前基础镜像都是由我们自己制作，会检查安装的软件和版本。后续会引进镜像安全扫描，来定期检查镜像。

Q：请问网络采用 host 模式，如果一台主机运行多个同一端口的容器怎么办？比如运行 2 个 Tomcat 项目？

A：我们在容器管理工具中增加了端口的配置管理，不会出现这种情况。另外部分网络性能要求不高的应用，也会采用 flannel host-gw 的方案，这样端口就可以相同了。后续会调研 MacVLAN 模式，给每个容器分配一个物理 IP 地址。

以上内容根据 2016 年 10 月 18 日晚微信群分享内容整理。分享人柳正龙，恒生电子研发中心 Docker 技术负责人。8 年来一直专注于金融行业高性能中间件、分布式消息分发系统架构和研发。对于网络通信、服务器性能调优、GDB 调试等有丰富的经验。2015 年开始研究 Docker 技术，现负责推进 Docker 技术在公司内的落地。

---

2016-10-24：PPTV 聚力传媒的 Docker 与 DevOps

Q：线上和线下环境不一致的问题，通过配置中心，比如文件或者安全变量，容器 App 启动读取文件或者变量，就能过去正确的配置，这样方式 pptv 实践为什么不采用这个方法呢？

A：我们线上环境是有配置中心的，但是因为管理上的原因，配置中心主要是管理系统级别的配置，和业务相关的配置不放在配置中心里。而且我们想要做到的效果是使用相同的配置在线下线上环境跑，通过配置中心来做的话，只是把配置项做成了变量，配置实际上还是有差异的。

Q：DB 变更流程怎么控制的，PPTV 的业务中是否涉及到分库分表，又采用了哪些手段来针对测试库与生产库的数据变更带来对业务的影响？

A：DB 变更主要通过流程去规范，比如分库分表、表结构变更，需要提前 1 天以上申请，由 DBA 评估审核，涉及数据库的更新必须避开业务高峰期，选择凌晨或者早上 8 点前。技术上，要求业务方在数据库变更应该有备份脚本，备份需要更新的数据。

Q：如何解决发布的时候 Nginx 频繁 reload 问题？对容器的 Swap 有限制么？

A：Marathon 上有变更的时候不会立即触发 reload，首先会将变更的信息记录到 DB 中，然后有间隔的批量同步触发 reload，Swap 目前没有做配置

Q：1、Redis、MySQL、DB、ZooKeeper 这些如果跑在容器，数据初始化持久化的方案是什么，2、linux bridge 网络方案 有没有对比过 Calico Contiv 等？

A：1. 挂载外部卷 GlusterFS 实现持久化存储 。 2.对比过 Calico，可以参考之前的一篇文章《PPTV Docker 集群的网络方案选型》，Contiv 没有做过对比。

Q：持续组件 ZooKeeper、MySQL 之类的是怎么和应用集成的，是一个整体镜像还是单个镜像组合的？

A：ZooKeeper、MySQL 是不同镜像，运行在不同容器中。

Q：请问服务自动发现怎么搞的?新手，不知如何将 Node 注册进 HAProxy 或 Nginx？

A：对 Marathon 的 label 属性进行约定，默认 label 属性是没有意义的，可以在程序中判断 label 是否符合约定条件，并触发注册、修改操作。

Q：您好，请问你们的 DNS 是怎么做的，单点故障问题是如何解决的？

A：DNS 也运行在由 Marathon 调度的容器中，Marathon 实现故障自愈，DNS 重启的同时将触发服务发现的同步操作。

Q：灰度发布回退是回退 images 还是直接回退 Docker 中的应用包呢，回退前如果改过 Volume 中数据库话，数据库也一起回退？遇到什么问题么？

A：目前线上环境的容器化还在进行中，将来会是回退 images。线上的数据库不会跑在容器中，回退的时候数据库也回退，和没有用容器的时候流程一样。

Q：在生产环境，一个 App ID 会存在需要多个容器的情况，也就需要多个 IP。按上述使用方式应该会有问题。这块是如何解决呢？

A：在生产环境中在 Marathon 上层封装了一套发布系统，同一个项目创建多个容器，会在 Marathon 上创建多个 App ID，Marathon 上的信息对外不可见。

Q：我想问，使用 bridge，10.199.45.0/24，会不会 IP 耗尽？还有有没有测试过 bridge 的效率？

A：10.199.45.0/24 只是举个例子，实际场景下会有多个 IP 段，或者使用一个大的网段。只做了简单的测试，bridge 效率基本能达到原生网络的 90% 以上。

Q：选择 CentOS 而不是 Ubuntu 或者 CoreOS 的原因是什么？DNS 和 IP 地址池如何协调？

A：技术栈原因，公司一直在用 RedHat 和 CentOS。DNS 和 IP 由 DCOS 管理平台进行管理。

Q：Mesos 和 Marathon 结合时，关闭容器后会产生 stop 状态的容器而不自动清理，只能脚本清理，这个请问你们有什么方案处理么？

A：目前我们也是脚本。将来可能会和 Mesos 的 hook 做到一起，Mesos 发现 task 结束时删除容器，或者通知管理平台，由管理平台定期批量处理。

以上内容根据 2016 年 10 月 11 日晚微信群分享内容整理。分享人李周，PPTV 聚力传媒 DCOS 技术主要负责人，专注于 Docker 网络解决方案，容器监控，DevOps。之前在中小创业公司长期负责客户现场实施工作，积累了大量关于网络，监控，权限认证，大数据，Oracle，中间件等经验，同时喜欢研究各种新兴技术。

---

2016-10-20：基于 Docker 的开发云提高资源利用率的实践

Q：你好，你们有做不影响服务的升级和自动伸缩吗？

A：是的，上边提到的”动态应用部署”组件就是能够实现应用的升级更新不受影响，自动伸缩通过 Rancher 的监控和应用多实例来实现，监控到应用容易的 CPU、内存、网络等如果在一个时间段内一直处于较高的利用率，就增加应用实例，反之则减少，保证应用的连续性。

Q：请问对 Docker 学习需要看 Docker 源码吗？

还是用 Docker 等工具来解决问题就可以了？

A：这个得根据实际需要来了，如果是说需要从 Docker 容器层面上来定制开发，那 Docker 源码肯定是需要去研究的，若仅仅是将 Docker 作为工具使用，那关注点可以放在相关的工具如 Rancher、Mesos、Kubernetes 等，当然了，若时间允许，了解源码好处多多，可以从底层弄清楚 Docker 的各种机制，有利无弊。

Q：感谢分享，请问在容器资源池部分提到的”运行状态的 IDE 容器，与开发者的访问域名绑定” 假设有两个用户,用户 A 和用户 B，他们访问的域名分别是什么？

A：这个是用户自定义的二级域名，假如基于顶级域名 cloudx5.com，用户 A 创建一个 IDE 实例，这是他可以输入一个二级域名如 a.cloudx5.com（或者我们自动生成一个），资源池组件就会将这个域名与获取的 IDE 容器绑定，用户 A 就可以访问了。

Q：想问下 Docker 部署应用，应用配置参数怎么处理？改一个参数就要重新打一包吗？

A：其实在我们这个结构中，用户并不需要关心打包及参数配置，他需要做的，就是把开发的代码上传，我们后端使用了 Jenkins 来做统一的打包，打包完成后会调用”动态应用部署”环节提到的 Deployer 容器，这个 Deployer 会去约定好的目录下载打包好的文件做部署配置。

Q：实例收缩的时候能保证释放的容器没有业务访问？

A：这个不需要保证，运行着的实例容器都是无状态的，实例之间的 Session 是共享的，需要持久化的数据也是存在别的容器中的如 MySQL。

Q：LB 路由 WebApp 的时候是按照 IP 寻址的吗？这样如何保证 WebApp 重启时候 IP 不变化?

A：LB 路由的本质是一个带有服务发现功能的 Haproxy，WebApp 重启后 IP 变化了，LB 会得知这个变化并修改配置和 reload。

Q：就是说配置文件还是打到 Docker 里的，比如这时开发要改个配置或加一配置，而代码都没变，这时只能在打一个新的包？

A：关于这个我们做了一些约定，例如上边讲到的一个最基本的 Wex5 应用，我们将其分为 Wex5 APP 容器、MySQL 容器与 Deployer 容器，APP 应用容器访问 MySQL 容器都是通过 Rancher 的内部 DNS 解析 MySQL 容器在 Rancher 中的服务名称来访问，这个是相对固定的，例如在外卖 APP 应用中配置的 MySQL 的地址是：database.waimai，database 是服务名称，waimai 是 Rancher 的 stack 名称。

---

2016-10-04：深入解析 DC/OS

Q：请问 DC/OS 目前测试的最大集群是多少节点的？

A： Mesos 的节点数 Tweeter 和 Apple 网上说的数目都万节点以上，我们公司现在的客户有千节点级别的。

Q：DC/OS 目前用在什么场景？

A：DC/OS 目前的应用场景主要还是微服务和大数据混合部署比较多，也是其设计核心所在。

Q：请问有部署 Stateful 的应用，比如 MySQL 吗？

A：是用 DC/OS 还是建议从无状态的服务开始，随着运维能力的提高，可以部署有状态的服务，但是有状态的服务不建议直接使用 Marathon 进行部署，一方面它无法区分多个 instance 之间的区别，另一方面需要配合统一存储来实现。对于有状态的服务，可以自己实现 Framework，例如我们使用的数据库是 MongoDB，也是写了自己的 Framework 的。

以上内容根据 2016 年 10 月 4 日晚微信群分享内容整理。分享人**刘超，Linker Networks 首席架构师，10 年云计算领域研发及架构经验，OpenDC/OS 贡献者。长期专注于 OpenStack、Hadoop、Docker、Spark、Mesos 等开源软件的企业级应用及产品化。个人博客：**。

---

2016-09-27：Docker 在 B 站的实施之路

Q：你好 问下贵公司的自动扩容是针对应用的吧

有没有针对 Mesos 资源池监控并做 Mesos Agent 的扩容？

A：目前的自动扩容是针对应用的。Mesos Agent 扩容时，先把物理机信息录入 PaaS 平台，手动在 PaaS 平台点击扩容，后台会调用 Ansible，分钟快速级扩 Mesos Agent。

Q：现在是确定 Nginx+UpSync+Upsteam check 是无法一起用的么？贵公司的 Nginx 版本是多少哇？

A：测试过 Nginx 1.8 和 1.10，确认无法一同编译。我们用的最多的 Nginx（SLB）是 Tengine 2.1.1，部署在 Docker 上。

Q：既然是封装， 那底层用 Mesos 比 Kubernets 并没有太大的灵活性吧？

A：对于 PaaS 平台，目前我们希望的只需要资源调度这个功能，其他功能我们还是希望可以自己实现，而 Mesos 是专注于调度资源，而且已经历经了大量级的考验。而 Kubernetes 目前提供的很多服务，我们并不需要，所以选择了 Mesos。

Q：容器是采用 Monitor Agent 监控，那容器内的呢？也还是内部埋点？还是 EFK 吗？监控是采用 Prometheus 吗？

A：Prometheus 没有使用，我们是用自己的监控 Agent InfluxDB。容器内有多种监控方式。有用 ELK，也有其他埋点，比如 StatsD，基于 Dapper 论文实现的全链路追踪。

Q：网络选型这块,还调研过其他网络方案吗？譬如 Calico、Weave 等，为什么会选用 Macvlan？

A：我们的选型第一步是先选择标准的，要从 CoreOS 主导的 cni 还是 Docker 官方主导 cnm 里面选择，目前由于我们容器方案还是走的 Docker，所以选择了 cnm，那从 cnm 的标准里面的选择基本是：1. 基于 XVLAN 的 Overlay；2. 基于三层路由的 Calico；3. 基于二层隔离的 Macvlan，实际以上的方案我们都调研使用过，基于希望尽量简单的原则最终选型还是 Macvlan。

Q：Bili PaaS 平台，自动扩容和手动扩容，应用多的是哪种方式？自动扩容后，资源会重调度么？是否会中断已有业务呢？

A：用的更多的是根据制定好的策略，自动扩容。通过 Nginx 动态 Upstream 对外提供服务，不会中断业务。

Q：关于日志收集每个容器里都跑一个 Logstash 吗？好像 ELK 不能搜索展示上下文的啊？

A：容器里面没有跑 Logstash。目前是在远端的 Logstash 集群上监听一个 UDP 端口，应用直接把日志推送到 Logstash 的 UDP 端口，然后 Logstash 把日志推送到 Kafka，Kafka 的消费者有两个，一个是 Elasticsearch，一个是 HDFS。一般用 ELK 足以。需要详细日志时，由运维通过 HDFS 查询。

Q：我想请教下 Nginx 的一些动态配置文件是封装在容器内部了？还是通过 volume 的方式挂载了？有没有配置中心类似的服务？这块想了解下是怎么实现的？

A：Nginx 的 Upstream 是从 Consul 动态获取生成在本地的，通过 Volume 挂载，持久化到宿主机。有配置中心。业务 Docker 化时，就会推动业务配置接配置中心，Docker 中不在保存业务依赖的配置。

以上内容根据 2016 年 9 月 27 日晚微信群分享内容整理。分享人武安闯，Bilibili 运维工程师，目前主要负责 B 站运维和业务 Docker 化的实施。一直关注于 Docker 的发展，Docker 与 Mesos 结合的容器平台实施

---

2016-09-20： Acttao 开发、运维容器化实践

Q：为什么不采用 Kubernetes 呢？

A：我们在 2015 年初做选型时，Kubernetes 还不是很成熟。当时我们评估 Mesos 和 Kubernetes 后，觉得 Kubernetes 太复杂，Mesos 的核心功能很简单，其他的功能都由 Framework 来实现。我们很容易就理解了 Mesos，于是就选择了 Mesos。

Q：您对容器化 OpenStack 怎么看？

A：OpenStack 在我们看来只是更方便的提供底层资源的平台，容器化后的 OpenStack 只是能使用 OpenStack 的方式管理容器了。但使用 Mesos 来管理容器的话它不关心底层到底是虚拟机还是物理机。 容器化 OpenStack 软件本身后部署升级 OpenStack 也较为方便。我们现在这个系统部署的软件除了 Mesos 外，能使用 Docker 运行的也尽量地采用了 Docker 进行运行。

Q：关于 Weave 很多文章都说性能不行，就你们的项目和实际使用情况来看，能对 Weave 做更多的评价么？

A：我们自己当时测试在 FastDb 模式下，Weave 的性能还在接受的范围里，大概比 OpenStack 中的 Neutron 网络损失了 10% ～ 20% 。就实际的使用情况看来，Weave 集群搭建起来非常容易，毕竟不依赖于任何外部存储。但是它出现任何问题时，调试不是很方便。

Q：Container 网络中，Weave 有什么优点，为什么不采用 Flannel？

A：Weave 的优点搭建方便，有 proxy、plugin、cni 模式，自带 DNS 做服务发现。在 Mesos 还没有原生的容器网络支持时，weave proxy 的方式能很容器的让使用 Marathon 创建的 Docker 容器拥有自己的网络。 我们是一个小的团队，优先考虑我们能容易理解的方案。

Q：请问目前你们 Staging 和 Product 环境的发布频率如何？两套环境是用的同一套 CI/CD 系统吗？对于部署在客户的系统即网络不连通的，如何实现镜像或环境同步的？

A：Staging 环境的发布频率很快，开发恨不得没 merge 一个 mr 就做一次发布。Product 环境在今天之前依然是运维人工去部署的，明天正式迁移到阿里云后，前期依然会采用人工调用我们的 PaaS 工具去做发布。等大家都接受容器化自动化的部署方式可能会考虑在生产环境也进行自动部署。 都是用的同一套 CI/CD 系统。 我们现在的 Registry 使用的阿里云的 OSS，每个网络的内部部署自己的 Registry。

Q：为什么不直接用阿里云的容器服务而自己搭建呢？

A：我们自己弄这套环境时，没有想过会使用阿里云。当计划迁移到阿里云时，自己的那套东西已经运行很稳定，和开发流程配合的很好。使用阿里云的容器服务可能现有的流程要调整，而且我也不确认公司还会不会从阿里云迁走。

Q：如果现在选，会选 Kubernetes 吗？ 为什么？

A：依然会选择 Mesos，因为除了容器编排，不排除我们后续会使用其他的服务，比如 Spark 。同时，Kubernetes 有的， Mesos 现在也有，cni、Docker Volume 等等。

Q：你们的网络似乎经历了 Calico- Weave- Calico 的过程，why？

A：我们从来没有在正式的环境中使用过 Calico。选用 Weave 的原因是 weave proxy 模式在当时能很好的 Mesos/Marathon 进行集成。 现在考虑 Calico 的原因是 Mesos 1.0 后支持 cni 了，Calico cni 能很好的集成进 Mesos，而且 Calico 的性能、稳定性、网络隔离较 Weave 好。

Q：这么多应用，数据库分布是怎样的？数据是挂载进 Docker 的？

A：使用的 REX-Ray 把 OpenStack 的块存储作为数据盘挂载到 VM 的，然后采用 docker volume plugin 的方式挂载到容器里的。一个 Volume 对应一个 Cinder 块设备。

Q：从你说的把你们这套 CI/CD 移到阿里云上差不多用了接近两个月的时间，这也算比较长了，能说说在迁移过程中都做了哪些事情，有什么需要注意的地方？那一般一个普通的应用系统如果迁移到阿里云上（当然也包括其维护的 CI/CD），需要多长时间，有哪些需要注意的地方？

A：实际的迁移时间没有用到两个月，在阿里云上搭建这个系统大概花了 2 到 3 周的时间（大部分的时间都在编写 Aliyun 的 terraform provider），真正部署起来用了一天的时间，我记得是在 8 月 13，那天我们采用包月的方式买了一批的阿里云资源。后续的时间大多是在做迁移后的测试工作，因为公司的运维对在阿里云中运行 Docker 持怀疑的态度，而且这个迁移后续是用业余时间来完成的，8 月中旬我们又忙活了一阵子，这两天刚歇会而。迁移系统应用系统需要注意的事情就是尽量多测试。

以上内容根据 2016 年 9 月 20 日晚微信群分享内容整理。分享人何威威，Acttao 技术总监，多年 Python 开发经验，使用 SaltStack、Ansible 倒腾过 OpenStack 的部署。从 2014 年初开始使用 Docker，2015 年初接触 Mesos 半年后使用 Ansible 在 OpenStack 中部署 Mesos 集群运行到今年 8 月初。现在管理维护公司 IDC KVM 中和阿里云中运行的 Mesos 集群。

---

2016-09-06：唯品会数据库备份恢复容器化项目实践经验总结

Q：发现现在很多采用桥接网桥的方式改善 Docker 网络 ，这个可有测试？

A：桥接网桥的方式是个简单的方案，但 IP 地址分配只能在本机做 IPAM，无法全局管理，存在地址资源浪费的问题。

Q：请问改体系在实战中研发环境，测试环境和预发布环境的交付物是什么呢？

A：MySQL 数据的备份恢复能力。

Q：”容器异常退出 IP 地址不能释放的问题，这都需要我们自己去解决。”可否提供一个大致的解决思路？

A：计划通过 libnetwork unix socket 调一个叫 ReleaseEndpoint 的 API，这样可以保证删除操作的完整性，包括 ovs port、etcd ep 信息、IP 地址。

Q：Docker 1.12 内置 Docker swarm mode，Overlay 网络的性能相比其他开源方案的优劣势是什么？

A：Overlay 网络的优势在于对虚拟网络，多租户场景支持更好，没有 4096 个的限制， 然而没有支持 VXLAN 硬件的情况下无法直接访问，这对于开发，问题定位，监控都是个难题。性能的话对于容器来说不会是一个瓶颈。

Q：做过 Mesos 1.0 测试吗？1.0 已经不会依赖 Docker daemon 了？

A：Mesos 1.0 中仍然支持 Docker 作为 Containerizer。实验环境验证过 Mesos + Docker + Netplugin 是可行的，理论上无论用哪个 Mesos 版本，只要它仍然支持 Docker，那么就可以网络插件的形式来落地网络实现。

Q：容器一般是即用即销毁，想问下，你们做的容器监控，是如何保证数据持久性的？

A：MySQL 备份出来的数据是保存在容器外部卷上，即宿主机上的，容器销毁外部卷并不会被删除，所以数据仍然能够保留下来。

Q：请问你们的容器告警是基于什么做的，cAdvisor 并不能提供告警吧？

A：基于我司已有的监控体系，即 Zabbix。

Q：Devicemapper 使用的是 Direct LVM 吗？设备空间用满的情况下如何扩容？

A：是的。扩容可以通过添加物理磁盘设备，扩 VG，再 resize dm pool 大小。

Q：当您用到上百台机器的时候，镜像是提前下载好的吗？还是临时下载，有没有做镜像下载加速这块儿？

A：镜像是保存在本地 IDC 的 Registry 里，所有机器访问 Registry 通过相近的网络，下载速度很快。好的做法是先全局 Pull 一次再 Run 吧。

Q：我对容器中放数据库的性能比较担心，你们的性能这么高，主要做了什么配置？

A： 因为害怕互相抢资源，我们严格限制单一主机的容器数量、CPU、内存、磁盘都不超配。在资源充足的情况下，MySQL 跑在容器里跟跑在外面没有本质的区别，都是进程。

Q：关于监控这块，上文提到了两个，能给我们介绍一下 Zabbix 和 cAdvisor 的分工吗？

A：Zabbix 通过自己写的脚本，向 cAdvisor RESTful 接口请求容器监控数据。

Q：MySQL 数据库容器化后，性能如何？故障恢复速度怎么样？

A：从数据备份恢复的角度来说，基本与在物理机上跑相当。

以上内容根据 2016 年 9 月 6 日晚微信群分享内容整理。分享叶凯峰，唯品会云平台资深开发工程师。十年 IT 行业工作经验，开发老司机，成长在爱立信，测试界与开发界都打拼过。技术实现崇尚”Simple is the best”，”不以解决问题为目的的技术引进就是耍流氓”。现在专注 OpenStack、Docker 等云计算相关技术的设计与开发工作，负责 Docker 整体技术方案设计、容器网络、监控、日志、操作系统等方面，为公司云计算技术基础设施演进提供支持。。

---

2016-09-08：云计算应用技术发展与企业异构资源池统一管理案例分析

Q：CMP 怎样实现易构多资源池管理，一个 OpenStack，一个 VMware？

A：CMP 针对每种类型的资源池提供特定的 driver，当前 4.0 版本已经支持 CloudStack、OpenStack、VMware，公有云支持阿里云、Amazon 等。

Q：CloudStack 和 OpenStack 也属于云管平台 上层套 SkyForm 的定位也是云管平台这样做的原因是什么？会不会有些臃肿或是在功能会有冲突？

A：对 SkyForm CMP 来说，OpenStack 和 CloudStack 只是一个虚拟化资源池。SkyForm CMP 是一个统一的管理平台，不仅能管理不同类型的虚拟化资源池，企业版 CMP 平台还能管理物理机资源池。

Q：请问 OpenStack 的 Keystone、Glance、Neutron 分别与 VMware 如何结合的？

A：这个项目的 OpenStack 资源池中，我们只使用了 KVM。VMware 是最为一个和 OpenStack 平级的虚拟化资源池。SkyForm CMP 在上层管理网络和镜像。SkyForm CMP 和 OpenStack 使用同一套 Keystone。

Q：看到图例里面 SkyForm 也支持 Docker 容器 开始也提到客户的 VM 生命周期很短为何不建议用户用容器取代一部分虚拟机的工作呢？

A：是的，我们已经支持容器了。使用虚拟机主要是用户业务决定了，这个项目用户的程序都在虚拟机里面跑的，还没有容器化。

Q：镜像可以跨平台，跨资源池使用吗？

A：镜像是不能跨平台的，比如 VMware 的镜像是 OVA，KVM 的镜像是 qcow2，是无法直接使用的。补充一个功能，CMP 支持使用 IOS 创建虚拟机。

Q：好多 OpenStack 版本中不支持克隆和快照，SkyForm CMP 是否完善过这些功能呢？

A：对于 VMware 资源池和 CloudStack 资源池，快照和克隆功能已经支持。OpenStack 我们有修改过，支持 Ceph 存储的快照，对于 san 存储还需要看具体设备了。

Q：这家的 OpenStack 使用的是什么版本的 OpenStack，上到生产环境了么 ？

A：先后有 I 版和 K 版上线。是生产环境。

Q：VMware 尚不具备 SDN，OpenStack 具备 SDN 这块是怎么补齐的呢？

A：SkyForm CMP 支持 VMware 分布式交换机，可以实现基本的网络隔离和控制需求。在这个项目中，用户虚拟机都在客户企业内网，虚拟机网关直接使用网络设备。

以上内容根据 2016 年 9 月 8 日晚微信群分享内容整理。分享人**高铭，天云软件高级实施架构师。从事 SkyForm 云管理平台的实施与技术支持工作。对 VMware vSphere、Citrix XenServer、KVM、CloudStack、OpenStack 有较多的实施部署与运维经验。

---

2016-08-28：基于容器技术构建企业级 PaaS 云平台实践

Q：弹性扩容的时候怎么区分需要垂直扩容还是水平扩容？

A：自动扩容是水平扩容，根据并发量、CPU、内存的实时数据分析来实现。

Q：所有的扩容都是水平扩容吗？不太清楚自动化的垂直扩容应该怎么判断，有什么想法不？

A：目前所有扩容都是水平扩展，要垂直扩展只能手动，原因是垂直扩展变更内存、CPU 后有些情况下需要重新进行实例分布。

Q：水平扩容只是增加实例就可以了，对吧。缩容呢，怎么判断呢？

A：缩容也是一样的，根据最近 10 秒内的并发量决定需要多少个实例。

Q：现在扩容的依据是基础监控数据和业务的监控数据同时考虑吗？

A：目前平台主要基于基础监控数据来进行扩容，业务数据如果也是导致应用性能瓶颈的一个因素的话，纳入到扩容策略里面也是比较简单。

Q：数据共享卷的解决方案是如何考虑的，基于 cinder 还是 ceph，创建个数据共享卷要先格式化创建文件系统，如何实现和 node 节点挂载前的前格式化的，node 节点故障，容器发生重生共享卷如何挂载到新节点上呢？

A：共享卷是直接挂到容器上的，不是挂载到宿主机上，Glusterfs、Ceph、NFS 等都支持。

Q：灰度发布功能，目前我理解的是分为滚动升级和 AB 测试，这个目前实现的那种，AB 测试具体如何理解呢？

A：您说的是蓝绿发布吗？蓝绿发布应该是保证无宕机的前提下，将老版更新到新版。

Ｑ：请问，Kubernetes 中的 A 域名指向一个应用，B 域名指向另外一个应用，都要用到 80 和 443 端口，这个该怎么做呢？

---

2016-08-25：中英人寿保险有限公司基于容器技术的实践分享

Q：您好，现在基于容器的解决方案也有很多，我想了解下部署后，你们是如何设置监控系统的，如果监控容器，可能会因为容器的生命周期不固定，导致部分监控数据会随着容器消失，变成无用数据；如果通过宿主机监控，那么你们是通过什么方式实现的，是通过自行开发，还是第三方开源程序，如何做到资源、应用数据的准确收集和合并？

A：您提的问题也是实践中最担心一些问题，由于容器的技术变化很快，目前监控方面的问题我们更多使用第三方厂商提供的软件进行监控。 保险公司 IT 本身对容器相关技术，更多目前还是处在摸索和熟悉阶段。我们更多把容器作为一种灵活的工具，因此对于后台管理和监控，没有使用 Docker 自带的工具。

Q：请问在 Docker 化过程中，遇到的最大的难题是什么，最后是怎么解决的？谢谢！

A：最大困难还是对容器的理解问题，特别是管理层及运维开发实际操作人员如何理解容器。实际容器 2015 年下半年我们就想使用，但考虑到实际的推广困难，我们也是一直在找合适的机会，直到有合适机会才会真正开始应用和推广。我在分享中也提到了，谨慎原则，因为一旦第一步推广部顺利，那么后续困难就很大。所以我们第一步并没有给自己订立太高目标。

Q：规模上去后，容器如何自动化的管理和容器配置文件如何自动化管理？谢谢！

A：规模问题更多要看自身情况，目前更多介绍上都在强调容器在规模上的优势。但正如我开始提的，实际在业务场景中，规模本身是随着业务发展而增长的。我们目前考虑就是随着规模的增长，自身对容器的使用和经验积累也会随之增长。同时对于我们这样的寿险公司来说，更多采用商业解决方案。这样有比较持续可靠的长期支持，毕竟这个技术变化很快，我们更多关注灵活性和我们选定的优势的发挥。自动化管理和容器配制文件，只要项目部是很多，那么问题不大。如果普遍推广的话（这也是我们下一步计划）那么开发和运维人员自身的能力提高是解决自动化的关键，而不只是软件。

Q：您好，能否介绍下微服务技术改造方面的经验，尤其是数据拆分方面，如何破除数据库之间的表依赖，比如在单体应用里很多功能都是直接通过数据库的关联查询实现的，如果进行微服务改造，怎么处理类似的关联查询？另外，能否介绍分布式事务管理的技术方案？

A：数据部分我分段来回答一下。数据拆本身更多是 IT 对业务的理解问题，中英 IT 在这方面是比较擅长的，毕竟是自己的业务。这点首先我认为没有什么通用解决方案，必须根据实际自身情况来考虑。中英情况我接着介绍一下。\ 关联查询问题会很多，特别是性能。所以我也提到，这点光用技术解决方案很难解决，必须结合业务逻辑，考虑如何把数据前推。关于分布式事务管理，目前我们不建议采用分布式的事务管理，那样只会带来更复杂的逻辑关系。我们最多是考虑 Redis 的集群部署，但事务处理都是集中的。对于复杂问题，我们尽量去回避，本身项目就有很多挑战，不希望在这方面有更多不稳定因素。

Q：数据库的数据前移到 Redis， 增删改也是通过 Redis？

A：不是数据库前移，我们由于考虑信息安全和合规的要求，实际这次数据不落地。Redis 都是缓存数据，而且不写文件系统。只用作查询，对后台数据的更新删除，还是采用远程调用服务的方式。根据业务分析，我们的应用绝大多数是查询，因此首先保证查询速度。

Q：如果通过服务调用的方式

更新后台数据的话，怎么做到事务的集中管理的呢？

A：由于寿险公司核心业务系统都是集中系统，事务处理一开始就根据业务模块和逻辑做了划分。因此在内部本身就是事务逻辑非常严格控制。这里首先是业务逻辑就有严格的前后逻辑顺序，什么前提下能做什么不能做什么有严格划分的。在 DB 层面的事务，我们 DB 本身就是集中 DB，不是分布式的，因此 DB 本身控制事务，不存在控制不住的情况。但如果调用太多，的确会有严重锁的问题，这点反而是我们比较头疼的问题。同时首先业务时时交互频率不是那么高，因为不像电商，这个问题不突出。

Q：规模上去后，有没有测试过性能方面的场景，比如某种配置的物理设备，可以负载多少容器，性能相关指标如何？谢谢！

A：目前我们还没有这方面实际的经验。但在实施中考虑到规模的问题，因此这次实际选择的就是公用云，直接使用云的基础服务。另外关于性能和物理配制。这点，至少目前我们遇到的主要问题是内存不是 CPU。合理分配内存是个经验积累的过程,我在分享里也提到了，我们遇到了因为配制不合理 ELK 性能非常差的情况，反而应用环境本身没什么问题。由于我们在规模上没有太多经验，因此不能给您更多的有用建议，这点互联网企业应该更有经验。

Q：您好，请问你们公司是否存在一些 Windows 应用，针对这些应用如何使用容器统一部署管理？

A：我们有 Windows 应用，至少目前我认为用 Docker 来统一部署 Windows 应用不太合适，我们内部如果有这个要求会选择 VM，VBOX 也是不错选择。

Q：您提到不过分强调测试自动化，尽量不改变测试流程，那么对于自动构建和单元测试的自动化有没有考虑呢？毕竟这些是比较消耗人力的部分。

A：自动构建我认为比较现实，单元测试有考虑。不过我们测试案例过于复杂，目前看短期实现不太现实。而且性能也是个问题，如果下一步要做我们会更多考虑一些特定场景。比如产品发布后的回归测试，这个有可能，但不会是普遍应用。

Q：这次容器化改造后，对比原来的系统有哪些方面具体的提升呢？

A：性能本身我认为和容器没什么关系，虽然这次性能有很大提升，但更多是因为用了公有云和 Redis 做缓存。容器改造后最大提升的我认为目前是部署和更新的效率。对运维工作效率有非常大的提升，毕竟大部分应用环境的更新都自动化了。这点本质性变化。

Q：请问中英人寿应用更新的自动化流程能做些介绍吗，有没有将应用和配置分离做改造？

A：我们这次是个全新项目，所以不涉及改造。自动化部分就是标准的持续集成 Git+Jenkins 的自动化管道。Git 根据环境做了一些分支，部署直接采用 Docker 方式。这是一整套的。Docker 相关配制目前是在 cSphere 里做管理，实际我们没太多操心这个部分。对于开发来说实际没什么太大变动。只是自动化构建做通了。

Q：是否建议企业最佳实践是从新开发或重构应用开始容器化？

A：这是个最保险方法，但我认为重点不是全新或者重构。而是是不是能带来实际效益，我说的是业务效果。对于用户来说实际并不了解和关心容器技术，想推广一个过用户关，一个过运维和开发协调的关。

以上内容根据 2016 年 8 月 25 日晚微信群分享内容整理。分享人张琦，中英人寿信息技术部总经理。中央财经大学保险专业毕业，具有 15 以上的寿险从业经验。长期从事寿险业务及信息技术相关工作。

---

2016-08-18：用 Harbor 实现容器镜像仓库的管理和运维

Q：Master-Slave 的镜像架构中,如果 Slave Registy 中的镜像被删除了，会不会再次自动从 Master Reg 里面自动同步？

A：如果停止后再重新启动复制策略，可以同步被删除的镜像。

Q：对于多个投产地，多个仓库，哪种方式的高可用方案好么？第一种，共享存储存储可能会出现单点故障么？

A：共享存储只适合同一数据中心，多个产地延时太大，不适合共享存储。

Q：Registry 之间同步是如何实现的？

A：Registry API。

Q：在存储这块考虑过提供插件方式可以调用外部模块，比如以插件方式支持 s3 这种对象存储？

A：Harbor 支持其他存储方式，参见 Harbor 文档。

以上内容根据 2016 年 8 月 18 日晚微信群分享内容整理。分享人**张海宁（HenryZhang），VMware 中国研发中心云原生应用首席架构师，Harbor 开源企业级容器 Registry 项目负责人，Cloud Foundry 中国社区最早的技术布道师之一。在 VMware 中国研发中心先后负责开源平台 Cloud Foundry、大数据虚拟化、软件定义存储等领域的技术布道和解决方案推广。目前着重关注云原生应用的研发工作，内容包括 Container、PaaS、IaaS 等方面。

---

2016-08-16：容器化 ICT 融合初体验

Q：网络转发有没有遇到瓶颈？有没有尝试一些加速技术，比如 DPDK？

A：因为是控制面网元，目前没有遇到瓶颈，没有用 DPDK，我们之前测试过虚拟机的，因为网元特点，也是没有配置 DPDK，目前的测试上看，性能上没有问题。

Q：现在数据库也放在容器中吗？

A：是的，但是也是数据库集群，我们正在做将数据库分离的工作。

Q：你们实测的容器运行于虚拟机环境，性能如何，你们容器网络如何实现 NFV 互联？

A：容器没有基于虚拟机环境，因为是控制面网元，性能没有遇到瓶颈。

Q：容器不会包打天下，与虚机，物理机并存可能是一段时间内的一种常态，我们有没有分析哪些业务适合容器化，哪些业务不宜改变？并且在利用 Kubernetes 作为容器的编排调度工具时，如何实现容器与虚机应用的互通？

A：其实业务不宜改变不仅仅是技术问题，也和业务厂商是否愿意改变有关，毕竟一些遗留的业务已经在现网运行很久了，很难短期内容器化。另外，我们确实碰到了需要内核优化的业务。我们系统中还没有做容器和虚拟机应用互通。

Q：传统 CT 网络不仅仅是 IMS 吧，对于 CS、PS，SDN/NFV 化，你们有什么思路吗？

A：IMS 使我们容器化的第一个尝试，其他的网元也正在研究中，后续也会做相关的测试，如果有兴趣，也欢迎参加我们后面的测试。

Q：你们的资源池，有路由器，安全组，负载均衡之类的功能嘛？路由器，负载均衡器可以被分配公网 IP 吗？

A：指的是容器的资源池还是我们已有的私有云资源池，已有的私有云资源池是有的，但是容器这个原型系统还没有。

Q：类似 Clearwater 的开源项目还有哪些？

A：NFV 方面的吗，如果是 IMS，Clearwater 业界用的比较多，NFV 其他网元开源项目很多。

Q：你们的虚拟机底层使用什么虚拟化技术支撑？

A：这次演示，底层用的就是 Docker，我们的私有云资源池有 VMware、KVM 也有 Xen。

以上内容根据 2016 年 8 月 16 日晚微信群分享内容整理。分享人马轶慧，中国移动通信有限公司研究院私有云项目经理，之前曾任 VMware 研发中心研发工程师。一直关注并致力于虚拟化、容器、云计算等相关领域。

---

2016-08-11：应用容器化之 Kubernetes 实践

Q：请问在 Kubernetes 架构下 搭建分布式服务框架如 Dubbo

需要将主机地址和暴露端口注册到 ZooKeeper 上，这个主机地址和暴露的端口你们是怎么处理的，即容器内的应用如何获取 Docker 宿主机地址？

A：Dubbo 服务不需要暴露主机的 IP 和地址，只需要知道容器地址即可。这些服务都是注册到 ZooKeeper 上面，通过 ZooKeeper 完成服务发现，Kubernetes 能够根据暴露端口进行调度,当然有些应用要求容器能获取到宿主机的 IP 地址，这块我们对 Kubernetes 做了一些修改，可以动态注入诸如宿主机 IP，宿主机主机名信息到容器的环境变量中。

Q：ECP 的定位和解决目标相比较目前大家在用传统的云平台解决方案来讲下？

A：ECP 产品定位是一套完整的容器解决方案，从容器生命周期管理，资源监控到日志分析处理，相比与云平台解决方案管理的对象不再是虚拟机，而是容器，面向的对象是服务。

Q：关于容器本身的资源性能监控，是用的 cAdvisor+Heapster 吗，如何能保持 pod 重启（重启后 pod 名称变化）后的数据连续性，谢谢。

A：资源监控用的不是 Heapster，ECP 的资源监控是用 cAdvisor+ 我们自己研发的采集 Agent+Ceilometer+MongoDB+HBase 等技术。复用了我们在做 CMP 产品时的技术，rc 中的 pod 重建后会重命名，这块对于单一 pod 数据的连续性还没有考虑，我们是把 rc 当做一个整体考虑的 。

Q：你们对外服务的负载均衡如何做的？是直接用 Kubernetes 的 service 吗？

A：对外负载均衡现阶段用的是 Kubernetes 的 service，考虑到 iptables 带来的性能损耗，后续我们会考虑使用别的方案，在集群内部直接把流量转发到对于的 pod 上。

Q：请问 Kubernetes 容器和在其中运行的应用程序监控是如何做的？能介绍下吗？谢谢！

A：ECP 的资源监控是用 cAdvisor+ 我们自己研发的采集 Agent+Ceilometer+MongoDB+HBase 等技术。复用了我们在做 CMP 产品时的技术。简单来说就是用 cAdvisor 采集原始数据，然后通过 Ceilometer 持久化，提供实时数据查询、告警等功能。数据会定期转存到 hbase 做历史数据分析。

Q：请问，有基于 Kubernetes 的多租户和用户配额开源实现嘛？

---

2016-08-04：传统金融 IT 对混合云管理的一些思考

Q：传统金融行业很多关键系统架构比较简单都为集中式架构，不好做横向扩展，不适合放到私有云上，这个问题有什么好的解决思路？

A：从数据面和业务场景来细分，关键系统涉及客户资料、资金动账系统，仍然保留在传统集中式的主机平台，但是会将查询类交易下移到基于 X86 的私有云上。

Q：混合云如何解决多租户服务与金融行业监管要求物理隔离之间的矛盾？

A：金融行业监管要求物理隔离在数据中心网络层面表现为”2 网分离”：办公网和业务网。 相对应的，混合云的多租户也细分出开发云、测试云和生产云租户。各租户的资源和操作严格进行隔离

Q：您认为迁移到云的步骤应该如何，哪些适合迁移到云

A：在实践中，先理清应用的家底。根据业务场景需要和云的能力、团队的技能成长、监管底线（上公有云的话）等维度进行评估，选择上云的应用。迁移步骤具体看是否要重构应用架构，相应迁移难度不一。

Q：哪些业务适合使用云服务?云架构与传统架构肯定存在一个并行期，两套架构如何融合并存?

A：在私有云，云服务不是像公有云服务一样完备，建设是有个过程，所以前期内部管理类、和客户交互的渠道类业务适用上云。

Q：云架构与传统架构肯定存在一个并行期，两套架构如何融合并存?

A：的确存在并行期，架构职能团队可以发挥较大作用，一个作用是架构管理团队各片区和开发团队设计角色管理好各产品的应用架构,另外一个作用组织人手开展云架构的设计、原型开发，引导产品的架构进行演进。

Q：你指的混合云是以 Oracle、IBM、VMware 主导的商业软件公司提供的平台比如 O 记的数据库混合云，还是以开源软件为主的比如 OpenStack、KVM，上面跑基于开源的 Tomcat、MySQL ？

A：我们理解的混合云是更广义，包括公有云和私有云领域，公有云例如 AWS、AZURE、阿里云等，私有云例如 vCloud、青云等。

Q：传统金融的现有商业软件如何与开源平台结合？

A：以选择云平台的技术栈建设云服务，现有商业软件不是强求结合，结合成本太高或技术架构不合适就该舍弃。例如小机 WEB 应用上云，就会从 Was 换成轻量级的 WEB 应用服务器，例如 Tomcat、JBoss。

Q：传统金融的 IT 运维能否自己支撑开源平台构建自己的混合云，从你的视角看中小型城市商行依靠自己的 it 运维构建自己的混合云当前阶段是否切实可行？

A：这要看单位的大背景，如果业务部门没有传导市场压力到 IT 部门，那么面对 IT 开发团队，由 IT 运维主导建设基于开源的混合云平台作为起点，也是一种可行的选择。我们的大背景是业务压力的传导，以及自我变革的高层压力，所以是由架构职能团队牵头规划设计，新建的云平台团队实施落地。

Q：请问在云化的过程中，是已自行研发开源技术为主呢，还是使用较为成熟的商用软件为主。如何平衡成本与效率的关系

A：贴近应用的部分建议自研，例如开发框架、公共组件。基础设施部分需要稳定为主，例如虚拟化平台、对象存储服务、消息队列服务等，一般选择商用软件或开源软件企业版，有些加客户化定制。

Q：如果是混合云的架构话不是应当考虑公有云和私有云一致性吗？，而刚才说的结合就变成了一种简单的去 IOE，客户总不能生产跑 Was，公有云跑 Tomcat 吧，如果这样推动混合云那么是不是意味着先就要推动去 IOE，改造应用？

A：这个问题可以细分 2 种层次来看，混合云架构设计对基础设施（VM、容器、镜像、网络等）是要进行抽象，达成这个层次上看私有云和公有云是一致 的。 另外混合云架构设计上，管理的另一个高阶层次是对应用架构的抽象，理想能够做到应用在不同云上进行无痛迁移。传统上在 IOE 上的业务系统，如果有开发框架的支持，且框架的架构做的好，则开发框架改造上云后，应用代码改造量很少。

以上内容根据 2016 年 8 月 4 日晚微信群分享内容整理。分享人罗文江，某传统金融 IT 架构师，关注和 IaaS、Docker 和云管理关联的技术。

---

2016-07-28：SAP Anywhere 产品背后 CD 的实现

A：DaemonSet 是 Kubernetes 的一种功能，用来把 POD 调度到所有满足条件的节点上。我们的使用场景是把看家狗程序调度到每一个集群里的节点，以起到监控作用。

Q：你们主要跑的什么类型的应用？

A：我们的业务是基于 WEB-UI 的 ERP 产品。

Q：请问 Kubernetes 使用 health check http 请求的时候有没有遇到容器可能本身需要好久才能启动完毕那么这个人机制就会一直死循环…请问这个有没有好的方式解决？

A：Kubernetes health check 分成 readinessProbe 和 livenessProbe。前者决定容器是否 ready，后者当检查失败后直接暴力杀死容器。某些容器启动较慢，所以需要设定一个等待时间。我们的容器等待时间是 readiness->15s, liveness->2min。

Q：后来，我们按功能把原先的一个集群拆分成了多个，分别运维，如此一来，稳定性大为提升，这个怎么拆的呢？

A：根据功能拆。比如一个集群专门跑 Jenkins，另一个集群专门跑 slow-test。BTW、slow-test 是用来进一步验证当前提交是否存在 bug 的一种测试，由于跑的时间比较长，所以叫 slow-test。

Q：Kubernetes API server 经常宕机?到规模上限了？API server 可以起多个做负载均衡吧，API server 宕机的时候 Scheduler 和 controller-manager 到瓶颈了么？

A：早期的宕机可能是我们自己使用不当，比如把 API server 交给每一个开发人员（我们有 200 多人），然后大家都去玩 kubectl 各种命令，里面有几个命令比较吃资源，一种是 port-forward，另一种是 watch kubectl get pod。

Q：对于应用的配置你们如何管理？

A：这是个好问题。我们内部讨论的比较激烈。目前有两种极端，一类人倾向于每个服务自己管理配置；另一类人倾向提供一个专门的配置微服务。各有利弊吧。

Q：一个 DEMO 系统是否包括依赖的服务？如果依赖，那假如 DEMO 系统中多个服务需要发布，要每个都起一套 DEMO 系统吗？

A：前文提到我们有接近 30 个微服务，是的，每一套 DEMO 系统都包含那么多微服务，所以做一套 DEMO 系统挺”重”的。当然我们在搭建 DEMO 系统时，主要还是利用了 Kubernetes 的调度能力来并行处理任务的。

Q：Web UI 应用有没有涉及到负载均衡可以介绍一下的？

A：我们使用 Nginx 作为反向代理，Kubernetes 的 deployment/rs 作为负载均衡。nginx upstrea/server 编写服务的内部域名，被 SkyDNS 解析成 cluster IP，再被 IP tables 做 round robin 路由到真实 pod。

Q：『根据功能拆。比如一个集群专门跑 Jenkins，另一个集群专门跑 slow-test。BTW，slow-test 是用来进一步验证当前提交是否存在 bug 的一种测试，由于跑的时间比较长，所以叫 slow-test』，你们原来是混在一个集群里的啊？

A：是的，早期我们是跑在一个集群里的。那时候我们膜拜 Kubernetes，认为谷歌大师级的产品一定能很好的利用异构系统组成集群，并且良好的管理里面的应用的。事实比较令人遗憾，当然不排除我们自己代码的问题，总之跑在一起比较不稳定，而且遇到故障时比较难恢复（因为影响面比较大）。

Q：您好，我想了解下你们开发的 DaemonSet 可不可以用 Supervisor 这样的去替代，如果可以需要注意些什么，之前监控 Web 遇到过 Web 服务 200，实际 Web 服务已经挂起的情况，如何监控类似事件？

A：补充一下第一个问题的答复：监控 web 服务，这个需要服务自己暴露（实现）一个特殊的 API，通常可以是 /heath，然后服务自己在 API 里面完成健康扫描。那么 k8s 就知道服务是否处于僵尸状态了。

Q：你们的 Kubernetes API 有没开启 HTTPS？如果开启是否有在 Pod 访问 API 的案例介绍一下？

A：事实上，我们开启了 HTTPS，但是在大部分情况下，我们仍然使用 HTTP 端口连接 API server。我们下一个目标就是全面启用授信的安全模式。至于 Pod 访问 API server 只要有 service token 即可。

Q：你好，把 Jenkins 和 Slow Tests 拆分集群是按命名空间分了，还是再单独部署了另外一套 Kubernetes？

A：我说的拆分是指物理上的拆分，变成两个 Kubernetes 集群了。这方面我们仍然在摸索，到底是多个小集群容易管理还是一个大集群容易管理。

Q：有考虑过使用 Docker 官方的 Swarm 吗？新手，不知道该选择哪个。

A：Kubernetes 和 Docker Swarm 天生就是两种教派，有点”正邪不两立”的味道。事实上，我们早期做原型的时候有考虑过 Mesosphere。个人观点：从目前的发展来看 Kubernetes 和 Swarm 很难走到一起去，这意味着选择其中之一必然会放弃另一个。而 Kubernetes 是谷歌主推的，考虑到谷歌内部 Borg 系统是 Kubernetes 的原型，每天跑着百万级的应用，应该不会有错的。

以上内容根据 2016 年 7 月 28 日晚微信群分享内容整理。分享人陈贇喆（MilesChen），资深开发工程师、全栈工程师、系统架构师。从业十年有余，目前就职 SAP 中国研究院，担任架构师一职，负责 SAPAnywhere 产品的 CI/CD 工作。

---

2016-07-26：基于 Docker 的负载均衡和服务发现

Q：同一个域名指向一台主机内的容器服务，部署了 n 个相同的容器，怎么根据他们的负载来分配到不同的容器中？

A：7 层负载均衡麻烦参考下 Nginx 和 HAProxy 的使用方法即可，注意，我们的 HAProxy 容器跟其他目标服务的容器是直接在同一个网络里面的。你说的根据负载分配，可以使用最小连接数算法，即 leastconn 算法，需要查看 HAProxy 帮助手册进行设置。

Q：Docker 1.2 IPVS 的方案，是否可以实现完全取代 Keepalived+Nginx 的效果？

A：不能， IPVS 是 4 层协议的，在很多场景下，需要 7 层协议的功能，例如共享同一个端口，提供 7 层协议解析，gzip 压缩，cookie 注入，session 保持等功能。

Q：有没有评估过 Kubernetes 在 host 上用 iptables 做 lb 的方案？为什么不用那种？

A：因为我们希望提供 7 层的路由和负载均衡，iptables 的方案是基于 4 层的，不能共享同一个端口，不能提供 7 层协议解析，压缩，cookie 注入，session 保持等功能。

Q：问下灰度发布具体是怎么实现的？

A：灰度发布的具体实现方式如下： 例如有服务的两个版本 A 和 a，他们使用相同的路由，挂在同一个域名（例如 www.example.com）的后端，但是 A 和 a 的权重不一样，通过调整权重来做到灰度发布，流量分配到不同的后端。

Q：请问 haproxy 访问其它主机容器网络怎样通信？

A：一个容器集群有多台机器，通过 Overlay 网络，可以做到跨主机节点在同一个网络中。

以上内容根据 2016 年 7 月 26 日晚微信群分享内容整理。分享人谭林华，阿里巴巴高级工程师，多年以来一直关注系统接入层相关技术，包括 DNS，负载均衡，服务路由和发现，热衷容器技术。

---

2016-07-19：浅谈 Docker 安全合规建设

Q：容器安全和虚拟机的安全有什么异同？

A：容器可以在更细的颗粒度上来保护应用，比如说物理机好比大楼，虚拟机好比不同的房间，容器就是里面同房的租户，大楼及房间保障了外部的安全，如果你不相信同屋的租客，则需要用容器来更强的隔离，这是 2 个不同角度的问题。

Q：镜像安全，Clair 扫描靠谱么？

A：Clair 是 CoreOS 发布的一款开源容器漏洞扫描工具。该工具可以交叉检查 Docker 镜像的操作系统以及上面安装的任何包是否与任何已知不安全的包版本相匹配。漏洞是从特定操作系统的通用漏洞披露（CVE）数据库获取,它偏向于静态扫描，即镜像安全，国际上对容器运行时安全方案涉足较少，国内容器云对安全更是空白一片。

Q：Docker 有一个 User Namespace 的机制，这种隔离在正式的安全规范里有相应描述吗？有没有尝试过利用这种机制增加安全性？

A：Docker 的安全标准规范基本处于空白阶段，大家都在摸索，主要是实践累计。user namespace 可以增强一定的隔离性，但是刚才也提到：用 user namespace 隔离后，其实太多用户不会用操作日志，用于后期追踪及审计。

Q：能介绍下沙箱与容器的不同吗？

A：沙箱和容器只是在工作的方式上比较类似，但是底层的技术实现和代码其实是完全不一样的。

Q：如何才能有效的检测出下载的镜像是否含有木马等不安全的信息呢?挂载到容器中的目录，如何给只读权限，后续数据库一些信息想写入宿主机又如何实现？

A：对镜像扫描目前世面上还是有一些产品的，比如说刚才某位同学提到的 Clair。 挂载到容器的目录可以通过 ro 参数设定只读权限，但是需要写入的目录挂载只设只读权限程序是不能运行的，这样就涉及到宿主机的文件安全，相信宿主机的安全产品及方案，现在已经很多，就不复述了。

Q：木马检测涉及到特征代码库，检测比较难吧？

A：木马检测其实都是基于目前的技术， 只是容器的数量可以远远大于虚拟机，这样对检测的性能和时效有了更高的要求。

Q：最近一直被人问到安全性的问题，但是只从单机角度考虑安全性是否已经无法满足分布式计算环境，我们是否更应该从分布式计算带给我们的规模效应和自愈机制来重新审视 Docker 的安全标准，请问嘉宾是如何看待分布式计算中的整体和部分，以及它们之间的安全关系，谢谢。

A：分布式也是由节点组成的，单机安全是基础，如果单机安全性都无法满足，分布式的安全更无从说起。 当然，分布式存在大规模效应，节点更多需要关注的是数据的处理及储存安全；在满足了节点安全后，分布式更多的应该是考虑跨节点之间的数据传输安全，尤其是跨公网的数据传输（VPN 隧道也是属于跨公网的传输一种）。自愈机制其实应该算保障业务连续性的一种方式，当然也可以归纳为安全的一种。

Q：请问 Rancher 除了使用”环境”外，目前能完美实现租户隔离吗？

A：可以使用主机标签 + 容器策略的方式，将不同用户用虚拟机或物理机进行隔离。 就目前 Rancher 来说，不同环境是比较好的隔离方案。

Q：不知道嘉宾给的安全建议是否适用于 CoreOS 这种 Docker 化的 OS，还是说这类 OS 会有更好的合规功能？

A：CoreOS 这种系统确实更适合容器，而且承载的功能也更加少，相应的需要合规的点也越少。 但是不排除某些合规要求强制的功能点无法满足，这需要根据实际情况来判断。

Q：除了镜像扫描，还有哪些容器安全需要注意的地方，和哪些成熟方案呢？

A：除了镜像扫描，还需要关注容器运行时安全，如网络安全，应用程序漏洞，防止被攻击，安全策略等； 相信接下来有容云发布的 AppSafe 产品不会让大家失望。

Q：虚拟机的安全方案是否也同样适用于容器？

A：应该是部分适合，刚才提到容器和虚拟机关注点是不一样的。 虚拟机更多是系统安全 + 应用安全， 容器的主要关注点还是应用安全，如代码漏洞，软件漏洞等等。

Q：如何评价 Docker 1.12 中 Swarm 模式自带的 TLS 认证？

A：大家都知道前段时间的心血漏洞，大家也知道目前互联网环境的情况， 其实 TLS 认证已经是很多环境的必备要求，甚至对 TLS 的版本号也是严格的要求，比如说某些行业必须使用 TLS1.2 以上的版本才能合规。Swarm 模式自带的 TLS 认证相信也是基于此类要求。

以上内容根据 2016 年 7 月 19 日晚微信群分享内容整理。分享人**蒋运龙，有容云高级咨询顾问，一个 IT 的老兵，十年来混迹于存储、三网融合、多屏互动、智能穿戴、第三方支付、Docker 等行业；经历过测试、运维、实施各岗位全方位的摧残，依然活跃在技术的风头浪尖上。之前分享过《老司机带路 使用 Docker 实现丝般顺滑的持续集成》**。

---

2016-07-14：应用容器 env 化实战

Q：Mesos 运行一个任务，如果发现该任务运行过程中需要加大资源，Mesos 如何做到对任务资源的弹性扩容？如果采用 Docker 的话，是新建更多的 Docker 容器还是直接扩大现有 Docker 的大小？

A：一般是扩展更多的 Docker 容器个数，除非是某个任务有最小资源要求，才要扩大单个 Docker 的大小。

Q：开发人员使用的本地环境变量如何管理？例如一个应用，有数据库，有搜索引擎，还有两个 Java APP，不同开发可能需要嗯环境不同，例如我是搜索功能的开发，需要链接公共的数据库，而有些开发需要自己有数据库，搜索引擎却需要链接公共的。这种配置，如何管理？

A：这种最好将数据库环境变了进行区分，配置两个或多个类似环境变量。

Q：请问 MySQL 数据库怎么随 Docker 迁移?备份和恢复有什么好的建议吗？

A：MySQL 现在是固定主机主从同步，没有对 MySQL 做迁移，我们的数据现在备份是定时全备份，正在尝试使用 MariaDB 集群 Galera Cluster ，但还没有上生产，当然有共享存储的话就最好不过啦。

Q：请问线上服务更新 war 包，如何能使对外服务不间断吗？

A：数人云目前采用代码版本和镜像版本统一，对外服务不间断，数人云目前的做法是对应用进行无状态改造，后通过 marathon put 更新容器。

Q：请问 配置文件的话生产环境和开发环境怎么区分？

A：生产环境和测试环境都是隔离的，配置文件配置不同的参数即可。

Q：请问对类似 Java 应用 jdbc、spring.xml 等配置文件如何管理？

A：XML 配置 通过 sed 替换传入的环境变量。

Q：生产上配置项变更怎么操作？

A：生产配置的值需要修改时 ，在 configcenter 页面中修改，再触发 Jenkins 更新配置文件的 job， 生产新的配置文件 ，再调用 marathon API 更新 task 进行更新。

Q：业务的配置是和环境配置放在一起的么？

A：是的，都是通过 envfile 进行统一的。

Q：请问你们针对应用弹性扩展是自感应的吗？如果是，请问是基于什么策略做的，监控报警还是什么？

A：数人云是通过监控报警触发弹性扩展的，如监控接口返回的时间，容器内存使用率等。

Q：请问你们对环境变量是采用什么样的管理方法？有相应的命名规范吗？环境变量多了，会出现管理方面的问题吧。

A：环境变量键值由开发维护，运维需要提前了解新增环境变量，目前在配置中心里维护，容器环境变量变量命名规范很重要，我们目前采用服务名 ＋ 需连接的组件名 ＋ 属性 进行命名的，且环境变量全部大写。

以上内容根据 2016 年 7 月 14 日晚微信群分享内容整理。分享人方志浩，92 年的程序猿，毕业之后一直在数人云，对 Docker 和 Mesos 有深入研究，目前做数人云平台打包部署以及部分客户项目实施工作，喜欢在实践中尝试新事物并总结。

---

2016-06-30： Docker 网络方案初探

Q：从你发的 Marathon json 文件来看，你们是对 Mesos 底层的网络做了扩展吗？容器网络通过"parameters"传递下去的吗？

A：就是利用 Marathon 支持的 Docker parameters 下发，等同于 docker run ---net dataman xxx。

Q：Felix 根据配置的 pool 地址段配置路由，BGP Client 通告路由？请问 bgp 的邻居关系是怎么建立的？是依靠 etcd 里的信息？

A：是的，Felix 配置本地 Kernel 路由，BGP Client 负责分发路由信息；BGP 小规模部署采取 mesh 方式建立，所有节点互联 n^2 的联系，大规模部署推荐 部署一个或多个 BGP route reflector，专门负责路由信息分发。

Q：请问在 DataMan 这个网络中路由信息是如何更新的？我们知道 BGP 是可以自己发现收敛网络的，那么在网络控制层面是如何设计的？

A：随着使用 DatMan 这个网络的容器的添加或者删除，Felix 负责更新本地路由，BGP client 负责向外分发；Calico 的 BGP 和广域网的 BGP 还是有不同，它只是使用 private AS num，相对自治，网络控制层面都是可以程序控制的。

Q：请问 Calico 如何解决多租户里地址冲突的问题？

A：多租户容器混部在同一主机上时，所使用的 Network 最好不要用同一个 Pool 里的就好，这样就不可能有冲突了。

Q：如果集群的容器很多，那么相应的路由表的规则也会增多，这样会不会对网络性能造成影响？

A：网络性能不会有太大影响，因为容器多流量多网络压力本来就大，倒是会增加系统负载，毕竟要配置路由规则，同步网络信息；这部分我们也很关心，但还没有具体的测试结果。

Q：还有就是路由信息是存放在 etcd 中吗？如何保证路由表的读取性能和维护路由表的信息更新？

A：生效的路由肯定是本地的，Endpoint 等信息是在 etcd 的；这两个问题都是 Calico 自身要解决的问题，这部分我们也很关心，但还没有具体的测试结果；

Q：Calico 下跨多个路由 hop 的情况，中间路由不需要学习这么多的容器路由表吗？

A：不需要，中间过程是依赖节点之间原有的网络建设的，只要两个节点互通，所有的 hop 都不需要知道 Calico 内部的容器路由信息。

Q：还有一个问题，就是网络管理问题。目前从设备厂商网站看有几个支持 VXLAN 控制器的。这些控制器能不能与容器 OVS 协同？目前来看我们这里买国外产品还是比较困难的。

A：这个肯定是问题，我觉得作为平台方，我们能做的很少，如果要改变，肯定是要 SDN 设备厂商发力，就像是各家都会去为 OpenStack 适配设备提供 driver 一样，但是也需要 Docker 或者说容器编排系统能做到如同 OpenStack 那样的行业标准级。

Q：Calico 能和 Flannel 整合么，CoreOS 上 Kubelet 里同时出现了 Calico 和 Flannel？

A：Calico 在 DockerCon 2016 应该是高调拥抱了 Flannel，两个整合出了一个叫 canal 的项目，有兴趣可以去找找看。

Q：我想问一下老师，你这 VXLAN 的标签是 Calico 打的对吧？

A：Calico 没有 VXLAN，Calico 的 tag 会对应到 ipset，iptables 用来 match filter 规则。

Q：Calico 下跨多个路由 hop 的情况，中间路由不需要学习这么多的容器路由表吗？

A：不需要，中间过程是依赖节点之间原有的网络建设的，只要两个节点互通，所有的 hop 都不需要知道 Calico 内部的容器路由信息。

---

2016-06-28：公有云上的容器实践分享

Q：请问你们是生产环境么，应用代码放容器里还是挂卷，镜像权限如何控制（比如测试和生产），代码测试后，上生产配置自动还是手动修改还是有配置中心呢？

A：您指的是源码还是编译后的产物，我们是编译后的产物是镜像，容器直接运行，测试和生产是隔离的，相当于我们管理了四套环境（开发、测试、预发、生产），介质是通过跳板机同步的，有统一的 SCM 做不同环境的配管。

Q：Kubernetes Master 的高可用你们是怎么做的？

A：Master 我觉得没必要做，宕了重启就行，没有损失，我们就是这么做的，只要保证 etcd 等高可用就行。

Q：从集群外部对 Kubernetes 的 Service 的访问是如何实现的？比如公网 IP 是怎么绑定给 Service 的？

A：Kubernetes 发布成 Service，是可以给定 publicip 的，这个时候你可以用公网 IP 作为网络池，内部有一层端口映射。

Q：Kubernetes 现在自己还缺少可视化编排能力，那个 UI 也是以监控为主，你们实际使用中对 Kubernetes 可视化编排需求多吗，如果多的话目前怎么解决？

A：我们自己做了部分编排，编排不一定非得是图形化的，我们以表单为主，主要用于部署编排。

Q：阿里云上的容器能提供负载均衡嘛比如我有个宿主机挂了？

A：这个不是阿里云做，而是 Kubernetes 做的，Kubernetes 有 Replication 的能力。

Q：这几天遇到个需求，用户想要通过 VNC 进入容器里安装他的应用，请问你们碰见过吗，网络方面怎么解决呢，需要将用户使用的容器配置上外网的 IP，我们也用 Flannel，但 Flannel 似乎不行吧？

A：这不是个好方式，这是把容器当虚机用，如果真要这么做，那 Flannel 就不要用了，直接端口映射或者 Pipework，但真不建议，会丧失容器的好特性。

---

2016-06-21：基于 Docker 实现 DevOps 的一些探索

Q：对于一些中小互联网企业尤其 DevOps 二次开发能力不强的，在使用 Docker 集群方面有什么建议？

A：一条 DevOps 流水线对集群环境的需求不高，我们更应该关心的是对每一个步骤的单个工具怎么去使用和管理，集群环境适用于都会用到大规模的容器部署中。还是那句话，技术不分好坏，选择最合适的就行。如果把容器当作虚拟机来跑，可以解决你的一些问题，那就这样跑又如何呢，技术或者工具是为需求服务的。

Q：运维投拆开发应用消耗太大，为什么用了容器就能解决？只是开发和运行用了同一套环境，性能低下一样得靠优化，客器只是让大家在同一个平台上对话了。

A：对的，如果应用本身的代码写得不好，不论在开发环境和运维环境都会造成应用消耗大的问题。使用 DevOps 这样的流水线，一个方面就是解决环境异构的问题。好比我是一个开发者，我在 Windows 里面开发，Java 用的是 1.5。但是在生产环境中，APP 服务器用的是 Linux，Java 是 1.6，那这样可能会引起功能性的问题。

Q：您好，有些传统应用比较难拆分，上云的话难免会把容器做虚拟机用，请问在这一块有好的实践么？

A：传统应用拆分确实是个难题，从可用性和性能方面考虑把传统应用放到容器当作虚拟机跑是可以的。这种场景实现了硬件的资源的高利用率，但是由于传统应用的紧耦合，很难以利用到容器的灵活迁移和弹性部署。而且需要关心的是，传统应用放到容器里面跑，数据保护这方面到底如何去做。目前我这边没有很好的实践方案，而且这种案例确实是国内整个 Docker 界需要面临的一个问题。

Q：虚机或容器，传统双机节点模式部署，出问题通过双机切换主备应用还有意义么？

A：有，双机热备或互备的方案是在传统 IT 环境中经历了时间的考验的。容器的出现并不是要颠覆以前的所有，而是让客户的应用场景拥有一个多的选择。

Q：目前容器化的都是应用 APP 之类的，可以使用容器化一个类 Unix 系统么？比如容器化一个苹果系统能实现么？

A：容器的定位就是在于 APP 的封装，就算有 CentOS 这样的镜像也只是为了拉取运行应用需要的 Bin 文件和 Lib 文件。你这个问题有点是想把容器当作虚拟机跑了，可以去了解一下 RancherVM 或 HyperContainer，或许能够满足你的需求。

---

2016-06-14：传统企业 PaaS 平台功能设计与业务上云思考

Q：在你的新一代 PaaS 平台中，我怎么对公司的很多个不同的应用做不同的集群，有些集群偏向于大量的 IO 占用，有些集群偏向于大量的网络占用，有些集群偏向于大量的内存占用，并且启用的集群间还有通信和交互，针对这些不均衡现象该如何处理？

A：所以 PaaS 平台硬件资源会针对不同应用去做区分，在企业私有云建设时，需要对应用进行梳理，将不同的应用分类，底层采取相应集群支撑，比如计算密集型、IO 密集型等，同时综合考虑波峰波谷与业务特性进行配置。

Q：公司有很多 Web 系统，每一个 Web 系统都有自己的存储、数据库，所以如果融入 PaaS 平台的话，首先第一点软硬件问题如何做到全部满足，其次就是就算把我的 DB 层整合迁徙到你的 PaaS 的 DB 层，我是不是还要做其它方面的投入，比如开发成本等等，还有就是 DB 的兼容性是不是会有问题？

A：Web 层我们推荐做无状态化，且要做应用与数据分离，session 信息集中存放。DB 迁移到 PaaS 层是一个比较慎重的过程，PaaS 层优先考虑开源数据库。如果原先是 MySQL 基于 PaaS 平台也提供的 MySQL 数据库服务，那么开发成本基本比较小，只需考虑版本问题。

Q：后面的 OLAP 主要的作用是数据整合和存储与分析，但是首先要解决的就是各个应用的数据不一致问题，还有就是数据中又分业务数据和非业务数据，这些问题是各个应用的团队自己解决吗？该怎么解决？

A：数据仓库大数据平台中数据不一致的问题由 ETL+ 数据建模来解决，应用团队要参与一起进行数据分析与建模。

Q：请问 MySQL 部署数据应用能承载多大数据量，响应速度如何？

A：我们一个项目中，采用读写分离的 MySQL 架构，几千万的数据表，及时查询没问题，这也要看硬件配置与数据索引的建立等。

Q：有些传统公司，有些软件设备是以序列号安装使用的，所以这一块融入 PaaS 平台是不是不太可能？

A：比较困难，另外还有一个问题是 License 限制的问题，在弹性架构中也比较难。

Q：讲 session 集中到 Redis，是需要做代码层面的修改吗？

A：要修改，每次 session 的操作都要到 Redis 中增删改。

Q：请问架构改造会不会导致应用要重新开发？

A：会，从 IOE 架构到 x86 架构，从 x86 物理机到虚拟机到 Docker，应用需要以越来越小的模块化分布式部署，也就是说逐步向微服务化过渡。

Q：为什么 Kubernetes 和 Mesos 要一起用呢，考虑点在哪里？

A：针对单个应用 Docker 化，我们开始的选型定位在 Kubernetes，主要考虑了 POD 的应用场景更类似虚拟机，另外 Kubernetes 的模块比较丰富，像负载均衡、服务发现等已经成熟，后来用 Mesos 是因为需要把大数据之类的应用进行整合。需要 Kubernetes/Spark on Mesos。

Q：分处于不同子网的容器和虚拟机之间三层网络通信如何解决的？中间还走传统三层交换机？

A：三层网络之间的互通还是走三层交换机。二层组网我们基于 OVS+VXLAN。

Q：开发周期过长或者客户开发能力弱会导致整个架构流产有配套的应用改造方案吗？

A：对传统企业而言，一开始就搭建一个大而全 PaaS 方案是不现实的，我们推荐从某一个典型应用做起。我们针对交易性应用、分布式应用、批处理应用等应用都有配套改造方案。

Q：另外大量采用开源工具 如何解决 版本升级及后期维护？

A：一般会跟应用的代码配套做版本升级与维护。

Q：Mesos 使用集中式存储和分布式存储效率上有什么不同吗？

A：这个看应用，集中式存储在集群中应用时，如果针对单一与应用划分 Volume，性能会好一些，如果是分布式应用，比如 MR 类的应用，分布式存储反而会好。

Q：容器弹性伸缩策略具体怎么考虑的，CPU？

A：CPU、内存、IO、用户连接数等都可以作为弹性伸缩的策略依据。

以上内容根据 2016 年 6 月 14 日晚微信群分享内容整理。分享人**牛继宾，曾任 VMware 研发中心研发工程师，IBM 实验室服务部高级技术专家，目前在天云软件（北京天云融创软件技术有限公司）担任技术总监。擅长云计算与大数据相关技术，除了底层平台技术，对云计算解决 IT 应用系统的实际问题、应用的分布式改造、业务支撑等也有丰富的经验。

---

2016-05-31：站在运维的角度讲如何打造一个 Docker-Mesos 平台

Q：您好，请问一下你们的监控采用的是什么方案？发现”变慢”后的动作是自动的还是需要人工介入的呢？

A：1、我们 PaaS 上的 SaaS 业务的框架，由平台部统一提供，框架本身集成了健康检查（存活状态，响应时间）；2、运维开发小组会针对于这些有一套监控；3、另外针对于变慢，我们有 Zabbix、日志收集、trace 系统统一来做数据展示、分析、比对报警。

Q：请问，你们环境的存储用的是本机存储还是分布式存储？

A：由于我们的业务直接走的 RDS，存在本地的只有日志，我们的日志是挂载本地，规范了存放的格式，统一收走来做日志分析、trace 问题排查系统等。

Q：请问 Docker 你们是如何做鉴权的？即控制哪些人可以使用 Docker Registry 哪些又可执行 push 等操作？怎么实现的？谢谢！

A：1、首先鉴权分为业务层和 PaaS 层，业务层我们配套了框架及 API GATEWAY/认证系统等来做业务上的鉴权；2、Docker 层的我们这里做的比较简单：我们的 Registry 只做了简单的鉴权，由于我们只为内网服务，所以 otheruser 都具有 pull 权限，我们的 push 操作只有单独的几台机器、操作人员可以通过 Jenkins 操作（这里我们做了封装开发）。

Q：可以讲讲在 CentOS 7 跑 Java 的时候，对 JRE 和 JDK 做了哪些修改吗？跑 Java 应用按理说 JRE 就够用了么？

A：理论上 JRE 就够了，但是不排除一些其他需要 javac 等的嘛 O(∩_∩)O~；另外修改的最重要的算是内存细分的限制了（看业务要求，我们对单个容器使用的内存严格限制），以及一些第三方的 APM 性能监控插件。

Q：对于 Java 应用，如何设置 DataSource？我的意思的测试环境和生产，如果用同一个 image？

A：针对于不同的环境，我们在用封装过的 Jenkins 来打相应的镜像，也就是不同环境的镜像在 build 的时候的操作，其实不一样。针对于环境信息的配置放在 etcd 中。

Q：请问整个项目中的大概成本比例呢？如何定义各种成本？

A：这点比较难说，看公司的态度吧，比如百度和腾讯对于新技术的投入比例就远远不同。

Q：请问，使用 host 模式，你们目前怎么实现对端口的分配控制？

A：端口是由 Marathon 随机分配的，不过可以针对端口段来做控制。一个机器可以开几千个端口，但是容器就开不了那么多啦。

以上内容根据 2016 年 5 月 31 日晚微信群分享内容整理。分享人**陈延宗，杭州数云运维工程师，工作内容比较多、杂：Docker/基础服务/SRE 等等。

---

2016-05-30：虚拟化老兵介绍虚拟化技术

Q：虚机迁移是否有涉及？不论是负载触发还是容灾触发或者业务逻辑触发。

A：负载触发的有 DRS，省电模式。基本考虑是负载高时往低负载上迁移，省电模式则正好相反，把虚拟机集中起来，关闭那些不需要的虚拟机。

Q：KVM 的 Host 内核参数开启 IP 转发作用是啥，如果使用的是桥接网络是否一样需要开启？

A：一般情况下都是需要开启的，如果物理机需要给虚拟机网络通信的话。

Q：容器化取代虚拟化真的只是时间问题吗？

A：虚拟化技术源于以 CPU 为核心的硬件能力溢出，一虚多也绰绰有余。带来的结果：1.降低 x86 硬件平台的差异性，VM 随便漂移；2.可统一管理池化后的资源，提高管理性和利用效率；3.不同 guest os 的 vm 可同时运行在同一个主机里；4.各层级，各种类软件近乎零成本往上迁移。 所以，短期未来更有可能的是：虚拟化与容器各负责自己擅长的部分，由于更容易与现有世界”兼容”，虚拟化占的市场份额可能会更大。长期未来，当统一的世界什么都提供时，哪里都可运行时，虚拟化，容器，你，我可能都已不存在。

Q：后面讲到的 Docker 具体 Ceph 的高可用和迁移，是已经实现了，还是只是一个设想？

A：设想，原计划这么去做，但有其他优先级的事情就没做了。

Q：请问桌面虚拟化有什么痛点，或者难点么？

A：业务上的疼点： 2）协议的分析，研究，以及改进。

Q：KVM 虚拟化中 Linux 内核的两个模块 kvm 和 kvm_intel 具体起到什么作用？

A：我有段时间没有摸具体的代码了，kvm 和 kvm_intel 组合在一起完成 KVM 内核相关的工作。

---

2016-05-19：容器的配置管理

Q：有两个问题，基础镜像的继承管理和如何处理多个技术栈的应用版本。举个例子，我们对于 CentOS 7，做了公司级别的基础 OS 镜像 A，基于这个镜像加入了 JDK 成为镜像 B，基于 B 加入了 JBOSS 成为 C，在 C 的基础上再构建项目的 APP 镜像 D。问题来了 1，有没有办法针对 A 镜像修改了，B，C 和 D 去级连更新。2，由于是继承关系，各层软件的版本不同，导致镜像种类就特别多，例如 JDK 有 3 种，jboss 有三种，那么镜像 C 就有九种，技术栈深了，命名又成为了问题。求指导解决思路？

A：镜像如果涉及到继承，需要通过 Jenkins 之类的工具实现链式自动构建。 Jenkins 中的任务可以设置触发条件，在某个任务完成后自动触发本任务。依赖关系可以在 Jenkins 的 Jobs 里面定义清楚。 镜像命名问题，可以用镜像名 +tag 的方式，如：tomcat:8-jre-7

Q：我有个问题。现在这个平台只是 Web 服务级的 PaaS 平台么？

A：cSphere 目前除支持 Web 服务外，还支持任意复杂度的企业级应用。可以实现多个相互关联的服务的一键快速部署和环境 Clone。

Q：有没有打算开源你们这套容器的配置管理系统？

A：目前我们有企业版和免费版。其中免费版可以根据我们官方网站上的文档自己安装部署。开源方面我们主要以向 Docker 的开源项目中贡献代码为主。

Q：这里 Agent 能否理解成通过伙伴进程的方式来实现的配置管理？那是否连带有服务发现的功能？

A：这里的 Agent 就是 cSphere 在每台主机上的 Agent，该 Agent 与控制器协同处理所有管理工作，包括配置引擎。配置引擎本身支持应用、服务、容器、节点四种对象的发现，不仅仅是服务发现。

Q：请问据你所知其他类似平台如何解决刚刚提到的配置问题呢？

A：据我所知，包括 Docker 官方产品在内的一些产品还是主要以修改配置后重启容器或者通过-v 参数映射配置文件的方法解决。这样做主要问题是配置文件的更新与容器的生命周期联动不起来

Q：请问嘉宾，你们这个配置管理系统是自己完全独立开发的，还是借鉴了哪个开源项目？

A：配置管理系统完全是我们自己独立开发的。配置管理的 Agent 除负责配置管理外，还负责控制器与各主机上的 Docker Daemon 的通信、监控数据采集等工作。

Q：能否详细讲解下 Agent 如何装载配置文件的

A：Docker 1.9 为了支持所谓的”完全客户端镜像构建”能力，为 docker cp 命令添加了向容器传文件的 API。我们通过这种机制把配置文件”装”到容器里

Q：Create -> 下发配置 Start 这样确保容器启动之前已经加载了正确的配置文件。这一步的下发配置是怎么做的，因为那个时候容器还没启动？

A：向容器里 copy 文件并不需要容器处于运行状态，只要容器存在就能 copy。

Q：支持批量部署上百台服务吗？自定义部署到不同的环境。

A：cSphere 的配置引擎，支持批量下发，可以选择某个服务或多个服务，也可以针对个别容器做灰度下发，同时支持上千容器没有问题。另外针对不同环境部署，可以通过配置模版化能力，解决环境之间的微小差异，既可以通过用户定义变量，也可以通过类似发现的技术自动计算出对应参数，比如 MySQL InnoDB 的 Buffer 需要根据内存做一个公式计算。

Q：请问 Agent 在发现新的配置后，针对不同容器是执行不同命令是怎么管理的？执行的命令和容器中应用运行状态有关系吗？

A：在配置文件下发后执行的命令是与容器所属的应用关联的，要执行的命令并不是配置文件的一个属性。比如：某个配置文件同时在 A 应用和 B 应用里都用到，可以配置为在 A 应用下发后执行 restart container，同时在 B 应用中下发后什么也不干

Q：cSphere 是企业 PaaS 平台，请问 Agent 程序是否开源？如果不是企业在自己的机器上安装闭源程序会不会有担忧。

A：我们的客户没有过这方面担忧。首先客户基本都是内网。其次客户在过去大量使用 vSphere，同样没有这样的担心。客户关心的是你的产品是否能解决自己的实际问题。

以上内容根据 2016 年 5 月 19 日晚微信群分享内容整理。分享人

魏世江，云栈科技（希云 cSphere）技术负责人，Docker 代码贡献者，目前在 Docker 开源项目中代码贡献量全球排名 50 名左右。创业之前在新浪负责 PasS 平台（SAE）的各种基于 Web 的服务管理系统的设计及开发，全程参与了 SAE 从无到有、从 3 台虚拟机到后来支撑 30 多万应用和十几亿日 PV（13 年数据）的整个过程，在 PaaS 建设及 DevOps 方面积累了丰富的经验。2013 年底离开新浪，与前 SAE 总监王利俊先生一起创立了云栈科技，主要做基于 Docker 的企业级私有 PaaS 产品（cSphere）及容器相关解决方案。

---

2016-05-10：基于 Docker 的分布式服务研发实践

Q：用 Jenkins 持续集成过程中，如何对项目进行测试？

A：在 jenkins 中进行测试，一般主要是已 unit test 为主，除此之外，可以自己写测试脚本进行测试。

Q：研发采用 IDE 远程调试这个地方我不是很清楚细节可否详细讲讲？

A：我们使用的 Web 容器为 Tomcat，你只需在 Tomcat 中开启远程调试端口，在 IDE 中进行配置即可。

Q：我们不采用 Marathon 和 Swarm 的原因是什么？

A：Swarm 目前还不成熟，还在发展中，功能相对弱一些。Marathon 的话还是看使用场景，如果还要跑例如 Hadoop 的话可以选择。如果是纯容器，建议 Kubernetes。

Q：问下开发使用的目录挂载到容器是在宿主机还是共享存储上开辟存储空间，能否做到针对每个用户存储空间容量限制？

A：开发使用的宿主机在办公云中，使用的存储是宿主机的本地存储。

Q：测试和研发数据库用的是同样的一套吗？如果数据不一致，怎么处理呢？

A：测试和研发使用的环境是一致的，包括使用的数据库脚本也一致，如果出现对同一个计算资源操作产生不同的数据，那就需要研发和测试一起来定位。采用同一套环境的一个好处是让研发不再有借口：”我的环境是好的，我本地无法复现”！

---

2016-05-03：基于 Docker、Mesos、Ceph 全新技术栈的三地三中心容灾体系之大二层网络

Q：请教下 Overlay 性能和稳定性如何，适合大规模生产应用吗？你是全部的 Overlay 吗？

A：我接触的思科 ACI 是可以实现在大规模生产应用的，在整个方案中使用的全部是 Overlay 网络。

Q：请问，你所说的 Swarm 发布的网卡，是物理网卡还是虚拟网卡？

A：不是 Swarm 发布的，是 Docker1.9 的一个新的网卡特性，在 Docker 里面使用 docker network -help 可以看到。

Q：请问 Overlay 使用的是物理交换机还是虚拟交换机？

A：在本方案中使用的是物理交换机，VTEP 是部署在 leaf 层的物理交换机上的。当然也可以使用 OVS 来作为 VTEP，不过这样在性能和稳定性不如物理交换机。

Q：请问通过 Docker Network 创建的网桥怎样可以让 OVS 发现并控制？

A：当 Docker Network 为容器创建新的网卡接口后，通过脚本自动的挂载到 OVS 的网桥上。对网络的管理是是在更宏观的层面进行的，换句话说实在调度框架层面进行的，调度框架会根据自己的需求将需要的网络配置发给 APIC，APIC 会下发相应的网络配置策略。

以上内容根据 2016 年 5 月 3 日晚微信群分享内容整理。分享人赵英俊，来自城云科技企业云事业部，从事云计算大数据云存储的项目咨询和管理工作。

---

2016-04-28：Docker 容器对存储的定义（Volume 与 Volume Plugin）

Q：Kubernetes 中是否有 Volume 的处理模块，或者说 Volume 的重要性，以及前面提到的各种操作，在 Kubernetes 中是怎么体现的？

A：Kubernetes 借助 Docker Volume 实现一套自己的 volume 管理机制。Kubernetes 的相关问题下一次再详细说明。

Q：请教下现在分布式存储很多，Ceph、CFS 等，哪个性能更好，更稳定，适合上生产？

A： Ceph、Glusterfs 都有上生产环境成功的案例。 就运维成本来说 Gluster 更加简单点。Ceph 的运维成本较高。稳定性上 Gluster 因为设计更简单，所以社区版本就已经稳定了。

Q：Docker Volume 和 Kubernetes volume/persistent volume 比较，有什么异同？

A：Kubernetes 借助 Docker Volume 实现一套自己的 Volume 管理机制。

Q：应用日志管理收集是否适用 Volume？有没有什么注意的地方？推荐的共享方式？不同应用是否-v 到不同的地方？

A：容器如果需要持久的数据，使用 Volume 挂在到目标存储上。注意日志太多对系统资源的占用。

Q：想问下有没有类似测试过，或者说你现在觉得性能比较好的一些方案？有没有测试用例级数据？

A：存储的性能是与实际的应用是相关联的。我们开发适合容器的存储。

Q：一个存储盘能共享挂载到多个容器吗？

A：看后端存储类型，如 NFS、Glusterfs 是支持存储盘能共享挂载多个容器。

Q：Rancher 刚出，不知道它这个 Convoy 能单独用么，比如说安装在 Ubuntu？

A： Convoy 与 Rancher 是独立的，可以独立安装在 Ubuntu。

Q：请问有什么静态资源共享数据的方案，例如 Web 图片？

A：OpenStack Swift、GlusterFS 都可以。

Q：Convoy 或 Flocker 能支持 rbd 么？

A：原生的 Convoy 目前不支持 rbd。现在我们做 Convoy 支持 rbd 的功能。

Q：不同主机上的容器能同时挂到一个共享存储上吗，最多能支持多少个？

A：共享存储支持就可以，NFS、Glusterfs 都可以支持。

Q：Kubernetes 和 Docker Swarm 两个更看好谁，如果只能选一个的话？

A：看具体的应用场景，Kubernetes 会越来越稳定。Swarm 对容器的支持会越来越好。

以上内容根据 2016 年 4 月 28 日晚微信群分享内容整理。分享人**江松，有容云联合创始人兼研发副总裁。拥有 16 年的国内外企业级软件基础架构研发经验，在企业级存储，云计算解决方案方面有很深的技术造诣和行业理解。曾任美国 AITechLtd、爱尔兰 Raidtec Ltd 高级系统架构师，存锋科技 Storwind 创始人兼 CEO。

---

2016-04-26：Kubernetes 代码贡献者谈 Kubernetes 的发展动态

Q：谢谢分享 Scheduler 的演进，想问一下 planning 的问题，针对 multiple scheduler 和 rescheduler，是谁在主导，有时间线吗？浙大会参与设计和开发吗？

A：据我所知，目前 design 和 implementation 都是由 Google 主导，国内主要是华为的团队在参与开发，网易也有人力投入，当然极有可能存在一些我不知道的团队。Timeline 上 Multiple Scheduler 已经完成了接口，但是有不少细节的工作还没有完成。Rescheduler 还在 design 阶段。据我所知，浙大的确有感兴趣的同学在做相关的内容，但是我不确定有没有向社区贡献 code 的计划。

Q：这些讨论一般都集中在哪些地方？是公开的吗？

A：大多数在 GitHub 上可以 trace 到，当然也有 weekly sig 视频会议和 offline discussion。如果是个人开发者的话，可以在 GitHub 上的 issue/pr 里 comment 或者直接提交 pr 参与开发。

Q：Kubernetes 目前表现的比较好的托管方式是容器安装吗？还有 CoreOS 官方给了这么多选择不知道选什么好。

A：definitely not。容器安装是一个快速的 solution，但是可能会有很多 bug。CoreOS 应该是一个支撑性非常高的平台。我本人是 Ubuntu 平台的 maintainer 之一，如果希望 play with ubuntu 的同学，也可以尝试一下。

Q：未来 horizontal pod autoscaling 将不仅仅是依据 CPU，还会有更多的指标。请问如何处理可能的矛盾。如 CPU 超载指示扩容，而 memory 可能使用低而指示减少容器数量？

A：这是一个策略问题。对应的解决方案无疑会牺牲其中一个，Kubernetes 是否允许用户来指定这个 priority 也还值得讨论。但是就目前看来用户还不需要过分担心，毕竟它还没有实现。

Q：还是那个老问题，在企业环境下 Kubernetes 和 Mesos 哪个更可取？

A：如果一定用事实说话的话，当前 Mesos 在企业中的 use case 无疑比 Kubernetes 要多。作为一个两级调度框架，Mesos 的完备性相当高。但是我个人并不认为 Kubernetes 就相对不适用于企业环境。毕竟在选取 solution 的时候，需要考量的实际因素很多。

Q：其实去年开年的时候玩过 Kubernetes，然后是因为网络部分的限制导致选择了 Mesos，想问下容器网络这部分 Kubernetes 你觉得最成熟的方案是哪一种？

A：我自己只玩过 Flannel（包括 UDP 和 VXLAN），但是它在效率上可能并不是非常好，VXLAN 相对来说要好一些。我所知道的方案中，Calico 应该做得还不错。您也可以尝试一下 OpenVSwitch。

Q：Rancher 除支持自己的编排方案 cattle 以外，也支持 Kubernetes 和 Docker Swarm。想听听你的建议，是否可以采用 Rancher+Kubernetes 这样的方案？谢谢

A：非常抱歉没有使用 Rancher 的经历。但是就大多数我所知道的 cross-platform solution 而言，通常都出于生产环境中具体的需求。比如我现在实习的公司的 AP 组就自己写了 docker-on-yarn。在 solution 的选取上很难脱离需求来进行评断。

Q：现在所有调度规则都是集中在 master 控制分发，Kunernetes 可不可以在 node 上面添加像 mesos role 的概念？

A：调度器的演化经历了很长时间的发展，各有千秋。Kunernetes 选用的单体调度器，而 Mesos 是两极调度框架，本质上还是有相当大的 gap 的。当然现在也有 Kunernetes 和 Mesos 的集成，有兴趣的同学也可以尝试一下。

以上内容根据 2016 年 4 月 26 日晚微信群分享内容整理。分享人何思玫，浙江大学 SEL 实验室研究生，Kubernetes、Docker 等容器相关开源项目的代码贡献者。

---

2016-04-19：阿里云容器服务设计实践

Q：针对容器跨主机通讯采用 vSwitch 和 vRouter，那么容器和 VM 应用通讯也是采用此方法吗？vRouter 规模如何？

A：在前面说的 VPC 实现中，容器和 VM 是可以直接通信的。VPC 目前的 vRouter 支持 50 个条目，也就是最多 50 个网段。

Q：各种扩展和 Plugin 有开源吗？

A：未来我们会开源安装在用户机器上 Agent 和 Plugin 代码，目前还有一些知识产权工作需要解决。

Q：Registry 的 HA 方案能否介绍下？

A：我们开发过 Registry 的 OSS storage driver，已经提交到社区。后端使用 OSS 存储，直接启多台 Registry，挂一个 vip 就好了。

Q：想问下阿里的支持混合云吗？宿主机是不是要求一定是阿里的 ECS？

A：目前主要支持阿里云环境和专有云。对于宿主机在外面的，也可以通过 VPC 的方式接入。

Q：跟 Docker hub 兼容有哪些方面，hook 功能是怎么实现的？

A：支持仓库管理、自动构建、加速器等功能。hook 方面是通过 Registry 的 Notify 实现的。

Q：镜像对分发到多个 Registry 吗？

A：OSS 本身可以保证数据的高可用。对于 Registry，重点在于 Pull/Push 速度，我们在会每个 Region 都部署 Registry，尽可能提供最好的用户体验。

Q：Docker 服务本身的升级，怎么解决的，需要用户停止线上容器吗？

A：目前我们支持的社区版本 1.10 需要重启容器，用户可以自己选择合适的时间升级。对于阿里内部我们同事修改过的 alidocker 是无需重启的。当然，随着 1.11 的 Docker 重构，未来社区版本也不再是单点失效点。

以上内容根据 2016 年 4 月 19 日晚微信群分享内容整理。分享人姜继忠，花名戒空，阿里云技术专家，一直专注于云服务和 PaaS 平台相关的架构和开发工作，目前负责阿里云容器服务的架构和开发。

---

2016-04-12：双模 IT 给你的企业装上双引擎

Q：双模模式和 DevOps 以及目前流行的 Docker 容器有什么关系吗？

A：首先双模模式是一个管理理念，它指导 IT 部门采用的组织架构、制度、人员技能，以及技术。如前所说，DevOps 和 Docker 技术优势可以更有效推动企业提升业务创新能力，因此在我见到的金融企业中普遍应用到了信用卡、互联网金融等 2C 端的业务。

Q：这个双模模式和目前常用的敏捷开发，CMMI 开发在操作上，产品质量保证上，开发迭代，效率上有哪些不同？或者说有哪些优势？以及如何和这些开发流程协作？

A：大家可能以往比较关注技术，较少关注管理体系方面的内容。双模 IT 管理更多侧重在管理体系，它指导 IT 部门采用的组织架构、制度、人员技能，以及技术。CMMI 采用了传统的瀑布模型，这种方式适合在明确需求的前提下稳步推进工作。但由于当前市场环境十分不确定，需求的不确定性是创新的最大挑战，因此演化出一种持续迭代的开发方法，这也是 DevOps 强调持续反馈的原因。

Q：怎么理解 ITIL V3 的服务驱动？

A：相比 V2，ITIL V3 尝试从服务战略、服务设计、服务转换、服务运行、服务持续改进五个方面阐述服务生命周期，一个比较明显的特点就是重点强化了服务目录，并从服务目录出发将服务交付、事件、问题、变更、容量管理等流程串联在一起。

Q：客户在碰到类似的管理产品时，通常很畏惧，不仅收效甚微，还可能要改造现有流程，反而增加他们的工作量，后续更是增大管理成本，如何说服他们？

A：双模 IT 首先是一个管理理念，然后基于这种理念演变成管理最佳实践、管理方法和管理标准。其次，管理重点要解决的是人、财、物，如何最大化协调三者，使得企业效益最大化，提升 IT 效率才是关键，所以我们在推进一个新方法的时候关键要说明白好处已经风险，让管理者有一个全面了解。在实际的推进过程中，最常用的方法是培训理念导入，让企业内部关键人员说一种语言，统一思想，但最近几年一个明显的变化是我们可以采用一种技术驱动的模式将管理理念通过平台落地。

以上内容根据 2016 年 4 月 12 日晚微信群分享内容整理。分享人**张亮，上海翰纬信息科技有限公司技术总监兼合伙人。IT 从业经验 14 年以上，先后从事开发、架构、项目管理、技术管理等岗位，曾就职于 IBM，在大型企业数据中心运维方面，积累了超过 10 年的架构和规划管理经验，先后为五大行、农商行等金融机构提供数据中心运维管理规划和管理平台落地咨询及实施服务。热爱开源技术，现专注于 OpenStack、Docker、Cloudify、Apache Kylin 等开源方案在传统企业的落地。

2016-04-05：搜狐基于 Docker+Kubernetes 的一站式运维管理实践

Q：”可以在 Pod 中配置一个或多个日志收集模块，该部分用 Flume 实现”这块能具体说下吗？

A：我们把 Flume 做成了一个镜像，利用 Kubernetes 的 Empty Directories 来收集其他容器产生的日志。

Q：我想问下容器内监控是怎么实现的？每个容器安装 open-falcon 的 Agent 吗？

A：每个 Node 上会启动一个 Agent，通过 Agent 收集主机和容器的信息，Agent 集成了 open-falcon 的 Agent 和 cAdvisor。

Q：自动化构建过程中，对应用的测试是怎么实现的？

A：单元测试可以在编译的时候完成，功能测试需要启动部署。

Q：你们的部署环境是同时使用了 overlay 模式和 host 模式吗，对于预防潜在的冲突你们有什么好的建议？

A：我们主要对端口冲突做了严格限制，host 模式下提供了自动寻找 20000~21000 段可用端口的插件，overlay 模式会根据数据库中配置检测冲突。

Q：使用 Kubernetes 编排容器后，你们怎么做服务发现的？如何解决容器间互相调用问题，及容器外调容器内服务问题？

A：我们用 skyDNS 做服务发现，容器间相互调用可以用内部域名，Kubernetes 集群内的主机通过修改 DNS 服务器配置也可以通过内部域名访问容器。

Q：项目有什么瓶颈吗？

A：Kubernetes 的部署比较复杂，我们做的是私有云下的管理，不同系统下部署会有各种各样的问题。

Q：刚刚提到 WebSSH 在 Agent 里封装了 docker exec，当在 master 执行某容器的命令时，具体是如何控制 Node 节点执行 docker exec 的，Agent 封装是自己开发的吗，还是借用一些第三方工具，Kubernetes 好像也有 kubectl exec？

A：WebSSH 有 Server 端和 Agent 端，Agent 在每个 Node 节点上，Server 只要一个就够了。kubectl 也可以 exec，不过采用的是 Kubernetes 自定义的连接协议，性能也不如我们目前采用的方案。

以上内容由李世龙根据 2016 年 4 月 5 日晚微信群分享内容整理。分享人**刘菲，搜狐北京研发中心副研究员，主要负责 DomeOS 系统的设计研发工作。致力于研究 Docker 为代表的容器技术，为企业级用户打造持续交付和自动运维平台，解决用户从代码自动编译打包，到线上运行维护的全套需求。

---

2016-03-31：DCOS 中监控和弹性伸缩方案经验分享

Q：CPU 占用率，内存占用率这些指标为啥要改 cAdvisor 的代码实现？既然使用了 Grafana 的话，Grafana 本身就有对数据二次加工的能力，比如 CPU 利用率可以直接通过 cAdvisor 发送的 cpuacct，usage 的数据做 Derivatives 就能取到 CPU 的利用率了。不知道这块你们是基于什么考虑在 cadvisor 里去提前算了？

A：首先，我们并没有使用 Grafana；其次你说的不错，CPU 只是打了一个比方，其实我们计算更多的是网络传输的一些数据，比如收发报的数量，大小，这些都是在我们公司 NFV 的业务比较常见，这里给大家分享的主要目的是，可以通过 cAdvisor 做一些定制化的开发。 我们用 cAdvisor 的目的主要是 统一信息的收集，并不想用多个监控工具，这样会有点复杂。

Q：请问，每个 Prmetheus 会管理 10 个 Mesos-Slave+cAdvisor 的节点信息，抓取频率是 1s，如何保证在规定时间间隔搜集完所有监控信息，即如何保证监控指标是实时有效的呢？

A：这个结果其实是我们经过反复测量得出来的，是有前提，就是我说的每个 Slave 的大小其实是有限制的，我们的每个 Slave 在 8 CPU， 16G 内存，这样保证了运行的容器数量是有限制的。我觉得如果容器过多，那么管理 10 个节点可能就不适合，抓取频率也需要调整。 目前官方没有给出 Best Pactice，我们也是经验之谈。 测试下来，我们的配置 基本上没有出现丢失信息的情况。

Q：想问下嘉宾：1、DCOS 这套环境是用的社区版？2、方便透露下集群规模么？

A：DCOS 的这套环境是我们公司研发的， 但是我们公司和 Mesosphere 的 Open DCOS 是合作伙伴，这个消息近期就会宣布。目前我们环境规模是 50 个 mesos-slave 左右。

Q：请问这个系统本身消耗好资源多少？例如采集 CPU 用 top 命令，top 本身是消耗很多资源。

A：目前在我们的环境实测下来，cAdvisor 的 CPU 占用率在 1~5%； 如果容器非常拥挤的情况下，开销会在 10% 一下，我们的 cAdvisor 是用 Marathon 启动的，配置的 CPU 是 0.1。

Q：请问每次新增监控纬度时，是否需要同时修改 cAdvisor 和 Prometheus，如何保证通用化？是否考虑过其他的容器监控方案，比如通过 FUSE 在用户态统计，兼容历史的监控工具？

A：是的， 是需要修改 cAdvisor 和 Prometheus， 这一点也是相对来说比较头疼的部分，我们的主要是通过 2 方面来做的，第一方面是抽象服务模型来做的，让不同的服务模型的共同部分可以共享我们的监控指标和告警规则。第二是利用灰度升级的方式，对 cAdvisor 和 Prometheus 来进行升级，尽量保证服务监控的不中断。正如我说的，提前的规划非常重要。其他方案也有所考虑，但是使用下来还是觉得 cAdvisor 和 Prometheus 更加适合自动弹性伸缩。

---

2016-03-29：基于 Docker、Mesos、Ceph 全新技术栈的三地三中心容灾体系

Q：您这个框架中使用的 PaaS 执行框架具体是什么？

A：这个是开放的，可以是马拉松也可以 Kubernetes，这个都没有具体的限定的。因为我觉得这两个都是比较好的执行框架。

Q：Docker 的兴起是否会影响 OpenStack 云计算的地位会和 OpenStack 竞争，共存？OpenStack 工程师如何面对 Docker 技术的兴起？Unikernel 发展趋势能否取代 Docker？

A：竞争肯定是有的，但是共存也是存在的，我认为这是一个灰度的。我觉得 OpenStack 工程师要拥抱 Docker，其实我的主要工作就是向客户设计基于 OpenStack 的私有云解决方案。Unikernel 技术的对手不是 Docker，是容器。具体是否会取代，我觉得不一定。

Q：Vxlan 具体怎么实现？是核心交换机旁挂大二层设备吗？另外超远距离，比如北京上海这么做会有什么问题？我们现在遇到延迟问题比较大。

A：VxLan 的实现在 Vswitch 中通过对每次 TCP 包的 UDP 封装，Vswitch 是在每个宿主机上的。北京到上海的话，就需要通过光纤中继，这会损耗一定的传输带宽，这么远距离的传输只能等待光传输技术的发展以及在应用层面进行弥补。不过在应用层去弥补这不是很好的方案。

Q：ZK 集群的部署是怎样？有做哪些调优么？另外网络方面有做哪些监控么？

A：主要是根据实际的请求时延对 TIMEOUT 进行修改，网络方面的监控是通过专业的安全设备进行。

Q： 那个数据中心部署 3 机 Mesosmaster，所有数据中心共享一个 ZK 集群，难道这个 ZK 集群如何在多数据中心部署，还有因为网络延时导致 slave 掉了后，或者 executor 挂了后怎么处理孤儿容器。

A：ZK 是每台 Master 节点上的，由于使用了大二层网络，所以所有的 ZK 就相当于在同一个局域网内部署的。对于孤儿容器，是 Kill 掉然后替换的。

Q：请问在你们设计的方案中通常建议用户租用几条裸纤来实现三地三中心，同时考虑过租用长距离裸纤给用户带来的长期运维成本吗？

A：恩，这是个好问题，我在准备这次分享的时候也在考虑这个问题。这个设计方案的前提是客户有这样的需求，需要支付这样的成本去实现。从技术的角度，双纤是性能与经济性的平衡点。

Q：请问关于事务处理的负载轮询，如果使用长连接，如何保证每个连接负载是均匀的，同时这里的事务是指存储层的还是应用层的，如果是应用层是如何保证事务的？

A：这个确实比较难，可以采用类似于一致性哈希环的思想，就是尽可能多的将轮询环进行分割，这样长连接就会尽可能的均衡分配。负载轮询是在应用层面进行轮询的。

Q：你们这套架构上生产环境了吗？Ceph 是强一致性的，6 个副本延迟会不会大？六个副本是不是有点浪费存储空间？大规模写入的时候 IO 会不会是瓶颈（Ceph 先写 Journal，再写磁盘）？另外，你们是全 SSD 吗？

A：这套架构没有上生产环境。这是我们公司做的一个前瞻性方案设计研究。在 Ceph 的副本配置中，有一个最小副本数，可以先设置一个最小副本数实现快速的写操作。之所以 6 副本，主要是防止避免过度频繁的数据读切换。在这种方案下，建议全部是 SSD，当然也可以有选择性的使用 SAS。

以上内容根据 2016 年 3 月 29 日晚微信群分享内容整理。分享人**赵英俊，来自城云科技企业云事业部，从事云计算大数据云存储的项目咨询和管理工作。

---

2016-03-22：太保 DCOS 平台——微信项目实践

Q：想问下嘉宾，资源调度层为啥选用了 Mesos 而不是 Kubernetes？Mesos 使用的是开源版本？从项目预研到落地投入的人力是多少（含开发、测试、运维）－方便透露的话？

A：Kubernetes 提供的集成功能较多，可以提供整体的解决方案，但我们有很多内部的应用间调用，最后选定了 HAProxy+Mesos 的方式，而且从前期的评测来看 Mesos 与 Marathon 集成更为稳定。

Q：容器运行 WebLogic 的时候有没有遇到什么坑可以分享一下吗？

A：容器运行 WebLogic 本身没有问题，但如果程序包过大，容器的自动恢复时间会较长，所以建议控制每一程序包的大小。

Q：研究新的软件如 Mesos 这么重量级的产品也是需要很大的时间成本和人力成本的！如何权衡的？

A：主要还是看面对的问题，在微信红包这样的应用场景中传统技术已遇到瓶颈，必须要引入新技术。不过我们很多新技术的研发是前期即进行，进行前期的技术储备。

Q：我们发现，在 Mesos 中，如果主进程先退出，而子进程还在的话，会导致 task 直接返回，而我们的实际应用中有比较复杂的父子进程关系，除了重新梳理一下外，还有什么别的好的做法？

A：应用之间的依赖关系，我们正在着手在 Marathon 调度之前，如 B 应用与 A 应用有依赖关系，则先判断 A 是否启动，A 如果没启动则启动 A 再启动 B，同时，需判断 A 应用启动后是否满足应用服务能力，比如一个容器是否能承受压力。

Q：请问下 Docker 地址如何分配和管理跨主机通讯？

A：地址是有容器平台动态分配，跨主机通讯通过 HAProxy 进行应用间调用。

Q：你们如何做监控的？就是红包活动的时候如何监控当前的服务器性能或者是接口的访问量之类的？

Q：聊一聊为什么使用传统方法 +APM 监控而不使用 cAdvisor、Prometheus、Docker API 来实现？

A：两个问题我一并回答，因为我们 APM 并不是仅使用在容器平台，目前在传统平台也使用，正好上容器平台发现传统监控遇到问题，当时我们做 APM 的 poc 有一段时间，发现 APM 正好可以解决此问题，所以就采用了这种方式。\ 容器平台本身是有性能和可用性监控工具。用 APM 是更好的进行应用的端到端监控。

Q：传统行业转容器一般没那么容易，你们有什么过度方案吗？

A：我们针对无状态的应用、传统应用的容器化都制定了对应的技术方案，帮助研发团队进行应用的容器化迁移。

以上内容根据 2016 年 3 月 22 日晚微信群分享内容整理。分享人**沈大斌，太平洋保险信息技术中心高级经理，目前主要负责 Docker 容器技术在太保集团的落地、推广及优化工作。18 年保险行业 IT 从业经验，专注于应用运维领域。

---

2016-03-15：Kubernetes 集成外部服务实践

Q：请问在举的 MySQL 服务的例子中，讲到不是采用应用与 MySQL 一起打包成容器运行的方式，而是只需要把应用链接 mysql 服务的环境变量注册到 PaaS 平台上面就可以使用 MySQL 的服务了是吗？那么你们平台上面不是运行多个 MySQL 镜像吗？

A：后端服务与 PaaS 在逻辑上是分开的，可能独立运行在平台集群外部，也可能运行在集群里，以 service 的形式服务。所以是否运行多个 MySQL 容器，取决于 servicebroker 的设计实现。每一种 servicebroker 的设计都不必相同。

Q：如果我把 MySQL 环境变量注册到 PaaS 平台后，我应用链接你们平台上面的 MySQL 服务后，如果后期分库分表可以吗？还需要重新配置环境变量信息吗？

A：这个取决于后端服务提供的套餐。不同套餐计划提供不同程度的服务。

Q：1. Kubernetes 自定义扩展具体怎么做的？2.后端服务你弹性伸缩直接用 Kubernetes 自带的，还是有什么改造？

A：1. 扩展 Kubernetes 是我们参考 Kubernetes 的 API server、Controller 这种异步机制直接在 Kubernetes 中增加代码，Kubernetes 在易扩展性上做的挺好。2. 后端服务可以运行在 Kubernetes 集群上，或独立运行，其弹性伸缩由后端服务自身的设计来决定。

Q：请问容器里的环境变量是 Kubernetes 的 BackingService 自动生成的，还是 OpenShift 特有的？是不是可以说因为 Backing Service 会自动在容器里注册环境变量，所以某些场景下使用起来比起直接使用 MongoDB 地址来得方便？

A：是实例在绑定的时候由我们的扩展生成，并更新到 pod 里，不是 OpenShift 特有的。第二个问题的话，确实是这样，多数情况下，用环境变量都会很方便。

Q：Kubernetes 的 Volume，你们是如何使用的，当 pod 发生迁移后，如何保证 Volume 还挂在 pod 上？

A：Kubernetes 本身提供了 persistent volume 功能，并且支持多种存储机制。pod 迁移时，Kubernetes 会维护其对应的 Volume，根据不同的存储，Kubernetes 有不同的调度实现。

Q：现在生产上用什么监控，监控有报警吗，什么粒度的？还有就是日志收集怎么处理有什么成熟的方案吗？

A：我们采用了多种监控机制。主机、容器、和 Kubernetes 服务本身，我们都采取不同的监控策略/工具。至于粒度，也跟监控的对象有关。日志我们用 ELK。

Q：Kubernetes 的部署可否做到跨数据中心吗？如何实现？谢谢。

A：Kubernetes 是分布式的异步系统，理论上是可以跨数据中心的。但考虑到网络环境的复杂性，我们当前还没有作这方面的尝试。

以上内容根据 2016 年 3 月 15 日晚微信群分享内容整理。分享人**柴宗三，资深架构师，10 年的 IT 从业经验，在云计算、大数据方面及大型企业级应用拥有丰富技术架构经验。负责北京亚信智慧数据科技有限公司大数据云平台的架构设计及开发管理。

---

2016-03-04：Docker 在乐视的实践之路

Q：想请问一下这些 Docker 是部署在物理机上还是虚拟机上？在扩容的时候除了增加内存，能增加 CPU 吗？

A：物理机和虚拟机都有，我们提供一键安装 Docker 和其他组件环境的脚本，业务部门单纯执行脚本即可。在扩容方面我们现在只做了内存扩容，CPU 是共享的。

Q：通过镜像的构建脚本是怎么生成镜像的？在基础镜像上执行相关脚本么？一些端口存储卷环境变量这些镜像中的信息是怎么解决的？

A：我们对 Dockerfile 进行了封装，业务和开发人员不需要关心 Dockerfile 语法，直接写一个镜像构建脚本，最后根据一定的规则由 Harbor 生成 Dockerfile，之后调用 docker build 去生成镜像。在这个过程中， 镜像的名称，版本都已经根据规则生成

Q：资源共享的方式，不能是一个部门或者小组增加一个公用账号，把需要分享的资源，push 到公用账号吗？

A：我们没有使用公共账号的方式，我们使用的是镜像仓库的方式，镜像仓库可以有团队成员，达到的效果是一样的。

Q：抛弃 Jenkins 那你们多语言怎么办 Java 编译和 Golang 编译这些？

A：我们不需要关心什么语言，我们现在提供了一个 Java 公用的基础镜像，编译什么的都可以在构建时候完成。 如果需要其他语言，比如 go、Python，可以有业务部门自己创建自己的基础镜像。

Q：Jenkins 配置 jdk 和 maven，是要在容器里自己安装吗？

A：在构建时候，这些环境可以在业务部门基础镜像里，提前安装好。

Q：在构建时候，这些环境可以提前安装好？

A：应用里都有自己的版本概念，每个应用版本里有：镜像版本，环境变量、 export、Volmue 等信息，所以在回退或者升级时候，最终的表现形式就是杀掉旧容器，根据版本的参数创建新容器。

Q：Harbor 和 Jenkins 比起来你们是不是基于后者的实现思路开发的精简版，解决问题的方法和思路变了吗？

A：原因有多个，我们希望 Harbor 能从代码到构建到部署一气呵成，如果用 Jenkins，会给用户已断片的感觉，业务部门一旦业务多的话，有可能会分不清哪个 Git 对应哪个 Jenkins 配置。学习成本也比较高。

Q：你们这样，开发人员的本地环境是不是不需要使用容器了？

A：本地环境一般不需要容器，但是如果开发人员想使用容器玩玩，可以通过我们提供的基础镜像创建一个容器即可。

Q：最近在学习 Magnum 和 Kubernetes。有一些疑问比如 minionA/B 上分别有 serviceA 的 podA/B。那么访问 minionA 的 kube-proxy 是不是也会被导流到 minionB 上的 podB 上？service 的重要部件 proxy 就是起到了个负载均衡和反向代理的作用。这个角色是不是直接可以用 haproxy/nginx 这样的软件代替呢？

A：我们也在研究 Kubernetes，不敢做过多的评价，据说 proxy 这块性能有问题。 刚开始没用 Kubernetes，是因为之前他还不是很稳定，变动也比较快。 负载均衡这块是我们自己写的，整个乐视网现在 300 多个域名都跑在上面。

Q：请问构建一次平均要多长时间？

A：现在 Java、Dubbo、Python、go 的多， 一般 2 分钟，而且有的镜像用户开启了自动构建后，在他们没意识的过程中，都已经构建完成。 到时候升级时候，选择对应的镜像版本即可。

Q：使用了 harbor 之后，Dockerfile 是不是不用写了？

A：是的，用户和业务部门只需要关心基本的容器概念（export 和 Volume）就行， 不需要写 Dockerfile。

Q：App 的每一次提交都是一个 version 吗，是不是每次构建完测试完成，就可以发布了？

A：App 没有提交的概念，您说的应该是镜像，我们设计的是一个镜像对应一个 Git 仓库以及分支。当有 push 或者 tag 操作后，会自动触发构建，构建的行为是根据用户写的镜像构建 shell 脚本来决定的。 一般我们建议业务部门做出的镜像跟测试环境和生成环境没关系。 镜像就是镜像，只有应用有测试环境和生产环境。

Q：提到”用公有云的思想去构建私有云”，请问您在构建公有云和私有云时，在技术上有什么区别？可以谈谈您的看法吗？

A：我们主要是把我们内部用户也看成外部用户去对待，在产品设计上会考虑这一点。这也是我们一直摸索的方向。

Q：您有物理机和虚机，请问根据什么场景选择运行在物理机还是虚机上？是性能的选择吗？

A：这完全看业务方的需求，Harbor 本身不关心。 它允许业务自己创建私有集群，把自己的虚拟机或者物理主机添加进去。

---

2016-02-23：一个关于不可变基础设施的实践案例

Q：你们这套方案中遇到过哪些坑让你印象深刻，请举一两个具体实例说明？

A：使用 Packer 在国内进行构建时，因为众所周知的网络原因，经常会有失败的问题，这一点可以通过其他方式避免。此外由于 Terraform 并非完全支持所有的 AWS 资源管理，如 Cloudfront、Route53 Geo DNS，仍然需要手工管理这些，不过未来 Terraform 会加入这些的支持。

Q：每个 vpc 组是完全独立的提供服务？能说下这套技术应对的业务层是哪个方面的么？

A：每个 VPC 组提供的是一个完整的应用功能实现，上面也提高了我们会有 prd-sg-master，prd-sg-slave，可用于灾容。业务层提供的主要是 HTTP 服务及内部依赖的微服务。

Q：请问为什么选用 Consul？很多类似方案用的 etcd。

A：Consul 对于 agent 的节点的失效更友好，此外 Vagrant、Consul、Terraform 都是由 HashiCorp 公司开发的，其文档和技术栈都很全面，值得应用实践。

Q：如果我用了 Kubernetes，对大数据 Hadoop、Spark 都没啥需求，是否还有用 Mesos 的必要呢？换句话说 Mesos 和 Kubernetes 结合针对纯容器平台有什么好处，使用场景是什么？

A：Kubernetes 和 Mesos 都是容器管理调度的框架，Mesos 的优势是更具可开发扩展性。

Q：请问对于 PHP 这种可以动态加载代码的服务，在这套系统里应该怎么应用呢？

A：动态加载代码的代码源建议使用微服务的方式提供。

Q：Vagrant 在宿主机使用的是 NAT 模式还是 bridge ？Packer 相对于 vagrant package 命令，优势是哪些？Vagrant 在宿主机使用 NAT 模式，这样可以减少 DNS 出问题的几率。

A：Packer 可以从 ISO 镜像开始构建你的系统，相对于 Vagrant 更纯粹；实际上 Vagrant 的大多数 box 都是从 Packer 打包过来的。

Q：我在上期分享时，介绍过类似的 Packer+Terraform 工具。在使用 Terraform 管理 AWS 资源时，你提到另外的脚本管理（thor exec:terraform apply)。请问，你为何不直接运行 Terraform 的命令，用 thor 的目的是什么，你的哪个 repo 了有用到 thor，我可以参考一下？

A：我们在运行 Terraform 时需要传递很多变量以及硬编码参数，同时我们使用了 AWS 国内区域和 AWS 国际区域，他们是分开的，对应的 AWS Access Key 及 SecretKey 不同，Thor 脚本的目的是讲这些内容通过配置文件和环境变量的的方式传递给 Terraform，使其能获取正确的参数和定位正确的执行环境。

Q：请问持续集成采用的是 Jenkins 加插件的方式吗？持续集成的代码采用了什么样的分支管理策略？

A：是的，持续集成采用 Jenkins 及插件，我们采用的分支是 Git Flow 的变种，基于 pull 的模型。

Q：单纯的用于 AWS 的话，亚马逊自家的 CloudFormation 支持的基础设施应该更全面，如果不考虑跨平台的能力，还有什么理由选择 Terraform 吗？

A：CloudFormation 的设计并不友好，基于 JSON 的语法非常晦涩且难于维护，不像 Terraform 一样一目了然。

Q：跨主机网络是咋解决的啊？是结合了 Kubernetes 和 Mesos、Docker 功能吗？

A：我们采用的方案是 Weave，没有使用 Kubernetes。

---

2016-02-14：基于 Docker 搭建轻量的私有构建环境

Q：是否 Windows 2016 原生支持 Docker 运行之后 Virtualbox/Ubuntu 这一层就可以跳过了？

A：我们使用 VB／Ubuntu 的原因不是因为 Windows 原生不支持，实际上 Boot2Docker 在 Win7 上就可以用，主要原因是公司机器要装非认证的软件流程没权限，本地认证的虚拟机只有 VB。。。

Q：Oracle Express 和 Oracle 企业版的区别是？能否开发测试环境用 Oracle Express，生产环境用 Oracle 企业版？

A：Oracle Express 和 Oracle Enterprise 区别还是比较多的，私有构建环境用 Express 是为了限制资源占用。但是集成和测试环境都是 Enterprise。

Q：选择的什么操作系统运行的 Docker ？

A：Ubuntu 14 LTS。

Q：在 Docker 用 Oracle 数据库存储如何做？

A：通过 Volume 挂上去, 由于是较小的测试库，所以数据量不大。

Q：请问你们一直是使用 Virtual box 吗，有没有尝试在 VMware 下部署？为什么考虑前者？谢谢！

A：没有用过 VMware，关键因为公司认证的是 Virtual box，而且是特定版本的。VMware 还是 Virtual box，对于我们的部署区别不大。还有一个考虑是希望有一个松耦合（不强依赖于特定产品）的开发环境，并且 VIRTUALBOX 开源，免费，够用。

Q：能分享下 jenkins master 与 jenkins slave 上与各个 Docker 容器是怎么调度的？

A：Jenkins 有个 Docker 的插件，可以做到这三者间的调度协调。但是我们没有用，由于我们的实践相对还是比较特殊的，所以都是自己写的 shell 脚本。

Q：Oracle 对资源要求比较高，你们用 Docker 做性能如何，有对比数据吗？

A：我们没有特意做过测试，但经过一段时间的实践，基于 Docker 的测试比基于 Windows 桌面的测试速度快。稍微量化一点来说，用 VIRTUALBOX，起一套私有环境跑 AT，16G 内存，2 核 4 线程的开发机器，内存和 CPU 的占用率将近 80%。用 Docker 的话，跑一套私有环境做 AT，内存和 CPU 占用率大概 40% 多一点，基本上能省一半的资源。

Q：vagrant 用于开发环境，Docker 用于生产环境，这里面哪个坑最多，你们怎样解决的？

A：现在 Docker 并没有用在生产环境，只是用来辅助开发和回归测试。技术本身的坑并不多，因为我们用的方式都很直接，基本上查 docker docs 加 google 一下都能解决了。

Q：使用容器起一套 AT 环境，代码是通过 Volume 挂载到容器内部吗？运行的输出，如测试结果，编译出的 binary 是怎么交付的？

A：对的，代码通过 volume 挂载。我们的输出结果是一个文本文件包含测试的结果，以及日志；文本文件我们会自动上传至一个共享的位置，而日志是通过 logstash 收集，发送至 elasticsearch。关于 binary，我们 AT 的产出不包括 binary，我们也有构建的 job 会产生 binary，这些我们会上传至中央共享位置。

Q：开发测试环境下的数据库每次是全量构建还是增量构建？基准数据是如何管理和导入的？

A：每次都是全量构建。基准数据是来自于生产环境，对敏感数据进行清洗后得到一个轻量的测试库，然后再应用最新的代码，就成了我们每天的测试库。这个测试库是在 Oracle Enterprise 版本上，通过 Oracle 的 export/import 导入到私有构建环境，这样保证我们的所有测试环境都是一致的而且干净。基准数据不是每天导出的，大概一周到两周才会做一次。

---

2016-01-30：IT 基础架构的自动化编排

Q：Terraform 建立 EC2 时怎么用之前构建好的镜像？

A：例子中， "source_ami": "ami-de0d9eb7" 就是引入源镜像。

Q：packers 感觉就是镜像的封装，不知道描述是否贴切，它与 kickstart 有什么不同？

A：可以理解为封装。kickstart 更像 userdata。

Q：这个 Terraform 构建基础架构是否可以理解为基础应用环境的搭建？

A：是基础设施（Infrastructure) 的搭建。

Q：請問如果在 AWS 主要服務運行在 ECS ElasticBeanstalk 甚至 API Gateway、Lambda 這些 stack，是否這些工具就不適用了？

A：ElasticBeanstalk 本身已经是高度自动化了。 但是 lambda 支持。 具体可以查看：terraform.io/docs。

Q：Windows 系统也可以用 packer 制作镜像，底层需不需要虚拟化?

A：可以在源镜像上扩展，也可以直接用操作系统的 iso 文件制作。

Q：请问这里面介绍的模板与 heat 的模板通用么？

A：我没有用过 heat。 但是这里有个专门的比较：www.terraform.io/cloudformation。

Q：我现在用的技术栈也是基于 vagrant+packer+terraform，上面讲到 Terraform 不支持 AWS VPC Peering 这一点是不正确的，因为我现在已经在使用了，可能您使用的版本比较老。

A：Terraform 里的原话： You still have to accept the peering with the AWS Console, aws-cli or aws-sdk-go.（www.terraform.io/docs/）。

Q：这个 Terraform 是否可用于管理 CPU、内存等资源？

A：可以定义和更新需要的资源类型 （instance type），不同的 instance type 代表不同的 CPU 和内存。

Q：用 packer 制作一次镜像能用于生产测试各环境运行吗，不同环境配置参数可能不同，packer 如何支持一次打包到处运行的问题？

A：你可以按需定制不同的模版文件和制作不同的镜像。

Q：packer 和 vagrant 使用起来感觉很像呀，他们的主要区别是啥 ？

A：你说的是 vagrant box 吧， packer 是可以用来创建 vagrant box 的。具体参考 www.packer.io/intro/ 。

Q：可以简单介绍一下您认为最好用的服务层和应用层的自动化工具，以及原因。

A：这个话题很大。 主流的话，就是 Puppet、Ansbile、Chef、SaltStack。 我们公司用 Puppet 来管理系统配置，用 Ansible 管理应用级别的配置。因为系统配置改变相对较少，我们是 level 4 engineering team，用 Puppet 统一管理不同的云服务（AWS 和公司内部的私有云）的系统配置。 但是 Puppet 相对来说，学习曲线要比 ansbile 困难很多。 对应用的管理，需要较多的修改，BAU（运维）团队比较容易支持。所以选用 ansible 做自动配置管理。

Q：自动化编程能实现 0 运维吗？

A：还是需要 DevOps（自动化运维）

Q：基础设施可以理解为中间件？JVM 对于 Hadoop 来说是基础设施？这样理解正确吗？

A：对我来说，jvm 和 hadoop 都属于应用层的。

Q：packer 制作镜像，使用本地 shell 脚本文件来执行命令感觉调试困难，因为命令有错的话如何方便配合用户修改？不会是让用户看日志然后改脚本从头重试，再错再试，如此反复吧？很低效哦。

A：有很多方法。但是写脚本是最直接的。 镜像的制作确实需要不断调试的过程。 这是 DevOps 工作的一部分。 通常你将制作好的镜像告诉开发人员即可。

Q：脚本里直接使用 apt-get，会不会导致不同时间创建的基础设施上软件版本出现不一致？你们考虑过自建软件源保证一致性吗？

A：这就是用 packer 的好处。 你可以阶段性的产生不同的镜像，不会覆盖以前的。 然后新镜像需要在 dev／uat 环境下测试。过关后，才可以用于生产环境。 镜像制作完后，里面的内容不会改变了。

Q：可以对创意的资源健康状况进行监控么？一旦有异常，会有自愈策略么？

A：Terraform 里有部分支持的。比如某个 security group 的 inbound 规则有改变，运行 terraform plan 是可以看到有资源被修改。 如果运行实施的话，会修复的。

Q：编排的时候有没有把类似监控 nagios sensu 之类 agent 的考虑在内？

A：这个属于应用层的配置，归自动化配置管理工具，比如 puppet／ansible 来管理。

Q：按照您的回复，不同时间创建的镜像还是存在某些包版本不一致，您有针对性的测试方法推荐吗，还是在 uat 环境应用没问题就直接上生产使用了？

A：我们暂时是这样使用的。dev/uat 环境下运行正常就推到生产环境。 如果出了问题，也可以快速回滚。公司允许我们承担这个风险的。

Q： Terraform 在 AWS 使用 play apply 等创建实例时候，只支持单个 AMI 镜像么？如果想要同时配置多个不同镜像的实例，该怎么办？

A：不是的，可以创建任意多个。在创建不同的 ec2 实例时，指定不同的源镜像即可。

Q：你们有没有类似 cmdb 将所有的资源包括虚拟机的信息放在一个统一的数据库里。另外，你们有用服务发现吗？用的什么软件做服务发现? 怎么做的集成？

A：Terraform 的模版文件做的就是做这个事情啊。 针对第二个问题，服务发现属于应用层的。 当然你可以在定制 terraform 实例资源里的 userdata 时，加一条 服务发现的命令即可，这样该实例启动后，发现服务自然就注册了这个新的实例了。

Q：用模版文件管理是如何进行版本控制（version control）的？

A：就是用 Git 。 将 Template 文件存到 Git 里， 可以是内部的 Git 服务器，比如我们公司用的 atlassian stash， 也可以用 GitHub 之类的 。

Q：这个自动化部署的工具，嘉宾有实践过通过 PaaS 调用，并且部署成功吗？

A：没有。 AWS 属于 IaaS。

---

2016-01-23：基于 OVS 的 Docker 多主机互联设计和实践

Q：我见你是一台主机创建了一个 Vxlan，如果有上万台机器，岂不是要创建上万个 Vxlan？

A：创建网络是通过 Swarm 管理的，因此只需创建一次。

Q：这个对网络硬件有要求么？

A：没有具体的要求，倒是相应的内核版本要编译 OVS 的 Kernel 模块。

Q：有没有试过 Docker 自带的 Overlay 网络，和 OVS 有什么区别？

A：Docker 自带的 Overlway 网络，通过 Serf 提供的邻居节点发现功能，如实的广播 ARP，而我们 OVS 网络，ARP 都被代理了。另外 Overlay 需要更高的内核支持，应该是 3.19，OVS 没有这个限制。另外我们还提供多租户内网络地址复用。

Q：我以前 OVS 和 Docker 容器重启后，容器的 IP 变化了怎么办？

A：在 Vxlan 网络里面，在容器的生命周期内，IP 不变。

Q：为什么不直接使用大二层，就像之前的 IaaS，2 个主机的容器在 Vlan 里面可以互通？

A： 关于 Vlan，我们也有自己的 Vlan 网络插件。Vlan 和 Vxlan 场景不同，Vxlan 的优势是可以节省 IP 地址资源。

---

2016-01-15：关于混合云的一点思考

Q：我的感觉混合云是从私有云向公有云的过渡，之所有现在还存在私有云是由于一些 DC 的利旧和安全方面的考虑，这些考虑与成本和管理上便利就看孰轻孰重了。不知理解的对不对？

A：公有云是私有云和公有云发展的结合。而不是过度。大型企业涉及到国家命脉的企业是不会抛弃私有云的。

Q：您认为使用混合云面临的最大问题是什么？

A：管理的复杂。每家接口不一样。很难抽象统一。

Q：了解下目前支持混合云的开源方案有没有比较流行的解决方案？希望能提供一些指导性的建议或意见。

A：混合云还没非常完善的开源方案（我的了解），如果只是从管理角度做混合云，那么只是调用 API 就行了。如果是资源角度，那么资源混用，目前还没方案（这个首先是网络上的问题，涉及 SDN 等）。

Q：目前大多数企业都是为了云而云，在没有完善私有云 CI/CD 和微服务化前，企业如何将笨重的 VM 在混合云环境下部署？

A：CI/CD，这个问题，在 PaaS 层，如果从 PaaS 层谈混合云，又是一种不同的做法。

Q：混合云的安全性一般是怎么考虑的？

A：安全这个问题比较大。管理角度做只能保证用户基本数据的安全。1. 如何确保企业的数据在网络传输中严格加密，保证数据即使获取也无法还原；2. 保证云计算服务商在得到数据时不将企业数据泄露出去。；3. 在云计算服务商处存储时，如何保证访问用户经过严格的权限认证并且是合法的数据访问，同时保证企业在任何时候都可以安全访问到自身数据。

Q：如何看待目前国内一些 CaaS 厂商提供的自有主机管理功能？是否能为混合云的管理提供新的思路？

A：个人看好 CaaS，但目前还在发展阶段，估计成熟还需要一点时间积累，经过市场检验后。才能算成功。

Q：公有云和私有云网络打通后如何解决安全问题，是否需要防火墙，IPS 做一定的隔离？

A：防火墙 IPS 我感觉在内部需要的，公有云这些我们也无法管理到，公有云的安全都是软件定义的。

---

2016-01-06：思源基于 Docker 和 OpenStack 的私有云平台实践

Q：Hostname DNS 贵方 用什么方案固定？

A：首先 Container 创建之初，hostname 和 DNS 都是通过 Docker API 来设置的。Hostname 是 nova instance 的 name，DNS 是公司内部设置。如果想修改 Container 默认设置也是可以的，我们在内部镜像预留了一个目录，该目录下的 hosts、hostname、DNS 如果存在都会在 Container 启动后主动覆盖 Container 外部挂载的内容。

Q：在使用 Docker 去封装 novacompute 模拟大规模集群测试时，运行一段时间后总出现部分使用 Docker 封装的 nova compute 服务出现 down 的状态，不知道你们是否遇到过这样的问题？

A：我们这边没有遇到，有没有可能是模拟的 nova compute 进程数量过多消息有所积压。NOVA 方面考虑增加 NOVA 时间戳超时设置。Docker 方面建议 Docker 的网络使用 host 模式，并在 NOVA 配置文件中设置不同的 host，以便成为不同的 hypervisor node。

Q：Sahara 在使用 Docker 替代 KVM 创建 Hadoop 集群时，是直接使用 heat 创建 Docker，还是使用 nova-docker？Sahara 相关的代码是否需要改动，遇到过哪些坑？

A：我们是使用 nova docker 的 driver 创建 docker container 的，Sahara 本身相关的代码有部分改动，但是不大，主要改动在使用 container 和虚机的差别，比如 hostname、cloudinit 的部分配置等等。

Q：Docker 的网络模式中，中间添加一层 linux bridge 的原因是什么，这么做是否会有性能问题？

A：这个还是为了安全组，实际上我们支持配置两种模式，linux bridge 并不是默认配置的。OpenvSwitch 2.4 以后可以根据流表设置安全组。

Q：Container 限速是如何实现的，是否有必要针对 Container 进行限速？

A：我们的环境中使用的 OpenvSwitch，通过 veth pair 的方式建立虚拟网络设备的关系。限速主要是使用 tc，毕竟 OpenvSwitch 的限速也是使用 tc 做的。

Q：NOVA 组件中 Docker 的高级特性无法使用你怎么看，是否使用 docker api 来控制容器？

A：上面已经说过这个问题了，其实通过 flavor metadata 的设置，nova docker driver 可以实现生成一组容器。nova docker 这块过去确实是直接调用 Docker API 的，但是为了应对不断变化的 API，我们使用了 docker-py 作为 Client，并在 nova 配置文件中增加了 API 版本的设置。从而尽可能拿到 Docker 本身升级带来的福利。

Q：OPS 已经有超分设置，你设置超分的意义是什么？

A：我们 Docker 和 KVM 都在一个 openstack 平台中，而 nova 的超分实在 NOVA Conductor 中生效的。Nova compute Libvirt Driver 是直接上报的服务器核数。而我们认为 Docker 在密度上存在比 KVM 密度更高的需求，所以在 Compute 上支持超分是有必要的。

Q：使用 CPU share 是否会出现单个容器负载很高的场景，出现这种情况如何处理？

A：还是会出现的，记得有个容器 CPU 占用 1600% 的场景（32 核心）。通常这种情况还是应用出现了问题，最简单的方法是通过 cgroup 本身的命令进行限制。容器重启之后该限制就会丢失。限制方法例如： cgset -r cpuset.cpus=20-23 cpuset:/docker/91d943c55687630dd20775128e2ba70ad1a0c9145799025e403be6c2a7480cb2

Q：Docker 的监控和 scale-auto 是如何实现的？

A：监控方面目前主要是通 docker stats api 和 部分脚本来实现，集成到 Zabbix 中，后面会考虑使用 CAdvisor。\ 后者目前不支持，计划上会在 Kubernetes 平台中支持，而非 heat 或 NOVA 中。毕竟这是 Kubernetes、Mesos 它们的专长。

Q：你的三层镜像中，第一层和第二层都是系统层，为什么不合并成为一层？

A：首先我们的第一层镜像并不是通过 dockerfile 创建的，而是依据官方文档从 0 建立的最小的镜像，这一层是很少变动的。而第二层的设置是为上层设计的通用层，涉及到进程管理器、SSH 设置、pam 设置、入侵检测设置、开机初始化设置、还是有很大可能变动的，我们希望有关配置都应该放入 dockerfile 以便管理。

Q：nova-docker 如何支持 cloudinit？

A：因为在 novadocker 中就是完全模拟 KVM 的网络模式，所以 cloudinit 除了一些小幅配置变更之外没有什么特殊的。 +

Q：能否详细介绍下 ARP 问题？

A：由于建立的 vm 的 ip 之前分配给了已经删除的 vm，导致 mac 被记录在交换机上。数据交换经过 3 层，3 层交换机会将 mac 直接返回给 ping 的一方，导致无法 ping 通、 启动 container 后通过 arping -c 3 -f -U -I eth0 172.28.19.243 -c 3 开机发送免费 arp 来处理。

Q：NOVA Docker 实现了热迁移吗？如何做快照？

A：热迁移目前还没有支持，nova docker 快照就是将容器 commit 成一个镜像，然后使用 glance 的接口上传 glance 中。通过快照可以重新建立新的 container。

Q：nova-docker 不是早在 H 版本就废弃了吗？你们自己维护的？

A：确实废弃了，我们自己维护。不过 GitHub 上有了更新，我们刚刚 merge 机那里一些特性。可以再关注一下。

Q：OpenStack 如何对 novadocker 环境的 container 进行监控？在监控指标上是否与其他 hypervisor driver 有区别？

A：监控方面目前主要是通 docker stats api 和 部分脚本来实现，集成到 Zabbix 中，后面会考虑使用 CAdvisor。监控上有一些区别。主要是 pid_max、docker daemon 存活，和 Docker 自身存储 pool 等 Docker 特有的，其他方面没有太大区别。

Q：您好，贵公司只维护 Git 代码和镜像容器。请问假如同一个编译环境，能编译不同操作系统版本的库吗？或者镜像。因为同一套代码会部署到不同的系统上？

A：我们这条编译环境只是用来编译 OPS 本身的，如果需要增加新的编译环境，我们会向 Registry 推送一个新的编译镜像。

Q：glance 管理镜像和快照时有没有能用到 Docker 的分层？如果有，如何利用的？

A：没有，tar 包形式，compute 节点下载之后 load 到 compute 节点上。

Q：生产环境相比测试环境有什么不同吗？

A：Docker 在 CPU 超分系数不同，系统 pid_max 等调优参数略有不同。

Q：Nova Docker 快照是如何实现的？

A：将操作的 Container commit 成为一个镜像，并上传到 glance 中。

---

2015-12-29：用 Docker 和 Git 搭建在线开发环境

Q：那么多的开发者，域名怎么分配？

A：目前，我是通过 Nginx 的反向代理来分配不同的子域名给不同开发人员。

Q：在这个体系中开发与测试是如何联系？

A：这套体系主要专注于开发的部分，测试与开发的互动并没有在这套体系中体现出来，不过有很多成型的 DevOps 体系可以作为参考。

Q：云端开发是不是开发环境放在云上，开发者 SSH 到自己的开发环境，提交代码后 Compose 是自动执行还是人为执行？

A：理想状况下，是将一下三个部分都放倒云端，目前我只实现了运行环境在云端。 Compose 现在也是手动之行的，但是可以通过脚本做到自动化功能完备的代码编辑器 一个应用运行环境 一个调试工具箱。

Q：云端开发会不会减少开发者的工作量，让其更专注于代码上，而不是流程的应用上？

A：云端开发会让开发人员更少的经历去学习了解中间件， 用更多的时间专注于业务功能的实现，从而做到让开发更关注需求本身，而不是技术本身。 另外在线开发环境可以提高协作性。因为运行环境和代码都在云端，开发人员可以很快的切换其他人的开发环境和代码。

Q：在线 IDE 在实际使用中的体验，可被开发人员的接受程度如何，对各类语言的支持情况呢？

A： 目前的尝试在线 IDE 受网络，和功能的制约，不能完全和本地的 IDE 相比较。 不过因为 Git 的解耦，开发人员可以选择使用本地的 IDE 编辑代码

Q：Git 还是比较复杂，有没有更简单的工具？

A：除了 Git 之外还有一种 sshfs 的技术，可以直接映射远端代码到本地。 不过考虑到版本的回溯，甚至将来利用大数据来分析开发人员的开发行为。 Git 会是一个比较好的选择。 Git 现在的复杂是因为相应的自动化脚本没有建立，在建立之后，开发人员可以忽略 Git 同步的部分。

Q：代码提交到云端后，容器中是怎么生效的，是把代码目录作为挂载点还是容器中有进程实时去拉？

A：是的，现在代码作为卷挂载到容器中的。

Q：但是如果是以挂载的方式，怎么能重现 Commit 镜像时保证代码的同步呢？

A：我想这个问题回到了”这个体系关注的问题到底是什么”上。 我分享的这套体系专注于项目中的开发部分，并不专注版本控制，测试和部署。 通常情况下，项目应该有另外一个 Git 仓库来做版本控制，然后会有专门的 build 体系，来自动 build 指定的代码。

Q：Commit 镜像时的镜像里并没有代码啊？打算任何环境都是以挂载的方式吗？这样可移值性会不会很差？

A：首先 Container 是通过项目路径下的 dockerfile 生成的， 只是在运行环境中又挂在了一次代码。 当开发结束后， 可以通过项目的 dockerfile,整体 build 代码和环境，并部署。

Q：例如采用 git flow 这样的多分支并行开发，每个分支都要有一套对应的 docker container 吗？如何来关联分支和容器？

A：这是个好问题，首先 Docker 只提供代码的运行环境，如果代码的不同分支使用的是不同的运行环境，docker container 是应该是多套的，而且，不同的 dockerfile 是应该跟代码在一起的。 如果运行环境是相同的，可以使用同一套 docker container。只需要把代码切换到 Container 里即可。

Q：当先就目前来说，在云上部署确实很好，可是关于一些生产的私有性环境是不是在本地比云端更靠谱？

A：我理解这个问题应该是问将云端开发环境部署到公有云，还是私有云。 我个人的理解是， 目前来看，应该部署在企业内部的私有云上，来避免代码的泄露。

Q：当前来说搭建一个统一的环境使用 Kubernetes or SHIPYARD 搭建起来会更方便，而且现在物理设备的价格也更便宜，可控程度更高，在云端真的比在内部控制好么？

A：同第一个问题一样，云端指的可以是私有云，也可以是公有云。 我赞同提问者的考量，私有云会更好一些。

Q：是不是先提交代码，触发 hook，在容器里同步代码并编译和执行。这样效率会更高吗？

A：将代码编辑环境和运行环境解藕， 使用 Git 来同步，效率受两个因素制约： - I/O 也就是网络速度和盘速度。 保证网络速度的前提下，这个因素是可以忽略的 - Git 本身的效率，因为每一次保存都会提交 Git，Git 本身是增量存储，所以效率也不会太低。

Q：对私有仓库是否也能同样生效？对于容器不能被外部访问的话，hook 机制还能同步代码吗？

A： 目前这套体系建议整体部署在私有云中。

Q：每位开发者都具有相同的开发环境，该开发环境是用 Container 么，网络是如何解决的？也就是说在开发者眼里使用的就是虚拟机，具有故定的 IP。

A：应该说每位开发者都有相同的代码运行环境，这部分是通过 Container 实现的。目前明没有对网络有太多的考量， 在规划中会有一个网络分配的组件，为开发人员分配不同的子域名，并自动将域名路由到 container 上，这样可以更灵活的分配主机资源，管理 Container。

Q：代码放在云端怎么保证安全，防止企业代码泄漏？

A：部署在私有云上， 需要公网访问时，使用 VPN。

Q：我公司主要需要是 C++ 研发电信行业，不通的省份，不同的机型都要搭理一套开发测试环境，你们讲的主要是 Web 开发，C++ 是否适合云端开发？

A：我主要研究 Web 方向。 只能简单的说一下思路， C++ 的 docker image 是有的，主要是看你需要一个什么样的调试环境。如果可以通过 Web 查看结果。我觉得是可行的。

Q：关于使用 Git 搭建持续集成环境有一个疑问，就是如何处理在开发环境和生产环境下，个别文件不同的情况应该如何处理？例如一些配置文件，Django 中的 settings.py，在生产和开发环境下，其内容是不同的。

A：通常情况下，配置文件是要独立在代码之外的，用 Django 举例， 可以使用.env。 在开发环境，和生产环境使用不同的配置文件，而不是直接写在代码里面。 如何配置产品环境和开发环境，可以参考一些好的实践文章。 分离运行环境和代码的实践文章，业界比较认同的是”The 12-Factor App“这个设计思路。

Q：如果后端采用集群方式进行管理，请问您对后端容器资源使用的预估，以及对整个集群的负载能力的判断，是如何考虑的？项目不同，对后端资源影响挺大。

A： 目前项目还处在概念验证阶段。 对于中型的 Web 项目，单个开发人员分配 1CPU 资源，1GB 内存是完全可以满足需要的。

Q：本地开发可以快速切换本地 Git 的不同代码版本查看，远程运行的话，想要查看之前代码的运行结果需要真的将代码在远程共享本库中回滚吗？

A：是的，因为每个开发都自己的远程代码代码库。 所以，回滚并不会影响其他人，也不会丢失自己的代码。

---

2015-12-22：基于 Docker 和 Git 的持续集成工作流

Q：开发每提交一个 bugfix，都会触发 jinkens 去构建镜像，那么多的开发者，岂不是要构建很多镜像？

A：没有错，我们是每次都触发构建 image，由于 image 是分层的，底层已经存在的父对象，是不用存储，只存储变化的部分所以再用的磁盘空间很低，在系统开始初，我做过统计，1000 个 image 也不到 9G，这其中还有很多基础镜像。

Q：想问一个集群相关的，像 Docker 部署这部是直接调用 Docker 部署容器，还是通过 Ansible 或其他工具？

A：有了 Kubernetes 管理集群后，发布的工作就比较简单了，用不上 Ansible。但是 Ansible 还是有它的用处的，比如清理集群中过时的 image，和已经退出的 Container 等。

Q：你好，以前也做过类似的服务”第三步：Jenkins 会把相应的 image 部署到服务器集群中，开发者就可以通过 iss001.kingdee 这个域名访问刚刚对应分支的服务了”，单独一个分支解决了对应的 bug，但实际生产中非常容易修改一个 bug 引起其他的 bug，你们是怎么去把控整体的稳定性？如何提高这种单个 bug 分支单个测试环境的意义？

A：这个 pull-request 的工作方式是应对功能开发的，如像长期开发某个 new feature，你刚刚说的一个 bug 产生另外一个 bug，我们的做法是有回归测试，我们有一个 smoke 分支，持续不断的对其做功能回归测试，只有通过的才能 cherry pick 到 release 上。

Q：测试环境依赖的 redis/MQ 之类的外部服务如何做的隔离?每次测试单独拉起来一套外部依赖的服务吗？

A：我们通过多个手段来实现共享数据：master、smoke、release 分支测试都有自己独立的中间件，要是不用访问共享的数据，可以部署如 MQ image，代码层面的，如 MQ key 的名称加上机器的 IP。

Q：有没有用到 Mesos？是否容易遇到问题？这方面的文档好像并不多。

A：Mesos 是个二级调度，适用于像存在多套集群的情况，来均衡资源，如：部署了 Hadoop 和 storm ，一般会使用 storm 来处理实时的请求，Hadoop 做离线工作。晚上和白天就存在一种可能就是 Hadoop 闲置，但是 storm 可能很忙，这时 Mesos 这样的二级调度就可以平衡资源，节约成本，我们暂时没有这样的需求。至于文档方面我也没有深入研究，建议看官方文档。

---

2015-12-15：容器服务如何在企业客户落地？Rancher 解决之道分享。

Q：rancher-compose 和 docker-compose 关系？

A：rancher-compose 是对 docker-compose 的扩展，docker-compose 目前的能力太有限。

Q：Rancher 自己有持续集成的工具？

A：我们本身产品中不带 CI，但会在 CATALOG 里提供这样的工具让客户一键部署，我想这个比直接提供 CI 集成更 COOL

Q：Rancher 产品是付费还是开源的呀？

A： 我们是开源的，但也会有对应的企业版，像 CentOS 和 RHEL 一样。

Q：Rancher 的网络是如何实现的？

A：简单来说，我们目前是 IPSEC VPN+ 基于 DNS 的服务发现。

Q：我接触 Rancher 有两个月了，感觉是目前 Docker 管理平台里比较出色的。stack、service 管理逻辑很好。不过目前还是 0.4*版，迭代应该比较频繁。现在上业务的话，后期升级会有什么影响么？

A：升级非常容易，且向后兼容，在这一点上秉承 CloudStack 的设计原则。

Q：私有网络与公有云之间的数据安全是怎么控制的？

A：通过 ReverseNAT 下采用 IPSec Tunnel，也就是数据是加密的，但要开在服务器间开两个 UDP 端口。

Q：请问 Rancher 在多租户隔离方面做了那些事，采用哪些安全手段？

A：容器的隔离是和虚拟机不太一样，目前我们用”环境”的概念做多租户隔离，每个”环境”有自己的容器主机和容器。

Q：相比于 Kubernetes、Mesos 和 Swarm、Rancher 的优势在哪里？

A：我们和上述容器编排不是竞争关系（虽然目前编排是我们自己写的），我们会根据用户的需求提供 Swarm、Kubernates 甚至是 Mesos 的编排方式。但容器编排不是全部企业容器服务内容。

Q：请问 Rancher 是自己实现了一套容器管理工具吗，能介绍一下你们用到的技术栈吗？

A：我们是完全自己实现的。借鉴了之前团队做的 CloudStack 的成功经验。

Q：Rancher 推荐运行在什么样的宿主机之上，Ubuntu or CentOS？

A：都行，Rancher 可以管理标准 Docker 主机。

Q: 我看新版本多了一个存储池 storage pool 这个是什么作用，可以添加集群存储来供容器使用么？rancher.com/how-rancher/rage/。

Q：请问 catalog 离线可以使用吗？

A：很多企业都是没有互联网访问的，我们支持从本地镜像库 Registry 中拉 images。

Q：请问你们跟 Docker 公司是如何合作的？是什么一种关系？他们会推广你们的产品吗？

A：都是硅谷公司，有深入的技术合作，很多 Docker 组件如 libcompose 都是我们贡献的。

---

2015-12-09：玩转 Docker 镜像和镜像构建

Q：京东私有云是基于 OpenStack＋Docker 吗，网络和存储的解决方案是什么？

A：是的。私有云网络使用的是 VLAN。并没有使用租户隔离，主要保证效率。存储使用的是京东自己的存储。

Q：那个镜像压缩，有什么好处？

A：镜像压缩或者说合并，主要是减少层数，减少担忧。其实目前看，好处并不明显。因为层数过多带来的更多的是担忧，但没有确凿证据表明会影响稳定。

Q：在线编译应用广泛吗？我们一般可能更关注最后的结果。有很多代码都是先在本地编译，成功后，再发布到镜像中的。

A：这个玩法应该说并不广泛。主要是我自己玩的时候，不想自己去拉镜像的全部层，只关注编译结果。所以这样玩

Q：对于 Docker 镜像的存储京东是使用什么方式实现的分布式文件系统京东 Docker 上有使用吗能否介绍下？

A：镜像存储使用的是官方的 registry。v1 版本。registry 后端是京东自研的 JFS 存储。

Q：你之前提到了”镜像的合并缩减了层数，但是弊端在于将生成镜像的 Dockerfile 信息也消除了（使用 Dockerfile 生成的镜像，可以通过 dockerhistory 进行回溯）。”那如果使用了 Compress 之后，应该如何进行回溯？还是说需要舍弃这部分功能？

A：是的，确实没办法回溯了，所以要舍弃了。不过反过来想，其实如果 Dockerfile 的 ADD 和 COPY 之类的功能，就算能回溯，其实意义也不大。所以我认为保存 Dockerfile 更有意义。

Q：为什么不采用将要执行的命令做成脚本，直接 add 进去执行这种，也能减少层数？

A：这种方法也是可行的。只是 Dockerfile 更显式一些。同理，其实只要你做好镜像，直接 export 出去，就可以得到所有文件了。再配上配置文件。这样整个就只有一层了。

Q：我平时在，测试的时候并没-有压缩过，也不知道，压缩会带来什么风险，但是，看你刚才说有可能会带来一定的风险。你们遇到过么？

A：因为我们的镜像都做过合并层，所以层数并不多。不合并会带来什么风险，其实更多的是出于性能和稳定性上的担忧。这种担忧可能是多余的。但是我们宁愿选择谨慎一些。

Q：镜像的合并方面怎么样能方便的减小镜像的大小，我做的镜像有些都在 1G 以上？

A：减少镜像大小主要还是靠去除不必要的文件。合并只能减少冗余文件，如果每层的文件都不相同，合并并不会缩小镜像的大小。

Q：网络这个使用 VLAN 能说详细一些吗，是每个容器都有一个和宿主机同网段的真实的物理 IP 吗？

A：是的。每个容器都有一个真实的 IP。跟宿主机网段不同。是单独的容器网络。这个可以参考 neutron 中的 Vlan 实现。

Q：还有，把镜像压缩我也觉，但是像你那样把父镜像整个合并成新镜像这点我觉得有点问题，毕竟大家玩容器时都是在基础镜像上添加东西，你把常用的镜像为了压缩生成一个一次性的镜像，以后再使用基础镜像做其他业务时那不还得重新下载基础镜像？

A：镜像合并其实主要还是为了获得一个基础镜像。然后大家在基础镜像上添加东西。基础镜像相对来说，不会轻易改变。

Q：在你们的实践中，大规模部署容器时，每个节点都会从 Registry 节点下载镜像，给网络带来的压力大吗？

A：我们做了一些优化。首先，大部分业务使用的镜像会提前推送到每个 Docker 节点上。即使节点没有，Registry 后端接的是京东的 JFS，通过优化，临时去下载的时候可以直接从 JFS 去拿镜像数据。所以网络压力并不大。

Q：镜像压缩或者合并之后，镜像的层次减少了，但每层镜像不是变大了吗，这对于发布不是会占用带宽降低效率吗？

A：这个问题跟上个差不多。合并主要是为基础镜像使用的。

Q：你们怎么看待 OpenStack 和 Docker 的关系？在京东未来会长期两个并存吗？现在两个架构的发展速度和研发力量对比如何？

A：OpenStack 和 Docker 并不矛盾。私有云采用 nova docker 的结合更多的是迎合用户习于使用 VM 的习惯。Magnum 也在快速发展中。所以我相信二者都有存在的价值和发展的必要。

Q：关于 dockfile 的优化，你们有没有什么好的建议或者经验？

A：似乎也没多少新的建议。参考 DockOne 的相关文章。Dockerfile 之优化经验浅谈、大家在写 dockerfile 时有啥最佳实践？希望得到大家的建议。

Q：比如创建一个 rabbitmq 镜像，需要安装很多依赖包，最后编译，最后生成的镜像 1.3G，像这种情况，在创建镜像的时候能否减少镜像的大小呢？

A：并没有什么好的办法来减少。可能需要一定的人工或者工具去分析不需要的文件，来减少镜像的大小。

Q：Docker 是如何进行自动更新的，自己搭建的镜像仓库，如何更新新版本的镜像？

A：Docker 我们固定了一个版本。如果没出大面积的严重问题，几乎不会更新。目前来看，运行稳定。所以也没有更新必要。新版本的 Docker 提供的如网络等，暂时我们还不会大面积跟进使用。自己的镜像仓库，如果要更新新版本镜像，push 进去就可以了。

Q：一个困扰我比较久的问题，如果镜像间存在依赖关系，基础镜像发生改变后其他镜像你们是跟着更新的呢？

A：在内部私有云中，一般大家使用的都是一个做好的 base 镜像。这里面就有一个问题，一旦这个 base 镜像需要打补丁，影响面比较大。首先很多 base 的子镜像会受到影响。另一方面，就是要考虑已经在使用基于 base 或者 base 子镜像的节点。前者我的方案是直接在 base 镜像中的 layer，把需要打补丁的文件加入进去，重新打包放回。对于后者，目前还没想到很好的方法解决。

Q：在运行容器的时候，1、应用里面的日志或者配置文件，使用本地映射是不是好点，我是考虑到方便查看日志或者修改配置；2、创建的数据库镜像，在运行容器的时候把数据文件是不是映射到本地更好些呢？

A：日志我们的确是使用的本地映射。而且有的业务方狂写日志不加约束。所以我们给本地映射做了个 LVM，挂给容器。做了容量上的限制。配置的话，现在是有一个内部的部署系统会帮他们部署配置。数据库的话是一个道理，也是映射到本地。也有一部分接入了云硬盘。

Q：Docker 中，每层镜像打标签那我觉的很奇怪，当 pull 一个镜像或生成一个容器时，它如何找到你所命名的镜像层？

A：并不是给每层都打标签，而是你根据你的需要来给某一层打标签。至于标签内容，需要自己来进行控制。

Q：关于 Compress 的实现有些疑问，是不是在实现的过程中，只考虑最后的镜像和前一层的 diff，还是说要逐层做 diff？

A：是只考虑最后的镜像和你要合并到的父层镜像做 diff。这样只要做一次 diff，就可以获得中间的所有文件变化了。

Q：wrapdocker 文件的工作原理是什么?

A：这个工作原理主要是准备一些 Docker 启动必要的环境。比如在 CentOS 下，需要 wrapdocker 把 cgroups 等准备好等。你可以参考下 wrapdocker 里面的代码。

Q：容器运行在物理机上，与 OpenStack 平台虚拟机是同一套管理系统？如何与容器的集群系统整合？

A：是同一套系统，都是用 nova。虚拟机 KVM 和容器主要是镜像类型不同。在 nova 调度的时候，会根据镜像类型调度到 KVM 或者 Docker 节点进行创建。

Q：在一台物理机上运行 Docker 的数量是否有限定 还是看运行的应用来决定？

A：没有特别做限定。主要还是业务方去申请的。业务方习惯用大内存，多 CPU 的。那这个物理机上创建的容器数就少些。大致这样。

Q：想了解一下，你们对镜像的 tag 是怎么管理的？根据什么来打的？对于旧的镜像你们是丢弃还是像 Git 保存代码一样一直保留在仓库呢？

A：tag 由各个用户来定。不同的用户在不同的 Repository 里。镜像 tag 自己管理。不过我们更希望他们能够更加规范一些，比如用 git 的版本号来打 tag。

---

2015-11-29：微服务架构云端应用

Q：请问你是基于 Docker 和 Mesos 吗?

A：用了 Docker。

Q：是混合云架构吗?

A：是的，也可用在私有云。

Q：微服务是谁发布哪？

A：只要有代码就可以发布微服务，一般由微服务的开发者发布。

Q：业务系统日志是如何处理的？

A：统一输出到标准输出和错误输出，按租户存储，实时显示到页面，可以按天下载。

Q：请问你们的容器管理系统是基于开源平台还是自己开发的？有何优势？

A：用了一部分开源。 4.持开源服务和用户贡献的服务，用户选择空间更大。

Q：请问你们的服务「水平伸缩」和「垂直伸缩」分别面对哪类场景？如何实现？

A：「垂直伸缩」对于所有场景都是可以使用的。「水平伸缩」用到无状态服务的场景，而且可以和「垂直伸缩」叠加使用的，有状态服务不支持水平伸缩。针对不同微服务类型，在管理后台配置就可以实现。

Q：微服务跨平台如何解决网络延迟问题呢？

A：在网络不稳定的场景，服务之前的调用一定要用断路器，另外只有优化物理网络链路了。

Q：微服务怎么解决后端数据库的部署和依赖问题？

A：在好雨云，数据库也算特殊一类微服务，同样有其他微服务的特性，一样可以通过微服务的特性部署和配置依赖关系。

Q：介绍下服务间通信是如何实现的？

A：在服务使用端实现了一个透明的代理，它根据服务注册的 Endpoint，找到要使用的服务，如果是多个服务，自动实现负载均衡。

Q：支持的语言有没有 c 语言？

A：可以通过 dockfile 支持的。

Q：请问一下 docker 选用的是哪个版本？有特殊原因么？

A：我们比较保守，用的是比较稳定的，除非有个大特性吸引我们

Q：请问代理模式是指类似于 API GATEWAY 吗？具体用什么实现的？

A：是的。有很多种实现方式，可以自己写代码实现，也可以部署一个 Nginx。

Q：从前面架构图看每个微服务的数据库是独立的，这是必须的吗？

A：这样有很多优点，比如业务隔离，独立团队维护，业务分区，等等，不是必须，共享模式就是特例。

Q：能否理解解决「服务伸缩」问题的重点是「服务发现」和「状态共享」？

A：这块的核心依赖程序实现，如果程序实现的好，就可以做到非常好的水平伸缩，我们自己的有状态服务也是可以水平伸缩的。

Q: 请问当每个服务都可能同时存在多个在线版本时，如何做 ab testing？如何控制业务路由？

A：ab testing 我们当前没有实现，下一步会引入这个特性。我们的设计思路是实现一个控制用户访问路由的微服务，同时支持 ab testing。

Q：哪种服务模式用的最多？异步消息模式吗？

A：用的最多的是聚合模式和异步消息模式。

Q：微服务后端的数据库是弹性伸缩的怎么做的？MySQL，mongodb

A：要支持水平伸缩，需要部署一个支持水平伸缩的数据库中间件做为微服务。 垂直伸缩，直接调整资源就可以了，受限于物理机的资源容量。

Q：伸缩的时候对业务可以做到完全透明吗！

A：是的。我们现在的实现是对业务完全透明。

Q：服务发现用到什么，Consul、Dubbo？

A：轻量级封装 etcd。

Q：每个微服务对应一个数据库，怎么做到数据共享呢？

A：每个微服务后面的数据库支持有状态数据的持久化，对外整体是一个业务服务，需要根据业务关系来梳理服务结构。如果有一致性要求比较高的场景，可以使用共享数据库或消息服务实现。

Q：垂直伸缩，调整资源就可以了，资源需求超过一台物理机呢？拆库？

A：三种方式：第一种，把业务拆的小，数据库分库。第二种，数据库 sharding。第三种，使用 CQRS 模式，重新设计实现。

Q：服务调用链的事务怎么保证的？

A：可以通过共享数据库，使用数据库事务解决调用链事务问题。另外，还可以使用异步的消息服务，通过保证消息可靠消费来实现。

Q：CQRS 模式的 维护成本很高啊 有评估过这种改造的成本吗？

A：有框架重用的，比如 AKKA，性能奇高，开发也很简单。只是学习曲线比较陡

Q：能分享下如何把控提供微服务的细粒度，微服务的范围和边界怎么控制？

A：一定要结合实际业务场景，还要看团队情况，我的经验是，微服务的粒度和内部人员管理关联。随着业务发展，粒度也需要不断调整的。边界要考虑业务抽象的合理性。

---

2015-11-25：搭建企业私有 Docker Registry 实战分享

Q：目前有没有尝到监控 Register 运行和使用情况的好处，或者在维护私有 Register 有没有遇到过什么问题？

A：能够实时监控 Registry，就能观察用户的行为，当我们在负载量很大的时候，能够有效保持 Registry 稳定运行。维护私有的 Registry 的问题，就是要跟进官方的更新，看看是否也需要同步。

Q：Rancher 实际上是基于 Docker 的开源 PaaS，基于容器技术的开源 PaaS 很多，比如 Deis、Flynn 等，但是 Rancher 跟这些项目不同的地方是，它尽可能的和 Docker 生态圈工具兼容。请问当初为什么会选择 Rancher，在你看来，Rancher 最吸引你的地方是什么？

A：Rancher 的 UI 比较方便于上手和使用。而且 Rancher 的概念也更接近 Docker compose，目前官方的文档也比较齐全。

Q：Flowdock+Hubot 这种方式下的监控是否必须用 Sensu，是否支持采用 zabbix 作监控，Zabbix 的远程脚本可以实现一些自动重启等等操作?

A：Sensu 不是必须的，你可以使用你熟悉的监控服务，比如 Zabbix。

Q：Flowdock+Hubot 在一些安全性要求比较高的生产环境上是否可用，其发布的命令采用什么方式连接到容器\虚拟机或者主机上？要不要建立 SSH 免密码连接之类的操作？

A：Hubot 是拉取 Flowdock 的信息，所以 Hubot 可以部署在公司防火墙内。目前 Hubot 使用 docker remote API 来控制虚拟机上的容器。

Q：请教一下，Rancher 可以理解为 Compose 的增强版吗，特别是可视化部分？

A： Rancher 自己有一套 rancher-compose，提供 load balance 和 auto scaling，可以算是 Compose 的增强版。可视化部分，是 Rancher 的一个 Feature。

Q：Rancher 的 lb 是用的 HAProxy 么？

A：是的。

Q：有没有做过横向比较，Kubernetes 和 Swarm+Compose，Rancher+Compose，在这几种选择间做过比较，或者说为什么最终选择了 Rancher？

A：最初是选择 Swarm+Compose，但是由于那个时候的 Swarm 不太稳定，有 bug，集群管理工作不起来。Rancher 部署方便，操作简单，所以就用了它。

Q：Rancher 的网络具体是怎么做的呢？

A：据目前了解，是 overlay 模式。各主机之间采用 IPsec Tunneling 来实现通信，使用 udp 的 500 和 4500 端口。启动时在各个主机部署容器之前启动一个 Network Agent 管理容器网络。具体可以参看文档：docs.rancher.com

Q：rancher master 如何实现的高可用？之前看了文档搭建之后，cpu 等监控图无法显示了

A：通过 rancher-compose 提供 load balance 和 auto scaling 实现高可用。监控图无法显示也是我们遇到的问题，目前正在解决。

Q：从描述看 Rancher 的网络类似于 weave 吧，给每个容器分配固定 IP，对集群规模比较大的或者 IP 地址段受限的似乎不太够用？

A：从我们目前的经验来看，的确有这样的限制，如果有大规模集群的需求下，需要重新评估 Rancher 来管理和部署。

Q： Hubot 是不是也支持非容器方式的部署，比如部署在虚拟机上？

A：可以，可以参照 hubot.github.com。

Q：Hubot 使用 docker remote API 是否采用了安全策略，另外 Docker Registry 采用了何种安全策略？

A：Remote API 使用了 TLS 验证。目前我们的 private registry 使用了 LDAP+token 作为安全认证。

Q：在部署方面很重要的是动态伸缩和灰度发布，在这两方面你们是怎么考虑的？Rancher 在这两个方面有支持吗？

A：通过 rancher-compose 提供 load balance 和 auto scaling 实现动态伸缩。其他方面，还没有考虑过。

Q：Rancher 的管理数据是不是都放在了 MySQL 里面？MySQL 需要搭建在物理机上吗？

A：MySQL 是 rancher server 自己提供的，无需手工部署。

Q：Rancher 能支持云存储吗？

A：最新版本的 Rancher 对 Docker volume 插件有了支持，可以通过它来实现 Container 的数据存储管理。

Q：请问你们实践或了解到的基于 Rancher 的集群规模有多大？

A：目前我们的使用规模比较小，还没有这方面的准确数据。

Q：从介绍看整个系统是搭建在 OpenStack 上的，采用 Swift 作为存储，那 Docker 的部署是不是采用的 nova-docker 呢？容器是部署在物理机上还是虚机上的，如果是虚拟机采用的是哪种 hypervisor，性能方面如何，有没有做过相关的压测？

A：Docker 是部署在 KVM 的虚拟机上，使用的企业私有云平台，目前没有做过性能测试。

Q：Rancher 实际应用中有哪些要特别注意的问题，麻烦分享下？

A：Rancher 版本更新快，较低的版本会有很多 bug。

Q：有考虑过升级问题么？比如 Registry 从 v1 升级到 v2？或者 docker 升级到 1.9？

A：目前我们使用的就是 v2，使用 rancher upgrade 来升级。 升级 Docker 的成本较大，目前还没有相关最佳实践。

Q： Rancher 中文资料多嘛，有推荐嘛？

A：目前我们看的都是官方英文文档，这样能看到最新的信息，中文文档没有关注。

---

2015-11-17： 接触 AWS 近 5 年，谈谈我的运维经验

Q：请问您觉得 AWS 和国内的云厂商相比，最大的优势是什么？

A：从全球的角度来看，根据 Gartner Report，是最领先的云服务。对于功能而言，AWS 的服务多，质量上乘。对于业务需求在海外的，AWS 更为重要。有些国内的云服务，基本上都是模仿着 AWS 起来的。

Q： 防 DDoS 架构都需要自己搭建，AWS 没有提供外层包装好的服务么？

A：AWS 内置的服务中已经提供了防范 DDoS 的能力，大多数情况下都够用，只是针对应用层的攻击，需要额外的服务。另外有很多安全厂商和 AWS 有合作，在 AWS Market 可以得到相应的安全服务。

Q：你们用过 ECS 服务吗，功能上能否满足你们的应用需求？

A：我们目前正在尝试采用 ECS 的方式来部署我们的服务，10 月份的 reInvent 大会发布了 Private Registry 还有 ecs-cli 等一些工具，会使 ECS 更易使用。

Q：前端放不同 az 还好说，后端数据库不同 az 怎么搞？

A：数据库如果是自己在 EC2 上部署的话，比如我们使用的 Cassandra，多台同样可以采用不同 AZ，至于 AWS 本身的数据库服务 RDS、Aurora、DynamoDB，里面有一个 multi-AZ 的功能。

Q：另外目前很多公司都采用了云服务，很多运维同学比较关注的一个问题是会对运维成员带来了一定的影响，因为很多工作使用云服务就可以解决。一种观点是，上云，是运维人员的一个机会，因为使用云服务在某个方面来说，对运维人员的要求又提高了。目前熟悉 AWS 的运维人员并不好招。请问，您是怎么想的？

A：这个问题，我自己也深有体会，Docker 会这么火，里面也有这一层关系。

Q：自动伸缩服务对于用户这边需要做哪些准备，如何保证代码持续更新，自动伸缩也是可用的，就是我怎样信任自动扩容出的机器？

A：主要还得要求机器中的服务实现无状态，信任是建立在测试和监控的基础上。代码持续更新是另一个问题，持续发布的问题，这个现有的解决方案也蛮多的，可以线下讨论。

Q：亚马逊云的故障率大概有多少，企业级应用的价格是否可以接受？

A：目前根据我们使用的服务来看，故障率不高，稳定性和质量都蛮高的，剩下的都是一些小问题，2012 年的时候曾有 5 个大问题（AWS 专门解释原因的）。对于价格可能要具体问题具体看，对于我们而言，也做企业级应用，7 个地区的部署，还是能接受的。

Q：请问有没有部署将企业自己数据中心和 AWS 上服务互联，推荐方式是？

A：公司里其他部门是有的，通过 VPN 的方式更安全。

Q：请问 ECS 是否只有提供 CD、CO、CI 部分是否只能是用户自己定制和对接，还有预计 ECS 什么时候会在中国站点发布呢？

A：AWS 本身有提供 code deploy、code pipeline、code commit 持续发布的服务，可以和 ECS 一起使用，新发布的 Private Registry 也会对 ECS 的 CI/CD 带来帮助。中国站点的情况，不了解。

Q：请问老师是否知道目前亚马逊在国内数据中心部署进展怎样？

A：我们没有使用，所以具体的细节不太了解。似乎是有限开放，之前去 reInvent 开会，有一个中国专场，很多国内的公司都在使用了。

Q：你们有考虑过灰度发布吗，AWS 上对此是否有相应支持？

A：有在使用，粒度现在还比较粗一点。一方面需要依靠应用程序本身，可以做到配置管理。AWS 的支持，还是需要通过架构设计来做到，比如 Router53 支持带权值的 DNS，另外还有今年发布的 API Gateway 也可以拿来帮忙。

Q：目前 AWS 的一个趋势是推广基于事件的服务，就是逐步弱化服务器的概念，根据事件进行相关服务，这也是领先其它云厂商的一个方面，请问针对这一点，您是怎么想的？

A：本来我也想聊聊 lambda 这个服务，考虑到时间的问题，没有讨论到。这确实是一个蛮好的想法。我了解的信息是，欧洲、北美有蛮多的公司采用了这种无服务器的方式，基本上不用自己来管理 EC2 机器，做好监控就可以。好处就是快，坏处就是和 AWS 耦合太紧。

---

2015-11-11： 一篇文章带你了解 Cloud Native

Q：如何达到分享老师这种技术深度、广度、理念？

A：过奖了，谢谢。有几点可以和大家分享一下：1. 技术都是慢慢积累过来的，你做的久了，自然知道的就多些，做技术贵在坚持。2. 多和一些大牛学习和交流很重要，最直接的就是多向你的直接领导请教；3. 多学习，每天坚持学习；4. 平台很重要，有个很好的发展平台可以让你多学习很多内容。

Q：唯品会属于康威定律中哪类公司，对促进 Cloud Native 都作了哪些组织结构上的调整？

A：为了推行 Cloud Native，我们成立专门的云计算部门。但是为了推行云，我们需要和周边各个部门打交道。推行 IaaS 还好说，因为这块基本上是标准化的东东，但是在推行 CI、CD 时碰到很多问题。CI、CD 是和业务密切相关的，规范的推行，必然会给大家带来额外的工作量。针对这些问题，我们是联合多个部门一起搞，项目制运作。

Q：在实际使用过程中，12 因子是定性的还是定量的，如何检测？

A：应该是定性和定量结合更为合适。比如代码统一放入 Git 库，这个是定性。但是代码提交次数，代码圈复杂度大小，CI 成功率等就是定量的。

Q：针对移动端的自动化测试，你们是怎么做的？你们的服务发现是如何做的？

A：移动端的自动化测试，这块了解有限，暂时无法答复你。服务发现，我们有两种模式：DNS 传统模式，另外一个就是基于自研 OSP 开放平台的服务注册、服务发现模式。

Q：灰度发布采用的什么策略，是 AB 两个集群轮流替换的方式吗？

A：目前是按批次分批发布的，比如 50 个节点，先升级 1 个，再升级 20，最后升级 29 个。

Q：自动化测试是怎么做的，尤其是 Web 应用的自动化测试，采用的什么工具？

A：我知道的有 Test link。

Q：这些云上的数据库是如何部署的，处理的数据规模有多大，事务吞吐量多少，扩容这块如何实践的？

A：DB 有专门的部署工具，对于规模和事务吞吐量、扩容问题，这个比较敏感，可以线下专门交流。

Q：请问，唯品会目前云上用的是什么数据库？

A：MySQL、MongoDB。

Q：请教一下，后台数据库是如何分离的，比如，是不是先从用户微服务中拿用户列表，在用用户 ID 去商品微服务中去拿这个用户的商品列表？

A：后台 DB 链接信息一般可以作为环境变量注入 App 中。

Q：在基础设施上您同时使用了虚拟机和 Docker，请问这两种基础设施承载业务也不同吗？

A：虚拟机目前是开发测试环境用。Docker 后续会直接用在生产环境，主要是无状态 App 甚至缓存。其实 VM 大部分场景都可以使用 Docker 代替。

Q：在服务注册和发现的图里 Consumers 应该不会直接连接 Producer 吧，一般会通过企业治理 esg 连接？

A：Producer 和 Consumer 之间一般还有个 LB。

Q：能把预发布环境理解为集成测试环境吗？

A：预发布是上线前的一个环节，链接的 DB 都是线上真实环境的。集成测试环境，还在预发布环节的前面。

Q：作为环境变量到终端 DB 安全性如何保证，难道是每个用户一个 DB？

A：一般是后台 service 链接 DB 的吧，用户是无法接触 DB 的。

Q：那个动态更新配置的服务是需要启动一个守护进程去更新吗？

A：一般来说，client 都会安装一个配置 agent，它来负责从配置 server pull 配置进行更新。

Q：怎么理解版本控制的分布式配置中心，主要是配置的哪些信息？

A：比如 Nginx 配置（端口、vhost 等）、tomcat 配置、DB 链接信息、缓存链接信息等等。

Q：12 因子是否过于严格，嘉宾的表格里关于应用无状态也只是部分满足？

A：12 因子主要针对 App 的，它不适用于 service 层面，比如对于 db，mc 的服务是不适合的。

Q：Gateway 实现是使用开源框架（kong、loopback）还是自己实现？

A：既可以自己实现（比如 Java、Nginx），也可以采用开源的，比如 Zuul。

Q：必要时进行协议转换（比如 Http 转为 AMQP）？

A：比如外部是通过 http rest 请求的，拿到这个请求后，把参数封装，然后以 mq 的方式发给后台其他服务。

Q：微服务一定是无状态的吗？

A：这个不一定的。

Q：能介绍 OpenStack 在项目中怎么和 Docker 等结合使用的吗？

A：目前我们的 CI 采用 Docker，Docker 直接跑在 VM（VM 由 OpenStack 创建）上。对于 OpenStack 底层和 Docker 如何结合，目前还在方案评估中。

---

2015-11-08：细节 ｜ 谈谈 CoreOS 的 etcd

Q：请问下 etcd 目前的并发连接是多少，支持多少目录？

A：这个要看你自身的服务器情况。目前每个 watch 都会占用一个 tcp 资源和一个 go routine 资源，大概要消耗 30-40kb。etcd 3 做了很多优化。支持目录和 key 是类似的，目前可以做到 100k 左右的小 key。

Q：etcd 未来的版本会像 ZooKeeper 一样支持临时节点吗？

A：目前 etcd 支持 ttl key，etcd 3 会支持 lease，lease 可以 lease 到多 key，lease 到期会把所有 key 自动删除。相当于 group 一些 ttl keys。ZooKeeper 的临时节点从我看来是一个 broken 的功能。

Q：etcd 在其他 OS 像 CentOS 上性能会有折扣吗？

A：etcd 对 CoreOS 本身没有任何依赖，所以不会。

Q：etcd 2 和 ZooKeeper 相比优势在哪些方面？

A：和 ZooKeeper 的设计理念和方向不太一样。目前 etcd 着重于 go stack 和 cloud infra 领域。很多上层系统例如 Kubernetes、CloudFoundry、Mesos 等都对稳定性、扩展性有更高的要求。由于理念的不同，导致了很多设计的不同。比如 etcd 会支持稳定的 watch 而不是简单的 one time trigger watch，因为很多调度系统是需要得到完整历史记录的。etcd 支持 mvcc，因为可能有协同系统需要无锁操作等等。在性能上今后 etcd 可能也要做更多工作，因为 container infra 有更多的大规模场景。

Q：etcd 能放到 Docker 里么，有没有这方面案例？

A：coreos/etcd.md。

Q：etcd 与 Consul 比，有什么特色和差异？

A：Consul 是个 full stack 的工具。etcd 只是一个简单的一致性 kv。我们认为能把一致性 kv 这件事情完整的做好已经不容易了。 我们希望上层的系统可以在 etcd 上搭建，而不是让 etcd 本身服务最终用户。另外在某些程度上而言，Consul 并不着重保证自身的稳定性和可靠性。HashiCorp 自己的调度系统 nomad 也并没有采用 Consul。这些差别导致了很多设计、实现上的不同。

Q：请问 Kubernetes 中使用 etcd 主要用来做什么？

A：存储重要的集群信息和做相关组建之间的协调。

Q：etcd 在 n 台（n 大于等于 3）机器组成的集群下，性能如何，性能会随机器数下降么？

A：写性能会的。etcd 3 做了相关优化，分配了一些写 load，etcd 2 下降一些。

Q：外 Masters 实效后，要多久才能选出新的 Masters 恢复写？

A：可以根据服务环境自行设置。默认的 timeout 是 1 秒，2 秒内可以选出。如果网络经常不稳定，或者服务器忙，可以提高到 5 秒，10 秒内选出。

---

2015-11-06：Docker 1.9 新特性解读

Q：请问 ovs 和 vxlan 在吞吐和延迟方面有性能损失吗，有无测试指标？

A：损失肯定是有的，但是具体的指标，Docker 方面没有给出测试结果。

Q：本地化创建 images 咋样了，ovs 是本地化吗，物理网卡需要多少带宽？

A：这个本次更新没有提到。ovs 的配置会本地化，具体物理网卡多大 Docker 官方没有给出说明。

Q：1.9 之后容器的网络栈是在容器启动之前就配置好了还是启动之后，之前版本的 Docker，网络初始化是在容器启动前还是启动后？

A：网络栈启动之前就会配置，启动时候进行加载。之前的 Docker 也是这样。

Q：dockerdaemon 为跨主机网络增加了哪些配置项，跨主机网络的信息存放在哪里？

A：这个问题太具体了，需要仔细看看代码才知道，我只是大概看了一下，毕竟网络这部分更新太多了。

Q：请问从 1.9 开始 Docker 就支持 ovs 了么，ovs 还是需要自行安装吧？

A：1.9 开始使用 ovs 实现 networking 部分，底层还是调用的 ovs。ovs 需要自己安装。

Q：也就是说从 1.9 以后 ovs 就是直接通过隧道使用，而不是通过 route 来实现，对么？

A：可以这样理解。

Q：请问 volume 特性现在有类似 kubernetes persist volume 的功能吗，对接第三方存储？

A：现在的 volume 还是对接本地文件夹的，拥有了子命令，更多的是方便使用和管理。

Q：1.9 版本特性，是不是更容易建立固定 IP 类虚拟机的容器？

A：是的。

Q：跨主机的容器网络是由 Docker daemon 来维护的吗？

A：是通过 daemon 维护的。

Q：Docker1.9 的 CRIU 方案相对前几个版本有哪些改进，新版本使用热迁移有哪些坑？

A：Docker 还是不能热迁移，runC 才可以。

Q：跨主机网络功能是全部在 docker engine 实现的么，还是需要依赖安装好的 ovs 相关环境？

A：底层还是调用 ovs。

Q：如果容器重启或重新生成对已经构建的虚拟网络有影响吗？

A：没有影响。

Q：D 能不能给个 1.9 网络新特性的实际使用的例子？

A：我上面给的那个执行流大概就和实际使用的例子类似，就是创建 Network，然后创建 ep，创建沙盒，将 ep 装入沙盒中。实际使用的例子可以参考 Docker 官方文档。

Q：多个容器共享一个存储如何解决同时写的问题？

A：其实本质上 Docker 的数据卷就是一个 bindmount，其工作原理和 Linux 主机上的共享卷原理一致。

---

2015-11-04： 蘑菇街基于 Docker 的私有云实践

Q：请问容器间的负载均衡是如何做的？

A：容器间的负载均衡，更多是 PaaS 和 SaaS 层面的。我们的 P 层支持 4 层和 7 层的动态路由，通过域名的方式，或者名字服务来暴露出对外的接口。我们能够做到基于容器的灰度升级，和弹性伸缩。

Q：请问你们的 OpenStack 是运行在 CentOS 6.5 上的吗？

A：是的，但是我们针对 OpenStack 和 Docker 依赖的包进行了升级。我们维护了内部的 yum 源。

Q：请问容器 IP 是静态编排还是动态获取的？

A：这个跟运维所管理的网络模式有关，我们内部的网络没有 DHCP 服务，因此对于 IaaS 层，容器的 IP 是静态分配的。对于 PaaS 层来说，如果有 DHCP 服务，容器的 App 所暴露出来 IP 和端口就可以做到动态的。

Q：请问你们当时部署的时候有没有尝试过用 Ubuntu，有没有研究过两个系统间的区别，另外请问你们在 OpenStack 上是怎样对这些虚拟机监控的？

A：当然，容器的数据是需要从 cgroups 里来取，这部分提取数据的工作，是我们来实现的。

Q：容器间的网络选型有什么建议，据说采用虚拟网卡比物理网卡有不小的性能损失，Docker 自带的 weaves 和 ovs 能胜任吗？

A：容器的网络不建议用默认的 NAT 方式，因为 NAT 会造成一定的性能损失。之前我的分享中提到过，不需要启动 iptables，Docker 的性能接近物理机的 95%。Docker 的 weaves 底层应该还是采用了网桥或者 OpenvSwitch。建议可以看一下 nova-docker 的源码，这样会比较容易理解。

Q：静态 IP 通过 LXC 实现的吗？

A：静态 IP 的实现是在 nova-docker 的 novadocker/virt/docker/vifs.py 中实现的。实现的原理就是通过 ip 命令添加 veth pair，然后用 ip link set/ip netns exec 等一系列命令来实现的，设置的原理和 weaves 类似。

Q：容器内的进程 gdb 你们怎么弄的，把 gdb 打包到容器内吗？

A： 容器内的 gdb 不会有问题的，可以直接 yum install gdb。

Q：共享存储能直接 mount 到容器里吗？

A： 虽然没试过，但这个通过 docker -v 的方式应该没什么问题。

Q：不启动 Docker Daemon 的情况下，离线恢复 Docker 中的数据是咋做到的？

A： 离线恢复的原理是用 dmsetup create 命令创建一个临时的 dm 设备，映射到 Docker 实例所用的 dm 设备号，通过 mount 这个临时设备，就可以恢复出原来的数据。

Q：Docker 的跨物理机冷迁移，支持动态的 CPU 扩容／缩容，网络 IO 磁盘 IO 的限速，是怎么实现的，能具体说说吗？

A：Docker 的冷迁移是通过修改 nova-docker，来实现 OpenStack 迁移的接口，具体来说，就是在两台物理机间通过 docker commit，docker push 到内部的 registry，然后 docker pull snapshot 来完成的。动态的 CPU 扩容／缩容，网络 IO 磁盘 IO 的限速主要是通过 novadocker 来修改 cgroups 中的 cpuset、iops、bps 还有 TC 的参数来实现的。

Q：请问你们未来会不会考虑使用 Magnum 项目，还是会选择 Swarm？

A：这些都是我们备选的方案，可能会考虑 Swarm。因为 Magnum 底层还是调用了 Kubernetes 这样的集群管理方案，与其用 Magnum，不如直接选择 Swarm 或者是 Kubernetes。当然，这只是我个人的看法。

Q：你们的业务是基于同一个镜像么，如果是不同的镜像，那么计算节点如何保证容器能够快速启动？

A：运维会维护一套统一的基础镜像。其他业务的镜像会基于这个镜像来制作。我们在初始化计算节点的时候就会通过 docker pull 把基础镜像拉到本地，这也是很多公司通用的做法，据我了解，腾讯、360 都是类似的做法。

Q：做热迁移，有没有考虑继续使用传统共享存储的来做？

A：分布式存储和共享存储都在考虑范围内，我们下一步，就计划做容器的热迁移。

Q：请问你们是直接将公网 IP 绑定到容器吗，还是通过其他方式映射到容器的私有 IP，如果是映射如何解决原本二层的 VLAN 隔离？

A：因为我们是私有云，不涉及 floating ip 的问题，所以你可以认为是公网 IP。VLAN 的二层隔离完全可以在交换机上作。我们用 Open vSwitch 划分不同的 VLAN，就实现了 Docker 容器和物理机的网络隔离。

Q：Device mapper dm-thin discard 问题能说的详细些吗？

A：4 月份的时候，有两台宿主机经常无故重启。首先想到的是查看/var/log/messages 日志，但是在重启时间点附近没有找到与重启相关的信息。而后在/var/crash 目录下，找到了内核 crash 的日志 vmcore-dmesg.txt。日志的生成时间与宿主机重启时间一致，可以说明宿主机是发生了 kernel crash 然后导致的自动重启。”kernel BUG at drivers/md/persistent-data/dm-btree-remove.c:181!”。从堆栈可以看出在做 dm-thin 的 discard 操作（processprepared discard），虽然不知道引起 bug 的根本原因，但是直接原因是 discard 操作引发的，可以关闭 discard support 来规避。在今年 CNUTCon 的大会上，腾讯和大众点评在分享他们使用 Docker 的时候也提到了这个 crash，他们的解决方法和我们完全一样。

Q：阈值监控和告警那块，有高中低多种级别的告警吗，如果当前出现低级告警，是否会采取一些限制用户接入或者砍掉当前用户正在使用的业务，还是任由事态发展？

A：告警这块，运维有专门的 PE 负责线上业务的稳定性。当出现告警时，业务方和 PE 会同时收到告警信息。如果是影响单个虚拟机的，PE 会告知业务方，如果严重的，甚至可以及时下掉业务。我们会和 PE 合作，让业务方及时将业务迁移走。

Q：你们自研的 container tools 有没有开源，GitHub 上有没有你们的代码，如何还没开源，后期有望开源吗，关于监控容器的细粒度，你们是如何考虑的？

A：虽然我们目前还没有开源，单我觉得开源出来的是完全没问题的，请大家等我们的好消息。关于监控容器的细粒度，主要想法是在宿主机层面来监控容器的健康状态，而容器内部的监控，是由业务方来做的。

Q：请问容器的 layer 有关心过层数么，底层的文件系统是 ext4 么，有优化策略么？

A：当然有关心，我们通过合并镜像层次来优化 docker pull 镜像的时间。在 docker pull 时，每一层校验的耗时很长，通过减小层数，不仅大小变小，docker pull 时间也大幅缩短。

Q：容器的 memcg 无法回收 slab cache，也不对 dirty cache 量进行限制，更容易发生 OOM 问题。这个缓存问题你们是怎么处理的？

A：我们根据实际的经验值，把一部分的 cache 当做 used 内存来计算，尽量逼近真实的使用值。另外针对容器，内存报警阈值适当调低。同时添加容器 OOM 的告警。如果升级到 CentOS 7，还可以配置 kmem.limit_in_bytes 来做一定的限制。

Q：能详细介绍下你们容器网络的隔离？

A：访问隔离，目前二层隔离我们主要用 VLAN，后面也会考虑 VXLAN 做隔离。网络流控，我们是就是使用 OVS 自带的基于 port 的 QoS，底层用的还是 TC，后面还会考虑基于 flow 的流控。

Q：请问你们这一套都是用的 CentOS6.5 吗，这样技术的实现。是运维还是开发参与的多？

A：生产环境上稳定性是第一位的。CentOS6.5 主要是运维负责全公司的统一维护。我们会给运维在大版本升级时提建议。同时做好虚拟化本身的稳定性工作。

Q：请问容器和容器直接是怎么通信的?网络怎么设置？

A：你是指同一台物理机上的吗？我们目前还是通过 IP 方式来进行通信。具体的网络可以采用网桥模式，或者 VLAN 模式。我们用 Open vSwitch 支持 VLAN 模式，可以做到容器间的隔离或者通信。

Q：你们是使用 nova-api 的方式集成 Dcoker 吗，Docker 的高级特性是否可以使用，如 docker-api，另外为什么不使用 Heat 集成 Docker？

A：我们是用 nova-docker 这个开源软件实现的，nova-docker 是 StackForge 上一个开源项目，它做为 nova 的一个插件，替换了已有的 libvirt，通过调用 Docker 的 RESTful 接口来控制容器的启停等动作。使用 Heat 还是 NOVA 来集成 Docker 业界确实一直存在争议的，我们更多的是考虑我们自身想解决的问题。Heat 本身依赖的关系较为复杂，其实业界用的也并不多，否则社区就不会推出 Magnum 了。

Q：目前你们有没有容器跨 DC 的实践或类似的方向？

A：我们已经在多个机房部署了多套集群，每个机房有一套独立的集群，在此之上，我们开发了自己的管理平台，能够实现对多集群的统一管理。同时，我们搭建了 Docker Registry V1，内部准备升级到 Docker Registry V2，能够实现 Docker 镜像的跨 DC mirror 功能。

Q：我现在也在推进 Docker 的持续集成与集群管理，但发现容器多了管理也是个问题，比如容器的弹性管理与资源监控，Kubernetes、Mesos 哪个比较好一些，如果用在业务上，那对外的域名解析如何做呢，因为都是通过宿主机来通信，而它只有一个对外 IP？

A：对于 Kubernetes 和 Mesos 我们还在预研阶段，我们目前的 P 层调度是自研的，我们是通过 etcd 来维护实例的状态，端口等信息。对于 7 层的可以通过 Nginx 来解析，对于 4 层，需要依赖于 naming 服务。我们内部有自研的 naming 服务，因此我们可以解决这些问题。对外虽然只有一个 IP，但是暴露的端口是不同的。

Q：你们有考虑使用 Hyper Hypernetes 吗？实现容器与宿主机内核隔离同时保证启动速度?

A：Hyper 我们一直在关注，Hyper 是个很不错的想法，未来也不排除会使用 Hyper。其实我们最希望 Hyper 实现的是热迁移，这是目前 Docker 还做不到的。

Q：你们宿主机一般用的什么配置？独立主机还是云服务器？

A：我们有自己的机房，用的是独立的服务器，物理机。

Q：容器跨 host 通信使用哪一种解决方案？

A：容器跨 host 就必须使用 3 层来通信，也就是 IP，容器可以有独立的 IP，或者宿主机 IP＋ 端口映射的方式来实现。我们目前用的比较多的还是独立 ip 的方式，易于管理。

Q：感觉贵公司对 Docker 的使用比较像虚拟机，为什么不直接考虑从容器的角度来使用，是历史原因么？

A：我们首先考虑的是用户的接受程度和改造的成本。从用户的角度来说，他并不关心业务是跑在容器里，还是虚拟机里，他更关心的是应用的部署效率，对应用本身的稳定性和性能的影响。从容器的角度，一些业务方已有的应用可能需要比较大的改造。比如日志系统，全链路监控等等。当然，最主要的是对已有运维系统的冲击会比较大。容器的管理对运维来说是个挑战，运维的接受是需要一个过程的。当然，把 Docker 当成容器来封装应用，来实现 PaaS 的部署和动态调度，这是我们的目标，事实上我们也在往这个方向努力。这个也需要业务方把应用进行拆分，实现微服务化，这个需要一个过程。

Q：其实我们也想用容器当虚拟机使用。你们用虚拟机跑什么中间件？我们想解决测试关键对大量相对独立环境 WebLogic 的矛盾？

A：我们跑的业务有很多，从前台的主站 Web，到后端的中间件服务。我们的中间件服务是另外团队自研的产品，实现前后台业务逻辑的分离。

Q：贵公司用 OpenStack 同时管理 Docker 和 KVM 是否有自己开发 Web 配置界面，还是单纯用 API 管理？

A：我们有自研的 Web 管理平台，我们希望通过一个平台管理多个集群，并且对接运维、日志、监控等系统，对外暴露统一的 API 接口。

Q：上面分享的一个案例中，关于 2.6 内核 namespace 的 bug，这个低版本的内核可以安装 Docker 环境吗，Docker 目前对 procfs 的隔离还不完善，你们开发的 container tools 是基于应用层的还是需要修改内核？

A：安装和使用应该没问题，但如果上生产环境，是需要全面的考虑的，主要还是稳定性和隔离性不够，低版本的内核更容易造成系统 crash 或者各种严重的问题，有些其实不是 bug，而是功能不完善，比如容器内创建网桥会导致 crash，就是 network namespace 内核支持不完善引起的。我们开发的 container tools 是基于应用的，不需要修改内核。

Q：关于冗灾方面有没有更详细的介绍，比如离线状态如何实现数据恢复的？

A：离线状态如何实现恢复数据，这个我在之前已经回答过了，具体来说，是用 dmsetup create 命令创建一个临时的 dm 设备，映射到 docker 实例所用的 dm 设备号，通过 mount 这个临时设备，就可以恢复出原来的数据。其他的冗灾方案，因为内容比较多，可以再另外组织一次分享了。你可以关注一下 mogu.io，到时候我们会分享出来。

Q：贵公司目前线上容器化的系统，无状态为主还是有状态为主，在场景选择上有什么考虑或难点？

A：互联网公司的应用主要是以无状态的为主。有状态的业务其实从业务层面也可以改造成部分有状态，或者完全不状态的应用。不太明白你说的场景选择，但我们尽量满足业务方的各种需求。

---

2015-10-28： OCI 标准和 runC 原理解读

Q：对容器热迁移听得比较少，也比较好奇，想问问热迁移的时候容器依赖的文件系统怎么解决，是直接 copy 到目标机吗，可否使用公共网络文件系统解决呢，还有对目标机有什么特殊要求吗？

A：依赖文件系统要保持一致。最好事先在目标机预置文件系统。有些容器涉及到不能迁移的设备之类的，那么这个容器则不能被迁移。目标机的 OS 位数要一样。

Q：解 runC，问下和 Docker 对比，有那些不同，又有什么优势？

A：runC 的优势体现在轻量级和标准化，这是 Docker 没有的。而 Docker 那一套庞大的体系，也是 runC 没有的。

Q：dumpfiles 是可以持久化的吗，还是仅仅用于一次性的热迁移交换？

A：保存在硬盘，可以进行多次使用。

Q：CRIU 热迁移网络配置信息会保存么，还有就是大概热迁移延时是多少？

A：只要设定了参数就会保存，热迁移的延时这个要看你配套设施和配套软件。

Q：我对这个热迁移没了解过。想问下，这个热迁移主要是迁移配置 rootfs 么，能迁移当前的容器状态么，比如正在进行的计算？

A：是的，这个要在对应的机器上有对应的 rootfs 才能迁移。状态什么的都可以迁移。

Q：那是不是意味着我可以利用 CRIU 工具把容器固化下来，类似于虚拟机的快照，以便在未来的某个时刻进行恢复或者迁移？

A：是的，就是这样。以的，容器内的状态都可以迁移。

---

2015-10-20：中兴软创（ZTEsoft）基于 Jenkins 和 Docker 的 CI 实践

Q：你好，问一个问题，我们前段时间也把 Dubbo 框架运行在 Docker 里面，也是采用你们现在的把宿主机和端口作为环境变量传入的方式实现的，我比较想了解的是后继你们有什么更好的方式实现，我看你提到了基于 OVS 的方案？

A：有两种解决办法：1. 一种是将显式传递环境变量做成隐式的自动获取宿主机和端口，从而减少配置工作；2. 另一种则是通用的 Open vSwitch（OVS）方案，这是与 Dubbo 无关的。

Q：容器中的 Dubbo 注册问题，扩展 Dubbo 的 protocol 配置，增加 publishhost 和 publishport 解决了注册问题，能不能说的详细一点？

A：目前我们硬编码了 Dubbo 的 protocol，在里面加了两个字段，这种扩展方式有点野蛮，但 Dubbo 本身提供的扩展方式目前很难支持传递环境变量方式，我们在考虑将环境变量隐式获取，这样就不用硬编码了。

Q：你们用的还是端口映射吧，那么也会存在很多个端口的问题吧，像 IP 可以访问一样？

A：在这个项目中作端口映射是运营商的要求，他们要求能通过配置来设置每个容器的端口映射，这与他们现有的运维方式有关，一开始我们考虑的是 docker 的自动端口映射，当然这种需求将来肯定是趋势，我们的”云应用管理平台”中也有考虑。

Q：为何考虑 Dubbo 而不是 etcd 做服务发现，Dubbo 的优势是什么？

A：选中 Dubbo 是很偶然的，公司本身有 ESB 产品，但相对来说比较重，一般用于多个产品间的调用，而 Dubbo 我们一般用于产品内部多个模块之间的调用，是一种轻量级的服务总线，Dubbo 这种方式不依赖于硬件和操作系统，etcd 并不是所有操作系统都能支持的吧，当然我也没有对 etcd 作深入的研究。

Q：Jenkins 的 slave 是选用了虚拟机还是直接物理机？

A：我们的 Jenkins 的 master 和 slave 都是用的虚拟机。

Q：代码提交上去，如果测试有问题，回滚是肿么处理，也是通过 Jenkins？

A：这里要分情况来说，一种是测试发现问题，提单子给开发修改，开发修改完代码提交到 scm，然后触发 Jenkins 下一轮的编译和部署；另一种情况是如果某次部署失败，则会用部署前的备份直接还原。

Q：请问用的 Registry V1 还是 V2 ，分布式存储用的什么，有没有加 Nginx 代理？

A：目前我们用的是 V1。生产环境多是集群环境，需要加 Nginx 作分发。目前应用中分布式存储用的并不多，一般来说用 hdfs 来存储一些日志便于后面分析，也有用 FastDFS 和 MongoDB 的。

Q：底层云平台用的是私有云？

A：底层平台一开始想用私有云，但运营商已经有了 vCenter 的环境，因此后来我们改用 Ansible 来管理各类物理机和虚机，用 Docker API 来管理容器。

Q：Dubbo 实现的服务发现是否具备 failover 功能，自动检测并迁移失败容器？

A：Dubbo 目前不具备迁移容器的功能，其 failover 是通过负载均衡和心跳连接来控制的，自动检测和容器迁移我们一般会考虑放在监控系统里面来做，如果放在 Dubbo 里面会加重 Dubbo，只所以用 Dubbo 也是考虑到它的轻便性。

Q：能否谈下对 Jenkins+Mesos 的看法，这个涉及到 docker-in-docker 的必要性？

A：Mesos 我们才刚刚接触，我了解的不太多，至于 docker-in-docker 我觉得生产上很难用，因为性能方面损失比较严重，我们做过性能测试，非 --net=host{.prettyprint}方式的容器性能损失接近 30%。

Q：能具体介绍下利用 Dockerfile 打包镜像吗，jar 包也是在这一步编译出来的吗，这样发布出去的镜像会既包括代码又包含 jar 包吧？

A：我们的镜像中是不包含代码的，镜像里面是产品包，编译是在打镜像之前做的。

Q：对不生产环境中不适合以容器运行的组件，Jenkins+Docker 是否就没有优势了？

A：开发和测试环境还是很有优势的，当然有些有大量 IO 操作的服务其实不适合放在容器里面，这主要是性能方面的考虑。

Q：云平台是怎么管理容器的，有没有使用 Docker 生态系统相关的组件？

A：目前没有用到 Swarm\Compose 之类的组件，将来要看这块的发展了，也有可能会引入 k8s 或者 Mesos 来作管理，这些目前都在考虑当中

Q：在怎么判断部署 Docker 服务不可用，不可用后自动迁移还是如何操作？

A：目前云应用平台只在发布时才对 Docker 容器进行状态检测，如果检测到失败，会根据指定的容器数目进行重新创建。后续我们会把对容器状态的持续检测统一放到监控系统中。

Q：我是不是可以这么理解，你们的 Jenkins 是主要用来 CI，而实际集群管理则是云应用平台做的？

A：是的，这个是严格分工的，当时作云应用管理平台时，是以测试交付物为起始点的，这里的测试交付物就是 CI 的产物，容器方式下就是镜像了。

Q：我可以理解 Docker 是部署在实体机，实体机上都有一个 agent 的东西负责与管理端通信，主要负责 Docker 的管理（安装，部署，监控等）吗？

A：我们的 Docker 目前都是部署在虚拟机上的，操作系统是 Redhat7.1，你所谓的 agent 其实应该就是 Docker daemon 吧。

• 徐新坤：这个我补充一下，作为 Jenkins 的 slave，会向 slave 里面启动一个 agent 来执行相关脚本命令的。这个属于 Jenkins 的功能，可以去体验下。

Q：一个应用多个容器你们怎么负载均衡？

A：前面其实回答过，要加 Nginx 的。

Q：利用 Dockerfile 打包镜像并上传到 Registry 更像是 CD 环节的事情，那在单元测试、集成测试环境是否有利用到 Docker 呢，是否使用 Jenkins 中 Docker 相关的插件了？

A：当前项目的单元测试、集成测试都用到 docker 容器的。Jenkins 中没有用 Docker 插件，试过感觉都不太成熟，目前还是 Docker 命令行最方便。

Q：开始的时候有讲如果没有 Docker 自动部署会自动部署，这个是如何部署的？

A：这个前面讲过，是通过 lftp 脚本比对编译环境与待部署的远程目录。

Q：也就是你们在虚拟机里面部署的 Docker？

A：是的，当前的项目是在虚拟机里面部署 Docker 的，但我个人观点从长远看来，其实在物理机上部署 Docker 会更好，所以现在很多私有云比如 OpenStack、CloudStack 都能支持直接管理容器，不过目前虚拟机还是不能缺少的，容器的隔离性不如 VM。

Q：如果用 nat 模式 容器如何指定 IP 啊？

A：不需要指定容器 IP，只需要映射端口。

Q：有通过 Dubbo 做服务路由么？

A：Dubbo 本身就有服务路由的功能。

---

2015-10-17：Docker Registry V1 to V2

Q：想问下，那你们的 layer 数据是不是要存两份，V1、V2 各一份？

A：是要分开存两份的，因为他们的格式其实都是不一样的一个是 tar 包一个是 gzip 包，但内容一样。

Q：为啥 tar 变为 gzip 会耗费 CPU 和网络，不就是不同的压缩格式么?

A：网络其实是节省的，但是压缩是很耗 CPU 的 tar 其实并不太消耗。

Q：V1 如果做些优化，一次获取 Ancestry，然后并行下载 layer，是不是也可以提高吞吐量么？

A：理论上是这样的，我看 1.8 的代码在 pull v1 也一次会拿到所有的 Image ID 但是并没有去并行下载，估计 Docker 自己把这块放弃了吧。

Q：请问，您提到的利用 Registry 的 hook，来获取 image 更新的信息，指的是利用 Registry 的 notification API？

A：V2 是这样，V1 是自己在 Registry 那里做了个 hook。

Q：请问关于镜像删除的问题，V2 的删除感觉坑很多，如何删除，还有，如果同一个镜像名称及版本但是内容并不同的镜像重复 push，有没有办法检测，以及同步？

A：我们用的 AWS 对象存储，存储还比较便宜，所以没太关注，GitHub 上有一个 v2 gc 的项目可以删除无用镜像，官方叫着做停机 gc，叫了好久了，目前还没实现，只能自己造轮子了；重复 push 和刚才提到的乱序类似，我们会保证这种情况是串行的。

Q：V2 这么不成熟，眼下上还是不上，push 到 V2 registry 的 image 能不能查询？

A：我们当初的想法是照着 Docker 这么任性的态度，没准 1.8 就不支持 V1 了，所以就赶紧调研用上了。查询没有直接的 API，我们很多 tar 没有的 API 都是自己造轮子造出来的。

Q：V2.1 后，Registry 提供一个叫 catalog API，具有一定 image 搜索的功能，但还不够完美？

A：catalog 会遍历整个存储消耗还是蛮大的，可以通过 catalog 做离线，然后 notify 做实时更新来实现 search 的一个索引。

Q：请问，灵雀云的 registry backend storage 是什么类型，文件系统么，理由是什么？

A：直接 AWS 在中国的 s3，目前官方支持的最好的，不用自己造轮子，就酱紫。

Q：针对 V2 的 auth 方式，有没有什么好的建议，对于平台类的开发？

A：我的建议是使用 token auth 的方式，虽然复杂一步到位，可以做一些复杂的权限认证。类似的项目还是：https://github.com/SUSE/Portus，不过建议每次 Docker 版本更新都跟着测一遍。

Q：有没有类似 docker auth 的项目？

A：SUSE/Portus 一个开源的 auth server，但是比较坑的是 Docker Engine 老变，一升级可能就不一样，我们自己的 auth server 也改了好几次。

Q：由 V1 升级到 V2，为什么非得把旧仓库上的镜像迁移到新的 V2 这么折腾，直接两个版本并存一段时间不行吗，新上传用新的 V2 的 url，如果要回退旧版本旧库上镜像 url 也还有吧，一段时间后旧库就能退役了？

A：因为我们有用户的 push 而用户很多还在用旧版本，也有用户发现新版本不合适回滚的，如果只顾一头用户一变就发现镜像没了。

Q：alauda 云 push 的时候 443 端口拒绝连接怎么办？

A：这个应该不会吧……，可以先下再联系复现一下，我们的两个版本 Registry 都是走 HTTPS 的。

Q：V2 好像仍然没有解决 Registry 最大的痛：单点，你们怎么对待这个问题的？

A：Registry 一直都是可以水平扩展的，只是一个 HTTP 的服务器是无状态的不存在单点问题。

Q：企业私有云场景下用多个 Registry 实现 HA 该如何选择后端存储，京东的 Speedy 是否合适？

A：Registry 有 Swift 的 driver 私有云可以考虑，或者根据已有的情况选择自己的存储自己写个 driver 也是可以的，写的难度其实不大，七牛那个一个下午就能写出来。要求不高的话还是不难的。京东的不是太了解，我觉得主要看现有的技术框架和产品选一个易上手的就行。把 Registry 水平扩展挂载 lb 后面就好了。

Q：V1 已经被官方 deprecated，V2 仍然缺少一些基本的管理 API，请问现在私有 Registry 升级到 V2 是否还为时过早？

A：看需求了吧，我觉得要是稳定考虑 deprecated 也没啥影响，V2 的很多好处确实在私有云表现不出来，反而会有一些表现不如 V1 的地方。

Q：用七牛海外加速之前用哪种方案的？

A：我先答一下这个吧，这个挺有意思的，我们发现一个 tcp 的拥塞算法是用于卫星通信的，卫星这种高延迟高丢包的拥塞算法貌似还蛮合适国外往国内传数据。

---

2015-10-14：企业级云平台的实践和思考

Q：你认为面向资源和面向应用架构的区别是？

A：一个关注的资源的供给，一个关注应用的架构、实现第 2 个其中会有一部分资源的申请、管理问题。面向应用更关注业务，所以上层的应用往往叫做负载管理系统或任务管理系统。

Q：大数据 HDFS 是在虚拟机 VM 里面还是真实物理机里面？

A：建议不要使用虚拟机，除非能将 IOPS 搞到类似物理机的程度，或者就是用来做算法验证，要不对存储系统冲击太大。

Q：目前作者分享的一般都是基于互联网，针对企业级其实也有类似的技术，具体有哪些，怎么实现？

A：我介绍的第一个产品 EGO 就是完全面向企业的，主要给金融等领域使用，比如花旗银行，倒闭的雷曼兄弟等，现在也在电信等行业使用，互联网行业基本没有用户。

Q：在服务化的过程中，架构如何同时兼顾老的非服务化的部件和服务化的服务？

A：其实我们有个实践就是，有的服务或部件就让它随着时间 over 吧。重要的考虑云化，实在不行考虑盖个帽子封装成服务，就是经典的设计模式中的门面，adapter 等的在服务层面的使用，也可以叫做服务网关之类的。

Q：你们是如何对集群资源做到细粒度的管理的，能说说你们遇到过哪些坑吗？

A：主要通过设计了资源组和各种资源 tag 来过滤资源，同时设计了一种规则语言和引擎支持 select、order，支持各种数学运算和与、或非的逻辑关系来让用户定义资源的需求。最大的坑其实就是资源粒度定义有点问题，一度都出现零点几个 slot 的情况，其实简单点就好了，甚至随机分配都会有个很好的效果，毕竟这个宇宙也是混沌的，呵呵。当然只是个人的看法，其他人不一定同意。

Q：你们肯定有考虑过硬件资源使用情况负载的问题，Docker 容器上前段时间倒是出了监控宝，可以监控容器的各种资源使用情况，但是想问下今天您提到的”应用的资源使用情况”，你们是做的实时监控吗？这个是怎么实现的？

A：原来 EGO 的调度策略一直有个基于负载的规则，LIM 会准实时的收集系统的负载，包括 CPU、MEM、DISK 等信息然后汇总到 master LIM 供 EGO master 使用。天云的系统构建了一套自己的监控体系、也支持 zabbix 采集信息，还支持名的 APM 公司 newrelic 的 agent 协议，另外也开放了 API，可以自己定制监控采集系统。监控宝我们也看过，类似的都有几个，不过这是应用开发团队需要自己选择的。

Q：Auto Scaling 过程中是需要停止服务吗？

A：不需要停止服务，参考 AWS 和具体业务，我们设计了多个 AutoScaling group，一部分用于系统基本运行需要的最少的资源，其他则为动态改变的，也就是说会保留最少的服务节点。

Q：天云的云平台如何解决单点问题，除了热备冷备，实现了分布式吗，怎么实现的，分布式的事务怎么处理的？

A：天云云平台一开始就是 Load Balance 模式设计，类似 OpenStack，单点主要就是数据库。DB 的问题也是采用常规的做法，当然也可以采用类似 etcd、zk 的方式，不过规模大不了。

Q：我觉得云平台最吸引人是弹性调度，能否就弹性调度如何实现这个问题，分享些经验给我们？

A：个人建议，多研究一下 AWS 的 autoScaling 服务，比如 QingCloud 的调度服务其实也是它的简化版。它支持定时、手动、规则驱动等触发方式，对执行的动作也有很多可配置的方式，比如发消息、自动执行动作等。

Q：EGO 中对容错机制是怎么理解的么，能否讲下？

A：EGO 的容错分了 2 部分，一部分是系统本身的，主要靠共享存储来保存核心数据，然后每个模块做到可以随意重启。应用主要靠其中的 egosc，它会监视应用的模块，做到按照定义的规则执行重启等动作，应用本身的数据一致问题，则要应用自己处理。

Q：能介绍下 Symphony 在 DCOS 中的作用么？

A：Symphony 整体是个 SOA 的任务或负责管理系统，底层需要一个资源管理系统，类似 Hadoop、Habase 与 Yarn 的关系。

Q：EGO 核心 Master 它是基于插件的架构，支持热插拔吗？

A：没有采用热插拔。因为系统的每个组件都能够做到重启不丢数据，启动时会和相关模块同步数据并纠正不一致的地方，所以对系统稳定运行没有影响，类似 Google 的思路，做到每个点都能很容易的重启。

Q：能否介绍一个典型的调度器实现策略?如何考虑资源和需求的？

A：简单来说，就是将所有的资源请求先放到队列中，然后针对请求采用背包算法，或者线性规划算法来找一个次优解就行。因为要近实时的给出资源分配结果，所以没有最优解。

Q：云平台的容灾措施是怎么样，有什么好的方案？

A：容灾关键还是数据，关键在企业的存储设计，我也没有太多建议。

Q：Docker 网络选择是 host 还是 nat，性能损失分别是多少？

A：Docker 网络真实只在自己环境管理自己 SkyForm 使用过，其他的都是实验室环境，没有真实线上环境测试，没法给出实际数据，建议去看一下新浪、雪球等公司的建议。当前只是在一些项目中实验 Docker，没有大规模去推。

Q：目前我们都提倡服务抽象、组合化，我们目的是为了向稳定、便捷的方向进取，那么，我想问是着重管理，还是着重技术功能方向呢？

A：具体分析，建议按照建设、实用、运维、优化管理的次序来考虑。

---

2015-10-08：容器和 IaaS：谁动了谁的奶酪

Q：容器当做虚机，CloudFoundry 现在能很好的支持 Docker Hub 的用法吗，如何做到的？

A：很抱歉我不是容器的专家，对各个容器编排系统了解也有限。第一个问题我无法回答，因为我没有研究过 CloudFoundry 对 Docker Hub 是如何支持的。但从技术上来说，IaaS 支持 Docker Hub 没有技术障碍。我以大家熟悉的 OpenStack 举例，Glance 完全被 Docker Hub 做成一个后端，用户无需上传 image，只要输入自己的账号，就可以浏览和下载 image 到 cinder 这样的块存储服务。将来 ZStack 对 Docker Hub 的支持也是这个思路，即把 Docker Hub 做成我们的 backup storage 的一个后端插件。

Q：『Mesos 是在大规模集群生产环境中运行 Docker 的黄金搭档。』对这句话你的看法是？你提到的容器编排系统，是否指 Mesos，还是指 Docker Swarm 或 Kubernetes?

A：我指的容器编排系统主要就是 k8s、Mesos、Rancher 这些。他们的主要方向还是奔着 App-Centric 去的。至于谁是 Docker 的黄金搭档我不知道，我感觉每家都说自己是最佳选择和黄金搭档。当然这是因为他们对我国的新广告法不太了解。

Q：容器适配不同的 IaaS：容器是对操作系统的虚拟化，对网络、计算、存储的适配是操作系统的基本功能，容器适配不同的 IaaS 应该自然就有的功能吧？

A：容器适配 IaaS 主要是指容器的编排系统可以通过 IaaS 的 API 去获取自己需要的计算、网络、存储的资源。例如通过 IaaS 的 API 去创建虚机，拿到虚机的 IP 地址去部署容器；又例如使用创建私有网络等功能。好的 IaaS 必定是提供全 API 给容器编排系统使用的。这样容器编排系统可以专注往上做，做 DevOps 的功能，而不是把精力浪费在管理存储、网络这些它自己不删除的东西。比如说容器编排系统去编程硬件交换机配置网络，我认为就是方向走偏了，是在做 IaaS 的东西。

Q：能不能详细点解释一下 App-Centric 是什么样的？

A：App-Centric 要解释清楚比较难，这个跟 Microservices、Cloud-Native Apps 一样。要用简单的几句话解释清楚是比较难的。我个人简单理解是，App-Centric 的编排系统的核心是应用的的部署、管理、发布、持续集成，一切功能以应用为中心设计。如果编排系统的核心是管理计算、存储、网络的硬件资源，那这个是 iaas 的编排系统，就不是 App-Centric 的。

Q：问一下轻量级的 IaaS，除了 ZStack 还有哪个比较成熟？

A：我当然想说是 ZStack。我看到后面有几个关于问 ZStack 的问题，为了避免在这次分享上打广告，我就不详细讲了。欢迎大家访问我们的网站 zstack.org/cn，我们有 16 篇技术文章讲我们的不同和优势。另外关于跟 OpenStack 和 CloudStack 的对比，大家百度一下 ZStack、OpenStack、CloudStack 就可以搜到几篇业内人士写的对比文章。

Q：虽然有京东和 360 案例，但你支持把容器当虚拟机使用吗，为什么？很多人曾经很质疑这种方案，包括我也反对。

A：这个问题很难说支持和不支持，我刚才也说了，技术人员有自己的情怀和初衷，但市场是用脚投票的。用户选择了这样的方式一定有他自己的理由，没有对错之分。运维人员有一句话叫没有绝对好的技术，只有最适合的技术。其实很容易理解为啥大家会把容器当虚机用，因为已有的存量系统都是基于虚机设计的，要为了容器的出现而重写业务系统，我认为除非有巨大的痛点，否则很少有公司会主动去这么做。当然，很多新兴互联网公司，在没有历史包袱的情况下，我非常赞同以新的方式去构建业务系统，但这也不是那么容易的。借 Netflix 团队的一句话说：你看到了我们现在微服务做的这么好，是因为我没告诉我们填过多少坑。

Q：请问 IaaS+APP 是怎样的一个架构呢，在您最后一段分享里”因为大部分运维人员和开发人员，最熟悉的还是以虚机的方式构建应用，当容器带来了更快、密度更高，更轻量级的虚拟化技术时，大量的存量系统还是以他们最熟悉的方式，就是虚机方式来使用容器技术。这个现实，为传统 IaaS 带来了巨大的机会。”，可以简单介绍下”为传统 IaaS 带来了巨大的机会”中有哪些机会吗？

A：这个巨大的机会就是让我们反思大而重的 IaaS 系统到底是不是客户所需要的，IaaS 系统自身是否需要做减法做虚拟化 +。因为我们看到使用容器的很多公司，他们没有 SDN，没有分布式存储，一样把业务搬迁到容器上了，运行的很好。那么现在大而重 IaaS 系统设计，是不是路走偏了，我们是不是能够把 IaaS 简化，提供最方便、最可靠、最容易的方式让容器使用 IaaS，而不是让容器因为 IaaS 的大而重拒绝 IaaS 而自己去做 IaaS 的功能。

• 林帆：容器和虚拟机本质上只是实现虚拟化的两种方式，一开始初衷不同，之后由于用户习惯而产生一些交叉，最终而言容器的应用场景还是会趋于 PaaS 化的。没记错的话，在京东和 360 的例子里，是先经过了 Docker 做虚拟机这样的过渡时期吧，但最终的目标同样是真正将容器的分布式调度、编排的优势发挥出来，也就是走向类似 PaaS 的方向。

Q：我的理解是容器做虚拟机使用这个过程更多的存在于产品底子已经比较重的企业，很多互联网企业会直接从容器的 PaaS 模式开始，不知道你怎么看这个观点？

A：nova-docker 不热是正常的，因为这种虚机用法不是容器社区的主流。k8s、Mesos 是主流。但大家要认识到开发者圈子里的热并不代表市场热，技术圈是一个最容易自 high 的群体。当 Hype Cycle 过渡到谷底时大家才能看清楚到底市场需要的是什么技术。ZStack 目前没有计划推出 k8s 这样的编排系统功能，技术上不是问题，我们的架构是编排系统的通用设计，用同行的评价说你们去做 12306 都没问题。我们的主要的考虑是要专注，当一个软件号称什么都能做，什么功能都有的时候，通常意味着它什么都做不好，用户也会搞不清楚这个软件到底要解决什么问题。但我们之后一定会推出虚拟机用法的容器集成，这个对我们来说非常简单，而且也看到很多用户在这样用了，所以我们一定会去做。

Q：怎么理解什么是轻量级的 IaaS，和现在的会有哪些变化和区别？

A：这个前面一个问题谈到了。即现在大而重的 IaaS 设计不一定是市场需要的。举个例子，OpenStack 在新版本里面去掉了 nova-network，部署传统的扁平网络也需要用 neutrons，这个我认为就是重了。轻量级的 IaaS 就是要使用最稳定、最简单的技术去实现用户的使用场景。而不是期望用一种技术就能够解决所有场景，这样只会越做越重，越做越复杂。

Q：问一个计算的问题，我们的程序需要用到大量的 GPU 资源，容器理论上应该是可以和 CPU/存储一样高效率使用的吧，有什么限制吗？

A：理论上是可以的，CPU/存储的使用效率即使用传统虚拟化也已经比较高了，但 IO 相对于容器来说，路径太长有性能损失。使用容器是可以很大程度上缓解这个问题，这个也是为什么我们以前 HPC 用一个一台物理机一个容器的方案。

Q：你怎么看 hyper.sh 和 clear container 等超轻量级 hypervisor 对容器技术的影响？

A：hyper.sh、clear container 解决的主要是容器的隔离性、安全性的问题。它们没改变容器社区倡导的主流。比如 hyper.sh 的用法跟 Docker 就很类似。所以我认为他们是对容器社区的补充。当然，半个月前我也在跟 Intel 的虚拟化团队沟通，建议他们做轻量级的虚机，因为我们感觉到市场对这个的需求还是很强的。

Q：ZStack 跟 OpenStack 下的 Magnum 有什么相同点和区别？

A：完全没有相同点。我们还是纯 IaaS，没有为容器做特别的编排系统。

Q：因为我是 HPC 出身，我想问一下，算法开发绕不过去的 Intel Cluster Studio 怎么办，授权怎么处理。我们在开发算法的时候需要深度依赖 MKL 你们是怎么处理的。另外就是 GPGPU computing 貌似还没正式支持，这方面容器技术怎么处理呢？

A：我们只是提供计算资源，应用层面、业务层面是用户自己需要解决的。我不认为容器可以帮助解决这些问题。

Q：目前 ZStack 有没有什么成功案例吗？

A：有的，我们已经有客户使用开源版生产上线几个月了。

Q：我的理解是容器做虚拟机使用这个过程更多的存在于产品底子已经比较重的企业，很多互联网企业会直接从容器的 PaaS 模式开始，不知道你怎么看这个观点？

A：这个取决于企业的历史包袱多重。老牌互联网公司的业务系统也很成熟稳定了，要完全改成容器的 PaaS 模式，例如容器单进程，不是用 SSH，我个人觉得还是有一定难度，而且企业切换的意愿也不见得强烈，但在新业务系统里面使用 PaaS 的容器模式是非常可能的，我也知道很多公司正在这么做。

Q：如何摆脱网络的依赖来创建个 Docker 的 image 呢，我觉得这个是 Docker 用户自己的基本权利？

A：这个基本权利我觉得还是要问 GFW。国外的开发人员是非常难理解有些他们认为跟水电一样普及的基础设施在某些地方还是很困难的。

Q：我认为 PaaS 和 IaaS 是不可分的，现在人为分开是有问题的，长久必然和二为一，楼主怎么看？在合二为一的前提下，也不存在容器和 IaaS 之争了。

A：其实从用户的层面来说他们是不分的，他们只关心自己的业务。但从开发人员的角度来说还是要分的，因为这个是理清楚自己软件的界限，对软件的架构和设计都非常重要。未来的产品可以提供 IaaS 和 PaaS 打包的产品交付给客户，但开发自己还是要分清楚产品里面那些是 IaaS 的东西，哪些是 PaaS 的东西，否者很难做产品，做设计。

Q：真正 App-Centric 的是 SaaS，容器编排顶多算 PaaS，或者说是 PaaS+IaaS（PaaS、IaaS 相互依存的），跟 SaaS 没啥关系吧？

A：这个前面也回答了。编排系统的 App-Centric 我认为是指编排系统的核心功能是围绕什么服务什么设计的。围绕部署、分发、管理、运维、持续集成的应该算 App-Centric 的编排系统。围绕计算、存储、网络的算 IaaS。

Q：你认为以后的趋势是容器只要配合轻量级别 IaaS？SDN 那些网络存储都不用考虑，那重 IaaS 又应用在什么场景?

A：我是指大部分用户场景使用轻量级的 IaaS+ 容器就足够了。因为现在很多容器应用也没有使用到 SDN、SDS 这些技术，也已经非常流行了。SDN、SDS 解决了很多传统技术的痛点，当然他们也不是银子弹，对用户的要求也是比较高的。所以我的看法是不能用新技术去硬套所有的场景。重的 IaaS 我认为适合公有云场景、大规模私有云场景的容器使用，需要用户有较强的 IT 运维团队，解决复杂环境下多租户的容器使用问题。

---

2015-10-02：暴走漫画的 Docker 实践

Q：统计某个板块同时在线人数的变化趋势。

A：用户每次访问都有日志，日志里包括访问内容以及用户标识。首先 spark stream 从日志里抽取出特定板块不同用户的访问事件，以秒为单位合并相同用户事件。

Q：请问 Docker 是部署在裸机还是虚拟机，Docker 的管理用的什么？部署是人工吗？

A：Docker 是跑在国内某云主机上的，所以应该算虚机。

Q：传统关系数据库怎么 Docker 化的？

A：我们传统关系数据库并没有 Docker 化，一方面我们直接用的云主机提供的 sql 数据库服务，另一方面，也许这部分原有的方案太成熟，短期 Docker 完全取代可能比较困难。

Q：每台机器上都部署 Logstash，那 filter 部分在哪处理？为什么不用 syslog 来转发日志到日志服务器？

A：filter 部分是通过 spark stream 来做的，Logstash 纯粹收集转发，kafka 是一个 MQ 系统，而且实时分析从 Kafka 到 spark stream 很方便。

Q：如何做微服务拆分的，经验是什么？

A：这个问题我感觉有点大，我尝试回答下：先做好详细的计划，尽量保证服务的平稳过渡，必要的时候，老系统和新系统同时保留一段时间。

Q：Docker 用的时候可以挂载存储？就是想把静态的网站图文数据 Docker 化，这些静态文件我们存储在单独的分布式存储和阵列中，走的 nfs 协议和私有 api 的形式。

A：这个放 image 里好像不是好主意，要不用一些分布式的存储方案，要不用云存储服务?

Q：”一份 copy 存到 hdfs 里”考虑过其他的存储吗？

A：Spark 有方便的对 hdfs 的接口，且云服务商有现成的 hdfs 服务提供，所以我们就用了。

Q：为什么选择 Logstash，而不选择 Flume，它们有什么差异，比如对安装端的资源开销投入产出比等？

A：最近在研究用 heka，开始用 Logstash 的话是因团队本身的知识偏好(Ruby 团队)。

Q：我觉得在数据服务部分讲了太多，我更想知道 Docker 在开发，测试或生产环境怎么使用，利用什么方式管理 Docker 集群，部署服务？比如那个 shell+etcd 来启动 Docker 是怎么回事，为什么不用一些 Docker 生态相关的开源工具，比如 k8s、swarm 之类？

A：关于为什么没用 k8s。我开始也说了，选择技术架构不光要考虑技术本身，还要考虑团队资源，以及现有的限制。我们用的国内的云主机，这样的前提下要在生产环境中用 k8s 本身就不太可能。另外技术团队人手也很欠缺。

Q：请问 Docker 容器是如何进行远程部署和自动部署的？

A：我们用了传统的部署工具(Ansible)。

Q：Ansible 如何获取 Docker 主机列表，所有的 Docker 容器？

A：Ansible 是操作云主机的，就和以前的用法一样。

Q：请问 ping nginx 获得用户点击是怎么做的，可以详细介绍下吗？

A：将某些统计数据放在 ping 接口的参数里，这样定制 nginx 的日志可以记录下来。

Q：反垃圾系统数据库的数据是通过什么方式进入 Kafka 的，ogg、sqoop 吗？

A：样本数据的话是 rails 程序推进 mq 的。

Q：搜索引擎选 Elasticsearch 而不是 Solr，可以讲一下这样选择都有哪些考虑吗？

A：Elasticsearch 不仅仅是个搜索引擎，更是我们用来做结果聚合的 database，而且有很好的水平扩展特性。

---

2015-09-23：基于 Docker 和 Java 的持续集成实践

Q：CI 过程中 test 需要连接数据库的代码时，您在写测试案例方面有哪些经验分享？

A：单元测试不能依赖外部资源，用 mock，或者用 h2 等内存数据库替代。集成测试的时候是从接口层直接调用测试的，测试用例对数据库无感知。

Q：请问部署到生产环境是自动触发还是需要手动审批？SQL 执行或回滚是否自动化？

A：当前是需要手动触发。SQL 更新当前没做到自动化，这块正在改进，因为部署私有环境需要。SQL 不支持回滚，代码做兼容。Docker 镜像回滚没有自动化。

Q： 问一下你们的 Redis 内存版是用的什么？

A：我们用的内存版的 redis 是 spullara/redis-protocol 中的 server 实现。不过这个实现部分功能没支持，比如 lua 脚本，我们自己做了改进。

Q：介绍下 workflow 带来的好处。

A：workflow 的好处我那篇文章中有说明，如果没有 workflow，所有的步骤都在同一个配置的不同 step 实现，如果后面的失败，要重新从头开始。workflow 可以中途开始，并且每一步骤完成都会触发通知。

Q：h2 并不完全兼容 MySQL 脚本，你们如何处理的？

A：我们通过一些 hack 的办法，会探测下数据库是什么类型的，替换掉一些不兼容的 SQL，进行容错。

Q：请问你们在构建的时候，你说有些需要半个小时左右，那么构建过程的进度监控和健康监控你们怎么做的呢，如果有 build 失败了怎么处理呢？

A：CI 的每一步都有进度的，并且我们的团队通讯工具可以和 CI 集成，如果失败会发消息到群里通知大家。

Q：cleanup 脚本做哪些？

A：主要是清理旧的 Docker 镜像，以及清理自动化测试产生的垃圾数据。

Q：请问你们文件存储怎么解决的呢，使用自己的网络文件系统还是云服务？

A：文件系统支持多种 storage 配置，可以是本地目录（便于测试），也可以使云服务（比如 s3）。

Q：刚才说你们能通过一键部署，但是中间无法监控，测试环境可以这么玩，那生产环境你们是怎么做的呢？还有你们后续的改造方向是自己开发？还是采用集成第三方软件？

A：生产环境 shell 当前只能是多加错误判断。这块我们在改进，比如通过 ansible 等工具，以及使用 Kubernetes 内置的 rolling-update。自动化部署这块还没有好的开源工具。

Q：你们的测试用了很多代替方案、如 h2 代 MySQL，要保证测试效果，除了你们用的 hack 方法之外，是不是从写代码的时候就开始做了方便测试的设计？

A：对。这也是我文章中分享的观点之一。测试用例的编写人员要有业务代码的修改权限，最好是同一个人。要做自动化测试，业务代码必须要给测试留各种钩子以及后门。

Q：请问你们的集群应用编排怎么做的？

A：上面说了，还没用到编排。一直等编排工具的成熟。正在测试 k8s。

Q：你们做这个项目选型是出于什么考虑的，介绍里有提到使用一些脚本来管理容器解决开发和测试各种问题，感觉这种管理容器方式过于简单会带来管理问题，为何不用第三方开源项目来做二次开发，如：Kubernetes；另一个问题是，下一步有没有考虑如何让你的 Docker 和云服务平台结合，要解决运营成本问题（Docker 最大吸引力在这里），而不只是解决开发测试问题？

A：因为我们最早用的时候 k8s 1.0 还没有，变化太大，创业团队没精力跟进，脚本是粗暴简单的办法。一直在等待各种基于 Docker 的云解决方案呀，肯定考虑结合。

Q：对于 Docker storage 分区用完问题，我想问一下，你们是使用 Docker 官方提供的 Registry 仓库吗，如何解决仓库单点问题，这机器要是故障了怎么办？

A：Registry 用的是官方的，后端存储是挂载到 s3 上的。没有 s3,推荐使用京东田琪团队开源的 Speedy，实现了分布式存储。

Q：除了介绍的 Java 相关的 CI 方案，对于 C/C++ 开发语言有没有推荐的 CI 方案？

A：Teamcity/Jenkins 等 CI 工具支持任何语言的。其实任何语言的 CI 都差不多，单元测试，集成测试。关键还在于依赖环境的准备以及集成测试用例的管理。

Q：我看到你们为了方便测试和调试会有独立的集合 Docker 环境，这种环境和上线环境其实是有差别的，这样测试的结果能够代表线上环境吗？这种问题怎么看待？

A：所以我们有多个流程。清理数据的测试环境，以及不清理环境的沙箱环境。但这也不能避免一部分线上环境的数据导致的 bug。另外就是配合灰度上线机制。当前我们的灰度是通过代码中的开关实现的，使用这种方案的也很多，比如 facebook 的 Gatekeeper。

Q：请问 Grouk 有涉及前端（Node.js 方面的）并结合 Docker 的 CI/CD 经历吗，可以分享下吗？

A：这我们也在尝试。当前 js 的测试主要还是基于 ariya/phantomjs，纯粹的 js 库比较方便测试，但如果牵扯到界面，就比较复杂些了。

---

2015-09-15：Mesos 在去哪儿网的应用

Q：Mesos 和 Yarn 的区别在哪里？

A：Mesos 的主要目标就是去帮助管理不同框架（或者应用栈）间的集群资源。比如说，有一个业务需要在同一个物理集群上同时运行 Hadoop，Storm 及 Spark。这种情况下，现有的调度器是无法完成跨框架间的如此细粒度的资源共享的。Hadoop 的 YARN 调度器是一个中央调度器，它可以允许多个框架运行在一个集群里。但是，要使用框架特定的算法或者调度策略的话就变得很难了，因为多个框架间只有一种调度算法。比如说，MPI 使用的是组调度算法，而 Spark 用的是延迟调度。它们两个同时运行在一个集群上会导致供求关系的冲突。还有一个办法就是将集群物理拆分成多个小的集群，然后将不同的框架独立地运行在这些小集群上。再有一个方法就是为每个框架分配一组虚拟机。正如 Regola 和 Ducom 所说的，虚拟化被认为是一个性能瓶颈，尤其是在高性能计算（HPC）系统中。这正是 Mesos 适合的场景——它允许用户跨框架来管理集群资源。

Mesos 是一个双层调度器。在第一层中，Mesos 将一定的资源提供（以容器的形式）给对应的框架。框架在第二层接收到资源后，会运行自己的调度算法来将任务分配到 Mesos 所提供的这些资源上。和 Hadoop

YARN 的这种中央调度器相比，或许它在集群资源使用方面并不是那么高效。但是它带来了灵活性——比如说，多个框架实例可以运行在一个集群里。这是现有的这些调度器都无法实现的。就算是 Hadoop

YARN 也只是尽量争取在同一个集群上支持类似 MPI 这样的第三方框架而已。更重要的是，随着新框架的诞生，比如说 Samza 最近就被 LinkedIn 开源出来了——有了 Mesos 这些新框架可以试验性地部署到现有的集群上，和其它的框架和平共处。

Q：基础架构里面，数据持久化怎么做的？使用是么架构的存储？

A：持久化剥离在集群外部，Mesos 0.23 提供了持久化的支持，但是没敢上到生产环境中。

Q：Storm on Mesos，快可用了吗？是否跟 Spark on Mesos 做过比较？

A：Storm on Mesos 的代码在 GitHub 可以找到，说实话只是基础功能，许多资源的控制和 attributes 的东西都没有做，而且我们的测试发现 storm on mesos 的消息 ack 特别慢。不建议直接拿来就跑。

Q：发布用的业务镜像是怎么制作的，平台有相关功能支持吗？还是用户手工做好上传？

A：Jenkins build 的镜像，可以用 Jenkins on Mesos 这个框架，安装 Docker 和 mesos 插件就可以开始用了。

Q：做这么个平台用多大规模的团队开发的？用了多久？

A：开始 2 个人，最多的时候 5 个人，现在保持在 4 个人。从 5 月份到现在一点一点测试，扩容慢慢堆出来的。

Q：镜像存储单机应该是不行的，你们是怎么管理镜像的？

A：镜像放 swift 里了。

Q：Docker 采用 host 方式，是什么考虑或者限制，效果怎么样？

A：平台本身就是大吞吐量的，bridge 模式性能测试都偏低，就选择了 host 模式跑了。

Q：Mesos 的调度算法是怎样的？有没有做容器的高可用？

A：双层调度，底层 offer 一个资源列表给 framework，framework 根据 CPU 和内存去列表中过滤，选中合适的 slave 部署，framework 层的调度可以随意实现。Marathon 已经帮忙做了高可用。

Q：使用效果如何？600 容器部在多少台机器上，CPU 和内存使用率多少？有什么提升资源使用率的策略吗？

A：效果达到预想了，600 台分部在了混合集群上，有 VM 和实体机，全部折算的话大概 30 台左右吧，目前资源还有富余，主要是预留 buffer。不推荐跑虚拟机，Mesos 的资源分配就是一刀切，即使没用也算的，所以虚拟机利用率会很低。

Q：mesos 在哪一层面实施了 paxos 投票？

A：leader 的选举，mesos 其实是两套选举，即使 zk 挂了 mesos master 也可以自己选举 leader。

Q：为什么选择 heka，而不是 fluend，然后 logstash 有什么问题？

A：fluent 和 heka 我们都在用，都是收容器日志，heka 可以从容器的 ENV 里读更多东西出来。换 logstash 主要看重了 heka 的监控，资源占用和处理速度。

Q：会涉及数据卷的迁移吗，有什么好解决方案？

A：目前平台里没有持久化的东西。这块不敢说用什么合适，我们也没开始尝试。

Q：镜像做成代码库和运行环境具体是什么意思，为什么运行环境方式合适？

A：镜像具体做成什么样要根据自己的应用来判断，我们用的 logstash、statsd 什么的，都是配置文件描述流程的，所以我们选择了运行环境的方式。

Q：镜方式像做成代码库和运行环境具体是什么意思？

A：代码库就是说你把你工程的代码，配置什么的都全部打成一个镜像。运行环境就是有一些 bin 或者 Java、PHP 这些工具的，启动后才下载代码，配置。

Q：你们会不会遇到跨机房的 MesOS 问题啊，如果跨机房，怎么办？

A：有跨机房的情况，我们机房间有 logstash 专门转发日志流量，统一管控。

Q：比如数据库初始化的脚本，做在镜像里合适还是有其他方式比较好？

A：db 的数据文件其实挺难脱离外层的应用单独说的，因为有业务线代码引起的 schema 变更，最好先解决 db ci 的问题，然后再考虑数据何时加载，可以映射上对应 schema 的时候，db 文件可以先从 swift 等共享存储直接下载到本地使用，或者用脚本重新初始化也可以，我们的快速 rebuild 环境正在试验。业务线还不敢这么来。

Q：用运行环境方式，容器启动后再拉代码和配置，不符合 Docker 设计镜像的初衷吧，怎么做到一处打包到处运行，镜像不是完整可执行的？

A：主要是代码库版本和镜像的 tag 如何映射，为了简单点可以考虑启动后下载代码，如果代码已经编译好放到了共享存储里直接下载代码包也可以。我们目前没有考虑过把代码库版本和镜像 tag 映射这个问题。

Q：Mesos 资源统计会出现与实际不符，你们的解决思路是什么？

A：要看是什么资源了，Mesos 的划资源的格子属于一刀切的方式，即使你没用满也会被归入已使用的资源里，如果从这个角度看，实际运行的资源和 Mesos 内上报的资源确实不一致，但是考虑到计算资源的周期性，突发性，还是推荐以 Mesos 上报的资源为准。我们自己跑在 Mesos 上的监控 framework 本身也是这么做的。

Q：cAdvisor 好像只能监控单机容器情况，那对于集群的容器监控，使用 ca 怎么处理呢？

A：我们目前是 cAdvisor 聚合好以后发给我们的公司的监控平台，由监控平台统一处理。最新版已经 merge 了许多 storage-driver 了，statsd 值得试一下。

---

2015-09-08：Docker 三剑客之 Swarm 介绍

Q：Kubernetes 和 Swarm 相比较来看如何选择呢？

A：一个很 Open 的话题，根据特点，选择适合自己的就 OK。Swarm 对外提供 Docker API，自身轻量、学习成本、二次开发成本都比较低，自身是插件式框架。从功能上讲，Swarm 是 Kubernetes 的一个子集，个人感觉，Compose+Swarm=Kubernetes。

Q：Swarm 最终目标是什么，只是为了管理容器吗，有没有考虑过提升资源利用率，会把资源弹性伸缩做上来吗，最终把所有机器负载提升，防止有些低负载或空负载浪费资源？

A：Auto-scaling 能力，个人感觉后边可能通过 Compose 来实现，感兴趣的话，可以在 Swarm 社区提一个 proposal。

Q：Swarm 对节点的选取是否可定制化，指的是策略选择，感觉只有这三种不够强大？

A：可以，可以根据自己的特点实现对应 API。

Q：调用 Swarm API 及 Swarm 调 Docker API 安全认证是怎么做的？

A：安全这部分是通过 SSL 协议实现通信安全以及认证，支持 Swarm 对外（比如与 Client）之间的提供通信安全，同时 Swarm 与 Docker Engine 之间的也支持通信安全。

Q：Swarm 怎么跨节点 link？

A：目前不支持跨节点，如果使用了 link，创建的容器和 link 的容器会被调度到同一个节点上。

Q：Swarm 的调度系统也是插件形式？可以使用 Mesos 的资源调度吗？

A：Swarm 调度器是插件形式。Mesos 采用两层调度框架，第一层，由 mesos 将符合框架的资源上报给框架，第二层，框架（swarm）自身的调度器将资源分配给任务。

Q：Swarm IP 是怎么管理的？Swarm 下的各个节点是动态分配 IP 的么？

A：当前网络部分还是用 docker-engine 自身的能力，后续会和 libnetwork 进行集成，具体怎么管理正在讨论中。

Q：网络部分集成除了 libnetwork 还有其他计划或者考虑吗？

A：libnetwork 自身也提供了 plugin 机制，个人理解，和其他网络项目很好集成。

---

2015-09-02：畅谈 PaaS

Q：开源势必引入安全问题。Cloud Foundry 的安全保护机制？

A：Cloud Foundry 对于应用有个安全组的特性，可以控制应用容器的访问。但是实际上能力不强，容器安全这块一直是被担心的地方。

Q：Cloud Foundry 的 DEA，即应用的运行时节点，是虚拟的操作系统么？Warden 对底层的操作系统有和要求？Warden 如何实现的隔离性？

A：DEA 是个服务，其实还是 Linux 系统 Warden 对内核有要求，实现原理和 Docker 类似。

Q：va/spring/web 应用很容易在 Docker/Kubernetes 环境运行，如果要迁移到 CF，工作量大吗？

A：CF V2 工作量应该挺大，V3 的话因为支持 Docker，所以还好。

Q：关于 k8s 中 Flannel 和 Weave 两者哪个更适合生产环境？

A：这个我最近正在分析，感觉 Flannel 和 Weave 都还不成熟，推荐 OVS。

Q：Docker 既然是 namespace 隔离的，就算不安全应该也影响不是很大吧？

A：其实如果你清楚原理，很容易进入到容器环境中的，没办法，安全是个大问题。

Q：k8s 可以实现应用的自主迁移吗？

A：目前没有 Pod 迁移的 API。

Q：CloudFoundary 中监控部分有插件机制么？

A：支持导入到各种第三方监控系统。

Q：Pod 直接通信需要开通隧道么？换句话说他们之间是如何实现通信的？

A：容器跨主机的通信，是对 Docker 的增强，像 Flannel、ovs 等。

Q：PaaS 的三个典型代表： Cloud Foundry、Docker 和 Kubernetes，最近的 DaoCloud、灵雀云、时速云等以 Docker 为核心提出了新的 CaaS 概念。CaaS 和 PaaS 都使用了 Docker，Kubernetes 等技术，您是怎么理解 PaaS 和 CaaS 的？

A：CaaS 容器即服务，我的理解就是 PaaS，只不过主打这 Docker 容器，所以叫 CaaS。

Q：Docker 在 CentOS 上使用 devicemapper，据说容易使系统 crash，对于其他的文件系统有没有推荐，brtfs 和 aufs 哪个更好？

A：aufs 是内核不接受的，听说是因为代码太乱。

Q：对于管理 Docker 这件事情，除了 Kubernetes， OpenStack（IaaS 阵营），YARN（Hadoop 阵营）也开始发力，怎么看待这几者间的竞争？

A：没有任何技术是银弹，不同需求不同设计。当然大家都想占据制高点了，这就是运作了。

Q：k8s 现在具备 auto scaling 能力吗，比如应用响应时间变长，k8s 可以自动扩容？

A：没有。

Q：如果将 Flannel 替换成 ovs 是不是也可以替换掉 kube-proxy，如果是那会不会影响集群中 SVC 的使用？

A：flannel/ovs 和 kube-proxy 的作用是不一样的，可以看下 dockone.io/article/545。

---

2015-08-26：一篇文章带你了解 Flannel

Q：数据从源容器中发出后，经由所在主机的 docker0 虚拟网卡转发到 flannel0 虚拟网卡，这种 P2P 实际生产中是否存在丢包，或者此机制有高可用保障么？

A：只是本机的 P2P 网卡，没有经过外部网络，应该还比较稳定。但我这里没有具体数据。

Q：UDP 数据封装，转发的形式也是 UDP 么？我们一般知道 UDP 发送数据是无状态的，可靠么？

A：转发的是 UDP，高并发数据流时候也许会有问题，我这里同样没有数据。

Q：实际上，kubernates 是淡化了容器 ip，外围用户只需关注所调用的服务，并不关心具体的 ip，这里 fannel 将 IP 分开且唯一，这样做有什么好处？有实际应用的业务场景么？

A： IP 唯一是 Kubernetes 能够组网的条件之一，不把网络拉通后面的事情都不好整。

Q：Flannel 通过 Etcd 分配了每个节点可用的 IP 地址段后，偷偷的修改了 Docker 的启动参数：那么如果增加节点，或删除节点，这些地址段（ETCD 上）会动态变化么？如果不是动态变化，会造成 IP 地址的浪费么？

Q：sudo mk-docker-opts.sh -i 这个命令具体干什么了？非 coreos 上使用 flannel 有什么不同？

A：生成了一个 Docker 启动的环境变量文件，里面给 Docker 增加了启动参数。

Q：容器 IP 都是固定的吗？外网与物理主机能 ping 通，也能 ping 通所有 Docker 集群的容器 IP？

A：不是固定的，IP 分配还是 Docker 在做，Flannel 只是分配了子网。

Q：Flannel 的能否实现 VPN？你们有没有研究过？

A： 应该不能，它要求这些容器本来就在一个内网里面。

Q：Flannl 是谁开发的？全是对 k8s 的二次开发吗？

A： CoreOS 公司，不是 k8s 的二次开发，独立的开源项目，给 k8s 提供基础网络环境。

Q：Flannel 支持非封包的纯转发吗？这样性能就不会有损失了？

A：非封装怎样路由呢？发出来的 TCP 包本身并没有在网络间路由的信息，别忘了，两个 Flannel 不是直连的，隔着普通的局域网络。

Q： Flanel 现在到哪个版本了，后续版本有什么侧重点？性能优化，还是功能扩展？

A：还没到 1.0，在 GitHub 上面有他们的发展计划，性能是很大的一部分。

Q： 就是在 CoreOS 中，客户还需要安装 Flannel 吗？

A：不需要，在启动的 Cloudinit 配置里面给 Etcd 写入 Flannel 配置，然后加上 flanneld.service command: start 就可以了，启动完直接可用，文档连接我不找了，有这段配置，现成的。

Q： 可不可以直接用命令指定每个主机的 ip 范围，然后做 gre 隧道实现节点之间的通信？这样也可以实现不同主机上的容器 ip 不同且可以相互通信吧？

A：还不支持指定哪个节点用那段 IP，不过貌似可以在 Etcd 手改。

Q： Flannel 只是负责通信服务，那是不是还要安装 k8s？

A：是的，k8s 是单独的。

Q：现在 Docker 的网络组件还有什么可以选择或者推荐的?

A：Overlay 网络的常用就是 Flannel 和 Weave，其他 OVS 之类的另说了。

---

2015-08-19：360 的容器化之路

Q：开发自己的调度系统大概花了多久，有遇到特别的技术难点吗？

A：大约 2 个工程师一个月样子，没有太多得困难。因为调度逻辑比较简单。

Q：您刚才说，通过绑定独立的 IP 就可以直接使用 SSH 了。

A：通过绑定独立的 IP 就可以直接使用 SSH 了，官方关于 network 那篇文档有介绍实现方案。

Q：一般 Docker 的服务封装是 no daemon 的，这时如果重启服务，容器也会退出的，如何 debug？

A：可使用 supvirsod 或者 monit 等将 no daemon 封装一下。

Q：你们服务的注册发现用的是什么？

A：我们基础架构组开发了一个，名字叫 QConf，已经开源在 GitHub 上。

Q：你说 Zabbix 做的一个容器监控，那有没有一个基于宿主机的监控方式？因为据我所知你这样的话每个容器都要运行一个代理吧。

A：我们就是使用宿主机里安装 Zabbix 代理，通过 Zabbix 自发现来动态获取容器列表，再基于自定义的监控脚本获得每个容器的监控数值。

Q：你们的那些业务跑在 Docker 里了？

A：目前 360 的很多 Web2.0 业务已经跑在了上面，像影视、新闻、免费 WIFI 等。

Q：Docker 建议无状态，那么是否意味着不建议存放数据？比如 MySQL，还是说通过-v 来解决？

A：这其实是数据存储问题，你可以使用分布式存储来存储数据，只要数据和逻辑分离容器就无状态了。

Q：Docker 建议无状态，那么是否意味着不建议存放数据？比如 MySQL，还是说通过-v 来解决？

A：我理解就是容器无状态就是基于镜像创建的马上就能线上使用。

Q：线上 Docker 的稳定性如何？

A：目前运行都很稳定，没有出现容器异常崩溃等情况。

Q：Container 中跑多个进程，那么 PID 为 1 的进程你们是由什么控制的，直接由对应的应用程序还是其他什么？

A：之前用了 supervisord 现在使用 S6。

Q：Registry 面对大量的并发，有测试出大致的性能占比吗，整个 registry 是 mirror 还是其他架构？

A：Registry 目前我们更新到了 V2，我们测试 V2 在高并发 pull 和 push 上性能非常好，镜像存储使用共享存储，这样 Registry 也可以横向扩展。

Q：如果容器配置用户可以直接访问的 IP，在宿主虚拟机中是否可以基于 Open vSwitch 实现，否则会太依赖虚拟机网络？

A：这个可以的，实际上我们也测试过没问题，当时基于稳定性考虑没有使用。

Q：奇虎的 CPU 配额管理是如何实现的？

A：这个 Docker 1.7 已经实现了，我们和官方的实现思路是一致的。

Q：关于容器中数据存储是怎么做的，如果是共享存储如何进行对应？

A：可以试试 GlusterFS 或者 Ceph。

Q：容器绑 IP，容器重启后 IP 要重新绑吧，IP 会变吗？

A：需要重新绑，可做成自动化脚本。

---

2015-08-12：闲谈 Kubernetes 的主要特性和经验分享

Q：kubelet 本身也跑在 pod 里吗？

A：可以跑在容器里，也可以跑在 host 上，可以尝试 hyperkube 的集成工具。

Q：roollback 的具体机制是？

A：感觉应该通过 lablel，再一个个替换已经升级的 pod，不过还没仔细研究过。

Q：Mesos 和 Kubernetes 到底有什么区别？感觉有很多重合的地方。

A：Mesos 和 Kubernetes 侧重点不同，确实有一些重合的地方；mesos 更擅长资源管理，支持上层 framework，k8s 原生为容器设计，更关注 app 相关的一些问题。

Q：”比如用 HAProxy，直接导流到 service 的 endpoints 或者 Pods 上”，haproxy 如何导流到 Pod 上，podIP 不是不固定的吗？

A：可以通过 watch etcd 或者 api server 的方式，监听变化来更新 haproxy；kubeproxy 改用 haproxy，只是 external loadbalancer 的方式；如果要替换，需要重新开发。

Q：有没有可以推荐的分布式 Volume 方案？你们使用起来性能如何？

A：分布式 volume，可以尝试 rbd，性能的话就需要自己多多测试，不断调优了；有用户提到在使用 moosefs 做存储，对 glusterfs 的支持也很多。

Q：k8s 的插件规范吗？还是直接硬改？

A：有些还是比较规范的，可以 plugin 方式；有些还需要后续版本的调整，否则要动源码了。

Q： k8s 如何监听 docker 的事件，比如：在意外退出前，想抛出一些额外的事件，通知 lb 如何做？

A：不确定这个是监听 docker 的哪些事件，再 pod，rc 层面可以进行 watch。

Q：k8s 如何设置各个 pod 的依赖和启动顺序？

A：目前没看到很好的控制 Pod 的依赖和启动顺序的机制可以在应用层面避免这些依赖和顺序问题。

Q：问一下 k8s 集群内部容器间网络这块的解决方案有哪些，类似 flannel 这类方案的性能问题有什么好的解决方案？

A：目前 flannel 有其他的替代方案，但 flannel 部署比较方便，贴近 Kubernetes 的整体工作模式；性能上，如果做联机内网，总会有损耗，这个需要取舍了；有用户反映，华为的测试结果说 ovs 比 flannel 好，但是自己没有实际测试过；flannel 的性能可以看 coreos 官网的 blog，上面有测试报告。

Q：先用容器做轻量级虚拟机，容器间可以通过 hsotname 访问，不知如何动手？

A：k8 上的内网 DNS（kube2dns + skydns） 应该可以满足需求，可以尝试一下。

Q：有没有好的监控工具？

A：可以参考 DockOne 上的另外一篇文章。

---

2015-06-17：OpenStack Magnum 社区及项目介绍

Q：我观察到 k8s 里面的 cloud-provider 里面有了 OpenStack 的插件。想问下，这个 cloud-provider 在 magnum 里是否有使用？如果使用了，是如何使用的？

A：现在 Magnum 在和 Kubernetes 社区合作，这个是 Kubernetes 社区贡献给 Magnum 社区的，但是现在还没用。

Q：magnum 现在是可以创建 swarm 集群，但是 Swarm 没有 pod/service/Replication Controller 的概念，这个 magnum 后期会有这方面的计划把这些概念引入 Swarm 集群么？

A：暂时没有，现在 Magnum 还是分开管理 k8s 和 Swarm 对象的，magnum api 端的调用就可以指定用户用的是 k8s 还是 Swarm。

Q：magnum 可以作为独立模块使用吗？

A：现在还不行，因为需要依赖 heat 和 keystone。

Q：我看你的命令截图，想问下底层架构是 OpenStack 吗？

A：是的，Magnum 是 OpenStack 生态圈的一员，主打 Container Service。

Q：架构图中左边最下面那个 micro os 是 Docker 引擎的载体？这是相当于还是要起一个实例吗？能不能去掉这个载体，由 OpenStack 直接提供统一的 Docker 引擎。

A：因为现在 micro os 已经提供了，所以社区暂时么有计划通过 OpenStack 去提供，可能不想重复造轮子。

Q：Magnum 支持 GUI 的 L 版什么时候出 ，会区分个人版和企业版吗，会收费吗？

A：L 版会有个 draft 的 gui，不收费的，OpenStack 社区都是免费的。

Q：bay 可以动态扩容吗？

A：可以，通过 magnum bay-update。

Q：在 magnum 的网络解决上 libnetwork 和 Neutron 区别在什么地方，各自的优势是什么，现在有哪些难点需要解决？

A：这个我还在调查 现在还没有一些结论 具体的可以关注这个 bp spec/native-docker-network,我会定期的去 append 一些调查结果.希望对网络感兴趣的人参与到 native-docker-network 这个 bp 的讨论中来。

Q：Magnum 的 Blueprint 写着”Add support for mesos bay type”，bay type 支持 mesos, k8s,swarm，这个以后真的能做到统一抽象吗？这三者之间差异化还不小。Magnum 社区是怎么考虑的？

A：这是个非常难解的问题，这个可能还得需要在开发中，和社区讨论，看能不能有一个折中的办法：能抽象的尽量抽象，不能抽象的再定制。我们可以在 OpenStack ML 讨论。

Q：Magnum 相对 Kubernetes 的优势？

A：magnum 相对与 Kubernetes 的优势主要有这么几个：1）多租户，不同的租户有不同 bay，baymodel 等等

2）OpenStack 为 Kubernetes 提供底层的基础设施服务，OpenStack 负责 IaaS，Kubernetes 负责 PaaS，Magnum 负责联通 Kubernetes 和 OpenStack。

Q：magnum 没有显式创建 master node，是不是创建 bay 的时候就创建了 k8s/swarm 的 master 节点？多个 k8s/swarm luster 就是创建多个 bay 就 ok 了？

A：答案都是 yes，Magnum 会自动创建 Master 节点。

---

2015-06-03：新浪 SCE Docker 最佳实践

Q：如何实现跨机部署？

A：shipyard 和 swarm 都可，当然还有其它方案。shipyard 有不错的 web UI，支持 container 多机部署，调度基于 tag，还可以 scale。swarm 调度策略比较灵活，可以依据你指定的 filter、weighter 进行调度部署。

Q：Compose 能否实现跨机编排？

A：不行。目前只支持单机编排。

Q：container 监控是如何实现的？

A：cadvisor 做 container 监控。监控这部分也是有一定工作需要去想去做的，比如说可以考虑和 EK 结合提来，提供一个独立的 docker 集群监控解决方案出来。

Q：如何对某一容器进行扩容？

A：目前没有比较好的解决办法，我们的建议的做法是删了再启个大的。

Q：SCE 方案中，docker container 大概是跑在那一层？

A：大概的栈是 IaaS，CaaS，SCE docker container 是跑在 CaaS。

---

2015-05-20：AppC 和 Docker 的对比

Q：关于镜像的问题是否可以基于本地源来创建？我个人觉得本地源对于企业来说很重要。

A：AppC 的镜像创建方式不太一样，现在还不支持用编写 Dockerfile 这样的方式创建，而是把文件放到指定结构的目录，然后直接用 actool 工具打包创建。

Q：能支持不同的发行版？

A：AppC 是跨系统的，只是一个标准。Rkt 可以在任意的 Linux 发型版使用。

Q：Rkt 的最小镜像是？

A：Rkt 的最小镜像可以小到里面只有一个可执行程序。

Q：”信噪比”的概念不是很明白。

A：内容”信噪比”就是说实际用户要的文件和其他辅助文件的比例。

Q：Rkt 容器可以起多进程吗？

A：和 Docker 一样的，入口命令只能一个，里面可以后台运行多个进程。

Q：”但 Docker 的这种进程运行模型，使得不论是通过进程树还是 cgroup 树都无法看出创建容器的 Docker 令行与容器本身有任何关系。因此许多任务管理工具如果不对 Docker 进程进行特别对待，就无法正常的管理通过 Docker 启动的容器里的进程。”这里提到的任务工具对 Docker 进程特别对待，通常需要怎么处理，才可以方便用户的任务工具对 Docker 启动容器里的进程进行管理？

A：就是说在比如结束容器进程的时候，不能通过启动容器的命令所在的 pid 或者 cgroup 来跟踪容器内的进程，而要和 Docker 后台服务进程去取。

Q：那 Rkt 的日志网络等是怎么处理的呢？

A：这个 Rkt 就撒手不管，让用户自己选择其他工具，比如 Kubernetes 或者 Mesos 这些框架都可以用，AppC 目的就是做纯粹关注容器本身功能（环境隔离）的容器。

Q：Rkt 运行自己的镜像和 Docker 的镜像有什么区别吗？

A：镜像格式上有些区别，不过其实两者应该是很容易转换的，Docker 容器到 AppC 容器转换的工具已经有了，反转的还没有，估计 Docker 现在自己是主流，也没打算做这种事情。

Q：Rkt 有提供 Restful 的 API 吗？ A：没有，因为要实现 Restful

API 就必需要有一个常驻后台的进程，这样就违背了 Rkt 做纯粹的容器工具，并尽可能的减少对系统入侵性的设计意图了。

Q：感觉 Rkt+CoreOS 和 Docker+Machine/Swarm/Compose 这两种组合都在做集群的事情？

A：是的，其实是存在一定竞争关系的。只不过 CoreOS 觉得 Docker 越做越复杂，不符合他们的应用场景，就新建了一套，顺便改进一些 Docker 的小毛病。但 CoreOS 依然会对 Docker 解决方案继续提供长期支持。

Q：Rkt 能使用 Docker 的镜像吗？

A：能，Rkt 支持直接下载 DockerHub 或其他 Docker Repo 的镜像，只是下载后会自动转换成 AppC 格式存储到本地。

---

2015-05-12：Docker Registry 的定制和性能分析

Q：2.0 的性能也没什么变化啊，优势在哪里？

A：客户端优化有限，在超过 100 个节点同时 pull 一个镜像时，2.0 服务端资源占用少。

Q：服务端的并发瓶颈在哪里？

A：服务端的代码还没做过更多的分析，从经验判断主要还是 IO，python 的内存占用比较多。

Q：考虑过多机房 image 存储 CDN 没？

A：这个还真没考虑过，目前我们的镜像服务是个内部 PaaS 平台用的，只要保证集群所在机房能快速访问就行。

Q：那还不如每机房加缓存？

A：是的，也可以考虑 registry 的 mirror 机制，用了 mirror 后可以一个点 push，其他点 pull。

Q：你们的调度器是自己开发的吗？

A：我们底层用的是 Kubernetes，调度器做一定的修改，主要是为了保证多个可用域。

Q：内部的 PaaS 有没有做资源限制、网络隔离？

A：有，目前我们的 Docker 是跑在 kvm 上。

Q：昨天网易好多服务断片了，据说是网络攻击，那这些服务有跑在 Docker 上吗？

A：断片是因为 BGP 的核心交换机问题，我也很好奇是什么引起的，目前还没有组织和个人声称对此事负责。

Q：有没有考虑过 nova-docker？

A：社区不是很活跃，我们没有采用这个方案，但对于中小公司来说这是最快的方案。

Q：为啥不考虑自己实现调度器？

A：忙不过来，我们也想做啊，这个放在后面实现。

Q：我们准备在某公有云上跑 Docker 集群。

A：先这么用呗，我觉得 Docker 的优势就是底层平台无关，今后换了底层迁移也没有那么困难。