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, forglobal.hosts.domain:, the agent server is reachable at

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

Set, for example:

This example uses 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.

annotations{}Pod annotations.
common.labels{}Supplemental labels that are applied to all objects created by this chart.
extraContainers List of extra containers to include. repository.
image.tagv13.7.0Image tag.
hpa.behavior{scaleDown: {stabilizationWindowSeconds: 300 }}Behavior contains the specifications for up- and downscaling behavior (requires autoscaling/v2beta2 or higher)
hpa.customMetrics[]Custom metrics contains the specifications for which to use to calculate the desired replica count (overrides the default use of Average CPU Utilization configured in targetAverageUtilization)
hpa.cpu.targetTypeAverageValueSet the autoscaling CPU target type, must be either Utilization or AverageValue
hpa.cpu.targetAverageValue100mSet the autoscaling CPU target value
hpa.cpu.targetAverageUtilization Set the autoscaling CPU target utilization
hpa.memory.targetType Set the autoscaling memory target type, must be either Utilization or AverageValue
hpa.memory.targetAverageValue Set the autoscaling memory target value
hpa.memory.targetAverageUtilization Set the autoscaling memory target utilization
hpa.targetAverageValue  DEPRECATED Set the autoscaling CPU target value
ingress.enabled true if global.kas.enabled=true You can use kas.ingress.enabled to explicitly turn it on or off. If not set, you can optionally use global.ingress.enabled for the same purpose.
ingress.apiVersion Value to use in the apiVersion field.
ingress.annotations{}Ingress annotations.
ingress.tls{}Ingress TLS configuration.
ingress.agentPath/Ingress path for the agent API endpoint.
ingress.k8sApiPath/k8s-proxyIngress path for Kubernetes API endpoint.
metrics.enabledtrueIf a metrics endpoint should be made available for scraping.
metrics.port8151Metrics endpoint port.
metrics.path/metricsMetrics endpoint path.
metrics.serviceMonitor.enabledfalseIf a ServiceMonitor should be created to enable Prometheus Operator to manage the metrics scraping. Enabling removes the scrape annotations.
metrics.serviceMonitor.additionalLabels{}Additional labels to add to the ServiceMonitor.
metrics.serviceMonitor.endpointConfig{}Additional endpoint configuration for the ServiceMonitor.
maxReplicas10HPA maxReplicas.
maxUnavailable1HPA maxUnavailable.
minReplicas2HPA maxReplicas.
nodeSelector Define a nodeSelector for the Pods of this Deployment, if present.
serviceAccount.annotations{}Service account annotations.
podLabels{}Supplemental Pod labels. Not used for selectors.
serviceLabels{}Supplemental service labels.
common.labels Supplemental labels that are applied to all objects created by this chart.
redis.enabledtrueAllows opting-out of using Redis for KAS features. Warnings: Redis will become a hard dependency soon, so this key is already deprecated.
resources.requests.cpu75mGitLab Exporter minimum CPU.
resources.requests.memory100MGitLab Exporter minimum memory.
service.externalPort8150External port (for agentk connections).
service.internalPort8150Internal port (for agentk connections).
service.apiInternalPort8153Internal port for the internal API (for GitLab backend).
service.loadBalancerIPnilA custom load balancer IP when service.type is LoadBalancer.
service.loadBalancerSourceRangesnilA list of custom load balancer source ranges when service.type is LoadBalancer.
service.kubernetesApiPort8154External port to expose proxied Kubernetes API on.
service.privateApiPort8155Internal port to expose kas’ private API on (for kas -> kas communication).
privateApi.secretAutogeneratedThe name of the secret to use for authenticating with the database.
privateApi.keyAutogeneratedThe name of the key in privateApi.secret to use.
global.kas.service.apiExternalPort8153External port for the internal API (for GitLab backend).
service.typeClusterIPService type.
tolerations[]Toleration labels for pod assignment.
customConfig{}When given, merges the default kas configuration with these values giving precedence to those defined here.
deployment.minReadySeconds0Minimum number of seconds that must pass before a kas pod is considered ready.
deployment.strategy{}Allows one to configure the update strategy utilized by the deployment.

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 \
      --set global.hosts.externalIP=XYZ.XYZ.XYZ.XYZ \
  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:

      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