GitLab Shell 차트 사용
gitlab-shell
서브 차트는 Git SSH 액세스를 위해 구성된 SSH 서버를 제공합니다.
요구 사항
이 차트는 완전한 GitLab 차트의 일부로서 또는 이 차트가 배포된 Kubernetes 클러스터에서 도달할 수 있는 외부 서비스로 제공되는 Workhorse 서비스에 의존합니다.
설계 선택 사항
SSH 복제본을 쉽게 지원하고 SSH 공인 키에 대한 공유 저장소를 피하기 위해 GitLab 공인 키 엔드포인트의 인증을 위해 SSH AuthorizedKeysCommand를 사용합니다. 이로 인해 이러한 팟 안에 AuthorizedKeys 파일을 유지하거나 업데이트하지 않습니다.
구성
gitlab-shell
차트는 외부 서비스 및 차트 설정 두 부분으로 구성되어 있습니다. Ingress를 통해 노출된 포트는 global.shell.port
로 구성되며 기본값은 22
입니다. Service의 외부 포트도 global.shell.port
에 의해 제어됩니다.
설치 명령줄 옵션
매개변수 | 기본값 | 설명 |
---|---|---|
affinity
| {}
| 팟 할당을 위한 Affinity rules |
annotations
| 팟 주석 | |
podLabels
| 보조 팟 레이블. 셀렉터에 사용되지는 않음. |
(중략)
metrics.annotations
| DEPRECATED 명시적인 메트릭 주석 설정. 템플릿 내용에 대체됨. |
차트 구성 예시
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 documentation에서 찾을 수 있습니다.
아래는 pullSecrets
의 사용 예시입니다:
image:
repository: my.shell.repository
tag: latest
pullPolicy: Always
pullSecrets:
- name: my-secret-name
- name: my-secondary-secret-name
serviceAccount
이 섹션은 ServiceAccount가 생성되어야 하는지 여부 및 기본 액세스 토큰이 포드에 장착되어야 하는지 여부를 제어합니다.
Name | Type | Default | Description |
---|---|---|---|
annotations
| Map | {}
| ServiceAccount 주석. |
automountServiceAccountToken
| Boolean | false
| 기본 ServiceAccount 액세스 토큰이 포드에 장착되어야 하는지 여부를 제어합니다. 이 기능은 특정 사이드카가 올바르게 작동하기 위해 필요할 때를 제외하고 사용하면 안 됩니다(예: Istio). |
create
| Boolean | false
| ServiceAccount가 생성되어야 하는지 여부를 나타냅니다. |
enabled
| Boolean | false
| ServiceAccount를 사용해야 하는지 여부를 나타냅니다. |
name
| String | ServiceAccount의 이름입니다. 설정되지 않은 경우 전체 차트 이름이 사용됩니다. |
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
을 사용하면 테인트된 워커 노드에서 포드를 스케줄링할 수 있습니다.
아래는 tolerations
의 사용 예시입니다:
tolerations:
- key: "node_label"
operator: "Equal"
value: "true"
effect: "NoSchedule"
- key: "node_label"
operator: "Equal"
value: "true"
effect: "NoExecute"
affinity
자세한 내용은 affinity
를 참조하십시오.
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 Pods / Service의 일부입니다. 이 값이 제공되고 host 가 아닌 경우 차트는 host 값을 현재 .Release.Name 의 서비스의 호스트 이름으로 템플릿화합니다. GitLab 차트 전체를 사용하는 경우 편리합니다.
|
차트 설정
다음 값들은 GitLab Shell Pods를 구성하는 데 사용됩니다.
hostKeys.secret
SSH 호스트 키를 가져 오기 위해 쿠버네티스 secret
의 이름입니다. Secret의 키는 ssh_host_
라는 키 이름으로 시작해야 GitLab Shell에서 사용될 수 있습니다.
authToken
GitLab Shell은 Workhorse와의 통신에서 Auth Token을 사용합니다. 공유 Secret을 사용하여 GitLab Shell 및 Workhorse 사이에서 토큰을 공유합니다.
authToken:
secret: gitlab-shell-secret
key: secret
Name | Type | Default | Description |
---|---|---|---|
authToken.key
| String | 위의 Secret에서 인증 토큰을 포함하는 키의 이름입니다. | |
authToken.secret
| String | 가져올 쿠버네티스 Secret 의 이름입니다.
|
로드밸런서 서비스
만약 service.type
이 LoadBalancer
로 설정되어 있다면, 클라우드 공급업체가 지원하는 경우 사용자 지정 IP를 사용하여 LoadBalancer
를 생성할 수 있는 service.loadBalancerIP
를 선택적으로 지정할 수 있습니다.
또한, 클라우드 공급업체가 지원하는 경우 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
(최신 .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
로 전체 구성 스니펫을 제공하려면 /etc/ssh/sshd_config.d
로 마운트하여 *.conf
와 일치하는 파일을 사용합니다. 참고로, 이들은 응용 프로그램이 컨테이너와 차트에서 작동하는 데 필요한 기본 구성 이후에 포함되며. 이 값들은 sshd_config
의 내용을 덮어쓰지 않고 확장합니다.
예시로, ConfigMap의 단일 항목을 extraVolumes
및 extraVolumeMounts
를 통해 컨테이너에 마운트합니다.
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 네트워크 정책이 활성화됩니다. 이는 규칙이 지정되지 않으면 모든 Ingress 연결을 차단합니다.
|
ingress.rules
| 배열 | []
| Ingress 정책에 대한 규칙, 자세한 내용은 여기와 아래 예시 참조 |
egress.enabled
| 불리언 | false
|
true 로 설정하면 Egress 네트워크 정책이 활성화됩니다. 이는 규칙이 지정되지 않으면 모든 Egress 연결을 차단합니다.
|
egress.rules
| 배열 | []
| Egress 정책에 대한 규칙, 자세한 내용은 여기와 아래 예시 참조 |
네트워크 정책 예시
gitlab-shell
서비스에는 포트 22로의 Ingress 연결 및 다양한 기본 workhorse 포트 8181로의 Egress 연결이 필요합니다. 다음은 추가된 네트워크 정책입니다.
- 모든 네트워크에서 TCP
0.0.0.0/0
포트 2222로의 Ingress 요청이 허용됩니다. - DNS를 위해 UDP
10.0.0.0/8
포트 53으로의 Egress 요청이 허용됩니다. - Workhorse를 위해 TCP
10.0.0.0/8
포트 8181으로의 Egress 요청이 허용됩니다. - Gitaly를 위해 TCP
10.0.0.0/8
포트 8075으로의 Egress 요청이 허용됩니다.
제공된 예시는 단순히 예시일 뿐이며 완전하지 않을 수 있음에 주의하세요.
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 및 메모리 트리거가 자동으로 추가됩니다:
- triggers
가 설정되지 않았음
- request.cpu.request
또는 request.memory.request
설정이 0이 아닌 값으로 설정되어 있음
트리거가 설정되지 않은 경우, ScaledObject
는 생성되지 않습니다.
더 많은 세부 정보는 KEDA 문서를 참조하세요.
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
enabled
| 불리언 | false
|
HorizontalPodAutoscalers 대신 KEDA ScaledObjects 를 사용합니다
|
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
에서 확인할 수 있습니다.