[NCP] 쿠버네티스 서비스와 쿠버네티스의 주요 컴포넌트 소개

메린·2023년 1월 3일

NCP

목록 보기

17/32

완전관리형 Kubernetes Cluster 제공
- Container의 배포(Scheduling), 운영(HA, Failover), 확장(Scaling)을 자동화하기 위한 플랫폼
- Control Plane 설치, 운영에 대한 고민 없이, 사용자는 Container가 구동되는 Worker Node에 대한 관리만 하면 됨
- Container Registry, Load Balancer 등 네이버 클라우드 플랫폼 다른 서비스와 통합하여 사용 가능

파드는 쿠버네티스 애플리케이션의 기본 실행 단위이다.
쿠버네티스 객체 모델 중 만들고 배포할 수 있는 가장 작고 간단한 단위이다.
1) 단일 컨테이너만 동작하는 파드. "단일 컨테이너 당 한 개의 파드" 모델은 쿠버네티스 사용 사례 중 가장 흔하다. 이 경우, 한 개의 파드가 단일 컨테이너를 감싸고 있다고 생각할 수 있으며, 쿠버네티스는 컨테이너가 아닌 파드를 직저 관리한다고 볼 수 있다.
2) 함께 동작하는 작업이 필요한 다중 컨테이너가 동작하는 파드. 아마 파드는 강하게 결합되어 있고 리소스 공유가 필요한 다중으로 함께 배치된 컨테이너로 구성되어 있을 것이다. 이렇게 함께 배치되어 설치된 컨테이너는 단일 결합 서비스 단위일 것이다. 한 컨테이너는 공유 볼륨에서 퍼블릭으로 파일들을 옮기고, 동시에 분리되어 있는 "사이드카" 컨테이너는 그 파일들을 업데이트 하거나 복구한다. 파드는 이 컨테이너와 저장소 리소스들을 한 개의 관리 가능한 요소로 묶는다.

디플로이먼트란, 애플리케이션을 다운타임없이 업데이트 가능하도록 지원해주는 쿠버네티스 리소스
사용자의 기대상태(Desired State)를 유지하도록 하는 Controller
- Deployment는 ReplicaSet에 대한 Update를 담당
- ReplicaSet은 사용자가 선언한 기대 상태인 Replica의 수를 지속적으로 확인하며 유지 시킴

클러스터 내 Pod들에게 접근하기 위한 방법으로 사용
여러 Pod를 묶어 Healthy한 Pod로 Traffic 라우팅하는 로드 밸런싱 기능 제공
클러스터의 Service CIDR 중에서 지정된 IP로 생성 가능
서비스 이름은 클러스터내 고유한 DNS로 동작
Q. Service Type에는 어떤 것들이 있나요?
- 기본 옵션은 클러스터 내부에서 사용할 수 있는 ClusterIP 타입
- 클러스터 외부에서 내부의 Pod로 접근하기 위해, Service 타입의 변경이 필요
- 앱을 외부에 노출 시, kume-proxy가 해당 포트 Listen을 담당하며 요청을 분산되어 있는 Pod로 전달

Bare Metal 환경에서의 사용

On-Premise환경에서는 CSP사들의 LB와 같은 이용 기대 힘듬
L3 DSR을 이용하는 경우, Service의 externalIPs 속성에 L4 Loopback Interface에 할당된 VIP를 명시하여 사용
L4 Switch는 Syn Packet을 통한 Health Check수행
Pod가 Healthy인 경우, VIP를 통해 Pod의 애플리케이션 접근 가능
NCR은 로드밸런서 및 공인 아이피 사용을 최소화하기 위해, 하나의 VIP에 모든 도메인을 할당
Ingress를 이용하여 HTTP Request의 Host와 URL Path 정보를 통해 타겟 Pod로 라우팅