来源：https://www.cnblogs.com/zisefeizhu/p/14601287.html

2020年6月初进入公司后，实实在在感受到了创业公司的集群环境之乱(只有前端业务Kubernetes化且测试和生产通过namespace区分、生产Kubernetes资源特别低且服务副本数只有2个、gitlab代码仓库是部署在Kubernetes环境上的、权限混乱等)。提出了一些自己的解决方案：https://www.cnblogs.com/zisefeizhu/p/13692782.html
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及向有关人员的阐述，准备实施此架构image.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格式输出且不允许多行日志出现
一提之举在：

  • 实现了多集群、多环境日志的统一化管理

CICD

基于我司目前的研发现状，选择的自动化部署工具为gitlab-runner。代码仓库创建规范可以参考：https://www.cnblogs.com/zisefeizhu/p/13621797.html。
大致实现思路：研发提交代码代码到特定分支(分支区分环境，生产分支需要项目总监merge) —> 镜像打包(由预发Kubernetes集群的一台特定节点执行) —> 根据.gitlab-ci.yml 规则进行业务pod化。
一提之举在：

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

监控预警系统

实现三个纬度(业务监控、应用监控、操作系统)的监控预警系统。
其中业务监控主要是研发提供一些业务指标、业务数据。对其增上率、错误率等进行告警或展示，需要提前定义规范甚至埋点。
应用程序的监控主要有探针和内省。其中探针主要是从外部探测应用程序的特征，比如监听端口是否有响应。内省主要是查看应用程序内部的内容，应用程序通过检测并返回其内部的状态、内部的组件，事务和性能等度量，它可以直接将事件、日志和指标直接发送给监控工具。
操作系统主要是监控主要组件的使用率、饱和度以及错误，比如CPU的使用率、CPU的负载等。
一提之举在：

  • 三个纬度
  • 裸机也进行监控
  • windows也进行监控

服务治理

随着业务的不断微服务化、对于服务的运行的失控感越来越强、且对东西向流量的管理成为了急需解决的痛点、而Kong网关的ab test是付费版的开箱即用功能，而我司恰恰开始需要此功能。基于上服务治理开始进行视野。
我司对于服务治理的使用应算中度依赖，主要使用到如下点：

  • 负载均衡：基础服务使用最少连接策略，业务层服务使用一致性哈希负载均衡。
  • 健康检测：输出健康检测具体配置方案。（如：基础移出时间30秒，10秒内出现3次错误移出，检测时间间隔为10秒…）
  • 连接池：创建连接池，每个实例最大处理请求数为10，每个连接处理2个请求后关闭，重试次数为3次，连接超时时间为500ms。
  • 熔断策略：根据健康检测和连接池策略实现熔断策略
  • 重试策略：最多重试3次，每次调用超时为2秒。
  • 限流策略：后期用户数提高后再实行。
  • 链路追踪

私有化部署

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

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

一提之举在：

  • 私有化部署严重考验对业务、集群的熟悉度，是考验一个运维人员的技能修养的

这篇文章挺厉害的，把我很多想法概况出来了，哈哈哈，学习下。不过他刚毕业一年就明白这些还是很厉害的，我出来四年了才弄明白，前面三年想其他去了，最近一年才回归技术上。
总结下：
整体项目可分为几部分：集群相关、日志系统、监控系统、CICD的实现、服务治理（这个我还没实践过），优化也是从这个几方面入手

我觉得：生产单独一套集群、开发 测试 压测 预生产 可以放到一套集群（控制预算的情况下），预生产有些配置要跟生产环境一样（只是说环境，并不是预生产配置跟生产配置一样），按业务线划分env_namespace，非生产权限可以全部下放，就按不同的namespace授权给各自的业务线。
日志系统可以先用阿里云的，后续自建，参考阿里云的收集方式。
监控系统也是可以照搬阿里云监控系统的指标，很全面，上家就是的，出现问题我们很快响应到位了，上家觉得最好就是监控系统，除Prometheus+grafana业务监控外，还有一套自己开发的监控系统，监控网页关键字、域名证书、访问页面状态码、图片（CDN）等信息，即时时监控网页是正常的。
在业务流量高峰的时候，会到监控系统中查看当前pod所使用的资源，不对的话会在流量下来后打印程序dump文件给开发检查，每次上新版本后都会如何，再根据链路监控，评估出该容器需要配置多少资源，这样上家生产环境没出现过pod jvm类问题
CICD 上家也可以，出去面试才发现，上家的已经是很便利的了，jenkins集群独立，使用的是pipeline，每个项目一个yaml，yaml中就是项目的信息，gitlab路径 项目域名 环境信息，及其他项目对应所需的信息，更重的是pipeline中的stage也是在这个yaml中的，第一个stage 拉取代码，第二个stage 编译（前端不用），第三个制作镜像，第四个部署容器，这里有两部分，之前还是docker部署的，使用的是ansible，后面上k8s了，使用的是helm，helm就部署一个yaml，这个yaml里面是deployment、service、ingress、configmap等信息，apollo、eureka、nacos可以配置到configmap中，最后是检测该容器是否部署成功。
整理来说，流程比上面文章兄弟的公司简单，也满足需求，但功能性还没这么强。