Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
https://cocktailcloud.io/
Cocktail Cloud는 올인원 컨테이너 관리 플랫폼(All-in-one Container Management Platform)이다.
클라우드 사용이 보편화 되면서, 인프라 뿐 아니라 어플리케이션, 서비스 관리에 대한 요구가 높아지고 있다. 과거와 같은 개발, 운영 방식으로는 클라우드의 장점을 활용하기에 한계가 있기 때문이다. 특히 어플리케이션 영역에서는 지속적인 통합 및 배포(Continuous Integration/Deploy, CI/CD), 마이그레이션(Migration), 멀티/하이브리드 클라우드 구축 등 자동화, 효율화, 통합 관리에 대한 요구가 증가 하고 있다.
컨테이너 기술의 확산은 이러한 맥락에서 당연하다고 할 수 있다. 현재 많은 기업들이 컨테이너 기술을 도입하였고 그 추세는 계속 증가하고 있다. (참조: http://redmonk.com/fryan/2017/09/10/cloud-native-technologies-in-the-fortune-100)
컨테이너는 어플리케이션 또는 서비스를 독립되고 실행 가능한 단위로 패키지 화 하는 기술로, 인프라 환경에 관계 없이 동일한 개발, 운영 경험을 제공 한다. 따라서 인프라에서 서비스까지 클라우드 관리를 표준화하고, 개발 및 운영 노력을 절감 할 수 있다. 특히 일관된 환경하에 멀티/하이브리드 클라우드를 관리 할수 있다는 장점을 제공한다.
Cocktail Cloud는 컨테이너의 장점을 클라우드 관리에 적용하여, 개발 및 운영 업무를 효율화 하고 단일 또는 멀티/하이브리드 클라우드 전략 구현을 위한 플랫폼을 제공한다.
Cocktail Cloud의 주요 기능은 다음과 같다
코드로 부터 빌드, 배포, 업데이트까지의 파이프라인 자동화
워크로드(서비스)중심의 컨테이너 관리: 패키징, 수명주기, 자원 등
풀 스택 모니터링: 인프라에서 컨테이너까지의 상태 및 자원 모니터링. Alert 관리
멀티/하이브리드 클러스터 프로비져닝 및 관리: Baremetal, 프라이빗/퍼블릭 클라우드
컨테이너는 이미지로 배포 되고 실행됩니다. 컨테이너 이미지는 파드의 컨테이너 스펙에 이름으로 설정하는데, 이미지명:태그의 형식 입니다(예: nginx:latest). 이미지명에는 이미지가 위치한 리지스트리(Registry) 주소가 포함되는 데 도커(Docker)에서 제공하는 도커허브(hub.docker.com)인 경우는 생략됩니다.
칵테일 클라우드는 워크스페이스 별로 독립적인 이미지 리지스트리를 제공합니다. 또한 이미지 빌드 과정을 자동화 하는 ‘빌드(Build)’ 기능을 제공 합니다.
이미지 리지스트리는 컨테이너 이미지를 저장하고, 해당 이미지를 파드 실행 시 제공 합니다. 이미지 리지스트리의 저장/제공 인터페이스는 표준화 되어 있습니다. 보통 이미지를 만든 후 리지스트리에 저장 할 때는 ‘Push’를 컨테이너 실행 시 이미지를 가져올 때는 ‘Pull’ API를 사용 합니다.
칵테일 클라우드에서 이미지 리지스트리는 워크스페이스 마다 할당 할 수 있습니다. 팀에서 독립으로 사용하는 리지스트리 입니다. 또한 팀 간 이미지 리지스트리를 공유 할 수도 있습니다.
할당 된 이미지 리지스트리를 통해 서비스 맵에서 파드를 배포 할 경우, 이미지 설정은 이미지명이 아닌 ‘빌드’를 선택하여 수행합니다. 빌드는 이미지를 생성하는 과정을 자동화 한 것으로, 선택한 빌드의 ‘태그(Tag)’에 따라 최신의 이미지를 파드로 배포 할 수 있습니다.
빌드는 컨테이너 이미지를 생성하는 과정을 자동화하는 칵테일 클라우드의 리소스 입니다. 빌드는 하나 이상의 태그(Tag)를 갖는데, 각 태그마다 생성 과정을 다르게 정의 할 수 있습니다. 태그는 일종의 이미지 버젼이라 할 수 있습니다. 이미지 생성 과정을 빌드 플로우(Build Flow)라 합니다.
빌드는 워크스페이스에 할당되는 이미지 리지스트리에 생성된 이미지를 저장합니다. 따라서 이미지와 빌드은 같습니다. 다만 이미지 태그(버젼) 별로 고유 한 빌드 플로우를 가집니다. 이미지 리지스트리 - 이미지(빌드) - 태그(빌드 플로우)의 구조 입니다.
사용자는 워크로드의 파드에서 빌드(이미지)와 태그(버젼)를 선택해 배포합니다. 그러면 태그의 빌드 플로우가 생성한 이미지가 배포 되어 실행 되는 것 입니다. 서비스 맵의 파이프라인에서는 코드 변경 후 이미지 태그의 빌드 플로우를 실행하여, 이미지를 자동 업데이트 하는 전 과정을 자동화합니다.
빌드 플로우는 특정 태그(버젼)의 이미지 생성 과정을 자동화 합니다. 빌드 플로우가 이미지 생성을 위해 실행하는 각 단계를 ‘태스크(Task)’라 합니다.
칵테일 클라우드는 다양한 유형의 기본 태스크를 제공합니다. 또한 사용자가 직접 태스크를 만들어 빌드 플로우에 설정 할 수도 있습니다.
기본 태스크는 코드 저장소(Git)의 코드 다운로드, 사용자가 정의 한 스크립트 실행, 이미지 빌드 스트립트(Dockerfile)와 같은 것이 있습니다. 이 외에도 외부 시스템의 API 연계, FTP 기반의 파일 전송 등의 태스크도 제공됩니다.
태스크는 사용자가 개발하여 빌드 플로우에 추가/확장 할 수 있습니다. 이 때 사용자 태스크는 컨테이너화 하여 추가 하여야 합니다.
빌드 플로우의 태스크는 ‘빌드 서버(Build Server)’에서 실행 됩니다. 칵테일 클라우드는 빌드 서버의 용량을 조정하는 옵션을 제공합니다. 많은 자원을 필요로 하는 빌드 작업의 경우, 빌드 서버의 용량을 조정 할 수 있습니다.
워크스페이스(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 플러그인, 다중 컨테이너 네트워크 구성 등 쿠버네티스 확장 컴포넌트를 제공 합니다. 설치 부터 업그레이드까지 자동으로 관리 되며, 필요한 애드온을 선택하여 사용 할 수 있습니다.
보통 어플리케이션은 하나 이상의 워크로드(컨테이너)로 구성 됩니다. 특히 쿠버네티스에 배포되는 경우는 서비스 노출, 볼륨 등 다수의 관련 리소스를 가집니다. 이 경우 어플리케이션 배포는 복잡하고, 업그레이드도 여렵습이다.
패키지(Package)는 이러한 문제를 해결합니다. 다수의 어플리케이션 리소스를 하나의 단위로 묶고, 필요한 경우 사용자 설정을 통해 배포합니다. 업그레이드도 버젼을 기준으로 자동화 합니다. 패키지 생성, 배포, 관리를 지원하는 오픈소스는 다수 있습니다. 그 중 쿠버네티스 공식 프로젝트인 Helm이 많이 사용됩니다.
칵테일 클라우드의 카탈로그는 패키지를 검색하고 서비스 맵에 자동 배포 할 수 있는 기능을 제공 합니다. 패키지 형태는 Helm를 사용합니다. Helm 패키지는 대다수 오픈소스가 지원 합니다. 오픈소스 패키지는 패키지 저장소(Package Repository)에 등록 되고, 관리됩니다. 오픈소스를 모아 놓은 다수의 공개 패키지 저장소가 있는데, 카탈로그는 이 저장소들에 있는 모든 패키지를 검색 할 수 있습니다.
카탈로그를 통해 배포된 패키지는 서비스맵의 패키지 메뉴에서 관리됩니다. 배포된 패키지의 상태와 모니터링을 제공하고, 새로운 버젼으로 업그레이드를 할 수 있습니다.
기업에서 오픈소스 페키지 외에 내부 어플리케이션 또는 자체 구성 패키지를 사용 할 경우가 있습니다. 보통 보안, 구성 표준 등 정책이 적용된 패키지입니다. 경에 따라서는 상업용 소프트웨어를 패키지로 관리 할 수 있습니다.
칵테일 클라우드는 카탈로그에 공개 패키지 저장소 외에 사설 패키지 저장소를 생성하여 등록 관리할 수 있습니다. 기업 전용의 패키지 저장소 입니다.
클라우드 네이티브 어플리케이션은 클러스터와 컨테이너 기술을 사용합니다. 클러스터는 인프라와 컨테이너 관리를 담당하고, 컨테이너는 어플리케이션 배포와 실행을 담당합니다. 따라서 모니터링 대상도 기존 어플리케이션과 차이가 있습니다.
클러스터는 노드(Node)로 구성 됩니다. 노드는 CPU, Memory, Disk를 가진 컴퓨팅 머신으로 운영체계(OS)와, 컨테이너를 실행하는 런타임(Container Runtime)이 있습니다. 따라서 컨테이너 실행에 필요한 물리적 자원 사용량과 성능 모니터링은 노드에서 데이터(모니터링에서는 매트릭이라 합니다.)를 수집해서 합니다.
컨테이너 관리는 쿠버네티스가 담당합니다. 쿠버네티스는 다수의 컴포넌트로 구성되며, 클러스터의 마스터 노드에 설치 됩니다. 쿠버네티스 장애가 발생하면, 컨테이너 관리를 할 수 없어, 마스터 노드와 설치된 컴포넌트도 모니터링이 필요 합니다. 마스터 노드의 자원 사용량, 컴포넌트의 상태 등을 모니터링 합니다.
클러스터의 각 노드와 컨테이너는 서로 통신을 합니다. 이 통신은 물리적인 네트워크와 쿠버네티스가 제어하는 논리 네트워크를 통합니다. 네트워크의 사용량 모니터링은 이 두 영역을 대상으로 합니다.
클러스터 모니터링은 컨테이너 실행에 필요한 인프라 자원을 대상으로 합니다. 반면 컨테이너 모니터링은 자원 사용량 뿐 아니라 실행 상태, 수명주기를 모니터링 합니다. 또한 컨테이너 간 통신량, 지연 시간 같은 요청부터 처리까지 과정도 모니터링 합니다.
컨테이너 모니터링은 쿠버네티스 API와 서비스 매시(컨테이너 간 통신 구성) API에서 매트릭을 제공합니다.
알림은 모니터링 매트릭 데이터가 일정 조건이 되었을 때 발생합니다. 이 조건을 알림 규칙(Rule)이라 합니다. 알림 규칙은 기본 제공되는 것 이외에 사용자가 설정 할 수 있습니다.
이벤트는 쿠버네티스 리소스 변경 시 발생합니다. 예를 들어 파드 생성, 실행, 업데이트, 삭제가 있습니다. 칵테일 클라우드에서는 이벤트를 수집하여 알림으로 제공합니다.
알림과 이벤트 모두 운영 중 발생하는 정보로, 어플리케이션과 클러스터의 상태와 장애 발생 전 대비를 할 수 있게 도와 줍니다.
쿠버네티스의 로그는 크게 3가지 유형이 있습니다. 먼저 쿠버네티스 마스터가 기록 하는 로그로, 마스터 운영에 필요한 정보를 제공합니다. 다음으로 컨테이너 로그로, 컨테이너 실행 시 표준 출력(STDOUT/STDERR)에 표시되는 로그입니다. 마지막으로 어플리케이션 로그로, 컨테이너에서 표준 출력 외에 별도 파일로 기록하는 로그입니다.
칵테일 클라우드는 세가지 유형의 로그를 모드 수집하여, 조회/분석 할 수 있는 환경을 제공합니다.
보안은 기업 클라우드에서 중요한 요소 중 하나 입니다. 클라우드 네이티브 환경의 보안 구성요소는 크게 3가지 입니다.
클러스터 접속 인증과 권한(인가)은, 허가 된 사용자가 클러스터에 접속하여, 필요한 리소스를 관리 할 수 있는 권한을 말합니다. 접속 사용자는 ‘사용자 계정’을 가집니다. 리소스는 어플리케이션과 데이터입니다. 관리자는 사용자에게 접속을 허가하고, 리소스에 대한 적절한 권한을 부여 하여 클러스터 보안을 관리 합니다.
칵테일 클라우드 사용자는 워크스페이스에서 할당 받은 클러스터를 GUI로 관리 할 수 있습니다. 따라서 클러스터에 직접 접속하여 관리 할 필요는 없습니다. 다만, 명령행 도구나 외부 CI/CD 시스템을 사용하는 경우는 클러스터 사용자 계정이 필요합니다. 이 경우 관리자는 사용자에게 클러스터 계정을 발급 합니다.
칵테일 클라우드는 하나의 사용자 계정으로 여러 클러스터에 접속하여, 권한에 따라 리소스를 관리 할 수 있는 통합 클러스터 계정 관리 기능을 제공 합니다. 칵테일 사용자는 관리자에게 클러스터 계정을 발급 받고, 유효 기간 안에 클러스터를 관리 할 수 있습니다.
감사로그는 칵테일 사용자 또는 클러스터 계정으로 접속한 사용자가 어떤 리소스를 대상으로 명령어(API)를 수행했는지 기록합니다. 장애와 보안 이슈가 발생할 경우, 감사로그를 추적하여 원인을 분석 할 수 있습니다.
칵테일 클라우드는 플랫폼(칵테일 클라우드 기능)과 클러스터(쿠버네티스) 감사로그를 모두 수집하여 추적 할 수 있는 기능을 제공 합니다.
파드 보안 정책은 컨테이너 실행 시 권한, 노드의 접근 권한, OS 보안 설정 등을 제어 합니다. 보통 파드를 정의할 때 보안 설정을 같이 합니다. 하지만 기업에서는 보안에 대한 통제가 필요합니다. 팀 또는 조직마다 다른 보안 설정은 예기치 못한 보안 헛점을 만들어 낼 수 있습니다.
파드 보안 정책은 클러스터 전체 또는 어플리케이션 별로 보안 설정을 강제 할 수 있습니다. 기업이 기존 보안 정책을 가지고 있다면, 보안 정책으로 통제할 수 있습니다.
칵테일 클라우드는 보안 정책을 설정하고 적용할 수 있는 기능을 제공합니다.
컨테이너 실행 이미지는 다수의 오픈소스를 포함 할 수 있습니다. 예를 들어 베이스 이미지(Base Image)는 컨테이너 이미지의 바탕으로 제작자가 인터넷에 공개한 이미지 입니다. 사용자는 베이스 이미지에 자신의 구성 요소를 첨가하여 컨테이너 이미지를 만듭니다. 이 경우 베이스 이미지에 악성 코드가 있다면, 보안 문제가 됩니다.
칵테일 클라우드가 제공하는 이미지 리지스트리는 이미지 악성 코드를 검사 할 수 있는 기능을 제공합니다. 또한 오래 된 구성 요소 버젼이나, 취약한 코드 등 추가 검사를 제공합니다.
칵테일 클라우드가 무엇이며, 특징과 장점에 대해 설명 합니다.
칵테일 클라우드는 쿠버네티스(Kubernetes)를 기반으로 한 플랫폼으로 클라우드 네이티브 어플리케이션(Cloud Native Application)의 빌드로 부터 배포, 모니터링, 운영에 필요한 기능과 API를 제공합니다.
다수의 기업에서 쿠버네티스 도입을 고려하는 이유는, 컨테이너(Container), 마이크로서비스(Micorservice), 서버리스(Serverless) 등 클라우드 네이티브 어플리케이션의 필요성이 높아지고 있기 때문입니다.
클라우드 네이티브 어플리케이션은 개발/운영의 연속성과 효율을 높여 주고, 자동화를 통해 장애 대응, 부하에 따른 스케일링 등 어플리케이션의 높은 가용성을 확보 할 수 있습니다. 하지만 쿠버네티스의 도입과 운영은 새로운 기술에 적응해야하는 어려움과 관리의 복잡성 때문에, 기업의 또 다른 도전 과제가 되고 있습니다.
칵테일 클라우드는 쿠버네티스의 구축과 관리, 클라우드 네이티브 어플리케이션의 개발과 운영에 필요한 모든 기능과 컴포넌트를 통합 플랫폼으로 제공합니다. 기업은 초기 도입의 시간과 노력을 절감 할 수 있으며, 이 후 관리와 확장을 어려움 없이 수행 할 수 있습니다.
쿠버네티스의 도입 기업 수는 늘고 있지만, 오픈소스의 설치, 업데이트 등의 운영/관리에 대한 부담과 조직이 새로운 기술에 적응하는 시간과 노력이 많이 듭니다. 또한 모니터링, 네트워크, 보안 등 쿠버네티스가 제공하지 않는 영역은 관련 에코시스템 컴포넌트를 추가 구성 해야 하므 추가인 노력이 필요합니다.
칵테일 클라우드는 자동화 된 설치 도구를 통해 쿠버네티스 클러스터 구성과 확장을 손쉽게 할 수 있습니다. 클러스터의 업그레이드, 노드 확장 등 관리 기능도 제공합니다. 초기 구축과 관리 노력이 절감 됩니다.
칵테일 클라우드는 애드온(Addon)을 통해 쿠버네티스 구성을 확장 합니다. 모니터링, 네트워크, GPU 지원, 보안등 컴포넌트가 애드온으로 제공 됩니다. 애드온 역시 자동화 된 설치/업데이트 기능을 제공 합니다.
보안을 위한 망 분리, 운영계 시스템의 분리 운영, 퍼블릭 클라우드의 사용 등 기업이 멀티 클러스터를 사용하는 이유는 다양 합니다. 하나 이상의 클러스터와 서로 다른 쿠버네티스 배포판을 혼용하는 사례도 증가 하고 있습니다.
칵테일 클라우드는 다중 클러스터를 하나의 제어부(Single Control Plane)에서 운영, 관리 하는 환경을 제공합니다. 프라이빗, 퍼블릭 클라우드와 데이터센터 등 다양한 인프라 기반에서 다중 클러스터를 구축 및 관리 합니다.
물리 장비(베어케탈) 기반의 클러스터
가상화 기반의 프라이빗 클라우드 : OpenStack, VMWare, CTRIX Hypervisor etc.
퍼블릭 클라우드 : GKE(GCP), EKS(AWS), AKS(Azure) etc.
기업은 조직, 팀의 역할에 따라 클러스터와 필요 자원을 할당 또는 공유하는 작업 환경이 필요합니다. 특히 어플리케이션 서비스 개발과 운영은 전담 조직이 담당하는 것이 일반적이며, 어플리케이션의 특성에 따라 고유한 컴퓨팅 자원이 필요합니다.
칵테일 클라우드는 조직 또는 팀별 독립적인 작업 공간을 제공하며, 필요한 컴퓨팅 자원(클러스터)을 할당/관리 할 수 있습니다. 클라우드 네이티브 어플리케이션에 기본적으로 필요한 자원은 CPU, GPU, Memory, Volume 등 컴퓨팅 자원 뿐아니라 컨테이너 이미지 리지스트리, 자동화 파이프라인 등 개발/운영을 위한 자원이 필요합니다. 독립적인 작업 공간에 이러한 자원을 할당하고, 필요한 경우 추가/조정 할 수 있는 자원 관리와 작업 공간 내 구성원의 권한 관리등 멀티테넌시 환경을 손쉽게 구성하고 관리할 수 있습니다.
다중의 클러스터, 멀티테넌시 환경은 복잡하고 관리가 어렵습니다. 칵테일 클라우드는 다양한 통합 관리 기능을 통해 이러한 문제를 해결 합니다.
기업 전체 어플리케이션과 인프라 자원(클러스터, 저장소)의 현황을 확인하고 관리 합니다. 팀 또는 조직 별, 어플리케이션 서비스 별로 개발/운영 현황을 파악하고, 필요 자원의 요청과 이슈를 처리 할 수 있습니다.
다중 클러스터 인프라 자원, 어플리케이션 상태, 네트워크 등을 중앙에서 모니터링 하고, 실시간 알림(Alert)/이벤트(Event), 로그(Log)를 통해 장애 또는 이슈에 효과적으로 대응 할 수 있습니다. 또한 매트릭과 규칙의 확장으로 기업에 맞춤화 된 통합 모니터링 환경을 제공 합니다.
최근에 들어 어플리케이션 빌드에서 부터 배포, 업데이트의 전 과정에 대한 연속성 확보가 중요 해 지고 있습니다. 고객의 요구를 다양한 채널을 통해 수집하고, 빠르게 대응하는 전략이 비즈니스 성공을 가져 오는 핵심 요소이기 때문입니다. 기업은 이를 위해 자동화 된 CI/CD(Continuous Integration/Continuous Deploy) 파이프라인(Pipeline)를 구축 합니다.
클라우드 네이티브 어플리케이션은 자동화 파이프라인 구축에 있어 이전 보다 발전 된 기술을 제공합니다. 칵테일 클라우드는 이 기술을 바탕으로 자동화 된 CI/CD 파이프라인 구축과 관리를 위한 다양한 기능을 제공합니다. 기업은 어플리케이션 특성과 개발/운영 환경에 따라 맞춤화 된 파이프라인을 구축 할 수 있으며, 운영 및 모니터링 등 DevOps 플랫폼을 팀 또는 조직에게 제공 할 수 있습니다.
기업에 있어 보안은 중요한 관리 요소 입니다. 특히 어플리케이션을 배포하고 실행하는 인프라(쿠버네티스의 경우 클러스터)에 대한 허가된 사용자의 접속과 권한 관리는, 비 인가 사용자의 위협에 대응하는 기본 방법 입니다.
칵테일 클라우드는 허가 된 사용자에게 접속 계정과 권한을 발급하고, 사용기간/회수를 통해 위험을 관리 합니다. 또한 접속계정의 사용 이력을 감사로그를 통해 추적하여, 보안 이슈 발생 시 원인 분석/차단등의 조치를 신속히 수행 할 수 있습니다.
이 외에도 컨테이너 실행 시 보안을 정책화 하고 적용 할수 있는 '보안 정책 관리'와 컨테이너 이미지의 취약점을 검사하는 '이미지 검사' 기능을 제공 합니다.
서비스 맵(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)’도 플랫폼 정보로 관리 됩니다. 이 계정은 클라우드 인프라 관리와 인증 정보로 활용 됩니다.
칵테일에서 제공하는 어플리케이션 관리 공간인 서비스 맵에서 디플로이먼트, 스테이트풀셋, 데몬셋, 잡, 크론잡 같은 워크로드를 생성합니다.
이 때, 워크로드를 체계적으로 관리하기 위해서 워크로드를 생성하기 이전에 워크로드 그룹을 먼저 생성한 후, 새로 만들 워크로드를 워크로드 그룹에 할당하게 됩니다. 생성된 워크로드는 워크로드가 소속된 워크로드 그룹에 따라 카드 형태로 상하 정렬되어 표시됩니다.
워크로드를 생성하고 설정하기 위해서는 다양한 항목들의 설정이 필요합니다. 칵테일 클라우드는 워크로드에 대한 복잡한 설정 사항들을 YAML에 대한 지식 없이 웹 UI에서 손쉽게 설정할 수 있습니다.
디플로이먼트 (Deployment)
스테이트풀셋 (StatefulSet)
데몬셋 (DaemonSet)
잡 (Job)
크론잡 (CronJob)
하나의 네임스페이스에서는 여러가지 유형의 워크로드들이 실행될 수 있고, 경우에 따라서는 한눈에 파악하기 힘들 정도로 많은 워크로드들이 수행될 수 있습니다.
워크로드들의 유형에 따라 워크로드 그룹들로 조직화한 후에, 워크로드 그룹에 따라 워크로드들의 상태를 표시한다면 워크로드들의 상태를 일목요연하게 파악할 수 있습니다.
개발자가 각각의 워크로드 유형에 대한 YAML이나 kubectl을 직접 다루지 않고, 웹 UI 컨솔상에서 간편하게 워크로드 설정 항목을 입력하게 함으로써, 잘못된 설정으로 인한 오류 발생을 최소화할 수 있습니다.
웹 UI 컨솔을 통해 입력하더라도 쿠버네티스에서 정의하고 있는 워크로드에 관련된 거의 모든 세부 설정 항목들을 입력할 수 있습니다.
실제 웹 UI 입력 폼을 통해 배포된 워크로드에 대한 상세 현황 정보를 YAML 형식으로도 조회가 가능합니다.
워크로드 그룹 생성
워크로드 생성
워크로드 수정
워크로드 중지/재시작/삭제
워크로드 그룹 관리
서비스 맵의 워크로드 탭 화면에서 워크로드 그룹을 생성합니다.
1) 화면 중앙부 워크로드 목록 아래에 표시된 워크로드 그룹 이름 오른쪽에 확장 메뉴(점 세개) 클릭합니다. 클릭하면 왼쪽이나 오른쪽에 그룹을 추가할 수 있는 메뉴 나옵니다. 오른쪽에 그룹 추가를 선택합니다.
2) 추가할 워크그룹의 이름을 입력할 수 있는 텍스트 입력 폼이 나타납니다. 워크그룹의 이름을 입력하고 엔터키를 누릅니다.
3) 워크그룹이 새로 추가된 것을 확인합니다.
Deployment, StatefulSet, DaemonSet, Job, CronJob 등의 워크로드를 생성합니다. 워크로드의 유형은 달라도 컨테이너 정보를 입력하는 방법은 기본적으로 동일합니다.
워크로드 생성을 시작하기 위해서는 서비스 맵의 워크로드 탭 화면의 우측 상에 표시된 "+생성" 버튼을 클릭합니다.
생성하려는 워크로드의 유형을 선택합니다. 여기서는 Deployment를 선택합니다.
워크로드의 기본정보 (유형, 이름, 그룹, 설명, 라벨, 주석), 배포 및 관리 정책 (Toleration, 배포 정책, 오토스케일링, 업데이트 정책), 컨테이너 정보 (초기화 컨테이너, 컨테이너), 스토리지 정보 (볼륨, 볼륨 마운트)를 입력후 생성 버튼을 클릭합니다.
모든 정보를 입력할 필요는 없습니다. 이름, 그룹, 설명, 한 개 이상의 컨테이너 정보를 반드시 설정해야 하지만, 나머지 정보는 필요에 따라 입력하면 됩니다.
이름, 그룹 (워크로드 그룹), 설명 정보를 입력합니다.
2.2.2.1 컨테이너 기본 정보
컨테이너 이름, 이미지 정보, CPU/Memory/GPU 자원 요청량과 제한량을 입력합니다. 컨테이너 이름과 이미지 정보는 필수 입력 정보입니다. CPU/Memory 자원 요청량과 제한량은 별도 입력하지 않는 경우 입력 화면에서 회색으로 표시되는 디폴트 값이 설정됩니다.
2.2.2.2 컨테이너 명령어 정보
컨테이너에서 실행할 명령어 및 Arguments 정보를 입력합니다.
2.2.2.3 컨테이너 환경 변수
컨테이너에서 사용할 각종 설정 정보를 설정합니다. 설정 정보에는 환경 변수, 컨피그 맵, 시크릿, 워크로드 메타데이터에 대한 필드 참조 유형이 있습니다. 컨테이너에서 사용할 컨피그 맵과 시크릿은 별도의 설정 정보 관리 화면에서 미리 생성해 두어야 합니다.
2.2.2.4 보안 설정
컨테이너에 대한 사용자 및 권한이나 Linux Capabilities를 설정합니다.
2.2.2.5 헬스 체크
컨테이너에 대한 Liveness Probe와 Readiness Probe를 설정합니다.
2.2.2.6 LifeCycle Hook
PostStart, PreStop 라이프 사이클 훅을 입력합니다.
2.2.2.7 컨테이너 포트
컨테이너 포트 정보를 입력합니다.
초기화 컨테이너 정보 입력 항목은 일반 컨테이너의 경우와 동일합니다. 실행 순서가 따를 뿐입니다.
배포, 오토스케일링, 업데이트 정책 입력부는 워크로드 생성 기본 정보 입력부 아랫부분에 위치해 있습니다. 입력 순서는 상관없고, 필요한 경우에만 해당 정보를 설정하면 됩니다
2.2.4.1 Toleration 설정
2.2.4.2 배포 정책 설정
2.2.4.3 오토 스케일링 설정
2.2.4.4 업데이트 정책
설정해 놓은 워크로드에 대한 설정을 업데이트하기 위해서는 해당 워크로드에 대한 설정 화면을 접근합니다. 여기에서는 컨테이너 이미지를 수정하는 경우의 예시를 들겠습니다. 다른 설정 항목을 변경하는 경우에도 변경된 설정 정보를 저장하고 워크로드를 재기동하는 방법은 동일합니다.
워크로드 설정 상세 조회 화면에서 이미지를 변경하고자 하는 컨테이너의 이름을 클릭하면, 이미지 설정을 변경할 수 있는 화면이 나타납니다. 컨테이너 이미지 정보를 직접 입력하거나 CI/CD 파이프라인을 통해 빌드해 놓은 이미지를 선택한 후, "적용" 버튼을 클릭합니다. 변경한 내용으로 컨테이너를 재시작하기 위해서는 워크로드 설정 상세 화면에서 다시 "저장 후 시작" 버튼을 클릭합니다.
워크로드 상세 모니터링 화면에서 컨테이너가 변경된 이미지 설정으로 재기동되는 상황을 조회합니다.
특정 워크로드를 중지하거나 재시작 혹은 삭제하기 위해서는 해당 워크로드의 배포정보 상세 조회 화면을 접근합니다.
실행중인 워크로드의 배포정보 상세 조회 화면 상단 우측의 "동작" 버튼을 클릭하면 중지하거나 재시작할 수 있는 선택 박스가 표시됩니다. 원하는 작업에 따라 "중지" 혹은 "재시작"을 선택합니다.
동작 중인 워크로드를 삭제할 경우에는 우선 워크로드의 실행을 중지하여야 합니다. 실행이 중지된 워크로드의 배포정보 상세 조회 화면 상단 우측의 "동작" 버튼을 클릭하면 시작하거나 삭제할 수 있는 선택 박스가 표시됩니다. 삭제를 선택하면 워크로드가 삭제됩니다.
서비스 맵의 워크로드 조회 메뉴를 접근하면 워크로드들이 워크로드 그룹에 따라 정렬되어 표시됩니다. 워크로드 그룹의 이름이나 배치 등의 표시 방식을 다음과 같이 변경할 수 있습니다.
그룹명 변경
컬럼수 변경
왼쪽으로 이동
오른쪽으로 이동
왼쪽에 그룹 추가
오른쪽에 그룹 추가
이를 수행하기 위해서는 워크로드 그룹 이름 오른쪽에 표시된 확장메뉴(점 세개) 클릭합니다.
워크로드 그룹을 삭제하기 위해서는 해당 워크로드 그룹 내에 어떤 워크로드도 존재해서는 안됩니다. 만일 해당 워크로드 그룹 내에 기존 워크로드가 존재했다면, 모든 워크로드를 우선 삭제해야 합니다.
워크로드 그룹을 삭제하기 위해서는 워크로드 그룹 이름 오른쪽에 표시된 확장메뉴(점 세개) 클릭합니다. 팝업에서 "그룹 삭제"가 활성화 되어 표시되는 것을 볼 수 있습니다. 이를 선택합니다.
설정 정보로서 ConfigMap과 Secret 유형을 제공합니다.
ConfigMap: ConfigMap은 컨테이너에 설정 데이터를 주입하기 위한 쿠버네티스 객체입니다.
Secret: Secret은 암호, 토큰, 키 값 등 민감한 데이터를 포함하는 쿠버네티스 객체로서, 쿠버네티스에서는 Docker-registry, generic, tls 유형을 정의하고 있습니다. 칵테일 클라우드는 이 모든 유형을 지원합니다.
사용자가 설정 정보 관리 메뉴에서 Key-Value 형태로 사용할 설정 정보를 생성해 놓으면, 나중에 컨테이너 설정 시 선택 박스에서 간편하게 컨테이너에서 사용할 설정 정보를 선택할 수 있습니다.
ConfigMap 생성
Secret 생성
설정 정보 조회
워크로드에서 설정 정보 사용
서비스 맵의 설정 정보 화면을 접근하여 우측 상단의 "+생성" 버튼을 클릭합니다. 이때, 컨피그 맵과 시크릿 중에서 컨피그 맵을 선택하도록 합니다.
컨피그 맵의 이름과 설명, 라벨과 주석 정보를 입력합니다. 이름 항목은 필수 입력 항목입니다.
컨피그 맵 정보 입력 화면에서 하단 데이터 섹션 우측의 "+" 버튼을 클릭하여 키-값 정보를 입력합니다. 해당 컨피그 맵에서 여러 개의 키-값 정보를 관리할 경우, 필요한 갯수 만큼 키-값 정보 입력 작업을 반복하면 됩니다.
컨피그 맵 정보 입력 후 이를 실제로 생성하기 위해서는 저장 버튼을 클릭합니다.
서비스 맵의 설정 정보 화면을 접근하여 우측 상단의 "+생성" 버튼을 클릭합니다. 이때, 컨피그 맵과 시크릿 중에서 시크릿을 선택하도록 합니다.
시크릿의 이름과 설명, 유형, 라벨과 주석 정보를 입력합니다. 이름 항목은 필수 입력 항목입니다. 시크릿 유형은 Generic, DockerRegistry, TLS 유형을 지원합니다. 유형의 경우 별도 입력이 없을 경우 Generic 유형으로 설정됩니다.
시크릿 정보 입력 화면에서 하단 데이터 섹션 우측의 "+" 버튼을 클릭하여 키-값 정보를 입력합니다. 해당 시크릿에서 여러 개의 키-값 정보를 관리할 경우, 필요한 갯수만큼 키-값 정보 입력 작업을 반복하면 됩니다.
시크릿 정보 입력 후 이를 실제로 생성하기 위해서는 저장 버튼을 클릭합니다.
서비스 맵의 설정 정보 화면을 접근하여 생성된 설정 정보의 목록을 조회합니다.
설정 정보 목록에 표시된 컨피그 맵 혹은 시크릿 이름 링크를 클릭합니다. 선택한 설정 정보에 대한 상세 정보가 표시됩니다.
설정 정보의 상세 정보를 YAML 형식으로 조회할 수도 있습니다. 상기 화면 우측 상단의 설정 버튼을 클릭한 후 표시되는 화면에서 죄측 상단의 설정 보기를 "YAML 보기"로 선택하면 YAML 형식의 정보가 표시됩니다.
서비스 맵 화면에서 설정 정보를 사용할 워크로드의 이름을 클릭하면, 워크로드의 상세 화면이 표시됩니다. 워크로드 관련 설정을 하기 위해서는 상단 우측의 "설정" 버튼을 클릭합니다. 워크로드 상세 설정 화면이 표시됩니다.
기존 동작 중인 워크로드에서 설정 정보를 사용하려고 하거나 새로 정의하고 있는 워크로드에서 설정 정보를 사용하려고 하거나 설정 방법은 동일합니다.
컨피그 맵 값이나 시크릿 값을 사용할 컨테이너의 이름을 클릭하면, 컨테이너 관련 정보를 설정할 수 있는 화면이 나타납니다. 환경 변수 메뉴를 선택합니다.
컨테이너 환경 변수 설정 화면에서 사용하려고 하는 설정 정보의 유형을 선택합니다. 컨피그 맵 값을 선택하거나 시크릿 값을 선택하였을 경우, 간단하게 사용하려는 설정 정보 리소스 및 설정 정보 리소스가 포함하는 키 값을 선택할 수 있습니다. 컨테이너에서 선택한 설정 정보 키-값을 접근할 환경 변수 키 값을 별도로 입력한 후, "적용" 버튼을 클릭합니다.
환경 변수가 효력을 발휘하기 위해서는 컨테이너의 재시작이 필요합니다. 워크로드 상세 설정 화면 상단 우측의 "저장 후 시작" 버튼을 클릭하여 재기동시킵니다.
워크로드 상세 배포정보 조회 화면에서 환경 변수를 적용한 컨테이너를 찾은 후, 오른쪽 터미널 아이콘을 클릭합니다. 터미널 아이콘을 클릭하면 해당 컨테이너에 대한 대화형 쉘이 화면에 표시됩니다. 대화면 쉘에서 env 명령어를 표시하여, 환경 변수의 내용이 올바르게 설정되어 있는지 확인합니다.
칵테일 클라우드는 다중 클러스터와 팀 또는 조직을 위한 멀티테넌시 환경을 통합 관리하고, DevOps를 위한 자동화 플랫폼을 제공 합니다. 이번 장에서는 칵테일 클라우드의 이해를 위한, 핵심 개념을 살펴 보도록 하겠습니다.
사용자 계정관리 (IAM, Identity & Access Management) 는 보안관리의 시작과 끝이라고 할 수 있습니다. 체계적인 계정관리를 위해서 발급부터 회수까지의 라이프사이클을 관리하고 기록해야 합니다. 이를 위해서는 승인된 사용자에게만 계정 생성과 삭제, 변경에 대한 권한을 부여하고 현재 발급된 계정의 권한 등급과 현황을 확인 할 수 있어야 합니다.
메뉴이동: ⓦ 플랫폼 관리 > ←사용자 계정 > ↑사용자 > 사용자 목록 화면
칵테일클라우드 플랫폼에 로그인하는 사용자는 계정이 필요합니다. 보안 수준을 유지하고 역할을 분리하기 위해, 시스템 설정 및 계정 발급 등의 주요 변경 작업과 플랫폼의 자원관리 및 운영작업은 ‘어드민’ 권한으로 수행하는 것을 권고합니다. 이것은 OS 운영 환경에서 root 권한을 특정 작업에만 임시로 요청하여 사용하는 것과 동일한 이유입니다.
가장 높은 등급의 권한을 가지며, 다른 사용자 계정을 생성하고 권한을 변경할 수 있으며, 감사로그를 열람하고 검색할 수 있습니다.
플랫폼을 생성하고 자원을 할당 할 수 있습니다.
클러스터 계정과 접속 터미널의 접속 권한을 부여 할 수 있습니다.
플랫폼에 워크스페이스를 생성하고 구성원을 추가 할 수 있습니다.
실제 서비스 구동단위인 서비스 맵을 추가 할 수 있습니다.
서비스 맵 추가 시 자원(CPU, Memory, 총Pod 수)을 할당하고 제한 할 수 있습니다.
플랫폼에서 사용할 클러스터를 등록 할 수 있습니다.
할당 된 클러스터의 자원 및 상태 정보를 모니터링 할 수 있습니다.
애드온을 추가하거나 재설치, 재시작 할 수 있습니다.
배포된 애플리케이션 현황을 확인 할 수 있습니다.
컨테이너 이미지를 추가하거나 생성 할 수 있습니다.
레지스트리를 생성하고 관리 할 수 있습니다.
헬름챠트에 공개된 패키지를 플랫폼에 배포 할 수 있습니다.
관리자로 부터 할당받은 워크스페이스의 자원을 관리하고 애플리케이션을 서비스 할 수 있습니다.
워크로드 생성, 서비스 노출 방법, 볼륨 요청 및 사용, 애플리케이션 배포 시 Config 정보, 패키지와 파이프라인 기능을 사용 할 수 있습니다.
컨테이너 이미지를 추가하거나 생성 할 수 있습니다.
헬름챠트에 공개된 패키지를 플랫폼에 배포 할 수 있습니다.
플랫폼의 설정에 필요한 정보를 관리할 수 있는 메뉴가 제공됩니다.
메뉴이동: ←플랫폼 설정
생성된 클러스터를 칵테일 클라우드에 연동하기 위해 플랫폼 정보, 조직 및 담당자, 퍼블릭 클라우드 서비스 접속 계정 등록, 접속 계정에 연결된 클러스터 정보를 입력하고 관리 할 수 있습니다.
플랫폼에 대한 기본 설정 정보를 입력합니다.
이름 (플랫폼 이름 설정)
플랫폼 접속 계정 (로그인 시 사용하는 시스템 계정이름)
사용자 인증 유형 (ID/PW, LDAP etc.)
플랫폼 유형 (설치형, 온라인 서비스 버전, Cube Cluster Engine etc.)
사용 상태 (라이선스 사용 만료일 정보)
기본 언어 (한국어, 일본어, 중국어, 영어 선택 가능)
플랫폼 로고 (플랫폼에 사용할 로고 업로드)
설명 (플랫폼 정보에 대한 추가 설명)
라이선스를 포함한 부가정보를 입력합니다.
조직명 (플랫폼을 사용하는 조직의 이름)
주소 (사업장의 물리적 주소)
담당자 명 (플랫폼 담당자 성명)
담당자 이메일 (플랫폼 담당자 이메일)
라이선스 코드 (계약 시 발급된 라이선스 정보 입력)
퍼블릭 클라우드에 생성된 클러스터를 연동하기 위한해 정보를 설정합니다. 각 CSP 마다 필요한 입력값은 상이 할 수 있습니다.
Cloud Service Provider (CSP) 선택 (AWS, GCP, Azure)
접속 계정명 (접속 계정 식별을 위한 이름 설정)
설명 (클러스터 접속 계정에 대한 설명 입력, 선택 사항)
AWS Access Key ID (AWS 입력 사항)
AWS Secret Access Key (AWS 입력 사항)
Key(Json) (GCP 입력 사항)
Tenant ID (Azure 입력 사항)
Workspace ID (Azure 입력 사항)
Application (Client) ID (Azure 입력 사항)
Client Secret (Azure 입력 사항)
계정 권한 확인
현재 접속 중인 사용자 계정으로 접근 가능한 권한을 가진 클러스터 목록을 제공합니다. 제공된 목록에서 클러스터를 선택하고 Public Cloud Service 접속 계정을 연결할 수 있습니다. 클러스터에 접속 계정 연결을 통해 아래와 같은 기능을 추가로 사용 할 수 있습니다.
클러스터에 연결
클러스터 로그
애플리케이션 로그
서비스 시는 애플리케이션들과 그들 사이의 인터랙션을 구성하는 마이크로서비스들의 네트워크를 기술하기 위해 사용되는 개념입니다.
서비스 시를 관리하기 위한 시장 표준 기술이 Istio입니다. 칵테일은 Istio의 설치와 모니터링을 지원합니다.
서비스 간 연결 구성을 가시화하여 제공합니다.
네트워크 트래픽 모니터링 정보를 제공합니다.
칵테일 클라우드의 애드온 기능을 통해 손쉽게 Istio의 설치가 가능합니다.
Istio의 모니터링 화면이 칵테일 클라우드의 웹 UI와 통합되어 제공됩니다.
서비스 메시 설치
서비스 메시 조회
서비스 메시를 이용하기 위해서는 플랫폼 관리자가 특정 클러스터에 애드온 기능을 통해 Istio를 배포해야 합니다.
플랫폼 관리 화면에서 좌측 클러스터 메뉴를 선택합니다.
클러스터 목록에서 Istio 설치를 원하는 클러스터 이름을 클릭하면, 해당 클러스터에 대한 개요 조회 화면이 표시됩니다. 이때 상단의 "애드온" 메뉴를 클릭하면, 해당 클러스터에 설치된 애드온의 목록이 표시됩니다.
Istio를 설치하기 위해서는 애드온 목록 조회 화면의 우측 상단 "배포" 버튼을 클릭합니다. 이미 클러스터에 설치된 애드온과 설치가능한 애드온 목록이 표시됩니다.
Istio 카드의 "배포" 버튼을 클릭합니다. Istio 애드온에 대한 설명과 배포 시 설정 가능한 Parameter에 대한 설명이 표시됩니다.
Istio 애드온 정보 조회 화면의 상단 우측 "설정" 버튼을 클릭하면, Istio 배포를 위한 설정 정보 입력 화면이 나타납니다. 설정 정보를 입력한 후 "배포" 버튼을 클릭합니다.
클러스터에 istio가 설치되고 나면 해당 클러스터에 속한 서비스 맵 화면을 접근했을 때, 상단에 "서비스 메시" 메뉴가 노출됩니다.
특정 서비스 맵에 대해서 "서비스 메시" 메뉴를 접근합니다. 화면 중앙에 서비스와 워크로드 사이의 연결 관계 및 요청/응답 관련 정보가 표시됩니다. 화면 우측에는 화면 중앙에서 선택한 연결 관계 상의 트래픽 관련 정보가 표시됩니다.
화면 상단 Graph 오른쪽 물음표 버튼을 클릭하면 그래프 조회 방법을 안내받을 수 있습니다.
조회하고자 하는 그래프 유형을 선택합니다.
제공되는 그래프 유형은 다음과 같습니다.
App Graph: 서비스와 워크로드 사이의 연결 관계를 표시합니다. 이 때, 워크로드의 모든 버전을 하나의 그래프 노드로 표시합니다.
Service Graph: 서비스 사이의 연결 관계를 표시합니다.
Versioned App Graph: 서비스와 워크로드 사이의 연결 관계를 표시합니다. 이때, 워크로드의 버전이 여러 개 존재할 때, 워크로드의 개별 버전과의 연결 관계까지 표시합니다. 또한, 동일한 워크로드의 여러 버전을 하나의 박스 안에 포함시켜 표시합니다.
Workload Graph: 서비스와 워크로드 사이의 연결 관계를 표시합니다. 이때, 워크로드의 버전이 여러 개 존재할 때, 워크로드의 개별 버전과의 연결 관계까지 표시합니다. Versioned App Graph와는 달리, 동일한 워크로드의 여러 버전을 하나의 박스 안에 포함시켜 표시하지는 않습니다.
그래프 상에서 노드를 연결하는 Edge 상에서 표시되는 정보를 설정할 수 있습니다. 또한, 그래프 상에서 표시되는 요소들을 설정할 수 있습니다.
"서비스 메시" 메뉴에 접근 시 기본적으로 "대시보드" 메뉴에 접근하게 되며 위의 2. 서비스 메시 조회 에서 설명한대로 서비스와 워크로드 사이의 연결 관계 및 요청 / 응답 관련 정보등을 확인할 수 있었습니다.
"서비스 메시" 메뉴에는 "리소스" 라는 서브메뉴가 존재하는데 해당 메뉴에서 Istio의 Traffic을 관리할 수 있는 기능을 제공합니다.
"서비스 메시" - "리소스" 메뉴에서는 서비스 메시의 주요 기능중 Traffic Management 관련 설정이 가능합니다.
Traffic Management를 구성하는 Object는 Kubernetes의 Custom Resource Definition (CRD)를 이용하여 정의할 수 있습니다.
"리소스" 메뉴에서는 이러한 CRD를 생성 / 편집할 수 있도록 기능을 제공하여 Istio의 Traffic Management 설정이 가능하도록 합니다.
"리소스" 메뉴에서 "생성" 버튼을 클릭한 후 각각의 리소스 유형에 맞는 설정을 할 수 있습니다.
리소스의 구성은 YAML 편집기를 이용하여 생성 / 편집이 가능하며, 이미 생성되어 있는 구성 정보에 대한 삭제 기능도 제공됩니다.
애플리케이션의 빌드에서 배포, 운영 까지의 “개발/운영(DevOps)의 연속성”은 기업 IT 서비스 생산성과 요구 대응 민첩성 측면에서 중요합니다.
칵테일 클라우드가 제공하는 애플리케이션 빌드/배포 파이프라인 자동화 기능은 자체적으로 개발한 기술로서 DevOps 파이프라인의 높은 성능과 자동화를 제공합니다.
사용자는 이미지 빌드 과정을 구성하는 코드 다운로드, 코드 빌드, 테스트 등의 개별 작업 단계를 정의하여 연결함으로써 빌드 파이프라인을 구성하고 실행할 수 있습니다.
각각의 이미지 빌드 단계를 사용자가 정의할 수 있기 때문에, 빌드 과정을 유연하게 구성할 수 있습니다.
파이프라인이 구성되면 코드로부터 컨테이너 빌드까지의 전과정이 자동적으로 수행됩니다.
Jenkins 같은 오픈 소스 도구에 비해 더욱 가볍고 빠르게 실행됩니다.
이미지 빌드 파이프라인 생성
이미지 빌드 실행
파이프라인 목록 조회
파이프라인 메뉴에서의 이미지 업데이트 및 빌드 수행
워크 그룹 화면에서 좌측 이미지/빌드 메뉴를 선택하면, 사용자가 설정해 놓은 이미지 빌드 목록이 표시됩니다. 우측 상단의 "+생성" 버튼을 클릭합니다.
이미지 명, 생성할 이미지 결과를 업로드할 레지스트리, 이미지 태그를 입력합니다.
이미지 파이프라인은 한개 이상의 단위 빌드 작업들로 구성됩니다. 각각의 단위 빌드 작업들에 대해 빌드 작업을 추가하고, 작업에 대한 설정을 수행하도록 합니다.
지원하는 빌드 작업 유형은 다음과 같습니다.
코드 리파지토리 작업
사용자 작업
파일(FTP) 작업
REST 호출 작업
스크립트 작업
이미지 빌드 작
빌드 작업 섹션 오른 편의 "+" 버튼을 클릭하여 빌드 작업을 추가하도록 합니다.
소스 코드가 존재하는 리파지토리와 브랜치 정보를 입력하고, 소스 코드를 접근하기 위한 사용자 정보를 입력합니다. 해당 위치에 존재하는 소스 코드를 사용자가 설정한 코드 저장 경로에 저장하거나 GIT 프로젝트 이름 경로(코드 저장 경로를 설정하지 않았을 경우)에 저장합니다.
컨테이너를 기반으로 실행할 사용자 작업을 설정합니다. 작업 볼륨의 설정을 통해 작업의 입력을 받아 들이거나 수행 결과를 남기는 것이 가능합니다.
빌드할 대상 관련 리소스를 포함하는 원격 호스트와 빌드 작업을 수행할 빌드 호스트 사이에 파일이나 디렉토리를 다운로드하거나 업로드 하는 작업을 설정합니다.
외부 서비스와 REST 방식으로 연동이 필요한 경우, REST 호출 작업을 설정합니다.
스크립트 작업을 정의합니다.
도커 파일 내용을 직접 입력하거나 도커 파일 경로를 입력합니다.
워크 그룹 화면에서 좌측 이미지/빌드 메뉴를 선택하면, 사용자가 설정해 놓은 이미지 빌드 목록이 표시됩니다. 조회를 원하는 이미지 명을 클릭합니다.
빌드를 실행할 이미지 태그를 선택한 후, 빌드 실행 컬럼 아래의 삼각형 버튼을 클릭합니다. 빌드 노트 입력 창이 나타나면 빌드 작업에 대한 설명을 입력합니다.
이미지 빌드 파이프라인 작업이 진행되면서 개별 빌드 작업의 진행 상황을 조회합니다. 처음에는 모두 Wait 상태였다가 성공적으로 종료되었을 경우에는 모두 Done 상태로 표시됩니다.
빌드 상세 화면에서 우측 상단의 "빌드 내역" 버튼을 클릭합니다. 빌드 수행 이력이 표시됩니다.
특정 빌드 수행 건에 대한 빌드 로그를 조회하기 위해서는 해당 빌드 건에 대해 "빌드 로그" 아이콘을 클릭합니다. 빌드가 실패하여 상태가 Error로 표시된 경우에는 빌드 로그를 조회함으로써 실패 이유를 확인할 수 있습니다.
특정 서비스 맵의 상단 파이프라인 메뉴를 조회하면 해당 서비스 맵에 속하는 대상 컨테이너들의 이미지 정보 및 빌드 정보를 조회할 수 있습니다.
대상 컨테이너의 업데이트 유형은 빌드 유형과 이미지 유형으로 구분됩니다. 빌드 유형의 경우 컨테이너 이미지는 칵테일 클라우드에서 구성한 CI/CD 파이프라인을 통해 빌드됩니다. 이미지 유형의 경우 컨테이너 이미지는 외부에서 이미 생성된 이미지를 사용만 하는 경우입니다.
파이프라인 목록 조회 화면에서 이미지를 업데이트하고자 하는 대상 컨테이너의 우측 업데이트 컬럼 아래의 좌우 화살표를 클릭하면 이미지 변경이 가능합니다.
이미지 변경을 선택하였을 때, 새로운 이미지 태그 정보를 입력하거나 기존에 빌드되었던 이미지 태그 목록 중에서 선택할 수 있는 팝업이 표시됩니다.
파이프라인 목록 조회 화면에서 빌드를 수행하고자 하는 대상 컨테이너의 우측 업데이트 컬럼 아래의 삼각형을 클릭하면 빌드 수행이 가능합니다.
빌드 수행을 선택하면 빌드 노트 (빌드 수행에 대한 설명)를 입력합니다. 빌드 수행으로 인한 업데이트 상태를 조회할 수 있습니다.
볼륨은 간단히 말해서 디스크 내지 컨테이너 상에 존재하는 디렉토리 정도로 생각할 수 있습니다. 기본적으로 볼륨의 수명은 그를 감싸고 있는 Pod와 동일합니다. Pod가 존재하길 그치면, 볼륨도 함께 사라집니다.
하지만, 어떤 경우에는 Pod가 사라지더라도 디스크 상의 데이터를 유지해야 할 수 있습니다. 이 경우에는 영구 볼륨을 사용합니다.
일반 볼륨: emptyDir과 hostPath 방식을 지원합니다.
영구 볼륨: 하나의 노드에서만 사용할 수 있는 Single 유형과 여러 노드 상에서 공유할 수 있는 Shared 유형을 지원합니다.
사용자가 필요로 하는 영구 볼륨의 최소 필수 요건을 입력하면 칵테일 클라우드가 내부적으로 자동적으로 관련 PV (Persistent Volume)과 PVC (Persistent Volume Claim) 리소스를 생성하고, 해당 PVC에 대한 PV를 매칭시켜줍니다.
개발자는 설정 중인 Pod에서 생성된 해당 PVC를 선택하여 볼륨 및 볼륨 마운트를 구성만 하면 됩니다.
볼륨 요청 생성
볼륨 요청 조회
컨테이너에서의 볼륨 사용
서비스 맵의 볼륨 요청 화면에 접근하여 우측 상단의 "+생성" 버튼을 클릭합니다. 사용자가 원하는 스토리지 볼륨을 생성하면 내부적으로 볼륨 요청 (PVC)와 볼륨이 자동 생성됩니다.
서비스 맵의 볼륨 요청 화면을 접근하면 사용자가 생성한 볼륨 요청 목록이 표시됩니다.
생성된 볼륨 요청과 관련된 PVC의 상세 정보를 조회하기 위해서는 볼륨 요청 목록에서 이름 링크를 클릭합니다.
생성된 PVC의 상세 정보를 YAML 형식으로 보기 위해서는 상단 화면에서 설정 버튼을 클릭한 후, 좌측 선택 박스에서 "YAML 보기"를 선택합니다.
볼륨 요청 목록 화면에서 생성된 볼륨 요청과 관련된 PV 정보를 조회하기 위해서는 볼륨(PV) 이름 링크를 클릭합니다.
생성된 PV의 상세 정보를 YAML 형식으로 보기 위해서는 상단 화면에서 설정 버튼을 클릭한 후, 좌측 선택 박스에서 "YAML 보기"를 선택합니다.
서비스 맵 화면에서 볼륨을 설정할 워크로드의 이름을 클릭하면, 워크로드의 상세 화면이 표시됩니다. 워크로드 관련 설정을 하기 위해서는 상단 우측의 "설정" 버튼을 클릭합니다. 워크로드 상세 설정 화면이 표시됩니다.
기존 동작 중인 워크로드에서 볼륨을 사용하려고 하거나 새로 정의하고 있는 워크로드에서 볼륨을 사용하려고 하거나 볼륨 및 볼륨 마운트 설정 방법은 동일합니다.
워크로드 상세 설정 화면의 하단 볼륨 섹션의 오른쪽 부분에 있는 "+ Add" 버튼를 클릭합니다.
볼륨 유형을 선택하고, 볼륨 명을 입력합니다. 선택한 볼륨 유형에 따라 추가적인 입력 정보가 요구될 수 있습니다. 영구 볼륨일 경우에는 볼륨 요청을 입력해야 하는데, 미리 설정해 놓은 볼륨 요청 목록이 표시되어 간단하게 선택할 수 있습니다.
"적용" 버튼을 클릭하여 볼륨을 생성합니다.
볼륨을 추가한 후 이를 워크로드에서 사용하기 위해서는 해당 볼륨을 디토리 구조로 마운트시켜야 합니다. 워크로드 상세 설정 화면의 하단 볼륨 마운트 섹션의 오른쪽 부분에 있는 "+" 기호를 클릭합니다.
볼륨을 마운트시킬 컨테이너를 선택하고 볼륨을 선택한 후, "+ 추가" 버튼을 클릭합니다. 마운트 시킬 경로를 입력하도록 합니다.
"적용" 버튼을 클릭하여 볼륨 마운트를 생성합니다.
볼륨 추가 및 볼륨 마운트 설정을 수행한 후, 실제 효과를 발휘하기 위해서는 워크로드 상세 설정 화면 상단 우측의 "저장 후 시작" 버튼을 클릭합니다. 설정한 볼륨과 볼륨 요청이 적용되어해당 컨테이너가 재시작되는 것을 조회할 수 있습니다.
클러스터 내부와 외부에서 워크로드가 제공하는 서비스 기능을 호출하기 위해서 각각 클러스터 IP 방식과 노드 포트 방식의 서비스를 정의합니다.
클라우드에 클러스터를 구성한 상태에서 노드 포트 방식으로 서비스를 정의한 경우, 그 앞단에 로드 밸런서를 구성하여 외부에서 로드 밸런서 주소와 포트를 통해 서비스를 호출하게 할 수도 있습니다.
클러스터 IP
노드 포트
로드 밸런서
웹 UI 컨솔 상에서 손쉽게 각각의 서비스 노출 유형을 생성할 수 있습니다.
퍼블릭 클라우드에서 클러스터를 구성했을 경우 경우, 칵테일 클라우드가 로드벨런서를 자동 생성해 줍니다. 로드벨러서 유형의 서비스 노출은 AWS, Azure, GCP 같이 지원하는 클라우드에서만 가능합니다.
서비스 생성
서비스 조회
인그레스 생성
인그레스 조회
서비스 맵의 서비스 노출 화면에서 우측 상단 "+생성" 버튼을 클릭합니다.
서비스 노출 명 및 라벨 정보를 입력합니다. "라벨 선택기"를 클릭하여 워크로드에 미리 설정되어 있는 라벨을 선택할 수도 있습니다. 미리 설정되어 있는 라벨을 선택하는 경우가 아닌 경우에는, 라벨 이름과 값의 쌍을 입력할 수 있습니다.
서비스에 의해 노출되는 포트를 추가합니다.
설정 정보 입력 후 생성된 서비스를 실제 생성시키기 위해서는 반드시 저장 버튼을 클릭하도록 합니다.
서비스 맵의 서비스 노출 화면에서 생성된 서비스 정보를 조회합니다.
서비스 맵의 서비스 노출 화면에서 서비스 목록을 조회합니다.
서비스 목록에 표시된 서비스 이름 링크를 클릭합니다. 서비스의 설정 정보 및 상태 정보가 표시됩니다.
서비스 설정 정보 및 상태 정보를 YAML 형식으로 조회할 수도 있습니다. 상기 화면 우측 상단의 설정 버튼을 클릭한 후 표시되는 화면에서 죄측 상단의 설정 보기를 "YAML 보기"로 선택하면 YAML 형식의 정보가 표시됩니다.
인그레스는 클러스터 외부로부터 클러스터 내부 서비스로의 HTTP/HTTPS 라우팅을 제어할 수 있게 해 주는 기능입니다. 인그레스를 생성하기 위해서는 칵테일 클라우드의 애드온 관리 화면을 통해 해당 클러스터에 사전에 인그레스 컨트롤러를 설치해 놓아야 합니다.
서비스 맵의 인그레스 화면에서 우측 상단 "+생성" 버튼을 클릭합니다.
인그레스 이름을 입력하고 미리 클러스터에 설치해 놓은 인그레스 컨트롤러를 선택하는 등, 인그레스의 기본 정보를 입력합니다.
인그레스 규칙을 적용할 호스트 정보를 설정하고, 해당 호스트에 대한 인커밍 요청에 대한 벡엔드 서비스로의 라우팅 규칙을 설정합니다.
인그레스와 관련된 TLS (전송 계층 보안) 관련 정보를 설정합니다. 443 포트에서 TLS 트래픽을 종료하기 위해 사용되는 시크릿 정보 및 TLS 인증서에 포함되는 호스트 정보를 입력합니다.
인그레스를 실제 생성시키기 위해서는 반드시 저장 버튼을 클릭하도록 합니다.
서비스 맵의 인그레스 화면에서 생성된 인그레스 정보를 조회합니다.
서비스 맵의 인그레스 화면에서 인그레스 목록을 조회합니다.
인그레스 목록에 표시된 인그레스 이름 링크를 클릭합니다. 인그레스의 설정 정보 및 상태 정보가 표시됩니다.
인그레스 설정 정보 및 상태 정보를 YAML 형식으로 조회할 수도 있습니다. 상기 화면 우측 상단의 설정 버튼을 클릭한 후 표시되는 화면에서 죄측 상단의 설정 보기를 "YAML 보기"로 선택하면 YAML 형식의 정보가 표시됩니다.
최근 기업의 오픈소스 기반 애플리케이션 및 플랫폼 구성 추세가 증가하고 있습니다. 오픈소스는 검증 및 배포, 구성 등에 많은 시간과 노력이 소요됩니다.
칵테일 클라우드는 애플리케이션 구성에 필요한 각종 오픈소스/상업용 소프트웨어 패키지들을 카탈로그 방식으로 제공하여 사용자가 손쉽게 설치할 수 있는 환경을 제공합니다.
공식 패키지: 검증된 구성의 관리형 패키지 (AI, IoT, BlockChain, Bigdata 등 기업 디지털 전환을 위한 패키지)를 제공합니다.
오픈소스 패키지: 검색을 통한 오픈소스 패키지 죄회 및 배포가 가능합니다.
사전 구성된 패키지를 클러스터에 원클릭 배포가 가능합니다. 이때, 배포되는 환경별로 상이한 환경 변수 등의 정보의 경우에 있어서는 사용자의 별도 설정이 가능합니다.
배포된 패키지의 워크로드 구성 현황 및 모니터링이 가능합니다.
패키지 배포 이후 신규 패키지가 추가되었을 때, 웹 GUI 상에서 패키지 버전 업그레이드를 간편하게 수행할 수 있습니다. 또한, 패키지 배포 시 설정했던 Parameter를 변경할 경우에도, 손쉽게 Parameter 변경 및 적용 작업 수행이 가능합니다.
특정 워크그룹 하의 좌측 "카탈로그" 메뉴를 클릭하면, 이용할 수 있는 패키지 목록이 표시됩니다.
카탈로그 화면의 우측 상단의 검색창을 통해 설치를 원하는 패키지를 검색할 수 있습니다.
관심이 있거나 배포를 원하는 패키지에 대해 "배포" 버튼을 클릭하면, 최신 패키지 버전에 대한 개요 정보와 더불어 패키지 배포 시 설정 가능한 Parameter들에 대한 설명이 제공됩니다. 이전 패키지 버전에 대한 정보를 조회하기 위해서는 화면 상단에 위치한 선택 박스를 통해 이전 패키지 버전을 선택하도록 합니다.
패키지 배포를 위해서는 패키지 도움말 화면 우측 상단의 "설정" 버튼을 클릭한 후, 배포를 위한 설정 정보를 입력한 후 "배포" 버튼을 클릭합니다.
이 때, 패키지 배포 실행 전 디폴트로 설정되어 있는 Parameter 값들을 선택적으로 변경할 수도 있습니다. 아래 Values (yaml) 섹션 아래에 표시된 파일 상에서 변경을 원하는 Parameter를 찾아 값을 직접 변경합니다.
배포 수행 후에는 화면이 해당 패키지의 패키지 상세 조회 화면으로 이동됩니다.
카탈로그를 통해 배포된 패키지들의 목록을 조회하기 위해서는 서비스 맵 화면의 상단 "패키지" 메뉴를 클릭합니다.
패키지 배포 목록 조회 화면에서 특정 패키지의 이름을 클릭하면 해당 패키지의 상세를 조회하는 화면이 표시됩니다.
네임스페이스 상에 배포된 워크로드들의 상태, 배포 현황, 자원 사용량을 제공합니다.
서비스 맵 대표 화면에서는 네임스페이스 단위로 배포된 워크로드들을 그룹 별로 조직화하여 배포 상태와 자원 사용량 정보를 제공합니다.
이 때, 사용자가 특정 워크로드에 대한 상세 현황을 조회하길 원할 경우, 워크로드 별로 CPU 사용량, Memory 사용량, 네트워크 사용량 정보를 별도로 제공합니다.
네임스페이스에 배포된 워크로드들의 상태 가시성 및 관리 편의성을 높이기 위해 워크로드 그룹 관리의 개념을 도입하였습니다.
워크로드 그룹은 사용자가 비슷한 유형의 워크로드들을 그룹화 시킨 것으로 (예를 들어, Frontend, Build, API, Monitoring, Tools, Database 등), 그에 따라 워크로드 현황 정보가 카드 형태로 표시됩니다.
모니터링할 서비스 맵 선택
서비스 맵에서의 배포 현황 조회
서비스 맵에서의 워크로드 목록 조회
개별 워크로드 상태 조회
워크스페이스의 서비스 맵 화면을 접근하면 서비스 맵 목록이 표시됩니다. 모니터링하고 싶은 서비스 맵의 이름을 클릭합니다.
특정 서비스 맵의 이름을 클릭하면 해당 서비스 맵에서의 배포 현황에 대한 개요가 표시됩니다.
서비스 맵 조회 화면에서 상단 "워크로드" 버튼을 클릭하면 해당 서비스 맵에서의 워크로드 목록이 여러 개의 카드가 나열되는 형식으로 표시됩니다. 각각의 워크로드는 워크로드가 속하는 워크로드 그룹에 따라 배치됩니다.
각각의 카드는 워크로드에 해당하며 워크로드의 동작 상태도 함께 표시되기 때문에 서비스 맵에 속한 워크로드들의 상황을 간편하게 일별할 수 있습니다.
워크로드 목록 표시 화면에서 특정 워크로드의 이름을 클릭합니다. 해당 워크로드의 배포정보가 표시됩니다.
워크로드 배포정보 조회 화면에서 상단 우측 "모니터링" 버튼을 클릭하면, 워크로드의 CPU/Memory/네트워크 사용량이 차트로 표시됩니다.
해당 워크로드의 구성이나 상태 정보를 YAML 형식으로 조회하기 위해서는 상단 우측 "설정" 버튼을 클릭한 후, "설정 보기"를 "YAML 보기"로 변경합니다.
클러스터는 클라우드 네이티브 어플리케이션이 배포/실행되는 인프라 입니다. 따라서 칵테일 클라우드를 처음 시작 할 때 반드시 등록하여야 합니다.
칵테일 클라우드는 물리, 가상화 인프라부터 퍼블릭 클라우드까지 다양한 유형의 클러스터를 등록하여 통합 관리 할 수 있습니다. 여기서는 설명을 위해 구글(Google) 클라우드의 GKE(Google Kubernetes Engine)을 예로 들겠습니다. GKE는 OAuth인증 방식을 지원하여 클러스터 등록과정이 간편합니다.
GKE 클러스터를 생성하는 과정은 해당 사용 설명서를 참고 합니다. 만약 구글 사용자 등록을 하지 않았다면, 먼저 사용자 등록을 하여야 합니다. 등록한 사용자는 이 후 칵테일 클라우드에서 클러스터 등록 시 사용 됩니다.
생성된 GKE 클러스터를 다음 절치에 따라 칵테일 클라우드에 등록 합니다.
1) ⓦ 플랫폼 관리 > ←클러스터 > 〓 (클러스터 등록 버튼 선택)
1) 클러스터 설정 폼의 프로바이더 속성을 'Google Cloud Platform'으로 선택 합니다.
2) 유형 속성을 'GKE'로 선택 합니다.
3) 위 두가지 속성을 선택하면 클러스터 설정 폼에 인증 속성이 표시됩니다.
4) 인증 버튼을 누르면 구글의 인층 창이 뜨고, 이 곳에 구글 계정을 입력 합니다.
이 계정은 등록 할 GKE 클러스터를 생성 할 때 사용한 계정이어야 합니다.
1) 인증이 완료 되면 인증 속성에 '인증 완료'가 표시됩니다.
2) 프로젝트 아이디 속성에서 구글 클라우드의 프로젝트 아이디를 선택합니다.
프로젝트 아이디는 등록하려는 GKE 클러스터가 생성된 프로젝트 이어야합니다.
3) 클러스터 속성에서 등록할 GKE 클러스터를 선택합니다.
4) 러스터 이름 속성에 칵테일 클라우드에서 관리할 클러스터 이름을 입력합니다.
아이디는 영문 소문자, 숫자, 특수문자 3가지(- . _)만 가능합니다.(예: gke-demo-cluster)
또한 이미 등록된 다른 클러스터의 이름과 중복되지 않아야 합니다.
5) 아이디 속성에 클러스터의 아이디를 입력합니다.
6) 클러스터 등록을 위해 메뉴 바에서 '저장' 버튼을 선택합니다.
참고로, 입력하지 않은 나머지 속성은 클러스터 등록 후 GKE 클러스터의 정보를 통해 자동 입력됩니다.
7) 등록이 완료 되면 클러스터 목록이 출력됩니다. 이 곳에서 방금 등록 했던 클러스터를 확인 할 수 있습니다.
다음 과정은 등록 한 클러스터에 어플리케이션을 배포하기 위하여, 작업 공간을 만듭니다. '워크스페이스 만들기 ' 페이지로 이동 하세요.
대 고객 비즈니스 요구에 따라 서비스를 제공하는 환경(멀티 클라우드)에서 멀티 클러스터로 서비스 환경을 구축 할 수 있다는 점이 칵테일클라우드의 가장 큰 장점입니다.
클러스터 등록 방법 아래 링크를 참고하세요.
멀티 클라우드 구성시, 모든 종류의 환경을 비즈니스 요구사항에 따라 클러스터로 구성하여 통합된 단일 플랫폼에서 관리 가능합니다. 즉, 비즈니스 요구사항에 따라 클라우드 서비스 프로바이더와 온-프레밍스 환경을 벤더에 의한 제약 없이 전략적으로 선택하여 사용할 수 있다는 의미입니다.
구성 가능한 서버 인프라 환경
온-프레미스
데이터센터
프라이빗 클라우드
퍼블릭 클라우드
비즈니스 요구사항과 지역적, 법률적, 보안적 요구사항을 모두 충족하기 위해 하이브리드 클라우드를 선택하는 기업들이 늘어나고 있습니다. 하이브리드 환경으로 서비스를 구성할 경우에도 단일 플랫폼에서 구성된 모든 형태의 클러스터를 아래의 예시와 같이 구성 할 수 있습니다.
앞서 “클러스터 등록” 과정에 대해 설명 하였습니다. GKE 클러스터를 만들어 어플리케이션을 배포하고 실행하는 인프라를 준비 하였습니다. 이제 작업공간인 워크스페이스(Workspace)를 만들어 보겠습니다.
워크스페이스는 클러스터 자원을 할당 받아 어플리케이션을 빌드, 배포, 운영하는 공간입니다. 보통 팀 단위로 만듭니다. 여기서는 예로 ‘DevOps’팀의 워크스페이스를 만들고 이곳에 앞 만든 GKE 클러스터를 할당하여 워크스페이스를 생성하는 과정을 설명합니다.
아래 이동 경로에 따라 워크스페이스 관리 화면으로 이동합니다.
1) ⓦ 플랫폼 관리 > ← 워크스페이스 > 〓 (생성 버튼 선택)
1) 워크스페이스 생성 화면의 기본 정보 폼에서 이름 속성에 워크스페이스 이름을 입력 합니다.
2) 색상 속성에서 워크스페이스의 색상을 선택합니다.
워크스페이스의 색상은 화면의 ‘상단 바(Top Bar)’에 적용됩니다.
3) 설명 속성에 워크스페이스의 설명을 입력합니다.
4) 자원 할당 방식을 선택합니다.
Cluster : 클러스터 단위로 자원 할당
Service Map : 클러스터 내에서 네임스페이스 단위로 자원 할
*자원 할당 방식은 워크스페이스 생성 후 변경이 가능합니다.
1) 워크스페이스 생성 화면의 클러스터 목록에서 상단 측의 생성 버튼을 선택합니다.
생성 버튼을 선택 하면, 클러스터 등록 창이 나타납니다.
2) 클러스터 등록 창의 클러스터 속성에서 앞서 생성한 GKE 클러스터를 선택합니다.
3) 새로운 네임스페이스를 생성 할 지, 이미 생성된 네임스페이스를 사용할 지 선택합니다.
4) 서비스 맵 그룹을 선택합니다.
5) 서비스맵 이름과 네임스페이스 이름을 입력합니다.
6) 네트워크 정책을 선택합니다.
모든 인그레스 트래픽 차단/이그레스 트래픽 허용 (디폴트)
모든 인그레스 트래픽 허용/이그레스 트래픽 차단
모든 인그레스/이그레스 트래픽 허용
모든 인그레스/이그레스 트래픽 차단
7) 클러스터 목록에 추가 한 클러스터가 나타나는 지 확인 후, 클러스터 등록 창 하단의 적용 버튼을 선택합니다.
8) 클러스터를 추가 하기 위해, 생성 버튼을 선택합니다.
서비스 맵을 생성 할 때, 체크박스를 선택하여 추가적인 설정이 가능합니다.
자원 할당 사용 (디폴트)
CPU 요청량, CPU 제한량, Memory 요청량, Memory 제한량, 총 Pod 수
Container Limit Range 설정 사용 (디폴트)
CPU/Memory 기본요청값, 기본제한값, 최소값, 최대값
Pod Limit Range 설정 사용
CPU/Memory 최소값/최대
Storage Limit Range 설정 사용
Storage
9) 워크스페이스의 클러스터 목록에 등록한 클러스터가 표시되는 것을 확인합니다.
1) 워크스페이스의 생성 화면 상단에 저장 버튼을 선택하여 워크스페이스를 생성합니다
2) 워크스페이스 목록 화면에서 생성 된 워크스페이스를 확인합니다.
워크스페이스가 준비 되면, 이제 해당 워크스페이스에 할당 된 클러스터에 어플리케이션을 배포 할 수 있습니다. 다음은 이 과정에 대해 설명 합니다. ‘어플리케이션 배포’ 페이지로 이동 하세요.
워크스페이스(Workspace) 는 클러스터 자원을 할당 받아 애플리케이션을 빌드, 배포, 운영하는 공간입니다. 보통 팀단위로 만들어 사용하며, 사용 목적에 따라 사용자, 클러스터, 라이브러리를 등록할 수 있습니다.
워크스페이스를 만드는 방법은 아래 링크를 참조하시기 바랍니다.
클러스터 자원은 승인된 관리자에 의해 요청에 따라 워크스페이스 단위로 할당하여 사용합니다.
관리자는 서비스 규모와 요청에 따라 효율적인 할당과 관리가 가능하고, 사용자 그룹은 명시적으로 할당된 자원을 계획적으로 사용 할 수 있습니다. 또한, 워크스페이스 단위로 안전하게 격리된 환경은 다른 팀/그룹의 자원 사용에 어떤 영향도 받지 않습니다.
클러스터는 전용으로 유저그룹에 할당 할 수 있으며, 두개 이상의 워크스페이스에 공유해서 사용 할 수도 있습니다. 자원을 전용으로 사용 할 경우 보다 높은 독립성을 보장 받을 수 있습니다. 자원을 공유하여 사용 할 경우 대용량의 클러스터 혹은 특수한 자원(GPU Node) 을 중복 투자 없이 활용 가능합니다.
클러스터의 주요 구성요소는 노드, 스토리지, 애플리케이션 입니다. 구성한 클러스터가 계획에 따라 동작하도록 관리하기 위해서는 모니터링과 알림 그리고 보안 설정이 추가로 필요합니다.
클러스터 관리에 필요한 도구와 내용을 하나씩 살펴 보도록 하겠습니다.
메뉴이동: ←클러스터
클러스터 공급자(Cloud Service Provider) 종류, 물리적 위치(지역)
클러스터 동작 상태 (Running/Stop)
클러스터 자원 할당 유형 (클러스터/서비스 맵)
클러스터 할당 노드 수
클러스터 할당 자원
클러스터 할당 워크스페이스 수
클러스터 발생 알림
[기능] 클러스터 등록
[기능] 클러스터 웹 접속 터미널 연결 링크
[기능] 클러스터 외부 접속 인증서 다운로드
칵테일 클라우드는 온-프레미스 환경(물리적 서버) 과 클라우드 서비스에 구 가능하며, 지속적으로 추가 연동을 개발하고 있습니다.
On-Premise (물리서버)
Amazon Web Service
Google Cloud Platform
Microsoft Azure
Alibaba Cloud
Tencent Cloud
Rovius Cloud
클러스터 등록(생성) 은 아래 링크에서 상세히 설명하고 있습니다.
등록된 클러스터의 자원과 상태를 확인하기 위해서 클러스터 목록 화면으로 이동합니다.
메뉴이동: ⓦ 플랫폼 관리 > ←클러스터
클러스터 목록 화면에서 접근 가능한 클러스터의 목록이 표시됩니다.
클러스터 목록 화면 제공 정보
클러스터 이름 (사용자 지정)
공급자, 지역 (클라우드 서비스 프로바이더 구분, 물리적 위치 및 리전)
상태 (Running, Stop)
자원 할당 유형 (플랫폼, 클러스터, 서비스 맵)
노드 수 (클러스터 구성 노드 수)
클러스터 자원 (CPU, Memory, Storage) 현황
워크스페이스 (클러스터 자원)
알람 (발생된 알람 수)
등록된 클러스터의 구성 자원을 변경하거나 등록 정보를 변경하기 위해서 등록 정보 화면으로 이동합니다.
메뉴이동: ⓦ 플랫폼 관리 > ←클러스터 > (클러스터 선택) > ↑개요 > 등록정보 화면
(클라우드서비스) 프로바이더
(클라우드서비스) 서비스 유형
서브스크립션 아이디 (Azure AKS 선택 입력)
프로젝트 아이디 (Google GKE 선택 입력)
클러스터 (클러스터 이름)
리전 (프로바이더 및 서버의 지역적/물리적 위치)
클러스터 이름 (칵테일 클라우드에서 표현될 이름)
쿠버네티스 버전 (클러스터에서 사용하는 쿠버네티스 버전 정보)
아이디 (클러스터 공유 아이디, 알라메시지 리다이렉트 시 필요)
설명 (클러스터에 대한 사용자 설명을 추가)
마스터 주소 (Kubernetes API 주소. “ https://host:port ” 형식을 사용한다.)
인그레스 호스트 (인그레스 방식에 사용할 Host IP Address 서비스, Master IP or Load balancer IP)
노드 포트 호스트 주소 (노드에 포트를 붙여 서비스 노출하는 방식에서 포트 앞에 사용할 IP서비스, Master IP or Load balancer IP)
노드 포트 범위 (노드에 포트를 붙여 서비스 노출하는 방식에서 IP뒤에 사용할 포트의 범위, 30000~32767 권장)
Cluster CA Certification (마스터 서버 접속 후 /etc/kubernetes/pki 경로 이동 후 ca.crt파일값 입력)
Client Certificate Data (마스터 서버 접속 후 /etc/kubernetes/pki 경로 이동 후 admin.crt파일 값 입력)
Client Key Data (마스터 서버 접속 후 /etc/kubernetes/pki 경로 이동 후 admin.key파일 값 입력)
메뉴이동: ⓦ 플랫폼 관리 > ←클러스터 > (클러스터 선택) > ↑노드 > 노드 목록 > (노드 이름 선택) > 모니터링 화면
자원 사용 현황(CPU, Memory, Disk, 네트워크), 자원 요약(용량, 가용량, 요청량), 상태(이벤트 발생에 따른 유형, 상태, 최근 발생 시간, 최근 경과시간, 발생 이유, 메시지) 정보가 제공 됩니다. 노드에 대한 모니터링 정보는 통합 모니터링 메뉴에서도 추가적인 정보를 얻을 수 있습니다
클러스터에 스토리지를 할당하기 위해 서는 스토리지 생성 화면으로 이동합니다.
메뉴이동: ⓦ 플랫폼 관리 > ←클러스터 > (클러스터 선택) > ↑스토리지 > 스토리지 목록 > +생성 > 스토리지 생성 화면
스토리지 생성을 위해 유형을 선택합니다. 공통의 환경에서는 NFS 와 NFS Named 유형이 제공되며, Azure 서비스는 Azure Disk 와 Azure File 유형을 추가로 제공합니다.
선택한 유형에 따라 스토리지 생성을 위한 상세 설정이 가능하며, 설정 가능한 정보(스펙)는 아래와 같습니다.
이름 (스토리지 이름)
설명 (스토리지 사용자 설명)
기본 스토리지 (기본 스토리지 사용여부 선택)
정책 (스토리지 삭제 시 정책 설정, Retain or Delete)
총용량 (스토리지 총용량, Gb)
프로비저너 (스토리지 프로비저닝 값 입력)
라벨 (스토리지 라벨 설정)
주석 (스토리지 주석 설정)
Step 4. 파드 보안 설정
클러스터 레벨에서 보안 측면을 제어하기 위해 파드 시큐리티 폴리시를 사용하면 파드 생성 및 업데이트에 대한 세분화된 권한을 부여 할 수 있습니다.
미리 준비된 설정 필드들을 통해 시스템에 적용하기위한 기본값뿐만 아니라 시스템에 적용하기 위해 파드가 실행해야만 하는 조건 셋을 정의 할 수 있으며, 관리자는 아래와 같은 기능을 제어 할 수 있습니다.
제어 가능한 Pod Security 주요 기능
특권을 가진(privileged) 컨테이너의 실행 privileged
호스트 네임스페이스의 사용 hostPID, hostIPC
호스트 네트워킹과 포트의 사용 hostNetwork, hostPorts
볼륨 유형의 사용 volumes
호스트 파일시스템의 사용 allowedHostPaths
특정 FlexVolume 드라이버의 허용 allowedFlexVolumes
파드 볼륨을 소유한 FSGroup 할당 fsGroup
읽기 전용 루트 파일시스템 사용 필요 readOnlyRootFilesystem
컨테이너의 사용자 및 그룹 ID runAsUser, runAsGroup, supplementalGroups
루트 특권으로의 에스컬레이션 제한 allowPrivilegeEscalation, defaultAllowPrivilegeEscalation
컨테이너의 SELinux 컨텍스트 seLinux
컨테이너에 허용된 Proc 마운트 유형 allowedProcMountTypes
컨테이너가 사용하는 AppArmor 프로파일 어노테이션
컨테이너가 사용하는 seccomp 프로파일 어노테이션
컨테이너가 사용하는 sysctl 프로파일 forbiddenSysctls,allowedUnsafeSysctls
칵테일클라우드에서 배포한 애플리케이션은 워크로드 단위로 배포 되며, 배포 현황에서 확인 가능합니다. 메뉴 이동 : ⓦ 플랫폼 관리 > ←클러스터 > (클러스터 선택) > ↑배포 현황 > 워크로드 목록 화면
배포한 애플리케이션의 배포 상태를 포함하여 워크로드 이름, 워크로드 상태, 배포 유형(Deployment, Daemon Set, Stateful Set, Job, Cron Job), 인스턴스 갯수, 현재 자원 사용량(CPU, Memory) 배포 후 서비스 Uptime(Age) 등을 확인 할 수 있습니다.
운영중인 워크로드 (혹은 인스턴스)에서 알림이 발생 할 경우, SMS(Slack 등), E-mail, 대시보드를 통해 실시간으로 현황을 제공합니다.
메뉴이동 : ⓦ 플랫폼 관리 > ←클러스터 > (클러스터 선택) > ↑알림 > 알림 목록 화면
알림 목록을 통해 해결되지 않은 알림들이 출력되며, 각 알림들은 알림명(상태 요약). 중요도(Critical, Warning), 발생 일시가 제공됩니다.
알림의 상세 정보를 확인하기 위해 알림명을 선택하면, 알림 상세 정보 팝업을 통해 추가정보가 제공됩니다.
칵테일 클라우드에서 애드온은 클러스터 운영에 편의를 제공하는 프로메테우스를 포함한 클러스터 매니지먼트 컴포넌트는 애드온 매니저 기능으로 등록/삭제/롤백/재 배포 가능합니다. 사용자 요구애드온 수집/보관 매트릭 대상을 추가/수정 할 수 있습니다.
모니터링 애드온 수정
CPU / MEM 등의 상태 및 자원 등의 매트릭 대상 사용자 지정
매트릭 임계치 및 최대 / 최소치 사용자 지정
지정된 수치에 따라 이벤트 및 알람 발생
애드온 버전에 따른 개별 모니터링 매트릭 지정
수정된 매트릭 배포
수정된 매트릭 정보 (Rule, Config) 를 ETCD 저장
수정된 사용자 정보에 따라 애드온 등록/삭제/롤백/ 재 배포 기능 제공
저장 공간 부족하거나 계획한 작업에 따라 스토리지를 증설 한 경우, 이미 배포되어 있는 Pod 는 증설된 스토리지 정보를 확인 할 수 없습니다. 증설된 스토리지를 정상적으로 사용하기 위해서는 (증설 전) 배포 된 Pod 들을 재시작 해야 합니다.
메뉴이동: ←서비스 맵 > ↑서비스 맵 > ▤ (서비스맵 선택) > ↑워크로드 > ▤( 워크로그 선택) > ▣ 워크로드 상세 > 재시작 선택
칵테일 클라우드는 멀티클러스터 환경에서 발생하는 자원과 상태에 대한 200여개의 매트릭값을 활용하여 100여개의 모니터링 패널을 제공합니다.
각각의 패널은 클러스터, 인그레스, ETCD, 노드, 네임스페이스 뷰 배치하여 제공합니다. 또한, 알람/이벤트 페이지를 추가로 제공하며, 발생한 알람/이벤트에 대하여 시간순으로 확인하고 사용자 플랫폼 현황의 가시화를 극대화 합니다.
칵테일 클라드 모니터링 정보는 ←대시보드 메뉴에서 확인 할 수 있습니다. 하위 메뉴로는 클러스터, 인그레스, ETCD, 노드, 네임스페이스, 알림/이벤트 가능을 제공합니다.
클러스터 단위로 최신의 상태 정보를 제공합니다. 클러스터 뷰에서 대표적으로 제공되는 상태 정보는 아래와 같습니다.
현재 연결 수 총계
CPU 사용량
디스크 사용량
디스크 I/Os
메모리 사용량
리스타트 된 Pod 추적
초당 평균 요청 시간
실행 중인 Pod 추이
Top 5 CPU 집중 사용 Pod
Top 5 메모리 집중 사용 Pod
인그레스는 클러스터 외부에서 클러스터 내부 서비스로 HTTP와 HTTPS 경로를 노출합니다. 인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름 기반의 가상 호스팅을 제공하도록 구성할 수 있습니다. 인그레스는 서비스에서 네트워크 영역에 중요한 역할을 담당하고 있어 다각도의 모니터링이 필수입니다.
통합대시보드의 인그레스 뷰에서 제공되는 상태 정보는 아래와 같습니다.
인그레스 컨트롤러 요청
인그레스 컨트롤러 연결
인그레스 컨트롤러 요청 성공률
최근 인그레스 설정 리로드 성공 및 실패
인그레스 컨트롤러 요청 추이
인그레스 컨트롤러 성공율 추이
네트워크 I/O 추이
평균 메모리 사용량 추이
평균 CPU 사용량 추이
통합대시보드의 ETCD 뷰에서 제공하는 상태 정보는 아래와 같습니다.
ETCD 리더 존재 여부
최근 리더 변경 횟수
최근 리더 변경 제안 실패 횟수
gRPC 성공율
DB 사용량
동기화 시간
클라이언트 트래픽 In/Out
통합대시보드의 노드 뷰에서 제공하는 상태 정보는 아래와 같습니다.
클러스터 CPU 사용 빈도
클러스터 메모리 사용량
클러스터 디스크 사용량
클러스터 네트워크 사용량
클러스터 업타임
통합대시보드의 네임스페이스 뷰에서 제공하는 상태 정보는 아래와 같습니다.
네임스페이스 서비스레벨 목표(SLO)율 추이
네임스페이스 잔존 실패 허용 시간(Error budget)
네임스페이스 총 Pod 수
네임스페이스 생성 시간
네임스페이스 사용 메모리 총량
네임스페이스 안에 실행 중인 Pod 수
통합대시보드에서 모니터링하는 매트릭정보는 사용자 설정에 따라 대시보드, SMS, E-Mail 채널을 통해 전달되며 클러스터, 네임스페이스, 주요 자원 그룹 으로 필터링하여 조회할 수 있는 기능을 제공합니다.
대시보드에서는 발생한 이벤트를 한 시간단위로 조회하여 확인 할 수 있으며, 매 분 단위로 누적된 이벤트를 상세한 이벤트 설명을 포함하여 제공하므로, 이벤트 내용만으로 원인을 신속히 확인 할 수 있습니다.
각 이벤트는 심각도에 따라 5단계로 구분하여 표시되며, 사용자 설정에 따라 SMS 또는 E-Mail(혹은 양쪽 모두) 을 통해 실시간으로 알림을 전송합니다. 최근 발생한 이벤트와 알림은 필터 기능을 이용하여 조회 할 수 있으며, 사용자 설정에 따라 최대 1년까지 보관 가능합니다.
