谷歌发布 Skaffold，简化 Kubernetes 应用程序持续开发

看新闻很累？看技术新闻更累？试试下载 InfoQ 手机客户端，每天上下班路上听新闻，有趣还有料！

谷歌发布了 Skaffold ，一款旨在简化 Kubernetes 应用程序持续开发的开源命令行工具。Skaffold 进入了竞争日益激烈的 Kubernetes 开发自动化工具领域，其中有 Azure 的 Draft、Datawire 的 Forge 以及 Weavework 的 Flux。

Skaffold 将构建、推送及向 Kubernetes 集群部署应用程序的过程自动化。借助 Skaffold，开发人员可以在本地迭代应用程序代码，不断更新，准备好后再发布到本地或远程的 Kubernetes 集群进行验证或测试。在开发过程中，开发人员可以把 Skaffold 作为后台进程运行，也可以把它用于一次性或自动化的环境，如 CI/CD 管道。这让开发人员在从本地开发环境向生产环境部署应用程序时可以使用同样的工作流程。

谷歌云平台博客指出，Kubernetes 为操作人员 / 系统管理员提供的 API 和方法，增加了灵活性，方便他们可靠地部署软件应用程序。Kubernetes 采用定制的部署方法，并“提供了编程方法，实现至少是同样健壮的过程”。因此，操作人员可以专注于对组织而言至关重要的基础设施管理部分——保持（发布）速度和服务稳定性。

在某些情况下，开发人员可能是组织中最晚了解Kubernetes 的人。开发人员可能已经采取措施创建了可复制的应用程序部署工具，使用类似RPM 或DEB 这样的包管理技术或者是更新的类似 Docker 这样的 Linux 容器技术。Docker 让开发人员创造出可重复的运行环境，用一种简单、可重复的方式定义了依赖和应用程序配置。这使得团队里的开发人员可以保持开发环境的同步，不过，它并没有引入一种常用的部署验证方法。因此，开发人员通常希望使用 Kubernetes API 以及在生产环境中使用的方法，创建一个类似的本地集成 QA 环境。

下面是开发应用程序并部署到 Kubernetes 的典型流程。

1. 查找或配置 Kubernetes 集群。

• 集群初始化可以使用诸如 GKE 、 AKS 或者（未来的） AWS Fargate 这样的托管平台，也可以使用类似 kops 这样的本地工具。

2. 构建每个服务的 Docker 镜像并上传到集群提供的注册中心。

• 这通常是通过 Docker 社区版镜像构建工具（现在包含 Edge 版本 Kubernetes 的本地安装）完成的。

3. 借助参考文档和示例，创建 Kubernetes 清单定义。
4. 使用 kubectl CLI 或 Kubernetes Dashboard 部署应用程序定义。
5. 重复步骤 2-4，直到特性、Bug 修复或变更集全部完成。
6. 检入变更，通过 CI 过程运行，包括：

• 单元测试
• 集成测试
• 部署到测试或过渡环境
• 活性和可观测性检查

谷歌的博文指出，步骤 2-5 需要开发人员使用许多工具，通过多个界面更新他们的应用程序：

对于开发人员而言，这些步骤大部分都分不开，而且可以自动化，或者至少可以在一套定制工具的引导下获得良好的体验。

Skaffold 有两种运行模式“skaffold dev”和“skaffold run”。在“dev”模式下，Skaffold 执行以下操作：查看源代码以及 Docker 镜像依赖的变化，并在检测到变化时执行构建和部署；从部署好的容器获取日志流；运行持续构建 - 部署循环，只报告错误。在“run”模式下，Skaffold 运行一次管道，并在管道出现任何错误时退出。这对持续集成或持续部署管道以及“应用程序迭代后的完整性检查”很有用。

谷歌Skaffold 执行状态（图片来自 Skaffold GitHub ）

Skaffold 已经发布了“Alpha”版本，目前包括以下设计上的考虑和功能：

