将应用程序部署到 Kubernetes 非常简单，只需要用 yaml 或 json 编写一些资源定义并将它们应用到 kubectl 中就可以了，但要实现配置自动化就相对复杂了。
在应用程序部署中，一个比较流行的做法是将持续部署和 GitOps 结合使用：每次对源代码进行更改后，资源都会自动部署。如果想要使用 GitOps 将应用程序部署到 Kubernetes，需要经历以下过程：
- 容器映像构建， 将源代码和本地依赖关系构建到容器映像中。
- 资源模板， 为环境定制部署资源的资源模板。
- 包管理， 将多个资源捆绑到版本发布中，并管理包依赖关系。
- 持续部署， 通常通过一系列操作和步骤，对环境进行更改。
- 命令式部署， 以编程方式管理复杂的服务生命周期，并减少手动或简单的脚本化步骤。
- 自动缩放， 根据资源使用情况和消耗情况，自动缩放来管理应用程序的响应和资源分配。
在本文中，我介绍了 Kubernetes 应用程序生命周期管理的各个阶段可能会使用的一些工具（主流非主流的都有）。由于很难客观地判断工具的流行性和成熟度， 因此我对这些工具进行了注释，说明了哪些大型公司对这些项目进行了投资，供你参考判断。不过请记住，大公司对一个项目通常可能会做多个竞争性投资，因此，仅仅因为项目拥有一位知名的投资者，并不能得出它可以长期生存和发展的结论。
希望此列表可以在你寻找应用程序部署问题解决方案时提供一些帮助。
1. 容器镜像构建
- Moby /buildkit (Docker) ——用于将源代码转换为构建工件的工具包。
- kaniko(Google)—— 在容器或 Kubernetes 集群中从 Dockerfile 构建容器映像的工具。
- img(Jess Frazelle) ——一个独立的，没有守护进程，非特权模式的 Dockerfile 和 OCI 兼容的容器映像构建器。
- buildah (IBM/Red Hat)——用于构建开放式容器计划 (OCI) 容器映像的工具。
- Source-To-Image(IBM/Red Hat)——用于从源构建工件并注入容器映像的工具。
- Tanzu Build Service/kpack /pack (VMware/Pivotal) ——使用 Cloud Native Buildpacks 构建应用程序的 CLI 和服务。
- Carvel /kbld (VMware/Pivotal)——用于构建映像并将其推入开发和部署工作流的服务。
- Google Cloud Buildpacks(Google)——为运行在谷歌云的容器平台而设计的构建器和构建包。
- Makisu (Uber) ——快速而灵活的 Docker 镜像构建工具，可以在 Mesos 和 Kubernetes 等非特权的容器环境中工作。
2. 资源模板
- Helm(Microsoft, Google) ——Kubernetes 包管理器。
- Kustomize(Google, Apple)——用于定制原始的、无模板的 YAML 文件的 CLI，使原始的 YAML 保持原样并保持可用。
- Carvel /ytt (VMware/Pivotal)——基于 YAML 结构的 YAML 模板工具。
- jsonnet/go-jsonnet(Google) ——JSON 模板语言。
- gomplate(Dave Henderson) ——用于 golang 模板渲染的 CLI，支持本地和远程数据源。
- Mustache (Github) ——与框架无关的 JSON 模板引擎。
3. 包管理
- Helm(Microsoft, Google) ——一个 Kubernetes 包管理器。
- Cloud Native Application Bundles (CNAB)/Porter/Duffle(Microsoft/Deis, Docker)——这是一个用于管理云无关的分布式应用程序的包格式规范、打包器和安装程序。
4. 持续部署
- Spinnaker(Netflix, Google) ——多云持续交付平台，用于快速高质量迭代发布软件变更。
- Terraform Kubernetes Provider (Hashicorp) ——一个 Terraform 插件，支持 Kubernetes 资源的完整生命周期管理。
- Concourse (VMware/Pivotal)——一个基于容器的连续事务处理程序，用 Go 和 Elm 编写。
- JenkinsX(CloudBees)—— 用于 Kubernetes 的自动化 CI / CD，提供使用 Tekton、Knative、Lighthouse、Skaffold 和 Helm 的 pull 请求预览环境
- Argo CD(Intuit)—— 用于 Kubernetes 的高效 GitOps 持续交付工具。
- Tekton/Tekton Pipelines(Google) ——一个 Kubernetes 控制器， 提供 CI / CD 样式的管道资源。
- Cloud Build(Google)——在谷歌云平台基础设施上执行构建的服务。
- Skaffold(Google)——促进 Kubernetes 应用程序持续开发的 CLI。
- Azure DevOps/Azure Pipelines(Microsoft) ——一种云服务，它可以自动构建和测试项目的代码，并将其提供给其他用户。
- Brigade(Microsoft) —— Kubernetes 的基于事件的脚本。
- Habitat/habitat-operator(Chef) ——Kubernetes 控制器，在 Kubernetes 上运行和管理 Habitat 服务。
- gitkube(Hasura) ——使用 git push 在 Kubernetes 上构建和部署 Docker 镜像的工具。
5. 命令式部署
- Kubebuilder(CNCF, Google, Apple, IBM/Red Hat) ——用于使用 CRD 构建 Kubernetes API(以及控制器和操作符) 的 SDK。
- Operator Framework/Operator SDK(IBM/Red Hat/CoreOS) ——用于构建 Kubernetes 应用程序操作符的 SDK。
- KUDO(D2IQ) ——使用声明式方法构建生产级 Kubernetes 操作符的框架。
- Pulumi(Pulumi)——可以作为代码 SDK 的基础设施，用于在各种云上创建和部署使用容器、无服务器功能、托管服务和基础架构的云软件。
- Carvel/kapp/kapp-controller(VMware/Pivotal)——CLI 和 Kubernetes 控制器，用于安装应用程序 CRD 所描述的配置 (helm 图表, ytt 模板，yaml 文件)。
- Isopod(Cruise)——在没有 YAML 的情况下，用于 Kubernetes 资源配置的表达性 DSL 和框架。
6. 自动缩放
- Horizontal Pod Autoscaler(built-in)—— Kubernetes 控制器，它根据配置的指标自动伸缩复制控制器、部署、复制集或有状态集中的 Pods 数量。
- Vertical Pod Autoscaler(Google)——一组 Kubernetes 组件，自动调整运行在 Kubernetes 集群中的 pods 请求的 CPU 和内存数量。
- Addon Resizer(Google) ——垂直 Pod 自动调用器的简化版本，它根据 Kubernetes 集群中的节点数量修改部署的资源请求。
- KEDA(Microsoft)——一个基于 kubernet 的事件驱动的自动缩放组件。
- Watermark Pod Autoscaler Controller(DataDog) ——扩展了 Horizontal Pod Autoscaler (HPA) 的自定义控制器。
- Pangolin(Damian Peckett)—— 针对 Kubernetes 的一个增强的 Horizontal Pod Autoscaler，它基于 Prometheus 指标来扩展部署，使用各种高度可配置的控制策略。
- Predictive Horizontal Pod Autoscaler(IBM) —— 自定义 Pod Autoscaler，类似于 Horizontal Pod Autoscaler，但是添加了预测元素。
- Horizontal Pod Autoscaler Operator(Banzai Cloud)——Kubernetes 控制器，它监视部署或状态集，并基于 autoscale 注释自动创建 Horizontal Pod Autoscaler 资源。
7. 写在最后
正如 DevOps 倡导者宣扬的那样：这与工具无关，而与观念有关。没有一个工具能给你带来让你兴奋的全生命周期端到端管理体验，因为每种工具都有他们自己的工具组合，通过与脚本和集成代码配合完成工作。
你可以找到能够很好地完成一件事情的工具，易于替换和扩展，也可以选择为你提供最大性价比的工具，让你更容易对项目进行管理，集成成本也更低，同时还拥有较好的端到端用户体验。以上的选择都没有什么错。
权衡这些因素后，你还需要看看这些项目背后的大佬，它是哪家公司投资的、项目的流行度如何？那些拥有大型公司或者有着多样化投资者的主流工具更具有持续成长性。不然，你选择后，项目不更新或者被抛弃了，那你只能花自己的时间和精力来维护这些工具了。
