가상화
  - 1. 호스트 가상화
      Host OS 위에 Guest Os가 구동되는 방식
         - 가상화의 하드웨어를 시뮬레이션 하기에 Host OS에 제약 사항이 많지 않음
         - Host OS 위에 Guest OS가 실행되는 방식으로 OverHeader 가 크게 발생

 -2. 하이퍼바이저 가상화
     하드웨어 위에 하이퍼 바이저를 설치하여 사용하는 방식
       - Host OS 가 없어 overheader가 적으며 직접 하드웨어를 
         가상화 OS가 직접 제어하기에 효율적인 리소스 사용이 가능
       - 자체적인 머신 관리 기능이 없어 다른 컴퓨터나 콘솔이 필요
    하이퍼 바이저의 전 가상화 와 반 가상화
       전 가상화(Ful-Virtualization) - bare-metal or hypervisor
        - 하드웨어를 완전히 가상화 하는 방식으로 Hardware Virtual Machine 이라고도 부름
          하이퍼바이저를 구동하면 DOM0라고 하는 관리용 가상 머신이 실행되며 모든 가상
          머신들은 하드웨어 접근을 DOM0를 통해서 이루어지게 되며 이것은 모든 System 
          Call 에 DOM0가 개입을 한다는 의미 입니다.
        - 하이퍼 바이저는 가상화된 모든 OS(종류에 관계없이)에서 보내는 모든 명령어를 
           이해하여 실행하는 형태
         - 하이퍼 바이저가 모든 명령러를 중계하는 형태의 브로커 역할을 하기에 성능 
            느려질 수 있음(DOM0 하나를 통해서 중계)
          - 하드웨어를 완전히 가상화 하기에 Guest OS의 수정이 필요 없음
          - host의 CPU 가상화 기술을 이용하기에 Intel-VT 또는 AMD-V 등의 물리적인 
            가상 지원이 가능해야 합니다.
         - Trap & Emulate으로 인한 성능 저하 발생

        반가상화(Para-Virtualization)
           - 전가상화와 달리 하드웨어를 완전히 가상화 하지 않음
           - 전가상화의 성능이 느려지는 문제를 해결하기 위해 Hyper-Call 인터페이스를
             통해 하이퍼바이저에게 직접 요청
           - Hyper Call (인터페이스)를 호출 할 수 있도록 guest OS의 커널을 수정해야 하며
             Open 소스 OS가 아니면 반 가상화를 이용하기는 쉽지가 않음
           - 모든 명령어를 DOM0을 통한 전달이 아닌 Hyper Call interface를 호출하는
             방식이어 전 가상화보다 속도가 빠름

========================================================
컨테이너
 개발된 이유
   - 응용프로그램을 개발하고 , PC 또는 노트북의 프로그램을 테스트 서버로 프로그램을 
     배포하고 테스트 서버에서 테스트 완료 후 운영으로 프로그램을 옮기어 실행하면 
     생각하지도 못한 여러가지 오류가 발생되는 것이 개발하는 입장에서는 개발과 
     또 다른 해결해야 할 숙제입니다.
  - 환경마다 설정값(라이브러리 포함), 네트워크, 보안 정책, 스토리지 관리정책 등이 
    달라 이러한 일들이 일어 났습니다. 이것을 해결하기 위해서 소프트웨어를 
    다른 환경으로 이동하면서도 안정적으로 실행 하고자 하는 고민을 하게 되었으며 
    이것에 대한 해결책으로 컨테이너가 탄생했습니다.

 개념
  - 실행에 필요한 응용프로그램의 라이브러리, 바이너리 파일, 환경 파일등을 
    하나의 꾸러미(패키지)로 묶어 배포하는 것에서 출발
  - 개발환경,테스트 환경, 운영환경으로 실행 환경이 변경되어도 실행에 필요한 
    모든 구성들이 하나의 꾸러미로 움직여 오류를 최소화 할 수 있습니다.
  - 운영 체제(OS)를 제외하고 응용프로그램실행에 필요한 모든 구성파일들을 
    꾸러미로 묶는(패키징) 하는 것으로 운영 체제 레벨 가상화 입니다.

 사용 이유
 - 다양한 프로그램, 실행환경을 컨테이너로 추상화 하고 동일한 인터페이스를 제공하여
   프로그램의 배포 및 관리를 단순하게 해주며 , backend 프로그램, 데이터 베이스, 메세지 
   큐 등 많은 프로그램도 컨테이너로 추상화가 가능하고 PC, AWS, Azure,
   Google cloud 등에서도 실행이 가능
 - 서버 가상화를 사용하지 않고 컨터이너를 사용하는 이유로는 size와 수행 속도입니다.
  - 컨테이너는 OS 상에서 실행되는 내용만 가지고 있으미 size 가 MB단위로 
     VM의 GB 단위보다 Size가 작습니다.
  - VM 보다 크기가 작으니 서버당 실행 할 수 있는 수가 VM보다 상대적으로 많습니다.
  - 컨터이너는 OS 부팅이 필요 없이 컨테이너만을 이용해서 실행 시킬 수 있어 
    몇 초 안에 서비스를 실행 할 수 있습니다.
 - 배포를 컨터이너 단위로 할 수 있어 배포도 매우 용이합니다.
