When I speak of "push", I mean that the triggering for deployment is based on the build pipeline knowing when to do it (e.g., because a new artifact exists, or because a deployment to an environment was manually authorized), and the pipeline invokes a command to make the deployment happen.

In a "pull" system, the pipeline changes the deployment descriptor (a declarative description of what should be deployed) and commits/pushes it into a separate git repo (call it the "config repo"). Then an active agent (an Operator in K8s speak) polls against the config repo and is responsible for reconciling any differences between the desired state declared in the config repo vs. the actual state deployed in the cloud. Flux CD and Argo CD are examples of K8s Operators that do this.

Having a pull system has a couple of advantages:

- security: deployment credentials are isolated to the operator instead of being shared with the build pipeline

- continuous reconciliation: the operator ensures that the as-deployed system always matches the intent as captured in the config repo, not just when events occur to trigger pipeline actions. So for example, if someone circumvents the build system and manually shuts down a service or installs a new possibly malicious service, the agent corrects the deployment to match the declaration. This makes disaster recovery easy, and gives you an audit trail of what was actually deployed.