Advanced Distributed System

VM

The creation of a virtual(rather than actual) version of something

• Server Proliferation Problem

  몇몇 app들은 자기 자신이 온전히 사용할 수 있는, 환경(OS)을 필요로 한다.
  이 app들을 사용하기 위해 각각에게 물리적 컴퓨터를 하나씩 배정해 주는 것은 낭비이다.
  (app이 24/7 작업중이지 않기 때문에 작업이 없거나 적은 경우 고스란히 유휴 자원으로 낭비되어 버린다.)
  = Under Utilization Problem

  OS 여러개를 하나의 물리 컴퓨터 위에서 돌리면 되지만, 그렇게 하지 못했던 이유는 OS와 하드웨어 간의 긴밀한 결착 때문이다.
  서버의 하드웨어를 통제하기 위해선 드라이버를 통해서만 가능하고, OS들은 그 위 app들이 하드웨어를 사용할 수 있도록 하기 위해
  드라이버를 제공하지만, 이들은 자신들 만의 고유한 드라이버로 다른 OS 에서 사용할 수 없다.
  하드웨어 - 드라이버 (OS 고유) - OS - APP 의 결착이 형성되고 이는 다중 OS를 하나의 하드웨어에서 사용할 수 없는 걸림돌이 된다.

  • 해결책: Hypervisor

    (= Supervisor, VMM(VM Monitor) 이라고도 한다.)
    Hypervisor는 물리 하드웨어와 OS 고유의 드라이버 사이에 위치하여 여러 OS 가 자신이 원하는 방식으로 하드웨어를 사용할 수 있도록 인터페이스를 제공한다.
    Hypervisor를 사용하면 컴퓨터의 리소스를 OS 가 아닌 Hypervisor가 운용하게 된다. 리소스는 Hypervisor의 드라이버로 통제하고, OS 들은 Hypervisor 위에서 Hypervisor가 제공하는 가상 리소스를 사용하게된다.

    메모리가 32GB 밖에 없는데도 8Tb 가 있는 것처럼 보이게 할 수 있다.

    Hardware independence: 실제 Host의 하드웨어가 무엇이든 Guest가 필요로 하는 하드웨어가 있는 것 처럼 조성 가능.
    Isolation: VM이 바이러스가 걸려도 host 는 영향 받지 않음.
    Encapsulation: VM 전체가 파일 몇 개의 형태로 관리될 수 있음.

    VMM 은 반드시 guest VM 보다 높은 권한을 갖고 있어야 한다.

• Virtual Machine

  VM은 물리 서버의 sw 버전이라고 할 수 있다.
  여러대의 VM이 하나의 물리 서버에서 작동할 수 있으며, 각각은 그 위의 app들이 요구하는 사양에 맞게 커스터마이징 되는 것도 가능하다.
  => 하나의 물리 서버 위에 여러대의 VM을 조성해서 윈도우와 리눅스 를 동시에 돌리는 것도 가능해진다.
  VM은 소프트웨어이기 때문에 VM이 가상화 한 물리적 하드웨어의 상태들(cpu 레지스터, 스택…)을 기억장치에 저장해서 freeze 하여 상태를 보존할 수 있다.
  당연히 이 freeze 된 스냅샷들을 이동 또는 복사해서 다른 곳에 정확히 동일한 상태의 VM을 구축하는 것도 가능하다.

  • 장점

    • Efficiency

      여러대의 물리 서버를 하나의 물리 서버에 묶어서 관리 할 수 있으니 관리의 비용이 둘어들고, 유휴자원도 줄어든다.

    • Flexibility

      물리적인 서버에 결착되어 있을 때 보다 시스템을 이동하는게 쉽다.

    그 외 재난적인 상황에 대응하는 것이 쉬워지고, 새로운 app을 provision하는데 소요되는 시간이 엄청나게 줄어든다.

  • 한계

    새로운 레이어가 OS와 하드웨어 사이에 생기게 되어 오버헤드 발생.
    

• Server Consolidation

  여러대의 물리 서버들 위에 나뉘어 동작하던 것들을 하나의 물리 서버로 묶는 것을 말한다.
  VM기술을 이용해 각각의 물리 서버가 제공하고 있는 환경들을 그대로 구현해줄 수 있다.

  서버 운영에 필요한 전력이 감소되는 장점이 있고, 하드웨어 자원을 효율적으로 사용할 수 있게된다.
  

