• 에이전트 서버 비활성화
  • Ingress 지정
  • 설치 명령줄 옵션
• TLS 통신 활성화
• gitlab.kas.privateApi 속성을 통한 TLS 통신 활성화 (deprecated)
• kas 차트 테스트
• KEDA 구성

GitLab kas 차트 사용

kas sub-chart는 GitLab 에이전트 서버(KAS)의 구성 가능한 배포를 제공합니다. 에이전트 서버는 GitLab과 함께 설치되는 구성 요소로, Kubernetes용 GitLab 에이전트를 관리하는 데 필요합니다.

이 차트는 GitLab API 및 Gitaly 서버에 액세스해야 합니다. 차트를 활성화하면 Ingress가 배포됩니다.

최소한의 자원을 사용하기 위해 kas 컨테이너는 distroless 이미지를 사용합니다. 배포된 서비스는 통신을 위해 WebSocket 프록시를 사용하는 Ingress에 의해 노출됩니다. 이 프록시를 사용하면 외부 구성 요소와의 장기간 연결이 가능하며, agentk가 쿠버네티스 클러스터 측 에이전트 대응체입니다.

서비스에 액세스하는 경로는 Ingress configuration에 따라 달라집니다.

자세한 정보는 Kubernetes 아키텍처를 위한 GitLab 에이전트를 참조하세요.

에이전트 서버 비활성화

GitLab 에이전트 서버(kas)는 기본적으로 활성화되어 있습니다. GitLab 인스턴스에서 비활성화하려면 Helm 속성 global.kas.enabled를 false로 설정하세요.

예시:

helm upgrade --install kas --set global.kas.enabled=false

Ingress 지정

차트의 기본 구성을 사용하여 Ingress를 사용하면 에이전트 서버를 도달할 수 있는 서비스는 서브도메인에 도달할 수 있습니다. 예를 들어, global.hosts.domain: example.com의 경우, 에이전트 서버는 kas.example.com에서 도달할 수 있습니다.

KAS Ingress는 global.hosts.domain과 다른 도메인을 사용할 수 있습니다.

예시:

global.hosts.kas.name: kas.my-other-domain.com

이 예시는 kas.my-other-domain.com을 KAS Ingress의 호스트로 사용합니다. 나머지 서비스(포함하여 GitLab, 레지스트리, MinIO 등)는 global.hosts.domain에서 지정된 도메인을 사용합니다.

설치 명령줄 옵션

helm install 명령을 사용하여 이러한 매개변수를 --set 플래그를 사용하여 전달할 수 있습니다.

| Parameter | Default | Description | | ——————————————– | ——————————————————- | ———————————————————————————————————————————————————————————————————————————————————— | | … 중략 … | priorityClassName | | 파드에 할당된 우선순위 클래스. |

TLS 통신 활성화

• gitlab.kas.privateApi.tls.enabled 및 gitlab.kas.privateApi.tls.secretName 속성은 GitLab 15.8에서 deprecated되었으며, GitLab 17.0에서 제거될 예정입니다. 대신 전역 KAS 속성을 통해 TLS를 활성화하세요.

kas 팟과 다른 GitLab 차트 구성 요소 간의 TLS 통신을 활성화하세요. 전역 KAS 속성을 통해 TLS 통신을 활성화하세요.

gitlab.kas.privateApi 속성을 통한 TLS 통신 활성화 (deprecated)

경고: gitlab.kas.privateApi.tls.enabled 및 gitlab.kas.privateApi.tls.secretName 속성은 GitLab 15.8에서 deprecated되었으며, GitLab 17.0에서 제거될 예정입니다. 대신 전역 KAS 속성을 통해 TLS를 활성화하세요.

선행 조건:

• GitLab 15.5.1 이상을 사용하세요. GitLab 버전을 global.gitlabVersion: <version>으로 설정할 수 있습니다. 초기 배포 후 이미지 업데이트를 강제해야 하는 경우 global.image.pullPolicy: Always도 설정하세요.

1. kas 팟에서 신뢰할 수 있는 인증서 기관 및 인증서를 생성하세요.
2. 차트를 구성하여 신뢰할 수 있는 인증서를 사용하도록 설정하세요.
3. 선택 사항. TLS용 Redis 구성하세요.

생성한 인증서를 kas에서 사용하도록 구성하려면 다음 값을 설정하세요.