• 没有服务器端组件，意味着不会造成集群开销；
• 镜像标签管理；
• 支持多应用程序组件（只构建和部署应用程序栈中变化的部分）。

Skaffold 有一个可插拔的体系架构，让开发人员“可以使用最适合开发流程的工具”。

正如这个领域的思想领袖如 Gareth Rushgrove 和 Joe Beda 所指出的那样，目前，在 Kubernetes 开发工作流自动化领域出现了大量的工具——包括 Draft、Forge、Flux、Gitkube、Heighliner 和 ksync——它们的功能有着微妙的不同。

微软 Azure 团队发布了 Draft ，这个工具针对开发工作流的“内循环”：运行“draft create”基于 Draft pack 容器化应用程序；运行“draft up”把应用程序部署到 Kubernetes 开发沙箱；使用本地编辑器修改应用程序，变更会迅速部署到 Kubernetes。一旦开发人员对通过 Draft 做的变更满意，他们就提交并推送到版本控制系统，然后，持续集成（CI）系统就会接管。Draft 基于 Kubernetes Helm 和 Kubernetes Chart 格式构建，这使得为基于 Draft 的应用程序构造 CI 管道更容易。

Datawire 提供了 Forge ，这个工具是其开发自动化工作流工具的一部分，其中还包括远程调试工具 Telepresence 和 Ambassador API 网关（基于 Envoy Proxy 构建）。借助 Forge，开发人员可以定义每个服务如何使用Dockerfile 构建，定义每个服务如何通过Kubernetes 清单文件运行，使用一个“service.yaml”文件定义构成应用程序的服务和依赖。运行“ forge deploy ”可以自动执行所有面向 Kubernetes 的标准容器的构建和部署步骤，其中包括检测有变化的依赖和增量构建。Forge 还支持金丝雀发布（通过版本控制分支指定）和 CI/CD 集成。

Weavework 的 Flux 工具是该组织“ GitOps ”理念的实现，可以自动确保 Kubernetes 集群的状态与版本控制系统（单一版本真相）中指定的一致。Flux 的总体目标是自动化服务部署。一个典型的应用场景是：开发人员修改服务，创建一个GitHub 风格的pull request；一个正常运转的集群现在过期了，需要升级；Flux 检测到那些变化，并把它们部署到集群；Flux 维护着集群的当前状态（例如，万一出现故障）。Flux 还提供了一个CLI 和一个UI（在 Weave 云上），手动执行这些操作，并集成 CI/CD 工具。

Gitkube 是一个使用“git push”在 Kubernetes 上构建和部署 Docker 镜像的工具，和 Cloud Foundry 的“ cf push ”模型非常像。该项目的网站指出，Gitkube“非常适合于开发人员把一个 WIP 分支推送到集群进行测试”，该项目的目标是为编写基于 Git 的自动化工具提供一种参考实现。有个例子建议工程师生成 Gitkube 库的分支，创建一个 Kubernetes 自定义资源定义（CRD）、 Controller 和在 Kubernetes 集群上执行自动化操作的 git remote hook 。

Heighliner 为 Kubernetes 提供了 GitHub Flow ，每个新的 GitHub pull request 将自动部署到目标 Kubernetes 集群，“便于审核 [……] 真实世界的变更”。当开发人员创建一个新的 GitHub Release，Heighliner 就自动把变更分发到过渡环境或生产环境。 ksync 旨在加速 Kubernetes 开发，它可以从本地构建透明地更新运行在集群上的容器。它是通过同步本地文件系统目录和集群存储来实现的（其实现是通过在本地运行一个二进制文件，并在集群的每个节点上运行一个远程 DaemonSet ）。

GitHub 项目库提供了更多有关 Skaffold 的信息。上面提供了一份 GKE入门指南，同时还提供了一份本地安装指南（使用Minikube）并遵循 README 中的指令。如果希望讨论和反馈，则可以加入邮件列表或者在GitHub 上打开一个问题。

查看英文原文： Google Release “Skaffold”, a Tool that Facilitates Continuous Development with Kubernetes