Deployment Assets

Once a gateway is configured, the Deploy tab renders the assets needed to actually deploy it. This page covers the apply sequence itself, who does what, and in what order.

Danger

Generated YAML and Secret manifests contain real configuration for your clusters. Never paste example output from this guide into a real cluster, and never share a gateway’s generated Secrets outside your deployment pipeline.

1. Deploy the CFK operator.

   Install the Confluent for Kubernetes operator into the gateway’s namespace, then verify the operator pods are running. Your kubectl context must already point at the target cluster. For CFK and Gateway version compatibility, supported Kafka protocol versions, and licensing, see Confluent’s Gateway deployment documentation. This page covers the KMI side of the sequence, not the operator’s own requirements.

   By default, the generated CR’s application image is confluentinc/cpc-gateway:latest, which isn’t pinned to a specific version, so a redeploy can pick up a newer image without you choosing to. Set a specific tag in the builder’s state-level Image field if you need reproducible deployments.

2. Create the referenced Secrets.

   Apply the Secret manifests the gateway binds to. KMI never creates these for you. Each Secret is shown with the values you still need to fill in, and a kubectl apply command. Credential values are masked in the preview for safety; the copy button carries the real decrypted value. This isn’t limited to secret-store Secrets: a passthrough gateway with no secret store at all can still need a listener TLS certificate or a bootstrap trust store, and those get their own Secret here too (see Secret Store Contents below). There’s nothing to create at this step only if the gateway references no Secrets whatsoever.

3. Apply the Init Gateway CR yourself.

   Apply the Initial CR to stand the gateway up against the source cluster, then confirm the rollout completes.

4. Run the migration.

   From here on KMI is responsible: initialize and execute the gateway migration from the job’s X-Ray view, and KMI applies the Fenced and Switchover CRs for you as the migration progresses through those phases. Don’t apply either one manually. The Deploy tab’s own copy still names this automation kcp. That wording is stale and should be read as KMI: KMI applies these two CRs itself, with kubectl against the same namespace.

Caution

If a migration fails while the gateway is fenced, KMI normally rolls the fence back for you by re-applying the CR that was live before it, which is the Init CR from step 3. Four cases skip that rollback: the failure happened at or after topic promotion, where unfencing is deliberately not attempted to avoid split-brain; no rollback CR was supplied with the migration request; the rollback apply itself failed; or the service restarted mid-migration, where the normal failure path never runs at all. The first three set a warning on the migration status naming the case. A restart sets one only when the interrupted step was before promotion, so a restart during topic promotion leaves a fenced gateway carrying nothing but the generic restart error.

What to do next depends on where it failed, and the warning is not specific enough to tell you, because the first case above spans both sides of the cutover. Check the failed step before acting.

Before the switchover CR is applied, producers are genuinely still blocked, and re-applying the Init CR unfences them. Do not treat “complete the switchover” as an option here: the mirror topics were never promoted, so cutting clients over would point them at incomplete topics.

Once the switchover CR has been applied, the fence is already gone, and failures after that point (reconciliation timing out, or the check that confirms traffic actually moved to the destination reporting that routes still resolve to the source) leave producers unblocked but possibly still on the source. The warning still reads as though unfencing is the outstanding task. It isn’t. Re-applying the Init CR here is actively harmful, because the topics have already been promoted on the destination and you would be sending producers back to a source that is no longer the system of record. Finish the cutover instead, or roll the promotion back deliberately.

Responsibility Summary

CR / Asset	Who applies it
Secrets	You, before step 3
Init	You, manually
Fenced	KMI, automatically during migration
Switchover	KMI, automatically during migration

Secret Store Contents

What step 2 generates for a secret store depends on its provider:

• File: two Secrets: a credentials Secret (a flat map from source principal to destination credential) and a config Secret (the path where the gateway expects that map to be mounted).
• Vault: one config Secret with the gateway’s Vault connection settings (address, auth token, prefix path, separator). The credential mappings themselves live in Vault, not Kubernetes: you create them directly at the store’s prefix path.
• AWS Secrets Manager / Azure Key Vault: one config Secret with the provider’s connection settings. As with Vault, the credential mappings live in the external store, not Kubernetes.

Beyond the secret-store Secrets, step 2 also covers any JAAS, TLS certificate, or truststore Secrets referenced by the gateway’s auth or route blocks: each rendered with its own sample manifest and kubectl command alongside the secret-store ones.

Downloading State CRs

On the Deploy tab itself, each state’s CR (shown in the apply-sequence steps above) has a Copy button, not an individual download, the only download action here is Download all CRs, which gets all three states at once. To download a single state’s CR by itself, use the Overview tab’s Download YAML action instead (see Gateway Detail). Either way, every state, including one with no blocks configured, produces real YAML: an unconfigured state emits a default skeleton CR rather than being blocked or hidden. Downloads here are blocked by the same validation-error check as the builder’s Download button.