컨테이너(container)는 VM이 없으며 게스트 OS도 없습니다. 따라서 더 강력한 가상화 기술이며, PaaS가 대중화 되면서 주목받고 있습니다. 

===========================================================
도커
* 도커와 VM 비교
도커에서 중요한 개념은 이미지와 컨테이너이다.
 - 이미지 : 컨테이너 실행에 필요한 파일과 설정값등을 포함하고 있는
             것으로 변하지 않는다 
  - 베이스 이미지 : 리눅스 배포판의 기본 파일만 설치된 파일이다.
 - 도커 이미지 : 베이스 이미지에 필요한 프로그램과 라이브러리, 
                    소스를 설치한 뒤 파일 하나로 만든 것이다.  
 - 컨테이너    : 이미지를 실행한 상태로 추가되거나 변경되는 값은 
                   모두 컨테이너에 저장된다.
                   동일한 이미지로 다중 컨테이너를 만들경우 하부 이미지에 
                   대한 접근은 공유하나 각각의 컨테이너는 각자의 데이터를 가지고 있게된다.

도커 이미지는 컨테이너를 실행을 위한 모든 정보(실행파일,라이브러리,환경파일 등)를 가지고 있어 용량이 몇백 MB의 크기입니다.
다운로드 하여 처음 사용하는 것은 설치하는 과정이라 모든 정보를 다 다운로드를 받지만 원본 이미지에 파일 하나 수정이나 추가등의 
행위를 한 경우에도 다시 모든 파일을 다운 받으면 효율적이지는 않을 것이다.
항상 모든 정보를 다운 받아야 하는 문제를 도커에서 해결하기 위해 레이어(layer)  개념을 사용하여
유니온 파일 시스템을 이용 여러개의 레이어를 하나의 파일시스템으로 사용할 수 있게 하였다
이미지는 여러 개의 읽기 전용(read only) 레이어로 구성되며 파일이 추가되거나 수정되면 새로운 레이어를 생성합니다.

예) 
   ubuntu 이미지 = a + b + c 
   nginx 이미지에서 ubuntu 이미지를 베이스로 사용을 하면 
        nginx 이미지는  a + b + c  + nginx 로 구성 
   nginx 이미지 기반으로 AP 이미지를 만들면 
        AP 이미지는  a + b + c  + nginx  + source 레이어로 구성
  AP 소스를 수정하면 a, b, c, nginx 레이어는 그대로 사용하고 source(v2) 레이어만 다운 받아서 사용하면된다.

컨테이너를 생성할 때도 레이어 방식을 사용
   기존의 이미지 레이어 위에 읽기- 쓰기(read-write) 레이어를 추가
   이미지 레이어를 그대로 사용하면서 컨테이너가 실행중에 생성하는 
      파일이나 변경된 내용은 읽기/쓰기 레이어에 저장되어 많은 컨테이너를 생성해도 최소한의 용량만 이용

레이어 설계는 여러대의 서버에 배포하는걸 감안하면 단순하지만 엄청나게 편리한 설계 입니다.

컨테이너를 생성할 때도 레이어 방식을 사용
   기존의 이미지 레이어 위에 읽기- 쓰기(read-write) 레이어를 추가
   이미지 레이어를 그대로 사용하면서 컨테이너가 실행중에 생성하는 
      파일이나 변경된 내용은 읽기/쓰기 레이어에 저장되어 많은 컨테이너를 생성해도 최소한의 용량만 이용
