Fix API links

Signed-off-by: Stefan Prodan <stefan.prodan@gmail.com>

content/en/flux/components/_index.md

@@ -32,13 +32,13 @@ A reference for each component and API type is linked below.
     - [HelmChart CRD](source/helmcharts.md)
     - [Bucket CRD](source/buckets.md)
 - [Kustomize Controller](kustomize/_index.md)
-    - [Kustomization CRD](kustomize/kustomization.md)
+    - [Kustomization CRD](kustomize/kustomizations.md)
 - [Helm Controller](helm/_index.md)
     - [HelmRelease CRD](helm/helmreleases.md)
 - [Notification Controller](notification/_index.md)
-    - [Provider CRD](notification/provider.md)
-    - [Alert CRD](notification/alert.md)
-    - [Receiver CRD](notification/receiver.md)
+    - [Provider CRD](notification/providers.md)
+    - [Alert CRD](notification/alerts.md)
+    - [Receiver CRD](notification/receivers.md)
 - [Image automation controllers](image/_index.md)
     - [ImageRepository CRD](image/imagerepositories.md)
     - [ImagePolicy CRD](image/imagepolicies.md)

content/en/flux/concepts.md

@@ -59,7 +59,7 @@ If you make any changes to the cluster using `kubectl edit/patch/delete`,
 they will be promptly reverted. You either suspend the reconciliation or push your changes to a Git repository.
 
 For more information, take a look at the [Kustomize FAQ](faq.md#kustomize-questions)
-and the [Kustomization CRD](components/kustomize/kustomization.md).
+and the [Kustomization CRD](/flux/components/kustomize/kustomizations/).
 
 ## Bootstrap
 

content/en/flux/gitops-toolkit/packages.md

@@ -66,9 +66,9 @@ import kustomizev1 "github.com/fluxcd/kustomize-controller/api/v1"
 
 API Types
 
-| Name                                                      | Version |
-|-----------------------------------------------------------|---------|
-| [Kustomization](../components/kustomize/kustomization.md) | v1      |
+| Name                                                       | Version |
+|------------------------------------------------------------|---------|
+| [Kustomization](../components/kustomize/kustomizations.md) | v1      |
 
 ### helm.toolkit.fluxcd.io
 

content/en/flux/migration/faq-migration.md

@@ -87,7 +87,7 @@ Custom Prometheus metrics | Generic / common `controller-runtime` Prometheus met
 
 ### Are there any breaking changes?
 
-- In Flux v1 Kustomize support was implemented through `.flux.yaml` files in the Git repository. As indicated in the comparison table above, while this approach worked, we found it to be error-prone and hard to debug. The new [Kustomization CR](https://github.com/fluxcd/kustomize-controller/blob/main/docs/spec/v1/kustomization.md) should make troubleshooting much easier. Unfortunately we needed to drop the support for custom commands as running arbitrary shell scripts in-cluster poses serious security concerns.
+- In Flux v1 Kustomize support was implemented through `.flux.yaml` files in the Git repository. As indicated in the comparison table above, while this approach worked, we found it to be error-prone and hard to debug. The new [Kustomization CR](https://github.com/fluxcd/kustomize-controller/blob/main/docs/spec/v1/kustomizations.md) should make troubleshooting much easier. Unfortunately we needed to drop the support for custom commands as running arbitrary shell scripts in-cluster poses serious security concerns.
 - Helm users: we redesigned the `HelmRelease` API and the automation will work quite differently, so upgrading to `HelmRelease` v2 will require a little work from you, but you will gain more flexibility, better observability and performance.
 
 ### Is the GitOps Toolkit related to the GitOps Engine?

content/en/flux/use-cases/running-jobs.md

@@ -18,7 +18,7 @@ removed and then reapplied to the cluster.
 A typical use case for running Kubernetes Jobs with Flux is to implement pre-deployment tasks
 for e.g. database scheme migration and post-deployment jobs (like cache refresh).
 
-This requires separate [Flux Kustomization](../components/kustomize/kustomization.md) resources
+This requires separate [Flux Kustomization](/flux/components/kustomize/kustomizations) resources
 that depend on each other: one for running the pre-deployment Jobs,
 one to deploy the application, and a 3rd one for running the post-deployment Jobs.