11 月 23 日，Erda 与 OSCHINA 社区联手发起了【高手问答第 271 期 -- 聊聊大规模 K8s 集群管理】，目前问答活动已持续一周，由 Erda SRE 团队负责人骆冰利为大家解答，以下是本次活动的部分问题整理合集，其他问题也将于近期整理后发布，敬请期待！
Q1：K8s 上面部署不通的应用对于存储有不同的要求，有的要高吞吐，有的是要低响应。大规模 K8s 部署的时候是怎么协调这种存储差异的问题？还是说需要根据不同的场景，运维不同的存储服务？又或者说尽量存储使用解决方案？ A1：存储相对于 CPU 和内存确实会更复杂一些，就是因为它会包含更多类型，不同的存储空间，不同的性能要求。所以存储还是得从应用需求出发，来满足不同的存储需求。
Q2：请问下你们维护的最大 K8s 集群规模大小是多少？遇到了哪些性能、稳定性问题？做了哪些优化？ A2：我们目前维护的单个集群规模不大，总量相对大些，维护了几百个集群。量上来了就会碰到形形色色的问题，比如：如何提升运维效率？如何比用户更早地发现问题？如何优化内存碎片问题？如何优化磁盘驱逐带来的隐患？。我们也做了很多事情：第一步进行标准化，比如统一操作系统、统一版本、标准化节点规格、系统数据盘分离等等。接着开始建设诊断系统，覆盖操作系统、容器、K8s、常规中间件、平台（应用）等，目前就是先于用户发现问题，能全方位进行巡检覆盖，可以将其理解为运维系统的眼睛，近期我们刚好也开源了这个系统：kubeprober。当前也会有对应的一些优化，比如: 补充 docker k8s 的 log rotate 参数，优化 gc、eviction 参数，防止磁盘被写满；对 Pod PID 进行限制、EmtyDir 存储、容器可写层大小等进行限制；保障 K8s 关键 Pod 的调度；关闭 swap，优化 /proc/sys/vm/min_free_kbytes 等参数，优化内存回收。 问题有些大，涉及的工作也会特别多，我也只是列举了部分，每个点上都还可以做更多的事情。 kubeprober 开源地址： https://github.com/erda-project/kubeprober
Q3：老师目前容器化部署编排企业私有成本远没有云厂商实惠，这会不会形成垄断趋势？还有 Serverless 的发展是不是对容器技术的冲击呢? A3：会有些现状问题，国内不少企业都有自建 IDC，尤其是一些头部企业。不论考虑是进行利旧，还是数据安全性等，客户都会有不同的决策，所以一定会有共存的情况。
Q4：K8s 对标两地三中心这样的部署架构老师有什么推荐么？是一套 K8s 用 namespace 区分好，还是各自搭建，优缺点老师能分享一下吗？ A4：一套的好处，管理成本比较低，部署的业务可以直接基于地域标签进行打散部署。但会有较大的问题，比如两地三中心本身就跨地域的，网络质量的保障是个大问题。本身方案就需要能跨城市级的高可用，那单 K8s 集群的 ETCD 高可用怎么保障？如果真出现城市级自然灾害，那就会导致你的 etcd 集群异常。本身的容灾方案还没起作用，可能就会出现该 K8S 集群因为网络等因素导致的不稳定。 容灾方案本身就会有较大的复杂性，跟你的环境，跟你的场景，都会有较大的关系。我可能没办法直接告诉你一套方案，但可以一起探讨下。🤗
Q5：您好，请问需要把所有的服务都拆分为微服务吗？并发量到多大才需要这样？ A5：微服务是否拆分，可能还不是仅跟并发量有关，很多时候你拆分后，性能可能比你单体架构还要差。核心还是得看你要解决什么问题，比如研发效率太低了、团队规模太大了、业务复杂度太高了等等。并不只是一个简单的拆分动作，还得去考虑你开发运维方式的变化、组织结构的变化等。
Q6：K8s 持久化存储有推荐方案吗？nfs 性能和稳定性都不行，ceph 蛮复杂的（还要区分 rbd、ceph），貌似也有人反应不稳定。local pv 的话 pod 要锁死节点了，K8s 优势大减呀～ A6：是的，只是举个例子。local pv 也是一个场景，你需要有更强的性能时，就是一个不错的选择，虽然和节点绑定了，但是可以通过应用层的架构来提升高可用的能力，解决单点故障问题。只是举例子，所以关键是看场景去配对存储实现。
Q7：数据库这类对存储敏感的软件，你们会部署到 K8s 上吗？有什么要注意的？ A7：我们目前进行了区分，非生产环境采用了数据库上 K8s，可以有更高的成本和运维能力。生产环境还没有跑在 K8s 上，主要是考虑稳定性。很多中间件都一样，不仅仅是数据库，只考虑存储还不够，比如你需要注意扩缩容、监控、快照备份、故障恢复等等，还有一些特定中间件的运维需求。
Q8：请问老师你们运维的 K8s 集群是运行在物理机上还是虚拟机上呢？现在不少公司都已经有虚拟化环境，虚拟机和容器共存有什么经验、建议吗？ A8：我们现在运维的 K8s 集群大部分都是在虚拟机上。多一层虚拟机，会多一些开销，比如资源开销、VM 平台的管理开销，甚至还会有采购成本。多一层虚拟化，可以弥补下容器的隔离性及安全性，扩缩容的成本也比物理机要低，现在不少 VM 平台还提供了热迁移等功能，运维能力上还是会强一些。有没有虚拟机这层，对 K8s 的使用层面关系不是特别大。
Q9：老师您好，关于 K8s 我们主要是使用一些管理平台去做管理如 Kubesphere、rancher 等等，针对 K8s 学习路线，想问一下怎么能更地去结合现状实践学习？ A9：很好的一点是你已经有了实际的环境去使用以及研究 K8s 了，带着实际的场景以及问题去学习 K8s 往往是最有效的方式，但前提是你已经掌握了 K8s 的基本知识和原理，在这些知识背景下再碰到工作上的实际问题往往都能思考的更深，也对 K8s 掌握的更细致，尤其是 kubesphere 、rancher 管理下的 K8s，往往遇到问题要先甄别是 K8s 的问题还是管理平台的问题，这时基本的理论知识就显得尤为重要，共勉。
Q10：如果存在要跨地域建 K8s、跨时区的场景下，如何保障 K8s 集群的稳定性，主机时间如何处理？ A10：个人不建议跨地域、跨时区，构建同一个 K8s 集群。建议考虑多集群的方案。，主要是两类: Pod IP + Service IP。集群网络算是这两类的统称，看个人怎么理解了。Service 核心是用于服务发现及 Pod 流量负载。
Q11：如何理解 pod 内网络、集群网络以及 service 网络呢？目前该如何选择网络插件 CNI？ A11：如果没有太多的需求，可以选择 flannel，相对简单一些。当然还有很多其他的插件，比如 calico、weave 等，如果你想要有更强的性能，更丰的网络策略配置，可以考虑下它们。
更多技术干货请关注【尔达 Erda】公众号，与众多开源爱好者共同成长～
