Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
컨테이너는 이미지로 배포 되고 실행됩니다. 컨테이너 이미지는 파드의 컨테이너 스펙에 이름으로 설정하는데, 이미지명:태그의 형식 입니다(예: nginx:latest). 이미지명에는 이미지가 위치한 리지스트리(Registry) 주소가 포함되는 데 도커(Docker)에서 제공하는 도커허브(hub.docker.com)인 경우는 생략됩니다.
칵테일 클라우드는 워크스페이스 별로 독립적인 이미지 리지스트리를 제공합니다. 또한 이미지 빌드 과정을 자동화 하는 ‘빌드(Build)’ 기능을 제공 합니다.
이미지 리지스트리는 컨테이너 이미지를 저장하고, 해당 이미지를 파드 실행 시 제공 합니다. 이미지 리지스트리의 저장/제공 인터페이스는 표준화 되어 있습니다. 보통 이미지를 만든 후 리지스트리에 저장 할 때는 ‘Push’를 컨테이너 실행 시 이미지를 가져올 때는 ‘Pull’ API를 사용 합니다.
칵테일 클라우드에서 이미지 리지스트리는 워크스페이스 마다 할당 할 수 있습니다. 팀에서 독립으로 사용하는 리지스트리 입니다. 또한 팀 간 이미지 리지스트리를 공유 할 수도 있습니다.
할당 된 이미지 리지스트리를 통해 서비스 맵에서 파드를 배포 할 경우, 이미지 설정은 이미지명이 아닌 ‘빌드’를 선택하여 수행합니다. 빌드는 이미지를 생성하는 과정을 자동화 한 것으로, 선택한 빌드의 ‘태그(Tag)’에 따라 최신의 이미지를 파드로 배포 할 수 있습니다.
빌드는 컨테이너 이미지를 생성하는 과정을 자동화하는 칵테일 클라우드의 리소스 입니다. 빌드는 하나 이상의 태그(Tag)를 갖는데, 각 태그마다 생성 과정을 다르게 정의 할 수 있습니다. 태그는 일종의 이미지 버젼이라 할 수 있습니다. 이미지 생성 과정을 빌드 플로우(Build Flow)라 합니다.
빌드는 워크스페이스에 할당되는 이미지 리지스트리에 생성된 이미지를 저장합니다. 따라서 이미지와 빌드은 같습니다. 다만 이미지 태그(버젼) 별로 고유 한 빌드 플로우를 가집니다. 이미지 리지스트리 - 이미지(빌드) - 태그(빌드 플로우)의 구조 입니다.
사용자는 워크로드의 파드에서 빌드(이미지)와 태그(버젼)를 선택해 배포합니다. 그러면 태그의 빌드 플로우가 생성한 이미지가 배포 되어 실행 되는 것 입니다. 서비스 맵의 파이프라인에서는 코드 변경 후 이미지 태그의 빌드 플로우를 실행하여, 이미지를 자동 업데이트 하는 전 과정을 자동화합니다.
빌드 플로우는 특정 태그(버젼)의 이미지 생성 과정을 자동화 합니다. 빌드 플로우가 이미지 생성을 위해 실행하는 각 단계를 ‘태스크(Task)’라 합니다.
칵테일 클라우드는 다양한 유형의 기본 태스크를 제공합니다. 또한 사용자가 직접 태스크를 만들어 빌드 플로우에 설정 할 수도 있습니다.
기본 태스크는 코드 저장소(Git)의 코드 다운로드, 사용자가 정의 한 스크립트 실행, 이미지 빌드 스트립트(Dockerfile)와 같은 것이 있습니다. 이 외에도 외부 시스템의 API 연계, FTP 기반의 파일 전송 등의 태스크도 제공됩니다.
태스크는 사용자가 개발하여 빌드 플로우에 추가/확장 할 수 있습니다. 이 때 사용자 태스크는 컨테이너화 하여 추가 하여야 합니다.
빌드 플로우의 태스크는 ‘빌드 서버(Build Server)’에서 실행 됩니다. 칵테일 클라우드는 빌드 서버의 용량을 조정하는 옵션을 제공합니다. 많은 자원을 필요로 하는 빌드 작업의 경우, 빌드 서버의 용량을 조정 할 수 있습니다.
보통 어플리케이션은 하나 이상의 워크로드(컨테이너)로 구성 됩니다. 특히 쿠버네티스에 배포되는 경우는 서비스 노출, 볼륨 등 다수의 관련 리소스를 가집니다. 이 경우 어플리케이션 배포는 복잡하고, 업그레이드도 여렵습이다.
패키지(Package)는 이러한 문제를 해결합니다. 다수의 어플리케이션 리소스를 하나의 단위로 묶고, 필요한 경우 사용자 설정을 통해 배포합니다. 업그레이드도 버젼을 기준으로 자동화 합니다. 패키지 생성, 배포, 관리를 지원하는 오픈소스는 다수 있습니다. 그 중 쿠버네티스 공식 프로젝트인 Helm이 많이 사용됩니다.
칵테일 클라우드의 카탈로그는 패키지를 검색하고 서비스 맵에 자동 배포 할 수 있는 기능을 제공 합니다. 패키지 형태는 Helm를 사용합니다. Helm 패키지는 대다수 오픈소스가 지원 합니다. 오픈소스 패키지는 패키지 저장소(Package Repository)에 등록 되고, 관리됩니다. 오픈소스를 모아 놓은 다수의 공개 패키지 저장소가 있는데, 카탈로그는 이 저장소들에 있는 모든 패키지를 검색 할 수 있습니다.
카탈로그를 통해 배포된 패키지는 서비스맵의 패키지 메뉴에서 관리됩니다. 배포된 패키지의 상태와 모니터링을 제공하고, 새로운 버젼으로 업그레이드를 할 수 있습니다.
기업에서 오픈소스 페키지 외에 내부 어플리케이션 또는 자체 구성 패키지를 사용 할 경우가 있습니다. 보통 보안, 구성 표준 등 정책이 적용된 패키지입니다. 경에 따라서는 상업용 소프트웨어를 패키지로 관리 할 수 있습니다.
칵테일 클라우드는 카탈로그에 공개 패키지 저장소 외에 사설 패키지 저장소를 생성하여 등록 관리할 수 있습니다. 기업 전용의 패키지 저장소 입니다.
워크스페이스(Workspace)는 팀 또는 조직 별로 제공되는 독립적인 업무 공간 입니다. 팀은 하나 이상의 담당 어플리케이션의 개발과 운영, 모니터링을 워크스페이스를 통해 수행합니다. 하나 이상의 구성원이 워크스페이스에 등록되어 협업을 수행합니다.
워크스페이스에는 어플리케이션의 배포와 운영에 필요한 자원이 할당 됩니다. 자원의 할당은 플랫폼 관리자가 수행하는데, 플랫폼에 등록된 클러스터와 이미지 리지스트리를 대상으로 합니다.
칵테일 클라우드에서 워크스페이스에 클러스터 자원을 할당하는 방법에는 두가지가 있습니다. 하나는 클러스터 전체 자원을 할당하는 것으로 이를 ‘하드 멀티테넌시(Hard Multi-Tenancy)라 합니다. 또 하나는 클러스터의 서비스 맵을 할당하는 방법인데 이를 ‘소프트 멀티테넌시(Soft Multi-Tenancy)라 합니다. 칵테일 클라우드의 서비스 맵은 네임스페이스를 확장 한 관리 단위로, 정확히 말하면 워크스페이스에 네임스페이스를 할당 한다고 할 수 있습니다.
하드 멀티테넌시는 팀에 전용 클러스터를 할당하고, 담당하는 어플리케이션 별로 서비스 맵을 자체적으로 구성하여 관리하는 형태를 말합니다. 전용 클러스터를 할당하는 경우는 워크스페이스 팀이 인프라 즉, 클러스터와 어플리케이션 모두를 관리 할 때를 말합니다. 팀이 완전히 독립적인 DevOps를 수행하여야 함으로, 구성원 역시 해당 기술과 경험을 보유하고 있어야 합니다. 최근 들어 DevOps팀이 자체적으로 클러스터를 구성하고 어플리케이션을 서비스하는 사례가 늘고 있는데, 이 경우에 적합한 방법이라 할 수 있습니다.
소프트 멀티테넌시는 팀에 서비스 맵 즉, 네임스페이스만을 할당하는 방법입니다. 네임스페이스는 클러스터를 논리적으로 나눈 격리된 독립 공간 입니다. 보통 가상 클러스터라 불리웁니다. 네임스페이스를 할당 받은 팀은 어플리케이션 배포와 운영만 담당 합니다. 클러스터(인프라)는 별도 팀에서 관리 합니다. 팀의 구성과 역할이 어플리케이션 개발과 운영 중심인 경우 적합한 방법입니다.
워크스페이스에는 어플리케이션 컨테이너 이미지를 저장하고 관리 할 수 있는 리지스트리가 독립적으로 할 당 됩니다. 팀 또는 어플리케이션 별로 이미지를 관리 하고, 자동화 된 파이프라인을 구성 합니다.
경우에 따라 팀 또는 어플리케이션이 공통된 이미지를 공유하는 경우도 있습니다. 이 경우에는 워크스페이스에 공유할 이미지 리지스트리를 할당 할 수 있습니다. 이 경우 하나 이상의 워크스페이스가 하나의 공유 이미지 리지스트리를 사용 하게 됩니다.
클러스터(Cluster)는 컨테이너가 실행 되는 인프라 입니다. 컨테이너는 어플리케이션의 배포 단위이자 실행 프로세스 입니다. 클러스터는 컨테이너 실행에 필요한 컴퓨팅 자원(CPU, Memory, 스토리지, 네트워크)을 제공합니다.
클러스터는 노드(물리 머신 또는 가상 머신)로 구성 됩니다. 하나 이상의 노드가 네트워크로 연결되어 있습니다. 클러스터는 분산 처리를 위해 고안된 아키텍처 입니다. 컨테이너를 클러스터에 배포하면 적절한 노드에서 실행 됩니다. 이러한 과정을 스케쥴링(Scheduling)이라 하는데, 쿠버네티스가 담당합니다. 쿠버네티스는 클러스터에서 컨테이너 스케쥴링과 관리를 담당합니다.
클러스터는 노드의 추가를 통해 자원을 확장 합니다. 더 많은 자원이 필요하면 그 만큼 노드를 추가하고, 쿠버네티스는 확장 된 노드에 컨테이너를 배치하고 조정 합니다.
컨테이너 간 네트워크와 데이터 저장을 위한 스토리지도 클러스터의 구성 요소 입니다.
쿠버네티스는 클러스터에 컨테이너를 실행하고, 수명 주기를 관리하는 컨테이너 오케스트레이션(Container Orchestration) 엔진 입니다. 구글(Google)에서 오픈소스로 공개하고, 지금은 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation, CNCF)의 맴버 프로젝트로 관리 됩니다.
쿠버네티스는 클러스터에 설치 됩니다. 클러스터 인프라(노드, 네트워크, 스토리지)를 기반으로 컨테이너에 필요한 자원을 관리하고 제공하는 역할도 담당합니다
노드는 클러스터를 구성하는 하나 이상의 컴퓨트(Compute) 머신입니다. 물리 머신, 가상 머신 모두 구성 가능 합니다. 노드는 CPU, Memory, Disk를 가지며, 서로 네트워크로 연결되어 있습니다. 노드는 쿠버네티스에서 스케쥴링을 위해 관리 됩니다.
노드는 마스터(Master) 노드와 워커(Worker) 노드로 구분됩니다. 마스터 노드는 쿠버네티스의 제어부에 해당하는 컴포넌트가 설치 됩니다. 마스터 노드는 워크노드와 통신하여 클러스터를 관리합니다.
워커 노드는 어플리케이션 컨테이너가 배포되는 노드를 말합니다. 어플리케이션의 수와 용량에 따라 워커 노드 수가 증가합니다. 워커노드에 컨테이너를 배포하는 역할을 마스터 노드의 스케쥴러(Scheduler)가 담당합니다.
하나 이상의 노드에서 실행 되는 컨테이너는 서로 간 통신이 필요한데, 컨테이너 네트워크가 이를 담당 합니다.
컨테이너 네트워크는 쿠버네티스 구성요소로 설치 됩니다. 쿠버네티스는 자체 컨테이너 네트워크를 제공하지 않습니다. 대신 외부 공급자가 플러그인 형태로 제공할 수 있도록 표준 인터페이스를 제공하는 데 이를 CNI(Container Network Interface)라 합니다. 대표적인 오픈소스 CNI 플러그인에는 Flannel, WeaveNet, Calico 등이 있습니다.
칵테일 클라우드는 클러스터의 CNI 플러그인을 선택하여 구성 할 수 있는 옵션을 제공 합니다.
클러스터 외부에서 컨테이너로 접속은 인그레스 컨트롤러가 담당합니다. 인그레스 컨트롤러는 외부 트래픽을 호스트 명과 경로로 구분하여 컨테이너로 라우팅(Routing) 합니다. 이 라우팅 규칙은 어플리케이션 별로 설정하여 인그레스 컨트롤러에 적용 됩니다.
인그레스 컨트롤러는 쿠버네티스 구성요소 입니다. 주로 사용 되는 인그레스 컨트롤러로는 오픈소스인 NGINX 컨트롤러로 쿠버네티스에서 기본으로 제공 합니다. 그외 제 3의 공급자가 제공하는 인그레스 컨트롤러를 사용 할 수 있습니다.
칵테일 클라우드는 인그레스 컨트롤러를 선택하여 구성 할 수 있는 옵션을 제공합니다. 어플리케이션 별로 전용 인그레스 컨트롤러를 두어 대용량 트래픽에 대응 하도록 구성 할 수 있고, 제 3의 공급자 인그레스 컨트롤러 중 적합한 것을 선택하여 구성 할 수도 있습니다.
클러스터 스토리지는 컨테이너 데이터 저장을 위해 사용 되는 영구 볼륨(Persistence Volume)를 제공 합니다.
컨테이너는 클러스터 노드에 배포되고, 노드 장애나 자원 부족 시 다른 노드로 재배치 됩니다. 따라서 노드에 컨테이너 데이터를 저장 하면 재배치 시 문제가 됩니다. 이 경우 데이터를 안전하게 저장하고 관리 할 수 있는 별도의 볼륨이 필요합니다. 이를 영구 볼륨이라 합니다.
쿠버네티스는 스토리지 클래스(Storage Class)를 통해 영구 볼륨을 생성하고 컨테이너에 제공합니다. 클러스터 구성 시 스토리지에 맞는 스토리지 클래스를 설치 하여야 합니다.
칵테일 클라우드는 스토리지 클래스를 애드온으로 제공 합니다. 사용자가 적합한 스토리지 클래스를 선택하면 자동 설치와 업그레이드를 할 수 있습니다.
네트워크, 스토리지 외에 쿠버네티스를 확장하는 컴포넌트가 있습니다. 칵테일 클라우드에서는 이 확장 컴포넌트를 애드온(Addon)이라 합니다.
애드온은 컨테이너 관리 기능 외에 쿠버네티스 클러스터에 확장 기능을 제공합니다. 대표적으로 모니터링과 서비스 매시(Service Mesh)를 예로 들 수 있습니다.
모니터링은 쿠버네티스에서 매트릭스(Metrics) API로 클러스터와 컨테이너의 상태, 자원, 네트워크 사용량 등을 제공합니다. 이 API를 통해 뷰(View)를 구성하여 모니터링을 할 수 있지만, 별도 개발과 제 3자가 제공하는 솔루션을 사용하여야 합니다. 쿠버네티스 에코시스템 프로젝트의 하나인 프로메테우스(Prometheus)가 그 예 입니다.
서비스 매시도 마찬가지 입니다. 구글이 주도하는 오픈소스인 ISTIO가 많이 사용 됩니다. 서비스 매시는 마이크로서비스(Microservice)구축 시 네트워크를 담당 합니다. 마이크로서비스 간 라우팅, 트래픽 제어, 보안 등 네트워크 부분을 별도로 관리하여, 마이크로서비스 개발 운영에 시간과 노력을 절감 할 수 있습니다.
칵테일 클라우드는 모니터링, 서비스 매시 외에 NVDIA GPU 플러그인, 다중 컨테이너 네트워크 구성 등 쿠버네티스 확장 컴포넌트를 제공 합니다. 설치 부터 업그레이드까지 자동으로 관리 되며, 필요한 애드온을 선택하여 사용 할 수 있습니다.
클라우드 네이티브 어플리케이션은 클러스터와 컨테이너 기술을 사용합니다. 클러스터는 인프라와 컨테이너 관리를 담당하고, 컨테이너는 어플리케이션 배포와 실행을 담당합니다. 따라서 모니터링 대상도 기존 어플리케이션과 차이가 있습니다.
클러스터는 노드(Node)로 구성 됩니다. 노드는 CPU, Memory, Disk를 가진 컴퓨팅 머신으로 운영체계(OS)와, 컨테이너를 실행하는 런타임(Container Runtime)이 있습니다. 따라서 컨테이너 실행에 필요한 물리적 자원 사용량과 성능 모니터링은 노드에서 데이터(모니터링에서는 매트릭이라 합니다.)를 수집해서 합니다.
컨테이너 관리는 쿠버네티스가 담당합니다. 쿠버네티스는 다수의 컴포넌트로 구성되며, 클러스터의 마스터 노드에 설치 됩니다. 쿠버네티스 장애가 발생하면, 컨테이너 관리를 할 수 없어, 마스터 노드와 설치된 컴포넌트도 모니터링이 필요 합니다. 마스터 노드의 자원 사용량, 컴포넌트의 상태 등을 모니터링 합니다.
클러스터의 각 노드와 컨테이너는 서로 통신을 합니다. 이 통신은 물리적인 네트워크와 쿠버네티스가 제어하는 논리 네트워크를 통합니다. 네트워크의 사용량 모니터링은 이 두 영역을 대상으로 합니다.
클러스터 모니터링은 컨테이너 실행에 필요한 인프라 자원을 대상으로 합니다. 반면 컨테이너 모니터링은 자원 사용량 뿐 아니라 실행 상태, 수명주기를 모니터링 합니다. 또한 컨테이너 간 통신량, 지연 시간 같은 요청부터 처리까지 과정도 모니터링 합니다.
컨테이너 모니터링은 쿠버네티스 API와 서비스 매시(컨테이너 간 통신 구성) API에서 매트릭을 제공합니다.
알림은 모니터링 매트릭 데이터가 일정 조건이 되었을 때 발생합니다. 이 조건을 알림 규칙(Rule)이라 합니다. 알림 규칙은 기본 제공되는 것 이외에 사용자가 설정 할 수 있습니다.
이벤트는 쿠버네티스 리소스 변경 시 발생합니다. 예를 들어 파드 생성, 실행, 업데이트, 삭제가 있습니다. 칵테일 클라우드에서는 이벤트를 수집하여 알림으로 제공합니다.
알림과 이벤트 모두 운영 중 발생하는 정보로, 어플리케이션과 클러스터의 상태와 장애 발생 전 대비를 할 수 있게 도와 줍니다.
쿠버네티스의 로그는 크게 3가지 유형이 있습니다. 먼저 쿠버네티스 마스터가 기록 하는 로그로, 마스터 운영에 필요한 정보를 제공합니다. 다음으로 컨테이너 로그로, 컨테이너 실행 시 표준 출력(STDOUT/STDERR)에 표시되는 로그입니다. 마지막으로 어플리케이션 로그로, 컨테이너에서 표준 출력 외에 별도 파일로 기록하는 로그입니다.
칵테일 클라우드는 세가지 유형의 로그를 모드 수집하여, 조회/분석 할 수 있는 환경을 제공합니다.
칵테일 클라우드는 다중 클러스터와 팀 또는 조직을 위한 멀티테넌시 환경을 통합 관리하고, DevOps를 위한 자동화 플랫폼을 제공 합니다. 이번 장에서는 칵테일 클라우드의 이해를 위한, 핵심 개념을 살펴 보도록 하겠습니다.
보안은 기업 클라우드에서 중요한 요소 중 하나 입니다. 클라우드 네이티브 환경의 보안 구성요소는 크게 3가지 입니다.
클러스터 접속 인증과 권한(인가)은, 허가 된 사용자가 클러스터에 접속하여, 필요한 리소스를 관리 할 수 있는 권한을 말합니다. 접속 사용자는 ‘사용자 계정’을 가집니다. 리소스는 어플리케이션과 데이터입니다. 관리자는 사용자에게 접속을 허가하고, 리소스에 대한 적절한 권한을 부여 하여 클러스터 보안을 관리 합니다.
칵테일 클라우드 사용자는 워크스페이스에서 할당 받은 클러스터를 GUI로 관리 할 수 있습니다. 따라서 클러스터에 직접 접속하여 관리 할 필요는 없습니다. 다만, 명령행 도구나 외부 CI/CD 시스템을 사용하는 경우는 클러스터 사용자 계정이 필요합니다. 이 경우 관리자는 사용자에게 클러스터 계정을 발급 합니다.
칵테일 클라우드는 하나의 사용자 계정으로 여러 클러스터에 접속하여, 권한에 따라 리소스를 관리 할 수 있는 통합 클러스터 계정 관리 기능을 제공 합니다. 칵테일 사용자는 관리자에게 클러스터 계정을 발급 받고, 유효 기간 안에 클러스터를 관리 할 수 있습니다.
감사로그는 칵테일 사용자 또는 클러스터 계정으로 접속한 사용자가 어떤 리소스를 대상으로 명령어(API)를 수행했는지 기록합니다. 장애와 보안 이슈가 발생할 경우, 감사로그를 추적하여 원인을 분석 할 수 있습니다.
칵테일 클라우드는 플랫폼(칵테일 클라우드 기능)과 클러스터(쿠버네티스) 감사로그를 모두 수집하여 추적 할 수 있는 기능을 제공 합니다.
파드 보안 정책은 컨테이너 실행 시 권한, 노드의 접근 권한, OS 보안 설정 등을 제어 합니다. 보통 파드를 정의할 때 보안 설정을 같이 합니다. 하지만 기업에서는 보안에 대한 통제가 필요합니다. 팀 또는 조직마다 다른 보안 설정은 예기치 못한 보안 헛점을 만들어 낼 수 있습니다.
파드 보안 정책은 클러스터 전체 또는 어플리케이션 별로 보안 설정을 강제 할 수 있습니다. 기업이 기존 보안 정책을 가지고 있다면, 보안 정책으로 통제할 수 있습니다.
칵테일 클라우드는 보안 정책을 설정하고 적용할 수 있는 기능을 제공합니다.
컨테이너 실행 이미지는 다수의 오픈소스를 포함 할 수 있습니다. 예를 들어 베이스 이미지(Base Image)는 컨테이너 이미지의 바탕으로 제작자가 인터넷에 공개한 이미지 입니다. 사용자는 베이스 이미지에 자신의 구성 요소를 첨가하여 컨테이너 이미지를 만듭니다. 이 경우 베이스 이미지에 악성 코드가 있다면, 보안 문제가 됩니다.
칵테일 클라우드가 제공하는 이미지 리지스트리는 이미지 악성 코드를 검사 할 수 있는 기능을 제공합니다. 또한 오래 된 구성 요소 버젼이나, 취약한 코드 등 추가 검사를 제공합니다.
서비스 맵(Service Map)은 어플리케이션을 구성하고 관리하는 단위 입니다. 쿠버네티스는 어플리케이션을 네임스페이스(Namespace) 단위로 관리 합니다. 네임스페이스는 클러스터를 논리적으로 나누어 컨테이너를 배포하고 관리하는 일종의 가상 클러스터 입니다. 서비스 맵은 칵테일 에서 제공 되는 어플리케이션 관리 공간으로, 네임스페이스 를 기반으로 추가적인 관리 기능을 제공 합니다.
서비스 맵은 어플리케이션을 구성 하는 다양한 리소스(Resource)를 관리 합니다. 리소스는 내부적으로 쿠버네티스 API를 통해 생성되고 관리 됩니다. 서비스 맵 리소스는 어플리케이션을 구성 하는 논리적인 리소스로, 클러스터의 물리적인 리소스(노드, 스토리지 등)를 사용합니다.
대표적인 서비스 맵 리소스는 컨테이너를 배포하고 관리하는 워크로드(Workload)를 들 수 있습니다. 이 외에 영구 볼륨, 설정 정보, 서비스 노출 등의 리소스가 있습니다.
파드는 컨테이너를 배포/실행하는 리소스 입니다. 파드는 하나 이상의 컨테이너로 구성 됩니다. 어플리케이션 로직 처리를 담당하는 주 컨테이너(Main Container)와 보조 역할 을 담당하는 사이드카 컨테이너(Sidecar Container) 입니다. 대 부분의 경우 주 컨테이너 만 필요하지만, 로그 수집, 백업, 프록시 등의 기능이 필요 할 경우 별도의 사이드카 컨테이너를 추가하여 확장 합니다.
파드 내의 컨테이너들은 동일한 네트워크(localhost)와 볼륨을 공유하여, 컨테이너 추가로 확장이 용이 합니다.
파드는 독립적으로 생성 할수 있지만, 일반적으로 복제, 업데이트 등 배포와 수명 주기를 담당하는 워크로드를 통해 생성/관리 됩니다.
워크로드는 파드의 배포와 수명 주기를 담당하는 서비스 맵 리소스 입니다. 워크로드는 파드를 어떤 형태로 배포하고 실행할지, 파드 상태 확인, 문제 시 재시작 등 파드의 전체 수명 주기를 관리 합니다.
워크로드는 몇가지 유형으로 구분 됩니다. 각 유형마다 파드의 배포와 실행, 관리 방식 차이가 있습니다.
동일한 파드를 복제 수 만큼 배포하여 문제 되는 파드가 있더라도 안정된 서비스를 제공할 수 있습니다. 웹서버와 같이 데이터 관리를 하지 않는 스테이트리스(Stateless) 어플리케이션 구성에 주로 사용 됩니다. 복제된 파드가 동일한 컨테이너이므 데이터 관리에는 적합하지 않기 때문입니다.
디플로이먼트 워크로드는 파드의 롤링 업데이트(Rolling Update)도 지원 합니다. 순차적으로 파드를 교체 하는 방식으로 서비스에 영향을 주지 않고 업데이트를 수행 합니다.
파드가 요청된 CPU 또는 Memory 자원을 일정량 이상 사용 할 때, 자동으로 파드 복제 수를 증가 시키는 오토 스케일링(Auto Scaling)도 지원합니다.
서로 다른 역할을 수행하는 파드를 복제 수 만큼 배포하여 워크로드를 구성 합니다. 데이터 베이스, Key-Value 저장소, 빅데이터 클러스터 등 데이터 저장과 관리 어플리케이션에 적합한 방식 입니다. 각 파드에는 고유한 이름이 부여 되므으로, 파드 간 통신을 통해 작업을 처리 할 수 있습니다. 각 파드는 고유한 영구 볼륨을 사용 하여 데이터를 저장/관리 합니다.
백그라운드(Background)에서 계속 실행되면서어 작업을 처리하는 프로세스를 데몬(Daemon) 프로세스라 합니다. 데몬셋 워크로드는 데몬 프로세스 파드를 클러스터의 모든 노드에 배포하고 관리하는 서비스 맵 리소스 입니다.
모든 노드에서 백그라운드 처리를 하는 작업으로는 각 노드의 로그 수집, 자원/상태 등 모니터링 데이터 수집 등이 있습니다.
한번의 실행으로 작업을 처리하는 파드는 잡 워크로드를 통해 배포 합니다. 잡 워크로드의 파드는 데이터 변환, 기계 학습 등 주로 일괄 작업 처리를 담당합니다.
잡 워크로드는 파드를 실행하고 작업 시작, 실행 중, 완료 상태를 관리 합니다.
잡 워크로드와 유사하지만 잡의 실행을 특정 시간 또는 주기적으로 실행 할 수 있습니다. 리눅스에서 많이 사용되는 크론탭(CronTab)과 유사한 설정을 사용합니다.
외부에 어플리케이션을 서비스 하기 위해서는 파드를 외부 트래픽으로 부터 접속 할 수 있도록 노출하여야 합니다. 서비스 맵에서는 서비스 노출 리소스를 통해 파드를 외부로 노출합니다.
서비스 노출 리소스는 노출 할 파드를 라벨(Label)로 지정합니다. 따라서 같은 라벨을 가진 복제 파드인 경우도 하나의 서비스 노출에서 지정 할 수 있습니다. 이 경우 서비스 노출은 트래픽을 지정 된 파드들 중 하나로 보내는 부하분산(Load Balancing)을 수행 합니다.
서비스 노출 리소스에는 고정된 IP 주소가 부여됩니다. 이 IP는 클러스터 내에서 사용되는 사설 IP 입니다. 고정된 IP를 부여 하는 이유는 파드는 재시작 시 IP 주소가 변하기 때문입니다. 만약 파드로 직접 접속 한다면 문제가 될 수 있습니다. 따라서 고정 주소를 가진 서비스 노출을 통해 지정된 파드에 접속하는 방식을 사용합니다.
서비스 노출은 노출 방식에 따라 유형을 구분합니다.
클러스터 IP로 서비스를 노출 하면, 클러스터 내부에서만 접속 할 수 있습니다. 즉, 서비스 맵 내에서 고정 IP를 통해 파드 간 통신을 할 때 클러스터 IP로 서비스 노출을 사용합니다.
클러스터 IP로 서비스를 노출하면 다른 서비스 맵의 파드 간 통신을 할 수 있습니다. 단, 서비스 맵의 네트워크 정책에서 파드의 접속을 허용 하여야 합니다.
노드 포트는 노드 IP를 사용해 접속하는 포트를 말합니다. 노드 포트로 서비스를 노출하면 외부에서는 노출한 노드 포트로 파드에 접속 할 수 있습니다(노드 IP:노드 포트). 노드 포트는 파드가 실행 되는 노드 뿐만 아니라 클러스터 전체 노드에 지정됩니다. 따라서 어느 노드의 포트로 접속 하여도 파드에 접속 할 수 있습니다. 보통은 클러스터의 모든 노드를 L4 스위치에 연결하여 접속 주소를 단일화 합니다.
노드 포트는 클러스터 설치 시 30000 ~ 32767의 범위가 부여 됩니다. 서비스를 노출 할 때 자동 또는 포트를 지정하여 노출합니다. 이 범위는 사용자가 설정 할 수 있습니다.
클러스터가 클라우드에서 구성될 경우, 로드벨런서를 자동 생성하여 서비스를 노출할 수 있습니다. 이 때 파드는 노드 포트로 노출되고 생성된 로드벨런서가 파드 실행 노드와 포트를 연결합니다. 외부에서는 로드벨런서 주소와 포트를 통해 접속 할 수 있습니다.
로드벨런서로 서비스 노출은 지원하는 클라우드에서만 가능합니다. 대표적으로 AWS, Azure, GCP가 있고 클라우드 공급자는 클러스터 설치 시 설정 합니다.
외부에서 파드를 접속하는 방식은 서비스 노출 외에 서비스 맵의 인그레스 리소스가 있습니다. 인그레스는 호스트명/경로로 파드를 외부에 노출 합니다(예: abc.com/login, cdf.org/). L7스위치와 유사 합니다.
인그레스를 사용하기 위해서는 인그레스 컨트롤러(Ingress Controller)가 클러스터에 설치되어 있어야 합니다. 인그레스 컨트롤러는 외부 트래픽을 받아 인그레스에서 정의된 라우팅 정보(호스트 명/경로 -> 클러스터 IP서비스 노출)에 따라 파드로 전달합니다. 즉 인그레스 컨트롤러가 외부 서비스로 노출되고, 파드는 클러스터 IP로 서비스를 노출하여 인그레스 규칙으로 라우팅 하는 구성을 합니다.
쿠버네티스에서 인그레스 컨트롤러는 파드로 베포 됩니다. 따라서 클러스터에 설치 시 노트 포트 또는 로드벨런서로 서비스를 노출하여야 합니다.
참고로 인그레스는 호스트명/경로로 트래픽을 라우팅 하기 때문에, 내부 또는 외부 DNS 서버에 호스트명을 등록하고 인그레스 컨트롤러가 이를 사용 할 수 있어야 합니다. 칵테일 클라우드는 인그레스 사용을 위한 구성을 기본 제공하여, 별도의 설치 및 설정 작업이 필요 없습니다.
파드의 외부 트래픽이 많을 경우, 전용 인그레스 노드를 클러스터에 구성 하기도 합니다. 이 노드에는 인그레스 컨트롤러만 배포 되며 복제로 이중화 됩니다. 트래픽 증가에 따라 인그레스 노드를 추가하여 확장 할 수 있는 장점이 있습니다.
파드가 데이터를 저장하고 관리하는 경우 영구 볼륨이 필요합니다. 파드는 언제든지 재시작되고, 노드 장애 시 정상 노드로 재배치 될 수 있어, 파드 실행 노드의 디스크를 데이터 저장용으로 사용 할 수 없습니다.
영구 볼륨은 파드의 재시작/재배치/삭제 시에도 데이터 유실이 없습니다. 파드의 수명 주기에 독립적으로 관리 되기 때문입니다. 영구 볼륨은 클러스터와 함께 구성된 별도 스토리지를 사용 합니다.
서비스 맵의 영구 볼륨 리소스는 클러스터의 스토리지를 선택하여 생성 합니다. 생성된 영구 볼륨은 파드에 마운트(Mount)하고 컨테이너가 사용합니다. 영구 볼륨은 다중의 파드에서 마운드 할 수 있는 공유 볼륨과 하나의 파드에서만 마운트할 수 있는 단일 볼륨으로 구분됩니다.
영구 볼륨은 클러스터에 스토리지가 구성 되어 있어야 합니다. 일반적으로 많이 사용하는 스토리지는 NFS 스토리지 입니다. NFS 프로토콜을 지원 하는 모든 스토리지를 사용 할 수 있습니다.
웹 서버를 컨테이너로 배포 할 경우, 서버 실행을 위한 설정 파일을 사용하게 됩니다. 이렇듯 파드가 별도의 설정을 통해 실행 되는 경우 설정 정보 리소스로 관리 합니다. 설정 파일을 파드의 컨테이너 이미지에 포함하여도 되지만, 이 경우 설정 파일이 변경 되면 다시 이미지를 만들어야 합니다.
설정 정보는 서비스 맵에서 생성 되고 관리 되며, 파드의 컨테이너에 볼륨/파일로 마운트하여 사용할 수 있습니다. 컨테이너 구현에 따라 환경 변수로 전달 가능합니다. 파드 실행 중에도 설정 정보를 변경하고 반영 할 수 있다는 장점이 있습니다.
설정 정보 리소스는 관리 방식에 따라 ConfigMap과 Secret으로 구분됩니다. 둘 모두 설정 정보를 관리하는 리소스이지만, Secret의 경우 암호화하여 데이터를 저장하므로, DB 접속 정보 등 보안이 필요한 설정 정보는 Secret를 사용합니다.
서비스 맵의 파이프라인 리소스는 워크로드의 컨테이너 이미지를 업데이트 합니다. 워크로드 배포가 완료 되면, 파이프라인이 자동 생성 되고, 파드의 컨테이너 이미지를 업데이트 할 수 있습니다.
서비스 맵에서 워크로드의 파드로 배포된 컨테이너 이미지는 두가지 유형이 있습니다. 칵테일 클라우드의 빌드로 부터 생성 되는 이미지와 외부 리지스트리에 등록된 이미지 입니다.
칵테일 클라우드의 빌드로 부터 생성 되는 이미지는, 어플리케이션 코드 변경 시 자동으로 이미지 생성 부터 워크로드에 배포까지의 전 과정을 파이프라인이 자동으로 수행 합니다.(칵테일 클라우드의 빌드는 ‘빌드/이미지’ 부분을 참조)
외부 리지스트리의 이미지는 교체를 통해 업데이트를 수행합니다. 이 때 파이프라인은 배포 자동화 만을 수행 합니다.
서비스 맵의 패키지 리소스는 하나 이상의 워크로드와 관련된 서비스 맵을 묶어 배포와 업데이트를 수행합니다. 주로 오픈소스 기반의 소프트웨어를 배포하고, 업데이트 할 때 사용됩니다.
칵테일 클라우드는 ‘카탈로그’에서 많이 사용 되는 오픈소스 패키지를 제공합니다. 카탈로그에서 원하는 패키지를 검색하고 서비스 맵에 자동 배포 할 수 있습니다.(칵테일 클라우드의 카탈로그는 ‘카탈로그’ 부분 참조)
서비스 맵에 배포된 패키지는 상태/모니터링과 자동 업데이트를 수행 할 수 있습니다.
플랫폼(Platform)은 칵테일 클라우드를 사용하는 기본 단위 입니다. 모든 기능은 플랫폼을 통해 사용 할 수 있습니다. 사용자는 플랫폼에 로그인 후, 권한에 따라 어플리케이션 개발, 운영, 관리 업무를 수행 합니다.
플랫폼은 하나 이상의 워크스페이스(Workspace)로 구성 됩니다. 워크스페이스는 팀 또는 조직 별로 제공되는 독립적인 작업 공간입니다. 기업은 플랫폼에서 팀을 위한 작업 공간을 구성하고, 필요한 자원을 할당하여 어플리케이션 개발 및 운영 환경을 제공 할 수 있습니다. 플랫폼은 워크스페이스와 어플리케이션, 인프라 자원을 통합 관리합니다.
플랫폼의 통합 관리기능은 ‘플랫폼 관리’라는 특수한 워크스페이스에서 제공되고, 이 워크스페이스는 플랫폼 관리자 권한을 갖고 있는 사용자의 업무 공간 입니다.
플랫폼은 어플리케이션이 사용하는 클러스터(인프라 자원)를 등록/관리 합니다. 워크스페이스 별로 클러스터 자원을 할당하고 관리 합니다. 클러스터 자원 할당은 클러스터 전체 또는 네임스페이스(Namespace) 단위로 합니다. 팀이 관리하는 어플리케이션은 할당 받은 자원을 통해 서비스 됩니다.
플랫폼은 모든 워크스페이스에서 개발/운영되는 어플리케이션의 전체 현황을 파악하고 관리 합니다. 어플리케이션의 구성, 상태, 자원 사용량 등을 통해 어플리케이션을 관리하고, 필요 시 자원의 확장과 장애 대응을 수행 합니다.
클러스터는 쿠버네티스 기반으로 운영 됩니다. 플랫폼은 쿠버네티스의 상태와 버젼 관리 등, 클러스터 운영에 필요한 기능을 제공 합니다.
플랫폼은 그외에도 사용자 관리, 보안 등 통합 관리 기능을 제공 합니다.
다중의 클러스터와 어플리케이션의 상태와 자원을 플랫폼에서 통합 모니터링 합니다. 각 클러스터 인프라와 어플리케이션의 매트릭(Metric) 데이터를 수집하고, 실시간 관제와 분석 수행을 위한 기능을 제공 합니다.
자원과 상태 뿐아니라 이벤트를 수집하고 일정한 규칙에 따라 알림을 제공합니다. 사전에 이상 징후를 파악하고 조치하며, 장애 시 원인 분석을 통해 조치를 수행 할 수 있습니다.
플랫폼은 다양한 차트를 통해 모니터링과 분석을 할 수 있도록 통합 대시보드를 제공 합니다.
플랫폼은 고유한 식별자(ID)를 가지고 있습니다. 사용자는 이 ID를 통해 플랫폼에 로그인 합니다. 또한 플랫폼 이름과 로고 이미지를 설정 하여 고유한 아이텐터티를 나타 낼 수 있습니다.
플랫폼은 칵테일 클라우드 제품 라이센스 정보를 가지고 있습니다. 이 라이센스는 구매자 정보와 같이 관리 되며, 지정된 플랫폼 관리자가 대표로 지정 됩니다.
퍼블릭 클라우드에서 클러스터를 운영 할 때 필요한 ‘클라우드 계정(Cloud Account)’도 플랫폼 정보로 관리 됩니다. 이 계정은 클라우드 인프라 관리와 인증 정보로 활용 됩니다.