• Disable the agent server
  • Specify an Ingress
  • Installation command line options
• Enable TLS communication
• Enable TLS communication through the gitlab.kas.privateApi attributes (deprecated)
• Test the kas chart
• Configuring KEDA

Using the GitLab kas chart

The kas sub-chart provides a configurable deployment of the GitLab agent server (KAS). The agent server is a component you install together with GitLab. It is required to manage the GitLab agent for Kubernetes.

This chart depends on access to the GitLab API and the Gitaly Servers. When you enable this chart, an Ingress is deployed.

To consume minimal resources, the kas container uses a distroless image. The deployed services are exposed by an Ingress, which uses WebSocket proxying for communication. This proxy allows long-lived connections with the external component, agentk. agentk is the Kubernetes cluster-side agent counterpart.

The route to access the service depends on your Ingress configuration.

For more information, see the GitLab agent for Kubernetes architecture.

Disable the agent server

The GitLab agent server (kas) is enabled by default. To disable it on your GitLab instance, set the Helm property global.kas.enabled to false.

For example:

helm upgrade --install kas --set global.kas.enabled=false

Specify an Ingress

When you use the chart’s Ingress with the default configuration, the service for the agent server is reachable on a subdomain. For example, for global.hosts.domain: example.com, the agent server is reachable at kas.example.com.

The KAS Ingress can use a different domain than the global.hosts.domain.

Set global.hosts.kas.name, for example:

global.hosts.kas.name: kas.my-other-domain.com

This example uses kas.my-other-domain.com as the host for the KAS Ingress alone. The rest of the services (including GitLab, Registry, MinIO, etc.) use the domain specified in global.hosts.domain.

Installation command line options

You can pass these parameters to the helm install command by using the --set flags.

Enable TLS communication

Enable TLS communication between your kas pods and other GitLab chart components, through the global KAS attribute.

Enable TLS communication through the gitlab.kas.privateApi attributes (deprecated)

Prerequisites:

• Use GitLab 15.5.1 or later. You can set your GitLab version with global.gitlabVersion: <version>. If you need to force an image update after an initial deployment, also set global.image.pullPolicy: Always.

1. Create the certificate authority and certificates that your kas pods will trust.
2. Configure your chart to use the trusted certificates.
3. Optional. Configure Redis for TLS.

To configure kas to use the certificates you created, set the following values.

For example, you could use this values.yaml file to deploy your chart:

   .internal-ca: &internal-ca gitlab-internal-tls-ca # The secret name you used to share your TLS CA.
   .internal-tls: &internal-tls gitlab-internal-tls # The secret name you used to share your TLS certificate.

   global:
     certificates:
       customCAs:
       - secret: *internal-ca
     hosts:
       domain: gitlab.example.com # Your gitlab domain
     appConfig:
       gitlab_kas:
         internalUrl: "grpcs://RELEASE-kas.NAMESPACE.svc:8153" # Replace RELEASE and NAMESPACE with your chart's release and namespace

   gitlab:
     kas:
       privateApi:
         tls:
           enabled: true
           secretName: *internal-tls
       customConfig:
         api:
           listen:
             certificate_file: /etc/kas/tls.crt
             key_file: /etc/kas/tls.key
         agent:
           listen:
             certificate_file: /etc/kas/tls.crt
             key_file: /etc/kas/tls.key
           kubernetes_api:
             listen:
               certificate_file: /etc/kas/tls.crt
               key_file: /etc/kas/tls.key
       ingress:
         annotations:
           nginx.ingress.kubernetes.io/backend-protocol: https
           nginx.ingress.kubernetes.io/proxy-ssl-name: RELEASE-kas.NAMESPACE.svc # Replace RELEASE and NAMESPACE with your chart's release and namespace
           nginx.ingress.kubernetes.io/proxy-ssl-secret: NAMESPACE/CA-SECRET-NAME # Replace NAMESPACE and CA-SECRET-NAME with your chart's namespace and CA secret name. The same you used for &internal-ca.
           nginx.ingress.kubernetes.io/proxy-ssl-verify: on

Test the kas chart

To install the chart:

1. Create your own Kubernetes cluster.
2. Check out the merge request’s working branch.

3. Install (or upgrade) GitLab with kas enabled by default from your local chart branch:

   helm upgrade --force --install gitlab . \
     --timeout 600s \
     --set global.hosts.domain=your.domain.com \
     --set global.hosts.externalIP=XYZ.XYZ.XYZ.XYZ \
     --set certmanager-issuer.email=your@email.com
   

4. Use the GDK to run the process to configure and use the GitLab agent for Kubernetes: (You can also follow the steps to configure and use the agent manually.)

   1. From your GDK GitLab repository, move into the QA folder: cd qa.

   2. Run the following command to run the QA test:

      GITLAB_USERNAME=$ROOT_USER
      GITLAB_PASSWORD=$ROOT_PASSWORD
      GITLAB_ADMIN_USERNAME=$ROOT_USER
      GITLAB_ADMIN_PASSWORD=$ROOT_PASSWORD
      bundle exec bin/qa Test::Instance::All https://your.gitlab.domain/ -- --tag orchestrated --tag quarantine qa/specs/features/ee/api/7_configure/kubernetes/kubernetes_agent_spec.rb
      

      You can also customize the agentk version to install with an environment variable: GITLAB_AGENTK_VERSION=v13.7.1

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.