docs: add Kustomization v1 docs

Signed-off-by: Sanskar Jaiswal <[email protected]>

docs/spec/README.md

@@ -1,53 +1,7 @@
 # Kustomize Controller
 
-The kustomize-controller is a Kubernetes operator, specialized in running 
-continuous delivery pipelines for infrastructure and workloads
-defined with Kubernetes manifests and assembled with Kustomize.
+## API Specification
 
-## Motivation
-
-The main goal is to provide an automated operator that can
-bootstrap and continuously reconcile the cluster state
-from multiple sources (e.g. infrastructure and application repositories).
-
-When provisioning a new cluster, one may wish to install workloads in a specific order,
-for example a validation controller such as OPA Gatekeeper should be up and running before 
-applying other manifests on the cluster. Another example is a service mesh admission controller,
-the proxy injector must be functional before deploying applications into the mesh.
-
-When a cluster is shared with multiple teams, a cluster admin may wish to assign roles and service
-accounts to each team. The manifests owned by a team will be applied on the cluster using
-the team's account thus ensuring isolation between teams. For example, an admin can 
-restrict the operations performed on the cluster by a team to a single namespace.
-
-When dealing with an incident, one may wish to suspend the reconciliation of some workloads and
-pin the reconciliation of others to a specific Git revision, without having to stop the reconciler
-and affect the whole cluster.
-
-When operating a cluster, different teams may wish to receive notification about the status
-of their CD pipelines. For example, the on-call team would receive alerts about all
-failures in the prod namespace, while the frontend team may wish to be alerted when a new version 
-of the frontend app was deployed and if the deployment is healthy, no matter the namespace.
-
-## Design
-
-The reconciliation process can be defined with a Kubernetes custom resource
-that describes a pipeline such as:
-- **check** if depends-on conditions are meet 
-- **fetch** manifests from source-controller
-- **generate** `kustomization.yaml` if needed
-- **build** the manifests using the Kustomize SDK
-- **decrypt** Kubernetes secrets using Mozilla SOPS SDK
-- **impersonate** the tenant's Kubernetes account
-- **validate** the resulting objects using server-side apply dry-run
-- **detect drift** between the desired and state and cluster state
-- **correct drift** by applying the objects using server-side apply
-- **prune** the objects removed from source
-- **wait** for the applied changes to rollout using Kubernetes kstatus library
-- **report** the reconciliation result in the `status` sub-resource
-- **alert** if something went wrong by sending events to Kubernetes API and notification-controller
-- **notify** if the cluster state changed by sending events to Kubernetes API and notification-controller
-
-## Specifications
-
-The latest API specifications can be found [here](v1beta2/README.md).
+[v1beta1](v1beta2/README.md).
+[v1beta2](v1beta2/README.md).
+[v1](v1/README.md).

docs/spec/v1/README.md

@@ -0,0 +1,17 @@
+# kustomize.toolkit.fluxcd.io/v1
+
+This is the v1 API specification for defining continuous delivery pipelines
+of Kubernetes objects generated with Kustomize.
+
+## Specification
+
+- [Kustomization CRD](kustomization.md)
+ + [Example](kustomization.md#example)
+ + [Writing a Kustomization spec](kustomization.md#writing-a-kustomization-spec)
+ + [Recommended settings](kustomization.md#recommended-settings)
+ + [Working with Kustomizations](kustomization.md#working-with-kustomizations)
+ + [Kustomization Status](kustomization.md#kustomization-status)
+
+## Implementation
+
+* [kustomize-controller](https:/fluxcd/kustomize-controller/)