• Requirements
• Configuration
• Global Settings
• Chart settings
  • General settings
  • Pages specific settings
  • Configuring the ingress
• Chart configuration examples
  • extraVolumes
  • extraVolumeMounts
  • Configuring the networkpolicy
  • Example Network Policy
  • TLS access to GitLab Pages
  • Pages domain without wildcard DNS
    • TLS access to GitLab Pages domain without wildcard DNS
    • Configure access control
  • Rate limits
    • Configure rate limits subnets allow list
  • Configuring KEDA
  • affinity

Using the GitLab Pages chart

The gitlab-pages subchart provides a daemon for serving static websites from GitLab projects.

Requirements

This chart depends on access to the Workhorse services, either as part of the complete GitLab chart or provided as an external service reachable from the Kubernetes cluster this chart is deployed onto.

Configuration

The gitlab-pages chart is configured as follows: Global settings and Chart settings.

Global Settings

We share some common global settings among our charts. See the Globals Documentation for details.

Chart settings

The tables in following two sections contains all the possible chart configurations that can be supplied to the helm install command using the --set flags.

General settings

Pages specific settings

Configuring the ingress

This section controls the GitLab Pages Ingress.

Chart configuration examples

extraVolumes

extraVolumes allows you to configure extra volumes chart-wide.

Below is an example use of extraVolumes:

extraVolumes: |
  - name: example-volume
    persistentVolumeClaim:
      claimName: example-pvc

extraVolumeMounts

extraVolumeMounts allows you to configure extra volumeMounts on all containers chart-wide.

Below is an example use of extraVolumeMounts:

extraVolumeMounts: |
  - name: example-volume
    mountPath: /etc/example

Configuring the networkpolicy

This section controls the NetworkPolicy. This configuration is optional and is used to limit Egress and Ingress of the Pods to specific endpoints.

Example Network Policy

The gitlab-pages service requires Ingress connections for port 80 and 443 and Egress connections to various to default workhorse port 8181. This examples adds the following network policy:

• All Ingress requests from the network on TCP 0.0.0.0/0 port 80 and 443 are allowed
• All Egress requests to the network on UDP 10.0.0.0/8 port 53 are allowed for DNS
• All Egress requests to the network on TCP 10.0.0.0/8 port 8181 are allowed for Workhorse

Note the example provided is only an example and may not be complete

networkpolicy:
  enabled: true
  ingress:
    enabled: true
    rules:
      - to:
        - ipBlock:
            cidr: 0.0.0.0/0
        ports:
          - port: 80
            protocol: TCP
          - port: 443
            protocol: TCP
  egress:
    enabled: true
    rules:
      - to:
        - ipBlock:
            cidr: 10.0.0.0/8
        ports:
          - port: 8181
            protocol: TCP
          - port: 53
            protocol: UDP

TLS access to GitLab Pages

To have TLS access to the GitLab Pages feature you must:

1. Create a dedicated wildcard certificate for your GitLab Pages domain in this format: *.pages.<yourdomain>.

2. Create the secret in Kubernetes:

   kubectl create secret tls tls-star-pages-<mysecret> --cert=<path/to/fullchain.pem> --key=<path/to/privkey.pem>
   

3. Configure GitLab Pages to use this secret:

   gitlab:
     gitlab-pages:
       ingress:
         tls:
           secretName: tls-star-pages-<mysecret>
   

4. Create a DNS entry in your DNS provider with the name *.pages.<yourdomaindomain> pointing to your LoadBalancer.

Pages domain without wildcard DNS

1. Enable namespaceInPath in the global Pages settings.

   global:
     pages:
       namespaceInPath: true
   

2. Create a DNS entry in your DNS provider with the name pages.<yourdomaindomain> pointing to your LoadBalancer.

TLS access to GitLab Pages domain without wildcard DNS

1. Create a certificate for your GitLab Pages domain in this format: pages.<yourdomain>.

2. Create the secret in Kubernetes:

   kubectl create secret tls tls-star-pages-<mysecret> --cert=<path/to/fullchain.pem> --key=<path/to/privkey.pem>
   

3. Configure GitLab Pages to use this secret:

   gitlab:
     gitlab-pages:
       ingress:
         tls:
           secretName: tls-star-pages-<mysecret>
   

Configure access control

1. Enable accessControl in the global pages settings.

   global:
     pages:
       accessControl: true
   

2. Optional. If TLS access is configured, update the redirect URI in the GitLab Pages System OAuth application to use the HTTPS protocol.

Rate limits

You can enforce rate limits to help minimize the risk of a Denial of Service (DoS) attack. Detailed rate limits documentation is available.

To allow certain IP ranges (subnets) to bypass all rate limits:

• rateLimitSubnetsAllowList: Sets the allow list with the IP ranges (subnets) that should bypass all rate limits.

Configure rate limits subnets allow list

Set the allow list with the IP ranges (subnets) in charts/gitlab/charts/gitlab-pages/values.yaml:

gitlab:
  gitlab-pages:
    rateLimitSubnetsAllowList:
     - "1.2.3.4/24"
     - "2001:db8::1/32"

Configuring KEDA

This keda section enables the installation of KEDA ScaledObjects instead of regular HorizontalPodAutoscalers. This configuration is optional and can be used when there is a need for autoscaling based on custom or external metrics.

Most settings default to the values set in the hpa section where applicable.

If the following are true, CPU and memory triggers are added automatically based on the CPU and memory thresholds set in the hpa section:

• triggers is not set.
• The corresponding request.cpu.request or request.memory.request setting is also set to a non-zero value.

If no triggers are set, the ScaledObject is not created.

Refer to the KEDA documentation for more details about those settings.

affinity

For more information, see affinity.