If you’ve worked with Kubernetes for any length of time, you are probably intimately familiar with deployment manifests. If this concept is new to you, deployment manifests are used to add resources to a cluster in a declarative manor. Some of the larger projects (cert-manager, Istio, CNI plug-ins, etc.) in the Kubernetes ecosystem provide manifests to deploy the resources that make their application work. These can often be 1000s of lines, and if you are security conscious you don’t want to deploy anything to a cluster without validating what it is.
The K14S project took this issue to heart when they released the kapp utility. This super useful utility can help you see the changes that would take place to a cluster, but without actually making any changes. To show how useful this is, lets say you wanted to see which resource Istio would deploy. You can see this with kapp deploy:
kapp deploy -a istio -f <(kustomize build)
Target cluster 'https://127.0.0.1:33783' (nodes: test-control-plane, 3+) Changes Namespace Name Kind Conds. Age Op Op st. Wait to Rs Ri (cluster) istio-operator ClusterRole - - create - reconcile - - ^ istio-operator ClusterRoleBinding - - create - reconcile - - ^ istio-operator Namespace - - create - reconcile - - ^ istio-system Namespace - - create - reconcile - - ^ istiooperators.install.istio.io CustomResourceDefinition - - create - reconcile - - istio-operator istio-operator Deployment - - create - reconcile - - ^ istio-operator ServiceAccount - - create - reconcile - - ^ istio-operator-metrics Service - - create - reconcile - - Op: 8 create, 0 delete, 0 update, 0 noop Wait to: 8 reconcile, 0 delete, 0 noop Continue? [yN]: N
The output contains the resource type and the operation that will take place. In the example above we are going to create 8 resources, and assign the application name “istio” (a label) to each resource. Kapp deploy can also be fed the “–diff-changes” option to display a diff between the manifests and the current cluster state, “–allow-ns” to specify the namespaces that the app has to go into, and the “–into-ns” to map the namespaces in the manifests to one of your choosing. Kapp will assign a label to the resources it deploys, which is used by “list” to show resources that are managed by kapp:
Target cluster 'https://127.0.0.1:33783' (nodes: test-control-plane, 3+) Apps in namespace 'default' Name Namespaces Lcs Lca istio (cluster),istio-operator true 4d nginx - - - Lcs: Last Change Successful Lca: Last Change Age 2 apps Succeeded
Another super useful feature of kapp is its ability to inspect an application that was previously deployed:
kapp inspect -a istio --tree
Target cluster 'https://127.0.0.1:33783' (nodes: test-control-plane, 3+) Resources in app 'istio' Namespace Name Kind Owner Conds. Rs Ri Age (cluster) istio-operator ClusterRole kapp - ok - 4d istio-operator istio-operator ServiceAccount kapp - ok - 4d (cluster) istiooperators.install.istio.io CustomResourceDefinition kapp 2/2 t ok - 4d istio-operator istio-operator-metrics Service kapp - ok - 4d istio-operator L istio-operator-metrics Endpoints cluster - ok - 4d (cluster) istio-operator ClusterRoleBinding kapp - ok - 4d (cluster) istio-system Namespace kapp - ok - 4d (cluster) istio-operator Namespace kapp - ok - 4d istio-operator istio-operator Deployment kapp 2/2 t ok - 4d istio-operator L istio-operator-77d57c5c57 ReplicaSet cluster - ok - 4d istio-operator L.. istio-operator-77d57c5c57-dkl8b Pod cluster 4/4 t ok - 4d Rs: Reconcile state Ri: Reconcile information 11 resources Succeeded
In the output above you can see the resource relationships in tree form, the object type, the owner, and the state of the resource. This is a crazy useful utility, and one I’ve started to use almost daily. It’s super useful for observing the state of a cluster, and for debugging problems. Thanks K14S for this amazing piece of software!