디자인 결정

이 문서는 이 저장소의 Helm 차트 설계에 대한 이유와 결정을 수집합니다. 제안은 환영하며, 결정을 적용하는 방법은 의사 결정를 참조하십시오.

문제 있는 구성 잡기 시도

이 차트의 복잡성과 유연성 수준으로 인해 예측할 수 없거나 완전히 비기능적인 배포로 이어지는 구성을 생성할 가능성이 있는 일부 중복이 있습니다.

알려진 문제 설정 조합을 방지하기 위해, 우리는 사용자가 자신의 구성으로 인해 작동하지 않을 것임을 감지하고 경고하는 템플릿 로직을 구현했습니다.

이것은 API(비구조적 설정)의 동작을 반복하지만, 기능적인 구성을 보장하는 데 특별화되어 있습니다.

!757 checkConfig: add methods to test for known errors에서 도입되었습니다.

더 이상 사용되지 않는 기능을 통한 파괴적 변경

이 차트의 개발 중에 우리는 종종 기존 배포의 속성을 변경해야 하는 개선을 합니다.

예를 들어, MinIO 사용을 구성하는 중앙 집중화와 외부 객체 저장소 구성을 속성에서 비밀로 마이그레이션하는 것입니다(우리의 선호도를 따릅니다).

사용자가 작동하지 않는 구성의 파괴적 변경을 포함하는 이 차트의 업데이트된 버전을 실수로 배포하지 못하도록 하기 위해, 우리는 더 이상 사용되지 않는 기능 알림 기능을 구현하기로 결정했습니다. 이는 속성이 이동되거나, 변경되거나, 교체되거나, 완전히 제거되었는지를 감지하고, 구성에서 어떤 변경이 필요할지 사용자에게 알리도록 설계되었습니다. 여기에는 속성을 비밀로 교체하는 방법에 대한 문서를 참조하도록 사용자에게 알리는 것도 포함될 수 있습니다. 이러한 알림은 Helm install 또는 upgrade 명령이 구문 오류로 중단되게 하고 해결해야 할 항목의 전체 목록을 출력합니다. 우리는 사용자가 오류 루프에 빠지지 않도록 하기 위해 주의했습니다.

모든 차단 사항은 성공적인 배포를 위해 해결되어야 합니다. 우리는 사용자가 예기치 않은 동작이나 디버깅이 필요한 완전한 실패를 겪는 것보다 파괴적 변경에 대해 알림을 받는 것을 선호할 것이라고 믿습니다.

!396 Deprecations: implement buffered list of deprecations에서 도입되었습니다.

환경보다 initContainer에서 비밀 선호

컨테이너 생태계의 대부분은 환경 변수를 통해 구성될 수 있는 기능을 가지고 있거나 기대합니다.

이 구성 관행은 12-Factor 앱의 개념에서 비롯됩니다.

이는 여러 배포 환경 간의 구성을 크게 단순화하지만, 비밀번호 및 개인 키와 같은 연결 비밀을 컨테이너의 환경을 통해 전달하는 것에 대한 보안 우려가 남아 있습니다.

대부분의 컨테이너 생태계는 실행 중인 컨테이너의 상태를 검사하는 간단한 방법을 제공하며, 일반적으로 환경을 포함합니다. Docker를 예로 들면, 데몬과 통신할 수 있는 모든 프로세스는 실행 중인 모든 컨테이너의 상태를 질의할 수 있습니다. 이는 dind와 같은 특권이 있는 컨테이너가 주어진 노드의 모든 컨테이너의 환경을 검사할 수 있으며, 그 안에 포함된 모든 비밀을 노출할 수 있음을 의미합니다.

완전한 DevOps 라이프사이클의 일환으로, dind는 레지스트리에 푸시되고 이후 배포될 컨테이너를 빌드하는 데 정기적으로 사용됩니다.

이 우려 때문에, 우리는 initContainers를 통해 민감한 정보를 주입하는 것을 선호하기로 결정했습니다.

관련 문제:

하위 차트는 글로벌 차트에서 배포됩니다

이 저장소의 모든 하위 차트는 글로벌 차트를 통해 배포되도록 설계되었습니다.

각 구성 요소는 여전히 개별적으로 배포될 수 있지만, 글로벌 차트에서 제공하는 공통 속성을 사용합니다.

이 결정은 저장소 전체의 사용 및 유지 관리를 단순화합니다.

관련 문제:

