Skaffold v2 渲染与部署架构深度解析-优快云博客

本文链接：https://blog.youkuaiyun.com/gitblog_00499/article/details/148377608

Skaffold v2 渲染与部署架构深度解析

skaffold Easy and Repeatable Kubernetes Development 项目地址: https://gitcode.com/gh_mirrors/sk/skaffold

前言

在现代云原生应用开发中，Kubernetes 配置管理一直是一个复杂且具有挑战性的任务。作为 Kubernetes 开发工具链中的重要一环，Skaffold 项目正在经历一次重大的架构演进。本文将深入剖析 Skaffold v2 版本中全新的渲染（Render）与部署（Deploy）架构设计，帮助开发者理解其核心思想和技术实现。

核心概念解析

DRY 与 WET 配置

在 Skaffold v2 的设计中，配置被明确分为两种状态：

DRY 配置：原始应用配置，可能包含变量、基座/覆盖层（kustomize 结构化布局）等未展开的元素。这类配置尚未经过任何验证或操作检查，不能直接被集群理解。
WET 配置：经过处理的应用程序配置，已经从 DRY 结构扁平化，并通过了一系列验证、生成和转换操作，是纯粹的 Kubernetes 资源，可以直接应用到集群。

这种区分使得配置管理过程更加清晰和可控。

现有架构的问题

当前工作流分析

Skaffold 目前的工作流主要包含以下几个步骤：

构建容器镜像
标签管理
配置验证
配置生成/转换
部署到集群

当前支持四种"部署器"（deployer）：kpt、kustomize、helm 和 kubectl。每种部署器在不同步骤中执行的操作存在显著差异。

主要问题总结

部署器范围混淆：部署器名称与实际功能不符。例如，kustomize "部署器"实际上没有部署操作（依赖 kubectl），但却被称为部署器。
混合使用问题：不同部署器的混合使用通常意味着用户在使用变通方案填补功能空白，这会加剧已知问题并使 Skaffold 更加脆弱。
当前 kpt 部署器的限制：基于 kpt v0.34.0 设计的部署器存在兼容性问题，缺乏配置资源路径 DAG 检测，处理方式不够声明式原生。

Skaffold v2 架构设计

总体设计思路

Skaffold v2 的核心设计是将配置管理明确分为两个正交的关注点：

配置水合（渲染）：将 DRY 配置转换为 WET 配置
配置部署：将 WET 配置应用到 Kubernetes 控制平面

新架构将完全依赖 kpt 作为技术基础，提供配置打包、水合和部署的标准 API 和工具链。

新渲染功能设计

两种渲染模式

kpt 管理模式：适用于已经使用 kpt 水合功能的用户，直接指向声明式的 Kptfile。
Skaffold 管理模式：在 skaffold.yaml 中直接定义水合管道，包含三类操作：
- 生成：定义配置来源（原始清单、kustomize 资源、helm 图表等）
- 转换：定义变更配置的操作（仅允许白名单工具）
- 验证：定义验证配置的操作（仅允许白名单工具）

配置示例

apiVersion: skaffold/v3
kind: Config
render:
  generate:
    manifests:
      - k8s-pod.yaml
    helmCharts:
      - path: charts/myapp
        valuesFile: values/prod.yaml
  transform:
    - name: set-annotations
  validate:
    - name: kubeval
  output: rendered/

新部署功能设计

部署部分大幅简化：

不再支持 helm 安装（仅支持 helm 图表渲染）
仅使用 kpt live 应用 WET 配置
不再需要指定部署器名称

deploy:
  dir: rendered/
  inventoryID: my-app
  inventoryNamespace: default

技术实现细节

kpt 管道集成

无论是 kpt 管理模式还是 Skaffold 管理模式，最终都由 kpt fn render 命令驱动：

对于 kpt 管理模式，直接从 .render.kpt 路径读取 Kptfile
对于 Skaffold 管理模式，动态创建 Kptfile

Skaffold 会创建临时目录 .kpt-hydrated 缓存 kustomize DRY 配置、helm 图表和原始清单，kpt 将在临时目录中就地水合配置。

kpt live 集成

kpt live 依赖 ResourceGroup 准确地将 WET 配置部署到集群：

skaffold dev 和 skaffold deploy 会检测并在获得用户许可后安装 ResourceGroup 控制器
使用 kpt live apply 命令执行实际部署

内置 kpt

Skaffold 将通过 go bindata 嵌入 kpt，与 skaffold 二进制一起发布：

确保版本匹配
用户不再需要单独安装 helm、kubectl、kustomize 和 kpt
helm 和 kustomize 作为 kpt 函数使用

迁移方案

Helm 部署器迁移

用户可以选择：

继续使用 helm 部署器（但不会获得新 kpt 功能支持）
迁移到新架构的 kpt 渲染和部署

Skaffold 提供 fix 命令帮助迁移，该命令会重新生成 skaffold.yaml。迁移后，如果用户在 skaffold.yaml 中更改 helm 配置，Skaffold 将自动重新创建相应的 kpt 资源。

总结

Skaffold v2 的渲染与部署架构通过明确分离配置水合和部署关注点，并统一基于 kpt 实现，解决了当前版本中的主要痛点。这一设计：

提供了更清晰的配置管理流程
消除了工具链版本冲突问题
增强了部署的可靠性和准确性
为未来功能扩展奠定了更好的基础

对于现有用户，Skaffold 提供了平滑的迁移路径；对于新用户，这一架构将提供更一致和可靠的开发体验。随着云原生技术的不断发展，这种基于标准化工具链的架构设计将更好地满足日益复杂的 Kubernetes 应用开发需求。

skaffold Easy and Repeatable Kubernetes Development 项目地址: https://gitcode.com/gh_mirrors/sk/skaffold

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考