• I/O Virtualization

  1. I/O 작업을 VMM이 주관하는 경우

     VMM 내에 자체 I/O 드라이버를 사용하여 VMM이 직접 I/O 작업 주관.
     + 높은 작업 퍼포먼스
     - 높은 VMM 설계 비용
     - 낮은 오류 내구성 (새로 만든 드라이버다보니 버그 산재)

  2. I/O 작업을 privileged OS 가 주관하는 경우

     VMM 에 privileged Host OS 를 설치하여 해당 호스트가 I/O를 처리하도록 구현
     VMM은 guest VM으로부터 I/O 요청을 받아서 Host VM으로 요청을 다시 돌려줌 + 낮은 VMM 설계 비용
     + 높은 오류 내구성 (검증된 I/O 드라이버 사용)
     - 상당한 I\O 오버헤드
     

  • VMM Overhead
    

    CPU bound workload: OS 가 덜 관여하는 작업으로 오버헤드가 적다. virtualization overhead 가 없다.

    I/O - intensive workload : IO 작업이 빈범하면, OS 가 관여하는 빈도가 높아진다. => 시스템 콜과 privileged instruction 들의 호출이 많아지며 VMM 오버헤드 증가

    I/O intensive, I/O bound workload: I/O 작업 동안 processor 은 쉬어도 되니 Virtualization overhead 가 다소 가려질 수 있다.

• Level of Virtualization

  • Application

    JVM, .NET CLR

  • Library Support

    vCUDA

  • Operation System

    Docker, LXC

  • Hardware Abstraction layer (HAL)

    VMware, Xen, L4

  • Instruction Set Architecture

    QEMU, Bochs

Cloud Computing

• 정의

  Cloud is a parallel and distributed computing system consisting of a collection of inter-connected and virtualized computers
  that are dynamically provisioned and presented as one or more unified computing resources…
  - prof. Buyya

  a pay-per-use model for enabling available, convenient, on-demand network access to a shared pool of configurable computing resources
  that can be rapidly provisioned and released with minimal management effort or service provider interaction.
  - NIST

• 특징

  • 사용한 만큼 과금

  • 무한한 가상 자원에 대한 유연한 제공

  • 관리 시스템 스스로 사용자의 요청에 부합하는 서비스 제공

  • 서비스 제공자의 물리 자원들은 하나의 pool 형태로 추상화 되고, 사용자는 이 pool으로 부터 가상의 자원을 할당받아 사용함.

  • 이용자는 네트워크를 통해 가상 자원에 접속할 수 있어서 장소의 제약에서 자유로워진다.

• 4가지 관점으로 본 Cloud Computing

  1. 접근성 How to Access (유저의 입장)

     Cloud Computing의 리소스를 어떻게 접근할 수 있을까?
     web browser로 Cloud Computing에 접근할 수 있도록 웹 서비스

  2. 사용성 How to use (유저의 입장)

     클라우드 안에 복잡한 구현들은 다 감춰 놓기
     리소스를 다양한(원하는) 형태로 사용할 수 있도록 하기(Grid computing)
     리소스를 사용한 만큼 비용을 내도록 하기 (Utility computing)
     

  3. 어떻게 만드는지 How to create (서비스 제공자의 입장)

     리소스를 어떻게 제공할까? => Hardware Virtualization 기술
     코어가 많이 필요해짐 => 멀티코어 물리 서버

  4. 어떻게 관리하는지 How to manage (공급자의 입장)

     많은 리소스들에 대한 관리 자동화 (Autonomic Computing)
     데이터 센터를 yaml 이라는 것으로 자동화 하기 (Data center Automation) => scale up & down 자동화 복구 자동화…

• Keywords

  • Grid Computing

    여러 분산된 리소스들을 하나의 네트워크로 연결해서 수퍼컴퓨터의 연산력을 만드는 것.

  • Utility Computing

    리소스를 수도나 전기 처럼 필요한 만큼 사용하고, 그 비용을 지불하는 개념.

  • Autonomic Computing

    스스로 그 구성들을 세팅함. (self configuring)
    리소스 사용에 대해 스스로 관리하여 요청된 사항들을 만족하며, 최적의 수행을 할 수 있도록 함. (self optimizing)
    오류에 대한 자체적 탐지와 교정 (self healing)
    공격에 대한 선제적 식별과 방어 (self protecting)

    상황에 따라 자신의 Action을 수정하는 강화학습, 딥러닝을 여기에 적용할 수 있다.

Docker

