集群优化
思考：
现目前的架构是什么？业务逻辑？
研发一台，测试&生产共用一套k8s集群。
目前前端已经迁移到k8s，生产后端暂时没有上k8s。
造成目前架构的原因是什么？
历史遗留原因 造成架构不合理
那些地方不合理，为什么？
（1）.使用经典公网模式，会自动分配局域网ip地址 ， nginx-ingress-controller lb没有固定
（2）.使用名称空间做测试和生产环境的隔离，安全几乎无保障
（3）.线上只有一套环境而且是生产&测试两用，对于运维来讲等于没有测试环境(因为大多数系统应用具备全域穿透)
（4）.研发代码可以直接通过gitlab上生产，却不具备回滚功能，一旦出现未知bug(之前没有检测到的)，恢复不能做到快速简捷
（5）.集群架构和业务逻辑图没有做到实时更新，现有架构图不能清晰展示生产&测试 应用逻辑
（6）.权限不严格，目前公司内部的权限很混乱，目录结构也混乱，不能根据目录名称看出目录内容
（7）. 服务器优化不够，服务器上存在大量无效内容，造成服务器的运行不是很理想
（8）.服务器设备配置不合理，存在相当一部分小服务器，实用性不高
要改造的架构是什么？他们的优点？
对目前架构主要改造点：
（1）.将目前测试环境剥离出线上K8S集群
（2）.增配一套线上预发环境(缩小版生产环境)
（3）.将原集群的网络模式有经典公网改为专用网络+弹性IP
优点：
（1）.提高生产环境的稳定性和安全性
（2）.使用预发环境完全模拟生产环境，提高应用上生产的靠保障性
改造后能给公司带来什么？是效率更高？更安全？还是更省钱？
改造后的集群系统，形成，测试、预发、生产三套系统，测试在线下，预发和生产在线上，应用app 经过预发环境验证后再上生产环境，安全性得到保障。将小服务器更换大服务器，既省钱又便于管理维护。
改造牵涉的人有多少？需不需要动代码？
监管协助人：XXX
业务协助人：XXX
实际操作人：XXX
目前方案，确定不动代码。
考虑优化点：
统一环境名称： 研发 预发 生产
研发环境： 线下 供研发人员使用
预发环境： 线上 缩小版的生产环境，并且两者环境应尽可能一致（版本、应用等）
生产环境：线上 只有在预发环境经过验证的应用，且总结有相应操作步骤和故障演练的文档才能改动生产环境。
对生产的操作严格要求
（1）对生产的操作应提前在预发环境完成并得到验证(而不是在线下的研发环境)。
（2）对生产的操作要严格进行：公司内部通知、官网通告、预案报告
（3）对生产的操作要严格按照权限进行。生产的操作权限缩小到个别人。提高安全级别。
对集群的优化
（1）. 合理设置各目录的作用。如：
/data 目录放数据
/var/log/xxx 放日志
/service/scripts 目录放脚本文件
/yaml/xxx/xxx xxx是大的方向 比如日志系统(elfk) xxx是资源文件
（2）. 对集群的登陆 生产环境只能在公司办公区域内登陆，预发环境可以公网登陆 加强对集群的管理
（3）. 公司内部业务、集群(业务)拓扑图及时更新 有应用改动就更新
（4）. 加强对集群的稳定性优化 比如：对磁盘空间进行及时清理
（5）. 网络这块原：经典公网ip 新：专用网络 + 弹性IP
（6）.故障演练，每隔一段时间(半年)进行一次故障演练，可以及时有效的检验集群的健壮性
操作流程规范化
生产环境：
- 每次改动要提前提交邮件进行确认
- 每次改动要形成文档
- 每次在线上的改动要记录下操作命令和重要信息
- 线上的改动除紧急bug外，一律先在预发环境进行验证
- 对cicd流程 进行切分，预发cicd，线上cd。
- 对线上环境的改动要在办公区进行，且改动涉及到的所有人员都应该在现场。
响应等级
业务可用类故障等级表
等级 描述 赋值
一级故障
业务中断8小时
1
二级故障
业务中断2-8小时
2
三级故障
业务中断1-2小时，业务核心功能无法使用
3
四级故障
业务中断1小时，业务核心功能收到影响
4
五级故障
业务中断1小时以下，业务次要功能无法使用
5
故障响应时间表
故障等级 响应时间 联系人 解决时间
一级
1分钟
XXX、XXX、XXX、XXX、XXX、XXX
8小时
二级
1分钟
XXX、XXX、XXX、XXX
2-8小时
三级
1分钟
XXX、XXX、XXX
1-2小时
四级
1分钟
XXX、XXX
1小时
五级
1分钟
XXX
1小时
架构图优化
优化点：
1. 权限分明
2. 测试、预发、生产区分明
3. 可靠性、安全性比优化前更高
原文链接：https://www.cnblogs.com/zisefeizhu/archive/2020/06/12/13109631.html
以上是 集群优化 的全部内容， 来源链接： utcz.com/z/517372.html
