mirror of
https://github.com/kubevela/kubevela.git
synced 2026-07-29 02:11:44 +00:00
a1860544f0
* Docs(KEP): add KEP for Cluster Infrastructure Abstraction Introduce new CRDs for managing cluster infrastructure with OAM patterns: - Cluster: First-class cluster representation with inventory and health - ClusterPlane: Composable infrastructure layers with team ownership - ClusterBlueprint: Composition of planes into complete cluster specs - ClusterRollout: Emergency/manual rollout overrides - ClusterRolloutStrategy: Wave-based progressive rollout across fleet Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): Reduce duplication of concepts - Removed go code in lieu of explanations - Added command references Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): Add shared infrastructure plane semantics to ClusterPlane Introduces plane-level scope model for multi cluster shared infrastructure This enables cenarios where multiple clusters that share common infra without complex ownership semantics. Shared planes are created once on management cluster and their outputs are consumed by per-cluster planes via input bindings Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): Make cluster-gateway optional and isolate to backward compatibility appendix - Remove cluster-gateway from main architecture, connectivity options, and controller flow - Simplify Cluster CRD to 3 self-sufficient connectivity methods: inline, secretRef, cloudProvider - Move cluster-gateway backward compatibility to dedicated Appendix A - Fix internal contradictions and add GitOps integration section (Flux, ArgoCD) Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): add hub bootstrap prerequisites and fleet scaling guidance - Add Prerequisites section: hub cluster must be bootstrapped externally (Terraform/eksctl/cloud console) before KubeVela manages spoke clusters - Add hub-spoke architecture diagram and bootstrap sequence - Add Fleet Scale Controls: sharding, rate limiting for 50-1000+ clusters - Clarify KubeVela orchestrates composition/rollout, delegates provisioning to Crossplane/CAPI/tf-controller/KRO (user's choice) Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): Adds documentation for deletion and the order using garbage collection policy Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): Consolidate definition CRDs and fix lifecycle consistency Reuse existing KubeVela definition CRDs with scope annotation instead of introducing new PlaneComponentDefinition/PlaneTraitDefinition CRDs. Fix postCreate references to reflect validation/smoke-test purpose rather than cluster infrastructure. Remove stale mode:infrastructure references and resolve status phase inconsistencies across examples. Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): Fix broken TOC anchors and minor text fixes Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): recast core model to spoke-reconciled lifecycle Rework the Cluster Infrastructure KEP core model so the spoke is self-sufficient: - Introduce SpokeCluster as the hub-side fleet handle and blueprint dispatcher (kubectl get spokeclusters). - Recast Cluster as the spoke-side, self-reconciling object that vela-cluster-core builds from the dispatched ClusterBlueprint and keeps converged locally. - Replace status push-back with hub-initiated, on-demand reads, so hub downtime never stops spoke reconciliation. - Reframe the lifecycle phases to infraProvisioning (hub), planeProvisioning (spoke), and healthValidation (hub/both). - Update The Approach, CRDs Introduced, What Lives Where, the controller ownership/reconciliation/responsibilities sections, the migration path, and the table of contents. Downstream sections (the Cluster spec catalog, provision/adopt CLI, rollouts, health, and use cases) still describe the prior hub-centric flow and are flagged inline for a follow-up. Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): generalize SpokeCluster credential model and record connectivity decisions Make credential a discriminated union keyed by auth method: a directly supplied kubeconfig and cloud-native identity per provider (aws, azure, gcp), with provider-scoped auth modes so invalid combinations cannot be expressed. Record cluster-gateway as the connectivity substrate, with an agent-based alternative such as Open Cluster Management for fleets the hub cannot route to. Note per-provider workload identity for hub-to-spoke auth (AWS uses EKS Pod Identity, with IRSA as an alternative). Clarify mode as the seam between connect (attach to an existing cluster) and provision (create when absent). Note SpokeCluster as a hub-role object that a sub-hub also holds for its own children in a tree topology. Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): clarify spoke-local reconciliation in the Approach bullet Reword 'whether or not the hub is reachable' so it reads that reconciliation runs entirely on the spoke and never calls back to the hub, matching the no status push-back principle. Reword 'reconciles its blueprint into every cluster plane' to 'applies its blueprint by provisioning each ClusterPlane the blueprint declares.' Addresses review feedback on the Approach section. Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): unify vela-cluster-core placement in What Lives Where Replace the separate hub-controllers and spoke-engine rows with one vela-cluster-core row that runs on every cluster in the fleet. Hub-role and spoke-role controllers are activated by the CRs a cluster holds, so any cluster can act as hub, spoke, or both in the tree topology. Addresses review feedback on whether vela-cluster-core runs on the hub as well as the spokes. Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): rename design principles 1-3 per review Rename Principle 1 to Self-Sufficient, Principle 2 to Central Intent, Local Truth, and Principle 3 to One-Way Reconciliation Boundary, keeping each description. The earlier names for 2 and 3 read as descriptions rather than principle names. Addresses review feedback. Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): add spoke-reconciled clusterInit lifecycle phase Introduce clusterInit between infraProvisioning and planeProvisioning. It is spoke-reconciled: vela-cluster-core installs the foundational layer the planes depend on (Kubernetes controllers, operators, Helm charts, base CRDs) before planeProvisioning. infraProvisioning stays hub-side and ensures vela-cluster-core is running on the spoke first. Also drop the numbered phase labels in the lifecycle block so adding a phase no longer forces renumbering; phases are referenced by name. Updates the Approach bullet, TOC, heading, SpokeCluster example, and deletion order. Addresses review feedback on init/bootstrap blueprints and splitting infraProvisioning. Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): cover hub-reconciled infraProvisioning in the reconcile algorithm The hub SpokeClusterController algorithm now reconciles spec.infraProvisioning.blueprintRef on the hub against cloud APIs (consuming shared outputs when another SpokeCluster already reconciled it) before any dispatch, then dispatches the spoke-reconciled blueprints (clusterInit, then the main blueprint). Adds the matching responsibility to the controller matrix. Addresses review feedback on the reconcile algorithm. Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): carry infraProvisioning, patches, maintenance, pulled health on SpokeCluster The hub SpokeCluster example now shows infraProvisioning.blueprintRef (hub-reconciled cloud infra), patches and maintenance (homed on the hub object), and status.health pulled from the spoke on demand. First step of splitting hub-side concerns onto SpokeCluster and leaving the spoke Cluster as the self-representation. Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): make the spoke Cluster the self-representation Trim the Cluster spec to the spoke-reconciled phases (clusterInit, planeProvisioning, healthValidation) driven by the dispatched blueprint. Hub-facing fields (credential, desired blueprintRef, patches, rolloutStrategyRef, maintenance) now live on SpokeCluster; cluster-level policies fold into the blueprint. Drop hub-facing status from Cluster: connectionStatus, the maintenance window state, and the Connected condition. Rewrite the field note and Key Design Decisions to match. Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): align front-matter diagram, install steps, and What Lives Where with SpokeCluster Architecture diagram: ClusterController becomes SpokeClusterController; the hub CRD box notes Cluster is spoke-resident and lists SpokeCluster (one per spoke). Bootstrap step installs vela-cluster-core and its reconcilers and applies the SpokeCluster CRD. What Lives Where: provisioning controllers are needed for infraProvisioning. Provisioning Flexibility: the SpokeCluster's infraProvisioning delegates cluster creation. Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): migrate ClusterPlane section to the SpokeCluster model Hub fleet object becomes SpokeCluster; ClusterController becomes SpokeClusterController (hub) or vela-cluster-core (spoke reconciliation). preCreate -> infraProvisioning, postCreate -> healthValidation, and the deletion cascade becomes healthValidation, planeProvisioning, clusterInit, infraProvisioning. GitOps is reframed as hub-dispatches / spoke-reconciles. The nested shared-pattern, GitOps-flow, and deletion-cascade ASCII boxes are converted to clean text, and the shared-infra example is now a SpokeCluster using the discriminated credential union. Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): migrate Blueprint, Rollout, RolloutStrategy, Scale, Maintenance to SpokeCluster Fleet object becomes SpokeCluster (blueprint-reference, sharding, and maintenance examples). Rollout gating targets SpokeClusterController dispatch rather than a hub ClusterController; the applied blueprint status is reconciled by vela-cluster-core on the spoke. Fix push-vs-pull wording (spoke state is pulled by the hub, not written to it), move maintenance window state onto SpokeCluster.status, and convert the rollout relationship ASCII box to clean text. Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): fix execution model, broken anchor, and re-split the Lifecycle Phases example Rewrite the Component Execution Model to the four phases with the correct reconcile locations (only infraProvisioning on the hub; clusterInit/planeProvisioning/healthValidation reconciled by vela-cluster-core on the spoke) and fix the broken cross-link to the renamed Lifecycle Phases heading. Re-split the Lifecycle Phases YAML into a hub SpokeCluster (infraProvisioning + dispatched blueprintRef) and a spoke Cluster (clusterInit, planeProvisioning, healthValidation), and correct the phase text so healthValidation is spoke-run/hub-pulled and provisioning happens in infraProvisioning. Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): finish Lifecycle Management migration (modes, examples, provisioning, decommission) Convert the Cluster Modes diagram to clean text with the four-phase flow. Rename the mode 1/2/3 and decommission examples from kind: Cluster to kind: SpokeCluster (the hub fleet object). Fix ClusterController to SpokeClusterController in the adopt intro, the IAM comment, and the provisioning-integration steps (hub dispatches, spoke reconciles). Rename the remaining preCreate references in the decommission section to infraProvisioning. Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): state the pull boundary in Health and repoint Drift refs to SpokeCluster Make explicit that health is local truth on the spoke Cluster (aggregated by vela-cluster-core); the hub reads it on demand and mirrors a snapshot on SpokeCluster.status.health, never by push. Retitle the Health Status section as the spoke Cluster and note the pulled hub mirror, and clarify that rollout wave progression reads the pulled SpokeCluster.status.health. Point ClusterDriftException and ClusterDriftReport clusterRef at the hub SpokeCluster, derived from the spoke's local status.drift. Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): split API Reference into SpokeCluster + Cluster and migrate the Use Cases Split the API Reference Cluster field table into SpokeCluster (hub: mode, credential union, infraProvisioning, dispatched blueprintRef, rolloutStrategyRef, patches, maintenance; status connection/dispatchedRevision/clusterInfo/pulled health/provisioning/adoption/maintenance) and Cluster (spoke: clusterInit/planeProvisioning/healthValidation; status blueprint/planes/health/drift/conditions/resources/history). Migrate Use Case 2 and Use Case 5: kind: Cluster to SpokeCluster, preCreate to infraProvisioning, and reframe the onboarding comment as hub-dispatches, spoke-reconciles. Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): final consistency sweep (Appendix A, runtime-state comments, API consumers) Rename the backward-compatibility cluster-gateway example to kind: SpokeCluster; qualify the ClusterPlane/ClusterBlueprint runtime-state comments as the spoke Cluster's status.planes reconciled by vela-cluster-core; label ClusterPlane status.consumers entries as SpokeClusters. Doc-wide: no preCreate/postCreate/ClusterController remain, the only kind: Cluster left are the three spoke self-representation examples, code fences are balanced, and TOC anchors resolve. Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> --------- Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> Co-authored-by: Ayush Kumar <ayushshyamkumar888@gmail.com>
Make shipping applications more enjoyable.
Introduction
KubeVela is a modern application delivery platform that makes deploying and operating applications across today's hybrid, multi-cloud environments easier, faster and more reliable.
Highlights
KubeVela practices the "render, orchestrate, deploy" workflow with below highlighted values added to existing ecosystem:
Deployment as Code
Declare your deployment plan as workflow, run it automatically with any CI/CD or GitOps system, extend or re-program the workflow steps with CUE. No ad-hoc scripts, no dirty glue code, just deploy. The deployment workflow in KubeVela is powered by Open Application Model.
Built-in observability, multi-tenancy and security support
Choose from the wide range of LDAP integrations we provided out-of-box, enjoy enhanced multi-tenancy and multi-cluster authorization and authentication, pick and apply fine-grained RBAC modules and customize them as per your own supply chain requirements. All delivery process has fully automated observability dashboards.
Multi-cloud/hybrid-environments app delivery as first-class citizen
Natively supports multi-cluster/hybrid-cloud scenarios such as progressive rollout across test/staging/production environments, automatic canary, blue-green and continuous verification, rich placement strategy across clusters and clouds, along with automated cloud environments provision.
Lightweight but highly extensible architecture
Minimize your control plane deployment with only one pod and 0.5c1g resources to handle thousands of application delivery. Glue and orchestrate all your infrastructure capabilities as reusable modules with a highly extensible architecture and share the large growing community addons.
Getting Started
Get Your Own Demo with Alibaba Cloud
-
install KubeVela on a Serverless K8S cluster in 3 minutes, try:
Documentation
Full documentation is available on the KubeVela website.
Blog
Official blog is available on KubeVela blog.
Community
We want your contributions and suggestions! One of the easiest ways to contribute is to participate in discussions on the Github Issues/Discussion, chat on IM or the bi-weekly community calls. For more information on the community engagement, developer and contributing guidelines and more, head over to the KubeVela community repo.
Contact Us
Reach out with any questions you may have and we'll make sure to answer them as soon as possible!
-
Slack: CNCF Slack kubevela channel (English)
-
DingTalk Group:
23310022(Chinese) -
Wechat Group (Chinese): Broker wechat to add you into the user group.
Community Call
Every two weeks we host a community call to showcase new features, review upcoming milestones, and engage in a Q&A. All are welcome!
- Bi-weekly Community Call:
- Bi-weekly Chinese Community Call:
Talks and Conferences
Check out KubeVela videos for these talks and conferences.
Contributing
Check out CONTRIBUTING to see how to develop with KubeVela
Report Vulnerability
Security is a first priority thing for us at KubeVela. If you come across a related issue, please send email to security@mail.kubevela.io .
Code of Conduct
KubeVela adopts CNCF Code of Conduct.