• 요구 사항
• 구성
• 설치 명령줄 옵션

GitLab Webservice 차트 사용하기

webservice sub-chart는 GitLab Rails 웹 서버에 대해 하나의 pod이 어떠한 웹 요청도 처리할 수 있는 최소한의 요구 사항인 두 개의 Webservice 워커를 제공합니다.

이 차트의 pod은 gitlab-workhorse와 webservice 두 개의 컨테이너를 사용합니다. GitLab Workhorse는 포트 8181에서 대기하며 pod으로의 들어오는 트래픽의 목적지여야 합니다. webservice는 GitLab Rails 코드베이스를 포함하고 있으며, 8080에서 대기하며 메트릭 수집을 목적으로 접근 가능해야 합니다. webservice는 직접적인 트래픽을 받아서는 안됩니다.

요구 사항

이 차트는 Redis, PostgreSQL, Gitaly, 및 Registry 서비스에 의존하며, 완전한 GitLab 차트의 일부로 제공되거나 이 차트가 배포된 Kubernetes 클러스터에서 reachable한 외부 서비스로 제공되어야 합니다.

구성

webservice 차트는 다음과 같이 구성됩니다: 글로벌 설정, 배포 설정, 인그레스 설정, 외부 서비스, 및 차트 설정.

설치 명령줄 옵션

아래 표는 helm install 명령에 사용될 수 있는 모든 가능한 차트 구성을 --set 플래그를 사용하여 제공할 수 있습니다.

매개변수	기본값	설명
annotations		pod 주석
podLabels		보조 pod 라벨. 선택기에는 사용되지 않음.
common.labels		이 차트에 의해 생성된 모든 객체에 적용되는 보조 라벨
deployment.terminationGracePeriodSeconds	30	Kubernetes가 pod이 종료될 때까지 기다릴 시간(참고: 이 시간은 shutdown.blackoutSeconds보다 길어야 함)
deployment.livenessProbe.initialDelaySeconds	20	생존성 프로브가 시작되기 전의 지연
…

