我在创业公司的云原生之旅


【编者的话】始终认为IT是一座道场,修道,修道,修一座自己的道场。在毕业的近1年中,经历了入道、闯道、修道阶段,到目前的悟道阶段。需要提升和掌握的知识还有很多,技术没有止境,依然在路上。云原生是一条充满机遇的路,坚持与不断追求才能翻过一座又一座高山。

前言

IT是一座道场!
0.png

2020年5月中旬本科毕业后,进入严格意义上的第一家公司。当时带我的是阿里云的MVP,也是公司的CTO,跟着他(石老大)学到了很多很多,带领我经过了入道(机会,不是人人都有,请感恩,给你机会和帮助的人)。三个月后他离职了,感谢石老大,正是他的离职给了我独自闯道的机会。

2020年9月开始进入了闯道(孤独,痛苦和煎熬会时常与你共舞)、修道(别忘了,给风雨中的自己一个鼓励)、悟道(认知和思想,是拉开人与人之间的重要差距)阶段。可以说自石老大走后,我的任务都是自我安排,技术都是自我驱动实现的。

2019年7月离开学校时,告诉自己:我的路是一条追逐云原生的路。自2018年8月接触Kubernetes时就深深爱上了这条路。

2020年6月初进入公司后,实实在在感受到了创业公司的集群环境之乱(只有前端业务Kubernetes化且测试和生产通过namespace区分、生产Kubernetes资源特别低且服务副本数只有2个、GitLab代码仓库是部署在Kubernetes环境上的、权限混乱等)。提出了一些自己的解决方案:http://dockone.io/article/2434572

2020年6月构建以ELFK为技术核心的日志系统(只收集网关日志即nginx-ingress日志为唯一收集源)。

2020年7月围绕业务全面Kubernetes化展开,主导了业务从一到零再到一的过程。

2020年8月和9月忙于集群和CI/CD重构。新增了测试环境、预发环境,将网关由nginx-ingress改为kong-ingress,将GitLab从Kubernetes环境中剥离出来,借助cert-manager实现证书的自动申请和续签,增加堡垒机更正权限混乱问题,使用gitlab-runner实现多Kubernetes集群的自动化部署等。

2020年10月专攻于“监控预警系统”,实现三个纬度的监控,期间第一次参与并主导私有化项目的部署。

2020年11月以“ISTIO服务治理”为重心,在测试环境验证了连接、安全、流控、可视,期间开发了envoyfilter插件对接鉴权服务。

2020年12月和1月围绕“Kubernetes下微服务的日志系统”展开,实现了多Kubernetes集群服务和裸机服务的日志统一到一个管理平台。

2021年1月和2月实现了将预发环境的kong-ingress过度到istio。并对接了证书服务、监控预警系统和日志系统。

2021年3月忙于私有化部署和Istio准备上生产环境的验证。

2021年4月忙于旧服务器治理、私有化部署、聚石塔方面的有关工作。

2021年5月忙于Istio生产启用、聚石塔和私有化部署的工作。

在公司近1年中创建了13个代码仓库,写了130余篇技术文档,

2020年6月初经过规划了一张“基于Kubernetes的企业级集群架构”,经过和CTO及向有关人员的阐述,准备实施此架构:

1.png

此架构规划了三个集群环境:生产环境、预发环境、测试环境。

此架构除业务和项目外还增加了边界服务:统一日志管理平台、监控预警系统、链路追踪、统一管理平台、证书自动续签、流控等,下面将重点围绕此展开。

基于Kubernetes的企业级集群架构重点部分浅解

重构集群架构、业务全面容器化

这是一个从一到零再到一的过程,刚毕业即接触此类项目,实属幸运。

大致重构步骤如下:
  • 根据原有业务设计容器化架构方案;
  • 新增堡垒机Jumpserver;
  • 制作前后端业务镜像;
  • 新增测试环境Kubernetes集群、预发环境Kubernetes集群、改造原生产环境Kubernetes集群;
  • 借助Gitlab-Runner、GitLab、Kustomize等实现多集群的CI|CD;
  • 和有关同事一起定义前后端日志字段和输出形式;
  • 协助后端团队微调原裸机业务源码;
  • 借助Rancher实现对多Kubernetes集群的统一管理;
  • 用Cert-Manager实现域名证书的自动申请和续期;
  • 写Shell脚本对Gitlab备份进行检查、裸机服务备份进行检查、对域名有效期进行检查。


统一日志管理平台

此项目应是我近一年的最大收获了,思想上。

