A production Kubernetes cluster accepts no inbound connections from outside its network. How does pull-based delivery work there, and what do you give up compared with a cluster your CI system can reach?

## The network property that decides the design Some clusters cannot accept inbound connections: an API server on a private endpoint, an air-gapped or regulated environment, an on-premises cluster behind a corporate firewall, a customer-hosted deployment you do not control. For these, the pull model is not merely preferable — it is often the only shape that does not require new network engineering. The reason is direction. A reconciling agent inside the cluster initiates every connection it needs: - outbound to the Git host (HTTPS 443 or SSH 22) or to a registry serving manifests as an OCI artifact - outbound to the image registry to pull application images - inbound to nothing The API server it writes to is reached over the cluster's own network, so it can remain entirely private. ## What push would require instead To push into the same cluster you must create a path in, and every option has a cost: - **A runner inside the network.** Now you operate self-hosted runners in a privileged network position, and they execute pipeline code. You have moved the untrusted-code problem inside the perimeter. - **VPN or private link from the CI provider.** Real work to build and maintain, and it makes a hosted CI system a trusted network peer. - **Exposing the API server** to an allowlist. The smallest amount of engineering and the largest amount of exposure; allowlists on hosted runners are also impractical because their egress addresses are broad and change. Each of these also still requires the cluster credential to live outside the cluster, so you pay the perimeter cost *and* the credential-concentration cost. ## What you give up ### Immediate triggering Many teams point a Git-host webhook at their agent so a merge syncs within seconds. A webhook is an inbound connection, so in an isolated cluster it cannot arrive. The agent falls back to polling on its configured interval, and worst-case deploy latency becomes that interval. That is usually acceptable, but say it out loud: you have traded seconds for a closed perimeter. If seconds matter, the usual answer is a relay the cluster polls or subscribes to outbound, not an inbound hole. ### Feedback and observability Nothing outside can query the agent's UI or API. Deploy status has to travel outward: notifications the agent sends to chat or an incident tool, metrics scraped by monitoring that lives inside and forwards aggregates out, or an outbound-only reporting component. Expect to spend real effort here, because the failure mode of an isolated cluster is a change that quietly never applies with nobody outside able to see it. ### Debugging and break-glass When the agent itself is broken, someone has to get in. A bastion, a jump host, an identity-aware proxy, or a session-recorded access path is still required, and it is worth designing deliberately rather than discovering during an incident. ### Egress is not free either The cluster must still be allowed out to the Git host and the registry, which in a locked-down network means proxy configuration, TLS interception handling, and allowlists. In a genuinely air-gapped environment you run an internal Git mirror and an internal registry, and the pull model works fine against those — the agent does not care whether the endpoint is public, only that it can reach it. ## The shape of a good answer Lead with the direction argument: pull needs egress only, so the perimeter stays closed and the credential stays inside. Then show you know the bill — no webhooks means polling latency, no inbound means status must be pushed outward, and humans still need a controlled way in. Interviewers in regulated or on-premises environments ask this specifically to see whether you have run delivery into a network you cannot reach.