谷歌發布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執行狀態（圖片來自 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