大致实现思路:多Kubernetes集群的namespace绝对不能重复,Elasticsearch、Kibana、Logstash、Kafka独立于集群环境外且共用一套,Filebeat、Metricbeat、kube-state-metrics需要在每个Kubernetes集群中都存在一套、Metricbeat和tag需要标准清晰明了、日志以json格式输出且不允许多行日志出现。

一提之举在:实现了多集群、多环境日志的统一化管理。

CI/CD

基于我司目前的研发现状,选择的自动化部署工具为gitlab-runner。代码仓库创建规范可以参考:https://www.cnblogs.com/zisefeizhu/p/13621797.html

大致实现思路:研发提交代码代码到特定分支(分支区分环境,生产分支需要项目总监merge) --> 镜像打包(由预发Kubernetes集群的一台特定节点执行) --> 根据.gitlab-ci.yml规则进行业务Pod化。

一提之举在:
  • 通过分支区分环境
  • 镜像打包只在一台预发环境的特定节点执行,减少因打包镜像而对生产环境带来的波动,且可以存在镜像利用
  • 大量借助内置变量通过提前写的脚本提高Kubernetes 部署部分的资源清单的重复可用性


监控预警系统

实现三个纬度(业务监控、应用监控、操作系统)的监控预警系统。

其中业务监控主要是研发提供一些业务指标、业务数据。对其增上率、错误率等进行告警或展示,需要提前定义规范甚至埋点。

应用程序的监控主要有探针和内省。其中探针主要是从外部探测应用程序的特征,比如监听端口是否有响应。内省主要是查看应用程序内部的内容,应用程序通过检测并返回其内部的状态、内部的组件,事务和性能等度量,它可以直接将事件、日志和指标直接发送给监控工具。

操作系统主要是监控主要组件的使用率、饱和度以及错误,比如CPU的使用率、CPU的负载等。

一提之举在:
  • 三个纬度
  • 裸机也进行监控
  • windows也进行监控


服务治理

随着业务的不断微服务化、对于服务的运行的失控感越来越强、且对东西向流量的管理成为了急需解决的痛点、而Kong网关的A/B test是付费版的开箱即用功能,而我司恰恰开始需要此功能。基于上服务治理开始进行视野。

我司对于服务治理的使用应算中度依赖,主要使用到如下点:
  • 负载均衡:基础服务使用最少连接策略,业务层服务使用一致性哈希负载均衡。
  • 健康检测:输出健康检测具体配置方案。(如:基础移出时间30秒,10秒内出现3次错误移出,检测时间间隔为10秒……)
  • 连接池:创建连接池,每个实例最大处理请求数为10,每个连接处理2个请求后关闭,重试次数为3次,连接超时时间为500ms。
  • 熔断策略:根据健康检测和连接池策略实现熔断策略
  • 重试策略:最多重试3次,每次调用超时为2秒。
  • 限流策略:后期用户数提高后再实行。
  • 链路追踪


一提之举在:基于EnvoyFilter和Lua开发对接鉴权服务和Istio。

私有化部署

因我司主打产品为3D编辑器,数据保密性要求极高,大型企业更在意数据由自己掌握,所以在这近一年中做了好几个私有化部署项目。

在做私有化部署项目中学到了很多:
  • 业务:需要知道客户需求牵扯到的服务有那些,作出路由规划表。
  • 集群:根据客户的需求,估算出资源需求。
  • 沟通:需要和客户(基本是非技术类)、我司运营等人于啊进行技术上的沟通,需要将繁琐的技术通俗化。
  • 时间:根据客户的规定时间和我司的实际现状规划出准备、部署、测试、交付的时间段,考验项目时间把握度。
  • 协调:在项目部署中难免会出现一些配置类的问题,需要后端人员介入。


一提之举在:私有化部署严重考验对业务、集群的熟悉度,是考验一个运维人员的技能修养的。

总结

始终认为IT是一座道场,修道,修道,修一座自己的道场。在毕业的近1年中,经历了入道、闯道、修道阶段,到目前的悟道阶段。

需要提升和掌握的知识还有很多,技术没有止境,依然在路上。云原生是一条充满机遇的路,坚持与不断追求才能翻过一座又一座高山。

展望

  • 悟道(认知和思想,是拉开人与人之间的重要差距)
  • 试道(出道下山、世界这么大)
  • 围绕Kubernetes展开云原生的涉猎,更快的参与二开和社区。


过手如登山,一步一重天!

原文链接:https://www.cnblogs.com/zisefeizhu/p/14601287.html

0 个评论

要回复文章请先登录注册