Cloud Native란?

클라우드 컴퓨팅 모델의 이점을 활용하는 애플리케이션 구축 방법론
핵심은 애플리케이션을 어떻게 만드는지, 어떻게 배포하는지이며 애플리케이션이 어디서 동작하는지는 중요하지 않다.

CNCF란?

CNCF(Cloud Native Computing Foundation)는 2015년 12월 리눅스 재단 소속의 비영리 단체. 특이 사항으로는 Kubernetes를 Google에서 기증받았다. CNCF 맴버로는 Intel, Alibaba Cloud, MS Azure, Google, Redhat, SAP, vmware 등등 500개 이상의 글로벌 기업들이 있다.

Apahe란?

Apache는 웹 서버 소프트웨어 및 관련 프로젝트를 개발하는 Apache Software Foundation(ASF)에 의해 관리되는 프로젝트의 일부로 널리 알려진 이름이다. ASF는 다양한 오픈 소스 소프트웨어 프로젝트를 지원하고 개발하는 비영리 단체로, ASF는 이를 주관하고 있다.

Apache HTTP Server: 가장 유묭한 Apache 프로젝트 중 하나로, 단순히 "Apache"라고 불리는 이 웹 서버는 전 세계의 많은 웹 사이트에서 사용되고 있다. 높은 성능, 안정성, 확장성을 제공한다. 다양한 OS에서 실행되며, 모듈화된 아키텍처를 통해 다양한 확장 기능을 추가할 수 있다.

Micro Service Architecture

Micro Service Architecture(이하 MSA)란 커다란 서비스를 각각 세분화하는 방법론을 의미한다.

전통적 시스템 설계 방식은 Monolithic Architecture 한다. 시스템의 모든 구성요소가 한 프로젝트에 통합되어 있는 형식이다.

MSA VS Monolithic

특성	Monolithic Architecture	MicroService Architecture
구조	단일 어플리케이션으로 모두 통합	여러 독립적인 마이크로서비스로 나뉨
배포	전체 어플리케이션을 한 번에 배포	각 마이크로서비스는 독립적으로 배포 가능
확장성	전체 시스템 복제가 필요	필요한 서비스만 확장 가능
기술 다양성	동일한 기술 스택 사용	각 마이크로서비스는 독립적으로 기술 스택 선택 가능
유지보수 및 변경 관리	유지보수와 변경이 복잡	각 서비스는 독립적이며 변경이 다른 서비스에 미치는 영향 최소화
실행 환경	단일 어플리케이션 내에서 실행	여러 서비스가 독립적인 프로세스로 실행
통신 방식	함수 호출 또는 직접 호출	API 호출 및 메시지 큐 등을 통한 통신

그렇다고 MSA가 만능은 아니다. MSA는 설계와 구현 자체가 어렵고 복잡하기 때문에 시스템의Base Complexity 가 일정 이상을 넘어가야 Monolithic보다 생산성이 올라간다. 그러니 처음 프로그램을 만들 때는 Monolithic으로 만드는 걸 추천

---

Container 등장 배경

자신의 컴퓨터나 서버에 여러 대의 서버를 생성하고자 한다면, 여러 개의 VM(Virtual Machine)을 띄워야 한다. 이렇게 여러 개의 VM을 띄우려면 Hypervisor와 같은 소프트웨어를 설치하고 이를 통해 여러 대의 VM을 생성해야 한다. 그런데 이렇게 VM을 생성해서 호스트서버의 효과적으로 많은 서비스를 올리기 위해서 리소스 사용량을 조금 더 가볍게 만들 수 없을까? 에서 만들어진 게 Container engine이다.

Container D, Docker, Cri-o가 대표적인 엔진들이다.

VM VS Container

VM: 기본적으로 서버나 컴퓨터의 Guest OS가 깔리고 그다음 자원을 논리적으로 분리할 수 있는 Hypervisor가 설치되면 VM이 생성된다.

Container: VM에는 OS가 올라가 있지만 Container는 Container Engine을 통해 리소스를 가볍고 효율적으로 사용할 수 있게 된다.

Container Engine: namespace(Kernel)와 cgroups(cpu, memory)을 통해 자원들을 구분한다.

Container 특징

이동성, 배포 편의성

개발 환경과 상용 환경이 다를 경우 개발자는 그의 맞는 라이브러리를 사용하여 개발한다.

개발 환경: 리눅스 6, JDK X
사용 환경: 리눅스 7, JDK Y

Container Image를 통해 서비스 배포에 필요한 다양한 요소들을 포함하여 이미지를 생성한다. 이 Image를 상용 환경에 배포시키면 Container는 자신의 Image가 있는 라이브러리를 사용하기 때문에 환경에 구애받지 않고 시스템을 정상적으로 구동할 수 있게 된다.

Guest OS의 부재
장점

• 자원 효율성 증가
• OS 동시가 감소
  단점
• Host OS와 다른 Container 생성 불가
• 보안 위험성 증가

---

Docker

가장 대표적인 Container Engine

기능

• Docker 이미지를 만드는 기능
• 컨테이너를 생성하는 기능
• 이미지를 공유하는 기능

1. Docker 이미지를 만드는 기능

   Dockerfile

   컨테이너를 실행할 때 사용하는 Container(Docker) Image를 만들기 위한 설정 파일

   Build
   Dockerfile을 기반으로 이미지를 생성

2. 컨테이너를 생성하는 기능

   Run
   생성된 Container(Docker) Image를 통해 컨테이너를 생성

