Add latest changes from gitlab-org/gitlab@16-2-stable-eev16.2.0-rc42

6 files changed, 280 insertions, 247 deletions

diff --git a/doc/user/clusters/agent/gitops/agent.md b/doc/user/clusters/agent/gitops/agent.md
new file mode 100644
index 00000000000..07ed2b3a691
--- /dev/null
+++ b/doc/user/clusters/agent/gitops/agent.md
@@ -0,0 +1,255 @@
+---
+stage: Deploy
+group: Environments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Using GitOps with the agent for Kubernetes (deprecated) **(FREE)**
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/259669) in GitLab 13.7.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/332227) in GitLab 14.0, the `resource_inclusions` and `resource_exclusions` attributes were removed and `reconcile_timeout`, `dry_run_strategy`, `prune`, `prune_timeout`, `prune_propagation_policy`, and `inventory_policy` attributes were added.
+> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/346567) from GitLab Premium to GitLab Free in 15.3.
+> - [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/346585) to make the `id` attribute optional in GitLab 15.7.
+> - Specifying a branch, tag, or commit reference to fetch the Kubernetes manifest files [introduced](https://gitlab.com/groups/gitlab-org/-/epics/4516) in GitLab 15.7.
+
+WARNING:
+This feature was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/406545) in GitLab 16.2. You should use the [Flux integration](../gitops.md) for GitOps.
+
+This diagram shows the repositories and main actors in a GitOps deployment:
+
+```mermaid
+sequenceDiagram
+  participant D as Developer
+  participant A as Application code repository
+  participant M as Manifest repository
+  participant K as GitLab agent
+  participant C as Agent configuration repository
+  loop Regularly
+    K-->>C: Grab the configuration
+  end
+  D->>+A: Pushing code changes
+  A->>M: Updating manifest
+  loop Regularly
+    K-->>M: Watching changes
+    M-->>K: Pulling and applying changes
+  end
+```
+
+For details, view the [architecture documentation](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/architecture.md#high-level-architecture).
+
+## Migrate to Flux
+
+You should migrate your legacy GitOps deployments so they can be
+deployed with Flux. To migrate, configure Flux to deploy manifests
+with Kustomize. If you don't have a `kustomization.yaml` file in
+the given path, it is generated automatically.
+
+Prerequisites:
+
+- A configuration like:
+
+  ```yaml
+  manifest_projects:
+  - id: my-group/my-project
+    default_namespace: production
+    paths:
+    - glob: 'environments/production/**/*.yaml'
+  ```
+
+- A [Flux installation](https://fluxcd.io/flux/installation/) with manifests in `environments/flux-system`.
+- You use a deploy token to access GitLab.
+- Your cluster can access GitLab over HTTPS.
+
+To migrate:
+
+1. Create a file called `environments/flux-system/production.yaml` with the following contents:
+
+   ```yaml
+   # This manifest was generated by flux. DO NOT EDIT.
+   ---
+   apiVersion: source.toolkit.fluxcd.io/v1
+   kind: GitRepository
+   metadata:
+     name: production
+     namespace: flux-system
+   spec:
+     interval: 1m0s
+     ref:
+       branch: main
+     secretRef:
+       name: gitlab-deploy-token
+     url: https://gitlab.example.com/my-group/my-project.git
+   ---
+   apiVersion: kustomize.toolkit.fluxcd.io/v1
+   kind: Kustomization
+   metadata:
+     name: production
+     namespace: flux-system
+   spec:
+     interval: 10m0s
+     path: ./environments/production
+     prune: true
+     sourceRef:
+       kind: GitRepository
+       name: production
+   ```
+
+1. Optional. Because `agentk` uses the `default_namespace` by default, you might need to add a `kustomization.yaml` file to `/environments/production/` and list the relevant resources.
+   For example:
+
+   ```yaml
+   apiVersion: kustomize.config.k8s.io/v1beta1
+   kind: Kustomization
+   namespace: default
+   resources:
+   - relative/path/to-your/resource-1.yaml
+   - relative/path/to-your/resource-2.yaml
+   ```
+
+   When you commit the `kustomization.yaml` file to the repository, a reconciliation with Flux and `agentk` is triggered.
+   Because `agentk` can't handle the Kustomization file, it logs errors when you commit the file.
+
+1. To ensure Flux has taken over the management of the resource, check for the resource in the `status.inventory` value of the `production` Flux Kustomization object:
+
+   ```shell
+   kubectl get kustomization production -n flux-system -o json | jq '.status.inventory.entries'
+   ```
+
+1. Remove the entry from the `manifest_projects` list.
+
+After you migrate, your GitOps deployments deploy with Flux.
+To get the most out of your Flux integration, see the [Flux Kustomization CRD](https://fluxcd.io/flux/components/kustomize/kustomization/) and [GitLab Flux documentation](../gitops.md).
+
+## GitOps workflow steps
+
+To update a Kubernetes cluster by using GitOps, complete the following steps.
+
+1. Ensure you have a working Kubernetes cluster, and that the manifests are in a GitLab project.
+1. In the same project, [register and install the GitLab agent](../install/index.md).
+1. Configure the agent configuration file so that the agent monitors the project for changes to the Kubernetes manifests.
+   Use the [GitOps configuration reference](#gitops-configuration-reference) for guidance.
+
+Any time you commit updates to your Kubernetes manifests, the agent updates the cluster.
+
+## GitOps configuration reference
+
+The following snippet shows an example of the possible keys and values for the GitOps section of an [agent configuration file](../install/index.md#create-an-agent-configuration-file) (`config.yaml`).
+
+```yaml
+gitops:
+  manifest_projects:
+  - id: gitlab-org/cluster-integration/gitlab-agent
+    ref: # either `branch`, `tag` or `commit` can be specified
+      branch: production
+      # commit: <mysha>
+      # tag: v1.0
+    default_namespace: my-ns
+    paths:
+      # Read all YAML files from this directory.
+    - glob: '/team1/app1/*.yaml'
+      # Read all .yaml files from team2/apps and all subdirectories.
+    - glob: '/team2/apps/**/*.yaml'
+      # If 'paths' is not specified or is an empty list, the configuration below is used.
+    - glob: '/**/*.{yaml,yml,json}'
+    reconcile_timeout: 3600s
+    dry_run_strategy: none
+    prune: true
+    prune_timeout: 3600s
+    prune_propagation_policy: foreground
+    inventory_policy: must_match
+```
+
+| Keyword | Description |
+|--|--|
+| `manifest_projects` | Projects where your Kubernetes manifests are stored. The agent monitors the files in the repositories in these projects. When manifest files change, the agent deploys the changes to the cluster. |
+| `id` | Path to a Git repository that has Kubernetes manifests in YAML or JSON format. No authentication mechanisms are supported. Default is the agent configuration repository. |
+| `ref` | Optional. Git reference in the configured Git repository to fetch the Kubernetes manifest files from. If not specified or empty, the default branch is used. If specified, it must contain either `branch`, `tag`, or `commit`. |
+| `ref.branch` | Branch name in the configured Git repository to fetch the Kubernetes manifest files from. |
+| `ref.tag` | Tag name in the configured Git repository to fetch the Kubernetes manifest files from. |
+| `ref.commit` | Commit SHA in the configured Git repository to fetch the Kubernetes manifest files from. |
+| `default_namespace` | Namespace to use if not set explicitly in object manifest. Also used for inventory `ConfigMap` objects. |
+| `paths` | Repository paths to scan for manifest files. Directories with names that start with a dot `(.)` are ignored. |
+| `paths[].glob` | Required. See [doublestar](https://github.com/bmatcuk/doublestar#about) and [the match function](https://pkg.go.dev/github.com/bmatcuk/doublestar/v2#Match) for globbing rules. |
+| `reconcile_timeout` | Determines whether the applier should wait until all applied resources have been reconciled, and if so, how long to wait. Default is 3600 seconds (1 hour). |
+| `dry_run_strategy` | Determines whether changes [should be performed](https://github.com/kubernetes-sigs/cli-utils/blob/d6968048dcd80b1c7b55d9e4f31fc25f71c9b490/pkg/common/common.go#L68-L89). Can be: `none`, `client`, or `server`. Default is `none`.|
+| `prune` | Determines whether pruning of previously applied objects should happen after apply. Default is `true`. |
+| `prune_timeout` | Determines whether to wait for all resources to be fully deleted after pruning, and if so, how long to wait. Default is 3600 seconds (1 hour). |
+| `prune_propagation_policy` | The deletion propagation policy that [should be used for pruning](https://github.com/kubernetes/apimachinery/blob/44113beed5d39f1b261a12ec398a356e02358307/pkg/apis/meta/v1/types.go#L456-L470). Can be: `orphan`, `background`, or `foreground`. Default is `foreground`. |
+| `inventory_policy` | Determines whether an inventory object can take over objects that belong to another inventory object or don't belong to any inventory object. This is done by determining if the apply/prune operation can go through for a resource based on comparison of the `inventory-id` value in the package and the `owning-inventory` annotation (`config.k8s.io/owning-inventory`) [in the live object](https://github.com/kubernetes-sigs/cli-utils/blob/d6968048dcd80b1c7b55d9e4f31fc25f71c9b490/pkg/inventory/policy.go#L12-L66). Can be: `must_match`, `adopt_if_no_inventory`, or `adopt_all`. Default is `must_match`. |
+
+## GitOps annotations
+
+The GitLab agent for Kubernetes has annotations you can use to:
+
+- **Sort resources**: Apply or delete resources in a specific order.
+- **Use apply-time mutation**: Dynamically substitute fields from one resource configuration to another.
+
+The agent has [default sorting](https://github.com/kubernetes-sigs/cli-utils/blob/d7d63f4b62897f584ca9e02b6faf4d2f327a9b09/pkg/ordering/sort.go#L74),
+but with annotations, you can fine-tune the order and apply time-value injection.
+
+To provide the GitOps functionality, the GitLab agent for Kubernetes uses the [`cli-utils` library](https://github.com/kubernetes-sigs/cli-utils/),
+a Kubernetes SIG project. For more information, see the available annotations in the [`cli-utils` documentation](https://github.com/kubernetes-sigs/cli-utils/blob/master/README.md).
+
+## Automatic drift remediation
+
+Drift happens when the current configuration of an infrastructure resource differs from its desired configuration.
+Typically, this is caused by manually editing resources directly rather than via the used infrastructure-as-code
+mechanism. Minimizing the risk of drift helps to ensure configuration consistency and successful operations.
+
+In GitLab, the agent for Kubernetes regularly compares the desired state from the `git` repository with
+the actual state from the Kubernetes cluster. Deviations from the `git` state are fixed at every check. These checks
+happen automatically every 5 minutes. They are not configurable.
+
+The agent uses [server-side applies](https://kubernetes.io/docs/reference/using-api/server-side-apply/).
+As a result, every field in a resource can have different managers. Only fields managed by `git`
+are checked for drift. This facilitates the use of in-cluster controllers to modify resources like
+[Horizontal Pod Autoscalers](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).
+
+## Related topics
+
+- [GitOps working examples for training and demos](https://gitlab.com/groups/guided-explorations/gl-k8s-agent/gitops/-/wikis/home)
+- [Self-paced classroom workshop](https://gitlab-for-eks.awsworkshop.io) (Uses AWS EKS, but you can use for other Kubernetes clusters)
+- [Managing Kubernetes secrets in a GitOps workflow](secrets_management.md)
+- [Application and manifest repository example](https://gitlab.com/gitlab-examples/ops/gitops-demo/hello-world-service-gitops)
+
+## Troubleshooting
+
+### Avoiding conflicts when you have multiple projects
+
+The agent watches each glob pattern set under a project's `paths` section independently, and makes updates to the cluster concurrently.
+If changes are found at multiple paths, when the agent attempts to update the cluster,
+a conflict can occur.
+
+To prevent this from happening, consider storing a logical group of manifests in a single place and reference them only once to avoid overlapping globs.
+
+For example, both of these globs match `*.yaml` files in the root directory
+and could cause conflicts:
+
+```yaml
+gitops:
+  manifest_projects:
+  - id: project1
+    paths:
+    - glob: '/**/*.yaml'
+    - glob: '/*.yaml'
+```
+
+Instead, specify a single glob that matches all `*.yaml` files recursively:
+
+```yaml
+gitops:
+  manifest_projects:
+  - id: project1
+    paths:
+    - glob: '/**/*.yaml'
+```
+
+### Use multiple agents or projects
+
+If you store your Kubernetes manifests in separate GitLab projects,
+update your agent configuration file with the location of these projects.
+
+WARNING:
+The project with the agent's
+configuration file can be private or public. Other projects with Kubernetes manifests must be public. Support for private manifest projects is tracked
+in [this epic](https://gitlab.com/groups/gitlab-org/-/epics/7704).
diff --git a/doc/user/clusters/agent/gitops/example_repository_structure.md b/doc/user/clusters/agent/gitops/example_repository_structure.md
index 93c05e40bfd..a5bc3b153fe 100644
--- a/doc/user/clusters/agent/gitops/example_repository_structure.md
+++ b/doc/user/clusters/agent/gitops/example_repository_structure.md
@@ -60,7 +60,7 @@ the deployment branch back to the repository using the provided token. To preser
 commit history between both branches, the CI/CD job uses a fast-forward merge.
 
 Each cluster has an agent for Kubernetes, and each agent is configured to
-[sync manifests from the branch corresponding to its cluster](../gitops.md#gitops-configuration-reference).
+sync manifests from the branch corresponding to its cluster.
 In your own project, you can different GitOps tool like Flux, or use the same configuration to deploy
 to virtual machines with GitLab CI/CD.
 
diff --git a/doc/user/clusters/agent/gitops/flux.md b/doc/user/clusters/agent/gitops/flux.md
index f0a681c1a5c..13fcfeb28e9 100644
--- a/doc/user/clusters/agent/gitops/flux.md
+++ b/doc/user/clusters/agent/gitops/flux.md
@@ -1,97 +1,11 @@
 ---
-stage: Deploy
-group: Environments
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../gitops.md'
+remove_date: '2023-10-12'
 ---
 
-# Flux (Beta) **(FREE)**
+This document was moved to [another location](../gitops.md).
 
-Flux is a GitOps tool that helps you manage your Kubernetes clusters.
-You can use Flux to:
-
-- Keep your clusters in sync with your Git repositories.
-- Reconcile code changes with your deployments.
-- Manage your Flux installation itself with a bootstrap.
-
-You can use the agent for Kubernetes with Flux to:
-
-- Trigger immediate Git repository reconciliation.
-
-To get started, see the [Flux installation documentation](https://fluxcd.io/flux/installation).
-
-Support for Flux is in [Beta](../../../../policy/experiment-beta-support.md#beta).
-
-## Bootstrap installation
-
-Use the Flux command [`bootstrap gitlab`](https://fluxcd.io/flux/installation/#gitlab-and-gitlab-enterprise)
-to configure a Kubernetes cluster to manage itself from a Git repository.
-
-You must authenticate your installation with either:
-
-- Recommended. [A project access token](../../../project/settings/project_access_tokens.md).
-- A [group access token](../../../group/settings/group_access_tokens.md).
-- A [personal access token](../../../profile/personal_access_tokens.md).
-
-Some Flux features like [automated image updates](https://fluxcd.io/flux/guides/image-update/) require
-write access to the source repositories.
-
-## GitOps repository structure
-
-You should organize your repositories to meet the needs of your team. For detailed recommendations, see the Flux [repository structure documentation](https://fluxcd.io/flux/guides/repository-structure/).
-
-## Immediate Git repository reconciliation
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/392852) in GitLab 16.1.
-
-Usually, the Flux source controller reconciles Git repositories at configured intervals.
-This can cause delays between a `git push` and the reconciliation of the cluster state, and results in
-unnecessary pulls from GitLab.
-
-The agent for Kubernetes automatically detects Flux `GitRepository` objects that
-reference GitLab projects in the instance the agent is connected to,
-and configures a [`Receiver`](https://fluxcd.io/flux/components/notification/receiver/) for the instance.
-When the agent for Kubernetes detects a `git push`, the `Receiver` is triggered
-and Flux reconciles the cluster with any changes to the repository.
-
-To use immediate Git repository reconciliation, you must have a Kubernetes cluster that runs:
-
-- The agent for Kubernetes.
-- Flux `source-controller` and `notification-controller`.
-
-Immediate Git repository reconciliation can reduce the time between a push and reconciliation,
-but it doesn't guarantee that every `git push` event is received. You should still set
-[`GitRepository.spec.interval`](https://fluxcd.io/flux/components/source/gitrepositories/#interval)
-to an acceptable duration.
-
-### Custom webhook endpoints
-
-When the agent for Kubernetes calls the `Receiver` webhook,
-the agent defaults to `http://webhook-receiver.flux-system.svc.cluster.local`,
-which is also the default URL set by a Flux bootstrap installation. To configure a custom
-endpoint, set `flux.webhook_receiver_url` to a URL that the agent can resolve. For example:
-
-```yaml
-flux:
-  webhook_receiver_url: http://webhook-receiver.another-flux-namespace.svc.cluster.local
-```
-
-There is special handing for
-[service proxy URLs](https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster-services/) configured
-in this format: `/api/v1/namespaces/[^/]+/services/[^/]+/proxy`. For example:
-
-```yaml
-flux:
-  webhook_receiver_url: /api/v1/namespaces/flux-system/services/http:webhook-receiver:80/proxy
-```
-
-In these cases, the agent for Kubernetes uses the available Kubernetes configuration
-and context to connect to the API endpoint.
-You can use this if you run an agent outside a cluster
-and you haven't [configured an `Ingress`](https://fluxcd.io/flux/guides/webhook-receivers/#expose-the-webhook-receiver)
-for the Flux notification controller.
-
-WARNING:
-You should configure only trusted service proxy URLs.
-When you provide a service proxy URL,
-the agent for Kubernetes sends typical Kubernetes API requests which include
-the credentials necessary to authenticate with the API service.
+<!-- This redirect file can be deleted after <2023-10-12>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/user/clusters/agent/gitops/flux_tutorial.md b/doc/user/clusters/agent/gitops/flux_tutorial.md
index c6c9ed9e373..8aee0c01d65 100644
--- a/doc/user/clusters/agent/gitops/flux_tutorial.md
+++ b/doc/user/clusters/agent/gitops/flux_tutorial.md
@@ -9,6 +9,9 @@ info: A tutorial using Flux
 This tutorial teaches you how to set up Flux for GitOps. You'll complete a bootstrap installation,
 install `agentk` in your cluster, and deploy a simple `nginx` application.
 
+<i class="fa fa-youtube-play youtube" aria-hidden="true"></i> For an overview of an example Flux
+configuration, see [Flux bootstrap and manifest synchronization with GitLab](https://www.youtube.com/watch?v=EjPVRM-N_PQ).
+
 To set up Flux for GitOps:
 
 1. [Create a personal access token](#create-a-personal-access-token)
@@ -97,7 +100,7 @@ To install `agentk`:
    apiVersion: v1
    kind: Namespace
    metadata:
-   name: gitlab
+     name: gitlab
    ```
 
 1. Apply the agent registration token as a secret in the cluster:
@@ -140,7 +143,7 @@ To install `agentk`:
          sourceRef:
            kind: HelmRepository
            name: gitlab-agent
-           namespace: gitlab-agent
+           namespace: gitlab
      interval: 1h0m0s
      values:
        config:
@@ -177,8 +180,6 @@ To demonstrate, deploy an `nginx` application and point Flux at it:
      interval: 1m0s
      ref:
        branch: main
-     secretRef:
-       name: example-nginx-app
      url: https://gitlab.com/gitlab-examples/ops/gitops-demo/example-mini-flux-deployment.git
    ---
    apiVersion: kustomize.toolkit.fluxcd.io/v1
diff --git a/doc/user/clusters/agent/gitops/helm.md b/doc/user/clusters/agent/gitops/helm.md
index 182fd87e6f9..22587cd0e5d 100644
--- a/doc/user/clusters/agent/gitops/helm.md
+++ b/doc/user/clusters/agent/gitops/helm.md
@@ -1,152 +1,11 @@
 ---
-stage: Deploy
-group: Environments
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../gitops.md'
+remove_date: '2023-10-22'
 ---
 
-# Using Helm charts to update a Kubernetes cluster (Experiment) **(FREE)**
+This document was moved to [another location](../gitops.md).
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/371019) in GitLab 15.4.
-> - Specifying a branch, tag, or commit reference to fetch the Kubernetes manifest files [introduced](https://gitlab.com/groups/gitlab-org/-/epics/4516) in GitLab 15.7.
-
-You can deploy Helm charts to your Kubernetes cluster and keep the resources in your cluster in sync
-with your charts and values. To do this, you use the pull-based GitOps features of the agent for
-Kubernetes.
-
-This feature is an Experiment and [an epic exists](https://gitlab.com/groups/gitlab-org/-/epics/7938)
-to track future work. Tell us about your use cases by leaving comments in the epic.
-
-NOTE:
-This feature is an Experiment. In future releases, to accommodate new features, the configuration format might change without notice.
-
-## GitOps workflow steps
-
-To update a Kubernetes cluster by using GitOps with charts, complete the following steps.
-
-1. Ensure you have a working Kubernetes cluster, and that the chart is in a GitLab project.
-1. In the same project, [register and install the GitLab agent](../install/index.md).
-1. Configure the agent configuration file so that the agent monitors the project for changes to the chart.
-   Use the [GitOps configuration reference](#helm-configuration-reference) for guidance.
-
-## Helm chart with GitOps workflow
-
-To update a Kubernetes cluster by using Helm charts:
-
-1. Ensure you have a working Kubernetes cluster.
-1. In a GitLab project:
-   - Store your Helm charts.
-   - [Register and install the GitLab agent](../install/index.md).
-1. Update the agent configuration file so that the agent monitors the project for changes to the chart.
-   Use the [configuration reference](#helm-configuration-reference) for guidance.
-
-Any time you commit updates to your chart repository, the agent applies the chart in the cluster.
-
-## Helm configuration reference
-
-The following snippet shows an example of the possible keys and values for the GitOps section of an [agent configuration file](../install/index.md#create-an-agent-configuration-file) (`config.yaml`).
-
-```yaml
-gitops:
-  charts:
-  - release_name: my-application-release
-    source:
-      project:
-        id: my-group/my-project-with-chart
-        ref:
-          branch: production
-        path: dir-in-project/with/charts
-    namespace: my-ns
-    max_history: 1
-    values:
-      - inline:
-          someKey: example value
-```
-
-| Keyword | Description |
-|--|--|
-| `charts` | List of charts you want to be applied in your cluster. Charts are applied concurrently. |
-| `release_name` | Required. Name of the release to use when applying the chart. |
-| `values` | Optional. [Custom values](#custom-values) for the release. An array of objects. Only supports `inline` values. |
-| `namespace` | Optional. Namespace to use when applying the chart. Defaults to `default`. |
-| `max_history` | Optional. Maximum number of release [revisions to store in the cluster](https://helm.sh/docs/helm/helm_history/). |
-| `source` | Required. From where the chart should get installed. Only supports project sources. |
-| `source.project.id` | Required. ID of the project where Helm chart is committed. Authentication is not supported. |
-| `source.project.ref` | Optional. Git reference in the configured Git repository to fetch the Chart from. If not specified or empty, the default branch is used. If specified, it must contain either `branch`, `tag`, or `commit`. |
-| `source.project.ref.branch` | Branch name in the configured Git repository to fetch the Chart from. |
-| `source.project.ref.tag` | Tag name in the configured Git repository to fetch the Chart from. |
-| `source.project.ref.commit` | Commit SHA in the configured Git repository to fetch the Chart from. |
-| `source.project.path` | Optional. Path of the chart in the project repository. Root of the repository is used by default. Should be the directory with the `Chart.yaml` file. |
-
-## Custom values
-
-> [Introduced](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/merge_requests/766) in GitLab 15.6. Requires both GitLab and the installed agent to be version 15.6 or later.
-
-To customize the values for a release, set the `values` key. It must be
-an array of objects. Each object must have exactly one top-level key that describes
-where the values come from. The supported top-level keys are:
-
-- `inline`: Specify the values inline in YAML format, similar to a Helm values
-  file.
-
-When installing a chart with custom values:
-
-- Custom values get merged on top of the chart's default `values.yaml` file.
-- Values from subsequent entries in the `values` array overwrite values from
-  previous entries.
-
-Example:
-
-```yaml
-gitops:
-  charts:
-  - release_name: some-release
-    values:
-      - inline:
-          someKey: example value
-    # ...
-```
-
-## Automatic drift remediation
-
-Drift happens when the current configuration of an infrastructure resource differs from its desired configuration.
-Typically, drift is caused by manually editing resources directly, rather than by editing the code that describes the desired state. Minimizing the risk of drift helps to ensure configuration consistency and successful operations.
-
-In GitLab, the agent for Kubernetes regularly compares the desired state from the chart source with
-the actual state from the Kubernetes cluster. Deviations from the desired state are fixed at every check. These checks
-happen automatically every 5 minutes. They are not configurable.
-
-## Example repository layout
-
-```plaintext
-/my-chart
- ├── templates
- |   └── ...
- ├── charts
- |   └── ...
- ├── Chart.yaml
- ├── Chart.lock
- ├── values.yaml
- ├── values.schema.json
- └── some-file-used-in-chart.txt
-```
-
-## Known issues
-
-The following are known issues:
-
-- Your chart must be in a GitLab project. The project must be an agent configuration project or a public
-  project. This known issue also exists for manifest-based GitOps and is tracked in
-  [this epic](https://gitlab.com/groups/gitlab-org/-/epics/7704).
-- Values for the chart must be in a `values.yaml` file. This file must be with the chart,
-  in the same project and path.
-- Because of drift detection and remediation, the release history stored in the cluster is not useful.
-  A new release is created every five minutes and the oldest release is discarded.
-  Eventually history consists only of the same information.
-  View [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/372023) for details.
-
-## Troubleshooting
-
-### Agent cannot find values for the chart
-
-Make sure values are in `values.yaml` and in the same directory as the `Chart.yaml` file.
-The filename must be lowercase, with `.yaml` extension (not `.yml`).
+<!-- This redirect file can be deleted after 2023-10-22. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/user/clusters/agent/gitops/secrets_management.md b/doc/user/clusters/agent/gitops/secrets_management.md
index 6e1b7da9c6c..a9590f34183 100644
--- a/doc/user/clusters/agent/gitops/secrets_management.md
+++ b/doc/user/clusters/agent/gitops/secrets_management.md
@@ -4,7 +4,11 @@ group: Environments
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Managing Kubernetes secrets in a GitOps workflow
+# Managing Kubernetes secrets in a GitOps workflow (deprecated)
+
+WARNING:
+This feature was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/406545) in GitLab 16.2.
+To manage cluster resources with GitOps, you should use the [Flux integration](../../../clusters/agent/gitops.md).
 
 You should never store Kubernetes secrets in unencrypted form in a `git` repository. If you use a GitOps workflow, you can follow these steps to securely manage your secrets.