diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2022-03-04 21:20:01 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2022-03-04 21:20:01 +0300 |
commit | 698fe342b9fff4e569aa0f14a1973271144ff1a5 (patch) | |
tree | 102aa942c5903ecf7543bc9d087c0c7e3eaa6510 /doc/user | |
parent | 73e15fde38825a490903ef88933d8896585f3008 (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/user')
-rw-r--r-- | doc/user/admin_area/analytics/usage_trends.md | 3 | ||||
-rw-r--r-- | doc/user/application_security/index.md | 2 | ||||
-rw-r--r-- | doc/user/clusters/agent/ci_cd_tunnel.md | 9 | ||||
-rw-r--r-- | doc/user/clusters/agent/index.md | 19 |
4 files changed, 21 insertions, 12 deletions
diff --git a/doc/user/admin_area/analytics/usage_trends.md b/doc/user/admin_area/analytics/usage_trends.md index a9c5adcf838..5f46908adb0 100644 --- a/doc/user/admin_area/analytics/usage_trends.md +++ b/doc/user/admin_area/analytics/usage_trends.md @@ -12,9 +12,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w > - It's enabled on GitLab.com. > - It's recommended for production use. -WARNING: -This feature might not be available to you. Check the **version history** note above for details. - Usage Trends gives you an overview of how much data your instance contains, and how quickly this volume is changing over time. Usage Trends data refreshes daily. diff --git a/doc/user/application_security/index.md b/doc/user/application_security/index.md index 632c5804afb..e76497ab5de 100644 --- a/doc/user/application_security/index.md +++ b/doc/user/application_security/index.md @@ -219,7 +219,7 @@ security issues: WARNING: This feature is in its end-of-life process. It is [deprecated](../../update/deprecations.md#vulnerability-check) for use in GitLab 14.8, and is planned for removal in GitLab 15.0. Users should migrate to the new -[Security Approval Policies](policies/#scan-result-policy-editor). +[Security Approval Policies](policies/scan-result-policies.md). To prevent a merge request introducing a security vulnerability in a project, enable the Vulnerability-Check rule. While this rule is enabled, additional merge request approval by diff --git a/doc/user/clusters/agent/ci_cd_tunnel.md b/doc/user/clusters/agent/ci_cd_tunnel.md index d74f8ee6f89..c6dbb1ca70c 100644 --- a/doc/user/clusters/agent/ci_cd_tunnel.md +++ b/doc/user/clusters/agent/ci_cd_tunnel.md @@ -12,16 +12,15 @@ info: To determine the technical writer assigned to the Stage/Group associated w > - [Moved](https://gitlab.com/groups/gitlab-org/-/epics/6290) to GitLab Free in 14.5. > - Support for Omnibus installations was [introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5686) in GitLab 14.5. -You can use GitLab CI/CD to safely deploy to and update your Kubernetes clusters. +You can use a GitLab CI/CD workflow to safely deploy to and update your Kubernetes clusters. -To do so, you install a GitLab agent in your cluster. Then in your GitLab CI/CD pipelines, -you can refer to the cluster connection as a Kubernetes context. -Then you can run Kubernetes API commands as part of your GitLab CI/CD pipeline. +To do so, you must first [install an agent in your cluster](install/index.md). When done, you have a Kubernetes context and can +run Kubernetes API commands in your GitLab CI/CD pipeline. To ensure access to your cluster is safe: - Each agent has a separate context (`kubecontext`). -- Only the project where the agent is, and any additional projects you authorize can access the agent in your cluster. +- Only the project where the agent is configured, and any additional projects you authorize, can access the agent in your cluster. You do not need to have a runner in the cluster with the agent. diff --git a/doc/user/clusters/agent/index.md b/doc/user/clusters/agent/index.md index 6d3151434cc..a8ad19df2e1 100644 --- a/doc/user/clusters/agent/index.md +++ b/doc/user/clusters/agent/index.md @@ -14,7 +14,22 @@ info: To determine the technical writer assigned to the Stage/Group associated w > - [Renamed](https://gitlab.com/groups/gitlab-org/-/epics/7167) from "GitLab Kubernetes Agent" to "GitLab agent for Kubernetes" in GitLab 14.6. You can connect your Kubernetes cluster with GitLab to deploy, manage, -and monitor your cloud-native solutions. You can choose from two primary workflows. +and monitor your cloud-native solutions. + +To connect a Kubernetes cluster to GitLab, you must first [install an agent in your cluster](install/index.md). + +The agent runs in the cluster, and you can use it to: + +- Communicate with a cluster, which is behind a firewall or NAT. +- Access API endpoints in a cluster in real time. +- Push information about events happening in the cluster. +- Enable a cache of Kubernetes objects, which are kept up-to-date with very low latency. + +For more details about the agent's purpose and architecture, see the [architecture documentation](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/architecture.md). + +## Workflows + +You can choose from two primary workflows. In a [**GitOps** workflow](gitops.md), you keep your Kubernetes manifests in GitLab. You install a GitLab agent in your cluster, and any time you update your manifests, the agent updates the cluster. This workflow is fully driven with Git and is considered pull-based, @@ -23,8 +38,6 @@ because the cluster is pulling updates from your GitLab repository. In a [**CI/CD** workflow](ci_cd_tunnel.md), you use GitLab CI/CD to query and update your cluster by using the Kubernetes API. This workflow is considered push-based, because GitLab is pushing requests from GitLab CI/CD to your cluster. -Both of these workflows require you to [install an agent in your cluster](install/index.md). - ## Supported cluster versions GitLab supports the following Kubernetes versions. You can upgrade your |