Which Kubernetes Deployment Strategy Fits Your Business? The Three Key Approaches Explained

Overview

Kubernetes is the de‑facto standard for container orchestration. Organizations adopt it in three typical ways that differ in the degree of integration with existing infrastructure.

1. Above Kubernetes (vanilla)

Deploy a standard, upstream Kubernetes distribution without any modifications. Use a managed cloud service (EKS, GKE, AKS) or an on‑premise cluster, and operate applications solely through the native Kubernetes API (Deployments, Services, Ingress, etc.). This approach requires minimal operational overhead and stays fully compatible with upstream upgrades.

2. On Kubernetes (extended)

Retain legacy service‑mesh, monitoring, networking, or other platform components and augment the cluster with custom controllers, sidecar containers, or patched components. Typical industry examples include:

Alibaba Sigma

Meituan‑Dianping HULK 2.0

JD JDOS 2.0

These solutions keep the original Kubernetes API but add a compatibility layer that maps existing tooling onto Kubernetes resources. The trade‑off is additional maintenance effort and the need to re‑apply patches on each Kubernetes version upgrade.

3. In Kubernetes (deep integration)

Treat Kubernetes as a programmable platform and embed custom workload semantics directly into the control plane. This is achieved with Custom Resource Definitions (CRDs) and Operators. A concrete open‑source example is OpenKruise ( https://github.com/openkruise/kruise) which provides:

Advanced StatefulSet – adds in‑place update, pause, and MaxUnavailable support.

BroadcastJob – runs a Pod on every node in the cluster.

SidecarSet – injects and upgrades sidecar containers based on label selectors.

By defining CRDs such as AdvancedStatefulSet, BroadcastJob, or SidecarSet, teams can model domain‑specific workloads while remaining API‑compatible with upstream Kubernetes. Operators built on these CRDs can automate lifecycle tasks (e.g., MySQL cluster management) and are discoverable via OperatorHub.

Choosing the right pattern

Consider the following factors:

Team size & expertise – Startups with limited ops staff typically choose the “Above” model.

Existing technical debt – Mid‑to‑large enterprises with entrenched service‑mesh, monitoring, or networking stacks often adopt the “On” model to preserve investments.

Strategic cloud‑native ambition – Organizations willing to redesign their stack and contribute back to the ecosystem favor the “In” model.

All three patterns remain compatible with the Kubernetes API, ensuring that future version upgrades and ecosystem integrations are possible.

Reference

OpenKruise project:

https://github.com/openkruise/kruise