Study Note

Spring의 application.properties, application.yaml과 같은 설정 파일로 모든 환경설정 파라미터를 프로젝트와 함께 패칭징 하는 방식으로 많이 운영되고 있습니다. 프로젝트와 함께 설정 파일을 패키징하면 설정 정보가 변경되어야 할 경우 애플리케이션에 설정 파일이 함께 패키징 되어 있기 때문에 애플리케이션 전체를 다시 빌드애야 하는 단점이 있습니다. 이러한 단점을 보안하기 위해서 설정 외부화 패턴을 사용합니다. Spring을 예로 들면 Spring을 Build 한 후에 application.properties만 외부의 다른 파일을 지정해서 실행 할 수 있습니다. 이런 방식으로 서버를 운영할 경우 애플리케이션을 다시 Build 하지 않고 서버를 재실행 하는 작업만 해도 설정을 ..

helm helm은 apt, yum, pip와 비슷하게 플랫폼의 패키지를 관리하는 쿠버네티스 패키지 매니저입니다. helm 패키지는 YAML 형식으로 구성되어 있는 chart를 사용합니다. helm chart 구조 쿠버네티스틑 helm을 이용하여 프로세스(Pod), 네트워크(Service), 저장소(PersistentVolume) 등 어플리케이션에 필요한 모든 자원들을 외부에서 가져올 수 있습니다. values.yaml : 사용자가 원하는 값을 설정하는 파일입니다. templates/ 디렉토리 : 설치할 리소스 파일들이 존재하는 디렉토리입니다. 디렉토리 안에는 Deployment, Service 같은 쿠버네티스 리소스가 YAML 파일 형태로 저장되어 있으며 각 파일의 설정값은 비워져 있고(placehol..

Pod는 쿠버네티스의 최소 실행 단위입니다. 쿠버네티스는 Pod를 통해 기본 가상환경을 제공합니다. 가상환경 플롬폼 실행 단위 비교 가상머신 : Instance 도커 : Container 쿠버네티스 : Pod Pod 특징 1개 이상의 컨테이너 실행 Pod는 1개 이상의 컨테이너를 가질 수 있습니다. 보통 1개의 컨테이너를 실행하며, 3개 이상 넘어가는 경우는 거의 없습니다. 동일 노드에 할당 Pod 내의 실행되는 컨테이너들은 반드시 동일한 노드에 할당되며 동일한 생명주기를 갖습니다. [Pod 삭제 시 Pod 내의 모든 컨테이너 삭제] 고유의 Pod IP Pod 리소스는 노드 IP와 별개로 클러스터 내에서 접근 가능한 고유 IP를 할당 받습니다. 다른 노드에 위치한 Pod(노드의 IP가 다름)라도 Pod ..

쿠버네티스는 그림과 같은 구조를 가지고 있습니다. 마스터 마스터는 쿠버네티스 클러스터를 구성하는 핵심 컴포넌트들을 가지고 있습니다. 마스터는 단일 서버로 구성할 수 있지만 고가용성을 위해 여러 버서를 묶어서 클러스터 마스터로 구축할 수도 있습니다. kube-apiserver(API 서버) : 마스터로 전달되는 모든 요청을 받아 드리는 REST API 서버 etcd(저장소) : 클러스터의 모든 메타 정보를 저장하는 저장소 kube-scheduler(컨테이너 스케줄러) : 사용자의 요청에 따라 컨테이너를 워커 노드에 배치하는 스케줄러 kube-controller-manager(컨트롤러 집합) : 현재 상태와 바라는 상태를 지속적으로 확인하며 특정 이벤트에 따라 특정 동작을 수행하는 컨트롤러 cloud-con..

쿠버네티스는 일반적인 운영체제에서 지원하는 기능들을 비슷하게 제공합니다. 하드웨어 추상화 컨터이너 스케줄링 자원할당 관리 kubectl을 통해 User Interface 제공 쿠버네티스가 바라보는 서버를 바라보는 관점 쿠버네티스의 다음과 같이 서버를 바라보고 있습니다. 서버마다 특정 역할이 정해져 있지 않아 서버마다 특별한 이름을 부여하지 않습니다. 모든 서버(빌드 서버, 웹 서버, 모니터링 서버, DB 서버 등등)들은 워커 서버로 동일합니다. 한두개의 서버가 망가져도 손쉽게 다른 서버에 그 역할을 맡길 수 있습니다. 쿠버네티스안의 모든 서버들은 마스터와 워커로만 구분되어 있습니다. 마스터 : 쿠버네티스를 운용하기 위한 필수적인 핵심 컴포넌트 워커 노드 : 컨터이너를 실행하는 환경으로 특별한 역할을 맡지..

쿠버네티스는 여러 서버로 구성된 클러스터 환경에서 컨터이너화된 프로세스를 관리하기 위한 컨테이너 오케스트레이션(Orchestration) 플랫폼입니다. 이러한 쿠버네티스는 컨테이너의 배포, 확장, 스케줄링을 자동화할 수 있습니다. 컨테이너 오케스트레이션 컨테이너 오케스트레이션은 쉽게 말해 컨테이너를 여러 서버에 걸쳐 여러 개를 실행시키는데 체계적으로 관리하는 기술입니다. 쿠버네티스는 컨테이너 오케스트레이션 플랫폼으로 다음과 같은 역할을 담당합니다. 실행 및 배포 이중화와 가용성 보장 수평적 확장/축소 관리 스케줄링 관리 네트워크 설정 관리 health 체크 설정값 관리 데이터 센터 운영체제 쿠버네티스가 여러 컴퓨터의 집합으로 이루어진 하나의 거대한 시스템을 추상적으로 제어할 수 있는 사용자 인터페이스를 ..

AS(Auto Scaling)과 ASG(Auto Scaling Group) AS(Auto Scaling): AS는 어플리케이션을 모니터링을 하면서 필요한 시점에 자동으로 어플리케이션을 Scale Up 또는 Scale Down 해주는 AWS 서비스입니다. ASG(Auto Scaling Group) : ASG는 AS의 모니터링이 대상이 되는 서버 그룹입니다. ASG는 다음과 같은 서비스를 제공합니다. 증가되는 부하에 맞추어서 확장합니다. (ex. EC2 인스턴스 추가) 감소 된 부하에 맞추어서 축소합니다. (ex. EC2 인스턴스 제거) 최소/최대 인스턴스 설정이 가능합니다. LB에 신규 인스턴스를 자동으로 등록합니다. 문제가 있는 인스턴스를 교체합니다. ASG를 통한 확장 종류 Manual Scaling ..

ELB는(Elastic Load Balancer)는 AWS에서 제공하는 관리 형로드 밸런서로 애플리케이션 트래픽을 Amazon EC2 인스턴스, 컨테이너, IP 주소, Lambda 함수, 가상 어플라이언스와 같은 여러 대상에 자동으로 분산시킵니다. 즉 ELB는 AWS에서 제공하는 서비스중 분산 시스템 서비스입니다. AWS 서비스 중 ELB는 다음 이미지와 같이 사용자 트래픽을 여러 서버에 분산시켜 주는 서비스입니다. 때문에 ELB를 사용함으로써 확장성(scalability)과 고가용성(high availability)을 쉽게 끌어 올릴 수 있습니다. Scalability(확장성)과 High Availability(고가용성) Scalability(확장성) : Scalability는 비즈니스 요구에 맞도록 ..