大规模 K8s 集群管理经验分享 · 上篇

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】公众号**，与众多开源爱好者共同成长～