레이어 설계는 여러대의 서버에 배포하는걸 감안하면 단순하지만 엄청나게 편리한 설계 입니다.

===========================================================
쿠버네티스 기술과 방식
다른 기술과 마찬가지로 쿠버네티스는 초보자가 기술을 이해하고 습득하는 데 장애가 될 수 있는 기술 용어들이 있습니다. 쿠버네티스를 이해할 수 있도록 좀 더 일반적인 용어로 분류해서 설명해보겠습니다.
마스터: 쿠버네티스 노드를 제어하는 머신입니다. 여기에서 모든 태스크 할당이 시작됩니다.
노드: 할당된 태스크를 요청대로 수행하는 시스템입니다. 쿠버네티스 마스터가 이러한 노드를 제어합니다.
포드: 단일 노드에 배포된 하나 이상의 컨테이너 그룹입니다. 포드에 있는 모든 컨테이너는 IP 주소, IPC, 호스트 이름, 기타 리소스를 공유하며 포드는 기본 컨테이너에서 네트워크와 스토리지를 추상화합니다 이렇게 하면 클러스터에서 컨테이너를 더 쉽게 이동할 수 있습니다.
복제 컨트롤러:  이 컨트롤러는 클러스터에서 실행되어야 하는 동일한 포드 사본의 개수를 제어합니다.
서비스: 포드에서 작업 정의를 분리합니다 쿠버네티스 서비스 프록시는 클러스터에서 다른 위치로 이동한 경우든 교체된 경우든 서비스 요청을 적절한 포드로 자동 수신합니다.
Kubelet: 이 서비스는 노드에서 실행되며 컨테이너 매니페스트를 읽고, 정의된 컨테이너가 시작되어 실행 중인지 확인합니다
kubectl: 쿠버네티스의 명령줄 설정 툴입니다.

쿠버네티스 아키텍처
•컨테이너는 아주 심플하고 우아하게 동작합니다.
•run을 하면 실행되고 stop을 하면 멈춥니다.
•서버-클라이언트 구조를 안다면 컨테이너를 관리하는 에이전트를 만들고
•중앙에서 API를 이용하여 원격으로 관리하는 모습을 쉽게 그려볼 수 있습니다.

•쿠버네티스 또한 중앙(Master)에 API 서버와 상태 저장소를 두고
•각 서버(Node)의 에이전트(kubelet)와 통신하는 단순한 구조입니다.
•하지만, 앞에서 얘기한 개념을 여러 모듈로 쪼개어 구현하고 다양한 오픈소스를 사용하기 때문에 설치가 까다롭고 언뜻 구성이 복잡해 보입니다.
마스터 - 노드 구조

=========================================================
모놀리틱 아키텍처
처음 설계되는 애플리케이션의 구조는 그림 1과 같이 비즈니스 로직을 담당하고 있는 애플리케이션이 존재하고, 해당 애플리케이션은 데이터베이스 등 외부 시스템과 특정 프로토콜로 통신을 하게 됩니다. 또한, 사용자에게 인터페이스를 제공하기 위해서 HTML을 렌더링하는 부분과 RESTful API를 제공하는 부분을 갖게 됩니다. 이렇게 구성된 애플리케이션의 소스코드는 하나의 프로젝트로 구성되어 있으며 단일한 패키지로 배포되게 됩니다.

마이크로서비스 아키텍처
마이크로서비스 아키텍처 패턴은 그 이름에서도 유추할 수 있듯이 모놀리틱 아키텍처로 구성된 하나의 큰 서비스를 독립적인 역할을 수행하는 작은 단위의 서비스로 분리하여 설계하는 패턴을 말합니다. 여기에서 말하는 독립적인 역할이란 주로, ‘사용자 관리’, ‘주문 관리’, ‘결제 관리’, ‘알림 관리’와 같이 기능적인 요소를 의미합니다. 각각의 마이크로서비스는 그 크기만 작을 뿐, 자세히 살펴보면 각각이 하나의 모놀리틱 아키텍처와 유사한 구조를 갖습니다. 다만, 하나의 서비스에서 처리해야 하는 기능과 규모가 작기 때문에 이를 마이크로서비스라고 부릅니다.