(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@edge支持OS类型：linux（centos、ubuntu），windows server；CPU架构：X86，arm边缘节点接入；支持异构节点在同一个集群管理；k8s管控托管在云上，异构节点的支持主要在边缘端实施；

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

A2: 分两个角度：1. 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@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@edge中我们也支持overlay跨公网的安全方案，支持反向网络穿透打通云、边，支持VPN网络等；

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

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

Q： 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@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@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的优势就是底层平台无关，今后换了底层迁移也没有那么困难。