谷歌发布了促进Kubernetes可持续发展的工具Skaffold

司空胜博
导读找出DevOps中你今年应该注意的技术。成为团队中的创新者,对Kubernetes、服务网格和混沌工程有深刻的理解。阅读这份报告。谷歌发布了Skaffo...

找出DevOps中你今年应该注意的技术。成为团队中的创新者,对Kubernetes、服务网格和混沌工程有深刻的理解。阅读这份报告。

谷歌发布了Skaffold,这是一个开源命令行工具,可以促进Kubernetes应用程序的持续开发。Skaffold正在进入一个日益拥挤的Kubernetes开发自动化工具领域,包括Azure的Draft、Datawire的Forge和Weavework的Flux。

Skaffold自动化了将应用程序构建、升级和部署到Kubernetes集群的工作流程。使用Skaffold,开发人员可以在本地迭代和更新应用程序源代码,并在本地或远程Kubernetes集群中验证或测试它。开发人员可以在开发代码时将Skaffold作为后台进程运行,或者在一次性或自动化的上下文中使用它,例如CI/CD管道。这允许开发人员在将应用程序从本地开发环境迁移到生产环境时使用相同的工作流和工具。

谷歌云平台博客指出,Kubernetes为运营商/系统管理员提供了API和方法,以提高他们的敏捷性,促进软件应用的可靠部署。Kubernetes采用定制的部署方法,并“提供编程方法来实现类似的(如果不是更健壮的话)过程”。因此,运营商可以专注于对其组织最重要的基础设施管理部分——,以保持(发布)速度和服务稳定性。

在某些情况下,开发人员可能是组织中最后一个被介绍给Kubernetes的人。开发人员可能已经采取措施,使用包管理技术(如rpm或deb)或最近的Linux容器(如Docker)为他们的应用程序创建可复制的部署工件。Docker允许开发人员生成一个可重复的运行时环境,在这个环境中,他们可以以简单且可重复的方式定义应用程序依赖关系和配置。这可以使开发人员与整个团队的开发运行时保持同步,但它没有引入常见的部署和验证方法。因此,开发人员经常希望使用生产环境中使用的Kubernetes api和方法来创建类似的本地、集成和QA环境。

要部署到Kubernetes的应用程序的典型开发过程如下:

谷歌博客认为,步骤2至5要求开发人员使用许多工具,通过多个界面更新他们的应用程序:

对于开发人员来说,这些步骤大部分是无法区分的,并且可以自动执行,或者至少由一组根据开发人员的经验定制的工具来指导。

Skafold可以以两种模式运行,“Skaffold dev”或“Skaffold run”。在“开发”模式下,Skaffold执行以下操作:监控源代码和Docker映像之间的依赖关系,并在检测到更改时运行构建和部署;从部署的容器传输日志;并且以连续的构建-部署周期运行,只警告错误。在“运行”模式下,Skaffold运行管道一次,当管道出现任何错误时退出。这对于管道的持续集成或部署以及“应用程序迭代后的完整性检查”非常有用。

Skaffold已在《alpha》上发表,目前包括以下设计考虑和功能:

Skaffold有一个可插拔的架构,允许开发人员“在开发人员工作流程中选择最适合您的工具”。

正如思想领袖Gareth Rushgrove和Joe Beda最近指出的,在Kubernetes开发的工作流自动化领域,有很多工具3354,包括Draft、Forge、Flux、Gitkube、liner和ksync——,每一个工具都提供了微妙但不同的功能。

微软Azure团队已经发布了草稿,针对开发人员工作流程的“内环”:运行“草稿创建”以包含基于草稿包的应用程序;运行Draft将应用程序部署到Kubernetes开发沙箱中;使用本地编辑器修改应用程序,并将更改快速部署到Kubernetes。一旦开发人员对通过草案所做的更改感到满意,他们将提交并促进版本控制,这将由持续集成(CI)系统接管。Draft是基于Kubernetes Helm和Kubernetes图表格式构建的,这使得从支持Draft的应用程序构建CI管道变得很容易。

Wire提供Forge作为其开发人员自动化工作流工具的一部分,包括远程呈现远程调试工具和大使级API网关(基于特使代理构建)。使用Forge,开发人员可以定义如何使用Dockerfile构建每个服务,如何通过Kubernetes清单运行每个服务,以及定义组成应用程序的服务和依赖关系。Yaml文件。运行“forge deploy”可以自动化Kubernetes的所有标准容器构建和部署步骤,包括检测变更的依赖性和允许增量构建。Forge还支持canary发布(由版本控制分支指定)和CI/C。

d .一体化。

Weavework的Flux工具实现了组织的“GitOps”理念,并自动确保Kubernetes集群的状态与版本控制中指定的状态相匹配(“单一真实源”)。Flux的总体目标是自动化服务的部署。

一个典型的用例是:开发人员更改服务并创建一个github风格的拉请求;一个操作集群现在已经过时,需要更新;Flux观察这些变化并将它们部署到集群中;Flux维护集群的当前状态(例如,在发生故障时)。Flux还提供了一个CLI和一个UI(在Weave Cloud中)来手动执行这些操作,并与CI/CD工具集成。

Gitkube是一个使用“git push”在Kubernetes上构建和部署Docker镜像的工具,很像Cloud Foundry的“cf push”模型。该项目web声明Gitkube是“开发人员可以将WIP分支推到集群中进行测试的理想开发环境”,该项目旨在成为编写基于Gitkube的自动化的参考实现。一个例子表明,工程师派生Gitkube存储库,创建Kubernetes自定义资源定义(CRD)、控制器和git远程钩子,在Kubernetes集群上执行自动化操作。

liner为Kubernetes提供了GitHub流,每一个新的GitHub pull request都会自动部署到目标Kubernetes集群中,“这使得审查变得很容易……现实世界的变化”。当开发人员创建一个新的GitHub版本时,liner会自动将更改分发到临时环境或生产环境。ksync的目标是通过透明地更新本地构建中运行在集群上的容器来加速Kubernetes的开发。它通过将本地文件系统目录与集群中的存储进行同步(通过在集群中的每个节点上运行本地运行的二进制文件和远程守护进程来实现)。

有关Skaffold的更多信息可以在项目的GitHub存储库中找到。GKE入门指南和本地安装指南(使用Minikube)都可以在README中找到。为了讨论和反馈,请加入邮件列表或在GitHub上打开一个问题。

标签:

免责声明:本文由用户自主上传,版权归原作者所有,若有来源标注错误或侵犯了您的合法权益,请与本网联系,我们将及时更正、删除,谢谢您的支持与理解。