first commit

This commit is contained in:
douboer
2025-09-17 16:08:16 +08:00
parent 9395faa6b2
commit 3ff47c11d5
1318 changed files with 117477 additions and 0 deletions

62
cloudnative.md Normal file
View File

@@ -0,0 +1,62 @@
# 云原生
目前形成云原生理解上的最大共识概括为**4个核心要点**DevOps+持续交付+微服务+容器即基于这”4件套”构建的应用我们暂且认为就是云原生应用了。同时可以享受到云端极为丰富的PaaS组件如业务后续使用到的数据库、缓存、中间件、存储、CDN等等并且具备无缝在不同云厂商间透明迁移的能力。
微服务架构为基础,构建的集代码管理、服务开发、运维发布、服务运营为一体的一站式开发运营平台,实现了真正意义上的DevOps服务闭环贯穿了服务交付的CI、CD、CO环节得益于公司内外部更多优秀组件的集成包括TKE、蓝盾、QCI、Envoy等。
## **云原生运维转型思维**
这几年运维界听到最多的几句话:“云计算会淘汰掉运维!整个运维行业可能被干掉!再不转换运维就要丢饭碗”,诸如此类。那真相到底是什么?行业有一个共识,即运维工作本身交付的是一种服务,下面举一个可能不太恰当的例子,或者可以帮助大家找到答案。
云计算时代好比组装一辆汽车根据客户的需要通过PaaS能力选择匹配的引擎、车轮、离合器、 悬架、车控制系统等进行拼装。客户不用关心汽车各元部件的实现原理,最终获得是一辆满足自身要求的汽车。光有了汽车是玩不转的。还需要有修路、加油站、交通控制等服务体系,运维就是承担这个角色。
相比传统运维确实是少了自己采购元组与组装的工作。到了后云计算时代云原生出现了一个DevOps公司引入新技术与理念声称已经将修路、加油站、交通控制等环节都打通了形成了一体化服务能力并邀请运维哥一起加入创业。在这个阶段运维哥出去单干大概率会翻车。
但加入 DevOps 公司,运维的价值到底还有什么呢?因此,升级与转型是必然的,例如将普通国道升级成高速公路;实现客户在高速路上不停车换轮胎;贴近并理解客户,规划行程中所需的服务来提升客户体验;通过提升智能化水平,连接交通管制,缩短航程,避开损坏路段等等。相信大家心中已经有自己答案了。回到原点的灵魂拷问:“云原生背景下,运维不做转型会不会死?”,“运维要如何快速自救和升级?”。
## **文化层面**
以下几点是我们中心内部实行的几个机制,供作参考,因不同团队间存在一定差异,此处不展开说明。
开发与运维成立FT虚拟团队实现**组织融合**
开发或运维侧的例会、技术分享、事件复盘FT成员全程参与
项目立项时,运维接口人需要做“**左移**”,即提前参与技术架构讨论,有助于运维的问题提前在方案讨论或开发阶段提前暴露,有效做好防范与规避;
建立收集各方反馈问题与建议的机制与渠道,有效将好的想法影响至平台下个版本的迭代中,实现持续改进与优化。
## **云原生运维目标**
在云原生背景下,我们对运维体系进行了升级,在原有基础运维能力之上确定了以下几个目标:
具备服务全链路质量监控覆盖,涵盖数据域与业务域
具备一定智能化的资源动态调度、伸缩机制
具备一定的故障预警、根因分析、问题定位能力
服务具备在交付不同阶段(测试、预发布、运营)抵御异常的能力
具备资源高效交付的流程机制与快速上线的能力
具备多云的资源编排与管理的能力
具备业务快速上云的机制,确保切换过程的高可用性
确定了运维能力升级指导思想:**基于运维编排的云原生实例化**。广义而言,运维的本质就是多个运营事件的有机串联,来达到质量、效率、成本、安全多维收益,而编排是实现有机串联的有效手段,除了可以沉淀运维经验外,还可以有效实现共享。
CG: 一定要牢记**可沉淀、可积累、可共享**,形成迭代上升。
## **CI/CD**
## **平台能力**
**云端一切皆有操作**
- 云资源编排编排对象是各类云资源包括公有云、私有云等采用terraform来实现多云基础设施的编排可以覆盖腾讯云、阿里云、AWS、私有云等等。
- kubernetes编排编排对象是k8s集群资源采用Helm/YAML进行编排。
- 作业编排编排对象主要是主机节点对应的操作任务编排调用现有的蓝鲸job作业平台。
🐋[蓝鲸作业平台](https://bk.tencent.com/docs/document/5.1/7/3787)
运维编排三层之间如何串联?我们采用了开源的蓝鲸标准运维作为编排引擎,将不同的三层编排串联,打破从前跨云、跨平台各种割裂的操作界限,提升运维效率,一切皆编排,并能将编排任务沉淀为能力模板传承交接。
例如上图的场景我们需要扩容一个现网的TKE业务集群从基础设施层的资源采买到容器服务初始化部署和一些集群特性作业操作等均一站式运维编排完成操作时长从4小时优化到30分钟内而且集群再次扩容只需简单修改几个编排参数执行避免了繁琐重复的操作。在玄图平台能力中将通过自助开发可编排的原子包括操作、接口、算法等一切操作皆编排。
## **云原生监控**
## **云原生业务全链路跟踪(血缘关系链)**
## **混沌工程**
Adrian Cockcroft给出了另一个定义则是混沌工程是一种确保失败所带来的影响能够被减少的实验。
这里我们TKE集群中的服务设计了CPU负载注入演习启动实验后CPU按预期提升当CPU持续高负载时服务正常且触发自动扩容无请求超时用户无感知符合预期加深了团队对系统可靠性的理解和认知。
## **优势**
## reference
- [云原生背景下的运维价值思考与实践](https://cloud.tencent.com/developer/article/1753976)