Add latest changes from gitlab-org/gitlab@master

7 files changed, 45 insertions, 92 deletions

diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md
index e5b36f97fa2..defc74b7e9e 100644
--- a/doc/administration/reference_architectures/10k_users.md
+++ b/doc/administration/reference_architectures/10k_users.md
@@ -168,6 +168,8 @@ If this applies to you, we strongly recommended referring to the linked document
 Testing is done regularly via our [GitLab Performance Tool (GPT)](https://gitlab.com/gitlab-org/quality/performance) and its dataset, which is available for anyone to use.
 The results of this testing are [available publicly on the GPT wiki](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest). For more information on our testing strategy [refer to this section of the documentation](index.md#validation-and-test-results).
 
+The load balancers used for testing were HAProxy for Linux package environments or equivalent Cloud Provider services via NGINX Ingress for Cloud Native Hybrids. Note that these selections do not represent a specific requirement or recommendation as most [reputable load balancers are expected to work](#configure-the-external-load-balancer).
+
 ## Setup components
 
 To set up GitLab and its components to accommodate up to 10,000 users:
@@ -234,16 +236,12 @@ The following list includes descriptions of each server and its assigned IP:
 ## Configure the external load balancer
 
 In a multi-node GitLab configuration, you'll need a load balancer to route
-traffic to the application servers. The specifics on which load balancer to use
-or its exact configuration is beyond the scope of GitLab documentation. We assume
-that if you're managing multi-node systems like GitLab, you already have a load
-balancer of choice. Some load balancer examples include HAProxy (open-source),
-F5 Big-IP LTM, and Citrix Net Scaler. This documentation outline the ports and
-protocols needed for use with GitLab.
-
-This architecture has been tested and validated with [HAProxy](https://www.haproxy.org/)
-as the load balancer. Although other load balancers with similar feature sets
-could also be used, those load balancers have not been validated.
+traffic to the application servers.
+
+The specifics on which load balancer to use, or its exact configuration
+is beyond the scope of GitLab documentation. It is expected however that any
+reputable load balancer should work and as such this section will focus on the specifics of
+what to configure for your load balancer of choice.
 
 ### Balancing algorithm
 
diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md
index 4235edea58c..6520f63957b 100644
--- a/doc/administration/reference_architectures/25k_users.md
+++ b/doc/administration/reference_architectures/25k_users.md
@@ -168,6 +168,8 @@ If this applies to you, we strongly recommended referring to the linked document
 Testing is done regularly via our [GitLab Performance Tool (GPT)](https://gitlab.com/gitlab-org/quality/performance) and its dataset, which is available for anyone to use.
 The results of this testing are [available publicly on the GPT wiki](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest). For more information on our testing strategy [refer to this section of the documentation](index.md#validation-and-test-results).
 
+The load balancers used for testing were HAProxy for Linux package environments or equivalent Cloud Provider services via NGINX Ingress for Cloud Native Hybrids. Note that these selections do not represent a specific requirement or recommendation as most [reputable load balancers are expected to work](#configure-the-external-load-balancer).
+
 ## Setup components
 
 To set up GitLab and its components to accommodate up to 25,000 users:
@@ -236,25 +238,12 @@ The following list includes descriptions of each server and its assigned IP:
 ## Configure the external load balancer
 
 In a multi-node GitLab configuration, you'll need a load balancer to route
-traffic to the application servers. The specifics on which load balancer to use
-or its exact configuration is beyond the scope of GitLab documentation. We assume
-that if you're managing multi-node systems like GitLab, you already have a load
-balancer of choice. Some load balancer examples include HAProxy (open-source),
-F5 Big-IP LTM, and Citrix Net Scaler. This documentation outline the ports and
-protocols needed for use with GitLab.
-
-This architecture has been tested and validated with [HAProxy](https://www.haproxy.org/)
-as the load balancer. Although other load balancers with similar feature sets
-could also be used, those load balancers have not been validated.
-
-The next question is how you will handle SSL in your environment.
-There are several different options:
+traffic to the application servers.
 
-- [The application node terminates SSL](#application-node-terminates-ssl).
-- [The load balancer terminates SSL without backend SSL](#load-balancer-terminates-ssl-without-backend-ssl)
-  and communication is not secure between the load balancer and the application node.
-- [The load balancer terminates SSL with backend SSL](#load-balancer-terminates-ssl-with-backend-ssl)
-  and communication is *secure* between the load balancer and the application node.
+The specifics on which load balancer to use, or its exact configuration
+is beyond the scope of GitLab documentation. It is expected however that any
+reputable load balancer should work and as such this section will focus on the specifics of
+what to configure for your load balancer of choice.
 
 ### Balancing algorithm
 
diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md
index e14724fb5d8..d3f53ce3e14 100644
--- a/doc/administration/reference_architectures/2k_users.md
+++ b/doc/administration/reference_architectures/2k_users.md
@@ -101,6 +101,8 @@ If this applies to you, we strongly recommended referring to the linked document
 Testing is done regularly via our [GitLab Performance Tool (GPT)](https://gitlab.com/gitlab-org/quality/performance) and its dataset, which is available for anyone to use.
 The results of this testing are [available publicly on the GPT wiki](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest). For more information on our testing strategy [refer to this section of the documentation](index.md#validation-and-test-results).
 
+The load balancers used for testing were HAProxy for Linux package environments or equivalent Cloud Provider services via NGINX Ingress for Cloud Native Hybrids. Note that these selections do not represent a specific requirement or recommendation as most [reputable load balancers are expected to work](#configure-the-external-load-balancer).
+
 ## Setup components
 
 To set up GitLab and its components to accommodate up to 2,000 users:
@@ -124,25 +126,12 @@ To set up GitLab and its components to accommodate up to 2,000 users:
 ## Configure the external load balancer
 
 In a multi-node GitLab configuration, you'll need a load balancer to route
-traffic to the application servers. The specifics on which load balancer to use
-or its exact configuration is beyond the scope of GitLab documentation. We assume
-that if you're managing multi-node systems like GitLab, you already have a load
-balancer of choice. Some load balancer examples include HAProxy (open-source),
-F5 Big-IP LTM, and Citrix Net Scaler. This documentation outline the ports and
-protocols needed for use with GitLab.
-
-This architecture has been tested and validated with [HAProxy](https://www.haproxy.org/)
-as the load balancer. Although other load balancers with similar feature sets
-could also be used, those load balancers have not been validated.
+traffic to the application servers.
 
-The next question is how you will handle SSL in your environment. There are
-several different options:
-
-- [The application node terminates SSL](#application-node-terminates-ssl).
-- [The load balancer terminates SSL without backend SSL](#load-balancer-terminates-ssl-without-backend-ssl)
-  and communication is not secure between the load balancer and the application node.
-- [The load balancer terminates SSL with backend SSL](#load-balancer-terminates-ssl-with-backend-ssl)
-  and communication is *secure* between the load balancer and the application node.
+The specifics on which load balancer to use, or its exact configuration
+is beyond the scope of GitLab documentation. It is expected however that any
+reputable load balancer should work and as such this section will focus on the specifics of
+what to configure for your load balancer of choice.
 
 ### Balancing algorithm
 
diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md
index d298bb4fb11..c01564a3e7a 100644
--- a/doc/administration/reference_architectures/3k_users.md
+++ b/doc/administration/reference_architectures/3k_users.md
@@ -163,6 +163,8 @@ If this applies to you, we strongly recommended referring to the linked document
 Testing is done regularly via our [GitLab Performance Tool (GPT)](https://gitlab.com/gitlab-org/quality/performance) and its dataset, which is available for anyone to use.
 The results of this testing are [available publicly on the GPT wiki](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest). For more information on our testing strategy [refer to this section of the documentation](index.md#validation-and-test-results).
 
+The load balancers used for testing were HAProxy for Linux package environments or equivalent Cloud Provider services via NGINX Ingress for Cloud Native Hybrids. Note that these selections do not represent a specific requirement or recommendation as most [reputable load balancers are expected to work](#configure-the-external-load-balancer).
+
 ## Setup components
 
 To set up GitLab and its components to accommodate up to 3,000 users:
@@ -224,25 +226,12 @@ The following list includes descriptions of each server and its assigned IP:
 ## Configure the external load balancer
 
 In a multi-node GitLab configuration, you'll need a load balancer to route
-traffic to the application servers. The specifics on which load balancer to use
-or its exact configuration is beyond the scope of GitLab documentation. We assume
-that if you're managing multi-node systems like GitLab, you already have a load
-balancer of choice. Some load balancer examples include HAProxy (open-source),
-F5 Big-IP LTM, and Citrix Net Scaler. This documentation outline the ports and
-protocols needed for use with GitLab.
-
-This architecture has been tested and validated with [HAProxy](https://www.haproxy.org/)
-as the load balancer. Although other load balancers with similar feature sets
-could also be used, those load balancers have not been validated.
-
-The next question is how you will handle SSL in your environment.
-There are several different options:
+traffic to the application servers.
 
-- [The application node terminates SSL](#application-node-terminates-ssl).
-- [The load balancer terminates SSL without backend SSL](#load-balancer-terminates-ssl-without-backend-ssl)
-  and communication is not secure between the load balancer and the application node.
-- [The load balancer terminates SSL with backend SSL](#load-balancer-terminates-ssl-with-backend-ssl)
-  and communication is *secure* between the load balancer and the application node.
+The specifics on which load balancer to use, or its exact configuration
+is beyond the scope of GitLab documentation. It is expected however that any
+reputable load balancer should work and as such this section will focus on the specifics of
+what to configure for your load balancer of choice.
 
 ### Balancing algorithm
 
diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md
index 06c2138e639..92421a35273 100644
--- a/doc/administration/reference_architectures/50k_users.md
+++ b/doc/administration/reference_architectures/50k_users.md
@@ -168,6 +168,8 @@ If this applies to you, we strongly recommended referring to the linked document
 Testing is done regularly via our [GitLab Performance Tool (GPT)](https://gitlab.com/gitlab-org/quality/performance) and its dataset, which is available for anyone to use.
 The results of this testing are [available publicly on the GPT wiki](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest). For more information on our testing strategy [refer to this section of the documentation](index.md#validation-and-test-results).
 
+The load balancers used for testing were HAProxy for Linux package environments or equivalent Cloud Provider services via NGINX Ingress for Cloud Native Hybrids. Note that these selections do not represent a specific requirement or recommendation as most [reputable load balancers are expected to work](#configure-the-external-load-balancer).
+
 ## Setup components
 
 To set up GitLab and its components to accommodate up to 50,000 users:
@@ -243,16 +245,12 @@ The following list includes descriptions of each server and its assigned IP:
 ## Configure the external load balancer
 
 In a multi-node GitLab configuration, you'll need a load balancer to route
-traffic to the application servers. The specifics on which load balancer to use
-or its exact configuration is beyond the scope of GitLab documentation. We assume
-that if you're managing multi-node systems like GitLab, you already have a load
-balancer of choice. Some load balancer examples include HAProxy (open-source),
-F5 Big-IP LTM, and Citrix Net Scaler. This documentation outline the ports and
-protocols needed for use with GitLab.
-
-This architecture has been tested and validated with [HAProxy](https://www.haproxy.org/)
-as the load balancer. Although other load balancers with similar feature sets
-could also be used, those load balancers have not been validated.
+traffic to the application servers.
+
+The specifics on which load balancer to use, or its exact configuration
+is beyond the scope of GitLab documentation. It is expected however that any
+reputable load balancer should work and as such this section will focus on the specifics of
+what to configure for your load balancer of choice.
 
 ### Balancing algorithm
 
diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md
index 67f1342a71c..16a92944984 100644
--- a/doc/administration/reference_architectures/5k_users.md
+++ b/doc/administration/reference_architectures/5k_users.md
@@ -163,6 +163,8 @@ If this applies to you, we strongly recommended referring to the linked document
 Testing is done regularly via our [GitLab Performance Tool (GPT)](https://gitlab.com/gitlab-org/quality/performance) and its dataset, which is available for anyone to use.
 The results of this testing are [available publicly on the GPT wiki](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest). For more information on our testing strategy [refer to this section of the documentation](index.md#validation-and-test-results).
 
+The load balancers used for testing were HAProxy for Linux package environments or equivalent Cloud Provider services via NGINX Ingress for Cloud Native Hybrids. Note that these selections do not represent a specific requirement or recommendation as most [reputable load balancers are expected to work](#configure-the-external-load-balancer).
+
 ## Setup components
 
 To set up GitLab and its components to accommodate up to 5,000 users:
@@ -224,25 +226,12 @@ The following list includes descriptions of each server and its assigned IP:
 ## Configure the external load balancer
 
 In a multi-node GitLab configuration, you'll need a load balancer to route
-traffic to the application servers. The specifics on which load balancer to use
-or its exact configuration is beyond the scope of GitLab documentation. We assume
-that if you're managing multi-node systems like GitLab, you already have a load
-balancer of choice. Some load balancer examples include HAProxy (open-source),
-F5 Big-IP LTM, and Citrix Net Scaler. This documentation outline the ports and
-protocols needed for use with GitLab.
-
-This architecture has been tested and validated with [HAProxy](https://www.haproxy.org/)
-as the load balancer. Although other load balancers with similar feature sets
-could also be used, those load balancers have not been validated.
-
-The next question is how you handle SSL in your environment.
-There are several different options:
+traffic to the application servers.
 
-- [The application node terminates SSL](#application-node-terminates-ssl).
-- [The load balancer terminates SSL without backend SSL](#load-balancer-terminates-ssl-without-backend-ssl)
-  and communication is not secure between the load balancer and the application node.
-- [The load balancer terminates SSL with backend SSL](#load-balancer-terminates-ssl-with-backend-ssl)
-  and communication is *secure* between the load balancer and the application node.
+The specifics on which load balancer to use, or its exact configuration
+is beyond the scope of GitLab documentation. It is expected however that any
+reputable load balancer should work and as such this section will focus on the specifics of
+what to configure for your load balancer of choice.
 
 ### Balancing algorithm
 
diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md
index 0df4af89fe4..d6fdcbf7e04 100644
--- a/doc/administration/reference_architectures/index.md
+++ b/doc/administration/reference_architectures/index.md
@@ -720,6 +720,7 @@ You can find a full history of changes [on the GitLab project](https://gitlab.co
 
 **2023:**
 
+- [2023-12-12](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/133457): Updated notes on Load Balancers to be more reflective that any reputable offering is expected to work.
 - [2023-11-03](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/133457): Expanded details on what each Reference Architecture is designed for, the testing methodology used as well as added details on how to scale environments.
 - [2023-11-03](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/134518): Added expanded notes on disk types, object storage and monitoring.
 - [2023-10-25](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/134518): Adjusted Sidekiq configuration example to use Linux Package role.