예를들어, 다음 values.yaml 파일을 사용하여 차트를 배포할 수 있습니다:

   .internal-ca: &internal-ca gitlab-internal-tls-ca # 사용한 TLS CA를 공유하는 시크릿 이름.
   .internal-tls: &internal-tls gitlab-internal-tls # 사용한 TLS 인증서를 공유하는 시크릿 이름.

   global:
     certificates:
       customCAs:
       - secret: *internal-ca
     hosts:
       domain: gitlab.example.com # 귀하의 gitlab 도메인
     appConfig:
       gitlab_kas:
         internalUrl: "grpcs://RELEASE-kas.NAMESPACE.svc:8153" # 차트의 릴리스 및 네임스페이스를 사용하여 RELEASE 및 NAMESPACE를 교체하세요.

   gitlab:
     kas:
       privateApi:
         tls:
           enabled: true
           secretName: *internal-tls
       customConfig:
         api:
           listen:
             certificate_file: /etc/kas/tls.crt
             key_file: /etc/kas/tls.key
         agent:
           listen:
             certificate_file: /etc/kas/tls.crt
             key_file: /etc/kas/tls.key
           kubernetes_api:
             listen:
               certificate_file: /etc/kas/tls.crt
               key_file: /etc/kas/tls.key
       ingress:
         annotations:
           nginx.ingress.kubernetes.io/backend-protocol: https
           nginx.ingress.kubernetes.io/proxy-ssl-name: RELEASE-kas.NAMESPACE.svc # 차트의 릴리스 및 네임스페이스를 사용하여 RELEASE 및 NAMESPACE를 교체하세요.
           nginx.ingress.kubernetes.io/proxy-ssl-secret: NAMESPACE/CA-SECRET-NAME # 차트의 네임스페이스 및 CA 시크릿 이름을 사용하여 NAMESPACE 및 CA-SECRET-NAME을 교체하세요. &internal-ca에 사용한 것과 동일한 시크릿입니다.
           nginx.ingress.kubernetes.io/proxy-ssl-verify: on

kas 차트 테스트

차트를 설치하려면:

1. 별도의 Kubernetes 클러스터를 만드세요.
2. MR의 작업 브랜치를 확인하세요.

3. 로컬 차트 브랜치에서 기본적으로 활성화된 kas를 사용하여 GitLab을 설치(또는 업그레이드)하세요:

   helm upgrade --force --install gitlab . \
     --timeout 600s \
     --set global.hosts.domain=your.domain.com \
     --set global.hosts.externalIP=XYZ.XYZ.XYZ.XYZ \
     --set certmanager-issuer.email=your@email.com
   

4. GDK를 사용하여 GitLab Kubernetes에 대한 에이전트 설정 및 사용 프로세스를 실행하세요: (수동으로 에이전트 설정 및 사용 단계를 따를 수도 있습니다.)

   1. GDK GitLab 저장소에서 QA 폴더로 이동하세요: cd qa.

   2. 다음 명령을 실행하여 QA 테스트를 실행하세요:

      GITLAB_USERNAME=$ROOT_USER
      GITLAB_PASSWORD=$ROOT_PASSWORD
      GITLAB_ADMIN_USERNAME=$ROOT_USER
      GITLAB_ADMIN_PASSWORD=$ROOT_PASSWORD
      bundle exec bin/qa Test::Instance::All https://your.gitlab.domain/ -- --tag orchestrated --tag quarantine qa/specs/features/ee/api/7_configure/kubernetes/kubernetes_agent_spec.rb
      

      또한 환경 변수를 사용하여 설치할 agentk 버전을 사용자 정의할 수도 있습니다: GITLAB_AGENTK_VERSION=v13.7.1

KEDA 구성

이 keda 섹션은 일반 HorizontalPodAutoscalers 대신 KEDA ScaledObjects를 설치할 수 있도록 합니다. 이 구성은 선택 사항이며 사용자 지정 또는 외부 메트릭에 기반한 자동 크기 조정이 필요한 경우에 사용할 수 있습니다.

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

다음과 같은 사항이 참이면 CPU 및 메모리 트리거가 자동으로 추가됩니다. 이때는 hpa 섹션에 설정된 CPU 및 메모리 임계값에 따라 triggers가 설정되지 않아야 하고, 해당하는 request.cpu.request 또는 request.memory.request 설정도 0이 아닌 값으로 설정되어 있어야 합니다.

• triggers가 설정되지 않은 경우
• 해당하는 request.cpu.request나 request.memory.request 설정도 0이 아닌 값으로 설정된 경우

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

그 설정에 대한 자세한 내용은 KEDA 문서를 참조하세요.