How to use the Kubernetes Agent in free CE?

Hi!

We have an Omnibus-installed Gitlab CE self-managed instance that we upgraded to 14.5 today. We saw that the Kubernetes Agent had been moved to Core (Move the CI Tunnel for GitLab Kubernetes Agent to Core (&6290) · Epics · GitLab.org · GitLab) and we were eager to try it with our test cluster.

Unfortunately, according to the documentation, the agent needs the server (KAS) to work. However, the doc also says that the server is for Premium users only.

Is there a path for Free users to use the Agent without using Gitlab.com? This does not seem very clear to me.

Thanks!

I think the simplest way is to enable the appropriate KAS options in gitlab.rb and reconfigure and see if it allows you to use it or not. Worst case if it doesn’t so you disable KAS again.

All configuration options available from the gitlab.rb.template file:

################################################################################
## GitLab Kubernetes Agent Server
##! Docs: https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/blob/master/README.md
################################################################################

##! Settings used by the GitLab application
# gitlab_rails['gitlab_kas_enabled'] = true
# gitlab_rails['gitlab_kas_external_url'] = ws://gitlab.example.com/-/kubernetes-agent
# gitlab_rails['gitlab_kas_internal_url'] = grpc://localhost:8153
# gitlab_rails['gitlab_kas_external_k8s_proxy_url'] = ws://gitlab.example.com/-/kubernetes-agent

##! Enable GitLab KAS
# gitlab_kas['enable'] = true

##! Agent configuration for GitLab KAS
# gitlab_kas['agent_configuration_poll_period'] = 20
# gitlab_kas['agent_gitops_poll_period'] = 20
# gitlab_kas['agent_gitops_project_info_cache_ttl'] = 300
# gitlab_kas['agent_gitops_project_info_cache_error_ttl'] = 60
# gitlab_kas['agent_info_cache_ttl'] = 300
# gitlab_kas['agent_info_cache_error_ttl'] = 60

##! Shared secret used for authentication between KAS and GitLab
# gitlab_kas['api_secret_key'] = nil # Will be generated if not set. Base64 encoded and exactly 32 bytes long.

##! Shared secret used for authentication between different KAS instances in a multi-node setup
# gitlab_kas['private_api_secret_key'] = nil # Will be generated if not set. Base64 encoded and exactly 32 bytes long.

##! Listen configuration for GitLab KAS
# gitlab_kas['listen_address'] = 'localhost:8150'
# gitlab_kas['listen_network'] = 'tcp'
# gitlab_kas['listen_websocket'] = true
# gitlab_kas['internal_api_listen_network'] = 'tcp'
# gitlab_kas['internal_api_listen_address'] = 'localhost:8153'
# gitlab_kas['kubernetes_api_listen_address'] = 'localhost:8154'
# gitlab_kas['private_api_listen_network'] = 'tcp'
# gitlab_kas['private_api_listen_address'] = 'localhost:8155'

##! Metrics configuration for GitLab KAS
# gitlab_kas['metrics_usage_reporting_period'] = 60

##! Environment variables for GitLab KAS
# gitlab_kas['env'] = {
#   'SSL_CERT_DIR' => "/opt/gitlab/embedded/ssl/certs/",
#   # In a multi-node setup, this address MUST be reachable from other KAS instances. In a single-node setup, it can be on localhost for simplicity
#   'OWN_PRIVATE_API_URL' => 'grpc://localhost:8155'
# }

##! Directories for GitLab KAS
# gitlab_kas['dir'] = '/var/opt/gitlab/gitlab-kas'
# gitlab_kas['log_directory'] = '/var/log/gitlab/gitlab-kas'
# gitlab_kas['env_directory'] = '/opt/gitlab/etc/gitlab-kas/env'

although according to the docs, the only thing you need to change is this:

gitlab_kas['enable'] = true

and then run gitlab-ctl reconfigure. That would be the easiest way to find out if it is possible without premium self-managed or not.

1 Like

Thanks for your answer.

I forgot to specify it in my post, but I already enabled the KAS on the instance. The service is enabled and I can see that its status seems to be OK when doing a gitlab-ctl status but I can’t seem to be able to register the agent with the KAS. I keep getting 400 or 404 errors (I tried different config / addresses just in case). I do have a separate Nginx server in front of Gitlab, replacing the Omnibus one but it should have everything needed for websockets to work.

I might have done something wrong, but I decided to post about the tiers first as it would also be a cause for it not working.

Hi, assuming that the nginx config is correct, then it could hint at the fact that KAS won’t work unless premium or higher as per the docs. I suppose if you tried to register the agent using the gitlab.com websockets link and then that showing as working, would then potentially confirm this. My main reason for suggesting to try it, was just in case the docs weren’t correct by reflecting premium when it may have worked without.

Unfortunately, it could well be that it is only for premium for the KAS side, but free for using the KAS agents providing that it’s redirected to Gitlab’s websockets. That would be the only thing I can think of that explains the way the documentation is labeled - part premium/part free.

I haven’t tried with Gitlab.com as we do not have a paid account there (or any account).

I agree with your hypothesis, I had the same. I find that a bit strange though: why allow self-hosted Gitlab instances to use the Agent but not the KAS which is needed for the Agent to work… If this is true, I don’t see much use of the Kubernetes Agent for Free, self-hosted, users sadly :confused:

Maybe someone reading this with knowledge of the tiering for this feature could comment? I’d be happy to be proven wrong and have to fix a mistake of mine, but I want to be sure so that I don’t spend too much time trying to debug this.

There is this endpoint available: wss://kas.gitlab.com

although not sure if that is also restricted to premium or not. From this link: Install the GitLab Kubernetes Agent | GitLab

not sure if perhaps worth trying that? If it connects and the agent works, that would mean that at least we know either your install doesn’t pass the agent string via your nginx when you configure Gitlab for KAS, or, for self-managed it’s premium only.

I only tend to use bundled nginx, but I don’t use KAS, as haven’t Kubernetes so can’t help anymore than that, just bouncing some ideas around.

Hopefully someone from the Gitlab Team will add some input on if it actually is restricted and unavailable or a potential config problem.

Hello!

The GitLab PM responsible for these features here.

KAS should be available in GitLab Free too. Having it labeled as Premium is a documentation error, we missed changing the tiering label.

1 Like

Ok, thank you for the confirmation @vnagy! Then this means that we still have a problem somewhere. Is there a possibility to get more information on the 400 error that we get back from workhorse when the agent tries to register itself?