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-proje...


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 等,如果你想要有更强的性能,更丰的网络策略配置,可以考虑下它们。


<p style="text-align:center">更多技术干货请关注【尔达 Erda】公众号,与众多开源爱好者共同成长~</p>

03-05 22:23