OS Level 의 가상화를 제공하여 다양한 개발 환경을 가볍고 빠르게 deploy 할 수 있는 환경 제공.

• 특징

  1. Provisioning

     개발에 필요한 이미지들(ubuntu, django, nginx, …)을 다운 받을 수 있는 docker Hub 제공

     세팅한 개발 환경을 그대로 docker registry 로 만들어서 배포할 수 있게 해줌.

     어떠한 호스트에서 docker을 돌리든 상관없이 docker container을 구동할 수 있음.

     • light weight Container

       Union File System 방식으로 원하는 환경을 구축하는데 필요한 여러 이미지 파일들을 read only 로 연결하고, read write 이 가능한 레이어를 그 위에 얹어 디스크 차지 용량이 대폭 감소했다.
       hypervisor 필요 없이도 동작 가능하게 설계되어 오버헤드가 거의 없다.
       (Hypervisor 대신 docker engine이란 것을 사용한다.)
       크기도 작고, 속도도 빠르다.

       workload 상황에 맞추어 동적으로 scale up & down 등을 할 수 있다.
       (똑같은 컨테이너 하나 더 만드는것이 뚝딱)

  2. loosely isolated environment

     호스트 OS 위에서 가상환경을 제공하는데 HAL 가상화 처럼 강력한 분리가 아니라 느슨한 분리를 통해 호스트의 리소스를 낮은 오버헤드로 효율적으로 이용할 수 있다.

     여러개의 Container 들을 하나의 호스트에서 동시에 작동시킬 수 있다. (container 은 VM 에 대응하는 개념)

     단점은 Host가 바이러스에 걸릴 경우 Guest 또한 위험해진다.

     컨테이너들은 서로 isolate 되어 있지만, OS 나 다른 응용 프로그램 이미지(SQL 등) 은 컨테이너간 read only로 공유된다.
     bins/Libs 들을 컨테이너의 writeable 영역에 저장하여 각 컨테이너가 원하는 대로 이 응용들을 사용할 수 있다.

  3. Density

     이미지들을 중복으로 설치하거나 디스크에 저장할 필요가 없어서 저장공간의 사용 효율이 매우 높다.

• 단점

  • Reduced isolation

    호스트와 커널 공유

  • Reduced security

    컨테이너간 코드를 공유

• Architecture

  • Docker Engine (Server)

    • server : Docker daemon

      데몬 프로세스로 도커 오브젝트들을 생성하고, 관리하는 역할을 한다.
      오브젝트: image, container, network, data volume

    • REST API

      server 을 http 프로토콜로 call 할 수 있도록 해줌.
      프로그램들이 도커 데몬에 명령을 할 수 있는 인터페이스를 제공

    • CLI (command line interface)

      REST API 를 사용하여 도커 데몬에 명령을 내리고, 관리할 수 있게 해줌.
      by script & direct CLI commands.

  • Docker Container

    도커 이미지의 runnable instance 이다.

    Union File system 으로 되어 있음.
    도커 레지스트리에 올릴 수 있다.

    CLI 명령과 Docker API 를 이용해 컨테이너를 run, start, stop, move, delete 할 수 있다.

    실행에 필요한 모든 것을 갖추고 있다.
    (code, runtime, system tools, system libraries, …)

    호스트가 리눅스든 윈도우든 같은 컨테이너를 넣으면 항상 똑같이 작동하는 것을 보장

    • C Groups

      구글이 만든 것. 호스트 OS 가 도커 프로세스들에 대해 스케줄링 할 때 도커의 프로세스들을 그룹으로 묶고, CPU 자원을 그룹 단위로 할당받아 사용하게 함.
      호스트 프로세스는 다른 그룹으로 묶여져 있음.
      => 호스트 프로세스들과 스케줄링 충돌 방지

      CPU 뿐만 아니라 메모리, 디스크, IO 등도 도커의 프로세스들을 따로 그룹으로 묶어서 호스트로부터 Isolation.

    • Namespaces

      프로세스들의 이름을 호스트와 다른 네임 스페이스로 나누어서 관리.

    • images

  • Docker Registry / Hub

    도커 레지스트리는 이미지들을 저장할 수 있는 library 이다. (Hub 는 퍼블릭 레지스트리, private registry 도 만들수 있다.)

