共计 2724 个字符，预计需要花费 7 分钟才能阅读完成。
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>