Commit 329d40ca authored by Hordur Freyr Yngvason's avatar Hordur Freyr Yngvason Committed by Marcia Ramos

Update references to GitLab-managed apps with alternatives

parent b2d828d5
......@@ -9,7 +9,7 @@ export default {
GlSprintf,
},
computed: {
...mapState(['clustersPath', 'emptyImagePath', 'helpPath']),
...mapState(['emptyImagePath', 'helpPath']),
},
};
</script>
......@@ -18,8 +18,6 @@ export default {
<gl-empty-state
:svg-path="emptyImagePath"
:title="s__('Serverless|Getting started with serverless')"
:primary-button-link="clustersPath"
:primary-button-text="s__('Serverless|Install Knative')"
>
<template #description>
<gl-sprintf
......
......@@ -26,7 +26,7 @@ export default {
return this.missingData
? s__(`ServerlessDetails|Invocation metrics loading or not available at this time.`)
: s__(
`ServerlessDetails|Function invocation metrics require Prometheus to be installed first.`,
`ServerlessDetails|Function invocation metrics require the Prometheus cluster integration.`,
);
},
},
......@@ -48,7 +48,7 @@ export default {
<div v-if="!missingData" class="text-left">
<gl-button :href="clustersPath" variant="success" category="primary">
{{ s__('ServerlessDetails|Install Prometheus') }}
{{ s__('ServerlessDetails|Configure cluster.') }}
</gl-button>
</div>
</div>
......
......@@ -44,7 +44,7 @@ module ClustersHelper
base_domain: cluster.base_domain,
application_ingress_external_ip: cluster.application_ingress_external_ip,
auto_devops_help_path: help_page_path('topics/autodevops/index'),
external_endpoint_help_path: help_page_path('user/clusters/applications.md', anchor: 'pointing-your-dns-at-the-external-endpoint')
external_endpoint_help_path: help_page_path('user/project/clusters/index.md', anchor: 'base-domain')
}
end
......
......@@ -36,7 +36,7 @@ module EnvironmentsHelper
"environment_name": environment.name,
"environments_path": api_v4_projects_environments_path(id: project.id),
"environment_id": environment.id,
"cluster_applications_documentation_path" => help_page_path('user/clusters/applications.md', anchor: 'elastic-stack'),
"cluster_applications_documentation_path" => help_page_path('user/clusters/integrations.md', anchor: 'elastic-stack-cluster-integration'),
"clusters_path": project_clusters_path(project, format: :json)
}
end
......
......@@ -26,7 +26,7 @@
cluster_status_reason: @cluster.status_reason,
provider_type: @cluster.provider_type,
pre_installed_knative: @cluster.knative_pre_installed? ? 'true': 'false',
help_path: help_page_path('user/project/clusters/index.md', anchor: 'installing-applications'),
help_path: help_page_path('user/project/clusters/index.md'),
helm_help_path: help_page_path('user/clusters/applications.md', anchor: 'helm'),
ingress_help_path: help_page_path('user/clusters/applications.md', anchor: 'determining-the-external-endpoint-automatically'),
ingress_dns_help_path: help_page_path('user/clusters/applications.md', anchor: 'pointing-your-dns-at-the-external-endpoint'),
......
%h4
= s_('PrometheusService|Auto configuration')
= s_('PrometheusService|Prometheus cluster integration')
- if integration.manual_configuration?
.info-well
= s_('PrometheusService|To enable the installation of Prometheus on your clusters, deactivate the manual configuration.')
= s_('PrometheusService|To use a Prometheus installed on a cluster, deactivate the manual configuration.')
- else
.container-fluid
.row
......@@ -13,14 +13,14 @@
= image_tag 'illustrations/monitoring/getting_started.svg'
.col-sm-10
%p.text-success.gl-mt-3
= s_('PrometheusService|GitLab is managing Prometheus on your clusters.')
= s_('PrometheusService|You have a cluster with the Prometheus integration enabled.')
= link_to s_('PrometheusService|Manage clusters'), project_clusters_path(project), class: 'btn gl-button'
- else
.col-sm-2
= image_tag 'illustrations/monitoring/loading.svg'
.col-sm-10
%p.gl-mt-3
= s_('PrometheusService|Automatically deploy and configure Prometheus on your clusters to monitor your project’s environments.')
= link_to s_('PrometheusService|Install Prometheus on clusters'), project_clusters_path(project), class: 'btn gl-button btn-confirm'
= s_('PrometheusService|Configure GitLab to query a Prometheus installed in one of your clusters.')
= link_to s_('PrometheusService|Manage clusters'), project_clusters_path(project), class: 'btn gl-button btn-confirm'
%hr
%b
= s_('PrometheusService|Auto configuration')
= s_('PrometheusService|Prometheus cluster integration')
- if service.manual_configuration?
.info-well.p-2.mt-2
= s_('PrometheusService|To enable the installation of Prometheus on your clusters, deactivate the manual configuration.')
= s_('PrometheusService|To use a Prometheus installed on a cluster, deactivate the manual configuration.')
- else
.container-fluid
.row
......@@ -13,12 +13,12 @@
= image_tag 'illustrations/monitoring/getting_started.svg'
.col-sm-10
%p.text-success.gl-mt-3
= s_('PrometheusService|GitLab manages Prometheus on your clusters.')
= s_('PrometheusService|You have a cluster with the Prometheus integration enabled.')
= link_to s_('PrometheusService|Manage clusters'), project_clusters_path(project), class: 'gl-button btn btn-default'
- else
.col-sm-2
= image_tag 'illustrations/monitoring/loading.svg'
.col-sm-10
%p.gl-mt-3
= s_('PrometheusService|Monitor your project’s environments by deploying and configuring Prometheus on your clusters.')
= link_to s_('PrometheusService|Install Prometheus on clusters'), project_clusters_path(project), class: 'gl-button btn btn-confirm'
= s_('PrometheusService|Configure GitLab to query a Prometheus installed in one of your clusters.')
= link_to s_('PrometheusService|Manage clusters'), project_clusters_path(project), class: 'btn gl-button btn-confirm'
......@@ -234,7 +234,6 @@ Component statuses are linked to configuration documentation for each component.
| [GitLab Exporter](#gitlab-exporter) | Generates a variety of GitLab metrics | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | CE & EE |
| [GitLab Geo Node](#gitlab-geo) | Geographically distributed GitLab nodes | ⚙ | ⚙ | ❌ | ❌ | ✅ | ❌ | ⚙ | EE Only |
| [GitLab Kubernetes Agent](#gitlab-kubernetes-agent) | Integrate Kubernetes clusters in a cloud-native way | ⚙ | ⚙ | ⚙ | ❌ | ❌ | ⤓ | ⚙ | EE Only |
| [GitLab Managed Apps](#gitlab-managed-apps) | Deploy Helm, Ingress, Cert-Manager, Prometheus, GitLab Runner, JupyterHub, or Knative to a cluster | ⤓ | ⤓ | ⤓ | ⤓ | ⤓ | ⤓ | ⤓ | CE & EE |
| [GitLab Pages](#gitlab-pages) | Hosts static websites | ⚙ | ⚙ | ❌ | ❌ | ✅ | ⚙ | ⚙ | CE & EE |
| [GitLab Kubernetes Agent](#gitlab-kubernetes-agent) | Integrate Kubernetes clusters in a cloud-native way | ⚙ | ⚙ | ⚙ | ❌ | ❌ | ⤓ | ⚙ | EE Only |
| [GitLab self-monitoring: Alertmanager](#alertmanager) | Deduplicates, groups, and routes alerts from Prometheus | ⚙ | ⚙ | ✅ | ⚙ | ✅ | ❌ | ❌ | CE & EE |
......@@ -739,28 +738,6 @@ Starting with GitLab 13.0, Puma is the default web server.
- Layer: Core Service (Processor)
- GitLab.com: [Mail configuration](../user/gitlab_com/index.md#mail-configuration)
#### GitLab Managed Apps
- Configuration:
- [Omnibus](../user/project/clusters/index.md#installing-applications)
- [Charts](../user/project/clusters/index.md#installing-applications)
- [Source](../user/project/clusters/index.md#installing-applications)
- [GDK](../user/project/clusters/index.md#installing-applications)
- Layer: Core Service (Processor)
GitLab provides [GitLab Managed Apps](../user/project/clusters/index.md#installing-applications),
a one-click install for various applications which can be added directly to your configured cluster.
These applications are needed for Review Apps and deployments when using Auto DevOps.
You can install them after you create a cluster. This includes:
- [Helm](https://helm.sh/docs/)
- [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)
- [Cert-Manager](https://cert-manager.io/docs/)
- [Prometheus](https://prometheus.io/docs/introduction/overview/)
- [GitLab Runner](https://docs.gitlab.com/runner/)
- [JupyterHub](https://jupyter.org)
- [Knative](https://cloud.google.com/knative/)
## GitLab by request type
GitLab provides two "interfaces" for end users to access the service:
......
......@@ -172,12 +172,3 @@ they are written:
```shell
kubectl logs <pod_name> --follow -n gitlab-managed-apps
```
## GitLab Managed Apps
GitLab provides [GitLab Managed Apps](../user/clusters/applications.md), a one-click
install for various applications which can be added directly to your configured cluster.
**<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
For an overview of how to add a new GitLab-managed app, see
[How to add GitLab-managed-apps to Kubernetes integration](https://youtu.be/mKm-jkranEk).**
......@@ -308,6 +308,5 @@ and customized to fit your workflow. Here are some helpful resources for further
1. [Multiple Kubernetes clusters](index.md#using-multiple-kubernetes-clusters)
1. [Incremental rollout to production](customize.md#incremental-rollout-to-production) **(PREMIUM)**
1. [Disable jobs you don't need with CI/CD variables](customize.md#cicd-variables)
1. [Use a static IP for your cluster](../../user/clusters/applications.md#using-a-static-ip)
1. [Use your own buildpacks to build your application](customize.md#custom-buildpacks)
1. [Prometheus monitoring](../../user/project/integrations/prometheus.md)
......@@ -26,21 +26,20 @@ To make full use of Auto DevOps with Kubernetes, you need:
[new cluster using the GitLab UI](../../user/project/clusters/add_remove_clusters.md#create-new-cluster).
For Kubernetes 1.16+ clusters, you must perform additional configuration for
[Auto Deploy for Kubernetes 1.16+](stages.md#kubernetes-116).
1. NGINX Ingress. You can deploy it to your Kubernetes cluster by installing
the [GitLab-managed app for Ingress](../../user/clusters/applications.md#ingress),
after configuring the GitLab integration with Kubernetes in the previous step.
Alternatively, you can use the
[`nginx-ingress`](https://github.com/helm/charts/tree/master/stable/nginx-ingress)
Helm chart to install Ingress manually.
1. For external HTTP traffic, an Ingress controller is required. For regular
deployments, any Ingress controller should work, but as of GitLab 14.0,
[canary deployments](../../user/project/canary_deployments.md) require
NGINX Ingress. You can deploy the NGINX Ingress controller to your
Kubernetes cluster by installing the
[`ingress-nginx`](https://github.com/kubernetes/ingress-nginx/tree/master/charts/ingress-nginx)
Helm chart.
NOTE:
If you use your own Ingress instead of the one provided by GitLab Managed
Apps, ensure you're running at least version 0.9.0 of NGINX Ingress and
[enable Prometheus metrics](https://github.com/helm/charts/tree/master/stable/nginx-ingress#prometheus-metrics)
for the response metrics to appear. You must also
For metrics to appear when using the [Prometheus cluster integration](../../user/clusters/integrations.md#prometheus-cluster-integration), you must [enable Prometheus metrics](https://github.com/kubernetes/ingress-nginx/tree/master/charts/ingress-nginx#prometheus-metrics).
When deploying [using custom charts](customize.md#custom-helm-chart), you must also
[annotate](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
the NGINX Ingress deployment to be scraped by Prometheus using
the Ingress manifest to be scraped by Prometheus using
`prometheus.io/scrape: "true"` and `prometheus.io/port: "10254"`.
NOTE:
......@@ -65,10 +64,6 @@ To make full use of Auto DevOps with Kubernetes, you need:
You can configure Docker-based runners to autoscale as well, using
[Docker Machine](https://docs.gitlab.com/runner/install/autoscaling.html).
If you've configured the GitLab integration with Kubernetes in the first step, you
can deploy it to your cluster by installing the
[GitLab-managed app for GitLab Runner](../../user/clusters/applications.md#gitlab-runner).
Runners should be registered as [shared runners](../../ci/runners/README.md#shared-runners)
for the entire GitLab instance, or [specific runners](../../ci/runners/README.md#specific-runners)
that are assigned to specific projects (the default if you've installed the
......@@ -78,9 +73,9 @@ To make full use of Auto DevOps with Kubernetes, you need:
To enable Auto Monitoring, you need Prometheus installed either inside or
outside your cluster, and configured to scrape your Kubernetes cluster.
If you've configured the GitLab integration with Kubernetes, you can deploy it to
your cluster by installing the
[GitLab-managed app for Prometheus](../../user/clusters/applications.md#prometheus).
If you've configured the GitLab integration with Kubernetes, you can
instruct GitLab to query an in-cluster Prometheus by enabling
the [Prometheus cluster integration](../../user/clusters/integrations.md#prometheus-cluster-integration).
The [Prometheus service](../../user/project/integrations/prometheus.md)
integration must be enabled for the project, or enabled as a
......@@ -92,15 +87,13 @@ To make full use of Auto DevOps with Kubernetes, you need:
- **cert-manager** (optional, for TLS/HTTPS)
To enable HTTPS endpoints for your application, you must install cert-manager,
To enable HTTPS endpoints for your application, you can [install cert-manager](https://cert-manager.io/docs/installation/kubernetes/),
a native Kubernetes certificate management controller that helps with issuing
certificates. Installing cert-manager on your cluster issues a
[Let's Encrypt](https://letsencrypt.org/) certificate and ensures the
certificates are valid and up-to-date. If you've configured the GitLab integration
with Kubernetes, you can deploy it to your cluster by installing the
[GitLab-managed app for cert-manager](../../user/clusters/applications.md#cert-manager).
certificates are valid and up-to-date.
If you don't have Kubernetes or Prometheus installed, then
If you don't have Kubernetes or Prometheus configured, then
[Auto Review Apps](stages.md#auto-review-apps),
[Auto Deploy](stages.md#auto-deploy), and [Auto Monitoring](stages.md#auto-monitoring)
are skipped.
......@@ -128,9 +121,6 @@ When you trigger a pipeline, if you have Auto DevOps enabled and if you have cor
[entered AWS credentials as variables](../../ci/cloud_deployment/index.md#deploy-your-application-to-the-aws-elastic-container-service-ecs),
your application is deployed to AWS ECS.
[GitLab Managed Apps](../../user/clusters/applications.md) are not available when deploying to AWS ECS.
You must manually configure your application (such as Ingress or Help) on AWS ECS.
If you have both a valid `AUTO_DEVOPS_PLATFORM_TARGET` variable and a Kubernetes cluster tied to your project,
only the deployment to Kubernetes runs.
......
......@@ -687,11 +687,6 @@ The metrics include:
- **Response Metrics:** latency, throughput, error rate
- **System Metrics:** CPU utilization, memory utilization
GitLab provides some initial alerts for you after you install Prometheus:
- Ingress status code `500` > 0.1%
- NGINX status code `500` > 0.1%
To use Auto Monitoring:
1. [Install and configure the Auto DevOps requirements](requirements.md).
......
......@@ -33,9 +33,9 @@ permissions in a project or group.
1. Connect GitLab with Prometheus, depending on your configuration:
- *If Prometheus is already configured,* navigate to **Settings > Integrations > Prometheus**
to provide the API endpoint of your Prometheus server.
- *For GitLab-managed Prometheus,* navigate to your cluster's **Details** page,
select the **Applications** tab, and install Prometheus. The integration is
auto-configured for you.
- *To use the Prometheus cluster integration,* navigate to your cluster's **Details** page,
select the **Integrations** tab, and follow the instructions to enable the Prometheus
cluster integration.
1. Set up the Prometheus integration on the cloned example project.
1. Add the Kubecost `cost-model` to your cluster:
- *For non-managed clusters*, deploy it with GitLab CI/CD.
......
......@@ -17,12 +17,11 @@ your group, enabling you to use the same cluster across multiple projects.
To view your group level Kubernetes clusters, navigate to your project and select
**Kubernetes** from the left-hand menu.
## Installing applications
## Cluster management project
GitLab can install and manage some applications in your group-level
cluster. For more information on installing, upgrading, uninstalling,
and troubleshooting applications for your group cluster, see
[GitLab Managed Apps](../../clusters/applications.md).
Attach a [cluster management project](../../clusters/management_project.md)
to your cluster to manage shared resources requiring `cluster-admin` privileges for
installation, such as an Ingress controller.
## RBAC compatibility
......@@ -72,9 +71,6 @@ for deployments with a cluster not managed by GitLab, you must ensure:
(this is [not automatic](https://gitlab.com/gitlab-org/gitlab/-/issues/31519)). Editing
`KUBE_NAMESPACE` directly is discouraged.
If you [install applications](#installing-applications) on your cluster, GitLab creates
the resources required to run them, even if you choose to manage your own cluster.
### Clearing the cluster cache
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/31759) in GitLab 12.6.
......@@ -100,7 +96,7 @@ per [multiple Kubernetes clusters](#multiple-kubernetes-clusters) When specifyin
this is automatically set as an environment variable (`KUBE_INGRESS_BASE_DOMAIN`) during
the [Auto DevOps](../../../topics/autodevops/index.md) stages.
The domain should have a wildcard DNS configured to the Ingress IP address.
The domain should have a wildcard DNS configured to the Ingress IP address. [More details](../../project/clusters/index.md#base-domain).
## Environment scopes **(PREMIUM)**
......
......@@ -91,7 +91,7 @@ Here's an example setup flow from scratch:
1. Prepare an [Auto DevOps-enabled](../../topics/autodevops/index.md) project.
1. Set up a [Kubernetes Cluster](../../user/project/clusters/index.md) in your project.
1. Install [Ingress](../../user/clusters/applications.md#ingress) as a GitLab Managed App.
1. Install [NGINX Ingress](https://github.com/kubernetes/ingress-nginx/tree/master/charts/ingress-nginx) in your cluster.
1. Set up [the base domain](../../user/project/clusters/index.md#base-domain) based on the Ingress
Endpoint assigned above.
1. Check if [`v2.0.0+` of `auto-deploy-image` is used in your Auto DevOps pipelines](../../topics/autodevops/upgrading_auto_deploy_dependencies.md#verify-dependency-versions).
......
......@@ -184,8 +184,7 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
See the [Managed clusters section](index.md#gitlab-managed-clusters) for more information.
1. Finally, click the **Create Kubernetes cluster** button.
After about 10 minutes, your cluster is ready to go. You can now proceed
to install some [pre-defined applications](index.md#installing-applications).
After about 10 minutes, your cluster is ready to go.
NOTE:
If you have [installed and configured](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html#get-started-kubectl) `kubectl` and you would like to manage your cluster with it, you must add your AWS external ID in the AWS configuration. For more information on how to configure AWS CLI, see [using an IAM role in the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html#cli-configure-role-xaccount).
......
......@@ -70,8 +70,7 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
See the [Managed clusters section](index.md#gitlab-managed-clusters) for more information.
1. Finally, click the **Create Kubernetes cluster** button.
After a couple of minutes, your cluster is ready. You can now proceed
to install some [pre-defined applications](index.md#installing-applications).
After a couple of minutes, your cluster is ready.
### Cloud Run for Anthos
......@@ -79,8 +78,8 @@ to install some [pre-defined applications](index.md#installing-applications).
You can choose to use Cloud Run for Anthos in place of installing Knative and Istio
separately after the cluster has been created. This means that Cloud Run
(Knative), Istio, and HTTP Load Balancing are enabled on the cluster at
create time and cannot be [installed or uninstalled](../../clusters/applications.md) separately.
(Knative), Istio, and HTTP Load Balancing are enabled on the cluster
from the start, and cannot be installed or uninstalled.
## Existing GKE cluster
......
......@@ -61,16 +61,10 @@ When creating a cluster in GitLab, you are asked if you would like to create eit
cluster, which is the GitLab default and recommended option.
- An [Attribute-based access control (ABAC)](https://kubernetes.io/docs/reference/access-authn-authz/abac/) cluster.
GitLab creates the necessary service accounts and privileges to install and run
[GitLab managed applications](index.md#installing-applications). When GitLab creates the cluster,
When GitLab creates the cluster,
a `gitlab` service account with `cluster-admin` privileges is created in the `default` namespace
to manage the newly created cluster.
The first time you install an application into your cluster, the `tiller` service
account is created with `cluster-admin` privileges in the
`gitlab-managed-apps` namespace. This service account is used by Helm to
install and run [GitLab managed applications](index.md#installing-applications).
Helm also creates additional service accounts and other resources for each
installed application. Consult the documentation of the Helm charts for each application
for details.
......@@ -141,11 +135,8 @@ If you don't want to use a runner in privileged mode, either:
- Use shared runners on GitLab.com. They don't have this security issue.
- Set up your own runners using the configuration described at
[shared runners](../../gitlab_com/index.md#shared-runners). This involves:
1. Making sure that you don't have it installed via
[the applications](index.md#installing-applications).
1. Installing a runner
[using `docker+machine`](https://docs.gitlab.com/runner/executors/docker_machine.html).
[shared runners](../../gitlab_com/index.md#shared-runners) using
[`docker+machine`](https://docs.gitlab.com/runner/executors/docker_machine.html).
## Create new cluster
......@@ -162,20 +153,20 @@ Amazon Elastic Kubernetes Service (EKS) at the project, group, or instance level
- [Amazon EKS](add_eks_clusters.md#new-eks-cluster).
- [Google GKE](add_gke_clusters.md#creating-the-cluster-on-gke).
After creating a cluster, you can install runners for it as described in
[GitLab Managed Apps](../../clusters/applications.md).
After creating a cluster, you can [install runners](https://docs.gitlab.com/runner/install/kubernetes.html),
add a [cluster management project](../../clusters/management_project.md),
configure [Auto DevOps](../../../topics/autodevops/index.md),
or start [deploying right away](index.md#deploying-to-a-kubernetes-cluster).
## Add existing cluster
If you have an existing Kubernetes cluster, you can add it to a project, group,
or instance.
Kubernetes integration isn't supported for arm64 clusters. See the issue
[Helm Tiller fails to install on arm64 cluster](https://gitlab.com/gitlab-org/gitlab/-/issues/29838)
for details.
or instance, and [install runners](https://docs.gitlab.com/runner/install/kubernetes.html)
on it (the cluster does not need to be added to GitLab first).
After adding an existing cluster, you can install runners for it as described in
[GitLab Managed Apps](../../clusters/applications.md).
After adding a cluster, you can add a [cluster management project](../../clusters/management_project.md),
configure [Auto DevOps](../../../topics/autodevops/index.md),
or start [deploying right away](index.md#deploying-to-a-kubernetes-cluster).
### Existing Kubernetes cluster
......@@ -325,8 +316,7 @@ To add a Kubernetes cluster to your project, group, or instance:
1. Finally, click the **Create Kubernetes cluster** button.
After a couple of minutes, your cluster is ready. You can now proceed
to install some [pre-defined applications](index.md#installing-applications).
After a couple of minutes, your cluster is ready.
#### Disable Role-Based Access Control (RBAC) (optional)
......
......@@ -172,14 +172,9 @@ for your deployment jobs to use. Otherwise, a namespace is created for you.
#### Important notes
Note the following with GitLab and clusters:
- If you [install applications](#installing-applications) on your cluster, GitLab will
create the resources required to run these even if you have chosen to manage your own
cluster.
- Be aware that manually managing resources that have been created by GitLab, like
namespaces and service accounts, can cause unexpected errors. If this occurs, try
[clearing the cluster cache](#clearing-the-cluster-cache).
Be aware that manually managing resources that have been created by GitLab, like
namespaces and service accounts, can cause unexpected errors. If this occurs, try
[clearing the cluster cache](#clearing-the-cluster-cache).
#### Clearing the cluster cache
......@@ -200,19 +195,15 @@ To clear the cache:
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24580) in GitLab 11.8.
You do not need to specify a base domain on cluster settings when using GitLab Serverless. The domain in that case
is specified as part of the Knative installation. See [Installing Applications](#installing-applications).
Specifying a base domain automatically sets `KUBE_INGRESS_BASE_DOMAIN` as an deployment variable.
If you are using [Auto DevOps](../../../topics/autodevops/index.md), this domain is used for the different
stages. For example, Auto Review Apps and Auto Deploy.
The domain should have a wildcard DNS configured to the Ingress IP address.
After Ingress has been installed (see [Installing Applications](#installing-applications)),
you can either:
You can either:
- Create an `A` record that points to the Ingress IP address with your domain provider.
- Enter a wildcard DNS address using a service such as nip.io or xip.io. For example, `192.168.1.1.xip.io`.
- Enter a wildcard DNS address using a service such as `nip.io` or `xip.io`. For example, `192.168.1.1.xip.io`.
To determine the external Ingress IP address, or external Ingress hostname:
......@@ -262,13 +253,11 @@ This list provides a generic solution, and some GitLab-specific approaches:
If you see a trailing `%` on some Kubernetes versions, do not include it.
## Installing applications
## Cluster management project
GitLab can install and manage some applications like Helm, GitLab Runner, Ingress,
Prometheus, and so on, in your project-level cluster. For more information on
installing, upgrading, uninstalling, and troubleshooting applications for
your project cluster, see
[GitLab Managed Apps](../../clusters/applications.md).
Attach a [Cluster management project](../../clusters/management_project.md)
to your cluster to manage shared resources requiring `cluster-admin` privileges for
installation, such as an Ingress controller.
## Auto DevOps
......@@ -457,6 +446,6 @@ Automatically detect and monitor Kubernetes metrics. Automatic monitoring of
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/4701) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.6.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/208224) to GitLab Free in 13.2.
When [Prometheus is deployed](#installing-applications), GitLab monitors the cluster's health. At the top of the cluster settings page, CPU and Memory utilization is displayed, along with the total amount available. Keeping an eye on cluster resources can be important, if the cluster runs out of memory pods may be shutdown or fail to start.
When [the Prometheus cluster integration is enabled](../../clusters/integrations.md#prometheus-cluster-integration), GitLab monitors the cluster's health. At the top of the cluster settings page, CPU and Memory utilization is displayed, along with the total amount available. Keeping an eye on cluster resources can be important, if the cluster runs out of memory pods may be shutdown or fail to start.
![Cluster Monitoring](img/k8s_cluster_monitoring.png)
......@@ -81,7 +81,7 @@ Support for historical data is coming
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/197879) in GitLab 12.8.
When you enable [Elastic Stack](../../clusters/applications.md#elastic-stack)
When you enable [Elastic Stack](../../clusters/integrations.md#elastic-stack-cluster-integration)
on your cluster, you can filter logs displayed in the **Log Explorer** by date.
Click **Show last** in the **Log Explorer** to see the available options.
......@@ -90,7 +90,7 @@ Click **Show last** in the **Log Explorer** to see the available options.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/21656) in GitLab 12.7.
When you enable [Elastic Stack](../../clusters/applications.md#elastic-stack) on your cluster,
When you enable [Elastic Stack](../../clusters/integrations.md#elastic-stack-cluster-integration) on your cluster,
you can search the content of your logs through a search bar. The search is passed
to Elasticsearch using the
[simple_query_string](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-simple-query-string-query.html)
......
......@@ -63,18 +63,93 @@ information.
Follow this step-by-step guide to configure an executable runbook in GitLab using
the components outlined above and the pre-loaded demo runbook.
1. Add a Kubernetes cluster to your project by following the steps outlined in
[Create new cluster](../add_remove_clusters.md#create-new-cluster).
1. Click the **Install** button next to the **Ingress** application to install Ingress.
![install ingress](img/ingress-install.png)
1. After Ingress has been installed successfully, click the **Install** button next
to the **JupyterHub** application. You need the **Jupyter Hostname** provided
here in the next step.
![install JupyterHub](img/jupyterhub-install.png)
1. Create an [OAuth Application for JupyterHub](../../../../integration/oauth_provider.md#gitlab-as-oauth2-authentication-service-provider).
1. When [installing JupyterHub with Helm](https://zero-to-jupyterhub.readthedocs.io/en/latest/jupyterhub/installation.html), use the following values
```yaml
#-----------------------------------------------------------------------------
# The gitlab and ingress sections must be customized!
#-----------------------------------------------------------------------------
gitlab:
clientId: <Your OAuth Application ID>
clientSecret: <Your OAuth Application Secret>
callbackUrl: http://<Jupyter Hostname>/hub/oauth_callback,
# Limit access to members of specific projects or groups:
# allowedGitlabGroups: [ "my-group-1", "my-group-2" ]
# allowedProjectIds: [ 12345, 6789 ]
# ingress is required for OAuth to work
ingress:
enabled: true
host: <JupyterHostname>
# tls:
# - hosts:
# - <JupyterHostanme>
# secretName: jupyter-cert
# annotations:
# kubernetes.io/ingress.class: "nginx"
# kubernetes.io/tls-acme: "true"
#-----------------------------------------------------------------------------
# NO MODIFICATIONS REQUIRED BEYOND THIS POINT
#-----------------------------------------------------------------------------
hub:
extraEnv:
JUPYTER_ENABLE_LAB: 1
extraConfig: |
c.KubeSpawner.cmd = ['jupyter-labhub']
c.GitLabOAuthenticator.scope = ['api read_repository write_repository']
async def add_auth_env(spawner):
'''
We set user's id, login and access token on single user image to
enable repository integration for JupyterHub.
See: https://gitlab.com/gitlab-org/gitlab-foss/issues/47138#note_154294790
'''
auth_state = await spawner.user.get_auth_state()
if not auth_state:
spawner.log.warning("No auth state for %s", spawner.user)
return
spawner.environment['GITLAB_ACCESS_TOKEN'] = auth_state['access_token']
spawner.environment['GITLAB_USER_LOGIN'] = auth_state['gitlab_user']['username']
spawner.environment['GITLAB_USER_ID'] = str(auth_state['gitlab_user']['id'])
spawner.environment['GITLAB_USER_EMAIL'] = auth_state['gitlab_user']['email']
spawner.environment['GITLAB_USER_NAME'] = auth_state['gitlab_user']['name']
c.KubeSpawner.pre_spawn_hook = add_auth_env
auth:
type: gitlab
state:
enabled: true
singleuser:
defaultUrl: "/lab"
image:
name: registry.gitlab.com/gitlab-org/jupyterhub-user-image
tag: latest
lifecycleHooks:
postStart:
exec:
command:
- "sh"
- "-c"
- >
git clone https://gitlab.com/gitlab-org/nurtch-demo.git DevOps-Runbook-Demo || true;
echo "https://oauth2:${GITLAB_ACCESS_TOKEN}@${GITLAB_HOST}" > ~/.git-credentials;
git config --global credential.helper store;
git config --global user.email "${GITLAB_USER_EMAIL}";
git config --global user.name "${GITLAB_USER_NAME}";
jupyter serverextension enable --py jupyterlab_git
proxy:
service:
type: ClusterIP
```
1. After JupyterHub has been installed successfully, open the **Jupyter Hostname**
in your browser. Click the **Sign in with GitLab** button to log in to
......
......@@ -53,7 +53,7 @@ To run Knative on GitLab, you need:
The set of minimum recommended cluster specifications to run Knative is 3 nodes, 6 vCPUs, and 22.50 GB memory.
1. **GitLab Runner:** A runner is required to run the CI jobs that deploy serverless
applications or functions onto your cluster. You can install GitLab Runner
onto the existing Kubernetes cluster. See [Installing Applications](../index.md#installing-applications) for more information.
onto the [existing Kubernetes cluster](https://docs.gitlab.com/runner/install/kubernetes.html).
1. **Domain Name:** Knative provides its own load balancer using Istio, and an
external IP address or hostname for all the applications served by Knative. Enter a
wildcard domain to serve your applications. Configure your DNS server to use the
......@@ -68,54 +68,18 @@ To run Knative on GitLab, you need:
`Dockerfile` in order to build your applications. It should be included at the root of your
project's repository and expose port `8080`. `Dockerfile` is not require if you plan to build serverless functions
using our [runtimes](https://gitlab.com/gitlab-org/serverless/runtimes).
1. **Prometheus** (optional): Installing Prometheus allows you to monitor the scale and traffic of your serverless function/application.
See [Installing Applications](../index.md#installing-applications) for more information.
1. **Prometheus** (optional): The [Prometheus cluster integration](../../../clusters/integrations.md#prometheus-cluster-integration)
allows you to monitor the scale and traffic of your serverless function/application.
1. **Logging** (optional): Configuring logging allows you to view and search request logs for your serverless function/application.
See [Configuring logging](#configuring-logging) for more information.
## Installing Knative via the GitLab Kubernetes integration
The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22.50 GB
memory. **RBAC must be enabled.**
1. [Add a Kubernetes cluster](../add_remove_clusters.md).
1. Select the **Applications** tab and scroll down to the Knative app section. Enter the domain to be used with
your application/functions (e.g. `example.com`) and click **Install**.
![install-knative](img/install-knative.png)
1. After the Knative installation has finished, you can wait for the IP address or hostname to be displayed in the
**Knative Endpoint** field or [retrieve the Istio Ingress Endpoint manually](../../../clusters/applications.md#determining-the-external-endpoint-manually).
NOTE:
Running `kubectl` commands on your cluster requires setting up access to the cluster first.
For clusters created on GKE, see [GKE Cluster Access](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl),
for other platforms [Install kubectl](https://kubernetes.io/docs/tasks/tools/).
1. The Ingress is now available at this address and routes incoming requests to the proper service based on the DNS
name in the request. To support this, a wildcard DNS record should be created for the desired domain name. For example,
if your Knative base domain is `knative.info` then you need to create an A record or CNAME record with domain `*.knative.info`
pointing the IP address or hostname of the Ingress.
![DNS entry](img/dns-entry.png)
You can deploy either [functions](#deploying-functions) or [serverless applications](#deploying-serverless-applications)
on a given project, but not both. The current implementation makes use of a
`serverless.yml` file to signal a FaaS project.
## Using an existing installation of Knative
## Configuring Knative
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/58941) in GitLab 12.0.
The _invocations_ monitoring feature of GitLab serverless is unavailable when
adding an existing installation of Knative.
It's also possible to use GitLab Serverless with an existing Kubernetes cluster
which already has Knative installed. You must do the following:
1. Follow the steps to
[add an existing Kubernetes
cluster](../add_remove_clusters.md#add-existing-cluster).
[add a Kubernetes
cluster](../add_remove_clusters.md).
1. Ensure GitLab can manage Knative:
- For a non-GitLab managed cluster, ensure that the service account for the token
......@@ -164,13 +128,17 @@ which already has Knative installed. You must do the following:
kubectl apply -f knative-serving-only-role.yaml
```
If you would rather grant permissions on a per service account basis, you can do this
using a `Role` and `RoleBinding` specific to the service account and namespace.
Alternatively, permissions can be granted on a per-service account basis
using `Role`s and `RoleBinding`s (see the [Kubernetes RBAC
documentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
for more information).
1. Follow the steps to deploy [functions](#deploying-functions)
or [serverless applications](#deploying-serverless-applications) onto your
cluster.
1. **Optional:** For invocation metrics to show in GitLab, additional Istio metrics need to be configured in your cluster. For example, with Knative v0.9.0, you can use [this manifest](https://gitlab.com/gitlab-org/charts/knative/-/raw/v0.10.0/vendor/istio-metrics.yml).
## Supported runtimes
Serverless functions for GitLab can be run using:
......@@ -183,7 +151,7 @@ If a runtime is not available for the required programming language, consider de
### GitLab-managed runtimes
Currently the following GitLab-managed [runtimes](https://gitlab.com/gitlab-org/serverless/runtimes)
The following GitLab-managed [runtimes](https://gitlab.com/gitlab-org/serverless/runtimes)
are available:
- `go` (proof of concept)
......@@ -499,10 +467,10 @@ rows to bring up the function details page.
The pod count gives you the number of pods running the serverless function instances on a given cluster.
For the Knative function invocations to appear,
[Prometheus must be installed](../index.md#installing-applications).
For the Knative function invocations to appear, the
[Prometheus cluster integration must be enabled](../../../clusters/integrations.md#prometheus-cluster-integration).
Once Prometheus is installed, a message may appear indicating that the metrics data _is
Once Prometheus is enabled, a message may appear indicating that the metrics data _is
loading or is not available at this time._ It appears upon the first access of the
page, but should go away after a few seconds. If the message does not disappear, then it
is possible that GitLab is unable to connect to the Prometheus instance running on the
......
......@@ -73,10 +73,6 @@ CPU and Memory consumption is monitored, but requires
to determine the environment. If you are using
[Auto DevOps](../../../topics/autodevops/index.md), this is handled automatically.
The [NGINX Ingress](../clusters/index.md#installing-applications) that is deployed
by GitLab to clusters, is automatically annotated for monitoring providing key
response metrics: latency, throughput, and error rates.
##### Example of Kubernetes service annotations and labels
As an example, to activate Prometheus monitoring of a service:
......
......@@ -27,28 +27,6 @@ NGINX Ingress versions prior to 0.16.0 offer an included [VTS Prometheus metrics
## Configuring NGINX Ingress monitoring
If you have deployed NGINX Ingress using the GitLab [Kubernetes cluster integration](../../clusters/index.md#installing-applications), Prometheus [automatically monitors it](#about-managed-nginx-ingress-deployments).
For other deployments, there is [some configuration](#manually-setting-up-nginx-ingress-for-prometheus-monitoring) required depending on your installation:
- NGINX Ingress should be version 0.16.0 or above, with metrics enabled.
- NGINX Ingress should be annotated for Prometheus monitoring.
- Prometheus should be configured to monitor annotated pods.
### About managed NGINX Ingress deployments
NGINX Ingress is deployed into the `gitlab-managed-apps` namespace, using the [official Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress). NGINX Ingress is [externally reachable via the Load Balancer's Endpoint](../../../clusters/applications.md#ingress).
NGINX is configured for Prometheus monitoring, by setting:
- `enable-vts-status: "true"`, to export Prometheus metrics.
- `prometheus.io/scrape: "true"`, to enable automatic discovery.
- `prometheus.io/port: "10254"`, to specify the metrics port.
When used in conjunction with the GitLab deployed Prometheus service, response metrics are automatically collected.
### Manually setting up NGINX Ingress for Prometheus monitoring
Version 0.9.0 and above of [NGINX Ingress](https://github.com/kubernetes/ingress-nginx) have built-in support for exporting Prometheus metrics. To enable, a ConfigMap setting must be passed: `enable-vts-status: "true"`. Once enabled, a Prometheus metrics endpoint starts running on port 10254.
Next, the Ingress needs to be annotated for Prometheus monitoring. Two new annotations need to be added:
......
......@@ -27,28 +27,6 @@ GitLab has support for automatically detecting and monitoring the Kubernetes NGI
## Configuring NGINX Ingress monitoring
If you have deployed NGINX Ingress using the GitLab [Kubernetes cluster integration](../../clusters/index.md#installing-applications), Prometheus [automatically monitors](#about-managed-nginx-ingress-deployments) it.
For other deployments, there is [some configuration](#manually-setting-up-nginx-ingress-for-prometheus-monitoring) required depending on your installation:
- NGINX Ingress should be version 0.9.0 or above, with metrics enabled.
- NGINX Ingress should be annotated for Prometheus monitoring.
- Prometheus should be configured to monitor annotated pods.
### About managed NGINX Ingress deployments
NGINX Ingress is deployed into the `gitlab-managed-apps` namespace, using the [official Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress). NGINX Ingress is [externally reachable via the Load Balancer's Endpoint](../../../clusters/applications.md#ingress).
NGINX is configured for Prometheus monitoring, by setting:
- `enable-vts-status: "true"`, to export Prometheus metrics.
- `prometheus.io/scrape: "true"`, to enable automatic discovery.
- `prometheus.io/port: "10254"`, to specify the metrics port.
When used in conjunction with the GitLab deployed Prometheus service, response metrics are automatically collected.
### Manually setting up NGINX Ingress for Prometheus monitoring
Version 0.9.0 and above of [NGINX Ingress](https://github.com/kubernetes/ingress-nginx) has built-in support for exporting Prometheus metrics. To enable, a ConfigMap setting must be passed: `enable-vts-status: "true"`. Once enabled, a Prometheus metrics endpoint begins running on port 10254.
Next, the Ingress needs to be annotated for Prometheus monitoring. Two new annotations need to be added:
......
......@@ -20,10 +20,9 @@ rendered to HTML when viewed:
Interactive features, including JavaScript plots, don't work when viewed in
GitLab.
## Jupyter Hub as a GitLab Managed App
You can deploy [Jupyter Hub as a GitLab managed app](../../../clusters/applications.md#jupyterhub).
## Jupyter Git integration
Find out how to [leverage JupyterLab's Git extension on your Kubernetes cluster](../../../clusters/applications.md#jupyter-git-integration).
Jupyter can be configured as an OAuth application with repository access, acting
on behalf of the authenticated user. See the
[Runbooks documentation](../../../project/clusters/runbooks/index.md) for an
example configuration.
......@@ -26396,21 +26396,18 @@ msgstr ""
msgid "PrometheusService|Active"
msgstr ""
msgid "PrometheusService|Auto configuration"
msgstr ""
msgid "PrometheusService|Auto configuration settings are used unless you override their values here."
msgstr ""
msgid "PrometheusService|Automatically deploy and configure Prometheus on your clusters to monitor your project’s environments."
msgstr ""
msgid "PrometheusService|Common metrics"
msgstr ""
msgid "PrometheusService|Common metrics are automatically monitored based on a library of metrics from popular exporters."
msgstr ""
msgid "PrometheusService|Configure GitLab to query a Prometheus installed in one of your clusters."
msgstr ""
msgid "PrometheusService|Custom metrics"
msgstr ""
......@@ -26426,18 +26423,9 @@ msgstr ""
msgid "PrometheusService|Finding custom metrics..."
msgstr ""
msgid "PrometheusService|GitLab is managing Prometheus on your clusters."
msgstr ""
msgid "PrometheusService|GitLab manages Prometheus on your clusters."
msgstr ""
msgid "PrometheusService|IAP_CLIENT_ID.apps.googleusercontent.com"
msgstr ""
msgid "PrometheusService|Install Prometheus on clusters"
msgstr ""
msgid "PrometheusService|Manage clusters"
msgstr ""
......@@ -26453,9 +26441,6 @@ msgstr ""
msgid "PrometheusService|Monitor application health with Prometheus metrics and dashboards"
msgstr ""
msgid "PrometheusService|Monitor your project’s environments by deploying and configuring Prometheus on your clusters."
msgstr ""
msgid "PrometheusService|More information"
msgstr ""
......@@ -26468,6 +26453,9 @@ msgstr ""
msgid "PrometheusService|No custom metrics have been created. Create one using the button above"
msgstr ""
msgid "PrometheusService|Prometheus cluster integration"
msgstr ""
msgid "PrometheusService|PrometheusService|The ID of the IAP-secured resource."
msgstr ""
......@@ -26483,7 +26471,7 @@ msgstr ""
msgid "PrometheusService|These metrics will only be monitored after your first deployment to an environment"
msgstr ""
msgid "PrometheusService|To enable the installation of Prometheus on your clusters, deactivate the manual configuration."
msgid "PrometheusService|To use a Prometheus installed on a cluster, deactivate the manual configuration."
msgstr ""
msgid "PrometheusService|Waiting for your first deployment to an environment to find common metrics"
......@@ -26492,6 +26480,9 @@ msgstr ""
msgid "PrometheusService|You can now manage your Prometheus settings on the %{operations_link_start}Operations%{operations_link_end} page. Fields on this page has been deprecated."
msgstr ""
msgid "PrometheusService|You have a cluster with the Prometheus integration enabled."
msgstr ""
msgid "PrometheusService|https://prometheus.example.com/"
msgstr ""
......@@ -29633,10 +29624,10 @@ msgstr ""
msgid "Serverless platform"
msgstr ""
msgid "ServerlessDetails|Function invocation metrics require Prometheus to be installed first."
msgid "ServerlessDetails|Configure cluster."
msgstr ""
msgid "ServerlessDetails|Install Prometheus"
msgid "ServerlessDetails|Function invocation metrics require the Prometheus cluster integration."
msgstr ""
msgid "ServerlessDetails|Invocation metrics loading or not available at this time."
......@@ -29678,9 +29669,6 @@ msgstr ""
msgid "Serverless|In order to start using functions as a service, you must first install Knative on your Kubernetes cluster. %{linkStart}More information%{linkEnd}"
msgstr ""
msgid "Serverless|Install Knative"
msgstr ""
msgid "Serverless|Learn more about Serverless"
msgstr ""
......
......@@ -25,7 +25,6 @@ RSpec.describe 'Functions', :js do
end
it 'sees an empty state require Knative installation' do
expect(page).to have_link('Install Knative')
expect(page).to have_selector('.empty-state')
end
end
......
......@@ -11,7 +11,7 @@ exports[`EmptyStateComponent should render content 1`] = `
<p>In order to start using functions as a service, you must first install Knative on your Kubernetes cluster. <gl-link-stub href=\\"/help\\">More information</gl-link-stub>
</p>
<div class=\\"gl-display-flex gl-flex-wrap gl-justify-content-center\\">
<gl-button-stub category=\\"primary\\" variant=\\"confirm\\" size=\\"medium\\" icon=\\"\\" buttontextclasses=\\"\\" href=\\"/clusters\\" class=\\"gl-mb-3 gl-mx-2\\">Install Knative</gl-button-stub>
<!---->
<!---->
</div>
</div>
......
......@@ -21,7 +21,7 @@ describe('missingPrometheusComponent', () => {
const { vm } = wrapper;
expect(vm.$el.querySelector('.state-description').innerHTML.trim()).toContain(
'Function invocation metrics require Prometheus to be installed first.',
'Function invocation metrics require the Prometheus cluster integration.',
);
expect(wrapper.find(GlButton).attributes('variant')).toBe('success');
......
......@@ -192,7 +192,7 @@ RSpec.describe EnvironmentsHelper do
"environment_name": environment.name,
"environments_path": api_v4_projects_environments_path(id: project.id),
"environment_id": environment.id,
"cluster_applications_documentation_path" => help_page_path('user/clusters/applications.md', anchor: 'elastic-stack'),
"cluster_applications_documentation_path" => help_page_path('user/clusters/integrations.md', anchor: 'elastic-stack-cluster-integration'),
"clusters_path": project_clusters_path(project, format: :json)
}
......
......@@ -59,7 +59,7 @@ RSpec.describe 'projects/settings/operations/show' do
expect(rendered).to have_content _('Prometheus')
expect(rendered).to have_content _('Link Prometheus monitoring to GitLab.')
expect(rendered).to have_content _('To enable the installation of Prometheus on your clusters, deactivate the manual configuration.')
expect(rendered).to have_content _('To use a Prometheus installed on a cluster, deactivate the manual configuration.')
end
end
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment