K8S云原生系统架构优化

【摘要】

原生的K8S集群系统架构优化思路、过程及解决方案记录

【案例正文】

【背景】

公司在政务云环境部署了一个系统，同事自建的K8S集群V1.19.0，面板管理和展示用Kuboard 

v2.0.5.1。系统分正式环境和测试环境，均为一个控制节点+两个工作节点，节点均为虚拟机部署在政务云公共服务域（与互联网隔离）。

【问题】

正常情况下系统仅存在一些高可用和成熟度方面的问题，但是节点故障宕机情况下系统可用性很差，整体来看云原生成熟度不高。

【过程与结果】

【初步解决思路】

小问题和报错很多，具体优化项中再列举，先看一下整体的架构成熟度：

1）首先，按照我们给政务应用系统评估的标准，系统架构评估指标应该分为【上云前亲和度】和【上云后成熟度】。本系统在开发阶段已确定使用微服务架构，前后端数量也已明确，不涉及上云前亲和度评估，仅评估上云后成熟度-技术先进性（参考阿里云云原生架构成熟度SESORA）。

    S微服务化：容器化与微服务结合；

                        使用自建容器编排平台K8S，但是目前并没有达到理想的容器编排效果；

                        几十级微服务数量，简单微服务治理

   E弹性能力：手动扩缩容；

   S无服务器化：使用Paas，无状态计算委托给云；

   O可观测：不可观测；

   R韧性能力：高可用方面，负载自动漂移和自动故障转移均未达到；备份涉及物理机暂不考虑；

   A自动化：不具备自动化交付和运维能力；

2）按我们自己的标准，我们自己的系统得分45分，处于云原生的发展级，这就很尴尬了......

【解决方案】

1）评估后能够提升的能力包括

容器编排/微服务治理/弹性能力/可观测/韧性能力；

2）不可提升的能力及原因

       无服务器化：政务系统建设方案有相关要求，节点明确要求使用虚拟机，现阶段升级为Serverless架构不太现实；无状态计算已经委托给云，有状态存储委托给云涉及到数据库迁移，相当一部分后端业务配置的是本地数据库地址，更改将会影响正常使用的业务（也不具备割接条件）。

       服务网格：同样是架构升级的大工程，SpringCloud+Nacos大家使用很习惯，转为ServiceMesh面临较大难度，且现阶段工作较多，可以加到to-do list。

       自动化：与上述理由差不多，自动化交付和运维不仅仅是个技术问题，更是个管理问题，自动化交付工具CI/CD、IAC、operator、Gitops、OAM都不现实，属于长期工作。

3）确定要优化的能力后，先做什么？

      答案是先搞个混沌工程。

混沌工程的官方解释是：混沌工程是在分布式系统上进行由经验指导的受控实验，观察系统行为并发现系统缺陷，以建立对系统在规模增大时因意外条件引发混乱的能力和信心。

它会随机终止在生产环境中运行的EC2实例，工程师们可以快速了解他们正在构建的服务是否健壮，有足够的弹性，可以容忍计划外的故障。

混沌工程可以主动注入故障，以期提前发现潜在问题，迭代改进架构和运维方式，最终实现业务韧性。

它的目标是：为了具体地解决分布式系统在规模上的不确定性，可以把混沌工程看作是为了揭示系统缺陷而进行的实验。破坏稳态的难度越大，用户对系统行为的信心就越强。如果发现了一个缺陷，那么用户就有了一个改进目标，避免在系统规模化之后问题被放大。

具体的混沌工程详细介绍可以去看官方文档，在此不做赘述。

个人理解混沌工程是在满足先决条件下，即分布式系统且具备一定的弹性和观测性，最快确定未知缺陷和故障爆炸范围的方式。当然混沌工程需要熟练使用相关的工具和指标设计，由于专业的测试同事休假了，在此只借鉴混沌工程的思路，重复多次地节点宕机来确定未知缺陷和目前存在的问题以及问题影响范围，同时对优化后的指标也有一个直接的反馈。

要注意：使用混沌工程测试一定要满足几个先决条件，如分布式、弹性、可观测（监控），否则是无法控制爆炸半径和后果的。

其实我们这个系统也不满足混沌工程的条件，而且因为是物理机控制台不在我们这里，开机也麻烦；但是这是最快的方式，且宕机前已反复确认是一个没有影响的测试环境，所以就暴力推进了。

先写到这里，明天再从混沌测试的结果开始梳理优化项和问题解决方案。