설계 결정

이 문서는이 리포지토리의 Helm 차트 설계에 관한 이유와 결정을 모은 것입니다. 제안 사항은 환영하며, 결정을 적용하는 방법은 결정을 참조하십시오.

문제 있는 구성 사항 파악 시도

이 차트의 복잡성과 그들의 유연성 레벨로 인해, 예측할 수 없는 또는 완전히 기능하지 않는 배포로 이어질 수 있는 구성을 생성할 수 있는 겹침이 있습니다. 알려진 문제 있는 설정 조합을 방지하려는 노력으로, 사용자의 구성이 작동하지 않을 것임을 경고하는 템플릿 로직을 구현하였습니다.

이것은 사용자의 구성을 수정하도록 요구하는 알림을 발생시킴으로써 폐기(불필요한 것을 없애고 필요한 것은 남기는 일)의 행동을 복제하지만, 기능적인 구성을 보증합니다.

!757 checkConfig: add methods to test for known errors 에서 도입됨

폐기를 통한 변경 사항

이 차트의 개발 중에, 기존 배포의 속성을 수정해야 하는 개선 사항이 가끔 있습니다. 예를 들어 MinIO의 사용 구성의 중앙화와 외부 객체 저장 구성의 속성에서 시크릿으로의 마이그레이션은 두 가지 예입니다(우리의 기본 설정을 준수함).

기능하지 않는 구성에 대한 업데이트된 이 차트의 버전을 실수로 배포하는 것을 방지하기 위해 폐기 알림을 구현하기로 선택하였습니다. 이들은 속성이 재배치되거나 변경되거나 완전히 제거되었는지를 감지하고, 그 변경 사항을 구성에 적용해야 하는 것을 사용자에게 알립니다. 이것은 속성을 시크릿으로 대체하는 방법에 대한 문서를 참조하도록 사용자에게 요구하는 것을 포함할 수 있습니다. 이러한 알림은 Helm의 install 또는 upgrade 명령이 구문 에러로 중단되고, 처리해야 하는 모든 항목의 완전한 목록이 출력됩니다. 우리는 사용자가 오류, 수정, 반복의 루프에 빠지지 않도록 주의를 기울였습니다.

모든 폐기는 성공적인 배포가 이루어지기 위해 처리되어야 합니다. 우리는 사용자가 예상하지 못한 동작이나 디버깅이 필요한 완전한 실패를 경험하는 대신에 변경 사항을 알림받는 것이 낫다고 믿습니다.

!396 Deprecations: implement buffered list of deprecations에 도입됨

환경 대 initContainer에서의 시크릿 선호

대부분의 컨테이너 생태계는 환경 변수를 통해 구성될 수 있는 능력을 갖거나 기대합니다. 이 구성 관행은 12인치 팩터 앱의 개념에서 비롯되었습니다. 이것은 여러 배포 환경에서의 구성을 크게 단순화하지만, 컨테이너의 환경을 통해 비밀번호나 개인 키와 같은 연결 시크릿을 전달하는 데 보안 상의 우려가 남아 있습니다.

대부분의 컨테이너 생태계는 실행 중인 컨테이너의 상태를 검사할 수 있는 간단한 방법을 제공합니다. 이것은 Docker를 예로 들면 데몬과 통신할 수 있는 모든 프로세스가 실행 중인 모든 컨테이너의 상태를 조회할 수 있다는 것을 의미합니다. 이것은 dind와 같은 권한 있는 컨테이너가 주어진 노드상의 모든 컨테이너의 환경을 검사하고 그 안에 포함된 모든 시크릿을 노출할 수 있다는 것을 의미합니다. 완전한 DevOps 라이프사이클의 일환으로, dind는 일반적으로 레지스트리에 푸시하고 이후 배포될 컨테이너를 빌드하는 데 사용됩니다.

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

관련된 문제:

글로벌 차트에서 배포된 하위 차트

이 리포지토리의 모든 하위 차트는 글로벌 차트를 통해 배포되도록 설계되었습니다. 각 구성 요소는 여전히 개별적으로 배포될 수 있지만, 글로벌 차트에 의해 용이하게 유지보수되는 공통 속성 집합을 사용합니다.

이 결정은 리포지토리 전체의 사용 및 유지관리를 간단화합니다.

관련된 문제:

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 시크릿을 사용합니다.
  • 환경을 통해 민감한 키 제공을 제거합니다.
  • defaultBuckets를 사용하여 여러 버킷의 자동 생성은 defaultBucket.* 속성 대신합니다.

레지스트리

우리의 레지스트리 차트는 상류의 docker-registry에서 변경되었습니다.

  • 차트 내부 MinIO 서비스 사용 활성화
  • GitLab 서비스에 대한 자동 인증 훅 추가

NGINX Ingress

우리의 NGINX Ingress 차트는 상류의 NGINX Ingress에서 변경되었습니다.

  • TCP ConfigMap이 차트 외부에 있도록 하는 기능 추가
  • 릴리스 이름에 따라 Ingress 클래스를 템플릿화하는 기능 추가

차트 전체에서 사용되는 Kubernetes 버전

다양한 Kubernetes 버전을 지원하기 위해 현재 안정적인 Kubernetes 릴리스보다 1개 마이너 버전 낮은 kubectl을 사용합니다. 이렇게 함으로써 적어도 3개 이상의 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

자세한 내용은 Distribution Team Kubernetes and OpenShift release support policy에서 확인하실 수 있습니다.

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

자세한 내용은 Distribution Team Kubernetes and OpenShift release support policy에서 확인하실 수 있습니다.