GitLab Shell 차트 사용하기
gitlab-shell
하위 차트는 GitLab에 대한 Git SSH 액세스를 위해 구성된 SSH 서버를 제공합니다.
요구 사항
이 차트는 완전한 GitLab 차트의 일부로서 또는 이 차트가 배포된 Kubernetes 클러스터에서 접근 가능한 외부 서비스로서 Workhorse 서비스에 의존합니다.
설계 선택 사항
SSH 레플리카를 쉽게 지원하고 SSH 인가 키에 대한 공유 스토리지 사용을 피하기 위해 SSH AuthorizedKeysCommand를 사용하여 GitLab 인가 키 엔드포인트에 대해 인증합니다. 그 결과로 인해 이러한 파드 내에서 AuthorizedKeys 파일을 지속적으로 유지하거나 업데이트하지 않습니다.
구성
gitlab-shell
차트는 외부 서비스 및 차트 설정 두 부분으로 구성됩니다. Ingress를 통해 노출된 포트는 global.shell.port
로 구성되며 기본값은 22
입니다. Service의 외부 포트도 global.shell.port
에 의해 제어됩니다.
설치 명령줄 옵션
| 매개변수 | 기본값 | 설명 |
| ————————————– | ——————————————————————————————————————————————————————- | ————————————————————————————- |
| annotations
| | Pod 어노테이션 |
| podLabels
| | 보조 Pod 라벨. 선택기에는 사용되지 않습니다. |
| common.labels
| | 이 차트에 의해 생성된 모든 객체에 적용되는 보조 라벨 |
| config.clientAliveInterval
| 0
| 그 외의 유일한 연결에 대한 keepalive 핑 사이의 간격입니다. 기본값 0은 이 핑을 비활성화합니다 |
| config.loginGraceTime
| 60
| 사용자가 성공적으로 로그인하지 않았을 경우 서버가 연결을 해제할 시간을 지정합니다. |
…
(중략)
…
차트 구성 예시
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 시간을 조정하면 이점을 얻을 수 있습니다. 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
를 사용하면 지정된 worker 노드에서 파드를 예약할 수 있습니다.
아래는 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
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
host
| String | Workhorse 서버의 호스트 이름입니다. 이는 serviceName 으로 대체할 수 있습니다.
| |
port
| Integer | 8181
| Workhorse 서버에 연결할 포트입니다. |
serviceName
| String | webservice
| Workhorse 서버를 운영하는 service 의 이름입니다. 기본적으로 Workhorse는 webservice 파드/서비스의 일부입니다. 이 값이 존재하고 host 가 없는 경우, 차트는 host 값을 현재 .Release.Name 의 서비스 호스트 이름으로 템플릿화합니다. 이는 Workhorse를 전체 GitLab 차트의 일부로 사용할 때 편리합니다.
|
차트 설정
다음 값은 GitLab Shell 파드를 구성하는 데 사용됩니다.
hostKeys.secret
GitLab Shell에서 SSH 호스트 키를 가져올 쿠버네티스 secret
의 이름입니다. secret의 키는 GitLab Shell에서 사용하기 위해 ssh_host_
키 이름으로 시작해야 합니다.
authToken
GitLab Shell은 Workhorse와의 통신에서 Auth Token을 사용합니다. 이를 공유하여 GitLab Shell 및 Workhorse가 공유 Secret을 사용하는 방법입니다.
authToken:
secret: gitlab-shell-secret
key: secret
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
authToken.key
| String | 위의 secret에서 인증 토큰을 포함하는 키 이름 | |
authToken.secret
| String | 가져올 쿠버네티스 Secret 의 이름
|
LoadBalancer 서비스
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
컨테이너에 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를 특정 엔드포인트로 제한하는 데 사용됩니다.
Name | Type | Default | Description |
---|---|---|---|
enabled
| Boolean | false
| 해당 설정은 NetworkPolicy 를 활성화합니다.
|
ingress.enabled
| Boolean | false
|
true 로 설정하면 Ingress 네트워크 정책이 활성화됩니다. 이로 인해 규칙이 지정되지 않은 경우 모든 Ingress 연결이 차단됩니다.
|
ingress.rules
| Array | []
| Ingress 정책에 대한 규칙에 대한 자세한 내용은 https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-networkpolicy-resource 및 아래 예제를 참조하십시오. |
egress.enabled
| Boolean | false
|
true 로 설정하면 Egress 네트워크 정책이 활성화됩니다. 이로 인해 규칙이 지정되지 않은 경우 모든 Egress 연결이 차단됩니다.
|
egress.rules
| Array | []
| Egress 정책에 대한 규칙에 대한 자세한 내용은 https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-networkpolicy-resource 및 아래 예제를 참조하십시오. |
네트워크 정책 예시
gitlab-shell
서비스는 기본적으로 포트 22 및 다양한 기본 workhorse 포트 8181으로 Ingress 연결 및 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
섹션은 일반적인 HorizontalPodAutoscalers
대신 KEDA ScaledObjects
의 설치를 가능하게 합니다. 이 구성은 선택 사항이며 사용자 정의 또는 외부 메트릭에 기반한 오토스케일링이 필요한 경우에 사용될 수 있습니다.
해당되는 경우 대부분의 설정은 hpa
섹션에 설정된 값으로 기본값을 가집니다.
다음 조건을 충족하면 CPU 및 메모리 트리거가 자동으로 추가되며 hpa
섹션에서 설정한 CPU 및 메모리 임계값을 기반으로 합니다.
-
triggers
가 설정되지 않은 경우 - 해당하는
request.cpu.request
또는request.memory.request
설정이 0이 아닌 값을 가질 경우
트리거가 설정되지 않으면 ScaledObject
는 생성되지 않습니다.
더 자세한 내용은 KEDA 문서를 참조하십시오.
Name | Type | Default | Description |
---|---|---|---|
enabled
| Boolean | false
|
HorizontalPodAutoscalers 대신 KEDA ScaledObjects 를 사용합니다.
|
pollingInterval
| Integer | 30
| 각 트리거를 확인하는 간격 |
cooldownPeriod
| Integer | 300
| 최근 트리거가 활성 상태를 보고한 후 리소스를 0으로 다시 축소하는 기간 |
minReplicaCount
| Integer | KEDA가 리소스를 축소시킬 최소 복제본 수로, minReplicas 로 기본값을 지닙니다.
| |
maxReplicaCount
| Integer | KEDA가 리소스를 확장시킬 최대 복제본 수로, maxReplicas 로 기본값을 지닙니다.
| |
fallback
| Map | KEDA 후속 구성, 자세한 내용은 문서를 참조하십시오. | |
hpaName
| String | KEDA가 생성할 HPA 리소스의 이름으로, keda-hpa-{scaled-object-name} 로 기본값을 지닙니다.
| |
restoreToOriginalReplicaCount
| Boolean |
ScaledObject 가 삭제된 후 대상 리소스를 원래 복제본 수로 축소해야 하는지 여부를 지정합니다.
| |
behavior
| Map | 업-다운 스케일링 동작에 대한 사양으로, 기본값은 hpa.behavior 로 설정됩니다.
| |
triggers
| Array | 대상 리소스의 스케일링을 활성화할 트리거 디렉터리으로, 기본값은 hpa.cpu 및 hpa.memory 에서 계산된 트리거입니다.
|
examples/keda/gitlab-shell.yml
파일에서 keda
의 사용 예시를 확인하십시오.