【免费下载链接】charts⚠️(OBSOLETE) Curated applications for Kubernetes项目地址https://gitcode.com/gh_mirrors/chart/charts点击查看免费下载本指南以 stable/gitlab-ee/README.md 为核心结合 chart 内 values.yaml 与 templates 中的实际模板源码系统讲解如何在 Kubernetes 集群中通过 Helm 部署 GitLab Enterprise EditionGitLab EE涵盖前置条件、安装/卸载流程、全部可配置参数、持久化方案以及 ConfigMap、Secret、Deployment、Service 等底层资源的生成原理。读者学完后可以独立完成一次完整的 GitLab EE 部署并根据业务需求调整资源配额、访问方式与持久化策略。需要注意该 chart 已标记为废弃deprecated官方推荐迁移到 GitLab 官方 Helm chart本文内容可作为理解 Omnibus 模式部署与 Helm 模板机制的参考。Chart 概览与废弃状态stable/gitlab-ee是 Helm 官方 charts 仓库中的稳定版 chart用于在 Kubernetes 上以GitLab Omnibus单容器模式部署 GitLab Enterprise Edition。从 Chart.yaml 可以看到名称gitlab-ee版本0.2.3对应应用版本appVersion: 9.4.1deprecated: trueREADME 开头也明确说明该 chart 已被 官方 GitLab chart 取代因此本文内容适合用于学习、理解或迁移存量部署而非推荐新项目直接采用。在安装前应仔细阅读弃用说明评估是否直接使用官方 chart。chart 的核心思路是将 GitLab 以单个 Omnibus Pod 部署同时把数据库PostgreSQL与缓存Redis拆分为独立的 Helm 子 chartdependency避免在单个 Pod 内全部自托管从而降低资源压力并便于维护。这一拆分体现在 requirements.yaml 中dependencies: - name: redis version: 0.9.0 repository: https://kubernetes-charts.storage.googleapis.com/ - name: postgresql version: 0.8.1 repository: https://kubernetes-charts.storage.googleapis.com/架构组成Omnibus Pod Redis PostgreSQLREADME 的 Introduction 部分明确指出该 chart 会部署以下组件一个 GitLab Omnibus Pod运行gitlab/gitlab-ee镜像Redis作为 GitLab 的缓存/会话存储PostgreSQL作为 GitLab 的主数据库三者通过 Kubernetes Service 与内部 DNS 进行通信。在 deployment.yaml 中可以看到GitLab 容器通过一系列环境变量获取外部依赖的连接信息环境变量来源说明GITLAB_OMNIBUS_CONFIGConfigMap传递给 Omnibus 的 Ruby 配置脚本是整体配置的核心EXTERNAL_URLvalues 的externalUrlGitLab 对外访问地址GITLAB_ROOT_PASSWORDSecret初始 root 管理员密码可选DB_HOST/DB_USER/DB_PASSWORD/DB_DATABASESecret 直接值PostgreSQL 连接信息REDIS_HOST/REDIS_PASSWORDSecretRedis 连接信息从模板可以看出DB_HOST与REDIS_HOST使用了_helpers.tpl中定义的命名规则见 templates/_helpers.tplgitlab-ee.postgresql.fullnamerelease-name-postgresqlgitlab-ee.redis.fullnamerelease-name-redis也就是说安装时发布名release name决定了依赖服务在集群内的 DNS 名称例如发布名为my-release时数据库地址为my-release-postgresql。前置条件README 的 Prerequisites 部分列出如下要求集群至少拥有3 GB 可用内存且以 1 GB 为单位分配GitLab、Redis、PostgreSQL 各自约 1 GBKubernetes 1.4并启用 Beta API底层基础设施支持PV provisioner动态持久卷供应否则无法创建 PVC能够为 GitLab 实例配置DNS 记录或可访问的 URL对照 values.yaml 的默认资源配额可以理解 3 GB 内存需求的来源resources: requests: memory: 1Gi cpu: 500m limits: memory: 2Gi cpu: 1GitLab 容器请求 1Gi 内存、上限 2GiPostgreSQL 依赖默认memory: 1Gi、cpu: 1000mRedis 依赖默认resources.requests.memory: 1Gi。三者相加正是至少 3 GB、按 1 GB 分块这一要求的由来。安装 ChartREADME 给出最小安装命令$ helm install --name my-release \ --set externalUrlhttp://your-domain.com/ stable/gitlab-ee关键约束externalUrl是必传参数。README 明确警告——如果不传externalUrl得到的将是一个无法正常工作non-functioning的 release。从模板源码可以印证这一点deployment.yaml 最外层有{{- if default .Values.externalUrl }}条件判断只有提供了externalUrl才会渲染 Deployment 资源templates/NOTES.txt 在未传externalUrl时输出 WARNING 提示并给出补救命令helm upgrade my-release \ --set externalUrlhttp://your-domain.com stable/gitlab-ee因此安装时务必携带externalUrl否则集群中不会生成 GitLab 的 Deployment。安装完成后可通过helm list查看已部署的 release。卸载 Chart卸载与删除 release 的命令$ helm delete my-release该命令会移除与该 chart 相关的所有 Kubernetes 组件Deployment、Service、ConfigMap、Secret、PVC 等并删除 release 记录。需要注意持久卷声明PVC及其绑定的数据是否保留取决于底层存储策略卸载前应确认存储后端行为避免意外删除 GitLab 仓库数据。配置参数详解README 指出所有默认值都集中在 values.yaml其中既有 Kubernetes 相关指令也有 GitLab 相关指令。配置方式有两种通过--set keyvalue[,keyvalue]逐项指定$ helm install --name my-release \ --set externalUrlhttp://your-domain.com/,gitlabRootPasswordpass1234 \ stable/gitlab-ee通过-f传入 YAML 值文件$ helm install --name my-release -f values.yaml stable/gitlab-ee也可以直接使用默认的 values.yaml 作为起点进行修改。核心参数速查表参数默认值说明imagegitlab/gitlab-ee:9.4.1-ee.0GitLab EE 镜像及标签imagePullPolicy未设置镜像拉取策略latest标签建议Always固定标签建议IfNotPresentexternalUrl无默认值必填用户访问 GitLab 的完整 URL含协议如http://your-domain.com/gitlabRootPassword空初始 root 管理员密码不设置则首次访问时自行设置serviceTypeLoadBalancerService 类型minikube 建议NodePortsshPort22对外暴露的 SSH 端口httpPort80对外暴露的 HTTP 端口httpsPort443对外暴露的 HTTPS 端口resources.requests.memory1Gi内存请求resources.requests.cpu500mCPU 请求resources.limits.memory2Gi内存上限resources.limits.cpu1CPU 上限数据库PostgreSQL参数values.yaml 中 PostgreSQL 相关配置postgresql: # 9.6 是 GitLab 容器支持的最新版本 imageTag: 9.6 cpu: 1000m memory: 1Gi postgresUser: gitlab postgresPassword: gitlab postgresDatabase: gitlab persistence: size: 10Gi值得注意的细节imageTag: 9.6是刻意固定为 GitLab 容器兼容的版本注释明确说明9.6 是当前 GitLab 镜像支持的最新版本升级前需确认兼容性默认数据库名、用户名、密码均为gitlab生产环境务必覆盖默认密码后续 Secret 会引用该值。Redis 参数redis: redisPassword: gitlab resources: requests: memory: 1Gi persistence: size: 10Gi各参数在模板中的实际作用serviceType直接决定 svc.yaml 中spec.type的值LoadBalancer用于云环境NodePort用于 minikube 等本地方案ClusterIP则配合端口转发使用sshPort/httpPort/httpsPort映射到 Service 的三个具名端口ssh、http、https与 deployment.yaml 中容器的containerPort22/80/443对应resources通过{{ toYaml .Values.resources | indent 10 }}原样注入 Deployment 的 resources 字段imagePullPolicy使用{{ default .Values.imagePullPolicy | quote }}未设置时保持空值由 Kubernetes 根据标签决定。持久化PersistenceREADME 明确指出默认情况下GitLab 数据与配置通过 PVCPersistentVolumeClaim持久化。如果预计数据量较大务必查看 values.yaml 中persistence一节。同时 README 给出重要警告如果禁用持久化卷中的数据只与 Pod 生命周期一致升级或更改某些设置可能导致数据丢失。两个持久卷设计chart 将持久化拆分为两个 PVC分别挂载到不同的目录配置项默认大小访问模式挂载路径用途persistence.gitlabEtc1GiReadWriteOnce/etc/gitlab生成的配置文件、密钥、证书persistence.gitlabData10GiReadWriteOnce/gitlab-dataGit 数据及其他项目文件values.yaml 中的默认配置persistence: gitlabEtc: enabled: true size: 1Gi # storageClass: # 若定义则使用 volume.beta.kubernetes.io/storage-class accessMode: ReadWriteOnce gitlabData: enabled: true size: 10Gi # storageClass: accessMode: ReadWriteOncePVC 模板的 StorageClass 处理两个 PVC 模板templates/data-pvc.yaml 与 templates/etc-pvc.yaml结构一致定义了storageClass时使用注解volume.beta.kubernetes.io/storage-class: storageClass未定义时回退到默认注解volume.alpha.kubernetes.io/storage-class: default。这一逻辑表明在未指定 StorageClass 的环境里依赖集群的默认存储类。若底层无默认 StorageClass 或需使用特定存储如 SSD、NFS应在 values.yaml 中显式指定否则 PVC 可能无法完成绑定。禁用持久化时的行为在 deployment.yaml 中可以看到当对应persistence.*.enabled为false时卷会回退为emptyDirvolumes: - name: gitlab-etc {{- if .Values.persistence.gitlabEtc.enabled }} persistentVolumeClaim: claimName: {{ template gitlab-ee.fullname . }}-etc {{- else }} emptyDir: {} {{- end }}emptyDir卷的生命周期与 Pod 相同——Pod 被删除或重建后数据即消失这正是 README 中禁用持久化将导致数据随 Pod 消亡警告的源码级体现。因此生产环境务必保持持久化开启。源码级原理配置、密钥与健康检查ConfigMapOmnibus 配置注入configmap.yaml 生成了GITLAB_OMNIBUS_CONFIG环境变量所引用的配置内容这是 GitLab Omnibus 的主要配置入口。其内容是一段 Ruby 配置脚本展示了 chart 的核心设计external_url ENV[EXTERNAL_URL]; root_pass ENV[GITLAB_ROOT_PASSWORD]; gitlab_rails[initial_root_password] root_pass unless root_pass.to_s ; postgresql[enable] false; gitlab_rails[db_host] ENV[DB_HOST]; gitlab_rails[db_password] ENV[DB_PASSWORD]; gitlab_rails[db_username] ENV[DB_USER]; gitlab_rails[db_database] ENV[DB_DATABASE]; redis[enable] false; gitlab_rails[redis_host] ENV[REDIS_HOST]; gitlab_rails[redis_password] ENV[REDIS_PASSWORD]; unicorn[worker_processes] 2; manage_accounts[enable] true; manage_storage_directories[manage_etc] false; gitlab_shell[auth_file] /gitlab-data/ssh/authorized_keys; git_data_dir /gitlab-data/git-data; gitlab_rails[shared_path] /gitlab-data/shared; gitlab_rails[uploads_directory] /gitlab-data/uploads; gitlab_rails[builds_directory] /gitlab-data/builds;这段配置包含几个关键设计点关闭内置数据库与 Redispostgresql[enable] false与redis[enable] false强制 Omnibus 使用外部依赖与 chart 拆分子 chart 的架构一致敏感信息全部来自环境变量数据库与 Redis 的密码通过环境变量读取而不是硬编码进 ConfigMap配合 Secret 避免密码出现在kubectl get configmap明文输出中数据目录统一收敛到/gitlab-dataauthorized_keys、git 仓库目录git_data_dir、shared、uploads、builds 全部指向持久卷gitlab-data的挂载点保证 Git 数据、CI 构建产物等都能持久化Unicorn worker 数固定为 2并开启账户管理manage_accounts[enable] true。Secret凭据的集中管理secrets.yaml 定义了Opaque类型 Secret包含四个字段均经b64enc编码gitlab-root-password仅当设置了gitlabRootPassword时才生成未设置时模板注释说明使用一个无意义默认值来规避 b64enc 告警实际不会使用db-user/db-password来自postgresql.postgresUser/postgresql.postgresPasswordredis-password来自redis.redisPassword。Deployment 通过secretKeyRef引用这些密钥从而避免把密码明文写入 Pod 定义。这也是 README 中混合了 Kubernetes 与 GitLab 相关指令的设计体现。健康检查与启动节奏deployment.yaml 配置了 liveness 与 readiness 探针均请求/help路径livenessProbeinitialDelaySeconds: 200200 秒延迟、periodSeconds: 10、failureThreshold: 10readinessProbeinitialDelaySeconds: 30、periodSeconds: 10、failureThreshold: 3。模板注释特别提醒GitLab Pod 启动非常慢不要轻易调低 initialDelaySeconds否则可能因探针过早失败导致 Pod 反复被杀。这解释了为什么 liveness 初始延迟高达 200 秒——首次启动时要完成依赖初始化、数据库迁移与配置应用等耗时的阶段。Service 暴露方式svc.yaml 生成一个三端口 Servicespec: type: {{ .Values.serviceType }} ports: - name: ssh port: {{ .Values.sshPort | int }} targetPort: ssh - name: http port: {{ .Values.httpPort | int }} targetPort: http - name: https port: {{ .Values.httpsPort | int }} targetPort: https selector: app: {{ template gitlab-ee.fullname . }}targetPort使用具名端口ssh/http/https对应 Deployment 中容器的端口定义因此即使调整对外端口号容器内部仍使用固定的 22/80/443。安装后的访问与验证templates/NOTES.txt 在安装成功后输出访问指引按 Service 类型区分LoadBalancer默认# LoadBalancer IP 可能需要几分钟才可用可 watch 状态 kubectl get svc -w my-release-gitlab-ee export SERVICE_IP$(kubectl get svc --namespace namespace my-release-gitlab-ee \ -o jsonpath{.status.loadBalancer.ingress[0].ip}) echo http://$SERVICE_IP/NodePortminikube 等export NODE_IP$(kubectl get nodes --namespace namespace \ -o jsonpath{.items[0].status.addresses[0].address}) echo http://$NODE_IP/ClusterIP端口转发export POD_NAME$(kubectl get pods --namespace namespace \ -l appmy-release-gitlab-ee -o jsonpath{.items[0].metadata.name}) kubectl port-forward $POD_NAME 8080:80首次登录如果设置了gitlabRootPassword使用用户名root与设置值登录如果未设置首次访问安装界面时会提示设置管理员密码随后用root与自设密码登录。DNS 配置最后一步是将 DNS 记录指向实例地址确保用户能够通过安装时指定的externalUrlNOTES.txt 中会回显该值访问 GitLab。若省略此步骤虽然实例可以运行但基于externalUrl生成的克隆 URL、Webhook 等会无法正确工作。注意事项与迁移建议chart 已废弃README 首页即声明该 chart 已被官方 GitLab chart 取代Chart.yaml 中deprecated: true。新部署应优先评估官方 chart本 chart 仅建议用于学习模板机制或维护存量环境。externalUrl 必填不传会导致 Deployment 模板完全不渲染见 deployment.yaml 的if守卫且 NOTES 会输出 WARNING。内存规划按每组件 1 GiB规划集群容量避免资源不足导致依赖 Pod 无法调度。密码安全默认的数据库/Redis 密码均为gitlab仅适用于测试环境生产环境务必通过--set postgresql.postgresPassword...等方式覆盖并妥善保管 Secret。持久化开关生产环境保持persistence.gitlabEtc与persistence.gitlabData开启并按 GitLab 硬件与存储要求官方建议参考 GitLab 安装文档调整大小与 StorageClass。相关资源配置默认值总览stable/gitlab-ee/values.yamlChart 元信息与废弃声明stable/gitlab-ee/Chart.yaml依赖声明stable/gitlab-ee/requirements.yaml模板清单stable/gitlab-ee/templates/deployment.yaml主 Deployment、探针、环境变量与卷定义configmap.yamlOmnibus 配置脚本secrets.yaml凭据生成svc.yaml服务暴露data-pvc.yaml 与 etc-pvc.yaml持久卷声明NOTES.txt安装后访问指引赞分享【免费下载链接】charts⚠️(OBSOLETE) Curated applications for Kubernetes项目地址https://gitcode.com/gh_mirrors/chart/charts点击查看免费下载相关推荐基于 Bitnami Helm Chart 在 Kubernetes 上部署 GitLab Runner 的完整实战指南基于 Bitnami Helm Chart 在 Kubernetes 上部署 GitLab Runner 的完整实战指南 GitLab Runner 是 Git云原生容器编排基于 Helm 在 Kubernetes 上部署 Nextcloudstable/nextcloud Chart 完整配置指南基于 Helm 在 Kubernetes 上部署 Nextcloudstable/nextcloud Chart 完整配置指南 本篇技术指南以当前开源仓库 s基于 Helm 在 Kubernetes 上部署 JFrog Artifactoryincubator/artifactory Chart 实战指南基于 Helm 在 Kubernetes 上部署 JFrog Artifactoryincubator/artifactory Chart 实战指南 本文以创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考