运维Kubernetes集群到底有多难？

运维Kubernetes集群到底有多难？

在上篇文章不是技术也能看懂云原生我们提到，Kubernetes作为云原生基础设施统一了编排标准。而且他是开源的，但是开源不等于免费，仅仅是构建一个Kubernetes平台就需要考虑很多的因素，例如我的这篇文章中写的一篇文章搞定大规模容器平台生产落地十大实践，仅仅构建还不算，就算你有一个Kubernetes团队，真正大规模运维起来仍然很有挑战，我们这篇文章来讲讲运维的事情。

构建大规模Kubernetes平台有两个选择，一个是直接修改K8S源代码支持超大集群，一个是采取多集群的K8S。双方各有各的优缺点，前者优点是可以一个集群容纳上万个节点，维护集群数目少，缺点是可能对于K8S的核心代码改动比较多，将来K8S版本升级复杂。后者的优点是可以在不改K8S核心代码的情况下做参数调优，升级容易，缺点是调优后规模5000节点，如果规模大，需要维护更多的集群。

除了超大型互联网公司拥有一个K8S开发团队的情况之外，对于大部分使用者来说，第二种选择更为推荐。而且由于K8S升级快，大部分使用者都会等待社区解决一些问题，如果因为代码修改而不能升级，将非常痛苦。K8S是开源的，也就意味着社区并不会对SLA负责，责任就归到运维团队上，这个时候如果开源有问题导致升级失败，很可能会影响整个集群，因而很多运维团队会选择部署两个K8S起步，一个升级，一个维持老的版本，如果升级失败了，至少还有一部分业务跑在老版本上，可以快速把流量切过去。再加上如果有多个数据中心，多个部门，测试和生产的强隔离要求，有多个地域，甚至业务扩展到全球，这样K8S集群数目就更多了。对于大多数企业来讲，多K8S讲成为一个常态，这也同时加大了运维难度。

问题一：K8S依赖的底层资源如何管理

前面讲过，K8S在编排语义上是标准的，对应用友好的，但是对于底层网络，存储等，却仅仅提供了标准插件式的接入模式，真正的实现则交给了运维团队自己去选择，虽然开源有一些实现，但是很多复杂性就藏在了这些外围系统里面。

如果集群规模比较小，集群数目比较少，还不怎么头疼，但是一旦节点数目多了，集群数目多了，就不免会遇到以下问题：

节点的规格问题：节点CPU和内存是否统一？硬件的计算能力是统一的么？会不会随着CPU的演进而导致相同规格的容器计算能力不同？NUMA拓扑会不会不同？L3 Cache会不会不同？是否需要设置label来标记这些不同？操作系统问题：如何保证不同集群不同节点都使用相同的操作系统版本，保证安装相同的工具集和内核patch，从而保证稳定性和功能完整性。如果操作系统要升级，应该怎么办？网络问题：不同的节点网络带宽是否一致？随着硬件网卡的升级如何保证相同规格的容器有相同的带宽资源？硬盘问题：每个节点的硬盘是否一致，硬盘空间，SSD or HDD，BPS和IOPS的要求是多少网段问题：每个集群的网段如何规划，是否会产生冲突，不同集群之间如何互通？物理机和机架感知问题：是否要给每个节点打上label，让其感知物理机和机架，从而有利于业务层的容灾。弹性问题：如果遇到整个集群资源不足的情况，如何进行集群级别的扩容

如果事先没有考虑好这些问题，刚开始搭建集群的时候，可能很美好，但是随着这个集群持续个3年5年，问题就会逐渐的暴露出来，整个节点池参差不齐，调度经常失败，或者被调度到不是很理想的节点，例如硬盘空间不足，跨NUMA导致性能下降等。扩容速度也会越来越慢，有时候看起来很大的一个池子被分割成了很多小的节点池，使得灵活性大受影响。新建K8S集群的时候，发现由于网段规划问题，导致不同的K8S直接互通非常麻烦。

要解决这些问题，一方面要做好归一化和标准化，通过流程来一定程度上解决这个问题，另外一方面在容器平台和物理机中间有一层虚拟化能够解决很多这方面的问题，虚拟机的可迁移性使得物理机的维护和迭代屏蔽上层业务。虚拟机的灵活规格，网络虚拟化和存储虚拟化可以使得硬件升级的时候，容器节点规格相对一致。容器平台的自动化部署和扩容使得多集群运维和弹性也会更加方便。这也是很多企业有了容器平台同时愿意保留虚拟化平台的原因。

问题二：K8S组件如何管理

K8S本身组件就挺多的，但是随着你作为K8S平台的维护者接的上层需求越来越多，你会发现自己不得不开发一些另一些组件和插件，比如各种Operator，CNI，CSI等，后面会发现这些组件的维护也是一个问题，因为他们也是代码，也涉及到测试，发布，升级，监控等，而且作为K8S集群组件，极有可能出了Bug影响的整个集群，风险非常大。

