@@ -72,9 +72,8 @@ In keeping with GitLab's value of transparency, all of the Kubernetes cluster co
The following projects are used to manage the installation:
-[k8s-workloads/gitlab-com](https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-com): Contains the GitLab.com configuration for the [GitLab helm chart](https://gitlab.com/gitlab-org/charts/gitlab).
-[k8s-workloads/gitlab-helmfiles](https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-helmfiles/): Contains the configuration cluster logging, monitoring and integrations.
-[argocd/apps](https://gitlab.com/gitlab-com/gl-infra/argocd/apps): Contains the Applications for all services for ArgoCD.
-[k8s-workloads/gitlab-com](https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-com): Contains the Kubernetes workload configuration for GitLab.com, including the configuration for the [GitLab helm chart](https://gitlab.com/gitlab-org/charts/gitlab) deployment of the core GitLab.com application.
-[argocd/apps](https://gitlab.com/gitlab-com/gl-infra/argocd/apps): Contains the ArgoCD Applications for Kubernetes service workloads managed in ArgoCD; ArgoCD is the standard GitOps deployment tool for GitLab.com infrastructure workloads outside the core gitlab-com application.
-[argocd/config](https://gitlab.com/gitlab-com/gl-infra/argocd/config): Contains the top-level Applications, AppProjects, Repositories, cluster inventory and RBAC configuration for ArgoCD.
-[config-mgmt](https://gitlab.com/gitlab-com/gl-infra/config-mgmt): Terraform configuration for the cluster, all resources necessary to run the cluster are configured here including the cluster, node pools, service accounts and IP address reservations.
-[charts](https://gitlab.com/gitlab-com/gl-infra/charts): Charts created by the infrastructure department to deploy services that don't have community charts.
@@ -98,11 +97,11 @@ Logging is configured using [fluentd-elasticsearch](https://gitlab.com/gitlab-co
##### Cluster Configuration Updates
There is a single namespace `gitlab` that is used exclusively for the GitLab application.
Chart configuration updates are set in the [gitlab-com k8s-workloads project](https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-com) where there are [yaml configuration files](https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-com/-/tree/master/releases/gitlab/values) that set defaults for the GitLab.com environment with per-environment overrides.
Chart configuration updates are set in the [`k8s-workloads/gitlab-com` project](https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-com) where there are [YAML configuration files](https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-com/-/tree/master/releases/gitlab/values) that set defaults for the GitLab.com environment with per-environment overrides.
Changes to this configuration are applied by the SRE and Delivery team after a review using a MR review workflow.
When a change is approved on GitLab.com the pipeline that applies the change is run on a separate operations environment to ensure that configuration updates do not depend on the availability of the production environment.
For namespaces in the cluster for other services like logging, monitoring, etc. a similar GitOps workflow is followed using the [gitlab-helmfiles](https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-helmfiles).
For namespaces in the cluster for other services like logging, monitoring, and integrations, a different GitOps workflow is followed using ArgoCD, with service definitions in [`argocd/apps`](https://gitlab.com/gitlab-com/gl-infra/argocd/apps) and shared ArgoCD configuration in [`argocd/config`](https://gitlab.com/gitlab-com/gl-infra/argocd/config).
GitLab.com does not depend on itself when pulling images utilized in our Kubernetes clusters.
Instead, we utilize our [dev.gitlab.org](https://dev.gitlab.org) container registry for [CNG images](https://gitlab.com/gitlab-org/build/CNG/).
