Helm (特别是 Helm3)是 kapp 工具的替代品。就像 Helm 一样，kapp 可以执行应用程序的有状态升级。但是，Kapp 没有 Helm 这样的模板功能，Carvel 工具包中的 YTT 工具实现了这种功能。通过将 kapp 与 kapp 控制器相结合，您可以构建整洁的 GitOps 工作流，这将使其远远超出 Helm 的能力。
为了更好地理解 kapp，让我们使用以下命令在系统上安装它:
Shell 壳牌
wget -O- https://carvel.dev/install.sh > install.shbrsudo bash install.sh
前面的命令将在您的系统上安装 Carvel 工具包的所有工具，如 YTTl、 imgpkg 等。请自己探索这些工具的使用方法。Carvel 工具包中的每个工具都是独立的，在系统上占用的空间很小。
我写了一个简单的。NET 应用程序，包括一个前端和 Redis 数据库，我们将用于测试 kapp。请随意使用您的演示或学习目的的应用程序。你可以使用多功能一体机。Yaml 清单将应用程序的所有组件安装到您的集群。现在让我们使用 kapp 以名为 az-Vote 的应用程序的形式安装组件。
kapp deploy --app=az-vote -f https://raw.githubusercontent.com/rahulrai-in/azure-voting-app-dotnet/main/kubernetes-manifests/all-in-one.yaml
在执行该命令时，您将看到 kapp 将创建的组件列表如下:
如果您键入“ y”，kapp 将注释您的资源，以将它们链接到应用程序，然后对它们进行管理。基于实际状态和期望状态之间的差异，它将升级或删除资源，并提供您的应用程序的整体状态。下面的屏幕截图显示了 kapp 添加到应用程序的 pods 中的注释:
您可以使用 kapp list 命令查看集群中的应用程序，如下所示:
要查看组成应用程序的资源列表，可以按照以下方式使用 kapp check 命令:
检查应用程序
您将注意到，当您定义一个 Service 时，Kubernetes 在引擎罩下创建的一些对象(如 Endpoints 和 EndpointSlices)包含在命令输出中。输出格式使得读取所有应用程序资源的成功和失败状态变得容易。
现在我们将引入 kapp-controller 来自动部署应用程序。但是，在这样做之前，通过运行以下命令删除应用程序:
kapp delete --app=az-voteKapp 控制器
当您将应用程序捆绑为一组具有良好定义的名称(例如 Azure Vote 应用程序的组件)的原子管理资源时，您多少构建了一个 CustomResourceDefinition (CRD)。CRD 经常被 Kubernetes 运营商使用，这使得 Kubernetes 能够在资源被创建、销毁或更新时以“正确”的方式行事。实际上，您已经可以找到安装在 Kubernetes 集群上的几个 CRD，可以使用 kubectl get crd 命令列出它们。
Kapp-controller 工具接受一个 kapp 应用程序，并使用自动化功能(如 GitOps)对其进行增强。该工具允许您构建一个完全自动化的应用程序平台，该平台可以自动部署和管理100个应用程序，而不需要任何手动或自动输入。Helm 和 kapp-controller 等工具消除了构建操作符来管理大多数不需要与 Kubernetes API 交互的业务应用程序的生命周期的需要。
让我们通过使用 kapp 本身在集群中安装 kapp-controller，如下所示:
kapp deploy -a kc -f https://github.com/vmware-tanzu/carvel-kapp-controller/releases/latest/download/release.ymlbrkapp deploy -a default-ns-rbac -f https://raw.githubusercontent.com/vmware-tanzu/carvel-kapp-controller/develop/examples/rbac/default-ns.yml
第一个命令将 kapp-controller 作为应用程序安装在集群上。第二个命令创建一个 RBAC 规则，将默认名称空间的完全控制权交给 kapp-controller。这些权限使 kapp-controller 能够在命名空间中创建、更新和删除 Kubernetes 资源。
既然 kapp 控制器已经在集群中运行，我们就可以使用它从 Git 存储库中提供的 spec 中自动部署应用程序。为此，我们将创建一个 kapp CR 来定义我们的应用程序。Kapp CR 被 kapp 控制器很好地理解。Kapp 应用程序的规范格式可以在 Carvel 文档网站上找到。
为 Azure Vote App 创建一个应用程序规范，它将作为一个完全 kapp 控制的应用程序运行，如下所示:
apiVersion: kappctrl.k14s.io/v1alpha1brkind: Appbrmetadata:br name: azure-vote-appbr namespace: defaultbrspec:br serviceAccountName: default-ns-sabr fetch:br - git:br url: https://github.com/rahulrai-in/azure-voting-app-dotnetbr ref: origin/mainbr subPath: kubernetes-manifests/br template:br - ytt: {}br deploy:br - kapp: {}
从 Git 获取应用程序规范是创建应用程序的受支持方法之一。您还可以指示 kapp-controller 从 HTTP 位置、 Helm 图表、容器注册表等获取应用程序规范。默认情况下，kapp-controller 每分钟都会检查应用程序的源代码(HTTP 位置、 Helm 图表等) ，并尝试将集群中应用程序的状态与源代码中指定的状态进行协调。
通过运行命令 kubectl application-f < app-spec-file > 将应用程序部署到集群。然后，运行 kapp list 命令来列出集群中的应用程序，如下所示:
让我们查看申请的资源如下:
我们现在已经将我们的应用程序集成到一个 CI/CD 系统中，该系统可以完全在 Kubernetes 内部管理。我们现在可以将提交和维护应用程序的 CRD 的责任分配给开发人员，并让 kapp 控制器操作符在默认名称空间中部署和管理应用程序。
Kapp-controller 为我们在集群中为 kapp 应用程序安装了 CRD，现在我们可以使用 kubectl 命令来操作应用程序，就像其他本地 Kubernetes 对象一样，如下所示:
结论
我们使用 Carvel 工具包中最流行的两个工具: kapp 和 kapp-controller，它们帮助我们处理应用程序，而不是它们各自的组件。另外，我们注意到 kapp-controller 可以帮助我们以有状态的方式打包应用程序，而不需要我们编写任何自定义操作符。最后，我们使用 kapp 工具实现了 Azure Vote 应用程序的一个类操作员的部署模型，并意识到 kapp 控制器可以在实现操作员所需时间的一小部分内提供操作员的大部分好处。
