乐趣区

关于k8s:大规模-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-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>

退出移动版