mirror of
https://github.com/kubevela/kubevela.git
synced 2026-07-28 18:01:24 +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>
KubeVela Enhancement Proposals (KEPs)
This directory is a place to propose and discuss new ideas of KubeVela concepts, designs, architectures and techniques.
When do we need KEPs
When major changes are intended to be made to KubeVela project, we need KEPs. Major changes includes:
- New project-level features that add modules to the architecture, like new Controller or APIServer.
- Break changes to the core concepts of KubeVela, such as Application, Workflow, Component, etc.
- Techniques or domains that lots of related enhancements need to be added to KubeVela, like multi-cluster, observability, etc.
Changes to the internal mechanism of core KubeVela are recommended to add proposals as well, including:
- Application behaviours and related policies: State-keep, garbage-collect, resource dispatch, etc.
- API changes of auxiliary resources in KubeVela, such as ApplicationRevision, ResourceTracker.
- New concepts and layers in KubeVela APIServer on VelaUX, such as Project, Target, etc.
Minor changes and enhancements do not necessarily need to be included, but instead recommended to be tracked by issues, such as
- New addons.
- New Component/Trait/WorkflowStep definitions.
- New additional function APIs in APIServer.
- Bug detection and fixes.
- Auxiliary commands in CLI.
Areas
There are several directories contained. Each directory contains the KEPs in specific area.
- /vela-core: The proposals of features and changes to the core KubeVela, including Application APIs, internal mechanisms, auxiliary policies, etc.
- /vela-cli: The proposals of features to the KubeVela CLI, such as
vela top,vela def. - /api: The proposals of the interfaces KubeVela exposes to users, such as command line args for the core controller.
- /platform: The proposals of integrating features in various related areas outside KubeVela, such as edge computing, artificial intelligence.
- /resources: The related images embedded in the design documentations.
Writing a new Proposal
The aim of a proposal is to communicate designs with others and give KubeVela users some basic ideas of how features and evolved and developed.
To reach that, there are several things seed to be included in a proposal.
- The background of the feature or change, which explains why we need it.
- The goals and non-goals for the proposal.
- The potential technical solutions for the proposal and comparisons between various solutions. (Single solution is also acceptable.)
- How we should move on for the proposal. The estimated milestones or timelines for the feature development.
Submitting a new proposal
We recommend to use the template to start a new proposal. After finishing the proposal in the proper directory, raise a pull request to add the proposal to the main repo. If there are any issues related to the proposal, you can also add links to the issues in the pull request.