• 도커 명령어

        
    # 컨테이너 실행 명령어
    docker run -d -p [host]:[container] -v [host-volume]:[container-path] 
        --name [container-name]:[image-name]
    -d (--detach): Background에서 컨테이너 실행 요청
    -p (--port): 컨테이너 노출 포트 설정
    -v (--volume): Volume Mount 설정
    # docker run -d -p 8080:80 -v test-volume:/hello --name nginx nginx
    # 컨테이너 조회 명령어
    docker ps
  
    # 컨테이너 멈춤 명령어
    docker stop [container-name]
  
    # 컨테이너 삭제 명령어
    docker rm [container-name]
  
    # 컨테이너 이미지 삭제 명령어
    docker rmi [container-name]
  
    # 컨테이너 접근 명령어
    docker exec -it [container-name] /bin/bash
    # ex) docker exec -it nginx /bin/bash
  
    # 도커 파일 빌드 명령어
    docker build -t [name] [Dockerfile path]
    # docker build --tag "apache11097" .
        
    

• Dockerfile

        
    FROM:	# Dockerfile 에서 사용할 Base Image
    RUN:	# 새로운 레이어에서 RUN 에 담긴 명령어를 수행하고 새로운 이미지 생성.
            # 명령어엔 Base Image 등이 포함되어 있어야 함.
    COPY:	# Docker 에 없는 Custom File 등을 이미지 레이어에 등록하는 명령어.
            # COPY 는 Local File 을 대상으로 하고, ADD 는 NFS 등 외부 파일도 가능.
    WORKDIR:# cd 와 같은 역할을 하는 명령어. Docker 내부 작업 공간을 설정
    EXPOSE:	# Dockerfile 을 통해 생성된 컨테이너를 외부로 노출시킬 포트 설정.
    ENV:	# path 같은 환경변수 설정
    CMD:	# ["command", "param1", "param2"] / ["param1", "param2"]
            # / command param1 param2 의 형식
            # 컨테이너 생성하고 실행할 때 함께 실행시킬 명령어.
    ENTRYPOINT:	# 컨테이너를 생성하고 실행할 때 함께 실행시킬 명령어. CMD 와 달리 무조건 실행
  
  
    # ex1
        FROM ubuntu:latest
  
        COPY ./shell/ /app
  
        CMD ["bash", "/app/hello_world.sh"]
  
    # ex2
        FROM httpd
  
        COPY ./assets/index.html /usr/local/apache2/htdocs/index.html
        COPY ./assets/from.html /usr/local/apache2/htdocs/from.html
        COPY ./assets/whoami.html /usr/local/apache2/htdocs/whoami.html
        CMD ["apachectl", "-D", "FOREGROUND"]
  
        EXPOSE 80
        
    

micro-service

마이크로 서비스 는 소프트웨어 개발 방법론으로 service-oriented architecture(SOA) 에서 파생된 소프트웨어 개발 방법론으로 application을 여러개의 loosely coupled 서비스 들로 묶어 만드는 것이다.

이때,
서비스는 fine-grained 한 구성들이고,
이들간 프로토콜들은 lightweight 하다.

• Structure

  micro-service 방법론에선 application을 비즈니스 도메인에 대해 기능적으로 분할하여 구조를 설계한다.
  

  Functional decomposition

  • 2 aspects

    • Software design

      기능별로 잘게 나눌 수록 재사용성과 변형 가능성 높아짐.

    • Customer satisfaction

      비즈니스 로직은 개속 변화한다. 기능적 모듈화가 되어 있어 변화에 대응하기 용이하다.

• Domain Driven Design

  먼저 비즈니스 도메인에 대해 이해하는 것이 선행되어야 한다.
  complex한 비즈니스 도메인 컨셉을 추상화하여 independently deployable 서브 도메인들로 나뉘어진 구조를 짜고, 서브 도메인의 개념별로 서비스를 설계한다.

  이때,
  서브 도메인들은 기능적으로 구분되어야 하고(functionally bounded)이를 통해 loosely coupled가 가능해야 한다.

  이렇게 쪼개진 sub domain 들은 서로 machine, OS, platform 도 다르게 설계할 수 있다. (각각이 db 부터 UI 까지 fullstack 을 구현한다.)

  • DDD의 benefit

    1. modularity

       application을 작게 decompose 함으로 modularity가 향상되었다.

       application을 이해, 개발, 테스트 하는 것이 쉬워지고, 아키텍처의 erosion에 더욱 resilient 하게 대응할 수 있게된다.

    2. parallelizes development

       자율적인 소규모 그룹들으로 decompose 된 서브 도메인들을 동시에 개발, 적용할 수 있고, scale 조정 또한 각각의 기능의 수요에 맞게 조정 할 수 있게 되었다.

    3. continuous refactoring

       각각을 계속적인 리펙터링 하는 것이 가능해졌다. (다른 기능들과 loosely coupled 되어 있기 때문)

    4. continuous delivery and deployment

       3과 같은 맥락.