gitlab/*의 템플릿 부분은 가능한 한 글로벌해야 합니다

모든 gitlab/* 하위 차트의 템플릿 부분은 가능한 한 글로벌 또는 GitLab 하위 차트의 templates/_helpers.tpl의 일부여야 합니다.

포크된 차트의 템플릿은 해당 차트의 일부로 남습니다.

이는 이러한 포크의 유지 보수 영향을 줄입니다.

이점은 간단합니다:

  • DRY 행동 증가로 인해 유지 관리가 용이해집니다. 단일 항목만으로 충분한 경우 여러 하위 차트에 동일한 기능의 중복이 있어서는 안 됩니다.

  • 템플릿 이름 충돌 감소. 모든 차트 전체의 부분은 함께 컴파일됩니다,

    따라서 이를 글로벌 행동처럼 다룰 수 있습니다.

관련 문제:

포크된 차트

다음 차트는 포크 가이드라인에 따라 이 저장소에서 포크되거나 재작성되었습니다.

Redis

GitLab Helm 차트의 3.0 릴리즈와 함께 우리는 더 이상 업스트림 Redis 차트를 포크하지 않고, 대신 이를 종속성으로 포함합니다.

Redis HA

Redis-HA는 3.0 이전의 릴리즈에 포함된 차트입니다. 이제 제거되었으며, 선택적 HA 지원을 추가한 업스트림 Redis 차트로 대체되었습니다.

MinIO

우리의 MinIO 차트는 업스트림 MinIO에서 수정되었습니다.

  • 속성으로부터 새로운 것을 생성하는 대신 기존 Kubernetes 비밀을 사용합니다.

  • 환경을 통해 민감한 키를 제공하는 것을 제거합니다.

  • defaultBucket.* 속성 대신 defaultBuckets를 사용하여 여러 버킷 생성을 자동화합니다.

registry

우리의 registry 차트는 업스트림 docker-registry에서 수정되었습니다.

  • 차트에서 MinIO 서비스를 자동으로 사용할 수 있게 합니다.

  • GitLab 서비스에 인증을 자동으로 연결합니다.

NGINX Ingress

우리의 NGINX Ingress 차트는 업스트림 NGINX Ingress에서 수정되었습니다.

  • TCP ConfigMap을 차트 외부에서 허용하는 기능을 추가합니다.

  • 릴리즈 이름에 따라 Ingress 클래스를 템플릿화 할 수 있는 기능을 추가합니다.

차트 전반에 사용되는 Kubernetes 버전

다양한 Kubernetes 버전에 대한 지원을 극대화하기 위해, 현재 안정 릴리즈의 Kubernetes보다 한 개 마이너 버전 낮은 kubectl을 사용하세요.

이를 통해 최소 세 개 이상의 Kubernetes 마이너 버전을 지원할 수 있습니다.

kubectl 버전에 대한 추가 논의는 문제 1509를 참조하세요.

관련 문제들:

관련 머지 요청들:

CNG와 함께 제공되는 이미지 변형

날짜: 2022-02-10

CNG 프로젝트는 Debian 및 UBI를 기반으로 하는 이미지를 제공합니다. 두 배포판에 대한 구성 유지 결정은 다음에 바탕을 두었습니다:

  • Debian 기반 이미지를 제공하는 이유:
    • 실적 및 전례
    • 배포판에 대한 친숙함
    • 커뮤니티 대 “기업”
    • 공급업체 종속성에 대한 인식 부족
  • UBI 기반 이미지를 제공하는 이유:
    • 특정 고객 환경에서 필요
    • RHEL 인증 및 OpenShift Marketplace / RedHat Catalog에 포함되기 위해 필요

이 주제에 대한 추가 논의는 이슈 #3095에서 확인할 수 있습니다.

Kubernetes 릴리스 지원 정책

날짜: 2024-03-26

GitLab은 Kubernetes의 세 개의 마이너 릴리스를 공식적으로 지원합니다: N, N-1, 및 N-2. N은 다음 중 하나입니다:

  • 우리가 자격을 완료한 최신 릴리스된 마이너 버전의 Kubernetes.
  • 최신 마이너 버전의 자격을 완료하지 않았거나 시작하지 않은 경우 가장 최근의 마이너 버전.

예를 들어, 현재 사용 가능한 릴리스가 1.28, 1.27, 1.26, 1.25이고 1.28 릴리스의 자격을 완료하지 않았다면 N은 1.27이 되며 우리는 릴리스 1.25, 1.26, 1.27을 공식적으로 지원합니다.

릴리스 참조
1.27 N
1.26 N-1
1.25 N-2

자세한 내용은 배포팀 Kubernetes 및 OpenShift 릴리스 지원 정책에서 확인할 수 있습니다.

OpenShift 릴리스 지원 정책

날짜: 2024-03-26

GitLab은 OpenShift의 네 개의 마이너 릴리스를 공식적으로 지원합니다 – N, N-1, N-2 및 N-3. Kubernetes와 마찬가지로 N은 다음 중 하나입니다:

  • 우리가 자격을 완료한 최신 릴리스된 마이너 버전의 OpenShift.
  • 최신 마이너 버전의 자격을 완료하지 않았거나 시작하지 않은 경우 가장 최근의 마이너 버전.

예를 들어, 현재 사용 가능한 릴리스가 4.14, 4.13, 4.12, 4.11이고 4.15 릴리스의 자격을 완료하지 않았다면 N은 4.14가 되며 우리는 릴리스 4.14, 4.13, 4.12, 4.11을 공식적으로 지원합니다.

릴리스 참조
4.14 N
4.13 N-1
4.12 N-2
4.11 N-2

자세한 내용은 배포팀 Kubernetes 및 OpenShift 릴리스 지원 정책에서 확인할 수 있습니다.