因而这些K8S组件也需要一个发布平台和运维平台。K8S组件的代码使用Git进行管理，如果要添加功能，就要走严格的测试流程和CICD流程，进行发布和回滚。K8S的组件也需要高可用，需要挂掉重启等功能，从这个角度看，K8S组件放在K8S里面也挺合适的，当然这两个K8S不应该是一个，否则就循环依赖了，我们讲业务使用的K8S称为用户K8S，而运维用户K8S组件的K8S称为管控K8S。在管控K8S里面，可以将不同的用户K8S的管控节点放在不同的namespace里面进行隔离。

这里还需要强调一点的是，如果你自己开发K8S组件，这个组件一方面要经过一定的性能测试，否则很可能会拖垮其他组件，另一方面也需要暴露一些监控接口，使得组件有一定的可观测性。就像K8S已有组件类似。

对于管控面最应该关注的是etcd，是唯一有状态的部分，需要很好的进行维护，这里涉及到集群的创建，监控，备份，巡检等。

万级K8s集群背后etcd稳定性及性能优化实践今晚7点半｜规模化 etcd 集群运维实践分享（内有PPT）

问题三：多集群的统一监控如何处理

当运维的集群规模大，集群数目多的时候，就非常依赖于监控系统发现问题和预警问题，监控的粒度，实效性，存储的时长等就非常的重要。

都有哪些东西需要监控呢？集群的核心组件，例如apiserver, controller, scheduler都需要进行监控。集群上的工作负载，例如pod, deployment都需要监控。上面讲过自己开发的K8s组件也要强调可观测性，因而也需要进行监控。

这个时候，你会发现，监控系统能够收集到的数据量还是很大的。云原生的监控一般会用Prometheus系统，但是你发现Prometheus没有很好的解决这个问题。

原生Prometheus并不支持高可用，也不能做横向扩缩容，当集群规模较大时，单一Prometheus会出现性能瓶颈，数据量大小取决于被采集服务的指标数量、服务数量、采集速率以及数据过期时间。在数据量大的情况下，我们可能就需要做很多取舍，比如丢弃不重要的指标、降低采集速率、设置较短的数据过期时间等。

应对这种问题的方式就是对Prometheus进行某种维度的拆分，每个Prometheus集群仅仅负责存储一部分的数据，这样虽然能够解决存储瓶颈，但是聚合查询就变得非常困难。为了解决分片后聚合查询的问题，引入Thanos框架，可以实现全局视图，长期存储，高可用。Thanos Sidecar部署在Prometheus节点旁边，将其数据提供给 ThanosQuery 查询，并且/或者将其上传到对象存储，以供长期存储。ThanosQuery实现了 PrometheusAPI，将来自下游组件提供的数据进行聚合最终返回给查询数据的客户端。

Thanos 解决了 Prometheus 的分布式存储与查询的问题，但没有解决Prometheus 分布式采集的问题。我们通过实验观察到当series数目高于300w时，Prometheus内存将暴增，为了让每个Prometheus收集到的数据控制在这个临界点内，引入Kvass框架，他实现了一个独立于所有Prometheus的负载协调器，协调器周期性(15s)进行所有Prometheus实例的负载计算，如果有的实例即将超过临节点，则创建新的分片来分摊负载。

打造云原生大型分布式监控系统(一): 大规模场景下 Prometheus 的优化手段打造云原生大型分布式监控系统(二): Thanos 架构详解

视频|打造云原生大型分布式监控系统(三): Thanos 部署与实践

打造云原生大型分布式监控系统(四): Kvass+Thanos 监控超大规模容器集群

如何用Prometheus监控十万container的Kubernetes集群

有了监控平台，你还应该规划一下应该重点监控哪些数据。

规模类的数据，例如用户数，集群数，节点数，Pod数，Service数等。

负载类的数据，例如CPU，内存，硬盘的使用率

容量类的数据，例如requests占总体的比例，limits占总体的比例，IP的使用数量等，以及容器平台配额，底层云平台配额的监控。

管控组件类，例如apiserver, controller, scheduler以及自研组件的状态，负载等。

异常类，例如异常Pod，Service，Node等

请求类，例如对于apiserver的访问统计，错误统计，请求延时，请求来源，请求流量等。

要根据以上的统计数据配置相应的告警，提前发现问题。

问题四：如何对于集群进行巡检

如果公司有大促或者节日的活动，肯定希望在此之前保证整个平台万无一失，仅仅监控平台不能满足客户需求，需要有一个巡检系统，在重大事件之前进行一次大检查。

都要检查哪些东西呢？其实上面提到的很多方面都要检查一遍。

依赖的外部资源的状态，例如节点的CPU，网络，存储等Master节点的状态，例如是否健康，是否做了高可用，是否跨可用区，CPU和内存利用率如何，是否足够。etcd是否正常，请求是否有延时，硬盘是否足够，IO情况如何。apiserver的请求响应时间是否正常。Node节点的状态，例如kubelet是否正常，docker daemon是否正常，镜像是否正常，CPU，内存，硬盘利用率如何，是否过载工作负载是否正常，Service是否正常证书配置是否正确各组件参数配置是否正确，Linux操作系统参数配置是否正确