3. 이미지를 공유하는 기능

   Docker Hub
   클라우드 상에 저장소를 생성하여 도커 이미지 저장이 가능하며, 필요시 로컬 PC상에 도커 이미지를 다운로드하여 사용 가능

   ---

Kubernetes

컨테이너들은 가벼운 대신 하나의 VM의 여러 개의 컨테이너가 동작한다면 수많은 컨테이너들을 어떻게 관리할까?

앞서 말한 Docker는 하나의 서비스를 컨테이너로 가상화하여 시켜 배포시키는 역할만 할 뿐, 수많은 서비스의 관리, 배포에 관여하지는 않는다. 따라서 컨테이너 관리자는 VM에 SSH로 접속하여 해당 컨테이너 별로 관리해야 하는 불편함이 발생함.

인프라 관리/ 운영자

• 컨테이너가 너무 많아 관리가 어려움

• 서버가 다운되면 해당 서버 안의 컨테이너 서비스가 모두 죽음

• 수많은 컨테이너 한눈에 모니터링이 어려움

  개발자

• 컨테이너 수가 많다 보니 이미지 통합 관리가 어려움

• 개발에서 배포까지 프로세스를 한 번에 하고 싶다

Kubernetes란? 수많은 컨테이너를 관리할 수 있는 Container Orchestration Tool
알아서 컨테이너를 관리해 주고, 알아서 장애를 막아주고, 알아서 가장 효율적으로 리소스를 관리/실행해 준다

예시: Netflix, Pokemon Go

---

Kubernetes의 구조

무엇을?
시스템 관리자가 하는 작업

• 로깅

• 모니터링 등

  어떻게?

• 선언형 아키텍쳐 기반 Object 배포

  

  Master의 지시를 받아 Worker들이 컨테이너 CRUD를 하는 방식으로 동작

  ---

POD

POD란 Kubernetes에서 컨테이너 대신 사용하는 Computing 단위로서 가장 작은 배포 단위

Master가 원하는 상태의 POD를 입력하면 Worker는 POD 안에 n개의 컨테이너를 탑재하여 배포

---

POD의 장점

POD 내부 컨테이너 간의 IP및 Port 공유를 통한 통신 용이성 향상

예: N개의 컨테이너가 한 개의 Pod에 탑재되어 배포된 애플리케이션의 경우

• 애플리케이션 안의 컨테이너 A,B는 실시간으로 데이터 교환 및 상태 업데이트 필요

• 컨테이너 A,B는 별도의 IP 호출 없이 localhost를 통해서 통신 가능

  POD 내부 컨테이너 간의 디스크 볼륨 공유

  컨테이너 A가 컨테이너 B의 파일 로드 기능
  POD에 로그 수집기를 탑재하여 배포 시 POD내부 컨테이너들의 로그 모두 수집 가능

  ---

Master

Master는 API Server를 통해 Worker를 통제하여 요청을 불러온다. 특정 Worker에 컨테이너 명령하거나 로그를 조회할 때도 Master에 명령을 내리고 Master가 Worker에 접근하여 대신 결과를 응답한다.

API Server

• 모든 요청을 처리하는 마스터의 핵심 모듈, 원하는 상태를 저장하고 상태를 조회한다. 컨테이너 로그를 보여주고 보내는 디버거 역할도 수행한다.

  ---

Scheduler

• 적절한 Worker Node에 Pod 할당

  ---

Kube-Controller

• Kubernetes의 오브젝트의 상태 관리

  ---

etcd

• 클러스터의 모든 설정, 상태를 저장하는 저장소

  ---

Worker

Worker는 Master와 통신하고 필요한 POD를 생성하고, 네트워크나 볼륨을 생성한다.

Kubelet

• POD의 생명주기 관리

proxy

• POD로 연결되는 네트워크 관리, TCP, UDP등을 포워딩 하면서 여러개의 POD를 Round Robin 형태로 묶어서 서비스 제공

  ---

POD가 생성되는 과정

1. Master Node의 kube-apiserver에 Pod 생성을 요청

2. kube-apiserver는 etcd에 새로운 상태를 저장

3. kube-apiserver가 etcd의 상태 변경을 확인하여, kube-controller-manager에게 새로운 Pod 생성을 요청

4. kube-controller-manager는 새로운 Pod를 생성(no assign)을 kube-apiserver에 전달하고, 이를 전달받은 kube-apiserver는 etcd에 저장

5. kube-scheduler는 kube-apiserver에 의해 Pod(no assign)가 확인되면, 조건에 맞는 Worker Node를 찾고 해당 Pod를 할당하기 위해 우선, kube-apiserver는 etcd에 업데이트

6. 모든 Worker Node의 kubelet은 자신의 Node에 할당되었지만, 생성되지 않은 Pod가 있는지 체크하고 있다면 Pod를 생성

7. 해당 Worker Node의 kubelet은 Pod의 상태를 주기적으로 API Server에 전달

   흐름을 보면 각각의 컴포넌트들이 서로 개별적으로 통신하지 않고, API Server를 통해서 통신하는 것을 알 수 있다. 또한 컴포넌트들은 각기 현재 상태를 체크하고 독립적으로 동작하게 된다.

   ---

   Kubernetes 기능

   Self-Healing
   시스템이 영향받을 때마다 Container의 상태 감지 및 비정상적인 경우 자체적으로 교체

   rolling Update & Rollback
   이미지 tag 기능을 통한 버전 관리

   Load Balancing
   Service Object를 사용하여 Pod에 트래픽 분산

   Auto Scaling
   POD의 개수를 조정하는 HPA(Horizontal POD autoscaler)