ITPub博客

首页 > 应用开发 > Java > 个推在 Kubernetes 的效率提升举措揭秘及最佳实践解析

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

原创 Java 作者:个推2018 时间:2020-07-06 11:47:52 0 删除 编辑


一、如何提升Kubernetes研发效率


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

微服务与CI开发(提升开发效率)

研发网络与Kubernetes互通(提升调试效率)

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



01


开发效率:微服务与CI 开发

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

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脚本中完成,从而节省时间。



02


调试效率:开发集群网络

在调试效率上,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内进行的服务的需求。




03


运维效率:Kubernetes APP平台

在运维效率上,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使用过程中根据企业自身应用和环境特点找到适合的方案。


01


个推K8s集群概览

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




02


使用规范

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


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


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




03


填坑经验分享

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


问题:

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

解决方案:

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

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


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



PPT获取方式


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

(微信号:getuitech)

回复关键词“ k8s

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


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31556026/viewspace-2702660/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2018-09-25

  • 博文量
    46
  • 访问量
    32051