이 페이지를 참고하면 구성 동기화를 최대한 활용할 수 있도록 Kubernetes용 CI/CD GitOps 파이프라인을 계획하고 설계하는 데 도움이 됩니다.
GitOps 자체는 Kubernetes 구성을 대규모로 관리하는 조직을 위한 범용 권장사항입니다. 하지만 이 솔루션을 설계할 때는 많은 선택권이 있습니다. 선택 가능한 옵션과 이러한 결정의 장단점을 이해하면 나중에 아키텍처를 다시 만들 필요가 없습니다.
이 페이지에 나열된 모든 권장사항을 따를 필요는 없습니다. 고유한 상황에 따라 어떤 권장사항을 채택할지 결정하면 됩니다. 이 페이지를 참조하면 GitOps 아키텍처를 설정할 때 정보를 바탕으로 결정을 내릴 수 있습니다.
중앙 집중식 비공개 패키지 저장소 사용
공개 또는 내부 패키지(예: Helm 또는 kpt)에 중앙 저장소를 사용하면 팀이 패키지를 더 쉽게 찾을 수 있습니다. Artifact Registry 또는 Git 저장소와 같은 서비스를 사용할 수 있습니다.
플랫폼팀은 애플리케이션팀이 중앙 저장소에서만 패키지를 사용할 수 있는 정책을 구현할 수 있습니다. 또는 중앙 저장소를 검증된 패키지 집합으로 사용할 수 있습니다.
저장소에 대한 쓰기 권한을 소수의 엔지니어로만 제한할 수 있습니다. 조직 내 다른 부서는 읽기 액세스 권한을 가질 수 있습니다. 패키지를 중앙 저장소로 승격하고 업데이트를 브로드캐스팅하는 프로세스를 구현하는 것이 좋습니다.
다음 표에는 중앙 집중식 비공개 패키지 저장소를 사용할 때의 이점과 단점이 나와 있습니다.
이점 |
단점 |
|
|
wet 저장소 만들기
클러스터 또는 네임스페이스의 원하는 상태와 일치하는 YAML 출력으로 저장소를 만듭니다. diff를 사용하여 wet 저장소 또는 완전히 하이드레이션된 저장소의 변경사항을 쉽게 검토할 수 있어야 합니다. 검토 프로세스를 통해 wet 저장소만 변경하는 것이 좋습니다 (예: GitHub에서는 pull 요청).
다음 표에는 wet 저장소를 만들 때의 이점과 단점이 나와 있습니다.
이점 |
단점 |
|
|
구성 확인을 위한 원점 회귀
문제 확인을 위해 구성 동기화가 동기화를 시작할 때까지 기다리면 불필요한 Git 커밋과 장시간 피드백 루프가 발생할 수 있습니다. kubeval과 같은 kpt 검사기 함수를 사용하면 구성을 클러스터에 적용하기 전에 많은 문제를 발견할 수 있습니다.
다음 표에는 구성을 적용하기 전 문제를 확인할 때의 이점과 단점이 나와 있습니다.
이점 |
단점 |
|
|
브랜치 대신 폴더 사용
구성 변형에 브랜치 대신 폴더를 사용합니다. 폴더에서 tree 명령어를 사용하여 변형을 볼 수 있습니다. 예를 들어 브랜치를 사용하면 prod 브랜치와 stage 브랜치 간의 델타가 예정된 구성 변경인지 아니면 stage와 prod 간의 차이가 영구적인지 알 수 없습니다.
다음 표에는 브랜치 대신 폴더를 사용할 때의 이점과 단점이 나와 있습니다.
이점 |
단점 |
|
|
ClusterSelectors 사용 최소화
ClusterSelectors를 사용하면 구성의 특정 부분을 클러스터의 하위 집합에 적용할 수 있습니다. RootSync 또는 RepoSync를 구성하는 대신 적용 중인 리소스를 수정하거나 클러스터에 라벨을 추가할 수 있습니다. 하지만 시간이 지남에 따라 ClusterSelectors가 증가하면 클러스터의 최종 상태를 이해하기가 복잡해질 수 있습니다.
구성 동기화를 사용하면 여러 RootSyncs 및 RepoSyncs를 한 번에 동기화할 수 있습니다. 즉, 관련 구성을 개별 저장소에 추가한 후 원하는 클러스터에 동기화할 수 있습니다.
다음 표에는 ClusterSelectors를 사용하지 않을 때의 이점과 단점이 나와 있습니다.
이점 |
단점 |
|
|
구성 동기화로 작업 관리 방지
구성 동기화가 작업을 자동으로 적용할 수 있지만 다음과 같은 이유로 작업이 GitOps 배포에 적합하지 않습니다.
변경할 수 없는 필드: 많은 작업 필드는 변경할 수 없습니다. 변경 불가능한 필드를 변경하려면 객체를 삭제하고 다시 만들어야 합니다. 하지만 소스에서 객체를 삭제하지 않는 한 구성 동기화는 객체를 삭제하지 않습니다.
의도하지 않은 작업 실행: 구성 동기화로 작업을 동기화한 후 해당 작업이 클러스터에서 삭제되면 구성 동기화는 선택한 상태에서 드리프트를 고려하여 작업을 다시 만듭니다. 작업 TTL(수명)을 지정하면 작업이 자동으로 삭제되고 구성 동기화는 사용자가 정보 소스에서 작업을 삭제할 때까지 자동으로 작업을 다시 만들고 다시 시작합니다. 구성 동기화가 작업을 다시 실행하기 때문에 이는 의도한 결과가 아닌 경우가 많습니다.
조정 문제: 구성 동기화는 일반적으로 객체가 적용된 후 조정될 때까지 기다립니다. 하지만 작업은 실행이 시작되면 조정된 것으로 간주됩니다. 즉, 구성 동기화는 작업이 완료될 때까지 기다리지 않고 다른 객체를 계속 적용합니다. 그러나 나중에 작업이 실패하면 조정 실패로 간주됩니다. 경우에 따라 이로 인해 다른 리소스가 동기화되지 않으며 해결될 때까지 오류가 발생할 수 있습니다. 일부 경우에는 동기화가 성공하고 조정만 실패할 수 있습니다.
이러한 이유로 구성 동기화로 작업을 동기화하지 않는 것이 좋습니다.
대부분의 경우 작업 및 기타 상황별 태스크는 수명 주기 관리를 처리하는 서비스에서 관리해야 합니다. 그러면 작업 자체가 아닌 구성 동기화를 사용하여 서비스를 관리할 수 있습니다.
다음 표에는 작업을 관리하는 데 구성 동기화를 사용하지 않을 경우의 이점과 단점이 나와 있습니다.
혜택 |
단점 |
|
|
구조화되지 않은 저장소 사용
구성 동기화는 저장소 구성을 위해 구조화되지 않은 형식과 계층 구조 형식의 두 가지 구조를 지원합니다. 구조화되지 않은 형식을 사용하면 가장 편리한 방식으로 저장소를 구성할 수 있으므로 권장됩니다.
반면에 계층적 저장소는 특정 구조를 적용합니다. 예를 들어 CRD는 특정 디렉터리에 있어야 합니다. 이로 인해 구성을 공유해야 할 때 문제가 발생할 수 있습니다. 예를 들어 한 팀에서 CRD가 포함된 패키지를 게시하면 해당 패키지를 사용해야 하는 다른 팀은 CRD를 cluster 디렉터리로 이동해야 하므로 프로세스에 더 많은 오버헤드가 추가됩니다.
다음 표에는 구조화되지 않은 저장소를 사용할 때의 이점과 단점이 나와 있습니다.
이점 |
단점 |
|
|
계층적 저장소를 변환하는 방법은 계층적 저장소를 구조화되지 않은 저장소로 변환을 참조하세요.
별도의 코드 및 구성 저장소
모노 저장소를 확장할 때는 각 폴더별 빌드가 필요합니다. 코드 작업자와 클러스터 구성 작업자의 권한과 우려사항은 일반적으로 다릅니다. 코드 및 구성 저장소를 분리하면 각 저장소에 자체 권한 및 구조가 있을 수 있습니다.
다음 표에는 코드 저장소와 구성 저장소를 분리할 때의 이점과 단점이 나와 있습니다.
이점 |
단점 |
|
|
별도의 저장소를 사용하여 변경사항 보호
모노 저장소를 확장할 때는 폴더마다 다른 권한이 필요합니다. 이로 인해 저장소를 분리하면 보안, 플랫폼, 애플리케이션 구성 간에 보안 경계를 허용할 수 있습니다. 또한 프로덕션 저장소와 비프로덕션 저장소를 구분하는 것이 좋습니다.
다음 표에는 별도의 저장소로 변경사항을 격리할 때의 이점과 단점이 나와 있습니다.
이점 |
단점 |
|
|
패키지 버전 고정
Helm 또는 Git의 사용 여부에 관계없이 명시적 출시 없이 실수로 이동하지 않은 버전으로 구성 패키지 버전을 고정해야 합니다.
다음 표에는 패키지 버전을 고정할 때의 이점과 단점이 나와 있습니다.
이점 |
단점 |
|
|
워크로드 아이덴티티 사용
GKE 클러스터에서 워크로드 아이덴티티를 사용 설정하면 Kubernetes 워크로드가 안전하고 관리 가능한 방식으로 Google 서비스에 액세스할 수 있습니다.
다음 표에는 워크로드 아이덴티티를 사용할 때의 이점과 단점이 나와 있습니다.
이점 |
단점 |
|
|
대략적인 아키텍처
대략적으로 4개 이상의 저장소 유형이 필요합니다.
- 공유 구성이 저장되는 패키지 저장소. Artifact Registry에 저장된 Helm 차트일 수도 있습니다.
- 플랫폼팀이 클러스터 및 네임스페이스의 Fleet 차원 구성을 저장하는 플랫폼 저장소
- 애플리케이션 구성 저장소
- 애플리케이션 코드 저장소
다음 다이어그램은 이러한 저장소의 레이아웃을 보여줍니다.
다음 다이어그램은 애플리케이션 코드 저장소에서 애플리케이션 구성 저장소로의 구성 흐름을 보여줍니다. 개발팀이 애플리케이션 및 애플리케이션 구성을 위한 코드를 저장소에 푸시합니다. 앱과 구성을 위한 코드가 같은 위치에 저장되고 애플리케이션팀이 이러한 저장소를 제어할 수 있습니다. 그러면 앱팀이 코드를 빌드에 푸시할 수 있습니다.
