近日,个推TechDay系列线上首场直播沙龙圆满落幕。会上,个推研发总监之诺、个推资深运维专家壮壮以“k8s研发效率提升与实践解析”为主题,与线上观众一同探索了Kubernetes(又称K8s)领域的前沿技术及实践方法。

 

以下是Kubernetes专场精华内容分享

(文章结尾附直播内容PPT下载)

 

《如何提升Kubernetes研发效率》

 

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

 

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

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

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

 

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

 

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

 

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

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

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

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

 

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

 

为解决以上问题,我们采用了以下措施:

 

  • 在容器体系统一建设的同时,做到允许自定义,降低门槛;
  • 将镜像统一为公用几类(js/Java/Golang),统一维护安全更新;
  • 跨服务共用Build Cache;
  • 统一置入工具链、依赖、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 APP平台

 

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

 

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

二、每个服务都有各自的依赖,当我们想要对服务进行管理的时候,存在依赖管理的问题。

三、由于服务数量众多,服务手工升级过程也耗时耗力。

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

 

为解决以上痛点,我们提出了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最佳实践解析》

 

本文将从个推k8s集群概览、使用规范制定、使用经验总结三方面解析个推Kubernetes最佳实践,以帮助开发者在Kubernetes使用过程中根据企业自身应用和环境特点找到适合的方案。以下为其演讲提炼:

 

个推K8s集群概览

 

 

首先简要介绍下我们的组件地图与各组件的用途。如果用一把伞来比喻我们的组件地图,那么伞的核心组件是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请求压力过高。

 

解决方案:

  • 对边缘节点进行了改造,在node上部署了nginx,upstream中的节点通过实时从consul中获取服务的状态和ip实时更新,这样我们就绕过了service的流量分发,内部的转发也通过类似的方法去实现。
  • 由于ingress抗压能力强,故使用ingress也能实现流量负载均衡的需求,保证ingress到后端的流量是均衡的。

 

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

 

PPT 获取方式

 

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

(微信号:getuitech)

回复关键词“k8s”

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

 

Kubernetes 专场已圆满结束。本周六,个推TechDay系列线上技术沙龙将迎来【图】专场。

 

活动时间:2020年5月23日 14:00-16:00

活动主题:图挖掘实践及可视化应用

 

点击即可了解详细报名方式技术干货PPT及更多精彩内容请关注 “个推技术学院”公众号。