쿠버네티스 통합 개발 가이드라인

GitLab 쿠버네티스 통합 개발 시 아키텍처, 클라이언트 라이브러리, 성능, 보안, 디버깅 등 개발 가이드라인을 설명합니다.

이 문서는 GitLab 쿠버네티스 통합 개발 시 다양한 가이드라인을 제공합니다. 개발 # 아키텍처 # 제한된 프로젝트 네임스페이스 생성과 같은 일부 쿠버네티스 작업은 GitLab Rails 애플리케이션에서 수행됩니다. 이러한 작업은 클라이언트 라이브러리 를 사용하여 수행되며, 일정 수준의 위험 요소를 수반합니다. 해당 작업은 GitLab Rails 애플리케이션을 실행하는 것과 동일한 사용자로 실행됩니다. 자세한 내용은 아래 보안 섹션을 참조하세요. 클러스터 애플리케이션 설치와 같은 일부 쿠버네티스 작업은 쿠버네티스 클러스터 자체의 일회성 Pod에서 수행됩니다. 이러한 설치 Pod는 install-<application_name> 으로 명명되며, gitlab-managed-apps 네임스페이스 내에 생성됩니다. 코드 구성 측면에서, 쿠버네티스 리소스를 나타내는 객체는 일반적으로 lib/gitlab/kubernetes 에 추가합니다. 클라이언트 라이브러리 # 쿠버네티스 API 호출을 수행하기 위해 kubeclient gem을 사용합니다. kubeclient gem은 단일 클라이언트에서 다른 API 그룹(예: apis/rbac.authorization.k8s.io )을 지원하지 않으므로, 이를 가능하게 하는 래퍼 클래스인 Gitlab::Kubernetes::KubeClient 를 생성했습니다. 선택된 쿠버네티스 API 그룹이 지원됩니다. 새로운 API 그룹 또는 메서드를 사용해야 하는 경우, Gitlab::Kubernetes::KubeClient 에 해당 API 그룹 또는 메서드 지원을 추가하세요. 새로운 API 그룹 또는 API 그룹 버전은 SUPPORTED_API_GROUPS 에 추가할 수 있으며, 내부적으로 해당 그룹에 대한 내부 클라이언트가 생성됩니다. 새로운 메서드는 관련 내부 클라이언트에 대한 위임으로 추가할 수 있습니다. 성능 고려 사항 # 쿠버네티스 API에 대한 모든 호출은 백그라운드 프로세스에서 수행되어야 합니다. 웹 요청 내에서 쿠버네티스 API 호출을 수행하지 마세요. 이는 웹 서버를 차단하며, 쿠버네티스 클러스터의 응답 시간이 우리의 통제 범위를 벗어나기 때문에 GitLab에서 서비스 거부(DoS) 공격으로 이어질 수 있습니다. 호출이 백그라운드 프로세스에서 수행되도록 하는 가장 쉬운 방법은 Sidekiq 워커 에서 해당 작업이 수행되도록 위임하는 것입니다. 쿠버네티스를 호출하고 응답을 반환하고 싶지만 백그라운드 워커가 적합하지 않은 경우, reactive caching 사용을 고려하세요. 예시: def calculate_reactive_cache! { pods: cluster.platform_kubernetes.kubeclient.get_pods } end def pods with_reactive_cache do |data| data[:pods] end end 테스트 # KubernetesHelpers 에 WebMock 스텁이 있으며, 이를 통해 테스트에서 쿠버네티스 API 호출을 모킹할 수 있습니다. Ama