问题五：如何进行集群审计

通过审计对apiserver的访问事件，可以进行metrics之外的另一种集群观测维度，通过查看、分析审计日志，可以追溯对集群状态的变更；了解集群的运行状况；排查集群问题；发现集群潜在的安全、性能风险等等。

可以将审计日志放入日志中心，方便随时进行分析。

手把手教你使用容器服务 TKE 集群审计排查问题

问题六：如何进行K8S事件持久化

Kubernetes Events 包括了 Kuberntes 集群的运行和各类资源的调度情况，对维护人员日常观察资源的变更以及定位问题均有帮助。但是将events保存在etcd里面，会对etcd造成很大的压力，因而往往单独部署保存events的etcd集群。默认情况下，events会保存一个小时，这对于定位某些复杂问题，或者很久才发现的问题，显然不够，这里你可以通过开发一个组件，将K8S事件进行持久化，保存在ES或者对象存储上。

问题七：如何通过NPD实现节点自愈

NPD(Node-Problem-Detector)的目的是能够提前发现节点可能不可用状态，而不是当节点已经不健康后再上报状态。

为了减轻运维人员的负担，提供了根据采集到的节点状态从而进行不同自愈动作的能力。集群管理员可以根据节点不同的状态配置相应的自愈能力，如重启Docker、重启Kubelet或重启节点等。

如下表格所示，FDPressure表示该节点上已经使用的文件描述符数量是否已经达到机器允许最大值的80%；ThreadPressure表示节点上的线程数是否已经达到机器允许的90%等等。用户可以监控这些Condition，当异常状态出现时，提前采取规避策略。

由此可见，在线运维一个高可用的多K8S集群还是有些难度的，需要额外做很多的工作。

最后来个广告。

随着云原生时代的到来，各大厂纷纷上云，甚至有人说，未来的软件就是生在云上，长在云上的。在这种云原生时代大势下，衍生出来的 Kubernetes 工程师、云原生工程师的薪资也水涨船高，大厂不惜花重金聘请优秀的云原生技术人才。

可以说，作为云原生的核心技术，Docker 和 Kubernetes 是所有想要投身云原生行业的技术人员的必备技能。

但你可能会说，我是搞开发/运维的，云原生、Kubernetes 跟我没关系，这你可就大错特错了。

微博和京东的运维工程师要求你懂 Kubernetes，爱奇艺和京东的 Golong 工程师必备技能是 Kubernetes，如果想去百度和腾讯做架构工程师，你还是得会 Kubernetes 和 Docker。

还有人问：云原生学完是不是只能找运维开发？对后端开发有用吗？

eBay资深架构师孟凡杰说：

云原生的世界里没有纯后台开发，只管业务逻辑的世界越来越小。比如你做Java开发，微服务架构下的 Spring Cloud你至少要懂， Spring Cloud现在也支持 K8s native 的服务发现，也在被Istio取代，所以未来应该是相通的，除非把自己局限在代码逻辑的部分，否则学习云原生技术栈就是有用的。

云原生技术如此重要，但现在网上有关 Kubernetes 的学习资料杂乱无章，你要是搜一下 Kubernetes 入门能出来好几条不一样的学习方法，看着看着就把自己看懵了。没有基础的同学根本不知道在哪里学，从哪里开始学，好不容易慢慢理解，想要实战深入理解吧，却又上不了手，不知道自己哪里出了问题。

如果你也遇到了这些烦恼，那我推荐你来看极客时间与 eBay 资深架构师孟凡杰联合推出的 「6 小时掌握 Docker 和 K8s 架构核心」。

从最基础的容器核心开始，到 Kubernetes 的核心架构原则、核心对象和控制器模式， 6 小时让老师手把手带你掌握容器技术与 Kubernetes 的架构核心，上手云原生时代最重要的技能。

这个课程非常适合想要了解 k8s 和 Docker 的同学，我也特意为你申请了几个免费名额。

扫描下方二维码

免费领取课程+配套学习资料

讲师：孟凡杰

他是 eBay 的资深架构师，负责 Kubernetes 的架构和开发工作，专注于网络、多集群、服务治理和服务网格等方向。

他是 Kubernetes 开源项目的代码贡献者，参与了社区集群联邦的开发和服务控制器重构等工作。

他拥有 10 多年的从业经验，先后就职于 IBM、EMC、eBay 等公司，对资源管理、作业调度、网络技术有着非常深入的了解。

他是 CNUTCon 的明星讲师，也是《Kubernetes 生产化实践之路》图书的作者。他不仅技术厉害，而且还能给你讲明白。

你将获得

深入理解容器技术的实现细节；掌握 Kubernetes 的核心组件；熟悉 Kubernetes 对象定义的通用原则和核心对象特性。

想理解容器技术优势和实现细节的云原生小白；想了解 Kubernetes 架构原则的软件架构工程师；想了解 Kubernetes 基本操作的研发和运维。