因为我们的业务场景并不复杂，所以我们的容器化之路，其实走的也相对来讲蛮顺畅的，我们的运维人员很少，只有 2 位，所以我们也没有太多的时间精力去维护太多的自建系统，我们使用了很多的阿里云产品，包括 Rancher，他很方便的部署方式，友好的 UI，包括集成好的监控等等，在容器化之路上给了我们很大的信心。
我们使用构建两层镜像的方式，降低了开发人员的学习复杂度。使用了小体积镜像 alpine + 预编译 glibc 减小了镜像体积。提高了部署的时间，在架构上，我们采用了阿里云双区机房的灾备的架构，以及完备的备份方案。使用 Daemonset 部署的日志收集组件，收集到阿里云日志服务，支撑我们 6亿/日的日志系统。Rancher 还提供给了我们深度集成的监控系统、多租户隔离等。还有我们自己踩坑 踩出来的资源配额设置。
其实容器化并不复杂，如果没有 K8s，我们需要自己构建健康监测系统、发版系统、维护不同的主机环境，不能细粒度的进行资源划分，不能更有效的利用计算资源，运维的工作主要是什么？在我看来其实就是 节约成本、提高效率。虚拟化、自动化、智能化、高性能、高可用、高并发 等等，这些无一不是围绕着成本和效率这两个词，而 K8s 其实已经帮我们都做好了，而像 Rancher 这种编排平台又帮我们降低了 K8s 的学习复杂度，所以你要做的就是加入 K8s，好了，到这里这次的分享就结束了。感谢~
社区QAQ1：K8S在生产环境的高可用存储方案有推荐吗？
A1：存储方案没有标准答案，我们主要使用阿里云，所以用的是阿里云的块存储，比较常见的方案还有 Ceph、GlusterFS、Portworx、OpenEBS 等，他们各有优劣，需结合自己的业务需求进行选择
Q2：灰度发布，Kubernetes网络流量可以通过服务网格分流实现网络层面的分发，但是涉及到应用大版本的更新时候，涉及到数据库结构的变更的时候，如何实现灰度发布？
A2：没有遇到过这个场景，不过提供一个思路，可以准备两套数据库，网络分流也可以分流到不通数据库，具体需要你自己验证一下是否可行
要分清楚这是两层，一层是逻辑层，一层是数据层，不能混为一谈
Q3：Pipeline是用什么做的？Pipeline下，如何处理同一个分支，需要并行测试多个版本的场景？我用Rancher的Pipeline，局限性比较大，就是同一个分支无法并行多套进行测试。命名空间在使用，但是同一个分支下，命名空间是写在.rancher.yml下的，所以无法区分，Rancher的Pipeline不能在外面注入变量进行区分。
A3：Rancher 的 Pipline 目前还是有一些不够灵活，我们使用的是自建 Jenkins 做 Pipeline 的，并行测试，可以用命名空间等隔离策略进行隔离，或者准备多套测试环境
Q4: 你们运维的Dockerfile和开发的Dockerfile是怎么合并的？
A4：开发的 Dockerfile 是 From 运维的 Dockerfile
Q5：你们k8s的漏洞扫描用的什么工具？一般什么级别的镜像漏洞需要进行修复？
A5：暂时没有使用漏扫工具，我们主要根据 Rancher 企业服务通知的修复建议进行修复
Q6: 就是比如说从外网，通过service ip能够登陆并且管理容器。想实现这一步必须通过将service ip暴露出来，然后这个service ip怎么暴露出来？麻烦解答一下。
A6：如果需求是管理容器，其实可以使用 Rancher 的用户权限控制，让某一用户拥有某一容器的权限，暴露 service ip 到公网，让用户管理容器是无法实现的
Q6 : 好的，谢谢，我还有一点不明白，这个service ip有什么办法能让他暴露出来呢？你意思是说让不同的用户通过rancher平台去管理不同的容器吗？麻烦再给解答一下，谢谢。
A6：可以使用 NodePort 暴露，通过 Node ip 和 端口进行访问，或者使用 公有云的负载均衡产品
Q6 : 我不是这个意思，我是想把service ip暴露出来，不只单单想通过集群内部访问。
A6：service ip 本来就是 K8s 内部的，暴露不了，只能转发
Q7: 为何没有放在3个可用区，如果可用区H挂掉，是否会导致集群不可访问？
A7：3个可用区当然也是可以的，Rancher HA 架构，只要有一个 Server 可用就没有关系
Q8：请教下你们多套开发测试环境的pipeline是怎么样的流程呢 (差异化)？有使用helm template吗，方便讲解下更多细节么？
A8：目前是通过 Jenkins 部署参数，部署的时候可以选择 命名空间、环境标识、分支等，通过 sed 修改 template