Enable KAS ("Kubernetes Agent Server")
-
GitLab supplies various DevOps tools to manage and run CI pipelines and even production deployments.
This is most convenient when connecting GitLab to a Kubernetes cluster. GitLab can then self-provision pods as needed to launch CI runners, deploy applications, run red/green deployments, and so on.
Starting with GitLab 14.5, the preferred way of managing such Kubernetes clusters is with a GitOps approach using GitLab's Kuberentes agent called KAS.
This is a separate service which the Kubernetes cluster can poll to pull in information and infrastructure specifications from GitLab.
Other methods of managing a Kubernetes cluster have been deprecated in GitLab 14.5. and will thus be removed in future versions (https://gitlab.com/groups/gitlab-org/configure/-/epics/8).
The documentation for enabling KAS can be found at https://docs.gitlab.com/ee/administration/clusters/kas.html.
However, setting
production: gitlab_kas: enabled: truein
/app/data/gitlab.ymlseems to have no effect in Cloudron.It would be great if the Cloudron package could be modified to allow for a KAS to be started.
-
@niels I think you have to use an external KAS server. Or is your request to bundle this KAS agent as part of the GitLab package? https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/config/gitlab.yml.example#L1253 has the info on how to configure for use with an external agent.
-
@girish The request, or maybe more of a pious wish, is for the KAS to be available within the Cloudron app itself.
My understanding regarding running a separate KAS is that this would effectively require spinning up a GitLab Omnibus instance, thus sort of defeating the purpose / convenience of the Cloudron instance. There doesn't seem to be a standalone KAS binary.
The request for the container registry (https://forum.cloudron.io/topic/1837/gitlab-how-to-run-container-registry/25) is somewhat similar.
