个推在Kubernetes的效率提升举措揭秘及最佳实践解析

一、如何提升Kubernetes研发效率

成都创新互联公司专业为企业提供鲅鱼圈网站建设、鲅鱼圈做网站、鲅鱼圈网站设计、鲅鱼圈网站制作等企业网站建设、网页设计与制作、鲅鱼圈企业网站模板建站服务，十年鲅鱼圈做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。

本文将从三方面阐述如何提升Kubernetes研发效率：

微服务与CI开发（提升开发效率）

研发网络与Kubernetes互通（提升调试效率）

服务端软件管理平台建设（提升运维效率）

微服务目前已成为主流的容器编排技术，然而不少开发者在使用过中或多或少会遇到一些问题，主要在于以下四点：

1）Kubernetes涉及较多专业知识，而研发掌握有关知识有一定的门槛。

2）Kubernetes镜像常常没有充分利用 Build Cache，导致占用构建存储大，传输慢。

3）不同的业务其镜像差异大，运维在对镜像进行维护时操作过程非常复杂。

4）Kubernetes安全更新后，不仅要确保程序没有漏洞，还要确保编程语言、基础镜像、业务本身都没有安全漏洞。如果研发人员要维护全部的更新内容，负担比较重，一定程度上会影响其研发效率。

开发一个新的微服务涉及诸多环节，比如Dockerfile的编写、安全更新的维护、缓存层的设计，监控指标的接入等。而这些环节会出现一些问题，主要包括容器体系重复建设、安全更新需求需要在各个服务重复实现、Build Cache难以跨服务复用等。

为解决以上问题，我们采用了以下措施：

1）在容器体系统一建设的同时，做到允许自定义，降低门槛；

2）将镜像统一为公用几类（Node.js/Java/Golang），统一维护安全更新；

3） 跨服务共用Build Cache；

4） 统一置入工具链、依赖、ARM适配、监控指标等。这样一来，对于ARM问题，在构建镜像时，我们会先构建完X86，再构建统一的ARM。这些步骤都在统一的CI脚本中完成，从而节省时间。

在调试效率上，Kubernetes的痛点在于debug流程复杂耗时长，因为微服务通常需要依赖服务进行调试，但是开发机无法连接集群内Kubernetes Service 进行调试，且服务可能不位于流量入口位置，需要将中间环节的流量转发。

怎么样才能缩短debug流程，让调试完的代码能够秒级生效呢？

来看上面左边这张图。左图上半部分由开发机与DNS组成。下半部分是k8s集群，包含它的CoreDNS以及service B。为缩短调试流程，我们在开发区的网络拓扑中部署了Nginx，用于把所有的 k8s cluster的域名解析到 k8s服务上。

比如我们统一取名为*.svc. cluster.local，并把它都统一解析到 k8s集群上，集群上我们调起Nginx，Nginx收到来自b.app.svc.cluster.local的请求后，直接向 k8s的CoreDNS去获取它svc的cluster IP。获取到IP后，它就可以知道，该项服务是 APP内service中的B服务，以及cluster的IP地址，然后Nginx便可以通过proxy pass进行转发。这样我们就实现了在开发机内任意地访问开发网k8s内进行的服务的需求。

在运维效率上，Kubernetes的痛点主要来自以下四方面：

1）微服务化导致服务数量增加，需要将服务分组及模块化管理，而这会增加管理成本。

2）每个服务都有各自的依赖，当我们想针对服务进行管理的时候，存在依赖管理的问题。

3）由于服务数量众多，服务手工升级过程也耗时耗力。

4）在私有化部署背景下，我们很难直接将应用快速分发到客户集群上。

为解决以上痛点，我们提出了Kubernetes APP平台思路，并设计了如下技术架构。

架构图由四部分组成：Helm、ChartMuseum、APP Installer Container、Kubeapps。Helm是包管理器，可以管理依赖，并提供钩子机制，帮助实现模板化。ChartMuseum用于包存储。APP Installer Container执行定制的APP结构规范、自动升级SQL Schema、自动导入Consul配置以及注册网关入口及插件。Kubeapps方便UI管理。

要想提升运维效率，需要将运维管理维度从服务层面转换成APP层面。为此，我们把相近的业务合并成一个统一的模块去管理，降低管理复杂度。具体来看，每个服务生成一个helm包，包含自身标准化的SQL、Consul配置等，挂在Helm Hook上由定制化的Runner执行，并通过标准化SQL升级、Consul配置管理等，提升运维管理效率。

个推K8S最佳实践解析

个推Kubernetes最佳实践将从个推k8s集群概览、使用规范制定、使用经验总结三方面展开，以帮助开发者在Kubernetes使用过程中根据企业自身应用和环境特点找到适合的方案。

首先简要介绍下我们的组件地图与各组件的用途。如果用一把伞来比喻我们的组件地图，那么伞的核心组件是Kubernetes，docker则是底层最基础的运行环境，calico和fannel是网络cni的选型；coreDns是k8s内部的域名解析组件；kube-stat-metrics是主要的监控组件，kube-stat-metrics主要用于采集pod的状态; dashboard是运维管理工具；Harbor是企业级的镜像仓库开源解决方案；consul/Apollo是配置中心；Ingress用于提供负载均衡功能，是我们暴露集群外到集群内服务的http和https路由的方案之一。

为了更好地对k8s进行管理和维护，我们制定了详细的k8s使用规范。在个推实践中，规范主要分为五类：参数、安全、资源、日志、YAML。参数规范主要指的是对参数命名规则的规范。常见参数主要包含dns、ulimit、kubelet insufficient pods、calico、内核参数、xfs系统的d_type支持、label等。安全规范是面对网络各信息安全相关的规范，主要包括业务线的隔离、资源的限制、访问的控制以及PSP相关的设置；

资源类规范主要指的是资源可见性以及资源的控制与分配；日志规范是为了所有日志能够被统一采集和管理所制定的 规范，比如日志格式、日志分类以及日志存放目录规范；YAML的规范是为了保持线网环境以及测试环境的一致性，让功能更加稳定、发布更加高效和安全而制定的一些列规范和标准。

规范标准化是一个持续的过程。我们通过学习、思考以及经验汲取来制定执行和完善这个规范的过程，就是我们在不断提高质量、提高管理水平、提高收益的过程，这也是k8s集群得以持续发展的原因。

在制定标准的过程中，我们踩过一些坑，以下将分享有关经验供参考。

问题：

我们发现在service转发过程中，流量负载并不均衡，导致单个pod请求压力过高。

解决方案：

1）对边缘节点进行了改造，在node上部署了nginx，upstream中的节点通过实时从consul中获取服务的状态和ip实时更新，以此绕过了service的流量分发，避免了流量负载不均的问题。k8s集群内部服务模块之间的转发也可以通过类似的方法予以实现。

2） 由于ingress抗压能力强，故使用ingress也能实现流量负载均衡的需求，保证ingress到后端的流量是均衡的。

总之，k8s服务已经逐渐成熟，但也仍存在一些问题，需要我们开发者共同去解决这些问题，让k8s生态发展更健康，让工作更高效。

PPT获取方式

关注【个推技术学院】微信公众号

（微信号：getuitech）

回复关键词“ k8s”

即可领取Kubernetes专场完整版嘉宾分享PPT！