# GitLab Shell 차트 사용하기

DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** Self-Managed

`gitlab-shell` 서브 차트는 GitLab에 대한 Git SSH 액세스를 위해 구성된 SSH 서버를 제공합니다.

## 요구 사항

이 차트는 완전한 GitLab 차트의 일부로 제공되는 Workhorse 서비스에 대한 액세스에 종속됩니다.

또는 이 차트가 배포된 Kubernetes 클러스터에서 도달 가능한 외부 서비스로 제공됩니다.

## 디자인 선택 사항

SSH 복제를 쉽게 지원하고 SSH 인가된 키에 대한 공유 스토리지 사용을 피하기 위해 SSH [AuthorizedKeysCommand](https://man.openbsd.org/sshd_config#AuthorizedKeysCommand)를 사용하여 GitLab 인가된 키 엔드포인트에 대한 인가를 수행합니다. 따라서 이러한 파드 내에서 AuthorizedKeys 파일을 지속하지 않거나 업데이트하지 않습니다.

## 설정

`gitlab-shell` 차트는 두 부분으로 구성됩니다: [외부 서비스](#external-services)[차트 설정](#chart-settings). Ingress를 통해 노출된 포트는 `global.shell.port`로 구성되며 기본값은 `22`입니다. 서비스의 외부 포트도 `global.shell.port`로 제어됩니다.

## 설치 명령줄 옵션

| 매개변수                  | 기본값                                                                                                                                             | 설명                                                                                                                                                 |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| `annotations`           |                                                                                                                                                   | Pod 어노테이션                                                                                                                                         |
| `podLabels`             |                                                                                                                                                   | 보조 Pod 라벨입니다. 선택기로 사용되지 않을 것입니다.                                                                                                       |
| `common.labels`         |                                                                                                                                                   | 이 차트에 의해 생성된 모든 객체에 적용되는 보조 라벨입니다.                                                                                                          |
| `config.clientAliveInterval` | `0`                                                                                                                                           | 유휴 상태의 연결에서 keepalive 핑 간의 간격; 기본값 0은 이 핑을 비활성화합니다.                                                                                     |
| ... (이하 생략)

… (전체 번역 생략)

차트 구성 예시

extraEnv

extraEnv를 사용하면 파드의 모든 컨테이너에서 추가 환경 변수를 노출시킬 수 있습니다.

아래는 extraEnv의 사용 예시입니다:

extraEnv:
  SOME_KEY: some_value
  SOME_OTHER_KEY: some_other_value

컨테이너가 시작되면 환경 변수가 노출되었는지 확인할 수 있습니다:

env | grep SOME
SOME_KEY=some_value
SOME_OTHER_KEY=some_other_value

extraEnvFrom

extraEnvFrom을 사용하면 파드의 모든 컨테이너에서 다른 데이터 소스에서 추가 환경 변수를 노출시킬 수 있습니다.

아래는 extraEnvFrom의 사용 예시입니다:

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
  CONFIG_STRING:
    configMapKeyRef:
      name: useful-config
      key: some-string
      # optional: boolean

image.pullSecrets

pullSecrets를 사용하면 파드에서 이미지를 가져오기 위해 개인 레지스트리에 인증할 수 있습니다.

개인 레지스트리 및 해당 인증 방법에 대한 자세한 내용은 Kubernetes 문서에서 찾을 수 있습니다.

아래는 pullSecrets의 사용 예시입니다:

image:
  repository: my.shell.repository
  tag: latest
  pullPolicy: Always
  pullSecrets:
  - name: my-secret-name
  - name: my-secondary-secret-name

livenessProbe/readinessProbe

deployment.livenessProbedeployment.readinessProbe는 일부 시나리오에서 파드의 종료를 제어하는 메커니즘을 제공합니다.

크기가 큰 저장소는 일반적으로 오래 실행되는 연결에 맞게 liveness 및 readiness probe 시간을 조절합니다. clonepush 작업 중에 잠재적인 중단을 최소화하기 위해 readiness probe의 기간을 liveness probe의 기간보다 짧게 설정합니다. 스케줄러가 파드를 종료하기 전에 terminationGracePeriodSeconds를 늘리고 이러한 작업에 더 많은 시간을 부여합니다. 큰 저장소 워크로드에 대해 GitLab Shell 파드를 안정성과 효율성을 높이기 위한 시작점으로 아래 예시를 참조하세요.

deployment:
  livenessProbe:
    initialDelaySeconds: 10
    periodSeconds: 20
    timeoutSeconds: 3
    successThreshold: 1
    failureThreshold: 10
  readinessProbe:
    initialDelaySeconds: 10
    periodSeconds: 5
    timeoutSeconds: 2
    successThreshold: 1
    failureThreshold: 3
  terminationGracePeriodSeconds: 300

이 구성에 대한 자세한 내용은 공식 Kubernetes 문서를 참조하세요.

tolerations

tolerations을 사용하면 tainted 워커 노드에 파드를 예약할 수 있습니다.

아래는 tolerations의 사용 예시입니다:

tolerations:
- key: "node_label"
  operator: "Equal"
  value: "true"
  effect: "NoSchedule"
- key: "node_label"
  operator: "Equal"
  value: "true"
  effect: "NoExecute"

annotations

annotations를 사용하면 GitLab Shell 파드에 주석을 추가할 수 있습니다.

아래는 annotations의 사용 예시입니다:

annotations:
  kubernetes.io/example-annotation: annotation-value

외부 서비스

이 차트는 Workhorse 서비스에 연결되어야 합니다.

Workhorse

workhorse:
  host: workhorse.example.com
  serviceName: webservice
  port: 8181
Name Type Default Description
host String   Workhorse 서버의 호스트명입니다. 이는 serviceName 대신에 생략할 수 있습니다.
port Integer 8181 Workhorse 서버에 연결할 포트입니다.
serviceName String webservice Workhorse 서버를 운영하는 service의 이름입니다. 기본적으로 Workhorse는 webservice 파드/서비스의 일부입니다. 이 값이 존재하고 host가 없다면 차트는 host 값을 현재 .Release.Name의 서비스의 호스트명으로 지정합니다. GitLab 차트 전체를 사용할 때 편리합니다.

차트 설정

다음 값들은 GitLab Shell 파드를 구성하는 데 사용됩니다.

hostKeys.secret

SSH 호스트 키를 가져올 Kubernetes secret의 이름입니다. 시크릿에 있는 키는 GitLab Shell에서 사용하려면 키 이름이 ssh_host_로 시작해야 합니다.

authToken

GitLab Shell은 Workhorse와의 통신에서 Auth Token을 사용합니다. 공유된 비밀을 사용하여 GitLab Shell과 Workhorse에 토큰을 공유하세요.

authToken:
 secret: gitlab-shell-secret
 key: secret
이름 유형 기본값 설명
authToken.key 문자열   위의 비밀에 포함된 키의 이름으로 auth 토큰을 포함합니다.
authToken.secret 문자열   가져올 Kubernetes Secret의 이름입니다.

LoadBalancer Service

service.typeLoadBalancer로 설정된 경우, 선택적으로 service.loadBalancerIP를 지정하여 사용자 지정 IP로 LoadBalancer를 만들 수 있습니다 (클라우드 제공업체가 지원하는 경우).

또한 선택적으로 service.loadBalancerSourceRanges 목록을 지정하여 LoadBalancer에 액세스할 수 있는 CIDR 범위를 제한할 수 있습니다 (클라우드 제공자가 지원하는 경우).

LoadBalancer 서비스 유형에 대한 자세한 정보는 Kubernetes 문서에서 찾을 수 있습니다.

service:
  type: LoadBalancer
  loadBalancerIP: 1.2.3.4
  loadBalancerSourceRanges:
  - 5.6.7.8/32
  - 10.0.0.0/8

OpenSSH 보조 구성

OpenSSH의 sshd(via .sshDaemon: openssh)을 사용할 때, 두 가지 방법으로 보조 구성을 제공할 수 있습니다: .opensshd.supplemental_config/etc/ssh/sshd_config.d/*.conf에 구성 스니펫을 마운트할 수 있습니다.

제공된 모든 구성은 sshd_config의 기능적 요구 사항을 충족해야 합니다. 매뉴얼 페이지를 반드시 읽어보세요.

opensshd.supplemental_config

.opensshd.supplemental_config의 내용은 컨테이너 내의 sshd_config 파일 끝에 직접 배치됩니다. 이 값은 여러 줄의 문자열이어야 합니다.

예를 들어, ssh-rsa 키 교환 알고리즘을 사용하여 이전 클라이언트를 활성화하는 경우입니다. ssh-rsa와 같이 사용되는 폐기된 알고리즘을 활성화하는 것은 중대한 보안 취약점을 만듭니다. 이러한 변경 사항은 공개적으로 노출된 GitLab 인스턴스에서 중대한 취약점을 크게 증폭시킵니다.

opensshd:
    supplemental_config: |-
      HostKeyAlgorithms +ssh-rsa,ssh-rsa-cert-v01@openssh.com
      PubkeyAcceptedAlgorithms +ssh-rsa,ssh-rsa-cert-v01@openssh.com
      CASignatureAlgorithms +ssh-rsa

sshd_config.d

sshd에 완전한 구성 스니펫을 제공할 수 있으며, *.conf와 일치하는 파일을 /etc/ssh/sshd_config.d에 마운트할 수 있습니다. 기본 구성을 확장하기 위해 필요한 응용 프로그램 및 차트 기능을 Container 내에서 제공합니다. 이 값은 sshd_config의 내용을 무시하지 않고 확장합니다.

예를 들어, extraVolumesextraVolumeMounts를 통해 ConfigMap의 단일 항목을 컨테이너 내에 마운트하는 방법:

extraVolumes: |
  - name: gitlab-sshdconfig-extra
    configMap:
      name: gitlab-sshdconfig-extra

extraVolumeMounts: |
  - name: gitlab-sshdconfig-extra
    mountPath: /etc/ssh/sshd_config.d/extra.conf
    subPath: extra.conf

networkpolicy 구성

이 섹션은 NetworkPolicy를 제어합니다. 이 구성은 선택 사항이며 Pod의 Egress 및 Ingress를 특정 엔드포인트로 제한하는 데 사용됩니다.

이름 유형 기본값 설명
enabled 불리언 false 이 설정은 NetworkPolicy를 활성화합니다.
ingress.enabled 불리언 false true로 설정되면 Ingress 네트워크 정책이 활성화됩니다. 이는 rules이 지정되지 않은 경우 모든 Ingress 연결을 차단합니다.
ingress.rules 배열 [] Ingress 정책에 대한 규칙에 대한 자세한 내용은 https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-networkpolicy-resource 및 아래 예제를 참조
egress.enabled 불리언 false true로 설정되면 Egress 네트워크 정책이 활성화됩니다. 이는 rules이 지정되지 않은 경우 모든 Egress 연결을 차단합니다.
egress.rules 배열 [] Egress 정책에 대한 규칙에 대한 자세한 내용은 https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-networkpolicy-resource 및 아래 예제를 참조

네트워크 정책 예시

gitlab-shell 서비스는 포트 22의 인바운드 연결과 다양한 기본 workhorse 포트 8181의 아웃바운드 연결이 필요합니다. 이 예시는 다음과 같은 네트워크 정책을 추가합니다:

  • TCP 0.0.0.0/0의 네트워크에서 오는 모든 인바운드 요청은 포트 2222에서 허용됩니다.
  • DNS를 위해 UDP 10.0.0.0/8의 네트워크로 나가는 모든 아웃바운드 요청은 포트 53에서 허용됩니다.
  • Workhorse를 위해 TCP 10.0.0.0/8의 네트워크로 나가는 모든 아웃바운드 요청은 포트 8181에서 허용됩니다.
  • Gitaly를 위해 TCP 10.0.0.0/8의 네트워크로 나가는 모든 아웃바운드 요청은 포트 8075에서 허용됩니다.

주어진 예시는 단순히 예시일 뿐이며 완벽하지 않을 수 있음을 참고하세요

networkpolicy:
  enabled: true
  ingress:
    enabled: true
    rules:
      - from:
        - ipBlock:
            cidr: 0.0.0.0/0
        ports:
          - port: 2222
            protocol: TCP
  egress:
    enabled: true
    rules:
      - to:
        - ipBlock:
            cidr: 10.0.0.0/8
        ports:
          - port: 8181
            protocol: TCP
          - port: 8075
            protocol: TCP
          - port: 53
            protocol: UDP

KEDA 구성

keda 섹션은 KEDA ScaledObjects의 일반적인 HorizontalPodAutoscalers 대신 설치를 가능하게 합니다. 이 구성은 선택적이며, 사용자 정의 또는 외부 메트릭을 기반으로 자동 스케일링이 필요한 경우에 사용할 수 있습니다.

대부분의 설정은 해당되는 경우 hpa 섹션에 설정된 값으로 기본 설정됩니다.

다음 조건이 참이면, CPU 및 메모리 트리거는 자동으로 추가되며 hpa 섹션에서 설정된 CPU 및 메모리 임계값에 따라 자동으로 추가됩니다:

  • triggers가 설정되지 않음.
  • 해당하는 request.cpu.request 또는 request.memory.request 설정도 0이 아닌 값으로 설정됨.

트리거가 설정되지 않으면 ScaledObject가 생성되지 않습니다.

더 많은 정보를 원하시면 KEDA 문서를 참조하세요.

이름 타입 기본값 설명
enabled 부울 false KEDA ScaledObjects 대신 HorizontalPodAutoscalers 사용
pollingInterval 정수 30 각 트리거를 확인하는 간격
cooldownPeriod 정수 300 스케일링 대상 리소스를 0으로 다시 스케일링하기 전에 마지막 트리거가 활성 상태로 보고된 후 기다리는 기간
minReplicaCount 정수   KEDA가 스케일링 대상 리소스를 축소할 때의 최소 복제본 수이며, minReplicas로 기본 설정됩니다.
maxReplicaCount 정수   KEDA가 스케일링 대상 리소스를 확장할 때의 최대 복제본 수이며, maxReplicas로 기본 설정됩니다.
fallback   KEDA 대체 구성, 문서 참조
hpaName 문자열   KEDA가 생성할 HPA 리소스의 이름이며, keda-hpa-{scaled-object-name}으로 기본 설정됩니다.
restoreToOriginalReplicaCount 부울   ScaledObject가 삭제된 후 대상 리소스를 원래 복제본 수로 다시 스케일링할지 여부를 지정합니다.
behavior   업-다운스케일링 동작에 대한 사양으로, 기본적으로 hpa.behavior로 설정됩니다.
triggers 배열   대상 리소스의 스케일링을 활성화하기 위한 트리거 목록으로, 기본적으로 hpa.cpuhpa.memory에서 계산된 트리거로 설정됩니다.

keda의 사용 예시는 examples/keda/gitlab-shell.yml을 참조하세요.