<잇(IT)터뷰 전체 영상 보기>
잇(IT)터뷰 전체 내용은 ▼아래 영상▼에서 확인해 주세요!
◼ 게스트 : 최국현 이사 / 씨티아이앤씨(sales@ctinc.co.kr)
◼ 진행자 : 고우성 PD / 토크아이티 (talkit@talkit.tv, https://talkit.tv/)
<잇(IT)터뷰 – 핵심 내용 파악하기>
‘잇(IT)터뷰 – 핵심 내용 파악하기’는 영상의 핵심 내용을 정리한 글입니다.
|
쿠버네티스 환경에서 CI/CD를 구축하려면 하나의 도구만 잘 선택한다고 끝나는 것이 아니다. 소스코드를 빌드하고, 컨테이너 이미지를 만들고, 저장하고, 배포한 뒤 실제 서비스를 운영하는 과정이 하나의 흐름으로 연결되어야 한다.
기존에는 Jenkins와 Docker를 중심으로 CI/CD 환경을 구성하는 경우가 많았지만, 쿠버네티스와 클라우드 네이티브 환경에서는 각 단계에 특화된 오픈소스 도구를 조합하는 방식도 활용되고 있다.
이번 잇(IT)터뷰에서는 Tekton → Buildah → Harbor → Argo CD → Knative로 이어지는 CI/CD와 서비스 운영의 전체 흐름을 살펴본다.
1. Tekton은 쿠버네티스 방식으로 CI 파이프라인을 자동화한다
기존 Jenkins 기반 환경에서는 개발자가 직접 스크립트를 작성하거나 여러 플러그인과 에이전트 노드를 관리해야 하는 경우가 많았다.
처음에는 간단하게 시작해도 기능이 늘어나면 플러그인과 Jenkins 에이전트가 계속 추가되고, 로드밸런서나 네트워크 같은 인프라 요소까지 관리해야 한다. 개발자가 직접 처리하기 어려워지면 인프라팀이나 보안팀의 도움도 필요해진다.
수동 작업이 많아질수록 운영 복잡성뿐 아니라 보안 위험도 커진다. 계정이나 보안 키를 사람이 직접 관리하고 전달하는 과정에서 실수가 발생할 가능성이 있기 때문이다.
Tekton은 이러한 CI 파이프라인을 쿠버네티스 환경에 맞게 구성할 수 있도록 해주는 도구다.
파이프라인을 YAML 기반으로 선언하고, 특정 이벤트가 발생하면 트리거를 통해 자동으로 작업을 시작한다. 이후 최신 소스코드를 가져와 빌드하고, 컨테이너 이미지를 생성한 뒤 레지스트리에 저장하는 일련의 작업을 자동으로 수행할 수 있다.
Jenkins와의 중요한 차이 중 하나는 작업이 Pod 단위로 실행된다는 점이다.
빌드 작업이 필요할 때 임시 Pod가 만들어지고, 작업이 끝나면 해당 Pod가 제거된다. 항상 빌드 서버를 유지하는 방식보다 쿠버네티스의 동적인 실행 구조에 더 잘 맞는다.
결국 Tekton의 핵심은 사람이 직접 명령을 실행하는 CI 환경에서 벗어나 이벤트와 선언형 설정을 기반으로 자동화된 파이프라인을 만드는 것이다.
2. Buildah와 Harbor는 컨테이너 이미지를 만들고 저장하는 역할을 맡는다
CI 파이프라인에서 소스코드를 준비했다면 다음 단계는 실제 서비스에 사용할 컨테이너 이미지를 만드는 것이다.
기존에는 Docker를 이용해 이미지를 빌드하는 방식이 널리 사용됐다. 그러나 클라우드 네이티브 환경에서는 이미지 생성이라는 기능 자체에 집중한 별도의 도구를 활용할 수도 있다.
Buildah는 컨테이너 이미지 빌드에 특화된 오픈소스 도구다.
전체 컨테이너 실행 환경을 제공하는 Docker와 달리 이미지 생성에 필요한 기능에 집중하고 있기 때문에, CI 파이프라인에서 비교적 가볍게 활용할 수 있다.
과거 쿠버네티스 환경에서는 Kaniko도 많이 사용됐지만, 프로젝트의 개발 상황이 바뀌면서 Buildah와 같은 다른 이미지 빌드 도구가 대안으로 활용되고 있다.
이미지를 만들었다면 이를 저장할 장소도 필요하다.
공장에서 제품을 만든 뒤 출고 전까지 보관할 창고가 필요한 것처럼, 컨테이너 이미지 역시 저장하고 필요할 때 다시 가져올 수 있는 공간이 필요하다. 이것이 컨테이너 레지스트리다.
Harbor는 기업 환경에서 많이 활용되는 오픈소스 컨테이너 레지스트리 중 하나다.
Tekton 파이프라인에서 Buildah로 이미지를 만들고 Harbor에 저장하면, 이후 배포 시스템이 필요할 때 최신 이미지를 가져와 사용할 수 있다.
즉 Buildah가 이미지를 만드는 생산 공정이라면 Harbor는 완성된 이미지를 보관하는 물류 창고라고 이해할 수 있다.
3. Argo CD는 Git에 정의된 상태와 실제 운영 환경을 계속 일치시킨다
새로운 컨테이너 이미지를 만들었다고 해서 운영 중인 서비스가 자동으로 최신 버전으로 바뀌는 것은 아니다.
현재 쿠버네티스에서 실행되고 있는 서비스와 개발자가 Git에 정의해 놓은 원하는 상태가 같은지를 확인하고, 차이가 있다면 이를 맞춰주는 과정이 필요하다.
이 역할을 담당하는 대표적인 도구가 Argo CD다.
Argo CD는 Git 저장소를 지속적으로 확인하면서 운영 환경의 상태와 Git에 정의된 상태를 비교한다.
두 상태가 다르면 이를 ‘Out of Sync’ 상태로 표시하고, 동기화 과정을 통해 원하는 버전으로 업데이트할 수 있다.
예를 들어 개발자가 새로운 버전을 Git에 반영하면 Argo CD는 변경 내용을 확인하고 Harbor에서 해당 버전의 컨테이너 이미지를 가져와 쿠버네티스 환경에 배포할 수 있다.
또한 현재 어떤 버전이 배포되어 있는지 확인하거나 문제가 발생했을 때 이전 버전으로 롤백하는 것도 상대적으로 쉽게 관리할 수 있다.
이러한 방식을 GitOps라고 한다.
운영자가 서버에 직접 접속해 명령을 실행하는 대신, Git에 원하는 상태를 선언하고 시스템이 실제 환경을 그 상태에 맞추도록 자동화하는 방식이다.
사람의 직접 개입이 줄어들기 때문에 운영 절차를 표준화할 수 있고, 누가 언제 무엇을 변경했는지도 Git 기록을 통해 추적할 수 있다는 장점이 있다.
4. Knative는 배포 이후의 트래픽과 확장까지 자동화한다
서비스를 배포한 다음에는 또 다른 문제가 시작된다.
사용자가 늘어나면 서버를 늘려야 하고, 사용자가 줄어들면 불필요한 서버를 줄여야 한다. 여러 버전을 동시에 운영하면서 일부 사용자에게만 새로운 버전을 제공해야 할 수도 있다.
개발자가 이러한 인프라 운영까지 모두 직접 처리한다면 실제 서비스 개발보다 서버 관리에 더 많은 시간이 들어갈 수 있다.
Knative는 쿠버네티스를 기반으로 서버리스 형태의 애플리케이션 운영을 지원하는 도구다.
서비스의 트래픽이 증가하면 필요한 만큼 자동으로 확장하고, 트래픽이 감소하면 다시 축소할 수 있다.
특히 요청이 전혀 없는 서비스는 인스턴스를 0개까지 줄이는 ‘Scale to Zero’를 활용할 수 있다. 사용하지 않는 서비스를 계속 실행하지 않아도 되기 때문에 인프라 비용을 절감할 수 있다.
또한 서비스 버전을 리비전 단위로 관리하면서 여러 버전 사이에 트래픽을 나눌 수 있다.
이를 이용하면 새로운 버전을 일부 사용자에게만 먼저 제공하는 카나리 배포나 A/B 테스트, 블루·그린 배포와 같은 운영 방식도 구현할 수 있다.
결국 Knative의 목적은 개발자가 서버 수와 트래픽 배분을 직접 관리하는 부담을 줄이고 서비스 자체의 개발과 운영에 집중할 수 있도록 하는 것이다.
5. 좋은 도구를 고르는 것보다 전체 플랫폼과 운영 역할을 먼저 정리해야 한다
Tekton, Buildah, Harbor, Argo CD, Knative와 같은 도구를 잘 조합하면 쿠버네티스 기반의 CI/CD와 서비스 운영을 상당 부분 자동화할 수 있다.
하지만 좋은 도구를 선정해 파이프라인만 연결한다고 모든 문제가 해결되는 것은 아니다.
그 아래에 있는 쿠버네티스 인프라와 네트워크, 스토리지, 보안 체계가 제대로 정리되어 있지 않으면 각각의 도구도 안정적으로 운영되기 어렵다.
실제 기업에서는 컨테이너와 쿠버네티스를 도입한 뒤 “이 시스템을 누가 운영해야 하는가?”라는 문제가 자주 발생한다.
개발자가 담당해야 하는지, 시스템 운영자가 담당해야 하는지, 플랫폼 엔지니어가 관리해야 하는지 명확하지 않으면 책임의 경계가 모호한 ‘그레이존’이 생긴다.
따라서 쿠버네티스 기반 DevOps를 제대로 운영하려면 도구 선택만큼 역할과 책임을 명확하게 나누는 것도 중요하다.
개발자는 애플리케이션 개발에 집중하고, 플랫폼 엔지니어는 개발자가 사용할 쿠버네티스 플랫폼과 CI/CD 환경을 관리하며, 인프라 담당자는 기반 시스템을 안정적으로 운영하는 식의 역할 구분이 필요하다.
결국 성공적인 클라우드 네이티브 환경은 특정 도구 하나에서 만들어지는 것이 아니다.
인프라 → CI → 이미지 빌드 → 레지스트리 → CD → 서비스 운영까지 하나의 플랫폼으로 연결하고, 각 영역을 누가 책임질 것인지까지 함께 설계해야 한다.
6. 3줄 요약
– 쿠버네티스 기반 CI/CD는 Tekton으로 파이프라인을 구성하고, Buildah로 컨테이너 이미지를 만든 뒤 Harbor에 저장하는 흐름으로 구축할 수 있다.
– Argo CD는 Git에 정의된 상태와 실제 운영 환경을 지속적으로 비교·동기화하고, Knative는 배포 이후의 오토스케일링과 트래픽 관리 등을 자동화한다.
– 좋은 오픈소스 도구를 연결하는 것만으로는 충분하지 않으며, 기반 인프라와 개발자·플랫폼 엔지니어·운영 담당자의 역할까지 명확하게 설계해야 안정적인 클라우드 네이티브 환경을 만들 수 있다.
◼ 전체 잇(IT)터뷰 내용은 ▶영상으로 바로 가기(클릭)◀에서 확인하실 수 있습니다. |
◼ 콘텐츠 & 웨비나 문의 : marketing@talkit.tv, 02-565-0012
Copyright ⓒ 토크아이티 All rights reserved. 무단 전재 및 재배포 금지.