github.com/wmuizelaar/kpt@v0.0.0-20221018115725-bd564717b2ed/site/book/06-deploying-packages/00.md (about) 1 In this chapter of this book, we are going to cover how you deploy a kpt 2 package to a Kubernetes cluster and how the cluster state is managed as the 3 package evolves over time. 4 5 We use `kpt live apply` instead `kubectl apply` since it provides some critical 6 functionality not provided by the latter: pruning and reconcile status. To 7 enable this functionality, we need a cluster-side mechanism for grouping and 8 tracking resources belonging to a package. This cluster-side grouping is 9 implemented using a custom resource of kind `ResourceGroup`. Otherwise, 10 `kpt live` and `kubectl` are complementary. For example, you can use 11 `kubectl get` as you normal would. 12 13 `kpt` packages can also be deployed with [GitOps](gitops/) tools. 14 15 ## Pruning 16 17 `live apply` will automatically delete cluster resources that are no longer 18 present in the local package. This clean-up functionality is called pruning. 19 20 For example, consider a package which has been applied with the following three 21 resources: 22 23 ``` 24 service-1 (Service) 25 deployment-1 (Deployment) 26 config-map-1 (ConfigMap) 27 ``` 28 29 Then imagine the package is updated to contain the following resources: 30 31 ``` 32 service-1 (Service) 33 deployment-1 (Deployment) 34 config-map-2 (ConfigMap) 35 ``` 36 37 When the updated package is applied, `config-map-1` is automatically deleted 38 from the cluster. 39 40 ## Reconcile Status 41 42 Kubernetes is based on an asynchronous reconciliation model. When you apply a 43 resource to a cluster, you actually care about two different things: 44 45 - Did the resource apply successfully (synchronous)? 46 - Did the resource reconcile successfully (asynchronous)? 47 48 This is referred to as _apply status_ and _reconcile status_ respectively: 49 50 ![img](/static/images/status.svg) 51 52 The `live apply` command computes the reconcile status. An example of this could 53 be applying a `Deployment`. Without computing reconcile status, the operation 54 would be reported as successful as soon as the resource has been created in the 55 API server. With reconcile status, `live apply` will wait until the desired 56 number of pods have been created and become available. 57 58 For core kubernetes types, reconcile status is computed using hardcoded rules. 59 For CRDs, the status computation is based on recommended [convention for status 60 fields] that needs to be followed by custom resource publishers. If CRDs follow 61 these conventions, `live apply` will be able to correctly compute status. `kpt` also 62 has special rules for computing status for [Config Connector resources]. 63 64 Usually multiple resources are being applied together, and we want to know 65 when all of those resources have been successfully reconciled. `live apply` computes 66 the aggregate status and will wait until either they are all reconciled, the timeout 67 expires, or all the remaining unreconciled resources have reached a state where they 68 are unlikely to successfully reconcile. An example of the latter for `Deployment` 69 resources is when the progress deadline is exceeded. 70 71 ## Dependency ordering 72 73 Sometimes resources must be applied in a specific order. For example, 74 an application might require that a database is available when it starts. 75 `kpt live` lets users express these constraints on resources, and use them 76 to make sure a resource has been successfully applied and reconciled before 77 any resources that depend on it are applied. 78 79 80 81 [convention for status fields]: /reference/schema/crd-status-convention/ 82 [Config Connector resources]: /reference/schema/config-connector-status-convention/