• Classic SOA vs Microservices

  • Classic SOA

    integrates different applications as a set of services
    여러개의 application 을 묶어 하나의 서비스를 만든다.

    웹서비스 기반의 서비스를 여러개 합쳐서 하나의 APP 을 만드는것
    Macro service 를 합쳐 하나의 서비스를 만드는 것.

    목적: Integrate (legacy) Software
    Heavy-weight,
    Orchestration,
    License-driven,
    Intelligent Communication Layer,
    WS*/SOAP

  • micro-services

    architect a single application as a set of services

    하나의 서비스를 여러개의 micro-service 로 나누어 개발한다.

    목적: Architect new Business Platform
    Light-weight,
    Choreography,
    Intelligent Services,
    Dumb Communication Layer,
    HTTP/REST/JSON

• Features of MicroServices

  • Functional system decomposition

    => vertical slicing (서비스가 fullstack. 독립적인 UI, DB를 갖는다.)

  • Independent

    => 한 서비스에서 변경된 내용이 다른 서비스에 영향을 주지 않는다.
    => Quick fixes 와 deployment 가 개별적으로 가능하다.
    => 어떤 기술(os, api,…)을 사용할 지에 대한 자율이 보장된다.
    

  • One team manages everything

    하나의 micro-service 는 하나의 5 - 9명의 개발자로 이루어진 개발 팀에 의해 개발될 수 있어야 한다.(agile 과 궁합이 좋다)
    => 해당 팀은 해당 서비스의 전반에 대해 책임을 질 수 있어야 한다.
    => 하나의 서비스를 기똥차게 완수 할 수 있어야 한다.
    => micro-service 들을 독립시킬 수 있어야 한다.

  • no shared state

    각 서비스는 state를 공유하지 않으며, IPC(inter-process communication)을 하지 않는다.

  • Improved reusability

    개발된 서비스는 여러 프로젝트에서 재사용될 수 있다.

  • only provides an interface

    loosely coupled!
    서로간의 Communication은 합의된 Interface 에 맞게 수행되며, standard 통신 프로토콜을 사용하기도 한다. HTTP(s), REST, JSON

  • Better Scaling

    각각의 micro-service 들은 독립적으로 스케일링 될 수 있어야 한다.
    어떤 micro-service가 부하가 걸린다면, 그 micro-service만 scale up 하면된다.
    

    서비스별 스케일링이 가능한 이유는 state 를 공유하지 않기 때문이다. state를 공유하면 새롭게 증설된 micro-service 서버에 요청을 보내면, 그 새로운 서버는 state를 가지고 있지 않을 수도 있기 때문.
    대신 cookie를 사용하라!

• 3 Aspects of Microservice Architecture

  • Architectural Aspects

    • Bounded Context
    • API gateways
    • polyglot
    • Single responsibility
    • Choreographed
    • Smart endpoint and dumb pipe

  • Technical Aspects

    • Run on its own process
    • Isolates faults
    • Stateless
    • Deployed independently
    • Scales independently
    • Owns its data

  • Organizational Aspects

    • Teams organized around business capabilities
    • Products not projects
    • Culture of automation
    • Small teams
    • You build it you run it
    • Decentralised governance

• Challenges

  • Performance

    모든 서비스간 소통이 네트워크로 이루어짐. (mission critical 한 곳앤 사용 불가.)
    Marshalling overhead (http 헤더 등 오버헤드)

  • Code duplication

    도커 처럼.

  • Transaction

    REST 서비스는 Stateless 를 지향한다.(서비스간 통신: REST)
    따라서 한 서비스 내에서만 트렌젝션이 가능하고, 다른 서비스로 넘어가면 트렌젝션 불가.

  • More than just Infrastructure

    micro-service는 스프링 부트 같은 툴들이 필요하다.
    이를 이용하면 여러가지 복잡한 제반사항을 해결해준다만, 오버헤드나 이런것 문제가 생기겠죠?(사실 잘 모르겠음)

• micro-service benefits

  • Strong Module Boundaries

  • Independent Deployment

  • Technology Diversity

