转载

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

谷歌发布了 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的典型流程。

查找或配置Kubernetes集群。
- 集群初始化可以使用诸如 GKE 、 AKS 或者（未来的） AWS Fargate 这样的托管平台，也可以使用类似 kops 这样的本地工具。
构建每个服务的Docker镜像并上传到集群提供的注册中心。
- 这通常是通过 Docker社区版镜像构建工具（现在包含Edge版本Kubernetes的本地安装）完成的。
借助参考文档和示例，创建Kubernetes清单定义。
使用 kubectl CLI 或 Kubernetes Dashboard 部署应用程序定义。
重复步骤2-4，直到特性、Bug修复或变更集全部完成。
检入变更，通过CI过程运行，包括：
- 单元测试
- 集成测试
- 部署到测试或过渡环境
- 活性和可观测性检查

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

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

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

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

谷歌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上打开一个问题。

来自： http://www.infoq.com/cn/news/2018/03/skaffold-kubernetes