从运维的角度理解云原生

1. 需求的根本——应用交付(CI/CD)

CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。

1.1 持续集成CI

持续集成&＃xff08;CONTINUOUS INTEGRATION&＃xff0c;CI&＃xff09;指的是开发人员频繁的&＃xff08;一天多次的&＃xff09;将所有开发者的工作合并到主干上。这些新提交在最终合并到主线之前&＃xff0c;都需要通过编译和自动化测试流进行验证&＃xff0c;以保障所有的提交在合并主干之后的质量问题&＃xff0c;对可能出现的一些问题进行预警。持续集成的核心在于确保新增的代码能够与原先代码正确的集成。

持续集成带来的好处是&＃xff1a;

• 易于定位错误
• 易于控制开发流程
• 易于Code Review
• 易于减少不必要的工作

1.2 持续交付CD

持续交付&＃xff08;CONTINUOUS DELIVERY&＃xff0c;CD&＃xff09;的侧重点在于交付&＃xff0c;其核心对象不在于代码&＃xff0c;而在于可交付的产物。由于持续集成仅仅针对于新旧代码的集成过程执行了一定的测试&＃xff0c;其变动到持续交付后还需要一些额外的流程。

持续部署带来的好处是&＃xff1a;

• 发布频率更快&＃xff0c;因为不需要停下来等待发布。每一处提交都会自动触发发布流
• 在小批量发布的时候&＃xff0c;风险降低了&＃xff0c;发现问题可以很轻松的修复
• 客户每天都可以看到持续改进和提升&＃xff0c;而不是每个月或者每季度&＃xff0c;或者每年
• 自动实时的部署上线&＃xff0c;是最优的解决办法&＃xff0c;但持续部署的要求是团队非常成熟&＃xff0c;并且上线前是需要经过QA测试的&＃xff0c;所以实际情况下很难实现&＃xff0c;一般的团队也很难接受&＃xff0c;挑战和风险都很大。

2. 应用交付(CI/CD)的发展

CI/CD这些年&＃xff0c;经历了快速发展&＃xff0c;应用从开发到交付的流程也越来越方便和自动化。

2.1 裸机/虚拟机

在传统裸机&＃xff08;bare metal&＃xff09;或虚拟化的时代&＃xff0c;当开发团队将代码交付给运维进行生产环境中部署&＃xff0c;但是它却未能正常工作时&＃xff0c;挑战就出现了。

“运行环境不一致”、“没有安装相关依赖软件”、“配置文件不一样”等等已经成了开发和运维沟通的惯用语。

2.2 容器

有了容器之后&＃xff0c;由于容器镜像里打包的不仅是应用&＃xff0c;而是整个操作系统的文件和目录&＃xff0c;即其运行所需的所有依赖&＃xff0c;都能被封装一起。我们只需要解压这个容器镜像&＃xff0c;那么这个应用所需的所有运行依赖都是存在的、一致的。

2.3 k8s

在单机上运行容器&＃xff0c;无法发挥它的最大效能&＃xff0c;只有形成集群&＃xff0c;才能最大程度发挥容器的良好隔离、资源分配与编排管理的优势。

一个专门用于容器编排调度的工具呼之欲出&＃xff0c;Kubernetes的出现彻底改变了局面&＃xff0c;可以说它直接改变了应用的基础架构。而Kubernetes这种声明式配置尤其适合CI/CD流程。

2.4 云原生

从宏观概念上讲&＃xff0c;云原生是不同思想的集合&＃xff0c;集目前各种热门技术之大成&＃xff0c;CNCF&＃xff08;云原生计算基金会&＃xff09;给出了云原生应用的三大特征&＃xff1a;

• 容器化包装&＃xff1a;软件应用的进程应该包装在容器中独立运行。
• 动态管理&＃xff1a;通过集中式的编排调度系统来动态的管理和调度。
• 微服务化&＃xff1a;明确服务间的依赖&＃xff0c;互相解耦。

2.5 使用Jenkins进行CI/CD

1. 用户向Gitlab提交代码&＃xff0c;代码中必须包含Dockerfile
2. 将代码提交到远程仓库
3. 用户在发布应用时需要填写git仓库地址和分支、服务类型、服务名称、资源数量、实例个数&＃xff0c;确定后触发Jenkins自动构建
4. Jenkins的CI流水线自动编译代码并打包成Docker镜像推送到Harbor镜像仓库
5. Jenkins的CI流水线中包括了自定义脚本&＃xff0c;根据我们已准备好的Kubernetes的YAML模板&＃xff0c;将其中的变量替换成用户输入的选项
6. 生成应用的Kubernetes YAML配置文件
7. 更新Ingress的配置&＃xff0c;根据新部署的应用的名称&＃xff0c;在Ingress的配置文件中增加一条路由信息
8. 更新PowerDNS&＃xff0c;向其中插入一条DNS记录&＃xff0c;IP地址是边缘节点的IP地址。
9. Jenkins调用Kubernetes的API&＃xff0c;部署应用

3. OAM

3.1 基于 Kubernetes 的 DevOps 平台新挑战

随着云原生时代的到来&＃xff0c;以面向终态设计著称的申明式 API 逐渐打破了原有 DevOps 的工作模式。用户只需申明一个应用的 YAML 格式&＃xff0c;便可以在 K8s 上快速部署和交付软件。

然而 K8s 的 API 并非完美

• 依然有大量用户觉得 YAML 文件复杂难以理解
• 各类云资源也无法用原生的方式统一调用
• 复杂应用依然难以部署和管理
  

3.2 OAM 应用模型

OAM 是以应用为中心的分层模型。

OAM应用 &＃61; Component &＃43; Traint:

• Component
  OAM 中常见的概念是 Component 组件&＃xff0c;完全从研发角度定义的待部署单元。组件&＃xff0c;组合起来就可以构建简单的应用。
• Trait
  如果关心应用运维的问题&＃xff0c;OAM 中有 Trait 的概念&＃xff0c;指的是在原来组件的基础上附加一些特征。特征指的是运维的能力&＃xff0c;如手动扩缩容能力、外部访问能力、发布、负载均衡。弹性扩缩容、基于流量的管理等等。

有了OAM之后&＃xff0c;研发只需要关心component, 运维给component加上trait。

参考

如何基于 K8s 构建下一代 DevOps 平台&＃xff1f;
云原生技术实践公开课