서비스맵
서비스 맵(Service Map)은 애플리케이션을 구성하고 다양한 리소스(Resource)를 관리하는 단위입니다. 쿠버네티스는 애플리케이션을 네임스페이스(Namespace) 단위로 관리합니다. 네임스페이스는 클러스터를 논리적으로 나누어 컨테이너를 배포하고 관리하는 일종의 가상 클러스터입니다. 서비스 맵은 칵테일에서 제공 되는 애플리케이션 관리 공간으로, 네임스페이스를 기반으로 추가적인 관리 기능을 제공합니다.
대표적인 서비스 맵 리소스는 컨테이너를 배포하고 관리하는 워크로드(Workload)를 들 수 있습니다. 이 외에 영구 볼륨, 설정 정보, 서비스 노출 등의 리소스가 있습니다.
파드(Pod = Containers)
파드는 컨테이너를 배포/실행하는 리소스로 하나 이상의 컨테이너로 구성됩니다. 애플리케이션 로직 처리를 담당하는 주 컨테이너(Main Container)와 보조 역할을 담당하는 사이드카 컨테이너(Sidecar Container)입니다. 대 부분의 경우 주 컨테이너 만 필요하지만, 로그 수집, 백업, 프록시 등의 기능이 필요할 경우 별도의 사이드카 컨테이너를 추가하여 확장합니다.
파드 내의 컨테이너들은 동일한 네트워크(localhost)와 볼륨을 공유하여, 컨테이너 추가로 확장이 용이합니다.
파드는 독립적으로 생성 할 수 있지만, 일반적으로 복제, 업데이트 등 배포와 수명 주기를 담당하는 워크로드를 통해 생성/관리됩니다.
워크로드(Workload)
워크로드는 파드의 배포와 수명 주기를 담당하는 서비스 맵 리소스입니다. 워크로드는 파드를 어떤 형태로 배포하고 실행할지, 파드 상태 확인, 문제 시 재시작 등 파드의 전체 수명 주기를 관리합니다.
칵테일에서는 YAML이나 kubectl을 직접 다루지 않고, 웹 UI 콘솔상에서 간편하게 워크로드 설정 항목을 입력하게 함으로써, 잘못된 설정으로 인한 오류 발생을 최소화할 수 있습니다.
웹 UI 콘솔을 통해 입력하더라도 쿠버네티스에서 정의하고 있는 워크로드에 관련된 거의 모든 세부 설정 항목들을 입력할 수 있습니다.
실제 웹 UI 입력 폼을 통해 배포된 워크로드에 대한 상세 현황 정보를 YAML 형식으로도 조회가 가능합니다.
워크로드는 몇 가지 유형으로 구분됩니다. 각 유형마다 파드의 배포와 실행, 관리 방식 차이가 있습니다.
워크로드 그룹
하나의 네임스페이스에서는 여러 가지 유형의 워크로드들이 실행될 수 있고, 경우에 따라서는 한눈에 파악하기 힘들 정도로 많은 워크로드들이 수행될 수 있습니다.
워크로드들의 유형에 따라 워크로드 그룹들로 조직화한 후에, 워크로드 그룹에 따라 워크로드들의 상태를 표시한다면 워크로드들의 상태를 일목요연하게 파악할 수 있습니다.
디플로이먼트(Deployment) 워크로드
동일한 파드를 복제 수만큼 배포하여 문제 되는 파드가 있더라도 안정된 서비스를 제공할 수 있습니다. 웹 서버와 같이 데이터 관리를 하지 않는 스테이트리스(Stateless) 애플리케이션 구성에 주로 사용됩니다. 복제된 파드가 동일한 컨테이너이므로 데이터 관리에는 적합하지 않기 때문입니다.
디플로이먼트 워크로드는 파드의 롤링 업데이트(Rolling Update)도 지원합니다. 순차적으로 파드를 교체하는 방식으로 서비스에 영향을 주지 않고 업데이트를 수행합니다.
파드가 요청된 CPU 또는 Memory 자원을 일정량 이상 사용할 때, 자동으로 파드 복제 수를 증가시키는 오토 스케일링(Auto Scaling)도 지원합니다.
스테이트풀셋(StatefulSet) 워크로드
서로 다른 역할을 수행하는 파드를 복제 수만큼 배포하여 워크로드를 구성합니다. 데이터 베이스, Key-Value 저장소, 빅데이터 클러스터 등 데이터 저장과 관리 애플리케이션에 적합한 방식입니다. 각 파드에는 고유한 이름이 부여 되므로, 파드 간 통신을 통해 작업을 처리할 수 있습니다. 각 파드는 고유한 영구 볼륨을 사용하여 데이터를 저장/관리합니다.
데몬셋(DaemonSet) 워크로드
백그라운드(Background)에서 계속 실행되면서 작업을 처리하는 프로세스를 데몬(Daemon) 프로세스라 합니다. 데몬셋 워크로드는 데몬 프로세스 파드를 클러스터의 모든 노드에 배포하고 관리하는 서비스 맵 리소스입니다.
모든 노드에서 백그라운드 처리를 하는 작업으로는 각 노드의 로그 수집, 자원/상태 등 모니터링 데이터 수집 등이 있습니다.
잡(Job) 워크로드
한 번의 실행으로 작업을 처리하는 파드는 잡 워크로드를 통해 배포합니다. 잡 워크로드의 파드는 데이터 변환, 기계 학습 등 주로 일괄 작업 처리를 담당합니다.
잡 워크로드는 파드를 실행하고 작업 시작, 실행 중, 완료 상태를 관리합니다.
크론잡(CronJob) 워크로드
잡 워크로드와 유사하지만 잡의 실행을 특정 시간 또는 주기적으로 실행할 수 있습니다. 리눅스에서 많이 사용되는 크론탭(CronTab)과 유사한 설정을 사용합니다.
서비스 노출(Service Expose)
외부에 애플리케이션을 서비스하기 위해서는 파드를 외부 트래픽으로부터 접속할 수 있도록 노출하여야 합니다. 서비스 맵에서는 서비스 노출 리소스를 통해 파드를 외부로 노출합니다.
서비스 노출 리소스는 노출할 파드를 라벨(Label)로 지정합니다. 따라서 같은 라벨을 가진 복제 파드인 경우도 하나의 서비스 노출에서 지정할 수 있습니다. 이 경우 서비스 노출은 트래픽을 지정된 파드들 중 하나로 보내는 부하 분산(Load Balancing)을 수행합니다.
서비스 노출 리소스에는 고정된 IP 주소가 부여됩니다. 이 IP는 클러스터 내에서 사용되는 사설 IP입니다. 고정된 IP를 부여하는 이유는 파드는 재시작 시 IP 주소가 변하기 때문입니다. 만약 파드로 직접 접속한다면 문제가 될 수 있습니다. 따라서 고정 주소를 가진 서비스 노출을 통해 지정된 파드에 접속하는 방식을 사용합니다.
서비스 노출은 노출 방식에 따라 유형을 구분합니다.
클러스터 IP(Cluster IP)로 서비스 노출
클러스터 IP로 서비스를 노출하면, 클러스터 내부에서만 접속할 수 있습니다. 즉, 서비스 맵 내에서 고정 IP를 통해 파드 간 통신을 할 때 클러스터 IP로 서비스 노출을 사용합니다.
클러스터 IP로 서비스를 노출하면 다른 서비스 맵의 파드 간 통신을 할 수 있습니다. 단, 서비스 맵의 네트워크 정책에서 파드의 접속을 허용하여야 합니다.
노드 포트(Node Port)로 서비스 노출
노드 포트는 노드 IP를 사용해 접속하는 포트를 말합니다. 노드 포트로 서비스를 노출하면 외부에서는 노출한 노드 포트로 파드에 접속할 수 있습니다(노드 IP:노드 포트). 노드 포트는 파드가 실행되는 노드뿐만 아니라 클러스터 전체 노드에 지정됩니다. 따라서 어느 노드의 포트로 접속하여도 파드에 접속할 수 있습니다. 보통은 클러스터의 모든 노드를 L4 스위치에 연결하여 접속 주소를 단일화합니다.
노드 포트는 클러스터 설치 시 30000 ~ 32767의 범위가 부여됩니다. 서비스를 노출할 때 자동 또는 포트를 지정하여 노출합니다. 이 범위는 사용자가 설정 할 수 있습니다.
로드밸런서(Load Balancer)로 서비스 노출
클러스터가 클라우드에서 구성될 경우, 로드밸런서를 자동 생성하여 서비스를 노출할 수 있습니다. 이때 파드는 노드 포트로 노출되고 생성된 로드밸런서가 파드 실행 노드와 포트를 연결합니다. 외부에서는 로드밸런서 주소와 포트를 통해 접속할 수 있습니다.
로드밸런서로 서비스 노출은 지원하는 클라우드에서만 가능합니다. 대표적으로 AWS, Azure, GCP가 있고 클라우드 공급자는 클러스터 설치 시 설정합니다.
인그레스(Ingress)
외부에서 파드를 접속하는 방식은 서비스 노출 외에 서비스 맵의 인그레스 리소스가 있습니다. 인그레스는 호스트명/경로로 파드를 외부에 노출합니다(예: abc.com/login, cdf.org/). L7스위치와 유사합니다.
인그레스를 사용하기 위해서는 인그레스 컨트롤러(Ingress Controller)가 클러스터에 설치되어 있어야 합니다. 인그레스 컨트롤러는 외부 트래픽을 받아 인그레스에서 정의된 라우팅 정보(호스트 명/경로 -> 클러스터 IP 서비스 노출)에 따라 파드로 전달합니다. 즉 인그레스 컨트롤러가 외부 서비스로 노출되고, 파드는 클러스터 IP로 서비스를 노출하여 인그레스 규칙으로 라우팅하는 구성을 합니다.
쿠버네티스에서 인그레스 컨트롤러는 파드로 배포됩니다. 따라서 클러스터에 설치 시 노트 포트 또는 로드밸런서로 서비스를 노출하여야 합니다.
참고로 인그레스는 호스트명/경로로 트래픽을 라우팅하기 때문에, 내부 또는 외부 DNS 서버에 호스트명을 등록하고 인그레스 컨트롤러가 이를 사용할 수 있어야 합니다. 칵테일 클라우드는 인그레스 사용을 위한 구성을 기본 제공하여, 별도의 설치 및 설정 작업이 필요 없습니다.
파드의 외부 트래픽이 많을 경우, 전용 인그레스 노드를 클러스터에 구성하기도 합니다. 이 노드에는 인그레스 컨트롤러만 배포되며 복제로 이중화됩니다. 트래픽 증가에 따라 인그레스 노드를 추가하여 확장할 수 있는 장점이 있습니다.
영구 볼륨(Persistence Volume)
파드가 데이터를 저장하고 관리하는 경우 영구 볼륨이 필요합니다. 파드는 언제든지 재시작되고, 노드 장애 시 정상 노드로 재배치될 수 있어, 파드 실행 노드의 디스크를 데이터 저장용으로 사용할 수 없습니다.
영구 볼륨은 파드의 재시작/재배치/삭제 시에도 데이터 유실이 없습니다. 파드의 수명 주기에 독립적으로 관리되기 때문입니다. 영구 볼륨은 클러스터와 함께 구성된 별도 스토리지를 사용합니다.
서비스 맵의 영구 볼륨 리소스는 클러스터의 스토리지를 선택하여 생성합니다. 생성된 영구 볼륨은 파드에 마운트(Mount)하고 컨테이너가 사용합니다. 영구 볼륨은 다중의 파드에서 마운드 할 수 있는 공유 볼륨과 하나의 파드에서만 마운트할 수 있는 단일 볼륨으로 구분됩니다.
영구 볼륨은 클러스터에 스토리지가 구성되어 있어야 합니다. 일반적으로 많이 사용하는 스토리지는 NFS 스토리지입니다. NFS 프로토콜을 지원하는 모든 스토리지를 사용할 수 있습니다.
설정 정보(ConfigMap/Secret)
웹 서버를 컨테이너로 배포할 경우, 서버 실행을 위한 설정 파일을 사용하게 됩니다. 이렇듯 파드가 별도의 설정을 통해 실행되는 경우 설정 정보 리소스로 관리합니다. 설정 파일을 파드의 컨테이너 이미지에 포함하여도 되지만, 이 경우 설정 파일이 변경되면 다시 이미지를 만들어야 합니다.
설정 정보는 서비스 맵에서 생성되고 관리되며, 파드의 컨테이너에 볼륨/파일로 마운트하여 사용할 수 있습니다. 컨테이너 구현에 따라 환경 변수로 전달 가능합니다. 파드 실행 중에도 설정 정보를 변경하고 반영할 수 있다는 장점이 있습니다.
설정 정보 리소스는 관리 방식에 따라 ConfigMap과 Secret으로 구분됩니다. 둘 모두 설정 정보를 관리하는 리소스이지만, Secret의 경우 암호화하여 데이터를 저장하므로, DB 접속 정보 등 보안이 필요한 설정 정보는 Secret를 사용합니다.
이미지 업데이트(Image Update)
서비스 맵의 파이프라인 리소스는 워크로드의 컨테이너 이미지를 업데이트합니다. 워크로드 배포가 완료되면, 파이프라인이 자동 생성되고, 파드의 컨테이너 이미지를 업데이트할 수 있습니다.
서비스 맵에서 워크로드의 파드로 배포된 컨테이너 이미지는 두 가지 유형이 있습니다. 칵테일 클라우드의 빌드로 부터 생성되는 이미지와 외부 레지스트리에 등록된 이미지입니다.
칵테일 클라우드의 빌드로부터 생성되는 이미지는, 애플리케이션 코드 변경 시 자동으로 이미지 생성부터 워크로드에 배포까지의 전 과정을 파이프라인이 자동으로 수행합니다.(칵테일 클라우드의 빌드는 ‘빌드/이미지’ 부분을 참조)
외부 레지스트리의 이미지는 교체를 통해 업데이트를 수행합니다. 이때 파이프라인은 배포 자동화 만을 수행합니다.
카탈로그(Catalog)
서비스 맵의 카탈로그는 하나 이상의 워크로드와 관련된 서비스 맵을 묶어 배포와 업데이트를 수행합니다. 주로 오픈소스 기반의 소프트웨어를 배포하고, 업데이트할 때 사용됩니다.
서비스 맵에 배포된 패키지는 상태/모니터링과 자동 업데이트를 수행할 수 있습니다.
Last updated