Kubernetes Operators Deployment Strategy¶

The Kubernetes Operators strategy lets you keep an operator as the application lifecycle layer while Omnistrate supplies the control plane around it. The operator reconciles custom resources; Omnistrate manages the product, tenant, infrastructure, and operational surfaces needed to deliver that application as a service.

When to Use Kubernetes Operators¶

The Operator strategy is a good fit when:

• Your product lifecycle is already modeled by Kubernetes CRDs and an operator.
• The application needs domain-specific reconciliation, upgrades, backup and restore, failover, or status handling.
• You want customer-facing APIs and portals without replacing the operator’s application logic.
• You need to expose standard lifecycle operations together with provider-defined operations.

Responsibility Boundary¶

The operator owns application-specific state: CRDs, reconciliation, workload topology, application health, and domain-specific recovery or upgrade behavior. Omnistrate owns the surrounding service lifecycle: tenants, subscriptions, APIs, infrastructure, deployment orchestration, versioned releases, observability, metering, billing, and multi-cloud or BYOC delivery.

This separation keeps the operator focused on running the application while the control plane provides a consistent experience across customers and deployment environments.

Strategy Guide¶

• Start with Build from Kubernetes Operators for the short onboarding path.
• Use Build with Kubernetes Operators for service-plan modeling, system workflows, custom workflows, and backup/restore behavior.
• See Operator Troubleshooting when an operator-backed deployment or workflow fails.
• Review the generic troubleshooting workflow for shared debugging tools and instance-debug behavior.

For the enterprise control-plane perspective, see Beyond the Operator: The Enterprise Control Plane Layer.