# 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.livenessProbe
와 deployment.readinessProbe
는 일부 시나리오에서 파드의 종료를 제어하는 메커니즘을 제공합니다.
크기가 큰 저장소는 일반적으로 오래 실행되는 연결에 맞게 liveness 및 readiness probe 시간을 조절합니다. clone
및 push
작업 중에 잠재적인 중단을 최소화하기 위해 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.type
이 LoadBalancer
로 설정된 경우, 선택적으로 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
의 내용을 무시하지 않고 확장합니다.
예를 들어, extraVolumes
및 extraVolumeMounts
를 통해 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.cpu 및 hpa.memory 에서 계산된 트리거로 설정됩니다.
|
keda
의 사용 예시는 examples/keda/gitlab-shell.yml
을 참조하세요.