• micro-service costs

  • Distribution

    분산된 시스템은 프로그래밍 하기 어렵다. 각 시스템을 관리하는 call 들은 느리고, call 이 제대로 수행되지 않을 fail의 리스크가 크다.

  • Eventual Consistency

    결국 micro-service들은 하나로 묶여 동작해야 한다. 서비스 개발팀 모두가 이 어려운 다시 묶는 작업을 염두해야 한다.

  • Operational Complexity

    수많은 micro-service들은 지속적으로 발전할 것인데 이러한 지속적인 발전을 관리할 숙련된 팀을 운영해야 한다.

• 언제 micro-service 개발방법론이 좋은가?

  일정 규모 이상의 복잡한 시스템을 개발해야 하는 경우 micro-service 로 개발하는 것이 좋다.

  작은 서비스는 micro-service들을 관리하는 비용이 서비스 규모에 비해 너무 크고,

  서비스 규모가 점점 커질수록 각 기능간 구분을 하는 것이 productivity 향상 효과가 커진다.

• API Gateway

  single entry point into the system.

  responsible for request routing, composition, protocol translation.

  http 프로토콜로 클라이언트와 대화, Gateway 지나서 마이크로 서비스들과는 gRPC 프로토콜로 대화(구글이 개발)

  마이크로 서비스의 failure 을 외부에 드러나지 않게 masking 할 수 있다.

Kubernetes

open source container orchestration platform

loosely coupled collection of components 를 배포하고, 유지하며, 워크로드 스케일링을 위해 만들어졌다.

kubernetes는 declarative configuration과 automation을 지원한다.

kubernetes는 컨테이너화 된 {서비스 or 작업}에 대해 자동화된 deployment, scaling, management 를 자동화해준다.

• Orchestration

  스케일링을 하며 container가 늘어나고, 이들을 상황에 따라 dynamic 하게 관리하는 것이 굉장히 어려워졌다.

  Container orchestration은 다수의 컨테이너의 {scheduling, deployment, scalability, load balancing, availability, networking}을 자동화 하여 관리해주는 것을 뜻한다.

  컨테이너와 서비스의 생애주기를 자동으로 관리하는 것!

• Self Healing

  Desired state 와 실제 Actual state 간 차이를 인식하여 Desired state를 유지하도록 조정.

• 하는 일

  • Autoscale Workloads
  • Blue/Green Deployments
  • Fire off jobs, cron Job을 스케줄링
  • Stateless stateful app 들을 메니징

• 구성

  • Pods

    Atomic Unit.
    하나 이상의 컨테이너로 이루어짐.
    하나의 pod 에 있는 컨테이너들은 볼륨과 namespace, context를 공유한다.
    Ephemeral 하다! (일시적임) => 필요할 때 생성되어 필요 없어지면 사라짐.

  • Services

    여러개의 레이블이 붙은 pod들로 구성되어 있고,
    Not Ephemeral 하다! (영속적임)
    영속적인 resource 를 가지고 있다. (DNS name, static ip)

• Architecture

  • Control Plane

    • kube api-server

      client 들과의 모든 대화는 반드시 API server 을 통해야만 한다.
      REST api interface 를 클라이언트에 제공한다.
      리퀘스트 유효성확인, 권한 확인 등을 하여 쿠버네티스 클러스터의 게이트 키퍼 역할을 한다.

    • Etcd

      클러스터의 데이터 저장소 역할을 한다.
      Raft Consensus 알고리즘으로 fault tolerant 한 데이터를 보장한다.

    • kube controller manager

      클러스터의 상태를 모니터링 하는 primary daemon이다.
      actual state 와 desired state 의 괴리가 발생하면 그 간극을 좁히는 명령들을 내린다.

    • kube scheduler

      스케줄러…
      워크로드 요구사항을 만족하도록 자원할당.

  • Node

    • kubelet

      Node agent

      여기에 속한 pod 들의 lifecycle 관리.
      pod 들을 켜라 꺼라 시키면, kubelet이 이를 실행 하는 명령을 가지고 있어서 kubelet이 집행
      YAML 파일에 적힌 manifests 를 읽고, pod를 생성, 제거를 수행

    • kube proxy

      노드의 네트워크 할당에 대한 작업들

    • Container Runtime Engine

      Docker 등의 컨테이너 엔진들을 조작할 수 있도록 interface를 제공

    *kube proxy

Container Orchestration이 뭔지,

kubernetes 아키텍처