原创

基于Kubernetes 构建.NET Core 的技术体系

很多公司技术支持岗位的工作,如配置域名,部署环境,修改复位配置,服务重启,扩容缩容,梳理和完善监控,根据开发的需要查找日志等工作,需要和开发进行大量的沟通,如什么是外网域名,什么是内网域名、A name、C name,防火墙规则该如何设定,操作系统等基础环境需要什么依赖。因为很多研发不了解运维的术语和知识点,导致沟通困难,效率很低。而且这样的需求还很多,把运维压的喘不过气,占用了几乎所有的时间,但是开发的需求可能还是迟迟不能满足。

这样的公司可能遇到了以下问题:

  • 系统架构过于陈旧,性能、可靠性无法满足现有的需求;
  • 原有IT架构不灵活,业务模块新增或变更带来巨大成本压力;
  • 系统功能繁杂,结构紊乱,定制的代码与系统耦合性极高;
  • 服务种类繁多,各种技术栈横行;
  • 人员流动交接不充分,新接手的团队对部署环境不了解,只能做周边的修补,不敢迁移 。


如何才能解决?答案是流程化、标准化、自动化、平台化。

流程化

即主动梳理运维工作任务,形成标准化的操作流程,尤其是针对需要多人协作完成的任务,比如应用的发布部署,把流程固化到流程平台系统中,保证每个人执行都能按照流程严格执行,不会有哪些环节遗漏,而且当前的流程状态对所有人都可见,能清晰的看到谁正在处理,处理人也会更主动尽快的完成该任务。

标准化

从架构角度按照应用类别制定应用的部署标准,比如Web类型的应用,服务化的应用(我们内部用的.NET Core),或者是比较新的微服务的应用(.NET Core等),部署脚本和工具平台按照约定好的规范进行设计开发(基于Kubernetes),减少了因为应用种类繁多导致工具和平台的复杂。

自动化

很多公司早期写了非常多的脚本,任务执行机到要执行任务的服务器之间通过SSH免密钥认证,再根据需要批量执行命令。随着服务器规模和应用数量的扩张,很快脚本执行的方式无法满足业务发展,难以理解,同一个类型的任务多个脚本并存,存在误操作,缺乏清晰的操作历史记录和回滚机制,即使后续替换了如Puppet,Saltstack,Ansible这样的配置管理工具,但根本问题并没有解决。

平台化

平台化一定要在前面三条的基础上进行建设,如果没有清晰的流程,明确的标准,平台建设起来也只是自动化工具的集成,解决不了公司核心问题。

以下说的平台化内容主要是PaaS平台化,即主要从应用和中间件的角度,这里不讨论IaaS的内容。

PasS平台化将问题的关注点从基础资源上升到了应用层面,目标是提供一个帮助开发人员运行、管理应用的平台,让使用者更关注运行的代码(业务逻辑)。
PaaS能解决的问题:

  • 应用聚合:如开发需要一个Redis,直接启动一个Redis容器即可
  • 服务发现、快速伸缩、状态管理等
  • 服务监控、恢复、容灾
  • 安全管控:不管什么平台,安全都非常重要,例如A应用可以访问B,B不允许访问A以及安全审计等。
  • 快速部署。


随着Docker容器技术的出现,让我们有了更合适的工具建设PaaS平台,具备了基于应用构建服务的能力。 在Docker容器调度框架上,我们自然选择了Kubernetes平台。Kubernetes具有资源调度、服务发现、服务编排、资源逻辑隔离、服务自愈、安全配置管理、Job任务支持、自动回滚、内部域名服务、健康检查、有状态支持、运行监控/日志、扩容缩容、负载均衡、灰度升级、容灾恢复、应用HA等。Kubernetes的核心是如何解决自动部署,扩展和管理容器化(containerized)应用程序。

下图是一张最小化的PaaS 架构图:

基于kubernetes的开发运营平台

  1. 最上面的Ingress服务跟传统的负载均衡器的功能类似,提供请求分发的功能,分为两类: 对外提供API服务的API网关以及对外提供服务的站点,对外的API网关采用Ocelot 进行开发,Ocelot完成了对Kubernetes的集成工作,这个功能已经在我们的平台上工作一段时间了,上个月把代码合并进入Ocelot主干,已经可以通过Nuget包下载,具体参见 kubernetes 客户端KubeClient使用及常用api
  2. Service相当于后端Pod的一个代理服务器,Service需要通过Ingress服务才能被外部Client访问, Service 提供了服务的注册和服务发现。
  3. Pod则相当于我们传统的一个服务。
  4. 最小化PaaS平台还用到了DNS组件,在内部服务运行起来之后,我们会通过DNS组件分配一个内部域名供访问时使用。

Kubernetes 选用腾讯云 TKE ,TKE 服务在集群内默认启用了基于腾讯云负载均衡器实现的 l7-lb-controller,支持 HTTP、HTTPS,同时也支持 nginx-ingress 类型,可以根据业务需要选择不同的 Ingress 类型。

平台关键能力说明
  • 应用持续部署,平台实现快速、可视化自动部署功能。支持对应用的快速、可视化部署。用户仅需在界面中选择相应的镜像和组件,并填写简单的配置信息,点击部署按钮,即可完成整个应用的安装或者升级。
  • 应用弹性伸缩,构建具有需求预测和容器按需供给能力的弹性伸缩子系统,具有基于应用的负载和资源情况进行弹性伸缩能力,以应对互联网用户高并发的特点,应对流量冲击。其中,包括容器弹性伸缩、物理机弹性伸缩功能。
  • 容器和组件的统一管理,从整体应用的角度出发,平台不仅管理镜像和容器,而是将一个应用涉及的所有组件均做了统一管理,通过对系统相关组件和容器统一管理,平台将可以实现系统的全局统一部署、配置、升级/回滚、监控、故障处理等功能。
  • 高可靠性,容器的故障恢复,当服务器宕机时,平台系统会自动在其它服务器上重新启动容器并为其分配资源,从而达到秒级启动,恢复业务。保障业务不掉线,高可靠运行;
  • 应用Docker化封装,系统支持如下几类常见应用:.NET Core、Jexus、Nginx、Redis、Mongodb等。
PaaS平台功能组件

具体实施时,主要有几个基础组件需要开发:

  • 镜像管理,实际运行的应用镜像由 “基础中间件镜像”+“应用包”+“配置” 自动构建,借助于Visual Studio 2017/2019以及Visual Studio Code,以及微软开源的Helm、Draft,通过标准化内部培训,让开发人员快速理解镜像概念和制作镜像以及开发流程;
  • DNS管理,定制化公司内部使用的DNS管理平台,对公司的DNS进行统一管理;
  • 服务管理,需要定制化一套Kubernetes的Deployment模板,从Ingress到Service再到RC都定义在这套模板里面,方便对容器进行扩容、缩容、删除操作;
  • 服务内Pod管理,属于Kubernetes自有范畴,查看Service内的Pod运行情况、Pod日志输出等功能;
  • 日志管理,将日志输出到公司的日志平台(如ELK平台),对接研发人员排查问题、数据埋点使用;
  • 监控管理,参考方案:cAdvisor + InfluxDB + Grafana/ Heapster + Grafana/Prometheus/Zabbix:https://www.cnblogs.com/Cherry-Linux/p/9144650.html


虽然我们属于创业公司,我们相信技术的力量,技术帮助我们实现业务的持续健康发展,从发展的初期就规避很多公司的一些困境,一个中小企业做成这样后,日常运维的工作量即可大量减少,两三个人就能完成日常的应用运维工作,有兴趣地话可以去挑战一下。当然做完这些后,还只是一个小型的PaaS平台,我们基于腾讯云的TKE 平台构建这样一个小型的PaaS平台。
如果是再复杂一点的PaaS平台,应该还有哪些要继续做的呢?环境管理:即一套平台管理多套不同的Kubernetes集群、安全管理、流程管理、计费管理等功能模块。还有因为规模增加和更高的可靠性要求,对应的网络,IO等各种优化。其实还有很多功能就不一一列举了,可以根据自己的实际情况添加功能模块,设计有自己公司特色的PaaS平台。

正文到此结束
本文目录