<중략> | `priorityClassName` | `""` | Pod의 `priorityClassName` 설정을 허용하며, 이것은 이상적인 상황에서의 pod 우선 순위를 제어하는 데 사용됩니다. ## 차트 구성 예시 ### extraEnv `extraEnv`를 사용하면 pod의 모든 컨테이너에 추가 환경 변수를 노출시킬 수 있습니다. 아래는 `extraEnv`의 사용 예시입니다: ```yaml extraEnv: SOME_KEY: some_value SOME_OTHER_KEY: some_other_value ``` 컨테이너가 시작될 때 환경 변수가 노출되는지 확인할 수 있습니다: ```shell env | grep SOME SOME_KEY=some_value SOME_OTHER_KEY=some_other_value ``` ### extraEnvFrom `extraEnvFrom`를 사용하면 pod의 모든 컨테이너에서 다른 데이터 소스에서 추가 환경 변수를 노출시킬 수 있습니다. 후속 변수는 [배포](#deployments-settings)별로 재정의할 수 있습니다. 아래는 `extraEnvFrom`의 사용 예시입니다: ```yaml extraEnvFrom: MY_NODE_NAME: fieldRef: fieldPath: spec.nodeName MY_CPU_REQUEST: resourceFieldRef: containerName: test-container resource: requests.cpu SECRET_THING: secretKeyRef: name: special-secret key: special_token # optional: boolean deployments: default: extraEnvFrom: CONFIG_STRING: configMapKeyRef: name: useful-config key: some-string # optional: boolean ``` ### image.pullSecrets `pullSecrets`를 사용하면 pod에서 이미지를 끌어오기 위해 개인 레지스트리에 인증할 수 있습니다. 개인 레지스트리 및 해당 인증 방법에 대한 자세한 내용은 [Kubernetes 문서](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)에서 찾을 수 있습니다. 아래는 `pullSecrets`의 사용 예시입니다: ```yaml image: repository: my.webservice.repository pullPolicy: Always pullSecrets: - name: my-secret-name - name: my-secondary-secret-name ``` ### tolerations `tolerations`를 사용하면 오염된 워커 노드에 pod을 예약할 수 있습니다. 아래는 `tolerations`의 사용 예시입니다: ```yaml tolerations: - key: "node_label" operator: "Equal" value: "true" effect: "NoSchedule" - key: "node_label" operator: "Equal" value: "true" effect: "NoExecute" ``` ### annotations `annotations`를 사용하면 Webservice pod에 주석을 추가할 수 있습니다. 예를 들어: ```yaml annotations: kubernetes.io/example-annotation: annotation-value ``` ### strategy `deployment.strategy`를 사용하면 배포 업데이트 전략을 변경할 수 있습니다. 배포가 업데이트될 때 pod이 어떻게 다시 생성될지를 정의합니다. 제공되지 않을 경우 클러스터 기본값이 사용됩니다. 예를 들어, 롤링 업데이트가 시작될 때 추가 pod을 생성하고 최대 사용 불가능한 pod을 50%로 변경하고 싶지 않다면: ```yaml deployment: strategy: rollingUpdate: maxSurge: 0 maxUnavailable: 50% ``` 또한 업데이트 전략의 유형을 `재생성`(Recreate)으로 변경할 수도 있지만, 이 경우 새로운 pod을 예약하기 전에 모든 pod을 종료시키므로 주의해야 합니다. 또한, 웹 UI는 새로운 pod이 시작될 때까지 사용할 수 없게 됩니다. 이 경우 `rollingUpdate`만 정의하지 않아도 되고 `유형`(type)만 정의하면 됩니다: ```yaml deployment: strategy: type: Recreate ``` 더 자세한 내용은 [Kubernetes 문서](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#strategy)를 참조하세요. ### TLS Webservice pod은 두 개의 컨테이너를 실행합니다: - `gitlab-workhorse` - `webservice` #### `gitlab-workhorse` Workhorse는 웹 및 메트릭 엔드포인트 모두에 대해 TLS를 지원합니다. 이는 Workhorse와 다른 컴포넌트 간의 통신을 보호합니다. 특히 `nginx-ingress`, `gitlab-shell`, `gitaly`과 같은 컴포넌트와의 통신을 포함합니다. TLS 인증서에는 Workhorse 서비스 호스트 이름(예: `RELEASE-webservice-default.default.svc`)이 일반 이름(CN) 또는 대체 이름(SAN)에 포함되어야 합니다. Webservice의 [여러 배포](#deployments-settings)가 존재할 수 있으므로 서비스 이름별로 TLS 인증서를 준비해야 합니다. 이는 여러 SAN 또는 와일드카드 인증서로 구현할 수 있습니다. TLS 인증서를 생성한 후 [Kubernetes TLS 시크릿](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets)을 생성해야 합니다. 또한 TLS 인증서의 CA 인증서만 포함하는 다른 시크릿을 생성해야 하며 이 시크릿은 `ca.crt` 키로만 포함해야 합니다. `gitlab-workhorse` 컨테이너에서 TLS를 활성화하려면 `global.workhorse.tls.enabled`를 `true`로 설정하면 됩니다. 그리고 `gitlab.webservice.workhorse.tls.secretName` 및 `global.certificates.customCAs`에 사용자 정의 시크릿 이름을 전달할 수 있습니다. `gitlab.webservice.workhorse.tls.verify`가 `true`일 때(기본값), 자체 서명된 인증서 및 사용자 정의 CA를 위해 CA 인증서 시크릿 이름을 `gitlab.webservice.workhorse.tls.caSecretName`에 전달해야 합니다. 이는 NGINX가 Workhorse의 TLS 인증서를 확인하기 위해 필요합니다. ```yaml global: workhorse: tls: enabled: true certificates: customCAs: - secret: gitlab-workhorse-ca gitlab: webservice: workhorse: tls: verify: true # secretName: gitlab-workhorse-tls caSecretName: gitlab-workhorse-ca monitoring: exporter: enabled: true tls: enabled: true ``` `gitlab-workhorse` 컨테이너의 메트릭 엔드포인트에 대한 TLS는 `global.workhorse.tls.enabled`에서 상속됩니다. TLS가 Workhorse에게 활성화되어 있을 때 메트릭 엔드포인트의 TLS만 사용할 수 있습니다. 메트릭 리스너는 `gitlab.webservice.workhorse.tls.secretName`으로 지정된 TLS 인증서를 사용합니다. 메트릭 엔드포인트에 사용되는 TLS 인증서는 포함된 주제 대체 이름(SAN)에 대해 추가 고려 사항이 필요할 수 있으며, 특히 포함된 Prometheus Helm 차트를 사용하는 경우에 해당합니다. 자세한 내용은 [TLS 활성화 엔드포인트 스크랩 구성](../../../installation/tools.md#configure-prometheus-to-scrape-tls-enabled-endpoints)을 참조하세요. #### `webservice` TLS를 활성화하는 주요 사용 사례는 [Prometheus 메트릭 스크래핑](https://docs.gitlab.com/ee/administration/monitoring/prometheus/gitlab_metrics.html)을 통한 HTTPS를 통한 암호화 제공입니다. HTTPS를 사용하여 `/metrics/` 엔드포인트를 통해 Prometheus가 스크래핑하도록 하려면 인증서의 `CommonName` 속성 또는 `SubjectAlternativeName` 항목에 대한 추가 구성이 필요합니다. 해당 요구 사항은 [TLS 활성화 엔드포인트 스크랩 구성](../../../installation/tools.md#configure-prometheus-to-scrape-tls-enabled-endpoints)을 참조하세요. `webservice` 컨테이너에서 TLS를 활성화하려면 `gitlab.webservice.tls.enabled` 설정을 사용하면 됩니다: ```yaml gitlab: webservice: tls: enabled: true # secretName: gitlab-webservice-tls ``` `secretName`은 [Kubernetes TLS 시크릿](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets)을 가리켜야 합니다. 예를 들어, 로컬 인증서와 키를 사용하여 TLS 시크릿을 생성하려면: ```shell kubectl create secret tls <시크릿 이름=""> --cert=path/to/puma.crt --key=path/to/puma.key ``` ## 이 차트의 Community Edition 사용 기본적으로 Helm 차트는 GitLab Enterprise Edition을 사용합니다. 원하는 경우 Community Edition을 대신 사용할 수 있습니다. 두 버전 간의 [차이점](https://about.gitlab.com/install/ce-or-ee/)에 대해 자세히 알아보세요. Community Edition을 사용하려면 `image.repository`를 `registry.gitlab.com/gitlab-org/build/cng/gitlab-webservice-ce`로 설정하고 `workhorse.image`를 `registry.gitlab.com/gitlab-org/build/cng/gitlab-workhorse-ce`로 설정하세요. ## 전역 설정 차트 간에 일부 공통 전역 설정을 공유합니다. GitLab 및 레지스트리 호스트 이름과 같은 일반 구성 옵션에 대해서는 [Globals Documentation](../../globals.md)을 참조하세요. ## 배포 설정 이 차트는 여러 배포 오브젝트와 관련 리소스를 생성할 수 있는 능력을 갖고 있습니다. 이 기능을 사용하면 GitLab 애플리케이션에 대한 요청을 경로 기반 라우팅을 사용하여 여러 세트의 Pods 사이에 분산시킬 수 있습니다. 이 맵의 키들(`default` 예제에서)은 각각의 "이름"입니다. `default`는 `RELEASE-webservice-default`로 생성된 Deployment, Service, HorizontalPodAutoscaler, PodDisruptionBudget 및 선택적 Ingress를 갖습니다. 제공되지 않은 모든 속성은 `gitlab-webservice` 차트의 기본값을 상속받습니다. ```yaml deployments: default: ingress: path: # 상속되지 않음 또는 기본값 없음. 비활성화하려면 비워두세요. pathType: Prefix provider: nginx annotations: # ingress.annotations에서 상속 proxyConnectTimeout: # ingress.proxyConnectTimeout에서 상속 proxyReadTimeout: # ingress.proxyReadTimeout에서 상속 proxyBodySize: # ingress.proxyBodySize에서 상속 deployment: annotations: # 맵 labels: # 맵 # deployment에서 상속 pod: labels: # .podLabels에 대한 추가 라벨 annotations: # 맵 # .Values.annotations에서 상속 service: labels: # .serviceLabels에 대한 추가 라벨 annotations: # .service.annotations에 대한 추가 주석 # service.annotations에서 상속 hpa: minReplicas: # .minReplicas의 기본값 maxReplicas: # .maxReplicas의 기본값 metrics: # HPA 메트릭스 정의의 선택적 대체 # hpa에서 상속 pdb: maxUnavailable: # maxUnavailable에서 상속 resources: # `webservice` 컨테이너의 `resources` # resources에서 상속 workhorse: # 맵 # workhorse에서 상속 extraEnv: # # extraEnv에서 상속 extraEnvFrom: # # extraEnvFrom에서 상속 puma: # 맵 # puma에서 상속 workerProcesses: # workerProcesses에서 상속 shutdown: # shutdown에서 상속 nodeSelector: # 맵 # nodeSelector에서 상속 tolerations: # 배열 # tolerations에서 상속 ``` ### 배포 Ingress 각 `deployments` 항목은 차트 전역 [Ingress 설정](#ingress-settings)을 상속받습니다. 여기에 제공된 값은 그 설정을 덮어씁니다. `path`를 제외한 모든 설정은 해당 디렉터리과 동일합니다. ```yaml webservice: deployments: default: ingress: path: / api: ingress: path: /api ``` `path` 속성은 직접 Ingress의 `path` 속성으로 채워지며, 각 서비스로 연결된 URI 경로를 제어할 수 있게 합니다. 위 예제에서 `default`는 모든 경로를 받아들이고, `api`는 `/api` 아래 모든 트래픽을 받습니다. `path`를 비워두면 주어진 배포가 연결된 Ingress 리소스를 만들지 않도록 설정할 수 있습니다. 아래 예에서 `internal-api`는 외부 트래픽을 받지 않습니다. ```yaml webservice: deployments: default: ingress: path: / api: ingress: path: /api internal-api: ingress: path: ``` ## Ingress 설정 | 이름 | 타입 | 기본값 | 설명 | | :-------------------------------- | :-----: | :------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `ingress.apiVersion` | String | | `apiVersion` 필드에 사용할 값입니다. | | `ingress.annotations` | 맵 | [아래 참조](#annotations) | 모든 Ingress에 사용될 주석입니다. 예: `ingress.annotations."nginx\.ingress\.kubernetes\.io/enable-access-log"=true`. | | `ingress.configureCertmanager` | Boolean | | Ingress 주석 `cert-manager.io/issuer` 및 `acme.cert-manager.io/http01-edit-in-place`를 토글합니다. 추가 정보는 [GitLab Pages의 TLS 요구](../../../installation/tls.md)를 참조하세요. | | `ingress.enabled` | Boolean | `false` | Ingress 객체를 생성할지 여부를 제어하는 설정입니다. `false`일 때 `global.ingress.enabled` 설정 값이 사용됩니다. | | `ingress.proxyBodySize` | String | `512m` | [아래 참조](#proxybodysize). | | `ingress.tls.enabled` | Boolean | `true` | `false`로 설정하면 GitLab Webservice의 TLS를 비활성화합니다. 주로 Ingress 수준에서 TLS를 사용할 수 없는 경우에 유용합니다. 예: Ingress Controller 앞에 TLS 종료 프록시를 사용하는 경우. | | `ingress.tls.secretName` | String | (비어있음) | 유효한 인증서 및 GitLab URL용 키가 있는 쿠버네티스 TLS Secret의 이름입니다. 설정되지 않았을 때는 `global.ingress.tls.secretName` 값이 대신 사용됩니다. | | `ingress.tls.smardcardSecretName` | String | (비어있음) | 활성화된 경우 GitLab smartcard URL을 위한 유효한 인증서 및 키가 있는 쿠버네티스 TLS Secret의 이름입니다. 설정되지 않았을 때는 `global.ingress.tls.secretName` 값이 대신 사용됩니다. | | `ingress.tls.useGeoClass` | Boolean | false | IngressClass를 Geo Ingress class (`global.geo.ingressClass`)로 재정의합니다. 기본 Geo 사이트에 필요합니다. | ### annotations `annotations`은 Webservice Ingress에 주석을 설정하는 데 사용됩니다. 우리는 기본적으로 하나의 주석을 설정합니다: `nginx.ingress.kubernetes.io/service-upstream: "true"`. 이는 NGINX에 Webservice pods로의 트래픽을 더 균등하게 분산하기 위해 더 직접적으로 Service에 연락하도록 NGINX에 알리는 데 도움이 됩니다. 자세한 내용은 [NGINX 문서](https://github.com/kubernetes/ingress-nginx/blob/nginx-0.21.0/docs/user-guide/nginx-configuration/annotations.md#service-upstream)를 참조하세요. 이를 덮어쓰려면 다음과 같이 설정하세요: ```yaml gitlab: webservice: ingress: annotations: nginx.ingress.kubernetes.io/service-upstream: "false" ``` ### proxyBodySize `proxyBodySize`는 NGINX 프록시 최대 본문 크기를 설정하는 데 사용됩니다. 일반적으로 기본값보다 큰 Docker 이미지를 허용하는 데 필요합니다. 이는 [Linux package installation](https://docs.gitlab.com/omnibus/settings/nginx.html#request-entity-too-large)에서 `nginx['client_max_body_size']` 구성과 동일합니다. 대체로 다음 두 가지 매개변수 중 하나로 본문 크기를 설정할 수도 있습니다. - `gitlab.webservice.ingress.annotations."nginx\.ingress\.kubernetes\.io/proxy-body-size"` - `global.ingress.annotations."nginx\.ingress\.kubernetes\.io/proxy-body-size"` ### 추가 Ingress `extraIngress.enabled=true`로 설정하여 추가 Ingress를 배포할 수 있습니다. 이 Ingress는 기본 Ingress와 `-extra` 접미사가 붙은 이름을 가지며 동일한 설정을 지원합니다. ## 리소스 ### 메모리 요청/한계 각 pod는 `workerProcesses`와 동일한 수의 워커를 생성하며, 각각은 일정량의 메모리를 사용합니다. 권장하는 설정은 다음과 같습니다: - 워커당 최소 1.25GB (`requests.memory`) - 주요한 경우 워커당 최대 1.5GB, 기본으로 1GB (`limits.memory`) 필요한 리소스는 사용자에 의해 생성되는 워크로드에 dependent하며, GitLab 애플리케이션의 변경이나 업그레이드에 따라 미래에 변경될 수 있습니다. 기본값: ```yaml workerProcesses: 2 resources: requests: memory: 2.5G # = 2 * 1.25G # limits: # memory: 4G # = (2 * 1.5G) + 950M ``` 4개의 워커가 구성된 경우: ```yaml workerProcesses: 4 resources: requests: memory: 5G # = 4 * 1.25G # limits: # memory: 7G # = (4 * 1.5G) + 950M ``` ## 외부 서비스 ### Redis Redis 문서는 [글로벌](../../globals.md#configure-redis-settings) 페이지에 통합되었습니다. 최신 Redis 구성 옵션은 이 페이지를 참조하십시오. ### PostgreSQL PostgreSQL 문서는 [글로벌](../../globals.md#configure-postgresql-settings) 페이지에 통합되었습니다. 최신 PostgreSQL 구성 옵션은 이 페이지를 참조하십시오. ### Gitaly Gitaly는 [글로벌 설정](../../globals.md)에 의해 구성됩니다. [Gitaly 구성 문서](../../globals.md#configure-gitaly-settings)를 확인하십시오. ### MinIO ```yaml minio: serviceName: 'minio-svc' port: 9000 ``` | 이름 | 유형 | 기본값 | 설명 | | :------------ | :-----: | :---------- | :------------------------------------------------------ | | `port` | 정수 | `9000` | MinIO `Service`에 연결하는 포트 번호. | | `serviceName` | 문자열 | `minio-svc` | MinIO 파드에서 노출된 `Service`의 이름. | ### 레지스트리 ```yaml registry: host: registry.example.com port: 443 api: protocol: http host: registry.example.com serviceName: registry port: 5000 tokenIssuer: gitlab-issuer certificate: secret: gitlab-registry key: registry-auth.key ``` | 이름 | 유형 | 기본값 | 설명 | | :------------------- | :-----: | :-------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `api.host` | 문자열 | | 사용할 레지스트리 서버의 호스트 이름입니다. `api.serviceName`으로 대체할 수 있습니다. | | `api.port` | 정수 | `5000` | 레지스트리 API에 연결할 포트 번호입니다. | | `api.protocol` | 문자열 | | Webservice가 레지스트리 API에 도달하기 위해 사용해야 하는 프로토콜입니다. | | `api.serviceName` | 문자열 | `registry` | 레지스트리 서버를 운영하는 `service`의 이름입니다. 이 값이 있는 경우 `api.host` 대신 차트는 `api.host` 값을 현재 `.Release.Name`의 service 이름 (또는 .Release.Name)으로 템플릿화합니다. 오버올 GitLab 차트의 일부로 사용할 때 편리합니다. | | `certificate.key` | 문자열 | | [레지스트리](https://hub.docker.com/_/registry/) 컨테이너에 `auth.token.rootcertbundle`로 제공될 인증서 번들을 포함하는 `Secret`의 `key`의 이름입니다. | | `certificate.secret` | 문자열 | | GitLab 인스턴스에서 생성된 토큰을 확인하는 데 사용할 인증서 번들을 보유하는 [Kubernetes Secret](https://kubernetes.io/docs/concepts/configuration/secret/)의 이름입니다. | | `host` | 문자열 | | GitLab UI에서 사용자에게 Docker 명령을 제공하는 데 사용할 외부 호스트 이름입니다. 이 값이 없으면 `global.hosts`에 설정된 값(레지스트리 호스트 이름을 결정하는 `registry.hostname` 템플릿)을 사용합니다. 자세한 정보는 [글로벌 문서](../../globals.md)를 참조하십시오. | | `port` | 정수 | | 호스트 이름에 사용되는 외부 포트입니다. `80` 또는 `443` 포트를 사용하면 URL이 `http`/`https`로 형성됩니다. 기타 포트는 모두 `http`를 사용하고 호스트 이름 뒤에 포트를 추가합니다. 예를 들어 `http://registry.example.com:8443`. | | `tokenIssuer` | 문자열 | `gitlab-issuer` | 인증 토큰 발급자의 이름입니다. 기본값인 `gitlab-issuer`는 레지스트리 차트에서 사용하는 기본값과 동일합니다. | ## 차트 설정 다음 값은 Webservice 파드를 구성하는 데 사용됩니다. | 이름 | 유형 | 기본값 | 설명 | | :---------------- | :-----: | :------ | :---------------------------------------------------------------------------------------------------------------------------------------- | | `replicaCount` | 정수 | `1` | 배포에 생성할 Webservice 인스턴스의 수입니다. | | `workerProcesses` | 정수 | `2` | 파드당 실행할 Webservice worker의 수입니다. GitLab이 올바르게 기능하려면 클러스터에 적어도 `2`개의 worker가 있어야 합니다. `workerProcesses`를 늘리면 메모리가 약 `400MB`씩 필요하므로 pod `resources`를 해당 값으로 업데이트해야 합니다. | ### 메트릭 메트릭은 `metrics.enabled` 값으로 활성화되며 GitLab 모니터링 익스포터를 사용하여 메트릭 포트를 노출합니다. 파드에 Prometheus 주석이 지정되거나 `metrics.serviceMonitor.enabled`가 `true`로 설정된 경우 Prometheus Operator ServiceMonitor가 생성됩니다. 메트릭은 또한 `/-/metrics` 엔드포인트에서 스크랩될 수 있지만, 이는 [GitLab Prometheus 메트릭](https://docs.gitlab.com/ee/administration/monitoring/prometheus/gitlab_metrics.html)이 관리자 영역에서 활성화되어야 합니다. GitLab Workhorse 메트릭은 `workhorse.metrics.enabled`를 통해 노출되지만 Prometheus 주석을 사용하여 수집할 수는 없으므로 `workhorse.metrics.serviceMonitor.enabled`가 `true`로 설정되거나 외부 Prometheus 구성이 필요합니다. ### GitLab Shell GitLab Shell은 Webservice와의 통신에 사용되는 Auth Token을 사용합니다. 공유된 Secret을 사용하여 GitLab Shell과 Webservice에서 토큰을 공유합니다. ```yaml shell: authToken: secret: gitlab-shell-secret key: secret port: ``` | 이름 | 유형 | 기본값 | 설명 | | :----------------- | :-----: | :------ | :------------------------------------------------------------------------------------------------------------------ | | `authToken.key` | 문자열 | | 인증 토큰을 포함하는 Secret의 키의 이름을 정의합니다. | | `authToken.secret` | 문자열 | | 사용할 Kubernetes `Secret`의 이름을 정의합니다. | | `port` | 정수 | `22` | GitLab UI에서 SSH URL을 생성하는 데 사용할 포트 번호입니다. `global.shell.port`로 제어됩니다. | ### WebServer 옵션 현재 차트 버전은 Puma 웹 서버를 지원합니다. Puma 고유 옵션: | 이름 | 유형 | 기본값 | 설명 | | :--------------------- | :-----: | :------ | :--------------------------------------------------------- | | `puma.workerMaxMemory` | 정수 | | Puma 워커 킬러의 최대 메모리(메가바이트 단위) | | `puma.threads.min` | 정수 | `4` | Puma 스레드의 최소량 | | `puma.threads.max` | 정수 | `4` | Puma 스레드의 최대량 | ## `networkpolicy` 구성 이 섹션은 [NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/)를 제어합니다. 이 구성은 선택 사항이며, Pod의 Egress 및 Ingress를 특정 엔드포인트로 제한하는 데 사용됩니다. | 이름 | 유형 | 기본값 | 설명 | | :---------------- | :-----: | :------ | :-------------------------------------------------------------------------------------------------------------- | | `enabled` | 부울 | `false` | 이 설정은 `NetworkPolicy`를 활성화합니다. | | `ingress.enabled` | 부울 | `false` | `true`로 설정하면 `Ingress` 네트워크 정책이 활성화됩니다. 이 경우 규칙이 지정되지 않는 한 모든 Ingress 연결이 차단됩니다. | | `ingress.rules` | 배열 | `[]` | Ingress 정책에 대한 규칙입니다(자세한 내용은 <https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-networkpolicy-resource> 및 아래 예제 참조) | | `egress.enabled` | 부울 | `false` | `true`로 설정하면 `Egress` 네트워크 정책이 활성화됩니다. 이 경우 규칙이 지정되지 않는 한 모든 Egress 연결이 차단됩니다. | | `egress.rules` | 배열 | `[]` | Egress 정책에 대한 규칙입니다(자세한 내용은 <https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-networkpolicy-resource> 및 아래 예제를 참조) | ### 예시 네트워크 정책 웹서비스 서비스는 활성화된 경우 프로메테우스 익스포터 및 NGINX Ingress에서 오는 트래픽을 위한 인그레스 연결만을 필요로 합니다. 일반적으로 여러 곳으로부터의 이그레스 연결이 필요합니다. 이 예제는 다음과 같은 네트워크 정책을 추가합니다: - TCP `10.0.0.0/8` 포트 8080에서 네트워크로부터의 모든 인그레스 요청은 메트릭 익스포팅 및 NGINX Ingress를 위한 것으로 허용됩니다. - 모든 인그레스 요청은 포트 8181로 일반 서비스 운영을 위한 것으로 허용됩니다. - UDP `10.0.0.0/8` 포트 53으로 네트워크로의 모든 이그레스 요청은 DNS를 위한 것으로 허용됩니다. - TCP `10.0.0.0/8` 포트 5432로 네트워크로의 모든 이그레스 요청은 PostgreSQL을 위한 것으로 허용됩니다. - TCP `10.0.0.0/8` 포트 6379로 네트워크로의 모든 이그레스 요청은 Redis를 위한 것으로 허용됩니다. - TCP `10.0.0.0/8` 포트 8075로 네트워크로의 모든 이그레스 요청은 Gitaly를 위한 것으로 허용됩니다. - 로컬 네트워크로의 다른 이그레스 요청은 제한됩니다. - `10.0.0.0/8` 외부로의 이그레스 요청은 허용됩니다. _제공된 예시는 단순 예시이며 완벽하지 않을 수 있음에 유의하세요_ _웹서비스는 [외부 객체 리포지터리](../../../advanced/external-object-storage)의 이미지를 위해 공용 인터넷에 대한 아웃바운드 연결성이 필요합니다_ ```yaml networkpolicy: enabled: true ingress: enabled: true rules: - from: - ipBlock: cidr: 10.0.0.0/8 ports: - port: 8080 - from: ports: - port: 8181 egress: enabled: true rules: - to: - ipBlock: cidr: 10.0.0.0/8 ports: - port: 53 protocol: UDP - to: - ipBlock: cidr: 10.0.0.0/8 ports: - port: 5432 protocol: TCP - to: - ipBlock: cidr: 10.0.0.0/8 ports: - port: 6379 protocol: TCP - to: - ipBlock: cidr: 10.0.0.0/8 ports: - port: 8075 protocol: TCP - to: - ipBlock: cidr: 0.0.0.0/0 except: - 10.0.0.0/8 ``` ### 로드밸런서 서비스 `service.type`이 `LoadBalancer`로 설정된 경우, 클라우드 제공업체가 지원하는 경우 `service.loadBalancerIP`를 지정하여 `로드밸런서`를 생성할 수 있습니다. `service.type`이 `LoadBalancer`로 설정된 경우, 클라우드 제공업체가 지원하는 경우 `service.loadBalancerSourceRanges`를 설정하여 `로드밸런서`에 접근할 수 있는 CIDR 범위를 제한해야 합니다. 현재 [메트릭 포트가 노출](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2500)되는 문제로 현재 이를 설정해야만 합니다. `LoadBalancer` 서비스 유형에 대한 추가 정보는 [Kubernetes 문서](https://kubernetes.io/docs/concepts/services-networking/#loadbalancer)에서 찾을 수 있습니다. ```yaml service: type: LoadBalancer loadBalancerIP: 1.2.3.4 loadBalancerSourceRanges: - 10.0.0.0/8 ``` ## KEDA 구성 이 `keda` 섹션은 보통 `HorizontalPodAutoscalers` 대신 [KEDA](https://keda.sh/) `ScaledObjects`의 설치를 가능하게 합니다. 이 구성은 선택 사항이며 사용자 또는 외부 메트릭에 기반한 오토스케일링이 필요한 경우에 사용할 수 있습니다. 대부분의 설정은 해당되는 경우 `hpa` 섹션에 설정된 기본값을 따릅니다. 다음과 같은 경우에 CPU 및 메모리 트리거가 자동으로 추가됩니다: - `triggers`가 설정되지 않은 경우. - 해당하는 `request.cpu.request` 또는 `request.memory.request` 설정이 0이 아닌 값으로 설정된 경우. 트리거가 설정되지 않은 경우 `ScaledObject`가 생성되지 않습니다. 보다 자세한 설정에 관한 정보는 [KEDA 문서](https://keda.sh/docs/2.10/concepts/scaling-deployments/)를 참조하세요. | 이름 | 유형 | 기본값 | 설명 | | :---------------------------- | :-----: | :------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `enabled` | 부울 | `false` | `HorizontalPodAutoscalers` 대신 [KEDA](https://keda.sh/) `ScaledObjects` 사용 | | `pollingInterval` | 정수 | `30` | 각 트리거를 확인하는 간격 | | `cooldownPeriod` | 정수 | `300` | 스케일링된 리소스를 0으로 축소하기 전에 마지막 트리거가 활성으로 보고된 후 대기하는 기간 | | `minReplicaCount` | 정수 | | KEDA가 리소스를 축소할 때의 최소 레플리카 수, 기본값은 `minReplicas`로 설정됩니다 | | `maxReplicaCount` | 정수 | | KEDA가 리소스를 확장할 때의 최대 레플리카 수, 기본값은 `maxReplicas`로 설정됩니다 | | `fallback` | 맵 | | KEDA 대처 설정, [설명서](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback) 참조 | | `hpaName` | 문자열 | | KEDA가 생성할 HPA 리소스의 이름, 기본값은 `keda-hpa-{scaled-object-name}`입니다 | | `restoreToOriginalReplicaCount` | 부울 | | `ScaledObject`가 삭제된 후 대상 리소스를 기본 레플리카 수로 축소해야하는지 여부를 지정합니다 | | `behavior` | 맵 | | 업-다운스케일링 동작 사양, 기본값은 `hpa.behavior`로 설정됩니다 | | `triggers` | 배열 | | 대상 리소스의 스케일링을 활성화하는 트리거 디렉터리, 기본값은 `hpa.cpu` 및 `hpa.memory`로부터 계산된 트리거 디렉터리입니다 | 시크릿>중략>