This documentation is for not yet released version of kapp. For the documentation of the latest release version, see the latest version.
kapp includes builtin rules on how to wait for the following resource types:
- any resource with
metadata.deletionTimestamp: wait for resource to be fully removed
- any resource matching Config’s waitRules: see “Custom waiting behaviour” below
apiextensions.k8s.io/<any>/CustomResourceDefinition: wait for Established and NamesAccepted conditions to be
True(note that this is wait rule for CustomResourceDefinition resource itself, not CRs)
apps/v1/DaemonSet: wait for
status.numberUnavailableto be 0
apps/v1/Deployment: see “apps/v1/Deployment resource” below
apps/v1/ReplicaSet: wait for
status.replicas == status.availableReplicas
batch/v1/Job: wait for
Failedconditions to appear
batch/<any>/CronJob: immediately considered done
/v1/Pod: looks at
/v1/Service: wait for
status.loadBalancer.ingressto become set
apps/v1/StatefulSet: see “apps/v1/StatefulSet resource” below
If resource is not affected by the above rules, its waiting behaviour depends on aggregate of waiting states of its associated resources (associated resources are resources that share same
kapp.k14s.io/association label value).
Controlling waiting via resource annotations ¶
kapp.k14s.io/disable-waitannotation controls whether waiting will happen at all. Possible values: “”.
kapp.k14s.io/disable-associated-resources-waitannotation controls whether associated resources impact resource’s waiting state. Possible values: “”.
apps/v1/Deployment resource ¶
kapp by default waits for
apps/v1/Deployment resource to have
status.unavailableReplicas equal to zero. Additionally waiting behaviour can be controlled via following annotations:
kapp.k14s.io/apps-v1-deployment-wait-minimum-replicas-availableannotation controls how many new available replicas are enough to consider waiting successful. Example values:
apps/v1/StatefulSet resource ¶
Available in v0.32.0+.
kapp will wait for any pods created from the updated template to be ready based on StatefulSet’s status. This behaviour depends on the update strategy used.
Note: kapp does not do anything special when
OnDelete strategy is used. It will wait for StatefulSet to report it’s reconciled (expecting some actor in the system to delete Pods per
Custom waiting behaviour ¶
Available in v0.29.0+.
kapp can be extended with custom waiting behaviour by specifying wait rules as additional config. (If this functionality is not enough to wait for resources in your use case, please reach out on Slack to discuss further.)
(Help improve our docs: edit this page on GitHub)